Re: The interpretation of script

On Tue, 18 Jan 2011 17:39:24 +0100, Kurt Cagle <kurt.cagle@gmail.com>  
wrote:
> 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).

If it is inside JavaScript it is not a new scripting language.


> 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.

I agree that we have to take legacy into account, but HTML5 has very much  
been designed with the future in mind. Defining error handling and such is  
a strategy borrowed from CSS, which they call forward-compatible parsing  
rules. We definitely try to look forward, I think we just have a different  
vision of where things are going.


> 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.

Why should we introduce that now and not when we are adding this new  
scripting language? To me it makes much more sense to do it at that point  
as then we know the constraints and use cases much more thoroughly. Doing  
something like that now compared to a decade from now does not have much  
practical benefit either way.


> [...]
>
> (One last point - a procedural one: HTML5 is in last call.

HTML5 is not yet in Last Call. The WHATWG issued a Last Call and later  
superseded it with it being an "eternal" updated document, a Living  
Standard.


> 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.)

It should always be appropriate to raise tough or uncomfortable questions  
in my opinion. No need to have restrictions on that!


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Tuesday, 18 January 2011 17:02:30 UTC