- From: Philip Jägenstedt <philipj@opera.com>
- Date: Fri, 20 Sep 2013 09:49:22 +0200
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Glenn Adams <glenn@skynav.com>, Simon Pieters <simonp@opera.com>, Brendan Long <self@brendanlong.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>, Eric Carlson <eric.carlson@apple.com>
On Fri, Sep 20, 2013 at 5:21 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > On Thu, Sep 19, 2013 at 12:11 AM, Philip Jägenstedt <philipj@opera.com> wrote: >> Hmm, this makes we wonder what the property for accessing the data is >> supposed to be. If it's a string, then it requires that the UA at >> least know what the encoding of the text is, which seems like it might >> not be true. RawCue and exposing the data as a typed array .data >> property seems OK to me. The other option is to base64-encode cues >> which are of an unknown encoding, I guess? > > ArrayBuffer .data works for me. > Should we keep .text as well, because converting from ArrayBuffer to > String can be inefficient, see > http://updates.html5rocks.com/2012/06/How-to-convert-ArrayBuffer-to-and-from-String > ? What would the text property contain when the browser doesn't know the encoding? I think it's probably simplest to only expose a single ArrayBuffer property, and add convenience properties only as the need becomes apparent. > Also, I am not fussed about the naming - RawCue works for me just like > UnparsedCue. To throw in another, I'd consider DataCue with a data property, because it simply says what it is, not implying that it's always the the unparsed/raw form of something else which the browser could support if it wanted to. Philip
Received on Friday, 20 September 2013 07:49:50 UTC