the HTML5 landscape overview on my blog is getting a fair share of hits over time, and i guess the simple explanation for that is that HTML5 is a constantly evolving and vaguely defined concept, so people search for overviews and status reports.
i recently stopped hand-editing the HTML of the page and converted it to XML, so that i can now manage updates by editing XML, and then the blog HTML is generated with a simple XSLT transformation. for now, the only change in the blog has been that the status of specifications is now indicated by a superscript, but i'd like to take this a little further. mostly, i am interested to find out whether it would make sense to add some structure (and maybe more specs) to the list.
currently, there are 53 specs listed on the HTML5 page, and some people have pointed out that it might even make sense to start adding (some of) the current CSS work there, because CSS, too, is part of the whole more power to the browser
movement. i agree in principle, and it would be useful and interesting to provide a more complete picture of the current activities in the vaguely defined HTML5 space, but at some point just listing specs becomes a bit overwhelming.
so the question i am asking myself is the following: what would be a good classification to use for this evolving space of specifications? i don't have a good answer for that, so it would be great to get some feedback and ideas. possible ideas include, but are not limited to:
- in-browser vs. out-of-browser: certain specs are firmly in-browser (Web Storage is an example for this), while others are firmly providing browser access to things that used to be inaccessible to browsers (File API: Directories and System is the an example for that). this might be an interesting distinction, but on the other hand, by definition once there is an API for it, things become almost in-browser, so maybe it's actually not so easy to always draw a clear line.
- device-only vs. networking: certain specs look at how to improve access to a client's device (Vibration API), whereas others are about establishing connectivity from a client's device through some form of networking (Web Sockets API).
as with every classification, the challenge is to find one or more that are specific enough to be useful, general enough to be applicable to all/many specifications, open enough so that they can be extended when new specifications arrive, and partitioning enough so that they divide up the space of specifications into useful/interesting subsets.
while i don't have a good answer which classification to use, it would be useful to have at least one, and maybe even more than one, so that i can improve the way in which the landscape overview is published. so if you have any suggestions or ideas for classifications, please feel free to comment!
Comments