Re: contentScriptType and type on script elements

Dudes,

I've been given two actions [ACTION-1796] [1] and [ACTION-1831] [2] 
regarding this, both are pretty much the same.

In summary the Tiny 1.2 specification [3] has been updated and the Full 
1.1 errata [4] has been aligned to match Tiny 1.2.

This closes both action items.

Please let me know if we have any feedback on this. I'll organise a 
review for the errata item soon.

Thanks,

Anthony

[1] http://www.w3.org/Graphics/SVG/Group/track/actions/1796
[2] http://www.w3.org/Graphics/SVG/Group/track/actions/1831
[3] 
http://www.w3.org/Graphics/SVG/Group/repository/spec/mobile/1.2/1.2NG/master/script.html
[4] 
http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xml#clarification_of_content_script_type_behavior

Anthony Grasso wrote:
> 
> Dudes,
> 
> 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.
> 
> Thanks,
> 
> Anthony
> 
> 
> [1] http://www.w3.org/2008/01/15-svg-minutes.html#item03
> [2] http://www.w3.org/Graphics/SVG/Group/track/actions/1796
> [3] 
> http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xml#clarification_of_content_script_type_behavior 
> 
> [4] http://www.w3.org/TR/SVG11/script.html#DefaultScriptingLanguage
> [5] 
> http://www.w3.org/Graphics/SVG/Group/repository/spec/mobile/1.2/1.2NG/master/struct.html#ContentScriptTypeAttribute 
> 
> 
> 
> 
> 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 Wednesday, 13 February 2008 05:39:50 UTC