CSS animated loading indicators | Hacker News Reader

CSS animated loading indicators

tobiasahlin.com

327 pointshising70 comments

Are you telling me that CSS can now make nice animated wobbling circles but still can't center in a sane way?

(Nice work, btw, like the animations =)

I find centering in CSS pretty easy currently, what about it is troubling you? This resource (http://timseverien.nl/2013/10/css-alignment-and-sizing/) showcases a number of techniques.

This resource .. showcases a number of techniques.

That's kind of the point.. you should not need to have a page to showcase different techniques for something this basic.

I, for one, does not have to deal with this. But as and outsider it seems strange that simple things are so hard. Maybe web developers have gotten so used to dealing with things like this that they don't see how convoluted it is?

As a designer and client-side dev, I've been using CSS and HTML for about 9 years. A lot of the weird edge cases and nuances are second nature to me now. However, if you step back and look at it all, it's pretty goofy, but then again, so is English. But I'm going to keep using it, because there isn't anything else. At this point, I'm really good at it anyway and this stuff doesn't really bother me too much.

I see what you're saying and I agree it would be great to be simpler. My perspective is that the complexity is actually in the flexibility in CSS and the number of options provided to you. I'm not sure how I'd make it simpler without removing some of the control.

>My perspective is that the complexity is actually in the flexibility in CSS and the number of options provided to you

Not really, most of the complexity is of the ill-thought design they started with, and the LACK of options for certain things.

Initially the envisioned CSS as a styling technology, so layout was an afterthought. Even the messy floats hacks (those one that replaced tables) wasn't something that was though of specifically as a complete layout solution.

We had to wait 10+ years, to have actual layout solutions catering to the needs of web designers: Flexbox, Regions, Multi-Column layout and Grid Layout -- and of course those are still not implemented totally by browser vendors, give a few years wait for that too.

That's fair. Perhaps I'm too comfortable with the concepts I've been forced to learn thus far.

honest question, but what would the problem be with having "margin: auto" work vertically as it does horizontally?

EDIT: I mean, what freedom would have been lost when it was designed to work like this, not talking of changing it now.

What would you do with this case then?

  .outer {height: 1200px; width: 800px;}
  .inner {margin: auto;}

  <div class="outer">
    <p class="inner">This is centered vertically</p>
    <p>But where should this go?</p>
  </div>

And what if both p elements had the `inner` class?

>pretty easy currently

The use "currently" itself should set of a number of alarms in a sane person.

Then, to top it, you add: "showcases a number of techniques".

Centering should be an built-in, simple, capability. As simple as making some div red or adding a 2px border.

Not a "technique" or a "workaround" and surely not "many of them" (incompatible and each with different tradebacks).

You don't see "techniques" for making divs have a certain background color -- that's because there's a single instruction for that, and it bloody works all the time.

I find centering more complex because there's not just one type of centering. I think centering can differ based on fixed and fluid width, display type of element (inline, inline-block, block), and probably other factors. I can't think of a clear definition for how a single simple centering would work given all the possible variables at this point.

I agree with gizzlon. The inline-block versions are the closest things to actually saying "put this block in the middle". For a system that claims to be all about layout, it shouldn't be so obtuse to say "stick this, whatever this is, in the middle."

Also, auto-flowing text split between columns as a "column" property of some kind would be nice.

The list you provided is handy, but it shouldn't require knowing that you have to look up specific cases.

Split text between columns...

http://jsfiddle.net/BZuu9/

[edit: I appreciate the constructive example, should've mentioned that.]

Which unfortunately looks like crap, as there is no (standard) way to get browsers to hyphenate words in a sane way :-(

[edit: I wish CSS Regions was (or was likely to become) a viable solution, as it actually does what a lot of people want: a sane and standard way to lay out text, based on experiences from dtp. Sadly, afaik, it's unlikely to be accepted, and I'm not sure if there's even a decent way to get it to work with a polyfill (suitable for production):

http://dev.w3.org/csswg/css-regions/Overview.src.html

https://github.com/adobe-webplatform/css-regions-polyfill

In theory css-regions along with hyphenator or hypher should be enough to have layouts that are both semantic, look good, and are simple to implement. It's been a while since I tried to get it to actually work, and I don't remember it as "just working" (that would include proper pagination both on small screens and on print outs, without too much effort):

http://code.google.com/p/hyphenator/

https://github.com/bramstein/hypher

]

thanks, that is much appreciated.

> For a system that claims to be all about layout, it shouldn't be so obtuse to say "stick this, whatever this is, in the middle."

Ah, but unfortunately CSS isn't about layout at all. Hence proposals like css-regions (see comment below) -- which are about layout. It's a common mistake: We came to html (with our designer hats on), and thought: Oh, we can layout text with tables! We were wrong, and we got css -- and we thought: Oh, we can layout text with CSS -- but we were still wrong. We could do some minor (and as it turned out pretty major) styling with CSS -- but it was never really meant for layout. We do need a system for layout, and perhaps the most sane thing to do these days is to wrap CSS into a tool that does styling and layout. But CSS of today isn't quite there.

See: http://www.w3.org/TR/WD-css1-951117.html#abstract

"This document specifies level 1 of the Cascading Style Sheet machanism (CSS1). CSS1 is a simple style sheet language that allows authors and readers to influence the presentation of HTML documents. E.g., a publisher can suggest font families, colors and layout for a document, while the reader can ask for the document to be magnified. By attaching style to HTML elements, document structure and device-independence is preserved."

Over-eager use of emphasis mine. While it contains the word layout, it's set in the context of HTML documents -- and I think that was a mistake. Still it brought us forward from what things was like before the mid 90s!

There's an old phrase that the bad workman blames his tools and it seen to apply here too. It's really not difficult and why complain about it being obtuse? If you understand the fundamentals then it makes sense. As for the last sentence well the list he provided is only for people that need to look it up (like you) - that's like me saying to my car mechanic that I should have to look up where the fuses are in the car. If you don't know something you have to look it up (taking what? .4 seconds on google?) - if you knew it you'd obviously not have to look it up. Stop whining and learn this stuff.

That wasn't really necessary.

I'm glad you get to work in UI-world all day long that CSS' idiosyncrasies are something you can memorize inside and out. Personally, I'm required to know a lot more about mathematics and databases. My clients can deal with not-very-pretty UI, they can't deal with lost or incorrect data.

But if you want to make analogies about tools, one should always use the right tool for the job and not employ hacks. To me, "margin:auto" is a hack. It doesn't express that the object in question is being put in the middle of something else. It hides the intent of the action behind insider jargon. Or, to continue your analogy, it's using the handle of a screw driver to hammer in a nail.

>There's an old phrase that the bad workman blames his tools and it seen to apply here too.

Not all of us are "workmen" here, that have to get used to our tools, etc.

Some of us are actual scientists and engineers, with lots of experience in identifying broken APIs and tools. Some of us even PROGRAM the tools you get to use, from CSS implementations in browsers to editors and such. Heck, there are people on HN from Mozilla, Google, Apple and MS.

CSS, with regards to layout, has been broken from the start.

That's not up for debate just because someone has mastered all the intricasies. Even the original authors and the W3C agree and have taking corrective steps in later CSS versions (still not widely supported).

So "Stop whining and learn this stuff" is not really an answer in a technical debate.

Flex boxes?

http://jsfiddle.net/J88tz/

Here's the browser compatibility info: http://caniuse.com/css-animation

I often forget how late IE was to this party

IE?

(scnr)

Nice job. Is it a problem with the state of webdev that the thing I was most impressed by was that your website didn't break my back button? Seriously, good work.

Well, that's a nice feature, but as you bring it up, deep linking isn't possible ;-) There are various techniques to enable it though, pushState(), hash fragments etc.

Best would be a replaceState: would not break back button, would allow deep linking.

The thing I was most impressed by was the fact that the left and right cursor buttons worked straight off the bat :D

I believe it is a side-effect of the keyboard navigation. It appears to support the back button (due to the script listening for the arrow keys and disregarding the Alt-modifier) but only for those users who use the keyboard to navigate back-and-forth in history. If you observe carefully, the actual "back button" isn't activated (and hence useless).

These are really very nice, but they don't really convey any more information than a static picture of a puzzled kitten. Like "security theater," this is "progress theater" and I would prefer to give my users a more useful indication of progress. I do appreciate the work that went into these, and admire the skill.

>I would prefer to give my users a more useful indication of progress

Those are called "indeterminate progress indicators".

Not everything on the web has some specific state info or progress percentage to declare.

Just showing that "something is running" is still very useful for those situations, and can have a huge impact on the users perception of the page responsiveness.

(As has lots of other "theater", which is not to be dismissed -- e.g the mobile practice of showing a screenshots of the apps last state while you load it, making the user thing it loaded faster).

I agree that what you prefer would be ideal, however a lot of things that happen on the Web isn't conducive to a real "true current state of progress" loader. Actually, a lot of things that happen even on local machines are not possible to be determined in an absolute sense. That's why most progress bars seem to progress in fits and spurts, not in smooth consistent amount over time... I think this is due to some tasks just take an indeterminate amounts of time. In those cases, a progress bar isn't much better than a numbered list of things shown as "to do" and "done." In the case like client server request response, which may be asynchronous, where responses are only received when it's "done" then it makes sense why these cannot show progress... Just that it's "still waiting." Not ideal, but I can't see a better solution that doesn't require sending multiple updates back saying "still not really sure when we'll get to your request" or "just fetched stuff from the dB, 2 more tasks to do."

I've also created one

Windows 8 Loading with pure CSS3

http://codepen.io/surjithctly/details/Kfqak

Here is a little editing on one of the ones I like this better then the three in a row. .spinner { margin: 100px auto 0; width: 70px; text-align: center; }

.spinner > div { width: 22px; height: 18px; background-color: #333;

  border-radius: 100%;
  display: inline-block;
  -webkit-animation: bouncedelay 1.4s infinite ease-in-out;
  animation: bouncedelay 1.4s infinite ease-in-out;

}

.spinner .bounce1 { -webkit-animation-delay: -0.32s; animation-delay: -0.32s; }

.spinner .bounce2 { -webkit-animation-delay: -0.16s; animation-delay: -0.16s; }

@-webkit-keyframes bouncedelay { 0%, 80%, 100% { -webkit-transform: scale(0.0) } 40% { -webkit-transform: scale(1.0) } }

@keyframes bouncedelay { 0%, 80%, 100% { transform: scale(0.0) } 40% { transform: scale(1.0) } }

Unfortunately very CPU intense, compared to SVG-based indicators

Any numbers available?

looks like a problem with my chromium as firefox is almost idle when displaying the indicators. (30.0.1599.114 Developer Build 30.0.1599.114-0ubuntu0.12.04.3 x86_64)

I am on 31.0.1650.63-0ubuntu0.13.04.1~20131204.1, and it was ok here. CPU around 3-4% for most of them. One of them was 8%.

It works fine on Safari on my iPhone 4.

Nice work, especially "Wave" and "Circle" because they're more likely to be recognised as such. (Similar animations are already seen in the wild.)

Now we have brand new CSS and we do a subset of the cool things, we could do in SVG since ten years. I'm a bit confused.

Oh and it doesn't work in Opera 12 .

Feels a bit too flashy for me. That's just personal opinion though, it's still great work. Now work on cross browser support.

Very nice! Although I hope this won't be mainstream too soon as this uses 10% of my CPU (Firefox on Linux).

I believe all of them actually use more bandwidth then a gif, so why use this exactly?

I think you're mistaken. The first example is only ~700 bytes in size. Show me an animated GIF, with those dimensions, that many frames (to maintain that level of smoothness), for under 700 bytes?

(HTTP overheads are not factored since HTML + CSS is one less request than HTML + CSS + Image resource.)

CSS will normally also get zipped: you are comparing compressed gif to uncompressed css

Alpha channel support. Transparency in gifs is boolean, not a linear scale.

And easy to rescale, recolor, etc.

And this is main in favicon:

https://github.com/dawjan/Open_Me/tree/master/JQ%20busy%20in...

Sorry no preview

“Working only in Firefox”

This is pretty neat, also I was incredibly surprised when going through the code to see in how little number of lines he achieved that!

It's nice and well done, but now who would use this novelty idea in a real work? There are animated GIF or fonts SVG for that.

We're using something similar to this in our current project. We have a fallback to a classic animated gif if animations aren't supported. I'd guess we're not the only people doing this. Wrote it up here: http://icanmakethiswork.blogspot.co.uk/2013/04/a-navigation-...

Can't beat good progressive enhancement!

GIFs don’t do alpha. I’d probably use an SVG though for this.

Animated PNGs? (Or is IE support still a problem...?)

“Everything that’s not Firefox”-support is still a problem: http://caniuse.com/#feat=apng

I would. Certainly prefer CSS stuff compared to GIFs for this kind of stuff.

You might have more luck getting this to work than animating SVG files; which doesn't work in any IE version, and has issues in Safari and iOS Safari, and old versions of Android (Pre 3.0, but damn, they are everywhere).

I agree, it's really nice but it isn't even working in ie9. A .gif would fit the bill in the cross browser department

SVG animation can be chanky on a mobile device

As can CSS animations.

On a project that targeted tablets (iPads and Androids), we eventually went back to good ol' gifs because of how bad SVG and CSS animations rendered and performed.

indeed, here is a non-that-fancy loading indicator in SVG:

http://rendro.github.io/SVG-Spinner/

I too would use this.

Does anyone have a tutorial that shows how to implement a loading screen?

With Backbone.js: I usually just hide all views except for my "loadingView" (which is usually just a simple HTML element with a spinner/translucent background/etc.) while I'm retrieving data. When my data arrives, I hide the "loadingView" and display the data as usual. There are probably better approaches, but it works for my projects. Hope this helps.

The animation tears, and it needs antialiasing.

They don't seem to animate in Chrome 31.

They do for me in Chrome 31 on Windows 7.

Ugly aliasing in Firefox though.

Also works for me, Chrome 31, Linux.

Works for me. Chrome 31, Windows 7.

Reply on news.ycombinator.com