I have done a couple of fairly complex layouts in HTML 5 now. I find myself only using div’s for elements that I’m anchoring graphical effects to that have nothing to do with the text content.
For example, in a layout with fixed headers and footers where the body scrolls underneath them. To get this layout to work even when there isn’t enough text in the body to fill out the page a div the with of the header must be placed under the heading, and the same for the footer
(Merely using body padding here doesn’t work, or at least I can’t figure it out). Those divs serve no other purpose, and when the media constraint drops width below 500px the header and footer go back to being inline and these divs are set display: none.
Anyway, all my text content is landing in semantic tags, section, article, aside, and so on. Divs seem relegated those last remaining layout structures that CSS can’t entirely deal with on its own. At least this is the direction I find myself going (along with trying to find a way to eliminate them entirely).
I can see using the tag much less now though. And honestly, about time.
Anyone else make discoveries in playing with HTML 5 - particularly with regards to how their layout styling might change?
For me, I only focused on HTML 5 features and not on semantics… but a good question indeed. I’m sure Divs will still stick around for HTML 5 and maybe it’ll be used more specifically. As of now, a lot of people use Divs for… uh… everything but now that there is new tags available we can start using them. But, if I need to group bunch of tags then I’ll still go for Div. For example, I may have <div id=“menu”> but no <div> within that context. Perhaps, Div will be main used off to separate the section. If that’s the case, I’m all in.
For the most part if you aren’t seeing less DIV, you’re using HTML 5 wrong. The entire point of the REDUNDANT “section” tag is to supplant div in most cases.
Many of the new tags also seem to exist JUST to replace the DIV’s people were putting in their markup for no good reason in the first place (see “nav” and “header”) – which is why with the loosening of the rules to the point of “slap any style of html/xhtml in there, it’s fine” I call it the new transitional and a step BACKWARDS a decade in coding practices.
Sure, they try to sell those new tags as being ways to have simpler accessibility than things like accesskeys and skipto menus, but when it has nowhere near the functionality or usefulness of those even in the user agents that support them (wait, which mobile UA’s support them again? Even webkit based don’t do it yet) isn’t as useful to the end user as a properly written accesskeys menu. (in the browsers that support them like Opera mini)
Others like section and the new use of heading tags is just to deal with people not being able to grasp the point of heading tags or the order/methodology of their use – but of course since many can’t grasp that, those tags will go unused/abused just as before… With people being unable/unwilling to learn that tags like LABEL, TH, CAPTION, LEGEND and FIELDSET even exist, much less tags like ABBR being abused for nonsense like “microformats” – adding more tags at this point in time is NOT the answer.
Of course, sg707 hit upon the real reason that they have decided to move every other unrelated NON-MARKUP technology under the HTML5 banner – on it’s own just talking what is ACTUALLY HTML, HTML5 offers NO REAL IMPROVEMENTS for the end user and nothing fancy to really look at either. This is why the “gee ain’t it neat” redundant nonsense like AUDIO and VIDEO were added, and elements that shouldn’t even HAVE tags since they’re nothing but javascript hooks (CANVAS) were created.
You take away all the stuff that has NOTHING to do with marking up actual content on a page and the stuff redundant to existing tags (like OBJECT) and what’s left? Some goofy semi-semantic tags that are unnecessary, overcomplicated and shouldn’t be enough of anything useful to impress ANYONE with more than two brain cells to rub together.
All the really good stuff is in CSS3, takes javascript to be useful, or you end up having to double check again anyways server-side.
But yes, it’s kind-of the point of tags like SECTION, ASIDE, NAV, et al to make you use less DIV, and less ID’s and classes.
OF course if like me you usually only have extra DIV to divide up SECTIONS and as presentational hooks to make up for CSS2’s shortcomings and not for semantic reasons… After all, DIV applies no extra meaning to it’s content – and content should have enough meaning thanks to lists, headings and paragraphs not to need it extra semantics applied to them.
READ what was said in that sentence, not just the part you decided to snip.
Which is javascript, not markup.
Which is javascript, not markup.
Which is javascript, not markup.
Which is the only necessary for web apps, which are by their nature… javascript. If you don’t use it on anything simpler than a web app, that’s no different than hitting “save as complete”
In other-words, all the things the REST of that sentence EXCLUDED before the statement you quoted! “counting what is just HTML” as in what is JUST useful markup; excluding all the javascript stuff and codec stuff. The sentence is SAYING they’re taking a bunch of stuff that has NOTHING to do with HTML, aka markup, and slapping it under the HTML5 banner because without it – there’s very little for developers to get excited about.
Ah gotcha! Somehow that one sentence came as a red alert to me. Yeah, I’m not excited about new semantics as well. I’ll use it if it’s there but nothing that excites me.
I’m guessing you either don’t use id attributes or do the “div div div div div” stunt. When everyone and their aunt bertha is placing <div id=“nav”> and the like in documents, maybe it would be simpler to read <nav> y’know? Just maybe…
Aside from semantics, canvas, audio and video tags will see use.
Death, the more you post the more you sound like a veteran programmer with next to no experience with PHP / HTML and CSS. You make accusations about those three that are baseless or outright false much of the time, and while you know your programming theory better than most web programmers - hell probably better than I - your arguments often make the sort of mistakes only someone with a lot of experience could make.
That and an healthy level of nostalgia.
Your irritating, in an entertaining an insightful way, but irritating because you rant constantly and never rave. Also, constantly belittling other programmers in your posts is hardly endearing or polite.
I do if there’s a reason to have it there – like for a presentational hook because CSS2 can’t add them itself. (while CSS3 can – when CSS3 is real world deployable not needing the “for testing not deployment” -moz and -webkit nonsense, I’ll be making a LOT less markup)… But I get annoyed with the constant “slap a meaningless container around a UL just because” routine. Code for nothing is code for NOTHING, no matter how you try to color it. This is how people end up with 1 megabyte websites with 200k of markup and 400k of javascript just to deliver 3k of plaintext…
Well, it does give me a different perspective which is why I come up with often radically different conclusions. To say I have no experience with them (8+ years) is funny – if you look at the directory of rewrites I’ve done for people that can quickly put the CSS/HTML knowledge to bed.
I’m just constantly amazed how people miss the point of HTML, don’t see the advantages of separation of presentation from content, fail to grasp the “cascading” part of “Cascading Style Sheets” and in general just slap DIV and CLASS on EVERYTHING for no fathomable reason other than to make more markup for NOTHING… to go in hand with the javascript for nothing that’s rapidly flushing every new website down the toilet before they even launch. (the last part of that is NOT me talking as a programmer, but a user… Dan called Ajax the new framesets – he wasn’t kidding).
Remember Dan Schulz? I’m the guy who taught him how to write code in the first place… he’s the one who made me embrace semantic markup and separation of presentation from content.
I was taught that we belittle each-other so we can make things better - but I run up against that issue whenever dealing with people from outside New England. “Ya cahnt geht theyah frum heeyah” isn’t a stereotype, it’s a way of life… of course that period of military service (which is how I got to see what a hole the rest of the planet is) doesn’t help.
I’m constantly shocked at how thin skinned people are over the simplest of things. Taking offense at things that’s just normal conversational speech to me.
You know, you see the freezing homeless guy, say “what ahre yah, freaking retahded?” and then give them the shirt off your back and invite them into your home.
A LOT of times the way people react online to stuff I’d say to someones face makes me want to say… well, I won’t say it. It involves growth of two items… you might call it a pair… but I’ve become increasingly intolerant of the “I’m ok, you’re ok” tree-hugging feel good encounter group drum circle crowd. Status Quo for the win – NOT. If there’s ANYTHING I’ve figured out in my 42 years on this planet is the only way things get better is if you tear them down to the ground and build them up. You think somethings manure, call it manure.
Or as George Bernard Shaw put it: The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.
Have to say, looked at your directory of rewrites, and picked 3 random ones… one was an HTML Turk template which looks farmed out from somewhere, the others go against a lot of the best practices you’ve been trying to impose on everyone else in other threads! Colour me not that impressed I’m afraid!
There is a difference between constructive criticism in order to help each other, and just plain rudeness, which is what comes across from you a lot of the time it has to be said.
Anyway, as for the topic in hand, you don’t think the new form input types in HTML 5 are useful at all? I think there’s a lot of good stuff here I don’t see how you can be against the new element types - replacing <div id=“nav”> with <nav> has got to be better, for example. Screen readers could provide a way of easily getting back to the navigation for example. How is that not a bonus to the end user? Or, for example, skipping reading an <aside>, another machine can parse a page for <articles>, many many uses I can think of without really trying. To say it offers no improvements to the end user and nothing new to look at is a load of rubbish.
Three years ago I was enthusiastic about them… right up until I tried them.
Much like javascript verifications I don’t see the point anymore – since you cannot EVER trust client side validation and have to recheck everything server-side anyways… and the number of times there’s enough errors to have a OH NOES submit and rejection resend just isn’t offset by the increase in complexity… much less bandwidth even when they fill it out properly.
Though at least with HTML5 there’s no real bandwidth penalty for it – but it’s nothing I can’t live without or would get excited about.
… assuming you believe in putting DIV around a UL for no good reason in the first place. When the element it’s replacing has no place in the markup to begin with, what’s the point. Rather than encouraging people to use more markup for NOTHING, maybe we should be encouraging them to use less code to do the same job. MENU was dropped in 4 as redundant to UL… Now we are wrapping that UL why? If we’re going to throw the intent of STRICT out the window, I say drop NAV, bring back menu, and say MENU is for menus and not just some specific menu type that makes people as unlikely to use it as they are ADDRESS.
Which a properly written accesskeys .jumpto menu and the ID on the UL can already accomplish? It’s cute, but it’s not providing anything NEW – and I’ve not seen any implementations using it that’s superior to pulling up a accesskeys menu in mini. (or Opera desktop for that matter).
It just seems like taking something simple and making it more complex than need be – and recreating things we already have been given the means to do… that nobody can be bothered to do properly with what we have…
The ACTUAL HTML parts of HTML5 that aren’t pointless redundancies don’t really do anything new… they just do it different.
Though I’ll admit, IF we can get people to embrace them and IF user agents can finally agree on how to implement them (YEAH RIGHT) then fine – I just don’t get why we can’t get people to embrace what we already have…
Just like I don’t get why browser makers are implementing HTML5 and CSS3 when they all still have gaping holes in their HTML4/CSS2.
Honestly though – I don’t really have as big a problem with those elements (except section which to me is pointless since DIV’s original purpose is to divide content into sections) as I do AUDIO, VIDEO, EMBED and CANVAS – the first three undoing the purpose of STRICT (since they’re redundant to OBJECT), and the last one having no business being a markup element.
I do suspect that they made SECTION because people have been abusing DIV for so long they felt the need for a clean break from it – so people can keep abusing DIV for wrappers and sandbags while keeping SECTION clean…
Which would be fine and dandy if CSS3 didn’t mean that 99% of those extra DIV can be axed…
But really the issue as I see it is that most people can’t be bothered to use half the tags we have now properly if at all (again, th, caption, legend, fieldset, label) – I don’t see adding more tags improving that situation.
You don’t use a mobile device much do you? Also, “placeholder”, and the various input types aren’t useful?
I think you got it all wrong. Once all the browsers get it sorted out, I think the value of HTML5 and CSS3 is less JS. CSS3 alone is wroth the trouble: embedded fonts, RGB colors, shadows, transparency, etc, etc. All in CSS. No more hacking js or png images.
And forms in HTML5? Finally, I can tell the browser; this field is a phone number or this field is an email and should look like it. Or this field is required.
Sure I CAN do this now, with js. But I want less code. Not more.
Now the section tags… from what I see they don’t do much except replace divs. But maybe’s that’s the point: organization - organizing your code.
It depends on the structure of the page - if you are splitting the site up into sections then it makes a lot of sense to keep the hierarchy right. Lots of people don’t like putting a <ul> as a sibling of all the <div>s if they can help it.
Menu wasn’t equivalent to ul at all, and wasn’t solely used for navigation either.
I use <address> all the time… don’t you? It pretty much goes on every site I do as they all have contact details somewhere on the page.
Access keys are for individual items, not the navigation as a whole. As for ‘jump to menu’, why bother littering the HTML with pointless ‘jump to’ links when these new, better ways now exist?
<section> carries semantic meaning that <div> doesn’t, and also does things like set up a new context for heading hierarchies as well. Not the same thing at all.
I don’t see why not. It tells a user agent what to expect in that place, and can handle the content differently for video, audio, canvas etc
Like I said, they are different, so I doubt it.
Speak for yourself. I use them all the time, and I suspect rather a lot of people here do as well.
Not only that <section> carries semantic meaning, it’s HEAVY with semantic meaning, which makes it the most confusing element ever.
But to further discuss this properly, give me a good reason and example of how you use <section>, and I’ll give you the reason, and that same example twisted around <section>'s very very loose semantic meaning, as to why you will ALWAYS take the risk of having what you thought to be a good example turn into an irresponsible mess.
You know, I kind of get tired of all of these “because most people aren’t doing it, who cares” arguments.
I use good programming practices.
Stormrider uses good programming practices.
Many many other developers use good programming practices.
Just because some or most people don’t use good programming practices, we should stop working to improve them? I use just about every HTML element that we have now, when I have the appropriate need for it.
Just because Joe Smith puts everything in divs and spans and uses inline styles, we shouldn’t develop new semantic elements like address so I can specify a block of code is an address and not instructions for cooking pop-tarts?
That’s like saying because most people don’t know how to use Linux, we should just stop worrying about making it better because only some people will get use out of it.
replacing <div id=“nav”> with <nav> has got to be better, for example. Screen readers could provide a way of easily getting back to the navigation for example.
Hm.
DS already brought up the point of, why do you have <div id=“nav” there? So I won’t repeat it (have I had boxes wrapping navs? Yeah, for CSS to do multiple backgrounds on… otherwise, ul is a block like div is a block).
I will update about the screen readers:
First, you don’t need <nav> for people to skip to it (or skip over it). If you have anyone sighted, using a graphical browser and then not using a mouse or stylus, you want skip links ANYWAY.
Second, I predict <nav> will end up wrapped around every semi-navigational list, making the original idea of it impotent. The original idea being, <nav> = “main site navigation”. This is fuzzy enough right here before you get people high on HTML5-aid using it much more liberally.
And the only reason <nav> would be of any user to someone with assistive technology is the role that element gets by default (which no old browser will see but for example FF4b does understand HTML5 and so does assign a role of “navigation” to nav elements). If your reader is newer, you can navigate by role, and yes, this is sweet (if you like to use it).
But you don’t need <nav> to put the role of “navigation” on the “main site navigation”. You can use landmark roles TODAY with HTML4. And XHTML1. Or whatever.
Currently there’s still bugs with roles AND the specs are still working themselves out with these. The bugs are in browsers and AT software and so HTML5 and screen readers is not a good combination at the moment. I’m sure it will be gee-whiz awesome in a year or so, but not right now.
Jason Kiss has an awesome list of tests with HTML5 bugs if anyone cares: Accessible Culture | Web Accessibility Research and Consulting (and not limited to HTML5 but still…)
As for ‘jump to menu’, why bother littering the HTML with pointless ‘jump to’ links when these new, better ways now exist?
Because these new, better ways don’t work with
-keyboarders?
-older browsers?
-older AT (accessibility technology)?
I don’t even use skip links for screen reader users unless they feel like navigating my sites the slow way; they’re for sighted keyboarders.
Though this doesn’t mean browser vendors won’t implement something… I mean, each browser does have keyboard shortcuts for stuff. Why not Navigation-By-Element-Type?
I wanted to repeat this (DS answered it first):
Web Sockets for bi-directional channel between client & server
Web Workers to utilize multiple cpu
Web Local Storage - no more cookies!
Web Cache - able to use the site offline
Above is a very short lists of HTML 5 and I’m sure there’s a lot more.
These are on Bruce Lawson’s B*tch-list for being associated with HTML5. The closest one can come to a lot of this hawt new l33t fun stuff is <canvas> is an HTML5 tag… beyond that, Bruce proposed NEWT as a name for these things… so HTML5 will mean markup. Boring old tags.
Since they aren’t a bandwidth cost, why not use them to help users put in the RIGHT information the FIRST time? Which is all it does.
Currently it’s just iWhatevers, but I like where that’s going: their on-screen “keyboard” creates @ buttons when the input is type=email for example. If this doesn’t spread to more mobiles then it’s mostly pointless (well, another way to reference an input without a class or id…) but I expect it will.
Placeholder, we all know will become another excuse trendy designers use to not add adequate labels. “Oh I don’t have room for them” “Oh labels are so ugly and so… 90’s” “Oh but now we don’t need them!”
I’ve already heard these so I’m just waiting for everyone to do it. Like the 9px light grey text on white thing. Ug.
Though that autofocus thing bugs me. YOU the author shouldn’t be telling ME the visitor where my focus goes unless I set that (cookie or browser or something).
Cause HTML5ers already brough MENU back from the dead, but gave it other functions, so no can use for menus anymore. Braaaaaiiiiinsssss…
That had better not be the reason they start using <nav>, nor where! (But I think they will)
What little I dare do with it (until browsers and AT can actually work well it… and well, until the two sometimes-contrasting specs actually can decide on something), it’s mostly styling hooks other than classes and ids.
I suppose whenever I can leave IE6-8 behind I could totally go for the whole <header> <footer> thing for even more per-element styling instead of tokens… but I’m not willing to require Javascript just to get browsers to read… markup.
They should be able to do that on their own. So, it’ll be a few years for me.
I’m well aware of this and using the <ul id=“nav”> etc, but I responded to this point above. Lots of people are uncomfortable with having <div id=“header”> and <ul id=“nav”> as siblings, and as you say, you may need the div for CSS hooks.
Once the browsers implement HTML 5 properly, it should be their job to provide keyboard shortcuts or buttons etc to skip to various types of content, not the website author to provide links. Same links for the WCAG Samurai group saying you shouldn’t use access keys or tab indexes - it’s the user agent’s job to provide decent keyboard navigation, not implement your own key shortcut standards specific to your site. Most user agents provide perfectly good keyboard navigation themselves without website authors screwing things up with an unintuitive tab order or keyboard shortcuts which can override the browsers own shortcuts in some cases.
Perhaps, but the fact that it might get misused isn’t a problem with the element itself. Bit of a red-herring argument.
Same links for the WCAG Samurai group saying you shouldn’t use access keys or tab indexes - it’s the user agent’s job to provide decent keyboard navigation, not implement your own key shortcut standards specific to your site.
You get points for WCAG Samurai Group. ++ needs a webcomic tho
Most user agents provide perfectly good keyboard navigation themselves without website authors screwing things up with an unintuitive tab order or keyboard shortcuts which can override the browsers own shortcuts in some cases.
Why I don’t use or recommend either of those (yeah, I saw Crusty mentioning one of them). Skip links, however, do not interfere with anything. They are navigation links any other navigation links.
Perhaps, but the fact that it might get misused isn’t a problem with the element itself. Bit of a red-herring argument
Might?
My argument is, the tag will be close to useless for any kind of navigation because it’s unclear (go visit HTML5doctor.com and see for yourself) where it should be used and people have been using it on every somewhat-kinda-navigational something-or-other (including… search forms), making it non-usable (because you’re only going to use something when it works on more than one web site, right?).
This doesn’t mean it won’t label those elements to some kind of machine or program as “something to do with navigation” which, if that’s the only goal, the nav will do that.
Well except where roles conflict. For example, do we know what a browser who understands roles will do when an author puts a role (like “navigation”) on an element with a default role already (like “search”) or wraps one such element around another, and they are deemed conflicting?
(where to find the list of what roles conflict? Well there’s apparently a different list depending on whether you grab it from WHATWG or W3C so I guess we don’t know at this point… so, who feels charged and ready and brimming with enthusiasm to redo their web sites once some of these specs finally get nailed down, if it turns out something you did conflicts with settled specs? Joy.)
While I’m not excited about semantic tags but weren’t they created so that search engine can do a better search? Because of this, wouldn’t people who care about SEO embrace this tag?
Also, I’ve heard from an expert that Canvas is crap compared to SVG capability. He said that somewhere along that SVG creates “instances” of graphics while Canvas is just one big object. So, if you’re having any sort of interaction graphics like “live stock graphics” then SVG is the way.