The people upstairs would like to here new things are being created in HTML5 – don’t ask.
That’s my point 
I realize that even if all of the vendors next update supports the entire HTML5 draft there will be millions of browsers that don’t. Has anyone on the HTML5 cheerleading squad come up with methods to support backwards compatibility or even philosophized how that may occur?
What we have so far is:
I know, it starts with an A and ends with a JAX.
If a form is really that long and complicated, even I will start thinking of breaking up sections in separate pages (I usually hate that, stringing the user along, but here you can get submissions and validation for each “chunk” of data). You can layer your ajaxy junk on top of that if the boss insists on the pretty spinny-gif and new form questions appear under the last-answered one (a la twitter, duckduckgo, facebook).
The second coming indeed. This has a name: hype. Doesn’t mean there’s nothing behind it, but c’mon, the job ads I’ve been seeing lately make the milk squirt out of my nose from lawlz. XHTML has been replaced with HTML5, CSS has been replaced with CSS3, and Javascript has been replaced with jQuery. Blargle.
Or you’re lucky like me, write pages for a corporate Intranet, and get to dictate which browser the users have available.
Course jerks that preceded me dictating IE 6 started a lot of this mess.
On the website I’m developing at the moment I’ve decided to go the HTML 5 route. I don’t think that using the shiv is that much of a concession really. Especially when it’s just for the one browser - IE 8 and below.
The new elements work in the other browsers out of the box, you just simply need to apply display:block to them (header, footer, section etc). The only browser I’ve hit a roadblock with is the Playstation 3. I don’t have a solution for that browser yet though. I don’t know of any conditional comments you can use for it etc.
Obviously I do think backward compatibility is important but a javascript fix to fix an issue with one browser (a browser that’s held back standards long enough already) isn’t that bad of a solution. I’d prefer it if I didn’t need to apply a javascript fix but I think it’s worth the effort to use it.
I know I’m currently in the minority there but there we go. Likewise I’m using some of the new CSS3 styling to provide a better experience for those using newer browsers. I think doing corners with CSS is much better solution than trying to do it with images or javascript.
Obviously I do think backward compatibility is important but a javascript fix to fix an issue with one browser (a browser that’s held back standards long enough already) isn’t that bad of a solution. I’d prefer it if I didn’t need to apply a javascript fix but I think it’s worth the effort to use it.
I think doing corners with CSS is much better solution than trying to do it with images or javascript.
Why? Just curious.
For the first quote because it’s future proofing the sites. The move will have to be made eventually so why hold back on the account of a browser which has held back standards long enough already when there’s a solution available that will get it working even in that browser.
There’s no point waiting until it comes out of draft as that won’t be for years if not decades. Why not at least use some of the new features such as the new form types which degrade for the non supporting browsers? If we can provide a better experience for those using newer browsers why shouldn’t we?
I can understand that people will see having to use javascript for older IE users (when using the new elements) as a bad solution but that’ll have to be a decision for every web developer to make for themselves. For me personally I don’t see it as much of an issue but obviously others will.
For the second quote: Using images for corners is incredibly messy for a start, I spent a long time about 3 years ago looking for various solutions to rounded corners and all of them were horrid. I ended up selecting a javascript based solution but I don’t see why anyone wouldn’t use CSS3 corners if they are developing a site nowadays.
It’s better imo to provide a good solution to the majority of users which degrades nicely to everyone else than a bad solution for everyone. Why punish users of newer browsers for staying up to date with features when you can give them a better experience using the latest standards?
Excellent 
This is just what I was looking for. Please feel free to post any ideas you have for workarounds. Also, if you find areas where HTML5 clearly provide an advantage in some way come back and post it. I’m extremely comfortable working in xhtml but I’m pretty sure it’s just a matter of time before enough momentum builds to push HTML5 into our development world. As Stomme poes has mentioned, some ads are already specking out HTML5 and CSS3 in their requirements.
Cheers and good luck with your project.
If you don’t mind a giant bloated javascript that tends to break other scripting, often breaks other workarounds to get elements behaving right int the first place, and in general bloats out the code you send to EVERYONE regardless for something that frankly, you CAN USUALLY ALREADY DO IN HTML 4.
Besides, it’s not “future proofing” to be implementing a specification that COULD CHANGE AT ANY TIME. FUTURE PROOFING is using what works and is a recommendation in the here and now, because there’s no “expiration date” on HTML 4 – it’s not like browsers are going to stop supporting it just because of some new specification that throws all the progress of 4 out the window.
Which is where I think people fail to grasp that these new features are in said browsers for TESTING, NOT deployment – that’s the difference between “DRAFT” and “RECOMMENDATION”. It’s like the CSS3 browser specific prefixes, by definition they mean “for testing”, “not for use on production sites”.
It’s the SAME MISTAKE people made using IE5’s CSS2 implementation, which was done BEFORE it was out of draft and BEFORE they up and decided to use a box model that wasn’t compatible with the only browser that had tried to implement the draft at the time.
… and we’re still paying for said mistake TODAY in terms of keeping IE backwards compatible.
I can understand that people will see having to use javascript for older IE users (when using the new elements) as a bad solution but that’ll have to be a decision for every web developer to make for themselves. For me personally I don’t see it as much of an issue but obviously others will.
Inconsistent rendering cross browser for a start? Poor anti-aliasing behavior that often looks worse than jpeg artifacts? The need for something a wee bit more complex than just making a corner round?
Though admittedly, that’s why I’m a LOT more interested in CSS3’s border-image property… NOT that I would try to deploy anything using that right now – it’s tons of fun to play with to see what we MIGHT be able to use SOMEDAY.
Images for corners is only as messy as you make it… I often laugh hysterically when I see people doing fixed width websites and STILL end up using 9 separate images to do the job of one.
… and when it’s not a good solution, is worse than the older way of doing it… much less “punish WHAT?”… deploying “for testing” versions that could change at any time? Just because it’s in there doesn’t mean you should be using it on production code.
But again, people just want to repeat the same mistakes that were made with IE5 – this time out it’s just gecko and webkit’s turn. (At least Opera has the decency to give us the REAL CSS3 properties)
I have yet to see a HTML5 based site that was worth a flying furry 4channer. MOST of what I’ve seen is the same garbage we’ve been seeing for the past two decades; idiocy like non-breaking spaces in empty elements, splash pages, and 50k of markup doing 10k’s job. Might as well have a splash page with nothing resembling content on it while at it – as it’s in that same class of “sleaze it out any old way”.
Nothing is stopping you from using CSS3 with a HTML 4.01. HTML5 isn’t necessary to use many of the features of CSS3 that help to promote cleaner mark-up such as; rounded corners, gradients, etc. Just make sure you degrade properly or perhaps use something like CSS PIE – additional bloat I know but its a great solution to keeping the integrity of a design in tact in <=IE8 w/ some restrictions of course. That said I haven’t noticed any unexpected cross-browser inconsistency on browsers that implement CSS3 in some form. A short while ago I was very against CSS3 and thought many of the things are stupid, such as rounded-corners. However, even with the varying implementation across browsers its nice not to clutter mark-up with presentational crap to achieve a certain effect like the empty element with absolute positions or excessive wrapping to apply rounded corners – yuck! Now I tip my hat to CSS3 for providing a way to achieve just about any effect regardless of how convoluted or unnecessary it may be without resorting to adding presentational mark-up.
Aha, but they actually do have -o properties. It’s just that you see them a lot less because people don’t write so much for Opera.
Poor, poor Opera. Only gets any love in former Soviet States and Southeast Asia. : )
Giant bloated javascript? Have you even looked at the shiv? Besides you can use google’s minifed version and that way you don’t even need to provde it yourself.
I can understand that argument when talking about new elements but what about simply using html5 to improve your website’s functionality? What about improving your site’s SEO? e.g. look at the picture below
EDIT: Sorry can’t hotlink to the image, if you google “Xenforo” you’ll probably see one titled “Welcome to XenForo! | XenForo Community” underneath that within the <cite> tags you’ll see some breadcrumbs, they link back to their respective sections on the forums. I’ve not even spent time looking into that yet myself but surely that will be beneficial for SEO?
Xenforo is pretty new forum software, they’re using html5 microdata and Google is already picking that information up. If you can provide a better experience without harming your other users then surely there’s no argument against that.
What is the harm in at least using the new doctype and using the progressive enhancements like the microdata above, new form input types etc. By simply using the number input type where you expect numerical data you’d automatically be making your site more phone/tablet friendly. You’d still want to validate the entry yourself but the more of that behaviour that’s done by the browser the better in the long run.
I’d disagree with that. Things are very different imo with how they were then. Now you have several mainstream browsers mostly singing from the same hymn sheet. And they’re the ones setting the pace. Something only makes it in if multiple browsers implement it.
There are several bits of the new CSS 3 syntax that can be implemented now with safety that the syntax won’t be changing. Such as box shadow and border radius. You don’t need to put the vendor prefixes in even. They’re all (the main browsers) either supporting or going to be very shortly the same vendor less syntax. Obviously if you want to ensure it’ll work in a slightly older version of Firefox or safari then you can put the prefixes in too but the syntax for those examples won’t be changing from the current recommendation. I’m sure of that much.
The huge majority won’t be changing, development is changing though and surely we should be looking to make use of the latest developments coming through. Especially when we can do quite a lot of without causing any harm to the users of older browsers. I’m not trying to force anyone to switch to HTML5 but I certainly think it’s naive to exclude the entire package without taking advantage of the positive aspects of it.
If you’d prefer to carry on using HTML 4, Tables, or whatever you’re currently using then there’s nothing stopping you.
Why even go that far? Why not simply use CSS3 to progressively enhance the site for users of modern browsers? Re-producing everything pixel by pixel so things look exactly the same in every browser is firstly painstaking plus unnecessary. Why resort to using CSS Pie just to make sure that you keep your rounded corners in IE 8? They won’t even realize the corners are meant to be rounded.
Re-producing everything pixel by pixel so things look exactly the same in every browser is firstly painstaking plus unnecessary. Why resort to using CSS Pie just to make sure that you keep your rounded corners in IE 8? They won’t even realize the corners are meant to be rounded.
Same here. When I use CSS3 stuff, it’s minor and I don’t try making it work in older browsers… why make those users download a steaming pile of JS just for goofy looks?
But I do check that I’m not relying on those features in the older browsers. For example, if I use rgba() for a background, I make sure IE and everyone else old gets a solid background colour as well… contrast reasons.
Similarly when I have “buttons” and I’m using images… usually I can also get away with adding a background colour behind the image, so users without images get similar contrast and feedback.
re data- attributes:
John Resig has an interesting blawg about them.
Sounds like HTML5 trying to imitate microformats lawlz. I had forgotten about these: they are in Bruce and Remy’s book as a “these are not in the book because no browser supports them yet”, though I guess I’m not surprised the Googles are trying to keep up with the new stuff.
Good point. In the case of corner-rounding, when it fails (older browsers), it doesn’t break the layout, so it’s not worth a lot of agony.
In fact, I don’t worry too much about things being slightly different in IE7 - you know, element positioning being “off” by a few pixels, and so on. Sure, the page may not look exactly the same, but as long as it’s pretty close, who cares? IE7 users are now accounting for something in the low single-digit percentages of my site visitors, and they’re not getting a “bad” experience, just one that isn’t pixel-for-pixel identical to what other visitors see. IE8 probably has a long life ahead of it, however, because WinXP will be around for a long time.
In the case of the html 5 shiv it’s a little different. If you don’t use it then IE stops you from styling any of the new elements. i.e. if you put in your css that the text color of your header should be blue IE would ignore it completely unless you use a bit of javascript to essentially register the element with the DOM (to my basic understanding). There’s a difference between pixel differences and functional differences. If IE behaved like the older versions of the other browsers then it wouldn’t need the javascript fix. In CSS the respective elements (header, footer) need to be set as being display block but that’s the only issue with using the new element in the other browsers (except for PS3 as I found out last week).
In the case of the html 5 shiv it’s a little different. If you don’t use it then IE stops you from styling any of the new elements. i.e. if you put in your css that the text color of your header should be blue IE would ignore it completely unless you use a bit of javascript to essentially register the element with the DOM (to my basic understanding). There’s a difference between pixel differences and functional differences. If IE behaved like the older versions of the other browsers then it wouldn’t need the javascript fix. In CSS the respective elements (header, footer) need to be set as being display block but that’s the only issue with using the new element in the other browsers (except for PS3 as I found out last week).
And I refuse to force people to need scripts for their user agent to read markup. YMMV
Prolly why I’m more ok with CSS3 stuff than HTML5 stuff
Over 50% of the audience is in IE and the integrity of the design relies heavily on rounded corners w/ opacity. Besides CSS PIE is actually very simple use. Furthermore, its much easier to implement CSS PIE than explain the technical aspects to marketing/sales/higher-ups using IE. Its never a good thing when you need to explain to none-technical people that the browser they know well is not going to provide the same experience as one they do not. Avoiding that conversation as much as possible keeps me sane. I rather work harder to make keep the integrity intact than need to deal with defending “graceful degradation” to a majority of people who are going to be viewing the site in a degraded form. That isn’t always the case, but many times it is.
and the integrity of the design relies heavily on rounded corners w/ opacity.
Guess I’m a function-over-form kinda girl. I would agree with you if the client was a large brand like Adidas or Audi who use their web sites purely to push their global brand, where tiny stupid cutesy things like opacity really did matter somehow (not that CSS would have any involvement anyway… those people are such suckers for Flash/Silverlight it’s not funny).
Beyond that: ffffffffp. I’ve not seen a case where a lack of rounded corners or opacity made a site less usable or marketable, just maybe ugly.
But I’m willing to change my mind if I see such a site.
Well I’m not the one making the designs, but implementing. Its my job to get “as close” to designers vision as possible. Coming from a design background myself I try my best to keep the integrity of the design in tact, even if that means adding some additional code to the mix, so be it. When some people might say no I generally try my best to get things looking as envisioned by the designer.
I’ll go to lengths to get something I want visually, so I understand that. If it’s a bit of extra markup, it’s prolly going to end up in my live code.
I kinda like to draw the line at asking people to consume more bandwidth, make extra requests on my (or whomever’s) server, just for teh Pretteh. I know lots and lots of people do though. Developers differ. Plus, I don’t currently have to slave away for some graphix d00d right now, so I can haz freedomz.