Semantic-ui: [Framework] SASS Support

[dsignr]

Hi Jack, I'm happy to present an SCSS "on demand" port for SUI. This is just an alpha version and I definitely think it could use a lot of improvements. But still, I'd love to hear your thoughts. Today is my birthday and I'm working on SUI from morning..damn :D :dancers:

https://github.com/RealtyPremium/Semantic-UI-SCSS

Cheers.

[jlukic]

Hey, thanks for spending time on your birthday to be working.

Is there an example of the SCSS output from less conversion?

[dsignr]

Hi Jack, You're most welcome :) I will update from office tomorrow for sure :) :+1:

[dsignr]

Hi Jack, here's a sample converted file. I guess if you had too may nested properties within your LESS files, then this converter would be pretty helpful :) Otherwise, it's as good as simply renaming the LESS file to SCSS :D Nevertheless, this code makes use of some weird regexes (I hate regexes). I will try to implement a proper converter using a proper parser, sometime this weekend.

Cheers~

https://github.com/RealtyPremium/Semantic-UI-SCSS/blob/master/semantic/assets/stylesheets/semantic/elements/_button.scss

[jlukic]

My goal is to preserve a version with all the variables, import statements and calculations intact, and is still valid compilable scss. This might be very difficult.

[dsignr]

Hi Jack,
Can you please provide me a LESS file from the framework, which would be the ideal test case you would want me to use? I can probably give it a shot, though, like you said it might be somewhat difficult. But, there's nothing wrong in trying, I guess? ;)

I would love to do a manual port (infact I did one and ditched it), but the problem is that, it requires the project maintainer to manually stay in sync with the changes from the parent repo (please let me know if this isn't the case). For example, _I think_ this is a manual port (since it uses compass):

https://github.com/doabit/semantic-ui-sass

And my god, I am pretty sure there has been a LOT of changes since June (the last time that repo was updated). So, if you look at my solution, you just run rake convert, it does two things:

!) It fetches the latest code from the main SUI repo
2) It then converts the LESS files to SCSS from the fetched code.

1) works perfectly fine as of now, it's 2) that's the most difficult part, which is what I'm planning to improvise upon.

Honestly, I would also love to create a converter like you've described, since it will personally benefit our company's in-house workflow of SUI as well (not having to re-write image helpers, convert eligible classes to compass-includes, etc.). I will update you soon on this.

Cheers.

[jaredmoody]

I'm a little confused about what's happening with sass support in this project and why this ticket exists.

Is the plan to create a separate semantic-ui-sass repo and keep in sync (following the model of bootstrap-sass?) That seems to be indicated above with @designr's repo as well in #939.

My goal is to preserve a version with all the variables, import statements and calculations intact, and is still valid compilable scss. This might be very difficult.

However, this sounds like the goal might be to convert the LESS in this repo to SCSS?

Can you clear up what the plan for supporting sass is and what the current status is?

Thanks!

[dsignr]

Hi Jared,

..why this ticket exists.

I created this ticket to demonstrate Jack (at the time) that I had created a way to get SASS version of the Semantic UI.

Is the plan to create a separate semantic-ui-sass repo and keep in sync (following the model of bootstrap-sass?) That seems to be indicated above with @designr's repo as well in #939.

Almost. The way this works is that, if we had created a properly converted LESS to SASS version of SUI, in a separate repo, then someone would need to maintain it separately as and when Jack updates SUI. This could involve a lot of manual work and leads to the risk that if the project maintainer stops updating his repo, then the SASS repo has a very old version of SUI in it (which is how it is currently with many other repos).

So, following the Bootstrap-SASS model, in which, there is a converter offered to the public, which when run, will fetch the latest live code on the SUI repo and convert it locally to SASS from LESS, thus solving the problem of redundancy. However, Jack has requested for a version that doesn't mess up with the variables in his source files and my converter as of now doesn't respect that. So, for the time being, all it does is convert the LESS files in the SUI repo to SASS files locally and leaves the variable configurations upto you.

Me not updating the SASS repo (which is mine) has nothing to do with Jack, so very sorry for the confusion if it seemed so. My only intention was to share it (at the time) to Jack, with a working version.

As for the current status of my repo, I plan to update it soon with a working fix to adhere to Jack's requirements. And this takes time. Currently, I'm busy traveling and I promise to get this right when I'm back.

I hope this helps. If not, please don't hesitate to ping me for further clarification.

[bsides]

:+1: for this, If you need help let me know

[hason]

:+1:

[dsignr]

@bsides , If you were asking me, then yes, definitely I could use some help. If that's the case, please create a pull request with the necessary changes and I'll accept it. Thanks!

[jlukic]

@dsignr @hason @bsides I've added you to the SCSS team. If this was in error and you aren't interested in participating. Feel free to remove yourselves.

I think the best strategy for doing a port is to incorporate in the gulp file a task that builds SCSS from LESS.

This task would

• Translate variables from @varName to $varName (Something like /^(@[\s|\S]+?;)/gm)
• Copy src/ to SCSS repo directory and push them, tagging if new version from main repo (This is already done for gulp release for single component releases. Probably some easy cut and paste.)

In SCSS repo

• Rewrite theme.less the theme inheritance loader for SCSS. Keep it in src/ and make sure gulp build doesn't overwrite it

Additional Constraints

• LESS handles scope poorly, so definitions can't be directly imported (i've written about this somewhere else on github issues already). We need to check how theme inheritance holds up with SCSS.
• Themes would not be interoperable between environments. This means when a theme ecosystem launches, we'd be stuck with two walled gardens.
• Themes written for SCSS would not work on semantic-ui.com or its source.

Still knowing all this I think its a good thing we go forward, knowing that we will always officially support the LESS version first, and that the less version will be used with the upcoming theme package manager site.

[dsignr]

Thanks Jack, will be glad to contribute as always! :+1:

[bsides]

@dsignr @jlukic @hason I'll look into it this weekend

[christianmagill]

I'm looking forward to seeing this develop!

[einkoro]

@jlukic I've been working on gulp tasks to convert to SCSS maintaining inheritance and the overrides. The main roadblocks I've run into is the naming of variables, mixing of units during operations and functions that do not appear to have direct equivalents such as unit() for converting.

With the variables I could parse them to attempt to determine which are global and which are specific to definitions and then prefix any that are not global with the definition's filename. ie. $statisticInvertedValueColor: $invertedTextColor;

However its extra work, potentially prone to error, and the process is much slower. Any thoughts on changing the variable names in the less version to use prefixes to determine global from definition specific? Would you have any time to hop on slack and discuss it?

[jlukic]

@Einkoro Thanks for taking the time and effort to make steps towards an SCSS release, I understand completely the strain & difficulty with inheritance. Im pretty dissatisfied with their current global implementation in less and scss.

The way I worked around things was always to make sure each file is compiled individually, making sure in the context of each "pass" through the compiler that all variables would be inherited correctly for that one UI element using the constraints of the compiler.

Trying to create a single pre-processed file, where _all UI_ are expected to complete 6 levels of variable inheritance (site default, site theme, site site theme, ui default, ui theme, ui site theme) brings you to an an impasse that I was never able to surpass with the current generation of preprocessors.

I can discuss on slack tomorrow during EST work hours.

[dsignr]

I would love to be a part of this discussion as well, as you know already Jack, I'm working on one, too. Maybe we can collaborate our efforts into a single one? Just a thought.

[einkoro]

@jlukic I'm on slack during PST work hours so I should be available three hours after you start?

@dsignr I'd certainly welcome collaboration on this. It would probably be good to reach out to doabit as he has been maintaining a sass port for awhile and seems to have gotten stuck on the variables as well resorting to manual changes: https://github.com/doabit/semantic-ui-sass

[dsignr]

:+1:

[Jakobud]

Big +1 for SCSS support. What is the status of this? Is it possible to automatically convert the LESS to SCSS? I know it can be done automatically for a lot of stuff like variables, but I don't know how complicated your LESS mixins are.

Any chance of pulling this SCSS version into an official repo under Semantic-Org?

[einkoro]

@Jakobud The blocker in my attempts is mixed units which are not supported in SASS. You can take a poke at it here if you feel brave: https://github.com/BitPiston/semantic-ui-scss/

[Jakobud]

You mean like adding together two different types of units? Like 10px + 1em or something (I'm not even sure that makes sense)?

[Jakobud]

Okay so I was just looking at your issues in the readme. How is LESS doing some of those things? They don't make sense from a CSS standpoint. Example:

@headerLineHeightOffset : (@lineHeight - 1em) / 2;

In Semantic UI's LESS files, is this assuming that @lineHeight is an em value? What happens if a user changes it to be px? Lets @lineHeight has a value of 20px. How do you do 20px - 1em? ems are dynamic sizes based off the parent font size... This is a calculation that cannot be done.

[einkoro]

@Jakobud Thats correct. There are a fair number of variables mixing units that cannot use calc() client side. Some are also just issues with interpolation of string literals and not actual mixed units – good example would be any variable prefixed with a negative. I've been able to account for a number of these and jlukic has fixed a bunch upstream but I haven't had too much time lately to revisit it.

I'm fairly sure the issues noted in the readme have been fixed but there is likely many more to account for. In the end it will likely be necessary to use a rem and em calc function like Foundation 5 does to keep units consistent:
https://github.com/zurb/bower-foundation/blob/master/scss/foundation/_functions.scss#L105

[Jakobud]

I could help you out with these maybe. You should move those issues into actual GitHub issues on your repo so that people know what is outstanding and what isn't.

Also the double negative issue could be solved fairly easily with a regex find replace to simply remove all double negatives or maybe convert them into a plus in the case that its used in a calculation.

[Jakobud]

Also, @Einkoro what is the status of this repo (https://github.com/RealtyPremium/Semantic-UI-SCSS) vs your's?

[einkoro]

@Jakobud The double negative in this case was unintentional and actually a bug upstream if I remember correctly.

I'll be using issue tracking once I can actually produce a usable SCSS build from it for people to try out. Right now its very experimental hence why I haven't shared it with anyone but jlukic on slack previously. You should drop by #scss on slack if you'd like to contribute.

The other two SASS conversions depended on Ruby which I wanted to avoid and one of them was intended to be installed as a ruby gem. My intent was to produce a SASS port thats entirely automated, available via bower, and very similar in structure to Foundation 5.

The biggest challenge after dealing with the remaining syntax issues will likely be variable scope as dumping everything into one default variable file and one theme specific variable file is less than ideal. Currently I prefix component names to the variables to avoid scope issues. I would much rather use defaults per component in addition to this as Foundation does but its pretty tricky when maintaining theme support. Only supporting the default would be much easier. Good example is the top of any component, global and functions:
https://github.com/zurb/bower-foundation/blob/master/scss/foundation/components/_buttons.scss

[Jakobud]

Again, what about this: https://github.com/RealtyPremium/Semantic-UI-SCSS

According to that page, it successfully converts, using Ruby's rake.

[einkoro]

To my knowledge it does not account for variable scoping issues (names being the same between components) or any other cases specific to Semantic UI yet. It also does not process anything but the default theme. It uses the bootstrap conversion script which has a lot of bootstrap specific cases and in bootstrap they avoid the mixed unit issue upstream to avoid dealing with it at conversion from what I remember.

doabit has a port for the default theme that was usable prior to changes in 1.0 but required manual effort to bring changes over. I haven't taken a look at that one for awhile but it might be usable at the moment.

[Jakobud]

Ah I see okay. Also, what is slack?

[jlukic]

You'll have to look around GitHub issues for my explanation about SCSS. Basically less/scss have very primitive scoping (everything is global), which makes inheritance a pain. Semantic has a pretty complex inheritance system, and its a battle to get it to work in this gen pre-processors.

See readme for description of slack.

[Jakobud]

Thanks @jlukic!

@Einkoro regarding the variable scoping, why don't you compile each SCSS component individually, just like @jlukic is doing with LESS in order to avoid the globally-unique variable names issue?

Also for @jlukic, official SASS/SCSS support seems to be pretty important at this point in the game ( #1127 ). If there are weird places in the LESS that does not easily/automaticaly convert to SCSS, would you consider changing up how the upstream LESS is written in those cases in order to make the transition easier (obviously as long as the compiled LESS output doesn't change)?

[einkoro]

@Jakobud Couple reasons: 1) I'd like to include the SCSS components individually in projects for the same workflow I have with Foundation; 2) Without variable interpolation in SASS imports its not possible to produce a theme config/settings file that can then compile each component like in LESS anyway. We would have to use a script to write one out for every component which is very ugly.

[Jakobud]

But in SASS you can just do @import "someFile" and it will bring in the variables from that file. I'm not sure what you are talking about regarding variable interpolation I guess.

Also, why wouldn't including individual SCSS components be possible with what I suggested? Can't you just comment out which components you don't want pulled into a build?

[einkoro]

The problem is we'd need to do @import's with variables as part of the path like here which is currently not supported in SASS: https://github.com/Semantic-Org/Semantic-UI/blob/master/src/theme.less

You would have to compile and include the CSS components the way it is now. Including SCSS components would encounter the same issue as the LESS version – compiling per component or pulling individual components into your LESS or SCSS is pretty much mutually exclusive due to scoping. In the LESS version any component you pull in will output duplicate CSS last I played around with it and you would encounter issues with variables being overwritten at compile time by the most recent component.

Essentially SASS needs to allow variable interpolation in imports and implement per file scoping to play nice with the way inheritance works in Semantic UI. The local scoping per block that was recently implemented is a step closer but would require each component be wrapped in a parent block and I'm not sure that would be something jlukic wants upstream.

[Jakobud]

Hmmm... you can't use variables in import strings? I never knew that. It's a normal string so I just assumed you could do that.

[einkoro]

Only for CSS imports. SCSS/SASS does not support it:
https://github.com/sass/sass/issues/739
https://github.com/sass/sass/issues/49

[Jakobud]

I see. That is a bummer. I don't see any way around that after investigating it a bit...

[jlukic]

I don't see any work around for automating a SASS. I think this discussion is closed pending changes in SASS.

[Jakobud]

So this could be years before SASS makes this change. Is there pretty much no alternative here? Is the big problem just that you can't specify themes to use since those theme names in variables determine which partials are loaded? Is it possible to have SASS support without the themes?

[jlukic]

Yeah, theming works by loading overriding variables from separate .variable files. Which files to load are determined by a theming variable for each element in theme.config.

I dont know any other way where specified themes could be loaded outside of the current practice of modifying the import paths for files using variables.

[lunetics]

as @Jakobud stated, isn't it possible to select one theme from the beginning? So no theme support, but at least some current SASS port (without theme support). Most likely developers gonna stick with one theme for a site anyways.

[frankis]

Twitter Bootstrap is moving to SASS in v4 (related to the creators twitter account it is not a joke) and I am wondering if Semantic Org has similar plans and if so, also a timeline?

[mcb]

:+1: Bootstrap is indeed moving to Sass. See http://blog.getbootstrap.com/2015/08/19/bootstrap-4-alpha/ for details.

[jlukic]

The details on this are in the readme. We need variables in import path before porting.

[topisani]

i have recently got a version 'working' where you had a "theme" folder, to drop all files from the theme you chose in. Then loading those files with mixins. This means, to change themes, all you have to do is drop the theme in the theme folder, instead of changing a variable in theme.config. This all worked, the only thing i needed was a general less->sass conversion, and the difference is quite big. First of all, you cannot refference a variable that is not yet assigned. This means you would have to move everything around. i got quite far with all of this, but simply gave up (i was doing it all by hand) when I got to the point where calculations didnt work, because of some unit proplems. Id love to put a team together to write a script that does this, adding mixins and converting to sass, but the biggest problem is not the variables in import path. Its the general less->sass.

BTW, the only reason while I even want to do this, is LESS-rails not working on windows BC of therubyracer depending on libv8, which in turn doesnt work on windows. Why continue using windows? sadly, i need windows specific applications for other things i do (Office, etc) and i got tired of dualbooting.

the point is.
If anyone wants to help me with this project, I'm in on it. and we don't need variables in @import to do it, even with themes

[ShaggyDude]

I love semantic UI but don't love less. I think this is doable but would require some hand work. I can help out if necessary...

[pedzed]

Can anybody update me on this? Are there any plans to use SCSS? I'm considering switching from Foundation to Semantic UI, but I don't like LESS.

[jlukic]

We mention this in the readme, SASS doesnt support variables in include paths preventing theming with SUI.

[pedzed]

SASS doesnt support variables in include paths preventing theming with SUI.

So unless it gets that support, you will not support SCSS? Not even the way Foundation does it? (https://github.com/zurb/foundation-sites/blob/develop/scss/foundation.scss)

[mootari]

For the record, the feature request is under consideration in https://github.com/sass/sass/issues/739. While waiting for it we could evaluate the various workarounds described in https://github.com/sass/sass/issues/279.

[mmahalwy]

Any update on this?

[gaui]

Why is this closed?

[domschmidt]

Would be so great to have the support for SASS

[pedzed]

Even Bootstrap uses SASS (SCSS) now. Too bad Semantic UI is still stuck with LESS.

I made the switch from Foundation 6 to Bootstrap 4 (as Foundation isn't as actively maintained as Bootstrap). I'm quite happy with Bootstrap now, but seeing Semantic UI make the switch too would be a welcome change.

[gaui]

@jlukic could you inform us if SASS/SCSS is on the roadmap?

[daftspunk]

There is nothing wrong with LESS it serves the purpose just fine. If you want SCSS, take a leaf out of Bootstrap's book (v1-v3), fork the project and make it happen. I understand you all come from a place of love but please also understand that @jlukic is a free agent and not your servant. This kind of pressure and constant nagging is killing the spirit of open source. Please stop.

[gaui]

@daftspunk Are you ok? I'm a FOSS advocate and contributor and I was not nagging nor demanding anything - just a simple question if it's planned in their roadmap. This is just a yes/no question.

[daftspunk]

Take the hint, @gaui.

[9r1nc3w1ll]

Why is this closed?

[hammy2899]

@9r1nc3w1ll
SUI: https://github.com/doabit/semantic-ui-sass
FUI: https://github.com/fomantic/Fomantic-UI-SASS