W3C home > Mailing lists > Public > www-style@w3.org > February 2004

Re: [CSS21] response to issue 15b

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 10 Feb 2004 14:26:59 +0000 (UTC)
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: www-style@w3.org
Message-ID: <Pine.LNX.4.58.0402101410250.25633@dhalsim.dreamhost.com>

On Tue, 10 Feb 2004, Bjoern Hoehrmann wrote:

> I object to this resolution. The operative Process document clearly
> outlaws such general statements and even if it were allowed, if the
> Working Group is not convinced that any feature of the document will
> get interoperably implemented, the document is clearly not mature
> enough to issue a call for implementations.

The question is not whether the working group thinks that implementations
of the spec are technically feasible or not -- the working group is just
ensuring that if a feature isn't implemented, CSS will not exit CR with
that feature, since doing so would be of very little use for authors.

> It is, for example, not acceptable for web authors to be presented as
> CSS 2.1 Recommendation without positioning, the :hover pseudo-class or
> media specific style sheets;

...because authors are happily using them in multiple browsers already? If
the implementations are interoperable, then the feature won't be removed
-- if the feature is not interoperable, then authors aren't referring to
the spec anyway (at least not successfully) so there is no point the spec
existing for those features.

> the Recommendation would be of no use to them if these features
> get dropped and hence they would formally object to the advancement of
> the Candidate Recommendation anyway.

The Recommendation would be of no use to them if it described features
they could not use, or worse, could use but not as described by the spec.

> no such features, in which case missing interoperable implementations
> just demonstrate that there is something wrong with the specification
> that requires a substantive change in order to get fixed, in which
> case the document must go back to Working Draft status anyway.

There is a third case, the much more common case: implementations either
have simply not gotten around to implementing the feature, or
implementations were written with poor code or inadequate testing and thus
a perfectly fine section of the spec was implemented incorrectly.

> I would also like to point out that changing only part four of the
> proposed exit criteria would not have been satisfactory anyway, my
> original issue was about part four and three.

The other part states that features that have not been adequately tested
will be dropped. Are you seriously suggesting that you would want features
that have not received adequate interoperability testing to remain in the
specification? Isn't that violating the spirit of the process document
(and the whole _point_ of a CR stage) much more than the given criteria?

Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 10 February 2004 09:27:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:11 UTC