Re: [webkit-dev] HTML5 Parsing & MathML
Alex Milowski milowski.org> writes: sorry for late reply, I'm not subscribed, just saw this in the archives. > > On Fri, Oct 1, 2010 at 12:52 PM, Adam Barth webkit.org> wrote: > > Our parser follows the spec (modulo late-breaking spec changes that we Actually most mathml in the wild will be mis-parsed by the webkit html5 parser because of https://bugs.webkit.org/show_bug.cgi?id=48105 but that's hopefully a temporary glitch. > > haven't picked up yet). The different namespaces can only be nested > > in certain ways, unlike in XML where arbitrary nesting is possible. > > ... > > ... > > > In XHTML, assuming there are appropriate uses of > namespaces, everything would work fine and you'd get a "div" > element fenced with stretching square brackets. It would probably render OK but wouldn't be valid according to the published schemas. As with most "polyglot" requirements assuming xml and html validity goes a log way to ensuring that you get the same dom. > > So, if you cut-n-pasted the same content with the 'xmlns' > attributes, you'd get two very different results. > > That really feels "fixable" but I'm going to need to think a bit > more about what adjustments there would need to be > to the rules. > > I wonder what the intersection of local names is between > MathML and HTML ... By design there is no intersection, although it turns out that browsers implemented (and html5 acknowledges) image as a synonym for img which is therefore the one clash with a mathml name. > > This is, of course, an HTML5 issue and not really an WebKit > issue except for the question of difficulty of implementation. > yep. David ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Parsing & MathML
On Tue, Nov 2, 2010 at 7:55 AM, David Carlisle wrote: > Alex Milowski milowski.org> writes: > > sorry for late reply, I'm not subscribed, just saw this in the archives. > >> >> On Fri, Oct 1, 2010 at 12:52 PM, Adam Barth webkit.org> wrote: >> > Our parser follows the spec (modulo late-breaking spec changes that we > > Actually most mathml in the wild will be mis-parsed by the webkit html5 parser > because of > > https://bugs.webkit.org/show_bug.cgi?id=48105 > > but that's hopefully a temporary glitch. Is this a bug in the HTML5 specification or a bug in our implementation of the spec? If its the former, you might want to file a bug with the HTML working group to resolve the issue. Adam >> > haven't picked up yet). The different namespaces can only be nested >> > in certain ways, unlike in XML where arbitrary nesting is possible. >> >> ... >> >> ... >> >> only > necessary because of html parser strangeness, I think it leads to a cleaner > design, and better fallback behaviour for systems that do not understand the > foreign elements, in any case. > >> >> In XHTML, assuming there are appropriate uses of >> namespaces, everything would work fine and you'd get a "div" >> element fenced with stretching square brackets. > > It would probably render OK but wouldn't be valid according to the published > schemas. As with most "polyglot" requirements assuming xml and html validity > goes a log way to ensuring that you get the same dom. >> >> So, if you cut-n-pasted the same content with the 'xmlns' >> attributes, you'd get two very different results. >> >> That really feels "fixable" but I'm going to need to think a bit >> more about what adjustments there would need to be >> to the rules. >> >> I wonder what the intersection of local names is between >> MathML and HTML ... > > By design there is no intersection, although it turns out that browsers > implemented (and html5 acknowledges) image as a synonym for img which is > therefore the one clash with a mathml name. > >> >> This is, of course, an HTML5 issue and not really an WebKit >> issue except for the question of difficulty of implementation. >> > > yep. > > David > > > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Parsing & MathML
It seems to be the later. This is indeed a regression, but I don't know how to detect when it appeared. From my memory, it was OK a few months ago. François Le 2 nov. 2010 à 17:26, Adam Barth a écrit : > On Tue, Nov 2, 2010 at 7:55 AM, David Carlisle wrote: >> Alex Milowski milowski.org> writes: >> >> sorry for late reply, I'm not subscribed, just saw this in the archives. >> >>> >>> On Fri, Oct 1, 2010 at 12:52 PM, Adam Barth webkit.org> wrote: Our parser follows the spec (modulo late-breaking spec changes that we >> >> Actually most mathml in the wild will be mis-parsed by the webkit html5 >> parser >> because of >> >> https://bugs.webkit.org/show_bug.cgi?id=48105 >> >> but that's hopefully a temporary glitch. > > Is this a bug in the HTML5 specification or a bug in our > implementation of the spec? If its the former, you might want to file > a bug with the HTML working group to resolve the issue. > > Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Parsing & MathML
On Tue, Nov 2, 2010 at 9:52 AM, David Carlisle wrote: > On 2 November 2010 16:26, Adam Barth wrote: >> On Tue, Nov 2, 2010 at 7:55 AM, David Carlisle >> wrote: >>> Alex Milowski milowski.org> writes: >>> >>> sorry for late reply, I'm not subscribed, just saw this in the archives. >>> On Fri, Oct 1, 2010 at 12:52 PM, Adam Barth webkit.org> wrote: > Our parser follows the spec (modulo late-breaking spec changes that we >>> >>> Actually most mathml in the wild will be mis-parsed by the webkit html5 >>> parser >>> because of >>> >>> https://bugs.webkit.org/show_bug.cgi?id=48105 >>> >>> but that's hopefully a temporary glitch. >> >> Is this a bug in the HTML5 specification or a bug in our >> implementation of the spec? If its the former, you might want to file >> a bug with the HTML working group to resolve the issue. >> >> Adam > > I'm pretty sure that it is an implementation issue (firefox 4 doesn't > have this problem for example). Certainly I can't see anything that > would specify parsing something as simple as > > > > > 1 > a > > > > as a completely different tree: > > 1 a > > It makes mathml and svg pretty unusable of course as it's common (very > common in mathml case) to have elements nested within an element of > the same name. Okiedokes. I've CCed Eric and myself on the bug since we're the mostly likely folks to fix the issue. We'd certainly welcome a patch from you, if you're interested in fixing the issue. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] W3C Proposal: User Interface Independence for Accessible Rich Internet Applications
On Mon, Nov 1, 2010 at 1:03 PM, Chris Fleizach wrote: > You reviewed- the first pass at an implementation of this proposal > Sorry for not responding sooner. > https://bugs.webkit.org/show_bug.cgi?id=47301 > > but haven't responded to this thread. Do you have any other objections. > Yes, but I don't know much about screen readers or ARIA, so I might just not understand the proposal. > On Oct 27, 2010, at 2:57 PM, James Craig wrote: > > James Craig responded: > > The main difference seems to be that our Undo and Redo *request* allows the > web application to determine what (if anything) should be undone, or redone, > where the HTML5 undo manager requires that the user agent make the change > directly to the DOM or editable content. The UIRequestEvent interface allows > the app to determine the outcome of the events based on the business logic > of the app, which the browser does not know about. > > I don't really understand how putting "request" in the name of the event is useful. There are plenty of existing events that "allows the app to determine the outcome of the events based on the business logic of the app" but aren't request events. > The reason these are all called 'request' events is because they don't > change anything. They only send a 'request' to the web application (not to > the user agent) to make a change on the user's behalf. The web application > can then intercept or ignore the event as needed. If ignored (if the web app > hasn't registered that event listener, or if the event is not canceled with > preventDefault) then the user agent or assistive technology can fall back to > whatever behavior is deemed appropriate, including then using the HTML5 undo > manager. > > Back to Tony's email: > > Ojan also proposed renaming the textInput event to just beforeInput because > it seems like it can apply to more than just text (e.g., undo'ing the > insertion of an image). Do you think the use of textInput/beforeInput would > meet the use cases needed by UIRequestEvent? > > In some cases, it may be appropriate, but my response to the previous > question may provide additional understanding of why textInput/beforeInput > is not sufficient, and why these two proposals are not mutually exclusive, > even if they do overlap in some places. > > I still don't see why beforeInput would not be sufficient. It might be more clear if you enumerated the list of things you expect to have UIRequestEvents for. > As I stated in the bug tracker comments, the W3C DOM and PF working groups > discussed this, and the outcome was to work on a standalone specification as > a joint effort of the two groups. The initial document editors will likely > be Doug Schepers (W3C staff contact for www-dom) and me. From the > teleconference discussions, these will be an add-on to DOM 3 Events and/or > ARIA 1.0, because both of those documents are currently in Last Call. The > only major change to the proposal so far that we're discussing a new method > to the Event object (perhaps 'suppressEvents' or 'suppressRelatedEvents') so > that we don't have to cancel the event by overloading the original use of > the preventDefault method. > > What's the difference between preventDefault and suppressEvents? Also, earlier in this thread, you said that you don't know of anything that requires these events to be synchronous, but that seems to contradict James's point above and the patch in question fires the events synchronously. The spec text all also implies that the event fires, then application has the chance to prevent it and then the action happens. So, unless I'm misreading, the events need to be synchronous and fire before the associated action occurs. To be clear, my concern so far has just been about UIRequestEvent, which seems to overlap 100% with beforeInput. Some other concerns with the proposal: -UIScrollRequestEvent: Don't we already have a scroll event? Can we just add a scrollType property to it? -UIValueChangeRequestEvent: This doesn't seem generic enough for the example listed. For example, with a range widget, lets say the range is from 1-10 and the user tries to move it from 2 to 5. Is that an INCREMENT_SMALL or INCRMENT_LARGE? If it's just INCREMENT, shouldn't there be some way to communicate the amount it changed? -DOMAttributeChangeRequestEvent: The spec text is pretty vague as to what should and shouldn't fire this. With the spec text, without the note/example, this event sounds a lot like DOMAttrModified and has all the associated problems. There's a note that claims it doesn't have the same problems, but I don't see how that's the case. I'd be happier with this if it were explicitly about ARIA attributes, i.e. AriaChangeEvent. Sorry again for not responding sooner. Ojan > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Parsing & MathML
On Tue, Nov 2, 2010 at 10:17 AM, Adam Barth wrote: > On Tue, Nov 2, 2010 at 9:52 AM, David Carlisle > wrote: > > On 2 November 2010 16:26, Adam Barth wrote: > >> On Tue, Nov 2, 2010 at 7:55 AM, David Carlisle > wrote: > >>> Alex Milowski milowski.org> writes: > >>> > >>> sorry for late reply, I'm not subscribed, just saw this in the > archives. > >>> > > On Fri, Oct 1, 2010 at 12:52 PM, Adam Barth webkit.org> > wrote: > > Our parser follows the spec (modulo late-breaking spec changes that > we > >>> > >>> Actually most mathml in the wild will be mis-parsed by the webkit html5 > parser > >>> because of > >>> > >>> https://bugs.webkit.org/show_bug.cgi?id=48105 > >>> > >>> but that's hopefully a temporary glitch. > >> > >> Is this a bug in the HTML5 specification or a bug in our > >> implementation of the spec? If its the former, you might want to file > >> a bug with the HTML working group to resolve the issue. > >> > >> Adam > > > > I'm pretty sure that it is an implementation issue (firefox 4 doesn't > > have this problem for example). Certainly I can't see anything that > > would specify parsing something as simple as > > > > > > > > > > 1 > > a > > > > > > > > as a completely different tree: > > > > 1 a > > > > It makes mathml and svg pretty unusable of course as it's common (very > > common in mathml case) to have elements nested within an element of > > the same name. > > Okiedokes. I've CCed Eric and myself on the bug since we're the > mostly likely folks to fix the issue. We'd certainly welcome a patch > from you, if you're interested in fixing the issue. This is my bug from the new handling of foreign content mode. I'll upload a patch shortly. James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] W3C Proposal: User Interface Independence for Accessible Rich Internet Applications
On Nov 2, 2010, at 12:48 PM, Ojan Vafai wrote: > On Oct 27, 2010, at 2:57 PM, James Craig wrote: >> James Craig responded: The main difference seems to be that our Undo and Redo *request* allows the web application to determine what (if anything) should be undone, or redone, where the HTML5 undo manager requires that the user agent make the change directly to the DOM or editable content. The UIRequestEvent interface allows the app to determine the outcome of the events based on the business logic of the app, which the browser does not know about. > I don't really understand how putting "request" in the name of the event is > useful. There are plenty of existing events that "allows the app to determine > the outcome of the events based on the business logic of the app" but aren't > request events. The best explanation I have for it now is the following paragraph, or the intro section in the proposal. The reason these are all called 'request' events is because they don't change anything. They only send a 'request' to the web application (not to the user agent) to make a change on the user's behalf. The web application can then intercept or ignore the event as needed. If ignored (if the web app hasn't registered that event listener, or if the event is not canceled with preventDefault) then the user agent or assistive technology can fall back to whatever behavior is deemed appropriate, including then using the HTML5 undo manager. >> Back to Tony's email: >>> Ojan also proposed renaming the textInput event to just beforeInput because >>> it seems like it can apply to more than just text (e.g., undo'ing the >>> insertion of an image). Do you think the use of textInput/beforeInput >>> would meet the use cases needed by UIRequestEvent? >> In some cases, it may be appropriate, but my response to the previous >> question may provide additional understanding of why textInput/beforeInput >> is not sufficient, and why these two proposals are not mutually exclusive, >> even if they do overlap in some places. > > I still don't see why beforeInput would not be sufficient. It might be more > clear if you enumerated the list of things you expect to have UIRequestEvents > for. There are several examples in the proposal, including: Users, wanting to change the value of a custom range widget (ARIA slider, ARIA media progressbar, etc.) in a web application, can indicate their intent a number of ways, including pressing various keys (up, down, left, right, pageup, pagedown, home, end) on most keyboard-controlled interfaces, and through gestures on many touch-enabled interfaces. User agents understanding this intent should initiate a ValueChangeRequest event. Web authors who have registered for this event, should process the event to determine whether to cancel the event. If the value change action is understood in the context of the web application, web authors should change the value of the associated widget by an amount determined via the changeType argument, and cancel the event using the event object's ---() method. If the event is not cancelled by the web author, user agents may pass the literal interaction event to the web application; in this case, in the form of a keypress event. We plan to include more examples in a later draft. >> As I stated in the bug tracker comments, the W3C DOM and PF working groups >> discussed this, and the outcome was to work on a standalone specification as >> a joint effort of the two groups. The initial document editors will likely >> be Doug Schepers (W3C staff contact for www-dom) and me. From the >> teleconference discussions, these will be an add-on to DOM 3 Events and/or >> ARIA 1.0, because both of those documents are currently in Last Call. The >> only major change to the proposal so far that we're discussing a new method >> to the Event object (perhaps 'suppressEvents' or 'suppressRelatedEvents') so >> that we don't have to cancel the event by overloading the original use of >> the preventDefault method. > What's the difference between preventDefault and suppressEvents? preventDefault only prevents the default action of the current event. supressEvents would allow the author to inform the user agent that any remaining events for the same user interaction are no longer relevant. For example, if the user pressed either Delete key and the application intercepted the DeleteRequest event, it could call Event.suppressEvents() (or whatever we call it) to indicate that the related events (keydown, keyup, keypress) are no longer needed, and the user agent should not fire them. > Also, earlier in this thread, you said that you don't know of anything that > requires these events to be synchronous, but that seems to contradict James's > point above and the patch in question fires the events synchronously. The > spec text all also implies that the event fires, t
