Hacker News Reader

Comment by ktpsns | Hacker News Reader

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

View on HN

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

Mozilla Suite also had toolbar for this kind of links. And early versions of Firefox either had it too or there was extension for it.

> Opera was the only browser which had a toolbar with these relational links.

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.

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.

Google search used to use rel=prev/next to identify paginated sequences for indexing, but not anymore. https://twitter.com/JohnMu/status/1108717486424363009

As of 2019, Bing was looking at those links for URL discovery. https://twitter.com/CoperniX/status/1108790528773021696

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.

Why do we have shit like `enterkeyhint` but not some really simple things like

    <input type="slider" min="0" max="100" step="10" name="foo">
    <input type="toggle" value="true" name="bar">

We have the first, it's just not called "slider".

It's called "range", and I didn't know about it either: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

And a "toggle" input is just a checkbox.

you mean range and checkbox inputs? (they both exist)

range -- damn, nobody told me

checkbox -- not a toggle, requires incredible pecking accuracy on mobile, non-hummingbirds cannot use

> requires incredible pecking accuracy on mobile, non-hummingbirds cannot use

At least that part is easily solved: Assign a label to the checkbox, label is tap-able. nice large target.

Styling it to look like a native toggle control is harder.

I remember that as the first time when using default styling of basic elements produced unusable results. I have to ask, when did it become my job to solve things like this?? Hidden check boxes with a check box in a label is not a nice elegant way of styling something at all. It's closer to an ugly hack. I find it an upsetting development given how well everything else was designed.

It seems we are going to get more good ideas in unfinished form?

The definition of a range is: "the area of variation between upper and lower limits on a particular scale." Why would the user only get to configure 1 of the 2? The definition of a slider is: a knob or lever that is moved horizontally or vertically to control a variable, such as the volume of a radio.

enterkeyhint="next" conceptually a great idea. Sadly it doesn't do anything? I wanted an attribute that makes the button go to the "next field".

Easily fixed by every developer individually a million+ times deep into the future.

> I wanted an attribute that makes the button go to the "next field"

What's wrong with the navigation controls provided by the browser for this purpose?

The up and down navigation controls provided by the browser work exactly the way we expect them to.

We had a good thing going there. It does what it says on the tin. Its how I (and everyone else) like things. A stop button makes it stop. Scissors are to cut. The little floppy disk is to save. A play button makes it play. etc

It seems so fundamental? How could anyone get this wrong? The user wants working buttons on their interface. Buttons that behave the way they expect.

I think no one wants an enter key that looks like a "next" button. In case I'm mistaken about that they could simply add a different value domstring.

>'enter' typically indicating inserting a new line.

I have to inserts a new line at the cursor?

>'done' typically meaning there is nothing more to input and the input method editor (IME) will be closed.

I have to close it?

>'go' typically meaning to take the user to the target of the text they typed.

I have to submit the form?

>'next' typically taking the user to the next field that will accept text.

I have to move the cursor to the next field?

>'previous' typically taking the user to the previous field that will accept text.

I have to move the cursor to the previous field?

>'search' typically taking the user to the results of searching for the text they have typed.

I have to submit the form?

>'send' typically delivering the text to its target.

I have to submit the form?

Maybe I'm missing something (I hope so)

> Why would the user only get to configure 1 of the 2?

I don't quite get what you mean here.

They had to come up with a name for a slider and called it range. This is the wrong name for it. A range slider should have 2 dots: One for the minimum and one for the maximum value. (Most common is searching by price in a web shop)

It means that if they ever want to introduce a real range selector it will have to get a different name.

It also means that if you search google for a range selector you are no longer able to find any of them. If a native one is ever introduced you wont be able to find it searching for range selector.

Also quite silly is that if you need both in your form you cant use this build in one as it will look different from your custom creation.

And it makes it harder to reason about forms. In the previous sentence I wanted to write "...need both a slider and a range selector" but that seems inaccurate/confusing.

If a checkbox isn't a toggle, what then by you is a toggle?

Have you used a phone at all?

Yes, every day since 2012 - I was a little late to the party, but managed to show up right around when it was really getting going. Unless the form is tiny and unzoomable, checkboxes have always seemed to work fine, no worse affected than any other web UI element by the essential imprecision of the interaction style.

Reply on news.ycombinator.com