A Better Way

Finding a better way to get things done, a technical journey

Posts Tagged css

My HTML5 Template

Apr 20

Posted by Jack Lawson in Development, Prototyping, Web Design, Web Standards | No Comments

I’ve noticed that whenever I make a site, 99% of the time I copy at least 50% of the markup from another site I’ve done before instead of re-writing the structure. It saves a lot of time, and it makes styling easy- I’m re-styling the same site as I’ve already done, maybe with different colors and images. So, what I’ve done is make a generic template that acts as a site-starter. It’s pretty full, so it may not be to everyone’s tastes, but it covers most scenarios I’ve run into.

Here’s what I use. Feel free to copy it and do whatever you want, it’s GPL v2 licensed. (zip file)

  • The Html5 Shiv (conditionally for IE, of course.)
  • The CSS is Richard Clark’s HTML5 Reset Stylesheet, plus some stub styles like image / text replacement for the h1.
  • Whatever jQuery UI 1.8 theme (if applicable.. most of my sites use jQuery UI, so I added it to my template.)
  • Conditionally, an IE stylesheet. I go ahead and lump IE 6+ into one bucket. This could be broken out into several stylesheets (per IE version), but I’ve found that using the reset sheet generally limits the amount of IE fixes I have to do, so there’s not much wasted download time at all for IE users. If your stylesheet gets too heavy, break it out at your discretion.
  • Several IE conditional statements to build IE wrapper divs to make styling easier. If you’re including styles by version, you probably don’t need this. Also has the added benefit of fast browser version checks with jQuery.
  • Header with heading, subheading. The h1 is a link sometimes, using css image/text replacement. I went back and forth on whether the page title or the site title should be an h1- and chose an h1 based on arguments on this blog post.
  • Seperate nav. I almost put it with header- but I like keeping the header more pure for the logo/title and subheading.
  • A div to wrap all of the content, and then a “maincontent” div. I haven’t found better names yet, so here you go. They’re not section elements, like most of the content is in- the structure is there strictly for styling reasons.
  • An example section. I like giving it an id with the page title, so I can add in page-specific styles as needed.
    • The section’s header, and content, as is reccomended
  • An aside, styled as a right-hand column with subsections
  • A footer, with links (probably the same as the main links), and copyright information. I’ve used an address element to wrap the webmaster’s email. Semantics!
  • Finally, jQuery 1.4.2 and jQuery UI 1.8 pulled from offsite sources (parallelize downloads, plus it’s likely cached from another site)

So, the idea was to get about an hour or two’s work done by simply opening up a file. I think I’ve accomplished this- anything extra I can remove, I can switch the left and right columns pretty easily (or add a third, or fourth), and I have some very basic styles down (just change those grays to something a little more colorful.) Be free, my template!

Reblog this post [with Zemanta]

Tags: , , , , , , ,

The Tables Test

Feb 4

Posted by Jack Lawson in Web Design | No Comments

As I’ve noted before, I believe that you should only use tables if you have an explicit reason to. Here’s the test I use, and I’m totally open for comments and suggestions.

1. Am I going to change the layout much?
If a lot, then I’ll use CSS; and even if it’s only a little, use CSS. It’s easier to make far-reaching changes to a couple classes in a single file, than to modify the HTML structure of several pages. It’s also easier to add a new box, or some kind of widget, to a CSSed design, since they stretch well, unlike many table-based designs that can explode when you go a pixel too far. You can do it with tables, but in the end, it turns out to be a kluge.

2. Am I worried about different screen resolutions?
For me, this is very important; I design from 1024×768 (downgrading gracefully, but not fully supporting 800×600 unless I have to; see stats here) all the way up to 1650. The problem with tables, is it’s tricky to get a well-stretched website; it can be done, but it’s usually akward. So, I always use the CSS way, where I can float elements, and create fixed- and fluid- width columns.

3. Do I care about accessibility?
The answer should always be “yes” here as well. Screen readers have a lot of trouble parsing tabilized content (in what order should it read?), whereas a well-designed, minimalistic HTML structure can be designed to order the content in the way it’s meant to be read, and then placed in the correct places using CSS.

4. Do I ever want to read the code again?
A mess of tag-heavy <table>s,<tr>s, <td>s, and the occasionally sprinkled-in <th> gets in the way; especially if you’ve got more than one nested table. It’s annoying to read the code and get from one logical place to the next. However, with a tag-light mix of <div>s with applied classes and IDs, you can see what’s going on; you can see through all the gunk and mess of the markup and cut straight to the content.

5. Do I care about several media types (print, mobile)?
Tables don’t always render right when printing a page; and they very rarely render correctly on a cellphone. That’s where the @media attribute of CSS comes in; you don’t have to make a totally seperate version of a site to allow your users to print, or to view from their cell. You can specifiy a simpler design that’s easier to print, and a more compact design that’s easier to view on a 340×200 screen with ease.

6. Do I care about search engines?
Search engines do a much better job at reading code-light pages, where the content’s at the top and the markup is light.

7. Is this tabular data?
Use a table.

Tables were awesome back in 1995. But today, the trend is heavily in the favor of CSS and maintainable code for a reason.

Tags: , ,

Re: “Why CSS should not be used for layout”

Feb 2

Posted by Jack Lawson in Web Design, Web Standards, css | 10 Comments

First, read this. Then come back.

I’ll wait here.

…

…

Ok, good. Now, here’s why the article’s complete and total garbage.

On his first point:

The CSS layout primites are inadequate because they do not allow elements to be positioned relative to each other, only relative to their containers.

They don’t? What about floats… do they not effect direct siblings? Can you not change positioning? Maybe I’m missing something here, but we’ve got the ability to change element positioning relative to other elements as well as the container (or even display on the screen at all times (“floating” elements on the screen), or display anywhere on the page). Using the table method that Ron advocates only allows you to position relative to it’s sibling. A table cell, which spans 1-n rows. A table cell that requires you to restructure your HTML (or at least move your content) if you want to move a section from the left, to the right. Whereas I could just swap the float, changing a couple lines of CSS.

The way CSS layout is rendered results in unavoidable interactions between the style sheets and the underlying content. So even when CSS is used exactly as intended, it is not possible to separate content from layout.

Unavoidable interactions? Giving elements IDs (which is good practice anyway), classes, and a <link> tag? Is this worse than creating an immutable structure? Again, perhaps I’m missing something somewhere, but the liquidity of a <div> layout is far superior. It’s changable, it’s easier to get things where you want them to go, it’s less HTML markup gunking up your content. A nicely “divved” layout is cleaner, easier to modify. Yes, I have to add IDs and classes… but a semantic, descriptive markup is far easier to read anyway.

One of the problems with criticising CSS is that it’s very hard to write good CSS, so pointing out problems with CSS begs the question of whether this is an indictment of CSS or one’s coding ability.

Hard for who? And regardless of difficulty, it’s a bit strange to denounce an entire language (markup syntax?) because it’s “hard”. C# and Ruby and Python and baking and riding bicycles can be hard for beginners too.

Ron follows his CSS bashing up with a kluge of examples that do nothing except show he has no idea what he’s doing, and badly mangles examples, saying “look, I reversed it, and it ‘sploded! css sux”.

But the point is they have to be fixed! The correct CSS is inextricably bound to the content. Smarter people than me have tied themselves into knots trying to figure out how to make a three-column CSS layout that doesn’t have these problems. To my knowledge, no one has succeeded. It may be possible.

To his knowledge, nobody’s suceeded? Funny, because several of my own websites use 3-column CSS layouts, without “these problems”. Because I understand how CSS works. Because I’m not afraid to get my hands a little dirty, and because I don’t base my knowledge on display-view of Dreamwaver.

All it comes down to is the ranting of a man who has no idea what he’s talking about. CSS is perfect for layouts. It’s hard, as he readily admits, but once you understand it’s semantics, understand when and how and what to apply, there’s nothing better.

Tags: , ,