Add Media Queries support, and re-introduce the one-whole width.

[emagnier]

Media Queries support:

• It take the media-query mixin from Inuit v5 as a reference.
• It still generate an elegant CSS code: all selectors which have the same width property are merged together (thanks to the new map data-type), and the mixin adds a comment block before each group of proportions.
• It keep the philosophy of the modular architecture. For example: if the media-query mixin is not available (detected via the new mixin-exists function), it will warn the user.

one-whole/1-whole width:

• I used the _trumps.width in my latest project, and the 1-whole was still necessary, particularly for some specific breakpoints.

If I have some time soon, I will play a bit with the pull & push helpers. I will submit a Gist for that (because this will be probably a new independent module).

[HellPat]

yeah, one-whole is very important for me, too.

[mcaskill]

Suggestion : The variables related to media-query output should be renamed to follow the naming conventions found in other "igloos".

$inuit-enable-widths--responsive:  false !default;
$inuit-enable-widths--responsive-extra:  false !default;

[emagnier]

Thanks for your suggestion. I made a new commit following your recommendation.

[BenjaminRCooper]

Why is necessary? Isn't this why the layout element has width: 100% set by default? https://github.com/inuitcss/objects.layout/blob/master/_objects.layout.scss - you would just fallback to this, if no namespaced value is present for a certain viewport

[jameshoward]

This is a great start but I'm afraid the natural language output looks a bit odd. Examples below:

[class~="one-eighths"] should be one-eighth
[class~="three-quarter"] should be three-quarters

Basically, the pluralisation is a bit inconsistent.

[emagnier]

@jameshoward you are right, I did not paid attention to the pluralisation... (English is not my native language). I will send a new commit very soon to fix that. Thanks for the report!

[emagnier]

I made a new commit to fix the pluralizing inconsistencies.

[csswizardry]

Thanks for your work on this, and sorry for ignoring it. I think that—seeing as we already have the widths typed out—we don’t stand to gain that much from generating them automatically. In fact, I feel it adds a layer of obscurity in that you have to be able to decipher the Sass.

I have started working on a trumps.widths-responsive module that will handle responsive stuff for us based on the responsive tooling inuitcss has; some input over there might be useful, if you have any opinions…?

Many thanks,
H

[emagnier]

No problem for that. As you suggested here #2 I will package my work in an inuitcss plugin.

I also took a look at the trumps.widths-responsive module, and I was thinking that if you wrap the width classes from trumps.widths in a mixin with an optional $alias property, you will avoid to duplicate code. trumps.widths is already a dependency of trumps.widths-responsive, so in trumps.widths-responsive you could just include the mixin declared in trumps.widths.
It will also make things easier to extend in an inuitcss plugin.

Thanks,
Etienne

[emagnier]

As I said in an other thread, I have created a new plugin, and made another one for the responsive widths.

• widths-generator: https://github.com/emagnier/inuitcss.widths-generator
• widths-responsive-generator: https://github.com/emagnier/inuitcss.widths-responsive-generator