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

111–120 of 136 posts

Re: Every HTML Element

#111

Post by lelanthran »

assimpleaspossi wrote: post #105
lelanthran wrote: post #93

Earlier quoted context omitted.

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? Your Name? It seems to me that there is a lot less room for error when not using IDs, so I always wrap the in…

Note that the tag does not need and does not use a closing slash and never has in any HTML standard: https://html.spec.whatwg.org/dev/input.html#the-input-elemen...

Sure, but ... what about the question I posed?

Re: Every HTML Element

#112

Post by idoubtit »

hn_acker wrote: post #50

The element says "This is a modal dialog displayed using just HTML." but that's a bit misleading because the dialog opens using JavaScript `document.getElementById('my-dialog').showModal()` in the onclick attribute of the relevant button.

No, a element will be displayed at page load if it has the "open" attribute. There is no need for JS.

The usual handling is with the JS API, but it's possible to handle it with CSS only. For instance, display the modal window only if a checkbox is checked.

Re: Every HTML Element

#114

Post by 1718627440 »

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)

Re: Every HTML Element

#115

Post by rat9988 »

worble wrote: post #103
robertoandred wrote: post #72

Earlier quoted context omitted.

But it's still a non-modal dialog, which doesn't match the JavaScript functionality.

Apologies, for some reason I was convinced you could get a proper modal using the popover api but you're right, it's not a proper modal.

Funny, when reading this sentence, it felt like an LLM that was hallucinating and apologizes when told.

Re: Every HTML Element

#116

Post by kevindamm »

lelanthran wrote: post #93
wxw wrote: post #78

Earlier quoted context omitted.

Whoa! I'm a big fan of yours. You've really inspired me to think more creatively about the web/software. Thanks a ton, I'm glad this reached you.

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? Your Name? It seems to me that there is a lot less room for error when not using IDs, so I always wrap the in…

Upside (of implicit labels) is that there's no more gap and you can avoid the exclusivity of `id` attributes (as you mention).

Downside is that screen readers may not handle the implicit label as well as one with explicit for= on it.

https://www.w3.org/WAI/tutorials/forms/labels/

Re: Every HTML Element

#117

Post by dmsnell »

rav wrote: post #107

No love for the tag? "The HTML element renders everything following the start tag as raw text, ignoring any following HTML. There is no closing tag, since everything after it is considered raw text." - it's my favorite obscure deprecated HTML tag.

Fun fact: this is very close but slightly inaccurate. I used to think this is how it worked before scrutinizing a rule in the HTML tree-building specification.

The tag leads the parser to interpret everything following it as character data, but doesn’t impact rendering. In these cases, if there are active formatting elements that would normally be reconstructed, they will after the PLAINTEXT tag as well. It’s quite unexpected.

  hi
In this example “hi” will render with every one of the preceding formats applied.

https://software.hixie.ch/utilities/js/live-dom-viewer/?%3Ca...

After I discovered this the note in the spec was updated to make it clearer.

  https://html.spec.whatwg.org/multipage/parsing.html#:~:text=A start tag whose tag name is "plaintext"

Re: Every HTML Element

#119

Post by layer8 »

kisonecat wrote: post #110
rav wrote: post #107

No love for the tag? "The HTML element renders everything following the start tag as raw text, ignoring any following HTML. There is no closing tag, since everything after it is considered raw text." - it's my favorite obscure deprecated HTML tag.

I'm terrified of opening a paren and forgetting to close it! How terrifying to find a tagged paren that cannot be closed! "please accept from me this unpretentious bouquet of early-blooming" s

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

Re: Every HTML Element

#120

Post by dmsnell »

Neuronaut wrote: post #113
bbx wrote: post #9

Relevant: https://htmlreference.io/

The HTML Tags Memory Test [0] game refers to 114 tags. Your link got 113. I wonder what's missing? [0]: https://codepen.io/plfstr/full/zYqQeRw

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.

Post reply on HN