4 ms·

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

by 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...
- SilasX 6y ago
  That much I understand. But then, if you want it to act like a button -- do something on the page but not link anywhere -- why not leave it to look like a button so the user has the right expectation for what it's doing? As I thought, this use-case comes down to "How do I trick the user into treating something like a link when it's really a button?" Or, more generally, "How do I subvert user expectations for a website?" How about, don't? Maybe the fact that it's hard to do within the web spec means you should re-think what you were trying to do?
  - kall 6y ago
    Do you think the [-] link on this very comment should look and layout flow like a button?
    - deleted 6y ago
      [deleted]
    - mwcampbell 6y ago
      Yes. So should the upvote, downvote, and unvote links, because these things don't go to nw pages, and the voting links take immediate action.
      - ratww 6y ago
        I agree with you, but just a point: the upvote and downvote arrows actually go to other pages when you disable JS, so it makes sense for them to be <a> tags. They should provide better feedback though (and a title attribute for screen readers). The [-] is more complicated. Ideally it would link to a non-js fallback, but alas. But it's much better as an anchor tag than as a button disguised as a link.
        robertoandred 6y ago
        No, it's the absolute worst kind of anchor link: it's linking to javascript:void(0). It should be a button. Not complicated.
        ratww 6y ago
        Read again. The point was that it should be a button that looks like a button, or a link with proper fallback for non-JS users. It should have a title attribute and feedback as well, for screen readers. It should never be a button disguised as a link, however. Fake links are much worse than javascript:void(0), because they break expectations of users, and are more prone to breaking. At least with javascript:void(0) browsers are able to use it as a hint to disable certain context-menu items, and it's much better than having a fake link. For accessibility purposes, if you need button behavior but link-look you should use role="button".
        mwcampbell 6y ago
        > The point was that it should be a button that looks like a button, or a link with proper fallback for non-JS users. And in case I wasn't clear, I agree with that.
- ratww 6y ago
  > 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. Why? It really shouldn't look like a link. The mere fact that it requires a 20-line-hack is enough proof that this is a hack. It subvert user expectations (example: it's a link that you can't right click, tab behaves differently), accessibility (example: it looks like a link but will register as a button to a screen reader) and will probably look different in some browsers. If you indeed need a navigational link you can freely attach a onclick event to a link. If the link has no proper non-javascript fallback (it ideally should, though) you can link to javascript:void(0); and most browsers will prevent the "Open in New Window" option from showing up in context menus.
  - deleted 6y ago
    [deleted]
  - Deimorz 6y ago
    The entire subject of this thread is about getting accessibility and other benefits for free if you write semantically-correct HTML. You're arguing for the exact opposite: just using whatever element gives you the appearance you want, regardless of whether it's the correct one or not. Using CSS to change the appearance of a button isn't a hack, that's the explicit purpose of CSS. It's a hack to make a link point to "javascript:void(0)" to prevent it from doing the thing it's supposed to do.
    - ratww 6y ago
      That's not true. I'm not advocating that. I'm making exactly the same point as the article: using semantic HTML will get you accessibility for free. If you need something that makes an action, then it should be a button but never disguised as a link. It should just look like a button. This way you won't subvert users expectations (you said it yourself: links are for taking users to another URL), and will still be accessible to screen-reader users. If you need something that takes to another page, then it should be a link, even if it uses Javascript behind the scenes. This way screen-reader users will know it's a link taking somewhere else and sighted users will have the same experience. - > Using CSS to change the appearance of a button isn't a hack, that's the explicit purpose of CSS. It's a hack to make a link point to "javascript:void(0)" to prevent it from doing the thing it's supposed to do. I disagree. MDN's CSS accessibility page starts precisely with this: "It is possible to use CSS to make any HTML element look like anything, but this doesn't mean that you should". [1] Changing the whole look and feel of an element to emulate another is definitely a hack. You would also need aria-role="link" to have proper accessibility, btw. Which is exactly the point of the article: not having to sprinke aria-role just because you're using non-semantic HTML. Ideally you would have a proper link instead of a fallback, so that users can open the link in a new window or save a bookmark. Using javascript:void(0) is less than ideal but at least gives a hint to the browser that the link is not taking the user to another URL. [1] https://developer.mozilla.org/en-US/docs/Learn/Accessibility/CSS_and_JavaScript https://developer.mozilla.org/en-US/docs/Learn/Accessibility... EDIT: Replaced bad argument with the MDN quote.
- dalore 6y ago
  This is a similar discussion to what happened last month https://news.ycombinator.com/item?id=22965184 https://news.ycombinator.com/item?id=22965184 I asked if book now should be a button or a link if it takes you to an ordering page, still not sure.
Etheryte 6y ago
I think focusing solely on the link side of things is missing the forest for the trees. All of the same points apply if you want a button element to look like pretty much anything other than the default button, that is, use an actual design on your page while keeping semantics in tact.

by SilasX 6y ago

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

SilasX 6y ago
That much I understand. But then, if you want it to act like a button -- do something on the page but not link anywhere -- why not leave it to look like a button so the user has the right expectation for what it's doing? As I thought, this use-case comes down to "How do I trick the user into treating something like a link when it's really a button?" Or, more generally, "How do I subvert user expectations for a website?" How about, don't? Maybe the fact that it's hard to do within the web spec means you should re-think what you were trying to do?
- kall 6y ago
  Do you think the [-] link on this very comment should look and layout flow like a button?
  - deleted 6y ago
    [deleted]
  - mwcampbell 6y ago
    Yes. So should the upvote, downvote, and unvote links, because these things don't go to nw pages, and the voting links take immediate action.
    - ratww 6y ago
      I agree with you, but just a point: the upvote and downvote arrows actually go to other pages when you disable JS, so it makes sense for them to be <a> tags. They should provide better feedback though (and a title attribute for screen readers). The [-] is more complicated. Ideally it would link to a non-js fallback, but alas. But it's much better as an anchor tag than as a button disguised as a link.
      - robertoandred 6y ago
        No, it's the absolute worst kind of anchor link: it's linking to javascript:void(0). It should be a button. Not complicated.
        ratww 6y ago
        Read again. The point was that it should be a button that looks like a button, or a link with proper fallback for non-JS users. It should have a title attribute and feedback as well, for screen readers. It should never be a button disguised as a link, however. Fake links are much worse than javascript:void(0), because they break expectations of users, and are more prone to breaking. At least with javascript:void(0) browsers are able to use it as a hint to disable certain context-menu items, and it's much better than having a fake link. For accessibility purposes, if you need button behavior but link-look you should use role="button".
        mwcampbell 6y ago
        > The point was that it should be a button that looks like a button, or a link with proper fallback for non-JS users. And in case I wasn't clear, I agree with that.
ratww 6y ago
> 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. Why? It really shouldn't look like a link. The mere fact that it requires a 20-line-hack is enough proof that this is a hack. It subvert user expectations (example: it's a link that you can't right click, tab behaves differently), accessibility (example: it looks like a link but will register as a button to a screen reader) and will probably look different in some browsers. If you indeed need a navigational link you can freely attach a onclick event to a link. If the link has no proper non-javascript fallback (it ideally should, though) you can link to javascript:void(0); and most browsers will prevent the "Open in New Window" option from showing up in context menus.
- deleted 6y ago
  [deleted]
- Deimorz 6y ago
  The entire subject of this thread is about getting accessibility and other benefits for free if you write semantically-correct HTML. You're arguing for the exact opposite: just using whatever element gives you the appearance you want, regardless of whether it's the correct one or not. Using CSS to change the appearance of a button isn't a hack, that's the explicit purpose of CSS. It's a hack to make a link point to "javascript:void(0)" to prevent it from doing the thing it's supposed to do.
  - ratww 6y ago
    That's not true. I'm not advocating that. I'm making exactly the same point as the article: using semantic HTML will get you accessibility for free. If you need something that makes an action, then it should be a button but never disguised as a link. It should just look like a button. This way you won't subvert users expectations (you said it yourself: links are for taking users to another URL), and will still be accessible to screen-reader users. If you need something that takes to another page, then it should be a link, even if it uses Javascript behind the scenes. This way screen-reader users will know it's a link taking somewhere else and sighted users will have the same experience. - > Using CSS to change the appearance of a button isn't a hack, that's the explicit purpose of CSS. It's a hack to make a link point to "javascript:void(0)" to prevent it from doing the thing it's supposed to do. I disagree. MDN's CSS accessibility page starts precisely with this: "It is possible to use CSS to make any HTML element look like anything, but this doesn't mean that you should". [1] Changing the whole look and feel of an element to emulate another is definitely a hack. You would also need aria-role="link" to have proper accessibility, btw. Which is exactly the point of the article: not having to sprinke aria-role just because you're using non-semantic HTML. Ideally you would have a proper link instead of a fallback, so that users can open the link in a new window or save a bookmark. Using javascript:void(0) is less than ideal but at least gives a hint to the browser that the link is not taking the user to another URL. [1] https://developer.mozilla.org/en-US/docs/Learn/Accessibility/CSS_and_JavaScript https://developer.mozilla.org/en-US/docs/Learn/Accessibility... EDIT: Replaced bad argument with the MDN quote.
dalore 6y ago
This is a similar discussion to what happened last month https://news.ycombinator.com/item?id=22965184 https://news.ycombinator.com/item?id=22965184 I asked if book now should be a button or a link if it takes you to an ordering page, still not sure.

Etheryte 6y ago

I think focusing solely on the link side of things is missing the forest for the trees. All of the same points apply if you want a button element to look like pretty much anything other than the default button, that is, use an actual design on your page while keeping semantics in tact.