Re: [whatwg] A plea to Hixie to adopt main, and main element parsing behaviour
Hi Ian, in regards to your post about how main is defined: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0239.html the main element [2] is being standardised at the w3c not the whatwg and as such, the whatwg list moderator has requested that discussion not continue on this list unless new information is provided that will result in a change of his opinion. comments on the spec should be directed as per below: The main element spec is published by the HTML Working Grouphttp://www.w3.org/html/wg/as a Working Draft. If you are not a HTML working group member and wish to make comments regarding this document please send them to public-html-comme...@w3.org (subscribepublic-html-comments-requ...@w3.org?subject=subscribe, archives http://lists.w3.org/Archives/Public/public-html-comments/). If you are a HTML working group member and wish to make comments regarding this document, please send them to public-h...@w3.org (subscribepublic-html-requ...@w3.org?subject=subscribe, archives http://lists.w3.org/Archives/Public/public-html/). All feedback is welcome. Anyone can also file a bug against the spec, as you have in this regard [1], so please add new info there. I will respond to any bugs or comments in due course. [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19591 [2] https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html -- with regards Steve Faulkner
Re: [whatwg] A plea to Hixie to adopt main, and main element parsing behaviour
Hi Steve, Thanks for the info. I had sent it to public-html-comme...@w3.org and had added new info to Bugzilla. Regards, Ian Yang On Sat, Dec 22, 2012 at 7:20 PM, Steve Faulkner faulkner.st...@gmail.comwrote: Hi Ian, in regards to your post about how main is defined: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0239.html the main element [2] is being standardised at the w3c not the whatwg and as such, the whatwg list moderator has requested that discussion not continue on this list unless new information is provided that will result in a change of his opinion. comments on the spec should be directed as per below: The main element spec is published by the HTML Working Grouphttp://www.w3.org/html/wg/as a Working Draft. If you are not a HTML working group member and wish to make comments regarding this document please send them to public-html-comme...@w3.org (subscribepublic-html-comments-requ...@w3.org?subject=subscribe, archives http://lists.w3.org/Archives/Public/public-html-comments/). If you are a HTML working group member and wish to make comments regarding this document, please send them to public-h...@w3.org (subscribepublic-html-requ...@w3.org?subject=subscribe, archives http://lists.w3.org/Archives/Public/public-html/). All feedback is welcome. Anyone can also file a bug against the spec, as you have in this regard [1], so please add new info there. I will respond to any bugs or comments in due course. [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19591 [2] https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html -- with regards Steve Faulkner
Re: [whatwg] A plea to Hixie to adopt main, and main element parsing behaviour
Roger has put his recommendation on a new post (header body footer), I have put my response on there. I don't see this particular suggestion as viable, for details please see the other post. Personally I would love to have a main element because I think there is a really useful purpose; I find it much richer to use articleheader/main/footer//article than articleheader/div/footer//article but I have no specific use-cases which are not currently supported just a general feeling that we've documented a number of common idioms and this seems to be one that's missing. Mat Carey -- Web Developer Consultant m...@matcarey.co.uk www.matcarey.co.uk On 9 Nov 2012, at 19:36, Roger Hågensen resca...@emsai.net wrote: On 2012-11-08 10:51, Steve Faulkner wrote: What the relevant new data clearly indicates is that in approx 80% of cases when authors identify the main area of content it is the part of the content that does not include header, footer or navigation content. It also indicates that where skip links are present or role=main is used their position correlates highly with the use of id values designating the main content area of a page. I'm wondering if maybe the following might satisfy both camps ? Example1: !doctype html html head titletest/title /head divdiv before body/div bodybody text/body divdiv after body/div /html Example2: !doctype html html head titletest/title /head headerheader before body/header bodybody text/body footerfooter after body/footer /html A html document ALWAYS has a body. So why not adjust the specs and free the placement of body, thus allowing div and header and footer blocks before/after. Curretly http://validator.w3.org/check gives warning, but that is easily fixed by allowing it. The other issue is how will older browser handle this (backwards compatibility) and how much/little work is it to allow this in current browsers? I'd rather see body unchained a little than having main added that would be almost the same thing. And if you really need to layout/place something inside body then use a article or div instead of a main. body already have a semantic meaning that's been around since way back when, so why not unchain it? As long as body and /body are within html and /html it shouldn't matter if anything is before or after it. Only issue that might be confusing would be Example3: !doctype html html head titletest/title /head headerheader before body/header bodybody text/body articlearticle outside body/article footerfooter after body/footer /html In my mind this does not make sense at all. So maybe Example2 should be used to unchain body a little. Example2: !doctype html html head titletest/title /head headerheader before body/header bodybody text/body footerfooter after body/footer /html Example4: !doctype html html head titletest/title /head body headerheader before body/header divbody text/div footerfooter after body/footer /body /html Example 4 is how I do it on some projects, while what I actually wish I could do is Example 2 above. Maybe simply unchaining body enough to allow one header and one footer outside (but inside html) would be enough to satisfy people's need? I wondered since the start why header and footer could not be outside body, it seems so logical after all! -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] A plea to Hixie to adopt main, and main element parsing behaviour
On 2012-11-08 10:51, Steve Faulkner wrote: What the relevant new data clearly indicates is that in approx 80% of cases when authors identify the main area of content it is the part of the content that does not include header, footer or navigation content. It also indicates that where skip links are present or role=main is used their position correlates highly with the use of id values designating the main content area of a page. I'm wondering if maybe the following might satisfy both camps ? Example1: !doctype html html head titletest/title /head divdiv before body/div bodybody text/body divdiv after body/div /html Example2: !doctype html html head titletest/title /head headerheader before body/header bodybody text/body footerfooter after body/footer /html A html document ALWAYS has a body. So why not adjust the specs and free the placement of body, thus allowing div and header and footer blocks before/after. Curretly http://validator.w3.org/check gives warning, but that is easily fixed by allowing it. The other issue is how will older browser handle this (backwards compatibility) and how much/little work is it to allow this in current browsers? I'd rather see body unchained a little than having main added that would be almost the same thing. And if you really need to layout/place something inside body then use a article or div instead of a main. body already have a semantic meaning that's been around since way back when, so why not unchain it? As long as body and /body are within html and /html it shouldn't matter if anything is before or after it. Only issue that might be confusing would be Example3: !doctype html html head titletest/title /head headerheader before body/header bodybody text/body articlearticle outside body/article footerfooter after body/footer /html In my mind this does not make sense at all. So maybe Example2 should be used to unchain body a little. Example2: !doctype html html head titletest/title /head headerheader before body/header bodybody text/body footerfooter after body/footer /html Example4: !doctype html html head titletest/title /head body headerheader before body/header divbody text/div footerfooter after body/footer /body /html Example 4 is how I do it on some projects, while what I actually wish I could do is Example 2 above. Maybe simply unchaining body enough to allow one header and one footer outside (but inside html) would be enough to satisfy people's need? I wondered since the start why header and footer could not be outside body, it seems so logical after all! -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] A plea to Hixie to adopt main, and main element parsing behaviour
Hi all, responses in line On 7 November 2012 19:38, Ian Hickson i...@hixie.ch wrote: On Wed, 7 Nov 2012, Simon Pieters wrote: My impression from TPAC is that implementors are on board with the idea of adding main to HTML, and we're left with Hixie objecting to it. If implementors wish to implement something, my objecting is irrelevant. :-) Just implement it. It appears that some implementers would like Hixie to spec main, but he is unwilling as he disagrees with the feature, In a hallway discussion with a microsoft rep at TPAC he indicated that IE would have no objections to implementing the feature was introduced via the HTML WG, which is what is happening at the moment. I also asked other browser implementers who indicated that agreement from Hixie was not a prerequisite for implementation. I suggest what is a prerequisite is clear use cases and data to back them up and a well defined spec of the feature. These are provided via the main spec and linked documents [1] I have also spoken to various browser accessibility engineers who have agreed that it would be a useful addition to complete the HTML element - ARIA landmark mapping, and that the accessibility part would be trivial to implement [4]: I am generally in favor of a main element, and FWIW, implementation of the semantics should be trivial in WebKit, or any UA that supports the ARIA 'main' landmark role already. another data point: when i discussed the main element with one of the mozilla accessibility engineers they suggested that it would be useful for providing a built in skip to content link, which is one of the use cases. Hixie's argument is, I think, that the use case that main is intended to address is already possible by applying the Scooby-Doo algorithm, as James put it -- remove all elements that are not main content, header, aside, etc., and you're left with the main content. The reason there is no element main in the HTML spec currently is that there are no use cases for it that aren't already handled, right. The use cases data and rationale have been provided [1]. If you have objections it would be useful to respond to them rather than restating your position. I think the Scooby-Doo algorithm is a heuristic that is not reliable enough in practice, since authors are likely to put stuff outside the main content that do not get filtered out by the algorithm, and vice versa. That people will get markup wrong is a given. This will not obviously be any less the case with an element named main than an element named article or elements named nav or aside or header. Agreed that people get markup wrong, I don't agree with your supposition that main would be just as prone to mistakes as the other elements you cited. main is a simple concept, and its use is clearly defined, its limitation of use once per page makes it less prone to mistakes in its use, it is based on concepts that are evident in authoring practises and the evidence of the strong correlation between elements (typically divs) identifying the main content area and their use for role=main and the target of skip links indicates the concept is already understood and in use. In fact, when we have looked at actual data for this (see e.g. the recent thread where I went through Steve's data, or the threads years ago when this first came up), it turns out authors are significantly more reliably using class names that relate to marking up navigation blocks and headers, than they are about marking up main. Authors seem to put class=main and equivalents around every possible combination of content in a page, purely based on their styling needs. Problem is Ian, you haven't responded to the data and use cases, you have have misdirected the discussion by continuing to talk about class names, when the data and use cases and rationale are based on the use of id values. Did the year's old previous discussion take into account id value data or skip link data or role=main placement data? What the relevant new data clearly indicates is that in approx 80% of cases when authors identify the main area of content it is the part of the content that does not include header, footer or navigation content. It also indicates that where skip links are present or role=main is used their position correlates highly with the use of id values designating the main content area of a page. furthermore when ARIA role=main is used in 95% [3] of the cases in the data sampled it is used once only which is a clear indicator that authors get how to identify the main content area of a page. * use of a descriptive id to value to identify the main content area of a web page is common. (id=main|id=content|id= maincontent|id=content-main|id=main-content used on 39% of the pages in the sample [2]) * There is a strong correlation between use of role='main' on an element with id values of 'content' or 'main' or permutations. (when used = 101 pages) 77%
Re: [whatwg] A plea to Hixie to adopt main, and main element parsing behaviour
On Wed, 7 Nov 2012, Simon Pieters wrote: My impression from TPAC is that implementors are on board with the idea of adding main to HTML, and we're left with Hixie objecting to it. If implementors wish to implement something, my objecting is irrelevant. :-) Just implement it. Hixie's argument is, I think, that the use case that main is intended to address is already possible by applying the Scooby-Doo algorithm, as James put it -- remove all elements that are not main content, header, aside, etc., and you're left with the main content. The reason there is no element main in the HTML spec currently is that there are no use cases for it that aren't already handled, right. I think the Scooby-Doo algorithm is a heuristic that is not reliable enough in practice, since authors are likely to put stuff outside the main content that do not get filtered out by the algorithm, and vice versa. That people will get markup wrong is a given. This will not obviously be any less the case with an element named main than an element named article or elements named nav or aside or header. In fact, when we have looked at actual data for this (see e.g. the recent thread where I went through Steve's data, or the threads years ago when this first came up), it turns out authors are significantly more reliably using class names that relate to marking up navigation blocks and headers, than they are about marking up main. Authors seem to put class=main and equivalents around every possible combination of content in a page, purely based on their styling needs. Thus if the use case is determine where the boilerplate ends, i.e. skipping navigation blocks, headers, footers, and sidebars, the evidence I've examined suggests that it would be more reliable to have authors mark up those blocks than mark up the main content. Implementations that want to support a go to main content or highlight the main content, like Safari's Reader Mode, or whatever it's called, need to have various heuristics for detecting the main content, and is expected to work even for pages that don't use any of the new elements. However, I think using main as a way to opt out of the heuristic works better than using aside to opt out of the heuristic. On what basis do you draw that conclusion? For instance, it seems reasonable to use aside for a pull-quote as part of the main content, and you don't want that to be excluded, but the Scooby-Doo algorithm does that. If it's a pull quote, why would you _not_ want it excluded? On Wed, 7 Nov 2012, Ojan Vafai wrote: This idea doesn't seem to address any pressing use-cases. I don't expect authors to use it as intended consistently enough for it to be useful in practice for things like Safari's Reader mode. You're stuck needing to use something like the Scooby-Doo algorithm most of the time anyways. Exactly. On Thu, 8 Nov 2012, Kang-Hao (Kenny) Lu wrote: [...] another argument, if I understand correctly, is to use article in place of this role. I think the Web is probably full of mis-used article already such that using the first article in document order has no chance to work out, but it would nice if this can be verified, even though I can already imagine that an author is unlikely to mark up the main content with article when the main content isn't an article in English sense. For the jump to the start of the body use case, article and main seem like they'd be misused exactly as much as each other. James Graham wrote: The observation that having one element on a page marked — via class or id — main is already a clear cowpath enhances the credibility of the suggested solution. On the other hand, I agree that now everyone heading down the cowpath was aiming for the same place; a div class=main wrapping the whole page, headers, footers, and all is clearly not the same as one that identifies the extent of the primary content. Right. Studying the data, as I have done in previous threads, has always indicated that there is actually no cowpath here for main. As James says above, these classes and IDs are used for all kinds of combinations of content and headers, content and navigation, just content, etc. If this is any indication, main wouldn't be useful for its stated purpose. So, assuming skip to main is the only use case for main, which I am not sure if Steve agrees, I think the proposal should use strong wording to prevent such misuse and the proposal should include one example of such misuse and explains it. The strength of the wording will have basically no effect, let's be realistic here. Few authors read the spec. It doesn't matter most of the time, because the failure mode if an author uses em instead of var or vice versa is just that the styling will be slightly off or maintenance will be slightly harder. The failure mode for main would be that its entire reason for existing (making a
