Topic on Talk:Requests for comment/ResourceLoader CSS Extensions

The reason we have ResourceLoader deployed and working today is because we avoided re-inventing the wheel as much as possible. There are many assumptions in this RFC that I think are incorrect. Upon reading it, these arguments appear to be tailored towards supporting a specific idea of inventing a new CSS processor, rather than trying to solve existing problems (see hashar's comment).

• CSSJanus does not need to be a part of a CSS preprocessor - it can stand on it's own just fine
• CSSMin, which does the URL remapping and embedding, could/should be extended to support local wiki files, this need not be built into a CSS preprocessor
• Any CSS preprocessor we choose to support can be run before CSSJanus and CSSMin, there's no problem here at all
• Existing CSS preprocessors do add new syntax, but that syntax is based on existing CSS syntax and in the case of LessCSS and SASS (ever since they changed their syntax to match LessCSS) is very well thought out
• Wikia is already using SASS, so we should talk to them about the pros/cons from their actual experience instead of hypothesizing about what the pros/cons may be

It's my recomendation that we do the following:

1. Add local wiki image support to CSSMin using a generic extension mechanism so that CSSMin can remain a stand-alone library
2. Evaluate using SASS and talk more with developers at Wikia who have experience implementing this into MediaWiki and porting skin code to it

This post was posted by Trevor Parscal (WMF), but signed as Trevor Parscal.

I still don't like the fact that if you throw our existing css into either SASS or LESS and they'll choke. If you throw vector/screen.css into SASS it'll choke because the css includes syntax it can't understand and it'll bail out fatally. And LESS will go and eat every comment thereby destroying the efficiency by killing the @embed comments and destroying RTL support by killing @noflip. LESS is also supposed to choke on some IE filter rules.

I also don't like the fact that these languages depart from css syntax for something as simple as making sure that border radius has all the vendor prefixes it needs:

/* Extended CSS */
.radii {
  border-radius: 5px;
}

/* SASS */
.radii {
  @include border-radius(5px);
}

/* LESS */
.radii {
  .border-radius(5px);
}

And to top it off those features will completely fall apart when you want uneven border radii, complex gradients, etc... which can't be expressed to all vendor prefixes with simple expressions.

And besides all that, SASS and LESS still don't do anything about making it possible for non-admins to use css. Which is a major annoyance.

I am certain it will be easier to implements @embed / @noflip in less / sass than rewriting our own libs. That could even prove useful to other people.

Trevor I agree. LESS and SASS/SCSS are already well understood by developers and battle tested.

I'm not familiar with the internals of the ResourceLoader but I'm having difficulty trying to understand why a custom parser is being suggested in place of SASS/LESS. In my opinion there should be two layers. SASS/LESS to assist developers and another to inject inject image paths etc, which could be an existing templating language such as mustache, erb, handlebars or a custom one if required.

I see the issues being discussed here as 2 problems and they should be solved separately.