6 ms·

Do you think the [-] link on this very comment should look and layout flow like a button?

by kall 6y ago

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.
    - a1369209993 6y ago
      The upvote link on your comment goes to [ https://news.ycombinator.com/vote?id=23327414&how=up&auth=51f460b4a5e8302f4ab6bf2d1dd7631902fab274&goto=item%3Fid%3D23327414#23327414 https://news.ycombinator.com/vote?id=23327414&how=up&auth=51... ] not [ javascript:void(0) ]. Are you sure you don't have RCE vulnerabilities enabled?
  - extra88 6y ago
    The title attribute is not a good way to give elements an accessible name for screen readers (except iframes, title attribute is the right choice for them). Better would be to put the text inside the existing div and use CSS to visually hide it (which does take ~11 properties to cover older and different browsers): <div class="votearrow" title="upvote">Upvote</div> Alternately, instead of having the grayarrow.gif as a background image on a div, they could use an img element so the alt attribute becomes the accessible name of the link. Editing it in my browser's inspector, it looks exactly the same: <img src="grayarrow.gif" alt="upvote" title="upvote"> An advantage of this approach is if the GIF doesn't load, the alt text is displayed instead (in some browsers, not all). If you want to leave the title attribute to show on hover, that's fine but it's only going to help a sighted mouse user who needs more than triangles to understand that clicking them will upvote or downvote. Since there are many upvote buttons on a page, a standard accessibility recommendation would be for each to have unique names to differentiate them out of context, something like "upvote ratww message 23326798." If user testing was done with people who use screen readers, I suspect they'd say that's too wordy and these controls should not be used out of context therefore, "upvote" and "downvote" are fine.
    - ratww 6y ago
      Great post, thanks for the correction.
  - robocat 6y ago
    A submit button also takes you to a new page using a POST, and functionally if JavaScript is disabled then upvote/downvote would be acting as a submit button. There is some nuance to getting that right (forms). I think an <a></a> shouldn’t be used, because that is a GET action, which should be idempotent.
    - ratww 6y ago
      That's true, I agree that this is a better option.
SilasX 6y ago
Let me first say, this is a really great discussion that has forced me to think, and I'm upvoting both sides, including Deimorz and ratww. On one hand, if I expect buttons, and only buttons, to have some non-link in-page effect, then yes, those [-] things should be buttons. OTOH, as ratww, notes, the up/downvotes "are links", in a sense -- if JS is disabled, it just does the upvote with a page load, so functionally it's like a link and deserves <a> and not being a button. But by that logic, nothing deserves to be a button because you could replace it with a page load + the desired effect. So let's go with the "make it a button" implication. I tried wrapping the [-]s it <button> tags, and yeah, that gives the button styling, which doesn't fit with the HN general style -- I'd prefer it stay text. So I grudgingly (and tentatively) concede there are things that semantically should be buttons but whose default styling I'd still want to excise right out of them, forcing me into that dilemma I previously ridiculed. But is there still a way that I'm wrong about that concession?
- ratww 6y ago
  My objection is more about making a button looking like a link, as in the linked StackOverflow answer. I stand by my post that this is wrong because you're subverting user expectations and probably making life harder for everyone involved ("why am I tabbing to this, this is not a button... why can't I right click it... aaaaargh"). > But by that logic, nothing deserves to be a button because you could replace it with a page load + the desired effect. Not really. For instance, for the downvote/upvote buttons (or links?) here I actually agree with mwcampbell, they should be buttons. I don't think my other answers don't apply to them, because they don't look like links anyway. They could even be submit buttons inside forms to keep the site working when JS is disabled. And for the [-], couchand just suggested <details> and this is the correct answer for me now.
  - SilasX 6y ago
    >My objection is more about making a button looking like a link, as in the linked StackOverflow answer. Oh, I agree on that point -- if it is legitimately a button, you should not make it look like a link. That's like you're trying to them into thinking the click will take them to a different page. (Among other problems.) It's just that the issue of handling the [-] collapse icon caused me to realize there could be a use under those constraints. >And for the [-], couchand just suggested <details> and this is the correct answer for me now. Ah, wasn't aware of that. That seems like a better approach.
couchand 6y ago
No, the proper semantic element is <details>, just let the browser render the expand/collapse control.
comex 6y ago
I’d say it already looks like a button. To me, [-] comes off as basically ASCII art for a box with a minus sign in it, similar to the classic Windows progressive disclosure controls: https://docs.microsoft.com/en-us/windows/win32/uxguide/images/progressive-disclosure-controls-image16.png https://docs.microsoft.com/en-us/windows/win32/uxguide/image... And a rectangular outline and/or background is of course the basic visual element that indicates a button. The ASCII art look works well here, but that’s because HN has an intentionally lo-fi aesthetic. On an average site I’d say it should be changed to a real box. Not a plain unstyled <button>, since (depending on the platform) those stand out too much for a relatively unimportant UI element. But I think a styled one would work. I don’t have enough HTML experience to know what the issues are with layout.

Do you think the [-] link on this very comment should look and layout flow like a button?

by 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.
  - a1369209993 6y ago
    The upvote link on your comment goes to [ https://news.ycombinator.com/vote?id=23327414&how=up&auth=51f460b4a5e8302f4ab6bf2d1dd7631902fab274&goto=item%3Fid%3D23327414#23327414 https://news.ycombinator.com/vote?id=23327414&how=up&auth=51... ] not [ javascript:void(0) ]. Are you sure you don't have RCE vulnerabilities enabled?
- extra88 6y ago
  The title attribute is not a good way to give elements an accessible name for screen readers (except iframes, title attribute is the right choice for them). Better would be to put the text inside the existing div and use CSS to visually hide it (which does take ~11 properties to cover older and different browsers): <div class="votearrow" title="upvote">Upvote</div> Alternately, instead of having the grayarrow.gif as a background image on a div, they could use an img element so the alt attribute becomes the accessible name of the link. Editing it in my browser's inspector, it looks exactly the same: <img src="grayarrow.gif" alt="upvote" title="upvote"> An advantage of this approach is if the GIF doesn't load, the alt text is displayed instead (in some browsers, not all). If you want to leave the title attribute to show on hover, that's fine but it's only going to help a sighted mouse user who needs more than triangles to understand that clicking them will upvote or downvote. Since there are many upvote buttons on a page, a standard accessibility recommendation would be for each to have unique names to differentiate them out of context, something like "upvote ratww message 23326798." If user testing was done with people who use screen readers, I suspect they'd say that's too wordy and these controls should not be used out of context therefore, "upvote" and "downvote" are fine.
  - ratww 6y ago
    Great post, thanks for the correction.
- robocat 6y ago
  A submit button also takes you to a new page using a POST, and functionally if JavaScript is disabled then upvote/downvote would be acting as a submit button. There is some nuance to getting that right (forms). I think an <a></a> shouldn’t be used, because that is a GET action, which should be idempotent.
  - ratww 6y ago
    That's true, I agree that this is a better option.

SilasX 6y ago

Let me first say, this is a really great discussion that has forced me to think, and I'm upvoting both sides, including Deimorz and ratww. On one hand, if I expect buttons, and only buttons, to have some non-link in-page effect, then yes, those [-] things should be buttons. OTOH, as ratww, notes, the up/downvotes "are links", in a sense -- if JS is disabled, it just does the upvote with a page load, so functionally it's like a link and deserves <a> and not being a button. But by that logic, nothing deserves to be a button because you could replace it with a page load + the desired effect. So let's go with the "make it a button" implication. I tried wrapping the [-]s it <button> tags, and yeah, that gives the button styling, which doesn't fit with the HN general style -- I'd prefer it stay text. So I grudgingly (and tentatively) concede there are things that semantically should be buttons but whose default styling I'd still want to excise right out of them, forcing me into that dilemma I previously ridiculed. But is there still a way that I'm wrong about that concession?

ratww 6y ago
My objection is more about making a button looking like a link, as in the linked StackOverflow answer. I stand by my post that this is wrong because you're subverting user expectations and probably making life harder for everyone involved ("why am I tabbing to this, this is not a button... why can't I right click it... aaaaargh"). > But by that logic, nothing deserves to be a button because you could replace it with a page load + the desired effect. Not really. For instance, for the downvote/upvote buttons (or links?) here I actually agree with mwcampbell, they should be buttons. I don't think my other answers don't apply to them, because they don't look like links anyway. They could even be submit buttons inside forms to keep the site working when JS is disabled. And for the [-], couchand just suggested <details> and this is the correct answer for me now.
- SilasX 6y ago
  >My objection is more about making a button looking like a link, as in the linked StackOverflow answer. Oh, I agree on that point -- if it is legitimately a button, you should not make it look like a link. That's like you're trying to them into thinking the click will take them to a different page. (Among other problems.) It's just that the issue of handling the [-] collapse icon caused me to realize there could be a use under those constraints. >And for the [-], couchand just suggested <details> and this is the correct answer for me now. Ah, wasn't aware of that. That seems like a better approach.

couchand 6y ago

No, the proper semantic element is <details>, just let the browser render the expand/collapse control.

comex 6y ago

I’d say it already looks like a button. To me, [-] comes off as basically ASCII art for a box with a minus sign in it, similar to the classic Windows progressive disclosure controls: https://docs.microsoft.com/en-us/windows/win32/uxguide/images/progressive-disclosure-controls-image16.png https://docs.microsoft.com/en-us/windows/win32/uxguide/image... And a rectangular outline and/or background is of course the basic visual element that indicates a button. The ASCII art look works well here, but that’s because HN has an intentionally lo-fi aesthetic. On an average site I’d say it should be changed to a real box. Not a plain unstyled <button>, since (depending on the platform) those stand out too much for a relatively unimportant UI element. But I think a styled one would work. I don’t have enough HTML experience to know what the issues are with layout.