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

19.01.2012, 17:20, "François REMY" <fremycompany_pub@yahoo.fr>:
> (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

It's already implemented, just artificially limited. It's even probable that it could be "implemented" by actually just unlocking that artificial limitation, and maybe result in even _simplifying_ implementations' codepaths.

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

Not all improvements in the world has significant results. There are small subtle improvements, and the fact that an improvement is small cannot alone be main reason to abandon it.

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

If it's considered so by those responsible for exactly speccing, then we could stop arguing/discussing right here.

We should keep in mind though, that @imports do (and definitely will continue) have its applicability as a stylesheet-management instrument both on client side (in schemes where one CSS-file is included in HTML document, and other CSS-files are imported to main CSS-file via multiple consequent @imports) and server-side (SASS, etc.) as well as in client-side implementations of alternative stylesheet syntaxes (there are sites that rely entirely on JS implementations of things like SASS). So it's not just about backward compatibility, it's widely used right now, and it's unlikely to change in the foreseeable future.

> - allowing @import anywhere will increase computation time (TCP connection
> left open longer

Parsing itself is quite fast, so there shouldn't be tangible performance difference between @import at the beginning of CSS-file and at the end of CSS-file.

> more complex parser...)

Usability for authors is more important than implementation complexity (though for @imports in particular, it's unlikely that parsing would get appreciably more complicated).

> - allowing @import anywhere does not allow the designer to solve *new*
> layout problems nor it avoids them a huge coding pain.

See above (beginning from "There are small subtle improvements").

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

I believe that browsers internally normalize @imports by virtual inserting imported-stylesheet contents in place of @import rule itself, so it's unlikely that any major changes in UA's code would be actually required. (I may be wrong here though. It would be nice to hear a comment from browser implementors. Boris?)

> 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,
> François

François, is it of your responsibility to make such decisions?

If yes, it's OK; I've injected the idea, it has been analyzed, and therefore my mission as for the subject is mainly accomplished.

Thanks.

>
> -----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 14:46:21 UTC