5 ms·

The Usability of HTML Elements

60 points by edent 6y ago

ape4 6y ago
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.
dsego 6y ago
> 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?
- edent 6y ago
  Which sort of tags did you have in mind? You can propose new ones - and comment on existing proposals - on https://wicg.io/ https://wicg.io/
  - dsego 6y ago
    Pretty much anything that used to require a jquery plugin, drag&drop file area, carousel, breadcrumbs, dropdown menus, range sliders, image slides, etc
    - giancarlostoro 6y ago
      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.
      - pxtail 6y ago
        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.
        giancarlostoro 6y ago
        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.
        PuercoPop 6y ago
        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/ https://www.cappuccino.dev/ - [1] http://web.archive.org/web/20140326112535/https://randyluecke.tumblr.com/post/45915323813/im-done-with-the-web http://web.archive.org/web/20140326112535/https://randylueck... - [2] https://news.ycombinator.com/item?id=5415585 https://news.ycombinator.com/item?id=5415585
        pwdisswordfish0 6y ago
        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.
    - rat9988 6y ago
      Isn't drag&drop file area a simple restyled button in html?
      - giancarlostoro 6y ago
        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.
    - extra88 6y ago
      We have range sliders, <input type=“range”> [0]. [0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/range https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
      - dsego 6y ago
        Right, yes of course. But it could do so much more, like the nouislider js control.
  - felixfbecker 6y ago
    It's not worth anything if browsers don't implement it though. <dialog> has been standardized for years and is only implemented in Chrome.
deleted 6y ago
[deleted]
captn3m0 6y ago
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/ https://captnemo.in/monopoly-deal/
- lxe 6y ago
  <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.
  - etripe 6y ago
    Damn, you just made me realise HTML5 is indeed that old.
- uryga 6y ago
  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!
sergeykish 6y ago
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 https://www.w3.org/QA/Tips/noClickHere [2] https://iandevlin.com/blog/2012/12/html5/html5-video-for-retina-displays/ https://iandevlin.com/blog/2012/12/html5/html5-video-for-ret... [3] https://developer.mozilla.org/en-US/docs/Web/CSS/@media/-moz-device-pixel-ratio https://developer.mozilla.org/en-US/docs/Web/CSS/@media/-moz... [4] https://developer.mozilla.org/en-US/docs/Web/CSS/@media/resolution https://developer.mozilla.org/en-US/docs/Web/CSS/@media/reso... [5] https://www.google.com/search?gbv=1&q=Your+browser+doesn%27t+support+HTML5+video.+Here+is+site%3Ashkspr.mobi https://www.google.com/search?gbv=1&q=Your+browser+doesn%27t... [6] http://sergeykish.com/html-script-style-are-not-indexed http://sergeykish.com/html-script-style-are-not-indexed
jchw 6y ago
<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.)
jancsika 6y ago
> <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: <noHTMLSyntaxIsNotTheLoserYouAreTheLoser src="myAudio.mp3" type="audio/mpeg">
notatoad 6y ago
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.
- missblit 6y ago
  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/224 https://github.com/ResponsiveImagesCG/picture-element/issues... [2] https://bugs.chromium.org/p/chromium/issues/detail?id=233751#c2 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.

60 points by edent 6y ago

ape4 6y ago

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.

dsego 6y ago

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

edent 6y ago
Which sort of tags did you have in mind? You can propose new ones - and comment on existing proposals - on https://wicg.io/ https://wicg.io/
- dsego 6y ago
  Pretty much anything that used to require a jquery plugin, drag&drop file area, carousel, breadcrumbs, dropdown menus, range sliders, image slides, etc
  - giancarlostoro 6y ago
    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.
    - pxtail 6y ago
      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.
      - giancarlostoro 6y ago
        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.
        PuercoPop 6y ago
        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/ https://www.cappuccino.dev/ - [1] http://web.archive.org/web/20140326112535/https://randyluecke.tumblr.com/post/45915323813/im-done-with-the-web http://web.archive.org/web/20140326112535/https://randylueck... - [2] https://news.ycombinator.com/item?id=5415585 https://news.ycombinator.com/item?id=5415585
        pwdisswordfish0 6y ago
        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.
  - rat9988 6y ago
    Isn't drag&drop file area a simple restyled button in html?
    - giancarlostoro 6y ago
      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.
  - extra88 6y ago
    We have range sliders, <input type=“range”> [0]. [0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/range https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
    - dsego 6y ago
      Right, yes of course. But it could do so much more, like the nouislider js control.
- felixfbecker 6y ago
  It's not worth anything if browsers don't implement it though. <dialog> has been standardized for years and is only implemented in Chrome.

deleted 6y ago

[deleted]

captn3m0 6y ago

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/ https://captnemo.in/monopoly-deal/

lxe 6y ago
<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.
- etripe 6y ago
  Damn, you just made me realise HTML5 is indeed that old.
uryga 6y ago
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!

sergeykish 6y ago

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 https://www.w3.org/QA/Tips/noClickHere [2] https://iandevlin.com/blog/2012/12/html5/html5-video-for-retina-displays/ https://iandevlin.com/blog/2012/12/html5/html5-video-for-ret... [3] https://developer.mozilla.org/en-US/docs/Web/CSS/@media/-moz-device-pixel-ratio https://developer.mozilla.org/en-US/docs/Web/CSS/@media/-moz... [4] https://developer.mozilla.org/en-US/docs/Web/CSS/@media/resolution https://developer.mozilla.org/en-US/docs/Web/CSS/@media/reso... [5] https://www.google.com/search?gbv=1&q=Your+browser+doesn%27t+support+HTML5+video.+Here+is+site%3Ashkspr.mobi https://www.google.com/search?gbv=1&q=Your+browser+doesn%27t... [6] http://sergeykish.com/html-script-style-are-not-indexed http://sergeykish.com/html-script-style-are-not-indexed

jchw 6y ago

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

jancsika 6y ago

> <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: <noHTMLSyntaxIsNotTheLoserYouAreTheLoser src="myAudio.mp3" type="audio/mpeg">

notatoad 6y ago

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.

missblit 6y ago
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/224 https://github.com/ResponsiveImagesCG/picture-element/issues... [2] https://bugs.chromium.org/p/chromium/issues/detail?id=233751#c2 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.