The graveyard of HTML attributes which never gained public attention/usage is large and full of useful ideas.
My favourite was relational links such as
<link rel='first' href='/de' title='Homepage' />
<link rel='prev' href='/some/bunnies.php' title='Previous Page about bunnies' />
<link rel='next' href='/some/cats.php' title='Next page about cats' />
<link rel="copyright" href="/de/impressum.php" title="Impressum">
<link rel="alternate" href="/gr/samepage.php" hreflang="gr" title="Page name in greek">
Opera was the only browser which had a toolbar with these relational links. This was around mid-2000. Unfortunately, this toolbar never survived or got taken over by other browsers.
Some relations survived (such as rel="search" for custom search pages), some got killed-by-ecosystem (such as RSS).
I've made use of those even recently. Even if they're not used much now, it's potential future-proofing. And I've written tools that manage content and read these values to organise pages in a series.
yah, rel links are still usuable at least for machine-read purposes, if not the old 'back', 'forward', 'up', type site navigation links that browsers used to display if those were present in the document.
Who knows, maybe someone who works on Chrome or Edge or Safari is reading this thread and will talk to their higher-ups about using it somehow. (Wishful thinking?)
They had a toolbar for it for a while, and I used it for forums and search results. And then they got rid of the toolbar, and the rel link because used only for search engines.
I recall IE (even up through "Spartan" Edge, I think) had a hard to discover/not quite as useful in practice as it was in theory support for prev/next links: if you pressed the browser's forward keyboard shortcut or gesture (but not the toolbar button since that was usually disabled) when there was no forward history it would sometimes follow next links. Even harder to pull off in practice (given how most people navigate to websites from searches and stuff) if you somehow managed to land on a page with no back history and pulled off a back keyboard shortcut or gesture it would try the page's prev link. I think that feature probably confused way more people than anyone ever came to rely on it.
Your post was something of a blast from the past for me: toolbars! I had forgotten about those. I used to spend a lot of time customizing those. Then Chrome was released which really was the end for browser toolbars.
I seem to remember this was used by emacs' mode embedding the w3m browser. It was great to read long structured documentation sites by just pressing space-bar to "scroll" through pages.
In opera back in the days, if you pressed the space bar, it would scroll down like all browsers but if you got to the end of the page it would load the rel="next" or any link with <a>next..</a> in it.
You can show these things via CSS. By default they have `display: none` but you can change it something like `display: inline` so <link> appears just like <a>. You may need JavaScript to make the clicking work.
These <link/> attributes belonged in the <head>. It was page metadata, not a page element: the browser itself was supposed to give you controls for forward, back, etc.
I'm pretty bummed the title attribute on stylesheets didn't get the love it needed. We had a native, built-in theme switcher (except Chromium) that would have been prefered to some of the contemporary options of needing to put it behind user preferences. If it could hawe been fixed to persist the selection as well as not load unused, then we'd maybe see a different space.
Is there no JS APIs to use those either? Cause that would make it infinitely cooler imho, then you can surface it as a way to show off web app themes on the front-end too.
Nothing pre-built, but you can cobble something together yourself – query the DOM for stylesheets, evaluate their attributes (i.e. especially the "title" and "alternate" attributes) and then enable and disable them as required.
I wrote something like that for my homepage, although as I only needed to switch between two styles and I'm not a front-end person, I didn't bother with an actual selection drop-down and just wrote a toggle that cycles through all alternate stylesheets one at a time.
i still use this feature in firefox, and it's still one of my favorite little tricks to add to personal projects for a little flair. i'd only wish safari would support it as well (i don't care for chrome or google in general).
I highly recommend re-reading the entire formal standard for technologies you work with routinely, on a roughly annual basis. It's a triple whammy of refresher, update, and niche discovery.
I attribute this advice to Æleen Frisch; albeit without pulling my very dog-eared copy from the stacks, I recall that words to similar effect can be found in the epochal Essential System Administration (2002), possibly in the form of reading every manpage in your local Unix base system.
The form attribute on fields is very useful to decouple the What from the How (it is laid out on the screen). You might for example want an upload widget, which does a separate request, right next to some other fields. Instead of wrapping things in forms (which you cannot nest) you can now freely lay out your document. Similarly you might want several fields or buttons spread across your document and don't want to wrap everything with a big form, or several forms.
I’ve been meaning to use these attributes for the very reasons you mention, but I’d need to check the impact on the accessibility tree. I’m not sure of the impact of having the submit buttons in a completely different part of the DOM to the inputs.
The accessibility tree doesn't represent form elements in relation to their particular <form>, a submit button's position in the accessibility tree will be equivalent to its position in the DOM tree.
The button's name (optionally also its description) and to some degree its position in the DOM order (what heading and/or other form elements precedes it) needs to be sufficient to convey what will happen when it's used.
The <a download> attribute sounds great on paper, but if request fails for whatever reason your user will, very confusingly, download a file named exactly as you specify but with error page HTML as contents.
There is no straightforward way[0] for you to gracefully handle an error, which is quite an oversight once you factor in that network isn’t always reliable.
Having used it at first, I switched to server-side logic where I return data with Content-Disposition header if everything went well or redirect the user to show a proper error message in case of a problem.
[0] I imagine this could be worked around with some JS-based preflight or other trickery—which sounds like a suitable solution only if you have no control over the headers returned for some reason.
> The <a download> attribute sounds great on paper, but if request fails for whatever reason your user will, very confusingly, download a file named exactly as you specify but with error page HTML as contents.
Though that is at least consistent with other download options like right-click/save-link-as, so is probably not incorrect behaviour.
This is true of pretty much anything that wants to directly invoke the browser's download mechanism. AFAICT the options are either:
1. Use JS, in which case one can handle errors and otherwise be involved in the request / response process. However, if you wish to offer a "download" funciton, this necessitates downloading all the data into JS memory before offering it to the user.
2. Use form-posting with `Content-Disposition`. One can no longer be involved with the request and response. And any response which does not have `Content-Disposition` will result in the browser redirecting. However, the user will be able to directly stream the download without your page being involved beyond initiating the request.
Since the data downloads are gigabytes in our case, we opted for (2). But I would also love to hear if I'm wrong about this trade-off.
I haven't used the download attribute in a while, but the last time I felt it was a bit too finicky. E.g. only works if the file is on the same origin and there are more differences between behavior in different browsers than setting headers from the server. Think it is still a good enough solution in many circumstances.
Since modern browsers are capable of rendering pdfs, it's downright infuriating when a site forces me to download a pdf and take more steps to view it. For being a user agent, this feature certainly removes agency from the user. Afaik there is no way to tell Firefox or Chrome to ignore the Content-Disposition header for files it should already know how to render.
`Content-Disposition` also works for form submission. If a response to a form submission contains the `Content-Disposition` header, the browser will expose that to the user as a download and the page will not navigate.
enterkeyhint doesn't do anything on Chrome on Android.
Which kind of illustrates why a lot of these things are not well-known. Why do something that that works on Firefox but not Chrome/Edge or on Safari/Firefox but not Chrome, etc? Specs are great, but near universal, reliably similar implementation is key.
In a lot of cases it means you have to build edge case UX. I'd rather lean on UX that's mostly under my control and not at the whim of browser adoption.
I love the <download> attribute, it's a quick way to use the default file download mechanisms without having to bother the user with opening a link or prompting. I realize there is the potential for abuse, but if you're careful, it's wonderful.
Native lazy loading support is coming to a bunch of things in the near future, if it's not there already, so this one is living on borrowed time.
If you've ever tried to implement CSP on a site, crossorigin and integrity should be famiilar - alas, CSP is hard, but you already knew that didn't you :)
You're mixing up elements and element attributes. There is an <cite> element, which it appears Standard Ebooks uses, and a cite attribute, which is seldom used, probably because it's not exposed to the user in any way.
Writing "<download>", with the word in angle brackets, makes it look like an element but it's not, download is an element attribute.
Ack. Yeah, the first one is my mistake looking at it again - although I would argue this element is relatively underused because it's not something you would need outside of contexts where printing is a concern - SE is a slight exception in that they are starting from print transcriptions in most cases.
I am aware of the distinction, I only used that way b/c HN doesn't really have a good way to indicate code without multiple spaces or just blindly using the ` character which is...not great.
> cite attribute, which is seldom used, probably because it's not exposed to the user in any way
I recall in a (lost) blog theme I had at one point in time I'd scrounged a nice bit of CSS to add cite attributes visibly appended to blockquote and q elements. Exposing it to the user is possible in just pure CSS, but it is a bit of a shame that browsers didn't style it by default so many people didn't learn it was a thing.
Seeing the download attribute mentionend felt weirdly nostalgic. I wrote a short blog post about that attribute which shot up to the number one spot here on HN when I submitted it back in 2013[0].
In the nine years since that post, I have not once used it in a real project.
Readit News
My favourite was relational links such as
Opera was the only browser which had a toolbar with these relational links. This was around mid-2000. Unfortunately, this toolbar never survived or got taken over by other browsers.Some relations survived (such as rel="search" for custom search pages), some got killed-by-ecosystem (such as RSS).
Frefox had it to, it's this famous bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=2800 opened 24 years ago.
They had a toolbar for it for a while, and I used it for forums and search results. And then they got rid of the toolbar, and the rel link because used only for search engines.
As of 2019, Bing was looking at those links for URL discovery. https://twitter.com/CoperniX/status/1108790528773021696
I wrote something like that for my homepage, although as I only needed to switch between two styles and I'm not a front-end person, I didn't bother with an actual selection drop-down and just wrote a toggle that cycles through all alternate stylesheets one at a time.
I attribute this advice to Æleen Frisch; albeit without pulling my very dog-eared copy from the stacks, I recall that words to similar effect can be found in the epochal Essential System Administration (2002), possibly in the form of reading every manpage in your local Unix base system.
The button's name (optionally also its description) and to some degree its position in the DOM order (what heading and/or other form elements precedes it) needs to be sufficient to convey what will happen when it's used.
Each row can be its own form and you still end up with valid html.
This can also be done by the webserver with Content-Disposition. [1]
But it's cool, I didn't know this could be done with HTML, it offers a lot of possibilities.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
There is no straightforward way[0] for you to gracefully handle an error, which is quite an oversight once you factor in that network isn’t always reliable.
Having used it at first, I switched to server-side logic where I return data with Content-Disposition header if everything went well or redirect the user to show a proper error message in case of a problem.
[0] I imagine this could be worked around with some JS-based preflight or other trickery—which sounds like a suitable solution only if you have no control over the headers returned for some reason.
Though that is at least consistent with other download options like right-click/save-link-as, so is probably not incorrect behaviour.
1. Use JS, in which case one can handle errors and otherwise be involved in the request / response process. However, if you wish to offer a "download" funciton, this necessitates downloading all the data into JS memory before offering it to the user.
2. Use form-posting with `Content-Disposition`. One can no longer be involved with the request and response. And any response which does not have `Content-Disposition` will result in the browser redirecting. However, the user will be able to directly stream the download without your page being involved beyond initiating the request.
Since the data downloads are gigabytes in our case, we opted for (2). But I would also love to hear if I'm wrong about this trade-off.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#...
Maybe just me.
Which kind of illustrates why a lot of these things are not well-known. Why do something that that works on Firefox but not Chrome/Edge or on Safari/Firefox but not Chrome, etc? Specs are great, but near universal, reliably similar implementation is key.
In a lot of cases it means you have to build edge case UX. I'd rather lean on UX that's mostly under my control and not at the whim of browser adoption.
I did at least find some blink discussion on it: https://groups.google.com/a/chromium.org/g/blink-dev/c/Hfe5x...
This site suggests that enterkeyhint is supported on Chrome: https://caniuse.com/mdn-html_global_attributes_enterkeyhint
My own testing also shows that it works. Using the "search" value of the attribute, I was able to change the enter button into a magnifying glass.
[1]: https://standardebooks.org/manual/1.6.3/single-page#5.8
I love the <download> attribute, it's a quick way to use the default file download mechanisms without having to bother the user with opening a link or prompting. I realize there is the potential for abuse, but if you're careful, it's wonderful.
Native lazy loading support is coming to a bunch of things in the near future, if it's not there already, so this one is living on borrowed time.
If you've ever tried to implement CSP on a site, crossorigin and integrity should be famiilar - alas, CSP is hard, but you already knew that didn't you :)
Writing "<download>", with the word in angle brackets, makes it look like an element but it's not, download is an element attribute.
I am aware of the distinction, I only used that way b/c HN doesn't really have a good way to indicate code without multiple spaces or just blindly using the ` character which is...not great.
I recall in a (lost) blog theme I had at one point in time I'd scrounged a nice bit of CSS to add cite attributes visibly appended to blockquote and q elements. Exposing it to the user is possible in just pure CSS, but it is a bit of a shame that browsers didn't style it by default so many people didn't learn it was a thing.
In the nine years since that post, I have not once used it in a real project.
[0]: https://news.ycombinator.com/item?id=5594791