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
[2.0] Switching to HTML5
-
- Regular
- Posts: 3652
- Joined: Mon Feb 13, 2006 2:40 am
- Location: Chicago, IL, USA
- Contact:
Re: [2.0] Switching to HTML5
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.
=Don=
Re: [2.0] Switching to HTML5
Yeah full ACK, and don't wait to long...yellowled wrote: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.
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
Re: [2.0] Switching to HTML5
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.Timbalu wrote: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
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
Re: [2.0] Switching to HTML5
Surely yes, to be more precise, I meant, switch back to old template by blogowner who wants to support old behaviour.yellowled wrote: 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.
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]-->
Re: [2.0] Switching to HTML5
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.Timbalu wrote:Surely yes, to be more precise, I meant, switch back to old template by blogowner who wants to support old behaviour.
It's a bit different in the backend, though.
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.Timbalu wrote:I allready did try some html5 blogs and used something like
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.Timbalu wrote:Is this what you call polyfill?
YL
Re: [2.0] Switching to HTML5
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
YL
Re: [2.0] Switching to HTML5
1, 2, 3 ... (people by now!)yellowled wrote:... everybody else is in favour ...
-
- Core Developer
- Posts: 30022
- Joined: Tue Sep 16, 2003 9:45 pm
- Location: Cologne, Germany
- Contact:
Re: [2.0] Switching to HTML5
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
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
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
Re: [2.0] Switching to HTML5
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.garvinhicking wrote: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.
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