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

[Bug 8731] Consider expanding buffering control for media elements

From: <bugzilla@wiggum.w3.org>
Date: Thu, 18 Feb 2010 04:50:07 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1NhyL1-0006GV-0O@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8731





--- Comment #18 from Maciej Stachowiak <mjs@apple.com>  2010-02-18 04:50:06 ---
(In reply to comment #17)
> 
> On the topic of autoplay vs this attribute, I really think the two aren't
> orthogonal. It really makes no sense to play without buffering, so the entire
> attribute is moot if we're autoplaying. Generally, that, to me, signals that it
> really should be the same attribute.

I don't think that argument works in general. For example: in CSS, if you have
"display: none" then your choice of font is moot, since you won't be rendering
any text. But that doesn't mean that choice of font should be controlled by the
"display" property, nor should display type be determined by font-face. To give
another example, when the type attribute of the "input" element is "image",
then the "src" attribute specifies the image to load. For other values of the
type attribute it has no effect. Likewise the "multiple" attribute only applies
for a subset of values of the "type" attribute. Yet it would not be the best
design to make the choice of image, or the choice of multiple vs not, be part
of the value of the type attribute.

It's not unexpected that attributes would sometimes interact, and that that not
all possible combinations may make sense. I think it's only logical to combine
things when they are truly affecting the same behavior. But "how much to load"
and "whether to start playing automatically" are separate behaviors, even
though they are contingent.


-- 
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 Thursday, 18 February 2010 04:50:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:11 UTC