W3C home > Mailing lists > Public > public-html@w3.org > July 2012

: ISSUE-194

From: Sunyang (Eric) <eric.sun@huawei.com>
Date: Fri, 6 Jul 2012 07:36:33 +0000
To: Maciej Stachowiak <mjs@apple.com>, "Edward O'Connor" <eoconnor@apple.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
CC: "public-html@w3.org" <public-html@w3.org>
Message-ID: <9254B5E6361B1648AFC00BA447E6E8C32AEB7112@szxeml545-mbx.china.huawei.com>


Yang
Huawei


> -----ʼԭ-----
> : Maciej Stachowiak [mailto:mjs@apple.com]
> ʱ: 2012630 7:50
> ռ: Edward O'Connor; Silvia Pfeiffer
> : public-html@w3.org
> : Re: ISSUE-194
> 
> 
> Hi Ted & Silvia,
> 
> It seems to me that the two transcript attribute proposals are now much
> closer than our original starting point. They are intended to meet the same
> requirements and satisfy the same use cases, and have pretty similar syntax
> and usage.
> 
> Currently the proposals at
> <http://www.w3.org/html/wg/wiki/ChangeProposal/ISSUE-194/TranscriptU

> RL> and <http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-194-2B>
> both propose a transcript attribute, one taking a URL, and the other taking a
> list of element IDs. However, neither provides direct rationale for why its
> form of the transcript attribute is different from the others. They focus more
> on why transcript support is useful at all, and on comparing to proposals no
> longer on the table.
> 
> I think it would improve both proposals if they gave rationale for why their
> form of the transcript attribute is better than the other.

[yang] +1. 
     From now, option 2 is better for compatibility with browser not supporting <video> element.
     Option 3 is better for simple and easy for understanding. From me, I prefer option 3, since video element has already been 
     Widely supported by main browser vendors. 

> 
> It would be even better if we could reach consensus, given how close the
> two proposals now are, but I recognize that at some point we need to move
> on and make a decision if we do not have consensus.

[yang] we may converge the 2 proposals into 1, each as a alternative for transcript, and browser vendor can choose which for implementation, but this will bring gap between browser. So I think we have to decide between "defer it to html.next" and "do it in html5", then select one option, this has more meaning.....
> 
> Regards,
> Maciej
> 
> 
> 
> On Jun 29, 2012, at 3:07 PM, Edward O'Connor <eoconnor@apple.com>
> wrote:
> 
> > Hi all,
> >
> > Eric Carlson, John Foliot, Silvia Pfeiffer and I had a call today in
> > which we attempted to resolve the remaining differences between our
> > ISSUE-194 proposals. Unfortunately, we were unable to come to a
> > consensus position. Given this, I will keep both of the following Change
> > Proposals on the table for an eventual poll on ISSUE-194:
> >
> >  Defer ISSUE-194 until HTML.next
> >    http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-194-6

> >
> >  Mint a transcript attribute for the programmatic association of
> >  transcripts with media elements
> >    http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-194-2B

> >
> >
> > Thanks,
> > Ted
> >
> 

Received on Friday, 6 July 2012 07:38:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:33 UTC