Re: contentScriptType and type on script elements - Errata added [ACTION-1796]


As per the telcon Tue 15th Jan [1] I was given an action [1796] to Align 
1.1 with 1.2 tiny regarding contentScriptType behavior [2].

I've added an errata item to align 1.1 and 1.2 [3]. This item has been 
set to Category 3 - is this correct?

I believe Erik is writing a test case for this as well - this still 
needs to be added to the errata item.

Other thing to note - the errata wording for contentScriptType in Full 
1.1 [4] (section 18.1.1) no longer matches the wording for 
contentScriptType in Tiny 1.2 [5] (section 5.1.2). This is a bit 
contradictory to the action item, but this was a suggested change. 
Should we change the wording in Tiny 1.2 such that "document" is 
replaced with "SVG document fragment"?

The contentScriptType for Full 1.1 and Tiny 1.2 are both optional as far 
as I can tell. However, From the DTD in Full 1.1 the "type" attribute 
for the "script" element is "#REQUIRED". I'm guessing this is what Chris 
meant by it shouldn't be required?

I've added to the errata item a change to the DTD from "#REQUIRED" to 
"#IMPLIED" - I'm not sure if this is correct though.

Please let me know if you have any thoughts or feedback with regards to 
the item.




Erik Dahlström wrote:
> On Thu, 10 Jan 2008 22:31:52 +0100, Chris Lilley <> wrote:
>> On Tuesday, January 8, 2008, 3:54:27 PM, Erik wrote:
>> (Your mail is responded to in a differnet order than how you wrote it)
>> ED> Spec[1] says: "The contentScriptType attribute on the 'svg' element
>> ED> specifies the default scripting language for the given document 
>> fragment."
>> ED> which seems to be in conflict with "Identifies the default scripting
>> ED> language for the given document."
>> ED> [1]
>> ED> [2]
>> Its not in conflict. The wording in 1.2T is correct:
> Ok, maybe it only sounds ambigous to me. Document != document fragment no?
>> contentScriptType = "content-type"
>>     Identifies the default scripting language for the given document.
> I would like to see the above sentence changed so that "document" is 
> replaced by "svg document fragment". Or can svg introduce a new default 
> behaviour like this for e.g html:script elements contained in the svg 
> document fragment?
>>     This attribute sets the default scripting language for all the
>>     instances of script in the document fragment. This language must
>>     be used for all scripts that do not specify their own scripting
>>     language. The value content-type specifies a media type, per
>>     Multipurpose Internet Mail Extensions (MIME) PartTwo [RFC2046].
>>     The default value is "application/ecmascript".
>>     Animatable: no.
>> The wording in 1.1 differs in two details, firstly it assigns a
>> default of text/ecmascript to identify ECMAScript (while in practice
>> that language was subsequently registered as application/ecmascript)
>> and secondly the description fails to cover the case where there is
>> more than one SVG document fragment in the document.
> The first difference is not of great importance as you note, it will 
> essentially mean the same thing.
> The second difference is indeed resolved in 1.2T, and if possible I 
> would like to see an alignment with 1.2T in the 1.1 errata.
> ...
>> ED> Reading the SVG 1.1 and 1.2T specs on how 'type' works on 'script'
>> ED> elements leads me to a couple of questions:
>> ED> 1. Given the markup below should the script element with id="s1" run?
>> No, because there is no script element in the SVG document fragment
>> (either for 1.1 or 1.2T)
> Yes, because of the definitions of "svg document fragment" and "rootmost 
> svg element" it's more clear in 1.2T. However the spec doesn't mention 
> what is the behavior for such "orphaned" svg:script elements, if they 
> should run or not. If you have an html:script element in an svg document 
> fragment it does in fact execute (tested in FF3 and Opera 9). Perhaps it 
> makes sense to align with that?
>> ED> <svg contentScriptType="foo/bar"
>> ED> xmlns=""><foo
>> ED> xmlns=""><script id="s1"
>> ED> xmlns=""> alert('whee'); 
>> </script></foo></svg>
>> ED> The script element has to move across the unknown markup to get the
>> ED> default scripttype, and if it gets that it shouldn't be executed 
>> unless it
>> ED> understands "foo/bar". Otherwise, one could see it such that it 
>> defaults
>> ED> to "text/ecmascript" even though it lacks a direct 'svg' parent. The
>> ED> script is executed in ASV3, Safari 3, Firefox 3, Opera 9.x and 
>> Batik 1.7.
>> ED> I guess this can mean that either 'contentScriptType' is not 
>> supported, or
>> ED> that all viewers assume ecmascript always or that the namespace 
>> border
>> ED> isn't crossed and that it assumes that it is ecmascript.
>> Several of those reasons may be true; a simpler test will determine
>> whether contentScriptType and/or type are implemented. If they are
>> not, then the more complex test is not useful. if they both are
>> implemented, then your test demonstrates failure to conform to the
>> definition of an SVG document fragment.
> I'm fairly certain that 'contentScriptType' has not been implemented by 
> any svg viewer yet. I'll attach a simple testcase.
>> ED> The spec isn't
>> ED> very clear on how it should work, if you are allowed to cross 
>> namespace
>> ED> boundaries in search of an 'svg' parent element, or what happens 
>> if there
>> ED> is none (although it is a required attribute in 1.1 none of the 
>> viewers
>> ED> seemed to respect that).
>> That should be an erratum for 1.1 since it can't be both required and
>> also have a default value :)
> That seemed a bit odd yes :)
>> ED> 2. Does 'contentScriptType' work on document fragments or on 
>> documents?
>> Document fragments.
> Agreed.
>> ED> That is does nesting 'svg' elements mean that you use the 
>> innermost or
>> ED> outermost 'svg' element when getting 'contentScriptType'?
>> Innermost.
> Yes, that makes the most sense to me as well.
> Cheers
> /Erik

Received on Wednesday, 16 January 2008 04:06:48 UTC