Re: Targeting CSS3 only (evil?), either with pseudoclass or an extra syntax for properties.

I'd like to understand _why_ we're sticking to this system. The
structures we're working on do not behave this way. They are not
single property structures, but rather multi-property structures. For
example color/background color should always be set together, but
inherit seperatly and are set seperately. At some point is the working
group going to sit down and see that they've produced rules to which
they are following tha require authors to know an additional set of
grammar that only the CSS Validator will tell them.

Since it seems that CSS isn't going to resolve a lot of the issues at
hand, is there another specification that will? I understand the
problem of backwards compatibility, but doesn't it seem that there are
so many problems right now that are being caused by either the grammar
or the fundamental rules that have been set before us.

Perhaps a better method would have been to seperate the underlying
properties of the model from the author and to instead present to them
methods that grouped those properties and included logic and presented
those the author. That was the author didn't have to know 400
different positioning and other CSS tricks and instead could
concentrate on getting the effects they wanted.

Orion Adrian

On Apr 7, 2005 7:00 PM, Ian Hickson <ian@hixie.ch> wrote:
> 
> On Thu, 7 Apr 2005, Ben Ward wrote:
> >
> > [positioned opacity is all-opaque in legacy UAs]
> >
> > So, with regard to the above scenario and any similar others that may
> > arise in future. Is it in the WGs vision that CSS should have some means
> > of handling such conflicts? Or are scenarios such as this accepted as
> > 'inevitable without resolution' as the CSS vocabulary grows larger?
> 
> I can't speak for the group, but the real problem is that all the
> solutions that have been proposed have fundamental problems, which have
> been discussed to death over the last eight years. It's a discussion that
> working group members have learnt to avoid because there simply haven't
> been any new ideas for years, and repeatedly pointing out the problems
> (some of which only really come to light when you try to specify it in
> enough detail to be worthy of putting it in a spec) is no fun.
> 
> In the absence of a working solution, the scenarios you mention are indeed
> effectively "inevitable". In general we try to avoid them.
> 
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> 
>

Received on Friday, 8 April 2005 13:49:52 UTC