I should have quoted. But anyway, to rephrase, the API itself is hardly horrid if it was used in a non-embedded context with enum support. ex:

enum Direction {
TOP:0,
RIGHT:1,
BOTTOM:2,
LEFT:3
}

It’s of course a simple academic observation.

I think if we’re going to add maths to the CSS standard, it should be within a function (eg expression()), if only to avoid people assigning mathematical values without understanding the consequences.

TNO,

It was clearly designed as the DirectX API, as it calls DirectX functionality against the DirectX API structure.

I think something like this would be good “width:50% – 16px;” – it would be more accurate than trying to accomplish the same with “width:48%;” , or playing with margins and relative positioning to fit something in.


filter:progid:DXImageTransform.Microsoft.Matrix(sProperties)


Not the best-looking API around, but ah.

I’m not actually faulting Microsoft their expressions implementation. I’m saying that it’s a good idea, and deserves a good standard and good implementations. And I provided some thoughts on how that might look.

I’m also, again, not saying that the rotation syntax is hard to understand. I’m saying it’s poor syntax and a poor API. And that the syntax was created so long ago isn’t really an excuse, as it was translated to IE 8′s supposedly “correct” CSS 2.1 implementation.

As far as the “rotation=3″ goes – I understand some people don’t like the syntax. That’s fine with me. The syntax was created in a different era when essentially you had a Netscape standard and an IE standard. But for me (this is me personally, I can’t say how anyone else thinks), it was never difficult to use or understand that rotation=1 rotates 90deg, rotation=2 rotates 180deg, rotation=3 rotates 270deg.

width: expression(100% – 16px);

And redraw/reflow would only occur when the container’s width changes (as is the case with width: 100%). As far as internal implementation, this could be accomplished by maintaining calculation adjustments (eg -16) to apply when the variable measurement is calculated, eg instead of [pseudocode]

element. positionedParentNode.onwidthchange = function() {
element.currentStyle.width = 1 * this.currentStyle.width;
};

use [again, pseudocode]

element.positionedParentNode.onwidthchange = function() {
element.currentStyle.width = (1 * this.currentStyle.width) + element.__expression.width;
};

where element.__expression.width would represent the static width expression adjustments (-16).

With these considerations, CSS expressions could still be tenable, and would be extremely useful.

Personally, I don’t think “rotation=3″ was all that difficult to write. But, at least, I think most everyone can agree the modern proprietary syntax is easier (transform: rotate…)

Also, you can use ‘-ms-filter:’ to make the text rotation work in IE8 in standards mode

You didn’t answer my question. Why would a developer want to differentiate between browsers? I’m not asking why a developer would want extensions (I think we agree they are a net positive), I’m asking why a developer would want to treat one browser differently than another.

“Agreed… but we’re not here talking about different results, we’re talking about different implementations of the same non-standard thing.”

Er, you were promoting differentiating browsers; different results is a necessary conclusion of that.

“I’m sure you aren’t arguing that MS should get together with Mozilla, Apple and Opera and agree on an implementation independent of standards bodies, are you? That would be a nice world to live in, but not a realistic one :)”

No, I’m arguing that Microsoft should take the same approach Apple and Mozilla currently take: implement extensions that are consistent with existing standard APIs, and then push for standardization of those extensions. I spelled it out in my last comment. Microsoft does neither.

“This is where I disagree and where I see a contradiction. Either a vendor can extend standards, in whatever way they want, or they can’t.”

If they claim to support standards and interoperability, they should use the standard’s extension mechanisms. If they don’t do so, they are lying about their support for standards and interoperability, and are therefore going to catch flack.

“They’re under no obligation in any way. … Remember, no vendor is under any obligation to implement standards.”

They’re certainly under some obligation. As any other vendor, they have an obligation to fulfill their promises. By adopting the CSS standard, they have an obligation to use the standard’s extension mechanisms. They’re not under any obligation to adopt the CSS standard, but they certainly have claimed adoption. In short, they have an obligation not to mislead their customers.

“Geez, I hate to sound like an MS booster because that’s just not accurate, but… is their behavior really any different than the other vendors?”

Yes!

“I mean, we have three different implementations of the same text rotation concept here. Sure, two vendors seem to have agreed on the value you set the attribute to, maybe just by chance, I don’t know, but the attribute name is different and therefore the API can’t be said to be the same because the API is not just the attribute value but also the attribute name.”

You’re wrong. The Mozilla and Apple implementations are identical, and according to the standard’s extension mechanism. The prefix (-moz-, -webkit-, -ms-, -o-, et al) is not part of the property, it indicates a vendor-specific extension namespace. Even Microsoft has adopted that in IE 8′s “real” standards mode. The property is “transform”. Mozilla and Apple are correctly following the extension mechanism in CSS to introduce new features by keeping their extensions out of the global namespace in order to await final standardization.

“but so what? That’s their choice.”

Not if their claim to support standards and interoperability holds any water. They catch flack for flouting what they claim to support, not for failing to meet expectations from on high.

“Hell, they *could* decide that MS is onto something and their API should be the standard! I think we can assume that’s not going to happen, but it *could*, and that’s what makes it OK, that and the fact that we have a choice right now.”

I think this ignores the fact that CSS as an API is generally consistent, and that extensions to CSS are adopted in a manner consistent with the existing API. Microsoft’s extension is basically disqualified from the outset by being syntactically inconsistent, not to mention tying the syntax to its own internal, proprietary APIs (DirectX).

“You know, this is actually a pretty bad example to argue about frankly because MS started offering these types of capabilities in like 1998 or so… they were WAY out ahead of others in this situation.”

I don’t think it’s a bad example, because my point applies to all of Microsoft’s CSS extensions. They could have resolved this easily by providing API-consistent aliases to their internal functionality within IE 8′s “real” standards mode (eg -ms-opacity: [decimal >=0 <=1] as an alias to -ms-filter: [DX crap]). Nobody cares that they use DirectX to implement the functionality (except insofar as it produces inconsistent results), just that they require non-standard code to achieve the desired result. They’re making us work harder and code more than necessary. They’re unnecessarily costing us time and money.

“It’s not really fair for anyone (not saying you did this by the way) to criticize them for something they did BEFORE the “standard” was announced.”

The vendor prefix for keywords (properties, values) was introduced with CSS 2.1 in 2005. http://www.w3.org/TR/CSS2/syndata.html#vendor-keywords

IE 8 began development in 2006 and was released in 2009. IE 8 claims to fully support CSS 2.1, but I think its handling of extensions is only according to the letter, rather than the spirit, of the standard.

“don’t blame vendor A for not supporting standard feature B, blame the people that still insist on supporting vendor A with their business!.”

What are we supposed to do, block 75% of web traffic? I think by doing that we’d be breaking our own (implicit) obligations; obviously this is more or less tenable depending on the purpose of our websites/applications and their respective target audiences, but you get the point.

“We’re at a point where no one is being forced to use any vendors’ browser any more, that’s an old argument that doesn’t, IMO hold water any longer.”

That’s false. A huge percentage of IE users, for example, are disallowed by their employers from installing a new browser. Including, apparently, you!: “we’re an IE-only shop.”

“I still think it’s true that vendors will pretty much always be out ahead of standards bodies in terms of implementing functionality, and that’s the point I was making: if we completely ignored vendors’ extensions and stuck to standards we’d be depriving ourselves of some powerful tools. You’re right though, the delta between what the vendors provide and what the standards provide maybe isn’t as far apart as it once was.”

I just want to reiterate to be clear: I’m for vendor extensions to CSS, provided the extensions are done according to both the letter and spirit of the standard. There is only one exception to that, which is if the standard itself is incapable of supporting a given feature, in which case a new standard should be proposed. As far as I’m aware, the CSS standard is perfectly capable of including the functionality of Microsoft’s extensions, but those extensions fly in the face of the standard’s API. If Microsoft wants credit for supporting the standard, they need to actually support it rather than paying lip service to it.

Rather than trying to change their behavior, let’s sidestep the problem entirely and get people off IE as much as possible. Not easy, not trivial, and in many cases not even possible, but we can and should try. Sure, it’s an idealistic goal that is probably a fool’s errand, but it’s worth doing, and in the end is probably less the fool’s errand than trying to get MS to truly embrace standards :)

“I don’t really think that’s true. The standards have a lot of great features that aren’t available for use because of a lack of consistent implementation across browsers. That is what most of us are up in arms about.”

You’re totally right, there are parts of various standards we can’t use because of browser implementations. and that totally sucks. But that’s placing the blame in the wrong place IMO… don’t blame vendor A for not supporting standard feature B, blame the people that still insist on supporting vendor A with their business!.

We’re at a point where no one is being forced to use any vendors’ browser any more, that’s an old argument that doesn’t, IMO hold water any longer. That being said, we need to start blaming the people that insist on acting like that’s still true, and we need to be evangelists to get people to make the… ahem… “hard”… choice. If IE isn’t getting the job done, switch. If that means we as developers have to stop supporting IE, then so be it.

Now, I realize this is a pretty utopian comment to make… if I wrote an app that didn’t work in IE at my job I’d be in trouble because we’re an IE-only shop. That doesn’t however mean that I can’t and shouldn’t evangelize about why we shouldn’t be on IE any more, and standards support is the biggest reason IMO (not so sure security is a big differentiator any more). And there may even be some cases where I can degrade the experience for IE and be like “well, too f’ing bad, get on a standards-compliant browser”… err, in a slightly more politically-correct way of course :)

I still think it’s true that vendors will pretty much always be out ahead of standards bodies in terms of implementing functionality, and that’s the point I was making: if we completely ignored vendors’ extensions and stuck to standards we’d be depriving ourselves of some powerful tools. You’re right though, the delta between what the vendors provide and what the standards provide maybe isn’t as far apart as it once was.