HTML5's time is back | Hacker News Reader

HTML5's time is back

lists.w3.org

73 pointsd0vs37 comments

All these specialised tags seem so completely redundant. Why do we need a sanctioned header and footer and time tag? Why wouldn't you just make tag names open ended and control the presentation with CSS? Why on earth can't we use arbitrary attribute names, instead we have to use this clunky data attribute. It's truly ridiculous.

This is how I hear W3C announcements on such things:

"A specialist committee of 500 have reviewed a sample of so-called 'internet sites' as found on the so-called 'internet'. We have noticed that often times people like to have so-called 'headers' and 'footers' in their website. We have decided then that in your best interests that we have officially sanctioned a <header> and <footer> tag. Thank you, thank you. We also have noticed that occasionally people put times and dates in their web pages. Therefore we have sanctioned a <date> tag for your convenience. We are glad to contribute to the evolution of the web."

It is so arbitrary and detached from real world web development. This isn't 'bringing the web forward' in any sense. I don't know what the answer is but it certainly isn't this.

If everything were arbitrary then there would be no agreed upon standards and semantics.

By having an agreed upon structure you allow the internet to get smarter. Data mining, search engines, usability, etc...

E.g <phone> tag that is always expected to have a phone number. That way when it's rendered on certain devices it will always have a phone number that can be interacted with.

Sure you can achieve that now with text parsing but there's better ways to evolve the web and that's what standards are for and the introduction to new elements that are semantically accurate.

A phone number is better represented by a URI (such as the tel: URI scheme). Though I agree with you, I wonder if there is no better way to represent time as well, rather than a new HTML element.

Pardon the devil's advocate question, but to what extent is semantic markup (other than with microformats) relevant to today's web? I mean, how is it used by anyone? I've tried to use semantic markup and it's not really a very effective abstraction for many kinds of data and UX.

Ask anyone who accesses the web through a screen reader and they’ll tell you it’s extremely useful. Not to be flippant, but well structured markup allows a screen reader to:

* Emphasise headings

* Allow users to skip past header sections automatically

* Ignore information unrelated to the content (aside sections)

* Allow users to navigate by heading structure

* Voice certain parts differently - links are an obvious candidate, but screen readers could put on different voices for quotes

* Etc etc etc.

Hang on a sec, that's what CSS does for the sighted, we don't expect the HTML to tell the browser how to layout the page, so why are you expecting the HTML to be able to tell a screen reader how to present it.

Semantic web is suppose to elicit meaning from content, not presentation.

The whole concept of semantic markup is extremely fishy to me. On the one hand you're supposed to remove presentation directions but on the other it's supposed to give presentation clues to screen readers?

When you build a site with CSS you’re over-riding the browser’s built in stylesheet. If you don’t provide your own CSS then the site is readable without, because the browser lends basic visual meaning to semantic markup.

Think of screen readers as having internal styling. Links are read in a different voice because the screen reader is applying a default audio style to the page.

Audio styling is part of CSS2.1 [1] but isn’t widely supported or widely written (classic chicken/egg problem). If you want to you can (at least theoretically) over-ride a screen reader’s default presentation of your markup.

[1] http://www.w3.org/TR/CSS21/aural.html

I know, although I disagree that almost any site without its css stylesheet is really readable, but the original question was how is semantic HTML useful.

If usability is the only answer and it's doing precisely the opposite of what semantic HTML is supposed to achieve, namely separation of content and presentation, it appears to me that we've not really decided what semantic HTML is, it just sounds kinda cool and has a happy side effect of making it easier for screen readers to parse.

So many of these new tags seem too narrow, a victim of the old fashioned thinking of the w3c where everything, to them, is still a document.

Why use article instead of div? Will it really make mining easier or will you get loads of false positives? If my site creates hourly weather reports, are they articles? Why can't I define my own tag of weatherreport? Is there any point?

To quote ryan's original comment:

This isn't 'bringing the web forward' in any sense. I don't know what the answer is but it certainly isn't this.

HTML shouldn't need CSS + JavaScript to incorporate basic functions. The point of these new elements is to DEFINE semantics that we can take advantage of TOMORROW. This goes far beyond screen readers.

The HTML doesn't tell the screen reader how to present the content; it just tells what the content is, and the screen reader then decides the best way to present it (web devs just aren't qualified to decide that).

To give just one example, microdata and RDFa (as well as microformat) contribute to Google search snippets, map location etc.: http://www.google.com/support/webmasters/bin/answer.py?answe...

Microformats are the one case that does seem obvious/sensible to me.

It would seem to me that decentralized, ad-hoc microformat micro-standards would make more sense than a slow, bureaucratic process. The web will adopt good ideas, useful semantics, etc., so I don't really see the benefit of a 5+ year process of introducing a few new tags.

Element names are not designed to be hooks for CSS and JS - they are designed to have meaning, to create a semantic web. This can't be achieved with arbitrary names.

For example, pre-HTML5 sites often use a variety of <div id="head">, <div id="heading">, <div id="header">, etc. If each website is a separate entity that's fine, but if we have a longer term goal of creating some kind of global project - a programmable, mashable, indexable web - it's easier with a pre-agreed vocabulary.

I agree there may be a better way to do it and tag names could be taken to far, but with iterative development we'll get something that works and can be used by everyone (which is better than a perfect solution that never leaves the drawing board), IMO.

Trying to aim a standard at an amorphous, undefined future goal doesn't seem very likely to succeed.

Ok, then. Let’s not talk about future goals, talk about current benefits. Headline tags allow the visually impaired to efficiently navigate webpages. Their screenreader doesn’t have to read everything, they can jump from headline to headline in order to get an overview.

This wouldn’t work so great if every website used different headline tags.

Is there actually a shipping user agent, screen reader or otherwise, that behaves this way? I could be wrong but I don't recall that they were ever particularly quick to make use of all the new markup we try and provide for them.

It reminds me of the battles about CSS vs Tables for layout where screen readers were always wheeled out as an argument for not using tables. Expect that all the shipping screen readers seemed to cope fairly well with tables.

(There are many ways in which your markup can break screen-readers but the issues are often more subtle and complex than 'use this tag or that tag' and require someone to actually test in a specific screen reader)

The iOS and OS X screenreader VoiceOver, for example. (JAWS, too, of course.)

It’s pretty cool actually: You can rotate with two fingers to switch between different ways of navigating the page: headline to headline, link to link, container to container, line to line and so on.

I suggest you try it out when you have the chance. (If you want you can test out HN to see how the experience here could be significantly improved if headline tags were used correctly.) Here is a short video if you can’t try yourself: http://www.youtube.com/watch?v=rxlxx6RXbs8

Do you really think accessibility advocates were asking everyone to correctly use headline tags for fun?

Have you ever listened to a web page read in VoiceOver or JAWS? When you can't see the screen, having additional details provided to you by the screen reader (through analyzing the tags surrounding the element) can be invaluable. Headers, Footers, Time and Date are all very specific types of content, in this case either "not part of the main content of the page" or "important things you probably want to make note of."

It's not about presentation, it's about semantics, and making the web more accessible.

Accessibility is an important part of HTML and the Web itself, so in that sense this sort of thing is most certainly contributing to the evolution of the Web.

One advantage I can think of is accessibility. For example, a text-only browser could certainly handle header and footer tags, whereas pure CSS layouts probably couldn't be handled well.

I think the cause for header/footer tags is that there's no way for another program (like googlebot, browser extensions that use JavaScript to access the DOM, page scrapers, etc) to figure out where the header and footer are. Sure, it's easy for you to figure that out if you wrote the page, but how does a program that's reading the page figure that out?

I'm sure there are readability-like algorithms to figure this out, but I'd also imagine that they're not 100% accurate and need hints from the page's creator from time to time (just like readability).

This is just speculation, but I'd appreciate if browsers could detect <time> tags and give me a context menu with various options related to times (add to calendar / view what was in my calendar on a past date, copy in alternate format...)

Your entire objection seems to be predicated on the idea that tags are either arbitrary or presentational, rather than a means of organizing and characterizing data. You may use them that way, but that is not how it's supposed to be.

The benefits of some new elements, e.g. <article> and <section> as opposed to <div> are more subtle, but <time> has a number of use cases beyond improved accessibility.

Right now, if you're a developer wanting to display dates and times in the user's timeline you have to write custom JS, but if encoded as <time> this job could be done by standardised JS libraries, widely distributed browser extensions or even browsers themselves.

Similarly, users could set their browsers to always (or just on request, e.g. as a contextual pop up) display times in 24h system or in their local non-gregorian calendar, which would help especially children or people with less education to understand more of the web.

The answer is that leading products (+ optionally standards bodies) create standards, not standards bodies by themselves. The W3C is optional in the evolution of the web, however much they may not like that.

So you would also like to skip the H1-H6 elements? This is not about presentation, it's about context.

"Why do we need a sanctioned header and footer and time tag? Why wouldn't you just make tag names open ended and control the presentation with CSS?"

I feel the same way. Tags have always been, until recently, only added when a new behavior was to be implemented (ex: canvas, video, etc).

I think this change in focus from technical ability to semantic information really signals that we are solidly into the information age.

We have pretty much worked out how to get stuff done, it's time to start harnessing the results and start reporting on what is out there.

Classifying the information can only be a good thing.

> Tags have always been, until recently, only added when a new behavior was to be implemented (ex: canvas, video, etc).

Not really. <th> versus <td> comes to mind.

I'm so glad about this response from W3C (I do criticize the general bureaucracy of W3C though). In many aspects, I felt that the recent moves of the HTML living standard were much like that of XHTML2:

- Why do keep the redundant <a> element while we can add the href attribute to all elements?

- Why do keep <br> while we can generalize the line structure via <nl>? (NB: I'm not sure about the exact element name)

Is removing <time> in favor of <data> really different from these statements?

The problem with HTML is that it tries to simultaneously solve two completely different problems:

1) How do I provide data in a meaningful, semantic, machine-readable format?

2) How do I display data in a web browser, on a phone or in print? Do I use columns? What type of navigation options should I provide to the user in this instance?

XML solves (1). XSLT/HTML (as a UI layout description format only) can solve (2).

Attempts to merge the two concepts together will end in certain failure.

Yes, certain failure. That internet thing will never amount to anything :)

There's a saying about the perfect being the enemy of something, can't remember it though.

Can someone translate this from bureaucrat-ese to English for me? I really don't understand what this is saying and what its importance is.

Dear Mr. Editor,

You have until next Tuesday to put the <time> element back in the spec. If you don't, we'll do it for you.

Lots of love,

HTML WG Chairs

Ah, ok. I parsed the title as meaning "HTML 5's time has come again".

I did same, and was left here thinking "Where the frak have I been - when was HTML5 on hiatus from being current?"

I like the followup message:

I respectfully request that the <time> rollback happen at 2am on Sunday.

http://lists.w3.org/Archives/Public/public-html/2011Nov/0012...

(Probably only funny if you have had to do timezone handling in your code before)

Reply on news.ycombinator.com