Resolution and build of responsive web sites

Pfeewww! I’m lucky I’ve not bumped into this when I was first prospecting SASS.

Don’t get me wrong, I use SASS instead of CSS for some time now. But boy, that’s a wrong example!

First off, he’s using the old, indented syntax. The new SASS is more true to the CSS form, it uses the curly brackets.

Then, the fact that it hides “760px” as “narrow” and “1000px” as “tablet” is… weird, to say the least.

All in all, not something that would make Paul change his mind. :slight_smile:

Also, for Paul to open the terminal and install COMPASS, that would mean Ruby is already installed, and that, normally, SASS is already installed. :wink:

[QUOTE=itmitică;5160469]Pfeewww! I’m lucky I’ve not bumped into this when I was first prospecting SASS.

Don’t get me wrong, I use SASS instead of CSS for some time now. But boy, that’s a wrong example!

First off, he’s using the old, indented syntax. The new SASS is more true to the CSS form, it uses the curly brackets.[/QUOTE]
There’s a difference between sass and scss, http://sass-lang.com/

Then, the fact that it hides “760px” as “narrow” and “1000px” as “tablet” is… weird, to say the least.

All in all, not something that would make Paul change his mind. :slight_smile:

Just names and it’s only an example, the names are only there for the author so it makes no difference.

Also, for Paul to open the terminal and install COMPASS, that would mean Ruby is already installed, and that, normally, SASS is already installed. :wink:

No, if he has Terminal then Ruby will already be installed, unless it’s a really old machine.

gem install compass
Fetching: sass-3.1.3.gem (100%)
Fetching: compass-0.11.3.gem (100%)
Successfully installed sass-3.1.3
Successfully installed chunky_png-1.2.0
Successfully installed fssm-0.2.7
Successfully installed compass-0.11.3
4 gems installed

You really shouldn’t try to one-up people with these posts, I found the video very helpful, if you don’t that’s fine too.

I think I made that perfectly clear when I said “the new SASS”. And we’re talking about different syntax, SASS is always the name of the language.

Unless… it’s a good chance that not everybody is clear on the fact that SASS is a Ruby gem. If you use a third party code editor (like I do), you need to know that in order to compile SASS to CSS. And this is what I do, I don’t rely on automatic compilation, I take control and manually compile SASS to CSS, at my own discretion.

In the case of COMPASS versus SASS. SASS is the first step, and that’s why I said, “normally, SASS is already installed”… by the time you decide to go for COMPASS.

Like it is the case for Ruby on Rails, you first learn Ruby. So I’m saying that one simply makes sure Ruby is installed, then it starts with “gem install sass” and really gets the hang of SASS first before deciding if it needs a framework like COMPASS. And I’m sure not everybody is using blueprint, yui, 960 frameworks.

I don’t just think so, I have arguments.

First off, half the video is not about SASS at all, and in the other half the author is making it clear it’s copying concepts from another author. And it does a poor job at it.

Then, it uses mixins to create repetitive tasks to subordinate media query calls to various elements. For me, this is wrong.

You have, for one media query expression, but one declaration per stylesheet, comprising the whole declarations for all the elements involved in the adjustments to be made for that scenario. That’s the efficient way. Scattering media rules for the same expression all over the stylesheet is just wrong.

Other than that, the powers of SASS are really more obvious and simple. Here are some things that would probably give more incentive to developers to give SASS a try:

http://sass-lang.com/tutorial.html

  • Parent References
  • Variables (my personal favorite)
  • Operations and Functions
  • Interpolation
  • Arguments
  • @import (my personal favorite too)

Keeping up with the SASS techniques in the video, one would end up with a CSS code structure like this:


header {}
[...]
@media A {
  header {}
}
@media B {
  header {}
}

section[role="main"] {}
[...]
@media A {
  section[role="main"]{}
}
@media B {
  section[role="main"]{}
}

footer {}
[...]
@media A {
  footer {}
}
@media B {
  footer {}
}

He’s trying, with the help of SASS, to explain/pass along others idea as to how it would make much more sense to keep media rules separate for every element involved, rather than grouping all media rules for a common expression into the appropriate separate file or section of the document.

I strongly disagree. And involving SASS it doesn’t make the idea a bit more attractive. In real life development, a more suited code structure is this:


header {}
section[role="main"] {}
footer {}

@media A {
  header {}
  section[role="main"] {}
  footer {}
}

@media B {
  header {}
  section[role="main"] {}
  footer {}
}

If I was to try to convince established CSS developers to go for SASS, I’d point them out articles like this one:

As far as SASS and mixins are concerned, this is what I believe to be a useful application in real life development:


@mixin border-radius($radius) {
  -moz-border-radius: $radius;
  -webkit-border-radius: $radius;
  -ms-border-radius: $radius;
  border-radius: $radius;
}

A “simplified border-radius mixin” that demonstrates how you can “use the new CSS3 border-radius attribute in a succinct way”:


a.button {
  background: black;
  color: white;
  padding: 10px 20px;
  @include border-radius(5px);
}

A simple to grasp and powerful example showing what advantages SASS brings to the table:

  • keeping your main code simple, DRY, future proof
  • means to hide the ugliness of the non-standard

It’s also fair to mention that COMPASS it’s not the only comprehensive library of SASS mixins:

https://github.com/MatthieuA/Sass-Css3-Mixins
https://github.com/v-sorokin/sass-mixin-library

and a few more.

To reiterate my SASS-first parallel with Ruby and its Rails framework, like with Rails, COMPASS is not the SASS’s only way to exist.
If one manages RWD without frameworks like 320andup, certainly one would manage to efficiently use SASS without COMPASS.

I, for one, don’t use COMPASS, and I’m managing perfectly fine SASS without it.

Off Topic:

“It’s Not A Bug, It’s A Feature!”

Ok thanks for the discussion guys on compass/sass it’s been very informative but I think we can call that part of the discussion ended now and return to the responsive theme :slight_smile:

Not all websites would fall in this category, patrons of big size pictures. But there are valid cases where you use them.

In those valid cases, if you really worry more about the client, than, no matter mobile or desktop, consider this scenario: you always use smaller size pictures (not necessarily the smallest possible, but small enough in size to qualify as slim and still be good looking), that you scale up if necessary. And this would be your low bandwidth version of the site.

When the user explicitly asks for the high bandwidth version, selecting the visible “High Bandwidth Version” link on your site, you use the bigger size pictures, which, hopefully, are not also bigger in size but are better looking too, in comparison. :wink:

It’s not correct to call RWD expensive. Your content is the one that may be expensive, and that’s the thing you’d want to work on: slimming down the content.

RWD can’t help you with heavy content issues, it’s not its job, it’s not its purpose, it’s not a content related technology, so stop asking that from it.

RWD can only help when it comes to layout. The D in RWD.

In order for your site to fit into any monitor screen, try to use table to organize your designing. This will allow you to centralized the first table and adjust the size as you like. All other tables will be inside the first table

Another option is to use 720px for the width of the table.

You could let the user decide how they want to view your website, but it’ll need either javascript or cookies (or a click every page change). You could then have a default view depending on the device.
I have recently changed how I style my site. I now add a class to the body and rely on cascading to set the rest. eg (CSS)

body.app{}
body.mobile{}
body.regular{}
body.wide{}

.app #main{}
.mobile #main{}
.regular #main{}
.wide #main{}

As they are all in the same CSS sheet, or imported dynamically, I can change the whole site just by changing the className attached to the body. Most areas are the same size in all modes so the difference in the stylesheet is minimal and worth loading all styles in one file.

This is quite good for accessibilty as well, as the mobile mode can be used in a browser and zoomed in really far so the text is very large.

It can also do some quite interesting things. I have recently given up a bit of SEO to make way for aesthetics on my hobby site www.unitingrhythms.com. (being moved and updated from .co.uk) By using position:absolute on all areas I can add css transitions to change the layout in an animated way. Try changing mode in a CSS3 transition enabled browser. (only 2 modes in this site at the moment). Funky :slight_smile:

Too late to edit again! Any number of the above modes can also be responsive (to fit in with topic:))

Okaay… Thanks for the help everyone. The on topic stuff was useful :smiley: