Posts in the Web Category

CSS3 Feedback: Selector Blocks

Published 16 years, 7 months past

(This is part of the Feedback on ‘WaSP Community CSS3 Feedback 2008’ series.)

Out of all the selector feedback, selector blocks was the part that really caught my attention.  I also see the usefulness of a parent selector, but that one has come up many times before, and it’s always died at the doorstep of implementors, who point out that it’s far too difficult to implement without serious performance penalties and even risk of browser lockup.  See, for example, the comment left by David Hyatt on Shaun Inman’s post on the idea.  Similarly, I think constants (or macros or whatever they’re called) are a great idea and would be very helpful, especially if you’re coding up a Jason Special.  Both are loaded with use cases, so I don’t feel like I can add a lot; besides, constants are already in the WG charter, so there’s once more hope in the land.

So anyway, selector blocks.  To pick one recent example, while working on a project that should very soon see the light of day, I had a situation involving the following chunk of rules. 

h1, h2, h3, h4, h5, h6, table {
   font: 1em Arial, "Helvetica Neue", Helvetica, sans-serif;}
h1 {font-size: 275%;}
h3:first-child {margin-top: 1em;}
p.tagline {margin: -0.25em 0 1.25em;
   font-size: 125%;
   color: #7B7960;}
h3 {margin: 1.5em 0 0.25em; font-size: 125%;}
h3:before {font-size: 75%; counter-increment: subhead;}
h4 {margin: 2.5em 0 0.75em;
   text-transform: uppercase; font-size: 125%;
   color: #928F59;}
p {margin: 0 0 1em;}
ul {padding-left: 1.5em;}
ul li {list-style: disc; margin: 0.5em 0;}

Nothing unusual about them, of course, unless you count my use of counters.  These rules had been written early on in development, and the design had evolved around that part of the document.  As more page components were added, I realized that I needed to scope all these rules to one section of the document: specifically, a div with a class of main.  So here’s what I had to do. 

.main h1, .main h2, .main h3, .main h4, 
.main h5, .main h6, .main table {
   font: 1em Arial, "Helvetica Neue", Helvetica, sans-serif;}
.main h1 {font-size: 275%;}
.main h3:first-child {margin-top: 1em;}
.main p.tagline {margin: -0.25em 0 1.25em;
   font-size: 125%;
   color: #7B7960;}
.main h3 {margin: 1.5em 0 0.25em; font-size: 125%;}
.main h3:before {font-size: 75%; counter-increment: subhead;}
.main h4 {margin: 2.5em 0 0.75em;
   text-transform: uppercase; font-size: 125%;
   color: #928F59;}
.main p {margin: 0 0 1em;}
.main ul {padding-left: 1.5em;}
.main ul li {list-style: disc; margin: 0.5em 0;}

This, on the other hand, is what I really wanted to do: 

.main {
   h1, h2, h3, h4, h5, h6, table {
      font: 1em Arial, "Helvetica Neue", Helvetica, sans-serif;}
   h1 {font-size: 275%;}
   h3:first-child {margin-top: 1em;}
   p.tagline {margin: -0.25em 0 1.25em;
      font-size: 125%;
      color: #7B7960;}
   h3 {margin: 1.5em 0 0.25em; font-size: 125%;}
   h3:before {font-size: 75%; counter-increment: subhead;}
   h4 {margin: 2.5em 0 0.75em;
      text-transform: uppercase; font-size: 125%;
      color: #928F59;}
   p {margin: 1em 0;}
   ul {padding-left: 1.5em;}
   ul li {list-style: disc; margin: 0.5em 0;}
}

Or, if necessary, to put the whole original chunk into its own style sheet and then do one of the following: 

div.main {@import url(main-style.css);}

<div class="main" style="@import url(main-style.css);">

Interestingly, the latter is theoretically possible, thanks to the more advanced profiles in the CSS module “Syntax of CSS rules in HTML’s ‘style’ attribute“.  I’m not aware of the former having been seriously considered (despite my best efforts, once upon a time), though it’s always possible I missed something.

But either one of those approaches would be a last resort, in my opinion.  I’d much rather just wrap the whole chunk in .main { }, like I showed previously, and be done with it.  That capability would also simplify certain annoyingly repetitive patterns, like the very first of those rules.  I think it’s pretty obvious which of the following is easier to write and maintain: 

body.home #content .entry h2, 
body.home #content .entry h3, 
body.home #content .entry h4, 
body.home #content .entry h5, 
body.home #content .entry h6 {...}

body.home #content .entry {
   h2, h3, h4, h5, h6 {...}
}

I mean, just look at the former, and imagine what one goes through to write it in the first place.  Copy, paste, paste, paste, paste, paste… maddening.  And that’s just for a small block of CSS like this one.  Imagine the tedium of doing this for a block of 50 rules, or 150.  (Also, this is the the same thing that was requested in the feedback as “Grouped Alternates“, albeit with a different syntax.)

One objection to this sort of pattern is that it increases dependence on descendant selectors, which are computationally inefficient.  But it doesn’t: I had to create a whole bunch of descendant selectors as it was, and did so far more clumsily.  And had I missed a command-V somewhere, I’d have had styles that applied outside their intended subtree.  Introducing a way to nest blocks like this doesn’t change anything except make it easier and more maintainable to do what we already do.  Honestly, it’s pretty much impossible to increase dependence on descendant selectors.  The best we can do now is make them less difficult to write.

I realize that the syntax I depict would cause backwards-compatibility problems, as in older browsers would not behave as intended when exposed to this sort of thing, but I’ve also stopped being concerned about that.  We can’t keep holding ourselves hostage to decisions made a decade or more back.  Provide the capability and authors will use it when they can.  Over time, its use will become more prevalent—kind of the same way authors adopted CSS in the first place.

I also realize that this case has been made time and again by many, many other people.  This isn’t even the first time I’ve made this case, though I think the other times were within the WG and therefore off the public record.  The fact that it keeps being made is a strong indicator that the need exists, and dismissing the idea because the same end effect can be achieved with existing selector syntax (as shown above) isn’t acceptable.  That’s like saying that complex selection effects can be achieved with JavaScript or XPath, so there’s no need for advanced CSS selectors.

So that’s my use case.  I actually have a bunch more, but they all follow the same basic pattern: the desire to group rules together into subsections of a document, or to otherwise simplify the writing of CSS.

Feedback on ‘WaSP Community CSS3 Feedback 2008’

Published 16 years, 7 months past

Back before holiday season hit, Elika Etemad—better known as Fantasai—published WaSP Community CSS3 Feedback 2008.  I gave it a read and came away with a number of things I wanted to say.  So many things, in fact, that I’ll need to split them up into a series of posts.  This here post will serve as introduction and hub, with links to the follow-on entries added as they’re published.  All very Bray-ny, no?  (Go ahead, groan.  It only encourages me.)

Here you go:

  1. Selector blocks
  2. Layout
  3. Wanted: Layout System
  4. Animated Shapes
  5. Graphical Thoughts

I want to make clear up front that I’m not going to address every single point in the feedback document: it’s just too incredibly huge.  I did think about making my own copy and then just filling in my reactions to each point, but that didn’t scale very well.  Not only did it seem really overbearing and maybe just a touch egotistical, but some of my reactions were based on related topics in separate areas of the original.  Besides, I know what it’s like trying to read a really, really long article, so breaking it up and just focusing on the parts that got me fired up made way more sense.

There is one thing I want to address before I start serving up the follow-on installments.  At the end of Fantasai’s post, there’s a link to my 2006 post about the benefit of having a community liaison, someone who bridges the gap between the WG and the public.  She then asks if anyone is interested in volunteering, but personally, I don’t see the need.  The WG already has a community liaison:  it’s you, Fantasai.  It has been for some time now, thanks to your regular and informative CSS WG blog posts and other outreach work such as “WaSP Community CSS3 Feedback 2008”.  The job is being done, and being done very well, I don’t think there’s any doubt that the Working Group is much, much better for it.

Using HTTP Headers to Serve Styles

Published 16 years, 7 months past

How many times have you played out the following scenario?

  1. Makes local changes to your style sheet(s).
  2. Upload the changes to the staging server.
  3. Switch to your browser and hit “reload”.
  4. Nothing happens.
  5. Force-reload. Nothing happens.
  6. Go back to make sure the upload is finished and successful.
  7. Reload again.  Still nothing.
  8. Try sprinkling in !important.  Upload, reload, nothing.
  9. Start swearing at your computer.
  10. Check Firebug to see what’s overriding your new styles.  Discover they aren’t being applied at all.
  11. Continue in that vein for several minutes before realizing you were hitting reload while looking at the live production server, not the staging server.
  12. Go to the staging server and see all your changes.
  13. Start swearing at your own idiocy.

This happened to me all the time as we neared completion of the redesign of An Event Apart.  It got to the point that I would deliberately add obvious, easily-fixable-later errors to the staging server’s styles, like a light red page background.

Now that we’re launched and I have time to actually, you know, think about how I do this stuff, it occurred to me that what I should have done is create a distinct “staging” style sheet with the obvious error or other visual cue.  Maybe repeat the word “staging” along the right side of the page with a background image, like a watermark: 

html {background: url(staging-bg.png) 100% 50% repeat-y;}

Okay, cool.  Then I just need to have that served up with every page on the staging server, without it showing up on the production server.

One way to do that is just make sure the image file never migrates to production.  That way, even if I accidentally let the above CSS get onto production, the user will never see it.  But that’s inelegant and wasteful, and fragile to boot: if the styles accidentally migrate, who’s to say the image won’t as well?  And while I’m sure there are all kinds of CMS and CVS and Git and what-have-you tricks to make sure that doesn’t happen, I am both clumsy and lazy.  Not only do I have great faith in my ability to screw up my use of such mechanisms, I don’t really want to be bothered to learn them in the first place.

So: why not send the link to the style sheet using HTTP headers?  Yeah, that’s the ticket!  I can just add a line to my .htaccess file on the staging server and be done.  Under Apache, which is what I use: 

Header add Link "</staging.css>;rel=stylesheet;type=text/css;media=all"

Those angle brackets are, so far as I can tell, absolutely mandatory, so bear that in mind.  And of course the path in those brackets can be absolute, unlike what I’ve shown here.  I’m sure there are simple PHP equivalents, which I’ll leave to others to work out.  I really didn’t need to add the media=all part, but what the heck.

Seems so simple, doesn’t it?  Almost… too simple.  Like there has to be a catch somewhere.  Well, there is.  The catch is that this is not supported by all user agents.  Internet Explorer, for one; Safari, for another.  It does work in Opera and Gecko browsers.  So you can’t deploy this on your production server, unless of course you want to use it as a way to hide CSS from both IE and Safari.  (For whatever reason.)  It works great in Gecko-based production environments like mine, though.

I looked around for a quick how-to on do this, and couldn’t find one.  Instead, I found Anne van Kesteren’s test page, whose headers I sniffed in order to work out the proper value syntax; and a brief page on the Link header that didn’t mention CSS at all.  Nothing seemed to put the two of them together.  Nothing until now, that is.

An Event Apart and HTML 5

Published 16 years, 8 months past

The new Gregorian year has brought a striking new Big Z design to An Event Apart, along with the detailed schedule for our first show and the opening of registration for all four shows of the year.  Jeffrey has written a bit about the thinking that went into the design already, and I expect more to come.  If you want all the juicy details, he’ll be talking about it at AEA, as a glance at the top of the Seattle schedule will tell you.  And right after that?  An hour of me talking about coding the design he created.

One of the things I’ll be talking about is the choice of markup language for the site, which ended up being HTML 5.  In the beginning, I chose HTML 5 because I wanted to do something like this: 

<li>
<a href="/2009/seattle/">
<h2><img src="/i/09/city-seattle.jpg" alt="Seattle" /></h2>
<h3>May 4—5, 2009</h3>
<p>Bell Harbor International Conference Center</p>
</a>
</li>

Yes, that’s legal in HTML 5, thanks to the work done by Bruce Lawson in response to my href-anywhere agitation.  It isn’t what I’d consider ideal, structurally, but it’s close.  It sure beats having to make the content of every element its own hyperlink, each one pointing at the exact same destination: 

<li>
<h2><a href="/2009/seattle/"><img src="/i/09/city-seattle.jpg" alt="Seattle" /></a></h2>
<h3><a href="/2009/seattle/">May 4—5, 2009</a></h3>
<p><a href="/2009/seattle/">Bell Harbor International Conference Center</a></p>
</li>

I mean, that’s just dumb.  Ideally, I could drop an href on the li instead of having to wrap an a element around the content, but baby steps.  Baby steps.

So as Bruce discovered, pretty much all browsers will already let you wrap a elements around other stuff, so it got added to HTML 5.  And when I tried it, it worked, clickably speaking.  That is, all the elements I wrapped became part of one big hyperlink, which is what I wanted.

What I didn’t want, though, was the randomized layout weirdness that resulted once I started styling the descendants of the link.  Sometimes everything would lay out properly, and other times the bits and pieces were all over the place.  I could (randomly) flip back and forth between the two just by repeatedly hitting reload.  I thought maybe it was the heading elements that were causing problems, so I converted them all to classed paragraphs.  Nope, same problems.  So I converted them all to classed spans and that solved the problem.  The layout became steady and stable.

I was happy to get the layout problems sorted out, obviously.  Only, at that point, I wasn’t doing anything that required HTML 5.  Wrapping classed spans in links in the place of other, more semantic elements?  Yeah, that’s original.  It’s just as original as the coding pattern of “slowly leaching away the document’s semantics in order to make it, at long last and after much swearing, consistently render as intended”.  I’m sure one or two of you know what that’s like.

As a result, I could have gone back to XHTML 1.1 or even HTML 4.01 without incident.  In fact, I almost did, but in the end I decided to stick with HTML 5.  There were two main reasons.

  1. First, AEA is all about the current state and near future of web design and development.  HTML 5 is already here and in use, and its use will grow over time.  We try to have the site embody the conference itself as much as possible, so using HTML 5 made some sense.

  2. I wanted to try HTML 5 out for myself under field conditions, to get a sense of how similar or dissimilar it is to what’s gone before.  Turns out the answers are “very much so” to the former and “frustratingly so” to the latter, assuming you’re familiar with XHTML.  The major rules are pretty much all the same: mind your trailing slashes on empty elements, that kind of thing.  But you know what the funniest thing about HTML 5 is?  It’s the little differences.  Like not permitting a value attribute on an image submit.  That one came as a rather large surprise, and as a result our subscribe page is XHTML 1.0 Transitional instead of HTML 5.  (Figuring out how to work around this in HTML 5 is on my post-launch list of things to do.)

    Oh, and we’re back to being case-insensitive.  <P Class="note"> is just as valid as <p class="note">.  Having already fought the Casing Wars once, this got a fractional shrug from me, but some people will probably be all excited that they can uppercase their element names again.  I know I would’ve been, oh, six or seven years ago.

    Incidentally, I used validator.nu to check my work.  It seemed the most up to date, but there’s no guarantee it’s perfectly accurate.  Ged knows every other validator I’ve ever used has eventually been shown to be inaccurate in one or more ways.

I get the distinct impression that use of HTML 5 is going to cause equal parts of comfort (for the familiar parts) and eye-watering rage (for the apparently idiotic differences).  Thus it would seem the HTML 5 Working Group is succeeding quite nicely at capturing the current state of browser behavior.  Yay, I guess?

And then there was the part where I got really grumpy about not being able to nest a hyperlink element inside another hyperlink element… but that, like so many things referenced in this post, is a story for another day.

Survey Halfway

Published 17 years, 1 month past

Okay, so yes, I posted about this two weeks ago and haven’t said anything since, but still: we’re halfway to the close of this year’s survey, so if you haven’t already done so, please devote ten minutes to taking it now!  You’ll make your voice heard along with literally thousands of fellow web professionals, hobbyists, and other people who make websites.  My copy of Excel is already weeping at the thought of having to crunch all that data, and I think that if there’s one thing on which we can all agree, it’s that anything which makes Excel cry is a good thing.

I TOOK IT! and so should you: The Survey for People Who Make Websites

Thank you.

I Took the 2008 ALA Survey

Published 17 years, 1 month past

Ladies and gentlemen, it’s back, bigger and better than ever.  Please read Jeffrey’s wonderful introduction, and then start answering!  It shouldn’t take much more than 10 minutes to complete (it took me 6 minutes, 44 seconds, but who’s counting?).

I TOOK IT! and so should you: The Survey for People Who Make Websites

Last year, we had an astonishing 32,831 responses; I can only imagine where we’ll end up this year.  And just as with last year, we will report our findings and release an anonymized raw data set.

The more people who take the survey, the better the results will be, so please—post the link on any relevant sites, mailing lists, discussion boards, or other communities.  Print up flyers and post them around your town.  Anything we can do to get the word out!

Thank you.

Crafting Ourselves

Published 17 years, 5 months past

My referrers lit up recently due to Jonathan Snook’s article about CSS resets and how he doesn’t use them.  To Jonathan and all the doubters and nay-sayers out there, I have only one thing to say:

Good for you.

Seriously; no sarcasm or passive-aggressiveness intended.  If I thought my reset styles, or really anything I’ve ever published or advocated, was a be-all end-all ultimate solution for every designer and design that’s ever been and could ever be, I’d be long past due for six rounds on the receiving end of a clue-by-four.

Reset styles clearly work for a lot of people, whether as-is or in a modified form.  As I say on the reset page, those styles aren’t supposed to be left alone by anyone.  They’re a starting point.  If a thousand people took them and created a thousand different personalized style sheets, that would be right on the money.  But there’s also nothing wrong with taking them and writing your own overrides.  If that works for you, then awesome.

For others, reset styles are more of an impediment.  That’s only to be expected; we all work in different ways.  The key here, and the reason I made the approving comment above, is that you evaluate various tools by thinking about how they relate to the ways you do what you do—and then choose what tools to use, and how, and when.  That’s the mark of someone who thinks seriously about their craft and strives to do it better.

I’m not saying that craftsmen/craftswomen are those people who reject the use of common tools, of course.  I’m saying that they use the tools that fit them best and modify (or create) tools to best fit them, applying their skills and knowledge of their craft to make those decisions.  It’s much the same in the world of programming.  You can’t identify a code craftsman by whether or not they use this framework or that language.  You can identify them by how they decide which framework or language to use, or not use, in a given situation.

Craftsmanship is something I’ve been thinking about quite a bit recently, as has Joshua Porter.  I delivered a keynote address on that very topic just a few days ago in Minneapolis, and my thinking infuses both of the talks I’m giving next week at An Event Apart New Orleans.  I’ve started looking harder for evidence of it, both in myself and in what I see online, and I believe striving toward being a craftsman/craftswoman is an important process for anyone who chooses to work in this field.

Because this isn’t a field of straightforward answers and universal solutions.  We are often faced with problems that have multiple solutions, none of them perfect.  To understand what makes each solution imperfect and to know which of them is the best choice in the situation—that’s knowing your craft.  That’s being a craftsman/craftswoman.  It’s a never-ending process that is all the more critical precisely because it is never-ending.

So it’s no surprise that we, as a community, keep building and sharing solutions to problems we encounter.  Discussions about the merits of those solutions in various situations are also no surprise.  Indeed, they’re exactly the opposite: the surest and, to me, most hopeful sign that web design/development continues to mature as a profession, a discipline, and a craft.  It’s evidence that we continue to challenge ourselves and each other to advance our skills, to keep learning better and better how better to do what we love so much.

I wouldn’t have it any other way.

Expressive Sculptor

Published 17 years, 6 months past

For those of you using Microsoft Expression Web, a free pre-release trial version of CSS Sculptor for Expression Web was announced by the WebAssist folks on Wednesday at MIX08.  So now you don’t have to put up with those snooty Dreamweaver users throwing you the mëtäl hörns every chance they get—throw ’em right back!  Røck!

If you’re curious about CSS Sculptor, I posted in some detail about it when it was first released in August 2007, and there’s of course plenty of enthusiastic copy about it on the WebAssist site.

One thing that’s different about the Expression version as compared to the Dreamweaver version is that it doesn’t have an “Apply” button to apply the input CSS ito the preview window.  Instead, changes are instantly reflected in the little preview.  It’ll be interesting to see how users react to that, since it could mean that the previewed design shatters as the CSS is updated, and then snaps back together upon further changes.  Is that good or bad tool usability?  Hard to say; it could scare people into undoing the shatter-change and never pushing forward, but it could also help users more quickly gain a deeper understanding of CSS by seeing how things come apart and then go back together.  I guess we’ll find out!

Browse the Archive

Earlier Entries

Later Entries