- From: Brendan Long <self@brendanlong.com>
- Date: Thu, 16 Jan 2014 13:39:51 -0700
- To: public-html@w3.org
- Message-ID: <52D84397.5060703@brendanlong.com>
On 01/16/2014 01:09 PM, Brendan Long wrote:
>
>> Ok. So existing WebKit behavior will add the cue again if the
>> application modified it. That is likely to be surprising to the
>> application developer. We definitely need clarification on what the
>> proper behavior should be in the spec.
>> Does this behavior take into account cues added by the application
>> itself. For example if the application uses addCue
>> <http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#addcue%28cue%29>()
>> with data that is identical to something in the in-band track, will 2
>> cues get displayed or only the one? It sounds like it would only be 1
>> which also might be surprising to the developer.
> In the case of WebKit, we should probably make the duplicate detection
> ignore cues added via addCue(), and check if the new cue matches the
> original content of a cue, not the current content. I think that would
> fix both of these.
>
I created two WebKit bugs for this, since the current behaviour seems to
be broken in these cases:
https://bugs.webkit.org/show_bug.cgi?id=127134
https://bugs.webkit.org/show_bug.cgi?id=127133
I'm willing to alter or remove these bugs if the consensus is that we
want to do it another way though.
--------------010305030606050603010808
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 01/16/2014 01:09 PM, Brendan Long
wrote:<br>
</div>
<blockquote cite="mid:52D83C62.1040207@brendanlong.com" type="cite">
<br>
<blockquote type="cite">
<div>Ok. So existing WebKit behavior will add the cue again if
the application modified it. That is likely to be surprising
to the application developer. We definitely need clarification
on what the proper behavior should be in the spec.</div>
<div>Does this behavior take into account cues added by the
application itself. For example if the application uses <a
moz-do-not-send="true"
href="http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#addcue%28cue%29"
class="cremed">addCue</a>() with data that is identical to
something in the in-band track, will 2 cues get displayed or
only the one? It sounds like it would only be 1 which also
might be surprising to the developer.</div>
</blockquote>
In the case of WebKit, we should probably make the duplicate
detection ignore cues added via addCue(), and check if the new cue
matches the original content of a cue, not the current content. I
think that would fix both of these.<br>
<br>
</blockquote>
I created two WebKit bugs for this, since the current behaviour
seems to be broken in these cases:<br>
<br>
<a class="moz-txt-link-freetext" href="https://bugs.webkit.org/show_bug.cgi?id=127134">https://bugs.webkit.org/show_bug.cgi?id=127134</a><br>
<a class="moz-txt-link-freetext" href="https://bugs.webkit.org/show_bug.cgi?id=127133">https://bugs.webkit.org/show_bug.cgi?id=127133</a><br>
<br>
I'm willing to alter or remove these bugs if the consensus is that
we want to do it another way though.<br>
</body>
</html>
--------------010305030606050603010808--
Received on Thursday, 16 January 2014 20:40:24 UTC