Canvas uses svg, doesn’t it?
Or perhaps not 
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?
That was one reason… or, the reason was “machines” in general (these could be anything… your PDA’s agenda program could use newer tags to know where to put which data it just downloaded from a web page… yadda yadda… think “microformats” basically).
HTML5 got started because forms sucked. Since XHTML2 didn’t get anywhere, a group started working on just improving HTML4 form tags… and it kinda went from there. So yeah SE’s but not just SE’s.
Also, I’ve heard from an expert that Canvas is crap compared to SVG capability.
Prolly different things for different needs. SVG is a file format for vector images… maybe not everything you want to do is vector images? Or maybe the JS you can do with <canvas> can do more in some way you need than SVG?
I don’t know enough about either to say more than, they work differently and so likely are best for different kinds of things.
This is the guy who said Canvas is crap.
He created JS library that uses SVG/VML and intentionally ignored Canvas. I still remember him saying “Canvas is pure crap”
I hate to break it to you, but thinking <nav> will change the world is /fail. Why? Most people use a screen reader called JAWS in the US. Other popular ones is WindowEyes, NVDA, and HAL, in Europe SuperNova is pretty high up there. I will talk about JAWS, JAWS costs $900+ to buy and between $450-900 to upgrade. Before Freedom Scientific begins to start modifying their screen reader, browsers (namely IE) have to support it. Why do I say IE? Because most users use IE.
They want to! Even though the general population stats said use Firefox in 2005, JAWS didn’t support it. Screen readers on the Windows platform uses MSAA, I am not 100% but I believe Firefox didn’t play nicely with MSAA. So JAWS users literally could not use Firefox till 2007 with minimal support. It wasn’t till 2008/2009 JAWS could fully work with Firefox. So in terms of JAWS users we are around 2003/2004 usage levels. There have been things like ARIA that are pretty cool, but it didn’t take off totally. :mad:
Then to add to the complexity, to be able to use the cool jumping around stuff, like <nav>, JAWS will have to come up with new hotkeys which will be up to the user to figure out. Think as a basic user: you use gmail, facebook, and cnn/fox only for the most part, and say none use <nav> will you remember the hotkey? Would you check every site just in case? I am leaning towards no to both.
Again, as fine as all of this is, it is not the fault of the language that software makers can’t keep up or that users aren’t willing to upgrade. You are talking about the situation now, but what’s to say that 10 years down the line, the <nav> element is supported pretty much universally and is useful? You are only talking about the present time, and not thinking of how these can be used in the future.
And this is why many thinks that HTML 5 won’t be in play for very very long time… kind of sad… for at least next 5 years or so… I still see IE 7/8 being the dominant browser that won’t have HTML 5. Some believe it’ll be 10 years… I certainly don’t want to keep 2 sets of code for HTML 5 and HTML 4 just to say “Look! I got HTML 5! Can I get a cookie?”
Oh, but HTML 5 is definitely active on the mobile platform. So, my strategy might have 2 view code for HTML 5(mobile) and HTML 4(desktop)… ah well… I see more work in the future…
IE 7 & 8 do not have 6’s inertia. IE 7 will last to about the end of the year before falling under 5%. 8 will last longer simply because 9 wasn’t put on Windows XP, but it will pass with the OS because, again, it doesn’t have the same inertia.
Microsoft has lost billions in sales in deferred and delayed upgrades over IE 6. I doubt they will ever let their browser stagnate that long again.
Sorry Stomme and others replied while I was typing that, work matters needed me. Re present time: I am pretty sure that some people can say “oh IE5 will fully support CSS.” and we know it is finally making strides 15 years later. I haven’t looked at the nav spec yet. I am guessing it looks like
<nav>
<li>Home</li>
<li>blah</li>
<...>
</nav>
that saves me from doing:
<a id='nav" name="nav" tabindex='-1'></a>
<ul>
<li>Home</li>
<li>blah</li>
<...>
</ul>
saves so much!
…And now you are talking about the HTML 5 elements as though they are supposed to be there to save you typing, which obviously they aren’t. Which argument against them do you want to use?
Also, you don’t put <li> tags inside <nav> directly - <nav> is not a replacement for <ul>.
Also, I don’t think anyone really uses <a> tags for creating an anchor on the page any more… just put an id on the appropriate element if you want to jump there!
I don’t know which tags are used in a <nav> so I made a guess.
If you code skip navs, and want them to work correctly in IE you need to. Skip Navigation
Seems like a minor issue to be honest, affecting old browsers.
… and where do people get that from?!? Both are block level containers – one describes a section for what it is – a list… the other applies no extra meaning. That would be like saying “I don’t like putting spans next to anchors” – you put it in that context that’s just silly.
Same thing… Majority of layouts people put that header div into it too is nothing more than wasted markup. MORE SO if you bother using heading tags in a sensible order and once CSS3 is on the table.
In a lot of ways these extra pointless wrappers really do serve no purpose once CSS3 is real world deployable. (which for me won’t happen until I can use them as the ACTUAL CSS 3 properties without the -moz and -webkit nonsense)… NOT that in most cases they served any useful purpose to begin with. div#header and div#nav topping the list of pointless wrappers…
Though in the past I’ve seen that made even funnier when the people who throw those in then kvetch about OH NOES double wrapping the content area for content first dynamic columns and dive for endless hacks for “holy grail” type chicanery. When the extra div serves a purpose it’s wrong, but when it isn’t doing anything you couldnt’ be doing with the semantic tags inside them it’s right?
Then why was it alongside DIR deprecated as being REDUNDANT to UL? Just as S/STRIKE was deprecated as redundant to DEL, APPLET and IFRAME were deprecated for OBJECT (which IE then dragged it’s heels on ever making work right, probably because their beloved EMBED wasn’t adopted instead… which along with BGSound were also supposed to be handled by OBJECT), with IMG on the chopping block before they threw the good version in the trash and went with WhatWG’s nonsense.
Sure, rather than ride browser makers case about having one element that works consistently, using a single simple tag with a parameter mechanism to be external file format neutral – allowing for new formats or different formats to be added at a whim… Let’s instead make a whole bunch of new tags they can all implement in a inconsistent and non-compatible manner. Even dumber once you get the codec bull into it – because hardcoding the browser makers favorite pet codec into every browser is SUCH a good idea…
Of course you’ll have the people who claim to know coding saying supporting different formats from one tag is ‘too hard’ – Really… REALLY? REALLY? – funny, I wasn’t aware Switch/case or a table of function pointers (the two best ways of handling it) qualified as “too hard”.
I usually have a contact FORM. ADDRESS in it’s original intent is crippled by it being just “contact for the page maintainer, not what the page is about” which is why the number of pages that use it is minuscule. As a rule, what SHOULD go into an ADDRESS tag is stuff that I wouldn’t be putting on a website in the first place in the age of data-scraping spambots.
Because those better ways AREN’T BETTER? Lemme guess, never hit shift-esc on a well written website in Opera? Never pulled up a hopto menu on Opera Mini? Never had the accesskeys title read to you by JAWS? Never been on a phone that has an actual useful keypad that you hit one of the d-pad buttons and it pulls up a list of accesskeys and either the URL or the TITLE attribute of the anchor?
Accesskeys + Title on a .jumpto menu lets you dial in optimal on-page navigation for the user, something just wrapping <nav> around it could never do. As SP said you’d be better off using the existing ROLE stuff; even if that is a needlessly complex and convoluted approach to something that should be kept simple.
Which wouldn’t even be neccessary if people could just grasp how to put heading tags in the proper order… Throwing more tags into it just means even MORE ways for people to screw up something simple.
and that couldn’t be a codec/format neutral single tag with an attribute WHY? Oh yes, the browser makers each want to push their own pet codecs forcing us into either endlessly nesting for no good reason, or having to keep five different copies of every file encoded differently on our servers… because now ‘plugins are evil’ – right.
… and yet if you view source on most websites or look at the code of people asking for help, those elements are typically nowhere to be found and in their place you still see <p class=“header”><strong>Title</strong></p> or <td colspan=“4” class=“tableCaption”>Our Data</td></tr><tr><td class=“columnHeader”> and all the abuse of DL or tables to do LABEL’s job. much akin to people now abusing lists on obviously tabular data…
Just take a look at the average vBull4 skin for that in action. They’ve got balls of brass charging money for that.
unless you use old browsers and rely on that 
Which you do if you can’t afford an upgrade or navigate using a keyboard (and work in an enirvonment were you cannot upgrade).
Upgrades to browsers are mostly free. As harsh as it may be to those who are stuck on old versions, technology, especially on the web, is a fast moving industry, and if you can’t get on top of it with updates and supporting the latest standards, you lose out.
As for those who can’t upgrade, this is mostly in a workplace, and if those employees have special requirements for assistive technologies, it is up to the workplace to provide those, not the user.
deathshadow: I’m no longer interested in replying to your comments. You have a serious problem with being able to communicate your points, and don’t seem to realise that people have perfectly valid ways of doing things that don’t meet your dogmatic standards / methods. You are both putting words into my mouth, and assuming that just because you have seen a bad way of doing something once, everyone but you does that and it’s the worst sin imaginable to mankind.
Accessiblity experts have recommended that you do not use access keys or tab indexes, and I’m not going to try and explain why (again) because you seem set in your ways and unwilling to learn from other people’s methods.
I believe I have pointed out perfectly reasonable uses for the new HTML 5 tags. You can disagree if you want - you are perfectly entitled to - but I’m not going to spend my evening replying to your essays on why you think that is wrong in your world and how it should be done another way etc. It’s just not worth my time.
Perhaps because you can’t support any of your arguements? Sorry, whenever someone starts doing that as their reply that’s all I can end up thinking of it.
… and what “experts” would this be? Is that why the UK gov’t released guidelines on how they’re to be used on their sites? Is that why pretty much every accessibility guide out there says TO use them? Is that why it’s the ONLY keyboard accessibility method supported and seeing improvements in every browser IE8 for example dropping the extra keystroke? Blazer adopting Opera style menus? Opera expanding the menu capability to use the TITLE attribute and not just the URL?
Sure you’ll always have the people who blame programmer ineptitude on things like accesskeys and role (see that wats.ca article a while back) – something new isn’t going to fix that either… Or the other complaint which is a lack of consistent implementation and conflicts with the user agent – so rather than fix what we have we implement something else for them all to go their own way and screw up – net change zero.
You google Accesskeys you’ll get endless sites saying use it, how to use it… Care to point me at some of those alleged “experts” of yours, or is that squarely in the Lame Excuses category.
ME, I prefer to go with WCAG 2.4.1
Which is why this isn’t just my way of doing things, it’s the way things are SUPPOSED to be done according to the LEGITIMATE sources telling us how to do it… and if one reads and comprehends the WCAG, you’ll find MOST everything I’m saying is in there.
… because I’m starting to suspect you don’t know why… since you’ve not explained a thing…
Only when the other way doesn’t make a lick of sense, show me something that shows something tangibly better, and I’m on like a pig on slop. I’m just not seeing “better” here. I’m seeing a giant step sideways at best, and a massive step backwards at worst.
Shame you can’t see that – and are unwilling to actually support your claims… of course that you call the barely 2k posts “essays” puts you squarely in the “Is so is not” category; Oh noes on a website where every bit of content is text you might have to READ something.
Your loss.
– edit – and small point “It seems like everybody” and “the majority” does not mean “everyone” – and if you take that to mean everyone you are probably in the group being slighted – in which case take a good hard look in the mirror.
The fact that you think the UK Govt. are accessibility experts and that the WCAG guidelines are suitable for following completely says it all really.
Look up the WCAG Samurai, which I mentioned earlier in the thread. They recognise that WCAG isn’t fit for purpose and set out to correct the guidelines. Two of the corrections are ‘don’t use tabindex’ and ‘don’t use accesskey’. Simple.