[2.0] Switching to HTML5

[yellowled]

HTML5 is here, although it is not even a W3C standard by now (or will be in the near future, for that matter), but it is supported well by modern browsers, there are polyfills for older browsers, and sooner or later, almost any new site out there will be built using it. It offers a lot of benefits in many areas (which I will not list here now for to keep this readable ).

While this is most likely not something for 1.6 or even 1.8, we should really consider switching both backend and frontend to HTML5 in the future. Since it is designed to be backwards compatible even with the XHTML syntax, it's not really difficult to switch. Potential issues lie deeper, i.e. in 3rd party components like WYSIWYG editors or JS/jQuery stuff.

YL

[Don Chambers]

Just because we will encounter issues with 3rd party components is no reason to avoid this. I am NOT HTML5 proficient just yet, but will support this in any way I can as we move forward.

[Timbalu]

HTML5 is here, ... switching both backend and frontend to HTML5 in the future. Since it is designed to be backwards compatible even with the XHTML syntax, it's not really difficult to switch.

Yeah full ACK, and don't wait to long...
I'll bet there are a lot of people out there who want to say goodbye to old and complicated web stuff. Web will change more quick, if you start to disable support for these old broken standards like IE < 8/9. We could always have a switch to fall back to bulletproof or anything supporting old Browsers and old HTML standards, if someone trally needs to support these clients.

Ian

[yellowled]

if you start to disable support for these old broken standards like IE < 8/9. We could always have a switch to fall back to bulletproof or anything supporting old Browsers and old HTML standards

In my humble opinion, that's a contradiction in terms. If we switch to HTML5 in full, we should do it without a fallback, if only to save to bloat and hassle to maintain the fallback.

We could actually switch to HTML5 now without any user actually noticing. Just change the doctype, adapt the charset/css link/script statements, lose obsolete elements like frames, iframes etc., and keep using everything else. There, HTML5.

Remember that anything not supported by older browsers like new structural elements, native audio/video, canvas etc. doesn't have to be used. Also, there are quite a lot of polyfills out there, although some of them sure as hell aren't pretty.

YL

[Timbalu]

In my humble opinion, that's a contradiction in terms. If we switch to HTML5 in full, we should do it without a fallback, if only to save to bloat and hassle to maintain the fallback.

Surely yes, to be more precise, I meant, switch back to old template by blogowner who wants to support old behaviour.

I allready did try some html5 blogs and used something like

Code: Select all

    <!--[if lt IE 9]>
    <script>
        document.createElement('header');
        document.createElement('footer');
        document.createElement('section');
        document.createElement('aside');
        document.createElement('nav');
        document.createElement('article');
    </script>
    <![endif]-->

Is this what you call polyfill?

[yellowled]

Surely yes, to be more precise, I meant, switch back to old template by blogowner who wants to support old behaviour.

Well, in the and all this is managed by the template -- and thanks to the child/engine template concept, it's actually pretty easy to do an HTML5 frontend already. I'm working on a new blog which will be full HTML5, and the S9y InfoCamp blog is HTML5 as well.

It's a bit different in the backend, though.

I allready did try some html5 blogs and used something like

That's the HTML5 shiv by Remy Sharp. What it does is sort of "register" the new structural elements using JS in IE<9. However, that will only work with JS active -- then again, the number of users using IE<9 w/out JS should be next to nothing.

Is this what you call polyfill?

Not quite. A polyfill is some non-HTML5 technique which replaces a native HTML5 technique for browsers which don't support it. The most common thing probably would be a flash fallback for native HTML5 audio/video.

YL

[yellowled]

Garvin, could you chime in on this? Seems to me everybody else is in favour of going HTML5 asap, so we should probably have some kind of decision on this before Don and I start working on new templates for backend and frontend ...

YL

[Timbalu]

... everybody else is in favour ...

1, 2, 3 ... (people by now!)

[garvinhicking]

Hi!

I don't have experience with HTML5 yet. Anything that does not break current existing browsers is fine with me.

Having IE6 look ugly is also no problem by me. But it should at least be somewhat usable and not fail alltogether.

Regards,
Garvin

[yellowled]

Anything that does not break current existing browsers is fine with me. Having IE6 look ugly is also no problem by me. But it should at least be somewhat usable and not fail alltogether.

As I said, there's no need to use new elements introduced in HTML5 so far, especially not in the backend. Same with new features like native audio/video, canvas etc. -- we probably want to use them at some point, but it's perfectly fine to not use them now. Other stuff like WAI-ARIA (accessibility) and the new form elements do work in modern browsers, but fall back to old behaviour in older browsers without any additional fixes needed.

We can also use the HTML5 shiv, which is a tiny piece of JS to enable the new elements in IE<9 as well as i.e. Flash fallback for audio/video. There are issues in Firefox 2 and Camino 1 as well, but it's pretty much safe to ignore those browsers -- their market share is minimal. As a bonus, all the "old" XHTML code should still be valid (although not perfect) in HTML5, meaning we don't have to rewrite every plugin's HTML code.

YL