csswizardry / inuit.css Goto Github PK

To hide content off-screen without hiding from screen readers, and supporting RTL languages at the same time, you can use the clip technique.

You used this to hide .accessibility class and as you noted, it doesn't support RTL languages.

.accessibility{
    /* Hide content off-screen without hiding from screen-readers. N.B. This is not suited to RTL languages */
    position: absolute;
    left: -99999px;
}

This is a modified version of the above. Hides content off-screen, doesn't effect screen-readers and supports RTL languages. Source ;).

.accessibility{
    /* Hide content off-screen without hiding from screen-readers. Supports RTL languages. */
    position: absolute;
    clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
    clip: rect(1px, 1px, 1px, 1px);
}

I have been taking a serious look into this framework, however I have recently started to use Less. I'm totally addicted to it at this point for development. Any plans to convert this to a Less framework?

I would like if I can have compatibility with IE7. I will list the thing which I found is not working in IE7 hope someone will try to have CSS only fixes for that

1. display:table-cell doesn't work in IE7 which is being used in flexbox, most probably in others http://jsfiddle.net/inuitcss/ufUh2/embedded/result/
2. HR styling not showing properly in IE7 http://jsfiddle.net/inuitcss/L6GuZ/
3. Options tab has problem in IE7 http://jsfiddle.net/inuitcss/vwfaf/embedded/result/
4. Breadcrumb object being disturbed in IE7 because of :after http://jsfiddle.net/inuitcss/rkAY9/
5. Greybox wireframe example not being displayed in IE7 and IE8 http://jsfiddle.net/inuitcss/qCXfh/
6. only one link+icon is showing in IE7 http://jsfiddle.net/inuitcss/Q6Lbf/embedded/result/
7. Sprite example is breaking in IE7 http://jsfiddle.net/inuitcss/6TKuS/embedded/result/
8. Flyout example not working in IE7 http://jsfiddle.net/inuitcss/B52HG/
9. This or this broken in IE7 http://jsfiddle.net/inuitcss/R3sks/embedded/result/
10. Pagination has aligment issue in IE7 http://jsfiddle.net/inuitcss/9Y6PU/embedded/result/
11. Matrix object is broken in IE7 http://jsfiddle.net/inuitcss/Y2zrU/embedded/result/
12. Nav abstraction is broken where :after is being used http://jsfiddle.net/inuitcss/Vnph4/embedded/result/
13. Colums is only for IE10 http://jsfiddle.net/inuitcss/E26Yd/

Sorry!

In Inuit there's :
a:active,
a:focus{
/* Give clicked links a depressed effect. */
position:relative;
top:1px; <---- PROBLEM
}

If I have a "position: absolute" set on a link this proprerty change the position of the element

Hi Harry

Just found a couple of issues with _links.scss, specifically .current a:

1. Just come across a situation where I need to nest <ul>'s for sub-menus:

<ul class=nav>
...
<li class=current><a href=#>Somewhere</a>
<ul class=subnav>
<li><a href=#>Sub 1</a>
...
</ul>
</li>
</ul>

.current a affects the sub-menu links too, so IMO the selector should be .current > a

2. I question whether this is the right way to do things in any case. A link to the same page you're currently on is still a link, and whilst it should probably appear different, making it appear NOT like a link I think is confusing.
   It's perfectly valid to simply not have an href attribute on an <a> to mark a menu item as current (see spec).
   From my quick tests, leaving off the href makes an <a> behave just like a generic span, and no hover or focus styles etc. apply at all anyway. This means it could just be left up to the designer to apply any appropriate styles and so .currrent. and could maybe be left out altogether? Or perhaps at least qualified with .current >a[href], or something?

Just a few thoughts.
What do you think?

Cheers,
Andy

Oh - and Happy Christmas :-)

The below example do not work

<!-- YOU CAN START WORKING IN THIS FILE RIGHT AWAY, JUST EDIT BELOW --> 

<div class="grids"> 

    <div class="grid-12"></div> 
    <div class="grid-4"><h1>Hello!!</h1></div> 
</div>          

if you put a "." in first grid then only it works.

<!-- YOU CAN START WORKING IN THIS FILE RIGHT AWAY, JUST EDIT BELOW --> 

<div class="grids"> 

    <div class="grid-12">.</div> 
    <div class="grid-4"><h1>Hello!!</h1></div> 
</div>          

Kindly look into this.

Hi, love and use your framework a lot, but the first thing I do every time is remove:

html{
...
color:#e4eef6;
...
}
body{
...
text-shadow:0 -1px 0 rgba(0,0,0,0.5), 0 1px 0 rgba(255,255,255,0.25);
}

/*------------------------------------*\
TYPE
\*------------------------------------*/
h1{
font-weight:bold;
font-size:3em;
line-height:1;
}

Why is this here?
The H1 is really too big and the text color is not readable...

Also the mobile text is smaller? Should the font size be bigger for mobile readability?

/*------------------------------------*\
MOBILE
\*------------------------------------*/
/*
CSS for mobile devices.
Linearise it!
*/
@media (max-width: 720px){
body{
font-size:0.75em;
}
}
/*--- END MOBILE ---*/

There have been a lot of requests—and rightly so—to integrate @necolas’ normalize.css.

The newer, non-IE7 version of normalize.css is the one that integrates nicest with inuit.css, the older version doesn’t integrate quite so well in that it would lead to the addition of a lot of redundant styling, particularly around headings.

I have made a normalize.css branch.

If we add normalize.css, it would have to be for IE8 and above.

There’s a lot of love for *{ box-sizing:border-box; } at the moment, it’s a really handy one-liner that makes a world of difference. A lot of inuit.css already uses this property, however… it’s only supported in IE8+ (starting to notice a pattern…?)

If we add *{ box-sizing:border-box; }, it would have to be for IE8 and above.

I propose that because a lot of inuit.css won’t work in IE7 anyway—anything with pseudo-elements, box-sizing and possibly more—we might as well go the whole hog and drop IE7 completely. Doing so would:

• Allow us to use normalize.css
• Allow us to use box-sizing:border-box;
• Allow us to stop having to wrestle IE7!

What are peoples’ thoughts?

Hi, how about rewritting code in this direction? https://speakerdeck.com/u/anotheruiguy/p/sass-32-silent-classes

The following boxes have bad readability (light text against light background).

<div class="message error">
  An error text.
</div>

<div class="message warning">
  An error text.
</div>

Would it be possible to somehow create an OOSASS version of inuit.css ? One that only uses placeholders – meaning nothing gets outputed to the final.css unless the modules have actually been used.

When trying to compile/parse inuit.css, Sass gives me the following error:

Syntax error: Invalid CSS after "...bkit-keyframes ": expected "}", was "$animation-name{"
        on line 51 of inuit.css/partials/generic/mixins.scss

When replacing the $animation-name with a hardcoded name, it works.

I don't know Sass/SCSS good enough to know why it does not work and how to fix it, but that seems a bit strange.

H,

Since there are no docs and even the fiddles don't show much about responsive layout using inuit. I was wondering if you could add some sort of support regarding that.

At the moment, I am struggling in using inuit properly for creating a working responsive design for my website.

The grids do nest properly, but I am not able to stack them on changing the width.

Would be great if you could help.

Thanks.

I've been studying Inuit and think the code is really solid. Thanks for the great resource.

Just wondering -- what's the rationale behind setting font-style: italic on the img element?

line 88 to 90

h1,h2,h3,h4,h5,h6 {
      font-size:1em;
 }

simple question, why do you put em to 1em, and later to their real hights?

Hey Harry,

I just wanted to leave some feedback about the latest commit that removes underscores from partials, and the removal of them in general for inuit files, which seems to be your preference.

I understand that according to the documentation you wrote, and perhaps even your preferred method of watching a project with SASS, only a single file is ever output. This is because you are specifying a file to watch (your-project.scss).

But when used side by side with something like Compass, you'd typically only have to run "compass watch" on your projects directory. Compass affords you the flexibility to omit a specific file you need to watch, as it handles that portion of it for you.

I'm not requesting that you expand the scope of the project to make it more "compass compatible", rather, I'm requesting that you consider going back to using SASS naming conventions with underscores before the name to make it more flexible and "sass-friendly" in general.

If the entire purpose of the underscore is to flag a file as a partial not to be output, and we agree that these files should never be output, then the conclusion would be to put underscores before the filename!

I think we'd both be in agreement that you'd never want to be outputting 40+ css files accidentally, so abiding by the SASS naming convention that would specifically prevent that from ever happening seems to be the best approach.

Thanks for inuit, it's awesome!

Modernizr adds a class named 'flexbox' to the html tag on browsers that support flexbox. This renders the layout incorrectly in those browsers.

Workaround:

html.flexbox{
    display:block;
    width:auto;
}

Browsers tested: IE 10 and WebKit r134433

I’ve had reports of the sprite not working in IE7, and it’s (unfortunately) down to the text-indent:100%; used in the Kellum method.

I’m probably gonna move this from the Kellum method to the H5BP method that @necolas writes about here.

I noticed that the CSS in _code.scss is based on invalid markup.
The 'pre' element doesn't allow for block elements to be contained within it, so one of the correct markups would be:

<ol>
  <li><pre><code>.someClass {</code></pre></li>
  <li><pre><code>  color: red;</code></pre></li>
  <li><pre><code>}</code></pre></li>
</ol>

This is invalid:

<pre>
  <ol>
    <li><code>.someClass {</code></li>
    <li><code>  color: red;</code></li>
    <li><code>}</code></li>
  </ol>
</pre>

I'm no pro at Sass, but I was looking in the ZURB Foundation source (like Bootstrap, but built in Sass), and noticed that all their variables were setup with default values.

I think that would be a great design consideration so that people can start new projects based on the Sass files and override the default values.

Why don't you create a sass version of the framework? As far as I know at the moment this is the only elastic 960 system (the other are fixed or liquid).
Transforming this in sass functions and mixins means separating the presentation code from HTML and storing it entirely in the CSS where it should be. Instead of using class="grid_6" you would just give your item an ID or class (ex. <img id="logo"... >) and then in the SASS file you use the Inuit mixin #logo {@include grid(6)} or something similar.
The benefit is not only semantic but if you want to change the columns of your boxes you just do it in your SASS(css) file and it changes in all the pages, without having to change all the HTML markup for all pages.

Hi guy!
There's a syntax error in example page code ... take a look on <table> example :

<tfoot>
    <td colspan="4">something</td>
</tfoot>

TR wrap missing and cause an error on validation, so ...

<tfoot>
    <tr><td colspan="4">something</td></tr>
</tfoot>

Cheers

You were so right. Hehe!
Moved to my own blog.

Line 780
.wrapper{
width:auto;
width:auto;
}
Shouldn't be just one width?

Adding 12 col support in the same CSS file bloats it somewhat and also leaves some unusual and messy looking stuff in there (e.g. d126fd6#L1R856 )

I may rewrite this in an upcoming release to keep anything 12 col related in a separate file that shall be included using an @import rule.

Benefits of this are the removal of (what is at first glance) odd looking rules and less code downloaded for an unused grid system.

Disadvantage is that inuit.css will become more than one file, which kinda defeats the point of what I was after :(

How to avoid displaying the margin within the nested grids test1 and test2 using a 12 grid fluid layout.

<div class=grids>
  <div class="grid-4">
    <div class="island promo">test</div>
  </div>  
  <div class="grid-4">
    <div class="island promo">test</div>
    <div class="grid-6 ">
      <div class="island promo">test1 margin</div>
    </div>

    <div class="grid-6 ">
      <div class="island promo">test1</div>
    </div>

    <div class="grid-12 ">
      <div class="island promo">test2 margin</div>
    </div>
  </div>
  <div class="grid-4">  
    <div class="island promo">test</div>
  </div>
</div>

There seems to be an issue with the blockquote styling. I think the encoding is getting messed up upon compilation. Inspecting a blockquote element reveals the quotes value to be: "ÔÇ£" "ÔÇØ"

I've tried fixing it with \201C and \201D with no luck.

I’m toying with the idea of adding responsive push and pull classes (merging the responsive namespacing mixin with the existing push and pull classes) however…

They would produce a lot of code. A lot that would likely never get used (you’d typically only want one or two of them, but there’d be dozens in the compiled CSS).

If you gzip and minify your CSS (as you should be) then this isn’t too big a problem, and I will have the classes produced conditionally through the $responsive var so that you can opt to not have them, but it still feels a bit much…

What are anyone’s thoughts?

H

As explained on Gallagher's micro-clearfix-hack using a whitespace inside pseudo-element's content avoids an Opera bug that creates space around clearfixed elements if the contenteditable attribute is also present somewhere in the HTML.

Example: http://codepen.io/anon/full/9454

cf{
zoom:1;
&:before,
&:after{
content:" ";
display:table;
}

I believe there are some design choices baked in inuit.css that should be looked into.

• base/_links.scss

There are many cases I wouldn't want to underline links at all, so I have to cancel those rules. Also, below there's a rule which sets cursor to text on hover if it's a .current link, which doesn't work well if there are images instead of text (text cursor + images = bad UX). Nevertheless, even with text links, it's not something everyone would like, some people prefer default cursor. #93

I suggest removing that component altogether.

• generic/_reset.scss

Maybe changing the cursor on hovering form elements is best to leave to the designer. Using pointer on hover for button elements is perfectly fine, but I don't think using it for text input elements is a common pattern.

• base/_images.scss

Setting height to auto prevents images to ever care for the HTML height attribute.

• base/_paragraphs.scss

I think the multiplier should be configurable.

• objects/_icon-text.scss

I think the margin should be configurable.

• Other

I think symbols like "»" (for breadcrumbs and other) should be configurable.

Well, that's all for now, let me know what you think ;)

Hey mate

/* */ comments will be output to the css, // comments won't be.

I would suggest using // due to the amount of comments. Maybe this is a personal opinion but the benefit of the comments is primarily in dev, particularly with the source being very visible on github.

CI can strip them out, as do some compiler tools for Sass, but there's a chance people will still be outputting these to production and adding a relatively large weight to the file.

When trying to compile/parse inuit.css, Sass gives me the following error:

Syntax error: Invalid CSS after "...bkit-keyframes ": expected "}", was "$animation-name{"
        on line 51 of inuit.css/partials/generic/mixins.scss

When replacing the $animation-name with a hardcoded name, it works.

I don't know Sass/SCSS good enough to know why it does not work and how to fix it, but that seems a bit strange.

The recently added feature has some problems with small screens. When the screen gets to small for the normal width of the image (counted from the height and original ratio) it will fall back to min-width:100%, but the height isn't changed. This results in a really bad looking image:

We can't solve this with media queries, as we don't know the breakpoint/width of the image.

Spacing between elements and clicking area is suboptimal (tested with firefox 16, chrome 21 ) with the current nav--fit.
http://jsfiddle.net/mauropinto/D7UXZ/

It doesn't actually fit (try stretching your browser and the last element will detach from the right); and the spacing between each cell varies depending on the content.

Here's an alternative method, which doesn't suffer from the problems above, but has it's own problem: added spacing at the bottom, noticeable when you want to add a background to the whole element http://jsfiddle.net/mauropinto/AMEPd/

Additional styling/positioning should somewhat fix this problem http://jsfiddle.net/mauropinto/AMEPd/7/

https://github.com/csswizardry/inuit.css/blob/master/inuit.css/partials/base/_links.scss#L12

If i remember right, this could be written as:
a {
&:hover { }
}

The first thing about Sass i noticed useful when my journey with it began - of course it is not an issue, since the code generated will be the same :)

Or may be hover state is written "the css way" to help people understand the source code?

Regards,
Paweł

It's more a question than an issue.

Regarding IE compatibility, do every inline-block should be followed by :

*display:inline;
zoom:1;


? or not necessarily ?

I notice partials/base/_forms.scss line 120 and 139 are not for instance.

I’m thinking of adding in an IE7 grids object, it will work something like this:

http://jsfiddle.net/inuitcss/9Euvj/

It requires a conditional and some extra markup but if you want grids in IE7 then I guess it’s a fair price to pay.

Hi Harry,

Any reason why you're not utilising Sass' ability to make your CSS code more modular and thus moving each 'section' of your code into its own file (thus making it easier to separate/maintain)...

So you could have your code split into the following separate files/directory structure...

• Mixins/_font-size.scss
• Mixins/_vendor.scss
• Configuration/_reset.scss
• Abstractions/_clearfix.scss
• Abstractions/_media.scss
• Abstractions/_island.scss
• Abstractions/_nav.scss

...etc etc.

That way you can @import each file as necessary.

Also for your users, they then have the ease and flexibility to include only the functionality they need within their project (e.g. don't use a reset? fine, don't @import it - a lot easier than having to find the relevant code in a single style sheet and then remove it manually).

Food for thought :-)

I think I might already know the answer to this, but why does the .lede class not make use of your font-size mixin?.

You note that the line-height of .lede is 24px, which implies that the base paragraph size .lede is being applied to is 16px. Now, assuming that's true in a specific use case, why set the values of .lede this way instead of using your mixin?

I have a hunch it's because (as you say further down under $SMALLPRINT) that the mixin is absolute, which would give .lede much less utility. Still, then, that would mean the /*24px*/ comment isn't really accurate except when $base-font-size is 16px. I would remove that comment to remove confusion, maybe?

Just wondering about all this, and I'm probably obsessing a bit over 8 characters of CSS...

Can you share some insight into your thought process for building the .lede class?

h1,.alpha{}
h2,.beta{}
h3,.gamma{}
h4,.delta{}
h5,.epsilon{}
h6,.zeta{}

I think using greek alphabet for class names isn't so intuitive, I suggest just using classes like .h1, .h2 etc.. or like in clothes sizes - s, m, l, xl.

You can just add an alternative class names.

Also, in this situation, clothes size based class names would be much better, because you can always add intermediate values.

.giga{}
.mega{}
.kilo{}

to

.fs-l 
.fs-m
.fs-s

and intermediate values:

.fs-l 
.fs-xm
.fs-m
.fs-xs
.fs-s

I feel like there needs to be a vars.scss file where the default values are defined (incase someone starting a new project won't include their own default values)

Then, there will be another vars file with overrides for the default variables (these do not need the !default identifier)

I would put in a pull request, but I feel like this should be more of a suggestion.

One major benefit in my workflow, is that I am able to make the "inuit.css" folder into a CodeKit Framework by simply cloning the source. Therefore, inuit is available to import into all of my scss projects!

Hi,

I'm thinking of adopting Inuit for a redesign of my work website, but there are places where I'll need to have equal height boxes in such a way that I think only display:table-cell will be adequate.

I've forked your greybox fiddle and added a few extra classes to make this possible (and hopefully consistent / compatible with the rest of Inuit):

http://jsfiddle.net/AndyKirk/8nZLz/
(see the 4 'Ad' boxes)

I just wondered what your thoughts were on this? Also happy to help out more / see this in the framework proper if you feel it's something useful.

Cheers

In breadcrumb object http://jsfiddle.net/inuitcss/9Y6PU/embedded/result/

on my browser 1 and 2 are smaller then 3,4,5 and when I hover over 3,4,5 hover's underline comes over the letters

I love SASS, but you need ruby installed to use it.

An awful lot of people won't have Ruby available, or just don't want to use it.

I for instance, can't use Ruby at University, so I can no longer use Inuit for my uni work.

Would it be particularly hard to provide two versions in the same repository?

http://www.w3schools.com/html5/html5_reference.asp

maybe its usefull changing the nav-tag for html5 markup?

.nav, nav {
    list-style:none;
}
.nav li, nav li {
    display:inline;
}
.nav a, nav a {
    display:inline-block;
}

regards

I am liking the framework so far. My only problem has been "discovery" of all its features. Sometimes I will write some code and then wonder, "is there something in the framework that can handle this?" And then I need to open a bunch of files and search it.

Having the code as documentation is great for when you want to get into the nitty-gritty of the styles, but at a basic level (especially while learning the framework) I just want to know the things I can use and where.

So I'd suggest a brief overview/list of the available classes, and the files they are in. That way it's easier to see at a glance if there is something to suit my purpose, and I can either use it straight off or go look at the code for more details.

I noticed the stats partial was using the "old" flexbox syntax which has mixed support in browsers. The official demo (http://jsfiddle.net/inuitcss/Bpwu6) currently only works in Chrome but it's possible support for this maybe removed as the "new" flexbox syntax is now at Candidate Recommendation status (http://www.w3.org/TR/css3-flexbox/).

To achieve the same outcome, the new flexbox syntax looks like this:

.stat {
    display: flex;
}
.stat__title{
    order: 2;
}
.stat__value{
    order: 1;
}

I've quickly put together a rough looking fiddle (no styling) which will only work in Chrome to demonstrate the new syntax ordering: http://jsfiddle.net/csscallum/J6gQ5/3/.

Personally speaking I fear it maybe too soon to use flexbox. Only Opera have implemented the new flexbox prefix-free and out of the rest only Chrome has it prefixed. IE (10 & 11), Firefox and Safari have implemented the old syntax.

Loving the elegant thinking behind inuit. I'm in the process of using it in a WordPress theme but I have come across an issue. If any files other than _vars and your-project are edited then preprocessing is prevented from continuing further. This applies in both Terminal and CodeKit. Here is the CodeKit log.

Syntax error: Undefined variable: "$base-spacing-unit".
on line 26 of /Users/dave/Downloads/csswizardry-inuit.css-0a516e0/inuit.css/partials/generic/_shared.scss
from line 129 of /Users/dave/Downloads/csswizardry-inuit.css-0a516e0/inuit.css/inuit.scss
Use --trace for backtrace.

(This action was triggered by a change to _grids.scss)

I am aware that the point of inuit is not to edit the framework code, but will always be times when an edit will be required.

I don't think its my config. I'm following Chris Eppstein's article at css-tricks: http://css-tricks.com/compass-compiling-and-wordpress-themes/

I have run one of the commenter's themes, which has a similar structure, through CodeKit and that works fine. https://github.com/mattbanks/WordPress-Starter-Theme

The issue also occurs with the default file structure i.e, outside a WordPress theme directory.

I will undertake more tinkering but wanted to post this in case wiser heads were ahead of me.

Regards

Dave Allen

It’d be nice to have an icon font in inuit.css, and I’d like to use @AdamWhitcroft’s Batch icons.

@AdamWhitcroft is cool with this, and I know @sdmix is able/wants to build it so… let’s get cracking!