CSS file with variable placeholders breaks at import

[seaneble]

I created a CSS file externally and would like to import it into Contao 3.4.RC1. I used the calc() function of CSS extensively:

.grid1  { width:calc(100%/12 - 20*10px); }

I am also making use of the Contao variables defined in my theme. The above code actually looks like

.grid1  { width:calc(100%/12 - 20*$margin); }

Both syntactical constructs get mangled during import into Contao. What is ending up in the backend is this:

.grid1  { width:10012-20cc%mrin; }

I think the problem is that Contao somehow tries to map the margin into the corresponding database field for the width, while it should actually go into the user defined code field.

Also, it would be convenient if Contao could keep variables defined in the CSS file. Currently, they are simply deleted when using syntax like:

.class { margin: $margin; }

[leofeyer]

I suppose this issue also occurs in Contao 3.2?

[seaneble]

Actually, as I mentioned right at the top, this happened with Contao 3.4.RC1 :-(

Please tell me if I can help fixing this somehow.

[leofeyer]

Sorry, I wanted to know if the issue also occurs in Contao 3.2. I have corrected my comment above.

[seaneble]

Oh, I see. I tried with Contao 3.2.15, the result is the same:

.grid1 {
    width:10012-20cc%mrin;
}

[leofeyer]

Generally, the internal CSS editor does not fully support CSS3. It has been written quite some years ago at the times of CSS2, therefore it is logical that it chokes on the modern stuff.

Also, I don't think we can and want to rework the internal CSS editor to handle all the new things, because it would take a lot of time to implement everything (if possible at all). Instead, we have been adding file content versioning and SCSS and LESS parsers recently, providing more contemporary means to handle CSS files.

That being said, I could imagine adding format definitions containing calc( to the "custom CSS code" section. But I really don't want to implement variable support, because it will be quite an amount of work. Except if we agree on adding anything with a variable into the "custom CSS section", too.

@contao/developers What do you think?

[Toflar]

@contao/developers What do you think?

I think CSS files should be written externally. There are a lot of extension languages such as SCSS and LESS etc. as well as tools for minifying, versioning and more. In my opinion, this is not a task for a CMS.
We don't provide parsers for things like CoffeeScript either, right? ;)

[frontendschlampe]

I also think, that CSS should be written externally, but I also know, that a lot of people use and love the internal style editor - and, I don't know exactly, I think no other CMS has such a thing?!

[aschempp]

We don't provide parsers for things like CoffeeScript either, right?

Bad example, as we do provide parsers for LESS ;-)

Regarding the original ticket comment, there are two things here. The incorrect import, which should lead to a custom code instead of writing into the "with" field. I never use the import myself, so I don't know how hard that would be to fix. The second one is adding support for variables, and I think that should be a separate ticket as a feature request.

[Toflar]

Bad example, as we do provide parsers for LESS ;-)

No, that's why it's a good example. Either you want to provide parsers to ease development or not. Parsers are not limited to CSS :)

[leofeyer]

As discussed on Mumble on January 29th, we will try to fix the import so it moves format definitions with variables or function calls into the "custom CSS code" section. However, we are not going to add more fields to the internal editor.

[seaneble]

Great news, thanks!

[leofeyer]

Fixed in 1ea2153.

Nevertheless, we all agreed yesterday that writing a style sheet externally and then importing it is a questionable thing to do. You should rather add your external style sheet as external style sheet to the page layout and generate an (empty) internal style sheet in which the client can make modifications.