W3C home > Mailing lists > Public > www-style@w3.org > January 2012

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

From: François REMY <fremycompany_pub@yahoo.fr>
Date: Thu, 19 Jan 2012 14:20:10 +0100
Message-ID: <6F45399D72474B919E6D14CC684352F3@FREMY2>
To: "Marat Tanalin | tanalin.com" <mtanalin@yandex.ru>, "Sylvain Galineau" <sylvaing@microsoft.com>
Cc: <www-style@w3.org>
(Side note: be able to do something using different ways is not always good: 
SQL has been critized for its lack of orthogonality)

What we are trying to say is that it's not worth taking everyone' time (and 
money) to implement that feature in every UA out in the world if it doens't 
solve a case that (1) would otherwhise be unsolved, (2) would otherwhise 
take more time to compute or (3) would otherwhise take significatively more 
time for the website designer to write.

At the current state of the discussion, it seems that:

- @import was a mistake and is only still there for compatibility reason. 
<link /> should be used instead in most cases.
- allowing @import anywhere will increase computation time (TCP connection 
left open longer, more complex parser...)
- allowing @import anywhere does not allow the designer to solve *new* 
layout problems nor it avoids them a huge coding pain.

- allowing @import anywhere could require major changes in UA' code since it 
could break their rule matching algorithm, where a single CSS file is either 
BEFORE or AFTER another css file in matching order, never IN BETWEEN, which 
means you can hold a simple list of CSS files, and not a tree.

Solving an inconsistency just for the sake of solving an inconsistency is 
not an option and will never be an option. If you don't have anything else 
to add about this thread (that we didn't hear before), I think you can 
consider the issue has been resolved as WON'T FIX.

Best regards,

-----Message d'origine----- 
From: Marat Tanalin | tanalin.com
Sent: Thursday, January 19, 2012 1:48 PM
To: Sylvain Galineau
Cc: www-style@w3.org
Subject: Re: @import -- allow at any place in stylesheet.

19.01.2012, 04:50, "Sylvain Galineau" <sylvaing@microsoft.com>:
> [Marat Tanalin:]
>>  18.01.2012, 21:58, "Sylvain Galineau" <sylvaing@microsoft.com>:
>>>  [Marat Tanalin:]
>>>>   18.01.2012, 21:16, "Sylvain Galineau" <sylvaing@microsoft.com>:
>>>>>   [Marat Tanalin:]
>>>>>>    18.01.2012, 20:48, "Ian Hickson" <ian@hixie.ch>:
>>>>>>>    On Wed, 18 Jan 2012, Marat Tanalin | tanalin.com wrote:
>>>>>>>>     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.
>>>>>>>    Changes that aren't solutions to specific tasks aren't
>>  improvements.
>>>>>>    Consider increased flexibility as a task if you want.
>>>>>   It's not. What the increased flexibility is used for would be the
>>  task.
>>>>   Insreased flexibity, oddly to say, allows to increase usability,
>>>>   productivity, and maintainability.
>>>  Then provide one or more real-world example demonstrating all this
>>>  will happen and explain why. General assertions are insufficient.
>>  See http://lists.w3.org/Archives/Public/www-style/2012Jan/0760.html
> That is not a use-case. A use-case states a problem and explains how
> the proposal leads to a better solution.
> That post simply says "If I have this feature I can X this way". It's
> totally unclear why doing this way is superior or beneficial.

Do you understand what is flexibility? It's ability to do same thing 
different ways. 
Received on Thursday, 19 January 2012 13:20:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:10 UTC