L. David Baron wrote:
I don't see why the same attribute _shouldn't_ be used to determine the
type of data to allow, and whether to do spell checking or not. After all,
whether to spell-check is directly related to what kind of data it is.
This sounds a lot like <object>, which allowed for tons of features but
didn't specify them precisely. Are you planning to specify exactly what
the semantics of every MIME type are for all of these features? And any
others people might want? And are there really MIME types that
accurately represent the semantics of all the combinations of even just
the 4 features you list above that authors will want? If every
combination needs a name, what if people want to toggle six different
things?
I don't think anyone was planning to specify "textarea elements with
accept='text/plain' should enable a UA spellcheck feature, if present".
At least, I very much hope not. Rather, UAs would be expected to make
intelligent decisions about their capabilities for different types of
content - in the same way that most offline text editors use different
editing features based on the file extension of the content that they
are using. This is why, in the Mozilla bug, I am nervous about
specifying only text/plain as the MIME type that supports spellchecking
since many uses of <textarea> actually accept a limited subset of
text/html, and I don't believe these <textarea>s should have their
accept attribute set as text/plain just to ensure that spellchecking works.
