Talk:Requests for comment/ResourceLoader CSS Extensions

Previous page history was archived for backup purposes at Talk:Requests for comment/ResourceLoader CSS Extensions/LQT Archive 1 on 2015-07-10.

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.

I think you should firstly establish a list of features we are currently missing. Then look at existing tools such as sass and lesscss. For each feature state if the existing tool support it or not.

Once done, we might be able to decide that we actually want to reinvent the wheel because nothing fit our needs :-D

This post was posted by Dantman, but signed as Hashar.

Nice ideas! I'd really like to have automatic vendor-prefixing and linking on-wiki files.

How could we make them available for inline style attributes? That would mean to split the functionality in a parser and a translator part. The translator then could be used from sanitizeHTML() and co.

Some things to point out at #Syntax:

• @-mw-extendedcss should be standard mode. Only if you have something that need not use it you might declare a @-mw-dontextendcss block.
• -mw-embed: I don't like it to be a function with url()s as the argument. How about -mw-embed-url('background.gif') and -mw-embed-file('Name.png', 100)? Another possibilty would be to allow the embed-comment directly before the css value, instead of before the css property: background-image: -mw-file('Background.jpg'), /* @embed */ url(images/icon.gif);
• calc(): I can't see any need for that. Do you want to allow the whole #expr:-syntax, or define you own math subset? The example with the 500px thing shows a need for a kind of templating system, but not for a calc-function.

@-mw-extendedcss is ONLY for things that don't fit in with standard css. Things like -mw-file will work unconditionally because they don't conflict. However things like converting border-radius: ...; to {-moz-,-webkit-,}border-radius: ...; have a slight risk of conflicting with existing css that already specifies all the vendor prefixes. In those cases we don't want extended css on because we could go and break a previously working stylesheet.

I don't like the idea of -mw-embed-url and -mw-embed-file. That's essentially defining a -mw-embed-* pattern that requires us to create a new function for each and every non-embed function we add. I picked -mw-embed( ... ); because it will work with everything. Native url(); We add in -mw-file, that'll work. Throw in a -mw-thumb, that'll work too. Say in the future we create a icon framework extension that lets action tabs have icons defined by the wiki and lets skins include the icons using -mw-icon( 'watch', 16 ); then we'd have to go back and also implement -mw-embed-icon.

calc() is defined by css3-values, I'm not making up syntax here. The idea is to allow the portion of static calculations we can pre-process to be used. ie: We'll substitute calc( 500px + 15px ); but not calc( 100% + 5em ); because it's not possible to preprocess two different units together. yes my example could use a variable system, however that does not exclude calc(). Because if you do add a variable system you will absolutely need calc() at that point. Because authors are inevitably going to need something like "$theboxwidth - 1px". Nearly every case where you would want to repeat numbers several times will be in a case where the numbers are not all the same.

I really like:

• Using CSS-like syntax in the -mw namespace in general (especially because, like you say, it allows integrating it where it's intended not above the rule and have the processor figure it out, thus limiting the usage)
• Introduction of -mw-file
• Moving processing into 1 unit, instead of multiple (right now having embed in CSSMin is fine, but if we're extending it further it should be moved out).

I'm personally not a fan of the hierarchy section, although I haven't investigated that a lot yet.