Foundation-sites: production build UnCSS breaks orbit slider

[snyde1]

How can we reproduce this bug?

1. add orbit container with at least 3 slides
2. hide container div for small display (in my setup, but not a verified step)
3. run foundation build

What did you expect to happen?
expected orbit slider to progress through slides with default transition
What happened instead?
slider moves to the second slide with no transition and stops

workaround
UnCSS removes /^.slide-.*/ classes used by motionUI from app.css if they are not present in the HTML

If an option is added to the config.yml file to ignore /^.slide-.*/ classNames, the issue is resolved.

[phifa]

oh uncss. it's crazy how often someone posts a bug about uncss removing classes. even of the framework. can we please get this sorted for 6.2.1, or alternatively let's remove uncss until it does not break the sites. #8413

[tehpeh]

I'm seeing this too for the 'Reveal' modal. I added - !!js/regexp reveal to UNCSS_OPTIONS in config.yml to fix for production builds. Not sure if that's the right thing to do in this case.

Using v6.2.0.

[JRetza]

If you're using motionUI - add this line to your config.yml UNCSS_OPTIONS > ignore:

• !!js/regexp ^.(fade|slide|hinge|reveal|scale|spin|zoom)

[phifa]

how about adding this to the template, as motionUI is deeply integrated in foundation elements?

[kball]

I'm inclined to remove uncss, as we do enough with javascript applied classes that this is likely to always be error prone. Thoughts @andycochran @rafibomb @brettsmason @colin-marshall @JeremyEnglert @designerno1?

[andycochran]

:+1: The framework inherently has ways to minimize the styles it outputs—e.g. components, mixins. I say remove it.

[colin-marshall]

I also say remove it, at least for now. Adding/removing this is pretty painless and we can revisit it later.

We could start keeping a list in the docs that tracks all of the classes that the framework adds after page load.

[JRetza]

I agree - UNCSS is theoretically great but still needs to mature some.

[phifa]

yeah but let's keep it on the bucket list. it's a great tool that should evetually find it's way into foundation. or another idea would be to have it not included by default, only with an experimental parameter. e.g.: foundation build --experimental or sth like that.

[colin-marshall]

@phifa it could also be turned on/off through the config.yml file.

[brettsmason]

I also vote to remove it. I've never used it myself but it seems to create more problems than its worth (at least at the moment). Until we have a list like @colin-marshall suggested I'd get rid of it - maybe even have a section in the docs on adding it yourself?

[snyde1]

Believe it or not, I've gotten so adept at adding ignore lines that I kinda
like having the reduction from it.

On Fri, Apr 29, 2016 at 3:20 AM, Brett Mason [email protected]
wrote:

I also vote to remove it. I've never used it myself but it seems to create
more problems than its worth (at least at the moment). Until we have a list
like @colin-marshall https://github.com/colin-marshall suggested I'd
get rid of it - maybe even have a section in the docs on adding it yourself?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/zurb/foundation-sites/issues/8451#issuecomment-215645192

[JeremyEnglert]

In my opinion, UnCSS shouldn't be included in the framework. I'd rather see developers add it to their own build process so it can be configured per project.

We're setting up a lot of ignore lines under the assumption that everyone is going to use every JS component - which isn't true. Users should configure and setup UnCSS based on what components they are using on a project by project basis.

[colin-marshall]

@JeremyEnglert what do you see as the downside of having extra ignore lines for components not in use on a project? It may add a little extra time to the build but UnCSS is only used in production and in an ideal situation you will only build once when doing production so the time added is negligible.

[JeremyEnglert]

@JeremyEnglert what do you see as the downside of having extra ignore lines for components not in use on a project?

It's not a huge deal, but it ends up almost defeating the purpose of UnCSS as you'll have a bunch of styles you aren't using.

For example, if I'm not using the topbar/menu, but UnCSS is setup to "ignore" these styles, my stylesheet is going to contain some of the menu styles even though I'm not using them.

It's a small issue. But something to consider.

[colin-marshall]

Maybe I'm misunderstanding how UnCSS works but I thought that it only removed styles. If it's set to ignore something that's not in your stylesheet initially, I figured nothing would happen. You're saying it actually adds in the classes it's supposed to ignore if they're not there?

[JeremyEnglert]

You're saying it actually adds in the classes it's supposed to ignore if they're not there?

Maybe I'm confused as well. I assumed UnCSS removed all unused styles - except files that were ignored. So if a user doesn't specifically remove the unused components from the Sass imports, they're going to end up with some styles they don't need.

Foundation already makes it super easy to only import the styles you need. I think we should be stressing that instead of having users rely on UnCSS to remove unused styles.

[colin-marshall]

I think your confusion is because with UnCSS we're talking about ignoring classnames, not ignoring files. You give UnCSS a stylesheet, a set of html pages, and a set of ignore rules. UnCSS will find all of the class names used in the html pages you gave it. It will then check that list against the classes in the stylesheet, and remove the classes that were not used in the html, unless they are on the ignore list. The classes on the ignore list should be any class that could potentially be added after page load via JS.

There is not much benefit to UnCSS if you're using the mixins with custom classnames, but if you're using using the stock component classnames (@include foundation-grid for example), which is where most developers new to Foundation will start, there is a benefit. With @include foundation-grid you will get classes for offset columns, expanded rows, collapsing, incomplete rows, etc that you might never use in the project. So even though you're using the grid component you could still end up with many unused classes.

[snyde1]

My understanding is that it searches the rendered HTML for any use of each
class name and if it doesn't find one, it removes the class declaration.
This obviously becomes a problem when a class is dynamically added by
JavaScript and the declaration has been removed because the class is not
present in the static HTML. I am not aware that it adds anything, only
removes things.

That being said, there can be a significant reduction in stylesheet size by
using UnCSS and I like having it available. Once you get used to
troubleshooting JavaScript issues by first checking if the function is
dependent on a class that has been removed, it's easy to remedy in the
ignore file.

I'm with @CollinMarshall - after the hair pulling, the only downside is a
fraction of additional compile time for what can result in a significant
reduction in css code.

Every little bit helps, especially when you hand the code off. It's nice
to be able to assume that the vast majority of classes in the rendered css
actually do something.

On Fri, Apr 29, 2016 at 5:07 PM, Jeremy Englert [email protected]
wrote:

You're saying it actually adds in the classes it's supposed to ignore if
they're not there?

Maybe I'm confused as well. I assumed UnCSS removed all unused styles -
except files that were ignored. So if a user doesn't specifically remove
the unused components from the Sass imports, they're going to end up with
some styles they don't need.

Foundation already makes it super easy to only import the styles you need.
I think we should be stressing that instead of having users rely on UnCSS
to remove unused styles.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/zurb/foundation-sites/issues/8451#issuecomment-215881878

[phifa]

I think all the issues I am having with UnCSS are comming from the fact that I am not using static html, but a content management system, http://typo3.org. So all my html templates are rendered via php and UnCSS is useless for me. Or am I getting this wrong? It seems as it is only valuable as long as you are working with static html. Right? @colin-marshall thanks for the hint. I uncommented it and everything works fine. So maybe it is nice to have. When deactivating it is so easy, it could stay in the framework I'd say.

[kball]

uncss has been removed from the template by default