Why don’t we add a `lovely` element to HTML?

<person>, <subhead>, <location>, <logo>… It’s not hard to come up with a list of HTML elements that you think would be useful. So, why don’t we?

Bruce Lawson has a look. The conclusion is largely that we don’t really need to and perhaps shouldn’t.

By my count, we now have 124 HTML elements, many of which are unknown to many web authors, or regularly confused with each other—for example, the difference between <article> and <section>. This suggests to me that the cognitive load of learning all these different elements is getting too much.

Direct Link to ArticlePermalink

The post Why don’t we add a `lovely` element to HTML? appeared first on CSS-Tricks.

Sass Selector Combining

Brad Frost was asking about this the other day…

.c-btn { &__icon { ... }
}

I guess that’s technically “nesting” but the selectors come out flat:

.c-button__icon { }

The question was whether you do that or just write out the whole selector instead, as you would with vanilla CSS. Brad’s post gets into all the pro’s and con’s of both ways.

To me, I’m firmly in the camp of not “nesting” because it makes searching for selectors so much harder. I absolutely live by being able to search my project for fully expanded class names and, ironically, just as Brad was posting that poll, I was stumped by a combined class like this and changed it in one of my own code bases.

Robin Rendle also notes the difficulty in searching as an issue with an example that has clearly gone too far!

Direct Link to ArticlePermalink

The post Sass Selector Combining appeared first on CSS-Tricks.

CSS Only Floated Labels with :placeholder-shown pseudo class

The floated label technique has been around for a good long while and the general idea is this: we have an text input with the placeholder attribute acting as a label. When a user types into that input, the label moves from inside the input to outside of it.

Like so:

Although I don’t see this pattern used on the web all that much, I do think it’s an interesting one! There are different approaches to it, but Nick Salloum describes a new one using a combination of :not and :placeholder-shown:

This UI technique does indeed slightly bend the definitions of label and placeholder listed above, in the sense that we’re giving the placeholder more initial importance in having to explain the input to the user, but it’s a tradeoff for a neat UI component, and one that I’m personally comfortable making.

I wonder if there are other peculiar ways :not and :placeholder-shown could be put to use.

Direct Link to Article — Permalink

The post CSS Only Floated Labels with :placeholder-shown pseudo class appeared first on CSS-Tricks.

The industry’s best open API

(This is a sponsored post.)

With our robust SDK, super clean dashboard, detailed documentation, and world-class support, HelloSign API is one of the most flexible and powerful APIs on the market. Start building for free today.

Direct Link to Article — Permalink

The post The industry’s best open API appeared first on CSS-Tricks.

The Codification of Design

Jonathan Snook on managing the complexity between what designers make and what developers end up building:

Everything that a designer draws in a Sketch or Photoshop file needs to be turned into code. Code needs to be developed, delivered to the user, and maintained by the team.

That means that complexity in design can lead to complexity in code.

That’s not to say that complexity isn’t allowed. However, it is important to consider what the impact of that complexity is—especially as it relates to your codebase.

Jonathan continues in that post to argue that designers and developers need to be in a constant feedback loop in order to properly assess whether the complexity of the design is worth the complexity of the engineering solution.

I’ve been thinking about this sort of thing for a really long time as it applies to my work in design systems — I have a feeling this issue stems from the fact that designers and developers are trading with different currencies. Designers generally care about the user experience above anything else while developers may prioritize the code under the hood, willing to over-engineer something for this one tiny detail.

As Snook mentions later in his post, pattern libraries won’t solve this problem entirely:

This is why it’s important to have these conversations during the design process. It’s important to understand what the priorities are within your team. It’s important to understand what tradeoffs you’re willing to make. Without consensus within your team, you’ll continue to butt heads as the requirements of the front-end development team conflict with the requirements of the design team.

So, the best way to get those two groups to exchange the same currency is with talking, instead of tools. Or, perhaps by designing with code.

Direct Link to Article — Permalink

The post The Codification of Design appeared first on CSS-Tricks.

Selectors That Depend on Layout

“Why the heck don’t we have ::first-column?”

I heard someone ask that the other day and it’s a valid question. I’d even take that question further by asking about ::nth-column() or whatever else relates to CSS columns. We have stuff like ::first-letter and ::first-line. Why not others?

There are many notable things missing from the “nth” crowd. Seven years ago, I wrote “A Call for ::nth-everything” and it included clear use cases like, perhaps, selecting the first two lines of a paragraph.

I don’t know all the technical details of it all, but I know there are some fairly decent reasons why we don’t have all of these in CSS. Part of it is the difficulty of getting it specced (e.g. words and characters get tricky across written languages) and part of it is the difficulty of implementing them. What I just found out is that there is a FAQ document that explains!

So, why don’t we have ::first-column? Because it’s a “selector that depends on layout”:

This falls into a class of problems that unlikely to be solvable in CSS: selectors in general, and pseudo classes in particular, cannot depend on layout, because otherwise they could be used to modify layout in a way that made them no longer match, which would modify the layout back to where it was, so they match again, and we get stuck in an infinite loop of contradictions.

For a simple example:

:stuck { position: static; }

Now what?

Some of the changes web developers might want to apply with a :stuck pseudo class may be safe and not trigger such loops, but selectors are a generic mechanism, and would enable this kind of contradictions.

So even though many of the problem people are trying to address using such pseudo classes are legitimate, selectors are unlikely to be the answer.

What we’ve got are infinite loops that are basically the problem (but read the FAQ — it goes into great detail about the nuance of it). In a related way, the same reason we don’t have element queries in CSS.

It’s a little tricky to think about because even stuff like ::first-line are riddled with paradoxes. Say you use it to increase the font-size. That means fewer characters fit on the line, so the characters that originally matched are now pushed down and don’t match anymore. Seems a bit loopy, but that’s been sorted out. Plus, classics like :hover potentially causing jitter. The document talks about these things in clear terms. It’s not all cut and dry!

The whole FAQ is a fascinating read and covers much more than this situation.

Direct Link to Article — Permalink

The post Selectors That Depend on Layout appeared first on CSS-Tricks.

Netlify

(This is a sponsored post.)

It’s always fun to watch developers discover Netlify for the first time. It’s so easy. One way to do it is to just literally drag and drop a folder onto them and it will be online. Even better, connect a Git repo to a Netlify site and tell it what branch you want to watch, then any commits to that branch will automatically go live, even running your site’s build as it does it. I heard one developer say, “It’s like someone actually designed hosting and deployment.”

That lends itself nicely to static sites, but don’t think that static sites are only for certain types of sites or limiting in some way. That’s what the JAMstack is all about! Wanna learn more about that? Come to JAMstack_conf!

Netlify does a ton to help you power your JAMstack site as well. They’ll process your forms. They’ll help you with authentication. They’ll do your A/B testing. They’ll even run your cloud functions. Pretty incredible, really.

Direct Link to Article — Permalink

The post Netlify appeared first on CSS-Tricks.

Test out the cloud platform developers love for free with a $100 credit

(This is a sponsored post.)

DigitalOcean invites you to experience a better, faster and simpler cloud platform designed to scale based on your needs. Get started for free with a $100 credit toward your first project and discover why the most innovative companies are already hosting on DigitalOcean.

Direct Link to Article — Permalink

The post Test out the cloud platform developers love for free with a $100 credit appeared first on CSS-Tricks.

The “Developer Experience” Bait-and-Switch

Alex Russell describes his thoughts on the current state of JavaScript and how we might sometimes put a ton of focus on the ease-of-use of development at the expense of user experience. So, for example, we might pick a massive framework to make development easier and faster but then that might have an enormous impact on the user.

Alex describes it as substituting “developer value for user value.”

The “developer experience” bait-and-switch works by appealing to the listener’s parochial interests as developers or managers, claiming supremacy in one category in order to remove others from the conversation. The swap is executed by implying that by making things better for developers, users will eventually benefit equivalently. The unstated agreement is that developers share all of the same goals with the same intensity as end users and even managers. This is not true.

Here’s the kicker, though:

JavaScript is the web’s CO2. We need some of it, but too much puts the entire ecosystem at risk. Those who emit the most are furthest from suffering the consequences — until the ecosystem collapses. The web will not succeed in the markets and form-factors where computing is headed unless we get JS emissions under control.

By that standard, it could also stand to reason that the work we put into “design systems” falls into this trap. But there is something to be said about achieving ease of use on this front: a more consistent codebase is probably a very good thing for accessibility, UX consistency, etc. etc.

So, although I agree with Alex’s premise here, I’m not entirely sure I agree wholeheartedly on this subject.

Direct Link to Article — Permalink

The post The “Developer Experience” Bait-and-Switch appeared first on CSS-Tricks.

Putting things on top of other things

A plain-language romp through the trials and tribulations of z-indexby Isabel Brison. On the surface, z-index seems simple. It’s a number and it represents what is on top of what… assuming it is positioned… and assuming it is within the same stacking context as the other things.

… that is the gist of it: stacking contexts are caused by a variety of properties and the main reasons for their existence are performance concerns and ease of implementation by browsers. They are not always related to z-index or ordering; they pop up wherever it makes sense to have several elements all on the same layer for rendering purposes.

Direct Link to Article — Permalink

The post Putting things on top of other things appeared first on CSS-Tricks.