2016-02-04 12:20:24 +00:00
|
|
|
// Path to assets for use with file-url()
|
|
|
|
|
$path: '/static/images/';
|
|
|
|
|
|
Use a Node-based tools for handling assets
…or how to move a bunch of things from a bunch of different places into
`app/static`.
There are three main reasons not to use Flask Assets:
- It had some strange behaviour like only
- It was based on Ruby SASS, which is slower to get new features than libsass,
and meant depending on Ruby, and having the SASS Gem globally installed—so
you’re already out of being a ‘pure’ Python app
- Martyn and I have experience of doing it this way on Marketplace, and we’ve
ironed out the initial rough patches
The specific technologies this introduces, all of which are Node-based:
- Gulp – like a Makefile written in Javascript
- NPM – package management, used for managing Gulp and its related dependencies
- Bower – also package management, and the only way I can think to have
GOV.UK template as a proper dependency
…speaking of which, GOV.UK template is now a dependency. This means it can’t be
modified at all (eg to add a global `#content` wrapper), so every page now
inherits from a template that has this wrapper. But it also means that we have a
clean upgrade path when the template is modified.
Everything else (toolkit, elements) I’ve kept as submodules but moved them to a
more logical place (`app/assets` not `app/assets/stylesheets`, because they
contain more than just SASS/CSS).
2015-12-15 08:20:25 +00:00
|
|
|
// Dependencies from GOV.UK Frontend Toolkit
|
2015-11-23 13:50:37 +00:00
|
|
|
// https://github.com/alphagov/govuk_frontend_toolkit/
|
2016-01-14 15:53:19 +00:00
|
|
|
@import 'conditionals';
|
|
|
|
|
@import 'shims';
|
|
|
|
|
@import 'measurements';
|
|
|
|
|
@import 'css3';
|
|
|
|
|
@import 'colours';
|
|
|
|
|
@import 'typography';
|
|
|
|
|
@import 'grid_layout';
|
|
|
|
|
@import 'helpers';
|
|
|
|
|
@import 'url-helpers';
|
|
|
|
|
@import 'design-patterns/buttons';
|
|
|
|
|
@import 'design-patterns/alpha-beta';
|
2015-11-23 13:50:37 +00:00
|
|
|
|
Use a Node-based tools for handling assets
…or how to move a bunch of things from a bunch of different places into
`app/static`.
There are three main reasons not to use Flask Assets:
- It had some strange behaviour like only
- It was based on Ruby SASS, which is slower to get new features than libsass,
and meant depending on Ruby, and having the SASS Gem globally installed—so
you’re already out of being a ‘pure’ Python app
- Martyn and I have experience of doing it this way on Marketplace, and we’ve
ironed out the initial rough patches
The specific technologies this introduces, all of which are Node-based:
- Gulp – like a Makefile written in Javascript
- NPM – package management, used for managing Gulp and its related dependencies
- Bower – also package management, and the only way I can think to have
GOV.UK template as a proper dependency
…speaking of which, GOV.UK template is now a dependency. This means it can’t be
modified at all (eg to add a global `#content` wrapper), so every page now
inherits from a template that has this wrapper. But it also means that we have a
clean upgrade path when the template is modified.
Everything else (toolkit, elements) I’ve kept as submodules but moved them to a
more logical place (`app/assets` not `app/assets/stylesheets`, because they
contain more than just SASS/CSS).
2015-12-15 08:20:25 +00:00
|
|
|
// Dependencies from GOV.UK Elements
|
2015-11-23 13:50:37 +00:00
|
|
|
// https://github.com/alphagov/govuk_elements
|
2016-01-14 15:53:19 +00:00
|
|
|
@import 'elements/helpers';
|
|
|
|
|
@import 'elements/reset';
|
|
|
|
|
@import 'elements/buttons';
|
|
|
|
|
@import 'elements/details';
|
|
|
|
|
@import 'elements/elements-typography';
|
|
|
|
|
@import 'elements/forms';
|
|
|
|
|
@import 'elements/forms/form-validation';
|
|
|
|
|
@import 'elements/forms/form-block-labels';
|
|
|
|
|
@import 'elements/forms/form-validation';
|
|
|
|
|
@import 'elements/icons';
|
|
|
|
|
@import 'elements/layout';
|
|
|
|
|
@import 'elements/lists';
|
|
|
|
|
@import 'elements/panels';
|
2016-07-28 09:05:10 +01:00
|
|
|
@import 'elements/phase-banner';
|
2016-01-14 15:53:19 +00:00
|
|
|
@import 'elements/tables';
|
2015-11-25 16:21:28 +00:00
|
|
|
|
2015-12-17 11:52:24 +00:00
|
|
|
|
Use a Node-based tools for handling assets
…or how to move a bunch of things from a bunch of different places into
`app/static`.
There are three main reasons not to use Flask Assets:
- It had some strange behaviour like only
- It was based on Ruby SASS, which is slower to get new features than libsass,
and meant depending on Ruby, and having the SASS Gem globally installed—so
you’re already out of being a ‘pure’ Python app
- Martyn and I have experience of doing it this way on Marketplace, and we’ve
ironed out the initial rough patches
The specific technologies this introduces, all of which are Node-based:
- Gulp – like a Makefile written in Javascript
- NPM – package management, used for managing Gulp and its related dependencies
- Bower – also package management, and the only way I can think to have
GOV.UK template as a proper dependency
…speaking of which, GOV.UK template is now a dependency. This means it can’t be
modified at all (eg to add a global `#content` wrapper), so every page now
inherits from a template that has this wrapper. But it also means that we have a
clean upgrade path when the template is modified.
Everything else (toolkit, elements) I’ve kept as submodules but moved them to a
more logical place (`app/assets` not `app/assets/stylesheets`, because they
contain more than just SASS/CSS).
2015-12-15 08:20:25 +00:00
|
|
|
// Specific to this application
|
2015-12-17 10:18:31 +00:00
|
|
|
@import 'grids';
|
Use a Node-based tools for handling assets
…or how to move a bunch of things from a bunch of different places into
`app/static`.
There are three main reasons not to use Flask Assets:
- It had some strange behaviour like only
- It was based on Ruby SASS, which is slower to get new features than libsass,
and meant depending on Ruby, and having the SASS Gem globally installed—so
you’re already out of being a ‘pure’ Python app
- Martyn and I have experience of doing it this way on Marketplace, and we’ve
ironed out the initial rough patches
The specific technologies this introduces, all of which are Node-based:
- Gulp – like a Makefile written in Javascript
- NPM – package management, used for managing Gulp and its related dependencies
- Bower – also package management, and the only way I can think to have
GOV.UK template as a proper dependency
…speaking of which, GOV.UK template is now a dependency. This means it can’t be
modified at all (eg to add a global `#content` wrapper), so every page now
inherits from a template that has this wrapper. But it also means that we have a
clean upgrade path when the template is modified.
Everything else (toolkit, elements) I’ve kept as submodules but moved them to a
more logical place (`app/assets` not `app/assets/stylesheets`, because they
contain more than just SASS/CSS).
2015-12-15 08:20:25 +00:00
|
|
|
@import 'components/placeholder';
|
|
|
|
|
@import 'components/sms-message';
|
2016-01-07 20:11:22 +00:00
|
|
|
@import 'components/page-footer';
|
Use a Node-based tools for handling assets
…or how to move a bunch of things from a bunch of different places into
`app/static`.
There are three main reasons not to use Flask Assets:
- It had some strange behaviour like only
- It was based on Ruby SASS, which is slower to get new features than libsass,
and meant depending on Ruby, and having the SASS Gem globally installed—so
you’re already out of being a ‘pure’ Python app
- Martyn and I have experience of doing it this way on Marketplace, and we’ve
ironed out the initial rough patches
The specific technologies this introduces, all of which are Node-based:
- Gulp – like a Makefile written in Javascript
- NPM – package management, used for managing Gulp and its related dependencies
- Bower – also package management, and the only way I can think to have
GOV.UK template as a proper dependency
…speaking of which, GOV.UK template is now a dependency. This means it can’t be
modified at all (eg to add a global `#content` wrapper), so every page now
inherits from a template that has this wrapper. But it also means that we have a
clean upgrade path when the template is modified.
Everything else (toolkit, elements) I’ve kept as submodules but moved them to a
more logical place (`app/assets` not `app/assets/stylesheets`, because they
contain more than just SASS/CSS).
2015-12-15 08:20:25 +00:00
|
|
|
@import 'components/table';
|
|
|
|
|
@import 'components/navigation';
|
2015-12-17 11:52:24 +00:00
|
|
|
@import 'components/big-number';
|
2015-12-17 14:05:35 +00:00
|
|
|
@import 'components/banner';
|
Enhance message textbox by styling placeholders
Users can add placeholders to their messages, eg
> …your vehicle ((registration number))
when the message is sent, this gets replaced with the data the user uploads, eg
> …your vehicle LC12 BFL
We reckon that it will be useful to see that the placeholder has been
recognised, ie that its syntax is correct, before uploading any data.
We reckon that the best way to do this is by styling it differently to the rest
of the text that the user types.
This is not a trivial problem. There are two possible ways to do it:
1 Write a Google Docs-style text rendering engine, which completely replaces
the native HTML `<textarea>` with a custom control, and programme what should
happen when the user types something that looks like a placeholder, or
presses an arrow key, or makes a selection, or…
2 Leave the `<textarea>` in place, unmodified, and duplicate layers in front
of/behind it to visually replace a placeholder with the blue lozenge
Unsurprisingly, this commit implements 2.
There are four layers. Each layer contains live-updated copy of the text in the
textbox, and each is styled differently:
- one layer behind the textbox to make the blue background
- the textbox itself
- a layer with the white text, which overlays the black text of the textbox
- a layer with an inner shadow to knock back the brackets
This is because of some interesting limitations:
- The text in the foreground and background must occupy the same physical space,
so no deleting characters from the duplicated layers
- Words can’t be split up into multiple elements,
eg `<span>((</span>regist…`:—this results in slightly different kerning to
`((regis…`, which messes up the alignment of the layers
- The textbox can’t be completely overlapped with a block of colour, because
the cursor disappears behind it. Trying to edit text when you can’t see the
cursor is hard.
Implementation
Technically this makes use of Paul Hayes work on Javascript modules in the
GOV.UK frontend toolkit[1].
It also makes use of the `oninput` event to detect changes to the textbox’s
contents. This is much more performant than `onkeydown`, `onpaste`, etc. Without
it the delay between user input and the layers all updating is too slow and you
see misalignment of the layers.
1. https://github.com/alphagov/govuk_frontend_toolkit/pull/227
2015-12-20 00:00:01 +00:00
|
|
|
@import 'components/textbox';
|
2016-02-02 17:28:30 +00:00
|
|
|
@import 'components/file-upload';
|
2016-01-07 12:29:56 +00:00
|
|
|
@import 'components/browse-list';
|
2016-01-13 16:27:54 +00:00
|
|
|
@import 'components/email-message';
|
2016-01-15 10:50:10 +00:00
|
|
|
@import 'components/api-key';
|
2016-04-13 12:50:13 +01:00
|
|
|
@import 'components/vendor/previous-next-navigation';
|
2016-08-07 09:17:49 +01:00
|
|
|
@import 'components/radio-select';
|
2016-04-13 12:50:28 +01:00
|
|
|
@import 'components/pill';
|
2016-04-18 11:10:47 +01:00
|
|
|
@import 'components/secondary-button';
|
2016-05-11 15:05:40 +01:00
|
|
|
@import 'components/show-more';
|
2016-05-26 17:05:16 +01:00
|
|
|
@import 'components/message';
|
2016-06-03 16:55:59 +01:00
|
|
|
@import 'components/phone';
|
2016-06-23 17:31:45 +01:00
|
|
|
@import 'components/research-mode';
|
2016-07-07 09:17:50 +01:00
|
|
|
@import 'components/tick-cross';
|
2016-09-20 12:30:00 +01:00
|
|
|
@import 'components/list-entry';
|
2015-12-17 11:52:24 +00:00
|
|
|
|
|
|
|
|
@import 'views/job';
|
2016-02-18 07:44:50 +00:00
|
|
|
@import 'views/edit-template';
|
2016-04-15 10:56:47 +01:00
|
|
|
@import 'views/documenation';
|
2016-04-20 15:37:17 +01:00
|
|
|
@import 'views/dashboard';
|
2016-07-07 09:17:50 +01:00
|
|
|
@import 'views/users';
|
2015-12-11 14:20:44 +00:00
|
|
|
|
2015-12-11 13:52:58 +00:00
|
|
|
// TODO: break this up
|
Use a Node-based tools for handling assets
…or how to move a bunch of things from a bunch of different places into
`app/static`.
There are three main reasons not to use Flask Assets:
- It had some strange behaviour like only
- It was based on Ruby SASS, which is slower to get new features than libsass,
and meant depending on Ruby, and having the SASS Gem globally installed—so
you’re already out of being a ‘pure’ Python app
- Martyn and I have experience of doing it this way on Marketplace, and we’ve
ironed out the initial rough patches
The specific technologies this introduces, all of which are Node-based:
- Gulp – like a Makefile written in Javascript
- NPM – package management, used for managing Gulp and its related dependencies
- Bower – also package management, and the only way I can think to have
GOV.UK template as a proper dependency
…speaking of which, GOV.UK template is now a dependency. This means it can’t be
modified at all (eg to add a global `#content` wrapper), so every page now
inherits from a template that has this wrapper. But it also means that we have a
clean upgrade path when the template is modified.
Everything else (toolkit, elements) I’ve kept as submodules but moved them to a
more logical place (`app/assets` not `app/assets/stylesheets`, because they
contain more than just SASS/CSS).
2015-12-15 08:20:25 +00:00
|
|
|
@import 'app';
|