Tuesday, July 13, 2010

Prefix or PostHack, or Both

The entire debate about "Prefix or PostHack" is going down the wrong path. With PPK going so far as to suggest that vendor prefixes should be completely eliminated or simplified into a single extension (though he did recant a little), and Eric Meyer rebutting that CSS before vendor prefixes was effectively a living nightmare. The REAL problem is not whether or not vendor prefixes should be used, but HOW should they be used to enable the developer/designer to choose which implementation is best for their purposes using prefixes as a posthack.

The Problem with Vendor Prefixes

The problem with vendor prefixes lies in the fact that each vendor recognizes only their own prefixed property until the module has reached the Candidate Recommendation, and that CSS 2.1 prevents the vendors from introducing unprefixed properties that have not met these Candidate Recommendation requirements. This is the wrong approach, and undermines the strength of standardization removing the control from the developers and designers that are using the standard in day to day practice. The entire section should be rewritten to empower the developer/designer with more control over how they want the parser to treat their properties, making vendor prefixes the first class citizens and unprefixed properties the second class citizens of CSS.

How Vendor Prefixes should work

Using Eric's example of text-curl, if vendor X decides to implement this new property the unprefixed property name, text-curl, should be recognized by vendor X's CSS parser, but the parser should give precedence to the prefixed property name -x-text-curl, a sort of property name specificity. Thereby allowing other vendors to implement the exact same property name and vendor X's value format for said property in their parser. If the other vendor decides that they don't like vendor X's implementation of text-curl and choose to make changes to the format of the value for instance, then the the prefixed property -x-text-curl would still take precedence in vendor X's implementation. Giving the developer/designer the ability to decide which implementation that he/she preferred, or thought would make it to Candidate Recommendation, and use that value format for the argument of the unprefixed property name text-curl, and allow the developer/designer to override the unprefixed property name with the vendor prefixed version of the competing implementation.
h1{ text-curl: small or large; -x-text-curl: large; }
In this case the other vendors value is used for the default, and vendor X's value is used only by vendor X. Effectively giving the developer/designer control over how the property is used by each vendor, but also allowing for the fact that each vendor may choose to use the same format and therefore the developer can choose not to include the prefixed property name.
h1{ text-curl: small or large; }

Give the Developers/Designers more power to control layout in specific browsers

Conversely, if the developer/designer is not to willing to chance it one way or the other over which implementation might succeed in making it to Candidate Recommendation, the developer/designer would have the option of choosing to include both vendor's prefixed property names and the unprefixed property name if they so desired.
h1{ text-curl: small or large; -x-text-curl: large; -other-text-curl: small or large; }

Give Developers/Designers ALL the power to control layout in specific browsers

Moreover, I would go a step further giving all properties the ability to be overridden using a vendor prefix, even existing standard property names. Allowing developers/designers to target a specific parser with different values for a given property name and avoiding the laborious system of hacks designed for targeting specific browsers with different interpretations and implementations.
h1{ height: 30px; -moz-height: 40px; -webkit-height: 50px;}
instead of
h1{ height: 30px; }
@-moz-document url-prefix() { h1{ height: 40px; } }
@media all and (-webkit-min-device-pixel-ratio:1) { h1{ height: 50px; } }

And Let Developers/Designers choose when to exercise that power

In my opinion, the vendors, and the W3C, would be well served to create a way for developers/designers to target not just a specific browser, but also a specific version of that browser using the @media syntax in addition to the new media query supports.
@media screen and user-agent(Gecko-1.9.3, WebKit-533) { h1{ height: 45px; } }

Don't standardize speed, standardize quality

Finally, while I do agree with Eric's statement that the W3C should set a rule for promoting a module to Candidate Recommendation once two competing vendors have implemented the same module in a similar manner. I disagree with the idea that this will improve the quality in which the standards are developed. It will definitely improve the speed of standardization, but I am reluctant to place my faith in the ability of multiple vendors to agree on implementation simply for the sake of pushing it through the red tape when the agreed upon implementation may or may not be what is best for the standardization process or community as a whole. But the recommendation that I have presented here would make such a rule unnecessary, since the speed of standardization would no longer be a drastic concern and each developer/designer would have the ability to target specific browsers with specific rules.

In conclusion, empowering developers and designers with the ability to target a specific browser when they so choose would go great lengths towards satisfying the needs and desires of those people who are using these technologies and standards every day and would lessen the need for hastening the standardization process. Let us decide what is the best use case for our designs.

1 comment:

  1. totally agree with you. was just trying to do -moz-height: with a mozilla difference just now.