On Mon, 13 Jul 2009 23:28:41 +0200, Jonas Sicking <jo...@sicking.cc> wrote:
On Mon, Jul 13, 2009 at 5:01 AM, Philip Jägenstedt<phil...@opera.com>
wrote:
The design you describe is what <object> tried to do, and it proved
to be
extremely problematic in practice -- and that was without another
built-in
fallback mechanism to complicate matters.
While <object> has had a very poor implementation story, I don't think
this was a big reason for that.
Robert O'Callahan, Boris Zbarsky and other gecko layout folks can
answer this better, but at least in gecko I don't think this part of
object was particularly hard to implement correctly once we actually
tried.
Has any browser vendor argued against displaying the fallback due to
high implementation burden?
Implementation probably isn't the biggest burden here, specifying sane
behavior is. For example:
If fallback content is displayed after the last source element has
failed,
what should happen when a new source element is inserted? Switching
back to
"video mode" would make it even more special than object fallback and
if you
don't you'll just get stuck with fallback and have effectively broken
the
possibility of inserting source elements via scripts.
Something like <video><source
src="cant.play.ogg"><new-fallback-element>Ooops!</new-fallback-element></video>
is what you'd need to make the resource selection algorithm deal with
fallback in a sane way when scripts are disabled, but this is too much
of a
corner case to justify the complexity in my opinion.
I think fallback contents is simply defined as the contents of the
<video>, minus any <source> elements (which wouldn't render anyway).
No need for <new-fallback-element>.
If I may nit-pick, the spec explicitly says "this content is not fallback
content". But your suggestion is to change is, so very well...
The simplest solution would be to display the fallback when there
aren't any <source> (or @src) elements being either displayed or
waiting to load. I think spec-wise the simplest thing would be to
display fallback when
The networkState of the element is NETWORK_NO_SOURCE.
This way even incremental rendering of the fallback contents would
work fine. The only case that's weird is markup like:
<video>
lots and lots of fallback here
<source src="...">
</video>
There is a risk that content would be displayed, and then switch to
displaying video. This doesn't seem like a big problem as it seems
more likely that people will put the <source> first. And if someone
doesn't the effects aren't very bad.
Alternatively we could use the following rules:
1. The networkState of the element is NETWORK_NO_SOURCE.
*and*
2. The <video> element is fully parsed. I.e. it has been removed from
the stack of open elements.
This would mean that incremental rendering doesn't work. This doesn't
seem any worse than what we have now when fallback is never displayed.
Though I think it'd work fine always display fallback whenever the
networkState is NETWORK_NO_SOURCE.
/ Jonas
Anything that can cause the element to switch back and forth between
displaying fallback and video is a no-go, that would cause a race
condition for if plugins/images in the fallback content. If they have
event handlers the results will get ugly fast:
<video>
<!-- network lag -->
<source>
<!-- network lag -->
<source>
<!-- network lag -->
<img src=foo onload="alert('how many times will you see this message?')">
</video>
--
Philip Jägenstedt
Core Developer
Opera Software
