Re: if conditions again

>
> 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.
>

Sebastian, rather than using different "approaches" for browsers with
significantly different capabilities you could create the basic layout using
"straightforward" CSS. Once you have a layout that displays adequately in
the full spectrum of browsers you can layer on additional styling which may
not be supported by all browsers.

Using bleeding edge CSS in any layout-related capacity is probably not a
good idea. You can go to town with shadows and reflections and whatnot,
though. :)

David


On 19 July 2010 19:47, Sebastian Hennebrueder <usenet@laliluna.de> wrote:

> 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
>
>
>
>