[whatwg] 'hidden' as resources control (Was: Simplified <picture> element draft)

Thu Jan 23 18:13:38 PST 2014

On 1/22/14 6:07 PM, "Boris Zbarsky" <bzbarsky at MIT.EDU> 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
>><img>
>> 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:

<object style="display:none" data="image.png">

As well as:

<head>
<style>
.dn { display:none; }
</style>
<head>
<body>
<object class="dn" data="image.png">
<body>

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 <object> as image resource.

Is <object> 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
>
><script> elements are display:none, note.
>
>So are <link> elements.  Both get preloaded.

Nods, I understand it gets complicated with that notion.

>
>And people do in fact depend on display:none images being preloaded on
>the web today.  People paint those images to canvases, unhide them and
>expect them to show immediately, etc.

Well legacy behavior has made it so... just seems quite flawed in
responsive design context where you'd expect the ability to set resources
in the DOM with some control as to wether they ought to load or not,
rather be forced to have *all of them* preloaded.

What bugs me the most is that a developer's expectations is superseded by
a feature (the preloader) with different implementation per browser
engine, that are neither documented (in plain English) nor specced out by
W3C or WHATWG standards. As hard as it is, and notwithstanding the
benefits of the preloader(s), this is not good and keep developers
uninformed as to what to expect...

The lack of such resource control can be a huge waste of bandwidth in
collateral damage along the benefits of the pre-loader. And in the case of
responsive images, it prevents us from implementing any simple straight
forward js solutions.

Anyway, to come to the point of this new parallel thread, this leads me to
a suggestion:

'HIDDEN' as [resources control]:

Could 'resource control' be an associated spec of the 'hidden' attribute?
The semantics seem compatible with the specs implied by 'hidden'?

Being that: hidden "Specifies that the element represents an element that
is not yet, or is no longer, relevant" [1]. That suggest it may not be
needed at all and if so, why load it's associated resources?

Using the currently abandoned [2] 'postpone' attribute specs, 'hidden'
added specs 
become something along the lines of:

'This value indicates that the User Agent MUST not start downloading the
resource associated with the element until either the bounding box of the
element is inside the User Agent's interpretation of the Document's
viewport, or the element has been styled such that its hidden property is
removed.'

Hidden being just a boolean property easy to handle by the pre-loader.
And also possibly have it set on container elements that aren't
visible. i.e. Doing what postpone intended.

That would give developers at least one way in which they can put a
'conditional load' on selected resources with the ability to bypass the
pre-loader as well as reducing network costs, without the associated
conflict with display:none;

And then maybe IE will decide to implement 'hidden' as deemed worth such
updated specs and role? (although not completely sure why IE hasn't
implemented 'hidden' yet...)

What do you think?

[1] http://dev.w3.org/html5/markup/global-attributes.html

[2] "The WG agreed to scope the spec back to lazyload and work from there"
http://lists.w3.org/Archives/Public/public-web-perf/2013Nov/0099.html