- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 23 Mar 2011 11:22:30 +0200
On Tue, 2011-03-15 at 21:06 +0100, Hay (Husky) wrote: > 3) 'Data blocks' in a <script> element, as described in the spec. You > can, for example, use a <script> element with an 'application/xml' or > 'application/json' type, which will not be processed by a browser, and > use Javascript to do the parsing. > > Data blocks seem to be the current most usable solution, but i get the > feeling that it's not quite expressive enough. <script> tags should > contain scripts, and XML and JSON are not scripting languages. The spec disagrees with your "should". :-) Don't get too focused on the element names. > Something like a <data> tag, with a required 'type' attribute that can > contain a mime type that could indicate to browsers what type of > content follows might be an interesting solution, but i'm not sure > what the implications might be. It wouldn't be backwards compatible the way <script type=not/js> is. http://hsivonen.iki.fi/test/moz/xml-data-block.html works in the latest versions of all the top browsers, so there's really no point in introducing something new that doesn't work yet. > It would be cool if you do a <data > type="application/json"> and get an automatic Javascript object when > getting the element with document.getElementById. Since the data will be processed by a script anyway, it's quite reasonable to ask the script to trigger XML or JSON parsing instead of making it implicit. This way, there is no need to elevate XML or JSON to some kind of special status as far as the data container is concerned. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/
Received on Wednesday, 23 March 2011 02:22:30 UTC