Re: CSS Classes Custom - by Leonardo Lima

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

I skipped this part.
In the original proposal made by Leonardo I saw no mention to nested
blocks. Nor would I have loved to see, actually.
I think that nested stuff should only appear in @media (it's even too much)
and I proposed something I'd like to receive feedback for, CSS scopes: i.e.
let's confine variables inside @media blocks, so that they don't escape and
force re-evaluation of them. That was a side note, though.

However, defining nested blocks is useless. An author could use a
recyclable ruleset when s/he wants rules to be recycled as they are, inside
multiple rulesets, not because s/he wants them to change according to
specific contexts. However, the same result could be achieved using
variables inside placeholder blocks, and then letting them take the value
specified in the block they're called in. This of course means that
variables definition could precede placeholder calls. Like this:

%error {
  color: red;
  border-width: thick;
  border-style: var(--error_border);
  border-color: red;
}

#error {
  --error_border: dotted;
  (%error)
}

.serious-error {
  --error_border: dashed;
  (%error)
  font-weight: bold;
}

Here I also used a possible short syntax to condense @extend %error, were
@extend dropped in favor of simply using placeholder blocks.



2015-04-08 21:52 GMT+02:00 Andrea Rendine <master.skywalker.88@gmail.com>:

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