A supplement for non-computer scientists reading Website Architecture Lezione 3: CSS.
All of the PDF is relevant to you guys. CSS still isn't exactly programming, so it's fair game, and it is the language of page design, which is a core part of the course.
The primary colors of light are red, green, and blue; you may have heard the acronym RGB. When projecting light to make color, such as in virtually any monitor or computer screen, you use some combination of red, green, and blue to make any color. The absence of light color is black; the presence of all light colors in full amounts is white.
The most common way to specify RGB colors allows 256 gradiations of R, G, and B. Thus it is conceptually like this:
Color = [0-255] [0-255] [0-255]
Note that 256 * 256 * 256 is 16-million-and-something, and you have probably heard the term "16 million colors" thrown around in monitor or graphics-card specifications. This simply means the monitor can support 256 shades of each color and all combinations thereof.
So, the notation isn't exactly like the one above. It actually looks like this:
#3F88CC (seafoam green)
#999999 (medium grey)
This numbering scheme has a direct correlation to our conceptual example with the [0-255]s. The notation has three groups of two-digit sections which represent R, G, B. They use a numbering scheme that has letters [A-F] as digits. It is called hexadecimal notation ("hex") because each digit goes from 0 to 15 for a total of 16 values. To review, we are used to decimal notation which goes from 0-9 for a total of 10 values. Since we don't have any digits in our vocabulary which mean "11", "12", etc., we use letters instead. The sequence of possible values for each digit is like this:
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B | C | D | E | F
That is one digit. When we have two digits, it is similar to our decimal notation, where you have a "ones place" and a "tens place"; now we have a "ones place" and a "sixteens place". So, in the following table, on the left are values in hexadecimal and on the right are values in decimal. The numbers in the table rows are increasingly large. The hexadecimal numbers have a leading zero just to keep things familiar with how they appear in CSS; hexadecimal does not need a leading zero.
All fonts generally fall into two different categories: serif and sans serif (i.e. "without serif"). This refers to serif markings, which are the little feets at the bottom of some letters and the similar style markings at the ends of other strokes. For example:
This is in a serif font.
This is in a sans-serif font.
This is also in a serif font.
Perhaps one of the most famous (and infamous) fonts is Comic Sans. Now you know how it gets its name, and maybe this can help you remember which one is "sans".
Serif and sans-serif fonts have traditionally appropriate uses. In graphic design, there are no rules, really, but there are conventions. Conventionally, serif fonts are better for copy text in print media and sans-serif fonts are better for copy text in digital media; copy text is the main body of text of the design; e.g. not headings, not the byline, etc., but the body of the news article. If people are going to be reading a lot of text, you want to make it easy on the eyes.
Serif fonts are considered easier to read because the little feets remind people of the connective trails in cursive writing; they help to guide the eye of the reader from one letter to the next. Serif fonts can get difficult to read when they are represented using only a few pixels, however, so it's sometimes best to avoid using them in digital media. This is because print media is almost always of higher resolution than digital media; print media may have 150 dots per inch (DPI) for a decent flyer, 200 or 300 DPI for a sharp, more photographic flyer, and even 600 and far higher DPI for very high-end photos. In contrast, digital monitors typically have 72 or 96 DPI; new monitors, such as the Apple Retina, have around 200-300 DPI, so perhaps you can bend the rules in their case.
You still may choose to make a website using serif font, perhaps because it gives an air of tradition or authority, and you may still want to make headings and other accent text in serif font. We will see more graphic design concepts in future lessons; this is just an introduction.
When specifying a font in CSS, you actually can specify a list of options, from most preferable to least perferable. If you specify this:
font-family: Helvetica, Arial, "Comic Sans", sans-serif;
You are saying that you want Helvetica, then, if they don't have that, Arial, then Comic Sans (multi-word font names should be quoted), then, as a last resort, the browser's default sans-serif font. Each type of browser is different (Windows Firefox, Mac Firefox, Windows Chrome.. etc.), and each person may have different fonts installed, so you never know if you can get your most preferred font, even if you think the font is common, like Comic Sans.
There is a core set of fonts that is generally assumed to exist on all browsers; these are sometimes called "web-safe fonts", and you can see a list on W3Schools. We will see later how you can embed a font into a website, so the font is downloaded when the user visits your site and it can then be used in the design.
Whichever font you choose, you should know that browsers are notoriously notorious in how they render fonts differently. You cannot expect that the same phrase in "the same font" will have the same size (width x height) in all browsers. You cannot assume that it will be "anti-aliased" ( ). So, if you were looking at some small but anti-aliased text on your browser and it was readable to you, it may not be anti-aliased thus it may not be very readable on someone else's browser & monitor.
The only real defense against these problem is to be conservative: make conservative font choices and don't make your text so small that it requires anti-aliasing to be readable.
Font kerning is the horizontal space between characters. Kerning affects readability and the aesthetic quality of the design, mostly in how professional or well-crafted the design looks. In physical media, such as when a guy draws or places each letter in a storefront sign, poor kerning is common. In digital media, and specifically most text areas of websites, you don't usually have to worry about whether the kerning is correct; you should simply be aware that is is another variable and it can vary across different browsers, computers/operating systems, etc.
First, you should recognize that each character in a font has its own conceptual rectangular box, like this:
I'm in a box.
As you may notice, not all boxes have equal width. The letter "i" is a slender letter, and usually, the font designer makes the box narrow to reflect this and take advantage of the opportunity to save horizontal space. Notice; this is a sequence of 10 "i"s:
Not all fonts are designed this way, however. Fonts may be characterized as monospace, in which all characters have the same width. Consider these:
I'm in a box.
For fonts which are not monospace (i.e. most fonts), kerning can be more complicated. The letter sequence "Wi", for example, should probably have a small amount of horizontal space between the box borders - maybe even a negative amount (overlapping) - to avoid wasting space or simply to avoid looking unsightly. So the font designer may actually encode a kerning pair for the character sequence "Wi"; there may be very many kerning pairs encoded in the font.
Consider also the problem that on digital media, all of these minute adjustments in the rendering of fonts - anti-aliasing, kerning, and more - need to be rendered using only a few pixels. Perhaps kerning would move a letter 8% closer to the next letter, but in the digital world and with small font sizes, that's just not enough to knock it down a pixel. Programs that render fonts have very many such decisions to make, and you can bet that different programs will approach this problem in different ways.
Hopefully, the browser or whatever program renders the font can recognize and use the encoded kerning pairs. As designers, we cannot rely on this, however. The lesson here is two-fold. It is valuable to learn that kerning exists and that you can manipulate it to change the character of a graphic design. Perhaps more importantly, it gives you yet another reason to distrust web browsers and remove the assumption that they will render fonts in a consistent manner. You should not expect that some sequence of characters is going to have the same width and height across multiple browsers and platforms. If you want a box of text to have a certain width or height, you have to set it explicitly.
The CSS property letter-spacing lets you affect kerning uniformly; try a value of 0.1ex, for example.
Poor kerning is everywhere and it is often funny. Poor kerning is sometimes called "keming" (note: KEMING). Look for examples online.
All HTML elements (inside of <body>)can be categorized as block elements or inline elements. The basic difference is that block elements appear on their own line and inline elements do not. If you place a block element in the middle of a paragraph, it will force a line break, then show its content, and then force another line break.
A more subtle distinction is that you can set the dimensions of a block element with CSS but not an inline element; an inline element simply becomes as tall and as wide as its content.
It turns out that <div> is an archetypal block element and <span> is an archetypal inline element. They have practically no other properties except being block and inline, respectively. However, you can use CSS to make any element behave like any other element; you can make <p> behave like an inline element, for example. This is probably not a great idea, since you may end up tricking yourself later when you read the HTML code and it doesn't behave how you expect, but you can do it in a pinch. This manipulation is generally done with the display property of CSS. It can take values block, inline, and several others. One notable value is inline-block, which flows like an inline element but lets you set its dimensions.
There are sometimes rules about the containment relationships of elements w/r.t. whether they are block or inline; these rules are generally style guides and violating them will typically not cause the page to break. An inline element should not contain a block element, and the children of <body> should be block elements.
Browsers typically have their own default styles which they apply to elements; for example, Firefox may give all <p> elements a padding of 10px. Every browser is different and you can't exactly assume any default behavior, though browsers do typically have very similar default styles. The important point is that you can always give a style explicitly which overrides this default style; e.g. you can give a margin of 20px or 0px for <p> tags.
These are the four main tools of layouts: float, absolute positioning, relative positioning, and fixed positioning. Each of them can be used in wild and clever ways, but this is a quick reminder of the basic uses.
Moves an element to the right or left side of the page (or container); subsequent text slides upwards as this slides left/right. Typical for inset photos on the left or right side of page, author photos & byline, summary boxes on Wikipedia, etc.
Moves an element to an exact coordinate. Most basically, it is an exact coordinate on the page/document (e.g. 50px from top, 20px from left). However, if you make an absolutely-positioned element within another absolutely-positioned element, the parent/ancestor one becomes a new context for the child/descendant one, and the child/descendant one is positioned relative to the bounding box of the parent/ancestor. Absoltuely-positioned elements scroll with the page content as normal.
Displaces an element relative to where it would occur in the normal flow; it still occupies space in its natural position, so to speak, so words will flow around it. Note that the top/left/bottom/right values are seemingly backwards, so that top: 20px will actually move something down. Commonly, relative positioning is used with zero displacement, because it has a useful side effect. Relatively-positioned elements also establish a new context for children/descendants, so that absolutely-positioned child/descendant elements are positioned relative to the bounding box of the relatively-positioned element.
Fixed positioning is like absolute except it does not scroll when the page scrolls. It's dumb, usually. It is perhaps best used for tiny tool bars on the tops or bottoms of pages.
Z-index can only be applied to "positioned" elements, which are those with a position value in CSS (which is not the default of static; i.e. absolute, relative, or fixed). You may want to give an element relative positioning simply to give it a z-index.
Positioned elements each establish a new "stacking context". It works like this.. You may have sibling elements with z-indexes of 1, 55, 333, and 5000. Within each one of them, though, you have a clean slate which starts back at zero. For example, the children of the element with the 333 z-index may have z-indexes of 1, 2, and 3, which are not comparable to the z-indexes of the layer above (1, 55, etc.); they will all be rendered above the elements with the prior z-indexes of 1 and 55. In other words, z-indexes are not "global" but are only relative to the elements in the same context - the same context as discussed above re: absolute/relative/static positioning.
It is often arduous to make fancy backgrounds, such as multiple layers of background images or the background images used in a rounded-rectangle button. Typically, in CSS 2.1, you would accomplish these layering and composition goals with a bunch of nested container <div>s; this is shown in the examples. CSS3 (see note below) makes this much easier. You don't need to know how to reproduce the fancy backgrounds of CSS 2.1 from memory, but you should generally read them and understand them. It's quite possible (probable) that you will run into a problem which is not so easily solved by CSS3 and you might need to use the same kind of thinking to accomplish what you want.
Moving forward, especially after the course and in your real-world endeavors, you should probably use CSS3, to start with the simple and clean slate that it provides. We will see some examples of these fancy backgrounds using CSS3.
In basically any computer language, there is a way to write "comments", which are typically just notes-to-self which are not treated like code; the program (e.g. web browser) skips over them. There is typically a code sequence which starts a comment and a code sequence which ends a comment. You can also wrap some actual code in these comment markers, meaning that the code is treated like a comment and is not processed; it is skipped. This is "commenting out" code.
HTML comments were mentioned briefly in one of the examples in the Lezione 1 PDF. They look <!-- like this -->.
CSS comments start with /* and end with */.
In common practice, you might give a CSS selector as simply ".SomeClassName", rather than "div.SomeClassName"; note that this selector would then apply to any kind of element, not just <div>s. This is more convenient and actually is more efficient, technically (you won't notice a diffrence), so it is the most common method. This also works for IDs, such as "#theID".
This is actually given in a footnote, but just to reiterate, this is the list of CSS 2.1 properties.
Firebug is a Firefox plugin which is a sort of interactive design-assistance tool. You can click on elements and see their margin, padding, etc., and very much more. We will see it in more detail throughout the course. It is super-helpful, so you might as well get it. Chrome apparently has a similar tool built-in; you would have to look in the Web Developer options or something similar (press F12 to bring up the menu?).
The new version of CSS, styled CSS3, is currently being drafted and is already somewhat supported. It is generally a superset of CSS 2.1, so we are fine for now because what we are learning is still valid CSS3. We will see CSS3 later in the course, when we see HTML5.