The Elements of HTML | Hacker News Reader

The Elements of HTML

w3c.github.io

94 pointsbpierre36 comments

Please use http://meiert.com/en/indices/html-elements/ instead, as it’s based on the WHATWG HTML Living Standard rather than W3C’s versioned fork.

Two things about that:

1. What are the differences? I've no idea what the significance of the source is.

2. The one you linked is hella unreadable. OP's table is, due to the color differences, extremely easy to skim, while the one you linked has only very similar black&white x and checkmark symbols, which require closer inspection to differentiate.

The "main" development site for HTML5 is the WHATWG. That's where all the browser implementors convened when they lost faith in the W3C.

The WHATWG doesn't bother with versions, there will be no HTML6, for example. They just continually update the HTML5 spec. It's a living spec.

The W3C kind of tracks the WHATWG progress and tags certain points with version numbers (that's where the "5.1" comes from).

Although they do some development on their own, and sometimes both sides disagree and the specs diverge. At some point WHATWG removed an element that W3C retained or the other way around.

I have no idea if they still diverge. I just discard the W3C when it comes to HTML5 and follow WHATWG.

Well, practically speaking, I follow what the Mozilla Development Network documents. :-)

> Well, practically speaking, I follow what the Mozilla Development Network documents. :-)

Yeah, I don't quite know when such a table is very useful anyway. What I check is: (A) http://www.whatwg.org/specs/web-apps/current-work/multipage/... (B) http://caniuse.com/

I love http://caniuse.com but I wish they had more detail. For instance, on the XHR page, I'd like to know which browsers support addEventHandler syntax and which ones require the use of onreadystatechange.

> That's where all the browser implementors convened when they lost faith in the W3C.

With the notable exception of Microsoft.

Is anyone out there actually using XHTML 2.0 currently?

I actually found it interesting to see what was in HTML5.1 and not in HTML5, even though I agree the 5.1 version number is quite silly.

Note, the reason why there some features in 5.1 that are not in 5.0 is that there are some features not implemented yet, 5.0 only includes implemented features.

The page you linked to doesn't look very trustworthy because it displays third-party ads. (Just an observation.)

No blink tag documentation. I can't use this thing.

I believe it is because it is a non-standard tag...

The browser-tag relationship often happens to be more nuanced than just “supports” or “not supports”. I'd recommend skimming an MDN article in case of doubt. They also include browser compatibility tables for quick reference and link to W3C and WHATWG specs.

Another index that's a lot more usable than this one IMHO is:

http://developers.whatwg.org/section-index.html#index

It serves a different purpose.

Your link does not show how HTML evolved/what tags are new, the OP link doesn't show what each element actually is.

Here's one also by WHATWG, with all the relevant changes:

http://meiert.com/en/indices/html-elements/

What is the point of things like hgroup and rbc that are listed as not available in any of the versions on the chart?

hgroup was in the unfinished HTML5 spec but was removed.

hgroup was part of the “original” HTML5 spec, but it won’t be part of HTML5 going forward as the living spec grows up a bit. I think it’s still useful: http://www.whatwg.org/specs/web-apps/current-work/multipage/...

Are frames really deprecated in HTML 5.1? Why does the documentation not tell that?

It's on the list of obsolete, non-conforming features http://www.w3.org/TR/html5/obsolete.html#non-conforming-feat...

Is it me or the <marquee> is missing?

Oh, may be because is a on-standard...

<center> is not HTML5? why? i love <center> & they standardised all other worst practices of the browser vendors, but this one they missed?

Probably because it's presentational, rather than "semantic". You're supposed to use CSS to do this.

If only they could retrofit <center> as a semantic tag, like they did with <small>.

<center>, though, has no semantic implication. <small> can be taken to mean "here be subsidiary information not worthy of large print (or in which we wish to hide critical information we do not with the reader to pay any attention to)". Centred text (or figures) is, and always has been, a stylistic decision, and there are already containers that are semantically meaningful to which that stylistic decision may be applied.

The repurposed definitions of B and I, when everyone remembers them as meaning "bold" and "italic" (and browsers still render them thus), seem really weak to me. SMALL makes sense really only because we have a concept of "small print". I will concede I can't conjure up a similar argument for CENTER, though alongside HEADER (the thing at the top of the page or a section thereof) and FOOTER (the thing at the bottom), it doesn't seem so ridiculous.

Let's not get started on the S/STRIKE/DEL mess.

And you would mark <i class="foreign" lang="fr">le seule mot juste</i> how? It's not emphasized, introducing a new term, or a citation, but it is traditionally typeset as italic (so simply marking it with a <span> is losing information). Much the same can be said for non-emphasized bold text. <strong> would be wrong. B and I still mean bold and italic respectively, but they are used only to cover the cases not specifically covered by other tags. Markup should be about langue, not parôle.

> it is traditionally typeset as italic (so simply marking it with a <span> is losing information).

"traditionally typeset as" is not information about the content, its information about historical typographical practices.

Ideally, over time, the actual semantics, rather than merely the traditional presentation, of the things where the "B" or "I" tags might be the currently least-bad standard tags would be defined in HTML. Though <span lang="fr"> is already semantically adequate for the specific case you present because the "foreign" is implicit in the span having a different lang attribute than the surrounding content, and the "i" is just an irrelevancy about traditional presentation of foreign-language content.

<center>-al (central) information maybe? but yeah, i understand why they don't standardise it, but still i prefer a working <center> tag over

  {
      display: block;
      margin-left: auto;
      margin-right: auto;
  }

You'll need width defined here too..

Agree. And also no valign="middle" in HTML5 <td> elements drives me crazy. I know I'm "supposed" to use CSS, but CSS should be simple. I shouldn't have to fight with silly non-intuitive negative margins and nested div hell just to center something. And then deal with IE's own artistic interpretation of that div hell.

You don't need to use negative margins or anything. You just need the flexible box model (http://philipwalton.github.io/solved-by-flexbox/demos/vertic...).

I can think of an use case for semantic <center> [0]: snippets of text that are somewhat connected to the current text (so they're not an <aside>) but serve a presentational role in the context of the text.

An example:

  Now a ghost, Mr. Smith was surprised to see the words on his own gravestone.
  	 		    HERE LIES
  			A MAN OF NO VIRTUE

[0]: Now that I'm capable of thinking up obscure cases, I just have to hone my ability to sanctimoniously ignore real needed uses and I'll be on my way to join a standards body.

Decoupling of styling and semantic markup. Simply doesn't fit in with any other tag. A simple <div style="text-align:center"></div> works the same.

Reply on news.ycombinator.com