CSSquirrel A look at web development and web design by Kyle Weems

Warning: this post falls into diatribe territory. I strongly feel that important technologies should be determined by consensus and not closed circles, and I’m not convinced that this is currently the case of HTML5.

I seriously doubt that Ian Hickson would ever kick Manu Sporny into a deep well (as today’s comic implies). For that matter, I’m not convinced he’d run around in only a cape, sandals and shorts, but I don’t know him as a person so I could be wrong on that point.

However, everything I’ve read, from the W3C’s mailing list archives, to blog posts by various people ranging from ARIA to RDFa, to Ian’s own words have convinced me that Hickson has fallen deep into a self-important gatekeeper mentality on the HTML5 spec, and anyone else’s opinions be damned. Although I will rant a bit on the topic, I’ll start by directing you to the following blog post/chronology by Sam Ruby that discusses this (albeit without the rhetoric I’d be more likely to fall into). The whole thing is a good read, but if you’re impatient you can jump to the end and check out his conclusion. He discusses the need for consensus over dictatorship in the open web again here (I get the impression he discusses that a lot, this is just a sample. I also don’t think he uses the word “dictatorship.”)

It’s become clear to a good deal of people more involved in these circles than I that a Not Invented Here attitude has tainted the HTML5 group, as discussed by Jeremy Keith here in a post about ARIA and HTML5. I’m guessing it’s an easy enough trap for any group of experts to fall into, but it still creates a situation where an otherwise open process becomes a closed loop. Case in point? Well, if ARIA isn’t enough for you, how about the attempts to get RDFa into the HTML5 spec?

RDFa has been facing a Hixie-manufactured road block for months now on inclusion into the HTML5 specification for what on the outside appears to be no better reason than its origination outside of his inner circle. Ian claims he’s seen insufficient use-cases and that he is “confused” by how RDFa is used, despite constant feedback by the RDFa proponents such as Manu Sporny providing both use cases and tutorials. Considering his technical expertise, I find the confusion claim by Hickson more than a bit perplexing. My own technical pedigree doesn’t come close to Ian’s, and yet I was able to successfully use valid RDFa syntax after less than a hour of reading the convenient RDFaWiki. Heck, if reading isn’t your strong point (which would be an unusual situation for a web professional) you can even watch videos they provide.

As near as I can tell, the only reason that he’d be “confused” by both the problems RDFa is designed to solve and how to implement it is because he wants to ensure that it doesn’t make it into the HTML5 spec, and he’s simply counting down the timer. Ian’s guide to handling people starts with Step 1: “There is No Situation” and concludes with Step 4: “Something could have been done, but it is too late.” Considering the stalemate for the past few months as he says repeatedly “There aren’t enough use-cases” or “I’m confused”, one could guess that he’s holding out until October, which according to his often derided timetable is when the Last Call Working Draft is supposed to occur.

Ultimately, though, the problem is more deeply routed than stubbornness. It seems, by all accounts, an unwillingness to play well with others. Quoted in a comment to Sam Ruby’s post Half Full, Ian said “The HTML5 work isn’t using the traditional W3C approach, and will never use a consensus approach so long as I am editor. Consensus simply isn’t a good way to get technically solid specifications, and is in any case basically impossible to achieve in a group with hundreds of participants such as this one.”

Someone with that mentality shouldn’t be allowed to steer the ship for a standard that will define how millions (if not billions) of web pages are made over the next few years. We’re all going to be impacted by HTML5, so even though we don’t need to all agree (an impossibility considering human nature) at least attempting a consensus of those involved is desirable. Even if I’m frustrated by glacial pace of CSS3 implementation, I prefer the W3C’s attempt at a participatory process to some sort of autocratic decision-making on how I’ll be coding for next few years.

For more views about the challenges of trying to be involved in the HTML5 process, peruse these bits about the RDFa/HTML5 conflict by Shelly Powers. Also, I reccomend checking out the advocacy of rev=”canonical” by Jeremy Keith here and here. These posts are notable because they illustrate issues with how the HTML5 group is impacting web development (without hitting the topic over the head as I’d be inclined to do) from the angle of an easy to state problem: the prevalence of URL shortening, the potential for link-rot, and a proposed solution that includes using rev, an attribute that the HTML5 WG has already decided to remove from the HTML5 spec.

What can be done? Well, you can do as Keith proposed for rev=”canonical”, and use it, validation be damned. If, for example, RDFa or ARIA is used enough by authors, then a time will come that no option will exist other than it be included in the spec. It’s a brute-force approach, but it’s a democratic one, which is far preferable to letting one Google employee decide what’s best for us.

This is a quick sanity check, if nothing else.

A while back, I found a way to make my inline-block spacing issues go away by getting tricky and using word-spacing to remove the gap, as discussed and tested here. I failed to check the results in a webkit browser, though, and recently discovered a slight problem.

Mainly, they don’t support that.

For whatever reason, IE, Firefox and Opera all apply word-spacing styling to inline-blocks, either adding to or removing the whitespace between the elements depending on your style. Safari and Chrome, however, do not. Mind you, they both have whitespace between the elements. They simply don’t allow the use of word-spacing to modify that space.

Here’s an example page showing the use of word-spacing with inline-blocks and normal sentances. Take a look in a webkit and non-webkit browser to notice the difference. (I didn’t bother to do IE 6&7 correction, so those browsers won’t show the lists side-by-side. Upgrade your browser already!)

As you’ll see, the webkit browser isn’t removing the whitespace.

So, the question is this: Does the w3c spec say what behavior is supposed to occur? Is the webkit result a bug/out-of-spec, or are the other browsers providing a result that isn’t required by the spec? It seems to me that the non-webkit result is the proper one. If you’re going to make blocks behave like words with spacing, you should be able to modify them in the same fashion. But then, there’s a lot about CSS that doesn’t always work like you think it should. (point in case: vertical-align. Probably the worst style ever.)

I’m not entirely surprised that Google decided to release its own browser. Considering their whole web-based business model it was probably inevetible. Although you have to wonder how it’ll affect their funding of Mozilla.

What does surprise me is that I heard nary a peep before today’s beta. I feel like a back-country rube that just learned about horseless carriages.

Anyhow, here it is. I like that it’s open source (encourages other browser makers to see what good ideas they’ve created and theoretically incorporate them), but I admit that I’m curious how it’ll shake up the browser usage wars.

You can download it here, and see their official post about it here.

I didn’t wake up today with the intent of revisiting old ground, but a motivated commenter rekindled the topic of Opera’s EU filing encouraging Microsoft to be forced to adhere to a series of guidelines for web standards, and my bold statements that both Microsoft and Opera needed to work on adhering to those guidelines.

As I was crafting a response, I discovered that I had more to say on the topic than could be rationally contained in a simple comment.

First, some facts: I don’t dislike Opera. I dislike hypocrisy. Also, I don’t like Internet Explorer. I hate Internet Explorer, and I would prefer to see Microsoft adhere to modern web standards with the same fervor as the other major browser makers.

However, the responses to my earlier posts made by Opera employees and by others on behalf of the browser maker, amount to the following two statements.

1. Microsoft needs to adhere to Mr. Lie’s list of rules they should play by because Microsoft is a monopoly. Opera does not need to do this because it is not.

2. Opera is justified in delaying implementations of “new” features because they’re focusing on backwards compatibility and not breaking the web.

Each is interesting, but ultimately unconvincing.

First, I don’t believe that implementing web standards and new site features is solely the responsibility of a company that is a monopoly. In his well publicized list of rules for Microsoft, Mr. Lie agrees with me. I’ve already quoted the fifth point (relating to adding a new standards-related feature to a browser if two major browsers have already implemented it), and have pointed out useful features that at least two browsers have implemented that aren’t live yet on Opera. I want to emphasize where Mr. Lie states these rules aren’t just for Opera:

“Microsoft will surely claim that it’s impossible for them to develop a browser that complies with the proposed requirements. However, other browsers have played by these rules for years. If Microsoft can’t live up to the standards of the web, I suggest they leave the browser business.”

His assertions are twofold, first that other browser makers do play by these rules (including Opera I presume, which exclusively makes a browser), and that failure to adhere by these rules is enough reason for a company to leave the browser business.

I agree with him completely. I find it comical that some of Opera’s employees apparently do not, and have yet to hear a compelling argument as to why they should be disregarding their CTO’s wisdom. This ties directly into point #2, which is that implementation of new features must be delayed as a necessary sacrifice to maintain backwards compatibility and not break the old web.

Backwards compatibility with the soccer mom-built sites of the world is the same boogeyman that Microsoft has been waving on a flagpole since at least Internet Explorer 6. The world of web developers have yet to give Microsoft any mercy for that, and often cry for blood when feature implementation or standards compatibility is sacrificed on that altar (such as the well documented IE8 meta-tag explosion). I’ve yet to hear a compelling argument as to why any smaller browser maker can justify their own delays at implementing “new” stuff with the same smoke and mirrors and not deserve the same treatment.

In the end, the simple fact is this: I expect better of Opera. I expect them to be better than Microsoft. This means I’m not going to accept Opera using the same excuses as Microsoft, and somehow get away with it due to their size.

So, chop chop. Back to the grindstone, boys.

Yesterday I wrote a post at Mindfly describing how to make use of the CSS @font-face rule for embedding fonts into web pages. I figured it was timely, as I’m getting tired of the number of times I have to use an image (or putz around with workarounds like sIFR) to substitute a special header all because of a non-web safe font, or a client with very specific typographic tastes and a very poor understanding of how the web and fonts work together (or more to the point, how they don’t). Furthermore, both Firefox and Opera have intentions to add support to the feature very soon, creating a world where all four major browsers will have the function (although with IE using EOT and not TTF it won’t be all peace and happiness quite yet).

The thing is, the more I look into the topic, the more it appears that @font-face won’t going to be ushering in a Utopian society of pretty fonts. The core issue seems to be how legal is font embedding going to be, and how will typographers feel about developers putting their font files on servers in a place where they could potentially be snatched?

So far the answers seem to be ‘not very’ and ‘not good’, respectively.

Which makes me wonder, what good, if any, will @font-face actually serve us. If, as a solution, it creates only another problem, a legal problem, that standards themselves can’t fix, is it worth the effort investing into this path to web fonts? Perhaps browser people should be looking into another technique that’ll prove to be more secure for the font files. Something that won’t look good on paper but results in a lot of angry mail from lawyers.

Although, it does make me wonder. Is there a technique that could be used with the current @font-face rule that would still protect the fonts?

@font-face. Good? Bad?