Show HN: A guide to all HTML5 elements and attributes

[shpx]

https://developer.mozilla.org/en-US/docs/Web/HTML/Element

Same thing but guaranteed to be up to date and (more) complete.

For example, htmlreference.io's page for <input> doesn't mention the autocomplete attribute. MDN lists all its possible values.

http://htmlreference.io/element/input/

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

[myfonj]

MDN indeed is (and should remain) the canonical resource, but projects like this could be nice additions.

https://meiert.com/en/indices/html-elements/ - another nice minimalist project with great value.

[callahad]

I believe your kbd example is incorrect. You suggest

> To save, press <kbd>Ctrl + S</kbd>.

But the spec (both W3C and WHATWG) suggests that individual keys should be nested inside an outer <kbd> tag: "When the kbd element is nested inside another kbd element, it represents an actual key or other single unit of input as appropriate for the input mechanism."

Thus, the example should be:

> To save, press <kbd><kbd>Ctrl</kbd> + <kbd>S</kbd></kbd>.

Cite: https://w3c.github.io/html/textlevel-semantics.html#the-kbd-...

On the face of it, this seems ridiculous. It's too verbose, the tag name is misleading, and if you actually use the correct markup on GitHub or StackOverflow, it will render incorrectly because both sites assume the standalone <kbd> element represents physical keyboard buttons.

On the other hand, what's the value in semantic markup if we don't adhere to its semantics?

Practically speaking, I would be a happier person today if I hadn't read that part of the spec, and instead persisted on in blissful ignorance of the element's intended semantics. Thanks, specs.

[callahad]

Update: Looks like the <kbd> tag dates to the first draft of HTML 2.0 in 1993, where it was defined as "in an instruction manual, Text typed by a user." (https://tools.ietf.org/html/draft-ietf-iiir-html-00)

It remained more or less the same through HTML 4.01: "Indicates text to be entered by the user."

The notion of using nested kbd tags to indicate literal keys appears to have been introduced by WHATWG when working on HTML5.

...I'll dig into this more and actually write a blog post about it. I'm this close to relaunching a proper blog.

[petepete]

From the docs:

> Such precision isn’t necessary; the following is equally fine: > <p>To make George eat an apple, select <kbd>File | Eat Apple...</kbd></p>

[jacobmischka]

Wow, the second example in fig 111.

> <kbd><kbd><samp>File</samp></kbd>|<kbd><samp>Eat Apple...</samp></kbd></kbd>

Boy that's terrible.

Edit: Oh, I missed that the example immediately following it is supposedly equivalent and only uses a single outer tag. I don't really understand then, if they're equivalent then what's the point of the defined semantics above?

[AceJohnny2]

> Practically speaking, I would be a happier person today if I hadn't read that part of the spec, and instead persisted on in blissful ignorance of the element's intended semantics. Thanks, specs.

Hear hear! I found this hilarious and speaking to a shared feeling about some specs.

Of course, I kind of understand why these WTF elements make it into the specs. Maybe it's some stupid corner-case that the first implementor's code handled in an odd way because the code was simpler. Maybe there are other interactions that made it simpler to have this case be weird so that it would at least be consistent with that case. Most often, of course, it's because some vendor's code is a buggy mess of spaghetti code that can barely do the most basic stuff without falling over.

We've all been there... ;)

[baby]

What's the point of this when <code> already exists :/?

I'd think a website like this should be opinionated and remove the tags that are useless or should be deprecated in a web 5.0 world (huhu)

(great website btw)

[blauditore]

How is this updated (manually or automatically from official specs)?

Call me paranoid, but I see this diverging from actual specs, then people googling for "html reference" finding it and thinking it is something official. The result would be another W3Schools disaster[1].

In my opinion, the official W3 specification pages are not that bad, and alternatively there's the simpler MDN with strong community support (thus lower risk of deprecation).

[1]: http://www.w3fools.com/

[chamini2]

It's maintained in GitHub[1], from the same guy of cssreference.io[2].

[1]: https://github.com/jgthms/html-reference

[2]: http://cssreference.io/

[giancarlostoro]

That site needs to be updated too, it links to WebPlatform Docs but that website / project itself is discontinued see:

http://docs.webplatform.org/wiki/Main_Page

[dagw]

Really cool. One feature request. when a description of a tag refers to another tag, then those tags should be links.

For example the description for <li> is:

   Defines a list item within an ordered list <ol> or unordered list <ul>.

Here I should be able to click on <ol> and <ul> to get information about those tags.

[frandroid]

Don't ask a web reference page to act like a web page...

[falsedan]

It's missing the links to context & to the spec, which was the killer feature of the old WDG HTML Reference[0].

[0]: http://www.htmlhelp.com/reference/html40/alist.html

[dahauns]

Well, there's a (rather hard to see) link to the MDN (which has reference links) in the upper right corner. But yeah, this should be more prominent.

I'd consider this one expendable, though:

https://imgur.com/a/V6SRq

(Get off my lawn!)

[bshimmin]

Oh, such happy memories of that site... This has quite made my day!

[adontz]

Links to http://caniuse.com/#search= will be useful. dt, li, option, td, th, tr are visible regardless of finder checkboxes

[ahstro]

Nice, but seems to be something wrong with the tagging. I unchecked all tags except `experimental` and I ended up with seven results, only one of which is actually experimental, (`picture`), the rest being _pretty_ cemented (`dt`, `li`, `option`, `td`, `th`, and `tr`). It also seems to leave out some other expermental tags, like `wbr` and `slot`, that are on the site.

[danielhunt]

Those `cemented` examples appear to be ones that don't have a tag at all

If you uncheck all boxes, those items remain. That's probably why they're there for your case.

[Vendan]

The tagging seems to be "filter out anything that has a tag that's not selected", not "only show things that have one of these tags"

[edent]

That's really well laid out. Less detail than MDN, but that site can be overkill.

Two small pieces of feedback. HTTPS support would be good. Also, when I scroll the list of element and then click on one, I'm taken back to the top of the list - I'd like to stay where I am.

[jgorn]

I think a nice feature would be if the description pages linked to the relevant MDN page - for when you want more extensive information about an element.

Otherwise, I love this OP. Will likely use it regularly!

[darekkay]

A more general/comprehensive API documentation tool (which can be also used offline) is DevDocs[1]

[1] http://devdocs.io

[jacobmischka]

Also Zeal[1] for Windows and Linux and Dash[2] for Mac, for those who would prefer native apps.

[1]: https://zealdocs.org/ [2]: https://kapeli.com/dash

[codingdave]

The checkbox filters at the top are somewhat un-intuitive. For example, If I uncheck everything but experimental, I want to see all experimental... but what I get is all experimental that are not block, inline, etc. I mean, as a developer, I see how those filters work... but as an end user, that isn't how I want them to work.

[etimberg]

The canvas page [1] has incorrect defaults listed for the width. It states that the default is 100 but it is actually 300 [2].

1. http://htmlreference.io/element/canvas/ 2. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ca...

[alexgrcs]

The <address> example is wrong. <address> defines contact information, but it's not appropriate for all postal and e-mail addresses. http://html5doctor.com/the-address-element/

[mouzogu]

from a UX perspective i really like this. like the way it's laid out and presented - found it easy to scan.

I know a lot of people big up MDN vs W3Schools and all their arguments are basically correct but i find it (mdn) really ugly and hard to read. i often find myself going to w3schools to just copy a snippet or get a 1 line description of what i need.

mdn often feels more like a technical spec as opposed to a guide, which it kind of is i suppose.

great work on the layout!

[seangrogg]

While I do find this to be the case with regard to MDN it's worth noting that in many cases they have very good practical articles: Using XMLHttpRequest, Getting Started with WebGL, Using IndexedDB, etc.

[xamuel]

This is really great. It would be even greater if it could be used offline. Instead of hitting the server every time I choose one of the elements to view.

[akcreek]

In the past I've used http://devdocs.io/, which is available offline.

[shdon]

You've got the description for the "ins" element the same as for the (admittedly related) "del" element.

[tenaciousDaniel]

I wouldn't say hgroup is experimental. It was on the standards track and now it's being deprecated.

[jbeales]

Came here to post that - it's not experimental at all - it's dead.

[jean-]

Good stuff. Would be even nicer if it showed information about optionally self-closing tags, which is one of the main reasons I occasionally need to look at the spec. For instance:

> A p element's end tag may be omitted if the p element is immediately followed by an address, article, aside, blockquote, div, dl, fieldset, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, nav, ol, p, pre, section, table, or ul, element, or if there is no more content in the parent element and the parent element is not an a element.

Links to the relevant parts of the official spec would be nice too, e.g. https://www.w3.org/TR/html5/grouping-content.html#the-p-elem...

[nathancahill]

Why would you do that to yourself?

[talmand]

I'd rather just close the tag instead of trying to recall the specific instances of when I'm not required to close the tag.

[tannhaeuser]

Don't worry, http://sgmljs.net/docs/w3c-html51-dtd.html has you covered

Edit: to expand a bit, the link is to a pretty readable/hyperlinked DTD grammar for HTML (W3C HTML 5.1)

[ytugiuyghvk]

Nit: self-closing refers to tags that are closed like <this/>.

[javajosh]

Without compatibility information this is more dangerous than useful. For example, a naive HTML author would use the semantic tags, only to fail in most browsers. There is mention neither of compatibility nor polyfill. Better off with MDN and caniuse.com.

[teh_klev]

Nice...would be useful to have the summary of what a tag's purpose is on the main page list of tags. For three letter or less tags it's not always obvious what I'm looking to achieve a specific task.

[xophishox]

Is there something similar to this for javascript?

I really find this format super easy to read, even if there may be slight inconsistencies and nuances to reading it.