W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2014

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

From: Bruno Racineux <bruno@hexanet.net>
Date: Fri, 24 Jan 2014 13:09:28 -0800
To: David Newton <david@davidnewton.ca>, Boris Zbarsky <bzbarsky@MIT.EDU>, "Tab Atkins Jr." <jackalmage@gmail.com>
Message-ID: <CF07FF15.806BE%bruno@hexanet.net>
Cc: WHATWG <whatwg@lists.whatwg.org>

On 1/24/14 7:35 AM, "David Newton" <david@davidnewton.ca> wrote:

>On Jan 23, 2014, at 10:52 PM, Boris Zbarsky <bzbarsky@MIT.EDU> 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" <bzbarsky@MIT.EDU> 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 <object> 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 <object>
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." <jackalmage@gmail.com> 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 <object> 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
<object>.

-Bruno
Received on Friday, 24 January 2014 21:10:12 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:15 UTC