Wess: the Wedge preprocessor for CSS

Nao

  • Dadman with a boy
  • Posts: 16,079
Wess: the Wedge preprocessor for CSS
« on May 10th, 2011, 07:01 PM »Last edited on October 16th, 2012, 01:00 AM
Feature: Wess (or WESS, or WeCSS, as you like...)
Developer: Nao
Target: themers, modders
Status: 100% (believed to be complete; given its nature, however, new features are being added regularly as needed.)
Comment:

This is one of the features that make me glad I made them, even though it took me many months of work. For the record, back in January 2011, I read an article about Sass, a CSS pre-parser written in Ruby. I already had plans to write something in that style, but they were nowhere near as advanced as their implementation, so I took inspiration and wrote my own PHP version. As a result, it's about 20 times smaller than Sass, and much faster. It's also a bit less elegant (in that it doesn't optimize resulting rules), and stricter in its structure, but I consider this to be a good thing. Finally, Wess also deals with JavaScript and CSS compression, although the line between Class-CSS[1] and Subs-Cache[2] is becoming increasingly blurrier. (Is that proper English?)

Given that Wess is an extremely complete (and sometimes overwhelming) implementation, it deserves, and will eventually get, its own documentation in the near future.
In the meantime, here's an incomplete list of features:

- selector inheritance ('extends' keyword),
  - multiple inheritance (both from and to),
  - prevent single rules from being inherited by children ('final' keyword),
  - cancel inheritance ('unextends' keyword, useful for inherited skins),
  - delete a property entirely ('@remove' command),
  - reset a selector's earlier styles ('@reset' command, also useful for inherited skins),
  - declare virtual selectors that will disappear once they're mixed or inherited.
- nested selectors,
- normal or simplified syntax (no {}; etc.),
- color manipulation functions,
- math functions,
- mixins (supporting parameters),
- variables,
- @if/@else/@endif (test for a browser or environment, and execute CSS accordinly),
- @is (basically an inline @if),
- & shortcut (current selector),
- cross-browser gradients,
- prefix-free CSS3 styles (just the common ones),
- grouping of properties with identical values (e.g. height, line-height: 20px),
- RGBA emulation in IE,
- and inline graphics where supported (can be disabled on a per-file basis.)

The example below is taken straight from our current index.css, and it uses many of the aforementioned features... Try to figure out what does what!

.catbase virtual
   overflow: hidden
   border-radius: 5px
   padding: 5px 10px 5px
   margin-bottom: 4px
   border: 1px solid rgba(0,0,0, .15)
   font: 700 1.4em/20px $big_font
   img
      vertical-align: -3px

.cat extends .catbase
   background-color: #b3afa9
   color: white
   a
      color: white
      text-decoration: underline
      font-size: .92em
      text-shadow: none
      :hover
         color: #fc9
     .cat final
   background-color: #c3b9c3
   border-color: #fd9604
   border-width: 2px 0 0 0
   text-shadow: black 0 1px 2px
   .table_list &
      margin: -5px

.title extends .cat
   padding: 4px 8px
   border, margin: 0
   #sidebar &
      margin-top: 6px
   a
      color: #faf8f8
 1. The main Wess core...
 2. The list of functions that create the actual CSS and JS files and pass them through Wess or other functions.

Re: WeCSS: the Wedge CSS parser
« Reply #16, on June 19th, 2011, 10:42 AM »
I belong to the school of semantics, by far, although I think using inheritance is only sensible.

I know I'm often the first person to write my own version of something, and I love learning from it and see if I can do better.  And here as well, I think writing a PHP version makes a lot of sense.  But, considering Sassy recently moved to using CSS-style syntax, and I personally hate Python style syntax, perhaps it makes sense to gravitate to the rules of another syntax?

That could make the documentation needs lighter.

-[Unknown]

Re: WeCSS: the Wedge CSS parser
« Reply #17, on June 19th, 2011, 11:30 PM »
I agree with Unknown - keep it standard. Sounds like something that could be very useful.

Re: WeCSS: the Wedge CSS parser
« Reply #18, on June 20th, 2011, 12:28 AM »
Quote from [Unknown
link=msg=262641 date=1308472960]
I belong to the school of semantics, by far, although I think using inheritance is only sensible.
Best of both worlds here :)
Quote
I know I'm often the first person to write my own version of something, and I love learning from it and see if I can do better.  And here as well, I think writing a PHP version makes a lot of sense.
WeCSS is not a PHP version of Sass per se -- it's more like a Sass-inspired original library.
Quote
But, considering Sassy recently moved to using CSS-style syntax,
...And I'm not going down the same route.
Quote
and I personally hate Python style syntax, perhaps it makes sense to gravitate to the rules of another syntax?
By another syntax, you mean the 'regular' CSS syntax?

Well, two things.
First, Sass added support for 'normal' syntax because of users requests. Probably couldn't get the hang of it... Dunno. From what they said on their website, it's quite clear to me they're still going to use the Sass syntax themselves.
Secondly, Wedge *does* support the CSS syntax. Really. It's just that you can't mix css and wecss syntaxes together. Only makes sense to me... Once you see my source code, you'll understand how complex it is already.
And because of multiple stylesheets and the styling system I described elsewhere, you can't use css syntax in any files that are related to the index stylesheet (i.e. index.css, sections.css, and any overrides like index.ie6.css etc.)
However, you may perfectly use wecss syntax in the index file, and css syntax in your plugin's file (my-stupid-addon.css), as long as you don't add it to the main file list. (i.e. your plugin must load it separately through add_css_file(), instead of adding it to the css file list array.)

One thing to note, though, is that I haven't tested the extent of what you can do in the css syntax. While all functions are available (color, etc), pseudo-language constructs like 'extend' may not be available (although you can use the alternative syntax for it, the 'base:' rule.)
Quote
That could make the documentation needs lighter.
I'm foolishly hoping that themers will find enough documentation just by reading through the index.css file ;) It has an introduction comment as well... (About a page's worth of details.)

Re: WeCSS: the Wedge CSS parser
« Reply #19, on June 20th, 2011, 02:14 AM »
I think you may be dreaming on the documentation front, but who knows, luck happens.

Well, I'm currently more of a fan of lesscss anyway (in part also because of its js-side implementation in addition to js and php server-side implementations.)  I know compass is uber popular, but it doesn't seem interesting to me.  I can see making the curlies optional, like in PHP with if, but in general I just like curlies.

I definitely want to give it a try.  Are you developing it as just part of Wedge or as a discreet module?  For any parsing system, like TOX-G, less, sassy, or this wecss, I definitely think test-driven development makes sense - do you have tests or just using the Wedge css as that for now?

-[Unknown]

Re: WeCSS: the Wedge CSS parser
« Reply #20, on June 20th, 2011, 02:35 AM »
It's being developed as part of Wedge rather than a standalone module though off the top of my head I think you could probably separate it out without too much fuss.


Re: WeCSS: the Wedge CSS parser
« Reply #22, on November 14th, 2011, 06:48 AM »
It isn't implemented. My algorithm was flawed so I postponed it. Instead I implemented a remove keyword for graphic elements. Should be in Warm.

Re: WeCSS: the Wedge CSS parser
« Reply #23, on November 14th, 2011, 06:50 AM »
I see both in the code. Although you say 'unextend', the regexes have 'unextends'. Also, what's the difference between this and 'reset'?

Re: WeCSS: the Wedge CSS parser
« Reply #24, on November 14th, 2011, 07:42 AM »
'final' means that related inherited classes will disregard this rule, which is only for the 'parent' to deal with.

'@remove' followed by a full line will scan the entire file (or set of files) for that line and remove it, allowing for easy removal of graphic files that might use space for nothing in an inherited skin.
It's not very practical, but it does its job.

'unextends?' (that is, in regex, 'unextend or unextends') means the ability to simply un-inherit a class from another...
i.e. .windowbg2 extends .windowbg, and if later in an inherited skin I say '.windowbg2 unextends .windowbg', it will cancel the previous request...
Although, as I said, I'm not sure it works. And it can probably get too complicated -- can I unextend .windowbg from .windowbg3 if .windowbg3 only extends .windowbg2, without unextending .windowbg from .windowbg2 as well? See, that kind of crap...
Thankfully, an inherited skin will always know what its parent is about, and what code it holds, so it should be easy to simply redefine the rules you don't like. But, ideally, unextends should be cool if it was thoroughly tested. Which it hasn't been.

WESS!?
« Reply #25, on May 2nd, 2013, 09:23 AM »
Maybe I missed a post but what s this WESS thats talked about, is it related to style sheets?

Re: WESS!?
« Reply #26, on May 2nd, 2013, 09:30 AM »
WeCSS

Re: WESS!?
« Reply #27, on May 2nd, 2013, 09:48 AM »
WeCSS is the old name... John being the only one who prefers it, and there are more things to worry about that this... :P

Anyway, if you'd read the feature list, it has its own topic....

Re: Wess: the Wedge preprocessor for CSS
« Reply #28, on May 2nd, 2013, 09:51 AM »
Quote from Nao on May 2nd, 2013, 09:48 AM
WeCSS is the old name... John being the only one who prefers it, and there are more things to worry about that this... :P

Anyway, if you'd read the feature list, it has its own topic....
I thought it was related to CSS but was unsure, I've been working my way through all the posts on the site but it takes some time ;)

Re: Wess: the Wedge preprocessor for CSS
« Reply #29, on May 2nd, 2013, 10:09 AM »
Actually, Wess is a behemoth that deals both with CSS and JavaScript, but it does far more work on CSS than JS. The JS jobs consists in minifying the files, as well as transforming $txt strings and doing @if tests (albeit a very limited set of our usual keywords... IIRC, it only supports 'member' and 'guest', at this point, because there's not much need for anything else...?)