Issue: referencing text/ecmascript in the spec is wrong.

Hi,

I mentioned this issue back in june as part of another thread *, and I'm
concerned it's been missed, so I'm reposting with more information.

In http://www.w3.org/TR/SVG11/script.html

| The contentScriptType attribute on the 'svg' element
| specifies the default scripting language for the given
| document fragment.

| contentScriptType = "content-type"
| Identifies the default scripting language for the given document.
| This attribute sets the scripting language used to process the value
| strings in event attributes. The value content-type specifies a media
| type, per [RFC2045]. The default value is "text/ecmascript".

My concern is with the default value, text/ecmascript is not a registered
mime-type, and a draft from
Bjoern Hoehrmann
http://www.websitedev.de/ietf/draft-hoehrmann-script-types-00.txt met
with some resistance and has expired indicating that text/ecmascript is
unlikely to ever be a registered mime-type.

HTML 4.01 uses the similar Content-Script-Type in META http-equiv element
or in the http header (see
http://www.w3.org/TR/REC-html40/interact/scripts.html#default-script )
This has no default value, indeed it says "Documents that do not specify
default scripting language information and that contain elements that
specify an intrinsic event script are incorrect."

I propose (to resolve the issue I have) that to avoid recommending a
default of an unregistered mime-type the contentScriptType attribute is
brought into line with the HTML behaviour, namely any document which
doesn't specify a default script type is incorrect although "User agents
may still attempt to interpret incorrectly specified scripts but are not
required to."  Making the actual attribute REQUIRED isn't necessary as
there may not be any events specified to require a script type.

Alternatively a default of "application/x-javascript" (reflecting the
current behaviour of UA's with Mozilla, Batik and ASV all using
JavaScript.) would be acceptable if there are reasons why a default is
required that I'm not aware of.

This change would still be compatible with existing SVG 1.0 viewers as
they can be doing the error recovery suggested, but not mandated I cited
above.

Jim.

* http://lists.w3.org/Archives/Public/www-svg/2002Jun/0062.html

Received on Friday, 9 August 2002 09:20:24 UTC