Remove HTMLTimeElement: dateTime syntax table, move it to <time> #35453
Conversation
Josh-Cena
requested review from
Elchi3 and
estelle
and removed request for
a team
github-actions
bot
added
Content:HTML
|
Preview URLs (comment last updated: 2024-08-15 20:19:59) |
| @@ -34,46 +34,131 @@ The _datetime value_ (the machine-readable value of the datetime) is the value o | |||
|
|
|||
| ### Valid datetime values | |||
There was a problem hiding this comment.
| ### Valid datetime values | |
| ### Valid `datetime` values |
There was a problem hiding this comment.
Hi @dipikabh, when we loosened the heading typesetting guidelines, I made sure it says "you may use code formatting, but you are not required to". My agreement to the initial proposal was based on the intention of disambiguation, and when there's no ambiguity, I would prefer not to use code in headings.
There was a problem hiding this comment.
On the contrary, I somehow remember the consensus leaning more towards adding the code formatting backticks in headings, and I believe I've also been suggesting those in my reviews.
I went looking — from Heading levels formatting guideline in our style guide and #22472 to https://github.com/orgs/mdn/discussions/271. I see the guideline is loose when it says "you can use backticks for code terms".
I agree, with datetime, there's no ambiguity, but it's a term we always format with backticks in prose, so it would make sense to extend the same treatment to it in the heading as well.
To me, it's just simpler and easier to consistently use backticks around names of properties, values, interfaces in headings (the guideline is not against it) without needing any other criterion. I'm not sure if everyone is using the same approach, that is ambiguous vs unambiguous, when deciding whether or not to use backticks. All the same, I won't insist on the change here but might be worth considering.
There was a problem hiding this comment.
My decision on this is because H1 headings can't have code formatting anyway, so we already have code-stripping happening for top-level headings.
There was a problem hiding this comment.
H1s never figured in my mind as part of this discussion! :) It's only been about the section headings.
Co-authored-by: Dipika Bhattacharya <dipika@foss-community.org>
|
Looks like we converged on something we can agree on, so I'm going to self-merge it. Thanks for the reviews |
This table is poorly marked up and very inconsistent. It also shouldn't belong here but should belong in the
<time>reference which is the canonical place for HTML attribute values.