Hacker News new | comments | show | ask | jobs | submit login
Show HN: A visual guide to the most popular CSS properties (cssreference.io)
1117 points by bbx 154 days ago | hide | past | web | 122 comments | favorite



This is a great little site.

A) How has the web been around for this long and nobody has done this before, i.e. there isn't at least some kind of authoritative reference like this?

B) Having worked with many UI/layout paradigms, and full aware of the fact that none of them are very good - css is indeed perhaps the worst. It takes quite a lot of abstraction on top of it to make sense of it.

But it's what we have - so good work.


Regarding point A, here are a few sites that come off the top of my head :

* Index of CSS Properties by W3C https://www.w3.org/Style/CSS/all-properties.en.html

* CSS Reference by Mozilla Developer Network https://developer.mozilla.org/en/docs/Web/CSS/Reference

* CSS Reference by Tympanus http://tympanus.net/codrops/css_reference/

* CSS Almanac by CSS-Tricks https://css-tricks.com/almanac/


Yes - those list a bunch of values - but they don't help that much in terms of actual documentation. They list nothing but the values.

Even MDN, which is probably the closest thing to 'standard' has very few examples, missing definitions, nothing interactive.

W3C is only really the basic stuff.

Let's face it: the tool we all use for showing our stuff to the world basically has no documentation. It's a mess.

The Mac/Safari documentation is literally blank for tons of objects. I mean - $100B billion in the bank and they can't make docs. Even swift documentation is totally lacking in examples and hard to read (they're still depending on your ability to read Objective-C stuff).


To your last point, making developers lives easier does not move their bottom line is my assumption. If they improve docs it isn't going to sell one single extra Mac, so why should they bother?


http://www.blooberry.com/indexdot/css/propindex/all.htm has been around since the beginning


There are references already but they are often really dry.


Please include the link to github ( https://github.com/jgthms/css-reference ) for everyone to edit and write issues.

Would be particularly nice to have a direct link to edit every particular property on its section, e. g. https://github.com/jgthms/css-reference/edit/master/property...


Really nice. I think it would be more helpful if the properties were ordered in a logical order (by "type" of properties) instead of alphabetical order.


From the title, I thought this would be a list of CSS properties ordered by frequency of use (as crawled on the web).


I thought so too, but looking at chrome css usage stats, flexible stuff is really low on the list. Its rising fast, but currently unused on the majority of the web.


Second this. Will be using this in the future, and some kind of categorisation would improve usability.


I disagree, I think it's much easier to search for a property by name. It's really hard to objectively categories every property, one person would put one property in one type another one would not. Sorting it alphabetically helps all users to find the property


But a user who was searching for a property with a particular name would presumably use Ctr-f/Cmd-f to search, rather than scrolling through the whole list to find it.


I agree with this viewpoint. Additionally, even if the categorization is to some degree arbitrary, at least it beats alphabetical order which ends up being the most arbitrary (well other than just rolling the dice).


I agree, or maybe make a toggle to switch between the two ways of ordering.


Quick question: this refers heavily to Flexbox, which as someone who has only a tangental interest in CSS, I don't know much about. Is it the standard way of doing positioning now? Care to explain it like I'm 5?


Flexbox is conceptually more difficult than older float & grid based layout systems (it takes some time to wrap your head around the relationship between `display: flex` containers and the various flex-* properties that child elements utilize), but it makes certain things dead simple that were nearly impossible before. For example, vertically centering content (almost comically difficult before flexbox) and fixed-width elements mixed with expanding elements that will share unused space in a row. In a lot of ways flexbox acts like old-school table layouts--which were easy to use and predictable--but without the ugly, non-semantic, and verbose markup. Best of both worlds really.

They are supported in all self-updating browsers, so unless you have to support IE<=10 they are safe to use and extremely convenient. Replacing a classic grid-based layout with flexbox saves an astonishing amount of markup. I've been using it exclusively for the last six months or so.

I found this CSSTricks article helpful when I was building my first flexbox layouts: https://css-tricks.com/snippets/css/a-guide-to-flexbox/


Thanks for the info. I did some simple CSS/HTML work a long time ago and never heard of flexbox (and it's everywhere on this page)


+1 for linking to Complete Guide to Flexbox. This guide is really great!


ooh, mixing fixed-width with expanding elements is exactly the thing i'm struggling with now. i'll look into converting from grid to flex based layout and see how that goes.


You can also use calc(100% - [fixed container width]px) in a pinch.


Thanks so much, this makes sense!


It can be easier than other ways of positioning in CSS, but you may need to be careful on relying on it, depending on your target audience, and what browsers they use. [0]

[0] http://caniuse.com/#search=flexbox


I think you're right on both counts. After getting the hang of it, flexbox is pretty straightforward to use, IMO less confusing and touchy than floats, especially for responsive layouts.

Most browsers are OK these days, but IE/Edge is where I've encountered the most problems with compatability. There are ways to work around it, but that takes a bit of additional effort. CSS tools, e.g., Autoprefix are useful.


Absolutely, flexbox is great.

My comment with browsers, is more about knowing your audience. Most of the evergreen browsers do support flexbox but...

Well, I maintain a website for a company.

97.3% of visitors, are return visitors.

69.77% of the visitors are using a version of Internet Explorer.

69.03% of the visitors are using Internet Explorer 7.0.

I have no hope of getting to use flexbox to simplify managing the website, which makes me very sad.


I would try communicating to my manager that maintaining IE 7 support is costly for you. When you work on some IE-7-specific issue, log your time, and show them an actual rundown. Maybe that will tilt the cost-benefit analysis far enough to push them into upgrading their default browser.

(By the way, I'm sympathetic with you. When I deployed a big feature in an intranet web application in 2012, it broke for dozens of users, and it took me days to track down the misplaced comma that broke the neck of the IE 7 JS parser.)


More than 69% of our regular users are on IE7, we just can't afford to drop that. (They do in fact get a pop up telling them to upgrade, but that had no noticeable affect on traffic).


He said it's an internal application IIRC, so someone in the company is responsible for that.


What country are you in? That is an alarming rate of ie7 traffic


Not sure country counts at all when looking at this stuff, because individual sites very rarely reflect national trends.

However, that particular site is Australian, where Chrome makes up ~50% of traffic.


Flexbox is really worth trying. It is a much more natural way to layout responsive components imo, and is great for layout design in particular.

However, that said, the majority of components I build are still not in flexbox. It's a useful tool in the toolset, but not sure I'd call it the new default yet.


Only the first few properties are flexbox related (alphabetical order). Keep scrolling through the property list and you'll find the non-flexbox properties.


All of the other positioning systems are still completely valid, it's just that some people (myself included) find it easier to center things horizontal + vertical and distribute items on the page.


Great clean guide. Here's a couple more that often offer extra tidbits of certain properties.

- https://css-tricks.com/almanac/ - http://tympanus.net/codrops/css_reference/


Am I the only one whose computer has trouble running the site? Using a xps 13 from 2015 and it is really sluggish. Breaking it down into sub-pages would help.


Yup, scrolling is a little bit sluggish. All sections with properties are loaded at one. Quick solution would be to break down into sub-pages as you said or use pagination.

For those from React world, there is really awesome component, for rendering large sets of data: https://github.com/bvaughn/react-virtualized.


For those not in the react world, this seems to similar to react-virtualized and has worked great for me before: https://clusterize.js.org/


I'm on an xps 13 2016 and it runs just fine. Guess you just have to upgrade. /s


I would expect a site about CSS properties to also know about the performance impacts of paints... Takes a good 5s for everything to load.


I don't get this complaint. This site is aimed at developers. I think it's safe to assume they're either not viewing this on mobile ever, or are going to come back and visit on desktop/etc if they actually want to use it as a resource for work, so perf is a low priority compared to the content.


I'm not viewing the website on mobile, and nor did the people I shared it with, but we all were surprised at the slowness. Of course, as you mention, the quality of the content is enough to cover over the performance issues, but it most certainly detracts from the website.


Fine, that wasn't the spirit of the original comment I replied to though, which was needlessly negative and lacked any awareness of context.


I'm a developer and I just read this whole site on mobile to see if there's anything I don't know. Initial load was clunky, fonts have initially not been showing up but after that it works pretty well on mobile.


Yep wasn't suggesting it wouldn't work fine on mobile, just addressing the 'perf' criticism which to me, isn't really relevant to most devs when they would tend to use that resource on their dev machines.


I nearly closed it when it it loaded this bad and I saw the fonts missing. But scrolled a bit and fonts showed up. So 'perf' criticism is valid because it's so bad on this site that it affected usability for me.


But you didn't close it? So you're not even one negative datapoint. I don't think any rational dev would close a useful developer resource based on perf reasons.

Again, I'm merely replying to the initial comment which was needlessly negative and frankly a tiring trope on HN (rudely criticising something unimportant about the site regardless of its intended use).


Honestly, your going on about it is worse. Sometimes a negative comment just comes out badly. It happens. And even then, taken in good faith, at least it's somewhat constructive. This whole sub-thread of you arguing against people doing exactly that, is off-topic good for nothing ballast. That is a tiring and persistent HN-trope I can really do without.


Just answered each comment as it came, trying to defend a good submission against nonsensical snark.

If you don't like sub-threads I suggest you get an HN-reader than can collapse comments.


Developers don't use mobile? Or tablets? Or...performance?

http://imgur.com/a/GiGBY


That's not what I said.


It's not your exact words, but I don't think it's an unfair characterization, if the excuse is simply that they'll be reading it on a desktop machine anyway.

I took that image from a non-laptop desktop machine, by the way.


> It's not your exact words, but I don't think it's an unfair characterization

You ignored the half of the sentence following the 'or'. To me, that's unfair.

> if the excuse is [...]

It's not an excuse, it's context.

The performance is a low priority compared to the content, when the site is a developer resource.


And for me it speaks to credibility.


As another random anecdote from another random developer, I find the site's content far outshines any purported credibility loss - which just seems like a very silly argument to make.


Perf is not important for a dev resource. If a dev had spent a ton of time optimising that they'd have wasted their time. Why does wasting their time make them more credible?


I disagree.

In many places, perf is still important, and one of the reasons, I believe, that GNU offers its manuals in various formats: [0]

I know of a few devs that work for web, but due to their nations economics, work:

* On a smartphone

* Via a satellite connection

Despite being in a first world country, I've had to do both at various times whilst working from remote areas.

The GNU manuals have a huge wealth of information, but they load fast by following simple-first policies.

caniuse.com is a SPA, but they load damn fast.

I'm not saying that this page is insanely slow, but that it is slow at all is still a surprise.

And not every dev in the world gets to have broadband.

[0] http://www.gnu.org/software/libc/manual/


> The GNU manuals have a huge wealth of information, but they load fast by following simple-first policies.

Do all GNU projects keep there documentation i one big file? I wanted to contribute some recently but got lost in a complex help file.


Most GNU manuals I've seen come as:

* HTML - entirely on one web page.

* HTML - one web page per node.

* HTML compressed (gzipped tar file) - with one web page per node.

* Info document (gzipped tar file).

* ASCII text compressed (gzipped).

* TeX dvi file (gzipped).

* PDF file.

* Texinfo source (gzipped tar file).

If the one big file (great for grepping) was too confusing, you probably want to opt for HTML, with one file per node. For example, the Sockets/Local Namespace page for glibc: [0]

[0] http://www.gnu.org/software/libc/manual/html_node/Local-Name...

Edit:

And it appears the help files are seperate inside the source code as well. [1]

[1] https://sourceware.org/git/?p=glibc.git;a=tree;f=manual;h=71...


> And it appears the help files are seperate inside the source code as well.

Thanks. It appears that this wasn't the case for make.


Ow. Make's manual is a 10,000 line texi file.

That really sucks.


How would they fix that? It's rendering all the examples on one page (like it should) so I understand it takes a long time.


Well they could have a list of the properties without them all rendered and then render just the property they need when someone clicks on the property name.

And why should it render all examples on one page?

They could have a static page for every property so one could link to http://cssreference.io/align-content instead of http://cssreference.io/#align-content and get just that static page. That should be pretty quick, especially with long caching of all other resources than the actual page content.

There's lots of different ways to have done it without having to do it all at once.


I personally don't like that solution. I want to see everything (on one page) without having to click anything.


How about both?


Then someone would have complained that this site needed JavaScript to handle those click event.

Or, would have complained that it was stupid to actually use an anchor tag to link to god forbid another complete page load.

Or, if they used a javascript framework to make deep links someone would have complained that they used a javascript framework for a static page, or even maybe they used the wrong JavaScript framework.


> like it should

No it shouldn't. Split up large chunks if it impacts performance.


I think it's much better UX to show everything on one page in this case. You're speaking like this is an application, completely disregarding the purpose.


I agree that it is fine for a reference site. Though, Virtual elements are possibly a solution where only the current viewport is painted.


The best solution would be to lazy load. If you can only see the first 3 property on page load, there is no gain in having them all load at the same time.


No it wouldn't, because this means additional delays for anyone that is actually using the site.


Lazy loading done well is invisible for the user. You preload things as users scroll down and when user hover / click on one of the anchors.


That doesn't work for those ctrl+f'ing for a specific property.

I'd probably do a full load for the text, with specifying the height for the examples inline, and then lazy-render the examples once they're visible.


You could have all content just unstyled (apart from sections heights) and enable the style for each section as it comes into view.

The problem with this site is not that it has too much context. Just too much new and crazy styles.


You would still need all the text to be in the markup for SEO purposes anyway.


Like how wikipedia does it? Full content but mostly collapsed.


The page almost crashed my browser and made me not want to use it.

Very lazy on the part of the developer to code it that way.


The page almost crashed my browser

Thanks for the report. Hopefully the author will almost fix it.


My chrome was unresponsive but recovered.


How would you do it and still view all the properties on one page?


Disable all the styles. Enable the styles just for the sections that are currently visible.

It would require setting section heights to fixed values so you can know which section is visible and enable and disable styles for them without changing the sites height.


I wouldn't have the properties on one page.


Then it's more a matter of taste than laziness. I very much prefer to have them all on a single page.


Except that it loads slowly which hurts the usability so it's not really that I prefer a certain layout but more that I prefer the page to load easily.


Scrolling is giving me ~20fps on my MBP...ouch.


And yet on the native browser on my (underspecced) Jolla phone, scrolling is beautifully smooth...


Really - it's fine here on this old iMac running updated Safari


Very useful.

You should consider serving a separate page for each property in addition to one big list. This would be more useful for quick Google lookups.


Nicely put together. I like the examples showing the effect of different properties.


Very nice - wish list items: adding css version numbers and browser compatibility.


In the corner of each there's an MDN link which has that info, though having it inline would be neat too. Also maybe a link to www.caniuse.com



Doiuse is a great PostCSS plugin that check if your css is compatible with the browsers you aim to support using caniuse. https://github.com/anandthakker/doiuse


"adding css version numbers and browser compatibility."

Changes daily. More work to keep that accurate than to make the page in the first place :(


Very nice CSS Visual Guide.

My other wish to really really learn CSS.... A list of CSS problems to solve ala project Euler. You get a visual example and you have to make it look identical. Then you get to see other solutions for the same problem.


I find layout to be the hardest part of CSS (as it deals with how elements interact).

This online book was helpful for me: http://book.mixu.net/css/


I think this is a good guide for brushing up css knowledge before interviews.

But for actual coding people would still Google for css-tricks or stackoverflow because Googling is faster than opening this website and searching.


Not as fast as asking random people on Youtube for help


I've put together a PR for lazy-displaying the property examples. This should help with the rendering speed. https://github.com/jgthms/css-reference/pull/10

Ace work on the site!


I've nothing more to say, other than that this is a lovely app. I'll certainly use it. Thanks.


This is an excellent resource ,, thanks for taking the time to make it.

I would request/suggest an option to have one-per-page display of attributes - currently there's a lot of scrolling if you want to move between things.


Small bug: http://cssreference.io/#animation-fill-mode does not play the animation the second time you click the button.

Great site though.


Same with animation-timing-function. It also doesn't fit on my screen, so it's hard to see what the ones on the bottom do.


Interesting app. Something I'll definitely use in the future for referencing


Handy, must have taken a while to put this together.

Minor bug (?): your lorem ipsum is showing when viewing via http://hn.premii.com/


As someone who does frontend only occasionally I expect this site to be of great help to refresh my knowledge now and then.

PS. Note to everyone - whitelist this in your ad blocker as author asks you to do!


Very handy tool. Might I suggest indexing some values too. Searching for gradient returns nothing, but a suggestion for background-image might make sense.


Flexbox is it supported by all major browsers?

How does it compare to table HTML vs. div HTML?

What are the benefits vs. div HTML & Bootstrap .. is it just the new thing to learn?


caniuse [0] has some stats.

Flexbox is supported in:

* Internet Explorer 11, but only partially

* Edge 14+

* Firefox 52+ (Everything but buttons in Firefox 50)

* Chrome 51+ (50 had it, but had a bug that still plagues Safari)

* Safari 9.1 (but Safari has a couple huge bugs [1][2])

* Opera 41+

* Safari iOS 9.3+ (but see [1] & [2])

* Every version of Opera mini

* Android Browser 4.4+

* Android Chrome 53+

A great bullet-point list of why not to use tables for layout can be found here [3].

Flexbox is designed to enhance and make easier some of the CSS that we already use today, so they go hand in hand.

As to Bootstrap, as of v4, it will include Flexbox as an opt-in option (in case you support old browsers where it wouldn't work). [4]

[0] http://caniuse.com/#search=flexbox

[1] https://bugs.webkit.org/show_bug.cgi?id=136041

[2] https://bugs.webkit.org/show_bug.cgi?id=137730

[3] http://phrogz.net/css/WhyTablesAreBadForLayout.html

[4] http://v4-alpha.getbootstrap.com/getting-started/flexbox/


This is fantastic.

For me CSS has been largely very unintuitive, and part of that has been because of the adversarial evolutionary race of browsers.


This is going to be super helpful - thanks!!


Wow that's so useful. Thanks for this.


It's a really nice app, I'm learning front-end so this will definitely help me.


A link to the relevant caniuse.com page in each section would be fantastic


A codepen that goes along with every example would be cherry on top.


The example is very helpful for me, brilliant works!


So useful, great stuff again after Bulma & marksheet.


The search feature doesn't work sometimes.


Whoa. That is awesome. Thanks for the hard work!


“Play animation” doesn't work in Safari


Definitely a nice site. However, I'd argue that if CSS was in any way intuitively designed, this site wouldn't be necessary.


very useful... thanks!


Very nice. Can you make a visual guide for CSS selectors too?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: