Posts Tagged ‘HTML’

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.

Forms With Elements With Form Attribute Names

Tuesday, September 23rd, 2008

I commonly create a form element that dictates the action I want the server to perform, like <input type="hidden" name="action" value="save">. This allows me to have a switch to determine what to do with the data in any situation instead of posting and getting to multiple places. I found a bug in Internet Explorer 7’s JavaScript today that introduces a problem with my naming scheme.

When doing Ajax, I often use form.getAttribute('action') to get the location to send the request to. This allows me to keep my code more portable. However, in Internet Explorer 7 (or IE7 for short), if there is also a form element with name="action", IE7 returns the input object instead of the value of the attribute as though I typed formname.action or, in long hand, document.forms['formname'].elements['action'].

To my knowledge, there is no work around other than changing the name of the element. So, I’ll be using name="faction" from now on. That’s short for “form action” but “faction” itself is fairly apt given IE’s behavior is different from all other browsers, making it a faction.

Element Swapping with Unobtrusive JavaScript

Monday, February 11th, 2008

There may come a time when you need to show different content on one page based on a user-selected option. Here’s a quick tutorial.

The first step is to set up your content properly. In this example, I’ll use a select to swap between two form elements, though the basic premise can be applied to other design patters such as module tabs. Here is how the form should look.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<form method="post" action="post.php">
 <div>
  <label>
   How Should I Reply To You?
   <select name="type" id="type">
    <option value="email">E-mail</option>
    <option value="phone">Phone</option>
   </select>
  </label>
 </div>
 <div id="byemail">
  <label>
   Enter Your Email:
   <input type="text" name="email">
  </label>
 </div>
 <div id="byphone">
  <label>
   Enter Your Phone Number:
   <input type="text" name="phone">
  </label>
 </div>
</form>

That is the basic setup you need. You have something for the user to select (that has an id to assign, in this case, an onchange event), and something to swap between that have ids. Now you need some JavaScript. Comments are inline to explain things.

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
/* Assign the onload event to the function init. */
/* Test which way adding events is supported. */
if(window.addEventListener) {
	/* W3C method. */
	window.addEventListener('load', init, false);
} else if(window.attachEvent) {
	/* IE method. */
	window.attachEvent('onload', init);
} else {
	/* Old school method. */
	window.onload = init;
}
 
/* This is the function that runs after the page loads. */
function init() {
	/* Get the select element you want the onchange to be applied to. I use the j_ prefix because sometimes errors happen when variables are named the same thing as IDs in the HTML. */
	var j_type = document.getElementById('type');
	/* If the element exists, we can assign the onchange event to call the swap function using the same type test we used before. */
	if(j_type) {
		if(j_type.addEventListener) {
			j_type.addEventListener('change', swap, false);
		} else if(j_type.attachEvent) {
			j_type.attachEvent('onchange', swap);
		} else {
			j_type.onload = swap;
		}
		/* Now, we need to fire the event to get the default. */
		if(document.createEvent) {
			/* The W3C method. */
			var j_event = document.createEvent('HTMLEvents');
			j_event.initEvent("change", true, true);
			j_type.dispatchEvent(j_event);
		} else if(document.createEventObject) {
			/* The IE method. */
			j_type.fireEvent("onchange");
		}
	}
}
 
/* This is the function that does the work of swapping the elements. */
function swap(e) {
	/* Get both the elements you want to swap between. */
	var j_email = document.getElementById('byemail');
	var j_phone = document.getElementById('byphone');
	/* Grab the event from the W3C method or the IE method. */
	var e = e || window.srcEvent;
	/* Grab the event target from the W3C method or the IE method. */
	var target = e.target || e.srcElement;
	/* Grab the target's value */
	var t_value = target.value;
	/* If both swap elements exist... */
	if(j_email && j_phone) {
		/* Depending on which option, hide or show the form elements. */
		if(t_value == 'email') {
			j_email.style.display = 'block';
			j_phone.style.display = 'none';
		} else if(t_value == 'phone') {
			j_email.style.display = 'none';
			j_phone.style.display = 'block';
		} else {
			j_email.style.display = 'none';
			j_phone.style.display = 'none';
		}
	}
	return true;
}

Save the script above to a file and include it in the head of your document that the form is in. You’ll have the swapping capabilities you desire using unobtrusive JavaScript and modern DOM techniques.

This was tested in Safari 3, FireFox 2, Opera 9.25, and Internet Explorer 7.

WYMEditor HTML Textarea Loses Focus

Thursday, January 24th, 2008

I’ve been using the WYMEditor on a little content management system I’ve been building at work. I was having a problem where I couldn’t edit in the HTML editor. Every time I clicked, the HTML textarea in WYMEditor would lose focus.

It turns out the problem was the way I used my label for the textarea that turns into the WYMEditor. There are two ways to use label. One is to tie the element to a form element via for="element-id" where element-id is the id of the form element. The other is to simply encapsulate the form element inside the label. I was doing the latter since I had written CSS to display forms.

labels focus the corresponding element when clicked (or when elements inside them are clicked). If you click the element directly, the focus doesn’t change. What I was failing to realize was that WYMEditor was putting the replacement / overlay inside the label. The visual editor itself uses an iframe, which overrides the label. The HTML Editor portion uses another textarea. In FireFox, when I clicked the textarea to edit, the focus would shift to the hidden (and first in the code) textarea.

The solution was to use the for method instead of the encapsulation method for WYMEditors and modify my CSS.

Easier Image Replacement

Monday, September 24th, 2007

If you didn’t hear, text on a website is better than an image. Images have their place, but many people use images where text should be. In recent times, people have been using a technique called image replacement to replace text with an image. Typically, there are crazy hacks that involve embedded elements, but there is an easier way.

Before I get to that, I want to clear up when I think it is good to use images and when it is good to use image replacement.

It’s good to use image replacement when the object in question is, simply, an image. For whatever reason, I always picture a horse, silhouetted against a brilliant pink sunset, running through a grassy field on cliffs above the ocean. What I did there was describe the image, which goes in an alt attribute. My rule for using images is: if the proper description is a sentence (or longer), use an image with an alt. If the proper description ends up being a few words (e.g. Amazon Logo), use image replacement with semantic markup.

Most of the time, fancy heading text (in h1s, etc) and logos are prime targets for image replacement. Logos typically appear at the top of the screen and, to me, seem to be the top-level heading of the site. Other times, people want their heading text to be in fonts that aren’t web safe. This is a great time for image replacement, because it retains the semantic value and accessibility without some level of complication (that is, the heading isn’t the alternate text inside an image, it’s just the text).

There are tons of ways to do image replacement. Until recently, I was doing it the way I think most people do it (sorry for the inline CSS; I’m trying to avoid confusion):

1
2
3
<h1 style="background-image:url(myheading.png); width:100px; height:100px">
 <span style="position:absolute; margin-left:-9999px;">My Heading</span>
</h1>

This is a perfectly valid way to do the markup. The only problem is that it has that extra span in there. It’s semantically valid (since spans don’t mean anything, but it’s one more level of complexity (that is, the heading is the text inside of the span), which is what we wanted to avoid.

Instead, I’ve been doing it this way1 (again, sorry for the inline CSS):

1
<h1 style="position:relative; width:100px; height:100px; clip:auto; overflow:hidden; line-height:210px; font-size:10px; background-image:url(myheading.png);">My Heading</h1>

The relative positioning makes it possible to clip and hide the overflow of the element. So, we set our height and width to that of the image that will replace the text. We then come up with a sane image height (I’ve used 10px because the text doesn’t have to resize since it is hidden and because the default don’t display text smaller than setting in browsers should be lower than this by default (if there is any worry, we can use a larger font size). Then, we set the line-height to the site of the image plus the size of the font (this seems to hide the font just out over the height of the element). Using the line height, we can also assure that the text will be hidden since it will be below the visible area instead of to the left or above it.

There you have it: yet another way to do image replacement. Is it better? Maybe. It reduces the complexity of the markup, making it less bloated and a bit more efficient, semantically if nothing else. However, it increases the work that needs to be done on the CSS side. With this we have a little math to do, and a little bit more to type. To reduce the extra typing a class could be created to handle the position, clip, overflow, and font-size with the second class setting up the stuff that changes per image. In the end, do what suits you best. I’ll be doing it this way.

As a warning, the only problem I’ve run into2 was if I set the line height too high, Internet Explorer would have some rendering problems. I don’t remember exactly what happened, as it’s been awhile since I tested this on a real browser. I’ll be sure to update this post the next time I am able to test.

  1. Wait! This is sort of untrue. I thought I was doing this one way, but it turns out I was wrong. I was using something with position: absolute, which has some positioning problems if the user is unaware of how absolute positioning works. I’m pretending I’ve been doing it this way because I like it better.

  2. Technically, it was a problem with the way I was doing the absolute positioned way. I’m leaving the warning in just in case for now.

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>

HTML 5: WHATWG versus W3C

Thursday, March 8th, 2007

The new W3C HTML working group launched. The charter states that they’ll attempt convergence with the WHATWG‘s recommendation. I remain a little confused with how the browser vendors will handle this.

My main concern comes from the WHATWG’s lack of DTD specification in the DOCTYPE. WHATWG proposes that HTML 5 use <!DOCTYPE html> as the DOCTYPE because browsers don’t care about DTDs. The only reason they include a DOCTYPE is to alert browsers to use standards mode (and DOCTYPE isn’t used in HTML 5 if the page is sent as XML). I think this was short sighted.1 WHATWG is essentially forking HTML. They made the false assumption that there would be no competing HTML standard. Since browsers would implement WHATWG’s HTML 5, they could take shortcuts. If the WHATWG can fork it, anyone else can.

Now there is a competing standard in the works from W3C. The W3C charter suggests that the W3C HTML Working Group will try to converge with the WHATWG’s HTML. They key word is try. They didn’t promise compatibility.

Can there be standards with multiple varying recommendations? I think so. That is what DTDs are for. The designer can even write his own DTD if he would like to define his own elements. This isn’t typically done, but it can be. WHATWG’s reasoning is that HTML 5 is no longer an application of SGML, but defines its own syntax. That’s all well and good, but DTDs at least gave us a way to determine what version of HTML to use, even if it was for our own personal standardizing. Declaring the use of the HTML 3.2 DTD, no matter what version of HTML the browser actually renders against, guarantees that the author attempted to make an HTML 3.2 document. If any problems are introduced (e.g. depreciated elements), at least it isn’t the author’s fault. After all, this standards thing is, in part, about future proofing and there is something to be said about not being on the bleeding edge.

The problem is that if the W3C departs from the WHATWG’s recommendation and agrees to the lack of DTD, there is no way to pick which version of HTML 5 you want (WHATWG’s or W3C’s). If there was some way to sniff DTDs, the designer could tell the browser which to use. WHATWG has ruled that out because, currently, browsers don’t care about DTDs / HTML 5 is not SGML.

Once upon a time, browsers didn’t care about DOCTYPE (as far as I know). When it became necessary to differentiate between standards mode and quirksmode, the DOCTYPE became important. If it becomes necessary to differentiate between versions of HTML 5, browsers may start to care about DTDs.

I imagine the reply to my concern would be, Browsers will support both recommendations, ultimately resulting in a better hybrid implementation of both WHATWG’s and W3C’s recommendations. This reasoning would work if, for example, WHATWG supported the footer element and W3C did not. The designer could still use the footer element, even though it technically isn’t part of the traditional web standards view (that is, the W3C created standards), and have global browser support (e.g. innerHTML in JavaScript is supported across all browsers, even though it isn’t in the ECMA standard2). However, this isn’t ideal. There are reasons to use particular recommendations (e.g. future proofing and avoiding proprietary elements). For longevity, picking a particular recommendation and sticking to it would be good practice, even if browsers supported the hybrid model. For argument’s sake, however, using the hybrid model in this instance isn’t problematic.

The problem will come when the two specifications differ on how to implement a particular element. While it is not the exact same case, compare the Internet Explorer box model to the standard box model. If, for example, WHATWG described something like the Internet Explorer box model, and W3C described something like the standard box model, how would the browser know what to choose? It wouldn’t unless it sniffed the entire DOCTYPE tag. Assuming the W3C keeps the DTD, a special case would have to be coded for WHATWG’s HTML that says something like, If there is a DOCTYPE but no DTD, assume it is the WHATWG’s version of HTML. Again, this isn’t ideal, but it would work. If W3C decides that the DTD isn’t necessary either, there would be no way to determine what the author wanted to use, resulting in a great deal of confusion.

Again, some may reply, Browsers will support both recommendations, ultimately resulting in a better hybrid implementation of both WHATWG’s and W3C’s recommendations. Presumably, this would eventually trickle up to the two recommendations resulting in normalizing the two documents. Again, I’ll reference the box model. The Internet Explorer team implemented the box model one way. Everyone else implemented it the other way. It was years before the two became congruent (if they even are yet). Until the two documents become normalized based on browser implementations, there will be confusion and incompatibility (aka instability). Further, it has never been a good idea for browser makers to decide what should be standard. If it were, we may have both LAYERs and DIVs. We’d have proprietary filters in our CSS and parts of CSS 2 would have to be axed completely because browsers don’t support them. It’s the job of the standards body / bodies to tell the browsers what they ought to do. It’s not the job of the browser implementation to dictate what standards ought to be.

Simply put, I’m worried about how WHATWG’s HTML and W3C’s HTML will interoperate. It could easily work out, but there could be problems just as easily. Luckily, WHATWG’s HTML isn’t a final recommendation and W3C hasn’t started yet. These problems can still be worked out.

  1. This might be an unfair statement. They might not be short sighted. They might be looking out for developers by making it easier to use DOCTYPE. This is noble, but ends up being a problem if I’m right. The other explanation is that the WHATWG is arrogant and believes it is the only version of HTML that matters. If we were talking about the W3C, I might suggest this was the case. I’m hoping that the WHATWG doesn’t pick up on the W3C’s bad habits. I’m giving them the benefit of the doubt since I have a lot of respect for many of the members.

  2. This was proclaimed by Douglas Crockford in his talk called An Inconvenient API: The Theory of the Dom that can be seen via the Y!UI blog.

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.

Markup Not Safe For Work Content

Friday, December 29th, 2006

Some guy named PJ Doland suggested we use rel="NSFW" to markup content that is NSFW.

I’m not validating or endorsing the idea by posting about it. I’m posting because I had written a comment on the accompanying Slashdot article (that I never posted) that addressed the issues below.

Then I wrote half of a post about how the rel attribute could only be applied to hyperlink-type elements and that putting it on other tags would cause the document to fail validation. Instead, class or title attributes should be used, depending on how microformat he wanted to go. However, I realized that he beat me to it. His second article pretty much says what I was going to with more words. I had already written the HTML for a document to prove that it wouldn’t validate.