W3C home > Mailing lists > Public > public-html@w3.org > May 2008

Re: Rewording Algorithms and Script Types

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 14 May 2008 07:23:01 +0000 (UTC)
To: Jim Jewett <jimjjewett@gmail.com>, Smylers <Smylers@stripey.com>
Cc: public-html@w3.org
Message-ID: <Pine.LNX.4.62.0805140702290.12911@hixie.dreamhostps.com>

On Tue, 7 Aug 2007, Jim Jewett wrote:
> 
> A few months ago, my main impression of the algorithms was that they 
> were needlessly complex; it wasn't until this weekend that I figured out 
> why.
> 
> Some of them are phrased to avoid an early exit.

The algorithms are by and large phrased to be direct representations of 
how I think of what should happen. I guess sometimes I think of it as a 
process with a single end, and sometimes I think of it as a search for an 
answer, and that probably decides which model the algorithm ends up 
looking like. If you think better in terms of early exit, then the former 
will end up making less sense; if you think better in terms of the latter 
model, then the latter will make more sense.


> This is useful in programming languages when you need to clean up, but 
> is more difficult for humans to understand.  (~10 years ago, the most 
> accessible literature was in linguistics, and dealt with 
> center-embedding.)
> 
> To make this more concrete, the wording for the optgroup namedItem 
> method is good; the end of each step is effectively either "stop, you're 
> done", or "forget this step; it didn't work; go to the next."
> 
> http://www.whatwg.org/specs/web-apps/current-work/#nameditem1
> 
> In contrast, the method for determining a script's type seems to read backwards:
> 
> http://www.whatwg.org/specs/web-apps/current-work/#running0
> 
> The only way I could understand it was to reword it mentally, and then
> it looked incomplete.  I would reword it to similarly to whichever of
> the following is intended:
> 
> If the script element has a type attribute, this determines the Script's Type.
>     If the type attribute's value is the empty string, then the
> Script's Type is "text/javascript".
>     Otherwise, the Script's Type is the value of the type attribute.
> 
> Otherwise, if the script element has a language attribute, this will
> determine the Script's Type.
>     If the value is the empty string, then the Script's Type is
> "text/javascript".
>     Otherwise, the Script's Type is "text/" + the value of the
> language attribute.
> 
> Otherwise (if the script has neither a type attribute nor a language attribute):
>     ?  Assume "text/javascript" or raise an Error?

Hm, yeah, that algorithm has a hole. Fixed.

However, I don't think the phrasing you have of it above is any better 
than what the spec has. In particular, I really don't like the duplication 
of the default value in three places.

I don't understand what you mean by "reading backwards".


On Tue, 7 Aug 2007, Smylers wrote:
> 
>   Let <var>type</var> be "text/javascript".
> 
>   If the script element has a type attribute whose value is not the
>   empty string then let <var>type</var> be the value of that attribute.
> 
>   Otherwise, if the script elment has no type attribute (not even one
>   whose value is the empty string) but does have a language attribute
>   whose value is not the empty string then let <var>type</var> be the
>   concatenation of the string "text/" and the value of the language
>   attribute.
> 
>   Let the script's type for this script element be <var>type</var>.

I don't really see that as being any better. Now you've introduced a 
temporary, which is just as taxing when reading the spec.


> Further, the context of this algorithm suggests it's only necessary for 
> user-agent implementers to read it, not authors (which I think would be 
> a good think -- authors wanting to write valid HTML5 don't need to be 
> aware of things like the language attribute, only included for backwards 
> compatibility).  But outside the algorithm type is merely defined as:
> 
>   The language of the script may be given by the type attribute. If the
>   attribute is present, its value must be a valid MIME type, optionally
>   with parameters. [RFC2046]
> 
> So an author knows that it is valid to omit type, but not what that
> signifies.  It would be good to make this explicit without requiring
> working through the algorithm, for example by replacing the above with:
> 
>   The language of the script may be given by the type attribute, which
>   specifies a MIME type.  The default language is ECMAScript [with a
>   link to the 'Scripting languages' subsection].  For a script written
>   in any other language its MIME type must be specified with the type
>   attribute.

Added notes.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 14 May 2008 07:23:43 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:55 UTC