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.
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.
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.
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 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.
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.
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]
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.
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.
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 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 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.
Very handy tool. Might I suggest indexing some values too. Searching for gradient returns nothing, but a suggestion for background-image might make sense.
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
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?
I agree it's a good idea that's long overdue, but I started at the first page and the descriptions don't make sense in combination with the illustration.
For example, the first illustration has five numbered boxes, but there are no references to them in the descriptive text. And the description says they'll "stretch," but does that mean horizontally AND vertically?
Then the next one says, "Each line will only fill the space it needs. They will all move towards the start of the flexbox container's cross axis."
What is "the start of the flexbox container's cross axis?" None of those three things is identified in the illustration: the start, the flexbox container, or the "cross axis."
If that's the quality of all the descriptions and illustrations, I'm afraid this is a disappointing implementation of a good idea.
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?
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.
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).
Only the first few properties are flexbox related (alphabetical order). Keep scrolling through the property list and you'll find the non-flexbox properties.
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.
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.
133 comments
[ 2.6 ms ] story [ 172 ms ] threadNo it shouldn't. Split up large chunks if it impacts performance.
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.
The problem with this site is not that it has too much context. Just too much new and crazy styles.
Very lazy on the part of the developer to code it that way.
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.
Thanks for the report. Hopefully the author will almost fix it.
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.
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.
http://imgur.com/a/GiGBY
I took that image from a non-laptop desktop machine, by the way.
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.
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/
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.
* 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...
Thanks. It appears that this wasn't the case for make.
That really sucks.
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).
If you don't like sub-threads I suggest you get an HN-reader than can collapse comments.
But for actual coding people would still Google for css-tricks or stackoverflow because Googling is faster than opening this website and searching.
Changes daily. More work to keep that accurate than to make the page in the first place :(
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.
* 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/
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).
For example, the first illustration has five numbered boxes, but there are no references to them in the descriptive text. And the description says they'll "stretch," but does that mean horizontally AND vertically?
Then the next one says, "Each line will only fill the space it needs. They will all move towards the start of the flexbox container's cross axis."
What is "the start of the flexbox container's cross axis?" None of those three things is identified in the illustration: the start, the flexbox container, or the "cross axis."
If that's the quality of all the descriptions and illustrations, I'm afraid this is a disappointing implementation of a good idea.
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.
PS. Note to everyone - whitelist this in your ad blocker as author asks you to do!
- https://css-tricks.com/almanac/ - http://tympanus.net/codrops/css_reference/
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...
Minor bug (?): your lorem ipsum is showing when viewing via http://hn.premii.com/
[0] http://caniuse.com/#search=flexbox
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.
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.
(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.)
However, that particular site is Australian, where Chrome makes up ~50% of traffic.
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.
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/
For me CSS has been largely very unintuitive, and part of that has been because of the adversarial evolutionary race of browsers.