Forums

The forums ran from 2008-2020 and are now closed and viewable here as an archive.

Home Forums Other Why no editor with support for CSS variables?

  • This topic is empty.
Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #170465
    Rhys
    Participant

    Obviously CSS does not have variables, but why has no-one ever made an editor that supports variables whilst editing/ working a project??

    To use comments or similarly browser-ignored text to store references to variables either stored in the .css (ie at top of file) or potentially stored in the editors project file.

    Obviously when you publish/export/save the design the editor would save the values inline and potentially minify the CSS and all ‘meta’ data comments that refference to variables would be deleted. The values simply inline as usual.

    Yeah you say, er noob make good CSS so you only declare that value once… well that’s hardly possible or reasonable especially when you have dynamic events from varying generated classes or :hover or js that need to overwrite each other in special conditions then be able to return to the ‘original’ value in another condition on top of that which is used in 20 places on the page… unless you like 600 classes being generated by js and as many selectors in your CSS… just so we can colour a link the same colour as we used elsewhere.

    Sure use find/replace…. well that’s not so great when you have something else that happens to use the same value and you don’t wish to change that usage of it.

    What I imagine writing in a CSS editor is something like;

    /*
    $coolcolour = #E4A938,
    $coolborder = 1px solid red
    */
    
    .myclass{
        border: /*$coolborder*/;
        color: /*$coolcolour*/;
    }

    Would produce a .css like this upon saving/exporting: (un-minified)

    /*
    $coolcolour = #E4A938,
    $coolborder = 1px solid red
    */
    
    .myclass{
        border: 1px solid red /*$coolborder*/;
        color: #E4A938 /*$coolcolour*/;
    }

    The editor should be able to reopen that file and “make-again-dynamic” the outputted value preceding the comment referencing a variable.

    Seems so beneficial yet simple and with no compatibility issues, no php processing or special installations like other ‘dynamic’ CSS solutions, why has it not been done?

    The trouble of not having variables or “reusable values” in CSS is mostly only a maintenance one, why not solve the problem where the maintenance is actually done (aka the editor)

    #170469
    Paulie_D
    Member

    Obviously CSS does not have variables,

    Actually it does, the support hasn’t been integrated in to browsers just yet.

    I think the last FF release supports them and it’s an experimental flag option in Chrome (Canary?).

    BTW…are you aware of SaSS or LESS?

    It/They are supported by most code editors today?

    #170482
    nixnerd
    Participant

    Yeah… just use SASS. SCSS syntax in particular look EXACTLY like CSS… because that’s what it is. It just gives you a whoooooole bunch of other tools. Variables being one.

    #170512
    Rhys
    Participant

    Actually it does, the support hasn’t been integrated in to browsers just yet.

    Yes sounds great however meanwhile we still are supporting IE6/7 and still need vendor prefixes for just about everything even in the most modern browsers, maybe 10 years and we can use real CSS variables without trouble, hehe ;)

    BTW…are you aware of SaSS or LESS?

    Yes, which require special installations on the server, not always possible or practical.

    What I’m suggesting is basically SaSS but do the processing in the editor – handling variables, vendor prefixes and etc then output a valid standard .css file which can be used anywhere without compatibility issues or special installations.

    Maybe you lose some flexibility with imports and etc but CSS is not really designed to be dynamic or comples interact with other .css files anyway.

    Most of the problem is with maintenance, why not solve the problem where the maintenance is done.

    #170514
    __
    Participant

    Yes, which require special installations on the server…

    No, not at all. SASS must be installed only on your development machine (the computer you write the code on: e.g., the same computer you installed your code editor on). It compiles to regular CSS, and that is what goes on your website. Your server need never know where it came from.

    What I’m suggesting is basically SaSS but do the processing in the editor – handling variables, vendor prefixes and etc then output a valid standard .css file which can be used anywhere without compatibility issues or special installations.

    This describes SASS exactly —the only difference is that it’s its own program, instead of specifically being part of a code editor.

    edit

    Yes sounds great however meanwhile we still are supporting IE6/7

    BTW, sorry to hear that.

    #170516
    Rhys
    Participant

    No, not at all. SASS must be installed only on your development machine (the computer you write the code on: e.g., the same computer you installed your code editor on). It compiles to regular CSS, and that is what goes on your website. Your server need never know where it came from.

    This describes SASS exactly —the only difference is that it’s its own program, instead of specifically being part of a code editor.

    WELL, I better take a better look at that then. Slight oversight on my behalf sorry. haha

    I always thought SASS was like a php script, where you would upload .sass/ .scss to the server which would process it and cache the “compiled” .css.

    I best take a better look at these tools.

    Would you consider SASS software just a “converter” which takes .sass and converts to .css to then be uploaded?

    #170552
    nixnerd
    Participant

    Yes, which require special installations on the server…

    So I actually asked a question about this on Reddit a little while ago. This is a COMMON misconception that people have. They think that they need Ruby, Gems, SASS and Compass all installed on their server. Couldn’t be further from the truth but this is what ton of people think.

    I think a lot of people are under the impression that SASS uses Ruby to process its syntax into valid CSS in REAL TIME, each time a page is requested. If that were the case, two things:

    1. SASS would suck and it would negate any gains with crappy performance.
    2. It wouldn’t be called a PRE-processor.

    All SASS does, is take a new syntax/new tools and spit it all out as regular, vanilla CSS. That’s it. Just give SASS a shot. It’s awesome. And once you do, I guarantee you won’t go back.

    I know for awhile Lea Verou was against pre-processors (not sure if she still is) but I think the argument against is a little half baked to be honest.

    #170553
    nixnerd
    Participant

    I would like to add one thing:

    Gross negligence with imports/patials and extensive use of the @extend directive CAN cause some problems. However… with good planning and documentation, these are easily manageable.

    But I will agree that being able to work in a modular/abstracted fashion is a double-edged sword. But… that’s more about the coder than the tools.

    #170554
    __
    Participant

    Would you consider SASS software just a “converter” which takes .sass and converts to .css to then be uploaded?

    It can certainly be used that way (and probably most people do). In that scenario, it’s just a way to make it easier to write/organize your css.

    It is capable of much more, however. SASS calls itself a pre-processor, but that really just describes its intended usage. SASS is a Turing-complete programming language, and being able to write and execute actual programs is very, very different than simply “processing” or “converting” input in one syntax to output in another.

    I always thought SASS was like a php script, where you would upload .sass/ .scss to the server which would process it and cache the “compiled” .css.

    Installing ruby+sass+compass+whatever on your server and actually running your sass scripts on every request is certainly possible. It would be pointless, however, without some way to manage input*: if the script always produces the same output, then running it repeatedly is just a waste of processor time.

    * which could be done without too much trouble, but I really don’t see a worthwhile use-case. edit: Actually, sites like codepen are a good example of this (and, now that I think of it, possibly a contributing source of the confusion).

    Also, that’s not quite how PHP works, either: the output of a PHP script isn’t cached (unless you intentionally do so, at some point, but even then the script will still “run” every time it is requested).

    I know for awhile Lea Verou was against pre-processors (not sure if she still is) but I think the argument against is a little half baked to be honest.

    Agreed. And it would seem she uses SASS now (and this article is also a good example of using SASS as a programming language vs. as a simple converter).

    #170565
    Rhys
    Participant

    This is a COMMON misconception that people have. They think that they need Ruby, Gems, SASS and Compass all installed on their server.

    That’s exactly what I thought ;(
    I think it’s this “Ruby” word. You hear Ruby and think Ruby-on-Rails. Also very rarely is any desktop software seen using Ruby.

    If it said Python or Java it might be a bit less misunderstood. Also their website could do a better job at communicating that it’s a desktop tool.

Viewing 10 posts - 1 through 10 (of 10 total)
  • The forum ‘Other’ is closed to new topics and replies.