Ain’t nothing wrong with max-width, but Ethan makes a point in the last sentence:
Rather than simply defaulting to max-width as a constraint, I can use the empty space around my design, and treat it as a layout tool.
If the space “around” your grid is actually part of the grid, it’s easier to use. Maybe you’d decide to scootch some author information up there after all, or show an ad, or who knows what. It will be more robust if you do it within the established grid.
Let’s say you’re building a site, and you’re working with a designer. They come to you with some solid designs, and you’re ready to go. You’re also a conscientious front end developer and you like to make sure the sites you build are accessible. The designs you’re working from have some body copy, but you notice that the links inside the body copy are missing underlines.
I would think this matters whether you underline links or not, but I take the point that without underlines the problem is worse.
I’d also argue the problem is even more complicated. You’ve also got to consider the text when it is selected, and make sure everything has contrast when that is the case too. And the hover states, active states, visited states, and focus states. So it’s really like hexacontakaienneagon of contrast or something.
Scrollbars are natural progress meters. How far the scrollbar is down or across is how much progress has been made scrolling through that element (often the entire page). But, they are more like progress indicators than meters, if you think of a meter as something that “fills up” as you go.
We can use some CSS trickery to make the scrollbar fill up as we go.
This will only work with -webkit- vendor-prefixed scrollbar-styling properties. In other words, these are non-standard. The standardized scrollbar styling properties are scrollbar-width and scrollbar-color, which can’t pull this kind of thing off, but are probably a safer bet in the long run. Still, the vendor-prefixed versions probably aren’t going anywhere, so if you consider this a weird form of progressive enhancement, that’s probably fine.
What’s the trick?
Essentially, it’s hanging a huge box-shadow off the top of the scrollbar thumb — or off the side if it’s a horizontally scrolling element.
That example didn’t differentiate the thumb part of the scrollbar at all, which makes it more meter-like, but also harder to use. My demo has a slightly different color thumb.
Can I really use this?
No! Aside from it being super weird and non-standard. Safari flips it’s lid and I have no idea how to fix it.
I linked up Water.css not long ago as an interesting sort of CSS framework. No classes. No <h2 class="is-title">. You just use semantic HTML and get styles. Is that going to “scale” very far? Probably not, but it sure is handy for styling things quickly, where — of course — you’re writing semantic HTML but don’t need to care tremendously about the look, other than it should look as decent as it can with low effort.
This week I saw MVP.css making the rounds. Same idea. There are a bunch more!
I was debugging some CSS last week, and I think that post is missing something important: your attitude.
Now – I’m not a very good CSS developer yet. I’ve never written CSS professionally and I don’t understand a lot of basic CSS concepts (I think I finally understood for the first time recently how position: absolute works). And last week I was working on the most complicated CSS project I’d ever attempted.
While I was debugging my CSS, I noticed myself doing some bad things that I normally would not! I was:
• making random changes to my code in the hopes that it would work • googling a lot of things and trying them without understanding what they did • if something broke, reverting my changes and starting again
This strategy was exactly as effective as you might imagine (not very effective!), and it was because of my attitude about CSS! I had this unusual-for-me belief that CSS was Too Hard and impossible for me to understand. So let’s talk about that attitude a bit!
It’s super unfortunate this specific bug (a difference in z-index behavior between Chrome and Firefox) is what was giving Julia a hard time. Those kind of cross-browser differences are fewer and farther between these days, thankfully. I’m certainly sympathetic to CSS being super tricky sometimes, and it can be that way without dealing with an actual browser bug.
But I like the sentiment: if you go into a tricky problem with a positive I can do this attitude starting with the basics, you can do it.
I think literally everything in life is easier and better with a better attitude. Food tastes better! Reminds me of my favorite mis-remembered quote from good ol’ Uncle Iroh from The Last Airbender:
The best tasting tea is the tea you drink when you are in a good mood.
Foldable phones are starting to be a thing. Early days, for sure, but some are already shipping, and they definitely have web browsers on them. Stands to reason that, as web designers, we are going to want to know where that fold is so we can design screens that fit onto the top half and bottom half… or left half and right half¹.
Looks like that’s going to make its way to us in the form of env() constants, just like all that notch stuff.
Interesting how there is no fold-right, isn’t it? And aren’t we trying to stay away from directional terms like that and use logical properties? Why not fold-inline-start?
It’ll be interesting to see how that sentence ages. Just watch the first really popular foldable phone will have three segments.
This report made a big splash last year. It’s a large chunk of research that shows just how terribly the web does with accessibility. It’s been updated this year and (drumroll…) we got a little worse. I’ll use their blockquote:
The number of errors increased 2.1% between February 2019 and February 2020.
From the choir:
Over the last year websites got **checks notes** LESS accessible?!?1 Jesus, my dudes. https://t.co/zvwb2wQxsH
Last year I wrote about @webaim’s analysis of one million home pages, and how it painted an *incredibly* bleak picture of the web’s accessibility: https://t.co/yLG9poTSMf
#Accessibility The WebAIM report is out and it's apparently getting worse. Seriously, it's about time we start making the web more accessible, people rely now more than even on a lot of online services for security, health, information, etc. https://t.co/7n0zxtUuyZ
Web accessibility is getting statistically worse. This is going to keep happening – and we’re going to keep being surprised about it – until we get honest about ableism. These cold, hard numbers are a human problem. https://t.co/gplKhUKQLy
Part of me thinks: it’s time for browsers to step up and auto-fix the things they can. But I also think that’s dangerous territory. AMP is a browser vendor’s version of “enough is enough” with poor web performance and I’m not loving how that’s turned out to date. That said, evangelism doesn’t seem to be working.
You can fix your site though. My favorite tool is axe.
I’ve written up my advice (sprinkled with great advice from others), but this is way more straightforward nuts-and-bolts training on technical writing. It’s structured like an actual course, with exercises along the way.
I’m far from an expert here. But between Geoff and I, we end up doing a lot of technical article editing for the sake of clarity.
Comedy writers seek the funniest results, horror writers strive for the scariest, and technical writers aim for the clearest. In technical writing, clarity takes precedence over all other rules.
It can be tricky to get right. Read the section on Active voice. That’s easy for anyone to get wrong.
Essentially every single rule is just an extension of “make it more clear.”
Independent transforms happen first. The transform property happens last and stacks on top of what has already been done, which can get confusing¹.
They all share the same transform-origin.
The offset-* properties also effectively moves/rotates elements. Those happen after independent transforms and beforetransform.
Claus Colloseus wrote in to fix some issues in this post and clarify just how confusing this can be. For example, rotate: 45deg; transform: rotate(-45deg); will do nothing as both of them will apply and effectively cancel each other out. So shouldn’t translate: 50px 0; rotate: 45deg; transform: translate(-50px, 0) rotate(-45deg); also all cancel out? No, because of the ordering, the end result is like translate(14.6447px, -35.3553px).
Scott Turner, who has an entire blog "Exploring procedural generation and display of fantasy maps", gets into why vector graphics seems on these surface why it would be bad for the look of a pencil stroke:
Something like this pencil stroke would require many tens of thousands of different elements. Basically each little blob of gray in that image would be separately defined.
Nada Rifki demonstrates the scroll-snap-type and scroll-snap-alignCSS properties. I like that the demo shows that the items in the scrolling container can be different sizes. It is the edges of those children that matter, not some fixed snapping distance.
I, Dave Rupert, a person who cares about web performance, a person who reads web performance blogs, a person who spends lots of hours trying to keep up on best practices, a person who co-hosts a weekly podcast about making websites and speak with web performance professionals… somehow goofed and added 33 SECONDS to their page load.
This stuff is hard even when you care a lot. The 33 seconds came from font preloading rather than the one-line wonder of font-display.
I also care about making fast websites, but mine aren't winning any speed awards because I'll take practical and maintainable over peak performance any day. (Sorry, world)
Bram covers how frustrating .bar:nth-child(2) is. It's not "select the second element of class .bar." It's "select the second element if it also has the class .bar." The good news? There is a real selector that does the former:
Tyler Gaw reminds us that mask-image can repeat, resize, and move just like background-image does, which is fun to combine and play with. I could see it being a fun option for an <hr>, like Sara is doing.
User groups not well served by use of the title attribute
• Mobile phone users. • Keyboard only users. • Screen magnifier users. • Screen reader users. • Users with fine motor skill impairments. • Users with cognitive impairments.
Sounds like in 2020, the only useful thing the title attribute can do is label an <iframe title="Contact Form"></iframe>.
From Adam and Una at Google, a podcast just about CSS. I believe I'm contractually obliged to link to that! Just one episode out so far, a shorty about the box model.
PPK digs into the subject, which he found woefully undercovered in web tech documentation. Our entry doesn't mention them at all, which I'll aim to fix.
Agree on this situation:
This is by far the most common use case for negative margins. You give a container a padding so that its contents have some breathing space. However, you want the header to span the entire container, ignoring the padding. Negative margins are the way to go.
Like this:
Anecdotally, I find negative margins fairly intuitive. Although that's surprising since there are so many oddities, like how they sometimes affect the element applied to itself (e.g. move itself to the left) and sometimes affect other elements (e.g. move other elements upward) — plus the fact that it affects margin collapsing which is weird anyway.
