Re: Supporting propriety "Extensions"

| 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."
| So we have established that there needs to be *some* kind of mechanism.
| Given that need, the CSS group came up with a convention of prefixing
| vendor-specific properties with -vendor-. I do not see what is so
| strange about the notation.

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?

Second: Does something like -moz-border-radius prevents
anybody to use it on the Web? No. We've already seen such sites.
And will see in the future. Exactly in the same way as IE introduced
its own set and without any -ie-xxxx and with the same result.

Third: If UA 'AAA' sees some-unknown-attribute in CSS
it just ignores it and its value. Ignorabimus et ignoramus as
stated in CSS. This is perfectly fine. Why do we need to
backup this in such ugly way?

My points are simple:

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.

2) Life is life. There are differences (including different attribute sets)
and bugs in different UA implementations. This is a reality.
If we really want to help authors to deal with
this then we should invent something like

@in_case_of  public_ua_name_1
{
   ....
}
@in_case_of  public_ua_name_2
{
 ...
}
@otherwise
{
   ....
}
and *this* will really help. Something similar was already proposed
here recently but did not get much attention for reasons unknown
to me.
In contrary -zzz-something is a misterious source of excitement.
Why?

Andrew Fediniouk.
http://terrainformatica.com


From: "Laurens Holst" <lholst@students.cs.uu.nl>
Sent: Tuesday, February 22, 2005 6:44 PM
|
| Andrew Fedoniouk wrote:
| >> For those two cases it doesn't matter if the units are obscure (e.g.
| >> "_moz_ch" would be perfectly find for an experimental implementation of
| >> the proposed "ch" unit).
| >
| > I understand "how" but do not understand "why"...
| > What is the purpose of introducing namespaces using such strange method
| > and notation?
|
| 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."
| So we have established that there needs to be *some* kind of mechanism.
| Given that need, the CSS group came up with a convention of prefixing
| vendor-specific properties with -vendor-. I do not see what is so
| strange about the notation.
|
| If you have a better suggestion, which works (in a backwards compatible
| way), please :). Complaining is always easier than thinking towards
| solutions.
|
| Personally, given that there currently is an established method however,
| I do not think it would be worth the effort to change it. I don't even
| see a reason to. The method seems to work well enough, and is used by a
| number of implementations. I understand it is a little troublesome for
| units, but heh, then don't prefix the units and just bet on it not
| conflicting with any future standard.
|
|
| ~Grauw

Received on Wednesday, 23 February 2005 05:51:31 UTC