meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Archive: January 2009

London CSS/XHTML Workshop

Hey all, and especially those of you in the EU: I’m going to be doing an all-new one-day workshop in London in early March via the offices of Carson Workshops, for whom I’ve done workshops in the past.  Previously I’ve done two-day gigs with a beginner-to-intermediate skill range, but this time we’re trying something different.  I’m going to get down and dirty with some tough topics, and really push hard at the limits of what CSS and semantic markup can do.

You can get the details at the CW site, and note the special price for the first quarter of the seats.  That’s right, this will be a small, intimate workshop, with plenty of chances for questions about and challenges to what I’m saying.  Previous workshops have featured some really great conversations among everyone there, and I expect the same this time around.

I had meant to blog this before life intervened and took me out of my wifi cloud (and more on that soon), so time is a little more of the essence than usual—if you know someone who you think might be interested, pass the word on, willya?  Thanks!

Using HTTP Headers to Serve Styles

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.

Bahstahn: the Gathering

The Robot speaks truth: I will be visiting the northern reaches of the greater Boston area in the first few days of February to do some client training (which is one of the many things I do).  To celebrate, I’ve managed to pull the Markup & Style Society (which of course includes that simplest of bits, the inestimable Mr. C.) out of hibernation, get them to link up with the Build Guild, and have the two jointly sponsor a gathering open to all who wish to join us.  Welcome to the social!

This massively meritorious meeting of minds will take place on 2 February 2009 in historic Salem, MA:  here’s the Upcoming entry with all the details and RSVP action.  If you plan to be with us, make your voice heard.  Or, if you’re the fearsome and mighty Windhammer, who rumor has it may also be there, bring forth thunder!  On the Upcoming page.

Hope to see you there!

Seeking JavaScript Help

Even though it turned out that there is no simple solution for the math problem I posted, I learned a fair amount from the fantastic responses—thanks, everyone!—and eventually came up with a solution that worked for me.  (I’d like to say it was one of the iterative approaches posted, but none of them worked for me.  In the end, I brute-forced it.)  I’m hoping for a different outcome with my next question, which is about JavaScript.

Consider the following structure, which is a much-edited-down version of part of the HYDEsim code:

function Detonation(name,lat,lon,yield) {
    var scale = Math.pow(yield,1/3);
    var gz = new GLatLng(lat,lon);
    this.name = name;
    this.lon = lon;
    this.lat = lat;
    this.gz = gz;
    this.yield = yield;
    this.overpressure = {
        p30 : 0.108 * scale,
        p15 : 0.153 * scale,
        p10 : 0.185 * scale,
         p5 : 0.281 * scale,
         p1 : 0.725 * scale
    };
    this.psi30 = {
        radius: 0.108 * scale,
        overlay : {
            points: makePoints(this.gz,0.108 * scale)
        }
    };
    this.psi15 = {
        radius: 0.153 * scale,
        overlay : {
            points: makePoints(this.gz, 0.153 * scale)
        }
    };
    this.therm20 = {
        radius: thermDist(20,this.yield,0.33,conditions.visibility),
        overlay : {
            points: makePoints(
                this.gz,
                thermDist(20,this.yield,0.33,conditions.visibility)
            )
    };
    // ...and so on...
}

There are two things I’ve tried and failed to do.  And tried, and tried, and tried; and failed, and failed, and failed.

  1. Eliminate the redundant calculations of radii.  Note how I define a radius property in each case?  And then have to not use it when I create the overlay?  It seems like there must be a way to just define the value once for each subsection and then use it as many times as needed within that context.  How?
  2. How do I make it so that all those properties and overlays and such automatically recalculate any time one of the “upper-level” terms changes?  As in, once I’ve created a new Detonation object det, how can I set things up so declaring det.yield = 250; will trigger recalculation of all the other pieces of the object?  At present, I’m just blowing away the existing det and creating a whole new one, which just seems clumsy and silly.  I have to believe there’s a better way.  I just can’t find it.

Please note: tossing off comments like “oh, just instantiate a mixin constructor with an extra closure” will be of no help at all, because I don’t understand what those terms mean.  Hell, I’m not even sure I used the words “object” and “property” correctly in my explanation above.  Similarly, pointing me to tutorials that use those terms liberally is unlikely to be of help, since the text will just confuse me.  Sample code (whether posted or in a tutorial) will help a great deal, because it will give me something to poke and prod and dissect.  That’s how I’ve always learned to program.  Actually, it’s how I’ve always learned anything.

As well, I’m absolutely willing to believe that there are much, much better ways to structure the object, but right now I really need to learn how those two things are accomplished in the context of what I already have.  Once I get familiar with those and finish up some other work, I can start thinking about more fundamental overhauls of the code (which needs it, but not now).

I really appreciate any concrete help you can give me.

Addendum: if you leave code in a comment, please just wrap it in a code element and use whatever indentation you like.  The indentation won’t show up when the post goes up, but I’ll go in after and wrap the code in a pre and then everything will be fine.  Sorry to those who’ve already gone to the effort of posting with indents or nbsp entities to try to preserve indentation!  As soon as I can dig up the right preference panel or plugin to allow pre in comments, I’ll do that, but for now I’ll manually edit in the needed pres as comments are added.  THanks, and again, apologies to those who posted before I made this clear!

Seeking Math Help

So I have this equation that’s great for finding one term.  Problem is, I need to solve for another term that’s scattered all across the right side.  I’m hoping someone here has the mad algebra skills I managed to lose in the two decades since I last took a math class and can help me out.

Here’s the original equation:

Q = (3.07 × F × Y × (1 + 1.4 × ((D/V) × e(-2 × D/V)))) / D2

I want to be able to solve for D, not Q; in other words, have a single D on the left and everything else on the right of the equation.  F, Y, and V are all variable terms; the e is the classic irrational constant.  I tried for quite a while to do this and ran very firmly aground.  The best I managed was this minor simplification:

Q = (3.07 × F × Y × (1 + 1.4 × (D / (V × e(2 × D/V)))) / D2

…and even that assumes that I did things correctly.  Here’s the original equation in pretty shoulda-done-it-in-MathML-but-oh-well form:

I can shuffle the chairs around, as it were, but never really get anywhere close to having a single D on the left.  “But it’s so easy!“, you may well be shouting.  That’s why you’re working for Google and I’m not.

I remember having questions just like this on tests back in college: “Given this equation, solve for blah”.  It’s been too long, though, and in all honesty I was never that great at this sort of thing in the first place. Help, please?

[Update 14 Jan 09]: several commenters have shown that what I’m trying to do is impossible.  Frustrating, but that’s math for you.  Looks like I’ll have to take another approach.

An Event Apart and HTML 5

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.

January 2009
SMTWTFS
December February
 123
45678910
11121314151617
18192021222324
25262728293031

Archives

Feeds

Extras