Multiple Class / ID and Class Selectors

Can you spot the difference between these two selectors?
#header.callout { }

#header .callout { }
They look nearly identical, but the top one has no space between “#header” and “.callout” while the bottom one does. This small difference makes a huge difference in what it does. To some of you, that top selector may seem like a mistake, but it’s actually a quite useful selector. Let’s see the difference, what that top selector means, and exploring more of that style selector.
Here is the “plain English” of “#header .callout”:
Select all elements with the class name callout that are decendents of the element with an ID of header.
Here is the “plain English” of “#header.callout”:
Select the element which has an ID of header and also a class name of callout.
Maybe this graphic will make that more clear:

Combinations of Classes and IDs
The big point here is that you can target elements that have combinations of classes and IDs by stringing those selectors together without spaces.
ID and Class Selector
As we covered above, you can target elements by a combination of ID and class.

This Should Be Red

#one.two { color: red; }
Double Class Selector
Target an element that has all of multiple classes. Shown below with two classes, but not limited to two.

Double Class

.three.four { color: red; }
Multiples
We aren’t limited to only two here, we can combine as many classes and IDs into a single selector as we want.
.snippet#header.code.red { color: red; }
Although bear in mind that’s getting a little ridiculous =)
Example
So how useful is all this really? Especially with ID’s, they are supposed to be unique anyway, so why would you need to combine it with a class? I admit the use cases for the ID versions are slimmer, but there are certainly uses. One of those is overriding styles easily.
#header { color: red; }
#header.override { color: black; }
The second targets the same element, but overrides the color, instead of having to use:
.override { color: black !important }
or perhaps prefacing the selector with something even more specific.
More useful is multiple classes and using them in the “object oriented” css style that is all the rage lately. Let’s say you had a bunch of divs on a page, and you used multiple various descriptive class names on them:

They all share the class “box”, which perhaps sets a width or a background texture, something that all of them have in common. Then some of them have color names as classes, this would be for controlling the colors used inside the box. Perhaps green means the box has a greenish background and light green text. A few of them have a class name of “border”, presumably these would have a border on them while the rest would not.
So let’s set something up:
.box { width: 100px; float: left; margin: 0 10px 10px 0; }
.red { color: red; background: pink; }
.blue { color: blue; background: light-blue; }
.green { color: green; background: light-green; }
.border { border: 5px solid black; }
Cool, we have a good toolbox going here, where we can create new boxes and we have a variety of options, we can pick a color and if it has a border or not just by applying some fairly semantic classes. Having this class name toolbox also allows us to target unique combinations of these classes. For example, maybe that black border isn’t working on the red boxes, let’s fix that:
.red.border { border-color: #900; }

Border color on red box changed because it had both the red class and border class
Based on this demo page.
Specificity
Also important to note here is that the specificity values of selectors like this will carry the same weight as if they were separate. This is what gives these the overriding power like the example above.
Browser Compatibility
All good current browsers support this as well as IE back to version 7. IE 6 is rather weird. It selects based on the first selector in the list. So “.red.border” will select based on just “.red”, which kinda ruins things. But if you are supporting IE 6, you are used to this kind of tomfoolery anyway and can just fix it with conditional styles.

Use Firebug in Any Browser

Just include this script on the site and you’ll get a Firebug console that pops up for debugging in any browser. Not quite as full featured but it’s still pretty helpful! Remember to remove it when you are done.

Keep Flash Behind Other Elements

For example, a dropdown menu going “behind” a flash movie, or staying on top of a lightbox layover.
Try This #1
Add this to the Flash embed code:


Try This #2
Make sure the element that is supposed to be on top has positioning (fixed, relative, or absolute) and a z-index value higher than the Flash object.

CSS Centering – fun for all!

How do you center a containing block on a page using CSS? There are two main methods and the choice should be made based on whether your page layout is liquid (will move in and out depending on the size of the browser window) or fixed width.
Centering liquid layouts
Liquid layouts are easy to center using margins on each side of the containing box. The margins can be set with em, pixel or percentage units.
div#container
{
margin-left: 10%;
margin-right: 10%;
}
Centering fixed-width layouts
Theoretically, you should be able to apply auto margins to the left and right of the containing block and it should center on the page.
The W3C Visual formatting model states: “If both ‘margin-left’ and ‘margin-right’ are ‘auto’, their used values are equal. This horizontally centers the element with respect to the edges of the containing block.”
So, a containing block should be able to be centered using the following rules:
div#container
{
margin-left: auto;
margin-right: auto;
width: 50em;
}
However, some browsers do not center the containing blocks using this method as they ignore the auto margins. These browsers include:
• NN4 (Mac and Win)
• Win/IE4
• Win/IE5
• Win/IE5.5
• Win/IE6 (when in quirks-mode)
By adding two simple rules, this problem can be overcome in all of the browsers mentioned above, excluding NN4.
1. Center the body
While these browsers ignore auto margins, they will follow “text-align: center”. If this is applied to the body, the containing block will center correctly. So, a new rule is added:
body
{
text-align: center;
}

div#container
{
margin-left: auto;
margin-right: auto;
width: 50em;
}
2. Resetting text-align
The only problem with this new rule is that all content on the page is now center-aligned. To overcome the center alignment problem, a new declaration is added within the containing block rule set – “text-align: left”. The final CSS code is:
body
{
text-align: center;
}

div#container
{
margin-left: auto;
margin-right: auto;
width: 50em;
text-align: left;
}

Optimizing HTML

Why clean markup?

Client-side optimization is getting a lot of attention lately, but some of its basic aspects seem to go unnoticed. If you look carefully at pages on the web (even those that are supposed to be highly optimized), it’s easy to spot a good amount of redundancies, and inefficient or archaic structures in their markup. All this baggage adds extra weight to pages that are supposed to be as light as possible.

The reason to keep documents clean is not so much about faster load times, as it is about having a solid and robust foundation to build upon. Clean markup means better accessibility, easier maintenance, and good search engine visibility. Smaller size is just a property of clean documents, and another reason to keep them this way.

In this post, we’ll take a look at HTML optimization: removing some of the common markup smells; reducing document size by getting rid of redundant structures, and employing minification techniques. We’ll look at currently available minification tools, and analyze what they do wrong and right. We’ll also talk about what can be done in a future.
Markup smells

So what are the most common offenders?
1. HTML comments in scripts

One of the gross redundanies nowadays is inclusion of HTML comments — — in script blocks. There’s not much to say here, except that browsers that actually need this error-prevention measure (such as ‘95 Netscape 1.0) are pretty much extinct. Comments in scripts are just an unnecessary baggage and should be removed ferociously.
2. sections

Another often needless error-prevention measure is inclusion of CDATA blocks in SCRIPT elements:



It’s a noble goal that falls short in reality. While CDATA blocks are a perfectly good way to prevent XML processor from recognizing < and & as start of markup, it is only the case in true XHTML documents — those that are served with “application/xhtml+xml” content-type. Majority of the web is still served as “text/html” (since, for example, IE doesn’t understand XHTML to this date), and so is parsed as HTML by the browsers, not as XML.

Unless you’re serving documents as “application/xhtml+xml”, there’s little reason to have CDATA sections hanging around. Even if you’re planning to use xhtml in a future, it might make sense to remove unnecessary weight from the document, and only add it later, when actually needed.

And, of course, an ultimate solution here is to avoid inline scripts altogether (to take advantage of external scripts caching).
3. onclick=”…”, onmouseover=”“, etc.

There are some valid use cases for intrinsic event attributes, such as for performance reasons or to target ancient browsers (although, I’m not aware of any environment that would understand event attributes — onclick="...", and not property-based assignments — element.onclick = ...). Besides well-known reasons to avoid them, such as separation of concerns and reusability, there’s a matter of markup pollution. By moving event logic to external script, we can take advantage of that script’s caching. Event handler logic doesn’t need to be transferred to client every time document is requested.
4. onclick=”javascript:…”

An interesting confusion of javascript: pseudo protocol and intrinsic event handlers results in this redundant mix (with 106,000 (!) occurrences). The truth is that entire contents of event handler attribute become a body of a function. That function then serves as an event handler (usually, after having its scope augmented to include some or all of the ancestors and element itself). “javascript:” addition merely becomes an unnecessary label and rarely serves any purpose.
5. href=”javascript:void(0)”

Continuting with “javascript:” pseudo protocol, there’s an infamous href="javascript:void(0)" snippet, as a way to prevent default anchor behavior. This terrible practice of course makes anchor completely inacessible when Javascript is disabled/not available/errors out. It should go without saying that ideal solution is to include proper url in href, and stop default anchor behavior in event handler. If, on the other hand, anchor element is created dynamically, and is then inserted into a document (or is hidden initially, then shown via Javascript), plain href="#" is a leaner and faster alternative to “javascript:” version.
6. style=”…”

There’s nothing inherently wrong with style attribute, except that by moving its contents to an external stylesheet, we can take advantage of resource caching. This is similar to avoiding event attributes, mentioned earlier. Even if you only need to style one particular element and are not planning to reuse its styles, remember that style information has to be transferred every time document is requested. Moving style to external resouce prevents this, as stylesheet is transferred once and then cached on a client.
7.

The thing is that charset attribute only really makes sense on “external” SCRIPT elements — those that have “src” attribute. HTML 4.01 even says:

Note that the charset attribute refers to the character encoding of the script designated by the src attribute; it does not concern the content of the SCRIPT element.

Testing shows that actual browsers behavior also matches specs in this regard.

Searching for this pattern, reveals about 2000 occurrences. Not suprising, given that even popular apps like Textmate include wrong usage of charset.



Copyright http://perfectionkills.com/optimizing-html/

Shadows and CSS3

Text-shadow

Applying text-shadow to elements is easy, and coupled with RGBA it works beautifully. Since both text-shadow and RGBA are supported by Safari, Firefox, Konqueror, and Opera, why not start playing with them now?

Text shadow is sexy.

If you’re using one of the aforementioned browsers, you should see a nice drop shadow on the text above. (If you’re not — why?) This drop shadow is created using the following code:

text-shadow: 1px 1px 1px rgba(0,0,0,.4);
Breaking it down

* The first 1px indicates how much the shadow should be offset horizontally; in this case we’re telling the shadow to appear one pixel to the right. Using -1px would move the shadow one pixel to the left.
* The second 1px indicates how much the shadow should be offset vertically; in this case we’re telling the shadow to appear one pixel lower than the text. Using -1px would move the shadow one pixel above the text.
* The third 1px value tells the shadow how much it should blur. Using 0 for this value would create a solid drop shadow, which has a blocky, high-contrast effect. Using only this value (ex. text-shadow: 0 0 1px rgba(0,0,0,.4);) would create an outer glow.
* rgba(0,0,0,.4); gives the shadow its color. In this case we’re using (0,0,0), which is the RGB value for black, and we’re giving that black an opacity of 40%, or .4.

Why use RGBA for the shadow color?

Using RGBA instead of a solid color for the shadow is great because it allows some of the page’s background color to bleed through. This means that the shadow will blend nicely with the page’s existing color scheme, and if you ever change up the site’s background color your shadows will change too. If you’re unclear about how rgba works, check out Drew McLellan’s 24ways article.

So now you should be able to implement text-shadow and RGBA in your designs. This technique is very powerful, as it can be used to make text jump off the page:

Text shadow is sexy.

or appear to be set into the page:

Text shadow is sexy.
Box shadow

Once you know how to use text-shadow + RGBA to achieve drop shadows, you’re well on your way to mastering box-shadow. The syntax is exactly the same, so box-shadow: 0 1px 10px rgba(0,0,0,.1); will create a black shadow at 10% that’s centered horizontally, one pixel down, with a ten pixel blur.

test image

Misty the one-toothed cat thinks box shadow is awesome.

Box shadow is supported in Safari and Firefox 3.5, but like border-radius it requires the use of vendor-specific properties. So assuming we wanted to add a drop shadow to an image in Safari and Firefox, here’s how we’d code it:

-webkit-box-shadow: 0 1px 10px rgba(0,0,0,.1);
-moz-box-shadow: 0 1px 10px rgba(0,0,0,.1);
box-shadow: 0 1px 10px rgba(0,0,0,.1);

You’ll notice I included the standard box-shadow property; this is in place for future browsers who may one day support this property.

There you have it! Once again your shadow blends nicely with the background because you’re using RGBA, and creates a kick-ass 3-D effect with minimal markup.

Box-shadow and text-shadow may not be for every project, but since they’re so easy to implement and browser support for these features is growing, why not try them out?

I can hear some of you naysayers yelling about Internet Explorer, but really is it so bad if some users get to see shadows and some don’t? The design won’t be broken for IE people, they’re just missing out on a few visual treats that other users will see.

If you’re not sold on the argument that we should reward users who choose modern browsers, check out Dan’s Handcrafted CSS book, Aaron Gustafson’s A List Apart article and Andy Clarke’s multiple well written articles on the subject.

This entry was posted on Monday, December 14th, 2009 at 4:42 pm and is filed under CSS3, Tips, web design. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Copyright: http://owltastic.com/2009/12/shadows-and-css3/

@font-face Browser Support & Tutorial

Up to now, web developers were limited in what typography they could use on a website to what the client had installed in their environments. Now that we have finally convinced designers to not include any fonts outside of georgia, helvetica, arial, times roman, and a handful of others because of the awfulness of text images, @font-face allows us to retrain designers to use unique fonts, only if they have the legal right to post those fonts on the web.

What is @font-face

Generally, we’ve been limited to using the fonts pre-installed on MS Windows, Mac and Linux OSs. Increasing support of the CSS3 @font-face allows us to load a font onto our servers, link to and name that font in our CSS, and then use that font we’ve imported as if it were a native font in the client’s environment. With @font-face, we can worry less about what font our users have installed, and make our sites better match the intentions of our designers. @font-face enables you to provide your own font(s), @font-face eliminates the need to depend on the limited number of fonts users have installed on their computers

Browser Support for @font-face

CSS2 introduced @font-face. CSS2.1 killed it. CSS3 is reintroducing it. Why do you need to know the history? Because, it means there is actually a feature of CSS3 that internet explorer supports, albeit, differently than all other supporting browsers.

Because I am browser support table happy, here is the @font-face browser support table:
CSS Property IE6 IE7 IE8 Safari iPhone Chrome Firefox Opera
@font-face 3.2 4.0.249.78 3.5 10
format EOT EOT EOT TTF/OTF 3.1 supports SVG TTF/OTF support added 1/25/10
SVG supported by default TTF/OTF TTF/OTF

* SVG is supported, but it’s a larger file size
Google Chrome and @font-face:

Google Chrome actually does support @font-face, but it was turned off by default until version 4.0.249.78 released on 1/25/20. Chrome has supporte SVG fonts for a while now.

While developers have been able to turn on @font-face support in Chrome in their own environment, only Chrome users who have updated to the January 25, 2010 release have it on by default. Google chrome users tend to be quick at updating, but stats don’t indicate the version number, so as of right now you can’t assume that Chrome has @font-face turned ON as the default settings for most users. Like with all site enhancement features, feel free to include fonts of type TTF/OTF, but make sure to pick a font backup that degrades nicely.

Note: Digging deeper, I found Becoming a font embedding master which both explains a link on where you can convert TTF2EOT so you can display similarly on IE than on good browsers (yeah, I said it) and exporting to SVG for font support on iPhone 3.1, Chrome 2 & 3, and 4 less than 4.0.249.78, and Opera 9 (your SVG font will work in Opera 10 and future versions of FF, Chrome, iPhone and Safari as well). Also check out FontSquirrel to convert your font files to differing formats (EOT, SVG, WOFF) for greater browser support. WOFF is a new format that Mozilla is hoping will become the browser standard. It is supported in FireFox only, as of FF3.6
Internet Explorer and @font-face:

Internet Explorer has been implementing @font-face support since version 4*. In any event, it is defintely supported in IE6, IE7 and IE8. However, their implementation relies on Embedded Open Type (.eot), a proprietary format, which no other browsers use. To make IE users happy (which some could argue you shouldn’t, as a method to encourage them to upgrade), import EOT fonts in addition to TTF/OTF fonts, and included them as "fall backs" in the font family declaration (discussed in @font-face implementation below) . FontSquirrel is a place where you can convert fonts you can legally distribute to EOT (and SVG) format.

* Note: Most people say original support of @font-face was IE5. I am not sure and I am not going to pull out my 286 to check. However, with a search, I found that IE4 had a few rendering issues, like not rendering anything on the page until the font was downloaded, so I am sticking with 4.
@font-face implementation

The syntax for the @font-face implemenation is:

@font-face {
font-family: yourNameForTheFont; /* required */
src: source; /* required */
font-weight: weight; /* optional */
font-style: style; /* optional */
}

The font-family name can be anything you make up. I like to make it one word, for ease of entering it correctly as a value of the font-family property of a CSS selector later.
Declaring font-family source(s):

The source can take several formats. In addition, you can declare more than one source. If the browser doesn’t find the first source, it will go for the next source, and so on, until it either finds a source, or it runs out of sources. Example formats include:

@font-face {
font-family: curlyQ;
src: url('../fonts/makeUpSomethingElse.eot');
src: local('Edwardian Script ITC'),
url('../fonts/EdwrdScrpItc') format('opentype'),
url('../fonts/GaelicWimsy') format('svg'),
url(data:font/otf;base64,T1RUTMillIONsOfLETteRsInaROW12fAtGrrYUUUUBx);
}

In the above example, I’ve listed 5 sources. A bit excessive, but I wanted to explain those five components, so I made an excessive example.

The first declaration is for IE. IE ignores local, which is the first declaration in the second listing. In this way, IE only downloads what it needs and doesn’t download stuff it doesn’t understand.

Next I declare a font local to the user’s machine: local('Edwardian Script ITC')**. This looks for the font file locally on the site visitors computer. IE ignores local, which is great, since it will then ignore the other stuff it doesn’t understand. If you don’t have a local font style to declaration, it is OK. IE also doesn’t understand the multiple listings or the format, so as long as you include local, more than one declaration or a declaration with a format suggestions, IE will do o.k. IE will either ignore in the case of local, or misunderstand it, if there is a format or more than one declaration withing a property/value pair.

If your suggested format is incorrect, as long as the file is an understood format, it should work in Safari, Opera and Firefox.

The next example looks for a file in the SVG format. This is what you are feeding to Chrome and Opera 9.

The last example is a data example, cut way short. Actual fonts will have a few thousand characters. Similar to how you can include a data source for images, you can include them for fonts. TypeKit (described below) actually serves their fonts up in data format to Firefox and Safari, and serves EOT for IE.

**Note: Watch this page become the first google results for Edwardian Script. That would be funny. None of these examples are actually meant to work. I made the URLs and file names up.
Applying imported fonts with CSS selectors

Once the font is declared using the @font-face syntax, you can then refer to it as you would helvetica, arial, etc. Using the example above:

h3 {
font-family: yourNameForTheFont, curlyQ, arial, helvetica, sans-serif;
}

Note that I have included two imported font family names. That is legal. Note that I have also included common fonts and a default font. That is HIGHLY recommended.
TypeKit

While the TypeKit website indicates support for Firefox 3.5+, Safari 3.4+ and all versions of IE, parsing the TypeKit javascript, they have support for the following browser engine versions:
Browser Type Version
Gecko 1.9.1
Safari 525.13
Chrome

4.249.4
supported by TypeKit.
Chrome has @font-face support turned off by default
IE 6.0
iPhone specifically excluded in Typekit
Opera not included in Typekit, though Opera Supports @font-face

However, I am reading obfuscated code, so I could be talking out of my tushy. I did test in those browsers (not necessarily those versions, but those browsers), and it works in all except iPhone.

The way TypeKit works is you join TypeKit, enter the domain you want to use TypeKit on (you’re only allowed one domain for the free version), and select the fonts you would like to enable for that domain. TypeKit provides you with a link to a script file and a javascript snippet to add to your document . TypeKit also provides you with a class that you can add to elements that you want to have the font, and provides you with a snippet of CSS code for the font-family property that you can sprinkle your CSS with for selectors where you want to use the TypeKit font.

The TypeKit javascript that you attach to your code basically does a LOT of browser sniffing, and only serves up to Gecko, Safari (not iPhone), Chrome and IE6+. Since it is sniffing, it doesn’t serve up any CSS to browsers not in the sniffing. So, while Opera10 does support @font-face, TypeKit does not.
Microsoft WEFT

The Microsoft WEFT is a free utility to create linked font objects. WEFT font objects are compressed and are privately installed by IE in a way that is inaccessible to other applications on the computer and other websites. WEFT supports OpenType (OTF) and TrueType (TTF) fonts in TrueType (TTF) format.
Legalese

The main issue with @font-face is the ownership of the fonts. Make sure you are legally allowed to upload and share a font before using @font-face, as when you embed a font, that is what you are doing: sharing a file. Just like music, for most fonts it is illegal to upload and share without proper attribution and/or payment.

Copyright http://www.evotech.net/blog/2010/01/font-face-browser-support-tutorial/

Just IE6 PNG fixes? Mmm how about this?

We all hate IE6

This browser is crap and we all know it. Unfortunately, some clients demand support for this browser so we can’t avoid having some workarounds for it.

PNG Images

.png images have the best quality and fidelity for our web designs. Their best feature is their seamless and smooth transparency. We can achieve transparency with .gif files but their smoothness are not even close to .png files.

There are many times where our designs need a transparent .png and we also need to add support for IE6. So… what do we do?

PNG fixes to the rescue!

PNG fixes are mostly javascript (sometimes css) solutions for fixing IE6’s lack of transparency support for.png files. There are various PNG fixes. Here are some of them:

• Unit PNG Fix (JS)
• DD_belatedPNG (JS)
• Komodo Media’s PNG Fix (CSS)

The good thing about PNG fixes

1. They are easy and fast to setup.
2. They get rid of the problem in most cases.

Problems using PNG fixes

Well, unfortunately, it’s not everything as nice as cupcakes and rainbows. I’ve encountered some problems using PNG fixes:

1. Background-image support is quite poor (repeats and positions specially).
2. It’s a pain in the ass if you are using CSS sprites.
3. Sometimes the proportion of the images gets screwed up.
4. You add another javascript file to your page.
5. In CSS workarounds the code isn’t pretty and fails W3C’s validation.

Ok… so what now?

Well, I have my own workaround for transparent .png’s in IE6. Maybe you will like it, maybe not, but I wanted to share the technique in case it comes in handy for you.

I don’t use transparent PNG’s for IE6

That’s right. I use .gif files instead.
Sorry to dissapoint, but I believe this is the way to go.
The quality of our images decreases of course, but we are embracing and accepting the browser’s limitations.

Copyright: http://thecssblog.com/tips-and-tricks/just-ie6-png-fixes-how-about-this/