Tom Mollerus' Weblog

Check out this technical style guide from Stanford University's IT department. Not only is it a guide to the CSS selectors that Stanford uses, but it helps to enforce consistent HTML code by different developers. One smart technique displayed in the document is the display of styled content right along side of the HTML that produced it.

Via .net magazine

.net magazine has a great article on some of the next-gen features being worked on in CSS: columns, flexible boxes, grids, templates, positioned floats, exclusions, and regions. There's one thing they left out, though: CSS variables. Implementation of variables would make it so easy to keep colors separated from layout in CSS files, and it would make changing common values (colors, padding, fonts, etc.) so much easier during development. Here's an example of how they would work:

@variables { elementcolor: black; }
#selector1 { color: var(elementcolor); }
#selector2 { color: var(elementcolor); }
#selector3 { color: var(elementcolor); }

I can't believe there are people who say that CSS variables aren't needed or wouldn't be useful. These folks tend to have two arguments:

• Variables make CSS too complex, and more like a programming language.
  I disagree with this one heartily. Variables would only make CSS more like a programming language if the developer felt like using them. If someone didn't want to use variables, the wouldn't need to touch them. And, what's wrong with letting a language evolve? HTML certainly has, and it's gotten more like a programming language since it came into widespread use.
• You don't need variables if you use your selectors correctly.
  This is a better argument. It's the idea that you'd have a bunch of selectors all in one comma-delimited list with one declaration after it-- color, for example, or font-family. But that kind of arrangement seems almost as contrived and complex as the use of variables. Variables, at least, let you organize your declarations where you want them, instead of forcing you to separate them in a predetermined manner.

This tip from 37 Signals' Signal vs. Noise blog is so good I have to pass it on: you can find all image tags that are missing a width or height attribute by embedding a simple CSS selector in your development stylesheet:

img:not([width]):not([height]) {
  border: 2px solid red !important;
}

I just noticed the post on Ben Forta's blog about CSS regions, which has been submitted to the W3C as a working draft. The video demonstrates what an excellent concept regions are; content flows between columns automatically as a page is resized, and not only does content flow within irregular shapes, such as within diamonds or around curved background photos, but it also happens as the page is resized or as the page scrolls. Hallelujah! We've been waiting for this to be implemented for the last decade! I can only hope that it gets approved and implemented by browser makers soon.

This first day of the conference is really making clear the difference between mediocre speakers and good ones. Whether anyone is a good speaker doesn't depend a bit on their intelligence or even their job expertise. Great speakers are entertaining; they tell a story, perhaps humorously; they keep your interest because they're good storytellers. Mediocre speakers just tell you about their topic, and only about their topic, in plain fashion.

I spent 30 minutes of frustration this morning trying to edit text content that I had pasted from a Google doc into a WYSIWYG editor on Marketo. In the Marketo editor, the content came through with all sorts of odd line breaks, mostly at the start of sentences. Simple enough to correct, I thought, so I used the backspace key in the WYSIWYG editor to remove the line breaks and saved my work and went back to email preview mode. But back in preview mode, the linebreaks remained. Additional edits showed the same behavior and it nearly drove me batty.

So I took a closer look at the HTML source of that comes with any text copied out of Google docs, and realized what the problem was. Docs produces standard HTML and CSS, but a lot of it, and there was one inline style declaration all over the place that was causing the problem: white-space: pre-wrap;. Copy the HTML source into a text editor, search-and-replace that string to delete it, and your content should look beautiful-- no more extra, stubborn, line breaks.

While working on demo code for an Adobe Developer Connection video, I was having real trouble getting my Android phone to read CSS3 media queries successfully. I was using three different stylesheet declarations, like so:

<link rel="stylesheet" href="index_files/mobile.css" type="text/css" 
	media="screen and (max-device-width: 480px)">
<link rel="stylesheet" href="index_files/tablet.css" type="text/css" 
	media="screen and (min-device-width: 481px) and (max-device-width: 1024px)">
<link rel="stylesheet" href="index_files/computer.css" type="text/css" 
	media="screen and (min-device-width: 1025px)">

I was expecting that both of my Android devices, a Motorola Droid and a Sprint Evo, would call only the first of the stylesheets-- the one with the media query of "max-device-width: 480px". But instead, it called the second stylesheet, meant for tablet devices with a screen with of between 481 and 1024 pixels (for instance, the iPad). I couldn't figure out what was going on.

Both devices have a specified resolution of 480px wide by 800px high in portrait mode; but even if I changed the device width in the first two media queries to 800px and 801px, respectively, it didn't change the behavior I saw in my phones. They ignored the first stylesheet and always called the second. An iPhone I was testing with had the expected behavior of calling the first stylesheet only. I was probably stumped for over an hour, trying different queries in different locations (within stylesheet links, within import statements, or within a single stylesheet).

Finally, I managed to find the answer. As usual with my intractable coding problems, the fix was pretty simple. For Android 2.2, you have to use the "viewport" meta tag for media queries to work: <meta name="viewport" content="width=device-width" />

What a great idea... wordmark.it is a site that lets you preview text in all font faces available on your computer. Someone should do this with web fonts, too.

Via Cameron Moll

I often use graphics in my CSS stylesheets: for background images, for link descriptors, and every once in a while, for list icons. And it was while reading A List Apart's venerable 2002 article "Taming Lists" that I remembered that graphics aren't the only assets you can specify in stylesheets-- you can also use plain text, in a format called generated content.

The term generated content refers to content that your users see in their browser but isn't present in the underlying HTML code. Instead, it's specified in the stylesheet and generated by the browser. This is especially useful with the :before and :after psuedoclasses. For instance, if you wanted users to see whether any link on your site led to an external site , you could specify the following:

<style>
a[target=_new]:after, a[href^=http]:after { content: " (External link)"; }
</style>

You'll end up with Ping Identity, Inc.. Look at the source of this post, and you'll see that the link is just "<a href="http://www.pingidentity.com" target="_new">Ping Identity, Inc.</a>

I just learned about some great new pseudoclasses in HTML5 for use on input tags: :valid and :invalid (These are among the many other new features in CSS3). Used in conjunction with the new validation capabilities for input fields, you can write styles which will change the appearance of your inputs in real time depending on where the cursor is in the form and what data the user has entered.

The new validation capabilities of HTML5 have to do with the new input types: "email", "url", "number", or "date", and the new "required" attribute. These new types are supported by most browsers except for Firefox, and just appear as regular text inputs in non-compliant browsers (and the "required" attribute will just be ignored). For example, in HTML5 you can now create a field like this:

Email address: <input type="email" name="your_email" required="true" />

Using these new features allows the use of the new pseudoclasses:

1. When your input field has the "required" attribute set, it will match the pseudoclass :valid if it has a value entered (unless the value doesn't match an additional validation rule)
2. If your input field has the "required" attribute set and it does not have a value entered, it will match the :invalid pseudoclass.
3. When your field is of type "email", "url", "number", or "date", and the value entered is not of the corresponding type, the will input will match the pseudoclass :invalid.

So our CSS can look like this (only works in Chrome, Safari, and Opera):

<style>
input:valid { border: 1px solid green; }
input:invalid { border: 1px solid red; }
</style>

<form>
Your name: <input type="text" name="your_name" required="true" /><br />
Email address: <input type="email" name="your_email" required="true" />
</form>

Give it a try:

Better yet, you can use the "adjacent" selector to style messages next to your inputs (only works in Chrome, Safari, and Opera):

<style>
input:valid + span { color: green; }
input:invalid + span { color: red; }
</style>

<form>
Your name: <input type="text" name="your_name" required="true" /><br />
Email address: <input type="email" name="your_email" required="true" />
</form>

Give it a try:

Jeffrey Way writes up a good list of things you should know about HTML5. It's a little random, and not as complete as Mark Pilgrim's tutorial, but a good read nonetheless:
http://net.tutsplus.com/tutorials/html-css-techniques/25-html5-features-tips-and-techniques-you-must-know/

We're all used to hyperlinks to web sites (http://) and email addresses (mailto:), but as mobile devices become more popular, you might find yourself needing to use some other types of links. If so, check out Apple's short, succinct reference for creating links for some of the less common resources such as calling telephone numbers (tel:), sending SMS messages (sms:), or even linking to iTunes (http//: again, but calling Apple's phobos.apple.com server should open up iTunes on the user's device).

http://developer.apple.com/safari/library/featuredarticles/iPhoneURLScheme_Reference/Introduction/Introduction.html#//apple_ref/doc/uid/TP40007899

Brad Neuberg gives an excellent summary of just which specifications and technologies are part of the concept that's been given the nebulous label of "HTML5". If you ever wanted to see a definitive list of what's new on the web without trying to slog through the specification, read his post.

If you haven't yet seen Marcin Wichary and Ernest Delgado's presentation on HTML5, make sure to take a look-- not only is it a pretty good summary of the new features offered in HTML5, similar to Mark Pilgrim's Dive Into HTML5 site, but it's actually an HTML5 app itself. It's the kind of work that keeps other developers coming back to it for ideas for years to come.

Check it out at http://apirocks.com/html5/html5.html

Jason Grigsby demos what I think is a pretty cool feature in CSS3: the ability to include orientation declarations in stylesheets. You can either put them in your link element like so:

<link rel="stylesheet" media="all and (orientation:portrait)" href="portrait.css">
<link rel="stylesheet" media="all and (orientation:landscape)" href="landscape.css">

or directly in your stylesheets:

@media all and (orientation:landscape) {
   [styles for landscape orientation]
}

@media all and (orientation:portrait) {
   [styles for portrait orientation]
}

Jason's post just refers to the iPad's support for this declaration (and the iPhone's lack of support), but I've found that Google's Webkit-based browser on Android supports it, too. Sadly, Opera Mini for Android does not. I've taken his original demo and modified it to demonstrate the use of the inline, single-stylesheet method.

Neat idea, though, and one that I think will be more and more useful as mobile device use continues to increase. I can see people using this to create HTML5 web apps that can serve either computers or mobile devices with the same codebase.

I stumbled across Mark Pilgrim's Dive Into HTML5 last night, and what a great read it is. Not only is it informative, teaching you about new tags and their uses, but you also get to read the history of HTML, written in Mark's entertaining style.

If I asked you to fill out the following form to get information about an LDAP server that you were supposedly giving me access to, would you know what type of information to type in?

Chances are you could enter the first value, but the second is a little tougher to understand. It would be useful to be able to give supply an example to show you what type of information is correct, right? But how do you put in examples while keeping it clear to the user that they're just examples and need to be replaced with something else?

Internet Explorer 8 Beta introduces a new live bookmark feature they call "WebSlices". WebSlices actually subscribe you to portions of a Web page. It's a pretty cool idea-- with some easy mark-up in your page, you can allow users to subscribe to subscribe to your site's information without creating an extra RSS feed. And, users can view the feed not as a text list in a grey menu, but as a slightly larger window with its original HTML/CSS formatting. It's kind of like a graphical RSS feed, but without the work of maintaining the feed.

When you click on the "Member login" link on the Text Link Ads site or respond to a comment through the admin section of a Movable Type installation, you'll be presented with a new form in a slightly different manner than you're probably used to: instead of being sent to a new page, or seeing a popup window, the current page darkens, or "greys out", and a form appears immediately overlying it. It's a really neat way to keep the user in the current page context, and it neatly gets around the growing tendency for users to suppress popup windows.

They both do it with Lightbox Gone Wild, which is an adaptation of Lokesh Dhakar's Lightbox project. It's a very easy technique to pull off... link to three script files and one stylesheet in your main page; create a second page containing the code for your form; and then put a link to the second page in the main page with a class of "lbOn". Complete instructions can be found on the Lightbox Gone Wild page.

I know that cfwindow offers some of the same functionality, but it seems to me that cfwindow can't achieve the same level of flexibility as Lightbox.js can. For instance, I think cfwindow is somewhat more limited in how much of it you can style, and is also limited in whether forms in the dialog area can target the whole page.

Ben Nadel's post about parsing CSS rules in ColdFusion reminded me of some of the techniques I've used in the past to make dynamic stylesheets. I've since stopped that practice, though, figuring that for my needs it didn't make sense to create a secondary CF request for the stylesheet each and every time someone called a page. So, I switched to a static stylesheet and used some of the techniques I've found from around the web. Save yourself some CPU cycles by letting the stylesheet and browser do the work instead.

Take, for example, the navigation at the top of my blog. The code for the navigation bar itself and the code for the stylesheet are the same for every page, yet the highlighted tab changes depending on which section of my site that you're in. The one thing that does change is the id attribute of the body tag. Read on how to get this technique to work for yourself.

In a few of the apps I've written there's been the need to show users a preview of a newsletter email or stock alert email. Before AJAX was widely known and available, you used to have to provide some action that would submit a form and refresh the page in the browser, perhaps interrupting the flow of the user's experience in the process. But today I noticed that the email service provider iContact has a great way of handling one-off preview emails without making you leave the page you're on.

Rob Wilkerson reminded me in yesterday's post regarding XRAY to mention the MRI bookmarklet from Westciv as well. From WestCiv's site: "MRI is a free cross browser tool that lets you test selectors with any web page. Selectors, particularly complex ones can be difficult to get exactly right - MRI lets you experiment with them on any web page (local or online, static or dynamic).

Essentially, MRI lets you search and identify specific selectors on your web page. Selectors are the names or tags that you specify in your CSS so that you can "select" which elements to style. So MRI will help you find all anchor tags within a list item (li > a), or all elements with a certain class or ID.

I put this as a "nice to have" since I don't think it's as useful as XRAY is. It's more often that I'm wondering "why on earth is this particular element styled/not styled this way?", which XRAY will tell me, than I wonder "which elements have this certain selector?"

I've got to add to my list of must-have developer tools:

• XRAY: XRAY is a JavaScript bookmarklet which allows you to "see the box model for any element on any web page". That doesn't sound very sexy, but it is-- when activated, this bookmarklet brings up a modal dialog box that will show you the nested parents for whatever element you click on, and you can even traverse up. Whichever element you click on or is in focus will be outlined. It's fantastic for determining an element's exact height, width, nesting, and CSS inheritance.

In my recent post titled "Preventing multiple page requests after double-clicks", I suggest a way to use JavaScript to prevent multiple requests resulting from double-clicks on submit buttons or links. In the comments of my posting, Sam Farmer mentions the technique of putting "...the submit button in a span or div and after submission change the span or div contents to say 'Processing' or something like that." His is a great idea, and one that I've used myself in other sites. I responded that I'd blog about my technique for changing the appearance of a submit button to show that it's been clicked, so here goes!

I've posted an update to my microformats CFC today. There are two bugfixes and several XSLT updates (thanks to Gideon Marken for bringing my attention to most of these issues.):

Bug fixes:

1. microformat classes would not be found in a string if they were combined with other class declarations (i.e., the CFC would find <div class="hcard"> but not <div class="pagetitle hcard">). The regular expression to match classes was updated to fix this issue.
2. the CFC would fail to recognize microformat strings as valid XML if they contained an unescaped ampersand ('&', often found in URLs, should be '&'). The CFC now automatically escapes all ampersands when parsing microformats out of a string.

1. xhtml2vcard.xsl was updated to the latest version as found on http://hg.microformats.org/x2v.
2. xhtml2vcal.xsl was updated to the latest version as found on http://hg.microformats.org/x2v.
3. mf-templates.xsl was updated to the latest version as found on http://hg.microformats.org/x2v.
4. hAtom2Atom.xsl was updated to the latest version as found on http://hg.microformats.org/x2v.

You can download the CFC from my microformats CFC project page.

Block-level elements treat multiple elements on the page as a single block, putting them all in one rectangular area (think <div>, <table>, and <blockquote>). Inline elements-- and this is the part that's easy to remember-- aren't treated as a block; instead, they fall within lines (ie, "in line") and can go next to other inline elements (think <span>, <a>, and <img>).

One thing to remember is that block elements cannot go inside inline elements.

I realized that I had better start updating the web site I work on, for several reasons: I should update my skills; I could make the site more modern; and, I could make the site's presentation code lighter and faster. So, I'll write about my experiences as I go in this blog.

@media print {
	.hideFromPrinter {
		display: none;
	}
}

Then I assigned the hideFromPrinter class to each and every image tag for those blue corners... but I'm sure that I didn't find them all.

But now I know about attribute selectors, and the task of hiding those rounded corners during print view becomes much easier. I just added a new clause to my @media print section, like so:

@media print {
	.hideFromPrinter {
		display: none;
	}

	img[src^='/images/blue_corners/'] {
		display: none;
	}
}

There you have it! All of the blue corners, whose src attributes start with "/images/blue_corners/", no longer show up in print view. This works across the whole site just from 3 lines added to my stylesheet instead of adding code to every image tag.