1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

Any good CSS frameworks other than YAML?

Discussion in 'CSS' started by chriskirk, Feb 14, 2008.

  1. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #21
    Or during - as Mr. Scott said: "the more they overtech the plumbing, the easier it is to stop up the drain."

    The more code you use, the more code there is to BREAK. Also simplified markup makes it easier to restyle the site later on without even touching the HTML - one of the whole reasons to USE css in the first place.

    Pretty much.

    The thing people forget about bandwidth is it works BOTH WAYS. Repeatedly you hear talk about users having broadband - but what is not discussed is that server pipes have NOT really increased in width all that much. If your site suddenly goes to having over two million unique pageviews a month, do you want to pay for a tb of bandwidth for fat bloated presentational markup that isn't even making good use of the caching model, or 50 gigs of bandwidth because you took the time to optimize down the page and study caching models?

    It gets worse when you look at the actual width of the data pipe coming out of the server - a LOT of hosting plans limit you to anywhere from 1-10mbps 'guaranteed', rarely do you see 100mbps or faster outbound unless it's 'burst' meaning you can use it if it's free - just dont rely on it being there.

    Let's say your server is connected at 10mbps 'guaranteed' - during peak hours that's likely all you are going to get... The maximum a 10mbps pipe can serve is 67 megs a minute - though due to things like handshaking this is cut down to a more realistic 30 megs a minute... You get 100 users requesting all at once, a 500K site is going to throttle all those users down to 65k/second... REGARDLESS of how fast their connection is. You drop that to a 100k site, and you are able to serve 650k/sec, roughly the 4mbps common to broadband connections. (mind you, this math is rough and done in my head - feel free to correct)

    ANYTHING you can do to shrink the size of the site - code optimization, better cache hits and sharing of cache across pages, image optimizations - ALL OF THEM contribute to a better experience for the end user AND reduced operating costs for yourself. As I've said a few other places, it can be the difference between choking a dual Xeon with 4 gigs of RAM to death by having requests back up due to outbound pipe limitations, and hosting the same site on a single core P4B with 2 gigs of RAM with processor and bandwidth to spare.

    Though yes, you will gain more through image optimizations and avoiding total crap like Flash - every little bit helps. Why use 100k of markup when 20K will do the job?

    Clean semantic markup, particularly the proper use of header tags, paragraph tags (around actual paragraphs - if it's a 'read more' link or inlined IMG, don't put it in a <p>), actual text with CSS image replacements for things like styled headers and links, etc, etc. will do more for your search engine results than an 90%+ of the rubbish spewed forth by so called SEO 'experts'. Especially if the site in question has actual content of value people might be searching for and is not just another advertising link-whore.
     
    deathshadow, Feb 18, 2008 IP
  2. chriskirk

    chriskirk Guest

    Messages:
    46
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    0
    #22
    I understand your point of view better with respect to proper semantic markup and CSS. I'm an old school C programmer myself and I'm pretty anal even about things like proper indentation of code let alone the semantics of poorly written code. If you know any books or web resources that can help, I'm interested in giving it a try.

    What you say about bandwidth also makes sense on a grander scale, although I'm only serving out something like 20MB per day, obviously having many more page hits can definitely saturate not only the bandwidth but also the server machines hosting the sites. When you refer to "cache hits" are you referring to actual cache hits in the caching layer on the server-side or client browser's and proxy server's caches?
     
    chriskirk, Feb 18, 2008 IP
  3. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #23
    Both actually. Server side smaller files can increase the probability of memory cache hits - client side the more you put into the CSS, the less information the user has to download when they visit a second page on the same site.

    A good example of this is comparing an old school styled menu with the modern approach. The following is a snippet from code someone else wrote:

    <a href="home.html">
    	<img src="images/mmHome.png" width="16" height="16" border="0" alt="Home" />
    	<font size="-1" color="red"><b>Home</b></font>
    </a> |
    <a href="articles.html">
    	<img src="images/mmArticles.png" width="16" height="16" border="0" alt="Articles" />
    	<font size="-1" color="black">Articles</font>
    </a> |
    <a href="forums.html">
    	<img src="images/mmForums.png" width="16" height="16" border="0" alt="Forums" />
    	<font size="-1" color="black">Forums</font>
    </a> |
    <a href="links.html">
    	<img src="images/mmLinks.png" width="16" height="16" border="0" alt="Links" />
    	<font size="-1" color="black">Links</font>
    </a>
    Code (markup):
    643 bytes of code... Let's say you have a 4 page website, you are transferring 2572 bytes total if the visitor goes to all four pages. My rewritten HTML for that was:

    <ul id="mainMenu">
    	<li class="home current"><a href="home.html">Home</a></li>
    	<li class="articles"><a href="articles.html">Articles</a></li>
    	<li class="forums"><a href="forums.html">Forums</a></li>
    	<li class="links"><a href="links.html">Links</a></li>
    </ul>
    Code (markup):
    268 bytes - but it needs CSS, how much?

    #mainMenu {
    	list-style:none;
    	font:normal 12px/16px arial,helvetica,sans-serif;
    }
    
    #mainMenu li {
    	display:inline;
    	padding-left:20px;
    	background:url(images/mainMenu.png) 0 0 no-repeat;
    }
    
    #mainMenu a {
    	color:#000;
    }
    
    #mainMenu .current a {
    	color:#F00;
    	font-weight:bold;
    }
    
    #mainMenu .articles {
    	background-position:0 -16px;
    }
    
    #mainMenu .forums {
    	background-position:0 -32px;
    }
    
    #mainMenu .links {
    	background-position:0 -48px;
    }
    
    Code (markup):
    Which is 471 bytes - which if used on a single page load gives us a total of 739 bytes, more than the original - BUT, if the visitor goes to all four pages of the site, they only total 1,543 bytes transferred, a savings of roughly 1k... If they only visit two pages, you've already more than broken even, and they visit more pages than that, the savings increase exponentially. Do this to a forums menu for example! Average visitor to the largest forums I maintain views 50 separate pages of unique html per day... if the above code examples were seeing that level traffic that would be - per user (of about 2,000 users) - 128,600 bytes using classic HTML with inlined presentation, but only 13,871 bytes by my recode. The more 'retention' you do of users on your page, the more the savings. (imagine the savings on a forums as large as these!) - multiply this across the code of an entire site and not just one tiny snippet... There's a reason when I do estimates for potential clients on recodes of existing sites WITHOUT changing appearance I often estimate the recode delivering a 75% bandwidth use reduction.

    Oh, and a side effect of my recode is it only uses one image - so that's three less handshakes with the server and therin faster pageloads and smoother rendering...
     
    deathshadow, Feb 18, 2008 IP
  4. chriskirk

    chriskirk Guest

    Messages:
    46
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    0
    #24
    The site has been updated to Blueprint. http://www.golfcoursehunter.com

    I changed the DOCTYPE to Strict instead of Transitional which YAML specified by default. However the google stuff doesn't validate of course. I think it's a lot cleaner, but there are still a lot of inlined style attributes that should be moved out to the main css file.

    Let me know if you see anything wrong that stands out.

    thanks
     
    chriskirk, Feb 18, 2008 IP
  5. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #25
    Very first line of code stands out like a sore thumb - the optional XML Prolog means you have to hack around IE6 & 7 being in quirks mode...

    It is div and class happy for no good reason - WAY too much markup for such a simple layout, and the use of presentational classnames (another 'problem' with frameworks) pretty much makes using CSS fairly pointless (since at that point you might as well just inline the presentation. Classes and ID's should say what something is, not how it appears)

    This:
    <div class="column span-6 last maincol">

    is pretty much defeating the entire point of using CSS in the first place, since all that does is trade presentational markup for presentational classes... The problem with a LOT of frameworks.
     
    deathshadow, Feb 18, 2008 IP
  6. SinanCan

    SinanCan Peon

    Messages:
    132
    Likes Received:
    1
    Best Answers:
    0
    Trophy Points:
    0
    #26
    deathshadow; Thank you
     
    SinanCan, Feb 21, 2008 IP