<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>

<channel>
	<title>Expert's Advice on CSS Styles</title>
	<atom:link href="http://cssweblog.com/?feed=rss2" rel="self" type="application/rss+xml" />
	<link>http://cssweblog.com</link>
	<description></description>
	<pubDate>Wed, 16 Sep 2009 17:56:15 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Drawing an architecture diagram</title>
		<link>http://cssweblog.com/?p=7</link>
		<comments>http://cssweblog.com/?p=7#comments</comments>
		<pubDate>Wed, 16 Sep 2009 17:56:15 +0000</pubDate>
		<dc:creator>admin</dc:creator>
		
		<category><![CDATA[css tools]]></category>

		<category><![CDATA[page styling]]></category>

		<category><![CDATA[seo]]></category>

		<category><![CDATA[web design]]></category>

		<category><![CDATA[css]]></category>

		<category><![CDATA[styling]]></category>

		<category><![CDATA[web browsers]]></category>

		<category><![CDATA[web tools]]></category>

		<guid isPermaLink="false">http://cssweblog.com/?p=7</guid>
		<description><![CDATA[Even for a simple site like this one, it’s worth drawing an architecture diagram to make you plan out the site’s structure before you start creating graphics and code. An architecture diagram also lets you see the balance of content between the various areas of the site, and forces you to consider what the pages [...]]]></description>
			<content:encoded><![CDATA[<p style="text-align: justify;">Even for a simple site like this one, it’s worth drawing an architecture diagram to make you plan out the site’s structure before you start creating graphics and code. An architecture diagram also lets you see the balance of content between the various areas of the site, and forces you to consider what the pages will be called and the kinds of logical groups into which they are organized. This is very important work in the development of a large site, and worth doing even for this site, which will be only a few pages. Figure 7.4 shows the architectural diagram for the Stylin’ site.<br />
Some presentational aspects of the site are suggested by Figure 7.4, although its primary purpose is to indicate site structure. You can see in the screenshot above that at the top of the architecture diagram I’ve dropped in the wireframe layout of the page (see Figure 7.5), which began as a hand-drawn sketch and then was refi ned on the computer. A wireframe represents a page layout as simple boxes with black-and-white text and gray rectangles for images. There is no effort at this point to represent the visual look of the site, and this allows the focus to be on issues of organization, hierarchy, and overall balance of the layout, without getting sidetracked by determining the right shade of blue or the precise cropping of graphics. There’s a time for such work, but it’s too distracting right now.</p>
]]></content:encoded>
			<wfw:commentRss>http://cssweblog.com/?feed=rss2&amp;p=7</wfw:commentRss>
		</item>
		<item>
		<title>The nature of developing with CSS</title>
		<link>http://cssweblog.com/?p=5</link>
		<comments>http://cssweblog.com/?p=5#comments</comments>
		<pubDate>Sat, 12 Sep 2009 14:10:51 +0000</pubDate>
		<dc:creator>admin</dc:creator>
		
		<category><![CDATA[css tips]]></category>

		<category><![CDATA[css tools]]></category>

		<category><![CDATA[page styling]]></category>

		<category><![CDATA[css advice]]></category>

		<category><![CDATA[seo]]></category>

		<category><![CDATA[web browsers]]></category>

		<category><![CDATA[web design]]></category>

		<category><![CDATA[web tools]]></category>

		<guid isPermaLink="false">http://cssweblog.com/?p=5</guid>
		<description><![CDATA[The nature of developing with CSS means that we can turn a wireframe into a working prototype Web page without the visual design being completed. In the case of icyou.com, which we saw earlier, I first coded a CSS prototype with the basic layout of the key pages, but focused only on the content organization [...]]]></description>
			<content:encoded><![CDATA[<p style="text-align: justify;">The nature of developing with CSS means that we can turn a wireframe into a working prototype Web page without the visual design being completed. In the case of icyou.com, which we saw earlier, I first coded a CSS prototype with the basic layout of the key pages, but focused only on the content organization and user interactions and didn’t worry about visual issues such as coloring type and adding background graphics. Of course, there were numerous minor modifi cations and additions to the CSS as the fi nal visual design took shape. My point is that by escaping from the “slice the fi nished graphics and drop them into a table” development methodology of yore, and moving to a structure-driven CSS approach, the interface coding and visual design can happen as a collaborative and iterative process, rather than one or the other driving the development process by being completed entirely before the other starts.</p>
<p style="text-align: justify;">So let’s begin by laying out the content of the page without worrying too much about colors and graphics in this fi rst pass. Our focus will be on the layout of the content to show its hierarchy and relationships.</p>
]]></content:encoded>
			<wfw:commentRss>http://cssweblog.com/?feed=rss2&amp;p=5</wfw:commentRss>
		</item>
		<item>
		<title>Web Design Is Not Just Visual Design</title>
		<link>http://cssweblog.com/?p=3</link>
		<comments>http://cssweblog.com/?p=3#comments</comments>
		<pubDate>Wed, 09 Sep 2009 09:30:34 +0000</pubDate>
		<dc:creator>admin</dc:creator>
		
		<category><![CDATA[css tips]]></category>

		<category><![CDATA[css tools]]></category>

		<category><![CDATA[page styling]]></category>

		<category><![CDATA[seo]]></category>

		<category><![CDATA[web design]]></category>

		<category><![CDATA[css]]></category>

		<category><![CDATA[css advice]]></category>

		<category><![CDATA[html]]></category>

		<category><![CDATA[styling]]></category>

		<category><![CDATA[web browsers]]></category>

		<category><![CDATA[web tools]]></category>

		<guid isPermaLink="false">http://cssweblog.com/?p=3</guid>
		<description><![CDATA[At the Voices that Matter Conference in San Francisco in October 2007, I heard several designers ask if this structure-driven approach could work for them, as they always start from the visual design of the page and then build from there. First, I think the structural and presentational aspects of the design can develop together, [...]]]></description>
			<content:encoded><![CDATA[<p style="text-align: justify;">At the Voices that Matter Conference in San Francisco in October 2007, I heard several designers ask if this structure-driven approach could work for them, as they always start from the visual design of the page and then build from there. First, I think the structural and presentational aspects of the design can develop together, but when coding begins, the structure has to lead, as it’s the framework on which the presentation hangs. So I think it’s fi ne, and even desirable, to have a visual design in front of you as you start to code. Often, I will take a printout of the page design, and start drawing the boxes that represent divs around the elements, grouping related areas of content together. I will give each of those boxes a name that I will later use as a div ID. If you do this, you can treat those boxes as the basis of your wireframe, then you can lead with the structure and let the visual design be added in as you develop the page’s markup.</p>
]]></content:encoded>
			<wfw:commentRss>http://cssweblog.com/?feed=rss2&amp;p=3</wfw:commentRss>
		</item>
	</channel>
</rss>
