Re: [WSG] Semantics vs Light Code
I think that like anything to do with building for the web, it all has to do with what is most appropriate for the project and the audience. If it's for a web site, I's take the path that renders most reliably across browsers/platforms, but if it's for an intranet (or other closed environment when you know the exact makeup of the audience and their equipment), I'd go for the most semantically correct method. In practice, I haven't come across too many examples where you can't strike a (more or less) happy medium. Cam Herrod, Lisa wrote: ... between each link. Just make sure it's with css and not a pipe :) -Original Message- From: Luke Moulton [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 05, 2004 2:51 PM To: [EMAIL PROTECTED] Subject: [WSG] Semantics vs Light Code Recent discussions about building a footer with numerous linked items styled as an unordered list has got me thinking about correct semantics verses light code/css. In using strictly correct semantics to mark-up content I think sometimes we run the risk of developing over complicated and bloated code. Building an inline, styled un-ordered list with appropriate css can add a bit of bulk to your css. So on one hand there's smaller file sizes, uncomplicated CSS (with fewer hacks) but imperfect semantics, and on the other there's perfect semantics bloated CSS with a few hacks thrown in for good measure. Where does one draw the line? Luke Moulton Go4 Multimedia Web Design Graphic Design www.go4.com.au ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Semantics vs Light Code
On Tue, 5 Oct 2004 14:50:49 +1000, Luke Moulton [EMAIL PROTECTED] wrote: Recent discussions about building a footer with numerous linked items styled as an unordered list has got me thinking about correct semantics verses light code/css. So far lightest code I've seen is achieved using semantic coding and CSS. In using strictly correct semantics to mark-up content I think sometimes we run the risk of developing over complicated and bloated code. Building an inline, styled un-ordered list with appropriate css can add a bit of bulk to your css. So on one hand there's smaller file sizes, uncomplicated CSS (with fewer hacks) but imperfect semantics, and on the other there's perfect semantics bloated CSS with a few hacks thrown in for good measure. Where does one draw the line? What are the alternatives? The only 'lighter' version I can think of is unstyled footer with links thrown in. Chances are big that you will want to style those links, so you will have some CSS. As for bloated CSS - I don't think it is appropriate word in this case. And don't forget - CSS is cached. In most cases n*9+9 eight extra bytes for unordered list are not critical, and usually there is a lot of code in other places to strip them off. I every byte counts and there are no more options left - why not to go with 'bare links' version. Regards, Rimantas ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Semantics vs Light Code
On Tuesday, Oct 5, 2004, at 14:50 Australia/Sydney, Luke Moulton wrote: So on one hand there's smaller file sizes, uncomplicated CSS (with fewer hacks) but imperfect semantics, and on the other there's perfect semantics bloated CSS with a few hacks thrown in for good measure. Where does one draw the line? opinion I think it's interesting to see the attention being paid to lean code as part of the embracing of the Standards ethic, and the discussions on same, here and elsewhere. If you code to the best practices that Standards espouses, your bloat will be vastly reduced - if not eliminated - as a matter of course. I started building sites using HTML (...2? 3?) way back when, learning as I went from JZ's Ask Doctor Web series. In those days, even the great man himself was advocating tables, spacer gifs, frames et al. No-one ever paid attention to the amount of code bloat they were generating - apart from trying to keep a total page size under 100KB (!). No-one knew any better. Now we do. The resources available, both in print and online, for start-up developers are amazing. The support of groups like this is amazing. What I can do with CSS these days is - amazing. But I think we should all keep one very clear objective in mind. The aim of the game is not to see how little code, how few bytes, we can use to build our sites. The aim is to communicate a message to an audience. Most of my clients neither know nor care how the code works. They are concerned, however, that their message reaches their target audience, and that hopefully that audience responds to the message in some way. So the line should be drawn at the point where a site's content is accessible by everyone for whom it's supposed to be accessible. The accessibilty gurus on this list is to define that as anyone who can access the medium - with whatever technology they use. And that makes sense (and is, let's face it, just courteous); if you're going to publish to a global audience, why wouldn't you use whatever means you have at your disposal to reach them all? A practical approach is to code for an intended audience. It's up to you to define that audience - whether the entire population of the planet, or a subset thereof that you choose - and code accordingly. If you have to 'bloat' your code - either with additional markup in the name of semantics (totally wrong use of the word, btw, but that's another story...) or with additional CSS to take care of buggy browser support - then do it, if it means your message reaches the audience. If you want to keep it bare bones, then do that. Your shout just won't be quite so loud. /opinion Nick ___ Omnivision. Websight. http://www.omnivision.com.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] Semantics vs Light Code
Recent discussions about building a footer with numerous linked items styled as an unordered list has got me thinking about correct semantics verses light code/css. In using strictly correct semantics to mark-up content I think sometimes we run the risk of developing over complicated and bloated code. Building an inline, styled un-ordered list with appropriate css can add a bit of bulk to your css. So on one hand there's smaller file sizes, uncomplicated CSS (with fewer hacks) but imperfect semantics, and on the other there's perfect semantics bloated CSS with a few hacks thrown in for good measure. Where does one draw the line? Luke Moulton Go4 Multimedia Web Design Graphic Design www.go4.com.au ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
