3 ms·
Agreed, I'm surprised they decided to use a non-standard attribute. But it is a simple and elegant technique if you want to save the server from doing extra wor
by bprater 18y ago
Agreed, I'm surprised they decided to use a non-standard attribute. But it is a simple and elegant technique if you want to save the server from doing extra work it doesn't need to.
- axod 18y agoSure, but it's just as easy for the server to output a javascript structure with the data in really. eg <script> var data = {time1: "Nov 5, 1955", time2: "Jan 1, 1970"}; function init() { // Update the spans with the "ago"s } </script> <span id=time1></span> Using the DOM to store program data just doesn't seem nice to me.
- lhorie 18y ago>> Using the DOM to store program data just doesn't seem nice to me. I disagree. I think the DOM is where data should be (look at meta tags, for example). Storing data in json style or xml-like attributes sound a bit like repurposing things. Also, according to Steve Sounders, sprinkling script tags everywhere (which I suppose is the easiest way to get the json approach working in a site of arbitrary complexity) is not a good idea in terms of loading speed.
- axod 18y agoWhat if your data contains html entities, newlines, unicode etc etc etc. HTML is a hornets nest, whilst js is pretty sane. I would never advocate sprinkling script tags everywhere :/ 1 is enough usually. (I would obviously in this case, have 1 script tag at the end of the body, with the data structure, and the function to initialize the span tags).
- lhorie 18y agoAs far as encoding goes, my experience has actually been worse on the javascript side, specifically with french text and regular expressions buried in 3rd party libraries. Compared to that, grabbing data from the DOM using DOM text node methods is a walk in the park. The thing with the json solution is that once we have things being ajaxed in, it becomes very hard to maintain the code. Has id="date7" been used? What if I add a comment while the "shoutbox" feature is updating? Having the data in HTML would let us use something like Jquery's livequery and it would work regardless of how the data and how much data got into the page (plus we get the benefit of the no-javascript scenario I mentioned before).
- axod 18y agojson? ajax? The solution I posed was a simple inline javascript at the end of the html. The js data is generated at the same time as the html output. The IDs all match, and are used once. I've never seen any issues with encoding in js, so I'm not sure what you mean about french text, regexps...
- lhorie 18y agoWhat I'm saying is that once a site becomes more complicated (e.g. if the data comes after page load, in an ajaxed popup, for example), that simple solution becomes harder to maintain (or to implement without wasting bandwidth). To be fair, if you don't work on complex web apps, you'll probably never run into this. >> I've never seen any issues with encoding in js, so I'm not sure what you mean about french text, regexps... Good for you. I hope you never see these types of bugs, they are nasty to troubleshoot.
- lhorie 18y agoI found that strange too. I'd probably have the date as a text node, so that there is still time information visible in the rare case when javascript is turned off.
- _phred 18y agoI'd go for the microformats way of representing time, now that they've standardized it: http://microformats.org/wiki/datetime-design-pattern http://microformats.org/wiki/datetime-design-pattern <abbr class="foo" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ">Date Time</abbr> There are a lot of good alternatives proposed and debated on that page, so I'm confident that they've come up with the best way to represent the date in the DOM. Additionally, it's readable from Javascript-less environments and and uses only standard elements and attributes.
- lhorie 18y agoI've heard about that. I think microformats are clever but I'm still waiting on the resolution of the whole microformats vs accessibility debate.