- From: Philip Jägenstedt <philipj@opera.com>
- Date: Tue, 14 Jul 2009 10:45:31 +0200
On Mon, 13 Jul 2009 23:28:41 +0200, Jonas Sicking <jonas at sicking.cc> wrote:
> On Mon, Jul 13, 2009 at 5:01 AM, Philip J?genstedt<philipj at 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
Received on Tuesday, 14 July 2009 01:45:31 UTC