- From: <bugzilla@jessica.w3.org>
- Date: Wed, 16 Apr 2014 17:28:54 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25353 --- Comment #5 from Glenn Adams <glenn@skynav.com> --- (In reply to Aaron Colwell from comment #4) > I thought DataCue > was only intended for things the UA doesn't know how to parse which is why I > feel like the .value property is a little strange. Not exactly. It is intended to be used for @kind metadata tracks, which imply the UA doesn't know how to process (e.g., render) the content. At a minimum, the UA will need to parse the container sufficiently to extract a data cue's content (payload), but it may or may not be able to parse that payload. One basic type of parsing a UA may provide on that payload, if it can determine the payload is an encoded string (text), is to decode the payload bytes into a string, which was the original intention of the DOMString text attribute. But that doesn't imply the UA knows enough about that string to further parse it into a structure, e.g., if is plain text, xml text, json text, etc. My understanding of Ted's ask is that it should be possible for a UA that does know how to parse the cue's payload into something other than a string to expose the result of that parsing to the APP, without forcing every APP to perform the same decoding on the APP side of the fence. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 16 April 2014 17:28:57 UTC