Further Notes On Extends

[lukeapage]

trafficstars

things to do, add etc. From the extend documentation

I wanted to leave the extend documentation releasable, however the following are notes that I removed which it may make sense to add later once they have been expanded upon.

Most of this is from @jonschlinkert

Examples for when "extend" will be valuable, and when it won't

The purpose of this section is to better understand how the :extend feature ought be used, thinking in terms of best practices, in order to help prioritize development decisions, and to qualify or disqualify feature requests related to this feature.

Repetitious Code

The :extend feature seems to hold the most promise as a device for:

1. Selector Inheritance: which means you can add the styles of one selector to other selectors, but without having to manually hunt down and directly edit each of the selectors you wish to extend. Clearly, this is advantageous at the time of need, but it's also helpful with code maintenance. 2.

:extend directive to a selector (or ruleset of a selector) allows you to add the styles of that selector to any other selectors,

.widget {
  &:extend(ul li, .blob, .kitchensink, .sanity, .willtolive, .questions, .etc);
  background: blue;
}

.widget {
  &:extend(.answers, .blob, .kitchensink, .sanity, .willtolive, .nav, .navbar, .etc);
  background: blue;
}

Don't understand: Notice that the Extending selector was grouped before the Extended selector. This was chosen not for stylistic reasons, but to be behaviorally consistent with the expected order of inherited declarations within the block.

TODOs: Specificity Order of Inherited Declarations Mixins <-- just do later?

Selectors Type Selectors Simple Selectors Combinators Pseudo-Elements

Extends with Mixins

TODO: that it is planned

.clearfix():extend() {
  // declarations
}

Extends, Mixins, "Empty" Mixins, and Placeholders

TODO We want :extend to make our lives easier by DRYing up our stylesheets, but only when :extend cannot "pierce the context barrier" of the selector you wish to extend. So within the same context the goal is to prevent order to prevent :extend from poluting styles

[seven-phases-max]

Don't understand: Notice that the Extending selector was grouped before the Extended selector. ...

I guess this means something like:

.questions:extend(.answers) {
    background: blue;
}

.answers {
    color: red;
}

with result:

.questions {
  background: blue;
}
.answers,
.questions {
  color: red;
}

I.e. .answers goes first in the list even if defined after .questions. (Probably it's too minor stuff to be mentioned at all)

[lukeapage]

Except its reverse.. the extending selector goes last in the list? (I guess depending on the definition of extending selector). Also the xamples that were around this were the wrong way round too. I think I worked it into some of the sentences anyway that it is added on to the end of the selector list.

[jonschlinkert]

I did all of the initial docs for extends while we were still discussing how you were going to implement it, so I imagine a lot of it was wrong

[seven-phases-max]

Actually those "extending" and "extended" labels are not so easy to define unambiguously. Hence sometimes we can even confuse ourselves. For example a:extend(b) looks like a extends b. So we may say that

a is the "extending" and b is the "extended".

However, since it's a who inherites b's properties, it is also true that

a is extended by b's properties

so it's

a is extended by b

so it's

a is the "extended" and b is the "extending"

:)

It all depends on how exactly one defines "extend" (as English word not as LESS keyword) in context of CSS classes... and the flip point is very thin and subtle... (Luckily examples make things unambiguous).

[lukeapage]

Cool Jon, thanks, makes sense now & feel free to critique or add to the extend documentation