Fire at Grand Central

Below is a letter to the editor that I emailed to the New York Times regarding an incident I’ll never forget. It was never published. Thus, I’ve decided to share it on my new blog. For some background, I was taking an excursion to the (now defunct) Astor Pl. K-Mart because they had large vats of Folgers Coffee that nobody else had at the time. It was on a hot Sunday afternoon, around 3PM.

Sitting at the front of the last car, reading an interview with Allan Holdsworth in Guitar Player magazine (unequivocally the greatest guitar player of all time, past, present or future bar none), I was shivering from the air conditioner blasting right on me. Without any further ado, here’s the rest of the story…


13 September 1999

Dear Editor,

While reading your article about the fire at Grand Central Terminal I noted a discrepancy in the facts. The article stated erroneously that the fire occurred at the south end of the northbound platform. This is incorrect as the fire took place at the north end of the southbound platform. I know this because I was a passenger in the last car of a southbound #6 train, pulling into the station at the peak of the fire.

As we pulled into the station, I felt an intense blast of heat from the air conditioner ducts followed by flames sweeping over the train. In a moment, the car was engulfed by the flames as we passed by the fully involved storage room. Stopping only a few feet away from the fire, the doors opened, there was a slight panic as we exited the train and made our way towards the stairs.

There was no light, save for that shed by the flames. The smoke was dense, with a sickening odor of burning wood, mixed with a faint trace of the even more sickening, acrid odor of burning plastic, and breathing became increasingly labored as we searched for the turnstiles.

Looking back on it, I find myself wondering why we ever left the 51st Street station. Why was the existence of this fire not communicated to the engineer before we pulled into Grand Central? By the time we arrived, the station was already completely evacuated, except for those of us on the train. Since the platform was deserted by the time we pulled in, it was obvious that it was known there was a fire, long before my train arrived, probably long before we even left 51st Street.

Once we pulled in, the doors opened and we were left to our own devices. It is fortunate that this incident occurred on a quiet Sunday afternoon, rather than a packed rush hour, whereby the ensuing panic most surely would have led to serious injuries and fatalities. The fact that there were no serious injuries, or worse, was a matter of pure luck.

Clearly, the MTA is totally unprepared for any such potential disaster. The actions as well as inactions on that day were completely irresponsible, and demonstrated clearly that should such an event, or even worse situation, occur at the height of rush hour, we cannot trust the MTA to have any plans to expedite the safe evacuation of passengers trapped on the trains or stations.
I for one am appalled.

David Kahn

What I’ve learned

Intro

Having nearly completed this project, I’ve learned some rather hard lessons about web development in general, and “responsive” development in particular. Recently, I received a new Motorola G Pure cell phone. It’s official screen specs are 408px x 773px (W x H). So, as per my usual practice, I added the device to the list in Firefox responsive design mode, and tested every page. It all looked good. Then I uploaded everything to my main site, and checked it on the actual phone. This is when it all fell apart.

Viewports and Responsive design mode discrepancy with actual devices

Mind you, it wasn’t a total disaster. Indeed, most of it looked fine. But there’s one page where I need to dynamically align some elements, both vertically and horizontally. A little research on MDN, beginning with the “Viewport concepts” page, which briefly discusses various relevant DOM interface values such as window.innerWidth and Element.clientWidth, along with briefly touching on the fact of two different kinds of viewports: the Visual Viewport, and the Layout Viewport

For the sake of brevity, if it’s not already too late to achieve, suffice it to say that MDN had nothing that helped my cause. It did however thoughtfully include a link to a discussion of viewports on one of my longtime favorite resources: Quirksmode. Here, Peter-Paul Koch discusses in depth the problem with how viewports are implemented in both devices and browsers, and most importantly, the fact that both devices and browsers intentionally deliver inaccurate dimensions and resolutions to both the DOM and to CSS media queries, in the name of user security.

Now, don’t get me wrong here, I’m totally in favor of protecting user security. Indeed, when it comes to web security, nobody is more paranoid than I am. Unfortunately, this breaks all but the most basic, simplistic designs. Even using grid layout with relative units like fr, vw and vh, not to mention plain vanilla “%”, and for that matter min/max-content, doesn’t work quite the way it should.

Using multi-line mode in the Firefox dev tools console, I checked the computed heights of the grid rows on both the desktop responsive design mode and the phone (which I connected with USB debugging). The first row was identical, but the remaining two rows were off to the tune of 15.6 pixels.

User selected font sizes

Interestingly, in the course of writing this post, it dawned on me that the second grid row contains a date and timestamp widget using a relative font size, 1.2em to be specific, and I have the fonts on my phone scaled to “extra large”, which turns out to be 16.9px when the <body> font size is set to 13px – a 130% increase. Queue up Homer Simpson blurting out “ Doooooohhhhhh!!!

Accessibility

At this stage, naturally, I’m thinking “how can I force the phone to use my specified font size?” Well, with more scouring the web for a good answer, I came to the realization that I shouldn’t. To do so would render the site non-accessible. I then realized that the real problem was using em‘s and rem‘s as a size unit for non-text elements. The solution was to use viewport percentages, in the form of the vw (viewport width) and vh (viewport height) css units. As long as the design is oriented to scroll vertically, as any mobile first design should be, this works beautifully.

The device toolbar problem and the new dynamic viewport units

Just when I thought I had solved the remaining issues, I discovered one last remaining, daunting issue. Devices display toolbars independent of the browser window, and don’t bother figuring the heights into the viewport heights reported to the DOM and CSS media queries. Again scouring the web for a solution, I came across a few newly available viewport units. There are three of them: small, large and dynamic. They’re essentially the same as the existing viewport based units, but with an s, l or d prefix: svw, svh, lvw, lvh, dvw and dvh. A more detailed explanation can be found on MDN here . As an aside, technology is advancing so rapidly, it feels impossible to keep up with. Even as I write this I’m learning new things. Apparently, in 2023, an @container query was introduced into CSS. Similar to an @media query, but targeting the identified container element. More information can be found on MDN here and here .

If you’re still reading this, you might be wondering by now why I’m blathering ad infinitum, ad nauseam about this little adventure that left me pulling out what’s left of my hair. I’m posting this to share the wisdom that I acquired the hard way so you don’t have to. Enjoy.

First post

Never has it occurred to me that I would ever write a blog post. Nevertheless, here I am, writing a blog post. Beginning with the assumption that nobody would likely ever see it, I initially considered the quality of its content irrelevant. Upon further consideration, I realized that someone might see this, thus it should at least be reasonably coherent.

With that being said, my next dilemma was the subject: just what should I write about? Suddenly, it dawned on me that writing about writing a first blog post, or any blog post for that matter, just might be the ticket. After all, who writes about such frivolities? Blog posts are frivolous, are they not? Yet, that is precisely what makes it a potentially intriguing topic. Thus, after much internal debate, I decided that it should at least pass muster with ENG101 scrutiny, sans citations if possible.

Following my usual practice of unloading a raw brain dump, to be later edited judiciously, my thoughts turned to how I might approach the questions surrounding creation of a blog post. There are of course the usual questions of what to write about, and how to organize and present it. However a couple of other, gnawing questions burned inside: why bother? And just what do I want to say? Answering the former question is easy, as the goal was originally learning how to code themes and plugins for WordPress, in hopes of securing gainful employment. Answering the former question was easy, the latter not so much.

To be sure, contemplating a first blog post can lead to brief fantasies of becoming a famous “influencer”, and receiving millions from advertisers seeking access to my enormous audience. Then reality hits home as I look up and around my rinky dink little hovel of an apartment and half dead laptop and lukewarm mug of coffee waiting for me to polish it off, or replace it with a fresh mugful. While I have much to say about numerous topics, with little thought needed, I have little to say about writing a blog post. It’s just not something I’m all that passionate about. Thus I have to actually think about it. Yet here I am, at the end of my fourth paragraph, wondering if I’ve said anything relevant, or even reasonably coherent.

It gives me a deeper appreciation and respect for professional writers, who are required to do this every day. Writers block, infamous and insidious lurks wherever and whenever one is facing a blank page or screen, be it paper, word processor, text editor, or for that matter, the WordPress blog post editor. Now I remember why I’ve embraced the raw brain dump approach. Without it, I’d never be able to write even one sentence.