Switching to HTML5

Posted: Sat Apr 23, 2011 12:15 pm

While I was taking a break from the development of Site Guardian I starting thinking back to something I had wanted to try for a while now.. using HTML5.
I thought maybe it might be fairly straight forward; just find the declarations for DOCTYPE and strip everything out of them and just leave the new DOCTYPE HTML which I did.
I ran the homepage through the validator and it starting complaining about me using the ISO-8859-1 charset and the validator switched to validating using the WINDOWS 1255-1 (or something) charset.
Obviously that wasn't a good start because now the validator was 'assuming' I was using the WINDOWS charset and that could throw off the correct validation errors.

I decided to then enforce UTF-8 charset and see if that was any better. Easy enough to actually change that to issue a utf-8 charset in the header. (find _CHARSET there is one in mainfile and one in the root language file) and change the constant declaration to utf-8.

The W3C validator seems to be giving correct validation errors now BUT it seems a lot of stuff we take for grnated and as 'best practise' now cause validation errors.
For a start, when declaring SCRIPT, the language type= attribute generates an error because it isn't used in HTML5 and there are also a gazillion inline declarations for border=0 which also cannot be used; instead you have to declare it via CSS

Code:

{border: 0}

not too much of a problem as you could probably get away with putting that in the main BODY, though you would still have to remove any inline declarations.

I had hoped to have a go at creating a HTML5 theme but it is clear from this (as far as actually validating your work is concerned) that you would have to do so locally and for the moment, having correctly validated HTML5 code is impossible without extensive re-coding of RN.
And of course that also means that correctly validated code to HTML 5 spec would fail when used with RN's x(HTML) 1.0 Transitional spec.

I think after Site Guardian is released, I'm just going to bite the bullet and re-code this site for HTML5 and use 1.0 Transitional purely on my development server.

Site Admin Joined: Jan 06, 2006 Posts: 311

Yeah, was researching this awhile back as well. I think if we had forced ourselves into XHTML 1.1 Strict on the RN side, things would have been much closer, but HTML5 is definitely no "slam dunk" and be careful what you use from is as there is a wide variety of support for the various components across browsers. I gave up considering it for the short run as I really don't want to impact my "users" nor go back to writing browser-specific code.

Good luck. Will be watching your efforts with great interest.

Posted: Sat Apr 23, 2011 3:56 pm

Luckily there is HTML5Shiv a js library that re-writes some stuff on the fly for older browser support but even so, they say HTML5 will not be a 'stable' specification until about 2020 (-ish) so I'm a bit torn at the moment.
It would be nice to be able to use it but I think I need to do some more research on the impact with regard to supporting older browsers. I'm not worried about IE6 but it seems there are some big differences with IE 7/8.
As you mentioned, and I agree, it's crazy writing work arounds for different browsers and not something I really want to do.
If nothing else, it would be nice to have full validation to HTML5 spec provided it doesn't break anything.

Site Admin Joined: Jan 06, 2006 Posts: 311

IE9 is even closer, but if I recall correctly 7&8 still are too far behind to really consider HTML5 IMO. And, its not just IE unfortunately.

I was considering it for mobile devices because we're also being pushed and pushed and pushed for mobile applications. My thinking was the mobile market is moving at such a feverish pace, that maybe support for HTML5 would be better. However, same issues exist.

It is exciting stuff though. I wish the freakin' browser makers would stop proliferating their own versions of things (again, its not just IE!) and give us a true stable PLATFORM to deliver web-based solutions upon.

Newbie Joined: Dec 06, 2007 Posts: 7

i have been looking at this aswell Guardian and the benifits dont outweight the hard work. Like Montego said you will be coding on a browser by browser basis in an ideal world we would have just one browser and it pains me to say it but Chrome is as close as we can get for the moment to a perfect html 5 browser.

Safari 4 (Win)

Firefox 3.5 (Win)

Google Chrome (Win)

Opera 10 (Win)

Internet Explorer 6, 7 & 8

these are a little outdated as FF 4 and Chrome improved on html5
but give you a good idea of the browser support for html5

so IMO its worthwhile waiting afew years till the standards for browser support of html5 is at a higher lever accross the board

Posted: Thu Apr 28, 2011 6:22 pm

Yes, I see your point and I appreciate the browsers are lagging, though with HTML5 not being fully finalised, there is only so much the browser developers can do at the moment.
From my own perspective, I am not looking to use all of the features HTML5 provides. I'm more interested at this point in time, utilising some of the HTML5 markup such as header, section, aside, footer etc and *some* of the CSS3 stuff.
In other words, I would like to be HTML5 'Ready', at least as far as most of the supported markup goes.

HTML5 Boilerplate is very interesting and offers a way to get around some of the current browser limitations and doesn't look like it would be to difficult to implement within RN plus it has some nice features I had not even thought about before.

Firefox 4 is pretty neat, I installed it a few days ago. Still trying to get used to the tabbed bar at the top but it does seem quicker and all my plug-ins still work (some had to be upgraded).

Posted: Tue May 31, 2011 11:45 am

I have actually now reverted my changes on this site and it's back to almost standard RN due to some unforseen issues I don't have the time to dig into.
I noticed some JS was falling over when it was being used to re-write the DOM on the fly, for example where you might utilise something like Lightbox where the JS looks for a specific trigger within an attribute.

I also had catastrophic failure of the CSRF Magic library which caused every form to fail with a 'invalid CSRF token' error (both for user and admin submitted data).
I also had a spurious issue with NS putting the site into 'Site Closed' mode (which definitely wasn't good) after running the NS admin functions for finding duplicate blocked IP's etc. NS puts the site into 'Site Closed' mode automatically when these functions are used but for some reason, failed to put it back into 'Site Open' mode.

I will no doubt get back to tinkering with this again but I have a home move looming and although I will still be developing stuff for RN for the forseeable future, I'm seriously contemplating transferring the data of this site to a Concrete5 installation (subject to further testing of the Concrete5 CMS

Posted: Sat Jun 25, 2011 10:30 pm

Just as an experiment I have replaced my websites at www.totalprojectdesign.com which was originally written as a University project.
I have utilised Ionize CMS (a CMS based on Code Igniter 2 PHP Framework) and replaced the original xHTML 1.0 Transitional theme with some compliant HTML5 code.
I still have a fair but of stuff to play with but found some of the new self validating (client side) form elements fun to work with (of course the data is validated server side before being processed).

Site Admin Joined: Jan 06, 2006 Posts: 311

Looking really nice. Tried to let you know, though, via your contact form, but it didn't work. Threw some error messages.

Posted: Sun Jun 26, 2011 7:48 am

Oops, I added a URL 'hint' for that field, apparently it doesn't work in all browsers yet Sad

I'll fix it when I have woken up a bit - thanks for letting me know.

Newbie Joined: Jan 27, 2012 Posts: 1

Just playing with converting a localbox copy of RN 2.5 to HTML 5 in as much as using DOCTYPE html and fixing the most common validation errors; meta tags, no language attribute for JS etc
and this CSRF failure is driving me nuts.
Even with debug mode on all I get is

Quote:

CSRF check failed. Please enable cookies.
Debug:
If the problem persists, please contact the server/website administrator

which seems to suggest no toekn is being passed but the weird thing is, I can log in/out just fine but every other form just falls over.

Newbie Joined: Nov 20, 2008 Posts: 55

I am going to try this and get back to you guys.

Posted: Sat Jan 28, 2012 11:33 pm

Yeah, a second opinion/thoughts would be good just so that I know I'm not going completely nuts. I should also mention I changed all CHARSET references to utf-8 and used the HTML 5

Code:

<meta charset="utf=8" />

I have a gut feeling it might be related to mass removing references to

Code:

<meta http-equiv="Content-Style-Type" content="text/css" />

Since http-equiv is generally not valid in HTML 5 but there are some exceptions. I need to revisit this as it's possible I might be able to use something like

Code:

<meta content="text/css" />

I was going to go back to it yesterday but reset that project dev box.

In case it drives you up the wall wondering why you cannot find some references in the code that are clearly in the viewed source, you'll find those pesky critters hiding in the nukeseodh_master table Wink

Site Admin Joined: Jan 06, 2006 Posts: 311

Guardian, you had mentioned once to me about mimetype.php. I am thinking that script was pre-HTML5? I haven't looked at it, but did you ever comment out the use of that with your HTML5 work? Cannot recall.

Posted: Sun Jan 29, 2012 3:59 pm

Yes, that was another thing that has potential to cause issues. What I did with that was replace it with one that just set the DOCTYPE to 'html', and charset to utf-8 if they weren't set.

I'll have to revisit it again. I'll probably start afresh with a new NetBeans project and rather than doing mass find/replace for none valid HTML 5 stuff, I'll do one file at a time and see when it falls over. I'll probably start with the nukeseodh_master table as that has a fair bit of stuff in it that's rendered by default that I cannot use for HTML 5 or maybe it might be easier to just create a new header file with hard coded stuff in rather than mucking about and see if forms work - might be a quicker solution actually now I think about it.