-
Notifications
You must be signed in to change notification settings - Fork 18
DESKTOP-129: Responsive Best Practices #165
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This update looks great! Only had small comments and typos to mention.
css/css-best-practices/readme.md
Outdated
@@ -93,14 +90,18 @@ When authoring CSS, you should be always aware of the selectors that you are cre | |||
|
|||
Strive to create selectors that actually fully describe where it is authored. Put another way, any given selector should tell you which file and where in the file it is written. | |||
|
|||
This can be down by following this simple rule: the first class in a selector is the file it can be found | |||
This can be down by following this simple rule: the first class in a selector is the file it can be found. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like an old typo:
This can be
downdone by...
css/introduction/readme.md
Outdated
|
||
These guidelines are a summary of our base principles: Our code bases should all... | ||
|
||
* Be written like a single person typed it | ||
* Be components first | ||
* Be mobile-first | ||
* Be modular–components are better than page specific styles |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given the "Be mobile-first" sentence above, it looks like this sentence is meant to read similarly: a continuous thought. But I suspect this is meant to be two thoughts. Can this be clarified? Maybe adding space, or switching to a colon?
@@ -0,0 +1,153 @@ | |||
# Responsive Best Practices | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other pages have table of contents, can we include one here too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
|
||
Our philosophy is that _the first breakpoint is no breakpoint_. | ||
|
||
There are plenty of good reasons to approach [design](https://www.lukew.com/ff/entry.asp?933) and [content strategy](https://alistapart.com/article/your-content-now-mobile) from this perspective, and the same goes for styling. An experience shouldn't depend on a specific viewport width work well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing "to"
An experience shouldn't depend on a specific viewport width to work well.
1. All component and sub-component styles, including modifiers, are in one place | ||
1. You can easily see what you are building on top of | ||
1. Less scrolling and reduced cognitive overhead | ||
1. Debugger is simpler |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DebuggerDebugging is simpler
|
||
Instead of: | ||
|
||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be nice to add scss
to these block for syntax highlighting.
|
||
Instead of: | ||
|
||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can add scss
for nicer syntax highlighting.
css/sass-best-practices/readme.md
Outdated
|
||
|
||
## Global vs. Local Variables/Mixins | ||
|
||
Any `$variable` that is used in more than one file should be placed in the `/vellum/variables.scss` file. Others should be placed at the top of the file in which they're used. | ||
Any `$variable` that is used in more than one file should be placed in the `/variables.scss` file. Others should be placed at the top of the file in which they're used. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
_variables.scss
(prefixed with underscore). Since it's not a directory, it might not need the slash.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, just one typo I noticed when reading through it!
@@ -308,9 +308,9 @@ Sometimes there are situations when a component makes use of other components, a | |||
</button> | |||
``` | |||
|
|||
In situations like this it is tempting to just style the icon's class inside of the button. However, this practice is poor and creates tight coupling between the Button and Icon components that shouldn't exist. As a rule of thumb, a component should only know about what it's responsible for; it should be unaware of anything external to itself. Continuing with this example, the Icon is an external component, therefore the Button component should be completely unaware there there is even such thing as icon classes, like `c-icon`. | |||
In situations like this it is tempting to just style the icon's class inside of the button. However, this practice is poor and creates tight coupling between the Button and Icon components that shouldn't exist. As a rule of thumb, a component should only know about what it's responsible for; it shouldn't be aware of anything external to itself. Since Icon is an external component, the Button component should be completely unaware that of `c-icon`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this say: "...should be completely unaware that of c-icon
."
Now that we're building more mobile/tablet/desktop sites, it's time to put our responsive best practices into our code style docs. These will be updated a bit more after we determine our final grid implementation strategy.
I've also updated our docs a bit in reference to React, and de-emphasized the Adaptive.js specific examples.
Changes
How To Test
TODOs: