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.
https://meiert.com/en/indices/html-elements/ - another nice minimalist project with great value.
> 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>.
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.
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.
Did that follow common usage at the time?
> Such precision isn’t necessary; the following is equally fine:
> <p>To make George eat an apple, select <kbd>File | Eat Apple...</kbd></p>
> <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?
1. <kbd>___</kbd> means "literal user input"
2. <kbd><kbd>___</kbd></kbd> means "this specific, atomic keypress"
3. <kbd><kbd><samp>___</samp></kbd></kbd> 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?
To select all text, press
or you can
right-click <ui-item>the empty space around the text</ui-item>
click <ui-item>Select All</ui-item>
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... ;)
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)
Because keyboard input doesn't always mean code?
Well speak for yourself ;)
They just invoke the procedure named "unknown" a lot, probably -- depending on any other preamble.
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.
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).
For example the description for <li> is:
Defines a list item within an ordered list <ol> or unordered list <ul>.
I'd consider this one expendable, though:
(Get off my lawn!)
If you uncheck all boxes, those items remain. That's probably why they're there for your case.
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.
Otherwise, I love this OP. Will likely use it regularly!
This would be really good. Mostly I'm just looking for a quick reference, but sometimes I want all the details.
They do, top right next to (the useless, ridiculous) 'share' link.
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!
> 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...
Edit: to expand a bit, the link is to a pretty readable/hyperlinked DTD grammar for HTML (W3C HTML 5.1)
I really find this format super easy to read, even if there may be slight inconsistencies and nuances to reading it.
However, the code examples don't look very nice on my box due to the font which comes out as Nimbus Mono L. How about you link to an actual font? (I like Ubuntu Mono, though there are lots of other good programming fonts).
Also with respect to code samples, would black text on a white background be a possibuility?
No, that's not true. I have just changed the monospace font on Firefox to Ubuntu Mono, and it is still showing as Nimbus Mono. This is the website doing this -- for example the change is reflected fine in HN.
> I feel you as a user have some responsibility in that case.
These days when I build websites I normally specify specific web fonts so that I know it won't default to something not good.
> "Inconsolata", "Source Code Pro", "Consolas", "Monaco", "Courier", monospace
So either it is using one of those fonts (Courier and Nimbus Mono L are similar I guess), the site is serving you special CSS that I'm not getting (and I've tested it on Linux and Windows), or Firefox has done some weird font aliasing and one of the above is being treated as Nimbus Mono L.
(I tried removing Courier and it displayed the text in something nice-looking which Firefox reports is DejaVu Sans Mono)
Is it design completely custom or did you use a template or theme? I'm really struggling with the design side of my side projects.
Also, if you don't mind me asking, how difficult was it to get approved for Carbon Ads?
I appreciate that the website works well even with all scripts blocked.
One minor issue: Your search bar doesn't look like one :)
I didn't notice it until my second visit.
- nice brogramming;
- not up to date;
- not refering the spec (sorry this is important when you are in trouble);
- well read @shpx comment he is right
Verdict: more signal less noise policiy says, don't click to the bait.
normally I put a goatse.cx link here or a rickroll