we have them in the gemfile to lock them to a specific version,
but normal behavior doesn't auto-require them
also, use 1.9 hash syntax in gemfiles (_except_ _before.rb)
Change-Id: I549c2775c65d48ff23ba1358b43713965df97813
Reviewed-on: https://gerrit.instructure.com/51636
Tested-by: Jenkins
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
fixes CNVS-14529
What it does:
- Adds feature flags for new styleguide styles
- Strips out un-needed variable highcontrast (these will need to
be set per element, not on the main color variables)
- Changes gemfile to point to temporary dress_code repo: we need this
so the dress_code generator strips out the parent tag
Test plan:
- get new gem: bundle install
- get new styles: npm run compile-sass
- regenerate styleguide: rake css:styleguide
- Make sure new_styles is disabled. You can do this in rails console:
Account.find(1).disable_feature!(:new_styles)
- Go to /styleguide and it should look the same as it does now
- Now turn on the feature flag. In rails console:
Account.find(1).enable_feature!(:new_styles)
- Refresh /styleguide and you should see are base starter styles for
the new look and feel!
Note: The new styleguide components are a wip and this request just
adds in the layout and styles specifically for the /styleguide page
to use while we work through all the components. You will notice
some funky looking ui - that's normal. We will be attacking these
components piece by piece.
Change-Id: I952b36346df77f98ddb7bbc5e27ab9b45ab4d8ca
Reviewed-on: https://gerrit.instructure.com/39600
Reviewed-by: Chris Hart <chart@instructure.com>
Reviewed-by: Derek DeVries <ddevries@instructure.com>
Product-Review: Colleen Palmer <colleen@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Matt Fairbourn <mfairbourn@instructure.com>
after many steps towards this moment, we're finally here
This yanks sass and compass out of canvas-lms
completely and instead uses the libsass based
node-sass to compile our SASS files.
wins:
It is WAYYY faster!
as in, < 10 seconds to recompile all css in canvas
(compared to the 5+ minutes it used to take)
It is all in JS, helping use move to a completely
nodeJS based fronted tooling workflow.
next steps:
remove jammit: we don't need an assets.yml file
since node-sass can output compressed css for us
and we use sass to do all of our @import'ing of other
files (@colleen calls those "compiler" sheets), this
would simplify and speed up fronted asset building
even more
use gulp/broccoli/whatev to do cached, incremental builds
test plan:
all outputted css should look exactly the
same as it used to.
run `npm run compile-sass`, make sure it works
and is way faster than `rake css:generate` used to be
Change-Id: I7d865ea6b3e374cdc27a883d2019a4c15746c0e2
Reviewed-on: https://gerrit.instructure.com/38416
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Trevor deHaan <tdehaan@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
This uses the fontcustom gem to compile our icons from svgs in the
public/fonts/ folder. No more complicated workflow for adding/editing
icons!
Way to test:
* Add your new svg to public/font/icons/
* Important!! Edit template file to update
stylesheet in public/font/_canvas-icons.scss
* Run the rake task to compile: bundle exec rake icons:compile
* Check the styleguide to make sure they're pulling in
* Done!
Update
fixes DES-101
-takes our core_en.js file (unneeded)
fixes DES-101
- Changes font directories
- Tweaked documentation
fixes DES-101
- Tweaked documentation
- Changed directories for font icon
- Added unique hash to font name
fixes DES-101
- Changed rake task to perform bundle exec
- Updated documentation
- Added missing config file
fixes DES-101
Takes out the default [date-icon] css fontcustom puts in
fixes DES-101
Take out all the icomoon comments in the svgs
fixes DES-101
Added missing icons to font
fixes DES-101
Adds the fontcustom gem to a different gemfile
Change-Id: I9860cb074baaf4518548c9d87c1177a14d96a44c
Reviewed-on: https://gerrit.instructure.com/36974
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Caleb Guanzon <cguanzon@instructure.com>
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Colleen Palmer <colleen@instructure.com>
AKA: run all of our compiled sass through autoprefixer
so we don't serve css designed for browsers we
don't support and so that we do output css for the
browsers we do support.
This will result in us sending the browser A LOT less
css. see this patch for how much it will remove from
our current css:
https://gist.github.com/ryankshaw/fd0ea0a8af4596569dcb
The idea going forward would be to write your css
prefix-free and just let autoprefixer handle the
rest for you.
Also, now that this exists, we could (and should)
retroactively go through the code base and remove
some of these places where we have these prefixes
to keep our css more maintainable.
test plan:
open /styleguide (or any canvas page) in ie10 (or any browser)
it should look exactly the same as it did before
Change-Id: I7e55518d69580af692a8f04ac6fe2b491f7678af
Reviewed-on: https://gerrit.instructure.com/34940
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Colleen Palmer <cpalmer@instructure.com>
Reviewed-by: Tyler Pickett <tpickett+gerrit@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
fixes CNVS-11426
The UI/UX team *really* wants to start doing some major style changes
to the canvas interface. Because it is a very visual change and especially
because we've let people hack the crap out of canvas styles with
their own css override file, any changes we do need to be behind a
feature flag so an institution can opt-in when they are ready.
This commit does some trickery so we actually create 4 different versions
of every stylesheet. one for each variant in:
legacy_normal_contrast legacy_high_contrast
new_styles_normal_contrast new_styles_high_contrast
and then sets the $use_new_styles and $use_high_contrast sass variables
accordingly in each.
now, in any sass file, you can do things like:
@if $use_new_styles {
background-color: red;
} @else {
background-color: blue;
}
@if not $use_high_contrast{
font-size: 12px;
}
test plan:
* in a production (minified assets) environment, ensure you see:
<link href="/assets/common_legacy_normal_contrast.css... in the <head> of the page
* go to the account settings page for the domain_root_account you are on
* turn on the "Use New Styles" feature
* now verify that <link href="/assets/common_new_styles_normal_contrast.css...
is in the <head>. There should not be any visible differences because we do
not have any styles that target specifically $use_new_styles yet.
* now, go to /settings and turn on the user feature for "Use High Contrast Styles"
* verify that <link href="/assets/common_new_styles_high_contrast.css..
is in the <head>
* again, turning that on will not actually change the way anything looks,
the next commit (g/32863) will take care of that
Change-Id: I45ba4ddfe780c5c819fb995b61ebfc0a5325d418
Reviewed-on: https://gerrit.instructure.com/31881
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
during a previous commit
(SHA 10e7b5b003bea9aea3286b9170f5e04b8a9e3735)
we removed indentation of gems, but this indentation
had semantic significance for us: any gem which was
not required by canvas but was required by another
gem required by canvas was indented. This allowed us
to clarify that canvas didn't actually use the gems
while still locking into specific versions of each
Also added a comment explaining this to Gemfile
Change-Id: I0f476e1bed6156f2f5969e54d56d44ded5442a0f
Reviewed-on: https://gerrit.instructure.com/32588
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Anthus Williams <awilliams@instructure.com>
QA-Review: Anthus Williams <awilliams@instructure.com>
this is a proof-of-concept to see if partitioning
our Gemfile helps more than it hurts. It's modeled
after the way the Squash team handles its dependencies
this doesn't implement any of the particularly nice
things that can be found in the Squash set up, such
as conditionally loading gems based on the contents
of our configuration files (we can already sort of
do this with groups in bundler), but it's a start.
In particular, it allows us to add non-OSS gems to
Gemfile.d without necessarily having to release it
as part of our open-source packaging
Change-Id: If7ff1fe97409de4cd09867ad5be1c4134c5d0117
Reviewed-on: https://gerrit.instructure.com/32442
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Nick Cloward <ncloward@instructure.com>
Product-Review: Anthus Williams <awilliams@instructure.com>
QA-Review: Anthus Williams <awilliams@instructure.com>
Cody Cutrer