W3C home > Mailing lists > Public > public-html@w3.org > March 2010

Re: Default value of "preload" attribute

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 25 Mar 2010 11:13:50 +1100
Message-ID: <2c0e02831003241713s71a7bc54x8592f432bdd68b7c@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: "Robert O'Callahan" <robert@ocallahan.org>, public-html <public-html@w3.org>
On Thu, Mar 25, 2010 at 10:51 AM, Ian Hickson <ian@hixie.ch> wrote:
> On Thu, 25 Mar 2010, Robert O'Callahan wrote:
>> The default value of "preload" is currently "auto".
> Actually the spec says the default is UA-defined. "auto" is only a
> suggestion.
>> The definition of "auto" is
>> "Hints to the user agent that the user agent can put the user's needs first
>> without risk to the server, up to and including optimistically downloading
>> the entire resource."
>> This seems like a hint that authors should opt into rather than being
>> the default. Authors who don't think about what they're doing may omit
>> "preload" on large media resources and find that everything's fine for a
>> while, but later users with faster, cheaper networks and more local
>> storage connect and download essentially unbounded quantities of media
>> data. There are already examples of pages with many media elements with
>> no "preload" (or "autobuffer") attribute. IMHO "metadata" would be a
>> better default.
> That is a conforming implementation.
> I'd be happy to change the suggestion to "Metadata" if you think that
> would be better, but essentially that is an editorial change.

I understood "auto" to mean "whatever the UA thinks is best".

But thinking about Rob's argument, "metadata" might make a lot of
sense. For those videos that aren't autoplay, even YouTube does
exactly that (just to give a reference example). This makes a server a
lot less fragile towards full buffering.

OTOH it enforces that UA control be explicitly given with the "auto"
attribute value. I guess the smaller risk for servers with lazy Web
developers is to make "metadata" the default.

Received on Thursday, 25 March 2010 00:14:43 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:00 UTC