Tags: css

722

sparkline

Saturday, August 12th, 2017

Shadow DOM: fast and encapsulated styles – Monica Dinculescu

Monica explains how Shadow DOM could be the perfect answer for scoping CSS:

We didn’t have style encapsulation, so we started naming things “the right way” with BEM, so that we didn’t accidentally stomp over each other’s styles. We wanted to be able to author CSS from inside a JavaScript component, so we started using CSS-in-JS. We needed all these tools, because “the platform” (read: the browsers that be) wasn’t there, and building these tools showed that there was a need to move forward. For style encapsulation, Shadow DOM is the platform moving forward.

Although, in a way, Shadow DOM is also another flavour of CSS-in-JS:

Before you complain that using a Shadow DOM and Web Components means that it absolutely requires JavaScript: this is true.

Friday, August 4th, 2017

CSS: Current, Soon, Someday (Web Directions Code 2017) // Speaker Deck

Oh, how I wish I could’ve been at Web Directions Code in Melbourne to see this amazing presentation by Charlotte. I can’t quite get over how many amazing knowledge bombs she managed to drop in just 20 minutes!

Monday, July 31st, 2017

Shoelace.css: a back to the basics CSS starter kit

A starter kit of CSS that gives you some basic styles that you can tweak with custom properties.

For when you don’t need the whole boot.

Also:

Shoelace doesn’t ship with a grid system because you don’t need one. You should use the CSS Grid Layout instead.

I approve this message!

Tooltips & Toggletips

Another great deep dive by Heydon into a single interface pattern. This time it’s the tooltip, and its cousin, the toggletip.

There’s some great accessibility advice in here.

rachelandrew/gridbugs: A curated list of Grid interop issues

Rachel is maintaining this (short) list of browser bugs with CSS Grid, inspired by the excellent Flexbugs.

Grid shipped into browsers](https://gridbyexample.com/browsers) in a highly interoperable state, however there are a few issues - let’s document any we find here.

Thursday, July 27th, 2017

Testing the accessibility of pattern libraries

Riffing on Rachel’s talk at Patterns Day:

At the Patterns Day conference last month, Rachel Andrew mentioned something interesting about patterns. She said that working with reusable interface components, where each one has its own page, made her realise that those work quite well as isolated test cases. I feel this also goes for some accessibility tests: there is a number of criteria where isolation aids testing.

Hidde specifically singles out these patterns:

  • Collapsible (“Show/hide”)
  • Form field
  • Video player

Tuesday, July 25th, 2017

Progressively Enhancing CSS Layout: From Floats To Flexbox To Grid – Smashing Magazine

A great example of progressive enhancement in action.

You can perfectly use CSS grid layout today if you don’t expect exactly the same appearance in every single browser, which isn’t possible to achieve nowadays anyway. I’m well aware that this decision isn’t always up to us developers, but I believe that our clients are willing to accept those differences if they understand the benefits (future-proof design, better accessibility and better performance). On top of that, I believe that our clients and users have — thanks to responsive design — already learned that websites don’t look the same in every device and browser.

Sunday, July 23rd, 2017

Against the grain | susan jean robertson

I’m looking for work. I’d prefer to work remotely with a product team and to work in the areas I love: accessibility, CSS, and HTML. But it turns out those three things are considered “easy” in the industry right now. Which is fascinating because if you talk to anyone who uses assistive technology to surf the web or who doesn’t use a mouse, or who is accessing content in a different manner, you’ll find out it isn’t so easy.

Somebody hire Susan already!

Friday, July 21st, 2017

Patterns Day 2017: Rachel Andrew on Vimeo

Rachel’s fantastic talk from Patterns Day. There’s a lot of love for Fractal specifically, but there are also some great points about keeping a pattern library in sync with a live site, and treating individual components as reduced test-cases.

Thursday, July 20th, 2017

0825 — ericportis.com

Well, well, well …following on from my post about container queries, it turns out that Eric has also been thinking about wrangling custom properties. He’s even written some code.

Container queries

Every single browser maker has the same stance when it comes to features—they want to hear from developers at the coalface.

“Tell us what you want! We’re listening. We want to know which features to prioritise based on real-world feedback from developers like you.”

“How about container quer—”

“Not that.”

I don’t think it’s an exaggeration to say that literally every web developer I know would love to have container queries. If you’ve worked on any responsive project of any size, you’re bound to have bumped up against the problem of only being able to respond to viewport size, rather than the size of the containing element. Without container queries, our design systems can never be truly modular.

But there’s a divide growing between what our responsive designs need to do, and the tools CSS gives us to meet those needs. We’re making design decisions at smaller and smaller levels, but our code asks us to bind those decisions to a larger, often-irrelevant abstraction of a “page.”

But the message from browser makers has consistently been “it’s simply too hard.”

At the Frontend United conference in Athens a little while back, Jonathan gave a whole talk on the need for container queries. At the same event, Serg gave a talk on Houdini.

Now, as I understand it, Houdini is the CSS arm of the extensible web. Just as web components will allow us to create powerful new HTML without lobbying browser makers, Houdini will allow us to create powerful new CSS features without going cap-in-hand to standards bodies.

At this year’s CSS Day there were two Houdini talks. Tab gave a deep dive, and Philip talked specifically about Houdini as a breakthrough for polyfilling.

During the talks, you could send questions over Twitter that the speaker could be quizzed on afterwards. As Philip was talking, I began to tap out a question: “Could this be used to polyfill container queries?” My thumb was hovering over the tweet button at the very moment that Philip said in his talk, “This could be used to polyfill container queries.”

For that happen, browsers need to implement the layout API for Houdini. But I’m betting that browser makers will be far more receptive to calls to implement the layout API than calls for container queries directly.

Once we have that, there are two possible outcomes:

  1. We try to polyfill container queries and find out that the browser makers were right—it’s simply too hard. This certainty is itself a useful outcome.
  2. We successfully polyfill container queries, and then instead of asking browser makers to figure out implementation, we can hand it to them for standardisation.

But, as Eric Portis points out in his talk on container queries, Houdini is still a ways off (by the way, browser makers, that’s two different conference talks I’ve mentioned about container queries, just in case you were keeping track of how much developers want this).

Still, there are some CSS features that are Houdini-like in their extensibility. Custom properties feel like they could be wrangled to help with the container query problem. While it’s easy to think of custom properties as being like Sass variables, they’re much more powerful than that—the fact they can be a real-time bridge between JavaScript and CSS makes them scriptable. Alas, custom properties can’t be used in media queries but maybe some clever person can figure out a way to get the effect of container queries without a query-like syntax.

However it happens, I’d just love to see some movement on container queries. I’m not alone.

I know container queries would revolutionize my design practice, and better prepare responsive design for mobile, desktop, tablet—and whatever’s coming next.

Tuesday, July 18th, 2017

Patterns Day 2017: Sareh Heidari on Vimeo

Time for another video from Patterns Day. Here’s Sareh Heidari walking us through Grandstand, the CSS framework at the BBC.

CSS

Last month I went to CSS Day in Amsterdam, as an attendee this year, not a speaker. It was an excellent conference comprising the titular CSS day and a Browser API Special the day before.

By the end of CSS Day, my brain was full. Experiencing the depth of knowledge that’s contained in CSS now made me appreciate how powerful a language it is. I mean, the basics of CSS—selectors, properties, and values—can be grasped in a day. But you can spend a lifetime trying to master the details. Heck, you could spend a lifetime trying to master just one part of CSS, like layout, or text. And there would always be more to learn.

Unlike a programming language that requires knowledge of loops, variables, and other concepts, CSS is pretty easy to pick up. Maybe it’s because of this that it has gained the reputation of being simple. It is simple in the sense of “not complex”, but that doesn’t mean it’s easy. Mistaking “simple” for “easy” will only lead to heartache.

I think that’s what’s happened with some programmers coming to CSS for the first time. They’ve heard it’s simple, so they assume it’s easy. But then when they try to use it, it doesn’t work. It must be the fault of the language, because they know that they are smart, and this is supposed to be easy. So they blame the language. They say it’s broken. And so they try to “fix” it by making it conform to a more programmatic way of thinking.

I can’t help but think that they would be less frustrated if they would accept that CSS is not easy. Simple, yes, but not easy. Using CSS at scale has a learning curve, just like any powerful technology. The way to deal with that is not to hammer the technology into a different shape, but to get to know it, understand it, and respect it.

Thursday, July 6th, 2017

CSS is Awesome | CSS-Tricks

Geek humour is no laughing matter, as Chris demonstrates here with his thorough dissection of that coffee mug.

CSS is weird. It’s unlike any other code, and that makes a lot of programmers uncomfortable. But used wisely it can, in fact, be awesome.

It’s not often I say this, but read the comments.

Wednesday, July 5th, 2017

Is it really safe to start using CSS Grid Layout?

Rachel uncovers a great phrase for dealing with older browsers:

It isn’t your fault, but it is your problem.

She points to multiple ways of using CSS Grid today while still providing a decent experience for older browsers.

Crucially, there’s one message that hasn’t changed in fifteen years:

Websites do not need to look the same in every browser.

It’s crazy that there are still designers and developers who haven’t internalised this. And before anyone starts claiming that the problem is with the clients and the bosses, Rachel has plenty of advice for talking with them too.

Your job is to learn about new things, and advise your client or your boss in the best way to achieve their business goals through your use of the available technology. You can only do that if you have learned about the new things. You can then advise them which compromises are worth making.

Monday, July 3rd, 2017

Fixing fieldsets — That Emil is Emil Björklund

This is an excellent proposal from Emil. If we can apply display: contents to fieldsets, then we would finally have a way of undoing the byzantine browser styles that have hindered adoption of this element. This proposal also ensures backwards compatibility so there’d be no breakage of older sites:

The legacy appearance of fieldsets probably needs to be preserved for compatibility reasons. But display: contents is not supported in any old browsers, and is most likely used on exactly zero sites using the legacy look of fieldsets.

Whaddya say, browser makers?

Sunday, July 2nd, 2017

Sticky headers

A three-part series by Remy looking at one interface pattern (a sticky header) and how his code evolved and changed:

  1. Sticky headers
  2. Smooth scroll & sticky navigation
  3. CSS sticky nav & smooth scroll

Sunday, June 25th, 2017

Aspect Ratios in CSS are a Hack | Bram.us

Bram hopes for a way to define aspect ratios natively in CSS. We can sort of manage it now, but all the solutions are pretty hacky.

Pure CSS crossword - CSS Grid

Form validation taken to the extreme. If you want to know more about how it was done, there’s an article explaining the markup and CSS.

Thursday, June 22nd, 2017

Oh No! Our Stylesheet Only Grows and Grows and Grows! (The Append-Only Stylesheet Problem) | CSS-Tricks

I think Chris is on to something here when he identifies one of the biggest issues with CSS growing out of control:

The developers are afraid of the CSS.