css
What do I need to read to be great at CSS?
100 Bytes of CSS to look great everywhere
Changing Our Development Mindset
So many little design helper sites!
Whostyles
A Definition by Kicks CondorThe 'whostyle' is a way of styling syndicated hypertext from other writers. This could be a quoted excerpt or a complete article. A feed reader could use a 'whostyle' to show a post without stripping all of its layout.
This page is a truly naked, brutalist html quine
An Article by Leon BambrickI decided to make a truly naked, brutalist html page, that is itself a quine. And this page is it.
Viewing the source of this page should reveal a page identical to the page you are now seeing. Nothing is hidden. It's a true "What you see is what you get."
this vs. that
A Website by Phuoc NguyenAn Interactive Guide to CSS Transitions
A Reference Work by Josh W. ComeauIn this tutorial, we'll dig in and learn a bit more about CSS transitions, and how we can use them to create lush, polished animations.
CSS at the Intersection
A TalkThroughout the talk I discuss the mental models we construct in tech, the cognitive dissonance we experience when confronted with new ideas, specifically about CSS.
We know CSS has a separate mental model because we keep hearing the same debate rage on: “Is CSS broken or awesome?” This talk is about enabling teams to communicate and accommodate these different mental models. I share examples of effective tools, and how they change the way designers and developers interact.
The Great Divide
An Article by Chris CoyierOn one side, an army of developers whose interests, responsibilities, and skill sets are heavily revolved around JavaScript.
On the other, an army of developers whose interests, responsibilities, and skill sets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, etc.
Product vs. Feature Teams
This article is certain to upset many people.
Empowered product teams
When I wrote about the virtues of empowered product teams, I was referring to what I’ll continue to call here as product teams. Specifically, they are cross-functional (product, design and engineering); they are focused on and measured by outcomes (rather than output); and they are empowered to figure out the best way to solve the problems they’ve been asked to solve.
Viability, usablity, feasibility
In an empowered product team, the product manager is explicitly responsible for ensuring value and viability; the designer is responsible for ensuring usability; and the tech lead is responsible for ensuring feasibility. The team does this by truly collaborating in an intense, give and take, in order to discover a solution that work for all of us.
However, in a feature team, you still (hopefully) have a designer to ensure usability, and you have engineers to ensure feasibility, but, and this is critical to understand: the value and business viability are the responsibility of the stakeholder or executive that requested the feature on the roadmap.
What went wrong?
If something ships from one of the companies I advise, and it is virtually unusable because of poor design (which as we all know occasionally does happen), you can bet I go directly to the designer and ask how this happened? It is absolutely on the designer to ensure this does not happen, so something went wrong.
Similarly, if the product ships and performance is terrible you can bet I go directly to the tech lead with the same question.
And most frequently of all, if something ships and the analytics show that it’s either not being bought or not being used, or it turns out that it violates some business constraint like compliance or privacy, you can bet I go right to the product manager with that question.