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.
Show HN: A guide to all HTML5 elements and attributes
31–40 of 97 posts
Re: Show HN: A guide to all HTML5 elements and attributes
#32Re: Show HN: A guide to all HTML5 elements and attributes
#33Re: Show HN: A guide to all HTML5 elements and attributes
#34> 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...
Re: Show HN: A guide to all HTML5 elements and attributes
#35I believe your kbd example is incorrect. You suggest > To save, press Ctrl + S . But the spec (both W3C and WHATWG) suggests that individual keys should be nested inside an outer 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 Ctrl + S . Cite: https://w3c.gi…
> File|Eat Apple...
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?
Re: Show HN: A guide to all HTML5 elements and attributes
#36I believe your kbd example is incorrect. You suggest > To save, press Ctrl + S . But the spec (both W3C and WHATWG) suggests that individual keys should be nested inside an outer 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 Ctrl + S . Cite: https://w3c.gi…
> Such precision isn’t necessary; the following is equally fine: >
To make George eat an apple, select File | Eat Apple...
Re: Show HN: A guide to all HTML5 elements and attributes
#37I believe your kbd example is incorrect. You suggest > To save, press Ctrl + S . But the spec (both W3C and WHATWG) suggests that individual keys should be nested inside an outer 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 Ctrl + S . Cite: https://w3c.gi…
From the docs: > Such precision isn’t necessary; the following is equally fine: > To make George eat an apple, select File | Eat Apple...
Re: Show HN: A guide to all HTML5 elements and attributes
#38I believe your kbd example is incorrect. You suggest > To save, press Ctrl + S . But the spec (both W3C and WHATWG) suggests that individual keys should be nested inside an outer 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 Ctrl + S . Cite: https://w3c.gi…
Wow, the second example in fig 111. > File | Eat Apple... 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?
1. ___ means "literal user input"
2. ___ means "this specific, atomic keypress"
3. ___ means "this specific, atomic button/action/menu item"
So you can fall back to just using method 1, but it implies generic user input, inclusive of but not limited to keypresses. Thus, styling and treating a single kbd tag specifically like a keyboard button is still likely incorrect, since that precludes other semantically valid uses?
Re: Show HN: A guide to all HTML5 elements and attributes
#39Good 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,…
Re: Show HN: A guide to all HTML5 elements and attributes
#40Why does it want me to whitelist it in my adblocker when it claims to be free and to always be free?