Moved over to HTML5

[markbrown4]

I completely missed the earlier thread, I read 90% of it until my head hurt. I think it should be ok to start a related thread if we can keep it on track. There were valid points raised by each person who contributed to the last one.

Nearly all HTML5 threads end up debating the usefulness of the semantic tags(section, article, header, footer, nav etc..). I find that almost pointless.

Those tags are the least of HTML5 in my opinion and their use is hard to defend.
Requiring js to style those tags in IE is a big deal, wrapping nav around a list that would suffice is a waste.
But, if you'd like to use them I won't lose any sleep, I more put it down to personal coding preference.
I've seen uses where those tags can make code look more readable, though I still don't see strong reasons to use them personally.

Other tags, like samanime pointed out are quite useful like <time>, these provide valuable semantics to a page that HTML4 didn't. Again, reading code with these tags makes them more readable. The variety of tags isn't a problem in itself. It was aimed to pave the cow paths and implement semantics for things that people were coding over and again with meaningless tags like div/span.

People who call these garbage don't understand why they were added.

--
Enough about the semantics already. HTML5 was designed for web applications. Let's talk about that instead.
--

The really interesting parts of HTML5 that set it apart are Forms, Rich Media(Audio, Video), 2D/3D Graphics(Canvas, WebGL, SVG - though not technically part of HTML5), Offline, and the other Javascript API's(localstorage, db, geolocation).. among others.

• HTML5 Forms should be used - one strong reason is that using the new types enables mobile browsers to switch keyboards for the types. - There's heaps of great additions to HTML forms, validation, placeholders, speech input.
• Rich Media is painful and inconsistent - but adding these to the specs is the right move, don't hate progress.
• Offline should be used - when relevant to an application.

The Javascript API's are the most of HTML5.

• Geolocation Flipping Awesome! should be used - when relevant to an application.
• WebSockets - Flipping Awesome! should be used - when relevant to an application.
• Web storage - More processing is moving client-side, you're not going to stop it. This enables another level of interactivity and responsiveness to applications.
• History API - make applications more responsive with partial page updates and keep your history.
• 2D/3D Graphics are flipping awesome! Seriously, these are game changers for the web as a platform. Being able to build interactive animated graphics with SVG or Javascript pushes the boundary of what can be achieved - and is much of the reason that Flash is being replaced.

Oh yeah, and everyone is on the same page with the doctype, use it.

I'm bored engaging in arguments about those 5 debatable semantic tags, the point that HTML5 is to support Web Applications and richer experiences on the web.
Not all web developers need to use these features, so HTML4 is fine. But if you're building a rich, interactive web application you'll want to look at some of these features.

--
When people ask if I use HTML5 or not I normally say "I just use HTML, HTML5 isn't an entirely new version, it's just a collection of new features, I use the parts that make sense."
I've had people say "Oh, if you can use HTML5 that would be awesome", I understand the misunderstanding of what HTML5 is, just nod and say sure.
It's strange that the general public should know about an HTML specification, or care

[markbrown4]

I should probably ask some questions to generate some discussion.. "Is HTML5 ready for prime time?" is the wrong question to ask because it's just a collection of features, some are well supported, other aren't at all, many require javascript polyfill's for consistent implementation. I just keep hearing people on the forum say don't bother with HTML5 & CSS3 and I don't think that's good advice at all.

Which HTML5 features do you use?

If none, then when?

With browsers that push new releases frequently like Chrome and Firefox - do you only support & test the latest versions?

[Stomme poes]

Which HTML5 features do you use?

I don't use the APIs, but that's mostly because I haven't built anything that would use them. I'd be okay with stuff like LocalStorage, History, video/audio with Flash fallback, because these things degrade well and mostly when Javascript tests for support for these things, it's usually correct (there are some things the browser will report back "Yup! I support this!" when it doesn't, arg). GeoLoc isn't HTML5 but similar, I have yet reason to use it.

I use:

• Shorter doctype: I can always tell the validator to pretend it's XHTML for finding stupid errors like unquoted attributes or unclosed li's/p's etc.
• Shorter other things: since browsers' error rendering needed to be able to read charset="somecharset" because so many developers misplaced the quotes, <meta charset="utf-8"> works, so why not? I drop types of link elements linking to CSS files and I'll drop the type for Javascript except when I'm debugging (Firebug etc complain when there's no type).
• ARIA isn't HTML5 but I use it, on HTML4, XHTML1, whatever. It's all good.
• I've used <time> and <mark>, since both degrade to either inline elements of no value (most browsers) or to nothing at all in IE (totally acceptable, in my view). If they're seen, great. If not, *shrug*
• Most of the new form input types. Color type is useless and horribly does not fall back well: the expected typed-in data is a hex value. Right, soccer mom's gonna know a hex value. And it's apparently not meant for e-commerce, which was the first thought I had for it: choosing the colour. But doesn't work that way, seems to be made for online PhotoShop or something really specific and weird. Whatever.
  Also CSSing and Javascripting the new input types makes things more code for parsers, yay: isntead of input[text] or input.type=text, you're now adding a bunch of things. So now it's either a class or a regex, and it wouldn't surprise me if this didn't slow a parser down somewhere.
• I don't use the form validation much because the default error messages are horrid and don't help users. Overriding with Javascript sounds like extra work that could be avoided by just not having validation in the HTML and just have server-generated error messages on submit and possible Javascript validation on the front to catch people before they submit. Opera's "hey use a title for the error message and it'll get added to the error box" is super retarded, and hurts users who see title tooltips and screen reader users who generally hear titles on inputs. Plus the language issue.
• I don't use stuff that should degrade well but don't, like <details>. Chrome's lack of keyboard support is bleh. Not sure what those guys were thinking. You can Javascript the heck out of it, but since it's supposed to be replacing "common" Javascript, might as well stick to good old Javascript and HTML4 in those cases.
• I'm very careful with placeholder attributes, and generally don't use them. User testing shows people see things filled in and on a long form where users may be skimming, the input may seem "filled" and people love to assume a filled-in default is all they need, so oops. Autocomplete is unfortunately on by default. I find this a violation of user privacy and security and it seems one cannot set this OFF on the form?? but has to set it on every single input who might have the attribute?? Arg, what a horrid design choice. I hope they reconsider, if this is still the case... it's been a few months since I looked at it last. The developer should be adding it in, not having it in by default. Unfortunately many developers might not realise their forms are treated as HTML5 by browsers with the HTML5 parser no matter what the dev thinks s/he's writing. HTML5 guys say browsers should offer the user the ability to turn these things off, but so far, that's not been built.
• No canvas: still needs accessibility work, but it's encouraging to see that some stuff's gotten done and it looks like making it accessible will be possible. But also, haven't had a need for it either. I'm not making games or interactive charts and graphs (but if I were, I'd prolly use raphael.js or flotr with a normal DOM instead).

That "using the shiny new stuff makes your site future-proof" is a poor argument for most sites. The old stuff is not getting dropped, not for a decade or more. Chances are, your site is not going to last more than a few years, let alone a decade, without either vanishing or getting rewritten anyway.

If none, then when?

Each new thing: when it's stable, then when it's got enough support AND falls back well, doesn't increase more Javascript coding on the front end to "fix" new defaults, and is applicable to the site and actually improves the user's experience rather than just being the new shiny thing.

I'm not a fan of polyfills in general. I'd rather a functioning site that looks a bit fuglier for older browsers than that older browsers have to download a bunch of extra stuff and run extra scripts for a performance-slowing poor imitation of native new things. But I suppose that depends on the client, the visitors, and what's going on.

With browsers that push new releases frequently like Chrome and Firefox - do you only support & test the latest versions?

Only if I have them. Like most users, I have periodic updates, and being on Debian using the Ubuntu release cycle (6 mos) I'm usually behind Windows users who update when the browsers do. This means I'm likely to be one of the last groups to update anyway, so if a bug was fixed I feel I'll probably have most users with teh bug-fix version, meaning maybe I can use something now. Same goes for CSS3 and ARIA stuff.
IE needs stats from the users the site is serving. If there's IE6 or 7, even 8... I'll consider using less new stuff because I'll be spending the time building extra images or elements or whatever anyway. It's not like this stuff is going to stop working in the future so future-proof is not an issue.

I don't even own a machine who has the drivers and capability of even doing WebGL. I'm thinking only people who've bought new machines anyway, or are web developers, have this. Most of the people I know who are not "computer people" have older desktops. If these are my users, I wouldn't think of using it then anyway. Nobody is going to go buy a new computer so they can see your WebGL. Unless you're giving them out for free :)

[markbrown4]

That seems like a pretty solid approach to me, I pretty much agree with everything you wrote, just a couple of points to clarify.

GeoLoc isn't HTML5 but similar, I have yet reason to use it.

Geolocation is part of HTML5.

I've used <time> and <mark>, since both degrade to either inline elements of no value (most browsers) or to nothing at all in IE (totally acceptable, in my view). If they're seen, great. If not, *shrug*

The elements are still available in IE, the only issue is that you can't style any of new semantic elements in anything less than ie9 without the js shim.

Also CSSing and Javascripting the new input types makes things more code for parsers

I might not have understood you correctly, but we don't need to worry about the browser coping to parse more tags & attributes.

No canvas: still needs accessibility work

Hmm, I don't know how important this really is - you can always provide hidden alt content that isn't visible on screen. But most of the uses of canvas I've seen don't really make sense translating to text, I wouldn't expect much being done about it other than a method for providing alt content.

I'm not a fan of polyfills in general. I'd rather a functioning site that looks a bit fuglier for older browsers than that older browsers have to download a bunch of extra stuff and run extra scripts for a performance-slowing poor imitation of native new things. But I suppose that depends on the client, the visitors, and what's going on.

You're right that it depends on the feature - if it's just visual reward we're talking about then I too don't always fill in the gaps with css/js for older browsers.
But for many of the js api's a js polyfil makes sense and is necessary - e.g. json2, excanvas, svgweb, localstorage etc.
The biggest reason to use them is to make the code much easier to write in a standard way. As time goes on I'm more willing to trade performance in older browsers with my own development performance - At some point we expect old browsers to behave badly with new code, or we just stop supporting them at all.

I don't even own a machine who has the drivers and capability of even doing WebGL.

Really? I haven't used WebGL myself yet but I hadn't actually thought about it requiring capable graphics cards to work. This is a very good point, I'll need to look into it.

[Stomme poes]

Geolocation is part of HTML5.

http://isgeolocationpartofhtml5.com/

Like ARIA, it started as part of the HTML5 specs way back when. But it has been removed. This may not matter, especially when we've got people throwing regular JS and CSS3 in with "HTML5", but I'm being technical.

The elements are still available in IE, the only issue is that you can't style any of new semantic elements in anything less than ie9 without the js shim.

Only if I'm already using the shim. No reason to add this for elements who don't make a difference in browsers who can't read them anyway. With other elements like <header> and <footer> it matters more since they are meant to be block containers and for JS and styling reason they'll be used for DOM navigation, but <time> and <mark> don't and yeah, that's one of the reasons I'm more willing to use them: they degrade better.

I might not have understood you correctly, but we don't need to worry about the browser coping to parse more tags & attributes.

I mean in the way that there is now simply *more* code, period, in the instances where before you would have only either "input" or input[type=text] to style most of your inputs, and input.type=text for Javascript, now when there are more types, if you are doing code by types, you now have more code.
I've been regexing them in my Javascript. It's not a big deal, but that didn't happen with HTML4 forms.

You're right that it depends on the feature - if it's just visual reward we're talking about then I too don't always fill in the gaps with css/js for older browsers.
But for many of the js api's a js polyfil makes sense and is necessary - e.g. json2, excanvas, svgweb, localstorage etc.

Yes I meant mostly the visual stuff. Having Javascript imitate something that's using Javascript anyway when it is supported, isn't a big deal. You've already made some amount of commitment once you've decided you're going to use those APIs.

Hmm, I don't know how important this really is - you can always provide hidden alt content that isn't visible on screen. But most of the uses of canvas I've seen don't really make sense translating to text, I wouldn't expect much being done about it other than a method for providing alt content.

Canvas is being used to create forms and GUIs. Yes, the creators have said (mostly to themselves) that this is a mis-use of canvas. Too late, you don't create addictive things and then blame people for using them all the time.
Anyway, with canvas there is no "alt". The only thing canvas has offered is a default content for browsers who don't know what <canvas> is, nothing more. It otherwise does not have a fallback... which makes the way <video> and <audio> tags work even more of a plus, when you realise you can nest <object>s and then more alter-children inside those... always something for the user, which is great. Canvas, no.

The problems with canvas are: there is no DOM, so no way to programmatically know what elements are, objects are, states are, and where things sit.
Things are then naturally unkeyboardable, cannot show keyboard focus, and cannot return states or settings or parents or children to the Accessibility Layers of the browsers running them. Screen magnification does not work, since things are built in pixels and there are no "objects" who have relationships with each other. Canvas is used mostly for interactive presentations: users do things, so plain text is not a suitable alternative. (I think this was what you meant? There are many other things that are accessible who also don't translate well to plain text, of course).

Now they are working on this, and I think it was at CSUN there were some updates on some things working. http://wiki.whatwg.org/wiki/Canvas shows some of the things going on so far. Here's a bit of discussion also: http://lists.w3.org/Archives/Public/...2Mar/0230.html and some more, specifically hit testing: http://www.w3.org/wiki/Canvas_hit_testing
Doug Schepers also had a proposal to merge the API of canvas and SVG somewhat as well... http://schepers.cc/retain-a11y-immediately#more-488

Really? I haven't used WebGL myself yet but I hadn't actually thought about it requiring capable graphics cards to work. This is a very good point, I'll need to look into it.

I think it was also a driver issue. That is, I went to the Chrome WebGL demo, the one with the fish tank and the sharks shooting lasers out of their eyes... I had a new-enough Chrome, but got a message that I didn't have a good enough driver. Could also be the video card. Changing that is pretty simple in a desktop... my machines are laptops.

Find a machine you think is kinda old and find that Chrome demo and see what message it gives you.

Somewhat off-topic, but there they go again: dev.w3.org/html5/status/issue-status.html#ISSUE-164 (hgroup... fight fight fight)

[markbrown4]

Like ARIA, it started as part of the HTML5 specs way back when. But it has been removed.

Oh right, I guess they are removing the JS API's because it confused people.

Only if I'm already using the shim. No reason to add this for elements who don't make a difference in browsers who can't read them anyway.

No, that's not right. The text content is still visible - it's only that you can't style them in ie9<

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>untitled</title>
<style>
  time { color: #999 }	
</style>
</head>
<body>
<p>It was posted <time datetime="2011-11-12T14:54">a while ago</time></p>
</body>
</html>

The problems with canvas are: there is no DOM, so no way to programmatically know what elements are, objects are, states are, and where things sit.

That's not a problem, it's a design choice, but I do share the peeves and SVG does seem like a more natural fit with the other web standards.

Canvas is being used to create forms and GUIs. Yes, the creators have said (mostly to themselves) that this is a mis-use of canvas. Too late, you don't create addictive things and then blame people for using them all the time.

Anyway, with canvas there is no "alt". The only thing canvas has offered is a default content for browsers who don't know what <canvas> is, nothing more. It otherwise does not have a fallback... which makes the way <video> and <audio> tags work even more of a plus, when you realise you can nest <object>s and then more alter-children inside those... always something for the user, which is great. Canvas, no.

Things are then naturally unkeyboardable, cannot show keyboard focus, and cannot return states or settings or parents or children to the Accessibility Layers of the browsers running them. Screen magnification does not work, since things are built in pixels and there are no "objects" who have relationships with each other. Canvas is used mostly for interactive presentations: users do things, so plain text is not a suitable alternative. (I think this was what you meant? There are many other things that are accessible who also don't translate well to plain text, of course).

I think <canvas> is a lot like <img>, I don't think of it as an interactive document like you are describing.
It's an <img> that you can draw pixels on, this is why I'm saying a static text description like alt="" may be the simplest accessibility option.
SVG is in a similar boat - even though there's DOM there's not much point reading to a user that there's a bunch of shapes and lines

Until they add support you can always do something like this:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>untitled</title>
<style>
.canvas-alt {
  border: 0;
  clip: rect(0 0 0 0);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;
}
</style>
</head>
<body>
<canvas></canvas>
<p class="canvas-alt">Alt content</p>
</body>
</html>

[Stomme poes]

No, that's not right. The text content is still visible - it's only that you can't style them in ie9<

That's what I meant by, "they degrade well". "<p>It was posted <time datetime="2011-11-12T14:54">a while ago</time></p>" gets you
"It was posted a while ago." and since that was fine before (before we had time), this is still okay. For browsers who recognise that there *is* a tag, great, styling etc... what I mean is, though, you wouldn't want to do that with an element like <header>, where yeah IE also shows any inline content inside that, but since stuff tends to get nested inside those, you're now missing a whole piece in the DOM and that can cause other problems if you're trying to access those nested elements. If I were using <header> and <footer> etc, I wouldn't use them without the shim for IE. <mark> and <time> though I can and do.

I think we're saying the same thing here.

Oh right, I guess they are removing the JS API's because it confused people.

I have no idea, 'cause other APIs *are* still in the HTML5 spec technically. So it only confuses me. I thought it was a W3C decision made for completely different reasons, or because some WG wanted to work on the spec without worrying what the 2 HTML5 groups were doing... or something. Who knows.

That's not a problem, it's a design choice, but I do share the peeves and SVG does seem like a more natural fit with the other web standards.

Well, the guys who made canvas are seemingly always on the mailing list saying stuff like "this is inappropriate use of canvas, they should be using SVG for this!" all the time... but SVG is retained-mode, it's slower, and while it has the benefit of a DOM it also has the disadvantage (speed wise) of a DOM. For things like forms I would think SVG (if images are necessary) would be the natural choice but it seems they are not, in the wild.

I think <canvas> is a lot like <img>, I don't think of it as an interactive document like you are describing.
It's an <img> that you can draw pixels on, this is why I'm saying a static text description like alt="" may be the simplest accessibility option.

The examples I see of canvas are never static. Discounting even the games, users are meant to interact with it. Drawing on something, dragging something, selecting something... otherwise, you would just use... an img. You're not loading all that JS for a static picture.
http://archive.dojotoolkit.org/night...s/circles.html <-- a canvas example used in chart/graph software. It's not just showing data, but the point is also that users can manipulate data. This is how canvas is being used in the wild.
Now you could have a static table filled with the data hidden behind the canvas, but manipulating it? Really, if they can get the browser to recognise things as objects, with states, and are able to work with regular input devices, then it really opens the whole set of benefits up to so many more users. And the way they're going, I think eventually that will happen.

I failed this http://archive.dojotoolkit.org/night...reer_test.html guess I don't get the job

[markbrown4]

For things like forms I would think SVG (if images are necessary) would be the natural choice but it seems they are not, in the wild.

I don't understand, for things like forms I'd expect <form>'s

The examples I see of canvas are never static. Discounting even the games, users are meant to interact with it. Drawing on something, dragging something, selecting something... otherwise, you would just use... an img. You're not loading all that JS for a static picture.
http://archive.dojotoolkit.org/night...s/circles.html

I didn't say they were static, I said <canvas> was just a <img> that you can draw on with javascript.

<-- a canvas example used in chart/graph software. It's not just showing data, but the point is also that users can manipulate data. This is how canvas is being used in the wild.

I disagree, the point of the whole page might be that users can manipulate data, that's not the point of the <canvas> - it's purely for rendering flat images. You seem to think that's a design flaw, I think it was always it's intention.
A simple example of what I'm referring to is entering data in a form in one part of the page, and a chart getting updated in a different part of the page.

[itmitică]

There are a few kinds of HTML5. header, footer, section, nav are one type. canvas is another type.

Even though I strongly disagree with your intro (see nav), I mildly disagree with you on canvas.

canvas is one of those elements that can actually produce a full scale progressive enhancement. That is, it can replace the whole content, it can put it in a better visual shape, and serve it with the full interaction package content had in the first place, +1.

All that if you can handle the complexity for the task. Which is huge, looking at the steps one need to take just for drawing a rectangle. The sole primitive shape. Also, using pixels, being "a resolution-dependent bitmap canvas", it doesn't help much.

Which lead you to the conclusion that canvas if for rendering flat images. And here is where I mildly disagree. You can do that, with a few benefits over classic images, and over the hurdles of using just JavaScript on HTML elements like div, as canvas clones. But if that was the case, SVG would be easier and faster to implement, with better results, facing the same challenges for support and fallback.

[deathshadow60]

In a lot of ways you outlined a hefty chunk of what's WRONG with HTML 5.

Other tags, like samanime pointed out are quite useful like <time>, these provide valuable semantics to a page that HTML4 didn't.

Except is that type of semantics even warranted on 99% of the sites people are going to put it on? Does ANYTHING MEANINGFUL really care about the last microsecond of detail on the time. The TIME tag strikes me as being akin to TITLE attribute idiocy; where most of the time if you need TITLE, there's something wrong with the contents of the tag you are applying it to.

ADMITTEDLY, there is the whole America vs. RoW time issue of what comes first, month or day; But the solution to that if you care is to spend the time to *shock* spell out the month. We have computers, we can do that automatically now. "j F Y" FTW.

Again, reading code with these tags makes them more readable.

How so? Extra inline-level phrase-type elements doesn't make it more legible because it breaks up content that probably shouldn't be. So many of the existing tags go unused either out of ignorance (DEL,DFN,KBD,SAMP,VAR,TH,LABEL,CAPTION,LEGEND,FIELDSET), bashing them into 'specific roles' making them useless for anyone (ADDRESS), or people just being too stupid to figure out which witch is which (ABBR,ACRONYM) -- throwing MORE phrase, structural or special elements in is NOT the answer.

The variety of tags isn't a problem in itself. It was aimed to pave the cow paths and implement semantics for things that people were coding over and again with meaningless tags like div/span.

... missing the point of using them -- NOT changing the content's existing meaning. Natural language and formatted data so far as USERS are concerned shouldn't NEED extra semantic tags for each and every little stupid case. That's just making more work for developers for no real tangible benefit. We keep this attitude going, by the time of HTML 10 we'll end up having wrapping every blasted word in it's own tag just so we know what type, tense and variation is being used. <pronoun personal="personal">I</pronoun> <verbaux tense="present">can</verbaux> <verb>see</verb> <pronoun>it</pronoun> <adverb>now</adverb>....

Putting many of the new tags squarely into the same bin as all that microformats asshattery -- except instead of abusing abbr we're making the spec more complex than it needs to be. It's like all this metadata crap many OS try to add to files that NOBODY actually has the time to bother filling out -- unless you can automated like with MP3's it's pointless. (trust me, as a former BeOS user I've seen it in action) -- Most DEVELOPERS can't even be bothered to use verbose names for ID's, classes or filenames, much less the cryptic "What the devil does that mean" normal people use for their files.

Enough about the semantics already. HTML5 was designed for web applications. Let's talk about that instead.

Which is another hefty part of my issue with HTML 5-- what in blue blazes does that have to do with Markup?

An HTML specification should be about writing markup -- a scripting specification should be about writing scripts -- a CSS specification should be about writing CSS.

But they've thrown it all under HTML 5's banner because without those extra things, it would be meaningless rubbish that serves no point... and since you can use CSS3 and the new scripting WITH HTML 4/XHTML 1, what's the POINT?!?

The really interesting parts of HTML5 that set it apart are Forms, Rich Media(Audio, Video), 2D/3D Graphics(Canvas, WebGL, SVG - though not technically part of HTML5), Offline, and the other Javascript API's(localstorage, db, geolocation).. among others.

Again, which has what to even DO with writing markup?!?

Let's go down the list of these 'features'.

AUDIO and VIDEO -- Redundant to OBJECT, locks us into supporting whatever pet codecs the browser maker wants to shove down our throats and locking out third parties from introducing their own to the browser... The fractionalization of video formats I predicted back when the Ogg whackjobs were touting VIDEO as the greatest thing ever has actually come to pass. There is no legitimate excuse for these to be new tags, or that the scripting that makes them desirable over object could not have been added to the existing tag. A new universal plugin format and forcing browser makers to sandbag their plugins (like chrome does) would have been MUCH more helpful.

CANVAS -- Shouldn't even HAVE an element since it's JS only... and if you bother having capabilities detection you're already building it's context on the dom before adding it; at which point is one more createElement really gonna kill you? This would have been much more useful if it could be attached via script to ANY element.

WEBGL -- This may someday actually be useful -- but JavaScript timers could REALLY use a massive overhaul to make this useful... though again this has WHAT to do with markup?

SVG -- Remember when Adobe was the champion of SVG 13 years ago (since it's loosely based in part on Postscript)? Of course not! They torched it, pissed on the ashes and buried it in a deep dark place the MOMENT they bought out Macromedia. SVG is one of those 'pipe-dream' formats that fails to deliver on it's promises by being needlessly complex, needlessly verbose, and too difficult for the average person to even THINK about using despite it's alleged "XML simplicity". It's been around for as long as HTML; and it's gone NOWHERE for a reason. People are trying to use CANVAS instead because they can at least wrap their heads around it... which is sad given that CANVAS isn't exactly simple either.

LOCALSTORAGE -- because after years of people complaining about cookies storing information, now we're going to be able to store even MORE crap on a users machine. Possibly handy for apps, potential for abuse massive.

DB -- ditto.

GEOLOCATION -- I don't get the appeal/need for this. But then anyplace you should really 'need' geoloc you probably wouldn't have coverage anyways. Could be cute for making

HTML5 Forms should be used - one strong reason is that using the new types enables mobile browsers to switch keyboards for the types.

NOT even sure what that means... could you elaborate?!? "Switch keyboards?!?" on mobile?!? You've lost me.

There's heaps of great additions to HTML forms validation

MAYBE if people would stop blowing 500k+ page loads on five input element forms, practicing separation of presentation from content and stopped resorting to hundreds of K of javascript for nothing -- resending the form populated wouldn't be the end of the world? I mean you're going to have to validate the data again server-side anyways.

THOUGH, the inclusion of 'required' and others is welcome because if they aren't present/functional, big deal. Validation is one of the things I do welcome; BUT -- I'm worried about all the people who will think it can be trusted and fail to provide fallbacks.

placeholders

For the people too lazy to bother using labels. Better than wasting javascript on some sort of garbage content swap that to be frank, strikes me as something that should be handled using ":target" in CSS instead of putting it in the markup; We're talking about a presentational effect performed on content that by all rights should be in a LABEL.

speech input

Because after twenty five years since I first encounted "ready for real world use" speech input, it has improved by leaps and bounds to where it's ACTUALLY ready for real world use -- NOT.

Rich Media is painful and inconsistent - but adding these to the specs is the right move, don't hate progress.

... and if it isn't progress? If it stifles innovation by locking you into each browser makers favorite pet codec? If javascript's timers and response times needs complete overhauls to even make them viable for all the things the legacy formats handled? If it prevents content providers from even wanting to consider using it? (Lemme put it this way, you won't see Hulu or Netflix using them any time soon -- DRM is not EVIL people, it's only in the hands of companies like SONY...)

The Javascript API's are the most of HTML5.

The most what?!?

Though again, what's that got to actually do with writing HTML? NOTHING.

Oh yeah, and everyone is on the same page with the doctype, use it.

Define 'everyone' -- as I think we have a different definition!

Complete lack of versioning, no link to the defining document, completely discarding the mechanism that was put in place so that browsers could automatically support new doctypes -- that not one browser maker has gotten off their asses to implement properly? But no, let's go for this 'living document' crap, throwing out any chance at providing consistent baselines and readiness states. All it does is the lip service feel good "look we're using less characters" without taking the time to think about why the original was so 'large'. Besides, if the size of the doctype was causing a significant impact on how long it took to write a page, deploy it to users, or any of the other lame excuses used to justify said shortening, there's probably something disastrously wrong with the page it's being applied to.

Again, you can tell nobody with an engineering background is even remotely involved in HTML 5's creation.

the point that HTML5 is to support Web Applications and richer experiences on the web. Not all web developers need to use these features, so HTML4 is fine. But if you're building a rich, interactive web application you'll want to look at some of these features.

90% of which work just fine WITHOUT HTML 5 since there's nothing stopping you from using most of the new scripting goodies and css3 'gee ain't it neat' stuff in a HTML 4 / XHTML 1.0 document. The only things you lose in terms of the 'rich content' are AUDIO and VIDEO, which to be frank we need to start standing up to the W3C and Browser makers and tell them what we REALLY need to tell them.

NO MORE VENDOR LOCK-IN!

Which is funny since that's what they claim those new tags were added to fight... RIGHT. Apple must love it though, they've been all about vendor lock-in since they day they introduced the Lisa.

Though to get back on track, you pointed out all the really useful bits of "HTML 5" -- too bad most all of them have NOTHING whatsoever to do with writing HTML. You take those away, and there's no longer even a reason to HAVE a new HTML...

Bottom line, "Newer isn't always better" -- and when they have to hide their idiotic rubbish changes to the markup behind other specifications that have nothing to do with marking up content; well, does the term snake oil ring a bell?

[Stevie D]

How so? Extra inline-level phrase-type elements doesn't make it more legible because it breaks up content that probably shouldn't be. So many of the existing tags go unused either out of ignorance (DEL,DFN,KBD,SAMP,VAR,TH,LABEL,CAPTION,LEGEND,FIELDSET), bashing them into 'specific roles' making them useless for anyone (ADDRESS), or people just being too stupid to figure out which witch is which (ABBR,ACRONYM) -- throwing MORE phrase, structural or special elements in is NOT the answer.

What was wrong with many of those was that they didn't have a sensible use-case. I do use some of them regularly, but things like <kbd>, <samp> and <var> were never going to be used outside of an extremely narrow scientific context, so they shouldn't have been built into the spec. Likewise, the difference between <abbr> and <acronym> is arbitrary and unnecessary - acronym is a subset of abbreviation, and it completely ignores the one useful distinction of initialism, which would have been helpful for screen readers.

Paving the cowpaths is not such a bad idea. Where a significant number of real-world uses have been found for a particular element or property, it makes more sense to include that in the official spec than to leave hundreds of different home-made unofficial heath-robinson attempts as the only way forward.

... missing the point of using them -- NOT changing the content's existing meaning. Natural language and formatted data so far as USERS are concerned shouldn't NEED extra semantic tags for each and every little stupid case. That's just making more work for developers for no real tangible benefit. We keep this attitude going, by the time of HTML 10 we'll end up having wrapping every blasted word in it's own tag just so we know what type, tense and variation is being used. <pronoun personal="personal">I</pronoun> <verbaux tense="present">can</verbaux> <verb>see</verb> <pronoun>it</pronoun> <adverb>now</adverb>....

Reduction ad absurdum. Computers are good at understanding natural language and figuring our what part of speech each word is, they don't need it to be programmatically specified. Being able to tell a computer a specific date/time, which a human reader would be able to infer, could be useful. If people want to use it then they can, if they don't want to then they don't have to. It adds to the potentiality of the language. As you are so fond of reminding people, HTML is about encapsulating meaning, not creating a particular mode of display. To that end, HTML is also being used for wider purposes, particularly on the mobile web, and allowing a richer interaction with other applications such as calendars is a natural direction to go in.

GEOLOCATION -- I don't get the appeal/need for this. But then anyplace you should really 'need' geoloc you probably wouldn't have coverage anyways.

On the contrary, it can be very useful for maps and directions, transport services (what time are the buses from my nearest bus stop(s)?), store locators, weather reports – all sorts of things. I think it would be great when I'm on my mobile (which is a bit slow and clunky when browsing a lot of sites) if it went straight to the most appropriate page for my location without me needing to type in and search for it.

NOT even sure what that means... could you elaborate?!? "Switch keyboards?!?" on mobile?!? You've lost me.

Some touch-screen mobiles switch between full text keyboard (or the traditional 0–9 number format text keyboard) and a purely numeric keyboard depending on the <input> type. If the device knows that I have to enter a number into a particular input, it's more helpful if it just gives me numbers and nothing else.

THOUGH, the inclusion of 'required' and others is welcome because if they aren't present/functional, big deal. Validation is one of the things I do welcome; BUT -- I'm worried about all the people who will think it can be trusted and fail to provide fallbacks.

A lot of the time, I really don't care if a form fails. If someone fills in a contact form and mistypes their email address then hard luck, they won't get a reply. I'm not going to set up a complex pattern match to allow for eejits who can't type tom@hotmail.com without messing it up, but if I can put type="email" on it nice and easily then that's a good solution – no effort to me, and it will help out the eejits with supporting browsers.

The sort of people who will use HTML5 forms for essential validation were probably the sort who would use Javascript as their sole form security measure before ... not really worth worrying about them!

Complete lack of versioning, no link to the defining document, completely discarding the mechanism that was put in place so that browsers could automatically support new doctypes

Completely irrelevant. With the exception of quirks mode – which was never actually about the doctype anyway, because you can have standards mode or quirks mode with any of the doctypes, that was just a handy place to have the switch – browsers ignore the contents of the doctype. It doesn't matter if you tell the browser it's HTML3.2 and then put HTML5 tags in there, they will render it just the same. So what's the point of having a long and complex doctype that is mostly full of redundant information? Nothing. So KISS – all browsers need to know is that it's an HTML document, and they will deal with each and every element that comes up.

But no, let's go for this 'living document' crap, throwing out any chance at providing consistent baselines and readiness states.

What the 'living document' does is ensure that there can be some real world deployment within the next ten years. if we had to wait for the HTML5 spec to be finished and then for all browsers to catch up, we'd never be able to use it. And whether or not you approve of what HTML5 adds and takes away, you have to agree that that wouldn't be a sensible development strategy.

Or to put it another way – if HTML5 was not a living document then you open up the possibility that existing elements could change their function, you reduce backwards compatibility. That's the only reason you would need versioning. And as soon as you do that, any page written in the new language becomes incompatible with older browsers that don't support it. We're too far down the line for that, rendering agents are ubiquitous and while it might be firming up some features we would rather not have had, we need the "pave the cowpaths" approach.

I'm not saying I disagree with everything you wrote – I'm right with you on the stupidity of tying Javascript too closely with the HTML and on vendor lock-in for rich media – but HTML5 introduces lots of new possibilities as well, and it's far better to welcome them and look to see where they could be used beneficially than just to rant and rave (although you do that so well ).

[itmitică]

We keep this attitude going, by the time of HTML 10 we'll end up having wrapping every blasted word in it's own tag just so we know what type, tense and variation is being used. <pronoun personal="personal">I</pronoun> <verbaux tense="present">can</verbaux> <verb>see</verb> <pronoun>it</pronoun> <adverb>now</adverb>....

I don't see that happening. We have lists to save us from that. In fact, we have lists to save us from everything.

After all, a phrase is a list of words:

<ul>
 <li role="personal" class="pronoun">I</li>
 <li role="verbaux" class="present">can</li>
 <li role="verb">see</li>
 <li class="pronoun">it</li>
 <li role="adverb">now</li>
</ul>

Right. All that remains now is to float them. Done. A little bit of right margin for each, a few :after to put punctuation in place. Done. Here you go. HTML10 saved.


But I do agree with you Jason that some parts in the HTML5 specification aren't looking to be practical also, but are there for the novelty hype part. Time will tell if content for canvas can be actually generated automatically by simple and interactive tools. Like it's the case for SVG.

Some parts of HTML5 keep the simplicity in place, as it should be, since that's what HTML is about: easy and affordable. canvas has a hard time keeping up with that. The rest, as you said, is more JavaScript then HTML. It doesn't need a 5 for it. It works very well without it.

Maybe they should've called it Web5.0.1.

[Stevie D]

After all, a phrase is a list of words:

<ul>
 <li role="personal" class="pronoun">I</li>
 <li role="verbaux" class="present">can</li>
 <li role="verb">see</li>
 <li class="pronoun">it</li>
 <li role="adverb">now</li>
</ul>

Sorry, but you're a week to early for that

[markbrown4]

canvas is one of those elements that can actually produce a full scale progressive enhancement. That is, it can replace the whole content, it can put it in a better visual shape, and serve it with the full interaction package content had in the first place, +1.
All that if you can handle the complexity for the task. Which is huge, looking at the steps one need to take just for drawing a rectangle. The sole primitive shape. Also, using pixels, being "a resolution-dependent bitmap canvas", it doesn't help much.

I don't really understand what you're getting at here, but I'll try. Canvas, being just a bunch of pixels could be used for almost anything(replacing form elements for example). That's true but I don't think those types of uses will become popular because like you say it's hard to get anything done quickly with it's API, if there are easier methods people will use those. And the whole point of form elements is that the input device can choose a method of display that suits it's user. Mobile devices have been a great example of why we should just let devices handle data input.
Canvas is not a "full interaction package" at all - It's just pixels you can draw on. There are no events on different parts of the <canvas> so if you want to interact with it you need to use the same old mouse / keyboard / touch events on other elements.
These are the issues that stomme was pointing out with it - if you want to be able to interact with it you need to manage all of that complexity yourself outside of the <canvas>.

Which lead you to the conclusion that canvas if for rendering flat images. And here is where I mildly disagree. You can do that, with a few benefits over classic images, and over the hurdles of using just JavaScript on HTML elements like div, as canvas clones. But if that was the case, SVG would be easier and faster to implement, with better results, facing the same challenges for support and fallback.

Maybe there's confusion with my choice of words - All I've said is that <canvas> is an <img> where you can manipulate it's pixels with javascript. I never said you couldn't make animation with it or update the image in real-time.

SVG is a collection of lines, shapes, text, images. Being part of the DOM and having it's own markup you can edit these objects independently in the markup, as well as interacting with them via events on the individual parts, or with javascript.

There is overlap between the technologies and some things can be achieved with both - In those cases I'll normally go with svg unless there's performance issues. Of course, you can also render strings of SVG in Canvas so the lines get even blurrier.

[markbrown4]

Except is that type of semantics even warranted on 99% of the sites people are going to put it on? Does ANYTHING MEANINGFUL really care about the last microsecond of detail on the time. The TIME tag strikes me as being akin to TITLE attribute idiocy; where most of the time if you need TITLE, there's something wrong with the contents of the tag you are applying it to.

ADMITTEDLY, there is the whole America vs. RoW time issue of what comes first, month or day; But the solution to that if you care is to spend the time to *shock* spell out the month. We have computers, we can do that automatically now. "j F Y" FTW.

Yes, I think <time> elements could be warranted on 99% of sites because nearly all pages on the internet are media, blogs, video, forums, wikis etc.. All these documents have dates and time attached to different parts. The time elements could be used for finding when things were published - Having this data in a language independent format means that humans can read it and computers can parse it.
I'm not sure why we're discussing the title attribute but it's main use these days is for tooltips ie. a more detailed Title than the visible content.

How so? Extra inline-level phrase-type elements doesn't make it more legible because it breaks up content that probably shouldn't be. So many of the existing tags go unused either out of ignorance

I only meant it's easier to identify which HTML is what type of content at a glance. This is why I also said some uses of section and article can achieve the same thing in your code and you don't have to track which closing </div> relates to which opening tag to find what it is. The closing tag does that on it's own having it's own tag. But I do want to move away from discussing those tags if possible.

Putting many of the new tags squarely into the same bin as all that microformats asshattery -- except instead of abusing abbr we're making the spec more complex than it needs to be. It's like all this metadata crap many OS try to add to files that NOBODY actually has the time to bother filling out -- unless you can automated like with MP3's it's pointless. (trust me, as a former BeOS user I've seen it in action) -- Most DEVELOPERS can't even be bothered to use verbose names for ID's, classes or filenames, much less the cryptic "What the devil does that mean" normal people use for their files.

I think you're right that the reason microformats hasn't taken off is that it does require more time and study and requires more work on the part of the developer.
People will only use it when the benefits are greater than the effort required e.g. Google has some examples of being able to parse some microdata and change the way you're listed. If you want that benefit, write the extra code.

Again, which has what to even DO with writing markup?!?
...
Though again, what's that got to actually do with writing HTML? NOTHING.
...
Which is another hefty part of my issue with HTML 5-- what in blue blazes does that have to do with Markup?

An HTML specification should be about writing markup -- a scripting specification should be about writing scripts -- a CSS specification should be about writing CSS.

But they've thrown it all under HTML 5's banner because without those extra things, it would be meaningless rubbish that serves no point... and since you can use CSS3 and the new scripting WITH HTML 4/XHTML 1, what's the POINT?!?

I'm comfortable with HTML5 being an umbrella term for additions to web technologies that supports web applications.
Web tech has always become more valuable and richer when the technologies are combined, they are supposed to work together. The different technologies are good for very little on their own. Just roll with it ds.

I disagree with you that the HTML changes aren't necessary or benefical:
I much prefer having <audio> and <video> than putting everything in an object. I want to see at a glance what type of content I'm marking up. I feel the same about <canvas> and <svg>
The HTML forms required changes, I like the way they designed these to be as backwards compatible as possible.
The cache manifest required a change to the HTML.
Supercharging the trusty <a> to include block-level elements is a good addition, yes there are some teething issues - but why should we not be able to links things that aren't defined as inline 'text-level' elements in an older spec?
I like the housecleaning they have done as well - shortening doctype, charset, script & style to the minimum required for browsers to do their thing.

For the purposes of discussion we can use this list for features, though I'm more interested in hearing about the HTML and JS components.
http://html5please.com/

[deathshadow60]

What was wrong with many of those was that they didn't have a sensible use-case. I do use some of them regularly, but things like <kbd>, <samp> and <var> were never going to be used outside of an extremely narrow scientific context, so they shouldn't have been built into the spec.

Scientific context? I'll give you that for VAR, but the others, not so much.

<p>
  Type <kbd>CATALOG<kbd> to pull up a directory from AppleSoft Basic and it should return a listing like:
</p>
<pre><samp>DISK VOLUME 254
A 002 HELLO</samp></pre>

KBD is for text to be entered by the user -- SAMP is for sample output... Programmatic/computer related perhaps, but not what I'd call 'scientific'...

Though you want to talk 'narrow context' I'll give you that for ADDRESS, which has been so completely shoved into a narrow and specific role that if you restrict it to what it's supposed to be for, you'll never use it on a website.

Likewise, the difference between <abbr> and <acronym> is arbitrary and unnecessary - acronym is a subset of abbreviation, and it completely ignores the one useful distinction of initialism, which would have been helpful for screen readers.

Not quite sure where you get either of those as they are grammatically two entirely different things... and initialism is just acronyms without the periods -- ooh.

Reduction ad absurdum. Computers are good at understanding natural language

Laugh... since when?!? Joke, I'm assuming you miss-spoke.

and figuring our what part of speech each word is, they don't need it to be programmatically specified. Being able to tell a computer a specific date/time, which a human reader would be able to infer, could be useful. If people want to use it then they can, if they don't want to then they don't have to. It adds to the potentiality of the language.

In other words, let's throw away one of the driving mantras we've been told the past decade -- write for people, not for computers. It's content micromanagement...

As you are so fond of reminding people, HTML is about encapsulating meaning, not creating a particular mode of display. To that end, HTML is also being used for wider purposes, particularly on the mobile web, and allowing a richer interaction with other applications such as calendars is a natural direction to go in.

Seems much like microformats before it -- to me at least, to be a waste of code, waste of time, for some mythical data scraper type user agent which has yet to materialize, and likely never will.

On the contrary, it can be very useful for maps and directions, transport services (what time are the buses from my nearest bus stop(s)?), store locators, weather reports – all sorts of things. I think it would be great when I'm on my mobile (which is a bit slow and clunky when browsing a lot of sites) if it went straight to the most appropriate page for my location without me needing to type in and search for it.

Normally I rag on the tinfoil hat brigade, but really you just outlined the potential for abuse and why I don't like it. I don't want websites to be able to look at where I am unless I tell them... and even then the most I'd tell them is what town/zip code. I could MAYBE see it for the whole maps/directions thing, except IMHO that should remain client side operations as how most current GPS navigation systems work.

Some touch-screen mobiles switch between full text keyboard (or the traditional 0–9 number format text keyboard) and a purely numeric keyboard depending on the <input> type.

I often forget that people even use numeric keypads for text input -- particularly for any sort of actual data form -- it's so uselessly awkward I really can't see wasting time worrying about them, particularly as moving forward mechanical keyboards on phones seems to be going the way of the dodo... but then the last mobile I owned with a mechanical slid in half sideways to reveal a full QWERTY so...

A lot of the time, I really don't care if a form fails. If someone fills in a contact form and mistypes their email address then hard luck, they won't get a reply. I'm not going to set up a complex pattern match to allow for eejits who can't type tom@hotmail.com without messing it up, but if I can put type="email" on it nice and easily then that's a good solution – no effort to me, and it will help out the eejits with supporting browsers.

I agree partly on the "let's not bend over backwards to help the re-re's" but a server side check of a e-mail is pretty simple, and should be done just so you don't fill up your DB with trash or send a pointless e-mail to yourself.... and since you're going to check it anyways, is it really that hard to re-send the form populated?

Completely irrelevant. With the exception of quirks mode – which was never actually about the doctype anyway, because you can have standards mode or quirks mode with any of the doctypes, that was just a handy place to have the switch – browsers ignore the contents of the doctype. It doesn't matter if you tell the browser it's HTML3.2 and then put HTML5 tags in there, they will render it just the same. So what's the point of having a long and complex doctype that is mostly full of redundant information? Nothing. So KISS – all browsers need to know is that it's an HTML document, and they will deal with each and every element that comes up.

... which is PART of the problem, hence my saying "completely discarding the mechanism that was put in place so that browsers could automatically support new doctypes" since if it's not already present the file/data linked to in the doctype is supposed to be downloaded and parsed to help build the page... if the browser makers had gotten off their asses and implemented doctypes properly fourteen to fifteen years ago, we could introduce all those fancy new tags HTML 5 wants and they'd just work, all the way back.

The problem isn't the doctype being too long, the problem is browsers ignoring it and failing to use it for what it's FOR.... as such throwing some stupid lip-service for backwards compatibility at it is NOT the right answer. HTML 5 is full of these types of idiocies -- where instead of solving the problem (let's ride Microsoft's ass about not implementing OBJECT properly) they throw up their hands and introduce something new for no good reason.

What the 'living document' does is ensure that there can be some real world deployment within the next ten years. if we had to wait for the HTML5 spec to be finished and then for all browsers to catch up, we'd never be able to use it. And whether or not you approve of what HTML5 adds and takes away, you have to agree that that wouldn't be a sensible development strategy.

Sorry, the engineer and social observer in me sees that as the same type of idiocy as credit; a pay more later for something we can't afford now attitude. It's the "we want it NOW, NOW, NOW!" attitude that to be frank, is a hefty part of what real world is tanking the economies of first and second world nations.

In other words, the EXACT same idiocy that led to there even being a 'quirks mode' for browsers in the first place! Jumping the gun on non-finalized constantly under revision specifications is how you end up with such scenarios. Oh noes, it might take a decade or more to implement; the problem with that is what exactly?!? If what we have now works... I'm not seeing the issue apart from the 'ooh, new and shiny' crowd clamoring for things before they're ready... assuming they should ever be ready or adopted in the first place.

... which describes most everything markup related in HTML 5 in a nutshell, and a hefty chunk of CSS3.

Or to put it another way – if HTML5 was not a living document then you open up the possibility that existing elements could change their function, you reduce backwards compatibility.

Gehugafugah?!? That's the OPPOSITE of what strict versioning does...

That's the only reason you would need versioning. And as soon as you do that, any page written in the new language becomes incompatible with older browsers that don't support it.

Unless of course in terms of markup there was say... a mechanism in place.... like say... a doctype with a link to the structural rules of said new language; that browsers would bother to parse before building pages... I know, crazy idea. Couldn't possibly have anything like that.

[markbrown4]

LOCALSTORAGE -- because after years of people complaining about cookies storing information, now we're going to be able to store even MORE crap on a users machine. Possibly handy for apps, potential for abuse massive.

DB -- ditto.

GEOLOCATION -- I don't get the appeal/need for this. But then anyplace you should really 'need' geoloc you probably wouldn't have coverage anyways. Could be cute for making

I'm optimistic about Localstorage & db, with more and more processing moving to the client it's only natural.

Mobile is huge Jason, I find location based web services to be some of most engaging user experiences on the web.
It's not just limited to mobile, but that's it's biggest use case.

Because after twenty five years since I first encounted "ready for real world use" speech input, it has improved by leaps and bounds to where it's ACTUALLY ready for real world use -- NOT.

Tried Siri yet? If not brilliant yet it will get there at some point, I think it's a natural progression that deserves an input type.

NO MORE VENDOR LOCK-IN!

I don't understand what you mean, the point of the sources is that they aren't locked in - you can use any formats supported by the browsers.
If you mean that they shouldn't have allowed mp4's to play I don't think that's right, it's one of the most popular formats.

<video controls preload="auto" width="640" height="264" poster="my_video_poster.png">
  <source src="my_video.mp4" type='video/mp4'>
  <source src="my_video.webm" type='video/webm'>
</video>

Time will tell if content for canvas can be actually generated automatically by simple and interactive tools.

There'll be great tools for this in no time. I'm liking the look of http://radiapp.com/

[ralph.m]

StevieD: "the difference between <abbr> and <acronym> is arbitrary and unnecessary - acronym is a subset of abbreviation, and it completely ignores the one useful distinction of initialism, which would have been helpful for screen readers."

Not quite sure where you get either of those as they are grammatically two entirely different things... and initialism is just acronyms without the periods -- ooh.

An acronym is a kind of abbreviation, as is an initialism, so they are a subset, as Stevie says. Initialisms and acronyms can both be written with or without periods. The difference is that an initialism is pronounced as a series of letters (like CIA) while an acronym is pronounced like a word in its own right (such as NASA). As Stevie says, it would be really useful if you could signal to a screen reader which way to pronounce these. (I don't know how screen readers handle these, but I can well imagine the user gets fed either "Seeya" for CIA or "En-Ay-Ess-Ay" for NASA.)

[markbrown4]

Normally I rag on the tinfoil hat brigade, but really you just outlined the potential for abuse and why I don't like it. I don't want websites to be able to look at where I am unless I tell them... and even then the most I'd tell them is what town/zip code. I could MAYBE see it for the whole maps/directions thing, except IMHO that should remain client side operations as how most current GPS navigation systems work.

That's exactly how it's implemented, it asks for permission.
If you don't want to give it, it could be coded to prompt you for some location info that you would be willing to give, like a post code.

I often forget that people even use numeric keypads for text input -- particularly for any sort of actual data form -- it's so uselessly awkward I really can't see wasting time worrying about them, particularly as moving forward mechanical keyboards on phones seems to be going the way of the dodo... but then the last mobile I owned with a mechanical slid in half sideways to reveal a full QWERTY so...

Yes, touch screens are clearly dominating the market, there will still be mechanical keyboards around for specific things but they won't be the majority in the future.

[deathshadow60]

I don't understand what you mean

That's very apparent from the rest of the post...

the point of the sources is that they aren't locked in - you can use any formats supported by the browsers.

Emphasis mine -- Which means it's all about what formats the browser makers want to support -- as opposed to OBJECT where anyone could get off their tuchas and write a plugin to provide support for ANY format and introduce *shock* NEW FORMATS -- Not just the ones each browser maker feels compelled to add to the codebase.

I'm not singling out ANY single format or even group of formats (like MP4) -- that's not what I'm even talking about -- I'm talking about vendor lock-in to whatever codecs each browser maker happens to feel like adding as opposed to letting anyone who wants to add a format simply make a plugin. That's a MASSIVE step backwards from OBJECT in terms of intent, freedom, and all the other things they seem to be claiming it's there to prevent. I've been saying that since the day I heard about the Video tag and the complete idiocy of hardcoding codecs into the blasted browser.

In fact... OBJECT was supposed to replace even IMG for that reason; so new formats could easily be added (like jpeg2k back in the day, webm pictures today) without digging into the guts and codebase of each browser.

They want to impress me, code in support for whatever codecs I happen to have support for installed on the host OS or through third party applications. Not to put too fine a point on it, but why are we dicking around with crappy slow codecs hard-coded into the browser, instead of just wrapping the windows media extensions for win users and embedding VLC into the browser for everyone else? Oh wait, then they wouldn't be able to try and shove MP4, Ogg or WebM down our throats when what the majority of content providers want to use is h.264...

But of course, then Apple wouldn't be able to say "no flash for you" when it's FINALLY the king of online content delivery in a meaningful manner with actual *SHOCK* hardware acceleration -- but no, Apple would rather force you into either MP4, or their buggy slow pile of crap (at least on windows) called Quicktime.

It's akin to the pissing and moaning done by the freetards over Mozilla considering adding h.264 support. Oh noes, NOT THAT, it's the end of the world... god forbid they add support for a codec content providers actually want to use, that there's existing hardware in place to provide REAL acceleration for, etc, etc...

Which is exactly why it's delivering the EXACT OPPOSITE of all the claims those two tags are supposed to be about... the real reason being apparent to anyone who takes the time to look; it's all about browser makers being too lazy to sandbag plugins, get a unified plugin format, interface properly to the host OS for media, and pimping whatever codec they just so happen to have happy feelings in their nether regions over.

It's funny, I hate flash on websites for things other than actual videos and games; and I'm no fan of Adobe, but at this point for video, I think we need to have someone tell Apple and it's users to go shtup themselves in terms of delivering video to them. Sometimes things become a monopoly because *shock* they work, when the alternatives are a absolute mess.

OR maybe I'm just pissed that my Acer Revo I've been using as my media center the past couple years struggles to play 480p video in Theora or WebM, can BARELY manage MP4 480p playback off YT inside a browser unless I force it to use flash, can't manage Netflix in HD thanks to silverlight -- but can handle a 1080p blu-ray h.264 rip in MPC or Hulu in HD flawelessly?

Oh yes, progress. That's what we have.

(P.S. Remember, MP4 is more a container than a codec, unless you mean the really OLD Mpeg4 codec; NOT that mpeg codecs are exactly bleeding edge anymore in practical deployment -- what with blu-rays STILL using MPEG2 like a crappy 1984 laserdisc; when you could fit two blu-ray movies on a single dvd with maybe 1% data loss using h.264 or webm -- though h.264 is based on mpeg4... as was DiVx... gah, it's a mess.).

[Stomme poes]

As Stevie says, it would be really useful if you could signal to a screen reader which way to pronounce these. (I don't know how screen readers handle these, but I can well imagine the user gets fed either "Seeya" for CIA or "En-Ay-Ess-Ay" for NASA.)

Sometimes they really screw up words. Generally you either hear a word mis-pronounced enough in the voice you usually use that you get used to it, or you hear something weird and you go back and spell the word out (and see if it's in upper or lower case) to figure out what it was.

How a word is pronounced depends on the voices you have, the synth you have, and the language (and how well that language had been built). Like, I was getting pretty exited that NVDA was getting a new Dutch voice, but the guy who was helping on it, I'd have to ask him how that's going.

You ought to hear VoiceOver say "Firefox", it's creepy. Veeerevux. Also wieeeb developers. Lawlz.

Anyway I don't think how to pronounce a word belongs in the HTML. If it's a standard dictionary word it should be handled on the AT side.

We keep this attitude going, by the time of HTML 10 we'll end up having wrapping every blasted word in it's own tag just so we know what type, tense and variation is being used. <pronoun personal="personal">I</pronoun> <verbaux tense="present">can</verbaux> <verb>see</verb> <pronoun>it</pronoun> <adverb>now</adverb>....

Not sure why HTML10 would need that added, we already have Schema :/ which I would only ever use if a client told me they had software that actually did something with it, since the whole adding all that itemscope prop etc stuff just seems like a lot of extra bytes for a reader who doesn't exist.

Microformats are outside the scope of HTML though. Which may be a good thing. With attributes like the data-foo ones where browsers increasingly don't do anything with the attribute at all, but it's there for someone else (Javascript, desktop software) who may also be reading the HTML, it could open up possibilities (and confusion) and leave HTML alone.

So anyway, back on topic: who else uses HTML5 stuff, and which stuff does you uses?

[ralph.m]

Off Topic:

You ought to hear VoiceOver say "Firefox", it's creepy. Veeerevux. Also wieeeb developers. Lawlz.

Do you mean the American version, or Dutch?

I don't think how to pronounce a word belongs in the HTML. If it's a standard dictionary word it should be handled on the AT side.

Do you mean you don't like elements like <abbr>? I think it's as useful to be able to mark up an acronym as such as it is to mark up a date, or whatever. It can be quite embarrassing to find—after reading a word like PNG on the web for years—that many an one pronounces it as "ping".

(I also now find myself compelled to refer to Australia's nearest neighbor as "Ping", which doesn't help. )

[markbrown4]

Some other things I've used are that we haven't yet mentioned:

File API, for drag/drop uploads as well as image previews client-side before upload - You can progressively enhance a normal file input and make it a lot more responsive.
contenteditable Edit any HTML element - Doesn't make sense without js but adds a few possibilities.

[Stomme poes]

Off Topic:


I can't remember anymore which language it was I heard it in! Macs come with English so if you want Dutch you have to go get that language pack yourself even if you bought a Dutch Mac with Dutch as the default OS language and everything. A failing on their part I think. It was a demo by Bram Duvigneau where his JAWS read English so I think his VO did too.

Do you mean you don't like elements like <abbr>? I think it's as useful to be able to mark up an acronym as such as it is to mark up a date, or whatever. It can be quite embarrassing to find—after reading a word like PNG on the web for years—that many an one pronounces it as "ping".

(I also now find myself compelled to refer to Australia's nearest neighbor as "Ping", which doesn't help.

<abbr> is kinda useless so I rarely use it. If a word needs a tooltip to explain it then I probably need a glossary or the full name after the term in parens().
And I still say pee en gee. For both the file format and the country. Ping's already taken in my vocab for what I do to google to check I have internets :)

[rguy84]

Because after twenty five years since I first encounted "ready for real world use" speech input, it has improved by leaps and bounds to where it's ACTUALLY ready for real world use -- NOT.

I am not sure if you are joking, but I will say you are incorrect here. Dragon Naturally Speaking has actually improved leaps and bounds. I first encountered Dragon in ~2000-2001, and individuals with speech impairments could not use it. Those people could use Dragon in ~2004 with 40-80 hours of training at 30-50% accuracy. I know somebody with a medium to severe speech impairment, and was able to pick up Dragon 10, train for 20-40 minutes, and got ~90% accuracy. If that is not improvement, I want to see what would qualify as such. I haven't looked at the built-in engine that comes with Windows 7, but most people who are AT Consultants, like myself, would never recommend using windows built-in components, unless there is no other option ($$$).

What I would need to know about Siri and whatever it is called on Android is does it remember what you say or is it a one-off everytime. I don't mean for tracking purposes. One of the benefits of Dragon, it actually learns as you talk.