This’ll allow you to specify an opacity value (between 0 and 1) and have LESS automatically add in the necessary IE filters, converting it to an IE opacity value (between 0 and 100).
LESS CSS class for cross browser opacity
6 Replies
Tag Archives: CSS
LESS CSS clearfix
The fantastic clearfix, as a LESS CSS class:
.clearfix {
zoom: 1;
&:before, &:after {
content: "";
display: table;
}
&:after {
clear: both;
}
}
Use in your code like so:
ul#gallery {
.clearfix;
li {
float: left;
}
}
Easy.
Modernizr progressives or exceptions?
Modernizr, what an interesting tool you are. How do I use your class names in my CSS files? You’ve given me a choice and I’m not sure what to use:
.multiplebgs div p {
/* properties for browsers that
support multiple backgrounds */
}
.no-multiplebgs div p {
/* optional fallback properties
for browsers that don't */
}
There are two ways to view this, bottom up, and top down. They both have their advantages and disadvantages, and I’m going to attempt to highlight these for you, so you can make your own decision.
Bottom up
For the “bottom up” way of doing things, we define a lowest common denominator. A set of styles that will work with all the browsers your website is designed to target. The intersection of all the features of all your browsers, if you want to put it that way. From here, we use Modernizr to progressively enhance the user’s browsing experience for browsers that support particular features. An example may help:
a.btn {
background:transparent url(../img/btn-red.gif) no-repeat scroll 0 0;
padding:5px;
display:inline-block;
width:40px;
}
.borderradius a.btn {
background-color:red;
background-image:none;
border-radius:5px;
}
The advantages being:
- A clearly defined baseline that works on all browsers we’re coding for
- If we aren’t able to determine client features (because for example, Modernizr is not available: the CDN is down, or the client doesn’t have JavaScript enabled) we know that the baseline styles will be used and will ensure the site looks acceptable regardless
The disadvantages are:
- We end up writing more and more CSS as we utilise new features that become available
- It doesn’t encourage a particularly forward thinking coding practice. You’re essentially coding for the browser with the lowest feature set
- If you want to change the baseline styles because of a redesign or perhaps your baseline is raised, you’re probably going to have to change overridden styles in the progressive enhancement style blocks as well
Top down
The “top down” approach is where we define styles for new browsers, and then use the “no-” prefix classes to define exceptions for browsers that don’t support the feature we’re exploiting. e.g.
a.btn {
border-radius:5px;
background-color:red;
padding:5px;
display:inline-block;
width:40px;
}
.no-borderradius a.btn {
background:transparent url(../img/btn-red.gif) no-repeat scroll 0 0;
}
We’re forward thinking, assuming everyone viewing our site is using these great new features and coding in fallbacks for the exceptions to the rule. Our view is that one day, all browsers will support the styles we’re using…and we’re adding in exceptions for in the mean time. The advantages are:
- We end up writing less CSS, as we don’t have to override properties we’ve previously declared that the browser doesn’t understand
- Our mindset is altered slightly, encouraging us to make use of and exploit new browser features that allow us to code and prototype faster
- As our browser baseline increases, it’s really easy to remove exceptions that are no longer used
The disadvantages are:
- We’re totally relying on Modernizr and the browser having JavaScript enabled. Without JavaScript the “no-” prefixed classes are not added to the <html> element and the browser is left trying to style things that aren’t supported or use style declarations that don’t exist (as far as the browser knows).
Well, sort of. You could always use the “no-js” class on the <html> element which Modernizr normally removes and replaces with “js” (to indicate JavaScript is available). You’d define your styles as above, but then define a lowest common denominator style set, for when you don’t know what features a browser does or doesn’t support. That’s kind of overkill though.
So, that’s basically it. When I first thought about it my gut reaction was to sit in the bottom up camp, but after thinking about it, and considering the audience for the project I’m working on it makes more sense to use the top down approach. Especially now that I’ve written it down like this. I’m hoping it’ll help others to make the right decision.
Highlight text using jQuery and the HTML5 mark tag
Here’s a jQuery plugin I wrote that’ll add HTML5 <mark> tags around keywords or phrases in an element’s body text.
What is mark?
a run of text in one document marked or highlighted for reference purposes, due to its relevance in another context
http://www.whatwg.org/specs/web-apps/
Usage
Add the script to your page, and then when the DOM is ready, do something like:
$('body').mark('Lorem ipsum');
The plugin can actually be used to wrap any tag around keywords. Simply pass the tag name you want to use as an option:
$('body').mark({
text: 'Lorem ipsum',
tag: 'span',
cssClass: 'mark'
});
The above example will wrap span elements around the words lorem and ipsum. Each span element will have the class ‘mark’. View an example implementation.
TODO
- Input sanitation on the text to be marked. Currently the text is dumped straight into a regular expression. It needs to be escaped so that any regular expression meta-characters are interpreted as literals.
- Similarly, HTML special characters in the input need to be expanded into their HTML entities.
- From what I can see, IE doesn’t like <mark> tags, and seems to automatically self close the opening and closing tags inserted into the DOM. WTF? Can anyone shed any light on this problem? For now, you’re going to have to use a <span> with a CSS class
If you’re interested in contributing, get in touch
em, and the two zooms
Back in the days before browser “zoom”*, making text bigger on the page was done by incrementing all the font sizes in the document. All fonts set at 16px became, for example 18px, and all fonts at 20px became 22px.
The problem with this was that often text would outgrow the element it appeared in, because the element was also given a width and height in pixels and this didn’t get scaled as the text size increased or decreased.
Sometimes even if you built a site that allowed text to grow and wrap, it would get to a stage where a single long word was wider than its container, and the overflow would have to either be hidden, or just left visible to run into whatever element was placed on the immediate right. Not only that, but there are just some situations where you don’t want elements to wrap – whether they’re text nodes, floated elements with text in them, or inline-bock elements that you often find in navigation lists.
We didn’t want text zoom, we wanted magnification zoom i.e. the zoom that we have nowadays…but it didn’t exist.
Em to the rescue! Luckily, the em unit is intrinsically linked to text size. It is a relative unit, meaning that the actual size of an em depends on the font-size of its container. Clever people figured out that you could simulate magnification zoom if you measured all your widths and heights using relative units.
How does that work?
Well, if your font sizes are all increased, and everything else is measured in em’s (the width of the letter ‘M’), then everything else gets bigger as well, in proportion. Hooray!
Sure, but why would we use them nowadays?
Firstly, if someone is using an old browser that doesn’t support magnification zoom, or is using the (still existing) older text size zoom, you don’t get the problems I’ve just described above that are inherent to text zoom.
Secondly, if you never define an absolute text size for your document, your viewers are free to set their own default text size (On Firefox you can do this by visiting preferences > content > fonts & colours), and your layout will change size to accommodate. Almost all browsers set their text size at 16px by default, so if you use this as your base – i.e. 16px = 1em, then your site will be the size your designer is probably expecting it to be.
I use em’s for almost all units that could also be expressed in pixels, or percentages or whatever. Percentages almost certainly have a very important place as well, but unless you’re working with a fluid design they’re not a necessity.
* Which, for your reference, works by changing the definition of how big a pixel is on your screen. It means you’re really working with points, not pixels, but that’s by the by.