Re: Extend use of namespaces

On Sat, Sep 18, 2010 at 8:41 AM, Paul Duffin <pduffin@volantis.com> wrote:
> Fine, then for now could everyone please ignore the syntax I use and forget that it wasn't intended to address these issues and provide me some real constructive feedback on why allowing CSS identifiers to be qualified by / grouped into namespaces is a bad idea and unnecessary.

It's unnecessary because... no one's demonstrated a need for it?
That's the definition of 'unnecessary'. ^_^ XML-style namespaces in
particular have several problems of their own, a few of which
unfortunately propagate into CSS's Namespace concept as well (namely,
the use of unintuitive and difficult-to-memorize namespace URLs).

>As part of that could you explain how the current vendor prefix mess is going to be sorted out. I would appreciate it if you could do it in response to my other email that provides concrete examples of how namespaces would help address those issues.

In general, the vendor prefix situation isn't a mess; the problems you
describe are actually features.  Properties are vendor-prefixed when
they're still experimental, and the spec defining them hasn't moved
into a stable state (CR or higher, in the spec life cycle).  We
*really* don't want a vendor to implement a property in a certain way,
get authors to depend on it, and then we realize there was a big
mistake and we have to change, but we can't because it would break
pages.  HTML's been through that pain multiple times, and CSS has
luckily been able to mostly ignore that.

As an example of what happens when you try and treat prefixed
properties as a real part of the language, rather than an experiment
that could change or disappear at any time, look at the painful
situation Webkit's found itself in due to their dominance of the
mobile smartphone market.

Now, that's not to say it's perfect.  There are times when particular
properties stay in a prefixed state for too long, because they're held
back by being placed in a spec that's progressing slowly.
Border-radius was one such property (though note that border-radius
was implemented incompatibly in different browsers for a while).
We're aware of that situation, and are trying to stay on top of things
there so we can take steps to allow stable properties to lose their
prefix.

In your previous email, you also brought up the possibility that an
author could use a namespace to target the implementation of a
property in a particular draft.  What happens when the browser you're
targetting updates to a new draft?  They can either start ignoring
your property, pretend that you're actually referring to the current
impl, or keep supporting both implementations indefinitely.  The first
sucks, especially if the property in question wasn't changed between
drafts, the third sucks even more, and the second is actually the
current situation theoretically, but with the added confusion that
you're claiming you want one draft but actually getting a different
one.

~TJ

Received on Saturday, 18 September 2010 17:18:57 UTC