Tag Archives: CSS

EXT JS: HTML5 Framework for Desktop and Mobile Devices (that will ruin your life)

Posted on by
Reply

How did we get into this mess?
Before we discuss why this tool often makes life worse, let’s talk about a common reason for its adoption. The primary reason businesses adopt EXT JS is that executives love it. Executives want to deliver software faster and cheaper, and EXT JS does a very good job selling that it is capable of delivering software faster and cheaper.

You don’t know it, but a strategic thinker and decision maker in your organization is being wooed by a salesperson at Sencha as you read this. That thinker and decision maker also knows of several projects on the horizon that align almost perfectly with those amazing examples on the EXT demo page. In 6 months, you’ll be given the requirements for a feed reader that has been sold to one of your company’s clients. Within those requirements there will be a reference to EXT JS (and its feed reader demo), and, at the moment you see it, you’ll remember this article.

Unfortunately, at that point, it will be too late for you. But I hope a few strategic thinkers read this, get it, and choose to spare their organizations from the inevitable pain of developing with this framework.

(If you’re a strategic thinker, and you’re reading this, you’re almost certainly thinking, “We need a feed reader. They have a feed reader. Where is the mess?”)

Where exactly is the mess?
EXT JS has many widgets. They all look the same: crappy. (They look like AWT/Swing components. No one takes those seriously, do they?) If you’re a strategic decision maker, just ask your Sencha salesperson to skin your favorite demo with one of your favorite customers’ brand images. While Sencha makes it possible to compose UIs quickly from the various widgets, they won’t look anything like what they’ll need to look like to convince your best customer that your company isn’t a bunch of hacks. To use EXT JS to create UIs that your customers will take seriously takes time–a lot of time. (You can get to market quickly with their crappy-looking widgets, but you won’t get to market looking professional.)

Maintenance of this framework is a nightmare. Junior programmers inevitably leverage the massive number of attributes that EXT JS adds to the DOM in order to effect change using conventional JavaScript and CSS. They also commonly edit the idiomatic syntax of EXT JS code to make small tweaks, again, using conventional patterns. This will be a source of maintenance problems and bugs.

We could go on, but all of my complaints are variations on these two themes. EXT JS isn’t fast or cheap if you want to customize it or maintain it. In fact, it’s expensive (especially over the full life of the solution) and slow. If you really want to deploy the demo version of the EXT JS Feed Reader, and you never want to upgrade it or change it, then you’ve found your dream framework.

Summary
Don’t be the sucker. Don’t fall for those goofy demos. Don’t be the guy that brings this into your team with promises of improved timing and cost. You’ll just end up proving to your team that you’re too narrow to make such decisions. Or, worse, that you’re totally incompetent.

SEO and Site Speed

Posted on by
Reply

At the time of this writing, Notes is listed as one of the top 2 million sites globally according to www.alexa.com. You can view the site information here: http://www.alexa.com/siteinfo/ecomware.com.

Two months ago, Notes was in the top 7M. Three months before that, it was in the top 4M. That’s a lot of change in six months.

One of the factors that causes ecomware.com (a micro blog with barely 50,000 readers annually) to rank so high is that it’s linked to from Liferay.com, and regarded as a good source for simple Liferay theme information. Link neighborhoods are important, and having embedded a link to myself in Liferay.com certainly helps ecomware’s visibility.

One of the factors that causes ecomware.com to rank so poorly, especially when it dropped into the 7M range, is caching. During the summer, I was experimenting with document freshness, and set the cache expiration date on the home page (the blog index page) to 14 days into the future. This, I assume, caused the major sites to believe the content was stale.

To speed up ecomware.com, I followed many of the well known steps for reducing latency. I consolidated and condensed the .js and .css that were part of the theme, and in cases where the pre-published source files are small, I simply embed them in the markup as part of the publishing action. This means I have just one include of each type. I also eliminate the head requests for these resources by using an expires header. I layer the real-time assets using AJAX. Subsequent page loads will cache at approximately 85-95%, and without head requests. I also use a publishing mechanism in front of Word Press to serve static pages so that I’m not incurring a real-time processing cost on each request. (Big frameworks have this already, but it’s simple enough to implement on a small scale.) I also leverage XML and XSLT on the client side. In cases where the presentation is almost identical across many assets, I cache a single XSLT file and serve literal XML data to the client. (The transformation creates a normal HTML DOM on the client side.)

The end result is that I can serve this site from a shared host/DB with reasonable performance (especially on subsequent loads) and still reap the benefits of good search ranking.

CSS URLs: The effect of relative and absolute pathing

Posted on by

Most people who work with CSS understand the difference between relative and absolute paths, but there is one situation that doesn’t immediately come to mind that can be very useful.

Let’s say we have a document hosted at:

http://www.a.biz/index.html

Let’s say that document contains a link tag (or an import directive) to an external CSS file:

<link href="stylesheet.css" rel="stylesheet" type="text/css" />

Inside this style sheet, we have the CSS selector:

body {
    background: url("styles/bg.png") repeat-x scroll 0 0 #FFFFFF;
}

First, the browser computes the base URL (http://www.a.biz) of the document, and appends the path to the style sheet to it. The style sheet will be downloaded from:

http://www.a.biz/stylesheet.css

Second, the browser will attempt to download the image. Because the image is relative, a base URL must be calculated. In most cases, the base URL is the same as the document itself, and so it is in this case. The base URL (http://www.a.biz) is prepended to the relative path of the image, and the resource is downloaded. In this case, the image will come from:

http://www.a.biz/styles/bg.png

Many developers assume the base URL is calculated the same way for both resources (style sheet and image), but it isn’t. The base URL for the relative image path is found by using the absolute URL of the style sheet, just as the base URL for the relative style sheet path is found by using the absolute path of the document (index.html).

This means that if we change our link tag in http://www.a.biz/index.html to what follows, the relative path of the image will change.

<link href="http://www.b.biz" rel="stylesheet" type="text/css" />

The URL of the style sheet is no longer relative to the document. The base URL of the style sheet is now http://www.b.biz, which means the computed absolute value of the image resource is:

http://www.b.biz/styles/bg.png

This can be very useful in cases where similarly-branded web content is distributed across hosts. It can be used in development effectively, too. Using this technique, it’s possible to develop a single set of resources (style sheets, images, etc) and reuse them. This enables sharding of the UI resources, and is especially effective in cases where real-time content cannot be cached behind a CDN by removing the resource requests to another architecture.

Writing a decent print stylesheet.

Posted on by
Reply 
<link rel="stylesheet" href="print.css" type="text/css" media="print" />

print.css. It’s enough to strike fear in the hearts of many web developers.

It doesn’t have to be. By laying a strong foundation, we can create print stylesheets that will meet the needs of our clients without burning through expensive cycles. This post is specific to print.css, but it builds on the principles outlined here: A Foundation: Basic CSS.

The following are the basic tricks I use for quickly creating a basic print stylesheet:

Override float, margin, padding, unusual heights and widths, and overflow on a global scale, etc. Target the full array of properties. Sometimes the same container needs to be targeted with multiple selectors to achieve the proper rank in the importance hierarchy for this or that style.

* , div#wrapper * {
    margin: 0px !important;
    padding: 0px !important;
    height: auto !important;
    width: auto !important;
    float: none !important;
    position: static !important;
}

Essentially remove everything from the printed page, and then make containers available from the top to the bottom (or, said another way, from the root to the inner-most child) 

div { display: none; }

div#wrapper,
div#wrapper div#div1,
div#div1a,
div#div1b,
div#div1c,
div#div1a1a,
div#div1a1a * {
    display: block;
}

Compensate for the discrepancies between browsers by using a lot of CSS. Make it perfectly clear what you intend the browsers to do by bridging the gaps with “unnecessary” selectors and styles.

div#div1a1a  {
    display: block;
    visibility:visible !important;
    background-image: none !important;
    background-color: #FFFFFF !important;
    float: none !important;
    margin: 0px !important;
    padding: 0px !important;
    border: 1px solid black;
}

Finally, use borders. Take advantage of knowing exactly where your containers are. It’s the best way to identify the misbehaving ones.

Lay a solid foundation, and it will make creating your print stylesheet a breeze.