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.
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?
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.
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.
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).
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.
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.
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]
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.
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).
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.
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.
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.
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.
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.
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?
* 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]
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.
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.
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.
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.
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.
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.
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
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.
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.
Very handy tool. Might I suggest indexing some values too. Searching for gradient returns nothing, but a suggestion for background-image might make sense.
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.