Posts Tagged ‘CSS’

Triangles in CSS

Wednesday, March 25th, 2009

I was reading Image-free CSS Tooltip Pointers and realized the trick of triangles in CSS. These odd little polygonal things have been around for awhile, but I just now figured out how the triangle works.

Basically, where two borders meet (e.g. border-top and border-left), a diagonal line is drawn where they meet, making a neat bezel effect, rather than having the top border sit above the left border. For example:

On the div above, you can see the diagonal lines where the borders meet.

1
<div style="margin: auto; border: 10px solid red; border-left-color: blue; border-right-color: green; border-bottom-color: yellow; height: 20px; width: 20px; background: gray;"></div>

Taking advantage of this, it’s easy to set the color of some borders to transparent and end up with a polygon.

1
<div style="margin: auto; border: 10px solid red; border-left-color: transparent; border-right-color: transparent; border-bottom-color: transparent; height: 20px; width: 20px;"></div>

Take that principle and mess around with it, and you can make triangles. For example:

Above, you have north, south, east, west, northeast, northwest, southeast, and southwest (in no particular order).

1
2
3
4
5
6
7
8
9
10
 <div style="position: relative; width: 100px; height: 100px; margin: auto;">
  <div style="width:0; height:0; border-left: 5px solid transparent;  border-right: 5px solid transparent; border-top: 5px solid blue; border-bottom: 0; position: absolute; bottom: 0px; left: 50%;"></div> 
  <div style="width:0; height:0; border-left: 5px solid transparent;  border-right: 5px solid transparent; border-bottom: 5px solid blue; border-top: 0; position: absolute; top: 0px; left: 50%;"></div> 
  <div style="width:0; height:0; border-top: 5px solid transparent;  border-bottom: 5px solid transparent; border-right: 5px solid blue; border-left: 0; position: absolute; top: 50%; left: 0px;"></div> 
  <div style="width:0; height:0; border-top: 5px solid transparent;  border-bottom: 5px solid transparent; border-left: 5px solid blue; border-right: 0; position: absolute; top: 50%; right: 0px;""></div> 
  <div style="width:0; height:0; border-left: 7px solid blue;  border-right: 7px solid transparent; border-top: 7px solid transparent; border-bottom: 0; position: absolute; bottom: 0px; left: 0px;""></div> 
  <div style="width:0; height:0; border-left: 7px solid blue;  border-right: 7px solid transparent; border-bottom: 7px solid transparent; border-top: 0; position: absolute; top: 0px; left: 0px;""></div> 
  <div style="width:0; height:0; border-left: 7px solid transparent;  border-right: 7px solid blue; border-bottom: 7px solid transparent; border-top: 0; position: absolute; top: 0px; right: 0px;""></div> 
  <div style="width:0; height:0; border-left: 7px solid transparent;  border-right: 7px solid blue; border-top: 7px solid transparent; border-bottom: 0; position: absolute; bottom: 0px; right: 0px;""></div> 
 </div>

So, as you can see, it’s pretty easy to make a triangle. Adjust the border widths to make them bigger.

The State of Web Fonts

Thursday, January 8th, 2009

A long time ago, Microsoft started making use of @font-face (also called web fonts) in CSS. This would have been revolutionary if not for the fact that using fonts required the designer to encode them into a weak DRM file called an EOT, which stands for Embedded OpenType. Open indeed. Things are starting to look up now.

The great thing about Microsoft trying to introduce this is that it would have ended an era of Web Safe fonts and “download this font to view my page properly” messaging before Web Safe fonts were understood. Unfortunately, no other browser bothered implementing the CSS or EOT and @font-face fell into obscurity for many years, forcing web designers to use images of text. EOT’s major flaw was that it pandered to font makers and left web designers jumping through hoops to create font files.

Microsoft apparently has strong corporate ties to certain Font Industry big-wigs, and they didn’t want to upset them. Better to make life hard for your developers than help font makers come up with workable solutions for licensing web fonts (like hosting font files and checking the HTTP_REFERER for the correct domain before allowing access to the font file, which seems as good as the weak DRM of EOT files). When you are the most commonly used browser, I guess you can do stuff like that and still have your CEO chant, “Developers! Developers! Developers!” The problem is that Microsoft didn’t anticipate empowering font creation software like FontStruct that lets mere mortals create fonts under Creative Commons licenses. Frankly, it’s unfair to force me to put DRM on stuff I create if I don’t want it.

Eventually, some good people created sIFR, which allowed designers to (with great effort) cobble together a Flash file that embedded a font. Adding some JavaScript code to the page allowed designers to add fonts in a more accessible, user-friendly manner than simply using images of text. While sIFR had some problems (for example, links in headings were buggy and the text wouldn’t resize with the browser), it was a breath of fresh air. Suddenly, it was only a little work to have nice typographic options for limited use in headers and the like.

Recently, Apple (in the form of WebKit) and Opera have brought back the @font-face. Luckily, Apple and Opera didn’t bend over for the Font Industry. They boldly allowed support of plain-old TrueType fonts. With half of the major rendering engines supporting easy web fonts (and Firefox support on the way), I decided to give EOT another shot. That would allow me to have four out of five browsers (that I support) rendering my fonts out-of-the-box with sIFR as a worse-case fallback.

The results were mixed. Using @font-face is progressive enhancement with CSS and using sIFR is progressive enhancement with JavaScript and Flash. To start, I went through the lengthy and buggy trial and error process of creating an EOT with WEFT. After getting that worked out, I added the following to my screen stylesheet:

1
2
3
4
5
6
7
8
9
10
11
@font-face {
	font-family: "MyFont Sans";
	src: url("../media/myfont_sans.ttf") format("truetype");
}
 
@font-face {
	font-family: "MyFont Sans IE";
	font-style: normal;
	font-weight: normal;
	src: url("../media/MYFONTS0.eot");
}

I could then set a font by specifying font-family: MyFont Sans, MyFont Sans IE, sans-serif;. In Safari, Opera, and Internet Explorer, my site used a custom font. Other browsers fell back so a system chosen sans serif font if the font MyFont Sans was not installed on the system. That gets us half way there.

The next step is to create the sIFR and load it only if it is needed.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
var MYSITE = {
	sifr: true,
	init: function() {
		if(window.getComputedStyle) {
			var ff = document.defaultView.getComputedStyle(h,null).getPropertyValue('font-family');
			switch(ff.toLowerCase()) {
				case 'myfont sans':
				case '"myfont sans"':
				case "'myfont sans'":
					MYSITE.sifr = false;
			}
		} else {
			MYSITE.sifr = false;
		}
		if(MYSITE.sifr) {
			MYSITE.setSifr();
		}
		return true;
	},
	setSifr: function() {
		// Code enabling sIFR
	}
};
 
if(window.addEventListener) {
	window.addEventListener('load', MYSITE.init, false);
} else if(window.attachEvent) {
	window.attachEvent('onload', MYSITE.init);
} else {
	window.onload = MYSITE.init;
}

The script runs after the page loads. Checking for window.getComputedStyle ensures that any standards compliant browser that supports web fonts will not get sIFR, since the browser will report that it is using MyFont Sans. Firefox, if I remember correctly, reports a list of fonts, but it ends up in the result of Firefox getting sIFR. Once Firefox has web fonts support, this script will need to be reevaluated. If the browser doesn’t support getComputedStyle, the browser is (probably) Internet Explorer, which supports web fonts. So, we can turn sIFR off.

Finally, any browser that needs sIFR will execute MYSITE.setSifr();, adding the custom fonts to the page.

This should provide custom font support in most major browsers. The only caveat is that a suitable fallback should be chosen (one that looks similar to the @font-face font, rather than sans-serif mentioned above), as browsers without Flash or without JavaScript will see the fallback font if the browser doesn’t support web fonts.

Since we have a suitable fallback with sIFR when web fonts aren’t available to the browser, there is a good enough methodology for implementing custom typography on live sites that don’t support web fonts. Until Firefox releases support for web fonts, it may be too much trouble to implement. However, in the spirit of progressive enhancement, one could skip the sIFR step and simply allow the installed system font fallback, as pixel-perfect cross browser support is turning into an obsolete, undesirable practice and progressive enhancement is becoming common place.

The final rub is Microsoft’s persistence in supporting EOT and not TrueType or OpenType fonts. While it is possible to get web fonts in Internet Explorer, it is a royal pain to create EOT files. If it’s too much effort, using sIFR or keeping the tenants of progressive enhancement with CSS may be a workable solution.

So, it seems web fonts have almost come of age. Once Firefox supports @font-face, web fonts can be used on a wide scale. While you may not want to jump on the bandwagon yet, it is definitely time to start looking into web fonts.

iUI Makes iPhone Development Easier

Friday, August 17th, 2007

The iPhone was a little less exciting when Apple revealed that web apps were the only way developers could write applications for the iPhone. While committed folks eventually opened the phone up for third-party applications, some interesting stuff was happening on the web application front. It’s called iUI.

iUI is a JavaScript framework to make coding pages for the iPhone really easy. Joe Hewitt’s (of FireFox, FireBug, and FaceBook fame) small JavaScript library can transform simple lists and links into an experience much like a regular iPhone application.

iUI uses many CSS3 properties with images ripped from the iPhone itself to create the distinctive interface, complete with sliding animations and Ajax page replacement. He points out in a Y!UI Theater video that Safari Mobile lacks many events found on regular browsers due to lack of ways to input those events on a touch screen, as well as having no mechanism to access flicks used to scroll in native applications.

Despite the limitations, knowing such an easy to use solution makes me want to download TestiPhone and write something for iPhone, even though I don’t own an iPhone. I would take Eric Meyer’s concerns into account, however.

Easy Clearing Of Floats

Tuesday, April 24th, 2007

Web standards designers often need to make use of display:float to handle things like columns, navigation lists, and more. Usually these floats are followed by something like <div style="clear:both"></div>. It turns out there is an easier way.

I was reading 35 Designers x 5 Questions and saw a link for a way to clear floats without clear divs. The code that comes with the article is a bit confusing and sloppily written, but it works!

So, to make things easier to understand, I wrote my own example. The code below will do it for you.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
 <head>
  <title>Easy Floats</title>
  <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
  <style>
h1 {
	background-color:#FFCCCC;
	margin:auto;
	width:500px;
	text-align:center;
	margin-bottom:0px;
}
div#outer{
	width:500px;
	overflow:auto;
	padding-bottom:0px;
	background-color:#AAAAAA;
	margin:auto;
}
div#column1 {
	float:left;
	background-color:#CCFFCC;
	width:200px;
}
div#column2 {
	float:left;
	background-color:#CCCCFF;
	width:300px;
}
div#footer{
	width:500px;
	overflow:auto;
	padding-bottom:0px;
	background-color:#FFCCFF;
	margin:auto;
}
div p{
	padding:10px;
}
  </style>
 </head>
 <body>
  <h1>title</h1>
  <div id="outer">
   <div id="column1">
    <p>
     Left
     <br>
     Column
     <br>
     Floated
     <br>
     Left
    </p>
   </div>
   <div id="column2">
    <p>
     Right Column float with no clears below it...
    <br>
    </p>
   </div>
  </div>
  <div id="footer">
   <p>
    FOOTER not cleared...
   </p>
  </div>
 </body>
</html>

How To Do Modern Web Design

Friday, January 12th, 2007

I’ve been trying to figure out the best way to explain how to do modern, semantic, standards compliant web design. I’ve been trying to make the point to my current protege that one should first look at a website like a term paper and move on from there. I’ve formulated a method now that I’d like to outline.

I once described how I see web design as a left brain plus right brain task. However, a new A List Apart article called Grok Web Standards breaks it down even more, suggesting that a web designer must think like a writer, artist, and engineer. The article inspired me to write the steps I think web designers should take to making a site.

I must say now that I seriously doubt anyone will ever work this way. It relies on the idea that content is given to the designer first. Rarely, if ever, will a client give you content without seeing a design. This is unfortunate because the goal of a website is to communicate a point. Looking pretty is the icing. You won’t be able to bake a cake without letting the client taste the icing first until you have a very good reputation. However, I hope my steps are written well enough that, if need be, designs can be done first.

How To Do Modern Web Design

  1. Understand Your Content

    Content is king. Before you touch an editor, read your content and understand it. Once you understand what you want to present, it becomes easier to mark up and will give you ideas on how you want to present the content to the user. Make a mental outline of what is in the content to help make decisions. To be clear, content does not just mean the text on the page. Content includes navigation and footer information as well as regular page content and images.

  2. Format Your Content

    The first goal of a site (web apps excluded) should be to present a message in a clear manner. The best way to do this is to make sure your markup is structured and semantic. I like to think of it as manually marking up a term paper or essay. Term papers must be clearly arranged and defined in logical sections. Lists should be presented as lists, paragraphs as paragraphs, and headings as headings.

    Every designer should have some boilerplate to work with. That is, having a very simple HTML template with basic elements (e.g. DOCTYPE, head, title, body, and any other basic elements you usually work with) will save you a few minutes up front and allow you to get down to business. Smultron, for example, has this built in. If you don’t, write a basic, empty HTML document. Don’t include stylesheets yet.

    To qualify the previous paragraph, boilerplate is only really needed if you want to validate as you go. If you trust your ability to write valid disembodied markup, just bang out the markup in a text editor without the rest of the code. It’s how I’m writing this post since it’s going to be injected into a design that has the rest of the code. In the end, you might save some time by not using boilerplate (e.g. if you have tons of pages that will need extra elements inserted during step four below). For the beginners, though, understanding the document structure will be more useful than the time saved by skipping out on it.

    Your task is to turn your content into something logical, legible, and semantic. Use your understanding of the content to create a document. Based on your mental outline, use headings with the correct level (typically the document title should be the first level heading, for example), lists, paragraphs, blockquotes, tables for tabulated data. Give emphasis, citations, and hyperlinks. Front load your lists if you need to. Don’t use divisions, fonts, or styles. Do rely on the browser’s built in formatting. Default styles are well thought out by the browser maker. You just want to make sure your content makes sense. Yes, it looks boring, but it also looks clean. When you view your document in a browser with no stylesheets, it should make sense when you try to read it.

  3. Design For Your Content

    By now, you should be pretty intimate with the content. You should have a clear idea about what the content is about. This will allow you to create a design that helps present that content in a truthful manner. Take what you know about your content and mockup something that can present it well. I suggest using Photoshop to work on mockups at this point. This will keep you from having to write a big stylesheet when you don’t know if you need it.

    Also, focus on usability. People that come to this site have no knowledge of how you intended them to use it. They have certain knowledge about the way the web usually works. It’s best to take that into consideration. If you break from tradition, you need to make it obvious how you intend the user to interact with the site.

    After you are certain that the content is accurately represented and the design is usable, then worry about aesthetics.

    Typically, clients will want to approve a design. So, make a good composite to show off. You may even want to do a little HTML and drop a full-sized composite into a browser so the client can get a feel of how it would look.

    If it turns out that you have to do this step first, you should have an idea about what sort of content the client wants to be on his site. You may have to use your imagination a little more. Don’t worry, though. This is where most people have to start, and I believe starting here can still produce a great site, even if it isn’t the most ideal place to start.

  4. Start Merging Content and Design

    Open your basic document in FireFox, Opera, or Safari. Since these browsers basically agree with one another, this will help you start with a standards compliant site. Now is when you want to start working on your stylesheets.

    Start coding your stylesheet based on what you already have. Before, people misused tables to create designs. Using web standards, people tend to get div diarrhea. Instead of using elements that exist, people put divs around everything whether they need it or not. So, I suggest making creative use of headings, navigation lists, and paragraphs to trim down your stylesheet as much as possible.

    The best place to start is by throwing out some of the default formatting. I know I just said it was well thought out. It still is. It just isn’t well thought out for your design.

    The first part of my main stylesheet clears margins, paddings, and borders (i.e. *{margin:0px; border:0px; padding:0px;}). From there, it’s the designers job to figure out the best proximity. It also forces the designer to take a better look at default behavior and hopefully start coding it out (or coding it in) to have well thought out alignment and contrast, which makes cross-browser compatibility a little easier to achieve.

    As you go, you will probably find that you need a div here and there to help represent a certain aspect of your design. For example, I like my designs centered on the page. In HTML 4, the best way to do this is a div that has margin: auto wrapped around all the content (though in real XHTML, the html and body elements can be used to achieve the same ends with no extra markup).

    So, add extra divs when you absolutely need them, and make sure to either code in or code out default styles. Be creative, though. It’s your job. Usually the easiest solution is not the best.

  5. Make Sure It Is Accessible

    A pretty design is useless if it isn’t a good design. Good designs are accessible to the most number of people possible. So, audit your site and make sure there aren’t any serious accessibility problems. Make sure images have meaningful alt tags, form elements have labels, etc. Don’t forget niceties like skip to content links. This section really deserves an article of its own. So, I won’t go into much detail.

    Since I’m on a Mac, I’ve familiarized myself with browsing web sites with VoiceOver. While it isn’t as good as the other web screen readers, it helps me get an understanding of what the page might be like. I highly suggest this (or some similar testing) be part of the audit if you have access.

  6. Debug for Internet Explorer

    Internet Explorer 7 was supposed to bring in a new age of standards compatibility. It didn’t. Even if it did, use of Internet Explorer 6 is still rampant. In the old days, stylesheet hacks were the way to account for differences in browser rendering (fighting bugs with bugs). Now, though, Internet Explorer has a proprietary concept called conditional comments.

    This is the first proprietary HTML concept Microsoft has created that is worth a damn. Conditional comments allows the designer to hide or show page content in Internet Explorer based on variables such as browser name or browser version. So, we create a conditional comment to show our Internet Explorer bug fix stylesheet only to Internet Explorer (e.g. <!--[if lte IE 6.0]> <link rel="stylesheet" type="text/css" href="ie_fixes.css"> <![endif]-->). No hacks needed.

    Work in Internet Explorer to clear up any layout issues by overwriting your real stylesheet values. So, if you had a fieldset{border: 1px dotted gray;} in your real styesheet, which causes weird results in Internet Explorer, you can change it by adding fieldset{border: 1px solid gray;} in your Internet Explorer stylesheet. Don’t get bent out of shape if things aren’t one-for-one the same. Sometimes a reasonable likeness is as good as you can get.

  7. Show It To The Client

    By now you have a semantic document custom tailored to your client’s content that is usable, accessible, and hopefully aesthetically pleasing. You can now show it to the client. Since you had the forethought to use web standards, you can make changes to every page at once via the few stylesheets you created. It will save you time and your client money. Since the code is semantic, search engines can better understand the content and index it properly, which may lead to increased revenue for your client. Everyone wins.

Examining John C. Dvorak’s Anti-CSS Article

Tuesday, July 18th, 2006

We all know it. John C. Dvorak is a troll. He’s not just a troll. He’s an uninformed troll. In Why CSS Bugs Me, an article posted on June 12th, 2006, at the PC Magazine website, John C. Dvorak explains why CSS is useless.

The base assumption of his article is that he actually knows what he is talking about. John C. Dvorak is not a designer. He’s a tech columnist. His blog site, which he claims to be redesigning, is proof enough of that. It’s pretty clear that his inability to style a website should mean his opinion is worthless. Nevertheless, I found the article linked from CSS Insider. That means someone cared about his opinion.

I know I’m in for a treat when the opening line of an article is ended by an question mark and an exclamation point. Dvorak claims that none of this stuff works. That statement is absolutely wrong. A great deal of it works. In fact, almost everything works as expected. If I do a font-family:verdana, helvetica, sans-serif on a div tag, every important graphical browser that has been released since I started using the web will render the text in one of the listed fonts. It’s only when using advanced CSS that problems arise.

What John seems to be upset about is the PC Platform. Frankly, every major browser for the Mac is pretty standards compliant. Opera was a little bit of a problem before Opera 9 was released, but even Opera 8 rendered most things the same way Firefox and Safari did. The problem lies on the PC where one of the major browsers, which happens to be the most popular, is not standards compliant. That browser is Internet Explorer if you’ve been living in a hole. Microsoft even prides itself on how well it embraced and extended standards (for example, filters). The major problem for most designers is that the Internet Explorer rendering engine does the box model wrong. But, really, with conditional comments, making a bit of CSS for Internet Explorer is a trivial task.

The point is that he is picking on CSS instead of picking on the people who write the CSS rendering engines. He should be bad-mouthing Microsoft, not CSS.

I take that back. For a moment, he did take a strike at the defining principle of CSS: it cascades.

The first problem is the idea of cascading. It means what it says: falling – as in falling apart. You set a parameter for a style element, and that setting falls to the next element unless you provide it with a different element definition. This sounds like a great idea until you try to deconstruct the sheet. You need a road map. One element cascades from here, another from there. One wrong change and all hell breaks loose. If your Internet connection happens to lose a bit of CSS data, you get a mess on your screen.

I’ll ignore the part about the connection losing a bit of CSS data because I think it’s an asinine suggestion. I can only think of one situation where this would happen and it wouldn’t totally mess up the design if the CSS were written properly. What I want to address is the fact that what Dvorak is bitching about is how CSS was designed to work. The beauty of it is that I can declare a font-family on the body and it should cascade down into paragraph tags. I don’t have to explicitly set the value every time. Further, plain-old HTML had some amount of inheritance built in (for example wrapping a bold tag in a font tag will cause whatever is in the bold tag to inherit the font information). The cascading nature isn’t broken; rather, Dvorak’s understanding of CSS or his ability to use it is under developed. If he’s having trouble figuring out where the style is attributed from, it is probably the fault of the author or his ability to read CSS, not the fault of CSS. Well written CSS, like C or PHP, is quite easy to read if the reader knows what he is reading and the writer wrote it well.

John closes his article by throwing punches at the W3C.

And what’s being done about it? Nothing! Another fine mess from the standards bodies.

First, it’s not the W3C’s fault that the browsers don’t implement the standard properly. That’s like blaming law makers when criminals commit crimes. If there were only Mozilla and Internet Explorer, I might concede that the standard is unclear. However, Opera, Safari, and Mozilla typically agree on how a page should look. So, I can’t blame it on the specification.

Second, something is being done about it. Initiatives like the Web Standards Project have been busting ass for years to get browser makers to stick to standards. The web standards movement is making major footholds. The only major graphical browser that isn’t standards compliant is Internet Explorer. The IE7 team is working hard to make Internet Explorer more standards complaint. Pretty soon, the differences between how browsers render pages will be almost nil. The only difference will be how soon the browser makers integrate new CSS features like those in CSS 3 draft that are already being built into browser releases.

It seems John got his panties in a wad over this one. For once, I think this was a real rant rather than a calculated troll to boost the number of page views on his articles. Unfortunately, he comes across as a whining web design newbie. Those of us that have been doing standards-based web design for awhile have dealt with far worse that he is and we still appreciate CSS for the excellent tool it is.

If you want to read the article, it can be found on on PC Magazine.