W3C home > Mailing lists > Public > www-style@w3.org > July 2010

Re: if conditions again

From: Sebastian Hennebrueder <usenet@laliluna.de>
Date: Mon, 19 Jul 2010 09:47:20 +0200
Message-ID: <4C440308.3020708@laliluna.de>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
CC: www-style list <www-style@w3.org>

Am 18.07.10 22:55, schrieb Aryeh Gregor:
 > On Sat, Jul 17, 2010 at 10:23 AM, Sebastian Hennebrueder
 > <usenet@laliluna.de>  wrote:
 >> In my opinion there is a need for conditions for a number of 
reasons. But I
 >> would not check for individual features but for standards and browsers.
 >> Syntax sample inspired by Zack Weinberg (see 5)
 >> @if ( css-support<= 3){
 >> ....
 >> }
 >> @elsif (css-support = 3){
 >> ....
 >> }
 >> @else{
 >> }
 > This is not even remotely possible.  CSS3 is modular.  Some parts are
 > almost at Recommendation (Selectors), and some parts haven't even been
 > written (look at all the blank or unlinked boxes under "Current" at
 > <http://www.w3.org/Style/CSS/current-work>).  At a minimum, you'd have
 > to test support for each module individually.  But this is still not a
 > good idea, as I explain below.
 >> The reason to check for standards is twofold. The first argument was
 >> provided by Bert Bos (see 3). The intention of a standard should be 
to be
 >> implemented completely. And after years it looks like as the browser 
 >> are competing to reach a higher level of standard conformance.
 > However, standards are usually implemented partially years before
 > they're implemented completely.  Your approach makes it impossible to
 > test for feature support reliably.  For example, every major browser
 > now implements border-radius, but no browser implements all features
 > of CSS Backgrounds and Borders Module Level 3 (I think).  Your
 > proposal doesn't allow authors to test for what they really want to
 > know: will some specific markup work, or not?

 >> The second reason is that checking for individual feature support 
might be
 >> ambiguous, meaning could change over time or an existing feature 
could be
 >> more detailed. It could cause a nightmare of backwards 
compatibility, as we
 >> might have any number of arguments for @if conditions and we need to 
 >> them for all times.
 > This is much *more* true if you draw the line at entire standards.
 > Nobody knows exactly what will go into a standard until it reaches
 > Proposed Recommendation, which requires it to have two interoperable
 > implementations of every feature (thus features get dropped so that
 > stage can be attained).  Features that aren't implemented fast enough
 > get pushed off to the next revision.  So your syntax would be unusable
 > right where it's most needed: at the point when support for the
 > feature is just getting off the ground, and it's not mature and widely
 > implemented enough to be in a Recommendation.
 >> There is currently little motivation to implement CSS standards 
 >> as nobody is using the newest version of standards. If conditions allows
 >> websites to provide CSS in multiple versions including the newest one.
 >> Suddenly the web is a lot more impressive, if you use a modern 
browser which
 >> implements the complete CSS standard.
 > Why *should* there be any motivation to implement standards
 > completely?  If implementers aren't interested in implementing some
 > part of a spec, that part should just be cut.  That's what happens
 > now.

This is leeds to a general question. How do we want browsers deal with 
CSS versions? I thought that it is simpler to create CSS rules, if you 
just need to do think like:

I have CSS support for 2.1 so I can solve my look and feel this way but 
if I have support for CSS 3, then I can solve my problem this way.

If every browser implements another combination of features, then in 
worst case you need to think like:

20 % of my visitors use a browser that supports x, y and z so I can 
create my look and feel with the following CSS rules and another 10 % 
have the combination of y, k and l so I need to use another approach.

Many layout decisions are not based on a single CSS feature but requires 
many to build the complete CSS rules. You need a lot more browser 
specific knowledge to check for a reasonable set of support features.

 > Even if your proposal were implemented, though, the motivations will
 > be exactly backwards from what you want, rendering the feature
 > useless:
 > 1) Authors are motivated not to rely on your conditionals, because
 > they mean users won't be able to view their enhanced content even if
 > their browser supports the specific features they use.  For example,
 > if an author uses border-radius, they would *not* want it to only
 > display for browsers that completely implement Borders and Backgrounds
 > 3.  They would want it to display in every capable browser, so as many
 > users as possible get the latest features.

The argument depends a lot on how browsers continue to implement 
features. If they continue to implement standards partly then you are 
right. But as pointed out here 

if we can motivate browser vendors to implement CSS versions completely, 
then my assumption is correct. It might be a question about the general 
strategy. Do we go for very big CSS releases which takes a long time to 
be created and even longer time to be implemented or better smaller 
releases which are implemented completely in short time.

 > 2) If authors did widely use the conditionals for some reason,
 > implementers would be motivated to do a half-baked implementation of
 > marginal features so they could get all the popular features working
 > in the face of conditionals.  Or they might simply lie and return true
 > before they implemented everything fully.

This is a risk. I fully agree here.

Best Regards / Viele Grüße

Sebastian Hennebrueder
Software Developer and Trainer for Hibernate / Java Persistence
Received on Monday, 19 July 2010 07:47:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:37 UTC