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

It's nice to see the "!required" syntax come up again.

@Laurens: The fundamental problem with any kind of "required
property/selector/rule" syntax in the spec is that the user agent must
be honest about its implementation. The syntax works fine for new and
unheard of properties, since a user agent wont have any recognition of
them to lie about. The problem will always be buggy implementations of
known properties - just as it is now.

The way I see it (and I think expressed at the time of the discussion
of the linked post) was that any UA which incorrectly matches
!required on a buggy property, that match is also a bug. There's
nothing which can be done to avoid that happening in lazy
implementations, sadly. I don't think that disrespect for "!required"
is a problem any worse than what we have now without "!required",
though.

I think that this kind of syntax is the best we can get. I also think
that it's far preferable to some kind of blanket CSS3 property suffix,
which does not offer any flexibility to handle partial
implementations.

Ben

On Apr 4, 2005 9:56 AM, Laurens Holst <lholst@students.cs.uu.nl> wrote:
> 
> Allan Sandfeld Jensen wrote:
> > I think it would degrade better if we had an all or nothing block, where all
> > the properties would need to be supported for any of them to be applied.
> >
> > .sidenote {
> >   padding: 5px;
> >   { border-radius: 15px; padding: 15px 5px; }
> > }
> 
> I agree that something like this would add *very much* value to CSS.
> Although I would personally prefer not such an additional nesting.
> Perhaps something like .sidenote {{ ... }} would work, it is certainly
> shorter than an @-rule.
> 
> Whether or not browsers are conservative in their claims for support
> does I think not really matter that much... If they claim support,
> surely they at least have some of it (although perhaps buggy), and
> people will in practice always check in multiple browsers. If it doesn't
> work, they will probably add some property which is not supported by a
> specific browser (kinda hackish like * html I agree), this is not very
> nice perhaps but I don't think you can prevent nor rule out the need for
> such practices.
> 
> So, in my opinion, when working on a per-property basis, questions about
> when a browser can support a certain property aren't that important.
> Actually, in this case it seems pretty trivial: as soon as it recognises
> it (and its values), and does something with it, it is supported. Even
> when the implementation is buggy. Anything else won't do.
> 
> So position: fixed in IE would cause the conditional block not to work.
> display: float in IE, even though it is a little buggy sometimes, would
> pass. max-width in IE would I guess only pass when placed on table
> elements, though I could also imagine it would always pass.
> 
> 
> ~Grauw
> 
> --
> Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
> 
> 


-- 
http://www.ben-ward.co.uk

Received on Monday, 4 April 2005 10:50:19 UTC