Posts in the CSS Category

Public Rabidity

Published 20 years, 3 months past

Oh, joy.  I’ve once again been accused of an anti-Explorer bias.  This would amuse me if it weren’t for the fact that it means I’m being misrepresented, despite my long-term efforts to be clear about where I stand.  It might annoy me if I could be bothered to expend the energy.  I suppose I should view this as karmic justice for my original SEO post, where I contributed to the misrepresentation of others.

For the record, I am indeed sometimes critical of IE for being non-compliant.  I’m also critical of other browsers, although of late there has been less to criticize because IE has been standing still while others advance.  That’s just the nature of things right now.  I was critical of Netscape Navigator back when the most recent version was 4.whatever and everyone else (including IE) had advanced.  It’s often easier to see the flaws in something when you have a point of comparison.

The same post implies that I’m also a CSS zealot.  True, I think CSS is a very powerful and useful technology.  However, the day I start saying things like “you can never ever use tables for layout and screw IE if it can’t handle your design”, that’s when you can accurately call me a zealot.  Until then, it’s just name-calling, and not very effective name-calling at that.

I will admit that the phrase “‘holier-than-thou’ sages on the mount” was an amusing choice of words.  Think he’s seen Episode II of the UI9 comic?


Of Site Styles and CSS Columns

Published 20 years, 3 months past

Thanks to a post over at Simon’s weblog, I discovered that the Mozilla 1.8a3 readme file tells us of some interesting CSS-related developments:

       
  • Users can now disable CSS via Use Style > None or a global preference (bug 32372.)
  •    
  • Mozilla now supports a at-rule for matching on site/document URL. Among other things, this makes site-specific user style rules possible (bug 238099.)
  •    
  • Preliminary support for CSS columns has been checked in to Mozilla bug 251162.)

The middle of the three is what Simon wrote about, and it’s indeed very cool.  CSS signatures would never have been necessary if browsers had always supported per-site styles.  I’m not entirely thrilled about the syntax, but it’s a good start.  And for those who are wondering how I could support a non-standard extension, I’ve never been against them as long as they were clearly marked as such.  Microsoft’s extensions (behavior, filter, the scrollbar stuff) weren’t, which inevitably led to confusion.  The Mozilla stuff is marked in such a way that you can tell it’s an extension, and in a way that won’t conflict with future CSS.

I’m happy to see that Mozilla will finally let users easily disable CSS.  For those who need the text view, say because they have poor vision, it will be a welcome feature.  For those who want to quickly check the document’s unstyled rendering, it will be similarly useful.

But I’m most intrigued by the addition of “preliminary” support for CSS columns.  This would allow you to declare that a given element’s content should be flowed into columns, complete with auto-balanced heights and everything.  For example, if you wanted a list flowed into two columns, you could declare:

ul {-moz-column-count: 2;}

That would split the contents of every undordered list into two halves, filling the first column with the first half of the list and the second column with the second half.  Thoroughly awesome.  See the CSS multi-column layout module for more details, although I don’t know how much Mozilla actually supports at this juncture.

Update: it turns out that column support isn’t present in Mozilla 1.8a3, contrary to the release notes.  I’ve been told that it will be present in 1.8a4.


Creative Dissidence

Published 20 years, 3 months past

Self-described ‘Web hobbyist’ François Briatte recently conducted a survey of ten sites, comparing them on 25 different points, and has published the results.  I suggested that those responsible for the sites that were reviewed might write up their perspectives on the rankings and their dissidence levels, as Dave Shea and Jon Hicks have already done.  I tied for John Gruber for third, which amuses me.

I’ve seen some criticism of this survey scattered about, with two points made:

  1. The survey is too small, only examining ten sites.
  2. The survey is too limited in terms of the kinds of sites studied (all ten are basically Web design blogs, to one degree or another).

True, François picked ten sites instead of several hundred, all ten being sites that François reads regularly, and looked at them in detail.  Well, at least he went to the effort of doing it and publishing the results for free.  Don’t like the number of sites, or the sites surveyed, or the questions that were asked?  Fine.  Do your own survey and publish the results.  We’re waiting.  I’d actually like to see more such surveys, especially those done with the impressive degree of thoroughness and thought that François displayed.

Here are my thoughts about meyerweb’s rankings and the criteria in general; I’ll stick to commenting on those points where I differed from the crowd, or else where I think there’s something particularly interesting to note.

Are links underlined / are hovered links underlined / do visited links differentiate? (yes on all three)

As it turns out, my site is acting as a mirror for François’ browser preferences: I don’t assert link styles at all.  What I’d be interested to know is how many of the surveyed sites follow the same path.  My guess is few, or none.  Even Jakob‘s style sheet asserts link styles.

Is the layout fixed in width? (no)

Mine is not, and that leaves me in a strong minority.  I prefer a layout that flexes with the browser window, and I suspect I always will.  This does mean that the layout can start overlapping itself at very narrow window widths, but then a fixed-width design forces a scrollbar at narrow widths.  Which is better?  I’ve made my choice, of course, as have all the others surveyed.  I’ve yet to decide one way or the other is truly better, although of course many people have very strong opinions.

Is there a search box? (no)

I should probably add one, but for some reason it just never seems like a critical priority.  There is a search function on the archive pages for “Thoughts From Eric”, but that comes built into WordPress.  It may be that my reluctance stems from the fact that I’d probably end up using a Google search box, which seems like cheating.  I should probably get over myself and just do it.

Are “steal these” buttons used? (yes)

Dave Shea’s reaction was: “Ugh. Please, no.”  I think they’re useful, both for RSS feeds and for the “XFN Friendly” badge.  I’d also like to think they’re well integrated into my design (such as it is), although obviously that’s a matter of taste.

Does the navigation bar use image rollovers? (no)

Nope, it’s all text.  I may one day get fancier about the design (don’t hold your breath) and if so, I’ll probably have some kind of image rollover for the navigation.  At the least, I’d use a Sliding Doors-type decoration, which could count as an image rollover effect.

Is there a print stylesheet? (yes)

I have to admit to some surprise that the majority of the sites didn’t use one.  Mine is pretty low-key, doing basic things like preventing the sidebar from being printed.  I wish more sites did that kind of thing.  A link-filled sidebar is as useless on the page as it is useful on the Web.

Is the page UTF-8 encoded? (no)

I’m still kickin’ it ISO-8859-1 style.  This is in part because when I tried to enable UTF-8 encoding a while back, all my characters got thoroughly mangled.  I spent some time trying to fix it, and then dropped back to 8859, which I knew would work.  If I ever figure out how to do UTF-8 correctly, I’ll probably switch over.

Is the DOCTYPE Strict / is the page XHTML / is there an XML prolog? (no on all three)

I use HTML 4.01 Transitional, so clearly there wouldn’t be an XML prolog.  Even if I used XHTML, there wouldn’t be one, since its presence triggers quirks mode in IE6/Win—thus the 100% agreement among the surveyed sites on its absence.

So why HTML instead of XHTML?  Because there continue to be no major advantages to valid XHTML over valid HTML, which is what I strive to attain.  In some sense, there are disadvantages, albeit of a minor variety—I find trailing slashes on empty elements and the lack of attribute minimization to be annoying.  If I’d learned XHTML first, I’m sure I wouldn’t care about them, and would wonder why HTML was deficient in those areas.  Since I taught myself HTML when the cutting edge was HTML 2.0, I have some fairly deeply ingrained habits that cause me to lean toward HTML.  I also have a decade’s worth of documents that I don’t really feel like trying to convert to XHTML just so I can claim big markup geek bragging points.  Sure, there are tools that will do it for me.  Then I’d have to go back and check to make sure the tools didn’t mangle anything.

I’ve gotten the occasional critical e-mail about this over the past couple of years, chastising me for not being a role model in this area.  I like to think that I am.  I’m trying to show, by example, that there’s nothing wrong with using HTML 4.01 as long as you’re using it correctly.  If your HTML is valid, you’ll have no more trouble converting it to a ‘pure’ XML format than you will if XHTML is your starting point.  So I stay with HTML, and probably will for some time to come.

One other point: the education of my quotes is entirely due to WordPress, and in pages that aren’t part of WP I don’t have educated quotes.  C’est la mort.

I’ve already written François to congratulate him on his work, which I think is a good look at the underpinnings of the sites surveyed and sheds some light on points that don’t get discussed very often—or when they are, it’s in needlessly polarizing ways (witness the various flame wars over fixed width vs. liquid width, HTML vs. XHTML, and so on).  It’s refreshing to see someone collect some facts, do a little analysis, and freely share the results.


Pocket Style, Take Two

Published 20 years, 4 months past
A picture of the cover of 'CSS Pocket Reference, Second Edition'

Just a few hours ago, I received a FedEx package containing a brand spankin’ new copy of the CSS Pocket Reference, 2nd Edition.  This new edition includes all of the CSS2 and CSS2.1 properties and values, information and algorithms covering the box model, table layout, font selection, and more.  It’s almost 130 pages, and that’s without a single page of it taken up by support charts.  The first edition has taken some flak for being obsolete; this new edition should address those concerns.  (Unless of course you want a CSS3 pocket reference, in which case this book won’t help you, and anyway, you’ll need much bigger pockets.)

And it’s still just $9.95!  What a bargain.  You should buy two.  That way you can have one for your pocket, where it will be handily available at all times, and the other for your bookshelf, where it will stay crisp and neat.

For a while I’d had a vague plan that, when this book’s arrival was announced, I would take that opportunity to say that I was taking a break from book writing for a while.  So much for that plan; I just today agreed to start another project.  Looks as though Molly was right about me.  I wonder how long it will be until there’s a cure…


Floating Points

Published 20 years, 4 months past

It seems I was a little unclear in my recent post about floats, and compounded the problem with the post title.  A number of responses said, basically, “maybe they’re bad for layout but what else is available?”  I didn’t mean to suggest that nobody should use floats for layout, or that using them in that manner is somehow wrong; my apologies if I did so.  There aren’t too many alternatives; in fact, there are precisely three general standards-based layout options.

  1. Floats
  2. Positioning
  3. Tables

Each of these options has its benefits and drawbacks.  All I was trying to say is that Andrei was dead on in his feeling that layout floats feel like something that have been bent to a purpose for which they weren’t intended.  That’s true.  Floats are simple, and were meant to do a very limited thing.  Push them hard enough into other roles, and they become a touch balky.  If nothing else, their source-order dependencies make them less flexible than one might like, and variances in browser handling of floats (many of those variances having to do with how one should deal with floats in their intended role) just makes the situation more frustrating.

One could argue that all three options are non-layout technologies that have been bent to layout purposes, but positioning at least was intended to be a layout mechanism from its inception.  It suffers from enough glaring flaws and browser bugs that it can’t be considered any better an option than the others, though.

In a move that may help matters, Shaun Inman (he of the Inman Flash Replacement technique) has just published the article Clearing Absolutes Again, which  further develops his attempts to give positioned elements a clear-like capability.  This is a very welcome development.  The IPC (Inman Position Clearing) technique may not be perfect— I haven’t had time to dig into it, so I don’t know— but it’s a fifty-foot neon arrow pointing in the direction things need to go.  Since we can’t expect this sort of capability to be added to CSS in the near future, let alone have enough browsers support it in the next few years, scripting our own fixes is the only reasonable solution I can see.  For another great big neon arrow of this kind, see Dean Edwards’ IE7.

And yes, I said “tables” back there.  If you can avoid using tables for layout, then by all means do, but it isn’t always possible.  In such cases, as long as the tables use as little markup as possible, and the markup validates, then I don’t see the problem.  Never have, really.  My whole objection to tables-for-layout has been, and continues to be, that most table-based designs use way too much markup.  Often you see markup-to-content ratios in the vicinity of 3:1.  That’s just icky.  I much prefer to see the inverse of that ratio, or at least something below 1:1.  CSS helps immensely in getting there.

Update: see Shaun’s new new post on the topic, “Absolute Clearance“, for another step in the evolution of his technique.  Ever forward!


Competent Classing

Published 20 years, 4 months past

At last week’s Web Design Meetup, a couple of people showed me their current projects.  As is my wont, I glanced over the visual design and then started digging into the document markup.  In the course of the resulting conversation, I pointed out some ways to tighten up the markup.  I’ll repeat them here for those who are curious.  All of them relate to using classes and IDs efficiently.

The first recommendation I had was to use classes and IDs in conjunction.  Not everyone is aware that an element can carry both a class and an ID.  Well, they can.  So it’s no problem to have markup like this:

<div id="utilities" class="menu">

That way, you can style all menus consistently via the menu class, while having the utilities ID there for any ‘Utilities’-specific styling you need to do.  This has always been possible, and it’s supported by multiple browsers.  You don’t see it often, I admit, but then it’s not often needed.

The second recommendation was to use space-separated words in your class values.  This is thoroughly legitimate, and can make things a lot more compact.  So you might have something like:

<td class="subtotal negative">(-$422.72)</td>

You can then have one rule that styles all subtotals, and another than styles any negative number.  For example:

.subtotal {font-weight: bold;}
.negative {color: red;}

By using these kinds of class values, you can avoid having to construct one class for subtotal, and another for subtotal-negative.  If you’re doing that sort of thing, I can tell you right now that your CSS is larger and more complicated than it needs to be.  Multiple-word class names also free you from having to do things like throw in extra spans or other elements just to add more information, like so:

<td class="subtotal"><span class="negative">(-$422.72)</span></td>

That kind of structure is almost never needed, except in extremely rare cases where you must have an inline element on which you hang some presentational styles that can’t be applied to the table cell.  I can’t even think of a concrete example right now, but I’m sure there is one.  In which case, I’d say do this instead:

<td class="subtotal negative"><span>(-$422.72)</span></td>

But, as I say, the odds of your having to do that are very very low.

All this leads to a third recommendation that came to mind as I looked over the markup.  Remember to use document structure to your advantage, and not to class everything in sight.  I can’t tell you how many times I’ve seen this kind of markup:

<div class="navlinks">
<a href="blah01" class="navlink">Blah01</a> |
<a href="blah02" class="navlink">Blah02</a> |
<a href="blah03" class="navlink">Blah03</a> |
<a href="blah04" class="navlink">Blah04</a> |
<a href="blah05" class="navlink">Blah05</a>
</div>

Out of the six classes that appear in that markup fragment, five are completely useless and simply bloat the page weight.  Here’s a much more efficient way to structure the markup:

<div class="navlinks">
<a href="blah01">Blah01</a> |
<a href="blah02">Blah02</a> |
<a href="blah03">Blah03</a> |
<a href="blah04">Blah04</a> |
<a href="blah05">Blah05</a>
</div>

Now all you do to style the links is write a rule that uses the selector div.navlinks a instead of one that uses a.navlink.  In addition to making the HTML weight smaller, it also makes the document cleaner and a whole lot easier to read.  Your users don’t really care about that, of course, but I bet you will, if you ever have to go in and adjust either the markup or the content.

So there you go.  Hopefully it was of some help to you.


Luminous Beings

Published 20 years, 4 months past

After collecting one hundred posted comments (and four pings) for the post “Wanted: CSS Luminary“, I closed comment posting and tallied the results.  This involved going through the comments and compiling a list of every name that was mentioned.  Once I filtered out duplicate or followup posts, I was left with a list of fifty-six names. Then I counted up the number of posts in which each name appeared, so any post that mentioned the same name more than once only registered a single vote for that person.  That yielded the top ten most-mentioned names, shown in Table 1.

Table 1. Most-mentioned names
RankNameMentions
1 Dave Shea 40
2 Doug Bowman 19
3 Jeffrey Zeldman 17
4 Dan Cederholm 14
5 Andy Budd 12
6 John Gallant 11
Tantek Çelik 11
8 Holly Bergevin 10
9 Molly Holzschlag 8
10 D. Keith Robinson 7

I also decided to do some weighted scoring, like I used to do with the CSS Leader Board back in the day.  For this situation, the first name listed in a post was counted as a ‘primary mention’.  Any name listed second was a ‘secondary mention’, and a name after that a ‘tertiary mention’.  Any names after that were lumped together in a category called ‘hrair mention’, which I guess means I can’t even count as high as rabbits.  I gave five points for every primary mention, three points for every secondary mention, two for a tertiary mention, and one point for each hrair mention.  That yielded the same ten names and the same leaders, but the mid-field order got rearranged, as you can see in Table 2.

Table 2. Highest-scoring names
RankNameScore
1Dave Shea 162
2Doug Bowman 53
3Dan Cederholm 49
John Gallant 49
5Jeffrey Zeldman 47
Tantek Çelik 47
7Holly Bergevin 40
8Molly Holzschlag 38
9Andy Budd 30
10D. Keith Robinson 23

So there you have it: the results of my wholly unscientific and vaguely subjective poll.  I’ll be passing the results along to the publisher in question, mostly by e-mailing the URL of this entry.  My thanks to everyone who responded, and congratulations to those who made the list!  I for one welcome our stylish new overlords.

For reference, here’s the entire list of names that was collected from the comments, sorted alphabetically by last name.

  • Cameron Adams
  • John Allsopp
  • Holly Bergevin
  • Bert Bos
  • Doug Bowman
  • Owen Briggs
  • Andy Budd
  • Dan Cederholm
  • Tantek Çelik
  • Andy Clarke
  • Simon Collison
  • Eric Costello
  • Mike Davidson
  • Kevin Davis
  • Meryl Evans
  • Todd Fahrner
  • John Gallant
  • Peter Gifford
  • Daniel Glazman
  • Danny Goodman
  • Patrick Griffiths
  • Aaron Gustafson
  • Jeremy Hedley
  • Andrei Herasimchuk
  • Jon Hicks
  • Ian Hickson
  • Didier Hilhorst
  • Molly Holzschlag
  • Dave Hyatt
  • Shaun Inman
  • Makiko Itoh
  • Jeremy Keith
  • Egor Kloos
  • Peter-Paul Koch
  • Patrick Lauke
  • Seamus Leahy
  • Håkon Lie
  • ‘Literary Moose’
  • ‘Meg at Mandarin’
  • Cameron Moll
  • Stu Nicholls
  • Paul O’Brien
  • Dunstan Orchard
  • Mike Pick
  • D. Keith Robinson
  • Richard Rutter
  • Blake Scarbrough
  • Christopher Schmitt
  • Dave Shea
  • Sue Sims
  • Petr Stanicek
  • Greg Storey (?)
  • Anne van Kesteren
  • Russ Weakley
  • Simon Willison
  • Jeffrey Zeldman

All right, I lied.  There were three suggested names I left off the list: John Kerry, George W. Bush, and Bill Gates.  I omitted them because none of the three men are known to have spent any time writing about or using CSS.  But hey, if either Kerry or Bush mentions CSS positively in a campaign speech, and isn’t talking about the Content Scrambling System, I’ll give him my vote!

Okay, that’s also a lie.


Wrapped in Canvas

Published 20 years, 4 months past

In his most recent post on the underpinnings of the Dashboard, titled Introducing the Canvas, Dave Hyatt said the following:

Another extension we made to HTML is a new element called the canvas. This element is essentially an image element that supports programmatic drawing.

And then, a bit later on:

In addition to the canvas element, we’ve also introduced a new attribute onto the img element. The composite attribute allows you to control how an image gets composited.

Wait a minute.  Did I just get hit over the head and magically transported back to 1994?  New HTML elements and attributes?  What the bleeding hell?!?

[insert sound of forehead banging repeatedly on desktop here]

I hope I’m reading his post incorrectly.  I hope that what Dave is really saying is that Dashboard widgets are actually XML, albeit an XML that looks very much like HTML except they’ve added some nifty stuff to it.  If so, great, fine, no problem.  XML lets you do whatever you want, really.  But if these are widgets that use actual HTML DOCTYPEs, and yet add this stuff, then the throbbing vein in my forehead is going to rupture and spray blood all over my shiny TiBook.  We just left that tag soup party.  I really don’t want to have another steaming, fetid bowl of it plopped down in front of me.  Not even one that exists in a ‘closed’ environment like OS X.

Even if Dashboard widgets are currently built around invalid HTML documents, it seems like there’s still plenty of time to convert them to well-formed XML, thus (largely) solving the problem.  Heck, there’s even time to create a DTD for the widgets, thus permitting the widgets to be both well-formed and valid.  I’m all in favor of that approach.  As a measure of last resort, a new HTML DTD could be written for “Dashboard HTML 1.0” or something like that.

But if it’s all really broken HTML 4.01, not XML, then there’s a serious problem.  From a forward-compatibility perspective, the Dashboard would be no better than Microsoft’s CSS-like extensions, the ones that let authors change the appearance of the browser’s scrollbars and other such wackiness.  In fact, they’d be much worse because there now exists the ability to create the Dashboard within the open framework the W3C has (slowly and painstakingly) created.  To ignore that would be the worst kind of regressive move.


Browse the Archive

Earlier Entries

Later Entries