Enhancement: Add MQ control with custom values

[lostsatellites]

As a design system creator using Pattern Lab I would like the ability to include the MQ control that contains a custom array of media queries values that match what I have defined as major breakpoints in the design so that the style guide viewport could be precisely resized to match those values.

---

Similar to the v1 implementation of the MQ control, there would be the ability via the config to display the MQ control with a dropdown of available widths to resize the style guide viewport. The primary difference being that instead of a media query sniffer to determine the values in the dropdown, they would be manually entered via an array in the config. Example: "mqs" : ["320px","544px","768px","992px","1200px"]

Here are some potential rules:

• The MQ control visibility can still be set to true or false in the config
• The MQ control does not replace the S M L controls and can coexist with them
• The MQ control would not display if the values array was empty
• The MQ array could accept fixed and relative units (px, em, rem, %)

The timeline for this feature is open, and not does not inhibit current use.

Tagging core, frontend/shared assets and spec-enhancement because this request is an additional configuration option that impacts the frontend and could potentially benefit the accuracy of developing items for specific breakpoints.

/cc @pattern-lab/voting-members

[bmuenzenmeyer]

Thanks for opening an issue after our brief conversation. The media query functionality of v1 had its disadvantages, so a re-consideration is warranted!

[dmolsen]

My 2 cents...

I'm not sure this is spec-worthy. Two things:

• MQs was dropped on purpose by @bradfrost. He didn't see it as core.
• It's a feature that doesn't replicate what we used to have and I could see others saying "do it the old way!" Then we're baking in more configuration or reimplementing code we've both removed.

This can be done as a plugin in PL/PHP. I realize Node is still playing catch-up in that area primarily because I haven't documented the input/output of plugins. That said it would seem to be better suited to a plugin than a core/spec feature.

I'm on the fence but I'm leaning to thumbs down. Sorry.

[lostsatellites]

Thanks guys. Since there was still the shell of what the MQ did previously in the current Node version JS we were able to build our own plugin for it this afternoon. I understand the "do it the old way" argument and definitely don't want to go back to that as we'd already reworked that when we were using PL/PHP.

Feel free to close this if you don't think it warrants further discussion.