Re: contentScriptType and type on script elements

Dudes,

Did we decided whether to errata some of the issues pointed out in this 
thread? I'm not entirely sure if this was resolved?

Thanks,

Anthony

Erik Dahlström wrote:
> On Thu, 10 Jan 2008 22:31:52 +0100, Chris Lilley <chris@w3.org> 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] http://www.w3.org/TR/SVG11/script.html#ScriptElement
>> ED> [2] http://www.w3.org/TR/SVGMobile12/script.html#ScriptElement
>>
>> 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="http://www.w3.org/2000/svg"><foo
>> ED> xmlns="http://foobar.com/baz"><script id="s1"
>> ED> xmlns="http://www.w3.org/2000/svg"> 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 Tuesday, 15 January 2008 03:56:07 UTC