Add responsive grid classnames for new grid system

[tilomitra]

This pull request is primarily for discussion purposes around the new responsive units. The entire pull request for the new grid system that I'm proposing is here: #146

[msweeney]

@tilomitra Ideally we can come up with more forward looking names than tablet and desktop, which are bound to device types rather than screen sizes. I don't have any good suggestions at this point, but this seems like a good opportunity to decouple screen sizes from device types.

[msweeney]

The new declarations are missing pure- prefix and need a newline after the last rule.

[tilomitra]

Yeah, I'll prettify the newline issue. I didn't add a pure- prefix on purpose since I felt all this is encapsulated within a pure-grid and there was no need to add further bloat to class names that people will be repeatedly typing.

[ericf]

The indentation is also different. For some reason all these Grids changes are using 2 space indentation while the rest of Pure uses 4 spaces.

[tilomitra]

That's because this is getting compiled from a SASS file that I wrote so that I don't have to repeatedly determine the *width for oldIE manually. I'll prettify it once we are ok with the code.

[tilomitra]

Ideally we can come up with more forward looking names than tablet and desktop, which are bound to device types rather than screen sizes.

I thought about this a lot and couldn't come up with anything better at this point. Rather than noodle on it and hold this back, I thought it was best to ship something.

[msweeney]

@tilomitra This seems like a great opportunity to noodle on it.

[tilomitra]

@msweeney We had this discussion a few weeks back with @ericf and I thought about it for a good while. We narrowed it down to a few possibilities:

Semantic names such as tablet, desktop, etc.

Pros

• Easy to understand
• People can add something between them, if they want. They aren't in numerical or alphabetical order.

Cons

• What is a "desktop" to me, may be a "large-tablet" to you.

Names such as small, medium, large

Pros

• Still relatively easy to understand.

Cons

• Hard to place something between med and large due to an inherent order.

More abstract names such as unit-a, unit-b, unit-c

Pros

• Not tied totally with a physical device. The abstractness helps in that regard

Cons

• Hard to understand. Suddenly I need to refer to documentation
• Hard to place something between unit-a and unit-b due to an inherent order.

Given the above choices, I think going with these names are the best option right now. We would just have to make the media query values customizable for it to work well with everyone.

Edit: I didn't want to make it seem like I don't want to think this through. I was just trying to say that having thought through the above, I felt this was the best choice, and I wanted it out in the open for discussion rather than be blocked because we couldn't figure out what to call the classnames.

[msweeney]

@tilomitra I agree that tablet and desktop are the best choices from the above. I think moving from phone to default is a step in the right direction, however, as with unit-a etc., it requires a lookup to determine that it maps to the narrowest view.

I'm not willing to block this PR based on the current names, but I want to give folks the opportunity to chime in with other ideas here.

[AurelioDeRosa]

@tilomitra I'm to have default too

[msweeney]

@AurelioDeRosa To clarify, we are looking for alternatives to tablet and desktop. I'm OK with default, considering we are moving to "mobile" first, but it would be nice to have alternatives to the device-specific semantics.

[AurelioDeRosa]

@msweeney I know. I was just expressing my thoughts on default.

[msweeney]

@AurelioDeRosa OK, cool, I just wanted to make sure I wasn't derailing with my default comments.

[xlnt-webdesign]

@tilomitra What about this:

• XS (phone)
• S (phone landscape)
• M (tablet)
• L (tablet landscape)
• XL (desktop)

This is a relation to a size everybody understands and is able to handle without a documentation and it is device independent.

[tilomitra]

@xlnt-webdesign It has the same issue that every "ordered" naming convention has. Suppose I want to introduce a "phablet" that sits between S and M. It would be hard for me to do so.

[bradleyfalzon]

I was going to suggest it, but I thought that it looked too crap, but have you thought about putting the min-width in the class name? eg unit-320-1-2 unit-480-1 pure-480-visible pure-980-hidden etc? It has it's own set of issues (such as the con listed in arbitrary unit - it's not 100% clear that unit-480 referred to a tablet. But it does solve the issue of slotting in other break point in the future (which is a real world problem). But it does tie the responsive classes to a min-width value (I can't think of a real world case where this would be a problem though).

<div class="pure-grid">
    <div class="unit unit-320-1 unit-480-1-2 unit-980-1-4"></div>
</div>

[ericf]

@tilomitra how come these don't need the old IE star-hack widths, like the Grid units PR?

[tilomitra]

Because they are within media queries and won't get picked up by old IEs.

[ericf]

These are also only 2 decimals instead of 4. We need to understand what that means, and switch them back to 4 if there's no concrete for why they were switched to 2.

[tilomitra]

I rounded it on purpose, based on the results of this article: http://nimbupani.com/using-decimal-percentage-values-in-responsive-design.html

[ericf]

The fundamental issues here are that media queries cannot be overridden, and ideally the content is driving the breakpoints. We are trying to come up with a declarative, generic solution which I think we should continue trying to come up with the best balanced solution we can.

I'd like us to hold off on this and not let it block the other Grids changes we want to implement. Currently I do not like the classnames or media query values. Additionally, we're seeing that device makers are tending towards providing screens at every size, therefore there's becoming less of a gap between "phone", "tablet", and "desktop". This fact leads to content-based break points seeming to be the better approach.

[tilomitra]

This fact leads to content-based break points seeming to be the better approach.

What do you mean by content-based break points?

[ericf]

Creating break points which are determined by the app developer and are driven by the content the page is displaying; i.e. custom per-app. Since the range of device screen sizes is increasing and the old gaps are getting filled in, I don't think it make sense for people to use pre-determined break points. Instead they need to look at their content and decide where the break points should be based on that.

[tilomitra]

I strongly disagree with that. We need to have sensible defaults, and people can over-ride them via the Grid Builder. I already have that functionality in there.

The fact remains that the vast majority of web developers would use some sensible defaults. For those who don't want that, don't pull in grids-r.css, or customize your breakpoints through the Grid Builder.

[tilomitra]

I'm ok with adopting @bradleyfalzon's approach of using the widths in the classnames if that prevents the issue of being unsure of what values to use. It's not pretty, but it works.

Personally, I think it's fine to use tablet and desktop, and let people override those in the Grid Builder (or through a pre-processor), but I don't know if that's the sentiment of the majority.

[ericf]

Personally, I think it's fine to use tablet and desktop, and let people override those in the Grid Builder (or through a pre-processor), but I don't know if that's the sentiment of the majority.

I think this sides with my point, that they are app-specific and content driven. If part of Pure's solution is to provide tooling around generating the media queries, I'm 👍 for that! Given that media queries cannot be overridden by the cascade in CSS, tooling seems like the best option to me.

[tilomitra]

I think this sides with my point, that they are app-specific and content driven. If part of Pure's solution is to provide tooling around generating the media queries, I'm 👍 for that!

@ericf, The Grid Builder already allows you to fiddle with the media queries (click the Edit Default button under Media Queries). Once we merge this in, I can make an update to the GridBuilder to work with this grid so that upon release, we can immediately point to the Grid Builder for folks who want to customize these media queries.

[xlnt-webdesign]

@tilomitra what about breakpoints based on rem or em and a pixel/em fallback. This could be more future save to use cause who knows where the pixel-density race will end. The current record i found is 651ppi. This would trigger tablet mode for an 1inch size display with breakpoints just defined in pixels.

what do you think about rem/ems?

[tilomitra]

@xlnt-webdesign From what I understand, targeting a *-width still work in devices which have a high screen resolution. For example, both the iPhone 4 and the iPhone 3G will respond to a min-width: 480px breakpoint, because Mobile Safari does the "device to pixel ratio" calculation under the hood [1].

That being said, I think it's a good idea for me to revisit these media queries and see how em/rem would work. I remember a conference talk at CSSConf about this, so I'll try to dig that up to get a sense of what the best practices are. Thanks for the feedback! I'll report back here.

[1] http://alxgbsn.co.uk/2010/06/26/targeting-iphone-4-using-css-media-queries/

[ericf]

That being said, I think it's a good idea for me to revisit these media queries and see how em/rem would work. I remember a conference talk at CSSConf about this, so I'll try to dig that up to get a sense of what the best practices are. Thanks for the feedback! I'll report back here.

Yeah we should look at this. But I think if we put effort into our tooling-up of Grid Builder, then do we really need these styles. This is my point.

[tilomitra]

We do, because the percentage of people using GridBuilder is a fraction of people using Pure. Most people using Pure will be ok with some form of media queries that works for a good subset of devices.

If you don't want to use media queries, get the grid-nr.css. If you want more customized media queries, go to the Grid Builder and edit them there. But if you want standard media queries based on what we feel work for an 80% use case, use the grid.css within Pure. That's what I think our story should be.

[seanjacob]

I dislike the semantic names, it is not good for current devices let alone future devices as landscape widths can overlap other devices, and naming in between such as "phablet" is ugly and limited.

Names such as S, M, L is better, future proof and is NOT hard to add something in between such as xs s sm ml l xl xxl etc.

[sdmajor]

I agree with @ericf here #149 (comment)

Read this article, it has some really good points to follow:

http://bradfrostweb.com/blog/post/7-habits-of-highly-effective-media-queries/

and then read about and try out this tool to help educate you better:
http://bradfrostweb.com/demo/ish/

[sdmajor]

Take this page for example, it uses the old way of thinking using device specific widths: http://www.governmentsecurity.org/test/example_html.html

It acts like Pure does right now in the way that it collapses to 100%, if content determined the responsiveness, then this page regardless of device type, size, dpi, etc. would gracefully collapse. The articles that are currently 4 blocks wide would first collapse to 2 wide, then 1

the trending on forums section because its a slider would just get smaller until it eventually collapsed to 1 block.

the code would not have to be edited and adapted every time a new device came along, or one that the design was not tested against. it would just work gracefully.

[ericf]

@tilomitra, should we close this out in favor of a different approach using tooling to generate the media queries since @media can't be overridden in CSS?

[ericf]

I've created rework-pure-grids which allows people to generate custom unit sizes and custom media queries. It basically implements the approach described here and doesn't force Pure to have to choose a one-size-fits-all.

[ericf]

Closing in favor of #267