3 ms·

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 e

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

by SilasX 6y ago

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.