Scout-app: Autoprefixer Support

Also requested by @blindmikey (https://github.com/scout-app/scout-app/issues/276).

As far as Compass is concerned, it is no longer maintained. So if you are using it on legacy projects, you can continue to, however if you are creating new projects or maintaining an older project, it may be wise to move away from Compass towards a different mixin library that is maintained, or to create your own mixins that replace the ones you were using from Compass.

Adding Auto-Prefixer Support is a longer term feature. There are higher priority items that are of greater use to more users (like live reload) that I would place ahead of this.

I've yet to see a use case for Autoprefixer that can't be fixed by just cleaning up an existing codebase. It feels like a bandaid.

Just adding my 2 cents, Autoprefixer allows my team to write css without having to think of which browser versions do or don't support which vendor prefixes, and without using redundant mixins to cover every prefix in lieu of just writing css.

Autoprefixer is a huge boon to our workflow, and many scss frameworks now utilize it by default such as bootstrap and foundation.

@Blindmikey

First off, thank you so much for creating a pull request for this feature and getting the ball rolling. I've pulled down your branch and tested it. Here's some stuff I noticed while testing it.

In your current branch if I process this file:

.test
    transition: 1s ease all
    -webkit-border-radius: 3px
    background: #1E5799
    background: -moz-linear-gradient(top, #1E5799 0%, #2989D8 50%, #207CCA 51%, #7DB9E8 100%)
    background: -webkit-linear-gradient(top, #1E5799 0%, #2989D8 50%, #207CCA 51%, #7DB9E8 100%)
    background: linear-gradient(to bottom, #1E5799 0%, #2989D8 50%, #207CCA 51%, #7DB9E8 100%)
    filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#1E5799', endColorstr='#7DB9E8', GradientType=0)

it will produce this:

.test {
  -webkit-transition: 1s ease all;
  transition: 1s ease all;
  -webkit-border-radius: 3px;
  background: #1E5799;
  background: -webkit-linear-gradient(top, #1E5799 0%, #2989D8 50%, #207CCA 51%, #7DB9E8 100%);
  background: linear-gradient(to bottom, #1E5799 0%, #2989D8 50%, #207CCA 51%, #7DB9E8 100%);
  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#1E5799', endColorstr='#7DB9E8', GradientType=0);
}
rstr='#1E5799', endColorstr='#7DB9E8', GradientType=0);
}

There are several problems here:

1. The output is not valid CSS.
2. A new user or someone just learning Sass will be confused to as to why Scout-App is adding new properties that they didn't want and removing properties they do want. Scout-App should not pretend that it's automated system knows better than the end user.
3. There is no option in the UI to enable/disable Autoprefixer. This would resolve the above two issues.
4. Errors from Autoprefixer don't seem to be surfaced currently. Ideally we would pass them into something similar to scout.helpers.alert. So there could be in app messages, desktop notifications, and sound effects played when there is an error.

We need to have a lot more discussion over the UX of how to give users options regarding Autoprefixer. The pull request cannot be merged in its current state as it gives a confusing user experience.

One possible solution would be to have a tab in the project settings panel to switch from a Sass settings view to an Autoprefixer view. You can see an example of this here:

• https://github.com/scout-app/scout-app/issues/316

However switching between tabbed views is out of the scope of this issue. For the time being, just throwing in an <hr /> at the end of the existing Sass settings and then putting the UI controls there would be fine until we have a better system in place for switching tab views. Eventually this can be refactored as a plugin if we implement a plugin system.

I'd like some discussion on how best to present the options for Autoprefixer in the UI. I'll need to research more into what options it accepts and all of the queries that Browserslist accepts.

Hey @TheJaredWilcurt,

Thanks! Interesting find with the invalid CSS, I'll have to replicate and see if I can narrow down the cause.

I agree having it optional would be best, even defaulting to off as to not effect existing projects. I think a simple checkbox would suffice. If we're looking to give more granular control over what browsers autoprefixer prefixes for, we could supply a text input giving the user the ability to add an autoprefixer browserlist argument, like autoprefixer's website does: https://autoprefixer.github.io/

As an autoprefixer user, this would be enough for me. Wonder what anyone else's thoughts are.

Reading Autoprefixer's documentation we might be able to just allow the user to add a browserlist config to their project root. I'll test and see if this works as well as I'm hoping, as it would eliminate the need for a text input for browserlist arguments while also being friendly to any other tools that would need the same browserlist configuration.

@Blindmikey

There should be an input field where you can browse for your browserslist file. We could do a quick check to see if it is already there and pre-fill the input field.

If one cannot be found the user can either manually point to it, or click the "create browser list file" button. That button would create the file in the root of their project folder.

After we find or create the browserslist file, we need to display some UI for editing the settings.

Option 1 - The easy route

A textarea will be displayed. We will read in the contents of the file and place them in the textarea. There will be a save button below the textarea. Clicking it will save the contents of the textarea to the browserslist file.

Option 2 - The hard route

I've made a quick mockup of a possible UI

This would require reading in the file, parsing each rule and building a UI control around it. Then on save recreating the rules an storing them to file. Not super hard, just more effort than the easy route. Users would still have the ability to just paste in their code directly into the file, outside of Scout-App.

This is just a quick rough draft. I'd like some more UX eyes on it to improve the design.

Hey @TheJaredWilcurt

I'm wondering what the value is of creating a gui that edits a text file in the user's project. Particularly users who are opting in to using autoprefixer knowingly (assuming it would be off by default), and where a browserlist file is purely optional. If an advanced user wants more granular control they would be privy enough to create a browserlist file in their project root. For users not familiar with browserlist & autoprefixer, I think some light documentation with a note about browserlist and a link to browserlist's documentation would suffice.

But having a gui dedicated to editing one configuration file seems like quite a lot of work for something a basic text editor can achieve. Even if the UI is meant to make configuration easier, it's not that effective because the interface of the UI already closely matches the output. One kudos to browserlist is that the syntax is straight forward and easy to read.

The workflow I imagine is something close to the existing workflow for scout-app, where a user creates a project, points to scss/sass input and css output, but then optionally selects autoprefixer and if they'd like can create a config file in project root to add advanced configuration.

Thoughts?

I've given it some more thought, and it really doesn't make much sense to give that more robust UI for this. Here's a revised concept:

The question mark icon after the text would link you to the browserlist documentation and open in the user's default browser.

@Blindmikey what are your thoughts on this design.

@TheJaredWilcurt I love it! I might suggest having that question mark icon after "Browser list" even when one is not found. Maybe some language that one is not required and what autoprefixer defaults to if one is not present.

@Blindmikey

I think the file should be required, and placed inside their project somewhere (in the root preferably). So it explicitly says what versions are being used. From what I could see, the defaults are >1%, last 2 versions, Firefox ESR.

So if you click the "load defaults" button it would replace the content of the textarea with those defaults (>1%, last 2 versions, Firefox ESR). But it doesn't take effect until you click "Save". If you click "Reset" it will replace the textarea contents with whatever is in the file currently.

Hey guys, how is it going? It'd be a really nice feature. Are you going to implement it?

@ayrtonvwf

In October I worked on Koa11y and got version 3 of it shipped.

In November I will be working on node-flif and getting version 1 of it shipped.

In December I will be working on Scout-App and getting version 2.x.x shipped. I'm not sure how many new features I will be able to put in it. This is high on the list, but depends on how crazy life gets (I am starting a new job in December, as well as normal holiday stuff). At the very least the current master branch will be tested/built/released for all platforms. But I may be able to sneak in some extra features before January, including (possibly) this feature. No promises.