always a disaster when a designer joins the conversation
I liek to star by urging them to THINK!!!
I think I will switch to coda, once someone flips $$ for it.
The problem with it isn’t just not using only code-view though – EVERY example template and auto-generated code even outside the WYSIWYG just mucks up everything. I have sites that all you have to do is load it into DW, do nothing but hit save, and it breaks the entire blasted layout – that’s just screwed up right there.
That made me chuckle, as one of the things people say about my work… is WOW… that’s definitely not a template (tho I think they are talking about the art direction… but maybe they did look at the source code… as I like show that off… tho am probably not at any of your levels… YET) … then when it comes time for me to custom code for them is when the “template” work is "requested " by the client. With no format, no structure, no content in mind… eventually they ask for "something that we can just plug in stuff as it comes to mind and ‘it displays like in our sketch’) " . Some times they cant tell me if they will have a secondary content such as a sidebar navigation or featured articles or staff… “we might… we dont wanna lock ourselves into anything… (DW preset layout is suggested… which not only offend me as a fledgling coder but as an art director) (followed by previews quote)” it’s really hard as hell to write semantically like that… but really that is or becomes 80% of my potential clients. I have already elaborated at length about their reaction when I try to push proper coding techniques. Which is what I am saying, at least in the chicago-midwest area… it seems the norm is that a coder and /or designer is a filter that magically does exactly what they would do but it there after considered “correct”.
that sounded messy. I mean I had an experience in which someone hired me to mere create a color scheme for their brand, handed me a ready made ( and horribly mismatching and inappropriate color palette )… I though easy $500…48 hours and a presentation later… they were mad I changed any of their colors, yet actually said " we thought you understood … we wanted you to make our colors match… " Essentially, fix what they felt was wrong , but w/o changing anything at all.
always a disaster when a designer joins the conversation
==:P
Seriously, I don’t advocate DW. I am just saying that it is easy to code well in it DESPITE it. It’s just a typing tool. The only advantage that SimpleText has over DW is that when someone who didn’t take the time to learn HTML/CSS gets on it… they get frustrated within right away and QUIT. I suppose that is slightly preferable, if a bit cruel a solution.
Yeah this thread is getting tired… but tonight I came across a PERFECT EXAMPLE of what I been trying to say about the urge to over reduce. Looking the source code for (mint) I saw that in their footer, they have a set of menu columns which they code this way:
<ul class="first left list">
<li class="header">Site Links</li>
<li><a href="/">Home</a></li>
<li><a href="/how-it-works/security/">Privacy & Security</a></li>
<li><a href="/help/">Help</a></li>
<li><a href="/blog/">Personal Finance Blog</a></li>
<li><a href="/mint_sitemap/">Site Map</a></li>
<li><a href="http://answers.mint.com/">Mint Answers</a></li>
</ul>
<ul class="left list">
<li class="header">Your Money</li>
<li><a href="/budget/">Manage your budget</a></li>
<li><a href="/invest/">Understand investing</a></li>
<li><a href="/credit/">Credit card advice</a></li>
<li><a href="/saving-money/">Save money</a></li>
<li><a href="/solutions/debt/">Pay off debt</a></li>
<li><a href="/solutions/student/">Pay off student loans</a></li>
<li><a href="/solutions/retire/">Save for retirement</a></li>
<li><a href="/solutions/taxes/">Get ready for taxes</a></li>
</ul>
...
While this is “valid code” , it is semantically wrong.
They have turned the first LI into a faux header. They should have used a <hx> for the header and a div wrapper, but the “coder” probably thought … , “hey since the UL is a block element already… I will save TWO TAGS, a DIV and an Hx!!!” A prefect example of people coding for presentation and tag reduction, which I think can be just as bad as overusing DIVs.
At the end of the day the amount of <div>'s on a page doesn’t matter to the client. As long as the design looks great, the page renders how you intended it to in the major browsers and the website is getting leads/sales then thats all they’re interested in.
Don’t get my wrong, we should all be striving for clean code yes, but spending ages arguing over whether ‘thats an improper time to use the H3 tag - it should be h4’ is a waste of time.
I think HTML5 goes a long way in reducing the number of divs we use and the more experienced you get using HTML and CSS you start to realise you can style other elements (e.g. unordered lists) to behave as a block level element.
At the end of the day the amount of <div>'s on a page doesn’t matter to the client. As long as the design looks great, the page renders how you intended it to in the major browsers and the website is getting leads/sales then thats all they’re interested in.
Unfortunately this is true. Which is why it’s up to us and us alone to reduce the bloat-boat. I could build our current insurance pages in tables and the bosses wouldn’t know the difference. But I don’t.
I think HTML5 goes a long way in reducing the number of divs we use
Reduces divs by increasing other (new) tags. Total result is more code per amount of content. Which could be okay in my book IF the new “semantics” of the new tags meant anything to user agents… which I expect they will, someday in the future. They don’t mean anything to anyone now.
In fact, the only parts of the new semantics that have gone anywhere are some of the new form input types, and the roles. HTML5 is giving elements roles, which UA’s mostly ignore, but some screen readers are starting to embrace both hand-listed ARIA roles and sometimes also default roles. Roles are pwning semantic tags right now.
Which gives two reasons to work in HTML5 now:
- A chance to learn HTML5 now, so that you’re ready when you do need it.
- Including future functionality right now. At some point these tags (e.g., time) may be widely used and you’ll already have them. This is much like including edge-case CSS3 now: you don’t do it for something core, but it’s nice to have in place for when browsers evolve.
Especially since many of the allegedly “semantic” tags add no new semantic meaning you shouldn’t already have (like heading and list) and are to be slapped around elements that don’t need extra block level containers around them (like heading and list)
Which is why I say HTML 5 is crafted for the people who used to slap tables around everything for nothing, then proceeded to slap div around everything for nothing. Basically the people who still vomit up HTML 3.2 and slap a tranny doctype on it.
Everything old we got rid of because it sucked is new and trendy. As already noted (was it this thread? Too lazy to backread) by someone on these forums, in a lot of places HTML 5 looks like “throwing your hands up and saying oh well” when it comes to expecting people to bother writing good code.
Literally might as well go back to using FONT, CENTER, and ALIGN for all the “improvements” HTML 5 offers.
I think that’s a bit pesamistic myself.
HTML5 is a step in the right direction massively imo.
Relating it to the topic at hand of excessive divs, now that we’re using HTML5, this;
<div class="nav"></div>
can become this;
<nav></nav>
Thats more semantic and you’ve eliminated an extra div! 
You haven’t eliminated anything. You’ve added an element.
This is what you have in HTML4.01Strict (not valid only because the W3C validator has not been updated to understand XHTML2 roles, which have been implemented in HTML at all levels but only recognised by the validator.nu HTML5 validator):
<ul id="nav" role="navigation">
...
</ul>
(if I’m not supporting IE6, I could just leave off the id=“nav” part)
Here’s what you get with HTML5:
<nav>
<ul id="nav">
...
</ul>
</nav>
Definitely added an element, since the only time you wrap a div around a nav ul is when you want/need a background colour/image/border to extend beyond the boundaries of the ul itself. In my case, that has happened but not very often.
What will eventually happen though is the nav element’s default role (which is “navigation”) will become implemented in browsers and will gain semantic meaning. This may pose a problem though when authors want to use ARIA landmark roles, where you may have this:
<nav> (has a native navigation role)
<ul id=“nav” role=“navigation”> (has an ARIA landmark role)
…
Maybe screen readers will get that figured out, but for example NVDA would read out multiple navigation roles, when ideally it should only read out one (the one the author put in the attribute… after all, you don’t want a navigational landmark role on every nav on the page… only the main navigation). That is, they should not announce native or default roles as landmarks.
I expect that to get figured out eventually, but in the meantime I know my code will work much better with current screen readers and current browsers if I stick to HTML4.01 and use landmark roles than mixing half-implemented HTML5 native roles with landmark roles.
But likely my next “new” site will use the HTML5 doctype, shortened attributes and the new form elements, since I know I can always tell the W3C validator to check my site “as if it were XHTML1.0 Strict” to see all real and possible errors. I can do this while still avoiding the funny stuff, the draft stuff and the stuff that’s conflicted in current user agents.
Also, I don’t have to worry about being “ready for the future” with this… user agents are NOT going to drop HTML4 within the next 10 years… and I dare any web site of any size or popularity to last 10 years without some kind of rewrite anyway. Certainly nothing I ever build will last that long. : )
I’ve never liked “nav” as a class/id Since every element on a page is navigation so it’s just a wee bit vague – and swapping a DIV that in 99% of layouts is a completely unnecessary wrapper if you are using semantic tags like UL/OL, for another tag to wap around them instead is NOT the answer! NAV also being so uselessly vague for targeting purposes you’d likely still have a ID or class on it. Falls into the same trap as calling your stylesheet “style.css” or using classnames like “style1, style2” – vague/meaningless/not all that helpful.
Especially when they could have just brought back the MENU tag to do that – but of course instead they brought MENU back for something completely unrelated.
MENU having been deprecated as redundant to UL.
<nav id="mainMenu">
<ul>
<li><a href="#">Home</li>
<li><a href="#">Forums</li>
<li><a href="#">Links</li>
</ul>
</nav>
Is STILL basically the same stupid extra wrapping tag around the UL for NOTHING. UL’s a perfectly good block-level tag… That’s what I mean by the people who used to wrap tables around single elements for nothing now wrap DIV around tags for nothing will just wrap most of HTML 5’s allegedly semantic tags around things… FOR NOTHING.
It’s why when I see code like
<div id="header">
<h1>Site Title</h1>
<div id="mainMenu">
<ul>
<li><a href="#">Home</li>
<li><a href="#">Forums</li>
<li><a href="#">Links</li>
</ul>
<!-- #mainMenu --></div>
<!-- #header --></div>
OR in HTML 5
<header>
<h1>Site Title</h1>
<nav id="mainMenu">
<ul>
<li><a href="#">Home</li>
<li><a href="#">Forums</li>
<li><a href="#">Links</li>
</ul>
</nav>
</header>
I shake my head in disgust – the above being LEAN versions compared to how some folks go about it… when all that really should be needed to do that job is:
<h1>Site Title</h1>
<ul id="mainMenu">
<li><a href="#">Home</li>
<li><a href="#">Forums</li>
<li><a href="#">Links</li>
</ul>
Perfectly good block level containers that unless you’re doing something like sliding doors (and even then) need no assistance from unnecessary parent wrappers.
It’s why I think that if they were going to introduce something like ‘nav’ for their alleged “better for screen reader” nonsense I’m not even sure CAN be implemented in a practical manner, it should probably have been reusing an attribute like ‘rel’ to say what it is instead.
That’s EXACTLY what I mean when talking about HTML 5 being little more than justification for the people who never really got the point of STRICT or semantic markup – and basically just vomit up HTML 3.2 to slap a Tranny doctype on it.
I asked this ina html5 question about the NAV tag a long time ago; but it really would have made more sense if NAV was a LIST of links.
<NAV>
<LI><A href=“#”></A></LI>
<LI><A href=“#”></A></LI>
<LI><A href=“#”></A></LI>
</NAV>
you know someone is going to eventually use it to wrap around a group of paragraphs that have links in them…
<nav>
<p> a long paragraph, blah blaha blah <a href=“#”>a link</a> blh blah bla</p>
</nav>
and wont that be funny?
I think, however the intended use of NAV was W/O the UL… just NAV wrapped around A tags.
That is how it was in the XHTML 2.0 draft that got the axe. I mean¬ I see why it was been done that way. A Nav may consistent of other elements such as a title. You wouldn’t to place that in a list item, so it makes some sense to have the nav element not be a list.
Thing is, there used to be a tag that did exactly that – MENU. It was deprecated along with DIR as redundant to UL for STRICT… Of course MENU is back now for 5 with some other weird purpose that has to do with lists whatsoever.
No… Well, not entirely. All these new allegedly semantic tags are not intended to replace ANY of the existing semantic tags… Look at the examples given in the HTML 5 spec:
<nav>
<ul>
<li><a href="/">Home</a></li>
<li><a href="/events">Current Events</a></li>
...more...
</ul>
</nav>
or worse:
<nav>
<h1>Navigation</h1>
<p>You are on my home page. To the north lies <a href="/blog">my
blog</a>, from whence the sounds of battle can be heard. To the east
you can see a large mountain, upon which many <a
href="/school">school papers</a> are littered. Far up thus mountain
you can spy a little figure who appears to be me, desperately
scribbling a <a href="/school/thesis">thesis</a>.</p>
<p>To the west are several exits. One fun-looking exit is labeled <a
href="http://games.example.com/">"games"</a>. Another more
boring-looking exit is labeled <a
href="http://isp.example.net/">ISP™</a>.</p>
<p>To the south lies a dark and dank <a href="/about">contacts
page</a>. Cobwebs cover its disused entrance, and at one point you
see a rat run quickly out of the page.</p>
</nav>
It’s like the article element or header (check the same page for this example)
<article>
<header>
<h1>The Very First Rule of Life</h1>
<p><time pubdate datetime="2009-10-09T14:28-08:00"></time></p>
</header>
<p>If there's a microphone anywhere near you, assume it's hot and
sending whatever you're saying to the world. Seriously.</p>
<p>...</p>
<footer>
<a href="?comments=1">Show comments...</a>
</footer>
</article>
Extra wrappers that 99% of the time serve no good purpose. I particularly like the date being formatted as a paragraph for no good reason, the lack of content on the time element, etc, etc…
Or worse:
<article>
<header>
<h1>The Very First Rule of Life</h1>
<p><time pubdate datetime="2009-10-09T14:28-08:00"></time></p>
</header>
<p>If there's a microphone anywhere near you, assume it's hot and
sending whatever you're saying to the world. Seriously.</p>
<p>...</p>
<section>
<h1>Comments</h1>
<article>
<footer>
<p>Posted by: George Washington</p>
<p><time pubdate datetime="2009-10-10T19:10-08:00"></time></p>
</footer>
<p>Yeah! Especially when talking about your lobbyist friends!</p>
</article>
<article>
<footer>
<p>Posted by: George Hammond</p>
<p><time pubdate datetime="2009-10-10T19:15-08:00"></time></p>
</footer>
<p>Hey, you have the same first name as me.</p>
</article>
</section>
</article>
Which plays to what I was saying about “thanks to the section and header tags, let’s make EVERYTHING a H1” – at which point why even bother keeping the numbered heading tags in the first place? Because of course making everything the same level heading makes it SO CLEAR the document structure.
For those of you from outside New England, the part in italics above is called sarcasm. When it comes to heading tags, it’s like rather than trying to get people to understand how they work or bothering to clearly define their purpose in English instead of legalese, they’re just giving up and saying “oh well, go ahead and vomit it up any old way”
HEADER in particular bothers me because IMHO it’s redundant to the numbered headings – which with the numbered headings reduced to only ever using h1… Gah, who the **** thinks this is a good idea or even a rational choice?
Though I suspect I know where you got the idea that it should just be anchors inside it – which is NOT semantic markup even in HTML 5. That oh so wonderful web-rot hell that’s been giving bad coding advice for over a decade and a half that people THINK has something to do with the W3C because it starts with W3, when it is COMPLETELY unrelated. You know, the disastrously bad nube-bait?
Pretty much, at this point in the game you can assume anything on W3Schools so far as HTML is concerned is wrong. ESPECIALLY their new HTML 5 stuff that even contradicts the spec in places. Though I’ve begun to suspect the people endorsing it’s use, promoting it’s use, writing online tutorials about it, or releasing books on the subject (like that new SitePoint one) have either failed to read the HTML 5 specification, or simply failed to comprehend it… as IMHO anyone with two brain cells to rub together who does so should be responding with a rather long string of expletives – or at the very least a handful of negative interjections.
[i]Interjections (Aw!) show excitement (Darn!) or emotion (Hurray!).
They’re generally set apart from a sentence by an exclamation point,
Or by a comma when the feeling’s not as strong.
So when you’re happy (Hurray!) or sad (Aw!)
Or frightened (Eeeeeek!) or mad (Rats!)
Or excited (Wow!) or glad (Hey!)
An interjection starts a sentence right.[/i]
Not to quote myself, but was past the edit limit.
I think I may know why there’s so much misunderstanding the 5 specs, it could have something to do with the 5.4 megabyte page size for 2.3 megabytes of plaintext.
Lands sake brake that mess up into sub-pages… it’s damned near unusable in it’s current form.
Of course if you need 5 megabytes – Larger than the King James Bible – to explain a markup specification… It’s time to throw that idiocy in the trash.