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

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

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. At the contrary, it's farsighted approach that helps us to progress. Another option is to do nothing, close W3, WHATWG, etc, and be happy with what we currently have -- forever.

Received on Wednesday, 18 January 2012 16:35:06 UTC