Appearance - Looks and Feels of Websites
Status: Just notes so far
Pagecode: T->2 A->SAml H->trsa[t,a,si,di]d[t,a,si,di] C->SA[cccej]
Last changed: Friday 2010-09-03 [15:24 UTC]
Abstract:
Modern web applications are usually divided into a three tier model also known as MVC (Model-View-Controller) approach - it starts with the data at the bottom (Model), then comes the logic (Controller) and the presentation (View) sits at the top of the stack. The top is where we connect to the outside world (read humans). This page is about the top layer (View) of a web application, basically all the things that make up for the look and feel of it. Why is this important? Well, studies have shown that humans, when visiting a website for the first time, decide within fractions of a second whether they want to stay or not. Our goal must be to make them stay and come back over and over again in the future. Of course, first and foremost the content (read domain object e.g. traveling, news, music, stocks, etc.) of our website must be of interest to them so they will stay and visit us again in the future. However, even it the content is of interest, visitors still might not stay or return simply because they are not comfortable with how the content is provided to them, how they can add/edit/view it and last but not least, how it looks (color, typography, font, structure, etc.). Most people might think creating the looks and feels for some website is easy when in fact it is not (at least not if the goal is anything else but something that looks like the works of a three-year old). If we look around then I think it is fair to say that more than two thirds of websites on the Internet fail to deliver on that most crucial part. Therefore, everything we do needs to center around the human nature first. Even though human vision is one big corner stone, there are also things like responsiveness of a website, a persons cultural background, time of year, geographical location, personal preference, etc. For example, why not provide different looks based on whether someone visits our website and who is in a hot and humid climate and provide yet another look to someone who is in a cold climatic region - we do have means of geolocation so lets use them! Another important thing we need to think about with any web application is what kind of information/content we present to the user, how much of it and when. The fact of the matter is that only the last steps in this design process (those who directly border the application tier of our web application) are concerned with technology e.g. what tools we use, how and why. At the beginning of any design process is human psychology and understanding how humans tend to process and gather information. The next step might then be about color theory, corporate identity, and maybe only then would we turn our attention to tools, utils, and frameworks used to create an appealing and satisfying user interface for our users. Those individuals who are at the top of the game across all three tiers are a very rare breed since they need to be database experts and system administrators (Model), outstanding programmers (Controller) as well as user interface wizards (View), all in one person. Some even say user interface design can not be learned, talent is or is not. I disagree. As with all things in life, user interface design can be learned (at least to a certain degree). Let us summarize: Appearance is nothing that somehow happens in the progress, rather, it should be something left to professionals with a pragmatic attitude who know a great deal about all of the afore mentioned things. This is what this page is all about, showing how to create good user interfaces which just work and make for happy users.
|
Table of Contents
|
Introduction
At the core of anything told here will be time, the most precious
thing we own. For the same reason we do not want to waste time do we
not want to waste the time of our users. Second, we care about
aesthetics — the overall appearance of a website, even if composed of
numerous bits and pieces, must appear to the user like a piece of
classical music. It only sounds good because each tone is in harmony
with other tones, the sequence they appear in is so that all taken
together form a masterpiece
The whole is more than the sum of its parts.
— Aristotle (384 BC - 322 BC)
The Players
Three things make for the looks and feels of modern web application:
- Structure: HTML
- Presentation: CSS
- Behavior: JavaScript
The Game
What is The Game? What is the aim of the game? How do players
interact, when, and why?
Structure
HTML
div/span and class/id
FAQs
This section gathers FAQs about HTML.
What is the difference between HTML Block and HTML Inline Elements?
In visual browsers, displayable HTML elements can be rendered as
either block or inline. While both are HTML body elements (<body> and
</body>, a container for the displayable content of an HTML document)
and are part of the document sequence, block elements appear within
their parent elements:
- As rectangular objects which do not break across lines and
- with block margins, width and height properties which can be set
independently of the surrounding elements
Conversely, inline elements are treated as part of the flow of
document text i.e. they cannot have margins, width or height set, and
do break across lines.
Page Structure
Inlines
HTML 5
Projects / Tools
HAML
Awestruct
Presentation
Colors
CSS
- http://en.wikipedia.org/wiki/Css
- http://de.wikipedia.org/wiki/Cascading_Style_Sheets
- Examples: http://en.wikipedia.org/wiki/CSS_Zen_Garden
- http://www.w3schools.com/css/default.asp
- http://www.html.net/tutorials/css/
- Headings (h1 elements), sub-headings (h2), sub-sub-headings (h3),
etc., are defined structurally using HTML. In print and on the
screen, choice of font, size, color and emphasis for these elements
is presentational and this is what we use CSS for.
- CSS also defines non-visual styles such as the speed and emphasis
with which text is read out by aural text readers.
- CSS information can be provided by various sources. CSS style
information can be either attached as a separate document or
embedded in the HTML document. Multiple style sheets can be
imported. Different styles can be applied depending on the output
device being used; for example, the screen version can be quite
different from the printed version, so that authors can tailor the
presentation appropriately for each medium.
- A style sheet consists of a list of rules. Each rule or rule-set
consists of one or more selectors and a declaration block. A
declaration-block consists of a list of declarations in braces.
Each declaration itself consists of a property, a colon (:), a
value, then a semi-colon (;).
- In CSS, selectors are used to declare which of the markup elements
a style applies to, a kind of match expression.
Cascading / Priority and Order
- http://en.wikipedia.org/wiki/Css#Sources
- CSS specifies a priority scheme to determine which style rules
apply if more than one rule matches against a particular element.
In this so-called cascade, priorities or weights are calculated and
assigned to rules, so that the results are predictable.
Pseudo Classes and Elements
- Pseudo-classes are another form of specification used in CSS to
identify markup elements, and in some cases, specific user actions
to which a particular declaration block applies. An often-used
example is the :hover pseudo-class that applies a style only when
the user 'points to' the visible element, usually by holding the
mouse cursor over it.
- A pseudo-class selects entire elements, such as :link or :visited,
whereas a pseudo-element makes a selection that may consist of
partial elements, such as :first-line or :first-letter.
- http://www.html.net/tutorials/css/lesson6.asp
- http://css-tricks.com/pseudo-class-selectors/
Box Model
CSS Layout Engines
Conditions and Hacks/Filters
Tips & Tricks
Sprites
CSS Frameworks
What CSS frameworks give us on top of CSS is, in a nutshell, means for
standards-compliant styling our websites across different web browsers
as well as ready-made libraries and tools. Those tools/libraries can
help us reduce overall development time dramatically by doing a lot of
otherwise repetitive and time-consuming work for us.
The basic idea behind most CSS frameworks is that the page should be
divided into an evenly spaced grid for content to line up with. In
print design, this tended to be a vertical and horizontal grid — kind
of like graph paper. For the web, it does not really make sense to set
up a vertical grid since page heights are not fixed and tend to expand
and contract based on the content in them. Because of this, most web
design grids are just evenly spaced columns.
However, in recent months (starting in early 2010) there has been a
major boost in this area and therefore a lot of great ideas already
unfolded into software which we can use to have CSS frameworks/tools
with almost as much flexible as otherwise only possible when doing all
the styling manually from scratch.
In fact this (the lack of flexibility) has always been a criticisms
towards CSS frameworks. So were bloated source code and the lack of
substantial additional features beyond what is already available with
plain CSS. It is probably fair to say that with the arrival of Sass
and Compass this is true no more, in fact, today one has to have good
reasons why to not use a CSS framework but going all manually about
styling websites, over and over again, without the ability to reuse or
share source code and without the ability to ever reduce TTM (Time to
Market).
Actually, for the latter it is quite the opposite, as web applications
will become bigger, the time needed to do styling will simply go up as
well. At some point it will probably become impossible to not use some
CSS framework and the ecosystem that goes with it.
Below are three of the most used CSS frameworks — two of them
(Blueprint and 960) are listed here for reference while the third one
(Susy) will be discussed in detail.
The rationale is that further down the road we will be using Sass and
Compass in connection with Susy — Susy is a semantic CSS grid creator
entirely native to Compass, it is lightweight but yet very powerful
and compared to most other CSS frameworks out there, very modern (read
state of the art technology) and modular in nature.
960
Blueprint
Susy
Susy is a semantic CSS (Cascading Style Sheets) framework creator
entirely native to Compass. Susy is an expert at fluid grids embedded
inside an elastic, fluid, or fixed shell that will never activate the
side-scroll bar.
Susy sets our width on the outer element called container, adds a
max-width of 100% and builds the rest of our grid in percentages.
Using simple mixins, we can create columns, we can suffix and/or
prefix them and also nest them inside each another. All this by using
intuitive and flexible percentage measures and we never have to care
about the maths involved since that is all done by Susy.
FAQs:
This section gathers FAQs about Susy.
What are Susy's Core Principles?
There are two main ideas/principles Susy tries to adhere to — those
are mainly about accessibility and usability but also about aesthetics
of course:
- Responsive to text sizing: In order for our site to be accessible
we need to allow different font-sizes to be set by the client. In
order to maintain design integrity of proportions and line-lengths,
the grid needs to respond to those sizes.
- Responsive to window sizing: In order to maintain usability across
platforms/monitors, our grid needs to respond to the size of the
viewport. This is mainly an issue as the viewport shrinks and we
are given a side-scroll bar. No one likes that. On the large end
our design integrity and line lengths are more important than
taking up all the possible space.
In order to achieve both goals we need to combine the best of the
elastic (em-based) and fluid (%-based) models. The solution is simple:
First we build a fluid grid, then place it inside an elastic shell,
and apply a maximum width to that shell so that it never exceeds the
size of the viewport. It is simple in theory, but daunting in
practice, as we constantly have to adjust our math based on the
context.
Susy harnesses the power of Compass and Sass to do all the math for us
so we do not have to bother about such basic but rather we can instead
focus on what is really important to us, building beautiful and
accessible websites that is.
Why would one be using Susy over other CSS frameworks?
Finally, why would one be using Susy over other CSS frameworks? Well
first of all it is squishy (see core principles and grid types) with a
max-width.
It also has a great typography system which carries the notion of a
vertical rhythm an overall relative measures amongst text size,
margins/padding and spacing in general — it just produces great
results; Susy/Compass is for the web what LateX/ConTeXt is for print.
Again, we consider the ability to handle the elastic/fluid nature of
websites that Susy was built to handle its main advantage over other
CSS frameworks (e.g. Blueprint). What Susy does is, it gives us a grid
that is based on em-units (responsive to font size) as well as
percentages (responsive to small window sizes).
Susy also allows us to choose the fixed or fluid style as standard,
but that is a side benefit of how Susy does things. That is: The Susy
grid works in exactly the same way no matter which style we choose —
the only change is with the width applied to our grid container.
In fact, fluid grids only make sense up to a certain window size — we
do not really want our site to fill a 3-inch monitor without changing
font size, layout or anything else! Why? Well, our line-lengths would
become unreadable and it would just look terrible.
For fluid grids that never get too large, it is recommended that we
take advantage of Susy's default settings. We simply define our grid
in ems, at the largest size we would ever want our site to be. Susy
will act fluid up to that point, and suddenly become elastic ... Et
voilà! We are set for a range screen sizes, from a 30-inch screen all
the way down to 3-inch smart-phones.
Sass
Sass (Syntactically awesome Style Sheets) is best described as a
meta-language/toolset on top of CSS, and is meant to abstract CSS code
and create simpler stylesheet files. Even though Sass is a programming
language, a DSL (Domain Specific Language) to be more precise, we can
only use it to emit CSS.
CSS is the weakest link in the web developers toolbox. The
problem goes deeper than CSS’s lack of variables. Unlike the
“function” in programming, CSS has no fundamental building block.
— A Sass user
CSS has proven to be an effective way to tell a web browser how to
style a web page. But it has failed us as a technology for direct use
by professionals who engineer websites. It should now be viewed more
as an assembly language that higher-level languages emit, but that we
should not be bothered with.
Another important point is that Sass is not a lock-in technology. If
we ever decide that it is not for us, we keep our generated CSS, throw
our Sass away and move along.
The really great news about this approach is that we do not have to
introduce any new technologies for browsers to build or standards to
be adhered to. Instead, we can start using Sass and Compass today and
we do not have to fear entering into something which we could not get
away from if we want/need to.
Sass is also the name for one of two syntax variants possible for Sass
the language/toolset.
Architecture
Interaction with the user is done either through
Haml::Exec (which handles the CLI (Command Line Interface)
utilities),Sass::Plugin (which handles integration with Ruby frameworks and
file watching),Sass::Repl (which handles sass -i, an interactive SassScript
shell), andSass::Engine (which is the main entrance point of the Ruby API).
When given an input string, first that string is parsed. Sass::Engine
handles parsing the indented syntax, Sass::SCSS::Parser handles
parsing SCSS, and Sass::SCSS::CssParser (a subclass of
Sass::SCSS::Parser) handles parsing plain CSS for sass-convert.
When being parsed, the string is transformed into an AST (Abstract
Syntax Tree). AST nodes are subclasses of Sass::Tree::Node, except for
property values, which are subclasses of Sass::Script::Node. In
general any SassScript and property evaluation is handled in the
Sass::Script namespace, whereas other sorts of evaluation are handled
in Sass::Tree.
There are several steps done when compiling the AST to CSS. First it
is performed, which means that all dynamic features including any
SassScript and control directives are run and resolved. Then is it
cssized, which means that any remaining Sass-specific structure is
removed i.e. nested rules are resolved, that sort of thing. Finally,
it is recursively converted to a CSS string.
Language Constructs
Variables
A variable is a simple but important abstraction, by creating a
variable with a name that didn’t exist before, you create a new
concept. That concept is defined in terms of a simpler concept: a
value.
Functions
CSS provides some functions for you to use. For example: rgb(), hsl(),
url(). However, there is no mechanism for defining new CSS functions,
but this doesn’t mean there couldn’t be. For example, in Sass, with a
little ruby programming, you can define your own functions for use
within your stylesheets. For example, the compass-colors extension
provides a handful of very useful functions for manipulating colors.
Expressions
An expression creates a new value by combining other values with
operators and functions. This is itself an abstraction because it
expresses the concept of how to arrive at a new value from other
values. While expressions are more typing and reading than just
specifying a value, they capture the process of creating the values
you used so that later change is simple and others can understand why
the value is what it is.
Mixins
A mixin is the contents of a selector without the selector. We can
think of it as a class whose name is only visible to the stylesheet
for use within that stylesheet for defining other selectors.
Mixins can accept arguments to control their behavior. Mixins can
contain other mixins and they can nest selectors too. Mixins are the
fundamental unit of abstraction in Sass. They are the building
blocks of maintainable stylesheets.
Macro Expansion
Macro expansion is the generation of selectors and styles using
variables, conditionals, looping, and the like. Macro expansion allows
for very high level concepts to be created. For example, a single
mixin can generate a whole grid system.
FAQs
This section gathers FAQs about Sass.
How many different Syntax Variants are there?
Two. SCSS (Sassy Cascading Style Sheets) and Sass — the former is
pretty close to CSS whereas the latter is whitespace aware (e.g. like
Python for example, it is using indentation.
It can also parse CSS but then it is not using the Sass semantics when
it does so — it just parses it as plain CSS. Go here for more
information on the matter.
Can I convert a CSS file into Sass or SCSS syntax?
Yes, by using the sass-convert utility like so sass-convert foo.css
foo.sass or like this sass-convert foo.css foo.scss.
In case we wanted to move an entire project structure of files and
directories living under the ../stylesheets directory over to Sass
syntax, we could do sass-convert --recursive --in-place --from css
--to sass stylesheets/.
Compass
Compass is a stylesheet authoring framework, written in 100% Sass.
There is nothing that Compass does that we could not do ourselves if
we were willing to write all the mixins Compass provides.
However, the magical part is that we do not have to. We can start
working with the abstractions that have been discussed, tested, and
iterated on by a community of designers and front-end engineers. It is
a huge time saver because it allows for abstraction.
Compass is Project aware
As we know, Compass is made of Sass mixins. One might ask, why not use
Sass as is and leave out Compass? The reason is simple, Compass is
project aware whereas Sass is not.
Sass has its own compiler, but it operates on a single Sass file and
generates a single CSS file. Compass on the other hand understands
that we have a complete website and provides a compiler for a whole
directory tree of Sass files (read project).
But distributing a design, is more than just distributing some
stylesheets. There is likely some images. But how can we build
distributable, upgradable stylesheets if those stylesheets need to
refer to an image? Well, we could provide a mixin that takes an
argument, or we could allow a variable to be set that says where it
is. Or, we can use the image_url function provided by Compass that
knows how to write a url, relative to our image path when serving over
a web server or relative to the generated stylesheet itself.
Abstraction
What Compass does is it abstracts out things — think of object
oriented programming, where we can encapsulate logic/functionality
into reusable bits and pieces with a clean and simplified interface
wrapped around that complex logic/functionality.
Benefits of Abstraction
Whether or not we decide to use a framework like Compass, we will
benefit from the capability to express abstraction.
- Browser Compatibility
-
Cross browser compatibility issues can be encapsulated by a mixin that
keeps browser compatibility details hidden and centralized for fixing.
- Clarity of Intent
-
By reading code it should be clear to see where all the values came
from. Since code is read many more times than it is changed, we can
use the power of abstraction to add clarity to the casual reader.
- Change Management
-
Bug fixes and design changes can be made confidently once and
propagated automatically.
- Domain specific style Vocabulary
-
Also known as Work how we think. Abstractions are all named by how we
do design within the mindset of our site as opposed to fixed style
primitives like with CSS for example. Naming our colors things like
engaging_orange and calming_blue help others know when it is
appropriate to use those colors without any additional documentation.
- Organization
-
Easier to keep similar concepts close to each other in code to
optimize coordinated changes.
- Work Faster
-
No need to revisit solved issues time and time again.
- Semantic HTML
-
Writing semantic HTML is about avoiding dependency inversion and
maintaining a separation of concerns. Lofty concepts that reap huge
rewards when we get requirements to do something completely
unexpected.
- Ability to Refactor
-
Refactoring, a programming concept that means to change the
implementation without changing the behavior, is a whole lot easier
now because there is no need to touch HTML to add new CSS classes for
the purposes of reuse.
- Reuse
-
Both internal and across projects, it has never been easier before ...
Downsides to Abstraction
- Learning curves
-
New concepts are new things to learn. Of course, I think a compelling
argument can be made that a site full of legacy styles might be easier
to comprehend once those explicit concepts are well understood.
- Bug fixing
-
Fixing a bug often requires understanding the abstraction at a deeper
level than we thought we had to. This tends to cause a lot of
frustration for people, but it is important to remember that this is
still less time than we would have spent building it from scratch.
- Finding the Source
-
Until around March 2010 it was hard to figure out what piece of Sass
code was responsible to produce a particular piece of CSS. In March
2010 FireSass was released. It is a Firebug plugin which shows us what
particular Sass code produced a particular piece of CSS i.e. it shows
the CSS and its corresponding Sass code.
-
What was possible even before FireSass showed up, was that we could
instruct Sass to emit filenames and line numbers of the original Sass
code as comments into the CSS.
- Toolchain Complexity
-
Adding a compilation phase makes our project build more complex and
places new requirements on those environments where stylesheets are
compiled.
- Documentation
-
Where there is code/functionality, it should be documented. Not sure
if this is a downside, it just is a fact so ...
- The Abstraction does not fit
-
This is a tough one. There are a couple of choices: 1) we do not use
it, 2) we change it, 3) we complain.
-
Once we learn the abstraction (read Compass in this particular case)
we may decide it does not fit. If we do not fully understand the
abstraction, we may think we should use it when we should not — this
is likely going to lead to complaining.
FAQs
This section gathers FAQs about Compass.
Semantics with Sass/Compass?
So let us remember real quick — semantics and syntax, every
programming language has them. We use syntax (grammatical structure)
to express the semantics (meaning).
So when we write x = x + y then this is syntax and it
would tell us the semantics which are add x and y and save the result
into x. Now that was Python syntax. Can we express the same semantics
using another syntax too? Sure, let us use C for example x +=
y. Another one? Sure, common Lisp this time (incf x y).
So, we got three times different syntax (grammatical structure) to
express the same semantics (meaning). Now we know the difference
between syntax and semantics!
Let us make one step from this common discussion into Sass-land. As
for the Python and C statements from above, Sass and SCSS can also
express the same semantics with different syntax — these statements
would then also be semantically the same. LESS and Sass on the on the
other hand have different semantics as well as different syntax.
We know, CSS 3 and Sass have different syntax. We also know, CSS 3 is
the same syntax as SCSS. What Sass brings to the table in addition to
plain CSS is better semantics in the form of logic we can use. This
type of logic is compile time logic to be found within the
presentation tier. It is not to be confused with the type of logic
used inside the application tier e.g. when we use Django for our web
application. The latter would be another tier plus it would be
run time logic.
Nicely spoken sir! What was the initial question again? ;-] Well, we
wanted to know what it means when somebody says Compass has not just a
different syntax but also different (read better) semantics compared
to CSS. We discussed the semantics part above. So now, Compass is
smarter/better because Sass allows for great semantics. Question is,
what can we do with it? Well, we can use it and therefore ease our
lives, save time, and build better web applications.
Shall I use the Sass or the SCSS Syntax with Compass?
Most of us like whitespace aware syntax best, it is more appealing to
the human eye and way of working/structuring things. One prominent
example for such programming language is Python.
As we know, Sass the language/toolset has two syntax variants we can
use — Sass (whitespace aware i.e. indented) and SCSS (Sassy Cascading
Style Sheets). While the Sass syntax is easier to read/write because
of its indented nature, SCSS is more like CSS and therefore used by
most people as they start with Compass and/or Sass the toolset.
So why did the Compass developers make SCSS the default language in
Compass/Sass when in fact the Sass syntax is easier to use and
preferred by most in the community, and, last but not least, what does
that mean for Sass the syntax?
The short version:
Sass and SCSS are a 100% interchangeable and Sass is not going to be
phased out or something. It is quite the opposite actually ... When
Sass was originally conceived, it was designed to get rid of the
syntactic cruft, and make it quicker to write stylesheets. This has
not changed. Why? Read on ...
The long version:
Since Compass switched from Sass 2 to Sass 3 with version 0.10, the
core of what Sass is then became also a lot more technically robust.
This has allowed us to get rid of a number of syntactic annoyances
like the need to use = or #{} in the most common cases
when using SassScript.
On top of this core, there are three parsers, one for the
indentation/whitespace based syntax called Sass, another one for the
CSS superset syntax called SCSS, and one for parsing CSS 3. The way
these parsers work is by translating a stylesheet document into a
syntax agnostic representation called an AST (Abstract Syntax Tree),
which can then be converted to CSS, Sass, or SCSS. This is also what
enables the two, Sass and SCSS, to completely interoperate across
imports.
Starting with Compass 0.10, SCSS will be the default syntax for new
Compass projects, but a simple configuration setting and/or command
line switch puts us right back into Sass-land. In short: We do not
have to use SCSS to write our stylesheets and there is no intention of
deprecating Sass.
The decision to change the default syntax of the files in Compass from
Sass to SCSS has been made because we want as many people to read and
understand it as possible — the majority of designers out there is,
as of now (April 2010), using CSS and therefore all the syntactic
cruft that goes with it i.e. they are used to semicolons, curly
braces, etc.
It is not just about syntax though — there was significant community
feedback that suggests that syntax and semantic changes (e.g. the
availability of SassScript) to the language are too much for new users
to absorb. That said, semantics was left untouched, only the default
syntax was switched from Sass to SCSS. However, as indicated already,
we can import any SCSS files into our Sass based projects by simply
removing the .sass from the end of our imports and work as usual —
SCSS and Sass are 100% interchangeable remember?
So what is the whole point for the switch from Sass to SCSS when in
fact Sass is what any serious designer and professional is going to
use at some point anyways? One word: Adoption.
We want a considerable amount of people join us, come to Sass-land and
see/feel the goodness for themselves. In order for that to happen, we
can not scare them away with syntactical differences to what they are
using right now (read plain CSS and all the syntactical cruft that
goes with it).
There is strength in numbers. For example: We can share our code with
each other, have an easier time hiring, and an easier time convincing
our management to let us use this technology. We will also learn and
develop best practices by collaborating with each other.
So yes, we want to increase adoption because the power of Sass is much
less about how it looks like but rather a lot more about how the
features it provides changes the way we approach building designs for
web application done using Pinax or any other technology out there.
This is why the switch to SCSS as the default syntax in Compass has
been made. This is also why it does not matter for all friends of Sass
syntax like you and me since, behind the curtain, we are going to use
Sass and Sass only anyways.
How can I add a left Gutter?
As of now (April 2010) most people use Blueprint as their
CSS framework below Compass — that might change in favor of Susy
though. However, there is one thing that Blueprint does differently to
e.g. 960.
960 is what its name implies. It is a 960 pixel wide grid. The grid
has 940 pixels of space for content and 10 pixel gutters on the right
and left. The 10 pixel gutter on the left is very important. When a
browser window is smaller than 960 pixels there is a gutter between
the edge of the browser window and the content making it more readable
than if the content went right to the windows edge.
The Blueprint grid is a 950 pixel wide grid with 24 columns. Each
column is 30 pixels wide with a 10 pixel gutter on the right side of
each column. What that does is it puts content up to the browser
window on the left when the window is smaller than the content area.
Some people like that, others do not. From a technical point of view,
there might be situations where this can cause problems with regards
to readability of contents. This is not a problem however since we can
add a gutter to the left side of the content to account for this. Some
possible ways we can add a left gutter when using Compass atop
Blueprint are:
- add 10px left margin to our container
- add 10px left padding to our container
- add a first class to the first grid column in each row and assign
a 10px left margin to the first columns
- create a
+first mixin that accomplishes the same as the above and
apply it as necessary to our selectors
Can I have a Fluid Grid?
Yes, use Susy.
How can I debug my obviously wrong Configuration?
Like this (only first 10 lines):
sa@wks:~$ compass config --debug | head
Configuration sources:
command_line, stand_alone, implied, defaults
***** preferred_syntax = :scss *****
default: :scss, :scss, :scss, :scss
value: -, -, -, -
raw: -, -, -, -
resolved: :scss, :scss, :scss, :scss
***** extensions_path = "/home/sa/extensions" *****
default: "/home/sa/extensions", "/home/sa/extensions", "/home/sa/extensions", "/home/sa/extensions"
value: -, -, -, -
sa@wks:~$
Note however that this only works for Compass since neither Sass nor
Haml read a configuration file.
Install and Configure Compass
Installing and configuring Compass is easy. We can either install the
debian package right away
1 wks:/home/sa# aptitude install libcompass-ruby
2 Reading package lists... Done
3 Building dependency tree
4 Reading state information... Done
5 Reading extended state information... Done
6 Initializing package states... Done
7 Reading task descriptions... Done
8 The following NEW packages will be installed:
9 libcompass-ruby libcompass-ruby1.8{a} libffi-ruby1.8{a} libfssm-ruby{a}
10 libfssm-ruby1.8{a} libhaml-ruby{a} libhaml-ruby1.8{a} libinotify-ruby1.8{a}
11 librb-inotify-ruby1.8{a}
12 0 packages upgraded, 9 newly installed, 0 to remove and 1 not upgraded.
13 Need to get 561kB of archives. After unpacking 2,961kB will be used.
14 Do you want to continue? [Y/n/?] y
15 Writing extended state information... Done
16 Get:1 http://ftp2.de.debian.org unstable/main libhaml-ruby1.8 2.2.22-1 [84.7kB]
17 Get:2 http://ftp2.de.debian.org unstable/main libffi-ruby1.8 0.6.2debian-5 [65.5kB]
18
19
20 [skipping a lot of lines ...]
21
22
23 wks:/home/sa# exit
24 exit
25 sa@wks:~$ compass --version --quiet
26 0.8.5
or we can grab the development version of Compass using RubyGems as
can be seen in line 48. Of course, for it to work, we need to have
rubygems installed which is what we do in line 29. Starting with Ruby
1.9, rubygems is part of Ruby's standard library so we would not have
to separately install rubygems.
27 sa@wks:~$ su
28 Password:
29 wks:/home/sa# aptitude install rubygems
30 Reading package lists... Done
31 Building dependency tree
32 Reading state information... Done
33 Reading extended state information... Done
34 Initializing package states... Done
35 Reading task descriptions... Done
36 The following NEW packages will be installed:
37 rubygems rubygems1.8{a}
38 0 packages upgraded, 2 newly installed, 0 to remove and 1 not upgraded.
39 Need to get 0B/264kB of archives. After unpacking 967kB will be used.
40 Do you want to continue? [Y/n/?] y
41 Writing extended state information... Done
42 Selecting previously deselected package rubygems1.8.
43
44
45 [skipping a lot of lines ...]
46
47
48 wks:/home/sa# gem install --pre compass
49 Successfully installed compass-0.10.0.rc3
50 1 gem installed
51 Installing ri documentation for compass-0.10.0.rc3...
52 Installing RDoc documentation for compass-0.10.0.rc3...
53 wks:/home/sa# gem install --pre compass-susy-plugin
54 Successfully installed compass-susy-plugin-0.7.0.pre7
55 1 gem installed
56 Installing ri documentation for compass-susy-plugin-0.7.0.pre7...
57 Installing RDoc documentation for compass-susy-plugin-0.7.0.pre7...
58 wks:/home/sa# exit
59 exit
60 sa@wks:~$ compass --version --quiet
61 0.8.5
62 sa@wks:~$ which compass
63 /usr/bin/compass
64 sa@wks:~$ gem environment gempath
65 /home/sa/.gem/ruby/1.8:/var/lib/gems/1.8
66 sa@wks:~$ gem environment gemdir
67 /var/lib/gems/1.8
68 sa@wks:~$ $(gem environment gemdir)/bin/compass --version --quiet
69 0.10.0 [6faed20]
70
71
72 [ here we use some editor to edit our ~/.bashrc ...]
73
74
75 sa@wks:~$ source .bashrc; alias | grep 'bin/compass'
76 alias compass_dev='$(gem environment gemdir)/bin/compass'
77 sa@wks:~$ compass_dev --version --quiet
78 0.10.0 [6faed20]
As we can see from lines 61 and 78, the Debian package and the
development version of Compass are different versions. We can use
both, as the one shipped with Debian is on our search path i.e. PATH
anyways, and, the manually installed one we can easily get using its
install directory (line 68).
There are several ways to make the use of the development version of
Compass as comfortable as possible — I choose to add another alias to
my ~/.bashrc as can be seen from line 76. What we also did was to
install Susy in lines 54 to 57. We are going to use it as our
preferred CSS framework with Compass because it is lightweight, modern
and easy to use but yet incredibly powerful.
How to start a Compass Project
79 sa@wks:~$ grep -A3 'compass / sass' .bashrc
80 ###_ , compass / sass
81 export COMPASS_PROJECTS=$HOME/0/compass/projects
82 alias compass_dev='$(gem environment gemdir)/bin/compass'
83 alias cdcompass_projects='cd $COMPASS_PROJECTS'
84 sa@wks:~$ source .bashrc
85 sa@wks:~$ mkdir -p $COMPASS_PROJECTS
86 sa@wks:~$ cdcompass_projects
87 sa@wks:~/0/compass/projects$ type la; la
88 la is aliased to `ls -la'
89 total 8
90 drwxr-xr-x 2 sa sa 4096 Apr 11 12:33 .
91 drwxr-xr-x 3 sa sa 4096 Apr 11 12:33 ..
Lines 79 to 86 only show what I use to do for all my frameworks like
for example Django, Pinax, and now also for Compass. In my ~/.bashrc I
put bunch of environment variables in place and also some aliases in
order to move around quickly on the filesystem.
As for all of the frameworks I use, Compass/Sass also have their
specific directories as can be seen from lines 87 to 91. Currently it
is empty. That is going to change ...
92 sa@wks:~/0/compass/projects$ compass_dev -r susy -f susy my_project_$(compass_dev --version --quiet)
93 directory my_project_0.10.0/
94 directory my_project_0.10.0/src/
95 directory my_project_0.10.0/stylesheets/
96 create my_project_0.10.0/config.rb
97 create my_project_0.10.0/src/screen.scss
98 create my_project_0.10.0/src/print.scss
99 create my_project_0.10.0/src/ie.scss
100 create my_project_0.10.0/src/_base.scss
101 create my_project_0.10.0/src/_defaults.scss
102 exists my_project_0.10.0/stylesheets
103 compile my_project_0.10.0/src/screen.scss
104 create my_project_0.10.0/stylesheets/screen.css
105 compile my_project_0.10.0/src/ie.scss
106 create my_project_0.10.0/stylesheets/ie.css
107 compile my_project_0.10.0/src/print.scss
108 create my_project_0.10.0/stylesheets/print.css
109
110 *********************************************************************
111 Congratulations! Your compass project has been created.
112
113 You may now add and edit sass stylesheets in the src subdirectory of your project.
114
115 Sass files beginning with an underscore are called partials and won't be
116 compiled to CSS, but they can be imported into other sass stylesheets.
117
118 You can configure your project by editing the config.rb configuration file.
119
120 You must compile your sass stylesheets into CSS when they change.
121 This can be done in one of the following ways:
122 To compile on demand:
123 compass compile [path/to/project]
124 To monitor your project for changes and automatically recompile:
125 compass watch [path/to/project]
126
127 More Resources:
128 * Wiki: http://wiki.github.com/chriseppstein/compass
129 * Sass: http://sass-lang.com
130 * Community: http://groups.google.com/group/compass-users/
131
132
133 To import your new stylesheets add the following lines of HTML (or equivalent) to your webpage:
134 <head>
135 <link href="/stylesheets/screen.scss" media="screen, projection" rel="stylesheet" type="text/css" />
136 <link href="/stylesheets/print.scss" media="print" rel="stylesheet" type="text/css" />
137 <link href="/stylesheets/ie.scss" media="screen, projection" rel="stylesheet" type="text/css" />
138 </head>
Lines 92 to 138 is about starting a Compass project using Compass in
its current development version as well as the Susy CSS framework in
its current development version, the ones we installed with lines 48
and 53 respectively. Of course, compass_dev only works because we
build ourselves an alias in my ~/.bashrc as can be seen from line 76.
139 sa@wks:~/0/compass/projects$ la
140 total 12
141 drwxr-xr-x 3 sa sa 4096 Apr 14 19:24 .
142 drwxr-xr-x 3 sa sa 4096 Apr 11 12:33 ..
143 drwxr-xr-x 5 sa sa 4096 Apr 14 19:24 my_project_0.10.0
144 sa@wks:~/0/compass/projects$ du -sh my_project_0.10.0/
145 404K my_project_0.10.0/
146 sa@wks:~/0/compass/projects$ type ta; ta
147 ta is aliased to `tree --charset ascii -a -I \.git*\|*\.\~*\|*\.pyc'
148 .
149 `-- my_project_0.10.0
150 |-- config.rb
151 |-- .sass-cache
152 | |-- 41f90d02892c66026598b74531b77f3b1e2606bc
153 | | |-- _css3.scssc
154 | | |-- _reset.scssc
155 | | `-- _utilities.scssc
156 | |-- 63e43f920f9da19ad363606b847a2e5e6ca7ac2a
157 | | |-- _nowrap.scssc
158 | | `-- _replacement.scssc
159 | |-- 84912882078ea19de6feb59103443596c0c6a009
160 | | |-- _base.scssc
161 | | `-- _defaults.scssc
162 | |-- 8a20f1932f3c762ad4db9f4b5635d41fdcc35f41
163 | | |-- _clearfix.scssc
164 | | |-- _float.scssc
165 | | |-- _hacks.scssc
166 | | |-- _min.scssc
167 | | |-- _reset.scssc
168 | | `-- _tag-cloud.scssc
169 | |-- 8e9739622363678d984c51bbe49dd5e433d3948c
170 | | |-- _background-clip.scssc
171 | | |-- _background-origin.scssc
172 | | |-- _background-size.scssc
173 | | |-- _border-radius.scssc
174 | | |-- _box-shadow.scssc
175 | | |-- _box-sizing.scssc
176 | | |-- _columns.scssc
177 | | |-- _font-face.scssc
178 | | |-- _gradient.scssc
179 | | |-- _inline-block.scssc
180 | | |-- _opacity.scssc
181 | | |-- _text-shadow.scssc
182 | | |-- _transform.scssc
183 | | `-- _transition.scssc
184 | |-- 9078d4cc436542689e1c42ef40c4451d2907c0d5
185 | | |-- _general.scssc
186 | | |-- _links.scssc
187 | | |-- _lists.scssc
188 | | |-- _sprites.scssc
189 | | |-- _tables.scssc
190 | | `-- _text.scssc
191 | |-- ba99b5ac9baf7b5b08cac7fe356b53767cefd7ec
192 | | |-- _alternating-rows-and-columns.scssc
193 | | |-- _borders.scssc
194 | | `-- _scaffolding.scssc
195 | |-- d17e85c048a866eba585e80aed01a502fc9b1846
196 | | |-- _bullets.scssc
197 | | |-- _horizontal-list.scssc
198 | | `-- _inline-list.scssc
199 | |-- d98839f8809f1108727a940a71dc009ad0a5252d
200 | | `-- _sprite-img.scssc
201 | |-- e4e3d1609706bc64588b5eef8b779eff8124f139
202 | | |-- _hover-link.scssc
203 | | |-- _link-colors.scssc
204 | | `-- _unstyled-link.scssc
205 | `-- f74cb806509101f0acc23422bd7a1f59ec304c05
206 | |-- _grid.scssc
207 | |-- _reset.scssc
208 | |-- _susy.scssc
209 | |-- _text.scssc
210 | |-- _utils.scssc
211 | `-- _vertical_rhythm.scssc
212 |-- src
213 | |-- _base.scss
214 | |-- _defaults.scss
215 | |-- ie.scss
216 | |-- print.scss
217 | `-- screen.scss
218 `-- stylesheets
219 |-- ie.css
220 |-- print.css
221 `-- screen.css
222
223 15 directories, 58 files
224 sa@wks:~/0/compass/projects$
The results can be seen from lines 139 to 223. We now have a Compass
project (my_project_0.10.0), build using the Susy CSS framework.
Excellent! We are done now, ready to start working on the presentation
tier for some web application/project.
Colors
- Luminosity and saturation measured in percents (0% - 100%).
- Alpha layer is a unitless number from 0 to 1.
- Hue is measured in degrees (0deg - 360deg).
Functions that operate on these values always take the corresponding
unit to adjust by.
Plugins
fonts
Behavior
JavaScript
FAQs
How do I check whether or not JavaScript is enabled?
This is a very common use case indeed since if we use JavaScript in
our application, we clearly want our users to have their browser
render/use it. The key here is with the <noscript> tag.
The <noscript> HTML tag is used to provide an alternate content for
users that have disabled scripts in their browser or have a browser
that does not support client-side scripting i.e. by using
<noscript>Your browser does not support JavaScript!</noscript>, Your
browser does not support JavaScript! would therefore only be displayed
if scripts are not supported, or disabled in the users browser.
The noscript element can contain all the elements that we can find
inside the body element of a normal HTML page. Please go here for more
detailed information on the matter.
Visualization
jQuery
jQuery, it is a write less, do more JavaScript library. It has many
Ajax and JavaScript features that allow you to enhance user experience
and semantic coding.
FAQs
jQuery in a Nutshell anyone?
Sure, this is what jQuery does:
- select some/all DOM (Document Object Model) elements and lets a
jQuery object reference them so we can
- carry out actions on them
What is a jQuery Object? How is it used?
A jQuery object references DOM elements. Trough it we can carry out
actions on DOM elements.
How does jQuery work? What is Chaining?
With jQuery we issue so-called commands/functions which return a
jQuery objects. Such object is then used to manipulate the DOM or
parts of it. Basically there are two things happening with each jQuery
command/function call:
- We tell it what elements of the DOM we want to select in order to
- carry out some action on/with them.
The point here is, each command does both in one go i.e. 1 and 2 from
above, each time it is called. Thus the returned jQuery object is a
selection of DOM elements with some action already applied to them or
ready to be applied.
This is called chaining in jQuery parlance and fluent interfaces in
general i.e. we can stack several selector parts (1) as well as
several action parts (2) atop each other and then ignite the whole
stack — the result is always a jQuery object no matter how tall this
stack is when ignited.
Command Line Metaphor
One can really think of jQuery as a combination of the command line
grep (the selector part in the chain, 1 from above) with its output
piped to another command line utility (e.g. tr) which carries out some
action (the action part in the chain, 2 from above) on what comes out
at the other end of the pipe e.g.
sa@wks:~$ echo -e "DOM: I am choosen\nDOM: I am not"
DOM: I am choosen
DOM: I am not
sa@wks:~$ echo -e "DOM: I am choosen\nDOM: I am not" | grep choosen | tr '[a-z]' '[A-Z]'
^^^^^^^^^^^^
1 ^^^^^^^^^^^^^^^^^^
2
DOM: I AM CHOOSEN
sa@wks:~$
jQuery Example
A typical jQuery command/function might look like this:
$("div.test").add("p.quote").addClass("blue").slideDown("slow");
^^^^^^^^^^^^^^^^^^^^^^^^^^^
1 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2
The selector part (1), taking as input the current DOM, returning a
jQuery object that finds the union of all div tags with class
attribute test and all p tags with CSS class attribute quote, followed
by the action part (2)**, which effectively adds the class attribute
blue to each matched element, and then slides them down with an
animation.
The $ and add commands/functions affect the matched set, while the
addClass and slideDown affect the referenced DOM elements/nodes.
How can I always use the latest and greatest?
Use <script
src="http://jquery.com/src/jquery-latest.js"></script>.
Equivalence / Shortcuts
$()
$() is equivalent to jQuery(). Read more about it here.
$(function() { })
$(document).ready(function() {
// code to execute when the DOM is ready
});
is equivalent to
$(function() {
// code to execute when the DOM is ready
});
Plugins
Examples
Keyboard Navigation
Gallery and Sliders
Sliders
Google Maps
Layout
Tricks and Tips
jQuery UI
CSS
Modernizr
Ajax
Miscellaneous
CDATA
- http://en.wikipedia.org/wiki/Cdata
- we can enclosed JavaScript in a CDATA tag. This prevents XHTML
validation systems from throwing a wobbly and allows the page to
validate for strict compliance.
XPath
DOM
- SAX http://en.wikipedia.org/wiki/Simple_API_for_XML
- http://en.wikipedia.org/wiki/Document_Object_Model
- http://reference.sitepoint.com/javascript/domcore
- Die ersten DOM-Standards des W3C sind daher Versuche, die
verschiedenen proprietären JavaScript- und DHTML-Techniken, die
während der Zeit der Browserkriege entstanden, zusammenzuführen, zu
standardisieren und letztlich abzulösen. Dies ist gelungen, so dass
DOM heutzutage eine zentrale Bedeutung bei der
JavaScript-Programmierung einnimmt.
- A web browser is not obliged to use DOM in order to render an HTML
document. However, the DOM is required by JavaScript scripts that
wish to inspect or modify a web page dynamically. In other words,
the Document Object Model is the way JavaScript sees its containing
HTML page and browser state.
Django / Pinax
Design Examples
Grid Accordion
Tools
FireSass
Resources
Images / Graphics
Fonts
|
