Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Every HTML Element

iamwillwang.com

Post reply on HN
Print view View original

131–136 of 136 posts

Re: Every HTML Element

#131

Post by xigoi »

1718627440 wrote: post #114
Theodores wrote: post #22

Most people insist on only using one element, which is the element of last resort, according to MDN. This is our friend, the . The only use case I have for is in a details/summary where there is no CSS to select the contents of a element, excluding the . Does this mean I use instead of , as a 'direct replacement'? Nope. When using CSS grid, there is no need for wrappers around everything. I do like to use the full HT…

> The only use case I have for is in a details/summary where there is no CSS to select the contents of a element, excluding the . div > *:not(summary)

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

Re: Every HTML Element

#132

Post by 1718627440 »

xigoi wrote: post #131
1718627440 wrote: post #114

Earlier quoted context omitted.

> The only use case I have for is in a details/summary where there is no CSS to select the contents of a element, excluding the . div > *:not(summary)

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

I see. But then that wrapper is actually semantic and thus is eligible for the appropriate element.

Re: Every HTML Element

#134

Post by jamesfinlayson »

benwills wrote: post #37

For people interested in this sort of thing, I recently published a blog post looking at counts of HTML tags and their attribute values from a 2.9B page Common Crawl dataset. [1] There's also a SQLite DB available to download of the top 1k tag+attr+value combinations. [2] [1] https://webparsing.io/blog/hidden-in-html-parsing-page-layou... [2] https://webparsing.io/data/commoncrawl-2024-11-html-tags-att...

I think someone who works on Chrome did something a few years ago - though I can't remember exactly what they were trying to figure out.

Re: Every HTML Element

#136

Post by dmsnell »

thiht wrote: post #122
dmsnell wrote: post #121

Earlier quoted context omitted.

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 t…

Interesting perspective, it makes me miss XHTML wayyy less. I was under the impression that XHTML (XML) was better specified and had less weirdness. I know HTML is now better specified but some of the things inherited from HTML 4 and before make no sense to me (optional closing times SOMETIMES, optional stuff everywhere).

HTML didn’t make sense to me until I realized it’s built on a state machine and its rules are based on what’s on the stack of open elements. For example, a number of tags trigger a rule to close open P elements or list items, and many end tags trigger a rule saying something like “close open elements until you’ve closed one with the same name as this tag.”

This, IMO, is a bigger reason to avoid regex and XML parsers for HTML documents. The rules aren’t apparent when thinking linearly about what strings appear after or before each other; they become clearer when thinking of HTML as a shorthand syntax for certain kinds of push and pop operations.

XHTML is easier to parse, but for well-formed documents pushes the complexity of invalid markup into the rendering side. For example, it’s well-formed to include a button inside a button, so XHTML browsers render exactly this, but it makes no sense from a UI perspective and strange things happen when invalid markup is sent in well-formed XML.

Post reply on HN