The Usability of HTML Elements | Hacker News Reader

The Usability of HTML Elements

shkspr.mobi

60 pointsedent26 comments

I love writing modern HTML, and using all the cool new tags and attributes to write content that is semantically correct. For eg, I found out recently about the <aside> tag, which works great alongside the click-to-open nature of the <summary/details> tags resulting in a semantically accurate aside tag that my readers can click-to-read. Works great as a in-content footnote of sort. Demo on my site[0].

What I've realized recently is that there are fewer people left with the ability to write raw HTML these days. Most content platforms these days either hide away raw HTML, or disallow it (like Medium) - resulting in users that can't use these features.

While writing in markdown is great, it only covers the lowest-common-denominator of HTML, and we need modern editors to embrace these new HTML features somehow.

[0]: https://captnemo.in/monopoly-deal/

<aside> is from the era from about a decade ago when semantic HTML was all the rage along with <article>, <main>, <footer>, <header>, <figure>, etc...

Nowadays I've noticed the focus has greatly shifted onto parts of HTML that are relevant to web application development.

Damn, you just made me realise HTML5 is indeed that old.

using <details> for popup-footnotes is a great idea! for anyone interested, here's a simple implementation (pure html+css):

  <style>
      details.footnote {
          display: inline;
          position: relative;
      }

      /* hide details arrow */
      details.footnote > summary { list-style: none; } /* firefox */
      details.footnote > summary::-webkit-details-marker { display: none; } /* webkit */

      details.footnote > summary {
          color: blue;
          cursor: pointer;
      }
      
      details.footnote > .footnote-content {
          position: absolute;
          background: white;
          border: 1px solid lightgray;
          padding: 1em;
          min-width: 40ch;
      }
  </style>
  
  Lorem ipsum dolor sit amet
  <details class="footnote">
    <summary>[1]</summary>
    <div class="footnote-content">This was once revealed to me in a dream.</div>
  </details>
  consectetur adipiscing elit, sed do<br>
  eiusmod tempor. Ut enim ad minim veniam, quis nostrud exercitation<br>
  ullamco laboris nisi ut aliquip ex ea commodo consequat.

edit: added webkit hack; thanks @timvdalen!

Hah, that's a nice application. You're missing a:

    details.footnote > summary::-webkit-details-marker {
        display:none;
    }

For webkit, though!

weird! on firefox this does the job:

   details.footnote > summary { list-style: none; }

but doesn't work on chrome, not sure why. updated the code to include both, thanks!

I love how "good" parts fail. Don't use "click here" [1]

    <audio>
      <source />
      <p><a>Birds singing in the morging</a></p>
    </audio>

How would retina display render <video>?

    <video controls> 
      <source src="video-small.mp4" type="video/mp4" media="all and (max-width:480px)"> 
      <source src="video-small.webm" type="video/webm" media="all and (max-width:480px)"> 
      <source src="video.mp4" type="video/mp4"> 
      <source src="video.webm" type="video/webm"> 
    </video>

And you probably should use min-device-pixel-ratio [2], oh, it is deprecated [3], time to use resolution [4].

Should search index <audio> fallback? Google does [5]. Did you know it does not index <script> and <style> content? [6]

[1] Created Date: 2001 by the QA Team, contributed Sep 2001 by Aaron Swartz https://www.w3.org/QA/Tips/noClickHere

[2] https://iandevlin.com/blog/2012/12/html5/html5-video-for-ret...

[3] https://developer.mozilla.org/en-US/docs/Web/CSS/@media/-moz...

[4] https://developer.mozilla.org/en-US/docs/Web/CSS/@media/reso...

[5] https://www.google.com/search?gbv=1&q=Your+browser+doesn%27t...

[6] http://sergeykish.com/html-script-style-are-not-indexed

> When we think about adding geographic mapping in HTML

Why aren't browsers adding new featureful html tags that would actually be useful for everyone, lowering the cost of web development and duplicated efforts, reducing the barrier to entry and resulting in more efficient web sites?

Which sort of tags did you have in mind? You can propose new ones - and comment on existing proposals - on https://wicg.io/

Pretty much anything that used to require a jquery plugin, drag&drop file area, carousel, breadcrumbs, dropdown menus, range sliders, image slides, etc

Theres so many times I go to look up components for Bootstrap assuming its a web feature they support only to find out I am looking for something that isnt even a web feature at all. Its been a little while since I have done more than basic web stuff but you mentioned some good examples. Its just insane to me that HTML5 has not evolved the basic UI components more. Old browsers be damned, we can shim the stuff that we already hack into working I am sure.

Hell I am okay with some bits requiring specific JS callbacks for "real handling" as long as web UI OOTB improves a bit.

Agree, it's so damn inefficient, for last 10-15 years web developers are building and "reinventing" same basic controls and functionalities over and over, this is such a waste of everything - developers time, businesses money, users cognitive load and frustration coming from differences between various implementations, transfer costs etc.

And what surprises me more than anything is, we've had jQuery, we've had React, etc but none of them seem to just give you reusable web UI components that are common enough. Maybe there's some magical UI library I'm missing out on somewhere. Components are better if you're not forced to include an entire kitchen sink with them.

Yes, there there is. You are looking for t is called Cappuccino. One of its developers literally wrote a rant about with the exact same complaint. It requires a significant buy-in though, it is written in another language, objective-j.

- [0] https://www.cappuccino.dev/

- [1] http://web.archive.org/web/20140326112535/https://randylueck...

- [2] https://news.ycombinator.com/item?id=5415585

I want to like Cappuccino. Like, really want to—Atlas was really cool, and I check in on Cappuccino a couple or three times a year and was even poking at it last night to see how smooth their bootstrap.sh script is, and I marvel at what we've lost when I compare how the early 2010s were looking compared to where things are now.

Aside from Objective-J, though, Cappuccino has performance problems. Every time I try the demos, there's so much jank, even though our hardware and browser engines are a lot better than they were in Cappuccino's original heyday years ago.

It's also at risk of being in questionable legal status depending on the Supreme Court's ruling in Google v. Oracle.

One of the cruxes of that post also stands out to me:

> Your day job is to build a piece of web software and you can’t take a few days to learn the ins and outs? [...] I’ve seen this reaction many times in the web culture. This mentality is pretty rare in the world of native development though. Almost every decent developer I know has no problem spending a weekend learning some new and cool tool, but sadly, this spirit seems to be absent from the web culture.

Looking at the state of tooling in the post-narwhal NodeJS era, the "web culture" has now "caught up" on this side of things, but unfortunately, that's not a good thing. This is another example of the deprogression we've seen. Webdevs had it right the first time on this one. It should not cost a whole several days to get started. The attitude that it should is pretty antithetical to the original value proposition behind Objective-C and Cocoa, in fact.

Isn't drag&drop file area a simple restyled button in html?

It is but that sounds like a hack. We should be able to work with HTML elements without hacking things up. The moment somebody even did that they should of proposed some way to allow support to a new HTML tag that can be plainly styled minus the button hiding hackery.

We have range sliders, <input type=“range”> [0].

[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

Right, yes of course. But it could do so much more, like the nouislider js control.

It's not worth anything if browsers don't implement it though. <dialog> has been standardized for years and is only implemented in Chrome.

<picture> is needfully complicated to some degree; it’s gotta be backwards compatible with browsers that don’t support it. This is less of a concern with <audio> and <video> which were not really supported before (though a Flash fallback was not too uncommon for a time.)

Yes html is inconsistent, but I'm just glad it can do video and audio - I remember when you had to use horrible <embed> for that.

so does anybody want to take a crack at answering some of the questions posed here? i'd love to know why <picture> uses srcset instead of src, and why the whitespace in media queries is significant.

A <picture> contains a list of <source>s each corresponding to a different media query, plus a fallback <img>. A <source> contains a srcset containing a set of candidate images (plus hints). Unlike the media queries to determine the <source> (which the web developer has control over), the browser is allowed to choose whatever candidate image it deems most appropriate from the srcset.

So to answer your question, srcset is used because it allows for multiple candidate urls. src isn't used because it's redundant with srcset [1].

As for the more meta question about why <picture><source srcset> exists in the first place and is the way it is, this comment is a good starting point and has some links [2].

[1] https://github.com/ResponsiveImagesCG/picture-element/issues... [2] https://bugs.chromium.org/p/chromium/issues/detail?id=233751...

---

The rest is just my opinion / speculation, but you have to break a few eggs to make an omelette.

The web platform is always walking an incredibly thin tightrope between backwards compat, making things more principled, addressing privacy issues, supporting new features, and addressing the wants or needs of multiple implementors or users.

A lot of the "why would anyone do things that way?!" questions start to make sense when you keep these constraints in mind and trawl through the old issue trackers / spec explainers / mailing lists.

Sure <picture> is kinda confusing compared to <img src>, but: 1. Web devs want their fancy media queries and browser hints 2. Changing src to behave like srcset might be dangerous for backwards compat reasons 3. Treating src like srcset just in the picture tag but not in the img tag would lead to just as much confusion.

And <picture> doesn't have to be used. A simple <img src> or <img srcset> is fine when it suits the developer's needs better, so I think it's fine that <picture> is a bit unwieldy in comparison.

> <source src="myAudio.mp3" type="audio/mpeg">

I can't help but read the use of the full "source" instead of "src" for the tag name as that common human trait of desperately attempting to hide embarrassment:

Reply on news.ycombinator.com