Re: [CSS] Rules for parsing and compatibility

> [Original Message]
> From: Ian Hickson <ian@hixie.ch>
> To: Ernest Cline <ernestcline@mindspring.com>
>
> On Thu, 1 Jan 2004, Ernest Cline wrote:
> >>>
> >>> It certainly is a lot better than the current practice of using the
> >>> quirks of existing UA's to try to select what CSS gets used where.
> >>
> >> I agree. IMHO the best solution is to simply write to the specs and if
it
> >> breaks in a browser somewhere, tough. That browser should be fixed, not
> >> the site.
> >
> > I was not referring the practice of using CSS hacks to get around
> > buggy CSS implementations but rather the practice of using CSS hacks
> > to determine what CSS properties and values  a UA supports.
>
> Oh. I was not aware anybody did that. Fair enough.
>
>
> > Let me repeat myself, I do not see @property being at all useful for
> > detecting or avoiding buggy implementations, and that is not what it
> > is intended for.
>
> In that case I'm somewhat confused... can you give an actual use case?

Here's one using CSS3 Text

blockquote {
text-indent:-0.6em
}
@property text-hanging {
blockquote {
text-hanging:start;
text-indent:0;
}
}

So if the 'text-hanging' of CSS3 is not supported, the CSS tries
to simulate it by providing a negative value for 'text-indent',
however if the 'text-hanging property is there, then the author
wants text-indent returned to normal.

Here's a CSS 2 only example, which I have used CSS hacks to
deal with. (in this case to deal with an HTML bug for IE so it
may fall under your buggy behavior clause, but in this case
one can argue that IE's buggy handling of the <q> element
is due to its non-support of the quotes property in CSS.)

@property quotes{
* {quotes: "\201C" "\201D" "\2018" "\2019" }
q .qm {display: none}
q:before { content: open-quote }
q:after { content: close-quote }
}

<q><span class="qm">&8220;</span>The quote mark is
a curious thing.<span class="qm">&8221;</span></q>


> Most of the complaints I've heard focus on trying to hide properties from
> UAs because those UAs handle said properties incorrectly, not on trying
> to hide properties from UAs that don't support them.

Not too surprising. For the CSS properties that are currently implemented
by the major UA's there isn't much need for @property as one can seldom
attempt to simulate a non-implemented property via other properties.
Also non-support of CSS 2 properties rarely would cause one to wish
to set another property different even when simulation is not the goal
since most of the CSS 2 properties rarely interact with others.

However as the new CSS 3 properties become deployed there is more
opportunity for simulation, and more chances that even if simulation
is not desired, that the desired values of some properties may vary
depending upon what other properties and values are available.

Received on Thursday, 1 January 2004 19:51:41 UTC