Re: The interpretation of script

>
> They are tied to ECMAScript. There was once a theoretical http-equiv
> directive called Content-Script-Type, but that got never implemented in any
> meaningful way. Browsers do not support Python or PHP (at least not exposed
> to the web) so this is not a problem I think.
>
> If we ever want to introduce a new scripting language to the web then is
> probably the right time to answer these questions. Trying to anticipate
> everything now is not really feasible I think.
>

Not to argue this point too strenuously, but I think the time is fast
approaching. One JavaScript reaches a level of performance where it can in
fact be used as a virtual machine, it will be. XQuery is the most obvious
one to me in that regard because of XQIB but I know there are similar
efforts at developing a JavaScript shim for Python underway now (something I
believe would have immediate appeal to Google, given the level of in-house
python development they do).

I realize that there is a certain degree of "capture the past" behavior with
HTML5 - that you are trying to encode in the browser a consensus view of the
technologies that have been become a major part of the web outside of the
scope of HTML4 - but this may be a case where a little proactive
future-proofing may pay off big dividends within the next year as these
"hosted" languages begin to come on line in a big way. A minor amendment,
even to the the extent of adding a <meta> tag that indicates the default
language for inline scripting attributes (and perhaps script blocks) would
make such a transition go fairly cleanly. If the browser doesn't support the
language in question, then it would raise an error during execution, exactly
as you would expect.

I understand the reluctance to go down a path different from JavaScript -
balkanization was a major bane of the web during its formative years
(vbscript comes to mind). However, the difference here is that JavaScript
MUST be supported out of the box and must be uniform enough to allow the
development of such VMs, two conditions that I think are close to being
fulfilled today. It then becomes the responsibility not of the browser
vendor but the language vendor to supply the relevant script content, and it
becomes the responsibility of the web developer to choose to incorporate the
relevant bindings for that language.

I'm bringing this up because this issue seems very much relevant to the
interpretation of content as script vs. data, as it becomes a question about
the interpretation of <script> elements that aren't within the JavaScript
domain. Given the state of Javascript VMs, I'd say it's certain that the
issue may very well surface even before HTML5 goes into a formal Rec status.

(One last point - a procedural one: HTML5 is in last call. From my
understanding, this is still a comment phase, but with the understanding
that the comments will not be processed beyond a certain date. There have
been comments on this list indicating that it is inappropriate for such
issues to be surfaced during Last Call, but I would in fact argue that this
is WHEN such arguments need to be surfaced - when the specification has been
rendered close to its final form and is now in a form that outside reviewers
can comment on with an understanding of the intent of the specification
itself. This is a form of wider peer review that every spec should go
through to insure that it is meeting the requirements of the larger
community, not just the drafting committee. Uncomfortable questions may be
asked, and it is the responsibility of the working group to effectively
defend their positions with regard to those issues. This may be apropos of
nothing, but I felt the point needed to be clarified.)

Kurt Cagle