We generally don't remember how bad the internet search was before Google came along, but it was really, really bad. I have zero evidence but I'm pretty sure that some time ago some industry heavyweights asked themselves "Why the search in the apps works fine but the internet search is broken? Is it because the apps have the intimate knowledge of the structure of their data and the search engines don't? Shouldn't we convey to them that structure?". Thus the idea of the Semantic Web was born, using tables for layout became cardinal sin and we entered the long Dark Age of trying to wrestle floats into doing something they never could really do. Then along came Google and made it all obsolete, but the priests of Semantic Web had too much fun torturing mere mortals that they stretched the Dark Age up until the adoption of the Grid Layout.
When I hear someone saying that tables are for data and should not be used for layout I want to punch them. Yes, I've been that bitter for two decades.
Haha, ya, in the end, tables are still the simplest to reason about when it comes to layout! I kept using them long past when we weren't supposed to since the whole float thing was a mess and compatibility was still a big issue.
While it's a ton of markup, tables are build upon a few easy-to-remember concepts and you can do anything (including vertically align without googling!). I'm still constantly looking up flex and grid rules.
Right, I’m not arguing for using it, I’m pointing out that easy vertical alignment has existed in some form since the 90s, so why did it take so long for a semantic version to make it into CSS? (ie, not the display:table version in the sibling comment)
Like, before the best way to do it in CSS was the change the display type of an element to a “table cell” even if it’s not a part of a table. I mean, changing it to “flex” or “grid” doesn’t make much sense either, really, I rather just have a box with vertically aligned content. I dunno, am I using the word semantic wrong?
OK I agree it was not intuitive to change the display-type to table-cell just in order to vertically center content. It basically mirrored how you would would vertically center in presentational HTML, except you didn't need to misuse the semantics of the table element (which is why I was initially confused by your comment about semantics.)
The flex-box approach is the most intuitive in my opinion. The flex display-type basically means you want to distribute the area of a box among its immediate child elements, and control how the children and aligned relative to the container and each other. Centering is naturally part of this.
Using grid is IMHO less intuitive, since a grid with a single cell seem just as much a hack as a table with a single cell.
this is my first time seeing the `place-items` property. at first glance I have no idea how it relates to `align-items` or `justify-content`. Feels like the grid API is getting a bit too cumbersome but maybe its just me.
I am a backend engineer, but I need to do work on UI for my personal project. This guide from Rachel Andrew on CSS grid and flexbox is superb. She will take you from a n00b to a total Grid Ninja.
But yeah, the discoverability or suggestion-to-refactor-something-to-shorthand is typically non-existent in CSS. Lists like these are really the only way I discover CSS stuff.
May I suggest trying out webstorm or any other JetBrains IDE?
They have the best CSS completion I’ve ever seen, and it includes live (and cached) mdn documentation for each rule. It also suggests shorthand collapses as a feature
place-items is just a shorthand property that takes 2 arguments. The first argument sets the align-items value and the second argument sets the justify-content value. If only one argument is provided (as in this example), it sets both align-items and justify-content to that value.
or you could just use flexbox to do the exact same thing and have a superset of that extremely broad support, including ie11 without having to rely on any kind of magic.
I do use grid when I need it, but I don't see the point of using grid in places where flexbox will do. Granted this is on the verge of not mattering at all anymore, but I just don't see the point in using something less compatible when you don't have to.
I want to learn grid, and I keep waiting to be given a layout I can't implement in flexbox as an excuse. It's been years of waiting through multiple jobs.
I like grid because it eliminates the need for any elements that
exist purely for layout. This makes markup cleaner which makes it easier to change in the future.
But as I stated in elsewhere in this thread, grid is not a replacement for flexbox. There is overlap, they both have their strengths.
the one thing i couldn't do with flexbox where I had to use grid was a sidebar that was being rearranged responsively, part of it below the main content, and part of it above. but yeah, most of the time flexbox + order can get you quite far
I have not found this to be true at all. It's far less than 99%, and would require double checking all your work in IE11 to make sure it works. I tried some basic layouts and found that a lot of unexpected things occurred. If you're supporting IE11, CSS grid isn't worth it.
IE compatibility is increasingly rare. Grid is supported by 95% of all browsers globally. If your target group is any narrower, or if centering the content doesn’t break the page and you aren’t shy of serving a weird looking layout to people with old browsers, there is no reason not to use grid.
Grid is not a replacement for Flexbox, it compliments it. Flexbox excels when you are only concerned with one dimension, grid excels when you're concerned with two (ie, a grid!) And yes, there is overlap.
They have many overlapping capabilities, but there are things flexbox can do which grid cannot. For instance, flexbox can wrap with dynamically sized children.
In general: Flex is for flowing content, grid is for structured. You can do some awesome wrapping with flex that is impossible with grid. Also `margin-inline-start: auto` is pretty rad using flex, although you can do something similar with `justify-self` with grid.
A good use case for flex would be a list of tags, that need to wrap.
Quote from that SO post: "This is not a Safari bug. It's just a different interpretation of the spec.
When dealing with percentage heights, some browsers (like Safari) adhere to the traditional interpretation of the spec, which requires a defined height on the parent.
In other words, a percentage height on an in-flow element will be recognized only when the parent has a defined height.
Some browsers, such as Chrome and Firefox, have moved past this interpretation and now accept flex and grid heights as an adequate parent reference for a child with a percentage height.
But Safari is stuck in the past. This doesn't mean it's wrong, invalid or a bug."
Just worth noting, as I had a lot of fun with that one.
I'd argue that `place-content: center` is better than `place-items: center` as it would handle multiple child elements in a way most people would expect from a simple centering snippet.
place-content will position all the children to the center, which is generally what's desired here.
place-items, would make each child element center itself within its own grid square
I'd love to see a "Can-I-use" browser extension when looking at articles like this.
I agree, though what I would find really helpful is not just can-i-use but should-i-use, taking into account not only feature availability but also quality of implementation. Even if a feature is theoretically supported in all major browsers, it’s not much use for a production site or app if what you actually see on screen in at least one of those browsers looks terrible, for example because of bad anti-aliasing or colour handling or animation calculations. I’ve been building new UI/design systems from scratch for a couple of projects recently, and it’s amazing how often that still happens, even with popular CSS features used to implement relatively simple effects.
caniuse.com reports whether something is too buggy to the point of being unusable in a different color, and has footnotes for whether something has some quirks/caveats but is otherwise usable
That’s true up to a point, but caniuse and I sometimes have different interpretations of what is too buggy to be usable. Rasterising vector formats and working with colour seem to be two common triggers for poor rendering, with extra chances for visible glitches if they are used in combination and a bonus if animation is involved as well.
What's everyone's opinion on simply forcing users of IE11 to upgrade / use a different browser?
I understand that one should aim for a certain level of backward compatibility, but when does the time come to drop IE11 support for good?
Especially as a smaller webdev-shop, how would one even come up with the resources to maintain that level of compatibility? Eventually there is a trade-off where one may end up losing a (hopefully reasonably small) percentage of customers in exchange for focusing on the experience of those customers who are more up to date, but it's a tricky decision to make.
IMHO totally depends on what you are doing and who your users are. Generally going for graceful degradation should keep a lot of stuff usable for outdated browsers, even if not full fidelity/pretty, and that often should be enough. If you have lots of IE11 users for whatever reason (i.e. I believe in some countries rates are a lot higher) it might be worth the effort to make it better for them. If you ship an internal app for a company that rolls out a newer standard browser everywhere, target that.
Basically none of this supports IE 10/11 (flexbox one works, calc works, and that's probably about it). Chances are if you see a cool new trick, it doesn't support IE 11.
I learned something. But would have been better (easier) if the snippets of code only included the css in question and not fonts/backgrounds etc. I had to read each a few times to find the relevant bits.
Okay, the ":target" psuedo class just blew my mind. Not necessarily for modals (which I don't particularly like) but I can think of a lot of other uses. Edit - Apparently it's been around for several years. Not sure how I missed this.
I used it several years ago to create deep links to a list of audio files on the homepage of a site I built. By default the controls were hidden, but if you clicked one of the titles in the list it would show the controls and update the url so you could share a link to that specific item with no JS required.
HTML tip: provide an ID to headers so you can link to them directly! :-) Also, provide an anchor so users can just copy the link and not have to inspect the html or use an extension to link to your headers.
I've used it for a few things and once you go beyond the basic examples, it's the wild west. But if you manage to make it work, some things like pricing tables where a section is sticky to the top until the next one pushes it upward, it's really neat.
Click the bookmark and sticky things disappear. Some websites are horrific with how much screen space they take up with sticyky banners. That also of course breaks some sites.
Interesting. Now does any browser actually support pgup/pgdown properly? Every time I run across a website that does this it annoys me that paging down doesn't properly account for the height of the stickied header making pgup/pgdown unusable.
I was researching something similar recently (sticky elements covering anchor scrolling) and there’s a somwhat modern solution to that: https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-padd... . As usual with new tech though, doesn’t work in Safari (and hence all of iOS) for now. I wonder if the same property could be used to make pgup/pgdown/space work correctly.
I used `position:sticky` in a productive website back in 2015, when it was already well-supported in Firefox. What's true is that Chrome only got support for it recently, and since Chrome == the internet nowadays, you will be forgiven for considering it new.
A good number of them either don’t work or are irrelevant on Safari/iPadOS.
That’s not to say this is a bad article; it’s not. It’s just that there is more to CSS than “here are some rules and ways of using them you might not have thought of”. That’s the real reason front-end dev and design is as difficult as it is.
Yes, I read the article - via Safari on my 11” iPad Pro.
Things that work:
- Typing Effect (@keyframes)
- Drop Shadow
- "center" (flexbox)
- Truncate Text (uses line-camp)
- Modals (uses :target)
- calc
- Style Empty (:empty)
- Position Sticky
- Scroll Snap
- Dynamic Tooltips (when using touchpad)
- Fancy Text
Things that don’t work:
- Smooth Scrolling
- Resize
- Cursors (even when using the touchpad cursor)
- ::selection (even using Safari in “Desktop mode”)
- Custom Scrollbars
I could test due to not having a live example:
- Caret color
Even custom scrollbars work everywhere with different prefixes[1]. It just needed a couple of extra (unprefixed) rules for the missing firefox support:
Check the stats on caniuse and get back to me. These would be mostly supported everywhere, partially supported, or with prefixes.
The only argument being "but not on IE". Which, 100% of these work on almost all versions of Edge. Edge is provided side-by-side with Internet Explorer these days (mostly...).
Internet explorer market share is near zero. Also reminding you that these are just CSS properties (meaning fallbacks are dead-simple or it just looks/behaves boring-er and doesn't break anything).
- Drop shadow
- Custom cursors
- Smooth scrolling
- Truncate text to a number of lines
- Custom scrollbars
- Sticky position
- Scroll snap
- Fancy text
- The CodePen CSS button
IE usage is under 1% now. It's really only used by people for accessing specific legacy apps and internal websites. Microsoft is ending support for it.
There is no longer any reason developers building general-audience websites, web apps, or libraries should care about IE support. It's not part of the general conversation anymore.
You only need to cater to IE if you're a developer on one of those legacy sites, or maintain a library that has been around for so long it's still actively used by those legacy sites.
I understand that and I happen to be one of those developers that has a customer that requires IE to be supported. So I was interested in the behavior of the site under IE. My experience testing the site in IE was different than that of another poster, so I thought I would document it. I apologize for causing you whatever consternation prompted you to react in this way, it certainly wasn't my intent and wasn't anticipated.
It isn't anything special like that, it's trying to jump to an element with id="!" but not finding one. Any gibberish after the # that doesn't match something on the page would work.
About a year ago I seriously considered rolling everything back on my homepage to HTML 2.0, given that was the last one with an actual RFC, though 4.01 had a decent specification.
Cool stuff, but wish there was a disclaimer saying many of the things here are Chrome-only. The target audience for this might not consider browser compatibility from the get-go and have to re-think their UI later.
I'm not sure what you mean; I just tested and all of the examples seem to work in Firefox. Many of them rely on features that have come out within the last couple years, but there's a big difference between "modern" and "Chrome-only".
Half these things should be avoided. Don't mess with scroll or scroll bars. If a user wants smooth scroll, they will enable it in their browser. Snappy scroll is unpredictable and disorienting.
How did I know this would be the top comment on HN?
There are legitimate uses for snap-scrolling, e.g. a horizontal carousel on mobile (or even desktop, depending on implementation), where you want swiping to swipe so the next item is in view.
Also, you said half these things should be avoided -- care to list the others? It seems like the theme of the post is "you don't need JavaScript to do this." If some functionality is rarely needed, but does have use cases, it's nice to know that it can be done in CSS without requiring JS (which would be clearly worse).
Oy. Yes there, are legit uses. A few straightforward examples:
1) You implementing something boards (like trello) on mobile. The well-established-in-all-the-apps-that-specialize-in-this behavior is snap scrolling.
2) Tiktok/stories/etc. When you scroll up or right, does it ever land you in between two stories? No. This is the exact behavior.
3) Presentations. Say you are building a presentation tool. The whole point is to define separate slides that are on screen one at a time. This is a very natural and appropriate use of this behavior.
So, yeah, carousels suck. But, this behavior is commonly used and useful in a lot of modern software.
That page is mostly about auto-rotating carousels. Don't do that.
It's also about making your home page a giant carousel, instead of showing multiple things vertically. Don't do that, either.
IMO, one great use for carousels is when you have a product catalog with a bunch of category sections, like Netflix. Each category gets a header, e.g. "Action" "Family" "Romance" "Horror" and each category is a horizontally scrolling list of products, with the next one on the list half-visible on the side, so it's clear that you can scroll it into view.
Carousels are the modern day <blink> and <marquee> tags. The only difference is that it occasionally has its place with photos, but it's just not optimal for any sort of written content, even if it's just a headline and short description.
nytimes.com uses horizontal carousel on mobile very well, I feel. It's usually for a group of related stories, it's non-intrusive, uses scrolling instead of buttons, and the next story is always partially-visible, which I think is gold-star UI for letting users know it exists.
My understanding is that NY Times spends quite a lot of effort on user metrics, so I would guess, but can't say for sure, that they have evidence that their carousels work.
I'm struggling to see how that is different to "rotating hero images". Is it that it doesn't rotate automatically?
What's the UX benefit here?
I get that mobile apps use horizontal swiping and some websites want to be app-like, but even in apps the only common horiztonal-swipe pattern I see is the Android hidden menus pattern, which is (a) a subject of debate in UX circles and (b) absolutely nothing like horizontally scrolling item selection, which is still a bad idea even in native mobile apps.
The other major example I can think of is Instagram's story circles, which I feel must be intentionally unusable to try and force people to view stories in their full-screen tap-to-advance format.
This seems needlessly nitpicky. You need JavaScript to view the embedded CodeSandbox, which is an interactive application within an iFrame. Good luck making what's effectively an IDE without JavaScript.
I suppose the author could show the CSS snippets inline and make you click to a demo, but that's not very fun is it?
We wouldn't have this mindset if sites retained enough basic functionality with it off, which is totally possible. I use NoScript pretty aggressively, and it's astounding how many sites actually render nothing unless you have JS turned on. Browsers and backends both implement form validation, yet most sites today don't support submitting a basic form without JS. I'm not expecting things like Spotify and YouTube to work without JS, but I should be able to at least read most webpages without running full-fledged applications with 7 different tracking scripts and 5 custom fonts.
> If a user wants smooth scroll, they will enable it in their browser.
I really think comments like this aren't helpful and presumptuous to pressing forward. People hate change and love their table layouts... Just going to make a friendly counter argument:
- Did you read what this actually does? It's for anchor tags...
- Bootstrap 5 uses this by default.
- Lot of crappy websites out there. I choose loading one line of CSS versus jQuery + animate all day...
- For perspective, almost 100% of every little interaction on native apps are animated these days. It's liked so much by the general population that, some would say, made iOS so appealing in the beginning to take off. People like interaction.
- It's possible your opinion does not represent the majority anymore (or even that the HN general opinion).
- By making it a browser-defined CSS property versus being JavaScript, you are actually opening accessibility doors for people having this be device configurable.
I really think if someone hates it so much or for accessibility reasons, instead they should just disable it in their browser.
So literally the opposite of what you said.
---
Edit: Example of why this is important to be part of CSS for accessibility versus JavaScript:
scroll-behavior: smooth seems to only affect the behavior of clicking named anchor tags. It doesn't seem to change the behavior when scrolling with a mouse wheel or trackpad. Other than general accessibility issues related to animations, I don't see any usability concerns here.
scroll-snap-type and scroll-snap-align also don't seem to affect the behavior when scrolling with a mouse wheel or trackpad, except that shortly after you stop scrolling the browser will smoothly scroll to the specified snap points. I suppose this could be over-used (like anything), but it seems to me that there are some pretty obvious places where using this would be entirely appropriate and not unpredictable or disorienting.
::-webkit-scrollbar styling strikes me as the most concerning, both because of how easy and tempting it is to over-use and because the browser support has some subtle gotchas. But this one doesn't seem related to your complaint about smooth versus snappy scrolling.
Yeah, if there's an alternative with functioning scrollbars people will probably use that instead.
It's always surprising how popular screwing with basic UI elements like that always becomes.
One trick that I'm pretty sure I invented is useful in the case where you may be implementing some sort of Material Design palette: you want to use shades of a colour without manually defining them but are losing saturation if you simply use ie. `rgba(255, 255, 255, 0.2)` -- just add `backdrop-filter: saturate(120%)`. This forces the browser renderer to over-saturate the white by mixing in the background colour. Unfortunately Firefox doesn't recognize this CSS property yet but it works fine in WebKit et al.
This can actually be done with 2 lines now!