kaioa.com

Decisions, decisions...

Legacy Ball Chains

A few weeks ago when Microsoft announced their "opt-in for the default behavior" strategy I was disgusted. Quite frankly I still am. As I see it it's just another scheme to pave the way for more legacy cruft. Don't get me wrong, I'm not disappointed. After all it's what Microsoft always did, but the way they did that - pretending they are doing everyone a favor - was just a bit too annoying. Why can't they do the right thing? Just once.

"Backward compatibility", they say. But wait a minute - don't we already have a tool for that? Yes, we do. Conditional comments (another Internet Explorer specific thing) are used for this kind of things for a couple of years. In a nutshell: you create a website with a good browser (i.e. not IE), and then you work around IE's issues with override style sheets targeting specific IE versions.

The strategy was always to lean forward; fix the issues of the current and previous IE versions and hope that the next one doesn't need extra workarounds. Back when IE7 was released that didn't really work out, because it still had some of IE6's problems and a few new ones on top of that. I should have seen that coming.

So, that didn't always work out as intended. However, all that IE specific workarounds were at one place and - even better yet - far away from our carefully crafted style sheets. Isolated and versionized. Once a new IE version pops up, add another one if required. It keeps your CSS files clean; there is no need to exploit any parser bugs.

Of course a bug free IE would have been great, but at least it gave us a rather good method to keep the IE cruft away.

And now Microsoft added yet another IE specific thing. A meta tag (or header) which specifies the engine we want to use. Doesn't sound that bad, does it? The catch is that it will use IE7's renderer (for all eternity) if it's missing. It's the "yes, I really really want to use standards compliant rendering" as some people started to call it. Actually, using a doctype was supposed to do just that.

Where will it end? Are we going to use five or even ten of those switches a couple of years down the road? It's madness.

But it's actually even worse than it initially looks. Including a couple of engines creates massive code bloat. The real issue isn't the memory usage tho. It's the increased complexity. Having half a dozen of engines - interacting with each other - makes everything more fiddly. It will create lots of maintenance work and there also will be lots of critical vulnerabilities. As the saying goes... the road to hell is paved with good intentions. Unsurprisingly every other browser vendor stated that they won't go that route ever.

Well, the specs from the W3C are very complicated. All of them are. But it's a mystery why Microsoft is doing such a bad job in comparison.

Treating Web Developers Like Users Was Wrong

Did you ever wonder how it turned out like this? Personally I think it was wrong choice to use something as fuzzy as SGML as starting point. Parsing a tag soup takes more processing power, it adds complexity to the parsers, and ultimately it leads to different behavior, because the behavior of all those nonsense markup combinations is undefined. Which leads to more work such as validating and testing in different browsers.

Everything we get in return for all of that hassle is rendering of invalid markup and styling, which may vary greatly with different browsers. That really isn't the best trade. It's actually so bad that I cannot come up with a matching real life metaphor.

Of course the vast majority of current websites don't adhere to ultra strictness. But things would be different if it would be absolutely required. Content management systems for example would always produce 100% valid markup - otherwise there would be a critical bug, which needs to be fixed as soon as possible. After all the user can only see an error message then.

With the application/xhtml+xml Content-Type header you can already enforce well-formed markup. However, IE (even IE8) doesn't support that. Well, it's the right Content-Type for XHTML. So, you could for example use that header for modern browsers and the wrong one for IE. This works if you take care of a few details. Unfortunately most content management systems aren't quite up to the task. Drupal for example produces invalid markup on the watchdog page. Seeing an XML error message there (and nothing else) would be quite inconvenient. But generally I think XML works fine as text/structure carrier.

Issues of CSS

But at least the strictness of the markup part can be sort of addressed nowadays. The other issue is CSS. In my opinion the CSS specs are far too complicated. At the same time CSS is very inflexible and even everyday tasks such as 3-column layouts - the thing CSS was created for - are only possible with lots of tricks and workarounds.

It's like a ultra restrictive programming language with a massive API. You have to know a lot, you have to try a lot, and yet you can't even do the simplest things such as basic math. There aren't even variables.

CSS was meant to make this kind of things easier. To be fair for simple things it's very effective. But as soon as the layout gets remotely complex it becomes a pain. There are many things in the specs you don't need and others the working group failed to predict. Everything needs to fit into their layout model and sometimes you've to make it fit with a hammer.

Just take that typical 3-column fluid-width layout with equally tall columns, a header, and a footer. It's the most basic layout and yet it's amazingly hard to do. I did about a dozen different versions - each with its own set of issues. Some of the approaches didn't work at all in IE - no matter what I tried. Sure, there are lots of "holy grail" templates, but those aren't perfect either. Even if they were written by famous CSS experts.

Something as basic as that should be a lot easier to do. It should be a no-brainer and it certainly shouldn't be a switch and refresh fest. Another giveaway of the current bad state is the lack of good WYSIWYG tools. Of course you like coding as much as I do - otherwise you wouldn't read this, but the absence of such a tool clearly indicates how fragile CSS really is.

What if...

Alright. Now imagine there would be a proper specialized static typed object orientated programming language for this task. Eventually even compiled (and always compressed). The API would be very minimal. E.g. there would be a few methods to influence the font rendering, calculating/changing the size of text boxes, drawing images, querying image sizes, basic drawing functions, and direct pixel buffer access etc. You could also create your own layout manager if you need a specific behavior. WYSIWYG editors for example could ship with a few extra layout managers to make specific things easier.

That would be actually less crazy than it initially sounds. You could reuse code, there would be some nice open source code, pinpoint error messages, high flexibility, a compact API, easy verification of implementations, performance could be pretty great, and you could even save some bandwidth. Yes, you could really save bandwidth, because there won't be much code and you could get rid of some images by doing the drawing of some effects yourself.

While the language itself would be more complicated, its API would be easier to use. If something is missing you can just add it, instead of inventing workarounds. E.g. if you need a foreground image for a specific element, you could simply draw it after the element. That's something the CSS working group failed to predict. If you want to do something like that with CSS, you would have to add extra markup.

Speaking of extra markup, with such a style language there won't be a need to add any non structural markup ever. You can always place the elements where you want 'em and you always have full control of the rendering. Round corners, custom borders, drop shadows of elements (not text only) etc. All of that would be possible and none of that would require additional markup or changes to the language.

I also mentioned easy verification of implementations. It seems that technical writers are better at specifying the behavior of programming languages. If the expected results are clear it can be also explained in a more definite language. Adhering to crystal clear specs is a lot easier. And what's more important: the results can be crosschecked (fully automated) in a test suite. Sun for example has a massive test suite for the Java programming language. If your implementation fails, you cannot call it "Java". Sounds harsh, but for Java programmers it's really great.

If there would have been something similar for CSS 1.0, Microsoft wouldn't have been allowed to state that IE6 supports it (background-position:fixed wasn't supported at all - and yet they claimed full CSS 1.0 support). As you can imagine that would have put enough pressure on 'em to fix it before the release.

If the ACID2 test comes to mind now, that something entirely different. It doesn't test each feature on its own, it's fiddly to integrate in a test process, it gives you "everything is fine" or "something isn't" kind of response, and it basically only tests if your CSS parser adheres to a specific set of fallback methods for semi-broken styling.

A set of fallbacks won't improves your productivity. As long as there are browsers, which don't implement all of those fallbacks, you'll always have to crosscheck the rendering in different browsers. It's the wrong direction. If there wouldn't be any fallbacks in any browsers, you wouldn't have to do that.

Yes, I Mean It

My point of view is pretty extreme. I'm fully aware of that. But from my own experience I know that absolute strictness is a big time saver. Getting an pinpoint error message as soon as possible always helps. Typing a bit more is always alright, if it makes the code easier to follow/maintain or if it makes the time requirements more predictable and less random.

Currently the markup/styling side of web development isn't anything like that. It's a fuzzy pile of goo with indirect error messages, which are sometimes very easy to overlook. Sure, there are validators, but that's an extra step (again and again).

I think that most of these issues stem from the decision to handle errors. Back then it probably looked like a good idea. Everyone should be able to create a website and a browser should be able to render it somehow - no matter how little sense the the markup makes. Nowadays that point is somewhat moot. Manually crafted markup is mostly created by people who know what they are doing. And most content is put online via content management systems, which can easily ensure that the markup is valid. Many people even use rich text editors, which always produce valid markup.

There really isn't much of a reason to handle this kind of errors. Especially if that error handling works against us and the browser vendors. Opera and Mozilla are doing pretty fine, but Microsoft seems to fail miserably (again) and there are no means to stop 'em from releasing another failure of a browser. We all will have to pay the price for that again.

The Future

Of course we won't see anything like the style language I outlined above any time soon. But it could be quite nice, couldn't it?

Well, the real problem is Internet Explorer again. For this blog I could just ignore IE completely. Only a few percent of my visitors use this bad joke of a browser. But generally what should I do?

I'll probably use "edge" as version target everywhere. This makes IE always use the very latest available rendering engine (as long as they don't add yet another tag). Accordingly to Microsoft its usage is highly discouraged. But it's the same deal with browser specific markup pollution, I would say. Additionally, it's the only way to "vote" against browser targeting.

Using the application/xhtml+xml header would have a similar effect, but for most websites it's perhaps a little bit too extreme. Maybe IE9 will support that Content-Type and eventually they will do something outrageously stupid with it. Like transforming it to tag soup and then mangling it through the IE7 engine. Yea, I'm afraid that sounds like a choice Microsoft could make.