Re: if conditions again

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.

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.

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.

> I believe that this cannot work. Either you are always guaranty
> compatibility then you cannot innovate or need to build weird constructs to
> add new features you didn't preview at the beginning. In that case the
> quality of your product degrade and you loose your users. The completely
> opposite approach allows you to break compatibility all the time. In that
> case you will loose your users as well.

It's actually worked very well for CSS, overall.  It's limited the
language's ability to change, but it's meant that new features can
mostly be very easily deployed.

Received on Sunday, 18 July 2010 20:55:37 UTC