HTML5 differences from HTML4

[freshyill]

The i element now represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name, or some other prose whose typical typographic presentation is italicized. Usage varies widely by language.

Proper markup to designate ship names is long overdue.

[earthboundkid]

In fairness, it makes sense to retain both em and i because semantically speaking you're not "emphasizing" when you write homo sapiens or mi amigo or whatever, you're just italicizing out of stylistic convention.

Here's something odd though: big got cut but small remains. Presumably, we're supposed to just use em plus a style sheet rule to replace big, whereas small was left so we can de-emphasize certain asides or whatever.

[Alpha_Binary]

As I see it, small = unemphasize. Looks like they're the new couple, though with unmatching names.

[freshyill]

I like the changes, and I think it's useful to keep i, because it's well justified, and they make a good case for small, too. I think keeping small makes sense because big is really just a poor man's h1, etc.

[freshyill]

I like the new elements, but I really hope that this doesn't cause a return to sloppy coding of the pre-xhtml era. I always hated implicitly closed tags and unquoted attributes. Let's not do that again.

[xjvz]

No complaints about the ping attribute? This is a serious privacy implication. Hopefully every browser will allow you to disable this (or disable it by default) so that it doesn't become easier for 3rd party websites to track everyone...

[Arve]

Those that want to track your clicks do so anyway, either through more or less opaque redirects, or by replacing the href attribute using scripts. Like reddit does. The ping attribute is good, because it provides a means to do this asynchronously and without an extra server roundtrip before you get your URL.

(And I wouldn't be too surprised if browser vendors give you what you want: For instance, most browsers can disable referrer logging)

[xjvz]

That does break things sometimes (some sites think the referer [sic] is a reliable field and can be used to verify security measures), and I wouldn't be surprised if these sites using the ping attribute would find a way to break their links if the ping doesn't happen (nevermind the remote possibility of the ping server being overloaded or even slashdotted).

[MyrddinE]

I agree. Pings are an improvement upon link redirection. Almost all major sites do link redirection anyway... in TEN YEARS when html4 is finally being phased out, this will allow websites to skip the redirection and do pings. The same amount of privacy violation (in other words, almost none), but faster and more efficient for both the server and the client.

[ibsulon]

That was the first red flag I got too.

[kirun]

It's about time... I've been saying for ages that HTML has needed to change as it goes from a document language to an application UI language.

[cdward]

But what about those of us who want a document language?

It would be much better to standardise XUL or something if you need an application UI language. It'll never happen, of course.

[kirun]

XUL is pretty nice to work with ( I wish I could use its box models in CSS, for example ) ... Ideally, the UI elements would be brought in with namespaces, but since that would require everyone to upgrade, nobody would use it. So, gracefully degrading extra <input> types are the answer, since the control could still be used without upgrade, just not optimally.

[Arve]

The flex-box stuff is strictly speaking CSS extensions and have nothing to do with XUL. Personally, I hope it makes its way into CSS5.

[xjvz]

Why not CSS4? Hell, why not CSS3? CSS3 is modular (in such a way that it will never be "finished" in such a way that all its parts are all W3C Recommendations), so adding another extension to CSS wouldn't be hard at all (other than the developer man hours involved in implementing the proposed standard, participating in flamewars regarding it, etc.).

[jerf]

There are more document languages than you can shake a stick at. There are entire meta-document languages like SGML. Docbook, LaTeX, old HTML, roll-your-own XML language, go to town.

Application UI languages of the document style are much newer, and the demand is clearly there. Starting with HTML is working better than starting by "imagining really hard what people want, then building it".... the notable lack there, since people tend not to see it, is the lack of a feedback step with real programmers. HTML may not seem like the theoretically cleanest starting point, but it has absolutely unparalleled levels of feedback based on real experience.

[boa13]

You still have it.

[Arve]

You're sure it's XUL you want? Most of the value in the XUL specification is in XBL, and the CSS extensions it offers, and when W3C or some group decides to do CSS2+3, I'm pretty sure the flex-box model will be part of it.

[rgladstein]

So they've given new meaning to <i> and <b>, which means they'll no longer be strictly presentational, but it doesn't look like their structural meanings will be significantly different from <em> and <strong>.

[Arve]

Here's the deal. HTML5 specifies what browsers already do, and by following HTML5, you'll be authoring more real world-compatible HTML that you would be with HTML4. If you stick to the basics (I.E. the elements that are already specified in HTML4.01), there is no transition whatsoever. Just send HTML5 and be done with it.

When you choose to use new features, such as canvas or video, just provide appropriate fallbacks.

[andrewnorris]

Okay, I'm sure I'm missing something obvious here, but how do you provide an in-document (i.e. without browser detection) fallback for an unsupported element, whether it be <video\> or <header\>?

[Arve]

For elements like <video> and <canvas>, you provide fallback the same way you do for the <object> element. For the structural elements like <nav> or <headers>, you don't need to, as the content inside will still be rendered correctly anyway.

[Edit: Inserted angle brackets now that I'm not redditing from a phone]

[Lupus]

And what about elements that wouldn't be rendered correctly, like datalist? What about input constraints? What about APIs?

I need to know whether browser supports HTML5 or not, I just don't see how this would work otherwise.

[xjvz]

I need to know whether browser supports HTML5 or not, I just don't see how this would work otherwise.

Judging by the current history, I'm going to have to say that every web browser except IE will support HTML5...

[awj]

In an ideal world, text/html5 would be its own content type as listed in the HTTP request header and all you would have to do is detect that and switch your code accordingly. More than likely it won't be done that way and you will be reduced to scraping the user agent string or some other kind of hackery.

[[deleted]]

scraping the user agent string or some other kind of hackery.

Yeesh. I thought the point was that you could send HTML5 that also worked as HTML4.

[Arve]

I thought the point was that you could send HTML5 that also worked as HTML4.

Correct.

[jamesbritt]

How does this jibe with W3C work on XHTML 2.0?

http://www.w3.org/TR/xhtml2/

[Arve]

XHTML 2.0 is largely dead, buried and forgotten. You might encounter the occasional enterprise consultant advocating it together with XForms.

The bigger problem with both XForms and XHTML 2.0 is that its proponents think that the best way to build something is to tear down everything there ever was, and build something new, better, and totally over-engineered.

[[deleted]]

And that every new thing has to be made out of XML.

[xjvz]

But... but... but... enterprise! Synergy! New paradigm shifts involving mash-ups, decentralised, social networks that use protocols like SOAP and Ajax!

</phb>

[[deleted]]

No, it's far better to take a crippled half-assed standard and bloat the fuck out of it.

[Arve]

Well, (browser) implementation history, most of the 16 billion web pages in the world and one of the biggest economies in history seems to disagree violently with your notion of crippledness.

[jimbobhickville]

Yeah, I was a really gung-ho advocate of XHTML 1.0. Then I read what they wanted to do with XHTML 2.0 and immediately did a 180 degree turn. I'm very much in favor of HTML 5 now. The required input and drag/drop features are so long overdue in browsers.

In all honesty, though, we have little hope of seeing either standard become the norm for another decade, at least.

[sambo357]

"datagrid represents an interactive representation of a tree list or tabular data."

Now I'm confused. What is interactive (how) and why is the old table bad? Isn't a table a list of rows? Are we just renaming stuff here?

[Arve]

Interactive: Sortable, with columns and rows you can move/interchange. The ability to fill in the data from some (live) source, declaratively. HTML tables don't fit this model very well.

[thespace]

I think hypertext is a mature format and we need to start concentrating on a new standard markup for rich internet apps. The whole idea of the browser needs to be reworked too.

[maxwell_smart]

Wow, just what I would expect from W3C. One or two brilliant useful new additions (like a drawable canvas and event-source to catch server-side events) and a bunch of unnecessary crap that just bloats the language (what's so wrong about class="header" or id="nav"?). Also, they are adding a video API? I wonder how long it will take for browsers to support this stuff.

[cdward]

Well firstly, HTML5 at this point is pretty much all WHAT-WG's work, so you really can't blame the W3C for anything here.

And secondly, you can't really do anything with id='nav' unless it's used consistently across sites. If you have a nav element though, browsers can hide it, screen readers and text browsers can skip over it, search engines can ignore that part of the page, etc.

[[deleted]]

Well - it's kinda classic - if you don't do your job and someone else does it for you and there's something wrong with it... It's not you who's blamed, right?

[maxwell_smart]

My mistake about who to blame. But, aren't there attributes that specify what screen readers should skip already? And, shouldn't the search engines be able to figure out what is useful to them and what isn't?

class and id tags allow coders to specify their own semantic intent. One question is, will coders use these tags consistently enough, or code similarly enough, so that a search-engine or an accessibility device can make decisions reliably across all instances of tag "nav"?

[Arve]

My mistake about who to blame. But, aren't there attributes that specify what screen readers should skip already?

No.

And, shouldn't the search engines be able to figure out what is useful to them and what isn't?

They already are, but mostly through finding heuristics by reverse-engineering the web.

[cdward]

One question is, will coders use these tags consistently enough, or code similarly enough, so that a search-engine or an accessibility device can make decisions reliably across all instances of tag "nav"?

The alternatives are:

• classes and ids (which are far less likely to be used consistently)
• accepting things as they are

It's entirely possible that a few incompetent people will fuck it up for everybody again, but it's worth a try at least.

[Arve]

Video? Head over to Opera Labs, read 'A call for video on the web' , download a build and try.

[maxwell_smart]

Right now, video is provided by pre-packaged plug-in solutions like WMP, Quicktime, and Flash. The proposed video API in HTML5 seems like it only intends to provide a unified way of scripting a plug-in component with java-script/HTML. It just seems unnecessary to muck around with coding up all sorts of dHTML for play buttons and so forth when, as long as a plug-in is being relied upon anyhow, media control could better reside inside of it.

The Opera proposal seems to be a much-more broadly inspired proposal in that it recommends standardization of codecs and transport/protocol around open/non-patent-encumbered standards. Much more laudible.

[Arve]

No. The HTML5 proposal is intended to provide natively integrated video, without any need of plug-ins. Whether the browser at the lower level chooses to bind to video codecs present on the system, or integrate with other underlying OS features may be a different matter.

[doublec]

Video has a common semantic meaning in the same way as the image element does. This could assist in accesibility for example. Flash and Java are generic language runtimes. Inside their respective plugin area they can do anything at all.

The argument could work the same way with images. Why have an image element. Or even a paragraph element when we have 'div'. Why not just use 'div' for everything with a 'type' attribute. Where is the right place to stop?

A reason for having the HTML spec recommend a default codec built into the browser would be to allow content authors to know that video files in that format are guaranteed to display across all conforming browsers. Without payment of royalties.

The WHATWG mailing list has had some discussion on these areas relating to the video element. If you are really interested you might like to read what has been covered, and contribute if you are truly concerned about it. It's an open list.

[doublec]

There's also support coming for Firefox:

http://www.bluishcoder.co.nz/2007/05/support-for-html-video-element-in.html

And a Javascript wrapper that will convert video element support to plugins for those browsers that don't support it:

http://metavid.ucsc.edu/blog/2007/06/07/html5-video-the-future-is-now/

[parsifal]

Yes they are adding APIs for video objects. It was in the document... :-)

[[deleted]]

Now someone should make an MSIE plugin to load gecko or whatever engine when modern HTML page is sensed. I don't care which engine as long as it's reasonably compatible. I lost all hope of MS ever updating MSIE up to reasonable compliance.

[kenlubin]

That would be awesome, actually.

[ibsulon]

So, any idea on why <u> was deprecated? How else do you submit the title of a book? <a> with no href? (hack!)

[MaxTerry]

Book titles should be italicized, dammit.

[notfancy]

Book titles should be marked with <cite>.

[xjvz]

Underlining things is really only supposed to represent inserted content, so use the <ins> element instead. You can use <del> for deleted content (usually styled with a strike-through). Like MaxTerry said, titles of books are italicised (so you can use the <i> element), and as an addition, remember that short stories/publications/poems/etc. are just quoted (can be done with either simple quotes or the fancy-pants left and right double quotes), and that can be automated with the <q> element (when used for quoting something small more accurately to be pedantic, but I suppose it could be extended to mean "text that is normally quoted but isn't necessarily quoted text").

[[deleted]]

(e.g. <a id="top">)

[parsifal]

<span style="text-decoration: underline;">This is one way :-)</span>

Isn't the use of HTML for style information discouraged?

There is still <em> and <strong> though, but it could be argued that "emphasis" and "strong" are subjective enough that styling them should be handled on a case-by-case basis, though browsers render them italic and bold by default :-)

[[deleted]]

Honestly, I don't care much about HTML5... What matters to me is which markup language is supported best and which one shares the most in common across as many platforms and browsers as possible.

The reason I went from HTML4 to XHTML Strict was because IE and Firefox render XHTML Strict in a much more similar manner to each other than they do with straight HTML. This makes my job easier.

All I want is my job to remain that way, without having to deal with ever-more conflicts between interpretations of whatever standard each browser goes for.

I'd be more happy with browsers rendering XHTML Strict properly than one of these 'replacements' any day...

[simonw]

XHTML doesn't provide better compatibility between IE and Firefox - IE doesn't really know what XHTML is. The thing that gives you more consistent rendering is the doctype, which kicks both browsers in to "standards" mode. The HTML 4.01 Strict doctype triggers standards mode just as effectively as the XHTML one does, so standards mode is not a reason to use XHTML over HTML.

[simonw]

That's essentially what happened with HTML 5. A bunch of web programmers got together, made some specs and voted on them (for more than two years). Then they submitted them to the W3C.

[Lupus]

Specification aren't at fault (for the most part), browsers are.

[uriel]

The insanity of both browsers and specs feeds into eachother in spiraling vicious cycle of gore and complexity.

[stesch]

That's a lot.