Since it’s a fact that browsers don’t give a rat’s what doctype you use (if comparing a Strict doctype to the <!doctype html>), and since the validator can be told to test your page under any other doctype (what I do with my HTML4.01 Strict pages… test as XHTML1.0 to catch any mistakes in my “style”), there is no good reason anymore to use the older doctypes. The doctype is for the validator, and the validator can be told to test differently, so… why not?
Remember that Far Side cartoon where the guy yells at his dog Ginger and explains she can’t get into the trash anymore bad dog? All Ginger hears is “blah blah Ginger blah blah bad dog Ginger blah blah”.
Browsers are the same way.
<!doctype html blah blah blah blah… wait, there’s more stuff here, so I’ll check for certain words in here just to make sure I do my doctype switching trick right… blah blah>
<html xmlblah blah I don’t understand namespaces anyway… lang=“somelang”>
<head>
<meta blah blah content-type is text/html but I’m going to ignore that cause I was going to parse this as html anyway cause the server didn’t say otherwise and it ends with .html and charset=utf-8" so I go back to the beginning of the document and start rendering all over again cause the server didn’t tell me otherwise, not that I always bother checking server headers anyway… it depends on the weather you know…>
<meta name=“description” blah blah>
<link rel=“stylesheet” typeblahblah cause I know it’s gotta be CSS or I don’t get it anyway href=“sometyle.css” media=“screen, projection” titleblahblah>
<script type blah blah ignore src=“library.js”></script>
</head>
<body>
stuff…
</body>
</html>
HTML5 is as much a retro-spec as a bring-new-stuff-in spec. Browsers ignore lots of stuff and that won’t change, so why bother typing it out (other than a vague feeling that your code looks and feels more jawsome). Browsers understand <embed>, so they documented it. The freaks who have been using <embed> all along aren’t going to quit now, so why fight that fight? Browsers understand XMLHttpRequest, so they documented it. Those who’ve been using it all along aren’t going to stop, so it’s in the spec.
The spec isn’t as proscriptive as much as it’s descriptive. “Ain’t” is in the dictionary for that reason, not because “ain’t” is correct Engrish, but because there needs to be documentation of its use and a description of how it’s used.
as many people on Reddit, as well as large companies like Microsoft and Intel are starting to move their designs towards being more responsive
They want to add more Javascript without having to actually write it themselves… someone made something called jQuery for that. Pre-written Javascript in a pretty sugary syntax that people can plug and play without needing to know a lick of code. And an added benefit for whose who know a lick of code and have already done the trial-by-fire of writing around basic browser bugs (addEventListener vs attachEvent, this!) and welcome their new jQuery overlords with open arms.
Though where some of the newer stuff like File API come together with XMLHttpRequest version 2 (!) and new attributes like multiple on inputs does allow one to make interesting new user experiences with forms with a lot less Javascript than one would have used with HTML4/XHTML1+Javascript. Guess it depends on what you’re doing and how easily it falls back to basic stuff that every user agent should already understand whether there are scripts or not, HTML5 support or not, new DOM stuff or not.
… and in the process made a page that should only take 9k and make it take 146k on EVERY browser.
This is something I need to look into more regarding Modernizr… it looks like it’ll add a class or two for every feature you’re testing for… with yepnope it then feeds either a yep script or a nope script (though you can leave either empty) based on that support… which looks to me to me a lot of Javascript and a lot of CSS. I get uneasy when I see 50 classes on the body tag on every page.
The CSS and Javascript frameworks… seem a lot like templates. Templates are overly large and bloated, but they are that way for a reason: people who either don’t want to write code, or can’t write code, need something automatic (and flexible). So I’d say if you’re a developer you stay away from these things because your job is to write code, and if you’re anything else you stick to these things because they are safe and fairly stable, and generally backwards compatible (but only if the UA supports scripting and the bandwidth is large enough).
Simply put, a lot of CSS frameworks state that if you plug them in you’ll write next to no code and your site will work in all legacy browsers and will degrade for different devices.
You always have to add to the end of those statements “for when you don’t know how to do it yourself”. Consider a box that’s like the babelfish, and translates what you say into Chinese. This is great if you don’t speak Chinese and need to. This is something to stay away from if you are
-learning Chinese yourself
-can already speak Chinese
because the magical box, designed and built by the most brilliant of minds and the best Chinese speakers, are limited by technology and size and speed and your own Chinese speaking will be either the same level (but you are in total control) or it will be much, much better. Depending on what the box offers I guess.
Sadly, as you’ve rightly declared, HTML5 isn’t even close to being workable,
I disagree. HTML5 isn’t one big thing. It’s a bunch of small things with different labels. Some of it is quite nice and degrades excellently. Some of it is good ideas that mean nothing today because there isn’t good enough browser support (roles roles roles… roles rule and will rule more when browsers fully support them). The multiple h1 thing will probably be a Good Thing with regards to syndication when people swap articles across domains… the idea is the header levels will still make sense no matter what page the article is plopped in, because the nesting level will determine the header level. However since current browsers don’t do this enough yet, current accessibility technology cannot use it, and so today using multiple h1’s is a terrible, terrible idea. But the bright future of structure determining header level to machines (this is an idea from XHTML2.0, the ill-fated tag called <h>) is ultimately, a good thing: unless your page is static and you have 100% control over it, letting bits of your markup and content be spread among other markup and content around the web means making sure the markup structure can be corrected automatically in a way machines understand. In this case, machines understanding is necessary for human understanding.
I’m glad you mentioned Reddit because this is exactly where I picked up the CSS framework.
Reddit is where people think making text with the canvas element is a great idea.
But that first link of his has been bandied around with a bunch of others… “Let’s build a GUI in <canvas>!” is getting more and more popular, while on teh W3C mailing lists they argue about what should be done about that.
Basically, a lot of people get together and exclaim something is really cool without checking it out more deeply.
width=“30%” align=“center” bgcolor=“#FF0000”
vs.
class=“center red width30”
Yup.
The idea of better semantics and new features always sounds appealing – but really 99% of the new tags are unnecessary bloat and break backwards compatibility for no good reason.
Section and Article for example are as redundant to DIV
Div didn’t mean anything at all. Article is supposed to mean “stand-alone article” though I’m sad that some of these ideas seem to only think of blogs and newspapers… I don’t see a <houselisting> tag… but these new tags came about from some research Opera did… they looked at the classes and id’s most commonly found on the web that looked like they were describing structure. The top ones they found are mostly what they’ve added as tags to HTML5 (not sure why “post” didn’t show up then, with all the Wordpress out there).
Section seems a lot more washy to me… only thing I can think of is, wrapping a div around random tags doesn’t mean a thing (might mean, I want to use CSS to add a border around it or colour it yellow) whereas <section> does denote that the stuff here “belongs together in some kind of structure or content-based group and there’s no better tag to describe this”.
Ah. Section is the new div. Except it has a bit of meaning.
NAV seems to exist for the sole purpose of placating the people who slap div around UL’s and/or header elements for no good reason,
Nav is an excuse to add a native role of “navigation” to things people are using as… navigation. UL only means “unordered list” which could be navigation, or it could be… anything else. A recipe. A list of products. Things you did while on the toilet this morning. UL != nav; instead
<nav> = <nl> from XHTML2.0
however when people are using <nav> to replace the stupid bloat-tag div they have around their navigational uls, I am indeed a bit disappointed, and still prefer
<ul role=“navigation”>
to
<nav>
<ul>…
but the point is, with more narrowed-down meanings of the newer tags, they can have more specific default roles. Divs have no real roles. They are “some dev wanted to group this stuff for some non-semantic and non-content reason (styling, scripting, for the lawlz)”.
header just seems redundant to the existing HEADING tags,
Unfortunately people will be using <header> just to do the job of wrapping around an <h1>, but the point of it isn’t to wrap senselessly around single header tags, but to group all the content that would otherwise be <div id=“header”> (meaning, more than one tag in there that contains content that is, when put all-together, the heading of that document… or article, or whatever).
…
and then you have the completely pointless new media tags.
AUDIO and VIDEO are redundant to OBJECT – there is NO reason that new functionality couldn’t have been applied to that.
The point wasn’t so much new functionality… it’s that object doesn’t say what something is. Which they wanted to do. Just as <div> tells the UA little, <object> tells it very little as well… which in the beginning, the creation of <object>, that was the point. This was back when the proponents of XHTML wanted to remove <img> tag and have <object> have pretty much zero meaning… it only says “some other file embedded in this page” and nothing more. Could get ridiculous and stretch that to anchors.
Canvas on the other hand is useless without javascript, so why the hell does it even exist as a HTML element in the first place. That would be a lot more useful if we could use .js to draw inside ANY element. There’s literally NO reason for CANVAS to exist as a HTML tag…
I haven’t figured out the point of canvas either, but I need to read up more on it.
If anyone working on HTML5 could jump in and explain why there’s a special tag for drawing on, rather than just updating the basic DOM API to allow drawing on anything anyway… I’d love to know.
