Re: <link> vs. <script> for external scripts

> [Original Message]
> From: Lachlan Hunt <lhunt07@postoffice.csu.edu.au>
>
> Ernest Cline wrote:
>
> >...I think we need to redefine how the script element is defined for
XHTML2.
> >...It needs a different attribute than type to indicate the MIME type of
the contents for the element.
> ><script datatype="text/javascript" type="image/gif" src="flashing_logo">
> >  // And here goes a script that if the UA doesn't support animated GIFs
> >  // would try to replicated the effect via scripting.
> ></script>
> >
>   A datatype generally refers to what type a variable, or function is 
> (eg. String, int, etc...) in programming, not what language is being 
> used.  We could bring back that old language attribute that was, 
> strangely, both introduced and deprecated in HTML 4. 

Well the name of the attribute is relatively unimportant, but to
avoid potential confusion, I don't think it should be given
the name language.  I don't think datatype would be confusing
in this context, but apparently you do. Let me throw out some
alternatives for people to consider. 
1) contenttype : I don't think anyone can say that this name
   would be unclear, but it is rather long.
2) stype: Nice and short, but not very memorable.
3) scripttype: shorter than #1, but just as clear.  However,
   unlike the first two, we'd have to use a different name,
   probably styletype for the equivalent attribute in the style
   element.

> 4. If the UA does not recognise the type specified by @language as a 
> *known scripting language*, then the UA (must/should)? render the 
> contents of the <noscript> element.  If <noscript> is not specified, then 
> the <script> just ignored.
>
> eg. if an author writes:
> <script language="text/unknown-script">
>     alert("This is JavaScript");
>     <noscript><p>Some useful content here</p></noscript>
> </script>
> Then, a UA should render the contents of the <noscript> element.
>
>   However, this raises the question of how strict the @language should 
> be.  If the browser actually recognises the script above as JavaScript 
> then should the browser still run the script, even though the language 
> was specified wrongly?

Absolutely not!

This could potentially raise nasty problems (even tho they are likely
to remain only theoretical.)

Imagining if you will, two scripting languages, Scriptease, and
BaliScript.

An author with no knowledge of BaliScript writes a script in Scriptease
that by chance happens to parse also as BaliScript, but will have
a different effect there.

Now suppose a user agent that only understands BaliScript
loads the page that contains that script element.
Do we really want it to assume that when the author indicated
contenttype="text/x-scriptease" he really meant
contenttype="text/x-baliscript"?  I think not.

>   Perhaps it should be similar to @type: If the UA has been advised of a 
> script type that it does not understand, then it should not bother 
> attempting to execute the script, and always use the fallback mechanism.

Absolutely

>   Another question this raises is, if @language is NOT specified, but 
> @type is, and there is no external resource, but there is internal 
> content (ie. just like current HTML4 to XHTML 1.1 scripts), should the 
> @type be substituted for the @language?
> eg.
> <script type="text/javascript">
>     // some JavaScript
> </script>

Well since the attribute that specifies the scripting language of the
script should be required, then if that attribute isn't there, it wouldn't
be valid XHTML2, so it wouldn't be rendered, end of story.

> >It has some other advantages besides allowing generic embedding.
> >Since type is not a required attribute in general, but needs to be
> >for script (and for style as well) so using a separate attribute seems
> >preferable, especially if type allows for multiple types to be indicated.
> 
> Agreed!
>
>   While looking at the script and noscript elements, I noticed some 
> other problems with them.  The current draft (2003-05-06) states that:
>
> "When this module is used, the script and noscript elements are added to 
> the Block and Inline content sets of the Block and Inline Text Modules..."
>   Also, the content model for noscript is: (Heading | List | Block)+
>
> Since <noscript> is added to the Inline content model, then it makes the 
> following valid:
> <span>some text <script 
> language="text/javascript">document.write("something");
>   <noscript><h>Heading</h></noscript> 
> more text</span>
>   Is there a way to specify that when script and noscript are used 
> within Inline elements, the content model is only (Inline)+, but when 
> used within Block elements, the content model is (Heading | List | 
> Block)+ using Schemas?  I know it can't be done with DTDs.

Two points.
1) using document.write doesn't work in XML.  You need to
manipulate the DOM directly in order to include content.

2) The problem is that it is possible to indicate with an SGML
DTD that an inline element can only have inline elements as
descendents, while it is not possible with an XML DTD.
(This same problem affects the <a> element, which has in
HTML a DTD restriction against nested links, while XHTML1
can only say SHOULD NOT to authors against doing so.
I don't know enough about XML Schemas to say whether
it is possible to do so in those.

Perhaps XHTML2 should switch to using five elements:
<script> which gets added to the content model of the
   <head> element and has as its MCM: (PCDATA|script)* ,
<blockscript> which gets added to the Block content set
   and has as its MCM: (PCDATA|blockscript|blocknoscript)* ,
<inlinescript> which gets added to the Inline content set
   and has as its MCM: (PCDATA|inlinescript|inlinenoscript)* ,
<blocknoscript> which gets added to the Block content set
   and has as its MCM: (PCDATA | Flow)* ,
and last but not least:
<inlinenoscript> which gets added to the Inline content set
  and has as its MCM: (PCDATA|Inline)* .

that certainly would give full support to the different content
models expected of  Head, Block, and Inline elements,
but there might be a simpler way of doing it.

Question: Should XHTML 2 let a <noscript> element 
located either directly in the head, or inside a <script>
element located in the head be able to include other
head content such as <link> or <style>?  (To make this
work it probably would be necessary to define in the
Structure Module, a Head content set which the modules
that add to the content model of the <head> element would
add to instead of <head>.  Assuming the five element scheme
given above, this would change
  the MCM of <head> to: title&(Head*) ,
  the MCM of <script> would be:(PCDATA|script|noscript)* ,
  and the MCM of <noscript> would be Head* .

Received on Wednesday, 19 November 2003 21:04:32 UTC