W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > August 2009

[Bug 7428] New: Safari 4 preloads media and FF 3.5 doesn't in <audio> tag; perhaps HTML5 sections 4.8.10.5 4.8.10.8 are unclear or need a 'preloading' attribute added.

From: <bugzilla@wiggum.w3.org>
Date: Wed, 26 Aug 2009 01:31:35 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-7428-2486@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7428

           Summary: Safari 4 preloads media and FF 3.5 doesn't in <audio>
                    tag; perhaps HTML5 sections 4.8.10.5 4.8.10.8 are
                    unclear or need a 'preloading' attribute added.
           Product: HTML WG
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec proposals
        AssignedTo: dave.null@w3.org
        ReportedBy: steven_rowat@sunshine.net
         QAContact: public-html-bugzilla@w3.org
                CC: ian@hixie.ch, mike@w3.org, public-html@w3.org


User agents FF and Safari have opposite implementations of preloading of audio
media using the same <audio> HTML, apparently due to insufficient clarity in
HTML5 4.8.10.5 Autobuffer and 4.8.10.8 Autoplay requirements.

This causes a page with many audio controllers (such as a search results page)
to load so slowly in Safari that it is unusable. 

Examination of the relevant sections in the HTML 5 Aug 25 draft proposal
(reproduced below) show that there is no specific direction about preloading
behavior. This should be fixed, because whether or not the page preloads media
is a major determinant of page success/usability when there are multiple
controllers.

To clarify: a page with one or two controllers will perform fine whether there
is a preload or not, but a search results page (for example), or any page with
many controllers, will only function well if the controllers do NOT preload.
Preloading 25+ controllers can take minutes of spinning beach balls before
control of the cursor is regained by the user. This is unacceptable and it
should be within the power of the page author to specify that preloading is not
to occur.

More specifically:

Firefox, encountering an <audio> and <source> tag with src media, does not
preload if the autoplay and autobuffer are both absent. See mozilla bug
https://bugzilla.mozilla.org/show_bug.cgi?id=493860
 Bug 493860 -  Add a pref to disable automatic download of videos (ogg) even if
autoplay/autobuffer is set  

See comment #5
"If autoplay and autobuffer are not specified on the element, Firefox will stop
fetching data once enough has been downloaded to decode the first frame of the
video or (for audio only) the audio metadata has loaded."

Safari, with the same configuration, does preload the media. 

Here are relevant sections I can find in the HTML5 Aug 25 draft:

"4.8.10.5 Loading the media resource

"The autobuffer  attribute is a boolean attribute. Its presence hints to the
user agent that the author believes that the media element will likely be used,
even though the element does not have an autoplay  attribute. (The attribute
has no effect if used in conjunction with the autoplay attribute, though
including both is not an error.) This attribute may be ignored altogether. The
attribute must be ignored if the autoplay attribute is present."

4.8.10.8 Playing the media resource

"The autoplay  attribute is a boolean attribute. When present, the user agent
(as described in the algorithm described herein) will automatically begin
playback of the media resource as soon as it can do so without stopping"


The main thing I notice about these sections is that automatic preloading is
not mentioned and so must be interpolated; apparently in opposite directions by
the two user-agents.

I can see two possible solutions (the first probably easier):
  1. Specify as part of the spec that preloading is not to occur if both
autoplay and autobuffer are absent (the FF behavior).
  2. Define a new boolean attribute, 'autoload', and attach that behavior to
it: ie., if it's absent, no preload; if it's present, preload.

Perhaps it's possible to control these things via Javascript and/or the DOM as
well, but I've managed to avoid going there for many years and I don't want to
start now. :-) . Joking aside, I think this is a straightforward and important
issue that should be available to anyone who writes HTML/CSS; ie, that there
should be an HTML element attribute combination that unequivocally controls
<audio> media preloading.

p.s.
It wouldn't surpise me to find that this is all the same for <video>, but I
haven't tested it.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 26 August 2009 01:31:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 26 August 2009 01:31:49 GMT