Jim said:
Jim said:
If you don't declare javascript through the meta tag, do you declare it
anywhere
No I don't.... It's potentially wrong, but then there's no registered
mime-type for javascript, [...snip...]
Which is not the same thing as saying there is *no* mime-type for
javascript. There is, and by common usage, the consensus seems to be
"text/javascript". A number of mime-types were in widespread use before
becoming officially registered and recoginzed in an RFC, among them
"text/css".
but that's wrong, and it's a lot more wrong than ignoring HTML
recomendations IMHO, so when it doesn't matter, I'm certainly not
going to promote the breaking of the mime-registration mechanism.
I simply disagree that this is wrong. The construct "text/javascript" is
perfectly consistent with the standard way of forming media-type names,
does not conflict with any existing usage, and does not break anything.
It is in use (and recommended) by many members of the internet community.
The argument seems to be: "text/javascript" is not an
officially-recognized mime-type, so don't use it. I think having an
officially recognized javascript mime-type is desirable; but lacking
this, I'm willing to accept an informal de facto mime-type that is
formed consistently with recognized usage. I believe our failure to use
"text/javascript" works against eventual adoption of this as a standard.
True, using a type not formally recognized by the IETF carries some
degree of risk. "text/javascript" could be registered to relate to some
content-type that is not javascript, and this *would* break a bunch of
things. But this is even less likely than eventually obtaining official
recognition for its current meaning and usage.
Yes; I reviewed both these documents before my last post. In the case of
the latter, I wanted to be sure that "text/javascript" still had not
made the official list. In the case of the former, I wanted to make sure
my memory was correct about "text/css" being a mime-type in general
usage well before becoming recognized in an RFC. The "Abstract"
paragraph of 2318 clearly states this. The case of "text/javascript" is
no less worthy than "text/css". Why, then, expect "text/javascript" to
achieve RFC recognition before using it?
This isn't the question unfortunately, the question is which standard
do we choose to ignore, Internet RFC's or W3 recommendations, I choose
to ignore the recommendations.
Good clarification.
I guess I would follow W3C recommendations and behave in a way that is
also consistent with current RFC practice, even though that behavior is
not (yet!) officially blessed by the IETF. Practice often precedes
formalization.
The mark-up I create aims to be valid in SGML terms, if it's not, it's
a **** up, not a decision, however badly specified meta hacks for
specifying a script type which requires me to use mime-types I
shouldn't.
I fully agree with this, the type attribute is the only one required,
you shouldn't use language, what I choose not to use is the meta
content-script-type, for various reasons.
This may be the crux issue--the meta-script-specifying mechanism. No
argument that some specs are "badly specified", making difficult choices
necessary. And this meta-script-specifying mechanism may be one. And
maybe this particular construct *should* be ignored -- but because it's
a poor specification, not because it requires "text/javascript". To
reiterate, there's plenty of precedent for usage-prior-to-formalization.
You'll be lucky!
Well, things have changed a lot since Steve Crocker issued RFC 1, when
this really was a "request-for-comment" rather a
"pontification-from-on-high". There seems to be much more politics
involved now, not to mention more people/companies/special-interests
involved. RFC 2318 had Bos & Lie (primary authors of css) and the W3C
behind it. We've not had such heavy-weight support for "text/javascript"
as yet. Doesn't look like the ECMA is particularly behind an effort to
formalize this. About a year or year-and-a-half ago (I'm sure you know)
there was an internet-draft posted, but it expired without action by
IETF. This draft was posted by an individual rather than by an IETF
working-group or an organization such as ECMA. And there are HUNDREDS of
individual-posted drafts at any given time. Most seem to expire without
action. I haven't noticed that this javascript draft was ever
resubmitted, even though its author had indicated an interest in
resubmission.
Yes, we may be lucky, but it's not an impossible mountain to climb. In
the mean time, encourage rather than discourage using "text/javascript".
Eventually, widespread common usage carries weight in adoption of standards.
Regards,
Stephen