This repo is open source, but doesn't seem to offer any community benefit. Would anyone use this outside of Incuna projects?

It also contains various mentions of ePatient and its functionality. Nothing too concerning, but we would need to be more careful if there's a good reason to keep it open.

cc @incuna/frontend

Suppose that we have the following structure:

master - this contains all of the common ground
web - adds IE stuff, other browser specific stuff
edetail - iPad stuff
epatient - not keen on this at all, but could be based on the web branch and contain some sensible defaults.

In theory you should never use the master branch, you would use one of the branches, but you would update it and version it accordingly.

How would the versioning work in a system like this?

master could be on v0.3, but since that change, several new features have been added to the web branch, bumping the version.

Would it be sensible having a changelog and versioning per branch?

Any thoughts @incuna/frontend @maxpeterson?

https://github.com/incuna/incuna-sass/blob/master/incuna-sass/mixins/_media.sass

• Apply box-sizing: border-box to all elements.
• Add a global variable to turn it off.

Here is the list of things that need documentation. For documenting style reference see https://github.com/incuna/incuna-sass/blob/master/incuna-sass/mixins/_svg.sass

Documentation should explain what the code does, why it's needed and provide examples of when / how it can be used.

If the file is not something we use anymore / need for currently supported browsers please make a note of this as well.

Mixins

• Font face - legacy
• Media
• Placeholder
• rgba-background - legacy
• svg

Helpers

• box-sizing - legacy
• clearfix - legacy
• image-replace
• inline-block
• link
• overflow-scroll
• pseudo-elements - legacy
• vertical-center
• visually-hidden

Functions

• em
• rem

Components

• Angular (not sure this needs much tbh)
• Datepicker
• Flowplayer
• Forms
• Icomoon - legacy
• Messages
• Modal

Root

• Browsers
• Normalise
• Reset
• Variables

@incuna/frontend please find some time to look these over and add some documentation. Alternatively you can come and tell me what it does / why we need it and I'll add the docs.

@incuna/frontend How does this sound?

Have master as the base (lots of mixins, helpers, etc) and then have epatient, edetail, ... branches that are kept in sync with the core stuff in master, but has additional stuff on top of that?

I know that with bower you can install a git repo from a specific revision or a specific branch if you provide the zip url. Obviously edetails would need to be updated to use bower for this as jam is a javascript package manager, not a front-end package manager.

Any thoughts?

mixins/_sprites.sass was removed in #51 but is still referenced here:

[ng-click] cursor: pointer
in an _angular.sass file ?

Via @henrahmagix

@function repeat($str, $times: 3, $join: '')
    $longStr: ''
    @for $i from 1 through $times
        @if $i > 1
            $longStr: $longStr + $join + $str
        @else
            $longStr: $longStr + $str
    @return #{$longStr}

body
    content: repeat(foo bar baz)
    content: repeat('gum foo', 5, ', ')

body {
  content: foo bar bazfoo bar bazfoo bar baz;
  content: gum foo, gum foo, gum foo, gum foo, gum foo;
}

@incuna/frontend can we have a discussion about this library? I'd like to get it de-compassed so we can stop slowing our grunt down so much and generally tidy it up / make it better / more useful.

So I know that @grahamgilchrist has suggested splitting it into 2 libraries, one with compass, one without. Thoughts about that? How do we go about it?

From what I can see not too much of this is using compass. Obviously sprites but we're working on a solution to that. The only other things I can see are a couple of instances of @include background-size (is that necessary anymore?). And some stuff in modal.sass. Am I missing anything?

Also I'm not convinced that everything in here is necessary, so a good first step would be to remove anything we no longer feel is useful. For example I think the inline-block and box-sizing helpers can go, there's no reason for them that I can see, both of those things are pretty widely supported now. (also getting rid of box-sizing would bring us one step closer to getting rid of compass). Does anybody disagree? Can anything else be removed?

There's also a lot of stuff in here that I either don't understand or can't see the purpose of. So it would be good to get some use cases for when these things might be helpful and some documentation for how they could be used. And possibly some of these things aren't necessary? I don't know.
Here's my list:

• visually-hidden
• vertical-center
• overflow-scroll
• image-replace
• icomoon (I think this is an iconfont thing, do we want to be supporting this still?)
• clearfix (I know we use this, I've used it, but I don't understand why it's better than clear:)
• messages (I can't really tell what this is intended to be used for)

So let's discuss these things and their purpose and maybe we can (between us :D) get some documentation into the files.

And feel free to add to the list. I made checkboxes so we can check them off as we make decisions :)

We are using several compass mixins in this library that we need to replace with something else so we can continue to support the files.

I have made new box-sizing helpers to replace the compass reliant ones we had before in #51. Will these suffice? We could easily make a mixin to do the same thing...

In #51 I also replaced all instances of @extend %inline-block with display: inline-block

These are the remaining compass reliant mixins that I found in the library:

• border-radius
• box-shadow
• transition (this one had several varieties with different suffixes)
• translate

so do we want to write our own mixins to replace these? Or use another library, like bourbon?

@incuna/frontend discuss