For those who have studied web site accessibility, this is probably old hat. Admittedly, I haven’t spent enough time thinking about accessibility, so this is one of those things I didn’t even realize until recently. So shame on me. :)
Let’s say you have the following page, with various elements, starting with maybe a form field:
At the recent W3Conf Nicolas Gallagher explained that although pseudo-elements have helped us add decorative content to our pages while keeping our HTML clean, this has led to some maintainability issues.
As Nicolas pointed out, the far-future improvement in this area is the Web Components spec, but I think this is something we can improve on right now.
One of the posts on this website that consistently gets a significant amount of traffic (5000+ page views this month alone) is a ridiculous article I wrote that discusses how to make a child element not inherit the opacity setting of its parent.
As we all know, opacity property can be annoying in this area.
Basically, if a parent element has an opacity value set at, say, 0.5, all of its children will inherit that opacity setting, and there’s no way to reverse that opacity on the child elements.
Those of us who have started using modular or object-oriented CSS principles have learned to avoid, as much as possible, the use of the descendant selector (or, more accurately, the descendant combinator).
A selector that uses the descendant combinator looks like this:
Last year, Microsoft announced that IE10 will not be supporting conditional comments. With their history, this is obviously a risky move. Up to now, to target quirky behaviour in IE6-9, developers have been using conditional comments, conditional classes, and other IE-specific hacks.
But without conditional comments in IE10, the only options we’re left with to target CSS problems are hacks or browser sniffing — and we certainly don’t want to resort to the latter.
Interestingly, there have been a few posts and code snippets floating around that apparently do target IE10 specifically using a hack. Below is a summary of these three techniques, for reference.
The other day, someone asked me the following question: “If I understand it right clear float is automatic in most modern browsers right?”
If you’re new to CSS, then it would seem that the answer to this question should be “yes, of course — modern browsers don’t have these types of bugs!” But the necessity to clear floats is not a browser bug; it’s actually, well, more of a CSS feature. And it’s still needed in so-called “modern” browsers (assuming you’re using floats for layout).
Every element in an HTML document accepts a value for the CSS display property. The possible values you can use for displayare many.
The three most commonly used values are none, block, and inline. But what if you don’t define a display value for an element? Well, all elements have an initial or default state for their display value. Let’s consider some of these and see some interesting things you might not have known.
The CSS3 Transitions spec maintains a list of properties that are animatable. This list, as far as I know, covers animatable properties for both transitions and keyframe animations.
But that’s a list of properties. And so, since CSS3 gradients are not really properties, but are actually images created by the browser, they aren’t in that list of animatable properties. But that doesn’t mean you can’t animate gradients.
Gradients, just like standard images, are subject to certain background-related properties that are animatable. These include background-size and background-position.
Here’s a crazy and ridiculous tip that probably has limited uses, but illustrates some quirky possibilities with CSS3 transitions. I’ve written something about this before and Chris Coyier explained the basic concept on his site.
But in this quick post I’ll show you how to make an element have a “mouseout” or “mouseleave” transition with no “mouseover” or “mouseenter” transition.