without javascript the only meaningful thing that can be done in HTML are to navigate to a new document with HTTP GET (A[href=]) or submit data via HTTP POST or similar verbs ((BUTTON, INPUT[TYPE=BUTTON]. INPUT[TYPE=IMAGE]) where the url is in the FORM tag or the form* attributes. This is because without javascript there are no persistent stores on the client side and you have to interact with HTTP to create a stateful application.
It is not sufficiently accessible because it still won't activate on Space Bar or Enter/Return keydown events. "Accessible" does not only mean "screen reader users can use it."
If it is supposed to be a meaningful link - be it internal or external - use a direct anchor element with an href. Styling it however you like shouldn't hurt.
Otherwise, for any other interactions use a <button> element
I don't think this rule. Anchor tags should be used to go somewhere. Buttons should be used to do something. There are cases where these overlap (am I popping up a settings menu (doing something) or navigating to the settings (going somewhere)) but in many cases it is distinct.
Furthermore anchors have awesome features such as being able to copy the destination or open the link in a new tab. If the target isn't actually a real location using anchors can be confusing.
Am I the only one who thinks CSS + JS on top of HTML broke the conceptual model beyond hope?
The fact you can make any element look and behave the almost the same way – ignoring compatibility and usability issues – is a minefield. We could create a guide like this for basically everything and demonstrate 99% of the web isn't compliant.
The only problem with this is that, for historical reasons (and lack of caring?), the default stylesheets for unstyled HTML in the leading browsers are terrible. Best to apply a simple classless style sheet once then forget about it.
There's not that much that is objectively bad about the default styles. About the only thing that I can really put my finger on is equal top/bottom margins on headings. Possibly default line height, too. I wonder if one of the browsers will (or already has?) ever change that.
I don't think that's really true; in the original WWW proposal[1], Tim Berners-Lee specifically talks about using the web to build applications and he considered hypermedia applications to be only a matter of time and resources (about which he was correct).
> Tim Berners-Lee specifically talks about using the web to build applications
And those applicatons are, and I quote:
=== start quote ===
Specific Applications
The following are three examples of specific places in which the proposed system would be immediately useful. There are many others.
Development Project Documentation.
The Remote procedure Call project has a skeleton description using Enquire. Although limited, it is very useful for recording who did what, where they are, what documents exist, etc. Also, one can keep track of users, and can easily append any extra little bits of information which come to hand and have nowhere else to be put. Cross-links to other projects, and to databases which contain information on people and documents would be very useful, and save duplication of information.
Document retrieval.
The CERNDOC system provides the mechanics of storing and printing documents. A linked system would allow one to browse through concepts, documents, systems and authors, also allowing references between documents to be stored. (Once a document had been found, the existing machinery could be invoked to print it or display it).
The "Personal Skills Inventory".
Personal skills and experience are just the sort of thing which need hypertext flexibility. People can be linked to projects they have worked on, which in turn can be linked to particular machines, programming languages, etc.
=== end quote ===
The web, even in Tim Berners-Lee's vision, is strictly about documents.
In comparison, by 1989 France's Minitel had over three million installed terminals with over 6000 different services [1]. Many of them (mail-order, games, ticket purchases etc.) cannot be expressed in a document-centric system. But even then (and I'm pretty sure Tim-Berners Lee had been aware of Minitel), the web was presented as a system for viewing and sharing documents, and the job of applications was left to applications.
It depends on your level of reductionism; if you believe in Unix-style "everything is a file" then "everything is a document, including the applications that edit other documents" isn't a massive conceptual leap.
literally describes web applications as handling documents and only documents. Bases HTML on SGML, which is literally a language to describe documents, and only documents. Calls the system, a ypertext system. Lists exclusively text systems as systems one might connect to.
In the conclusion writes (emphasis mine): "We should work toward a universal linked information system, in which generality and portability are more important than fancy graphics techniques and complex extra facilities. The aim would be to allow a place to be found for any information or reference which one felt was important, and a way of finding it afterwards."
HN in 2021:
no-no-no, that's reductionism, what he really meant was full-featured applications, it's not "a massive conceptual leap"
====
Edit.
Time Berners-Lee in an interview [1]:
"It was designed in order to make it possible to get at documentation and in order to be able to get people — students working with me, contributing to the project, for example — to be able to come in and link in their ideas, so that we wouldn’t lose it all if we didn’t debrief them before they left. Really, it was designed to be a collaborative workspace for people to design on a system together. "
You sound like a stereotypical school teacher discussing literature. "What did the author mean, when he wrote the doo was red? Let's look at the evidence: https://news.ycombinator.com/item?id=27282030 Ah, yes, definitely fully-featured applications"
This is just playing a game with semantics; the form, canvas, dialog, and keygen elements are also first class. Nobody is saying that the web isn't primarily documents.
I wonder how much "HTML non-compliance" is lack of education and how much dark patterns. Remember the time clean URLs were a thing? Don't tell me Facebook engineers haven't heard about it.
For html buttons and other newer input elements specifically the css styling is really hard to get consistent/looking/working across devices and browsers or just flat out doesn't work.
Maybe developers should lean into just leaving the native styles, but it can look bad and present its own problems in tightly styled mobile sites or apps.
I might propose a better solution is expanding accessibly, aria, etc so we can make modern sites & elements more accessible.
The concept of what a website is has changed a LOT.
I don't think we can (and personally don't want to) stop the train towards expanding custom elements, components, intense dom stuff.
So instead we should prioritize making it more accessible.
It broke the conceptual model for programming, but allowed the web to take off in a way that it wouldn't have otherwise. We're dealing with the legacy of that decision. As someone who doesn't have to work on browser rendering engines, but did get into web development because of the super low barrier to entry in the 90s, I think it was the right call!
> Am I the only one who thinks CSS + JS on top of HTML broke the conceptual model beyond hope?
no. developers everywhere (but nowhere near "all developers") are forgetting the fundamental advantages of hypertext and are often commanding high salaries despite their staggering ignorance about how to build user interfaces.
we should be trending toward mostly perfect UI paradigms in certain use cases, yet every few months, for no reason at all, user interface designers make huge changes and wreck everything. only rarely do user interfaces get better with such changes.
where is the UI which made large, sensible changes early in its life, favoring smaller and smaller changes as the perfect interface for a particular set of data and actions makes itself obvious? I can't remember the last time I saw one. some games, probably.
I maintain that games probably produce the most usable UIs today, in many ways. they are usually very well thought out, each page usually has a single purpose, and each screen provides all information needed to make a decision or change on a single page, whenever possible. and game UIs are FAST.
I'd love to see a motivated game designer have a go at Service Now or any other contemporary enterprise software, really.
it's very much like web designers are learning less as the study of electronic user interfaces matures. if you judge this by web or mobile user interfaces, you have likely lost all hope that a single semi-sensible design will ever emerge.
designers are very good at making things look good, don't misinterpret me. usability does not seem to be getting better, though.
virtually every piece of enterprise software is an absolute mess.
it is often the columns of a database row exposed as html with a tiny bit of client-side validation in JavaScript.
a good UI has pages, panels, windows --whatever-- which have a single purpose and show only what is necessary for a user to do the thing that page/panel/whatever is meant for. show everything that is needed, and nothing more.
it's a very high bar to reach, and very difficult to get right. just avoid making awful mistakes and you'll do fine, I'm sure.
This seems a bit unfair to single out given that they gave equal styles to all the buttons. Why didn't they include `cursor: default` so they all look exactly the same but function slightly differently?
They don't apply any cursor styles to any of these 'buttons', as far as I can see. Their stylesheet (https://www.buttoncheatsheet.com/assets/style.css) only has one instance of "cursor", which is unrelated.
The normal arrow (not the hand) is supposed to be the correct cursor for buttons, but many people change it to the hand because they think it indicates interactivity.
However, the div button is still wrong because it shows the text selection cursor in the button.
<applet code="button.class" height="60" width="240">
<param name="button" value="Yea or nay?">
<b>Sorry, you need Java to press this button.</b>
</applet>
I had some buttons like that back in the day, with animations, sound effects and all, geocities-esque. The computer almost grinded to a halt loading it, but pre-teen me felt it was worth it.
To me, a good website should be usable without any added style or scripting. CSS should make it look good, but you should be using the markup to make is usable and roughly laid out how you want, at least with a sensible default.
HTML embedded into email templates often uses tables for layout.
If you get a commercial email and the content has graphic borders around the content, check the source and you'll probably see a table. Also emails with text content in columns.
Do you have an example of such a website? I'm genuinely curious if such a thing exists. I've been doing some CSS+HTML tutorials lately, and the ones I've been reading, I don't see how you would without style attributes in all of your tags, which is essentially just using CSS.
This very site is usable for reading and writing without CSS or JavaScript. Oddly, you can vote without JavaScript but not without CSS (buttons aren't visible in layout), which could easily be corrected.
Its appearance doesn't change as much as it might because it uses nested tables for layout (a Nineties-era practice) and deprecated properties like bgcolor but even without those choices it could still be usable.
'Early' websites [0] were very linear, text-heavy affairs. They still had images, of course, just a pretty basic 'full width, top to bottom' layout. Authors quickly realised you could abuse tables for layout, but rudimentary alternatives used frames. They just relied on default styles. Next time you're working on a site, just drop the stylesheet. That. That's what sites looked like.
[0] I'm talking mid-late nineties here. I don't know, off the top of my head, what level of CSS support or style-in-html support there was, I'm just talking about very hazy memories of what they looked like.
69 comments
[ 4.8 ms ] story [ 108 ms ] threadSwitching markup completely is a larger effort than adding tabindex and role and the latter still provides a benefit.
The page repeatedly mentions accessibility characteristics, it just doesn't call them all out as such.
> Not keyboard focusable
> Correct button role
> correct key events by default
> No accessible name
"Shows wrong cursor on hover" is arguably also about an accessibility characteristic.
If it is supposed to be a meaningful link - be it internal or external - use a direct anchor element with an href. Styling it however you like shouldn't hurt.
Otherwise, for any other interactions use a <button> element
Furthermore anchors have awesome features such as being able to copy the destination or open the link in a new tab. If the target isn't actually a real location using anchors can be confusing.
Thanks for making this and illustrating all the cases and variations of a problem, consider making a whole site about these accessibility problems
You'll find more stuff like that on my other site htmhell.dev.l, if you're interested. :)
The fact you can make any element look and behave the almost the same way – ignoring compatibility and usability issues – is a minefield. We could create a guide like this for basically everything and demonstrate 99% of the web isn't compliant.
[1]: https://www.w3.org/History/1989/proposal.html
And those applicatons are, and I quote:
=== start quote ===
Specific Applications
The following are three examples of specific places in which the proposed system would be immediately useful. There are many others.
Development Project Documentation.
The Remote procedure Call project has a skeleton description using Enquire. Although limited, it is very useful for recording who did what, where they are, what documents exist, etc. Also, one can keep track of users, and can easily append any extra little bits of information which come to hand and have nowhere else to be put. Cross-links to other projects, and to databases which contain information on people and documents would be very useful, and save duplication of information.
Document retrieval.
The CERNDOC system provides the mechanics of storing and printing documents. A linked system would allow one to browse through concepts, documents, systems and authors, also allowing references between documents to be stored. (Once a document had been found, the existing machinery could be invoked to print it or display it).
The "Personal Skills Inventory".
Personal skills and experience are just the sort of thing which need hypertext flexibility. People can be linked to projects they have worked on, which in turn can be linked to particular machines, programming languages, etc.
=== end quote ===
The web, even in Tim Berners-Lee's vision, is strictly about documents.
In comparison, by 1989 France's Minitel had over three million installed terminals with over 6000 different services [1]. Many of them (mail-order, games, ticket purchases etc.) cannot be expressed in a document-centric system. But even then (and I'm pretty sure Tim-Berners Lee had been aware of Minitel), the web was presented as a system for viewing and sharing documents, and the job of applications was left to applications.
[1] https://en.wikipedia.org/wiki/Minitel
literally describes web applications as handling documents and only documents. Bases HTML on SGML, which is literally a language to describe documents, and only documents. Calls the system, a ypertext system. Lists exclusively text systems as systems one might connect to.
In the conclusion writes (emphasis mine): "We should work toward a universal linked information system, in which generality and portability are more important than fancy graphics techniques and complex extra facilities. The aim would be to allow a place to be found for any information or reference which one felt was important, and a way of finding it afterwards."
HN in 2021:
no-no-no, that's reductionism, what he really meant was full-featured applications, it's not "a massive conceptual leap"
====
Edit.
Time Berners-Lee in an interview [1]:
"It was designed in order to make it possible to get at documentation and in order to be able to get people — students working with me, contributing to the project, for example — to be able to come in and link in their ideas, so that we wouldn’t lose it all if we didn’t debrief them before they left. Really, it was designed to be a collaborative workspace for people to design on a system together. "
[1] https://achievement.org/achiever/sir-timothy-berners-lee/#in...
> would be immediately useful. There are many others.
Aren't we at the "many others" point of Sir Tim's theory?
You're using his three specific examples as if he was talking about the limit of the thing. I think he was talking about the start of something big.
Paragraph tags are first class versus a Modal in HTML.
https://m.facebook.com/events/2805322196445083/?event_time_i...
Like seriously. It's almost like someone learned HTML/HTTP best practices, then did the exact opposite.
Cool URIs are about permanence. Reworking your internal file-structure should not break existing URIs. [0]
Clean URLs are about avoiding leaking implementation details into the URL, e.g. .php, and also avoiding excessive use of query strings. [1]
[0] https://www.w3.org/Provider/Style/URI
[1] https://en.wikipedia.org/wiki/Clean_URL#Structure
Make up your own mind where you point it when it is loaded.
If you choose your own foot, that is your choice!
Maybe developers should lean into just leaving the native styles, but it can look bad and present its own problems in tightly styled mobile sites or apps.
I might propose a better solution is expanding accessibly, aria, etc so we can make modern sites & elements more accessible.
The concept of what a website is has changed a LOT.
I don't think we can (and personally don't want to) stop the train towards expanding custom elements, components, intense dom stuff.
So instead we should prioritize making it more accessible.
no. developers everywhere (but nowhere near "all developers") are forgetting the fundamental advantages of hypertext and are often commanding high salaries despite their staggering ignorance about how to build user interfaces.
we should be trending toward mostly perfect UI paradigms in certain use cases, yet every few months, for no reason at all, user interface designers make huge changes and wreck everything. only rarely do user interfaces get better with such changes.
where is the UI which made large, sensible changes early in its life, favoring smaller and smaller changes as the perfect interface for a particular set of data and actions makes itself obvious? I can't remember the last time I saw one. some games, probably.
I maintain that games probably produce the most usable UIs today, in many ways. they are usually very well thought out, each page usually has a single purpose, and each screen provides all information needed to make a decision or change on a single page, whenever possible. and game UIs are FAST.
I'd love to see a motivated game designer have a go at Service Now or any other contemporary enterprise software, really.
it's very much like web designers are learning less as the study of electronic user interfaces matures. if you judge this by web or mobile user interfaces, you have likely lost all hope that a single semi-sensible design will ever emerge.
designers are very good at making things look good, don't misinterpret me. usability does not seem to be getting better, though.
I welcome counter-examples.
it is often the columns of a database row exposed as html with a tiny bit of client-side validation in JavaScript.
a good UI has pages, panels, windows --whatever-- which have a single purpose and show only what is necessary for a user to do the thing that page/panel/whatever is meant for. show everything that is needed, and nothing more.
it's a very high bar to reach, and very difficult to get right. just avoid making awful mistakes and you'll do fine, I'm sure.
This seems a bit unfair to single out given that they gave equal styles to all the buttons. Why didn't they include `cursor: default` so they all look exactly the same but function slightly differently?
However, the div button is still wrong because it shows the text selection cursor in the button.
If you get a commercial email and the content has graphic borders around the content, check the source and you'll probably see a table. Also emails with text content in columns.
Its appearance doesn't change as much as it might because it uses nested tables for layout (a Nineties-era practice) and deprecated properties like bgcolor but even without those choices it could still be usable.
[0] I'm talking mid-late nineties here. I don't know, off the top of my head, what level of CSS support or style-in-html support there was, I'm just talking about very hazy memories of what they looked like.
As I was building it, I'd constantly check it with CSS off in order to make sure it had a reasonable flow for folks using screen readers.
www.ft.io if you're interested.
It's a button with all the properties of an image. Haven't used it in many years but it's still around.
In any sufficiently complex UI, you really do end up needing a wide variety of button treatments, depending on the context, hierarchy, etc