14 ms·

A Blog Post with Every HTML Element

326 points by lovegrenoble 3y ago

burcs 3y ago
How fortunate, I was looking for something like this today for a side project. HTML can do so much already, I'd rather lean into it than use one of the bloated frameworks/libraries out there. Really helpful to see it all in one place!
- coder_san 3y ago
  Have you tried htmx?
  - colecut 3y ago
    htmx isnt meant to solve frontend element problems, it's for more easily communicating with a backend.
  - burcs 3y ago
    Yes! I just used it last week to create a quick gallery website. It's been a lot of fun playing around with it. Like the other poster said though I wasn't able to get it to do everything I wanted in frontend so used a bit of vanilla javascript as well.
srivmutk 3y ago
It's so cool how much stuff you can get done with just stock HTML.
TheAceOfHearts 3y ago
Has anyone ever encountered a real world scenario where you reached <h6>?
- graypegg 3y ago
  Yep! The first tech job I ever had was at a hyper local marketing agency, so most of my time was spent updating restaurant menus and sales for little local stores. The restaurant menus would always reach into insane levels of hierarchy, mostly because many of them made way too many things. Sometimes you need the: Restaurant -> Menu -> Antipasti -> For Groups -> Fried -> Cheesy hierarchy to feature the mozza sticks and arancini correctly.
- zirror 3y ago
  Yes, specs and other technical documents. For example, the html spec[1] itself. [1]: https://html.spec.whatwg.org/#link-type-next https://html.spec.whatwg.org/#link-type-next
- Biganon 3y ago
  I made a web version of a huge book written by my former professor/boss. It definitely used 6 heading levels, maybe even more.
- dsego 3y ago
  One of many things that irk me, like why limit to 1-6 instead of allowing an attribute for arbitrary size, eg <h level=15>
  - extra88 3y ago
    You can go beyond 6 with ARIA, e.g. role="heading" aria-level="7". I don't know what the limit is. I think it's challenging to find distinct visual styles for many heading levels.
  - runarberg 3y ago
    They tried to make the the explicit number irrelevant and infer the level by the number of nested sections, so instead of: <article> <h1>Title</h1> <section> <h2>Section</h2> <section> <h3>Sub Section</h3> <section> <h4>Sub Sub Section</h4> </section> </section> </section> </article> You could simply use <h2> repeatedly and keep the semantic structure of the former. <article> <h1>Title</h1> <section> <h2>Section</h2> <section> <h2>Sub Section</h2> <section> <h2>Sub Sub Section</h2> </section> </section> </section> </article> However this was never implemented by any browser or screen reader and was finally dropped from the standard. http://html5doctor.com/computer-says-no-to-html5-document-outline/ http://html5doctor.com/computer-says-no-to-html5-document-ou...
    - throwaway18533 3y ago
      XHTML 2 did that. It only had a <h> tag that was depending on <section> to define the level. In fact your code would be exactly like xhtml2, if you replaced <h1-6> with <h> I understand why some people might not like xhtml2, but it did have some good ideas for creating a semantic document Example: https://www.w3.org/TR/2010/NOTE-xhtml2-20101216/mod-structural.html#s_structuralmodule https://www.w3.org/TR/2010/NOTE-xhtml2-20101216/mod-structur...
spread_love 3y ago
Most of these aren't widely used because they were quaint attempts at solving problems that no longer exist, could be better solved with CSS (as the author concedes with <small>), and very much depend on browser implementation. I was excited when <details> and <summary> landed in all evergreen browsers for example, but just to get the content to slide open (guiding the user) instead of pop open requires JS (the best implementations I've seen use WAAPI), Safari adds a proprietary pseudo element, etc.
- lelanthran 3y ago
  > I was excited when <details> and <summary> landed in all evergreen browsers for example, but just to get the content to slide open (guiding the user) instead of pop open requires JS (the best implementations I've seen use WAAPI), Safari adds a proprietary pseudo element, etc. It is possible to have sliding animations without JS, it just isn't very pretty on close (on open looks fine): https://codepen.io/dada1smo/pen/LYydWBg https://codepen.io/dada1smo/pen/LYydWBg (note, that is not mine, I found it via a comment on a css-tricks link).
  - spread_love 3y ago
    Thanks! I should have specified it's impossible without a fixed height (height: auto).
- bandergirl 3y ago
  <small> used to be a formatting tag, but with HTML5 it became a “fine print” tag.[1] Formatting-only tags like <font> have long been deprecated and fallen out of use. [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/small
  - spread_love 3y ago
    ...and <i> is supposed to mean "idiomatic text" now but let's be honest it's never used that way
Sniffnoy 3y ago
> Some of deprecated elements won’t render without some extra work, for example <frame> and <frameset> are designed to be used instead of a <body>, for I guess some kind of collage web page made up of other pages. The author is too young to remember frames, huh? :) I'd just link the Wikipedia article ( https://en.wikipedia.org/wiki/Frame_(World_Wide_Web) https://en.wikipedia.org/wiki/Frame_(World_Wide_Web) ), but I feel like it doesn't explain it very well. So, to briefly explain -- in the early web (OK, not the really early web, but once it got popular) frames were very common. They were commonly used for menus/sidebars, as well as things like headers that were meant to stay visible. So perhaps a page would have three frames -- a frame up top with a persistent header, one on the left with a sidebar, and then one main frame with the content. Each frame acted fairly independently, with e.g. its own back/forward history (a link in a frame would by default only affect that frame, although you could have links in one frame open in another, useful for implementing a sidebar). This meant using back/forward/reload/etc with frames could be pretty troublesome and unintuitive. If you somehow got a page into a messed-up state where the wrong thing was loaded in one frame, it could be hard to get out of this state other than by navigating to the page from the start. Or it could be troublesome if you accidentally loaded just the content page without the framing page it was supposed to be a part of. CSS got rid of most of the use case for frames, which is good, because frames were a real pain to deal with as a user!
- jwells89 3y ago
  One usage of frames I recall was for sites that were meant to act as an index of other sites, where there’d be a sidebar on the left with links to various sites that opened on the right. I think this was actually a pretty good use case for frames, especially back before browser tabs existed. It was nicer to run through a list of links in one window with frames than to jump back and forth through history or juggle multiple windows.
  - m-p-3 3y ago
    When I was young and still lesrning the basics I used it as a table of content for some long webpages that you could use to quickly jump from one anchor to another, or as a sitemap.
arun-mani-j 3y ago
Awesome article. Like the author, I'm also confused about when to use b and strong & i and em.
- xigoi 3y ago
  <em> is for emphasis, <i> is for other things that typically use italic text (except those that fall under <dfn> or <var>), such as foreign words. Analogously for <strong> and <b>.
- karaterobot 3y ago
  I had thought that <b> and <i> describe how something should look, whereas <strong> and <em> describe the meaning of something. <b> means "this text should be thicker and darker than it normally would be", <strong> indicates "this text has gravitas... interpret that however you want". In other words, visual vs. semantic.
  - vlz 3y ago
    I have heard similar but the consequences always seemed weird to me. Following this if something is important and also should look visually different, I should use both <strong> and <b>. However If something is important and I don't want it to show, I should use <strong> alone and <b> alone only for the case where something should look important but that has actually no meaning as the meaning conferring tag would be <strong>.
    - Kerrick 3y ago
      The quintessential semantic use of <b> is for typographically offsetting key words in a longer text, like how 5th Edition D&D adventures do when referencing a monster that has a stat block in the Monster Manual. It’s not strength of voice, but it has meaning that the text be emboldened.
- david2ndaccount 3y ago
  Just use b and i, em and strong are bloat and are harder to type if you are hand-writing html. The semantic web is dead anyway.
zerocrates 3y ago
This comes up briefly but I do still find it ridiculous that there's no simple standard CSS declaration to hide something from visible display but keep it for screenreaders. Everything I've seen still does clip, or positions the content off the side of the page, or something like that. How is this not just an alternative "display" value, or an additional property? There's been a "speak" property floating around in one of those theoretical CSS modules that would accomplish this but as far as I know it has zero uptake among implementers.
- alberth 3y ago
  > no simple standard CSS declaration to hide something from visible display but keep it for screenreaders ARIA attributes allow for that. https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... Example code. https://stackoverflow.com/questions/26032089/in-html-how-can-i-have-text-that-is-only-accessible-for-screen-readers-i-e-fo https://stackoverflow.com/questions/26032089/in-html-how-can...
  - zerocrates 3y ago
    aria-label/labelledby is not always a workable solution. Sometimes you really need the text to be sitting there on the page as text for things to work right. Note that the very SO thread you linked to goes immediately to doing position/clipping tricks right after mentioning aria-label.
    - darekkay 3y ago
      In addition, aria labels don't work reliably with some HTML elements [1]. Specifically, the example from SO (div) will not work in some screen readers. [1] https://www.tpgi.com/short-note-on-aria-label-aria-labelledby-and-aria-describedby/ https://www.tpgi.com/short-note-on-aria-label-aria-labelledb...
- nine_k 3y ago
  Why should it be a part of CSS, that handles visual representation, and not part of HTML, which handles data, structure, and semantics? I wonder if a whitespace <div> with a right aria-label could fit the bill.
isaacfung 3y ago
I was trying to make a web browsing ai agent a few days ago and I was shocked to find that hacker news comments are implemented as table inside table inside table.
- lelanthran 3y ago
  I was delighted when I found this out - my userContent.css to make HN more readable (make content have a limited width, set a 1.5em line-height and extra padding-top for all paragraphs). I no longer struggle to read HN on a wide browser which display 250 characters on a single line. Each paragraph is readable, and the paragraph breaks are visibly higher than the line-height.
  - djkoolaide 3y ago
    Do you mind sharing this? Sounds like it would solve the exact problem on my ultra-wide monitor.
    - lelanthran 3y ago
      Not at all, copied verbatim from my userContent.css file, full path $FIREFOXPROFILE/chrome/userContent.css: @-moz-document domain(news.ycombinator.com) { .comment { font-size: 12px; line-height: 1.75em; padding: 10px 0 10px 0; max-width: 64ch; display: block; } .commtext { font-size: 12px; line-height: 1.75em; padding: 10px 0 10px 0; max-width: 64ch; display: block; } }
  - airstrike 3y ago
    While we're talking userContent.css hacks, I'd be delighted to share my snippet to make code blocks look like (simplified) Mac windows in case anyone else wants to play with it. There's definitely room for improvement but I don't think it looks half-bad: https://i.stack.imgur.com/xcyoE.png https://i.stack.imgur.com/xcyoE.png @-moz-document domain("news.ycombinator.com") { body { font-family: -apple-system, "Adobe Clean", -apple-system, Helvetica, sans-serif !important; font-size: 11pt; color: #828282; background-color: #1B2835 !important; } * { font-family: -apple-system, "Adobe Clean", -apple-system, Helvetica, sans-serif !important; } * code { font-family: "Fira Code", "Monaco", "Consolas", "Courier New", monospace !important; margin: 0; padding: 0; font-size: 0.9em; } code:before { content: "⬤⬤⬤"; position: absolute; top: 5px; left: 12px; color: #ccc; letter-spacing: 3px; -webkit-text-fill-color: #ccc; /* Will override color (regardless of order) */ -webkit-text-stroke-width: 1px; -webkit-text-stroke-color: #223b4f; } code:before::first-letter { color: #ff5f56 !important; } pre { background-color: #234 !important; border-radius: 15px; padding: 30px 0px 10px; border: 0.5px solid #223B4F !important; box-shadow: inset 0 0 1px #123; position: relative; } table#hnmain{ background-color: #1B2835 !important; } a:link { color: #bfbfbf !important; text-decoration: none; } .c00 { color: #cecece !important; } .cdd { color: #768696 !important; } .c5a { color: #465666 !important; } }
deleted 3y ago
[deleted]
synn 3y ago
The article is interesting, but I often come across resources that talk about or reference the HTML5 specification by the W3C. Since 2019, HTML has become a living standard (and therefore no longer has a version number). It is available through Whatwg here: https://html.spec.whatwg.org/multipage/ https://html.spec.whatwg.org/multipage/
withinboredom 3y ago
You can nest details/summary tags. I once created a choose-your-own adventure using it and posting it on our corporate intranet (I had a generator script to stitch things together. The actual text was only a few pages long.) The HTML was 5mb ... I broke a lot of browsers that day. It had to be deleted.
- proamdev123 3y ago
  This sounds interesting, but I’m not following. Do you mind expanding? Specifically, how does nesting details/summary tags relate to 5 MB of HTML, and how does that relate to breaking a lot of browsers? Sounds like a great story, and I’d love to hear it!
  - marcosdumay 3y ago
    The GP made an entire game in an (autogenerated) static HTML file. Most browsers don't have a 5MB single HTML as an usual target, and I guess not as a test case either.
    - proamdev123 3y ago
      Got it. Thanks!
  - withinboredom 3y ago
    If you have a story with the following prompt: > go left > go right Where each of those is a branch in the story. Even if both branches converge eventually, all possibilities need to be in each branch. And so on. The number of summary tags is n! where n is the number of possible decisions. Thus you very, very quickly end up with a very large dom. Browsers aren’t really optimized to display hundreds of thousands of these tags, so they crashed.
    - proamdev123 3y ago
      Lol. Hilarious! Thanks for elaborating.
euroderf 3y ago
Semantic HTML has excellent potential. I personally like the style where footnotes for running text are placed in the right-side margin, in a smaller and/or semi-greyed font, and maybe with details/summary expanders. But every implementation of styles like this seem to require some sort of detailed knowledge of CSS to wrangle it into working order.
famfamfam 3y ago
Regarding the <menu> element, which the OP mentions their confusion about as: > I was initially surprised that it survived to HTML 5 (while <menuitem> didn’t) because modern browsers treat it as essentially a <ul>. Researching further on Wikipedia I read: "MENU existed in HTML Tags, and was standardized in HTML 2.0; deprecated in HTML 4.0 Transitional; invalid in HTML 4.0 Strict; then redefined in HTML5, but removed in HTML 5.2," and now I don’t know what to think. HTML 5.2 was retired by W3C in 2021 in favour of the WhatWG HTML Living Standard, which (unlike HTML 5.2) never deprecated <menu>, and has been redefined as representing "a toolbar consisting of its contents, in the form of an unordered list of items (represented by li elements), each of which represents a command that the user can perform or activate.". Wikipedia's list of elements seems to be out of date here — along with a lot of the Wikipedia information on HTML versions — as the <menu> element is still alive. Given its history of being repeatedly deprecated, and the fact that event recently browsers were confused by exactly what semantics to assign to <menu>, you are probably nearly always better off using <ul> with an appropriate ARIA role attribute (toolbar, menu, or menubar).
buidler 3y ago
[dead]
_joel 3y ago
It's got <marquee> I'm happy.
- twosdai 3y ago
  Did the same thing. Just scrolled to find it!
LorenDB 3y ago
Bing back <blink>!
- extraduder_ire 3y ago
  You can do that and <marquee> with some css rules for the tag. I did on a few joke sites I made a couple years back.
bjt12345 3y ago
[flagged]
sixdimensional 3y ago
This reminded me of when when I first learned HTML in around 1995… anybody else remember Kevin Werbach’s Barebones Guide to HTML? It was basically a site that listed all the HTML tags and what they did. That plus a text editor and early version of Netscape Navigator was all you needed, and you were off to the races to learn and experiment!
Terretta 3y ago
First, this is a fantastic way to learn, such a great exercise! It's also fun to see the author ponder some of the older and now unused elements, speculating on their use, when "back in the day" they were thrilling to suddenly have access to. That said, handcrafting HTML through every rev since Mosaic, I don't like MDN because of retcon changes like "description list". I prefer original spec, "definition list". To me dl, dt, dd, makes more sense to think of as "definition list", with defined terms, and defined definitions. OK, description is broader than definition, but for me, definition is easier to remember the list (dl) has terms (dt) and definitions (dd). And W3 calls it "definition list": https://www.w3.org/TR/html4/struct/lists.html#edef-DL https://www.w3.org/TR/html4/struct/lists.html#edef-DL

326 points by lovegrenoble 3y ago

How fortunate, I was looking for something like this today for a side project. HTML can do so much already, I'd rather lean into it than use one of the bloated frameworks/libraries out there. Really helpful to see it all in one place!

coder_san 3y ago
Have you tried htmx?
- colecut 3y ago
  htmx isnt meant to solve frontend element problems, it's for more easily communicating with a backend.
- burcs 3y ago
  Yes! I just used it last week to create a quick gallery website. It's been a lot of fun playing around with it. Like the other poster said though I wasn't able to get it to do everything I wanted in frontend so used a bit of vanilla javascript as well.

srivmutk 3y ago

It's so cool how much stuff you can get done with just stock HTML.

TheAceOfHearts 3y ago

Has anyone ever encountered a real world scenario where you reached <h6>?

graypegg 3y ago
Yep! The first tech job I ever had was at a hyper local marketing agency, so most of my time was spent updating restaurant menus and sales for little local stores. The restaurant menus would always reach into insane levels of hierarchy, mostly because many of them made way too many things. Sometimes you need the: Restaurant -> Menu -> Antipasti -> For Groups -> Fried -> Cheesy hierarchy to feature the mozza sticks and arancini correctly.
zirror 3y ago
Yes, specs and other technical documents. For example, the html spec[1] itself. [1]: https://html.spec.whatwg.org/#link-type-next https://html.spec.whatwg.org/#link-type-next
Biganon 3y ago
I made a web version of a huge book written by my former professor/boss. It definitely used 6 heading levels, maybe even more.
dsego 3y ago
One of many things that irk me, like why limit to 1-6 instead of allowing an attribute for arbitrary size, eg <h level=15>
- extra88 3y ago
  You can go beyond 6 with ARIA, e.g. role="heading" aria-level="7". I don't know what the limit is. I think it's challenging to find distinct visual styles for many heading levels.
- runarberg 3y ago
  They tried to make the the explicit number irrelevant and infer the level by the number of nested sections, so instead of: <article> <h1>Title</h1> <section> <h2>Section</h2> <section> <h3>Sub Section</h3> <section> <h4>Sub Sub Section</h4> </section> </section> </section> </article> You could simply use <h2> repeatedly and keep the semantic structure of the former. <article> <h1>Title</h1> <section> <h2>Section</h2> <section> <h2>Sub Section</h2> <section> <h2>Sub Sub Section</h2> </section> </section> </section> </article> However this was never implemented by any browser or screen reader and was finally dropped from the standard. http://html5doctor.com/computer-says-no-to-html5-document-outline/ http://html5doctor.com/computer-says-no-to-html5-document-ou...
  - throwaway18533 3y ago
    XHTML 2 did that. It only had a <h> tag that was depending on <section> to define the level. In fact your code would be exactly like xhtml2, if you replaced <h1-6> with <h> I understand why some people might not like xhtml2, but it did have some good ideas for creating a semantic document Example: https://www.w3.org/TR/2010/NOTE-xhtml2-20101216/mod-structural.html#s_structuralmodule https://www.w3.org/TR/2010/NOTE-xhtml2-20101216/mod-structur...

spread_love 3y ago

Most of these aren't widely used because they were quaint attempts at solving problems that no longer exist, could be better solved with CSS (as the author concedes with <small>), and very much depend on browser implementation. I was excited when <details> and <summary> landed in all evergreen browsers for example, but just to get the content to slide open (guiding the user) instead of pop open requires JS (the best implementations I've seen use WAAPI), Safari adds a proprietary pseudo element, etc.

lelanthran 3y ago
> I was excited when <details> and <summary> landed in all evergreen browsers for example, but just to get the content to slide open (guiding the user) instead of pop open requires JS (the best implementations I've seen use WAAPI), Safari adds a proprietary pseudo element, etc. It is possible to have sliding animations without JS, it just isn't very pretty on close (on open looks fine): https://codepen.io/dada1smo/pen/LYydWBg https://codepen.io/dada1smo/pen/LYydWBg (note, that is not mine, I found it via a comment on a css-tricks link).
- spread_love 3y ago
  Thanks! I should have specified it's impossible without a fixed height (height: auto).
bandergirl 3y ago
<small> used to be a formatting tag, but with HTML5 it became a “fine print” tag.[1] Formatting-only tags like <font> have long been deprecated and fallen out of use. [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/small
- spread_love 3y ago
  ...and <i> is supposed to mean "idiomatic text" now but let's be honest it's never used that way

Sniffnoy 3y ago

> Some of deprecated elements won’t render without some extra work, for example <frame> and <frameset> are designed to be used instead of a <body>, for I guess some kind of collage web page made up of other pages. The author is too young to remember frames, huh? :) I'd just link the Wikipedia article ( https://en.wikipedia.org/wiki/Frame_(World_Wide_Web) https://en.wikipedia.org/wiki/Frame_(World_Wide_Web) ), but I feel like it doesn't explain it very well. So, to briefly explain -- in the early web (OK, not the really early web, but once it got popular) frames were very common. They were commonly used for menus/sidebars, as well as things like headers that were meant to stay visible. So perhaps a page would have three frames -- a frame up top with a persistent header, one on the left with a sidebar, and then one main frame with the content. Each frame acted fairly independently, with e.g. its own back/forward history (a link in a frame would by default only affect that frame, although you could have links in one frame open in another, useful for implementing a sidebar). This meant using back/forward/reload/etc with frames could be pretty troublesome and unintuitive. If you somehow got a page into a messed-up state where the wrong thing was loaded in one frame, it could be hard to get out of this state other than by navigating to the page from the start. Or it could be troublesome if you accidentally loaded just the content page without the framing page it was supposed to be a part of. CSS got rid of most of the use case for frames, which is good, because frames were a real pain to deal with as a user!

jwells89 3y ago
One usage of frames I recall was for sites that were meant to act as an index of other sites, where there’d be a sidebar on the left with links to various sites that opened on the right. I think this was actually a pretty good use case for frames, especially back before browser tabs existed. It was nicer to run through a list of links in one window with frames than to jump back and forth through history or juggle multiple windows.
- m-p-3 3y ago
  When I was young and still lesrning the basics I used it as a table of content for some long webpages that you could use to quickly jump from one anchor to another, or as a sitemap.

arun-mani-j 3y ago

Awesome article. Like the author, I'm also confused about when to use b and strong & i and em.

xigoi 3y ago
<em> is for emphasis, <i> is for other things that typically use italic text (except those that fall under <dfn> or <var>), such as foreign words. Analogously for <strong> and <b>.
karaterobot 3y ago
I had thought that <b> and <i> describe how something should look, whereas <strong> and <em> describe the meaning of something. <b> means "this text should be thicker and darker than it normally would be", <strong> indicates "this text has gravitas... interpret that however you want". In other words, visual vs. semantic.
- vlz 3y ago
  I have heard similar but the consequences always seemed weird to me. Following this if something is important and also should look visually different, I should use both <strong> and <b>. However If something is important and I don't want it to show, I should use <strong> alone and <b> alone only for the case where something should look important but that has actually no meaning as the meaning conferring tag would be <strong>.
  - Kerrick 3y ago
    The quintessential semantic use of <b> is for typographically offsetting key words in a longer text, like how 5th Edition D&D adventures do when referencing a monster that has a stat block in the Monster Manual. It’s not strength of voice, but it has meaning that the text be emboldened.
david2ndaccount 3y ago
Just use b and i, em and strong are bloat and are harder to type if you are hand-writing html. The semantic web is dead anyway.

zerocrates 3y ago

This comes up briefly but I do still find it ridiculous that there's no simple standard CSS declaration to hide something from visible display but keep it for screenreaders. Everything I've seen still does clip, or positions the content off the side of the page, or something like that. How is this not just an alternative "display" value, or an additional property? There's been a "speak" property floating around in one of those theoretical CSS modules that would accomplish this but as far as I know it has zero uptake among implementers.

alberth 3y ago
> no simple standard CSS declaration to hide something from visible display but keep it for screenreaders ARIA attributes allow for that. https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... Example code. https://stackoverflow.com/questions/26032089/in-html-how-can-i-have-text-that-is-only-accessible-for-screen-readers-i-e-fo https://stackoverflow.com/questions/26032089/in-html-how-can...
- zerocrates 3y ago
  aria-label/labelledby is not always a workable solution. Sometimes you really need the text to be sitting there on the page as text for things to work right. Note that the very SO thread you linked to goes immediately to doing position/clipping tricks right after mentioning aria-label.
  - darekkay 3y ago
    In addition, aria labels don't work reliably with some HTML elements [1]. Specifically, the example from SO (div) will not work in some screen readers. [1] https://www.tpgi.com/short-note-on-aria-label-aria-labelledby-and-aria-describedby/ https://www.tpgi.com/short-note-on-aria-label-aria-labelledb...
nine_k 3y ago
Why should it be a part of CSS, that handles visual representation, and not part of HTML, which handles data, structure, and semantics? I wonder if a whitespace <div> with a right aria-label could fit the bill.

isaacfung 3y ago

I was trying to make a web browsing ai agent a few days ago and I was shocked to find that hacker news comments are implemented as table inside table inside table.

lelanthran 3y ago
I was delighted when I found this out - my userContent.css to make HN more readable (make content have a limited width, set a 1.5em line-height and extra padding-top for all paragraphs). I no longer struggle to read HN on a wide browser which display 250 characters on a single line. Each paragraph is readable, and the paragraph breaks are visibly higher than the line-height.
- djkoolaide 3y ago
  Do you mind sharing this? Sounds like it would solve the exact problem on my ultra-wide monitor.
  - lelanthran 3y ago
    Not at all, copied verbatim from my userContent.css file, full path $FIREFOXPROFILE/chrome/userContent.css: @-moz-document domain(news.ycombinator.com) { .comment { font-size: 12px; line-height: 1.75em; padding: 10px 0 10px 0; max-width: 64ch; display: block; } .commtext { font-size: 12px; line-height: 1.75em; padding: 10px 0 10px 0; max-width: 64ch; display: block; } }
- airstrike 3y ago
  While we're talking userContent.css hacks, I'd be delighted to share my snippet to make code blocks look like (simplified) Mac windows in case anyone else wants to play with it. There's definitely room for improvement but I don't think it looks half-bad: https://i.stack.imgur.com/xcyoE.png https://i.stack.imgur.com/xcyoE.png @-moz-document domain("news.ycombinator.com") { body { font-family: -apple-system, "Adobe Clean", -apple-system, Helvetica, sans-serif !important; font-size: 11pt; color: #828282; background-color: #1B2835 !important; } * { font-family: -apple-system, "Adobe Clean", -apple-system, Helvetica, sans-serif !important; } * code { font-family: "Fira Code", "Monaco", "Consolas", "Courier New", monospace !important; margin: 0; padding: 0; font-size: 0.9em; } code:before { content: "⬤⬤⬤"; position: absolute; top: 5px; left: 12px; color: #ccc; letter-spacing: 3px; -webkit-text-fill-color: #ccc; /* Will override color (regardless of order) */ -webkit-text-stroke-width: 1px; -webkit-text-stroke-color: #223b4f; } code:before::first-letter { color: #ff5f56 !important; } pre { background-color: #234 !important; border-radius: 15px; padding: 30px 0px 10px; border: 0.5px solid #223B4F !important; box-shadow: inset 0 0 1px #123; position: relative; } table#hnmain{ background-color: #1B2835 !important; } a:link { color: #bfbfbf !important; text-decoration: none; } .c00 { color: #cecece !important; } .cdd { color: #768696 !important; } .c5a { color: #465666 !important; } }

deleted 3y ago

[deleted]

synn 3y ago

The article is interesting, but I often come across resources that talk about or reference the HTML5 specification by the W3C. Since 2019, HTML has become a living standard (and therefore no longer has a version number). It is available through Whatwg here: https://html.spec.whatwg.org/multipage/ https://html.spec.whatwg.org/multipage/

withinboredom 3y ago

You can nest details/summary tags. I once created a choose-your-own adventure using it and posting it on our corporate intranet (I had a generator script to stitch things together. The actual text was only a few pages long.) The HTML was 5mb ... I broke a lot of browsers that day. It had to be deleted.

proamdev123 3y ago
This sounds interesting, but I’m not following. Do you mind expanding? Specifically, how does nesting details/summary tags relate to 5 MB of HTML, and how does that relate to breaking a lot of browsers? Sounds like a great story, and I’d love to hear it!
- marcosdumay 3y ago
  The GP made an entire game in an (autogenerated) static HTML file. Most browsers don't have a 5MB single HTML as an usual target, and I guess not as a test case either.
  - proamdev123 3y ago
    Got it. Thanks!
- withinboredom 3y ago
  If you have a story with the following prompt: > go left > go right Where each of those is a branch in the story. Even if both branches converge eventually, all possibilities need to be in each branch. And so on. The number of summary tags is n! where n is the number of possible decisions. Thus you very, very quickly end up with a very large dom. Browsers aren’t really optimized to display hundreds of thousands of these tags, so they crashed.
  - proamdev123 3y ago
    Lol. Hilarious! Thanks for elaborating.

euroderf 3y ago

Semantic HTML has excellent potential. I personally like the style where footnotes for running text are placed in the right-side margin, in a smaller and/or semi-greyed font, and maybe with details/summary expanders. But every implementation of styles like this seem to require some sort of detailed knowledge of CSS to wrangle it into working order.

famfamfam 3y ago

Regarding the <menu> element, which the OP mentions their confusion about as: > I was initially surprised that it survived to HTML 5 (while <menuitem> didn’t) because modern browsers treat it as essentially a <ul>. Researching further on Wikipedia I read: "MENU existed in HTML Tags, and was standardized in HTML 2.0; deprecated in HTML 4.0 Transitional; invalid in HTML 4.0 Strict; then redefined in HTML5, but removed in HTML 5.2," and now I don’t know what to think. HTML 5.2 was retired by W3C in 2021 in favour of the WhatWG HTML Living Standard, which (unlike HTML 5.2) never deprecated <menu>, and has been redefined as representing "a toolbar consisting of its contents, in the form of an unordered list of items (represented by li elements), each of which represents a command that the user can perform or activate.". Wikipedia's list of elements seems to be out of date here — along with a lot of the Wikipedia information on HTML versions — as the <menu> element is still alive. Given its history of being repeatedly deprecated, and the fact that event recently browsers were confused by exactly what semantics to assign to <menu>, you are probably nearly always better off using <ul> with an appropriate ARIA role attribute (toolbar, menu, or menubar).

buidler 3y ago

[dead]

_joel 3y ago

It's got <marquee> I'm happy.

twosdai 3y ago
Did the same thing. Just scrolled to find it!

LorenDB 3y ago

Bing back <blink>!

extraduder_ire 3y ago
You can do that and <marquee> with some css rules for the tag. I did on a few joke sites I made a couple years back.

bjt12345 3y ago

[flagged]

sixdimensional 3y ago

This reminded me of when when I first learned HTML in around 1995… anybody else remember Kevin Werbach’s Barebones Guide to HTML? It was basically a site that listed all the HTML tags and what they did. That plus a text editor and early version of Netscape Navigator was all you needed, and you were off to the races to learn and experiment!

Terretta 3y ago

First, this is a fantastic way to learn, such a great exercise! It's also fun to see the author ponder some of the older and now unused elements, speculating on their use, when "back in the day" they were thrilling to suddenly have access to. That said, handcrafting HTML through every rev since Mosaic, I don't like MDN because of retcon changes like "description list". I prefer original spec, "definition list". To me dl, dt, dd, makes more sense to think of as "definition list", with defined terms, and defined definitions. OK, description is broader than definition, but for me, definition is easier to remember the list (dl) has terms (dt) and definitions (dd). And W3 calls it "definition list": https://www.w3.org/TR/html4/struct/lists.html#edef-DL https://www.w3.org/TR/html4/struct/lists.html#edef-DL