Re: Extend use of namespaces

----- Original Message -----
> 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).
> 

Surely that is not an issue with namespaces as such but with the way that the URLs are chosen. Could you provide an example of a 'bad URL' and maybe an example of a good one, if there are any?

> 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.
> 

What painful situation? Could you elaborate?

In terms of CSS features that are in a specification which is not yet a recommendation (as opposed to purely proprietary features):
* Do you think that page authors are wrong to rely on them?
* Do you think that browser vendors are wrong to release with support for them?

> 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.
> 

I guess border-box fits into that as well given that it is in Basic UI which has been in Candidate Recommendation since 11 May 2004. So, how are you planning on improving the process? Are you going to separate those properties that are stable out into separate specifications? If you do that you would allow them to progress at different rates but would result in a greatly fragmented set of specifications.

As a point of general interest what is it that has held http://www.w3.org/TR/css3-ui/ in CR for so long?

In a better world:
* Specifications would progress quicker (possibly being split to ensure that each part progresses as quickly as possible).
* Browser vendors wouldn't release functionality until it had reached recommendation.
* Page authors wouldn't (couldn't) rely on it until it had reached recommendation.

However, we are not in that world and unlikely to ever be because:
* Creating specifications requires careful consideration which takes time, especially if you require consensus.
* The W3C process (rightly in my view) requires implementations before it reaches recommendations.
* Browser vendors have to invest significant resources to implement features in order to test their viability and progress the specification.
* Browser vendors are competing with each other (not a bad thing) and want to get some benefit from their investment and so will release early.

So, what I am proposing is to accept the world as it is and try and come up with a better mechanism to allow page authors to deal with the situation.

> 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 theorevetically, but with the added confusion that
> you're claiming you want one draft but actually getting a different
> one.
> 

If the property hasn't changed between drafts then an author wouldn't have to change the implementation and so you wouldn't have to change the URL namespace for those properties. However, a browser vendor would need to alias the namespace on those properties. This could mean that different features in the same specification are used at different levels. If a property doesn't change for a while then that should be an indication that it could be separated out if it was considered stable.

The browser vendor has a choice in how they deal with the situation:

1) They can continue to support both if they can and want to allow authors time to migrate. Whether this is practical will depend on the nature of the change in the property. A purely syntactic change such as renaming a property keyword, or changing value order would be quite easy to support whereas something like the change that occurred in border-image would not be quite so practical.

2) Alternatively, they can just ignore the old and implement the new one. That would mean that pages that wanted to use it would have to be updated and so wouldn't work on that browser any more. That would not necessarily be an issue as the author should have made sure that the page works ok on browsers that do not support that feature. They could also make use of the feature as soon as the specification had been published in readiness for browsers to implement it.

3) What they MUST NOT do is treat your old one as if it was the new one. That could make pages behave completely differently to what was intended.

(1) and (2) are possible to do now but they would need to have more vendor prefixes, one for each incompatible version of a feature. 

Even if the above is no better than what you have now, with namespaces you get a couple of advantages:
* You don't need to use different vendor prefixes for the same functionality.
* You can provide test pages for the properties that will work across browsers.

Couple of things I missed:
* Once it has reached recommendation the namespace can be dropped.
* When changing style properties through something like the {<namespace-uri>}<local-name> syntax would be needed to represent a namespaced property.

Thanks for your feedback it is very useful.

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