I see data but do you CDATA?
For a technology so widely used HTML and family can throw up a lot of roadblocks in the way of progress. I've been working with javascript ('AJAX') with a view to improving the responsiveness of Citebase's web interface. An important requirement is to maintain a 'single-page-interface' but to allow differing analyses and links to be loaded into that page through a menu-like mechanism: ordinarily I'm a fan of keeping-it-simple, which in this case would mean as many different pages as there are functions, but I suspect most users would get lost in the myriad of page reloads.
One javascript library (the J in AJAX) suggested to me by a colleague was 'DOJO' ( http://www.dojotoolkit.org/), which provides a lot of javascript-based widgets that turn your web page into something more akin to a windows GUI. But, and you'll notice this if you go to that page, it breaks the forward/backward browser history navigation. In which case we're somewhere closer to the entire-web-page in a Macromedia flash file than I'm comfortable with. (I dislike flash-based things because it prevents me using the neat tools that Firefox otherwise provides, like forward/backward navigation on my 5-button mouse, keyboard scrolling/searching/link selection etc.)
After several days trying different techniques I've ended up back where technology was several years ago: the iframe. Coupled with a bit of javascript to make interactive menus (so we don't have to go to the server to get more options) iframes keep the forward/backward navigation working and can be automatically stretched by javascript so as to fit the content i.e. no scrollbars floating around the middle of a page. Now the question is how I provide hooks in the page for non-javascript, non-iframe users - least I forget how web pages look to web spiders.
Where does CDATA come into all this? It turns out if you XHTML DOCTYPE a libxml2 DOM then try to add a 'script' element libxml2 decides the text must be a CDATA section, but doesn't render it in a fashion compatible with browser's javascript parsing. Reading around it seems this is because 'script' is defined as containing CDATA (or PCDATA) in the XHTML specs, which strikes me as an unfortunate collision of standards and how things actually end up working (or not, in this case). I can understand why this has come about (mixing of content types within a single document), but 'little' things like this can be really annoying e.g. using DOJO requires setting up a configuration variable, loading its js file, then loading up particular widgets. Putting that into external files would require another two files, with one line in each.
I've pretty much come to the conclusion AJAX is a really nice technology for some specific areas. AJAX is good for complex user interaction (e.g. form-filling) but bad for simple interaction (e.g. navigation, scrolling and reading). Firefox makes a good job of AJAX (and I suspect Opera is better still), but as long as 80% (?) of users insist on using Microsoft's crippleware we're stuck in the slow lane. Then again, perhaps Internet Explorer 7.0 will solve all AJAX's problems ...
One javascript library (the J in AJAX) suggested to me by a colleague was 'DOJO' ( http://www.dojotoolkit.org/), which provides a lot of javascript-based widgets that turn your web page into something more akin to a windows GUI. But, and you'll notice this if you go to that page, it breaks the forward/backward browser history navigation. In which case we're somewhere closer to the entire-web-page in a Macromedia flash file than I'm comfortable with. (I dislike flash-based things because it prevents me using the neat tools that Firefox otherwise provides, like forward/backward navigation on my 5-button mouse, keyboard scrolling/searching/link selection etc.)
After several days trying different techniques I've ended up back where technology was several years ago: the iframe. Coupled with a bit of javascript to make interactive menus (so we don't have to go to the server to get more options) iframes keep the forward/backward navigation working and can be automatically stretched by javascript so as to fit the content i.e. no scrollbars floating around the middle of a page. Now the question is how I provide hooks in the page for non-javascript, non-iframe users - least I forget how web pages look to web spiders.
Where does CDATA come into all this? It turns out if you XHTML DOCTYPE a libxml2 DOM then try to add a 'script' element libxml2 decides the text must be a CDATA section, but doesn't render it in a fashion compatible with browser's javascript parsing. Reading around it seems this is because 'script' is defined as containing CDATA (or PCDATA) in the XHTML specs, which strikes me as an unfortunate collision of standards and how things actually end up working (or not, in this case). I can understand why this has come about (mixing of content types within a single document), but 'little' things like this can be really annoying e.g. using DOJO requires setting up a configuration variable, loading its js file, then loading up particular widgets. Putting that into external files would require another two files, with one line in each.
I've pretty much come to the conclusion AJAX is a really nice technology for some specific areas. AJAX is good for complex user interaction (e.g. form-filling) but bad for simple interaction (e.g. navigation, scrolling and reading). Firefox makes a good job of AJAX (and I suspect Opera is better still), but as long as 80% (?) of users insist on using Microsoft's crippleware we're stuck in the slow lane. Then again, perhaps Internet Explorer 7.0 will solve all AJAX's problems ...
posted by Tim at
5:27 pm
0 Comments:
Post a Comment
<< Home