W3C home > Mailing lists > Public > www-svg@w3.org > January 2008

Re: contentScriptType and type on script elements

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Tue, 15 Jan 2008 14:55:41 +1100
Message-ID: <478C2EBD.4050002@cisra.canon.com.au>
To: Erik Dahlström <ed@opera.com>
CC: Chris Lilley <chris@w3.org>, "www-svg@w3.org" <www-svg@w3.org>


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



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

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:12 UTC