[whatwg] [hidden] attribute should not allow overrides via css
Those two lines from spec [1] are in conflict:
"Because this attribute is typically implemented using CSS, it's also
possible to override it using CSS"
"if something is marked hidden, it is hidden from all presentations"
The latter is not true as currently implemented.
The former allows a css enabled styled presentation to display a hidden
element,
while browsing with *styles disabled* with have the element hidden (not
displayed)
due to the default browser stylesheet making it so.
Technically it is therefore *not* hidden form all presentations and
breaks the hidden = aria-hidden accessibility assumptions. I find this
conflicting.
And allowing a css override, breaks my use case:
Say, I have a link: Email . And I only want this
link to
render dynamically and conditionally as a mailto: href with a
'display:block' style.
I am unable to pre-style my links with a 'display:block', because it cancels
'hidden',
which makes 'hidden' useless to me here if it wasn't for a *[hidden] {
display: none; }
at the end of my stylesheet.
I strongly suggest that hidden be made a 'display: none !important' instead
to remedy this confusion.
[1] https://html.spec.whatwg.org/#the-hidden-attribute
Re: [whatwg] HTML spec incorrectly suggests that can have its rendering changed with CSS
On 1/28/14 1:04 AM, "Elliott Sprehn" wrote:
>>
>Blink treats (conceptually) like a subclass of Text, there's nothing
>to style because it's just a run of text with a forced break.
I'd just like to note that 'inline' styling for should be allowed.
I have been using it for a long time as spacing adjustment, and
sometimes for addressing extra unwanted space with double entries
from wysiwyg, with the following rule:
br { font-size: 8px; line-height: 8px; }
To my recollection such styling was/is applied in all browsers.
Not sure if line-height is considered 'styling' in those terms, but just
want to mention that historical use case of applied styling on .
Re: [whatwg] 'hidden' as resources control
On 1/26/14 3:39 PM, "Qebui Nehebkau" wrote: >On Sat, Jan 25, 2014 at 4:13 AM, Bruno Racineux wrote: >> What exactly do you find misguided, can you be more specific? > >Basically, - and I'm trying not to over-elaborate here, since my >opinion isn't really very important - I just mean that I don't think >there should be any guarantees about how (or whether) browsers will >preload, nor any specific means of controlling this, because the way >resources get loaded is not really any of the author's business. I couldn't disagree more. It is my business to know how the browser loads assets in order to better assist the best performance for my users. Don't want to over-elaborate either but I'll leave you with a relevant quote: "The good news is all of these optimizations are done automatically on our behalf and often lead to hundreds of milliseconds of saved network latency. Having said that, *it is important to understand how and why these optimizations work under the hood*, because we *can* assist the browser and help it do an even better job at accelerating our applications." Ilya Grigorik - High Performance Browser Networking http://chimera.labs.oreilly.com/books/123000545/ch10.html#BROWSER_OPTIM IZATION There is a balance between putting DOM loading on auto-pilot, blindly assuming the preloader is your friend and can do no wrong, and the reality that the preloader can't ultimately do the best job on its own. It needs to be assisted with resource priority attributes (or preferably css) for better control. Without them, the preloader is no more than a 'seen-first priority' faster loader, with a priority agnostic performance shortfall. >the argument that preloaders >can't consider CSS isn't compelling to me, because a browser's choice >to preload an image or not isn't important enough (or, I think it >shouldn't be) to justify entrenching in a specification. If not for specifications, we certainly need 'preload opt-out' tools to better manage loading priorities. Whether it be 'postpone', 'lazyload' or said implications of 'hidden', and some documentation as to what to expect from preloaders.
Re: [whatwg] 'hidden' as resources control (Was: Simplified element draft)
On 1/24/14 7:37 PM, "Qebui Nehebkau" wrote: >On Fri, Jan 24, 2014 at 9:09 PM, Bruno Racineux wrote: >> The requirement for ATs with 'hidden' is to access the structure of >>hidden >> elements. Not the presentation aspect... I am having a hard time >> translating that a resources that is "not yet needed or is no longer >> needed" means that it should load immediately *regardless*. >That seems like it should be up to the user, and, thus, the user >agent, yes? This is not about user-agents. Not sure what you are getting at... >The question of whether and what to preload strikes me as >very much contingent on the priorities and circumstances of individual >users, and obviously not at all the authors' business. I find the >entire subject of specifying how user agents should preload completely >misguided. Shouldn't this, if *anything*, be open for innovation? What exactly do you find misguided, can you be more specific?
Re: [whatwg] 'hidden' as resources control (Was: Simplified element draft)
On 1/24/14 7:35 AM, "David Newton" wrote: >On Jan 23, 2014, at 10:52 PM, Boris Zbarsky wrote: > >> On 1/23/14 9:13 PM, Bruno Racineux wrote: >>> Could 'resource control' be an associated spec of the 'hidden' >>>attribute? >> >> It bothers me, at first glance, to overload the attribute to mean >>different things. I predict people will appear who want the hidden >>thing to hide but still want loading/preloading. >> >> It would be better to just have a separate attribute for the separate >>task if we go this direction. > >In addition to overloading `hidden`, it misses the `postpone` use case of >images that we want to be visible (i.e. not have a `hidden` attribute), >but not loaded until/unless the user scrolls enough for them to be in the >viewport. I am not necessary saying that it should replace 'postpone'. Though note again as I mentioned that 'postpone' is currently dead per: http://lists.w3.org/Archives/Public/public-web-perf/2013Nov/0099.html I am not sure what happens to the use case you mention;'lazyload' doesn't cover it and I don't recall it it did when before 'lazyload' was split into lazyload+postpone. But because without css 'postpone' can't work. That's Where 'hidden' actually helps implementing the 'postpone' functionality. 'Postpone' could exist separately as jit for that image lazy-loading case. The requirement for ATs with 'hidden' is to access the structure of hidden elements. Not the presentation aspect... I am having a hard time translating that a resources that is "not yet needed or is no longer needed" means that it should load immediately *regardless*. In practice that is not the case. The 'not yet' may never happen... Yet we decide to preload something 'hidden' which the UserAgent is asked "not to render". It doesn't compute for me... And I am not trying to overload 'hidden'. I am strongly conveying that by design, 'hidden' should not load right away as currently implied by current specs. The question become when does 'hidden' ought to load. It can load 3 ways: 1. Lumped into preloading like everything else, 2. On DOMContentLoaded or 3. Just-in-time loading. Either option 2 or 3 seem perfectly legitimate choices. But I strongly disagree with option 1 as default. 'hidden' indicate a lower priority. Preloading 'hidden' elements seems just wrong in the first place. It introduces backward resource priorities. On 1/23/14 7:52 PM, "Boris Zbarsky" wrote: >>Not only the pre-loader doesn't load the data-src >>but "image.png" doesn't actually load at all. > >How did you determine that last, if I might ask? Right, it's only webkit. My test were just follow-ups on Kornel's initial discovery: https://twitter.com/pornelski/status/405704147678535680 One false hope for potentially using as responsive image polyfill (or actual solution) because IE doesn't wait for the document 'interactive' state or documentready like Firefox or Webkit do, and so altering with JS prior to its resource loading is a no-go in IE... Just for the context. On 1/23/14 7:05 PM, "Tab Atkins Jr." wrote: >> >>Not only the pre-loader doesn't load the data-src >>but "image.png" doesn't actually load at all. > >You're assuming that preloads at all. Considering the pre-loader loads everything displayed or not, yes. That's not for misinterpreting any documentation though. And there is in fact a webkit bug, and/or oversight in implementation with . -Bruno
Re: [whatwg] 'hidden' as resources control (Was: Simplified element draft)
On 1/22/14 6:07 PM, "Boris Zbarsky" wrote:
>On 1/22/14 8:14 PM, Bruno Racineux wrote:
>> Meanwhile, is there a way in which all vendors can prevent their
>> pre-loaders from preloading (and loading at all for that matter) any
>>
>> that has either: An html5 hidden attribute
>
>This is feasible.
>
>> or display:none
>
>This is not really. The preload scanner has no idea bout styles.
Then how come it is the case right now for both:
As well as:
.dn { display:none; }
Not only the pre-loader doesn't load the data-src
but "image.png" doesn't actually load at all.
The above suggested to me that it is possible, as it seems to be what's
currently in place in Webkit for as image resource.
Is treated as such a Bug then?
>> I think it's safe to say that, for the browser to load assets marked as
>> 'display:none;' makes little sense
>
>
Re: [whatwg] Simplified element draft
On 1/22/14 3:54 PM, "Adam Barth" wrote: >The way we'd likely implement this feature in Blink is in couple >stages. In the first stage, we'd implement the portions of the >specification that don't involve media queries because we'll be able >to provide developers a high-quality implementation of that part of >the spec, including preload scanning. In the second stage, we'd >implement the parts of the specification that relate to media queries. > We'll likely wait to implement the second stage until we're able to >provide a high-quality implementation, which means waiting until we're >able to parse and process media queries in the preload scanner without >joining the main thread. > >Adam Meanwhile, is there a way in which all vendors can prevent their pre-loaders from preloading (and loading at all for that matter) any that has either: An html5 hidden attribute, or display:none; both inline or via a css class in the head, which is the current behavior of the element in Webkit: https://twitter.com/pornelski/status/405704147678535680 I think it's safe to say that, for the browser to load assets marked as 'display:none;' makes little sense, and overrides a developer's ability to control when his/her assets are supposed to load. Browsers loading stuff that's voluntarily set as hidden is a bad performance predisposition, as well as a waste of bandwidth, especially when it comes to responsive mobile sites where the context of hidden *really* means hidden as in: Do *not* load unless actually displayed. Bruno
Re: [whatwg] The src-N proposal
On 11/20/13 6:09 PM, "Kornel Lesiński" wrote: >With preload scanner limitation definitions in is the best we >could >possibly do. I have proposed Media Query Variables intended to be used in > > in for responsive images. > >I've also wanted MQ variables to be usable in external stylesheets to >reduce repetition in regular @media CSS, but even mere possibility of >authors misusing external CSS definitions for responsive images (which >would achieve centralization you want, but also get in the way of preload > >scanner) made browser vendors feel uneasy about this proposal. But having custom MQs in the head (on the main thread if I understand well), actually helps the preloader, and as such, creates a 2 fold situation, where external misuse fears is also hurdle to the preloader. Perhaps separating MQ variables and/or 'CSS constants' in a separate css type is a way to go then... just a syntax for example sake: