On Mar 7, 2013, at 7:19 PM, Glenn Maynard wrote:
> Chrome, at least, throws on new Blob([], {type: "漢字"}), as well as
> lowercasing the string.
>
Stricter rules are in place for "type" both while constructing Blob and for
slice calls:
http://dev.w3.org/2006/webapi/FileAPI/#constructorBlob
and
http://dev.w3.org/2006/webapi/FileAPI/#slide-method-algo
I agree with previous comments you've made about ByteString not solving any
problems that Anne vK brings up; instead, I think using DOMString is probably
ok, with tighter rules on what is valid and what should be ignored. Throwing a
SyntaxError might be overkill to developers and a bit too punitive; instead, I
advocate sticking with the original spirit of the opaque string idea and
ignoring bad use of "type."
> A couple points:
>
> - I disagree that we should discourage comparing against Blob.type, but
> ultimately it's such an obvious use of the property, people will do it
> whether it's encouraged or not. I'd never give it a second thought, since
> that appears to be its very purpose. Web APIs should be designed defensively
> around how people will actually use the API, not how we wish they would.
> Unless lots of Blob.type parameters actually include parameters, code will
> break unexpectedly when it ends up encountering one.
> - The RFC defines a protocol ("Content-Type"), not a JavaScript API, and a
> good protocols are rarely good APIs. Having Blob.type be the literal value
> of a Content-Type header isn't an elegant API. You shouldn't need to do
> parsing of a string value to extract "text/plain", and you shouldn't have to
> do serialization to get "text/plain; charset=UTF-8".
>
So the "type" attribute of a Blob object isn't the *literal* value of the
header; it's the type of the Blob, expressed as a MIME type. When
dereferencing Blob URLs, you get this type back with the Content-Type header,
as you do normally in HTTP scenarios. This is a well-understood behavior, and
I agree with points you've made about not being beholden to the RFC when
designing an API.
I think the question here is whether or not to include *separate attributes* on
the Blob interface for the rarely used Charset Parameter, namely anything after
the semicolon in MIME types of the sort: "text/plain;charset=UTF-8". I've
considered all your arguments by way of developer advocacy, and actually think
we'll do developers a disservice by adding to the Blob interface:
1. The Charset Parameter consideration applies only to text/plain. There are
numerous other MIME types that don't use it: application/*, audio/*, image/*,
video/*, etc. Complicating the interface on the off-chance that a stray use of
the Charset parameter breaks a direct equality comparison is "too much API for
too little."
2. The Charset Parameter even in the context of text/plain isn't common enough
to warrant a special case for text/plain within the API.
3. In general, it's a pretty stable assumption to conclude that developers will
expect "type" to be surfaced later along with "Content-Type" when dereferencing
a Blob URI. I don't think we've made an assumption that's terribly galling.
-- A*
