Every HTML Element (opens in new tab)

Ah well hello! I'm not sure I've been recognized like that on the internet before. Thank you, that makes me very happy!

From your website it looks like we're in the same city; feel free to shoot me an email (mine is in my profile) if you'd like to grab coffee sometime :)

After looking at the source for this, I have a tangential question (feel free to answer even if you aren't the OP):

Whats the advantage of creating a separate `label` element before/after the input and using `for=` compared to simply wrapping the target input in the label element, like the code snippet below?

    <label>
      Your Name?
      <input />
    </label>

It seems to me that there is a lot less room for error when not using IDs, so I always wrap the input. My pages use a client-side webcomponent to inject fragments of HTML into the page (navbar, footer, etc), and using IDs almost always cause conflicts in the end, so I avoid ID attributes in all but a few very rare instances.

The Popover API only makes non-modal popups.

It was an easy way to use an existing plain-text document where HTML was expected.

https://datatracker.ietf.org/doc/html/draft-ietf-html-spec-0...

The PLAINTEXT element was replaced by the LISTING element (which was itself deprecated in HTML 3.2): https://datatracker.ietf.org/doc/html/rfc1866#section-5.5.2....

I think it's very clear what he meant

Oh wow, TIL the HTML element for furigana is <ruby>

But I didn't demark them so they are still elements.

Also Oxygen was mentioned, but not Argon

> Raises the question, how far can you get using only custom elements and css?

I am so glad to see someone use "raises the question" correctly instead of using "begs the question" which does not mean "raise the question".

In response to your question - you'd be surprised if you have a few (3-4) webcomponents for the most common needs in front-end; things like client-side includes, etc.

In fact, with just client-side includes you get 50% of what a front-end framework gives you (ability to create reusable and standalone components).

Of course then you spend the time you won in ditching the framework to figure out ways to pierce the shadowroot so you can apply your global styles to the component :-(

Ask me how I know.

> Too bad OP is not omniscient and capable of predicting your made up tags

I think a more accurate word here would be "prescient".

"Omniscient" means knowing everything, but I believe that "everything" doesn't include "everything now and in the future.

"Prescient" means knowing future events, i.e. "predicting"

(Emphasis mine)

The memory test is missing some deprecated and non-conforming elements. The HTML spec doesn’t have a single comprehensive list either, so it can be a little tricky to define or name “all” of the elements.

For example, there are elements like nextid or isindex which don’t have element definitions but which appear in the parsing rules for legacy compatibility. These are necessary to avoid certain security issues, but the elements should not be used and in a sense don’t exist even though they are practically cemented into HTML forever.

You can revive <blink> with a tiny bit of css: https://www.quaxio.com/blink.html

You can't bring back something that never existed and both of those have never been part of any HTML standard. See my comment about this elsewhere.

Worse, it has changed content rules and semantics in backward-incompatible ways. Meaning there are pages out there that used to be valid, but aren't anymore. And since HTML spills to EPub specs, I recall there were EPubs or EPub spec examples/test suites themselves having to change specifically, epubcheck being actually used for validation and hence directly noting this backward incompatibility.

In a nutshell, hgroup was originally criticized and rejected when W3C was still redacting HTML specs received from the loose group of browser devs and other people calling themselves "WHAT working group" because it paired headings of multiple ranks in a way that confused assistive technologies in browsers. But the first (and at the same time the last;) W3C HTML recommenndation created as unredacted WHAT WG spec snapshot under the W3C/WHATWG "memorandum of understanding" actually smuggled hgroup in. Then Steve Faulkner removed HTML outlining and the whole concept of sectioning roots that was part of Ian Hickson's vision of "HTML 5" for the longest time, but W3C never actually started a new recommendation process afterwards, and the charter for the HTML WG at W3C, Inc. has ended last year. See details at [1].

Arguably, with this change in 2023, we're now post-HTML5. But don't tell the people believing in a single "HTML 5 standard".

[1]: https://sgmljs.net/blog/blog2303.html

> hgroup is considered deprecated in HTML5 though, whatever that actually means.

It was only deprecated in the W3C specification, not the WHATWG specification.

But now it's back in good standing: https://www.tpgi.com/subheadings-subtitles-alternative-title...

It means if you use it then it’ll work fine but younger people will frown at you.

Is it? I don't see any such warning or notice on https://developer.mozilla.org/en-US/docs/Web/HTML/Element/hg.... It's still listed here: https://www.w3.org/TR/2011/WD-html5-20110405/sections.html#t....

Perhaps it was re-added?

Commercial work is different to pet projects, and, given that I have been told off for using <address> before now, I am wary of making up mu own elements.

I quite like styling the attributes, which gets me half-way to what you describe. In ecommerce we have all kinds of extra attributes for marking up products, although you can ditch that and just have a chunk of JSON+LD these days.

What happens is that I end up with great document structure and human readable/writable HTML and no CSS preprocessor things needed. However, sometimes I have things such as lots of sections containing lots of articles that contain lots of sections. I might take your tip to write '<top-category>' for those top-level sections.

When styling the elements, you tend to use the full range of elements, so a list could be a <dl>, <ol> or <ul> even if it eventually just gets styled as an <ul>. Really, semantics needs to come first, even if the presentation is just normal stuff.

I keep finding code examples where people are doing more than just using divs, which means that I am feeling more confident flexing the whole HTML element LEGO set.

you don't need a hyphen for a custom tag ; as far as i know the hyphen makes it an inline element while no hyphen makes it a block

This selects all the elements individually, so it behaves differently with attributes like margin or border.

Not to hand, for sharing here, but just try it with something like your CV, in neat HTML. Set yourself some rules to not use classes (for the lols, not out of ideological hatred) or divs (there is always a better element).

If you can't do it, there is probably more work to do with your document structure. Also try and always have a h1-h6 heading in your articles, sections, asides and even navs, at the top. Headings should not be in a sea of paragraphs, they should be at the top of a content sectioning element, nowhere else.

The story of XHTML is instructive to the field of software design. There are plenty of good resources on the web if you search why did XHTML fail?

HTML parsing at least is deterministic and fully specified, whereas XHTML, as an XML, leaves a number of syntax errors up to the parser and undefined.

  Conforming software may detect and report an error and may recover from it.

While fatal errors should cause all parser to reject a document outright, this also leaves the end-user without any recovery of the information they care about. So XHTML leaves readers at a loss while failing to eliminating parsing ambiguity and undefined behavior.

Interestingly, it’s possible to encode an invalid DOM with XHTML while it’s impossible to do so in HTML. That means that XML/XHTML has given up the possibility of invalid syntax (by acting like it doesn’t exist) for the sake of inviting invalid semantics.

They're talking about the post itself and its structure

Why was it scrolling to it though?

They are both there, in the table at the bottom