Nerdlife

Earlier today I was attempting to style a table header when I came across a peculiar part of the CSS 2.1 spec.  Here is what I was trying to create:

I has a table with a number of header elements and I wanted to style it such that each one would have 2px of gray border on the bottom and 2px of space in between each element.  Simple enough, right?

After poking around for a bit with allowing table row elements to have margins, I decided it would be much easier to just put a right border on each element, 2px thick and solid white.  Easy enough, right?  Wrong!  Here’s what I got:

It seems the bottom border would take precedence over the right border.  But why?  How could I override this?  Eventually I stumbled upon the appropriate page of the CSS 2.1 spec, which explained everything (almost):

17.6.2.1 Border conflict resolution

In the collapsing border model, borders at every edge of every cell may be specified by border properties on a variety of elements that meet at that edge (cells, rows, row groups, columns, column groups, and the table itself), and these borders may vary in width, style, and color. The rule of thumb is that at each edge the most “eye catching” border style is chosen, except that any occurrence of the style ‘hidden’ unconditionally turns the border off.

The following rules determine which border style “wins” in case of a conflict:

1. Borders with the ‘border-style’ of ‘hidden’ take precedence over all other conflicting borders. Any border with this value suppresses all borders at this location.
2. Borders with a style of ‘none’ have the lowest priority. Only if the border properties of all the elements meeting at this edge are ‘none’ will the border be omitted (but note that ‘none’ is the default value for the border style.)
3. If none of the styles are ‘hidden’ and at least one of them is not ‘none’, then narrow borders are discarded in favor of wider ones. If several have the same ‘border-width’ then styles are preferred in this order: ‘double’, ’solid’, ‘dashed’, ‘dotted’, ‘ridge’, ‘outset’, ‘groove’, and the lowest: ‘inset’.
4. If border styles differ only in color, then a style set on a cell wins over one on a row, which wins over a row group, column, column group and, lastly, table. When two elements of the same type conflict, then the one further to the left (if the table’s ‘direction’ is ‘ltr’; right, if it is ‘rtl’) and further to the top wins.

So there we have it…there is an order of precedence for border edges.  While it seems relatively arbitrary, it is at least specified, which I suppose is better than nothing.  This doesn’t exactly fix my problem though, now does it?  In the end I copped out and just made the width in between the cells 3px and as per item 3, the white border took over.

I hope CSS 3 has some kind of mechanism to specify this (The CSS3 table module has yet to have a draft release).  It seems like the ordering is relatively arbitrary and in rare situations where it does matter it’s worth being able to specify.

CSS, html, W3

Douglas Crockford has a very interesting article on fixing HTML. He points out many of the most annoying things about HTML that make web development difficult. The currently proposed HTML spec only fixes one thing as far as I can see (being a developer), the addition of more specific types of inputs: time, date, email, etc. The W3C has consistently done a poor job, as do most standards bodies, at rapidly improving their spec due to the semi-understandable fear of pissing people off by breaking standard. Yes, I know that backwards compatibility is important, but is it worth the years upon years of expense in training, debugging, extra staff, etc just so that companies don’t have an extra inconvenience of having to maintain two versions for a few years?

But this post is not about new HTML standards (nor is it an IE bash, though it may appear so initially). It’s about the cost of developing to different specifications, and a proposed solution.

I’ve noticed that at every company I’ve been with, at some point I have this discussion:

Me: Man, these cross-browser bugs are annoying
Coworker: Yea, I spend more time adding in hacks than I do developing
Me: I bet if there was one browser out there web companies would save billions in development
Coworker: Yea, I can’t really thing of a reason not to only have one browser

Then we both go back to coding out IE hacks

It’s an undeniable fact that cross-browser compatibility is a huge black hole when it comes to productivity. Design, development, QA, nearly the whole process is bogged down by having to take this into account. Why? When it comes to developing for Windows/Macs/*nix it is at least justifiable: there’s big money in OSes (at least for now). Browsers? Maybe, though it’s arguable, especially since there are free open-source ones with fast release cycles and mature feature sets. My question is why are there different rendering engines?

And that leads into my proposed solution, which, for perspective’s sake, warrants an analogy:

Consider the consequences if the DNS namespace were like the current browser situations. There would be one major DNS provider, the default on most computers sold, along with one popular one with around 20% market share, and some smaller ones. There are a bunch of hacks in place to try and ensure that people using one DNS could still view sites from another provider, and sites will register with a bunch of DNSs, but if your not using the hacks and the company doesn’t have the finances to register with all these DNSs, you’re out of luck.

Sounds ridiculous, right? The solution to prevent this is supposedly ICANN. Granted, this organization has its issues, the internet as a whole seems to be better off with it. So why not do the same thing with rendering engines?

Why not have an organization, say for example the WHATWG, be the sole developer and distributor of a rendering engine. Just like how the Linux kernel is used by all Linux distributions, make this renderer’s source code the de facto standard for web parsing. Changes to the way it parses things would be discussed in a public forum, with significant input by all browser developers, and implemented accordingly. Of course, there would be a distinct line between renderer features and browser features, with things such as default style of buttons and how spell checking is visualized left to the individual browser, but things like size of default buttons, graceful failing, etc, specified in the renderer.

Granted, I’m sure this solution has been proposed before, but usually more along the lines of “why doesn’t everybody use Firefox.” I feel this is a better compromise…browsers can still have their silly little war, users would no longer have rendering issues, companies would no longer have twice the development time, new specs would be adopted much faster, bug fixes could be implemented much more quickly, and so on and so forth. Everybody wins!

I can see Mozilla and Opera going for this very quickly. Apple shouldn’t be hard to convince. The big issue would be Microsoft (not to single them out, but they do seem to be the most stubborn). Development resources are nothing to them, and they have a lot of IE-only sites that take advantage of IE’s quirks, such as Outlook Web Access, along with lots of sites. They also probably see IE-only sites as a hindrance to Firefox growth, which would discourage participation.

The solution? There’s always the “because the government said so” option, where they provide either massive incentive or legal requirement to use this spec (i.e. giving the body that makes this spec a legal monopoly, just like the power companies). Then there’s the PR option. Similar to Intel’s Intel Inside&rest; campaign, make the render brand a household name. Make people question why IE doesn’t use it. The final nuke that can be dropped on Microsoft’s headquarters is an idea that also came from my workplace conversations. If two or three major websites, say Google and Yahoo, which control over 75% of the search market (up to 90%, depending on who you ask), do one of three things, alternative browser usage would jump significantly:

1. If they block all users not using the recommended renderer, even for a day, and provide easy instructions on installing another browser, millions would switch. Of course, they would lose millions of dollars, but the amount they would save in development costs would make it worth it. Even the mere threat of this, coupled with a deadline, could cause MS to change their minds.
2. If they put up a prominent icon recommending a compliant browser, it would cost them a few pixels and virtually no revenue, and would get plenty of people to switch, again, doing this, if it yields results, would force MS to reevaluate their stance so as to not risk losing significant market share
3. Stop developing for IE, allow it to become deprecated. This would have to be done carefully, perhaps with a notice at the top explaining that other “better” browsers provide enhanced functionality. If not done well, users would simply go to a competitor (as is the risk with option 1, but that’s short term, whereas this isn’t), but if done carefully and over enough websites, it would slowly force either IE to conform, or users to switch (browser or website, hopefully the former).

Note that I’m singling out IE here since Microsoft is historically stubborn…these methods would work with any browser, especially smaller ones who don’t have as much pull as IE.

So there you have it, a perfectly reasonable solution to the browser wars, or better yet a way to not let it impact other fields. Stop being stubborn internet (like that will ever happen…)!

browsers, html, internet, programming