Re: Supporting propriety "Extensions"

Andrew Fedoniouk wrote:
> Laurens Holst wrote:
> | I think Anne explained the need for it well enough:
> | "This addresses the future, not now. So that vendor extensions are not
> | going to conflict with new W3C CSS specifications."
> 
> First: Minus in identifiers creates troubles in the *present*.
> It prevents to introduce formulas naturally.
> And allowing name tokens to start from it means propagating
> problem further. What future we are talking about?

I agree that the ascii hyphen/minus usage is a problem. Sure, 
workarounds exist but I hope I don't need to use CSS values like
    margin: -1 * -vendor-func(-1 * -vendor-special-value);
in the future. The "-1 * " is the hack I would need to use because 
the ascii hyphen/minus is already taken by function or special value 
vendor prefix so I need to negate the value through multiplication.

The future problem still exists and I would support using _vnd_ as 
verdor extension prefix instead of -vnd-. And already works for 
units too: an UA should ignore value like "2.52_foo_xunit" if it 
doesn't support unit "xunit" designed by vendor "foo".

> Second: Does something like -moz-border-radius prevents
> anybody to use it on the Web? No. We've already seen such sites.

No it doesn't. But it makes it really clear that vendor "moz" 
decides how that feature works in the future. I'm afraid that we're 
going to see
    -moz-border-radius: -foo-theme-radius-medium;
in wild. The vendor prefix makes it clear that support for such 
usage would be nearly nonexistant (because it probably needs UA 
manufactured by "foo" and that UA supports vendor specific property 
designed by vendor "moz" - it seems pretty clear to me that I cannot 
trust that behavior to stay in the future).

> 1) If company AAA wants to experiment with
> attribute 'cool-feature' internally then it may assign any
> name it wants to it. If company wants to publish 'cool-feature'
> then it should pass W3C approval. Dot.

Okay, company "foo" experiments with attribute called "margin" 
(imagine that it weren't in wide usage yet) and it's later found out 
that the design was narrow-minded. W3C cannot use property called 
"margin" for *anything* because the usage could collide with real 
world usage of *broken* design of such property. CSS is a technology 
published by W3C and I think that vendors should allow W3C to design 
the namespace. Vendor prefix is required to reserve usable property 
names for the future.

For example, "expression()" cannot never be used for anything but 
the MSIE version of the property.

> @in_case_of  public_ua_name_1
> {
>    ....
> }

And then page authors use that feature in not-too-intelligent way... 
And what do you know? A new UA vendor comes up and decides to *fake* 
it's "public_ua_name" so that existing content works better. 
(Compare to UA string used so often in JS scripts. Nearly all user 
agent strings start with "Mozilla " today!)

-- 
Mikko

Received on Wednesday, 23 February 2005 10:02:48 UTC