Blast From the Past

Sep/12/2014

LiveScript, Silicon Graphics, IRIX, Solaris, NCSA Mosaic, IE3… It was kinda fun listening to Brendan Eich talk about the evolution of JavaScript. Lots of names I hadn't heard in a long time. I found it quite interesting to hear all the political machinations that surrounded the creation and development of JavaScript. It's worth a listen: for historical edification if you're a young developer, or for a bit of nostalgia if you've been around for a while.

JSJ The Origin of JavaScript with Brendan Eich

CSS Pet Peeve #17 Redux

Sep/03/2014

Found this on another site.

.dropcap, blockquote, .team-member .member-mask .mask-text fieldset legend,
.button, button, .coupon .button, input[type=submit], .font2,
.shopping-cart-widget .totals, .main-nav .menu > li > a,
.menu-wrapper .menu .nav-sublist-dropdown .menu-parent-item > a,
.fixed-header .menu .nav-sublist-dropdown .menu-parent-item > a,
.fixed-header .menu > li > a, .side-block .close-block, .side-area .widget-title,
.et-mobile-menu li > a, .page-heading .row-fluid .span12 > .back-to,
.breadcrumbs .back-to, .recent-post-mini a,
.etheme_widget_recent_comments ul li .post-title, .product_list_widget a,
.widget_price_filter .widget-title, .widget_layered_nav .widget-title,
.widget_price_filter h4, .widget_layered_nav h4, .products-list .product .product-name,
.table.products-table th, .table.products-table .product-name a,
.table.products-table .product-name dl dt, .table.products-table .product-name dl dd,
.cart_totals .table .total th strong, .cart_totals .table .total td strong .amount,
.pricing-table table .plan-price,
.pricing-table table.table thead:first-child tr:first-child th,
.pricing-table.style3 table .plan-price sup, .pricing-table.style2 table .plan-price sup,
.pricing-table ul li.row-title, .pricing-table ul li.row-price,
.pricing-table.style2 ul li.row-price sup, .pricing-table.style3 ul li.row-price sup,
.tabs .tab-title, .left-bar .left-titles .tab-title-left,
.right-bar .left-titles .tab-title-left, .slider-container .show-all-posts,
.bc-type-variant2 .woocommerce-breadcrumb,
.bc-type-variant2 .breadcrumbs, .post-single .post-share .share-title,
.toggle-element .toggle-title, 
.product-thumbnails-slider .slides li.video-thumbnail span,
.coupon label, .product-image-wrapper .out-of-stock,
.shop_table .product-name a, .shop_table th, .cart_totals .order-total th,
.page-heading .row-fluid .span12 .back-to {
    font-family: Montserrat;
}

And it dawns on me: no human being did this. Right? This has to be CSS generated by some GUI. And here you have an execellent example of why I have never used GUIs to build web sites. I have never seen a tool that produces what I would even consider reasonable code. I remember looking at one mumble mumble years ago that used tables and single pixel gifs with various heights and widths applied to fix the layout. The markup was a sight to behold, let me tell you.

I get that it's a difficult problem to solve. No disrespect to those trying to crack this nut. Somehow I think a GUI that produces clean-ish code is going to take some serious AI to get it right.

CSS Pet Peeve #17

Aug/21/2014

It's amazing how often I see something like this:

.btn-submit, .btn-save-changes, .btn-send-email, a.btn-see-addresses,
a.btn-see-cards, a.btn-see-order-history, a.btn-see-wish-list, a.btn-share-wishlist,
a.btn-add-new-address, a.btn-add-new-card, a.btn-share-your-wishlist,
a.btn-continue-shop, .btn-update, .btn-add-wishlist, .btn-tell-friend,
.btn-continue-blue, .btn-no-thanks, .btn-add-wishlist-blue, 
a.joinnow, .btn-check-status{
    background: url("../images/buttons_24.png") no-repeat;
    border:0 none !important;
    cursor:pointer;
    display:block;
    height:25px;
    line-height:25px;
    text-indent: -9999px;
}

First: don't do that. Using a comma to apply the same rule to different styles is fine if you have two, maybe three, styles where it applies. Doing it with this many styles is just absurd. Oh, and I've probably removed a dozen rules from this list already.

Second: This used to be all on one line. Also bad. I know guys who write their rules on one line a la

a.btn-see-addresses{width:135px;background-position:-1697px 0;}

One fellow I know who is a proponent of this style says he likes to being able to see lots of class definitions as he scans down the page. Another says he's usually looking at rules in Chrome dev tools and not the CSS file itself. This way his CSS is already compact and he can skip some kind of build tool to compress his CSS. To each his own, I guess, but I'm not a fan. I think they're really hard to read. Of course, either argument falls apart when you have so many class names on the line you can't even see the rules. I had no idea there was an !important in these rules until just now when I broke it into multiple lines. Which brings me to...

Third: If you have to use !important you've done something wrong.

Here's one way to tackle this particular issue.

.btn-sprite {
    height: 30px;
    line-height: 30px;
    border: 0;
    overflow: hidden;
    text-indent: 500px;
    display:block;
}
.btn-yellow {
    background: url("/images/btn-sprite-yellow.png") 0 0 no-repeat;
}
.btn-red {
    background: url("/images/btn-sprite-red.png") 0 0 no-repeat;
}
.btn-checkout {
    background-position: 0 0;
    width: 140px;
}
.btn-checkout:hover {
    background-position: 0 -30px;
}

<button class="btn-sprite btn-yellow btn-checkout"></button>

I find this much easier to read and maintain. There's nothing wrong with having more than one class on an element. I try and draw the line at three, but that's just me.

Browser Quirks

Aug/12/2014

Here's a new oddity between Firefox and Chrome that I haven't come across before. I've removed the logo in question because I don't know how the company would feel about having their logo on my web site. You'll have to take my word for it that the black line indicates the baseline of the logo on the page.

Notice how the menu renders one pixel lower in Firefox. Now the typical developer loaths pixel pushing and is likely to respond "One pixel? Pffft." The problem is when you have a line on the page—a margin of some kind, a font base line— the human eye will pick up that kind of thing and it does become distracting. There are a few situations where pixel pushing is appropriate. Here's the relevant CSS.

.htlink {
    position: relative;
    top: 36px;
    line-height: 24px;
    height: 24px;
    letter-spacing: .14em;
    text-transform: uppercase;
}

If you look a the computed styles in each browser you can definately see some precision differences in the letter spacing numbers displayed by each browser. It's not unreasonable to assume there are similar precision differences when calculating the pixel location of the text baseline. So what to do? Browser detection and Firefox specific styles? If that doesn't make you cringe, it should. In this case, however, there was only one minor tweak that needed to be done.

line-height: 23px;

That had the desired effect of moving the font up one pixel in Firefox, but leaving the font in place in Chrome. I think I just got lucky this time, but if you face a similar situation, you might try tweaking your line-height or other font property that would exploit the precision differences between the two browsers.

How not to write your CSS

Aug/06/2014
position:relative;
top:-8px;
padding-top:10px;

I just found this on a web site I've been asked to update. True story.