Re: [webkit-dev] How to switch on MultiSampling for accelerated 2D Canvas?
On Tue, Nov 27, 2012 at 8:00 AM, Kui Zheng kuii.zh...@gmail.com wrote: Hi, I was trying to accelerate path filling using stencil buffer, For antialiasing, we rely on GPU multisampling. So, I want to know Does webkit support Multisampling for accelerated 2D Canvas? how to switch on it? Thanks for you help. I believe the details of this depend on which port you're using. For Chromium, the graphics layer is Skia, and you can get a more targeted answer on the skia-discuss mailing list. However, Chromium already uses the stencil buffer for some path rendering, and we've found it to be considerably *slower* than a software implementation in common web use cases. Tom (from the right email address this time) ___ 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
As I said on the thread you link to, I don't think this element addresses any real use-cases. I think people are far too likely to misuse this for it to be useful for things like readability to use. If Apple really wants this, I won't object, but my preference would be to not implement this. On Mon, Nov 26, 2012 at 2:01 PM, Steve Faulkner faulkner.st...@gmail.comwrote: 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 ___ 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, Silvia Pfeiffer wrote: I've not seen any place where @role=main was misused and I think the same would be the case for main. 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. At least I don't see why it would be misused any more than the other semantic elements that were introduced such as article, header and aside 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). 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. Also, since few authors ever test how their page works in ATs, they won't know that there's a problem. 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. 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=. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ 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, Nov 28, 2012 at 11:22 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 28 Nov 2012, Silvia Pfeiffer wrote: I've not seen any place where @role=main was misused and I think the same would be the case for main. 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. Agreed. I think that having this as an explicit element would make it easier for the Web Developer community at large to become aware of this problem and to provide this very valuable feature to users in need. At least I don't see why it would be misused any more than the other semantic elements that were introduced such as article, header and aside 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). Agreed. The analysis in my article came to the same conclusion. I think we need to let go of the idea that main will replace id=main and id=content, because it's not the point of main. It might sometimes co-incide, but oftentimes it won't. 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. That's a good thing, right? Because then Web developers have a means to find out that they've made the wrong markup. 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. If it is clearly specified, why would there be a difference in understanding what main means? Also, since few authors ever test how their page works in ATs, they won't know that there's a problem. Right, that's why introducing a keyboard shortcut for main would be useful: it would enable every user to test their page. If that is not possible (because we need to leave keyboard shortcuts to apps), it could at least become part of developer tools. In Chrome we have a developer tools plugin to run accessibility audits - it would be simple to add it there. I'm sure we can come up with a sensible way to make testing main part of Web development. Ultimately, we always have the accessibility users as the testers for this feature and they can register bugs where the main element is leading to the wrong place. After all, there are more deaf and hard-of-hearing users in the US than there are Web users in Spain or Canada [1], so that should provide a large enough audience to make this work. Regards, Silvia. [1] http://www.youtube.com/watch?v=tua3DdacgOo#t=117s ___ 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, Silvia Pfeiffer wrote: On Wed, Nov 28, 2012 at 11:22 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 28 Nov 2012, Silvia Pfeiffer wrote: I've not seen any place where @role=main was misused and I think the same would be the case for main. 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. Agreed. I think that having this as an explicit element would make it easier for the Web Developer community at large to become aware of this problem and to provide this very valuable feature to users in need. Well first of all, what problem? How big of an issue is the accessibility problem here anyway? It's not at all clear to me that it's a big issue at all. Sites have been quite happily working with a skip past navigation link, and HTML has an explicit nav element that makes this more likely to happen even for sites that don't provide a link, and ATs have all kinds of page navigation tools for users that let them jump around looking for whatever it is they want to read (which isn't necessarily the main content; e.g. on youtube.com you probably want the search box, not the stream, in many cases). But secondly, how do you think main will do anything to make authors aware of anything? To authors who hear about the element, it's just going to be met with ah, a way to replace my id=main element ID with an element instead, just like header and nav. And thirdly, since when are awareness campaigns appropriate ways to do language design? We design to solve real problems, we try to make the platform intuitive. We don't design the language to teach people. That's the job of tutorials, advocacy, etc. At least I don't see why it would be misused any more than the other semantic elements that were introduced such as article, header and aside 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). Agreed. The analysis in my article came to the same conclusion. This is the opposite conclusion than you drew in your earlier e-mail, so I'm confused now. (You said I don't see why it would be misused any more than the other semantic elements.) Note that if it's misused even as much as the other semantic elements, that's enough to make it useless, unlike with those other elements. That's an important distinction. It's like labels on foods. If many stores misuse a label that says where the food is stored in their warehouse, well, those stores have trouble using their warehouse, but it doesn't really affect other stores, and the stores that use it correctly have no trouble. On the other hand, a label that says Only Organic Ingredients!, if use incorrectly by many stores, stops being useful at all, because even in stores that use it correctly, shoppers won't know if it's right, and so won't trust it. The label loses all its value. It actually doesn't even take a big fraction of stores to misuse the label for consumer trust in the label to be fatally undermined. I think we need to let go of the idea that main will replace id=main and id=content, because it's not the point of main. That's how authors will use it. That it's not the point of main is *exactly* the reason main is a bad design. The use case for main is accessibility navigation. If authors use it incorrectly, the feature *doesn't work*. The element becomes pointless. That's a good thing, right? No, it's a terrible thing. It essentially means we shouldn't add the element. Because then Web developers have a means to find out that they've made the wrong markup. Uh, no? It doesn't teach authors anything at all. Authors have basically no way to find out if they've used it correctly (given that they're not going to use -- or in most cases, even know about -- ATs). 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. If it is clearly specified, why would there be a difference in understanding what main means? You seem to be under the assumption that authors read the spec. The number of authors who read the spec is absolutely insignificant compared to the number of authors who will use the element. Also, since few authors ever test how their page works in ATs, they won't know that there's a problem. Right, that's why introducing a keyboard shortcut for main would be useful: it would enable every user to test their page. Very few authors are going to do that. (Barely anyone
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
Re: [webkit-dev] Fwd: Adding main element to WebCore
I'm stunned that people are arguing this on webkit-dev. Just FYI, Mozillians with whom I have spoken generally agree that main does not meet the high bar required to add a new element to HTML. Shopping a patch to implementors, to get something into a standard spec by asserting de-facto status based on the patch(es) landing, is bad form. Back to the whatwg list! /be Dominic Mazzoni wrote: On Tue, Nov 27, 2012 at 4:22 PM, Ian Hickson i...@hixie.ch mailto:i...@hixie.ch wrote: The use case for main is accessibility navigation. If authors use it incorrectly, the feature *doesn't work*. The element becomes pointless. But it won't break accessibility. Worst case, it starts the screen reader user at an unusual point in the page. A single keystroke will bring the user back to the top of the page, so it's no big deal. So I'm in favor of it, because it's easy for developers, there's a small positive accessibility benefit, and I don't see any harm if it's sometimes used incorrectly. - Dominic ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ 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
Re: [webkit-dev] Adding main element to WebCore
I don’t think we should implement this feature in WebKit until the standards discussion settles. It’s very controversial at the moment. I also agree with Ojan and Hixie that authors are very likely going to misuse this element. - R. Niwa On Mon, Nov 26, 2012 at 2:01 PM, Steve Faulkner faulkner.st...@gmail.comwrote: 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
