The wif'e’s out and the kids are asleep, nothing interesting is on the TV so I started googling for “HTML5 explained” and such. I’m interested in the subject because I feel obliged to stay tuned on the new stuff coming at us and I’ve wanted to dig a few feet deep into the matter when I had the time. What I found was simply so interesting that I wanted to share it with you because it’s a whole new world, baby…
“HTML5 is a response to the observation that the HTML and XHTML in common use on the World Wide Web is a mixture of features introduced by various specifications, along with those introduced by software products such as web browsers, those established by common practice, together with many syntax errors in existing web documents”. Wikipedia tells us that HTML5 is trying to solve the problems we have today with an outdated HTML 4.01 specification where we rely heavily on Javascript, AJAX and a bunch of various industry standards such as JQuery to animate, play videos, validate data and so on.Take a look at the available types of input in HTML 4.01 and the input types available in HTML5. Geo-location is also a first-class citizen in HTML5 which enables any HTML5-capable browser to i.e. load a Google Map and mark your location on a map by using a few algorithms and whatever wireless network Google is able to locate you by.
By looking into the matter I found quite a few blogposts by people being concerned that the term “HTML5” is more of a marketing phrase than a distinct set of related technologies. Jeffrey Zelmand (who first coined the term “Web 2.0”, I think it was) has an interesting blogpost on the subject. He advocates for us to market HTML5 as “HTML5 and related technologies” or “HTML5 and other new technologies”. The reason is that HTML5 is still so vague that people don’t understand it (I don’t either – don’t shoot me, I’m just the pianoplayer) – which leaves plenty of room for misunderstanding core concepts and discussions running in circles. I like the “HTML5 and related technologies” since the HTML5 specification is concerning a lot on core HTML concepts (parsing) and less on everything else. There’s nothing about CSS in the spec for instance – that’s another story told by another spec.
How will the spec end up looking like? It is still under active development and every release has a profound disclaimer telling the world that they should expect the current APIs and elements to be subjects of change in the coming years until the standard have settled and stabilized itself. I found a fascinating post about the development of the first HTML standard and how it became to what we work with (and sometimes curse upon every day). Get this: “But none of this answers the original question: why do we have an <img>
element? Why not an <icon>
element? Or an <include>
element? Why not a hyperlink with an include
attribute, or some combination of rel
values? Why an <img>
element? Quite simply, because Marc Andreessen shipped one, and shipping code wins” I don’t expect things to have changed much since then (sarcasm intended) so we will probably see some of the big players on the market implementing things their way and once their solution reaches critical mass – that’s how things make it into standardized glory.
What can you do as a developer to prepare yourself for the inevitable? You don’t have to worry for the next few years but time will come when you will need to take a deep breath and unlearn your current way of doing things when developing for the web. The reason is that once you start to use HTML5 there’s probably some element which solves a given problem for you. Don’t format your dates and times using Javascript anymore – use the appropriate input-element instead. Don’t use the ol’ A HREF for links – use the input type “url” instead. Order a new copy of “Who moved my cheese”, unlearn what you know and move on. The time is right when the HTML5 spec settles a bit.
Become a Javascript jedi is another safe bet and you should start today. HTML5 (or HTML 4.01 for that matter) won’t do you much good if you don’t know your way around a scripting language for the web. The applications you run today locally on your machine is likely to move much closer to the web. Microsoft Office has a released a limited set of Office features in Office Web Apps for Sharepoint 2010 which enables users to open, edit and save Office-documents in a web browser without the user ever having installed Office locally on their machines. Things are moving towards webbased solutions and I wouldn’t be surprised if Office Webapps will have more features in 10 years from now than an Office installation on your local harddrive. Who says anyway that you need much more than a browser and an uplink to your desktop running in the cloud in 7-10 years from now? Which technologies are likely to be used when we get to that point? Spot on – HTML5 with Javascript (or something similar scripting engine) as the glue between data and user interactions.
Feel free to comment on your thoughts on HTML5 – I’d love some feedback on my thoughts in this matter.
3 kommentarer:
really informative post.. thanks for sharing...
Thanks for your tutorial. I learned lots from here like a e-book. Keep up your work.
Android apps developer| WINDOWS PHONE 7 DEVELOPMENT|
I hate some of the elements found in HTML5. I think part of it's because I don't understand it, or I might have overestimated my ability to lay out information in a semantic way.
For instance, I'm wondering if a layout structure with , , , wouldn't have been easier to use, instead of having to figure out whether a piece of information falls under or something else.
We have H elements, to add hierarchy to information. Why add confusing elements such as section and aside? Now the H1 can be used multiple times, instead of breaking down info further with H2, etc. As for aside, why didn't they give us a sidebar H element? Something like SH1, SH1, etc etc. This could go into a element. No mess, no fuss.
I'm probably just being a complete idiot about this, but we just put bumper sticker XHTML behind us. All I see is a different bumper sticker being added to websites. Where does it leave CMSes? Content management systems were initially designed to put website updates in the hands of non-tech website owners. Do you think they care about whether a picture they took, or a piece of badly written, superfluous text they're proud of, should go inside an aside or section element?
Send en kommentar