W3C home > Mailing lists > Public > www-style@w3.org > September 2005

Re: Block-based parsing; allow lies

From: Orion Adrian <orion.adrian@gmail.com>
Date: Wed, 14 Sep 2005 15:52:54 -0400
Message-ID: <abd6c8010509141252d3c62d1@mail.gmail.com>
To: www-style@w3.org

> **Scenario A - we don't have "required":
> h1 {color: yellow; text-shadow: olive 0.3em 0.3em 3px;}
> 
> h1 text is displayed in yellow, with drop shadow supported or not.
> 
> **Scenario B - we have "required"
> h1 {color: green}
> @required {h1 {color:yellow; text-shadow:olive 0.3em 0.3em 3px;}}
> 
> Scenario option 1) Browser cheated:
>     h1 text is displayed in yellow. What happened? Anything different from
> scenario A?
> Scenario option 2) Browser does not cheat and has no support for shadow
>     h1 text is displayed in green, which is more optimal.
> Scenario option 3) Browser is old.
>     h1 text is displayed in green, which is more optimal.
> Scenario option 4) Browser has support for shadow:
>     h1 text is displayed in yellow with supporting shadow for even more
> readibility.
> 
> So how would @require hurt us more than the current situation does?

Simple examples are a nice way of showing a concept, but they often
obscure reality a bit, eh?

Color probably isn't what we're talking about here; we're talking
about layout. Margin's, absolute versus fixed and it's not a single
line we're duplicating, but potentially dozens of properties across a
wide array of selectors. And now we're talking about nested fallback
solutions potentially or just defaulting to content that isn't layed
out by CSS.

selector {
   property: rule; /* my more ambitious position: absolute + relative layout */
   property: rule;
   property: rule;
   property: rule;
}

selector {
   property: rule;
   property: rule;
}

selector {
   property: rule;
   property: rule;
   property: rule;
}

@required {

selector {
   property: rule; /* this might be display: static or it might use floats */
   property: rule;
   property: rule;
   property: rule;
}

selector {
   property: rule;
   property: rule;
}

selector {
   property: rule;
   property: rule;
   property: rule;
}

}

At what level do we simply say no? To get the benefit we actually care
about, we're now writing multiple types of layouts.

Personally I'm all for CSS on the client, but not the server since
that's the only place things like this can really be known. And it's
future proof to boot.

-- 

Orion Adrian
Received on Wednesday, 14 September 2005 19:53:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:40 GMT