Re: [whatwg] Proposal for change in recommendation for loading behavior of non-applicable stylesheets
On 6/10/12 4:33 PM, Scott Jehl wrote: One issue with this is that in many cases the UA may not yet know what media queries apply to the document when starting the sheet loads. In some cases it does, of course, but those may be rarer than you think… That makes sense. For my own understanding, do you have any examples of media queries that can't be determined until a later time? Well, for example inside an iframe determining whether a width query matches requires flushing out DOM construction, style computation, and layout on the parent document. Right now none of that is done, at least in Gecko, when kicking off a stylesheet load. And note that this would be racy: the iframe width might depend on other things in the parent document that haven't loaded yet (e.g., think a grid layout where the sizes of the grid cells depend on images whose intrinsic size is not known yet). Even for a non-iframe document in Gecko right now the style loads can start before any sort of presentation has been set up and before the document knows what screen it's on, which viewport it's being rendered into, etc. Communicating this information to the style loader is obviously possible, but would involve flushing out various work that's done lazily and reduces parallelism opportunities I'd presume a UA would be able to run these before a page has begun loading, or at least after a meta[name=viewport] element has loaded (so that would need to come before stylesheets in the head to take advantage of this feature). Is that not the case? I don't think we can rely on it being the case, necessarily especially long-term (e.g. the addition of changed how all this stuff works, and I bet there will be future spec changes that change it too). I'm not entirely sure I understand your iframe example and how it would relate to the media query differently than any viewport width. See above about having to do extra work, not normally needed, to lay out the parent document and the inherent races that entails. Okay. But even if a user's preferences have previously changed the default font-size of the browser (say, by increasing their font size), wouldn't the UA would be privy to that size at load time, and be able to use that in determining whether, say, an EM-based media query was applicable to the viewport width or not? The point is that if the sheet is not loaded at all and then the user zooms the page so that the viewport size changes while the page is loaded... what happens? Recall that this part of the proposal was to not load the sheet at all, as opposed to lazy-loading it. Lazy-loading is definitely desirable, though I'd be wary of the specs requiring it, especially because such requirements are not easily testable. E.g. nothing in the spec actually has any requirements at all on starting rendering. I'm not sure what the sanest thing is to do here in spec terms. :( -Boris
Re: [whatwg] Proposal for change in recommendation for loading behavior of non-applicable stylesheets
Thanks for responding, Boris! > One issue with this is that in many cases the UA may not yet know what > media queries apply to the document when starting the sheet loads. In > some cases it does, of course, but those may be rarer than you think… That makes sense. For my own understanding, do you have any examples of media queries that can't be determined until a later time? In observing trends in web development and in my own work, it seems to me that the following types of queries are most commonly used to deliver cross-device Responsive designs: min-width max-width min-device-width max-device-width min-device-pixel-ratio I'd presume a UA would be able to run these before a page has begun loading, or at least after a meta[name=viewport] element has loaded (so that would need to come before stylesheets in the head to take advantage of this feature). Is that not the case? I'm not entirely sure I understand your iframe example and how it would relate to the media query differently than any viewport width. I'd love a clarification on that part, but the following part is clear to me: > There are also various user actions that can similarly change the width of > even the toplevel window in CSS pixels such that it's larger than the nominal > device width in CSS px (e.g. zooming out, in UAs that change the size of CSS > px when you zoom). Okay. But even if a user's preferences have previously changed the default font-size of the browser (say, by increasing their font size), wouldn't the UA would be privy to that size at load time, and be able to use that in determining whether, say, an EM-based media query was applicable to the viewport width or not? > Except device queries and viewport queries are not at all the same thing, of > course. Conflating the two may be ok for a library that developers are free > to not use if it's making assumptions that are not true in their use cases, > but it's really not OK for a UA to do. Understood. This example would be difficult to apply broadly, which is unfortunate as it'd be the area where the actual savings in HTTP requests could be made. That said, merely deferring the load of stylesheets that don't apply at initial load would be a huge performance improvement for users. In a few large-scale responsive designs I've reviewed, sometimes more than half of the CSS delivered in the head of a page does not apply at all in small-screen contexts, yet the device must wait while all of it loads. >> 2. Reducing the amount of time that an unresponsive stylesheet can >> block page rendering > > Yes, indeed. Excellent. I'd suggest something in the 6-8 seconds range would be reasonable (and that's the timeout implemented in my sample framework above), but that may be too aggressive for most folks' tastes. Thanks again! Scott
Re: [whatwg] Proposal for change in recommendation for loading behavior of non-applicable stylesheets
On 6/10/12 12:51 PM, Scott Jehl wrote: I'd like to propose that the spec recommends that vendors defer the loading of Stylesheets referenced via inapplicable media so that they do not block page rendering. One issue with this is that in many cases the UA may not yet know what media queries apply to the document when starting the sheet loads. In some cases it does, of course, but those may be rarer than you think... For example, if a stylesheet is referenced using a (min-width: 1000px) media query, a small-screen device could decide that this stylesheet should not be fetched at all because it could never apply on its screen dimensions. Actually, it could, because the media query applies to viewport dimensions (in CSS pixels), not screen dimensions. A trivial example would be this document: There are also various user actions that can similarly change the width of even the toplevel window in CSS pixels such that it's larger than the nominal device width in CSS px (e.g. zooming out, in UAs that change the size of CSS px when you zoom). It merely re-evaluates if an inapplicable query would apply if it were a "device" query instead of a viewport query, and if not, the stylesheet is not loaded at all. Except device queries and viewport queries are not at all the same thing, of course. Conflating the two may be ok for a library that developers are free to not use if it's making assumptions that are not true in their use cases, but it's really not OK for a UA to do. I agree that better UA behavior here would be nice, but it's not trivial to do without breaking sites or creating a poor user experience. 2. Reducing the amount of time that an unresponsive stylesheet can block page rendering Yes, indeed. -Boris
[whatwg] Proposal for change in recommendation for loading behavior of non-applicable stylesheets
Hello. This is a proposal for an addition to the LINK element spec that includes a recommendation for deferring the load of inapplicable stylesheets until later in the load process (thus not blocking page rendering for unnecessary styles). Some background: CSS referenced by link elements or @import has always come with the limitation that it will block page rendering until it has finished loading. In many cases, there's good reason for this behavior, as the alternative - simply letting the page render independently of stylesheet requests -- almost always results in a flash of unstyled content. However, the downside of this behavior is that ALL CSS, not just the CSS that will apply to the particular device and viewport at the time of page load, will block page rendering. This means that sites that use CSS3 media queries to deliver different styles to different browsing conditions will be delivering more and more overhead. Recently, I did some research into how browsers request CSS files via link elements with inapplicable media queries. The results were grim. Of all browsers that I tested, every one would not only request all CSS files referenced with inapplicable media types/queries, but they would also block the rendering of page content until all of those inapplicable styles were loaded. Here's the test page including a table with the test results: http://scottjehl.github.com/CSS-Download-Tests/ Proposal for change: I'd like to propose that the spec recommends that vendors defer the loading of Stylesheets referenced via inapplicable media so that they do not block page rendering. These stylesheets should probably still be requested asynchronously so that they are present in the event that their media becomes active (say, after a browser resize or orientation change), but loading them up-front slows down the user experience unnecessarily. Example implementation of proposed behavior: Following the research above, I created a JavaScript utility that causes browsers to load CSS in a blocking or asynchronous manner, depending on their need at load time. I'm not a fan of using JavaScript to do something like this unless we have to, but for the time being, I think it illustrates the advantages of the proposed behavior. The project readme explains further and includes demo files that log information about what files where loaded, and how, depending on device and viewport conditions: https://github.com/scottjehl/eCSSential#readme One very common case that this unfortunately can never solve is preventing the request of inapplicable styles that are concatenated into a single CSS file. The workaround above addresses this scenario though, and if link fetching behavior was improved in the ways suggested above, a workaround that works with concatenated files would at least be easier to produce. -- FURTHER SUGGESTIONS -- 1. Entirely preventing the request of stylesheets that may never apply It would be ideal if a device could completely restrict the download of stylesheets that it determines could never apply within its environment. For example, if a stylesheet is referenced using a (min-width: 1000px) media query, a small-screen device could decide that this stylesheet should not be fetched at all because it could never apply on its screen dimensions. This is actually the default behavior implemented by the eCSSential workaround above for min and max height/width queries. It merely re-evaluates if an inapplicable query would apply if it were a "device" query instead of a viewport query, and if not, the stylesheet is not loaded at all. The savings in HTTP weight and request counts as a result of this change can be very significant on a small screen. Of course, this behavior runs the risk of not having a stylesheet on-hand when the browser is moved to another screen. With this edge case in mind, it would be ideal if stylesheets that could not apply on a particular device are ONLY requested in the event that their media conditions become true. In other words, if device conditions changed to make a media query apply, such as moving the browser window to another screen, the necessary stylesheets would be requested at that time. 2. Reducing the amount of time that an unresponsive stylesheet can block page rendering One last suggestion. In the research above, I found that many modern browsers will prevent page rendering for upwards of 30 seconds (sometimes more) to ensure that all stylesheets have loaded. If a server is not responding for some reason, this results in a completely unusable experience. I'd like to propose that the spec recommends that stylesheets be given a timeout of a much lower maximum before rendering the page in whatever state it happens to be in. Ideally, the responsive requests would be left open or restarted so that they're given a chance to load and apply after the content is shown, but they should not block page rendering af
Re: [whatwg] Validator.nu: "Attribute role not allowed on element h2 at this point."
Hi Ian, On 10 June 2012 10:16, Steve Faulkner wrote: > Hi Ian, > >> On Mon, 12 Mar 2012, Charles Pritchard wrote: >> > On 3/12/2012 5:52 PM, Ian Hickson wrote: >> > > On Mon, 12 Mar 2012, Charles Pritchard wrote: >> > > > > >> > > > > Ignore the error, the HTML5 spec does not reflect implementations >> > > > > in this section about ARIA. >> > > > > >> > > > > The warning is not helpful to authors nor does it accurately >> > > > > describe the means in which ATs work with ARIA. >> > > >> > > Are you saying you think the spec is wrong here and we should not >> > > allow role="presentational"? I tend to agree, but I'm not sure it's >> > > worth it to try and work out exactly when role=presentational is >> > > harmful (as in this case) and when it's not. >> > >> > Consider something like CSS ::outside; it's a nice feature, but it's not >> > in many browsers. If it were, it'd make more sense for authors to mark >> > up decorative/presentation text in CSS. >> > >> > Pragmatically authors they have to make decisions, and sometimes that >> > means various techniques with HTML4 and strange mixes of roles. >> >> I don't understand how to interpret your answer with respect to my >> question (and thus whether you think the spec should change, given your >> earlier statement). >> >> >> > > On Mon, 12 Mar 2012, Charles Pritchard wrote: >> > > > > > These should only be warnings, not errors. The language "Authors >> > > > > > must not" is inappropriate. >> > > >> > > Warnings are generally not useful. Either something is fine and we >> > > should support it, or it's wrong and we should alert the author. I >> > > think "must" is very much the appropriate requirement level here. >> > >> > From the implementation-side, the spec is wrong, it ranks native HTML >> > semantics above ARIA DOM semantics. >> >> I do not understand what this means or why it is wrong. >> >> >> > As a "best practices" note, it seems overly optimistic. There are >> > situations with AT navigation where role conflicts do occur and/or >> > redundancy in tagging is helpful. >> >> Can you elaborate on this? Specifically, can you give an example of such a >> case that conflicts with what the spec says? >> >> >> > I don't believe it is appropriate for HTML to place restrictions on ARIA >> > DOM. It's does not reflect implementations. The HTML spec should only >> > specify what the default mappings are for HTML elements to ARIA. Authors >> > may be advised to test AT software with their product. >> >> I don't understand what you mean. >> >> >> > This statement is more in line with practice: "Authors must test >> > accessibility tree as part of development and usage of ARIA semantics.". >> >> We can't really put normative conformance criteria on whether authors test >> or not, that's a bit weird... >> >> >> On Tue, 13 Mar 2012, Charles Pritchard wrote: >> > >> > Some wild guesses: >> > Treating a link as a button or a button as a link. >> >> I agree that allowing a button to be reported as being a link is bad for >> accessibility. The spec currently allows this due to a W3C HTMLWG chair >> decision that I opted not to challenge. >> >> >> > @disabled and aria-disabled may be used via reference with aria-controls. >> > type="range" and role=slider for redundancy. >> > various styling tricks with css selectors. >> >> Can you elaborate on these? In what way do they conflict with HTML? >> >> >> > I've used role and/or redundant ARIA within the scripting environment to >> > minimize calls in applications checking for roles. Redundancy doesn't >> > harm anything, I actively promote it, as it does help, sometimes. >> >> I disagree with that premise, for what it's worth. Redundancy can lead to >> a number of problems; on the Web, in particular, it's common for >> redundancy to lead to cargo-cult authoring mistakes. For example, expert A >> writes a Web page with some redundant roles, author B copies markup from >> that page and changes it to suit their needs, but ignores the previously >> "redundant" bits and thus ends up with conflicting information instead of >> redundant information. Page ends up being sub-optimally accessible, >> because the previously "redundant" accessibility annotations now conflict >> with the page's real semantics, and are wrong. >> >> >> > Ian has stated that warnings aren't very useful, he's looking for error >> > or bust. That's confusing when it comes to ARIA testing, as it's more >> > about the pragmatic effects of applying semantics and using a variety of >> > ATs to test them. >> >> It's all about the pragmatic effects always. I don't see how this changes >> things here. Maybe we understand the words "error" and "warning" differently? >> >> >> On Tue, 13 Mar 2012, Scott Gonz�lez wrote: >> > >> > It's my understanding that authors should only apply ARIA via script. >> > The redundancy cases seem to be the most reasonable use cases I've heard >> > of for wanting ARIA in the initial markup, but even that seems wrong. >> > What happens
[whatwg] Validator.nu: "Attribute role not allowed on element h2 at this point."
Hi Ian, > On Mon, 12 Mar 2012, Charles Pritchard wrote: > > On 3/12/2012 5:52 PM, Ian Hickson wrote: > > > On Mon, 12 Mar 2012, Charles Pritchard wrote: > > > > > > > > > > Ignore the error, the HTML5 spec does not reflect implementations > > > > > in this section about ARIA. > > > > > > > > > > The warning is not helpful to authors nor does it accurately > > > > > describe the means in which ATs work with ARIA. > > > > > > Are you saying you think the spec is wrong here and we should not > > > allow role="presentational"? I tend to agree, but I'm not sure it's > > > worth it to try and work out exactly when role=presentational is > > > harmful (as in this case) and when it's not. > > > > Consider something like CSS ::outside; it's a nice feature, but it's not > > in many browsers. If it were, it'd make more sense for authors to mark > > up decorative/presentation text in CSS. > > > > Pragmatically authors they have to make decisions, and sometimes that > > means various techniques with HTML4 and strange mixes of roles. > > I don't understand how to interpret your answer with respect to my > question (and thus whether you think the spec should change, given your > earlier statement). > > > > > On Mon, 12 Mar 2012, Charles Pritchard wrote: > > > > > > These should only be warnings, not errors. The language "Authors > > > > > > must not" is inappropriate. > > > > > > Warnings are generally not useful. Either something is fine and we > > > should support it, or it's wrong and we should alert the author. I > > > think "must" is very much the appropriate requirement level here. > > > > From the implementation-side, the spec is wrong, it ranks native HTML > > semantics above ARIA DOM semantics. > > I do not understand what this means or why it is wrong. > > > > As a "best practices" note, it seems overly optimistic. There are > > situations with AT navigation where role conflicts do occur and/or > > redundancy in tagging is helpful. > > Can you elaborate on this? Specifically, can you give an example of such a > case that conflicts with what the spec says? > > > > I don't believe it is appropriate for HTML to place restrictions on ARIA > > DOM. It's does not reflect implementations. The HTML spec should only > > specify what the default mappings are for HTML elements to ARIA. Authors > > may be advised to test AT software with their product. > > I don't understand what you mean. > > > > This statement is more in line with practice: "Authors must test > > accessibility tree as part of development and usage of ARIA semantics.". > > We can't really put normative conformance criteria on whether authors test > or not, that's a bit weird... > > > On Tue, 13 Mar 2012, Charles Pritchard wrote: > > > > Some wild guesses: > > Treating a link as a button or a button as a link. > > I agree that allowing a button to be reported as being a link is bad for > accessibility. The spec currently allows this due to a W3C HTMLWG chair > decision that I opted not to challenge. > > > > @disabled and aria-disabled may be used via reference with aria-controls. > > type="range" and role=slider for redundancy. > > various styling tricks with css selectors. > > Can you elaborate on these? In what way do they conflict with HTML? > > > > I've used role and/or redundant ARIA within the scripting environment to > > minimize calls in applications checking for roles. Redundancy doesn't > > harm anything, I actively promote it, as it does help, sometimes. > > I disagree with that premise, for what it's worth. Redundancy can lead to > a number of problems; on the Web, in particular, it's common for > redundancy to lead to cargo-cult authoring mistakes. For example, expert A > writes a Web page with some redundant roles, author B copies markup from > that page and changes it to suit their needs, but ignores the previously > "redundant" bits and thus ends up with conflicting information instead of > redundant information. Page ends up being sub-optimally accessible, > because the previously "redundant" accessibility annotations now conflict > with the page's real semantics, and are wrong. > > > > Ian has stated that warnings aren't very useful, he's looking for error > > or bust. That's confusing when it comes to ARIA testing, as it's more > > about the pragmatic effects of applying semantics and using a variety of > > ATs to test them. > > It's all about the pragmatic effects always. I don't see how this changes > things here. Maybe we understand the words "error" and "warning" differently? > > > On Tue, 13 Mar 2012, Scott Gonz�lez wrote: > > > > It's my understanding that authors should only apply ARIA via script. > > The redundancy cases seem to be the most reasonable use cases I've heard > > of for wanting ARIA in the initial markup, but even that seems wrong. > > What happens when you have type=range and role=slider, the UA doesn't > > understand the new types, and the script either never loads or has an > > error? The AT will pick up the role
