CSS

1. CSS Presented by Chris Sanyk

2. CSS: Why take a class? Basic CSS is really, really easy to learn. The language syntax is pretty straightforward. Examples are everywhere. Just ViewSource. The tools needed to develop CSS are free and available on any computer. All you need is a text editor, a web browser, and a few good references.

3. CSS: Why take a class: Advanced CSS can be pretty hard. Complex CSS can be hard to work with. Dealing with browser inconsistencies can be a pain. Keeping up to date with CSS as it develops takes effort as well as patience.

4. Why this class: Most classes I’ve seen or taken have focused on by-the-book basics. I find those are easy enough to pick up on your own. What people really need from a class on CSS is to acquire “street smarts” so they can avoid the traps that ordinarily are discovered and defeated through experience. Hopefully you’ll come out of this with a solid understanding of fundamentals, how to do the basic stuff effectively and efficiently, and maybe a few cool tricks.

5. My Goals NOT to become known as “the CSS guy” I have 3 goals for this class: To help others learn CSS and enable them to work with it, and encourage sharing of expertise. To improve my own comfort and competence with CSS so that I can grow. To build a course foundation that can be re-used by any competent instructor, and improved upon in successive teachings, and potentially packaged and sold as a product. What goals do you have?

6. Student/Audience Where are you at? Silently assess yourself on a 0-4 scale…

7. Your Instructor Overall: 3 Basics: 4 CSS for HTML <form> elements: 2 Browser compatibility: 2 CSS positioning: 2 CSS 3: 1-2 Probably some people in the room know more. Let’s collaborate on making the class better!

8. History Before CSS, HTML used a combination of <elements> and attributes=“” for controlling the presentation of a web page. This was limited at best, and gave rise to really messy ugly code. The worst of it was HTML 3.2.

9. History HTML 4 (and XHTML 1), which has been around since 1999, was a major cleanup of this mess, and was very successful in many ways. 11 years later, we’re just on the cusp of HTML 5. OK, maybe this is also a testament to the slowness of W3C. Much of HTML 4’s success is owed to the success of CSS, especially CSS 2.1.

10. History Initially, HTML was all there was. It handled both describing the structure of a document, as well as how the document should be presented. Presentational aspects of early HTML were fairly limited, both in terms of the effects that could be achieved, and how they were applied to a document element.

11. History Early 90’s: HTML started coming together in the early 90’s (IETF) 1993-94: HTML begins to see real use. NCSA Mosaic launches WWW revolution. Birth of the modern internet. 1995: HTML 2 1996: CSS 1 becomes a W3C recommendation in 1996. It is fairly basic and not widely supported by web browsers right away. No one can use it in the real world.

12. History 1997: HTML 3.2 becomes the first version of HTML to achieve W3C recommendation status. Previously, HTML was just developed by various people and groups. HTML 3.2 mostly consolidated a bunch of proprietary extensions to HTML that had been created by Netscape, Microsoft, and others. Because browsers don’t support CSS well, and because CSS 1 is so limited, a host of presentational HTML elements and attributes are incorporated into the 3.2 spec, turning it into a horrid mess. HTML 3.2 code is bloated, ugly, and hard to read as content becomes buried in a mess of presentational markup.

13. History 1998: CSS 2 becomes W3C recommendation. 1999: CSS 1 finally well-supported in the browser. Beginning of a long period of inconsistent, incomplete support for CSS 2.0 in the browser… and seemingly endless frustration for web developers.

14. History 2003-04 Browsers now have decent support for much of CSS 2, and continue to improve. As of 2008, no browser had fully supported the CSS 2.0 specification. 2009: As of 2009, W3C has only managed to advance CSS 2.1 to “candidate recommendation” status. Despite this, CSS 2.1 is the current dominant de-facto “standard”, and has been reasonably well-supported by browsers since around 2005-6. Sadly, well-supported does not mean “perfectly” or “completely.”

15. Today CSS 3 is emerging. Parts of it are already widely supported by current versions of major browsers. Unfortunately a fair amount of users out there aren’t on the latest versions, so 2.1 is still your best bet. CSS 3 extends and builds on 2.1, so W3C should hurry the hell up and finalize the 2.1 recommendation already.

16. WTF, W3C? W3C risks making itself irrelevant if they can’t release recommendations more quickly. WWW currently has a strong foundation in open standards. This should not be taken for granted. If these standards do not evolve to meet the needs of web developers, we run the risk of losing this openness. Proprietary innovation could overtake open standards. WWW++ could end up being built from proprietary tech such as Flash and Silverlight.

17. On the other hand… Getting 10 (well, OK, more like 5) years use out of something is pretty nice. Not having to learn the latest version every year or so frees you from being stuck in the perpetual learning curve, and allows you to get good. Stability is great… but only if major problems are solved and deficiencies get addressed.

18. CSS weak points Layout Flexible/fluid layout is difficult Columns Lacking Orthoganality (orthowha?) There’s often more than one way to achieve a desired effect, and getting different properties to work together is… screwy. Position, Display, Float: Font sizes and dimensional units. Which do you use, when? How do they work together? Selectors are unable to ascend (there’s no “parent of” selector.) Vertical control (lack thereof, especially with centering). No way to express calculated values. No explicit scope declaration.

19. CSS weak points User agent settings can mess up your style (local custom CSS, font settings, default colors, etc.) This is actually a not a weak point, as it means that ultimately the client has control over their preferences. But this can drive designers and product owners nuts because they don’t have absolute control. Even if the standards remain stable, if the browsers are constantly going through updates and their support of CSS changes over time, you’re shooting at a moving target.

20. The Browser Browser Support for CSS Always lags behind W3C, at least for a while. Sometimes differs from what W3C specifies. (Sometimes browser devs make mistakes, sometimes W3C is vague.) Some browsers also support proprietary CSS extensions (got tired of waiting for slow W3C). This is fine, insofar as W3C does not own CSS; that’s why they’re called recommendations. It does, however, inconvenience web developers when browsers implement CSS support differently. Each browser has a “default” stylesheet that it uses for determining what plain HTML looks like. And each is somewhat different.

21. Browser Support Bottom line: Browser support for CSS is inconsistent. If you’re unlucky, badly interpreted CSS can cause your site to look broken in a particular browser (usually IE). It’s a pain to try to support every platform; it’s sane to support open standards. Try to stay sane. You may not always be able to.

22. Browser Support • Your website will therefore look slightly different in different browsers. • Browsers ignore markup they don’t understand. • Browsers mangle markup they think they understand. • Browsers attempt to render invalid markup, but do so inconsistently.

23. HTML + CSS Stop using HTML attributes for controlling presentational aspects of the web page. Avoid using tables for layout. It’s possible, though difficult, but worth it. Accessibility (508 & WCAG) SEO Let HTML provide logical structure, and let CSS handle presentation.

24. Why use CSS? Advantages of CSS In a word, reusability. CSS saves you work. Declare a style rule once, apply it everywhere you need to. Content from one page can be brought into another without having to re-work the HTML. (In theory.) Reduce burden on web server by providing light-weight markup. Easier maintenance. HTML is more readable. Less work to make changes to the way the site looks.

25. No, really. Why should I bother to learn CSS? Do you really need to know CSS in order to make web sites? Mmmm… maybe not. Consider: do you want to be a codemonkey, or do you want to author content? CMS frameworks do a lot of monkey work for you. They are good. Use them. Even if you’re a codemonkey. Especially if you’re a codemonkey. Use/modify existing templates/themes/etc. Concentrate on your message, and having something interesting to say.

26. Why learn CSS? Control. Customization. Do something unique. You want to understand why the #@%* your web site doesn’t look right in $browser, and fix it. Someone’s giving you money.

27. How to use CSS Connecting CSS to HTML Linked stylesheets Embedded stylesheets Inline style declarations

28. Linked Stylesheets <link rel="stylesheet" type="text/css" href=“mystyle.css" /> The preferred way. An external .css file contains your CSS code, and can be referenced by multiple HTML documents. Maximizes reusability. HTML document can reference multiple .css files, and take on styling from each of them. <link> goes in the <head> element.

29. Embedded Stylesheets <style><!-- /*your CSS here*/ --></style> Not very reusable, since the CSS rules can only be utilized by the HTML document it is embedded within. Useful in the event that you need to make sure the HTML file stays with its CSS markup. Devious “css injection” possibilities… (don’t allow <style> tag in web forums, or users will do bad things to your site.) <style> is w3c-valid only in <head> but most browsers will accept it in <body>

30. Inline style attribute style=“declaration1; declaration2;” <p style=“font-size:10pt; color:red;”> Nearly any HTML element can take a style attribute Inline styles are more specific; that is, they will override rules declared in external or embedded stylesheets. Inline styles are good for ad hoc or temporary solutions, but at the expense of the re-usability of the HTML/content. They’re fine for posting comments to discussion boards.

31. CSS Syntax Selectors Properties Values Comments property:value = declaration. ; = separator. Single declarations or the end declarations don’t technically need ; it is a separator, not a terminator. Selector{property:value;} /* Comment */

32. CSS Syntax Whitespace doesn’t matter (with one important exception.) Format for readability, try to be consistent. CSS itself is not case sensitive. Treat it like it is anyway; some browsers seem to implement it as case sensitive, and urls referencing resources in CSS are case sensitive. p { font-size:10pt; color: red; } div, p, h1 {font-family: arial;} #head {background-image: url(/caseSentitive-url-to/image.jpg);}

33. CSS Syntax: Selectors Universal Named element Class ID * div .myclass #MyID

34. Combinations Class and ID selectors can combine with elements to make a more specific rule: p.myclass{} selects only <p class=“myclass”></p> Not <p></p> Not <div class=“myclass”></div> p#MyID{} selects only <p id=“MyID”></p> Not <p></p> Not <div id=“MyID”></div>

35. CSS Syntax: Selectors (advanced) List of selectors (comma) Descendent selector (space) Child selector Sibling selector h1, .myclass, .otherclass {} .myclass p {} ul > li {} h1 + p{}

36. Classes, IDs Use IDs for unique regions on page, since ID value must be unique for the page. Make ID and Class names semantic, not descriptive. (e.g., .warning -- not .red)

37. CSS Selectors Pseudo-classes :link :visited :hover :active :focus :first-child

38. CSS Selectors Pseudo-element :first-line :first-character :after :before

39. CSS 2.1 Selector Summary

40. Other CSS Fundamentals Font size and dimensional units Colors The Box Model

41. Font size WTF Proportional or Absolute? Absolute units: pt px in cm mm Proportional units: ex em % Each has pros and cons; there is no ideal perfect method. Proportional units are usually the way to go. Absolute units are useful in some cases (print media) Be careful/take advantage of nested proportional sizing.

42. Colors Days of 216 “web safe” colors is long gone. Descriptive color names Only 16 color names are actually W3C standard. +124 (for a total of 140) more color names (orig. Netscape) are widely supported. But does each browser truly render them all identically? These can’t be relied upon absolutely for all user agents; some may not support them at all. System color names (OS-specific; maybe customized by user). #xxxxxx; hex notation #xxx; (shorthand, less precision, saves 3 bytes of bandwidth) RGB(0-255,0-255,0-255) and RGB(0-100%,0-100%,0-100%) (why bother?) Seem to be popular in generated code for some reason. If using number values, it can be helpful to comment with a name or description of the color. End user monitors are very likely not color calibrated, accuracy is not critical.

43. Colors “Transparent” named color Transparency and elements Background color Text Images Gradients

44. The Box Model http://www.blogoff.es/2010/02/01/15-articulos-de-css-para-principiantes/

45. Positioning static (default) relative (offset relative to static) absolute (offset relative to first non-static parent) fixed – position in a fixed position within the window viewpane. Does not scroll. IE support spotty. ( IE >= 7)

46. Float and Clear float and clear are not implemented consistently among all leading browsers. This is why they are sometimes more of a pain than they should be. Blame IE for its bad behavior with float. Usually can be fixed with an extra <div> to wrap the element and float the <div>. Floated elements do not influence the height of their parent. Beware overflowing floats. Use 0-height <div> with Clear after a overflowing Floated element if you need to fix it.

47. Float and Clear float:left or float:right takes the element out of normal flow, and wraps other content around it. If the floated HTML element does not have a defined width, float will not work properly unless you provide a width value. (<p>, <blockquote>, <div>, etc.) The floated element’s width has to be narrower than its parent.

48. Float and Clear clear tells the browser what to do with the next element that comes after a floated element. If an element clears, it will start on the next line, not wrap around the floated element. You can clear:left, clear:right, or clear:both. clear applies to the element occurring after a floated element, not to the floated element.

49. Display vs. Visibility Be aware of distinction between display:noneand visibility:hidden. Display:nonecollapses. Visibility:hidden takes up space.

50. HTML De-<table>-fication <table> was always intended for tabular data. Originally HTML had little/nothing else available for laying out pages. <table> was purposed for this. <table> is reasonably easy to design and is rendered consistently by browsers. You don’t get weird bugs with table based layouts like you will with a <div> based layout.