Building a Magical 3D Button with Vanilla HTML/CSS | Hacker News Reader

Building a Magical 3D Button with Vanilla HTML/CSS

joshwcomeau.com

136 pointsjoshwcomeau30 comments

I really like the look and feel of this button.

Flat design is a poison. It's an accessibility nightmare especially for older users. In a flat product, nothing and everything looks like a button, so nothing and everything looks clickable. Humans obviously use 3D spatial visual queues to process the world around us. Taking that away and removing references to real world items was something Jony Ive could have only poisoned the world with after Steve Jobs died. No hero worship for Jobs, but he led the way in understanding beautiful skeuomorphic design.

Apple has started introducing drop shadows and gradients and hinting at 3D elements, such as the new Messages icon on MacOS. The pendulum will swing back, not soon enough.

I would disagree. Flat design is not poison. It is simplicity. Simplicity, done well, leads to a good design.

Yes, there have to be visual cues to know that it is a button. There has to be contrast. There should be a hover state that changes the contrast/color when hovering over it. The shape can indicate that it is button.

While I love the technical accomplishment of the OP and think it is a great thought experiment, I wouldn't want this arcade-button everywhere.

I believe skeuomorphic design, when overused makes a website harder to mentally process.

If this were the sole button consistently used on a web app, and the 3D button fit with the website's design, then maybe it would be good.

However, I would hate for a generation of HN users to see this post and think they should regress to designs reminiscent of 1998/2007.

One problem, I think, is that touchscreens (generally) have no "hover" state. So an important mode of feedback is being lost.

There are alternatives, like the Material design ripple or haptic feedback, which at least let you know you're touching it. But it's different than being able to get a visual cue about what's touchable.

It's a tough compromise. We want to take advantages of all the dimensions we have to communicate, but we don't want to lose devices that don't have them. And as much as possible we'd like consistency.

That's a good point. Touch screens don't have that "hover" indicator.

I'm still not sure 3D is the answer... but you bring up a good conundrum.

Jony just parroted what Microsoft had been doing a couple years prior. We can once again blame Redmond for awfulness that somehow the rest of the industry found very endearing. I'll never understand why.

Why does copying awfulness instead of coming up with it absolve him of blame?

I am not a fan over super flatness and hence I appreciate a fake-3D button.

But in the same way that many great computer games ALSO don't try for ultra-realism, I don't think it needs to model the real world as much as it does.

Things I'd do without:

- rising on hover. Colour change is enough acknowledgement.

- shadow. Having the two coloured layers is enough.

- spring-like overshoot behaviour. Simple down+up is fine.

But it is always cool to see a nicely written "I want to achieve this; this is how" article. +1 to author.

Despite the visual appeal, the jiggle hover and push effect of the button significantly reduces my confidence and satisfaction when pushing the button.

To have confidence, I'd want a locked/disabled state, while whatever action is processing. The jiggle gives me an uneasy/broken feeling, as a button, even though it is very satisfying as a whimsical object.

It reminds me of the hockey puck buttons that you record a sound on, and how if you press it too quickly, the sound can't keep up, and it feels janky.

Hopefully this isn't too negative, because the tutorial was very readable, informative, and engaging, even for a css novice who had no intention of studying css today.

Didn't work consistently on Firefox on Android. It would miss taps, sometimes it would get stuck "down".

> Why not use box-shadow or border? Those properties are super expensive to animate. If we want a buttery-smooth transition on the button, we'll have way more success with this strategy.

Border I can understand, because it affects layout (though if you make balanced changes to top/bottom widths, admittedly a bit harder than it may seem at first if you use an easing curve, it would be possible for the engine to recognise it and skip layout, though I have no idea if they do).

But box-shadow? Huh? Why would that be expensive to animate (let alone super expensive)? It doesn’t affect layout, it’s just painting.

Now admittedly my perspective on this sort of thing has been skewed by using Firefox, where WebRender completely throws out the old performance guidelines (and box-shadow is certainly not expensive to animate, and the multiple-element version will certainly be a negligible smidgeon less efficient), but I thought and would expect that even in the old inferior rendering world that all the other browsers inhabit box-shadow is not expensive to animate provided you’ve used the standard hacks to GPU-accelerate the element’s rendering.

Certainly I’ve never observed any smoothness issues on animations of box-shadow.

I’m interested in whether I’ve forgotten something here, or whether Josh really is overstepping in his description.

Josh the web developer has probably experienced slow down animating shadows, whereas you're just guessing.

Maybe give the author the benefit of the doubt, or make an example disproving his theory. There are plenty of css performance gotcha's you wouldnt expect. Changing gradient backgrounds on body (or a big div, I forget) everyframe is fine, but changing it on html (for ios safari's outside-the-body app colours) is horrendously slow and actually causes visible tearing when animating. We could just assume theyre "the same", but with experience, you find they are not.

You should add "user-select: none;" so it looks better on touch devices without the blue selection box.

Breaking accessibility for looks is the cardinal sin of web development. The two are not exclusive and often it's actually less work to make things accessible — simply don't break the built in functionality. It's a widespread issue and mostly I'd put the onus on bad education: to this day, many big libraries have very poor accessibility both in their code examples and their components. The true measure of a website's user interface is not whether it's pretty, it's whether it's usable, by everyone.

As an alternative, you can make a custom focus style so that it is accessible but also pretty.

Touch screen tap works, but laptop track pad 'tap' does not count as a click on the button.

I like the button except it flickers when I press it and I accidentally selected the buttons text which just completely kills my vibe.

Selectable text is one of the best parts of the Web. But a whole lot more UI elements could be made unselectable by default.

Your lego guy that pops out asking to share something you've been working on is a bit annoying - I'm already half way through reading one article.

OK, I'm not now, I got distracted to come here and comment.

That evil little fecker just creeped the hell out of me.

I for sure could not stop clicking! :)

So satisfying! :)

It'd be nice to see an example of the button being a hyperlink to see if I could right click and open in new window or use mouse gestures with it. I tried just putting a <a href=""></a> within the class="FinalButton__Contents-shq40f-3 eFOYWi span and the link was non-functional in all GUI browsers I tried. Why bother not making it from JS when you have to use JS to actually use the button?

This button also does not render at all in browsers older than a handful of years. This might be good for a fun, hip project or something commercial where the customer base is small and well characterized. But if it's a site you where expect all kinds of people from all walks of life this isn't going to cover it.

The next step should be to implement it in a way that falls back safely so the function is always accessible even if the fancy animation isn't.

It does work. The following markup rendered a button that as also a standard anchor tag:

  <a class="pushable" href="//google.com">
    <span class="front">
      Push me
    </span>
  </a>

Gorgeous. The button and the explanation.

I don't know why, but it feels a bit uncanny for my eyes, felt off but don't know what it is.

Now that is a beautifully designed website.

> Why not use box-shadow or border? Those properties are super expensive to animate.

The web is the main obstacle to having nice things on the web.

This is a tradeoff that must be made in every place where technology meets aesthetics, not just the web - I'm an artist who mostly uses Adobe Illustrator, and every new way I think of to use it must be evaluated on the often-orthagonal axes of "how good does it look" and "how much does it slow down AI".

> This is a tradeoff that must be made in every place where technology meets aesthetics

In the case of HTML+CSS this is the direct result of the underlying tech: almost everything triggers a re-paint or resize+repaint, https://csstriggers.com/

Scott Forstall, is this really you? :-) [1]

[1] https://en.wikipedia.org/wiki/Skeuomorph

Reply on news.ycombinator.com