Re: CSS Classes Custom - by Leonardo Lima

Hi François.
> we usually don't send emails with formatting to this mailing list
Moreover, we try to reply inline and not at the top of the mail
Yes, it's quite natural. Can I use *this syntax* in order to highlight
parts of sentences? :)

> we try to reply inline and not at the top of the mail
This is good too. I usually see it done in HTML lists too.

> The question we ask is whether we should support it and how, as doing
things live in a browser has constraints
That it is technically available on CSS processing is a good information on
its own. The question whether it should be supported, well, it depends.
This kind of proposal allows a faster composition of stylesheets in a
static scenario, but it shouldn't be that difficult as it only requires a
direct reference to other blocks of instructions.

>  see http://tabatkins.github.io/specs/css-extend-rule/. Would this
proposal solve your needs?
Actually this is what I was looking for, and I guess the original proposer
can appreciate it too. I only have 2 issues:

 1. @extend : given what follows (pseudo-classes), I would suggest it to be
dropped altogether. It only creates issues about specificity.
See:

#error {
  color: red;
  border: thick dotted red;
}

.serious-error {
  @extend #error;
  font-weight: bold;
  border-style: dashed;
}

@extend extends a class-based ruleset using an id-based ruleset. Probably
in a scenario like the one above the specific rules in .serious-error are
meant to overwrite incorporated rules, but this is not clear given the
selectors' specificity.

It would be equivalent to writing

%error {
  color: red;
  border: thick dotted red;
}

#error {
  @extend %error
}

.serious-error {
  @extend %error;
  font-weight: bold;
  border-style: dashed;
}

And in this case the double feature could be solved by using a single
"token" (say, (%error)).

 2. The draft you linked states (with an issue tracked shortly after) that
placeholder selectors should have a specificity (which can be class-like or
below). I'd suggest them to have no specificity at all, and instead to
inherit the specificity level of the block they are called in. This way
they could be overwritten as usual (last wins over first). This could
create readability issues if a placeholder is called below current rules,
and therefore it should be mentioned that placeholder calls must always be
the first rule in the block, before actual rules, or they're ignored.

Could this be useful to improve CSS Extend Rule?





2015-04-08 21:12 GMT+02:00 François REMY <francois.remy.dev@outlook.com>:

> Hi Leonardo Lima, Andrea Rendine,
>
> Thanks for taking the time to reach this place :-)
>
> Before moving to the topic you're the most interested in: Just to let you
> know, we usually don't send emails with formatting to this mailing list, to
> decrease mail traffic and make archiving easier. Moreover, we try to reply
> inline and not at the top of the mail. The reason for this choice is that
> it allows people to read one mail and have comments following a logical
> order, like I've done in this email (except this part which isn't a reply
> to your concerns).
>
> > Andrea Rendine [mailto:master.skywalker.88@gmail.com]
> > Hi everybody.
> > I hope this proposal can be technically achievable.
>
> It is, since as you note preprocessors like LESS can already achieve this.
> The question we ask is whether we should support it and how, as doing
> things live in a browser has constraints which you don't have when working
> statically. We also try to make the features we add to CSS take advantage
> of the runtime nature of the operation, so that it's not only a slower
> alternative to a preprocessor, but brings useful additions, too.
>
> > Has there been any similar proposal in the past?
>
> Yes, see http://tabatkins.github.io/specs/css-extend-rule/. Would this
> proposal solve your needs? What's your opinion on it?
>
> Now, as you guess, things which can be improved in CSS are many, and
> comments like yours help prioritize one features against another, while
> developer feedback on www-style isn't the only thing browser vendors take
> in consideration when prioritizing features, of course.
>
>
>
> > Leonardo Lima <leonardo403@gmail.com>:
> >
> > Hi,
> >
> > After that i see css custom properties , think that if creating
> > Class custom for CSS can help us. Nowadays we have that
> > install preprocessor CSS to and using this preprocessor CSS
> > can using variables.
> >
> > I think using (classes custom) can we have an default of
> > ("mixins") a bunch of properties from one rule-set into
> > another rule-set.
> >
> > With this rule dont need use more preprocessor CSS.
> > Now lets change how make CSS variables, see example below:
> >
> > :root{
> > /*create class*/
> > --btn-default{
> >     width:50px;
> >     height:30px;
> >     font-size:15px;
> >     font-weight:bold;
> >     }
> > }
> > .btn-confirm{
> >     class(--btn-default);/*call class*/
> >     color:green;
> > }
>
> (Previous comments also apply here)
>
> I'm not sure I fully understood your thought. Do you propose that we allow
> things like this:
>
> html {
>     --quote: {
>          color: blue; font-size: 150%; font-weight: bold;
>     }
> }
>
> html section {
>     --quote: {
>         color: royalblue; font-size: 125%; font-weight: bold;
>     }
> }
>
> blockquote, q, span.inline-quote {
>     @imports --quote;
> }
>
> Or do you suggest something that would just be like you can do in a
> LESS/SASS preprocessor today?
>
> Best regards,
> François
>