Zorked!

There are a lot of problems with the transparent windowing mode (or wmode, as many are familiar with it) in the Flash browser plugin. It’s especially bad in Firefox’s implementation, as it will no longer dispatch Event.RENDER, which the CS3 component architecture is dependent on. Without a RENDER call, the components don’t show up, although they will take text input. The only way you can tell that they’re alive is that they FocusRectangle will come up if you click on it.

Now, if you legitimately need the transparency of the windowing mode because you’re popping a huge purple gorilla over the normal page, you’re pretty much stuck, unless you want to hack the UIComponent class to use an ENTER_FRAME event instead (which did not work for me). However, most people are actually looking to be able to z-index the Flash movie, in which case you can just use the “opaque” attribute value instead of “transparent”.

Remember, this is a single param of the object, like <param name="wmode" value="opaque" /> instead of <param name="wmode" value="transparent" />

If you’re interested in what’s happening behind the scenes, here’s the deal: normally whenever a browser lets a plugin lay itself on the screen, it’s actually doing a managed window outside of the actual page that you’re browsing; in short, it’s not part of the actual layout. So, instead of being on the screen, it’s in a layer above everything else except for other plugins. When you scroll the page, the browser scrolls the plugin too. Normally, you don’t notice this because it’s pretty much instantaneous. The only time you notice is when you have a dropdown menu that always falls behind the plugin, for example.

When you put the wmode (window mode for short, remember) parameter on the object/plugin, it’s now telling the browser to interlay the plugin with the rest of the elements that are in the page. In fact, it actually is one of the elements of the page, and is now z-indexable.

One minor problem with this approach is that performance is slightly slower, regardless of whether you chose transparent or opaque mode (although transparent is even slower). Most users will not notice, but be aware of it if you’re doing timer and sound synced animations.

Here’s a nice gotcha I found a while back when trying to run a filter on some XML data. If you write an attribute filter inside of a switch statement, the query will return null when you assign it to the XMLList variable. If you trace out the query instead of assigning it, it works fine.


switch (anything) {
case "testcase":
var xlData:XMLList = xmlData.Books.Book.(@author == 'Dickens');
break;
}

The above code will fail; apparently the scoping inside of switch statements is broken. There’s a bug report filed already, but it would be nice to see a fix for this.

I’ve switched over to Wordpress for easier maintenance of the site. Honestly, it’s just a lot easier than Expression Engine, even though I liked EE a lot. This gives me some nice features that I’ve been wanting to implement, such as better comments without spam, easier posting and management (and rich text editing too), so hopefully this turns out better and motivates me to post a little bit more.

Everything is already transferred over, so hopefully there weren’t too many jags on the feed readers, if any. I’d like to actually start posting more of the stuff I’ve learned so that other people don’t have to suffer as much as I did, so it’ll probably end up being a braindump for a little while.

The question I have today is: is it really so bad to break the rules to serve a greater good? Would Whitman’s flowing poetry feel as smooth if it were corrupted with the common ideas of rhyme and meter? Would a journalist’s point be as emphatic if she were restricted from using one-word exclamations?

I believe the same thing goes for web developers when they learn web standards. “XHTML will make my site more accessible, faster, cleaner, prettier, and cooler? Of course I’ll learn it!” So the naive web developer goes along his merry way, thinking that web standards are the best thing since Tim Berners-Lee, but he never learns or questions the reasons behind standards: the underlying fabric of HTML, CSS,XML and other less popular standards.

The standards framework

Many of us have learned an instrument in our lifetimes, so we’ve been forced to learn the framework of music: notes, key signatures, transitions, etc. Upon learning that framework, we can then transcend it, and play jazz, or techno, or other non-traditional genres, but we had to learn the framework first. In order to go beyond the rules, we first have to learn them by heart.

As such, it’s a good thing that we are ignorant in our first stages of web standards development. We need to learn to write good, solid HTML and CSS; we need to learn the differences among versions of the standards, and the DOCTYPES or namespaces that go along with them; we need to learn the ins and outs of cross-browser development.

Now, I like to think that I wasn’t totally naive when I first started learning well-written HTML and CSS. I’d heard the arguments, and I knew what was going on, at least in a theoretical, abstract sense. But I didn’t really know what I was getting into. I thought that by having a CSS-styled website, I would just be able to swap it out whenever I wanted, and we could change the look and feel in a matter of hours. While this is true in a sense, it’s also not the full truth. I still needed to know about good templating; about separating presentation and style; separating data from markup; and about separating styling into groups of layout, color, typography, and media.

Back to our roots

I think in the midst of learning all this new technology and fresh ways of doing things, we forget why we do them, and instead get caught up into dogmatic beliefs that XHTML is the only way to go, that tables should never be used, no matter what, and that divs can and should be used to do anything. But why do we even have standards? Why do we need them in the first place? Well, there are certainly auxiliary benefits to writing good HTML and CSS, such as saving bandwidth (and as such, improving the user experience for dial-up users), providing better accessibility, and enhanced precision and control of layout and theme. But really, there’s one reason why we develop with web standards.

Ease, speed, and maintainability of development.

That’s it. Although selfish at first glance, that’s really the reason that we have web standards in the first place. But before too many start screaming that “no, we’re doing it for the users”, let’s take a look at another powerful industry for a quick moment. Eli Whitney is often credited with division of labor and repeatable, reusable parts. It was Ransom Eli Olds and Henry Ford who turned the ideas into the modern assembly line. Instead of building cars piece by piece, with each automobile at least slightly different from the next, these two pioneers generated interchangeable, reusable parts. In effect, they created their own internal standards so that they could perform better.

What if nobody had ever tried out the idea of the assembly line and interchangeable parts with cars? Well, each car would still be custom-built, expensive, and very hard to maintain. Also, we wouldn’t have common safety features such as airbags, since they would essentially be untestable. Automobiles would be about as useful as tireless, slightly faster horses, rather than the speedy, relatively safe, maintainable vehicles that are manufactured today.

The same goes for web standards. Without them in place, we would still be in the first browser wars, where Microsoft and Netscape competed by adding their own proprietary features to HTML and Javascript (then commonly called DHTML, since the standard wasn’t effective). So, they are useful in the sense that they force browsers to compete on features, rather than rendering, and also that they provide a framework for web developers; an assembly line, if you will.

So, remembering that web standards are created for two reasons: user agent conformity and developer ease, why is it that there is so much conflict about dogmatic use of certain standards and de facto methods of development? I think it’s because of ignorance of the truth, and unwillingness to see the less-than-ideal current state.

The truth of the matter is, as long as a website or web application is usable across different browsers (meeting requirement 1), and is easily maintainable by the developer (requirement 2), why should it matter which standard we choose? Some people use XHTML because they feel it provides them with a better control over their website; I use HTML because I maintain that same level of strictness in my coding style. Certain developers like using Dreamweaver templates, while I like to use SSI instead. It’s a matter of personal preference at that point.

Current state and moving forward

I spoke above about the current state, and I’d like to revisit that. This is the crux of the issue, and is the only reason that I don’t advocate sticking entirely to the standards in complex situations. The only reason that we go “above and beyond” the standards is because certain browsers don’t support the standards that are the way to the future. My reasoning for not using XHTML is that it really doesn’t provide any benefit for me as a developer. I can make my tags lower case if I want to, and can make sure to close each and every one of them. XHTML just forces that upon me at this point. Now, when we get to the unfortunately distant future where people use browsers that can actually support the xml+xhtml doctype, then we’ll be able to do the cool stuff that web standards will provide.

User agents are complex beasts, and unfortunately take a long time to catch up to standards, so until they do I will use plain old HTML, as it serves the purposes of most of my sites.

I like my CSS to be right. And by right, of course I mean “my way”. Now, I try not to be anal-retentive about many of these things, but they’ve been valuable for me in easing maintenance work. They provide consistency and readability, which is what I like, since I’m lazy.

Now, everyone and their mom (assuming their mom is a web developer/CSS guru) has already gone over how they like this, so I know I’m beating a dead horse. However, I think it’s worthwhile to explain why I do it this way.

Property assignments

For example, display: block is a property assignment. There are two rules here. First, I keep all property assignments within a block alphabetically ordered so that I can find them with no problems.

Example:

.section {
background-color: #F00;
display: block;
height: 100px;
text-decoration: blink;
width: 200px;
}


I generally keep them in this format: the “sort of compact” method. The selector goes on the first line, along with the opening bracket. Then, all the property assigments are listed, one per line, and then the closing bracket is on its own line. Nice and readable.

If there is just one property assigment, as is the case with certain things, everything will go on one line, from the selector to the closing bracket. ex: a:link {color: #600; }

Declaration ordering

I try to keep all my declarations in the same type of hierarchy as they would normally appear in an HTML page, or however makes the most sense. Generally, tag-based selectors (h1, a, p, marquee [just kidding]) all come at the top, followed by class selectors for repeated elements, and then finally for single-use, ID selectors.

File hierarchy and structuring

This is really the most important part: how you organize the way you store your CSS files on your site. In Roots, the way I’ve split up my files is first by media type, and then by function. In addition to separate files for each media type, I create little snippets for layout, color palettes, typography, forms, etc. By allowing SSI to process my CSS files, I can keep everything organized and easily maintainable, yet only have one file that the client has to download.

Here’s the quick rundown:

Common CSS

/common/ - this is where I keep snippets that are used among media types, examples being the subfolders below…
»color-palettes/ - all main color for every element on the site is stored in a color palette CSS file, so that I can change color schemes at any time.
»typography/ - obviously, for all font declarations. Once again, I can change the typography with one line change. This is especially useful for when different media types require certain fonts.

Screen CSS

/screen/ - All code for the screen media type, including some files that simply reference a file in the /common/ folder. The main file here is screen.css, from which everything else is SSI’d in.
»color/ - This is one of those places where it’s just a reference to a color palette. I also include some overrides or additional declarations, if necessary.
»layout/ - This is where anything related to layout of elements on a page is stored. Layout grids and code snippets galore!
»»grids/ - I store a variety of grids here, generally for 1-, 2-, or 3-column layouts. Any one of them can be swapped in at any time
» - In this /screen/ folder are files for the header and footer, navigation, forms, and standard content. Keeping them separated helps for maintenance–if something’s wrong in the header, I don’t have to sort through a bunch of declarations in some huge file to find it.
»typography/ - this, like the color folder, is simply a place to reference which typography palette I wish to use.

Print CSS

/print/ - All code for the print media type. This is much more trimmed down than the screen folder.
»color/ - Once again, the color folder, for the same purpose as in the screen media type
»layout/ - This folder is for print layout, and only contains 3 files: base.css, content.css, and layout.css. Base.css is for setting up print-specific things, such as paging. Content.css is for standard elements, and layout.css is for basic layouts…no grids here, most likely.
»typography/ - Just like the screen media type

Handheld CSS

/handheld/ - All CSS for the handheld/small screen rendering goes here.
»color/ - The infamous reference color folder appears again.
»layout/ - This folder contains header and footer, navigation, forms, and basic content, just like the screen layout folder, but does not provide anything for grids, since that’s not very good for handheld devices. Basic layouts can be done in the content file.
»typography/ - Typography’s folder is here to join in the fun as well.

Aural/Auditory CSS

/aural/ - There’s just one file here, since there’s not much to do for aural. Not much support these days, so what can you do?

Sections and Pages

/_sections/ - Whenever you need to override or add some styles for certain directories/sections of your site, they go in here.
/_pages/ - For page-specific overrides, you can put a CSS file here rather than using inline styles if you want to have some of the benefit of SSI parsing or client caching.

Base.css - Default style simplification

Let’s not forget the magical base.css file, which tries to reduce as many of the differences in default styling among browsers. Mostly, this is margin and padding work, but also there are some font sizing things and list edits to take care of.