You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This will be changed; for now it's just a way to order things getting used to the new css method. Why /modules and not just /variables? I'm not using /mixins anymore so that's the first to go ... why use _root.less twice (once for variables and once to setup base styles.
Some of these are inherited from old frameworks and the parent styles from Print First CSS. We used to also use /themes/cards/missing.less and simple.less as well as a /component folder (ECSS tells us to keep page/component styles together with their main template files).
Anyway, bottom line is these can be simplified. For instance, as GPS#section styles should be nested inside#page styles, they should probably live inside the /pages folder with their parent #page. There's also Anki-specific sections such as #answer which is a #fragment for linking to on the reverse of the page (scrolls this portion into view).
Is #answer classed as a section? Well, I don't know! With GPS there's some fuzzyness to the decision making, whereas with ECSS it'd simply be .just-SomeClass_OrAChild. A proper guide is required for fringe cases.
Potential changes
/root or /base for all raw html styles and --css-variables (/partials would live here)
/global styles with .gl- classes (or /design-system as we'd need a specimen file to display component styles)
/page folder for all individual pages (or they could live with the /page.html inside it's folder)
A note on frameworks
I'm not entirely convinced yet about GPS-style css, but I DO believe in minimalism and increasingly have a brutalist mindset. While it's nice to have a fancy UI, it isn't necessary, and it's a real bugger to maintain and update as the code complexity increases. CSS is definitely not one of the nicest languages to code in.
Some of the rules in ECSS are still worthwhile, such as for gl- sections. It is a bit disconcerting after using this framework for so long to go from .gl-Card_Header (a child of .gl-Card) to simply .gl-Card header. I guess I'd have to train my brain out of that habit. Although BEM might look a little ugly, looking at the class names is habit and the rules of inheritance doesn't really matter as everything is a class. Using GPS you'll have to start thinking about inheritance a bit more. ↩
Is it really necessary to order them by grouping? Is it just easier to list styles alphabetically? Whichever method you choose, aim to be consistent and have your team follow the rules. ↩
The text was updated successfully, but these errors were encountered:
Why are the folders named that way?
This will be changed; for now it's just a way to order things getting used to the new css method. Why
/modules
and not just/variables
? I'm not using/mixins
anymore so that's the first to go ... why use_root.less
twice (once for variables and once to setup base styles.Some of these are inherited from old frameworks and the parent styles from Print First CSS. We used to also use
/themes/cards/missing.less
andsimple.less
as well as a/component
folder (ECSS tells us to keep page/component styles together with their main template files).Anyway, bottom line is these can be simplified. For instance, as
GPS
#section
styles should be nested inside#page
styles, they should probably live inside the/pages
folder with their parent#page
. There's also Anki-specific sections such as#answer
which is a#fragment
for linking to on the reverse of the page (scrolls this portion into view).Is
#answer
classed as a section? Well, I don't know! With GPS there's some fuzzyness to the decision making, whereas with ECSS it'd simply be.just-SomeClass_OrAChild
. A proper guide is required for fringe cases.Potential changes
/root
or/base
for all raw html styles and--css-variables
(/partials
would live here)/global
styles with.gl-
classes (or/design-system
as we'd need a specimen file to display component styles)/page
folder for all individual pages (or they could live with the/page.html
inside it's folder)A note on frameworks
I'm not entirely convinced yet about GPS-style css, but I DO believe in minimalism and increasingly have a brutalist mindset. While it's nice to have a fancy UI, it isn't necessary, and it's a real bugger to maintain and update as the code complexity increases. CSS is definitely not one of the nicest languages to code in.
Footnotes
Some of the rules in
ECSS
are still worthwhile, such as forgl-
sections. It is a bit disconcerting after using this framework for so long to go from.gl-Card_Header
(a child of.gl-Card
) to simply.gl-Card header
. I guess I'd have to train my brain out of that habit. Although BEM might look a little ugly, looking at the class names is habit and the rules of inheritance doesn't really matter as everything is a class. Using GPS you'll have to start thinking about inheritance a bit more. ↩Is it really necessary to order them by grouping? Is it just easier to list styles alphabetically? Whichever method you choose, aim to be consistent and have your team follow the rules. ↩
The text was updated successfully, but these errors were encountered: