Technologist. Leader. Music lover. Noise maker. Philadelphian.
1 min read
1 min read
Whether you're advocating for Web standards, design patterns, social media, or any other cause or group of people, certain basic principles apply. I think these two resources should be considered mandatory reading for evangelists of all sorts:
Read any other good evangelism resources lately? Mention them here!
1 min read
Since the practice of setting and managing standards is as much a management concern as it is a technical concern, I spend time reading a number of business blogs. The HBR Voices blog is full of important management insights.
A recent blog post, How Are You Defying "Best Practice"?, was particularly insightful. Although the article was referring to business and management best practices, it just as easily could have been about design and code best practices.
The only difference is that, while the business world has well-documented and well-established best practices (most commonly taught in MBA programs worldwide), the Web design and development world doesn't yet have that common set of agreed-upon best practices. What one designer or developer considers a best practice may be contrary to what another one believes.
This leads me to the question of how do you define what is an industry best practice? And, how do you defy those best practices, if at all?
3 min read
In the chat room, a number of questions and comments came up regarding the use of CSS hacks to address IE. I don't know how many people were in the camp of "all hacks are bad, all CSS must validate!" versus "who cares, use all the hacks you want", but I was put on the spot and asked for my two cents. I said something to the effect of,
"Aiming to write CSS which validates is a great goal and perfectly achievable on your personal site, but when putting together a site for work or for a client, especially a large site, you may find that using hacks is easier to write and read, and will scale better over time -- so long as you plan a way out." I think that resonated with some of the folks in attendance, who have always felt that to honor the Web Standards cause, a developer always had to follow the best practices and have valid code at all times.
So, just to reiterate, no, you don't have to have valid markup and style sheets all of the time. In fact, there are times where you'll intentionally code something not valid -- whether it's the use of the target attribute for an anchor to make sure a link opens in a new tab/window, or whether it's the application of a hack in your CSS, so a future developer doesn't have to look through multiple CSS files to figure out what you did. I think this is perfectly acceptable, provided you execute the hack consciously. At almost all of the large companies where I've worked*, we've had to use hacks or deliver non-valid code. It's just a fact of life. It's what you know about your non-validating code, what you plan for**, that matters.
*At PayPal, we attempted to maintain separate IE6 and IE7 style sheets, called with conditional comments; this caused developers to have to write additional CSS in many cases, as the CSS architecture included a global CSS file, one or more product/flow/page-specific CSS files, and then these IE-specific CSS files. Due to the cascade, overwriting one style in the IE-specific CSS file sometimes meant writing additional lines of CSS to restore a style -- unless you could ensure that tweaking selectors in the other CSS files to make them more specific would be a better fix, without breaking any other pages... perhaps you see where I'm going with this? With over 100 developers potentially working on a bit of code, decoupling IE-specific styles created a nightmare situation, which inline hacks would have solved in a way that would have been easier to read and easier to maintain.
**On the other hand, at CIM, we have no coding standards (yet), so each developer appears to be addressing browser-specific issues in whatever way they want. I've seen multiple hacks used in our code and backing them out later is going to be a major challenge. When you do use hacks, make sure everyone on the project/working on the site uses the same ones!
So, with that, you have my permission to use hacks and write non-validating code -- just make sure you have a good reason for doing so, in case someone comes asking why you did it. 'Cause I won't back you up if you don't have solid justification!
1 min read
More tutorial than strict style guide, the New York Public Library Online Style Guide contains information on XHTML and CSS for those developing pages that are part of the library system. Although written in 2001 (with the help of Carrie Bickner-Zeldman), all of the information is still relevant today.
NYPL continues to refine their best practices and processes, of course, and you can follow their progress on the NYPL Labs blog.
1 min read
Some of my favorite bits:
"If you are a person responsible for managing the information provided by your organization, you have to balance the advantages of a 'house style' with the advantages of giving each group or author free rein. If you end up with decisions in this area, it is as well to write them down (not to mention put them on the web)."
"Always use heading levels in order, with one heading level 1 at the top of the document, and if necessary several level 2 headings, and then if necessary several level 3 headings under each level 2 heading. If you don't like the way heading level 2 is formatted, fix it on your client, don't just skip to heading level 3."
"Have fun with style sheets. Also, within a company or a series of publications, use them to establish conventions which tie a given look to documents of a given status."
2 min read
Maybe it's the co-worker who sits next to you, or perhaps it's your boss. It could be a new client. And, invariably, someone in your family qualifies. That's right, they're the not-so-tech-savvy you have to deal with. How do you get them to understand you so that you can communicate and work together effectively?
Web Worker Daily provides 10 tips for working with the computer-illiterate, ranging from the obvious (avoid jargon and be patient) to smart strategies you may not have figured out yet (introduce new technologies gradually, talk results instead of process).
Two things that aren't mentioned in the article but deserve emphasis:
1 min read
Coding HTML emails is rarely regarded as a fun task, but these articles may help take some of the guesswork out of the task.
Sitepoint author Tim Slavin offers four steps (each with many details) to coding a better solution in How to Code HTML Email Newsletters.
Campaign Monitor provides an updated Guide to CSS Support in Email Clients for 2008. Their matrices thoroughly detail CSS support in both desktop and web clients, 21 in total.
1 min read
So far, the topics covered include WCAG 2.0, the Selectors API, and ARIA in HTML5. However, they haven't explained why they think that standards suck. I guess we're supposed to gather that from the complexities of what's discussed.
1 min read
While his findings show that type and class selectors are rendered more rapidly than descendant and child selectors, the example files are (necessarily) exaggerated in order to demonstrate the performance impact.
I'd like to see a well-coded, real-world example (one which balances type, class, and ID selectors with descendant and child selectors) vs. an example that exploits the use of class selectors (and is probably less efficient over all due to excess code) -- I would guess that they'd perform about the same. And, as pointed out elsewhere, the well-coded solution will be easier to maintain in the long run, which would well be worth the extra milliseconds on the client.