RE: @import -- allow at any place in stylesheet.

[Marat Tanalin:]
> 
> 18.01.2012, 20:02, "Sylvain Galineau" <sylvaing@microsoft.com>:
> > [Marat Tanalin:]
> >
> >>  18.01.2012, 03:59, "Sylvain Galineau" <sylvaing@microsoft.com>:
> >>>  [Marat Tanalin:]
> >>>>   17.01.2012, 12:18, "David Woolley" <forums@david-woolley.me.uk>:
> >>>>>   Marat Tanalin | tanalin.com wrote:
> >>>>>>    Hello. It makes sense to allow @import at any place in CSS
> >>  stylesheet.
> >>>>>   Regardless of any reasons for the original decision, this sort
> >>>>> of
> >>>>>   change is extremely likely to produce style sheets that do not
> >>>>>  degrade
> >>>>>   gracefully on older browsers (some of which may be fixed in
> >>>>>  silicon),
> >>>>>   so it would not be safe to use on the public internet for about
> >>>>> a
> >>>>>   decade after introduction.
> >>>>>
> >>>>>   --
> >>>>>   David Woolley
> >>>>>   Emails are not formal business letters, whatever businesses may
> want.
> >>>>>   RFC1855 says there should be an address here, but, in a world of
> >>>>>  spam,
> >>>>>   that is no longer good advice, as archive address hiding may not
> work.
> >>>>   This is obvious, and such comments are completely useless here.
> >>>  No, this is not a 'useless' comment. CSS must allow older parsers
> >>> to
> >>>  ignore old features in such a way that you can add new features in
> >>>  your existing stylesheet without breaking your site in older browsers.
> >>>  So no, we do not have the luxury of ignoring the past and doing
> >>>  whatever we want to the syntax.
> >>  @import between and after rules is successfully ignored by all
> >> browsers
> >>  including even IE6, and rest part of stylesheet is successfully
> >> parsed and
> >>  applied. So your current note is apparently purely theoretical
> >> (though
> >>  generally somewhat reasonable).
> >
> > You made a general comment about a type of comment being 'useless' and
> > implied that the design of future features should not care about
> > existing browsers. The latter is absolutely untrue and not at all
> > theoretical. That was the context of my response.
> 
> In case of it was not clear enough yet: my goal is not to find a solution
> for a specific task. Instead, my goal is to improve CSS itself. Saying
> that a feature is currently unsupported is incredibly pointless since
> (surprise!) I know that. 

You mean like saying you're on www-style to improve CSS? :) That is not 
in fact the nature of the comment that was made to you. David pointed
out that breaking syntactical changes are always a concern for CSS and
that is absolutely correct.

>The feature is unsupported, and that's exactly
> why I propose to add this to spec (which eventually means it will be
> implemented in browsers). If it would be supported currently, then I would
> not make the proposal to add it to spec, since, well, it's already
> supported.

If you can repeatedly state the blindingly obvious, why is it inappropriate
for others to do so?

 
> As for the paradigm "the sooner we add a feature, the sooner we'll be able
> to use it". Let's assume that we've introduced a feature that (edge case)
> even breaks current browsers (for @import it's not a case). Several years
> later, old browsers are gone, and we are finally able to use the feature
> that we added to spec _in advance_. What is bad here? Nothing. 

What is bad right now is that you persist in not listening. Nobody cares
about the distant ideal future where every browser in existence supports
the feature. Of course there is no issue at that point in time! The concern
is what happens between now and then (which can be a period of several years). 
Adding a new feature in your stylesheet for those browsers that support it 
MUST NOT cause existing browsers to fail processing the parts of the stylesheet
they can process e.g. cause them to ignore everything in the stylesheet that comes 
after the new feature declaration, or generally ignore things that they should 
otherwise be able to process. That is a fundamental explicit design principle of CSS [1]:

# Forward and backward compatibility. CSS 2.1 user agents will be able to understand 
# CSS1 style sheets. CSS1 user agents will be able to read CSS 2.1 style sheets and 
# discard parts they do not understand.

http://www.w3.org/TR/CSS21/intro.html

Any change that violates this principle is considered bad. Breaking compatibility is
generally considered bad. Telling existing users 'tough luck, buddy; go upgrade' when
things that worked fine stop doing so courtesy of a feature that only work in one other 
browser is bad. And that is not going to change. If you don't understand why, it would 
still be a more productive use of your time to accept it as a constraint and move on.

> At the
> contrary, it's farsighted approach that helps us to progress. 

There is very little that is farsighted about breaking compatibility. If every new
feature breaks stylesheets in unpredictable ways, who's going to use new features? 

>Another
> option is to do nothing, close W3, WHATWG, etc, and be happy with what we
> currently have -- forever.

You will not get your way in any group by implying the alternative is to stop all 
standardization work. (Go ahead, try that on WHATWG...) Asserting your idea constitutes
progress and belittling others' feedback is not going to do it either. Stick to the issue, 
please.

Received on Wednesday, 18 January 2012 17:40:28 UTC