[whatwg] defer on style, depends

On Mon, Feb 9, 2009 at 2:26 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 9 Feb 2009, Garrett Smith wrote:
>> On Sun, Feb 8, 2009 at 9:20 PM, Ian Hickson <ian at hixie.ch> wrote:
>> > On Sun, 8 Feb 2009, Garrett Smith wrote:
>> >>
>> >> Sometimes a document's resources are not needed all at first. For
>> >> example, a script that is not needed until after the document is
>> >> parsed can be given the defer attribute (for browsers that support
>> >> defer).
>> >>
>> >> External css can also be a blocking download. Scripts have defer
>> >> attribute, but style and link do not.
>> >>
>> >> The proposal is to add to defer to style, and link.
>> >>
>> >> This will allow browsers to not block on those elements.
>> >
>> > Browsers are already allowed to not block on those elements.
>>
>> But they do.
>>
>> If a script occurs after a link, the script expects updated style
>> information. That is why browsers do block on scripts.
>
> They block on scripts, yes. (Not on style.)
>
> See my reply to Jonas for further discussion of this matter.
>

If I put the script at the bottom of the page, and a linked stylesheet
in the head, the script waits for the stylesheet.

I want my page to load faster and this feature prevents it.

>
>> >> It would be more complete to have a depends attribute on script and
>> >> style.
>> >>
>> >> <script depends="a b c"></script>
>> >>
>> >> Where the depends is id-list [CS], space separated values of element
>> >> IDs.
>> >
>> > Why can't you just put the <script> element below the elements whose
>> > IDs you would have listed?
>>
>> An associated script might need that stylesheet to be loaded before it
>> runs. The depends attribute would guarantee that the stylesheet had
>> loaded. The order should not change because the script is an inline
>> scripts vs an external resource.
>
> It seems pretty simple to me; if you want the style to be loaded when the
> script runs, put the style first. If you don't, put the script first and
> defer it (or mark it async). Why should this not be enough?
>

The implementation might delayed the page from rendering when it sees
the stylesheet.

The script's defer attribute does not work in a majority of
implementations. For such browsers, it makes sense to put the script
lower on the page for performance reasons, not before the linked
stylesheets. Moving the deferred script from the bottom of the page to
the head, just before the stylesheet would mean that those scripts
would load first. This would prevent the page content from loading
until those scripts had loaded. This would hurt performance in the
majority of browsers in use today.

Putting scripts at the bottom works in all browsers. Including a
linked stylesheet in the head causes delays.

Please see the link that Thomas Broyer provided. See the section "Don't Stall".

Please also visit the example I made last night.

>
>> The "depends=" attribute allows the script to declare that it needs
>> style information first. This would be a much better design, and could
>> probably be implemented by the browser with some nice event-driven code.
>> Unfortunately, implementations that encounter <link defer
>> type="text/css"...>, followed by a script with no "depends" would still
>> have to block on that stylesheet because that is what they do today.
>>
>> The script could declare itself as "independent".
>>
>> That would result in links not blocking.
>>
>> To allow the stylesheet to load after all content loads, the stylesheet
>> could declare defer:
>>
>> <link defer src="deferred-all-min.css" type="text/css" rel="stylesheet"
>> id="lateBoundCSS">
>>
>> To fulfill a requirement of having loaded of the stylesheet before the
>> script runs, that script could declare depends to declare that it needs
>> style information before loading.
>>
>> <script defer depends="lateBoundCSS" src="app-all-min.js"></script>
>
> This seems like an inordinate amount of complexity for something that can
> just work already.
>

Whatever.

>
>> >> It would also be useful to have a way to dynamically load scripts,
>> >> other than createElement("script").
>> >
>> > This seems like a request for the ECMAScript group.
>>
>> Maybe. I would probably not be able to use it before I retire.
>
> We should not design specifications around the characteristics of the
> committees. If you have a problem with the ECMAScript group, I urge you to
> bring it to their attention. This forum is inappropriate for such
> discussion.

You focused on one sentence that I wrote. You misinterpreted what I
wrote. I never ever suggested designing a specification around
committee characteristics. I said:

| A script belongs to a document. ECMAScript has no notion of document.

Lets try to stay on-topic and focused. Thanks.

Garrett

Received on Monday, 9 February 2009 09:35:20 UTC