[HN Gopher] Every HTML Element
___________________________________________________________________
Every HTML Element
Author : wxw
Score : 445 points
Date : 2025-01-25 19:02 UTC (1 days ago)
(HTM) web link (iamwillwang.com)
(TXT) w3m dump (iamwillwang.com)
| XCSme wrote:
| Weird that the URL links to the bottom of the page(?).
| wxw wrote:
| Sorry bout that, fixed! It was scrolling to the <iframe>.
| amphitheatre wrote:
| On mobile (Safari), the link to the article scrolls me down
| towards the bottom of the page by the iframe/red dot, making me
| think half the page was missing.
| sidsancheti wrote:
| I'm on PC (Brave) and I experienced the same thing.
| wxw wrote:
| Thanks for the heads up! Misconfigured the source in <iframe>.
| Interesting behavior.
| mg wrote:
| I wonder if it would be possible to do this in a way that the
| page shows its own source code.
|
| Similar to:
|
| https://no-gravity.github.io/html-quine/index.html
|
| Could be tricky, because non-textual elements would probably have
| to be taken care of individually. For example a video would
| probably have to show a video of its own representation in code.
| jazzypants wrote:
| I think it would be better to do a split panel so you could see
| the source and the end result side by side. This would
| eliminate the need for somehow showing the video and the source
| in the same place. You could even include the shadow DOM trees
| for a full explanation of how the browser renders complex tags
| like video.
| fsckboy wrote:
| for certain elements, a quinesque approach might not be that
| useful, but source could be displayed juxtaposed to results.
| (to show numbered lists, do you want to display the ol tags
| before the numbers (thus using fake numbers) or do you let ol
| numbering tags tag the elements with numbers and then show the
| source inside that?)
|
| btw it really drives me crazy that browser implementors think
| that when I copy/paste a numbered list, I somehow don't want
| the numbers.
| alwillis wrote:
| This is very good: https://meiert.com/en/indices/html-elements/
| TZubiri wrote:
| Except this custom one I just invented that I implement in my
| custom browser
| byearthithatius wrote:
| Too bad OP is not omniscient and capable of predicting your
| made up tags
| lelanthran wrote:
| > 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)
| riffraff wrote:
| That's obviously up to your definition, but omniscience as
| commonly understood as an attribute of the Christian God is
| also knowledge of future events (which is why it's usually
| argued that it conflicts with free will).
|
| "The future" is part of "everything".
| lelanthran wrote:
| I agree with your reasoning (I'm not married to those
| definitions).
|
| Looking at it again, I would still say that "prescient"
| would be more accurate, because: 1.
| Omniscient is a superset that include prescient"
| 2. Prescient is a narrower meaning than omniscient.
|
| IOW, when describing a car, for example
| 1. "Automobile" can be used to describe my wife's car
| 2. "SUV" is a more accurate description.
|
| So I'll still go with "prescient" being more accurate, in
| much the same way that "SUV is more accurate.
| ruined wrote:
| ive been demaking html elements by removing them from my custom
| browser so it evens out
| TZubiri wrote:
| But I didn't demark them so they are still elements.
|
| Also Oxygen was mentioned, but not Argon
| somat wrote:
| Raises the question, how far can you get using only custom
| elements and css?
|
| It sometimes appears that the modern ideal is to not have an
| element "do" anything on it's own and depend on the css to
| define it's purpose. But we still have a lot of historical
| baggage we are carrying around.
| lelanthran wrote:
| > 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.
| bbx wrote:
| Relevant: https://htmlreference.io/
| assimpleaspossi wrote:
| Even more relevant:
| https://html.spec.whatwg.org/dev/semantics.html#semantics
| Neuronaut wrote:
| 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
| dmsnell wrote:
| 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.
| assimpleaspossi wrote:
| https://html.spec.whatwg.org/dev/obsolete.html
| alentred wrote:
| Wait. No <script> element? An elephant went missing!
| matchamatcha wrote:
| Look at the source.
| eieio wrote:
| I like this!
|
| It's fun to compare it to "A blog post with every HTML element"
| [1][2], which gets at a (very!) similar thing but in a very
| different way. This post primary _shows_ , and is a little more
| chaotic (meant positively!) whereas the other post is much more
| prose and explanation heavy (also good, but very different).
|
| [1] https://www.patrickweaver.net/blog/a-blog-post-with-every-
| ht...
|
| [2] HN discussion: https://news.ycombinator.com/item?id=37104742
| wxw wrote:
| 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.
| eieio wrote:
| 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 :)
| lelanthran wrote:
| 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.
| assimpleaspossi wrote:
| Note that the <input> 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...
| hk1337 wrote:
| It was required in the XHTML 1.0 specs, people carried it
| over I don't know why but everyone stopped validating
| html so nobody cared.
| lelanthran wrote:
| Sure, but ... what about the question I posed?
| kevindamm wrote:
| 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/
| robby1066 wrote:
| First I've ever heard of hgroup.
|
| Subheadings are one of those little things I've wondered about
| the proper semantics for a million times and always end up doing
| something slightly different on the fly.
| hellcow wrote:
| PicoCSS uses them well, as an example:
| https://picocss.com/docs/typography#heading-group
| adzm wrote:
| hgroup is considered deprecated in HTML5 though, whatever that
| actually means.
| sillysaurusx wrote:
| It means if you use it then it'll work fine but younger
| people will frown at you.
| fsckboy wrote:
| unlike the <blink> tag where younger people will just stare
| at you in a creepy extended unblinking gaze. it would be so
| much more satisfying if it still made them blink.
| 9dev wrote:
| I _absolutely_ need to write a polyfill for that.
| amenghra wrote:
| blink { animation: 1s ease infinite
| blink_effect; } @keyframes
| blink_effect { 0% { opacity: 0;
| } 50% { opacity: 1; }
| 100% { opacity: 0; } }
| hellcow wrote:
| 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?
| adzm wrote:
| Hmmm you are right! This discussion explains that a bit
| https://stackoverflow.com/questions/15808330/hgroup-
| element-... looks like it was going to be removed, but
| WHATWG ended up keeping it.
| alwillis wrote:
| > 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...
| tannhaeuser wrote:
| 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
| alwillis wrote:
| > First I've ever heard of hgroup.
|
| <hgroup> was officially added to the HTML spec in 2018 [1]
|
| It was deprecated in the W3C spec but not from the WHATWG spec,
| before they were merged.
|
| [1]: https://html.spec.whatwg.org/#the-hgroup-element
| joshdavham wrote:
| I like that you included the <ruby> tag! I really wish more pages
| would use them when rendering Chinese/Japanese characters in
| English text.
| fsckboy wrote:
| (your comment is very minimally informative, containing 1 bit
| of information: "there is something to learn about ruby".
| Searching "show source", "hidden gems" on OP's page marks the
| ruby spot)
|
| and looking up the <ruby> tag:
|
| https://interactive-examples.mdn.mozilla.net/pages/tabbed/ru...
|
| _The <ruby> HTML element represents small annotations that are
| rendered above, below, or next to base text, usually used for
| showing the pronunciation of East Asian characters. It can also
| be used for annotating other kinds of text, but this usage is
| less common._
|
| _The term ruby originated as a unit of measurement used by
| typesetters, representing the smallest size that text can be
| printed on newsprint while remaining legible._
| efilife wrote:
| I think it's very clear what he meant
| burgerrito wrote:
| Oh wow, TIL the HTML element for furigana is <ruby>
| joe8756438 wrote:
| no marquee? c'mon
| hinkley wrote:
| It's a prank bro!
| ewrong wrote:
| Blink
| cookie_monsta wrote:
| They are both there, in the table at the bottom
| assimpleaspossi wrote:
| Both <marquee> and <blink> have never been part of any HTML
| specification since the beginning of time except, in marquee's
| case, it was included in the current spec for the whole purpose
| of marking it as obsolete.
| pastureofplenty wrote:
| I know it's deprecated but I was expecting to see <xmp>.
| mwcz wrote:
| It was so fun tossing that opening tag into a forum post and
| watching the whole forum disintegrate.
| assimpleaspossi wrote:
| <xmp> was made obsolete in HTML3.0 or 2.0 which was around
| 1995, I think. In any case, it was removed from version 4.0.
| Isognoviastoma wrote:
| It's impressing that browser can display many levels of recursive
| iframe.
| queueueue wrote:
| I've counted 18! The next one was blank.
| Theodores wrote:
| Most people insist on only using one element, which is the
| element of last resort, according to MDN. This is our friend, the
| <div>.
|
| The only use case I have for <div> is in a details/summary where
| there is no CSS to select the contents of a <details> element,
| excluding the <summary>.
|
| Does this mean I use <section> instead of <div>, as a 'direct
| replacement'? Nope. When using CSS grid, there is no need for
| <div> wrappers around everything.
|
| I do like to use the full HTML element set, and, with scoped CSS,
| to style the elements, rather than have loads of divs with loads
| of class attributes. It all looks so much neater, particularly if
| the unstyled CSS looks rather good.
| alxeder wrote:
| do you have an example?
| Theodores wrote:
| 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.
| rerdavies wrote:
| Out of idle curiosity, which better element am I supposed
| to use when I'm using flex layout to space out elements on
| my page?
|
| (e.g., a toolbar with with left- and right- justified
| elements, among which is an expanding searchbox).
| assimpleaspossi wrote:
| HTML elements are used to describe their content and not
| have anything to do with layout. While they often have
| common properties, these can be changed using CSS.
|
| So use the element that best describes its content.
| hellcow wrote:
| This is a great approach. Just to add to it, you can also use
| custom elements in lieu of classes, such as:
|
| <my-product>...</my-product>
|
| Any tag with a hyphen is considered a custom element, which is
| completely valid HTML -- even without defining the element in
| JS.
|
| This gives you a more descriptive `div`, and then instead of
| classes like `product-primary`, you can use semantic
| attributes, like `<my-product primary size="large">`. In
| combination with CSS nesting, you can get some great looking
| HTML and CSS with minimal markup/visual noise and no build
| step.
| croisillon wrote:
| 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
| MrVandemar wrote:
| You do need a hyphen for a custom-tag. The HTML specs have
| guaranteed never to create a tag with a hyphen, so it
| prevents collisions with any future tag additions.
| Theodores wrote:
| 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.
| lelanthran wrote:
| > I do like to use the full HTML element set, and, with scoped
| CSS, to style the elements, rather than have loads of divs with
| loads of class attributes. It all looks so much neater,
| particularly if the unstyled CSS looks rather good.
|
| From a discussion on HN a few days ago, I bookmarked this:
| https://github.com/dbohdan/classless-css
|
| For the most common types of front-end work one needs to do,
| classless CSS is enough.
| 1718627440 wrote:
| > The only use case I have for <div> is in a details/summary
| where there is no CSS to select the contents of a <details>
| element, excluding the <summary>.
|
| div > *:not(summary)
| kayvulpe wrote:
| An index would be great
| fsckboy wrote:
| what this comment section is missing is "hey, here are other
| pages that do the same thing is a slighty different way" (there
| must be tons!? I would enjoy and learn from those type of
| comments so much I that I'd shout, "this is a motherfucking
| comment section!" https://motherfuckingwebsite.com/
| benwills wrote:
| 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...
| bornfreddy wrote:
| No <details> / <summary>? [0]
|
| [0] https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/de...
| adzm wrote:
| It's at the bottom by the dialog!
| 1LCode wrote:
| I think there was at the bottom of the form? No? In the "click
| here" part.
| hmmokidk wrote:
| As a browser game enthusiast I will have you tried for missing
| canvas
| butz wrote:
| Canvas is stealthily hiding, as it has no content to display.
| 3willows wrote:
| Lols you are offering to sell this for $1?
| https://iamwillwang.com/dollar/
| wxw wrote:
| haha, that's a bit of an inside joke (...for now?)
| divbzero wrote:
| Disappointed to see <blink> or <marquee> merely mentioned but not
| used on that page, seemed like a serious omission.
|
| Based on my tests just now, <blink> no longer blinks in today's
| browsers but <marquee> still scrolls happily.
| assimpleaspossi wrote:
| Both have never been part of any HTML specification. See my
| comment elsewhere here.
| hn_acker wrote:
| The <dialog> 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.
| worble wrote:
| Which is strange because you absolutely can open dialogs
| without javascript with the popover attribute
|
| https://developer.mozilla.org/en-US/docs/Web/API/Popover_API...
| robertoandred wrote:
| The Popover API only makes non-modal popups.
| worble wrote:
| Yes, but in the article I posted:
|
| > Popovers created using the Popover API are always non-
| modal. If you want to create a modal popover, a <dialog>
| element is the right way to go.
|
| > You can turn a <dialog> element into a popover (<dialog
| popover> is perfectly valid) if you want to combine popover
| control with dialog semantics.
| robertoandred wrote:
| But it's still a non-modal dialog, which doesn't match
| the JavaScript functionality.
| worble wrote:
| 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.
| rat9988 wrote:
| Funny, when reading this sentence, it felt like an LLM
| that was hallucinating and apologizes when told.
| mock-possum wrote:
| I wouldn't expect an LLM to use a phrase like "for some
| reason I was convinced,"
| sigzero wrote:
| Correct, it is only modal if JavaScript is used.
| idoubtit wrote:
| No, a <dialog> 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.
| divbzero wrote:
| Where is the good old... <center>alignment with
| no CSS</center>
| assimpleaspossi wrote:
| That's been obsolete for over 20 years:
| https://html.spec.whatwg.org/dev/obsolete.html#non-conformin...
| edoceo wrote:
| Bring back <blink> and <marquee>
| amenghra wrote:
| You can revive <blink> with a tiny bit of css:
| https://www.quaxio.com/blink.html
| assimpleaspossi wrote:
| 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.
| assimpleaspossi wrote:
| >>Ah, now there's some breathing room, thanks to <br />.
|
| That's XHTML which is XML. HTML does not use and does not need a
| closing slash and never has in any HTML specification.
|
| https://html.spec.whatwg.org/dev/text-level-semantics.html#t...
| thiht wrote:
| I hate that XHTML went away. HTML parsing is terrible
| dmsnell wrote:
| 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.
| thiht wrote:
| 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).
| pretoriusdre wrote:
| Websites these days don't seem to use 'Under construction'
| animated gifs, and I think they are probably worse for it.
| assimpleaspossi wrote:
| The worse thing would be publishing an unfinished web site.
| That's why no one uses them anymore.
| smitelli wrote:
| According to MDN [1] there is a <portal> element but hell if I
| know what it does.
|
| [1]: https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/po...
| epcoa wrote:
| While complexity of web tech means there's usually some hidden
| nuance, that description on MDN seems pretty clear: a non-
| interactive (other than for navigation) iframe, ie an <a>
| element that's a preview.
| assimpleaspossi wrote:
| Scroll to the bottom and you'll see that it must be enabled by
| the user, is experimental, and not listed in any HTML
| specification.
| bean-weevil wrote:
| Looks to me like it's intended as a link with preview, and part
| of the idea is that user agents could do a sort of animated
| transition morphing the preview into the content of the
| destination page.
| paulddraper wrote:
| It's a non-interactive iframe.
|
| (And experimental)
| Oia20 wrote:
| The soundbite was great lol!
|
| Nice Work!
| nsonha wrote:
| ...all of which have poor dx and ui. There isn't any philosophy
| or process behind "what should become a tag"
|
| but hey, "use the platform"
| butz wrote:
| It would be useful if HTML content was not minified and have some
| comments added about each element besides them.
| noduerme wrote:
| Very dismissive. Anyone not using <span> should take a second
| look. Of all the elements, this is the one to change font, size,
| color, etc. in any dynamic text without offsetting anything in
| your layout. Do you really want to throw your user's text inside
| a <div> inside your nice <div> layout? No.
| rahkiin wrote:
| Indeed, <span> is for inline elements what <div> is for block
| elements: a way to organize and apply styling. With raw html/js
| it can also be used for targeting text changes.
| shahzaibmushtaq wrote:
| Learned and also refreshed my HTML programming language (I'll not
| debate on it) knowledge without any touch of CSS.
| sylware wrote:
| great page, I discovered that my noscript/basic (x)html browser
| is doing more than I thought it did.
| rav wrote:
| No love for the <plaintext> tag? "The <plaintext> 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.
| filcuk wrote:
| What in the world was the intended use for that?
| kisonecat wrote:
| 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" <plaintext>s
| layer8 wrote:
| 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://datatracke
| r.ietf.org/doc/html/rfc1866#section-5.5.2....
| dmsnell wrote:
| 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. <a
| href="https://news.ycombinator.com"><b><i><u><s><plaintext>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"
| soheil wrote:
| same as <pre no?
| assimpleaspossi wrote:
| It's not deprecated. It's obsolete and totally removed from the
| HTML standard since HTML4.
| monroewalker wrote:
| It'd be cool to have a gutter on the left with the html tag that
| appears for that line
| assimpleaspossi wrote:
| Don't know which tag you are talking about but gutters are CSS,
| not HTML. If you want a gutter, add one with CSS.
| soheil wrote:
| Absolutely mind-boggling I didn't know _progress_ and _meter_
| existed, I supposed progress has been made.
| <progress value="70" onmousemove="value=Math.random()*100"
| max="100"/>
___________________________________________________________________
(page generated 2025-01-26 23:01 UTC)