6 ms·

This article hit on a number of issues I have with today's Web development. The Biggie: >Remember that the browser is the user agent, not the developer agent.

This article hit on a number of issues I have with today's Web development. The Biggie: >Remember that the browser is the user agent, not the developer agent. Others I find significant: >“trust the web browser”. >Don’t mess about with the scroll wheel >don’t override default behaviors on the right click and text selection. >Don’t use JavaScript to create custom input elements like text boxes, combo boxes, or scrollbars. >Try not to use a purely visual representation of information, such as an icon: these should always be paired with text. >Also avoid moving information around — animations and visually complex state transitions. >When adding images, always include an “alt” tag with a plain-English description of the image. When using correct document structure and semantics, it can be amazing what you get for "free" with respect to usability. Additional issues I deal with on a daily basis which exist because some folks weren't satisfied with the default, correct behavior: - A div with a "click" event is not a button or link - A div with nested span elements is not a select - The ad hoc "click" event handling does not handle auxiliary/middle click behavior - An icon, with no accompanying text, also has no title attribute or anything else to convey its purpose to the user - The ad hoc navigation implementation does not recall scroll position - The ad hoc navigation implementation does not allow me to "back" out of the website - The scroll event handler, called tens/hundreds of times per second, so that it can update the sticky "progress" bar that someone thought was necessary to inform me how far along the article I've come, increases my energy bill and the ambient temperature inside my home Sometimes I just want to grab these folks by the collar and yell "Stop touching it!"

raspyberr 6y ago
Something that I struggle with is finding how to do things properly. For example, search for "learn HTML" and you'll see all these online tutorials which I can already tell aren't gonna be what I'm actually looking for. How do you find out what to avoid and what standards to follow?
- cxr 6y ago
  Sorry you didn't get an answer. Unfortunately, as with many things, the answer is, "be someone who already knows all the things that you're trying to learn", or, "be an old person who witnessed the progression in real time". You could try replicating the old person experience by starting with something like Dave Raggett's introduction to HTML or anything that focuses on HTML 4, and then look at why HTML5 added the things that it did. alistapart.com also hosts a lot of articles on this type of thing.
Etheryte 6y ago
I think a big part of the issue here, and one that's often overlooked, is that both browser vendors and the resulting spec are to blame for the emergence of many of these patterns. For example, making a button that visually looks like a link but keeps the correct semantics takes over 20 lines of non-trivial CSS, even today [1]. It is then no wonder that developers take the easier route of attaching event listeners to links instead. Realistically, if we want to have sites that are semantically sound, writing them the correct way should be so easy that you'd have to go out of your way to make them broken. Even with standards as new as HTML5 we have nonsense like the <article> and the <section> tag. Quoting MDN [2][3], "[the] <article> element represents a self-contained composition" and "[the] <section> element represents a standalone section". Even when I try my best to be semantically correct, I can't really tell when to use which. [1] https://stackoverflow.com/a/12642009/1470607 https://stackoverflow.com/a/12642009/1470607 [2] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/article https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ar... [3] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/section https://developer.mozilla.org/en-US/docs/Web/HTML/Element/se...
- SilasX 6y ago
  >For example, making a button that visually looks like a link but keeps the correct semantics takes over 20 lines of non-trivial CSS, even today. Can you explain the use-case here? What about "being a button" do you need for the desired functionality? You just want it not to look like a button, while still acting like a button and looking like a link?
  - deleted 6y ago
    [deleted]
  - Deimorz 6y ago
    Over-simplifying, but in general a link should take you to a different url/destination. So if you want something that takes an action on the current page via JS but looks like a text link, it should be a <button> element styled as a link. Here's a good, extensive article on the differences and use-cases for links and buttons: https://css-tricks.com/a-complete-guide-to-links-and-buttons/ https://css-tricks.com/a-complete-guide-to-links-and-buttons...
esperent 6y ago
I would append 'unless you do it really well' to a lot of these statements. In fact, I bet you use websites on a daily basis that do many of these, but you don't even notice because they do it well. You only notice those who do it badly. Except for stealing the back button. There's a special hell for any dev who does that.
- ori_b 6y ago
  Yeah. With a lot of time and effort, you can get a result that's so good, it's indistinguishable from not doing anything special at all.
- deleted 6y ago
  [deleted]
- mwcampbell 6y ago
  The problem is that you can do it well enough that no one using a browser in the normal way would notice, but people doing things differently, whether by necessity (e.g. because of a disability) or preference, would still notice.
- a1369209993 6y ago
  No, it's especially if you do it really well, because then it takes longer for people to realize it's broken.
- chrismorgan 6y ago
  Trouble is that many of these things are impossible to do correctly. Taking some of the items in the list quoted: • Scrolljacking. The web doesn’t provide the APIs necessary to synthesise the effect of scrolling from mouse events. • Context menu behaviour: a tricky one, because there are some web apps where it seems reasonable and useful to provide your own context menu, but where it is conceivable that items in the native context menu may be desirable also. There’s no winning move here. There was a web API to handle this properly, where you could add items to the native context menu (<menu type=context>), but only Firefox has implemented it (and the writing is on the wall for it). I have no idea why the others have scuttled this seriously useful functionality. • Custom combo boxes: there’s a baseline of functionality (which most custom combo box widgets don’t cover properly anyway…), but beyond that each platform has its own subtleties that are not exposed in any way. If you truly want a custom combo box to feel native, you’ll need to sniff the platform and special-case. This leaves you open to getting things wrong in quite a few ways. • Custom scrollbars: all the relevant APIs are async and these days typically debounced a tad, so that it’s simply not possible to guarantee that your custom scrollbar will match the scroll container on every frame—and in almost all cases it will be delayed by at least one frame. (For the rest it is possible to do a flawless job. But it’s generally a much better idea to just not fiddle with things. I say this as someone who has made complex custom input controls and made sure they’re as close to perfect as is technically feasible without platform specialisation, but who definitely prefers to keep things simple. Oh, and I hate scrolljacking unconditionally.)
hinkley 6y ago
> Don’t use JavaScript to create custom input elements like text boxes, combo boxes, or scrollbars. You can style input elements heavily, and in some cases you can shadow them (associate a manufactured UI element with a real input element, and then conceal the real element). In fact for certain interactions you have to do this due to user agent hardening against CSRF attacks.

raspyberr 6y ago

Something that I struggle with is finding how to do things properly. For example, search for "learn HTML" and you'll see all these online tutorials which I can already tell aren't gonna be what I'm actually looking for. How do you find out what to avoid and what standards to follow?

cxr 6y ago
Sorry you didn't get an answer. Unfortunately, as with many things, the answer is, "be someone who already knows all the things that you're trying to learn", or, "be an old person who witnessed the progression in real time". You could try replicating the old person experience by starting with something like Dave Raggett's introduction to HTML or anything that focuses on HTML 4, and then look at why HTML5 added the things that it did. alistapart.com also hosts a lot of articles on this type of thing.

Etheryte 6y ago

I think a big part of the issue here, and one that's often overlooked, is that both browser vendors and the resulting spec are to blame for the emergence of many of these patterns. For example, making a button that visually looks like a link but keeps the correct semantics takes over 20 lines of non-trivial CSS, even today [1]. It is then no wonder that developers take the easier route of attaching event listeners to links instead. Realistically, if we want to have sites that are semantically sound, writing them the correct way should be so easy that you'd have to go out of your way to make them broken. Even with standards as new as HTML5 we have nonsense like the <article> and the <section> tag. Quoting MDN [2][3], "[the] <article> element represents a self-contained composition" and "[the] <section> element represents a standalone section". Even when I try my best to be semantically correct, I can't really tell when to use which. [1] https://stackoverflow.com/a/12642009/1470607 https://stackoverflow.com/a/12642009/1470607 [2] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/article https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ar... [3] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/section https://developer.mozilla.org/en-US/docs/Web/HTML/Element/se...

SilasX 6y ago
>For example, making a button that visually looks like a link but keeps the correct semantics takes over 20 lines of non-trivial CSS, even today. Can you explain the use-case here? What about "being a button" do you need for the desired functionality? You just want it not to look like a button, while still acting like a button and looking like a link?
- deleted 6y ago
  [deleted]
- Deimorz 6y ago
  Over-simplifying, but in general a link should take you to a different url/destination. So if you want something that takes an action on the current page via JS but looks like a text link, it should be a <button> element styled as a link. Here's a good, extensive article on the differences and use-cases for links and buttons: https://css-tricks.com/a-complete-guide-to-links-and-buttons/ https://css-tricks.com/a-complete-guide-to-links-and-buttons...

esperent 6y ago

I would append 'unless you do it really well' to a lot of these statements. In fact, I bet you use websites on a daily basis that do many of these, but you don't even notice because they do it well. You only notice those who do it badly. Except for stealing the back button. There's a special hell for any dev who does that.

ori_b 6y ago
Yeah. With a lot of time and effort, you can get a result that's so good, it's indistinguishable from not doing anything special at all.
deleted 6y ago
[deleted]
mwcampbell 6y ago
The problem is that you can do it well enough that no one using a browser in the normal way would notice, but people doing things differently, whether by necessity (e.g. because of a disability) or preference, would still notice.
a1369209993 6y ago
No, it's especially if you do it really well, because then it takes longer for people to realize it's broken.
chrismorgan 6y ago
Trouble is that many of these things are impossible to do correctly. Taking some of the items in the list quoted: • Scrolljacking. The web doesn’t provide the APIs necessary to synthesise the effect of scrolling from mouse events. • Context menu behaviour: a tricky one, because there are some web apps where it seems reasonable and useful to provide your own context menu, but where it is conceivable that items in the native context menu may be desirable also. There’s no winning move here. There was a web API to handle this properly, where you could add items to the native context menu (<menu type=context>), but only Firefox has implemented it (and the writing is on the wall for it). I have no idea why the others have scuttled this seriously useful functionality. • Custom combo boxes: there’s a baseline of functionality (which most custom combo box widgets don’t cover properly anyway…), but beyond that each platform has its own subtleties that are not exposed in any way. If you truly want a custom combo box to feel native, you’ll need to sniff the platform and special-case. This leaves you open to getting things wrong in quite a few ways. • Custom scrollbars: all the relevant APIs are async and these days typically debounced a tad, so that it’s simply not possible to guarantee that your custom scrollbar will match the scroll container on every frame—and in almost all cases it will be delayed by at least one frame. (For the rest it is possible to do a flawless job. But it’s generally a much better idea to just not fiddle with things. I say this as someone who has made complex custom input controls and made sure they’re as close to perfect as is technically feasible without platform specialisation, but who definitely prefers to keep things simple. Oh, and I hate scrolljacking unconditionally.)

hinkley 6y ago

> Don’t use JavaScript to create custom input elements like text boxes, combo boxes, or scrollbars. You can style input elements heavily, and in some cases you can shadow them (associate a manufactured UI element with a real input element, and then conceal the real element). In fact for certain interactions you have to do this due to user agent hardening against CSRF attacks.