- From: <bugzilla@jessica.w3.org>
- Date: Thu, 17 Apr 2014 17:38:27 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25354 --- Comment #10 from Eric Carlson <eric.carlson@apple.com> --- (In reply to Aaron Colwell from comment #9) > (In reply to Eric Carlson from comment #8) > > (In reply to Aaron Colwell from comment #7) > > > Do we actually need .data AND .value? Couldn't we just represent this as > > > something like .type = "unknown" (or "application/octet-stream" or "") and > > > .value = an ArrayBuffer() w/ the data? It seems like that would be better > > > than having everything optional. > > > > > That was our original idea, but when we presented it at the F2F last week > > Maciej pointed out that that would make it difficult for a UA to return a > > typed value for a key after shipping a version where it returned it as an > > ArrayBuffer. > > I guess I was under the assumption that .type would be different for the raw > unparsed vs parsed. Is the idea that it is better to roll out a single .type > that a UA can potentially backfill .value in a later revision instead of not > outputting a .type until the UA can support a parsed .value? .type identifies the .key namespace. It should not change depending on whether or not the UA is able to parse the cue value. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 17 April 2014 17:38:35 UTC