Post pobrano z: Valid CSS Content

There is a content property in CSS that’s made to use in tandem with the ::before and ::after pseudo elements. It injects content into the element.

Here’s an example:

<div 
  data-done="✅"
  class="email">
    chriscoyier@gmail.com
</div>

.email::before {
  content: attr(data-done) " Email: "; /* This gets inserted before the email address */
}

The property generally takes anything you drop in there. However, there are some invalid values it won’t accept. I heard from someone recently who was confused by this, so I had a little play with it myself and learned a few things.

This works fine:

/* Valid */
::after {
  content: "1";
}

…but this does not:

/* Invalid, not a string */
::after {
  content: 1;
}

I’m not entirely sure why, but I imagine it’s because 1 is a unit-less number (i.e. 1 vs. 1px) and not a string. You can’t trick it either! I tried to be clever like this:

/* Invalid, no tricks */
::after {
  content: "" 1;
}

You can output numbers from attributes though, as you might suspect:

<div data-price="4">Coffee</div>

/* This "works" */
div::after {
  content: " $" attr(data-price);
}

But of course, you’d never use generated content for important information like a price, right?! (Please don’t. It’s not very accessible, nor is the text selectable.)

Even though you can get and display that number, it’s just a string. You can’t really do anything with it.

<div data-price="4" data-sale-modifier="0.9">Coffee</div>

/* Not gonna happen */
div::after {
  content: " $" 
    calc(attr(data-price) * attr(data-sale-modifier));
}

You can’t use numbers, period:

/* Nope */
::after {
  content: calc(2 + 2);
}

Heads up! Don’t try concatenating strings like you might in PHP or JavaScript:

/* These will break */
::after {
  content: "1" . "2" . "3";
  content: "1" + "2" + "3";

  /* Use spaces */
  content: "1" "2" "3";
  /* Or nothing */
  content: "1 2 3";
  /* The type of quote (single or double) doesn't matter, but content not coming back from attr() does need to be quoted. */
}

There is a thing in the spec for converting attributes into the actual type rather than treating them all like strings…

<wood length="12" />

wood {
  width: attr(length em); /* or other values like "number", "px", or "url" */
}

…but I’m fairly sure that isn’t working anywhere yet. Plus, it doesn’t help us with pseudo elements anyway, since strings already work and numbers don’t.

The person who reached out to me over email was specifically confused why they were unable to use calc() on content. I’m not sure I can help you do math in this situation, but it’s worth knowing that pseudo elements can be counters, and those counters can do their own limited form of math. For example, here’s a counter that starts at 12 and increments by -2 for each element at that level in the DOM.

See the Pen Backwards Double Countdown by Chris Coyier (@chriscoyier) on CodePen.

The only other thing we haven’t mentioned here is that a pseudo element can be an image. For example:

p:before {
  content: url(image.jpg);
}

…but it’s weirdly limited. You can’t even resize the image. ¯\_(ツ)_/¯

Much more common is using an empty string for the value (content: "";) which can do things like clear floats but also be positioned, sized and have a background of its own.

The post Valid CSS Content appeared first on CSS-Tricks.

Post pobrano z: POSTing an Indeterminate Checkbox Value

There is a such thing as an indeterminate checkbox value. It’s a checkbox (<input type="checkbox">) that isn’t checked. Nor is it not checked. It’s indeterminate.

We can even select a checkbox in that state and style it with CSS!

Some curious points though:

1. It’s only possible to set via JavaScript. There is no HTML attribute or value for it.
2. It doesn’t POST (or GET or whatever else) or have a value. It’s like being unchecked.

So, say you had a form like this:

<form action="" method="POST" id="form">
  
  <input name="name" type="text" value="Chris" />
  
  <input name="vegetarian" type="checkbox" class="veg">
  
  <input type="submit" value="Submit">
  
</form>

And, for whatever reason, you make that checkbox indeterminate:

let veg = document.querySelector(".veg");
veg.indeterminate = true;

If you serialize that form and take a look at what will POST, you’ll get "name=Chris". No value for the checkbox. Conversely, had you checked the checkbox in the HTML and didn’t touch it in JavaScript, you’d get "name=Chris&vegetarian=on".

Apparently, this is by design. Checkboxes are meant to be boolean, and the indeterminate value is just an aesthetic thing meant to indicate that visual „child” checkboxes are in a mixed state (some checked, some not). That’s fine. Can’t change it now without serious breakage of websites.

But say you really need to know on the server if a checkbox is in that indeterminate state. The only way I can think of is to have a buddy hidden input that you keep in sync.

<input name="vegetarian" type="checkbox" class="veg">
<input name="vegetarian-value" type="hidden" class="veg-value">

let veg = document.querySelector(".veg");
let veg_value = document.querySelector(".veg-value"); 
veg.indeterminate = true;
veg_value.value = "indeterminate";

I’ve set the indeterminate value of one input and I’ve set another hidden input value to "indeterminate", which I can POST. Serialized means it looks like "name=Chris&vegetarian-value=indeterminate". Good enough.

See the Pen Can you POST an intermediate value? by Chris Coyier (@chriscoyier) on CodePen.

The post POSTing an Indeterminate Checkbox Value appeared first on CSS-Tricks.

Post pobrano z: POSTing an Indeterminate Checkbox Value

There is a such thing as an indeterminate checkbox value. It’s a checkbox (<input type="checkbox">) that isn’t checked. Nor is it not checked. It’s indeterminate.

We can even select a checkbox in that state and style it with CSS!

Some curious points though:

1. It’s only possible to set via JavaScript. There is no HTML attribute or value for it.
2. It doesn’t POST (or GET or whatever else) or have a value. It’s like being unchecked.

So, say you had a form like this:

<form action="" method="POST" id="form">
  
  <input name="name" type="text" value="Chris" />
  
  <input name="vegetarian" type="checkbox" class="veg">
  
  <input type="submit" value="Submit">
  
</form>

And, for whatever reason, you make that checkbox indeterminate:

let veg = document.querySelector(".veg");
veg.indeterminate = true;

If you serialize that form and take a look at what will POST, you’ll get "name=Chris". No value for the checkbox. Conversely, had you checked the checkbox in the HTML and didn’t touch it in JavaScript, you’d get "name=Chris&vegetarian=on".

Apparently, this is by design. Checkboxes are meant to be boolean, and the indeterminate value is just an aesthetic thing meant to indicate that visual „child” checkboxes are in a mixed state (some checked, some not). That’s fine. Can’t change it now without serious breakage of websites.

But say you really need to know on the server if a checkbox is in that indeterminate state. The only way I can think of is to have a buddy hidden input that you keep in sync.

<input name="vegetarian" type="checkbox" class="veg">
<input name="vegetarian-value" type="hidden" class="veg-value">

let veg = document.querySelector(".veg");
let veg_value = document.querySelector(".veg-value"); 
veg.indeterminate = true;
veg_value.value = "indeterminate";

I’ve set the indeterminate value of one input and I’ve set another hidden input value to "indeterminate", which I can POST. Serialized means it looks like "name=Chris&vegetarian-value=indeterminate". Good enough.

See the Pen Can you POST an intermediate value? by Chris Coyier (@chriscoyier) on CodePen.

The post POSTing an Indeterminate Checkbox Value appeared first on CSS-Tricks.

Post pobrano z: The Way We Talk About CSS

There’s a ton of very quotable stuff from Rachel Andrew’s latest post all about CSS and how we talk about it in the community:

CSS has been seen as this fragile language that we stumble around, trying things out and seeing what works. In particular for layout, rather than using the system as specified, we have so often exploited things about the language in order to achieve far more complex layouts than it was ever designed for. We had to, or resign ourselves to very simple looking web pages.

Rachel goes on to argue that we probably shouldn’t disparage CSS for being so weird when there are very good reasons for why and how it works — not to mention that it’s getting exponentially more predictable and powerful as time goes by:

There is frequently talk about how developers whose main area of expertise is CSS feel that their skills are underrated. I do not think we help our cause by talking about CSS as this whacky, quirky language. CSS is unlike anything else, because it exists to serve an environment that is unlike anything else. However we can start to understand it as a designed language, with much consistency. It has codified rules and we can develop ways to explain and teach it, just as we can teach our teams to use Bootstrap, or the latest JavaScript framework.

I tend to feel the same way and I’ve been spending a lot of time thinking about how best to reply to folks that argue that “CSS is dumb and weird.” It can sometimes be a demoralizing challenge, attempting to explain why your career and area of expertise is a useful one.

I guess the best way to start doing that is to stand up and say, “No, CSS is not dumb and weird. CSS is awesome!”

Direct Link to Article — Permalink

The post The Way We Talk About CSS appeared first on CSS-Tricks.