Cascading Style Sheets (CSS) are critical to web layout these days. If you do any web work at all, you owe it to yourself to have at least a passing knowledge of CSS, while most of us need a solid grasp of the subject.
Just because CSS is nearly ubiquitous, however, doesn’t mean that it’s easy. In fact, CSS can be just about enough to drive you batty when it’s not working the way you expect. In those moments, in can be helpful to go back to basics and make sure you’re not missing something important.
Whether you’re learning or refreshing, Smashing Magazine has an article that just might help you out: Mastering CSS Coding: Getting Started. This certainly isn’t a comprehensive reference, but it’s a great high-level overview.
In a recent post, I wanted to break out a paragraph into a callout or sidebar — a little box of goodness inset into the body of my post. This proved rather more difficult than I’d planned.
Initially, I crafted the callout by hand, using a DIV for the box, and two DIVs within that for the title and body. I putzed with the CSS for a while to get it looking the way I wanted, and when I finally got it looking the way I wanted, I pulled the styles out and coded them in my blog’s stylesheet.
So far, so good. This was shaping up to be a minor pain, but nothing I couldn’t handle. The first big hiccup happened when I realized that the styles for my DIVs weren’t showing up in Google Reader for my RSS feed (you may have noticed this).
Diagnosing this problem turned out to be a much bigger rathole than I expected. Initially, I thought that perhaps my feed just wasn’t referencing my stylesheet, so I started playing with this. Before long, I ended up writing a simple WordPress plugin to add a stylesheet reference to my feed. No matter which event I hooked, though, I couldn’t get the feed to do what I wanted it to do. After way too many attempts to fix this, I finally stumbled on some blogs that pointed out the root problem here: feed readers generally don’t use stylesheets.
[callout title=Feed readers – FAIL]Needless to say, when I found out that feed readers don’t actually use stylesheets, I was floored. Not only that, but this appears to be a problem almost across the board. There’s a clear opportunity here for someone to step up and lead the way on this issue – someone, please carry this ball forward![/callout]
So, the real solution, it appears, is to have the styles embedded in the DIV definitions. This is ugly for all sorts of reasons that are probably obvious to you, but it’s the only way I can see to solve this problem if I want styles in my feed (which I do).
Given that constraint, I elected to make another plugin — this time, to let me use quicktag-style encoding to type my callout into my post and translate this into appropriately-styled DIVs for display. As evidenced by the callout in this post, this is progressing nicely. I’ve checked this plugin into the WordPress plugin repository, though I’m sure there’s still some fine-tuning to come.
When have you extended a system that didn’t quite do what you wanted it to?
Right. I can’t wait to write CSS for this. Are you kidding me??
If you look at the picture of this browser, you can see that the frame of the browser window stays locked in place on the screen, and sure enough – as the screen is tilted, the rendering within the browser is tilted to compensate.
Can this really be considered a feature people want or need on their devices? Here’s the bottom line, Firefox: You’re running on a rectangular device, no matter how it’s tilted. There are only two reasonable layouts on a rectangular device: portrait and landscape. For everything in the middle, I’m going to go out on a limb here and stipulate that if someone is holding a device at an angle, it’s probably because the viewer is at an angle, and thus, wants to turn the device to match their aspect.
Let’s also not forget that a screen rendered at non-square angles is going to introduce all sorts of fun graphical artifacts as you re-render at a constantly-changing angle. Remember that our fonts and graphics are optimized for a rectangular pixel layout, and anything other than square is going to require interpolated rendering of everything on the screen (which, being a mobile device, by the way, is probably of lower resolution than our desktops. Take a look at this image:
Ignore, if you’re able, the weird optical illusion that makes the rest of your screen now look like it’s tilted to the right. This image, in fact, shows the mobile version of Engadget’s home page tilted about fifteen degrees to the left. Note that while this is certainly still readable, the fonts show significant pixelation — they’re blurry and jagged.
You can also see that the screen is cut off on four corners. This is because the size of the canvas that will fit perfectly inscribed within the fixed physical screen changes as the angle of tilt changes. I’m sure there’s a geometric formula that can be used to figure this out, and it would be more or less complicated depending on whether you hold the aspect ratio of the canvas constant (which could work right up to the point where you switch from portrait to landscape). In any event, the size is going to change, and that means that you either change the size of the HTML canvas, reflowing text, images, etc., or you do still more interpolation and rendering to account for the smaller canvas size you’re painting. Either way, I think the user loses.
Can you just picture the bugs that are going to come in once people start using this?
Your app blinks when I tilt the screen.
When I tilt my screen, I can see everything just fine, but when I tilt it back, the left side of the text is cut off.
When I tilt on FireFox, your app works fine, but when I tilt on Chrome, it doesn’t work at all.
I got a migraine because of your app.
What’s with the screen swimming around??
Can anyone, anywhere really come up with a scenario where I, as a user of a mobile device, am going to hold my device at an angle and hope that my software can figure out how to render a pixelated, ugly version of the app I’m using at an angle that now, no longer matches the angle of my screen, and (dare I add) keyboard?
On behalf of all web developers everywhere on Earth, Firefox, I implore you:
I did it again – just like so many others before me.
Last night, Rob Conerydropped a rant about an industry heavyweight who, Rob felt, was doing us all a giant disservice by suggesting that perhaps less could be more, process-wise. So, of course, I chimed in, and I used the tired, old construction analogy — you know — building software is like constructing a house, right?
In my defense, the specific point I was trying to make was that the software industry isn’t mature in the same way as construction. Where you have building codes in Civil Engineering, for instance, there’s no equivalent binding set of rules governing how software is built — just a nebulous collection of “best practices”.
Clearly, there are holes in that analogy, and I pointed out a couple in a comment on that site. The complexity (in terms of options) in construction pales next to software development in all but trivial applications. As I mentioned, in my comment, a buyer could sit with an architect and describe parts of a home in pretty general terms, and be quite satisfied with the resulting home, because there already exists a rich vocabulary of assumptions about how homes are supposed to work.
Software interface design is automatically more complicated than physical buildings in part because we’re emulating “real” things in software. All the metaphors and affordances we design into our software provide unlimited complexity, such that any conversation about what a customer wants to see in software has to occur at a high level of detail.
Beyond specifying behavior, the process of construction proceeds quite differently in software, as well. When building a home, you quickly come to understand that some aspects of construction are literally “set in stone” very early in the project, and more importantly, these things are intuitively understood by the customer. If a homeowner wishes to change a foundation or the frame of a home, he’s not surprised to learn that this will be an expensive change; anyone can see how one is built upon another.
Building codes also help constrain choices (and therefore, costs) when building a home. There’s simply no arguing about how studs are spaced, or the materials that are used for different parts of the home, because these are mandated by building codes. In software, everything is negotiable, which implies that it must be specified. Once again, the analogy breaks down.
As many times as I’ve seen the construction analogy, it’s clear that a lot of people want it to work. Just remember that it only works to a point.
I believe Microsoft may be able to get away with pricing at a slight premium to Amazon and GAE, in large part because SQL Azure is an absolute killer feature because of its compatibility with existing SQL Server code. Nevertheless, Azure pricing has to be aggressive, or the value proposition for Azure starts to look weak. I think it’s especially important to make the platform available to developers at a free or near-free price point, or Microsoft just won’t be able to build the mind-share and experienced developer base it needs to grow, so I’ll continue to keep an eye on this space.
Rocky Lhotka recently announced another CSLA upgrade. One of the features in this release is support for data annotations that work in both WinForms and SilverLight. Yesterday, Rocky blogged about this implementation (Leveraging data annotation attributes in CSLA .NET).
While this feature is pretty cool all by itself, it’s easy to miss the real win here. Looking back at the features that Rocky’s added to CSLA over the last few years, there’s a constant stream of technology-enabling features. If you’ve built to this framework (and stayed reasonably current with new releases), you’ve gotten a free pass to take advantage of everything from remoting to WCF to data binding to SilverLight.
Here’s a news flash for you — that’s exactly why you get on board with a framework. You don’t get this with design patterns, and you don’t get this with software factories. Frankly, you don’t get this with a lot of other frameworks, either.
I recently read about the SELFMAN project on ReadWriteWeb (Coming Soon: Internet Apps that Heal Themselves). This project, started in 2006, aims to standardize and package the infrastructure needed to manage large-scale distributed applications. So far, they’ve produced some sample / reference applications using components written in Java. I don’t know if the bits themselves will find their way to your project any time soon, but if you’re working on large-scale applications, you should definitely take a look at their approach.
As far as I can tell, much of the actual software that’s been produced thus far deals with managing an application where you control all the pieces. The techniques used by this software are interesting in and of themselves, but I’m really more interested to see if any of these techniques can be broadened in application to help federalized systems cope with unreliable components.
Right now, we’re in the early days of applied cloud computing, and we’re seeing a fairly regular parade of large-scale, highly-publicized cloud failures from big-name players like Google, Amazon, Facebook, and Twitter. As we deploy more applications into the cloud and construct these applications to more seamlessly integrate with all the other applications in the cloud, we start to introduce some really insidious dependencies. How can we ensure that our application doesn’t crash every time twitter burps?
At present, this sort of resilience must be custom-crafted in each and every application, which is time-consuming and error-prone. I’d love to see more thought put into standardized approaches like those used by SELFMAN so that enterprise resiliency can become the norm rather than the exception.