4 ms·

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 sh

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-element 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.

jacobmischka 10y ago
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?
- callahad 10y ago
  My reading of it is that: 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?
  - egeozcan 10y ago
    Then I don't understand why didn't they use something like To select all text, press <user-input type="keyboard"> <interaction-group> <interaction type="keypress">Ctrl</interaction> <comment>together with</comment> <interaction type="keypress">A</interaction> </interaction> </user-input> or you can <user-input type="mouse"> <interaction-group> <interaction type="click"> right-click <ui-item>the empty space around the text</ui-item> </interaction> <comment>and</comment> <interaction type="click"> click <ui-item>Select All</ui-item> </interaction> </interaction> </user-input> Nevermind. After writing this now I understand why.
petepete 10y ago
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 10y ago
  Yeah whoops I noticed that right after posting.
callahad 10y ago
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 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.
- gsnedders 10y ago
  > The notion of using nested kbd tags to indicate literal keys appears to have been introduced by WHATWG when working on HTML5. Did that follow common usage at the time?
  - chc 10y ago
    Talking about common usage of the kbd tag is kind of difficult given that it's never been commonly used, but personally, this was the only thing I ever saw it used for.
baby 10y ago
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)
- egeozcan 10y ago
  > What's the point of this when <code> already exists :/? Because keyboard input doesn't always mean code?
  - baby 10y ago
    yes but the way you express both are usually equivalent, I don't think having too many specific tags in HTML is a good idea.
  - dualogy 10y ago
    > Because keyboard input doesn't always mean code? Well speak for yourself ;)
    - baby 10y ago
      you just contradicted yourself.
      - rkeene2 10y ago
        His statement, yours, and mine are all valid Tcl code :-) They just invoke the procedure named "unknown" a lot, probably -- depending on any other preamble.
AceJohnny2 10y ago
> 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... ;)

jacobmischka 10y ago

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?

callahad 10y ago
My reading of it is that: 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?
- egeozcan 10y ago
  Then I don't understand why didn't they use something like To select all text, press <user-input type="keyboard"> <interaction-group> <interaction type="keypress">Ctrl</interaction> <comment>together with</comment> <interaction type="keypress">A</interaction> </interaction> </user-input> or you can <user-input type="mouse"> <interaction-group> <interaction type="click"> right-click <ui-item>the empty space around the text</ui-item> </interaction> <comment>and</comment> <interaction type="click"> click <ui-item>Select All</ui-item> </interaction> </interaction> </user-input> Nevermind. After writing this now I understand why.

petepete 10y ago

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 10y ago
Yeah whoops I noticed that right after posting.

callahad 10y ago

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 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.

gsnedders 10y ago
> The notion of using nested kbd tags to indicate literal keys appears to have been introduced by WHATWG when working on HTML5. Did that follow common usage at the time?
- chc 10y ago
  Talking about common usage of the kbd tag is kind of difficult given that it's never been commonly used, but personally, this was the only thing I ever saw it used for.

baby 10y ago

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)

egeozcan 10y ago
> What's the point of this when <code> already exists :/? Because keyboard input doesn't always mean code?
- baby 10y ago
  yes but the way you express both are usually equivalent, I don't think having too many specific tags in HTML is a good idea.
- dualogy 10y ago
  > Because keyboard input doesn't always mean code? Well speak for yourself ;)
  - baby 10y ago
    you just contradicted yourself.
    - rkeene2 10y ago
      His statement, yours, and mine are all valid Tcl code :-) They just invoke the procedure named "unknown" a lot, probably -- depending on any other preamble.

AceJohnny2 10y ago

> 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... ;)