« Viewing IP addresses and banning
Getting ready for an alpha release: WeCSS/Wess improvements
Current status of the beta? »

Nao

  • Dadman with a boy
  • Posts: 16,082
Getting ready for an alpha release: WeCSS/Wess improvements
« on September 8th, 2012, 11:33 AM »
So... I slept on it, and it's even worse now :)

I think WeCSS is getting a bit 'old' by my standards, and I should remove some of the dust. And maybe rename it to 'Wess', which I've been considering for a while...

- First of all, because I support 'base:' and added the 'extends' keyword to make it more objecty, I think it's only fair that I add a 'mixes' keyword that would do the exact same thing as 'mixin:'.

- Additionally, maybe mixins should be defined the same way as bases, that is, as regular selectors... (Or, at least, to enable virtuals to be used as mixins). To get the regular mixin behavior, we'd just need to define them as virtuals. The good thing is that it would mean .inline-block can be used both as a base and a mixin. Can you hear "solves the media query problem" already? Yes I'm sure you can...

- I went to check out LESS and SASS (my main 'competition' if I may say), and LESS has done a lot of progress in a year (I should have kept up with their new stuff really...). They now both support mixin parameters, and it's indeed something that could happen to be useful in WeCSS as well. I'm just trying to figure out the proper way of writing it if I'm going to use selectors for mixin declarations... Something like:

Code: [Select]
.my_mixin virtual params $col = #fff, $param2...
color: $col
box-shadow: ifnull($param2, none)

- As seen just above, there's already an undocumented feature in WeCSS which I like a lot:

background-color: ifnull($custom_color, #fff)

Meaning, "if $custom_color is set, then set background-color to it, otherwise set it to #fff".
Okay, so should this remain like this? Or would it feel more natural to use @ifnull instead of ifnull?

- Same for conditionals...

Code: [Select]
.class
color: #fff
@if ie6, ie7, firefox[-3.7]
background: url(border)
@else
border-radius: 5px
font-size: 1em

Should these keywords use @? Should whatever follows if be between brackets? if(ie) or if (ie), like in JavaScript or PHP... But maybe skin authors aren't too versed into these languages, I don't know.
Should we use @endif, too, or would indenting be enough to say "it's the end of the argument list"...? (I haven't tested for now whether or not it can allow for nested selectors in such a situation...)
Should we allow for single-line if statements?

Code: [Select]
.class
@if (ie[-8]) background-color: #fff @else background-color: rgba(255,255,255,.8)

Code: [Select]
.class
background-color: @if (ie[-8]) #fff @else rgba(255,255,255,.8)

(In which case, an @endif would mean end of statement, while a missing @endif would mean the statement ends at the end of the line.... But again, maybe it's too complicated?)

Or maybe, similarly to ifnull/@ifnull...

Code: [Select]
.class
background-color: @if (ie[-8], #fff, rgba(255,255,255,.8))

Just a few ideas like that. May add some in the future... Would like opinions from everyone interested in CSS in general, thank you :)
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #1, on September 9th, 2012, 12:04 AM »
I know it's a lot of questions (that's what life is about :P), but you don't have to answer them all ;)
Just gimme your feelings about whatever made you feel something!

Hopefully getting some opinions before I actually start work on implementing these :^^;:
Posted: September 8th, 2012, 05:56 PM

A bit
Of a
Desperate
Bump.
Sadness ensues.

godboko71

  • Fence accomplished!
  • Hello
  • Posts: 361
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #2, on September 9th, 2012, 12:37 AM »
Quote from Nao on September 9th, 2012, 12:04 AM
I know it's a lot of questions (that's what life is about :P), but you don't have to answer them all ;)
Just gimme your feelings about whatever made you feel something!

Hopefully getting some opinions before I actually start work on implementing these :^^;:
Posted: September 8th, 2012, 05:56 PM

A bit
Of a
Desperate
Bump.
Sadness ensues.
Head hurts to much to reply it isn't personal light makes me want to guege my eyes out.
Thank you,
Boko

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #3, on September 9th, 2012, 12:51 AM »
Quote
Can you hear "solves the media query problem" already? Yes I'm sure you can...
Sounds good to me.
Quote
Meaning, "if $custom_color is set, then set background-color to it, otherwise set it to #fff".
Okay, so should this remain like this? Or would it feel more natural to use @ifnull instead of ifnull?
No, it shouldn't use @, since other similar constructs in Wess do not, e.g. darken(). If all of them overloaded @, it'd be OK.

* Arantor is somewhat sandbagged from today, having had to get outside on a bus on barely 3 hours sleep, then engage in psychological warfare, before coming home, leaving 20 minutes later to go visit a care home and arrange for my grandmother to be moved on Monday because of the country's social services system's inability to manage resources.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,082

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #5, on September 9th, 2012, 02:40 PM »
@ is for directives like @media - it seems very odd to me to overload that. It sort of threw me when I first encountered LESS on its own when experimenting with Bootstrap, to have everything prefixed with @ throughout the entire source.

Either it needs to be be consistently with @ or consistently without to let @ be left alone as it was for @media type stuff. Unless you have a different symbol in mind that can be consistently used everywhere?

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #6, on September 9th, 2012, 05:00 PM »
I don't know. You tell me.

To me, it doesn't matter that much. @ is to help against mistaking commands for selectors. But @extends doesn't excite me so I decided tht any modifiers would be prefix free. But conditionals? Are they not commands?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #7, on September 9th, 2012, 07:15 PM »
It's more a semantic thing to me personally. LESS uses @ everywhere to indicate mixins, functions and whatnot and that helps differentiate it from CSS. Having the @ will certainly avoid making mistakes between commands and selectors, but it also conflicts with the use of @ for media.

Conditionals are somewhere between commands and modifiers, semantically speaking. But consider something like lighten(value, 10%) - what's different when writing compared to if(ie[-8], #fff, rgba(255,255,255,.8)) ?

You're still expressing an expression in-line. The difference is that you have a three parameter expression rather than a two parameter expression. To me, they're the same thing. It's a bit trickier with the else part, but even then I still think it should do what normal functions do.

I don't really mind either way, just offering up my thoughts on a technical perspective. People coming to Wedge will deal with whatever's there, warts and all.

godboko71

  • Fence accomplished!
  • Hello
  • Posts: 361

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #9, on September 10th, 2012, 11:13 PM »
Quote from Arantor on September 9th, 2012, 07:15 PM
It's more a semantic thing to me personally. LESS uses @ everywhere to indicate mixins, functions and whatnot and that helps differentiate it from CSS. Having the @ will certainly avoid making mistakes between commands and selectors, but it also conflicts with the use of @ for media.
@ is used for conditional commands, as well as directives (@import, @charset...), and a couple of non-specific instructions.
Basically, the thing that connects them all, AFAIK, is that they're at the beginning of a line, rather than lost inside a selector.
So, there's no reason to use @ on 'extends', 'virtual' or 'final', etc.
However, Wedge defines mixins with the simple 'mixin' keyword, instead of '@mixin', which is probably an oversight of mine.
When CSS adds functions that can be used inside a property, they aren't prefixed. 'calc', 'url', and so on.

Now, one might want to keep away from using @ function names when nothing says CSS4 won't implement @if in the future. If this happens, however, there's always time to rename it. In the meantime, I'd like to 'stick' to the CSS standards as much as possible.
Thus, if() should be @if() because it's a conditional command. Even if it can be used inside a property -- but it's really of no concern to us, because it can be used anywhere and is a preprocessor magic replacement, just like $variables are.
Quote
Conditionals are somewhere between commands and modifiers, semantically speaking. But consider something like lighten(value, 10%) - what's different when writing compared to if(ie[-8], #fff, rgba(255,255,255,.8)) ?
As mentioned above -- functions inside properties aren't prefixed in CSS.
Quote
I don't really mind either way, just offering up my thoughts on a technical perspective. People coming to Wedge will deal with whatever's there, warts and all.
Sure.

Well... I'll try to work on that this week.
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #10, on September 11th, 2012, 12:51 AM »
Quote from Arantor on September 9th, 2012, 02:40 PM
Either it needs to be be consistently with @ or consistently without to let @ be left alone as it was for @media type stuff. Unless you have a different symbol in mind that can be consistently used everywhere?
There's ~, by the way... It could be used. It's used by LESS as an escape character. It's hard to write for me, though. On an AZERTY keyboard, it's Alt Gr + number 2 on the keyboard (not the keypad), forcing us Frenchies to actually use both hands to enter the character... I think QWERTY keyboards have it more readily available.
Heck, even @ is Alt Gr + 0 number for us, but at least it's easy to type with a single hand... :)
Posted: September 11th, 2012, 12:46 AM

Oh, and the name Wess... Is that alright for everyone? Or does it sound too much like Wuss?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #11, on September 11th, 2012, 01:34 AM »
Well, ~ is a two key job on most QWERTY keyboards, it's usually shift and something (it varies, on the MacBook layout, it's shift + backtick, others, it's shift plus backslash), but it's still a one-handed job if you're reasonably dexterous.

I don't really mind - aside from not getting involved most of the time with CSS, the fact remains is that my objections are basically whiny and semantic rather than either pragmatic or logical :P

You've been working with this stuff, go with what your gut tells you feels right.

Like me with this bastard quick moderation mess. I've been pretty much rewriting it totally because it just felt so wrong how it was.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #12, on September 11th, 2012, 12:35 PM »Last edited on September 11th, 2012, 02:48 PM
What do you think looks best and/or readable...?

Code: [Select]
$bevel = ", url($images/theme/bevel.png) $button_gradient"
$bevel {ie6,ie7,ie8} = ""
$button_gradient = ", linear-gradient(90deg, rgba(212, 212, 212, .5), rgba(212, 212, 212, 0))"
$button_gradient {ie9} = ""
$max-width = "max-width"
$max-width {ie6} = "width"

Code: [Select]
$bevel = @if (ie6,ie7,ie8) "" @else ", url($images/theme/bevel.png) $button_gradient"
$button_gradient = @if (ie9) "" @else ", linear-gradient(90deg, rgba(212, 212, 212, .5), rgba(212, 212, 212, 0))"
$max-width = @if (ie6) "width" @else "max-width"

I'd say the first one.
So, I've got three possibilities...
- Just get a life and forget the first one,
- Keep support for {browser}, as I'll probably be keeping it in skin.xml as well (I need to think about it),
- Just get a life and forget the first one, really.

What do you think...?

Also:

- I've rewritten ifnull() to @ifnull(), as it's a conditional command. It should now accept spaces before the brackets as well.

- Rewrote {%function%} to use '@dynamic function' instead. (It's the same thing, except that you can actually call multiple parameters now and with a cleaner param syntax, they'll be sent as regular parameters instead of the array crap I was sending.)

- And finally, renamed mixin declarations to @mixin. (Have yet to add support for the 'mixes' keyword.)

I discovered (ah ah, completely forgot about it) that I'd already added support for optional variables in mixins, but I haven't tested them for a long time, so I don't know if it still works, I'll have to try... Problem is, I really, really don't make much use of mixins in Wedge...! Actually, it's only used twice (checkbox-styling and ie-inline-block). And none of them require a variable. I should probably do something about that...
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #13, on September 11th, 2012, 02:53 PM »
I've been breaking my jaws on the regex for @if... Grmpf!!

It's pretty hard to figure out.

- @if can be inline
- @if can be a block, in which case the code to be executed is in a nested block below it...
- @else can be on the same line, or at the same (horizontal) level in a following line <-- this is where it's getting complicated! Especially if I decide to allow for an inline @if followed by an @else statement on the next line...
- no @endif means I have to do a precise calculation of what is inside both @if and @else blocks
- I don't even know if I should allow @if to test more than CSS suffixes... i.e. in a mixin, @if ($param == 0) would be a nice thing to do... But then, how do I differentiate between a browser name and something else? (I mean in regex... and don't tell me "just look for $"...)

Perhaps I should do the parsing with multiple strpos calls. But I'm not sure it's even going to be any easier... At least with regex I can easily keep track of the positioning.

So much fun...
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #14, on September 11th, 2012, 05:23 PM »
It might work better if I used a different command for inline if's, but people might see it as 'odd'...
But if there's a different syntax, then @if could be done with the {browser} syntax easily, without brackets or whatever...

Code: [Select]
@if {ie[7-]}
    rule: property

@if $variable
    rule: property

.class
    rule: @test ({ie6,ie7}, property1, property2)
    rule: @ifthen ($variable == true, property1, property2)

Is that, err... Any good?? Or confusing? What name for the inline version? @ite (if then else)? Is that self-explained or too lame?
Posted: September 11th, 2012, 04:25 PM

Or something like @if agent(ie6,ie7) maybe..? agent() being a function that returns 'true' if the current browser is in the list?
Although it could also be tested for "agent(rtl)" for instance, in which case we'd need a more generic name...
Maybe global(variable) or something?
We could even test for global(index) for instance, to tell whether the current file is executed in the main context, for instance if we're adding some conditional code in common.css or custom.css... Wouldn't it be nice to be able to restrict custom/common code to just one file? :)

Oh... "if is(...)"...? Sounds like a winner to me. Or "if for(...)", but I don't like it as much (the only point is that it's also used in skin.xml...)
Posted: September 11th, 2012, 04:37 PM

(Anyone still reading this topic...? :^^;:)
« Viewing IP addresses and banning
Current status of the beta? »