Tag: Web Development - Page 16 - UNDERDOG of PERFECTION

The :first-child conundrum

Update (April 24, 2024): Yeah, this is a really old post. :first-of-type has existed for years now. Maybe it even existed when I wrote this in 2012, but I wasn’t aware of it.

I like to think I’m a pretty adept CSS developer. I may not have written the book, but I have a solid understanding of CSS and can do some sophisticated things with it.

But one place I always get snagged with CSS is in using the :first-child pseudoclass. The idea behind :first-child is that you can apply different styles to the first child element inside a parent element than for the rest of the instances of that child element inside the same parent.

A way I end up wanting to use it a lot is to give the first child different margins than the rest. Maybe most of them need margin-top: 2em; for instance, but I want the first one to be flush to the top of the parent by using margin-top: 0; to override the default margin.

The full CSS might end up looking like this:

div>h2 { margin-top: 2em; }
div>h2:first-child { margin-top: 0; }

And then that would be put together with some HTML like this:

<div id=”content”>

<h2>First header</h2>
<p>This is the first paragraph!</p>

<h2>Second header</h2>
<p>And, surprise! This is the second paragraph!</p>

</div>

So far, so good. The problem is, what if you stick something else into the <div> before the first <h2> that isn’t another <h2>? Say, something like this:

<div id=”content”>

<div class=”floating_sidebar”>This should be floating to
the right of the content.</div>

<h2>First header</h2>
<p>This is the first paragraph!</p>

<h2>Second header</h2>
<p>And, surprise! This is the second paragraph!</p>

</div>

You may have guessed at this point that I’m not describing a hypothetical situation here. This is a stripped-down version of exactly what I’m building right now. The problem is, now the first <h2> is no longer the first child element of the parent <div> overall, so the :first-child CSS gets ignored.

True, it’s not the first child element, altogether, inside the parent. But it is the first <h2> child inside the parent. I can understand how, in other circumstances — say, if the inserted <div> wasn’t a float — you’d want the h2:first-child not to apply here. But in general it seems to me that if you’re specifying a tag with your :first-child, it should only matter that it’s the first tag of that type under the parent, even if there are other different tags before it.

I guess the real solution here would be to create another pseudo-class that does what I want. Now I just need to convince the standards folks and the browser makers to do that.

Note: The sample HTML was kind of a mess when I originally posted this. That’s what happens when you write a blog post in a hurry before rushing out the door for a meeting. It has now been corrected, and I made some other edits for clarity while I was at it.

How not to do the Internet: a case study in bad web UX

My Subaru dealership’s website(s)

My Subaru Outback is due for service. Time to schedule an appointment. This is the kind of thing I just love to do online. No human interaction necessary!

Unfortunately, my dealership (who shall remain nameless, although I am happy to tell you that their shoddy website experience, which I am about to detail for you, was delivered by auto dealership web development behemoth Dealer.com) has not made the online scheduling option easy. And by “not easy,” I mean “practically impossible.”

First of all, for no good reason, the scheduling interface is built 100% in Flash. I’m pretty sure this scheduling system predates the iPhone, and Flash was at the time a de facto standard, but I’ve been building web applications since 1999 and there was never a time when it made sense to build a system like this in Flash. I deliberately don’t have Flash installed, except the version built into Chrome, so I couldn’t even load it in my browser of choice (Safari). Strike one.

I don’t think so.

Switching over to Chrome, I was able to go through most of the appointment scheduling process, picking the service I needed done, etc., until I got to the point of actually scheduling it, where I was stuck in an endless loop of picking days that were marked “available” on a little calendar overlay, only to get an error message stating “Not available due to shop capacity.” Over and over.

All but giving up, I spotted a curious item at the bottom of the page:

Ooh, this looks promising! Except… wait. How can clicking a link on my computer download an app to my smartphone? Maybe I should visit this site on my iPhone and then tap the link. Except… wait again. This part of the interface is in Flash, so I wouldn’t even see the link on my iPhone. So, what happens if I click it, anyway?

Are you kidding me? We are now at a place where I am interacting with a Flash-based web app on my computer, having it send to my phone an SMS message containing a link to the dealership’s mobile website. I’d even prefer a QR code over this convoluted mess. Strike two.

This is not how you do the Internet.

So I just decided to go over to my iPhone and try loading their website directly. It “smartly” (using the term loosely) redirected automatically to a separate iPhone-optimized version of the site, which I can only assume must be the mobile site the SMS would have linked to. (That is a reasonable assumption, right? We shall see.)

Here’s what I found when I navigated through the iPhone-optimized site to the service department’s page:

That “Service” button calls the service department. The “Contact Us” button is a link to a general-purpose email form. There are no other options.

“The mobile site will let you create, modify, and cancel appointments.” That’s what the SMS form promised. I decided (solely for the purpose of this blog post at this point) to fill out that form, but have the link emailed to me rather than sent as an SMS message. Not surprisingly, the email ended up in my junk folder. Also not surprisingly, the link goes to a different site than the version my iPhone was automatically redirected to when I tried to load the dealership’s main website. (So this is three separate websites they have now.)

I loaded this other mobile site on my iPhone, and it works!

Except, no, wait… it doesn’t:

Except, no, wait again… despite that weird error message, it actually does work:

(How many “except waits” is that now?)

But since it apparently only lets you edit existing appointments, not make new ones, I guess it really doesn’t work, after all. Also, don’t ask me why the iPhone version of the site doesn’t even have a link over to this version, but I guess ultimately it doesn’t matter anyway. Strike three. And four, five and six. In fact, let’s just call the game. And I’ll call the dealership.

Conclusions

What have we learned here? Aside from the fact that I am willing to spend far more time writing a blog rant about this problem than I am just calling to schedule an appointment over the phone, I hope I have impressed the value of web standards. If this site’s interface had been built in simple HTML and JavaScript, instead of Flash, which I can tell you is 100% possible — there is absolutely nothing in the interface functionally, and not even really anything in terms of the design or interaction, that could not have been done with HTML, CSS and JavaScript, even several years ago — then it would have worked fine in Safari without Flash, and it would work on my iPhone.

There has always been a lot of temptation to use Flash to do things that couldn’t be done with web standards, especially when the standards weren’t up to Flash’s capabilities. But succumbing to that temptation led to two trends that were profoundly harmful to the open web, and the effects of which we are — and I am literally — still experiencing today.

Bad UX as standard practice

First, since the sky is the limit when designing Flash interfaces, it created a feedback loop where designers took excessive liberties in experimenting with how basic interface elements like scrollbars and buttons should look and function. Then, project stakeholders who didn’t have the requisite background to make informed UX design decisions made demands that further pushed how these elements look and function. And since Flash had so few constraints on interface design, designers could accommodate those expectations, and the situation spiraled out of control.

This problem is not exclusive to Flash, of course. These days CSS and JavaScript offer tremendous potential for messing with standard UX conventions, and I’ve gotten myself into trouble with this on occasion. Customized scrollbars, fixed-position content, etc. Always remember, just because you can do something doesn’t mean you should. Things in the future will change in ways you can’t anticipate. Those changes are likely to accommodate existing standards, but not your customizations, no matter how brilliant they may be.

Flash as an industry

Second, as Flash grew in popularity it created an entire industry of Flash developers. Suddenly you had people whose livelihood depended upon building interfaces in Flash, regardless of whether or not Flash was really the right tool for the job. And as someone who has always favored open web standards, my perspective is that Flash is only the right tool for the job when it’s the only tool for the job. Even if standards couldn’t do something in quite as… ah-hem… “flashy” a way, if they could do it at all they should be chosen over Flash. I recognize this is a bit subjective, but one thing I can say about it with objectivity is that favoring web standards over Flash for a system like the one I’m describing here would almost certainly have obviated all of the problems I encountered this morning.

A metaphorical lesson to all technology workers: when your only tool is a hammer, every problem looks like a nail. Diversify your toolbox. It will serve your clients better by ensuring that you’re using the best tool for the job, not just the tool you know best. And it will serve your career better by not limiting your job options.

Future-proofing the web

There’s an even bigger reason now that having built this kind of system then using web standards instead of Flash would’ve been a good idea. If this site’s forms had been built with semantic HTML, it would be a comparatively trivial task to build new CSS with responsive web design techniques, allowing a single site to deliver the complete user experience on any device, rather than having to pay for and build three separate, wholly inconsistent, and all inadequate websites. By supporting and adhering to standards in the past, we could (and did) build websites that still work fine today. And by continuing to adhere to standards today, we can build websites that will still work fine tomorrow, even if we don’t really know what tomorrow’s devices will look like, or how we will interact with them.

Slow server? Don’t overthink it. (And don’t forget what’s running on it.)

I’ve just spent the better part of a week troubleshooting server performance problems for one of my clients. They’re running a number of sites on a dedicated server, with plenty of RAM and CPU power. But lately the sites have been really slow, and the server has frequently run out of memory and started the dreaded process of thrashing.

Fearing inefficient code in cms34 may be to blame, I spent a few days trying to optimize every last bit of code that I could, which did make a slight improvement, but didn’t solve the problem.

Then I spent a few more days poring over the Apache configuration, trying to optimize the prefork settings and turning off unnecessary modules. Still, to no avail, although getting those prefork settings optimized, and thus getting Apache under control, did allow me to notice that MySQL was consuming CPU like mad, which I had previously overlooked.

Hmmm… that got me thinking. I fired up phpMyAdmin and took a look at the running processes. Much to my surprise, almost every MySQL process was devoted to an abandoned phpBB forum. Within moments I realized the forum must be the source of the trouble, which was confirmed when I found that it had over 500,000 registered users and several million posts, almost all of which were spam.

As quickly as I discovered the problem, I was back in the Apache configuration, shutting down the forum. Then a quick restart of MySQL (and Apache, for good measure), and the sites were faster than I’ve seen them in months.

The moral of the story: if you have a web server that suddenly seems to be grinding to a halt, don’t spend days optimizing your code before first looking for an abandoned forum that’s been overrun by spammers.

File under “Don’t Make Me Do This Myself”: a comparison of “TTW” (Through The Web) WYSIWYG text editors

I really don’t want to have to spend time thinking about this, but there’s such a dearth of useful information out there on this topic — based on my searches of Google and Bing, which return little more than uncritical lists of 40+ different TTW text editors, usually displayed on such hideously designed or woefully outdated websites that I discount their validity on sight — that I feel compelled to step in.

The question today is TTW (through-the-web) WYSIWYG (what-you-see-is-what-you-get) text editors. If all of that sounds like 10 letters of gibberish to you, feel free to stop here. But if you’re a web developer, especially of the custom CMS variety, you’re certainly aware of the situation: how do you give users of your system a usable tool that allows them to easily edit site content without having to muck around directly with HTML? (That is, after all, kind of the whole point of a CMS.)

It’s something I’ve struggled with for over a decade. At one point I was actually rolling my own. But that’s a little more JavaScript than I care to deal with directly, and I long ago left the project of building a WYSIWYG editor to those who really love that kind of thing.

That puts me in a position where I need to select the best available option for a pre-built, drop-in WYSIWYG editor. Fortunately things have come a long way in this regard over the past decade. I’ve been — more or less happily — using TinyMCE to solve this particular problem for the past 3-plus years. But lately “less happily” has been outweighing “more,” and I’ve been exploring my options.

So far the only viable alternative I’ve found (or had recommended to me) is CKEditor. It’s the successor to one of the really early TTW WYSIWYG editors, FCKEditor, which I tried ages ago and never really liked.

Today I took a major step forward with cms34, my custom CMS, by setting up a configurable site option that allows users to select the editor of their choice: TinyMCE, CKEditor, or raw HTML. As inclined as I am to use raw HTML myself, I’m giving CKEditor a whirl for now.

So far I am inclined to say CKEditor is just the remedy I’ve been looking for to cure my TinyMCE malaise. As good as TinyMCE is, it just gets a little wonky sometimes. It especially seems to have trouble figuring out where to put closing tags when you’re switching between block elements, and especially when you’re inserting new content. I find myself often switching to the HTML pane to fix its quirks manually, but I can’t expect clients to do that.

My experience with CKEditor is still pretty limited at this point, but I have to say I really like how it’s set up for customizing the interface (which buttons to show, especially), in addition to its better handling of switching between elements than TinyMCE. They’re both pretty similar, actually, in how they’re configured, and in the overall user experience. But CKEditor has a little more polish, a little more flexibility. It almost feels like “TinyMCE done right,” although perhaps it’s too early for me to make such a proclamation.

So, that’s it for me, for now. The only two options in this realm that I really have any experience with. I know there are others out there. Some may even be good. Even better than TinyMCE or CKEditor. What’s your favorite?

CakePHP at the command line: it’s cron-tastic!

I’m kind of surprised it’s taken this long. cms34 has been around for almost three years now, and this is the first time I’ve had a client need a cron job that relied on CakePHP functionality. (The system has a couple of backup and general-purpose cleanup tools that can be configured as cron jobs, but they’re just simple shell scripts.)

And so it was today that I found myself retrofitting my CakePHP-based web application to support running scripts from the command line. I found a great post in the Bakery that got me about 85% of the way there, but there were some issues, mostly due to the fact that the post was written in late 2006, and a lot has happened in CakePHP land over the last 4 1/2 years.

There are two big differences in app/webroot/index.php in CakePHP 1.3 compared to the version that existed at the time of that original post: first, the calls to the Dispatcher object are now wrapped in a conditional, so the instruction to replace everything below the require line should now be something closer to “replace everything within the else statement at the bottom of the file.”

The other big change is that this file defines some constants for directories within the application, and those paths are all wrong if you move the file into the app directory as instructed.

Below is my revised version of the code. Note that I also reworked it slightly so the command can accept more than two arguments as well. There’s a space before Dispatcher is called where you can insert any necessary logic for handling those arguments. (I also removed all of the comments that appear in the original version of the file.)

<?php
if (!defined('DS')) {
    define('DS', DIRECTORY_SEPARATOR);
}
if (!defined('ROOT')) {
    define('ROOT', dirname(dirname(__FILE__)));
}
if (!defined('APP_DIR')) {
    define('APP_DIR', basename(dirname(__FILE__)));
}
if (!defined('CAKE_CORE_INCLUDE_PATH')) {
    define('CAKE_CORE_INCLUDE_PATH', ROOT);
}
if (!defined('WEBROOT_DIR')) {
    define('WEBROOT_DIR', APP_DIR . DS . 'webroot');
}
if (!defined('WWW_ROOT')) {
    define('WWW_ROOT', WEBROOT_DIR . DS);
}
if (!defined('CORE_PATH')) {
    if (function_exists('ini_set') && ini_set('include_path', CAKE_CORE_INCLUDE_PATH . PATH_SEPARATOR . ROOT . DS . APP_DIR . DS . PATH_SEPARATOR . ini_get('include_path'))) {
        define('APP_PATH', null);
        define('CORE_PATH', null);
    } else {
        define('APP_PATH', ROOT . DS . APP_DIR . DS);
        define('CORE_PATH', CAKE_CORE_INCLUDE_PATH . DS);
    }
}
if (!include(CORE_PATH . 'cake' . DS . 'bootstrap.php')) {
    trigger_error("CakePHP core could not be found. Check the value of CAKE_CORE_INCLUDE_PATH in APP/webroot/index.php. It should point to the directory containing your " . DS . "cake core directory and your " . DS . "vendors root directory.", E_USER_ERROR);
}
if (isset($_GET['url']) && $_GET['url'] === 'favicon.ico') {
    return;
} else {
    // Dispatch the controller action given to it
    // eg php cron_dispatcher.php /controller/action
    define('CRON_DISPATCHER',true);
    if($argc >= 2) {

        // INSERT ANY LOGIC FOR ADDITIONAL ARGUMENT VALUES HERE

        $Dispatcher= new Dispatcher();
        $Dispatcher->dispatch($argv[1]);
    }
}

After implementing this version of cron_dispatcher.php, I was able to get CakePHP scripts to run at the command line without being fundamentally broken, but there were still a few further adjustments I needed to make (mostly in app_controller.php). Those were specific to my application. You’ll probably find yourself in the same boat.

A couple of other things worth noting: if your server is anything like mine, you’ll need to specify the full path of the PHP command line executable when running your scripts. In my case it was /usr/local/bin/php. And, the one sheepish confession I have to make: I know the goal with the way the file path constants are defined is to avoid any literal naming, but I couldn’t find a good way to get around that for WEBROOT_DIR, with the file no longer residing in webroot itself. I’ll leave fixing that as an exercise for the reader.

Good luck!

Download the Script

Download zip file... cron_dispatcher.php
cron_dispatcher.php.zip • 1.2 KB