[whatwg] main element parsing behaviour
Hi all, After discussions with various implementers there appears to be some questions about the main element and the parsing algorithm Can anyone with the requisite knowledge provide advice on what needs to be added (if anything) to the main element spec [1] to define parsing for the element? also any other feedback welcome. https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] main element parsing behaviour
On Wed, Nov 7, 2012 at 10:55 AM, Steve Faulkner faulkner.st...@gmail.com wrote: Can anyone with the requisite knowledge provide advice on what needs to be added (if anything) to the main element spec to define parsing for the element? What did you do with the feedback you already got on this front? http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0155.html -- http://annevankesteren.nl/
Re: [whatwg] main element parsing behaviour
Hi Anne, That feedback as stated was mainly for Hixie, who dismissed it. I have sought further opinion, but do not have the expertise to know what I need to do with it. for example, I get the sense that implementers in general do not want to mess with the parsing algorithm, so does that mean. I don't need to put anything in the spec? regards SteveF On 7 November 2012 10:30, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Nov 7, 2012 at 10:55 AM, Steve Faulkner faulkner.st...@gmail.com wrote: Can anyone with the requisite knowledge provide advice on what needs to be added (if anything) to the main element spec to define parsing for the element? What did you do with the feedback you already got on this front? http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0155.html -- http://annevankesteren.nl/ -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] main element parsing behaviour
On Wed, 07 Nov 2012 11:40:57 +0100, Steve Faulkner faulkner.st...@gmail.com wrote: Hi Anne, That feedback as stated was mainly for Hixie, who dismissed it. I have sought further opinion, but do not have the expertise to know what I need to do with it. for example, I get the sense that implementers in general do not want to mess with the parsing algorithm, so does that mean. I don't need to put anything in the spec? That's right. I'm not convinced that we should freeze the parser now just because we have reached interop. I think not changing the parser here makes main (and other future elements; whatever we do here sets a precedent for future elements) inconsistent with the rest of HTML. In the long term, having main and aside parse differently just because we didn't want to change the behavior from 2012-era browsers will seem silly. Moreover, it will complicate the already complicated rules about when /p may be omitted (in terms of how people think of the rule), which means that we might have to say that /p is always required. I'm also not convinced by Henri's assertion that p will not precede main in conforming content. p is used for all sorts of things, not just a paragraph of text. -- Simon Pieters Opera Software
Re: [whatwg] main element parsing behaviour
On Wed, 07 Nov 2012 12:46:36 +0100, Simon Pieters sim...@opera.com wrote: On Wed, 07 Nov 2012 11:40:57 +0100, Steve Faulkner faulkner.st...@gmail.com wrote: Hi Anne, That feedback as stated was mainly for Hixie, who dismissed it. I have sought further opinion, but do not have the expertise to know what I need to do with it. for example, I get the sense that implementers in general do not want to mess with the parsing algorithm, so does that mean. I don't need to put anything in the spec? That's right. OTOH, if we wanted main to parse like aside, we'd add main to: [[ A start tag whose tag name is one of: address, article, aside, blockquote, center, details, dialog, dir, div, dl, fieldset, figcaption, figure, footer, header, hgroup, menu, nav, ol, p, section, summary, ul ]] and: [[ An end tag whose tag name is one of: address, article, aside, blockquote, button, center, details, dialog, dir, div, dl, fieldset, figcaption, figure, footer, header, hgroup, listing, menu, nav, ol, pre, section, summary, ul ]] in http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-inbody -- Simon Pieters Opera Software
Re: [whatwg] main element parsing behaviour
On 7.11.2012 12:46, Simon Pieters wrote: I'm not convinced that we should freeze the parser now just because we have reached interop. I think not changing the parser here makes main (and other future elements; whatever we do here sets a precedent for future elements) inconsistent with the rest of HTML. In the long term, having main and aside parse differently just because we didn't want to change the behavior from 2012-era browsers will seem silly. Moreover, it will complicate the already complicated rules about when /p may be omitted (in terms of how people think of the rule), which means that we might have to say that /p is always required. Changing parser each time new element is added is really evil idea and sign of a bad design. Parsing algorithm should be either not touched at all, or it should be promptly changed to treat all unknown elements in other way if the current treatment of unknown elements is not suitable for some reason. Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member --
Re: [whatwg] main element parsing behaviour
On Wed, Nov 7, 2012 at 12:55 PM, Jirka Kosek ji...@kosek.cz wrote: Changing parser each time new element is added is really evil idea and sign of a bad design. HTML badly designed? Film at 11. Parsing algorithm should be either not touched at all, or it should be promptly changed to treat all unknown elements in other way if the current treatment of unknown elements is not suitable for some reason. The problem is that the treatment of an element is largely a function of its purpose. -- http://annevankesteren.nl/
Re: [whatwg] main element parsing behaviour
On Wed, 07 Nov 2012 12:55:46 +0100, Jirka Kosek ji...@kosek.cz wrote: Changing parser each time new element is added is really evil idea and sign of a bad design. Parsing algorithm should be either not touched at all, or it should be promptly changed to treat all unknown elements in other way if the current treatment of unknown elements is not suitable for some reason. There are three ways to parse a new element that we probably want for new elements: inline - like span, current behavior for unknown elements. block - like address, currently a finite list of elements. void - like img, currently a finite list of elements. (Possibly also block void, - like hr, although none such elements have been added since parsing was specified.) If we were to design a system where we can make up new elements that go in one of those categories without changing the parser, I think we effectively have to put a magic string in the tag name, e.g. any element that starts with block is treated like address, but that has disadvantages: * Looking at a substring of the tag name complicates the parser and probably ruins some optimizations. * It means new non-inline elements will have long, ugly two-word names which is inconsistent with the rest of the language. I can imagine other designs as well but they don't seem any better. In conclusion, I think changing the parser when we introduce a new block or void element is a better approach. -- Simon Pieters Opera Software
Re: [whatwg] main element parsing behaviour
On 7.11.2012 13:13, Simon Pieters wrote: If we were to design a system where we can make up new elements that go in one of those categories without changing the parser, I think we effectively have to put a magic string in the tag name, e.g. any element that starts with block is treated like address, but that has disadvantages: * Looking at a substring of the tag name complicates the parser and probably ruins some optimizations. * It means new non-inline elements will have long, ugly two-word names which is inconsistent with the rest of the language. Indeed, this doesn't seem very appealing. I can imagine other designs as well but they don't seem any better. In conclusion, I think changing the parser when we introduce a new block or void element is a better approach. I think it's better to treat all new elements as inline (from parsing point of view) then to change algorithm each time. Changing parsing each time also means that such changes can't be undone. Look for example at hgroup. It's supported by parsing algorithm as implemented in browsers, so it will remain in spec forever even when it's not actually implemented. With such approach parsing algorithm will became boneyard of proposed but later thrown away elements over the time. Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member --
Re: [whatwg] main element parsing behaviour
On Wed, 07 Nov 2012 13:25:14 +0100, Jirka Kosek ji...@kosek.cz wrote: Changing parsing each time also means that such changes can't be undone. They can be undone if doing so doesn't break the Web. Look for example at hgroup. It's supported by parsing algorithm as implemented in browsers, so it will remain in spec forever even when it's not actually implemented. With such approach parsing algorithm will became boneyard of proposed but later thrown away elements over the time. I think we shouldn't put the parsing algorithm on a pedestal while not giving the same treatment to the default UA style sheet or other requirements related to an element that have to be implemented. -- Simon Pieters Opera Software
Re: [whatwg] main element parsing behaviour
On Wed, Nov 7, 2012 at 2:42 PM, Simon Pieters sim...@opera.com wrote: I think we shouldn't put the parsing algorithm on a pedestal while not giving the same treatment to the default UA style sheet or other requirements related to an element that have to be implemented. The difference between the parsing algorithm on the UA stylesheet is that authors can put display: block; in the author stylesheet during the transition. That said, the example jgraham showed to me on IRC convinced me that if main is introduced to the platform, it makes sense to make it parse like article. :-( (I’m not a fan of the consequences of the “feature” of making /p optional. Too bad that feature is ancient and it’s too late on undo it.) I guess I’ll focus on objecting to new void elements and especially to new children of head. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] main element parsing behaviour
On 7.11.2012 13:42, Simon Pieters wrote: Look for example at hgroup. It's supported by parsing algorithm as implemented in browsers, so it will remain in spec forever even when it's not actually implemented. With such approach parsing algorithm will became boneyard of proposed but later thrown away elements over the time. I think we shouldn't put the parsing algorithm on a pedestal while not giving the same treatment to the default UA style sheet or other requirements related to an element that have to be implemented. The difference is that deficiency of parsing algorithm can't be compensated by JS or CSS. Until new element is widely supported you can define it's styling in your CSS file or link to Javascript shim which will provide functionality in older browsers. But I don't think that you can alter parsing algorithm in the similar way. Web browsers are now upgraded much more frequently and regularly so change to PA might look like non problem. But various non-browser applications are relying on HTML5 parsing libraries and those will not be regularly updated. Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member --
Re: [whatwg] main element parsing behaviour
On Wed, 07 Nov 2012 13:47:53 +0100, Henri Sivonen hsivo...@iki.fi wrote: On Wed, Nov 7, 2012 at 2:42 PM, Simon Pieters sim...@opera.com wrote: I think we shouldn't put the parsing algorithm on a pedestal while not giving the same treatment to the default UA style sheet or other requirements related to an element that have to be implemented. The difference between the parsing algorithm on the UA stylesheet is that authors can put display: block; in the author stylesheet during the transition. I guess that's fair. That said, the example jgraham showed to me on IRC convinced me that if main is introduced to the platform, it makes sense to make it parse like article. :-( (I’m not a fan of the consequences of the “feature” of making /p optional. Too bad that feature is ancient and it’s too late on undo it.) For the record, the example is: mainp/mainp (The last p can be anything.) I guess I’ll focus on objecting to new void elements and especially to new children of head. -- Simon Pieters Opera Software
