From adamk at chromium.org Tue Apr 2 12:19:08 2013 From: adamk at chromium.org (Adam Klein) Date: Tue, 2 Apr 2013 12:19:08 -0700 Subject: [whatwg] HTML parsing, the stack of open elements, and foreign content In-Reply-To: References: Message-ID: Since I haven't heard any talk on this thread (or on the w3.org bug), I've landed a patch in WebKit to treat tokens being processed in HTML as if they had an HTML namespace (http://trac.webkit.org/r147441). My reason for landing was that we've already seen two crash bugs due to the WebKit parser getting into a bad state WRT the stack of open elements, and I'd rather not leave us open to more of the same. Note that this change passes all existing html5lib tests. I added one test case, which came (slightly modified) from Rafael's bug: Foo which is now parsed as: | | | | "Foo" |

| | |

| where previously (and in current Firefox) it's parsed as: | | | | | | | is being parsed as HTML (thanks to ), so it searches on the stack for an HTML td to close. There are probably a whole set of similar test cases, but they can be tricky to construct thanks, in part, to the various "escape hatches" from an HTML integration point (including

| | "Foo" That is, the

, and many more). I think the equivalent spec change would be to spell out in detail what it means for a token or element to match something on the stack of open elements. The new WebKit behavior seems more proper to me (and seemed reasonable to those I could raise on #whatwg a few days ago); I also think it's unlikely to affect much real content, so changing it to make the parser's internal state more sane is worthwhile. - Adam On Fri, Mar 15, 2013 at 10:31 AM, Rafael Weinstein wrote: > I just opened another similar bug: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=21292 which has a > similar root cause. > > I agree with Adam that it seems wrong that the stack of open elements > can contain elements in disparate namespaces, but its operation (at > times) only examines the local name (e.g. checking if an element is in > a specific scope, popping elements from the stack of open elements > until an element with the same tag name...) > > On Wed, Feb 27, 2013 at 12:39 PM, Adam Klein wrote: >> Consider the following script: >> >> tr = document.createElement('tr') >> tr.innerHTML = '

>> >> >> >>
>> (the "math" prefixes denote that these are elements with the MathML
>> namespace.) In Gecko, I instead get:
>>
>> >> >> >> >> >>
>> Note that the in both cases is an HTML element, even though in
>> Gecko it's in a MathML tree.
>>
>> The spec for what should happen to that is the first step of
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-intr
>>
>> This case clearly seems like a bug in Gecko: it's treating the > tr> as if it's an HTML . That is, it's comparing only the local
>> name (or "tag name" as the spec usually refers to it).
>>
>> But this same ambiguity exists elsewhere in the spec. For example, the
>> very next item under "in row" says "If the stack of open elements does
>> not have an element in table scope with the same tag name as the
>> token" (in this case, it's looking for a).
>>
>> I think the HTML parser ought to specify more precisely how to deal
>> with namespaces in the stack of open elements, given that that stack
>> can contain elements of varying namespaces.
>>
>> - Adam

From simonp at opera.com  Tue Apr  2 23:50:29 2013
From: simonp at opera.com (Simon Pieters)
Date: Wed, 03 Apr 2013 08:50:29 +0200
Subject: [whatwg] Notifications: in workers
In-Reply-To: References: Message-ID: On Sun, 31 Mar 2013 16:40:16 +0200, Anne van Kesteren wrote:

> There is some interest in exposing Notification objects in a worker so
> creating one does not require a postMessage() roundtrip.
>
> This seems problematic for shared workers as it is not clear which
> window the notification would be for. For normal workers this seems
> like less of a concern.
>
> If we go with the idea of exposing a URL on Notification objects and
> allow that to be set we might be able to address the shared worker
> issue, but it is not entirely clear to me which semantics are
> desirable there.

My knee-jerk reaction is to tie it to MessagePorts, so that if you make a  
notification on a port, the window that owns the entangled port displays  
the notification. If there isn't an entangled port or if it's not in a  
window, I guess it could silently fail.

The above would enable making notifications from one window on behalf of  
another window, if there's a message channel between the two.

> Maybe if we made it a URL prefix it could work. E.g. you create a
> notification with a URL http://example.org/mail/ If that origin is
> allowed to display notifications that will all go well. If there's a
> window open with that URL as prefix it can be focused once the user
> activates the notification. If there's no window open a window can be
> opened with that URL (no longer a prefix in this scenario). However,
> if there's several windows with that URL it's not clear what the best
> way would be. The last window the user interacted with maybe?
>
>
> --
> http://annevankesteren.nl/


-- 
Simon Pieters
Opera Software

From annevk at annevk.nl  Wed Apr  3 07:43:12 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Wed, 3 Apr 2013 15:43:12 +0100
Subject: [whatwg] Notifications: in workers
In-Reply-To: References: Message-ID: On Wed, Apr 3, 2013 at 7:50 AM, Simon Pieters wrote:
> My knee-jerk reaction is to tie it to MessagePorts, so that if you make a
> notification on a port, the window that owns the entangled port displays the
> notification. If there isn't an entangled port or if it's not in a window, I
> guess it could silently fail.
>
> The above would enable making notifications from one window on behalf of
> another window, if there's a message channel between the two.

So port becomes part of the constructor dictionary? I guess that works
as long as the port stays alive however, that still leaves the issue
we have with notifications today. User gets notification in
notification center. Ignores it. Closes browser. Opens browser. Opens
two identical tabs that share a worker. Clicks notification. ...


There's a somewhat related problem of where to show network dialogs
with shared workers that the workers specification does not touch
upon. E.g. what if the network requests proxy authentication? That
cannot always be transparently handled. Should the worker just stop
hold that task until that is in some other way resolved or should the
user get a dialog in some way?


--
http://annevankesteren.nl/

From senorblanco at chromium.org  Wed Apr  3 08:41:09 2013
From: senorblanco at chromium.org (Stephen White)
Date: Wed, 3 Apr 2013 11:41:09 -0400
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: References: <5141E102.2000001@mit.edu> Message-ID: Would Mozilla (or other browser vendors) be interested in implementing the
hint as Gregg described above?

If so, we could break out the LCD text issue from canvas opacity, and
consider the latter on its own merits, since it has benefits apart from LCD
text (i.e., performance). Regarding that, if I'm reading correctly,
Vladimir Vukicevic has expressed support on webkit-dev for the
ctx.getContext('2d', { alpha: false }) proposal (basically, a syntactic
rewrite of). Does this indeed have traction with other
browser vendors?

As for naming, I would prefer that it be something like ctx.fontSmoothing
or ctx.fontSmoothingHint, to align more closely with canvas's
ctx.imageSmoothingEnabled and webkit's -webkit-font-smoothing CSS property.
 -webkit-font-smoothing has "none", "antialiased" and
"subpixel-antialiased" as options. I think it's ok to explicitly call out
subpixel antialiasing, even if the platform (or UA) does not support it,
especially if the attribute explicitly describes itself as a hint.

Stephen


On Sun, Mar 17, 2013 at 11:17 PM, Gregg Tavares wrote:

> On Sun, Mar 17, 2013 at 1:40 PM, Robert O'Callahan >wrote:
>
> > On Sat, Mar 16, 2013 at 5:52 PM, Gregg Tavares wrote:
> >
> >> Let me ask again in a different way ;-)  Specifically about LCD style
> >> antialiasing.
> >>
> >> What about a context attribute "antialiasRenderingQualityHint" for now
> >> with
> >> 2 settings "default" and "displayDependent"
> >>
> >>    context.antialiasRenderingQualityHint = "displayDependent"
> >>
> >
> > How would this interact with canvas opacity? E.g. if the author uses
> > displayDependent and then draws text over transparent pixels in the
> canvas,
> > what is the UA supposed to do?
> >
>
> Whatever the UA wants. It's a hint. From my POV, since the spec doesn't say
> anything about anti-aliasing then it really doesn't matter.
>
> My preference, if I was programming a UA, would be if the user sets
> "displayDependent" and the UA is running on a lo-dpi machine I'd
> unconditionally render LCD-AA with the assumption that the canvas is
> composited on white. If they want some other color they'd fill the canvas
> with as solid color first. Personally I don't think that needs to be
> specced, but it would be my suggestion. As I mentioned, even without this
> hint the spec doesn't prevent a UA from unconditionally using LCD-AA.
>
> Very few developers are going to run into issues. Most developers that use
> canvas aren't going to set the hint. Most developers that use canvas dont'
> make it transparent nor do they CSS rotate/scale them. For those few
> developers that do happen to blend and/or rotate/scale AND set the hint
> they'll get probably get some fringing but there (a) there was no guarantee
> they wouldn't already have that problem since as pointed out, the spec
> doesn't specify AA nor what kind, and (b) if they care they'll either stop
> using the hint or they'll search for "why is my canvas fringy" and the
> answer will pop up on stackoverlow and they can choose one of the
> solutions.
>
>
>
> >
> > Rob
> > --
> > Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
> > Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
> > bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
> > lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe
> fynir
> > ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
> > tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
> >
>

From gman at google.com  Wed Apr  3 09:04:08 2013
From: gman at google.com (Gregg Tavares)
Date: Wed, 3 Apr 2013 09:04:08 -0700
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: References:

or ) and change the CSS based on that. Or Media Queries. But I don't really want to play with either JavaScript or CSS, I don't really know why I should. Especially given that in some comments [1], it is suggested that it is possible to lock the orientation in native apps. Beyond my current project, I have participated to a "FirefoxOS app days" in Bucharest (helped people developing their apps mostly answering their questions). A participant wanted to port his website (games for ~5yo kids) as an FirefoxOS app and told me clearly that if he had no way to lock the screen in landscape, he wouldn't be interested in FirefoxOS (pretty sharp opinion, but that's what he said). Fortunately, that's possible, but one has to use metadata to do so [5]. So I feel the need is there. I was wondering if it would be possible to add a (or whatever else is felt more relevant) to lock the orientation declaratively. It sounds like an information that belongs to the . I feel the FirefoxOS experience [5] sets a good example. Thanks, David [1] http://stackoverflow.com/questions/2772691/is-it-possible-to-prevent-iphone-ipad-orientation-changing-in-the-browser/2772748#2772748 [2] http://stackoverflow.com/questions/8738072/forcing-web-site-to-show-in-landscape-mode-only [3] http://stackoverflow.com/questions/3217805/force-orientation-on-ipad-javascript [4] http://stackoverflow.com/questions/1207008/how-do-i-lock-the-orientation-to-portrait-mode-in-a-iphone-web-application [5] https://developer.mozilla.org/en-US/docs/Apps/Manifest#orientation From chaals at yandex-team.ru Wed Apr 17 16:03:08 2013 From: chaals at yandex-team.ru (Charles McCathie Nevile) Date: Thu, 18 Apr 2013 02:03:08 +0300 Subject: [whatwg] Forcing orientation in content In-Reply-To: <516F27BF.4060508@gmail.com> References: <516F27BF.4060508@gmail.com> Message-ID: Hi, On Thu, 18 Apr 2013 01:52:47 +0300, David Bruant wrote: > Hi, > > Currently working on a web project where tablet support (iPad > especially) is important, I'm facing a need which apparently the > platform doesn't support. > I would need to lock the screen in landscape mode. Not sure if WHATWG is doing anything, but in the W3C there is https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html in the Web Apps group (by Mounir, who works on Firefox OS as a day job) I expect to know a bit more about the implementation status of this in about a week, when the group has a face to face meeting. cheers Chaals > I've been searching and StackOverflow suggested this is not possible > [1][2][3][4]. The best solution that I have read online was to listen to > orientation changes, update an "orient" attribute (on or ) > and change the CSS based on that. Or Media Queries. But I don't really > want to play with either JavaScript or CSS, I don't really know why I > should. Especially given that in some comments [1], it is suggested that > it is possible to lock the orientation in native apps. > > Beyond my current project, I have participated to a "FirefoxOS app days" > in Bucharest (helped people developing their apps mostly answering their > questions). A participant wanted to port his website (games for ~5yo > kids) as an FirefoxOS app and told me clearly that if he had no way to > lock the screen in landscape, he wouldn't be interested in FirefoxOS > (pretty sharp opinion, but that's what he said). Fortunately, that's > possible, but one has to use metadata to do so [5]. > > So I feel the need is there. > > I was wondering if it would be possible to add a (or whatever > else is felt more relevant) to lock the orientation declaratively. It > sounds like an information that belongs to the . I feel the > FirefoxOS experience [5] sets a good example. > > Thanks, > > David > > [1] > http://stackoverflow.com/questions/2772691/is-it-possible-to-prevent-iphone-ipad-orientation-changing-in-the-browser/2772748#2772748 > [2] > http://stackoverflow.com/questions/8738072/forcing-web-site-to-show-in-landscape-mode-only > [3] > http://stackoverflow.com/questions/3217805/force-orientation-on-ipad-javascript > [4] > http://stackoverflow.com/questions/1207008/how-do-i-lock-the-orientation-to-portrait-mode-in-a-iphone-web-application > [5] https://developer.mozilla.org/en-US/docs/Apps/Manifest#orientation -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex chaals at yandex-team.ru Find more at http://yandex.com From mikeday at yeslogic.com Thu Apr 18 00:27:29 2013 From: mikeday at yeslogic.com (Michael Day) Date: Thu, 18 Apr 2013 17:27:29 +1000 Subject: [whatwg] Another issue in 12.2.5.5 parsing tokens in foreign content Message-ID: <516FA061.7020800@yeslogic.com> Hi, Another issue regarding recent changes to 12.2.5.5 "The rules for parsing tokens in foreign content". When a HTML start tag is seen (specifically "b", "big", "blockquote", "body", "br", "center", "code", ...) the following procedure is given to recover from the parse error: """ If the stack of open elements does not have an element in scope that is a MathML text integration point, an HTML integration point, or an element in the HTML namespace, or if the stack of open elements has only one element, then process the token using the rules for the "in body" insertion mode. (fragment case) """ Since the stack of open elements always has at the top of the stack, the "element in scope" algorithm will always find it, and as a result, the first part of the condition will always fail. This seems unintentional, and depends upon the exact way in which the "element in scope" algorithm is defined. Perhaps rewriting this paragraph without reference to the "element in scope" algorithm would make the intent clearer? For example: If the stack of open elements does not any elements that are MathML text integration points, or HTML integration points, or that are in the HTML namespace, or if the stack of open elements has only one element ... Any thoughts? Best regards, Michael From bruant.d at gmail.com Thu Apr 18 01:08:03 2013 From: bruant.d at gmail.com (David Bruant) Date: Thu, 18 Apr 2013 10:08:03 +0200 Subject: [whatwg] Forcing orientation in content In-Reply-To: References: <516F27BF.4060508@gmail.com> Message-ID: <516FA9E3.6000207@gmail.com> Le 18/04/2013 01:03, Charles McCathie Nevile a ?crit : > Hi, > > On Thu, 18 Apr 2013 01:52:47 +0300, David Bruant > wrote: > >> Hi, >> >> Currently working on a web project where tablet support (iPad >> especially) is important, I'm facing a need which apparently the >> platform doesn't support. >> I would need to lock the screen in landscape mode. > > Not sure if WHATWG is doing anything, but in the W3C there is > https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html > in the Web Apps group (by Mounir, who works on Firefox OS as a day job) Thanks for the pointer! But as said very explicitly in the screen orientation draft: " This specification doesn't intend to specify a declarative orientation locking. However, other specifications specify ways to do that. The Web Application Manifest Format and Management APIs [WEBAPPS-MANIFEST-API] specifies a way to declare a default orientation for a web application inside the manifest file." And I really wished it was a declarative thing. I understand the value of locking dynamically in some cases, but both in my use case and the Romanian guy use case, we want to lock the screen once and for all at the beginning. The web browser shouldn't have to wait for JS execution to know how to render things. I'm afraid it will result in a graphic glitch at application startup if a first frame is rendered *before* the JS saying "lockOrientation" is executed. If the locking is expressed declaratively in the , no such glitch is possible, resulting in a better user experience. I feel an inline

'; >> >> That is, the fragment is parsed with tr as the context element. What >> should the generated DOM be? Note that is a "MathML text >> integration point", which causes the

to be processed not as >> foreign content but as a normal HTML token. This leads to the >> following DOM in WebKit: >> >>