Re: [whatwg] A plea to Hixie to adopt main
Stewart Brodie stewart.bro...@antplc.com schrieb am Fri, 14 Dec 2012 14:33:43 +: Steve Faulkner faulkner.st...@gmail.com wrote: Stewart wrote: It doesn't necessarily. I've come across pages that expect the head to be displayed too. e.g. tests at http://meyerweb.com/eric/css/tests/css3/like http://meyerweb.com/eric/css/tests/css3/show.php?p=caption-side Is this a common mark up pattern? I've not gone looking for any other real-world examples - that's the only one I've seen. However, I can't think of any reason why it shouldn't work, as it's just a block box like the body element (usually) is. I have some rules in my user stylesheet for this – among these one that displays the hyperlink with a small orange feed icon for elements matching „link[rel=alternate][title][type='application/rss+xml']“. I use conkeror (a web browser modeled after Emacs – scripting buffers ful of HTML using JavaScript), the configuration can be found here: https://raw.github.com/erlehmann/dotfiles/27cf8d18faad4d8deeb47ebaadcf91ce26357aa6/.conkerorrc When I tried to actually use this for a web page I found that while Gecko (from conkeror) generates Hyperlinks for link elements, WebKit (at least that from Chromium Version 22.0.1229.94) does not. Therefore, I decided against using this styling pattern for my blog sofware. I suggest people test for themselves, as I suspect I may have done something wrong with my user stylesheets in Chromium – it seems counter-intuitive that a link Element does not create a hyperlink: data:text/html;charset=utf-8;base64,PCFET0NUWVBFIEhUTUw%2BPHRpdGxlPkxpbmsgRWxlbWVudCBTdHlsaW5nIFRlc3Q8L3RpdGxlPjxzdHlsZT5oZWFkLGxpbmt7ZGlzcGxheTpibG9ja31saW5rW3RpdGxlXVt0eXBlPSdhcHBsaWNhdGlvbi9yc3MreG1sJ106OmJlZm9yZXtjb250ZW50OidMaW5rOiAnIGF0dHIodGl0bGUpfTwvc3R5bGU%2BPGxpbmsgcmVsPSJhbHRlcm5hdGUiIHRpdGxlPSJGZWVkIiB0eXBlPSJhcHBsaWNhdGlvbi9yc3MreG1sIiBocmVmPSJodHRwOi8vZXhhbXBsZS5vcmcvZmVlZCI%2BYm9keQ0K -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
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
I don't know if this is relevant at all, but according to the spec (section 4.4.1), The body element represents the main content of the document. What would you say is the relation between this use of the term main and your use of the term here? Might it perhaps be more accurate to state, The body element represents the *entire* content of the document (or something like that). I don't really know -- just asking. Cory On Thu, Dec 13, 2012 at 8:22 PM, Tantek Çelik tan...@cs.stanford.edu wrote: This was meant to follow-up to Henri's message[1]: [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-December/038219.html but for some reason that didn't make it to my archives so I'm replying to the latest message on this thread that did. tl;dr: Having previously opposed the addition of a main element, I've been convinced by the arguments (and counter-counter-arguments) and evidence presented[1] that it's worth adding main to HTML. I'm a strong advocate of being conservative of adding new elements to HTML. Every element we add has a cost (in maintenance, learning etc.) and perhaps increasingly so. That's the high bar that has been referenced that has to be met - a new element must provide advantages outweighing the cost to all of us of adding a new element. In particular I am thinking of the cost to authors/developers of continuing to grow HTML and its complexity. aside If anything I think I've grown more conservative regarding new elements in this regard based on experience teaching authors. I used to support hgroup, and though while I personally find it useful in content, I no longer find its addition useful enough for authors in general to overcome the confusion it adds. Similarly with section (which appears to be turning into an alias for div). IMO the outline algorithm is dead and we could simplify HTML by dropping these two. /aside There has been a lot of reference to previous threads (on this list, other lists, etc.) and at some point it becomes useless to say go search the mail archives because no one has time follow all the meandering threads. I've written up a wiki page documenting what I believe to be sufficient arguments to add the main element, along with arguments against that I've heard and rebuttals, as well as counter-proposals made along with flaws in counter-proposals: http://wiki.whatwg.org/wiki/Main_element Contributions/corrections/citations welcome, both for *and* against main. From discussions I've seen there appears to be a growing implementer consensus that adding a main element helps more than it hurts and thus I expect to see it happen. However, I still think adding main is fully supported on principle (rather than just on browser-implementation-Hixie-veto-override) and thus I'm interested in capturing that on the wiki page so that hopefully we can learn from this analysis about adding a new element and use those lessons when considering new elements in the future. Thanks, Tantek
Re: [whatwg] A plea to Hixie to adopt main
Hi Cory, I don't know if this is relevant at all, but according to the spec (section 4.4.1), The body element represents the main content of the document. What would you say is the relation between this use of the term main and your use of the term here? Might it perhaps be more accurate to state, The body element represents the *entire* content of the document (or something like that). I don't really know -- just asking. I filed a bug about this recently: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19967 -- with regards Steve Faulkner
Re: [whatwg] A plea to Hixie to adopt main
Steve Faulkner faulkner.st...@gmail.com wrote: Hi Cory, I don't know if this is relevant at all, but according to the spec (section 4.4.1), The body element represents the main content of the document. What would you say is the relation between this use of the term main and your use of the term here? Might it perhaps be more accurate to state, The body element represents the *entire* content of the document (or something like that). I don't really know -- just asking. I filed a bug about this recently: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19967 It doesn't necessarily. I've come across pages that expect the head to be displayed too. e.g. tests at http://meyerweb.com/eric/css/tests/css3/ like http://meyerweb.com/eric/css/tests/css3/show.php?p=caption-side -- Stewart Brodie Team Leader - ANT Galio Browser ANT Software Limited
Re: [whatwg] A plea to Hixie to adopt main
Steve Faulkner faulkner.st...@gmail.com wrote: Stewart wrote: It doesn't necessarily. I've come across pages that expect the head to be displayed too. e.g. tests at http://meyerweb.com/eric/css/tests/css3/like http://meyerweb.com/eric/css/tests/css3/show.php?p=caption-side Is this a common mark up pattern? I've not gone looking for any other real-world examples - that's the only one I've seen. However, I can't think of any reason why it shouldn't work, as it's just a block box like the body element (usually) is. -- Stewart Brodie Team Leader - ANT Galio Browser ANT Software Limited
Re: [whatwg] A plea to Hixie to adopt main
This was meant to follow-up to Henri's message[1]: [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-December/038219.html but for some reason that didn't make it to my archives so I'm replying to the latest message on this thread that did. tl;dr: Having previously opposed the addition of a main element, I've been convinced by the arguments (and counter-counter-arguments) and evidence presented[1] that it's worth adding main to HTML. I'm a strong advocate of being conservative of adding new elements to HTML. Every element we add has a cost (in maintenance, learning etc.) and perhaps increasingly so. That's the high bar that has been referenced that has to be met - a new element must provide advantages outweighing the cost to all of us of adding a new element. In particular I am thinking of the cost to authors/developers of continuing to grow HTML and its complexity. aside If anything I think I've grown more conservative regarding new elements in this regard based on experience teaching authors. I used to support hgroup, and though while I personally find it useful in content, I no longer find its addition useful enough for authors in general to overcome the confusion it adds. Similarly with section (which appears to be turning into an alias for div). IMO the outline algorithm is dead and we could simplify HTML by dropping these two. /aside There has been a lot of reference to previous threads (on this list, other lists, etc.) and at some point it becomes useless to say go search the mail archives because no one has time follow all the meandering threads. I've written up a wiki page documenting what I believe to be sufficient arguments to add the main element, along with arguments against that I've heard and rebuttals, as well as counter-proposals made along with flaws in counter-proposals: http://wiki.whatwg.org/wiki/Main_element Contributions/corrections/citations welcome, both for *and* against main. From discussions I've seen there appears to be a growing implementer consensus that adding a main element helps more than it hurts and thus I expect to see it happen. However, I still think adding main is fully supported on principle (rather than just on browser-implementation-Hixie-veto-override) and thus I'm interested in capturing that on the wiki page so that hopefully we can learn from this analysis about adding a new element and use those lessons when considering new elements in the future. Thanks, Tantek
Re: [whatwg] A plea to Hixie to adopt main
On Wed, Nov 28, 2012 at 4:26 PM, Ian Hickson i...@hixie.ch wrote: All of this has already been discussed on this mailing list, so this is not new information. I would please refer you to the earlier messages on this topic. In general, unless there is substantial new information, please don't keep posting on a thread in this mailing list -- the list is high-traffic enough without us covering old ground (which is unlikely to result in a different outcome if nothing has changed). I think there are misunderstandings here - in particular about how blind users perceive a Web page. I was trying to be helpful. It seems the cards have fallen and we will just need to continue authoring and preaching @role=main. Sorry about the noise. Regards, Silvia.
Re: [whatwg] A plea to Hixie to adopt main
On Sat, Nov 17, 2012 at 11:01 AM, Ian Hickson i...@hixie.ch wrote: [..] On Sat, 10 Nov 2012, Maciej Stachowiak wrote: I personally think main would be useful. I don't think it has a huge benefit, but it has modest benefits, like aside, header, footer and section. I also think the implementation costs are low. The reasons I think it has some benefits: - Even though heuristics (such as the scooby-doo algorithm or even guesses based on role or class, or the layout) will always be necessary in some cases, it's still good to have a simple and relatively trustworthy marker of the main content. This is useful both for accessibility purposes and for other browser features that want to find the main content. In many cases, we have found that even when semantics can be heuristically inferred, having an explicit marker is still useful. For example, you can usually guess that some text is an address, but we still have a microformat that helps identify such data unambiguously. But we already have this. The main content is whatever content isn't marked up as not being main content (anything not marked up with header, aside, nav, etc). I tried to validate that claim. It's not really possible with today's Web pages, since they haven't moved to making use of these elements, but I made some educated guesses as to where they would be used sensibly on a normal Web page. I have applied this to Google search results, Facebook user pages, YouTube video pages, and Wikipedia articles as examples of some of the most used content on the Web. You can see my results at http://blog.gingertech.net/2012/11/28/the-use-cases-for-a-main-element-in-html/. I believe that none of the heuristic approaches work 100% of the time. In particular Scooby Doo doesn't work because there are far too many layout-only elements that cannot be grasped with header, aside etc and for which we cannot clearly say that the first top-level such element should be regarded as the main content element. Hope that bit of research helps. Regards, Silvia.
Re: [whatwg] A plea to Hixie to adopt main
On Wed, 28 Nov 2012, Silvia Pfeiffer wrote: But we already have this. The main content is whatever content isn't marked up as not being main content (anything not marked up with header, aside, nav, etc). I tried to validate that claim. It's not really possible with today's Web pages, since they haven't moved to making use of these elements, but I made some educated guesses as to where they would be used sensibly on a normal Web page. I have applied this to Google search results, Facebook user pages, YouTube video pages, and Wikipedia articles as examples of some of the most used content on the Web. You can see my results at http://blog.gingertech.net/2012/11/28/the-use-cases-for-a-main-element-in-html/. I think you're massively over-complicating what needs to be authored here. For example, with a Google search, just mark up everything up to the id=main in a header, mark up the id=top_nav as a nav, and mark up the id=foot in a footer, and what's left is the main content. (Note that this does _not_ map to what the authors would have marked up using main, as determined by looking at what they marked up with id=main -- that contains the navigation.) I don't have a Facebook account so haven't checked that one. I don't know what you'd mark up on youtube.com because I don't know what is the main content there. But marking up all the children of id=body-container as header except the id=page-container child, and marking the id=guide-container and first class=branded-page-v2- secondary-col as aside, would make the stream in the middle be the first main content, which is probably what the page author intended. This again doesn't match what the author would likely use for main -- id=content -- which contains the second of those asides currently. Wikipedia already has role=main on the appropriate element, and all the stuff that isn't main (except the appeal) comes after that, so they're fine either way, even without ARIA. Their divs map pretty directly to the elements in HTML so that the algorithm I describe above would surface the main content fine. I believe that none of the heuristic approaches work 100% of the time. Sure. Nor would main. However, on pages written correctly, main would work no better than what HTML already has. Moreover, the difference is that this is main's only purpose, and so the fact that it doesn't solve it all the time means it can't be relied upon, whereas the other elements have other purposes, so that they don't satisfy this 100% of the time doesn't make them pointless. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A plea to Hixie to adopt main
On Wed, Nov 28, 2012 at 10:35 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 28 Nov 2012, Silvia Pfeiffer wrote: But we already have this. The main content is whatever content isn't marked up as not being main content (anything not marked up with header, aside, nav, etc). I tried to validate that claim. It's not really possible with today's Web pages, since they haven't moved to making use of these elements, but I made some educated guesses as to where they would be used sensibly on a normal Web page. I have applied this to Google search results, Facebook user pages, YouTube video pages, and Wikipedia articles as examples of some of the most used content on the Web. You can see my results at http://blog.gingertech.net/2012/11/28/the-use-cases-for-a-main-element-in-html/ . I think you're massively over-complicating what needs to be authored here. For example, with a Google search, just mark up everything up to the id=main in a header, mark up the id=top_nav as a nav, and mark up the id=foot in a footer, and what's left is the main content. (Note that this does _not_ map to what the authors would have marked up using main, as determined by looking at what they marked up with id=main -- that contains the navigation.) Agreed. But what the authors have marked up as @id=main is not relevant for this discussion - it's not what main tries to achieve. We need to look at what is marked up with @role=main and that's a completely different element. Google actually placed a @role=main on a different element, namely the one that encapsulates all the search results. This is where the main should be and that excludes all the columns on the right and left of the search results. I don't know what you'd mark up on youtube.com because I don't know what is the main content there. The feedback that I get from blind users is: the main content is the video and I can't find it. But marking up all the children of id=body-container as header except the id=page-container child, and marking the id=guide-container and first class=branded-page-v2- secondary-col as aside, would make the stream in the middle be the first main content, which is probably what the page author intended. Actually, no - see above. This again doesn't match what the author would likely use for main -- id=content -- which contains the second of those asides currently. No, the element with @id=content is also not the one that main should contain - see above. Wikipedia already has role=main on the appropriate element, and all the stuff that isn't main (except the appeal) comes after that, so they're fine either way, even without ARIA. Their divs map pretty directly to the elements in HTML so that the algorithm I describe above would surface the main content fine. Agreed - it's the simple case. I believe that none of the heuristic approaches work 100% of the time. Sure. Nor would main. When authored correctly or corrected after feedback from blind users, it will work - and it will always work better than the heuristic approach. In addition, there is a large enough blind community in the world to make sure that where it doesn't work they will speak up to get it fixed. For that reason, main is a hint that is always better than any heuristic approach, in particular as accessibility tools do not support any heuristic approaches. Regards, Silvia.
Re: [whatwg] A plea to Hixie to adopt main
On Wed, 28 Nov 2012, Silvia Pfeiffer wrote: On Wed, Nov 28, 2012 at 10:35 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 28 Nov 2012, Silvia Pfeiffer wrote: But we already have this. The main content is whatever content isn't marked up as not being main content (anything not marked up with header, aside, nav, etc). I tried to validate that claim. It's not really possible with today's Web pages, since they haven't moved to making use of these elements, but I made some educated guesses as to where they would be used sensibly on a normal Web page. I have applied this to Google search results, Facebook user pages, YouTube video pages, and Wikipedia articles as examples of some of the most used content on the Web. You can see my results at http://blog.gingertech.net/2012/11/28/the-use-cases-for-a-main-element-in-html/ I think you're massively over-complicating what needs to be authored here. For example, with a Google search, just mark up everything up to the id=main in a header, mark up the id=top_nav as a nav, and mark up the id=foot in a footer, and what's left is the main content. (Note that this does _not_ map to what the authors would have marked up using main, as determined by looking at what they marked up with id=main -- that contains the navigation.) Agreed. But what the authors have marked up as @id=main is not relevant for this discussion - Yes, it is, because by and large that's exactly the element that people are going to use main for. Most people aren't going to use main for accessibility reasons. That's not how most authors think. They'll use it for styling. We have to design the language with that in mind. That's why we have things like header and nav and aside _instead_ of something like main. The feedback that I get from blind users is: the main content is the video and I can't find it. Then browsers should let blind users have the ability to jump to video elements. No need for the page to be marked up at all being video. (But not that there's no video on the youtube.com home page, unless you mean the ad.) When authored correctly or corrected after feedback from blind users, it will work - Exactly. In other words, it won't work, because it's unlikely to be authored correctly, and feedback from blind users by and large has no effect on sites. There's also the assumption that what you want is just to jump to a part of the page, rather than read the page from top to bottom, just skipping the parts of the page that aren't hugely interesting, like navigation. I actually think that's the better UI here. That is, rather than: DALLAS - On a rainy night in early Summer, a tiny kitten with... ...getting: Pegasus News. (skipping navigation, press space to hear skipped sections.) Help Charlie the kitten find a new home. (skipping navigation.) DALLAS - On a rainy night in early Summer, a tiny kitten with... Even in the best-case scenario, main gets you the worse UI above, whereas using nav and aside and so forth can get you the second. http://www.pegasusnews.com/news/2012/nov/27/help-charlie-kitten-find-new-home/ All of this has already been discussed on this mailing list, so this is not new information. I would please refer you to the earlier messages on this topic. In general, unless there is substantial new information, please don't keep posting on a thread in this mailing list -- the list is high-traffic enough without us covering old ground (which is unlikely to result in a different outcome if nothing has changed). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A plea to Hixie to adopt main
On Sat, Nov 17, 2012 at 8:01 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 15 Nov 2012, Ian Yang wrote: That's a good idea. We really need an element to wrap all the ps, uls, ols, figures, tables ... etc of a blog post. That's called article. Thanks Hickson. Actually I had turned down my own opinion ( http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0182.html ). And isn't article used to wrap an entire blog post? Like this: article header / div / footer / /article Are you suggesting that we code it like the following one? article header / article / footer / /article Regards, Ian Yang
Re: [whatwg] A plea to Hixie to adopt main
Hi Ian, Responses in line. FYI For any implementers or other interested parties the main element specification [2] is currently in a call for consensus to publish as a first public working draft (over at the W3C) [3] On Thu, 8 Nov 2012, Steve Faulkner wrote: http://www.w3.org/html/wg/wiki/User:Sfaulkne/main-usecases#Introduction This page has the following: | Enable users to be able to navigate to and recognise the boundaries of | the main content area This is done by main (because of the likely authoring failures) no more reliably, and possibly in fact less reliably, than is already possible with things like aside. Requiring a the presence of number of elements and having those elements used correctly, (some of which from anecdotal reports author,s find difficult to use correctly), to provide an indication of something else, appears wholey more prone to failure than using one element that as specced [2] is clear in its use and based on current authoring practices. http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0067.html http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0162.html | Enable authors to style the main content area of a page specifically. This is already possible with div. It would make sense to have a more specific element if there was a cowpath, but there isn't: there is a clear cowpath and the data has been provided. 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. With all due respect, you have to ignore the data to come to that conclusion. Look at your own data: authors put this semantic all over the place. There is _no_ evidence that they'd do better with main. I have looked at the data and no they do not put div id=main content all over the place they put it approx 80% of the time in the right place. http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0162.html Did the year's old previous discussion take into account id value data or skip link data or role=main placement data? I do not recall the specifics. ARIA didn't exist back then, so clearly it wasn't examined, though. 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. Where do you get this number from? I looked at a couple of hundred pages [1] in the sample that I have added styling to show the use of id=main or id=content noting the borders and what content is and is not contained within them. 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. How do you determine this correlation? (Are you just using the word colloquially?) What does this correlation mean? Are they all using both incorrectly? (That would get you good correlation too.) What about pages that do not give skip links or role=main? (Pages that use those features are going to be disproportionally biased towards competent authors, which makes it dangerous to draw conclusions from that sample. see above , approx 80% I have provided the data set from which my statements are derived, if you want to disprove them you can analyse the same data set. 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. I think that's a wildly optimistic conclusion. Lots of pages only use body once, that doesn't mean they use it correctly. :-) again I have provided the data set if you disagree you can analyse the data. * 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]) As I discuss in the e-mail cited several times above, the area they indicate with these IDs is not reliably the main content. For example, it might or might not include the footer, sidebars, navigation links, headings, etc. well no, you are making suppositions again, the data set is available for analysis if you disagree with my conclusions based on my analysis of the data you can run your own analysis. * 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% were on an element with id values of 'content' or 'main' or permutations. I don't see what this tells us. Obviously if someone is going to mark an element as role=main, they'll use the same element for id=main.
Re: [whatwg] A plea to Hixie to adopt main
Hi Tim, Are you saying we should not introduce a main element... I don't believe I ever said anything about not introducing a mainelement. I'm very much on the fence about it. I've been trying to carefully balance the pros and cons to avoid a biased judgement. Here are some of what I've come up with. Pro: Adding a main element will provide a semantic element that developers can use to indicate primary content of a document. Con: Adding a main element adds redundancy to the [role=main] attribute. I don't see why this is a con, if main is mapped to role=main in the browser it means that authors won't have to. Also adding aside/article/footer etc adds redundancy to the matching ARIA roles. Pro: Adding a main element will allow developers to use a format such as: body header / main / footer / /body which tends to be quite clean and understandable (the easier it is to read code, the easier it is to fix code). Con: Implementing the main element in a backwards compatible manner requires JavaScript. it is/was the same for any of the new structural elements. Pro: Assistive technologies can use the main element as a means to rapidly navigate to the primary content. Con: The main element can only be used once per page. Pages with multiple content areas, or fragmented content would need to pick a single content region as primary, or not use the element. This restriction will likely cause more confusion than if multiple main elements were allowed. From the data it does not appear that authors are confused about use of role=main or the use of semantic id values to designate the main content area. Authors do not appear to have an issue with marking up div id=main and using it once per page. I think that the restrictions make it easier to use and understand rather than harder. Pro: The main element can only be used once per page. This forces the author to decide exactly where the main focus of the page lies, rather than relying on assumptions. Con: The main element is supposed to exclude content that is repetitious across pages, but content is often interspersed with blocks of advertisements, modules, CTAs and the like. authors can use more granular elements within the main element, to structure content, example: main article/ aside advertisements/aside article/ /main can you provide some examples of the sort of pages you are talking about? It would be useful. Personally, I'd rather see main be more about marking up content in general, such as in this example which is invalid given the current state of the spec: article id=1 header / main / footer / /article article id=2 header / main / footer / /article ...although this would probably fit better as a content element, and would require a whole other line of discussion that can wait for another day. Indeed, this appears to be something different from what the main element is designed for. Regards SteveF
Re: [whatwg] A plea to Hixie to adopt main
On Thu, Nov 15, 2012 at 12:59 PM, Tim Leverett ...@gmail.com wrote: Personally, I'd rather see main be more about marking up content in general, such as in this example which is invalid given the current state of the spec: article id=1 header / main / footer / /article article id=2 header / main / footer / /article ...although this would probably fit better as a content element, and would require a whole other line of discussion that can wait for another day. ☺ That's a good idea. We really need an element to wrap all the ps, uls, ols, figures, tables ... etc of a blog post.
Re: [whatwg] A plea to Hixie to adopt main
On Thu, Nov 15, 2012 at 7:27 PM, Ian Yang i...@invigoreight.com wrote: On Thu, Nov 15, 2012 at 12:59 PM, Tim Leverett ...@gmail.com wrote: Personally, I'd rather see main be more about marking up content in general, such as in this example which is invalid given the current state of the spec: article id=1 header / main / footer / /article article id=2 header / main / footer / /article ...although this would probably fit better as a content element, and would require a whole other line of discussion that can wait for another day. ☺ That's a good idea. We really need an element to wrap all the ps, uls, ols, figures, tables ... etc of a blog post. I'm sorry, but I have to eat my above words. Previously I proposed that main being a sectioning element for a better document outline ( https://www.w3.org/Bugs/Public/show_bug.cgi?id=19591#c0). So the use of mains in all blog posts won't help improving the document outline. Regards, Ian Yang
Re: [whatwg] A plea to Hixie to adopt main
Con: Adding a main element adds redundancy to the [role=main] attribute. I don't see why this is a con, if main is mapped to role=main in the browser it means that authors won't have to. Also adding aside/article/footer etc adds redundancy to the matching ARIA roles. Redundancy tends to be a source of error if they get out of sync. If one browser supports [role=main] and another supports main, both would be needed to provide compatibility. Obviously this is a bit contrived, as browsers supporting main would likely also support [role=main], but older versions would not support main . Going forward, this would mean that authors wanting to use main would have to use main role=main for backwards compatibility. I could be wrong on this, but I was pretty certain that article and the rest were supported by browsers before the ARIA roles model. Con: Implementing the main element in a backwards compatible manner requires JavaScript. it is/was the same for any of the new structural elements. Yes, and that's a con for using any of the newer HTML5 elements over ARIA roles. authors can use more granular elements within the main element, to structure content, example: main article/ aside advertisements/aside article/ /main Good point on the aside I hadn't thought of that. ☺ On Thu, Nov 15, 2012 at 6:43 AM, Ian Yang i...@invigoreight.com wrote: On Thu, Nov 15, 2012 at 7:27 PM, Ian Yang i...@invigoreight.com wrote: On Thu, Nov 15, 2012 at 12:59 PM, Tim Leverett ...@gmail.com wrote: Personally, I'd rather see main be more about marking up content in general, such as in this example which is invalid given the current state of the spec: article id=1 header / main / footer / /article article id=2 header / main / footer / /article ...although this would probably fit better as a content element, and would require a whole other line of discussion that can wait for another day. ☺ That's a good idea. We really need an element to wrap all the ps, uls, ols, figures, tables ... etc of a blog post. I'm sorry, but I have to eat my above words. Previously I proposed that main being a sectioning element for a better document outline ( https://www.w3.org/Bugs/Public/show_bug.cgi?id=19591#c0). So the use of mains in all blog posts won't help improving the document outline. Regards, Ian Yang
Re: [whatwg] A plea to Hixie to adopt main
Con: Adding a main element adds redundancy to the [role=main] attribute. I don't see why this is a con, if main is mapped to role=main in the browser it means that authors won't have to. Also adding aside/article/footer etc adds redundancy to the matching ARIA roles. Redundancy tends to be a source of error if they get out of sync. If one browser supports [role=main] and another supports main, both would be needed to provide compatibility. Obviously this is a bit contrived, as browsers supporting main would likely also support [role=main], but older versions would not support main . Going forward, this would mean that authors wanting to use main would have to use main role=main for backwards compatibility. yes this is true, same goes for the other new elements today. I see little issue with the redundancy though as the roles match the elements. I could be wrong on this, but I was pretty certain that article and the rest were supported by browsers before the ARIA roles model. no - the majority of accessibility APIs did/do not have non ARIA based roles specified for header/footer/article/aside etc some APIs are adding roles based on ARIA (Mac AX, Iaccessible2 etc) accessibility implementation in browsers for the semantics of these elements is variable [1] [1] http://www.html5accessibility.com/ regards SteveF
Re: [whatwg] A plea to Hixie to adopt main
On Fri, Nov 16, 2012 at 1:45 AM, Tim Leverett ...@gmail.com wrote: Con: Adding a main element adds redundancy to the [role=main] attribute. I don't see why this is a con, if main is mapped to role=main in the browser it means that authors won't have to. Also adding aside/article/footer etc adds redundancy to the matching ARIA roles. Redundancy tends to be a source of error if they get out of sync. If one browser supports [role=main] and another supports main, both would be needed to provide compatibility. Obviously this is a bit contrived, as browsers supporting main would likely also support [role=main], but older versions would not support main . Going forward, this would mean that authors wanting to use main would have to use main role=main for backwards compatibility. Actually, there's a good point: I would actually add this: if main or an element with @role=main exist on the page, there is no need to run the Scooby-Doo algorithm and that element can just be chosen as the main element. Silvia.
Re: [whatwg] A plea to Hixie to adopt main
On 15 November 2012 19:20, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Fri, Nov 16, 2012 at 1:45 AM, Tim Leverett ...@gmail.com wrote: Con: Adding a main element adds redundancy to the [role=main] attribute. I don't see why this is a con, if main is mapped to role=main in the browser it means that authors won't have to. Also adding aside/article/footer etc adds redundancy to the matching ARIA roles. Redundancy tends to be a source of error if they get out of sync. If one browser supports [role=main] and another supports main, both would be needed to provide compatibility. Obviously this is a bit contrived, as browsers supporting main would likely also support [role=main], but older versions would not support main . Going forward, this would mean that authors wanting to use main would have to use main role=main for backwards compatibility. Actually, there's a good point: I would actually add this: if main or an element with @role=main exist on the page, there is no need to run the Scooby-Doo algorithm and that element can just be chosen as the main element. What if both exist but are different elements? -- Eitan Adler
Re: [whatwg] A plea to Hixie to adopt main
On Thu, Nov 15, 2012 at 8:21 PM, Eitan Adler li...@eitanadler.com wrote: Actually, there's a good point: I would actually add this: if main or an element with @role=main exist on the page, there is no need to run the Scooby-Doo algorithm and that element can just be chosen as the main element. What if both exist but are different elements? Favor the first or most ancestral occurrence.
Re: [whatwg] A plea to Hixie to adopt main
On Fri, Nov 16, 2012 at 12:21 PM, Eitan Adler li...@eitanadler.com wrote: On 15 November 2012 19:20, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Fri, Nov 16, 2012 at 1:45 AM, Tim Leverett ...@gmail.com wrote: Con: Adding a main element adds redundancy to the [role=main] attribute. I don't see why this is a con, if main is mapped to role=main in the browser it means that authors won't have to. Also adding aside/article/footer etc adds redundancy to the matching ARIA roles. Redundancy tends to be a source of error if they get out of sync. If one browser supports [role=main] and another supports main, both would be needed to provide compatibility. Obviously this is a bit contrived, as browsers supporting main would likely also support [role=main], but older versions would not support main . Going forward, this would mean that authors wanting to use main would have to use main role=main for backwards compatibility. Actually, there's a good point: I would actually add this: if main or an element with @role=main exist on the page, there is no need to run the Scooby-Doo algorithm and that element can just be chosen as the main element. What if both exist but are different elements? Good question. I'd likely choose main over @role=main. Silvia.
Re: [whatwg] A plea to Hixie to adopt main
What if both exist but are different elements? Favor the first or most ancestral occurrence. I concur. ☺ On Thu, Nov 15, 2012 at 8:48 PM, Hugh Guiney hugh.gui...@gmail.com wrote: On Thu, Nov 15, 2012 at 8:21 PM, Eitan Adler li...@eitanadler.com wrote: Actually, there's a good point: I would actually add this: if main or an element with @role=main exist on the page, there is no need to run the Scooby-Doo algorithm and that element can just be chosen as the main element. What if both exist but are different elements? Favor the first or most ancestral occurrence.
Re: [whatwg] A plea to Hixie to adopt main
Hi *Tim*, I was just trying to make the point that an algorithmic approach to finding the main content of a document would still be necessary with or without the main element. The same can be said for any of the structural semantic elements, what we know is that some authors mark up headings, nav, footer, articles etc incorrectly or not at all. What we also know is that user agents do not generally implement heuristics to provide semantic information to users, they rely upon explicit markup to expose semantic structures to convey meaning and provide navigation of content. For example, ARIA landmark roles are now supported in most browsers and assistive technology and used by browsers for built in mapping of roles for new HTML structural elements that do not have platform accessibility API specific roles (most do not). regards SteveF Hope you're not just trolling I was just trying to make the point that an algorithmic approach to finding the main content of a document would still be necessary with or without the main element. ☺ On Tue, Nov 13, 2012 at 7:03 PM, Silvia Pfeiffer silviapfeiff...@gmail.comwrote: On Wed, Nov 14, 2012 at 4:25 AM, Tim Leverett ...@gmail.com wrote: Explicit author markup would make such a task so much easier. Only if every author marked up their code correctly. If some authors use incorrect markup, then an algorithm would still be necessary for determining if each usage was correct. Hope you're not just trolling. From a browser perspective, if there is one main element and it sits within body, that would be sufficiently correct. Whether it's semantically correct for a particular application, that's not something the HTML spec should or could deal with. We don't protect people from putting the wrong text in tags - not in microdata, not in article or anywhere else. An application may care - or they may trust the author and if the author cares enough, they will fix up their markup if it doesn't achieve the right goal. But I'm sure you were just trolling... ;-) Cheers, Silvia. http://www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] A plea to Hixie to adopt main
Steve, What we also know is that user agents do not generally implement heuristics to provide semantic information to users, they rely upon explicit markup to expose semantic structures to convey meaning and provide navigation of content. I am aware of that, but the point I was making was in regard to Silvia's email about the github visualreference tool that she found. From a non-UA standpoint, such as crawling service for a search engine, heuristics would still be needed to accurately identify primary content. So when Silvia said: I'm sure a lot of other people had to solve this problem as well and have done so in their own special way. Explicit author markup would make such a task so much easier. I was disagreeing with that point because there's no way to implicitly trust the author, in the same way that search engines can't trust meta name=keywords / I probably should have made that all explicit to begin with, ☺ ☺ On Wed, Nov 14, 2012 at 6:01 AM, Steve Faulkner faulkner.st...@gmail.comwrote: Hi *Tim*, I was just trying to make the point that an algorithmic approach to finding the main content of a document would still be necessary with or without the main element. The same can be said for any of the structural semantic elements, what we know is that some authors mark up headings, nav, footer, articles etc incorrectly or not at all. What we also know is that user agents do not generally implement heuristics to provide semantic information to users, they rely upon explicit markup to expose semantic structures to convey meaning and provide navigation of content. For example, ARIA landmark roles are now supported in most browsers and assistive technology and used by browsers for built in mapping of roles for new HTML structural elements that do not have platform accessibility API specific roles (most do not). regards SteveF Hope you're not just trolling I was just trying to make the point that an algorithmic approach to finding the main content of a document would still be necessary with or without the main element. ☺ On Tue, Nov 13, 2012 at 7:03 PM, Silvia Pfeiffer silviapfeiff...@gmail.comwrote: On Wed, Nov 14, 2012 at 4:25 AM, Tim Leverett ...@gmail.com wrote: Explicit author markup would make such a task so much easier. Only if every author marked up their code correctly. If some authors use incorrect markup, then an algorithm would still be necessary for determining if each usage was correct. Hope you're not just trolling. From a browser perspective, if there is one main element and it sits within body, that would be sufficiently correct. Whether it's semantically correct for a particular application, that's not something the HTML spec should or could deal with. We don't protect people from putting the wrong text in tags - not in microdata, not in article or anywhere else. An application may care - or they may trust the author and if the author cares enough, they will fix up their markup if it doesn't achieve the right goal. But I'm sure you were just trolling... ;-) Cheers, Silvia. http://www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] A plea to Hixie to adopt main
Apologies for misunderstanding - the smiley led me to believe it may not have been a real concern. I did answer in good faith though, so back to the concern. You are absolutely correct that an algorithmic approach would still be necessary to resolve the situation when main is not provided in the same way that browsers create a body tag when it's not provided or a head etc. Scooby-Doo seems both simple enough and appropriate for this. I'm sure a lot of other people had to solve this problem as well and have done so in their own special way. Explicit author markup would make such a task so much easier. I was disagreeing with that point because there's no way to implicitly trust the author, in the same way that search engines can't trust meta name=keywords / Are you fundamentally distrusting the author in all semantic markup? Why then did we introduce article, header, nav, aside, footer etc when we can't trust the author to put the correct content in there? I don't really see the difference. Cheers, Silvia. On Wed, Nov 14, 2012 at 5:21 PM, Tim Leverett ...@gmail.com wrote: Hope you're not just trolling I was just trying to make the point that an algorithmic approach to finding the main content of a document would still be necessary with or without the main element. ☺ On Tue, Nov 13, 2012 at 7:03 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Wed, Nov 14, 2012 at 4:25 AM, Tim Leverett ...@gmail.com wrote: Explicit author markup would make such a task so much easier. Only if every author marked up their code correctly. If some authors use incorrect markup, then an algorithm would still be necessary for determining if each usage was correct. Hope you're not just trolling. From a browser perspective, if there is one main element and it sits within body, that would be sufficiently correct. Whether it's semantically correct for a particular application, that's not something the HTML spec should or could deal with. We don't protect people from putting the wrong text in tags - not in microdata, not in article or anywhere else. An application may care - or they may trust the author and if the author cares enough, they will fix up their markup if it doesn't achieve the right goal. But I'm sure you were just trolling... ;-) Cheers, Silvia.
Re: [whatwg] A plea to Hixie to adopt main
the smiley led me to believe it may not have been a real concern. I've been using a smiley as my signature for some time now, although I am new to the whatwg mailing list, so I do understand the confusion. Are you fundamentally distrusting the author in all semantic markup? In some circumstances, yes. Most of the work I've done so far has been in environments where programmers write code, and editors write content. Typically the content is via a CMS. If the editor is good but the programmer is not, the content is still worth having even if its surrounded by rubbish markup. From a data analytics and processing standpoint, there's no reason to discard good content just because its held in bad code in the same way that there's no reason to accept bad content just because its well formatted. Why then did we introduce article, header, nav, aside, footer etc when we can't trust the author to put the correct content in there? I don't really see the difference. Steve made a good point about user agents being able to tune into semantic elements for assistive tech. But I would guess (with no data to support my claim) that most programmers *want* to do things the right way. I find that, semantically, most of the time most websites are mostly correct. Headings tend to be in h# elements, paragraphs tend to be in p elements, etc. Heuristic analysis of content can take advantage of semantic markup by giving it a heavier weight than, say...a div element, but that doesn't mean the heuristics are any less complex. ☺ On Wed, Nov 14, 2012 at 7:23 PM, Silvia Pfeiffer silviapfeiff...@gmail.comwrote: Apologies for misunderstanding - the smiley led me to believe it may not have been a real concern. I did answer in good faith though, so back to the concern. You are absolutely correct that an algorithmic approach would still be necessary to resolve the situation when main is not provided in the same way that browsers create a body tag when it's not provided or a head etc. Scooby-Doo seems both simple enough and appropriate for this. I'm sure a lot of other people had to solve this problem as well and have done so in their own special way. Explicit author markup would make such a task so much easier. I was disagreeing with that point because there's no way to implicitly trust the author, in the same way that search engines can't trust meta name=keywords / Are you fundamentally distrusting the author in all semantic markup? Why then did we introduce article, header, nav, aside, footer etc when we can't trust the author to put the correct content in there? I don't really see the difference. Cheers, Silvia. On Wed, Nov 14, 2012 at 5:21 PM, Tim Leverett ...@gmail.com wrote: Hope you're not just trolling I was just trying to make the point that an algorithmic approach to finding the main content of a document would still be necessary with or without the main element. ☺ On Tue, Nov 13, 2012 at 7:03 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Wed, Nov 14, 2012 at 4:25 AM, Tim Leverett ...@gmail.com wrote: Explicit author markup would make such a task so much easier. Only if every author marked up their code correctly. If some authors use incorrect markup, then an algorithm would still be necessary for determining if each usage was correct. Hope you're not just trolling. From a browser perspective, if there is one main element and it sits within body, that would be sufficiently correct. Whether it's semantically correct for a particular application, that's not something the HTML spec should or could deal with. We don't protect people from putting the wrong text in tags - not in microdata, not in article or anywhere else. An application may care - or they may trust the author and if the author cares enough, they will fix up their markup if it doesn't achieve the right goal. But I'm sure you were just trolling... ;-) Cheers, Silvia.
Re: [whatwg] A plea to Hixie to adopt main
On Thu, Nov 15, 2012 at 12:17 PM, Tim Leverett ...@gmail.com wrote: Are you fundamentally distrusting the author in all semantic markup? In some circumstances, yes. Most of the work I've done so far has been in environments where programmers write code, and editors write content. Typically the content is via a CMS. If the editor is good but the programmer is not, the content is still worth having even if its surrounded by rubbish markup. From a data analytics and processing standpoint, there's no reason to discard good content just because its held in bad code in the same way that there's no reason to accept bad content just because its well formatted. Why then did we introduce article, header, nav, aside, footer etc when we can't trust the author to put the correct content in there? I don't really see the difference. Steve made a good point about user agents being able to tune into semantic elements for assistive tech. But I would guess (with no data to support my claim) that most programmers *want* to do things the right way. I agree. I find that, semantically, most of the time most websites are mostly correct. Headings tend to be in h# elements, paragraphs tend to be in p elements, etc. Heuristic analysis of content can take advantage of semantic markup by giving it a heavier weight than, say...a div element, but that doesn't mean the heuristics are any less complex. Are you saying we should not introduce a main element because where there is no main element we may need to come up with a complex heuristic to determine where it should have been? Silvia.
Re: [whatwg] A plea to Hixie to adopt main
Are you saying we should not introduce a main element... I don't believe I ever said anything about not introducing a mainelement. I'm very much on the fence about it. I've been trying to carefully balance the pros and cons to avoid a biased judgement. Here are some of what I've come up with. Pro: Adding a main element will provide a semantic element that developers can use to indicate primary content of a document. Con: Adding a main element adds redundancy to the [role=main] attribute. Pro: Adding a main element will allow developers to use a format such as: body header / main / footer / /body which tends to be quite clean and understandable (the easier it is to read code, the easier it is to fix code). Con: Implementing the main element in a backwards compatible manner requires JavaScript. Pro: Assistive technologies can use the main element as a means to rapidly navigate to the primary content. Con: The main element can only be used once per page. Pages with multiple content areas, or fragmented content would need to pick a single content region as primary, or not use the element. This restriction will likely cause more confusion than if multiple main elements were allowed. Pro: The main element can only be used once per page. This forces the author to decide exactly where the main focus of the page lies, rather than relying on assumptions. Con: The main element is supposed to exclude content that is repetitious across pages, but content is often interspersed with blocks of advertisements, modules, CTAs and the like. Personally, I'd rather see main be more about marking up content in general, such as in this example which is invalid given the current state of the spec: article id=1 header / main / footer / /article article id=2 header / main / footer / /article ...although this would probably fit better as a content element, and would require a whole other line of discussion that can wait for another day. ☺ On Wed, Nov 14, 2012 at 9:52 PM, Silvia Pfeiffer silviapfeiff...@gmail.comwrote: On Thu, Nov 15, 2012 at 12:17 PM, Tim Leverett ...@gmail.com wrote: Are you fundamentally distrusting the author in all semantic markup? In some circumstances, yes. Most of the work I've done so far has been in environments where programmers write code, and editors write content. Typically the content is via a CMS. If the editor is good but the programmer is not, the content is still worth having even if its surrounded by rubbish markup. From a data analytics and processing standpoint, there's no reason to discard good content just because its held in bad code in the same way that there's no reason to accept bad content just because its well formatted. Why then did we introduce article, header, nav, aside, footer etc when we can't trust the author to put the correct content in there? I don't really see the difference. Steve made a good point about user agents being able to tune into semantic elements for assistive tech. But I would guess (with no data to support my claim) that most programmers *want* to do things the right way. I agree. I find that, semantically, most of the time most websites are mostly correct. Headings tend to be in h# elements, paragraphs tend to be in p elements, etc. Heuristic analysis of content can take advantage of semantic markup by giving it a heavier weight than, say...a div element, but that doesn't mean the heuristics are any less complex. Are you saying we should not introduce a main element because where there is no main element we may need to come up with a complex heuristic to determine where it should have been? Silvia.
Re: [whatwg] A plea to Hixie to adopt main
By random chance, I just stumbled across this GitHub tool: https://github.com/visualrevenue/reporter It provides another heuristic approach - different from Scooby-Doo - to determining what is the main content on a page. This is from a journalist's point of view and it is using a scoring and evaluation algorithm. I'm sure a lot of other people had to solve this problem as well and have done so in their own special way. Explicit author markup would make such a task so much easier. Regards, Silvia. On Tue, Nov 13, 2012 at 11:53 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Tue, Nov 13, 2012 at 5:26 AM, Jens O. Meiert j...@meiert.com wrote: Should main be optional or required? I’d deem an optional main to be nonsense because it suggests documents are inherently without goal, or focus. I’d deem a required main to be nonsense because we already have an (implied) body element, and because element proliferation doesn’t work in anyone’s favor. I can imagine it to become required, if we mean by that that the browsers will need to parse a page and either find a main element or determine heuristically with the Scooby-Doo algorithm which part of the page is actually the main part and then add that to its DOM. Since we have the Scooby-Doo algorithm, we have a means to stay backwards compatible. That body essentially means main always seemed reasonable to me. There are plenty of options for authors to add styling hooks if they need any, including div role=main. You are correct - there is no need for this for styling. However, main is actually not for styling, but to provide a direct markup of the *semantically* main piece of content on the page. A Scooby-Doo algorithm can only heuristically determine what that is - with main the Web Dev gets an actual vehicle to point their finger explicitly rather than implicitly saying in a hand-wavy manner that it's what remains if you take away all this other stuff (that is: if we're lucky and that other stuff has actually been marked up). Silvia.
Re: [whatwg] A plea to Hixie to adopt main
Explicit author markup would make such a task so much easier. Only if every author marked up their code correctly. If some authors use incorrect markup, then an algorithm would still be necessary for determining if each usage was correct. ☺ On Tue, Nov 13, 2012 at 5:11 AM, Silvia Pfeiffer silviapfeiff...@gmail.comwrote: By random chance, I just stumbled across this GitHub tool: https://github.com/visualrevenue/reporter It provides another heuristic approach - different from Scooby-Doo - to determining what is the main content on a page. This is from a journalist's point of view and it is using a scoring and evaluation algorithm. I'm sure a lot of other people had to solve this problem as well and have done so in their own special way. Explicit author markup would make such a task so much easier. Regards, Silvia. On Tue, Nov 13, 2012 at 11:53 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Tue, Nov 13, 2012 at 5:26 AM, Jens O. Meiert j...@meiert.com wrote: Should main be optional or required? I’d deem an optional main to be nonsense because it suggests documents are inherently without goal, or focus. I’d deem a required main to be nonsense because we already have an (implied) body element, and because element proliferation doesn’t work in anyone’s favor. I can imagine it to become required, if we mean by that that the browsers will need to parse a page and either find a main element or determine heuristically with the Scooby-Doo algorithm which part of the page is actually the main part and then add that to its DOM. Since we have the Scooby-Doo algorithm, we have a means to stay backwards compatible. That body essentially means main always seemed reasonable to me. There are plenty of options for authors to add styling hooks if they need any, including div role=main. You are correct - there is no need for this for styling. However, main is actually not for styling, but to provide a direct markup of the *semantically* main piece of content on the page. A Scooby-Doo algorithm can only heuristically determine what that is - with main the Web Dev gets an actual vehicle to point their finger explicitly rather than implicitly saying in a hand-wavy manner that it's what remains if you take away all this other stuff (that is: if we're lucky and that other stuff has actually been marked up). Silvia.
Re: [whatwg] A plea to Hixie to adopt main
On Wed, Nov 14, 2012 at 4:25 AM, Tim Leverett ...@gmail.com wrote: Explicit author markup would make such a task so much easier. Only if every author marked up their code correctly. If some authors use incorrect markup, then an algorithm would still be necessary for determining if each usage was correct. Hope you're not just trolling. From a browser perspective, if there is one main element and it sits within body, that would be sufficiently correct. Whether it's semantically correct for a particular application, that's not something the HTML spec should or could deal with. We don't protect people from putting the wrong text in tags - not in microdata, not in article or anywhere else. An application may care - or they may trust the author and if the author cares enough, they will fix up their markup if it doesn't achieve the right goal. But I'm sure you were just trolling... ;-) Cheers, Silvia.
Re: [whatwg] A plea to Hixie to adopt main
Hope you're not just trolling I was just trying to make the point that an algorithmic approach to finding the main content of a document would still be necessary with or without the main element. ☺ On Tue, Nov 13, 2012 at 7:03 PM, Silvia Pfeiffer silviapfeiff...@gmail.comwrote: On Wed, Nov 14, 2012 at 4:25 AM, Tim Leverett ...@gmail.com wrote: Explicit author markup would make such a task so much easier. Only if every author marked up their code correctly. If some authors use incorrect markup, then an algorithm would still be necessary for determining if each usage was correct. Hope you're not just trolling. From a browser perspective, if there is one main element and it sits within body, that would be sufficiently correct. Whether it's semantically correct for a particular application, that's not something the HTML spec should or could deal with. We don't protect people from putting the wrong text in tags - not in microdata, not in article or anywhere else. An application may care - or they may trust the author and if the author cares enough, they will fix up their markup if it doesn't achieve the right goal. But I'm sure you were just trolling... ;-) Cheers, Silvia.
Re: [whatwg] A plea to Hixie to adopt main
Should main be optional or required? I’d deem an optional main to be nonsense because it suggests documents are inherently without goal, or focus. I’d deem a required main to be nonsense because we already have an (implied) body element, and because element proliferation doesn’t work in anyone’s favor. That body essentially means main always seemed reasonable to me. There are plenty of options for authors to add styling hooks if they need any, including div role=main. -- Jens O. Meiert http://meiert.com/en/
Re: [whatwg] A plea to Hixie to adopt main
On Tue, Nov 13, 2012 at 5:26 AM, Jens O. Meiert j...@meiert.com wrote: Should main be optional or required? I’d deem an optional main to be nonsense because it suggests documents are inherently without goal, or focus. I’d deem a required main to be nonsense because we already have an (implied) body element, and because element proliferation doesn’t work in anyone’s favor. I can imagine it to become required, if we mean by that that the browsers will need to parse a page and either find a main element or determine heuristically with the Scooby-Doo algorithm which part of the page is actually the main part and then add that to its DOM. Since we have the Scooby-Doo algorithm, we have a means to stay backwards compatible. That body essentially means main always seemed reasonable to me. There are plenty of options for authors to add styling hooks if they need any, including div role=main. You are correct - there is no need for this for styling. However, main is actually not for styling, but to provide a direct markup of the *semantically* main piece of content on the page. A Scooby-Doo algorithm can only heuristically determine what that is - with main the Web Dev gets an actual vehicle to point their finger explicitly rather than implicitly saying in a hand-wavy manner that it's what remains if you take away all this other stuff (that is: if we're lucky and that other stuff has actually been marked up). Silvia.
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
On Nov 7, 2012, at 8:52 AM, Ojan Vafai o...@chromium.org wrote: On Wed, Nov 7, 2012 at 6:23 AM, Simon Pieters sim...@opera.com 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. For those of use who couldn't make it, which browser vendors voiced support? I assume Opera since you're writing this thread. I personally think main would be useful. I don't think it has a huge benefit, but it has modest benefits, like aside, header, footer and section. I also think the implementation costs are low. The reasons I think it has some benefits: - Even though heuristics (such as the scooby-doo algorithm or even guesses based on role or class, or the layout) will always be necessary in some cases, it's still good to have a simple and relatively trustworthy marker of the main content. This is useful both for accessibility purposes and for other browser features that want to find the main content. In many cases, we have found that even when semantics can be heuristically inferred, having an explicit marker is still useful. For example, you can usually guess that some text is an address, but we still have a microformat that helps identify such data unambiguously. - From a language design perspective, it seems inelegant to identify the main content solely by what it is not. I realize that this is a matter of taste and that tastes may differ. By analogy, in imperative programming languages that have a main function, it is generally marked with as specific name rather than just by not being any of the non-main functions. This is not perfectly analogous, but it still seems motivating to me. - The Scooby-Doo algorithm is not actually defined in HTML5 afaict so I am not sure what the spec recommends to find the main content or which elements should be excluded. I presume that header, nav, footer and aside are excluded. What about address? small? Arbitrary other elements with non-main ARIA landmark roles? It seems insufficient to me to say that the use case of finding the main content is satisfied by an algorithm that's ambiguous and not actually defined anywhere. Given the state of play, authors have no way to be confident that their main content can be identified correctly, and implementors have no way to know how to find it. - I'm not confident that the sectioning elements in HTML5 exhaustively cover all possible forms of non-main content. If not, then it's likely that authors will have legitimate reason to have non-main content inside body which cannot reliably be skipped by the Scooby-Doo algorithm. Overall, I would not fall on my sword to get the main element into WebKit but I would not reject a patch to add it either, assuming a sufficiently good spec exists for it somewhere. 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. I don't outright object, but I think our time would be better spent on addressing more pressing problems with the web platform. The same argument could have been made for article, but the implementation cost was so low that the benefit didn't have to be huge. I think the same applies to main. Regards, Maciej
Re: [whatwg] A plea to Hixie to adopt main
On 2012-11-07 23:41, Ian Hickson wrote: On Thu, 8 Nov 2012, Ben Schwarz wrote: What does concern me, as a web builder, *every day*, is how I markup the content in-between a header and a footer. If you just want it for styling purposes, div is perfect. article headerh1, h2, p/header div class=content/div footertime, a.permalink/footer /article Exactly like that (or even without the class, if you just have one per article you can just do article div to select it). I've begun to do this a lot now, the less I have to use class= or id= for styling the better. In one of my current projects I'm basically only using id= for actual anchor/indedx use, and no class= at all. In fact except the few id= for index shortcuts the stylingin is all done in the .css and the only css referencve in the html document is the inclusion of the css link url. I guess you could call it stealth css as looking at the html document does not reveal that css is used at all (except the css link in the html header) I wish more webauthors would do this, makes for very clean html indeed. Now back to the topic (sorry for getting sidetracked). As to the main thing, the only time I'd ever be for adding that to HTML markup was if it would be specced per the following. main and /main encloses the content of a document, can be used in place of a div or article but can only occur once in a document. If more than one instance of main and /main block is encounctered, then parsers should only accept the first and ignore any others. If no main then the content in the document itself is considered the main content. Maybe it's just me, but wouldn't a main sort of be a synonym for body almost? *scratches head* -- 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
I generally markup pages using ARIA roles: header role=banner article role=main footer role=contentinfo and variations thereafter— If there were to be a main attribute (with an implicit ARIA role to match), where would it end? contentinfo banner ? What is to be gained by adding an element, rather than using ARIA roles? Isn't that what ARIA is designed for? On 08/11/2012, at 1:23 AM, Simon Pieters sim...@opera.com wrote: Hi, 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. 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. 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. 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. 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 there is anyone besides from Hixie who objects to adding main, it would be useful to hear it. -- Simon Pieters Opera Software
Re: [whatwg] A plea to Hixie to adopt main
2012-11-07 16:23, Simon Pieters wrote: 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. Hixie's idea is sufficient for determining the main content (in some sense) on a page that systematically uses the new structuring elements. This in turn is sufficient for some styling purposes, but not all purposes. 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's one point. Another point is that authors don't really need to use all the header, nav, etc. elements, and validation does not check for this. E.g., if you just want to have some styles that only apply to the main content, you might want to use just main and not all the other stuff. But perhaps the strongest argument in favor of main is that the Scooby-Doo algorithm may determine the content, but it does not make it an element, on any DOM node. And elementhood is essential for many styling and scripting purposes. 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. Sounds logical. And the Reader Mode functionality that you mention is one of the few signs of any meaningful support to the new structuring elements. There is much talk about the assumed semantic benefits of those elements, much less evidence of real benefits. I suppose that the heuristics would include recognizing a div element to which class main has been assigned. Then one could argue that main is not needed, as authors can keep using div class=main, as millions of pages use. Then again, a similar argument would apply to header and friends. If there is anyone besides from Hixie who objects to adding main, it would be useful to hear it. Well, I haven't seen much point in any of the new structuring elements in general, but the browser behavior you write about would make main much more relevant than the others. Yucca
Re: [whatwg] A plea to Hixie to adopt main
Hi Ben, I generally markup pages using ARIA roles: header role=banner article role=main footer role=contentinfo and variations thereafter— If there were to be a main attribute (with an implicit ARIA role to match), where would it end? contentinfo banner ? What is to be gained by adding an element, rather than using ARIA roles? Isn't that what ARIA is designed for? various new HTML elements are already being mapped to ARIA or platform accessibility APIs aside is mapped to complementary ( IA2, AT-SPI and AX) article is mapped to article ( IA2, AT-SPI and AX) nav is mapped to navigation ( IA2, AT-SPI and AX) header/footer are mapped to banner and conteninfo ( IA2, AT-SPI and AX) etc. this means when fuly implemented authors will not have to add aria roles (built in vs bolt-on) the browsers do it already. ARIA roles are used because the semantics are not fully implemented in browsers yet. If you take the time to read the spec [1] and supporting research you will find the rationale and use cases detailed. Its based on commont authoring practice. [1] https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html regards SteveF On 08/11/2012, at 1:23 AM, Simon Pieters sim...@opera.com wrote: Hi, 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. 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. 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. 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. 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 there is anyone besides from Hixie who objects to adding main, it would be useful to hear it. -- Simon Pieters Opera Software -- 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] A plea to Hixie to adopt main
On Wed, 07 Nov 2012 15:35:31 +0100, Ben Schwarz ben.schw...@gmail.com wrote: I generally markup pages using ARIA roles: header role=banner article role=main footer role=contentinfo There is an implicit mapping already. and variations thereafter— If there were to be a main attribute (with an implicit ARIA role to match), where would it end? It ends at main since that's the last landmark lacking an element. contentinfo banner ? The are called footer and header. What is to be gained by adding an element, rather than using ARIA roles? The gain is better ergonomics and more likelihood of getting accessible pages by people using the elements without doing extra work to cater for AT. Isn't that what ARIA is designed for? The role and state part of ARIA was designed to be a stop-gap solution to make JS-based Web applications accessible in a way that would work in legacy IE with modern AT. The landmark part of ARIA was designed to do the same thing as the new elements in HTML. IIRC, landmarks were kept instead of embracing the new elements because the elements were specified in a document that was not expected to be finished in two decades whereas ARIA was expected to be finished in a much shorter time frame. That we would end up having both was not seen as a showstopper for either group. -- Simon Pieters Opera Software
Re: [whatwg] A plea to Hixie to adopt main
2012-11-07 16:53, Steve Faulkner wrote: ARIA roles are used because the semantics are not fully implemented in browsers yet. It's a bit more complicated than that, isn't it? ARIA roles are also, and originally, meant for describing the meaning of elements that are used in rich Internet applications in a manner that cannot be deduced from the HTML markup. For example, if you set up a span element that acts as a checkbox, driven by JavaScript and formatted with CSS to look like a checkbox, then the ARIA role attribute is needed to inform browsers and assistive software about this. Besides, many distinctions that can be made with ARIA roles cannot be described in HTML as currently defined. But that's not a big issue really, and it does not mean that corresponding elements should be added to HTML. ARIA has its role (no pun intended), and software that can currently handle role=foo would really benefit nothing from the introduction of a foo element. It would be just some new stuff that should be supported in addition to existing support. So the existence of something as an ARIA role value does not imply that a correspoding element should be added to HTML if not already present there. But neither does it constitute a counterargument to adding new elements. Yucca
Re: [whatwg] A plea to Hixie to adopt main
Am 07.11.2012 15:48 schrieb Jukka K. Korpela: I suppose that the heuristics would include recognizing a div element to which class main has been assigned. Then one could argue that main is not needed, as authors can keep using div class=main, as millions of pages use. I doubt that this is useable for that kind of heuristics anyway - as there is no standard for this, main as a class name may indicate the main contents, but also a main container to center the whole page. Also, non-english speaking coders may use their own language words as id or class names.
Re: [whatwg] A plea to Hixie to adopt main
On Wed, Nov 7, 2012 at 6:23 AM, Simon Pieters sim...@opera.com 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. For those of use who couldn't make it, which browser vendors voiced support? I assume Opera since you're writing this thread. 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. 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. 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. 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 there is anyone besides from Hixie who objects to adding main, it would be useful to hear it. 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. I don't outright object, but I think our time would be better spent on addressing more pressing problems with the web platform.
Re: [whatwg] A plea to Hixie to adopt main
On 11/07/2012 05:52 PM, Ojan Vafai wrote: On Wed, Nov 7, 2012 at 6:23 AM, Simon Pieters sim...@opera.com 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. For those of use who couldn't make it, which browser vendors voiced support? I assume Opera since you're writing this thread. To be clear, Opera didn't voice support for anything. Some people from Opera suggested that it seemed like a reasonable idea (I think it seems like a reasonable idea). 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. 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. 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. 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 there is anyone besides from Hixie who objects to adding main, it would be useful to hear it. This idea doesn't seem to address any pressing use-cases. I think that finding the main content of a page has clear use cases. We can see examples of authors working around the lack of this feature in the platform every time they use a skip to main link, or (less commonly) aria role=main. I believe we also see browsers supporting role=main in their AT mapping, which suggests implementer interest in this approach since the solutions are functionally isomorphic (but with very different marketing and usability stories). I think the argument that the Scooby Doo algorithm is deficient because it requires many elements of a page to be correctly marked up, compared to main which requires only a single element to get the same functional effect, has merit. 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. I don't know how these different uses stack up (apologies if it is in some research that I overlooked). 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. I think Maciej commented on this. IIRC, he said that it wouldn't be good enough for reader mode alone, but might usefully provide an extra piece of data for the heuristics. I don't outright object, but I think our time would be better spent on addressing more pressing problems with the web platform. I think that's a very weak argument. In fact, given the current landscape I would expect this to swallow more of the web standards communities' time if it is not adopted than if it is. But I don't think that's a strong argument in favour of adopting it either.
Re: [whatwg] A plea to Hixie to adopt main
(12/11/08 1:48), James Graham wrote: I think that finding the main content of a page has clear use cases. We can see examples of authors working around the lack of this feature in the platform every time they use a skip to main link, or (less commonly) aria role=main. I believe we also see browsers supporting role=main in their AT mapping, which suggests implementer interest in this approach since the solutions are functionally isomorphic (but with very different marketing and usability stories). I think the argument that the Scooby Doo algorithm is deficient because it requires many elements of a page to be correctly marked up, compared to main which requires only a single element to get the same functional effect, has merit. Hixie's 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. 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. 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. Cheers, Kenny -- Web Specialist, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
Re: [whatwg] A plea to Hixie to adopt main
As a developer I'm in favor of this. Just take a look at the how popular the question of How do I enable Reader mode is on SO[1], and how complex and mysterious the actual algorithm appears to be[2], and it's evident how authors and implementors alike could benefit from a dedicated element. Although, there's the question of how similar in definition it'd be to article. Is it merely a more specific version of a self-contained composition [...] that is, in principle, independently distributable? Or is it a more specific div; a semantic wrapper element? If it's the former, this could just as well be an empty attribute, as article main. Not too different from ARIA, which maybe makes it a little redundant, but it's less to type in CSS (article[main] vs article[role=main]), and also achieves landmark parity without breaking legacy HTML parsers, frameworks, etc. which only expect article. If it's the latter, it probably makes more sense for it to be an element, where it wouldn't say whether the content was self-contained or not; just that its contents are considered the primary focus of the page, except anything that would otherwise be excluded in the document outline. [1]: http://stackoverflow.com/questions/2997918/how-to-enable-ios-5-safari-reader-on-my-website [2]: http://mathiasbynens.be/notes/safari-reader
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
Re: [whatwg] A plea to Hixie to adopt main
On Thu, Nov 8, 2012 at 3:00 AM, Markus Ernst derer...@gmx.ch wrote: Am 07.11.2012 15:48 schrieb Jukka K. Korpela: I suppose that the heuristics would include recognizing a div element to which class main has been assigned. Then one could argue that main is not needed, as authors can keep using div class=main, as millions of pages use. I doubt that this is useable for that kind of heuristics anyway - as there is no standard for this, main as a class name may indicate the main contents, but also a main container to center the whole page. Also, non-english speaking coders may use their own language words as id or class names. Agreed. Looking at existing uses of div class=main to analyse whether we need a main element really doesn't make sense to me. I firmly believe that class=main is mostly used for CSS purposes and not for semantic (and thus accessibility) purposes. Instead, we should be looking at pages that use xxx role=main or more traditionally in older Web pages use a skip to main link as the use cases for a main element. Sometimes that may co-incide with div class=main, but not in general. Therefore, I don't actually think that the introduction in Steve's document is making a good case for the existence of the element with this sentence: The main element formalises the common practicehttps://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html#commonof identification of the main content section of a document using the id values such as 'content' and 'main'. I'd suggest explaining that there is currently no explicit means of identifying with 100% accuracy what part of a Web page is the single most important part. Instead we have a solution only for accessibility purposes with the @role=main ARIA attribute, or more traditionally by providing a skip to main link on the top of the page. If there was a main element that semantically identified the important part of a Web page, that would improve accessibility, but also enable for example search engines to give that part of a Web page a higher importance. On that latter part: I am always annoyed when a search engine gives me links to a particular topic that I was searching for which is only mentioned in a side bar as some related information. It would be possible to exclude such content if there was a main element. The argument that article and aside etc. will do away with such problems relies on authors actually making use of these elements. I am yet to see that happen - in fact I have seen people that started using these elements go away from them again, since they don't seem to have any obvious advantage. main on the other hand has a very real advantage - immediately for accessibility - and its easier to put a single main element on a page than to introduce a whole swag of new elements. It's the simplicity of that single element that will make it immediately usable by everyone, will reduce the probability of authoring error, and thus make it reliable for search engines and other semantic uses. Regards, Silvia.
Re: [whatwg] A plea to Hixie to adopt main
Skip to main isn't the only use case :-) FYI, as a web designer, (slap me here) I've almost never designed in a skip to main link. Call me ignorant (probably fitting), but in the real world a new way to markup 'skip to main' isn't on my mind. What does concern me, as a web builder, *every day*, is how I markup the content in-between a header and a footer. Consider the following: In this (real, cutdown) example, I was marking up a series of events on a page. Headers and footers, then … something in the middle. article headerh1, h2, p/header div class=content/div footertime, a.permalink/footer /article In this (also, real) situation, I separated the main content of my page from the 'chrome' of the site, headers, footers, etc. body class=contact nav role=navigation … /nav div role=main class=grid spine header h1Lets talk/h1 pProduct, sales or press enquiries—/p /header form action=# method=post … /form /div footer role=navigation class=grid … /footer /body The fact of the matter is that web authors are already inventing main, daily. Just some examples from the files open behind my mail right now. Happy to provide more! Best, Ben -- On 08/11/2012, at 5:13 AM, Kang-Hao (Kenny) Lu kangh...@oupeng.com wrote: (12/11/08 1:48), James Graham wrote: I think that finding the main content of a page has clear use cases. We can see examples of authors working around the lack of this feature in the platform every time they use a skip to main link, or (less commonly) aria role=main. I believe we also see browsers supporting role=main in their AT mapping, which suggests implementer interest in this approach since the solutions are functionally isomorphic (but with very different marketing and usability stories). I think the argument that the Scooby Doo algorithm is deficient because it requires many elements of a page to be correctly marked up, compared to main which requires only a single element to get the same functional effect, has merit. Hixie's 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. 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. 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. Cheers, Kenny -- Web Specialist, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
Re: [whatwg] A plea to Hixie to adopt main
In response to Silvia's comments— I think relying on xxx role= is a pretty good result, I think we need to stretch further. An article is a piece of content that isn't semantically defined on its parents. (right?) Shouldn't we have a way to define this without confusing the main content of the 'page'? On 08/11/2012, at 8:07 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Thu, Nov 8, 2012 at 3:00 AM, Markus Ernst derer...@gmx.ch wrote: Am 07.11.2012 15:48 schrieb Jukka K. Korpela: I suppose that the heuristics would include recognizing a div element to which class main has been assigned. Then one could argue that main is not needed, as authors can keep using div class=main, as millions of pages use. I doubt that this is useable for that kind of heuristics anyway - as there is no standard for this, main as a class name may indicate the main contents, but also a main container to center the whole page. Also, non-english speaking coders may use their own language words as id or class names. Agreed. Looking at existing uses of div class=main to analyse whether we need a main element really doesn't make sense to me. I firmly believe that class=main is mostly used for CSS purposes and not for semantic (and thus accessibility) purposes. Instead, we should be looking at pages that use xxx role=main or more traditionally in older Web pages use a skip to main link as the use cases for a main element. Sometimes that may co-incide with div class=main, but not in general. Therefore, I don't actually think that the introduction in Steve's document is making a good case for the existence of the element with this sentence: The main element formalises the common practicehttps://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html#commonof identification of the main content section of a document using the id values such as 'content' and 'main'. I'd suggest explaining that there is currently no explicit means of identifying with 100% accuracy what part of a Web page is the single most important part. Instead we have a solution only for accessibility purposes with the @role=main ARIA attribute, or more traditionally by providing a skip to main link on the top of the page. If there was a main element that semantically identified the important part of a Web page, that would improve accessibility, but also enable for example search engines to give that part of a Web page a higher importance. On that latter part: I am always annoyed when a search engine gives me links to a particular topic that I was searching for which is only mentioned in a side bar as some related information. It would be possible to exclude such content if there was a main element. The argument that article and aside etc. will do away with such problems relies on authors actually making use of these elements. I am yet to see that happen - in fact I have seen people that started using these elements go away from them again, since they don't seem to have any obvious advantage. main on the other hand has a very real advantage - immediately for accessibility - and its easier to put a single main element on a page than to introduce a whole swag of new elements. It's the simplicity of that single element that will make it immediately usable by everyone, will reduce the probability of authoring error, and thus make it reliable for search engines and other semantic uses. Regards, Silvia.
Re: [whatwg] A plea to Hixie to adopt main
On Thu, 8 Nov 2012, Ben Schwarz wrote: What does concern me, as a web builder, *every day*, is how I markup the content in-between a header and a footer. If you just want it for styling purposes, div is perfect. article headerh1, h2, p/header div class=content/div footertime, a.permalink/footer /article Exactly like that (or even without the class, if you just have one per article you can just do article div to select it). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
