Re: if conditions again

Hello,

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 
vendors
 >> 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 
support
 >> 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 
completely
 >> 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 
http://lists.w3.org/Archives/Public/www-style/2010Jul/0349.html

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
http://www.laliluna.de

Received on Monday, 19 July 2010 07:47:53 UTC