meyerweb.com

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

Archive: 'Commentary' Category

A Matter of Conscience

So Louisiana Justice of the Peace Keith Bardwell has gained national notoriety for refusing to issue a marriage license to an interracial couple, referring them instead to another justice to have the marriage performed.  His action has, of course, provoked a great deal of condemnation.  Pretty much every elected Louisiana official above Mr. Bardwell (and plenty of them to either side) in the administrative hierarchy has called for his removal from his position.  That goes all the way up to Republican Governor Bobby Jindal, who said:

“This is a clear violation of constitutional rights and federal and state law. Mr. Bardwell’s actions should be fully reviewed by the Judiciary Commission and disciplinary action should be taken immediately – including the revoking of his license.”

As for Mr. Bardwell himself, he has claimed not to be racist, but instead concerned for the biracial children that result from mixed-race marriage.  Of all that he’s said, though, I was particularly interested by the following:

“I didn’t tell this couple they couldn’t get married. I just told them I wouldn’t do it.”

It interested me because it’s exactly the kind of reasoning that underlies “conscience protection” laws that exempt medical professionals who wish to refuse participation in abortion, or dispensation of contraception.

So now I’m very curious to know whether what pro-life groups have to say about what this man has done and how he’s done it.  Or, for that matter, what Governor Jindal himself now thinks of the bill he recently signed into law.

Nine Into Five

Like so many others, I had tried to dig into the meat of HTML5 and figure out just what the heck was going on.  Like so many others, I had come away with my head reeling from the massive length and depth of the often-changing specification, unsure of the real meaning of much of what I had read.  And like so many others, I had gone to read the commentary surrounding HTML5 and come away deeply dispirited by the confusion, cross-claims, and rancor I found.

Then I received an invitation to join a small, in-person gathering of like-minded people, many of them just as confused and dispirited as I, to turn our collective focus to the situation and see what we found.  I already had plans for the meeting’s scheduled dates.  I altered the plans.

Over two long days, we poked and prodded and pounded on the HTML5 specification—doing our best to figure out what was meant by, and what would result from, this phrase or that example; trying to reconcile seemingly arbitrary design choices with what we knew of the web and its history and the stated goals of the HTML5 specification; puzzling over the implications of example code and detailed algorithms and non-normative notes.

In the end, we came away with a better understanding of what’s going on, and out of that arose some concerns and suggestions.  But in the main, we felt much better about what’s going on in HTML5, and have now said so publicly.

Personally, there are two markup changes I’d like most to see:

  1. The content model of footer should match that of header. As others have said, the English-language name of the footer element creates expectations about what it is and how it should work.  As the spec now stands, most of those expectations will be wrong.  To wit: if your page’s footer includes navigation links, and especially if you have an HTML5-structured “fat footer“, you can’t use footer to contain it.

    If this feels a little familiar, it should: the same problem happened with address, which was specified to mean only the contact information for the author of a page.  It was quite explicitly specified to not accept mailing addresses.  Of course, tons of people did just that, because they had an address and there was an address element, so of course they went together!

    A lot of us cringed every time this came up in the last ten years of conducting training, because it meant we’d have to spend a few minutes explaining that the meaning of the element’s name clashed with its technical design.  We saw a lot of furrowed brows, rolled eyes, and derisively shaken heads.  That will be magnified a millionfold with footer if things are allowed to stand as they are.

    As I said, the fix is simple: just change the content model of footer to state:

    Flow content, but with no header or footer element descendants.

    That’s exactly the same content model as header, and for the same reasons.

  2. time needs to be less restrictive.  That’s not very precise, I know.  But as things stand now, you can only apply time to Gregorian datetimes, and you’re not supposed to use it for anything that couldn’t be easily represented in a calendaring program.  The HTML5 specification says:

    The time element is not intended for encoding times for which a precise date or time cannot be established.

    That makes me wonder, in a manner not at all like Robert Plant, how precise do we have to be?  The answer, I’m sorry to say, is too much.

    To pick an example: I have what I think of as a great use case for the time element, and while it uses the Gregorian calendar, it’s only accurate to whole months (as is Wikipedia’s version).  In some cases I could get the values down to specific days; but in others, maybe not.  So I can’t use the datetime attribute, which requires at least year-month-day, if not actual hours and minutes.  I could omit the attribute, and just have this:

    <time>October 2007</time>
    

    In that case, the content has to be a valid date string in content—which is to say, a valid date string with optional whitespace.  So that won’t work.

    I’ve pondered how best to tackle this, as did the Super Friends.  Our suggestion is to allow bare year and month-day values as permitted in ISO8601.  In addition, I think we should allow a valid date string to only require a year, with month, day, and time optional.  That seems good enough as long as we’re going to go with the idea that the Gregorian calendar contains all the time we ever want to structure.

    But what about other, older dates, some of which are fairly precisely known within their own calendars?  On that point, though the historian in me clamors for a fix, I’m uncertain as to what.  PPK, on the other hand, has put alot of thought into this and written a piece that I have skimmed but never, perhaps ironically, found the time to read in its entirety.

These are not my only concerns, but they’re the big ones.  For the rest, I concur with the hiccups guide, though of course to varying degrees.  I’m still trying to decide how much I care (or don’t) about the subtle differences between article and section, for example, or the way aside fits (or doesn’t) with its cousin elements.  And dialog just bugs me, but I’m not sure I have a better proposal, so I’ll leave it be for the time being.

At the other end of the two days, I felt a good deal more calm and hopeful than I did going in.  As Jeffrey said, “the more I study the direction HTML5 is taking, the better I like it”.  While there are still rough edges to be smoothed, there is time to smooth them.  We’ve already seen responsiveness on some of the points we addressed in the hiccups guide, and discussions around others.  The specification itself is daunting, especially to those who might remember the compact simplicity of the HTML2 spec.  Fortunately, it has good internal cross-linking so that you can, with effort, track down exactly what’s meant by “valid date string with optional time” or “sectioning content” or “formatBlock candidate“.

With HTML5, the web is not ending, nor is it starting over.  It’s evolving, slowly and in full view of the public, with an opportunity for anyone to have their say (which is not, of course, the same as having one’s proposals accepted).  It’s the next step, and I feel quite a bit more confident that it’s a step onto solid ground.

CSS3 Feedback: Graphical Thoughts

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

My few thoughts on the “Graphical Effects” part of the feedback document.  A lot of what was mentioned by the community is already in the pipeline, so there’s not a lot to say about those except “hurry ‘em up, willya?”.

Gradients — like rounded corners, no surprise these came up.  (All we need is to define wet-floor-reflect and we’ll complete the Web 2.0 design tricks hat trick.)  I’d like to see them myself, and I don’t think defining them is quite as hard as the commentary implies:

Imagine, for example, applying a gradient to the text of a <span> broken across two lines. Do you apply the gradient to each part individually? Glue them together as if they were all on one line first? Draw a rectangle around both parts and apply the gradient to that? (CSS3 Backgrounds and Borders has a control for this.)

I’d say the answer is right there, in the form of background-break, but let’s assume for a moment that said property never existed and we still had to deal with this problem.  I can think of two solutions:

  1. Only allow gradients to be applied to non-inline boxes.  This would not be my preference, but it could be so defined.  There’s already precedence with CSS for that sort of limitation:  width, height, text-align, and other properties are restricted to non-inline boxes.
  2. Treat gradients the way backgrounds and borders are already treated on inline boxes.  I’d be much more in favor of this.  In other words, lay out the inline box as though it is all on one line and then break it in pieces as needed to fit into the actual text flow.  (This is the behavior of continuous, the default value of background-break.)

But since background-break exists, you just treat gradients as you would any other background in accordance with background-break‘s definitions.

The somewhat trickier problem is how to define the value syntax for background-gradient so that’s both powerful and extensible without being unusable.  I think that’s solvable, but not easily, and probably not in a way that will satisfy everyone.

(Though this would be a fabulous place for the cardinal-point values from pre-CSS1 days, which you can still find in the specification if you look hard enough, to make a roaring comeback, wouldn’t it?)

Unidirectional background repeats — I say yes.  Here, have some values: repeat-up, repeat-right, repeat-down, and repeat-left.  In each case, the image would be repeated in the indicated direction from the origin image (the one placed by background-position).  Ironically, really old versions of IE did half of this by not correctly supporting repeat-x and repeat-y, treating them instead as if they were repeat-right and repeat-down.

There are occasions where this would be very useful, especially if you can combine the values into something like repeat-down repeat-right, and most especially in conjunction with multiple backgrounds.  So you could put an image stripe across the top of the element background, another one down the left side, and then fill in the rest of the background with a repeat-down repeat-right image.  Not a particularly common case, but the only way to handle it at present is with multiple nested elements, each with its own background and possibly a lot of negative margin trickery, and nobody wants that.  (Which may also be why it isn’t a particularly common case.)

You could also put an image in the center of your page and then a single stripe that goes only downward from behind it.  Like a golf ball on a tee, say; or a tree trunk below the leafy crowm; or a stem from a flower.

Slanted corners — sure, why not?  The issues are all the same as with rounded corners; the only difference is that you have a flat corner instead of a rounded one.  It makes joins between different borders styles/colors more obvious, but that’s a good thing: any solution that works well for the slant corner should work as well for the rounded corner.  Besides, if we’re already going to the effort of rounding corners, this seems like a pretty easy add-on.

Multiple borders — I think this would be quite useful.  I occasionally fake this with a border and an outline (as in my diagnostic styles) but that only works for two; if you want three or more nested borders (or two or more in IE/Win) you have to start nesting elements.  Also, having multiple borders lets you define your own gradient borders like you were a pixel artist, and who doesn’t like pixel artists?

At the same time, though, I do feel that this should be fairly low on the implementation totem pole.  And, as pointed out in the document, if image borders get implemented then a lot of the need for multiple borders goes away.

Alpha channel image masks — the problem I have here is what happens if you, say, try to use an image to alpha-mask a non-replaced element?  How does it scale?  Or does it?  Will there be a mask-stretch property?  Who really wants to stretch an image over a great big div anyway?  (From a visual-results point of view, I mean.)

Allowing masks might help in figuring out how to do non-rectangular float areas, in that you could use the alpha image to define the area used for float exclusion.  Combine that with a stretch ability and SVG support, so you can draw scalable vector masks, and I think you’re really getting somewhere.  (As does Matt Wilcox; he and I have been chewing this over in the comments on the previous post in the series.)

CSS3 Feedback: Animated Shapes

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

The portion of the feedback devoted to shapes had two overarching themes, as I saw it.  That makes this entry a bit short, but when I tried to combine it with my feedback on “Graphical Effects“, it quickly got too long.  So, a little amuse cerveau, as it were.

Animations, transformations, and so on — the WebKit team have of course been having a field day in this area, and what they’ve done will likely make is way to other browsers.  Or not.  I don’t know.  I’m not entirely thrilled about the effort that’s gone into those properties when there are so many other, more basic things that need love and care, but there’s no denying the essential coolness of slowly rotating an entire page.  Which I totally need to do the next time I give a presentation.

I’m not going to get into the “these things are behavior and therefore JavaScript!” argument.  CSS already does behavior (think :hover) and it’s going to do more over time.  I don’t see how that historical pressure can be resisted for much longer, short of outright refusing to take on any more behaviors and thus making itself a prime candidate for replacement with something else.  We may as well do our best to make sure CSS does good behaviors well, in ways that makes the most sense to the most authors.

So that’s basically my feedback: since we’re going to do it, let’s do it right.  Apple’s made a start, and unless the syntax they’ve defined in their CSS Animations draft is completely unworkable in other browsers for technical reasons, then let’s just roll with it.  And please note I said the syntax, not the overall concept.  (Ditto for their CSS Transforms draft.)

Stuff that isn’t rectangular — including both polygonal element boxes and polygonal floats.  I’ve wanted these for at least a decade, so it’s little surprise that I’m in favor.  Ragged floats were invented as a hack to make the latter happen, of course, and the basic idea’s been improved upon more than once.

The tricky part, of course, is actually defining polygons.  Regular polygons, as in hexagons and octagons and dodecagons, are not terribly difficult; but creating an irregular polygon requires defining a set of point coordinates in relation to some origin and resolving what happens when the lines cross over each other and… well, yeah.

The build-on-what-exists approach would just adopt the syntax HTML area elements use in the coords elements.  There would be two interesting questions there, which are what happens with negative coordinate values, and what happens if you draw a polygon that cuts through some of the element’s content.  For example, you have a div containing an image, and you define the polygon to be smaller (in places) than the image.  Is the browser obligated to prevent content overlap in such cases?  I would tend to say no but I can see arguments for the opposite view, particularly when it comes to floats.

Then there’s the problem that you’d have to define a separate polygon for every element that needed a non-rectangular float, as Bert Bos notes in his thoughts on the topic from a couple of years ago.  His contour idea is certainly interesting, though I’d then start to wonder how you define a contour point on, say, an irregular faded gradient.

Anyway, I thought about adapting clip to the purpose of defining float polygons, but then I remembered the long, tortuous hell that is the history of clip (and offset-clip) and decided that a new property is the way to go.  Clean break, start fresh, et cetera.  I don’t know what it would be called.  content-shape, maybe, to go with element-shape.  Or not.

CSS3 Feedback: Layout

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

In this round, layout.  Not all of it, but the bits that struck me as either really useful or really, really way too long overdue.

Float containment yes, we need a property that does just that.  As long as we’re tied to floats for layout—and I plan to rant about that soon—there should be a clear, unambiguous, intentionally defined property that tells elements to wrap themselves around floated descendant elements.  overflow works in most cases but can fall down in unusual circumstances (I’ve seen scrollbars appear where none were actually needed) and anyway, it wasn’t intended to provide the wrapping effect in the first place.  That it does so is a happy side effect, but it’s still a side effect.  The rest of the float-wrapping techniques are even more convoluted.  “There are already ways to do that so we don’t need a property” is rather like saying “we can already do layout with tables so why do we need CSS layout?”.

Positioning by center yes, please.  The way to center an absolutely positioned element within its containing block is to set the top and left to 50% each and then define negative top and left margins that are half the positioned element’s height and width.  That’s just awful, and requires at least an explicit width, if not an explicit height.  When I did the structured timeline, here’s how I got the version numbers to center below the dots:

#timeline tbody td p {
	position: absolute;
	top: 50%;
	width: 2.1em;
	margin: -5px 0 0 -1em;
}

See that -1em left margin, and the 2.1em width?  Just to get the center of positioned elements’ boxes sit on top of a certain left offset (defined elsewhere in the CSS).  Ditto the negative top margin, to pull it upward just enough so that the elements’ boxes would have the point five pixels down from their tops line up with the vertical midpoint of their containing blocks.

I wanted to do something like this:

#timeline tbody td p {
	position: absolute;
	top: 50%;
	position-anchor: 50% 5px;
}

That would have said that the point in the center of the absolutely positioned element should be placed at the point in the containing block 21.7% down from the top and 44% of the way across from the left.  That would hang the positioned element’s center on that point, regardless of the size of the positioned element—note that I took out the width.  I could stop defining explicit sizes and just let the elements be the size they want to be to show their content.

The problem is that approach doesn’t fit at all well with the way positioning layout is defined.  Suppose I said this:

#timeline tbody td p {
	position: absolute;
	top: 50%; bottom: 0;
	left: 50%; right: 25%;
	position-anchor: 50% 5px;
}

Now what?  I’m not even sure myself.  Maybe define rename it to position-offset and define percentages to be relative to the height and width of the positioned element (not its containing block), so that it doesn’t interact directly with the offset properties like top and right?

All I want is a way to hang elements off of offset points, and not be restricted to the corners of the elements, and have the solution work even when the elements have automatic height and width, and not require extra markup to make it happen.  Oh, and a ponycar.

Box sizing what in the nine hells of Valeria is taking so long?  We needed that one ten years ago.  I no longer care if it’s done as its own property or as new keywords on height and width.  I just want it.  Someone will make it happen, with or without the WG or implementors—mark my words.

Same-height elements yes, a way to tie element heights (whether they’re siblings or not) together would be welcome, although I can see how specifying it in an implementable would be tricky; no, display: table-cell  is not the answer.  Soon I will rant about this.  Soon.

CSS3 Feedback: Selector Blocks

(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′

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.

Shock and Awe

I almost feel like the Presidential election didn’t happen.

You see, for the entire second half of Election Day, from almost noon until after midnight, Eastern time, I was aboard a Continental flight to Tokyo.  We had video-on-demand systems but not live satellite television, so as we arced over Canada, Alaska, and the northern reaches of the Pacific Ocean, we flew in ignorance.  As Jeremy Keith put it regarding his own flight to Japan, we were aboard Schrödinger‘s Airplane.

For me, the wave collapsed as we began the initial descent toward Narita.  One of the flight attendants, having announced that they were starting the initial-descent procedures and would like us to check around our seats for any personal items we might like to start stowing, added:  “And for those of you interested in the results of the election, we have a new President: Barack Obama.”

There was a burst of applause from the economy section of the plane.  In business class, there was silence.

Well, not quite.  I was myself sitting in business class, thanks to a great big pile of reward miles and some lucky timing in calling the airline.  As I heard her say Obama’s name, I let out an involuntary “Wow“.  Because until that moment, deep down I had believed, truly believed, that Mr. Obama would not win the Presidency.  That was not the outcome I desired, but it was the outcome I expected.

I am in many ways ashamed of my doubts and fears, because I had thought less of my fellow Americans than they deserved.

Since then, from here in Tokyo, I’ve felt weirdly disconnected from what’s happened.  In time zone terms, I’m fourteen hours in my home’s future, half a day ahead of everyone back home.  But because I received word after it was all over and soon after slept through America’s Wednesday daylight hours, I feel like I’m a day behind.  Time and distance combine to create a feeling of disconnectedness from the end result, as though I’m getting word of election results in Germany or India or Australia: interesting, but something seen at a remove.

It’s odd.  I’m used to being an observer, but this is something else entirely.  I think it’s pure astonishment.

April 2014
SMTWTFS
March  
 12345
6789101112
13141516171819
20212223242526
27282930  

Archives

Feeds

Extras