[webkit-dev] Adding main element to WebCore
maciej wrote: The WHATWG has pretty clearly rejected the idea of the main element can you point to a clear rejection in any of the relevant threads on the WHATWG apart from hixies? I would suggest the WHATWG has general support for adding main, but I may not be understanding what is meant by a whatwg rejection in this case. regards SteveF On Nov 29, 2012, at 8:35 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Nov 29, 2012 at 7:32 PM, James Craig jcr...@apple.com wrote: On Nov 29, 2012, at 7:10 PM, Ryosuke Niwa rn...@webkit.org wrote: I don't see a harm in waiting another couple of weeks or months until standards discussion settles assuming that the main element doesn't become the longdesc of the next decade. Don't confuse the two. The argument over the @longdesc extension is not even close to unanimous even within the accessibility development circles. Major objections to @longdesc came from several of us working full-time on accessibility. I was not intending to confuse the two. What I all meant to point out is that there still is an active debate. I mean just look at responses on this thread. There are people objecting to this feature. That?s a good indication that the feature is still premature. I?m not necessarily objecting to adding this feature to WebKit at some point. All I?m asking is to wait until standards discussion settles. I think this thread does not show a clear consensus either way, at least at this time. I worry though, that more standards discussion will not resolve the impasses. The HTML WG has moved forward with its main element specification and that seems unlikely to change. The WHATWG has pretty clearly rejected the idea of the main element and that seems unlikely to change. I am not sure how we as a community should deal with an impasse where there is a split like this and little hope of resolving it. It seems there are precedents in both directions and folks judge on the merits (for example, the community clearly does not favor support for HTML+RDFa and its related API, but there is ongoing implementation work for Encrypted Media Extensions; both of these are html extensions pushed by the w3c but rejected by the whatwg). Regards, Maciej -- 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
Hi Maciej, thanks for the clarification. I would suggest that if, as in this case, Hixie rejects a feature without convincing the WHATWG community that the data, use cases etc do not support the introduction of a feature, then the WHATWG process is broken. regards SteveF On 30 November 2012 06:18, Maciej Stachowiak m...@apple.com wrote: On Nov 29, 2012, at 10:00 PM, Steve Faulkner faulkner.st...@gmail.com wrote: maciej wrote: The WHATWG has pretty clearly rejected the idea of the main element can you point to a clear rejection in any of the relevant threads on the WHATWG apart from hixies? I would suggest the WHATWG has general support for adding main, but I may not be understanding what is meant by a whatwg rejection in this case. I mean that by the whatwg process, if Hixie says no clearly and definitively, that is the decision. I say this not to judge, just to describe what it is. This does not of course mean that everyone who participates in the WHATWG agrees. The only thing I see as likely to change things in the whatwg is implementations appearing. Regards, Maciej -- 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On 30 November 2012 06:46, Michael[tm] Smith m...@w3.org wrote: I think that's the spirit in which Steve took time to contribute code for this, and to start the discussion about it here. Yes, I was motivated by what Maciej stated on the whatwg list [1]: 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. [1] http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0104.html -- with regards SteveF ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On 30 November 2012 06:38, Maciej Stachowiak m...@apple.com wrote: I think discussing the merits of the whatwg process is probably off topic for this list. agreed, I am just trying to stop process getting in the way of adding a feature (notedly a minor one) to HTML which will benefit users with disabilities. regards SteveF ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Fwd: Adding main element to WebCore
On Wed, 28 Nov 2012, ian hickson wrote: ARIA is used by very few authors, and those authors are, by and large, much more competent than average. ARIA therefore tends to be used to a much higher level of quality than most elements. The claim that developers that use ARIA are much more competent than average is unsubstantiated. a quick check (html conformance) of some data [1] does not indicate any difference in the competency of developers that use ARIA and those who do not. ARIA like HTML contains simple well understood features (such as role=main) and more complex features more prone to errors of use (such as aria-posinset) Where features are well understood, map on to common authoring concepts and easy to author they are often used correctly. It would probably be used about as well, maybe a little less well than them because the idea of what is main varies from author to author (e.g. in the sites you analysed on the WHATWG list, as well as in many that others have mentioned before, id=main and id=content often include things like some navigation, some headers, some sidebars, some footers). The data does not support the claim that id=main and id=content often include things like some navigation, some headers, some sidebars, some footers). It indicates that in approximately 80% of cases headers, footers, navigation etc are not included. so I don't see why they would make sense to be supported while main doesn't. The use case for e.g. header is mainly one of maintenance and styling: lots of people style their headers very specifically. In general it doesn't matter if one author marks his navigation as being part of his header and another marks his navigation using nav; the result is the same: they are clearly marked in the source, they can be styled, and they can be skipped. If one author doesn't use it, or even if most authors use it incorrectly, it doesn't mean that other authors can't use it. The use case for main is accessibility navigation. If authors use it incorrectly, the feature *doesn't work*. The element becomes pointless. Combined with the way that the concept of main varies from author to author, you dramatically increase the likelihood that the element won't satisfy its stated purpose. From analysing the data [2] the wrapping of main content area of a web page in a div with an id value that indicates it is the 'main content' is a common occurrence, this indicates that developers do this for reasons other than accessibility as the majority do not include role=main or use the div as a target for a skip link. What the main element does is piggyback accessibility onto a common authoring practise. Also, since few authors ever test how their page works in ATs, they won't know that there's a problem. this is a problem, and it has begun to reveal itself due the misuse of new elements such as section and article. the difference between main and some of the other new elements is it is a simpler concept and is unambiguously defined. It builds on the singular instance of use per page (id value) rather than class names. This is like the difference between a href= and img longdesc=. If many authors don't use a href= right, big deal; their pages don't work well, but it doesn't stop other authors from using it. If many authors use longdesc= incorrectly, however, it means users who try to use the feature quickly stop expecting it to work and they give up and even pages that use it correctly lose out. drawing a comparison between longdesc and main here is fallacious: longdesc is known to be used incorrectly much of the time while role=main is known to be used correctly much of the time. div id=main is known to be used correctly much of the time. longdesc is bolt on accessibility requiring not only the correct use of the attribute, but also the provision of extra authored content that the attribute points to (i.e a lot of extra effort) main is built in accessibility that sneaks accessibility in on the back of a common authoring practise,i.e reduction of effort, much like the nav element And, since few authors ever test how their page works in ATs, they don't know that there's a problem, and so the feature is _more_ likely to be broken than a href=. that's why building accessibility into features that are based on common authoring practises is a good thing. [1] http://www.html5accessibility.com/tests/HTML5-main-content/ [2] http://lists.w3.org/Archives/Public/public-html/2012Oct/0109.html -- with regards Steve Faulkner ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] RESEND: Fwd: Adding main element to WebCore
resending in plain text as previous email was cutoff On Wed, 28 Nov 2012, ian hickson wrote: ARIA is used by very few authors, and those authors are, by and large, much more competent than average. ARIA therefore tends to be used to a much higher level of quality than most elements. The claim that developers that use ARIA are much more competent than average is unsubstantiated. a quick check (html conformance) of some data [1] does not indicate any difference in the competency of developers that use ARIA and those who do not. ARIA like HTML contains simple well understood features (such as role=main) and more complex features more prone to errors of use (such as aria-posinset) Where features are well understood, map on to common authoring concepts and easy to author they are often used correctly. It would probably be used about as well, maybe a little less well than them because the idea of what is main varies from author to author (e.g. in the sites you analysed on the WHATWG list, as well as in many that others have mentioned before, id=main and id=content often include things like some navigation, some headers, some sidebars, some footers). The data does not support the claim that id=main and id=content often include things like some navigation, some headers, some sidebars, some footers). It indicates that in approximately 80% of cases headers, footers, navigation etc are not included. so I don't see why they would make sense to be supported while main doesn't. The use case for e.g. header is mainly one of maintenance and styling: lots of people style their headers very specifically. In general it doesn't matter if one author marks his navigation as being part of his header and another marks his navigation using nav; the result is the same: they are clearly marked in the source, they can be styled, and they can be skipped. If one author doesn't use it, or even if most authors use it incorrectly, it doesn't mean that other authors can't use it. The use case for main is accessibility navigation. If authors use it incorrectly, the feature *doesn't work*. The element becomes pointless. Combined with the way that the concept of main varies from author to author, you dramatically increase the likelihood that the element won't satisfy its stated purpose. From analysing the data [2] the wrapping of main content area of a web page in a div with an id value that indicates it is the 'main content' is a common occurrence, this indicates that developers do this for reasons other than accessibility as the majority do not include role=main or use the div as a target for a skip link. What the main element does is piggyback accessibility onto a common authoring practise. Also, since few authors ever test how their page works in ATs, they won't know that there's a problem. this is a problem, and it has begun to reveal itself due the misuse of new elements such as section and article. the difference between main and some of the other new elements is it is a simpler concept and is unambiguously defined. It builds on the singular instance of use per page (id value) rather than class names. This is like the difference between a href= and img longdesc=. If many authors don't use a href= right, big deal; their pages don't work well, but it doesn't stop other authors from using it. If many authors use longdesc= incorrectly, however, it means users who try to use the feature quickly stop expecting it to work and they give up and even pages that use it correctly lose out. drawing a comparison between longdesc and main here is fallacious: longdesc is known to be used incorrectly much of the time while role=main is known to be used correctly much of the time. div id=main is known to be used correctly much of the time. longdesc is bolt on accessibility requiring not only the correct use of the attribute, but also the provision of extra authored content that the attribute points to (i.e a lot of extra effort) main is built in accessibility that sneaks accessibility in on the back of a common authoring practise,i.e reduction of effort, much like the nav element And, since few authors ever test how their page works in ATs, they don't know that there's a problem, and so the feature is _more_ likely to be broken than a href=. that's why building accessibility into features that are based on common authoring practises is a good thing. [1] http://www.html5accessibility.com/tests/HTML5-main-content/ [2] http://lists.w3.org/Archives/Public/public-html/2012Oct/0109.html -- with regards Steve Faulkner ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Adding main element to WebCore
Hi all, this is my first post to the list. I have submitted a patch [1] to add main element support to webkit and would appreciate your consideration. the main element is defined here: http://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html current status unofficial draft, CFC [2] to publish as a first working draft via HTML WG ends today. Rationale and use cases: http://www.w3.org/html/wg/wiki/User:Sfaulkne/main-usecases#Introduction details of data set and data analysis conducted during development of feature: http://lists.w3.org/Archives/Public/public-html/2012Oct/0109.html There has been discussion and feedback provided on the WHATWG list [3] and IRC and at TPAC 2012 HTML WG meeting. I look forward to your comments! [1] https://bugs.webkit.org/show_bug.cgi?id=103172 [2] http://lists.w3.org/Archives/Public/public-html/2012Nov/thread.html#msg129 [3] threads start here: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/thread.html#msg55 -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner http://www.paciellogroup.com/resources/wat-ie-about.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
