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

Re: Extending Class Proposal

From: Philip Walton <philip@philipwalton.com>
Date: Wed, 30 Jan 2013 23:04:31 -0800
Message-ID: <CAGRhNhUc015a58wRU5pK83uUZ8ii0+6zSQ2NKpBqU53rk7NtZw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>
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.

Currently I can do: document.querySelectorAll(".button") but this will not
match any elements that only contain extended classes, which (at least for
me) is very disappointing. As a result I always just put the base classes
in the HTML.

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.

An abstract class selector solves all three of the concerns I presented. It
allows for declaring extensions. It could be used in a querySelectorAll
function. And it would have its own specificity value, so there would be no
ambiguity (it would be less than a class selector, but greater than a type
selector).

Like I already said, I'm not tied to any particular syntax to declare the
inheritance, but I do think it's very important that whatever is decided is
accessible to JavaScript. Losing that ability for the sake of a prettier
syntax would be a real shame in my opinion.



On Wed, Jan 30, 2013 at 10:05 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Thu, Jan 17, 2013 at 3:56 PM, Philip Walton <philip@philipwalton.com>
> wrote:
> > I recently posted a proposal on my website for how I think CSS
> could/should
> > handle the concept of extending a base class:
> > http://philipwalton.com/articles/the-future-of-oocss-a-proposal/
> >
> > Tab sent me a link to this discussion from August started by David Baron,
> > and my proposal basically aligns with method (b) that he suggests:
> > http://lists.w3.org/Archives/Public/www-style/2012Aug/0363.html
> >
> > I've spent a lot of time thinking about this problem and trying to make
> it
> > work with in Sass; I've firmly come to the conclusion that preprocessors
> > can't handle this all by themselves. The article goes into a lot of
> detail
> > why.
> >
> > Anyway, I'd love to be part of any discussion on this topic, which is why
> > I'm sending this to the list.
> >
> > TL;DR for the article:
> >
> > * Create a new simple selector called the abstract class selector, which
> > uses the % sign (Ex: %base-widget { } ). The abstract class selector
> would
> > match any element with a class that extends from it.
> >
> > * Create a new @ rule called @extends to define the inheritance (Ex:
> @extend
> > .widget < %base-widget; )
> >
> > The primary reason I think a new simple selector should be created is so
> you
> > can target these elements via JavaScript without having to put the
> classes
> > in the markup.
> >
> > document.querySelectorAll("#sidebar %base-widget");
> >
> > It would also allow for extending base classes within media queries,
> which
> > currently Sass can't do.
>
> While I *really* want this general ability, I don't like this
> particular syntax for it, for the reasons I explain in
> <http://lists.w3.org/Archives/Public/www-style/2012Aug/0438.html> - I
> think it's somewhat more verbose and less clear than SASS's syntax,
> and requires substantially more work to refactor when you decide to
> start using it for a particular class.
>
> ~TJ
>
Received on Thursday, 31 January 2013 07:04:59 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:05 GMT