RE: [Bug 22329] New: [MSE] TextTrack attributes settable in conflict with the html spec

You made this comment on a bug for MSE will is NOT EME!

Please desist from making such non-technical comments on public-html-media@w3.org<mailto:public-html-media@w3.org>.  This is NOT the forum for such discussion.

/paulc
HTML WG co-chair

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329

From: Wayne Borean [mailto:wborean@gmail.com]
Sent: Tuesday, June 11, 2013 7:20 PM
To: public-html-media@w3.org
Cc: public-html-media@w3.org
Subject: Re: [Bug 22329] New: [MSE] TextTrack attributes settable in conflict with the html spec


Hmm. You do realize that EME is not compatible with the WIPO Internet Treaties?

While a private firm like Microsoft or Apple could (and do) build software which isn't WIPO-1995 compliant, making a Web Standard that isn't WIPO-1995 compliant would be a huge mistake.

Wayne


On Tue, Jun 11, 2013 at 7:02 PM, <bugzilla@jessica.w3.org<mailto:bugzilla@jessica.w3..org>> wrote:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22329

            Bug ID: 22329
           Summary: [MSE] TextTrack attributes settable in conflict with
                    the html spec
    Classification: Unclassified
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Media Source Extensions
          Assignee: adrianba@microsoft.com<mailto:adrianba@microsoft.com>
          Reporter: giles@mozilla.com<mailto:giles@mozilla.com>
        QA Contact: public-html-bugzilla@w3.org<mailto:public-html-bugzilla@w3.org>
                CC: mike@w3.org<mailto:mike@w3.org>, public-html-media@w3.org<mailto:public-html-media@w3.org>

"partial interface TextTrack {
  attribute DOMString kind;
  attribute DOMString language;
}"

The TextTrack interface in the html spec has readonly attributes of the same
name. I think the idea is to use specific constructors as the only way to pass
these in, or have them created by the parser for in-band text tracks and
<track> elements.

Do we need this interface? If it's muxed with the parent media element's source
stream, the in-band text track support should cover it, and if it's external,
the media.AddTextTrack and TextTrack.addCue methods should be sufficient to
implement dynamic subtitles with minimal complexity.

--
You are receiving this mail because:
You are on the CC list for the bug.