Julian Reschke writes: > If there's nothing wrong with the recommendation to use > application/ecmascript as Content-Type (in the HTTP message), then > HTML5 should just conform to that. > > The situation for script/@type is different when the script is > in-line; ... I have no problem for this case being handled > differently; but if it is, I wouldn't consider it a "willful > violation" of that RFC. That would lead HTML 5 recommending different media types for JavaScript in different places -- something which places a cognitive load on authors to remember which goes where, and which could lead to scripts not working in some browsers if confused (the latter being undetected by an author using a browser which does interpret application/ecmascript). The alternative of recommending a single media type for all JavaScript would seem simpler for all concerned, and with no real-world disadvantage. > That being said: HTML5 defines a lot of things that won't work in some > or all of the existing browsers, so how exactly is this situation > different? It would be changing something which currently works. Adding a new feature inevitably means previous browsers won't have that feature. Whereas keeping an existing feature but changing the syntax is gratuitous: new browsers get no gain in functionality, so there is no advantage, yet older browsers are cut out. SmylersReceived on Thursday, 2 April 2009 10:52:59 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:40:29 GMT