Re: Extending Class Proposal

On Wed, Jan 30, 2013 at 11:04 PM, Philip Walton <philip@philipwalton.com> wrote:
> I'm not tied to any particular syntax, I'm suggesting this as a solution to
> a problem. Perhaps if I define the problem more clearly then the discussion
> can be centered around whether everyone agrees on the problem, and whether a
> particular solution addresses the problem in its entirety. So far it seems
> the discussion is primarily about syntax, which is fine, but arguing syntax
> isn't constructive if everyone isn't on the same page regarding the goals of
> the proposal.
>
> I see the problem as threefold. The first part is the more obvious (one that
> Sass's @extend mostly addresses), and that is the ability to declare that a
> particular selector should include all the styles of another selector
> (usually a class selector). This means authors won't have to put base
> classes in the HTML, saving time and making maintenance easier.
>
> The second part of the problem is not addressed by Sass at all. It's the
> ability to use the declared inheritance in JavaScript. In classical OOP it's
> very common to inspect a class to determine its inheritance tree (what
> classes it extends from), and I believe CSS components should be the same.
> If I'm extending .button with .button-primary, I want to be able to use
> JavaScript to determine that. I want to be able to select all elements on
> the page that extend a certain base class.

That has nothing to do with SASS's syntax, and everything to do with
the fact that SASS is a preprocessor, not a part of the browser.

In SASS's @extend existed in the browser, it would apply to all
selector matching, including that done via JS.


> The last part of the problem is what to do about specificity. Currently,
> Sass's grammar can lead to ambiguity when dealing with selectors of
> differing specificity values. Consider the following example:
>
> .button {
>   border: thin solid black;
>   background-color: gray;
> }
> a {
>   @extend .button;
>   background-color: blue;
> }
>
> One way to deal with this is a blanket statement that less specific
> selectors cannot extend more specific selectors. That's fine if that's part
> of the rules, but I personally think a solution without these specificity
> concerns would be best.
>
> That's why, after a great deal of thought and playing around with different
> variations, I think a new simple selector would be the best solution. I
> suggested the abstract class selector which would use the percent (%)
> prefix. An abstract class selector would match any element that contains a
> class that extends the abstract class selector.

I don't think the specificity issue is that bad, nor is it unique -
it's basically identical to the problem we have with :matches(), where
we want the specificity to depend on which branch of the function was
used to match.

~TJ

Received on Thursday, 31 January 2013 18:28:48 UTC