No Issue - SCSS Media Query Style Proposal

README.md

Index: README.md
===================================================================
new file mode 100644
--- /dev/null
+++ b/README.md
@@ -0,0 +1,39 @@
+# SCSS Media Query Style Proposal
+
+## Background
+
+While working on Issue 5135, I wrote the responsive styles in this way:
+
+```
+.h1
+{
+  margin: $xl 0 $lg 0;
+  font-size: $font-size-h1;
+
+  @media (max-width: $tablet-breakpoint)

[juliandoucette, 2017/05/22 11:20:09]

Note: CSS3 does support nested media queries. CSS2 does not. 

The CSS output from this looks like:

h1 {
  ... }
    @media (...) {
        h1 {
            ... } }

See
https://codereview.adblockplus.org/29438582/diff/29438583/static/css/main.css
for real world example.

[ire, 2017/05/23 00:03:49]

Noted. I wasn't actually aware that CSS3 supported nesting media queries, I only
do them in SCSS in cases like this where the output is expanded.

[juliandoucette, 2017/05/24 11:44:18]

Acknowledged.

+  {
+    font-size: $font-size-h1 - 10px;
+    margin: $md 0 $lg 0;
+  }
+}
+```
+
+Julian asked me to make my case for this method, as opposed to the current method of one media query per file and having the responsive styles for each selector defined within. So, here it is.
+
+
+## Pros
+
+- It's, IMO, easier to read and understand. I think it's better to have all the styles for a class defined in one place, close together, rather than being scattered across different files or in different places of the same file. This also helps to make sure you don't accidentally have duplicate styles, because you can see all the styles related to this one element in one place.
+
+- It's easier to debug. Following on from my previous point, it's easier to debug styles related to a selector if they are all defined in one place.
+
+- It's consistent with the concept of "encapsulated modules". Instead of grouping styles by breakpoints, we group styles by component. This makes is easier to share components across projects.
+
+- It outputs cleaner CSS (IMO anyway). Particularly if we follow a "mobile-first" method for defining our styles, i.e. using `min-width` based media queries instead of `max-width` (and define them in the correct order). Styles will be laid out in a nice logical order, from mobile styles to styles for progressively larger screen sizes.
+
+
+## Cons & Workarounds
+
+- The major issue with this method is that, by default, it ends up outputting more CSS because each media query is duplicated. For example, see the `css/default.css` file/. However, this can be resolved with a postcss plugin I found, [css-mqpacker](https://github.com/hail2u/node-css-mqpacker). This plugin consolidates media queries so we don't get duplicates, see the `css/packed.css` file. Something to note with this is that declarations will be reordered a bit since they are packed together. In my experience, this shouldn't be a problem since styles are still roughly in the same order as defined.

[juliandoucette, 2017/05/22 11:20:09]

Good find. It looks like this also works with sourcemaps (which is a requirement
for my endorsement).

[ire, 2017/05/23 00:03:49]

Thanks!

[Thomas Greiner, 2017/05/23 12:17:49]

I can imagine that reordering CSS rules could cause unexpected behavior in case
of rules that were written with their order in mind.

Presumably, compression should be able to handle those duplicated media queries
quite well so that we might not be able to see any significant difference in
regards to the download size. Are there other reasons why you chose to group
them together?

[saroyanm, 2017/05/23 14:55:24]

You mean that compression fix duplication ? 
Or the file size shouldn't be an issue ?

[ire, 2017/05/23 17:20:11]

Yes there could be issues here, but since we know how the mqpacker works, we
would in theory work around it in cases where we are intentionally trying to use
the cascade in a particular way.
The main reason I think it's beneficial to group them together is to avoid
having hundreds of the same media query scattered across the file. Like in my
example, but scaled up considerably. 

[Thomas Greiner, 2017/05/23 18:30:35]

Since compression usually works quite well with reoccurring strings, the
bandwidth used when downloading such CSS files may not be noticeably larger.
We'd have to verify that assumption though.

On 2017/05/23 17:20:11, ire wrote:
It might be tricky to ensure that but fair enough.
I understand that the output code won't be as nice to look at but what's the
underlying issue this is trying to solve?

For instance, if it could split the CSS file up into multiple smaller files
(e.g. one per distinct media query) it'd allow us to download only the relevant
styles.

[juliandoucette, 2017/05/24 11:44:18]

I created a proof of concept where the order of media queries matters:
https://jsfiddle.net/ume1qatj/
Agreed.

See: https://github.com/hail2u/node-css-mqpacker#notes
If by "this" you mean mqpacker than I believe that it is trying to solve a file
size problem that may not be relevant if you use gzip (like you said, we could
test this). (And I think the output is nicer to look at without mqpacker. That
is why sourcemaps are necessary.)

I think that the mqpacker issue is separate from the code style issue because I
think it is unlikely that we will write a website/ui that contains enough
individual media queries to make a significant difference.

[ire, 2017/05/24 13:06:27]

I think we may be talking about different things. I was saying that the benefit
of using the mqpacker was to make sure that we don't end up with several of the
same media query, e.g. `@media (min-width: 600px)`, each with styles for one
element in them. Using the mqpacker, we can consolidate all the styles for that
particular breakpoint into the one media query, while being able to write our
SCSS in the way I wrote above. 

It seems that what you are talking about is splitting media queries into
different files. This could be achieved as well. If a tool doesn't already exist
to do this, we could create one.  

[ire, 2017/05/24 13:06:27]

Yes I totally agree that there are cases where order will matter. 

As a side note, I tend to stick to only one direction of media query (typically,
min-width). Additionally, I would also suggest always writing them in a logical
order, e.g. start with smallest and increase the size. This would solve issues
of the order, but of course requires a more strictly enforced style of writing
CSS. 
Noted. I was (maybe wrongly) working under the assumption that having less media
queries (especially ones that in theory could be consolidated) would be
noticeably better than the alternative. So we should definitely do some tests
ourselves to find out, and we can decide if the mqpacker is even necessary. 

[juliandoucette, 2017/05/30 10:10:47]

I would like to discuss mqpacker in a separate issue.

(If I understand correctly, it will not make a significant difference.)

+
+- Another potential con with this method is potentially ending up with a larger variety of media queries. This shouldn't be much of a problem for us, as I see we already use standard breakpoints abstracted into SCSS variables to keep things consistent.

[juliandoucette, 2017/05/22 11:20:09]

Another point:

See https://helloanselm.com/2014/web-performance-one-or-thousand-media-queries/

Do you know if this is still accurate?

[ire, 2017/05/23 00:03:49]

I haven't been able to find anything about this. My guess is that this'll only
be a problem when you have a significantly large amount of MQs.

[juliandoucette, 2017/05/24 11:44:17]

Acknowledged.