This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It is unclear what the type of new Blob([], { type: "TEXT/HTML" }) or new Blob().slice(0, 0, "TEXT/HTML"); should be ('text/html' or 'TEXT/HTML'). (Firefox has 'TEXT/HTML' twice; Chrome has 'text/html' for the former and 'TEXT/HTML' for the latter.)
Opera also has TEXT/HTML twice.
I think it might be useful to spec. this to be lower case.
In the spec., I defer to RFC2616, asking the parser to parse it in accordance with the definition of type and subtype tokens. RFC2616 says: The type, subtype, and parameter attribute names are case-insensitive. Parameter values might or might not be case-sensitive, depending on the semantics of the parameter name. Thus, TEXT/HTML is equivalent to text/html. This isn't a bug, but an implementation quirk. I don't think we need further spec. guidance on this issue. In fact, I think it places an emphasis on authors to coin the type string with some diligence. Authors get back what they ask for. Marking invalid.
Step 5.2 of the Blob constructor algorithm is > Convert every character in s to lower case. There's something similar for slice().
This is a good catch. I think this should be removed. Thoughts?
Like in Bug 18529, I am wondering whether we should forgo parsing for validity altogether. The prevailing school of thought is that browsers should just treat "type" as an opaque string.
We've decided to treat type as an opaque string. Implementations don't throw; browser developers are reluctant to throw, and thus validation against the RFC is not useful.