Good code, bad code, it's all about developing good behaviors.

I posted this on another forums a couple weeks ago, recent discussions made me want to share it here and several other forums as well. Being this covers both HTML and full on programming languages, I figured this would be the best spot to place it.

In a number of threads on various forums I have talked about coding habits and Minimalist Semantic Markup. The driving force behind MSM seems to be three rules I learned ages ago when home computing was more myth than fact. It is more than just the 'semantic markup' you hear mentioned, as being semantic is not enough. I coined the term 'minimalist semantic markup' combining my own minimalism with semantic markup for a reason, and am quite proud of the fact a few others have picked up on it.

To review, those rules I learned three decades ago were:

1) Program interfaces should concentrate on the user FIRST. As a programmer put your ego aside and concentrate instead of what the user wants.

2) Proper formatting, indentation and good commenting can prevent more errors than an entire boatload of debugging tools.

3) The less code you use, the less there is to break.

----------------------------------------------

The first of these can be seen by the movement of separating content from presentation, and 'flipping' the design process around backwards to work with CONTENT FIRST. The content is what the visitor is coming to your website to see - EVERYTHING else is secondary, should not get in the way, and in general is not as important. If content is indeed the most important thing on a page, WHY THE DEVIL do 'designers' start out in a paint program drawing pretty pictures, then shoe-horning their content into it? Doesn't sound right to me.

My design process, and the one the handful of us advocating the concept of 'MSM' are advocating, is that you markup your content first using semantic markup with NO CONCERN for what the final page is going to look like. Certainly you might include some DIV containers to group various 'sections' like content and sidebar together, and a master #container div is always a good idea, but apart from that when making your HTML the last thing you should be thinking is 'appearance'. What you should be thinking about is WHAT IS IT I am marking up. Is this a heading, is this heading a subsection of the previous heading or kin to it? If it's kin, is the previous heading a h1? If so then it shouldn't be. Is this a content paragraph? These italics I'm seeing in my copy, is it because of a book title like <i>Moby Dick</i> or text that is getting special emphasis - <em>if you know what I mean.</em> These images I'm adding, are they actually part of the page content warranting an image tag, or are they strictly presentational belonging in the CSS?

Once you have ALL of the content that is going on the page marked up, you start making your layout in CSS, bending that HTML to your will. Wherever possible adding to the html any sort of presentation or extra hangers should be avoided - though inevitably things like image sandbags may be required for things like glider-levin image replaceemnts or sliding doors. Most importantly TEST every major 'section' change in EVERY browser you can lay your hands on AS YOU GO. Time and time again you see on forums people asking "I have this layout completed in FF, and it's broken in IE" - Their biggest mistake was completing the layout before even THINKING about testing it!

Then and ONLY then should you start up the goof assed paint program to hang graphics on your layout.

----------------------------------------------

The second rule is one people have gotten incredibly LAZY about. Over-reliance on tools like htmlTidy, and rubbish like code completion and the 'acid trip' colour syntax highlighting have gotten programmers out of the habit of bothering to JUST WRITE CODE CORRECTLY IN THE FIRST DAMNED PLACE! If you master the tab key, don't go nuts trying to compress everything to a single wrapping line (that **** really torques my nuts) and learn what tags are deprecated in your doctype - guess what? The only thing validation is likely to be needed for is checking to typo's.

Another part of rule 2 is commenting - These days bad commenting is WAY more prevalant than a lack of commenting, and in a lot of cases the comments people use are pointless, silly and in the case of some of them, likely to trip rendering bugs in IE. (the much feared "Double Render" and "Dissapearing Content" quirks)

Take this example: (apologies for taking direct from the source for a certain forums)

<!-- start: nav -->

<div class="navigation">

Code (markup):

No, really? It's the start of the navigation? I never would have guessed that a DIV would be the start of a block, or that the block would be a 'nav' given that it's it's class name is Navigation. This is the PINNACLE of piss poor commenting.

On the flip side we have:

</div>
<!-- end: nav -->

Code (markup):

You don't need to say 'end', we know what </div> means. Likewise wouldn't it be more meaningful to list the classname?

This also puts the comment after the DIV. If in some skin we decide to float that div, the placement of the comment could trip those two pesky IE rendering bugs I mentioned because it would end up between .navigation and the table after. (and tables are well known to do the double render next to floats). Now, saying the name of the close is a good idea if the two end up more than 8-10 lines apart, or for 'major' section blocks so we do want something there - solution? Move the comment BEFORE the </div> - which is why my own style guide says to do it thus:

<!-- .navigation --></div>

Code (markup):

Proper meaningful helpful comments are important - commenting for commentings sake is not. A good writeup on the topic of clear comprehensable code is available on IBM's linux website. It is extremely insightful and I believe should be read by anyone serious about writing code:
http://www.ibm.com/developerworks/linux/library/l-clear-code/

You'll notice I said 'style guide' - I'm a firm believer in consistancy of code formatting. Every programmer should be able to work within a style guide, and for their own use either adopt an existing style guide, or develop their own distributing it with all of your works. It gives other programmers a clue what you are doing - though if you use verbose meaningful classnames with a consistant indentation format, with consistant use of carriage returns to make blocks clear, it is doubtful few will ever have problems with whatever else you do in your 'style'

For reference, the most recent revision of my style guide for HTML/CSS/JS is here:
http://battletech.hopto.org/html_tutorials/styleGuide.txt

I tend to also use the above for my own PHP code for consistancy instead of the 'recommended' which to me is a confusing jumble. God forbid you use the same indenting and formatting styles for HTML, CSS, JS and PHP.

----------------------------------------------

These first two rules combine well with the third rule, which is well known as the KISS theory.

An excellent example of this would be a contact form I was rewriting for a client last month. It was built off a framework example from their goldmine application - and was one of the WORST train-wrecks of code I've seen since the last time I poked my head into a turdpress installation.

First off before we even TALK overcomplicated code, it had major 'logic flow' and security issues. The goldmine template for a contact form passes the username, password and URL to the e-mail server in a simple subtractive hex hash in hidden inputs IN THE FORM SENT TO THE USERS BROWSER!!! Anyone who knows what algorythm is used to encode this data could simply view source on the contact form, then hijack the e-mail server for their own purposes. WHAT NIMROD THOUGHT THIS WAS A GOOD IDEA?!?

Worse, the code they used to decode the hash was unbelievably overthought. Get a load of this PHP:

function Decode($strValueIn) {
//Do not modify this function!
$intX = 0;
$intY = 0;
$Temp = "";
$Mod = "";
$intMod =0;
$intTemp = 0;
$ValueOut = "";
$intY = 1;
$strValueOut="";
for ($intX=1; $intX<=((strlen($strValueIn)/2)/2); $intX=$intX+1) {
    $strTemp="";
    $strMod="";
    if (($intX % 2)==0) {
      $strMod=substr(substr($strValueIn,$intY-1,4),0,2);
      $strTemp=substr(substr($strValueIn,$intY-1,4),strlen(substr($strValueIn,$intY-1,4))-(2));
    } else {
      $strMod=substr(substr($strValueIn,$intY-1,4),strlen(substr($strValueIn,$intY-1,4))-(2));
      $strTemp=substr(substr($strValueIn,$intY-1,4),0,2);
    }
    $intMod=hexdec($strMod);
    $intTemp=hexdec($strTemp);
    $intTemp=$intTemp-$intMod;
    $strValueOut=$strValueOut.chr($intTemp);
    $intY=$intY+4;
  }
  return $strValueOut;
}

Code (markup):

Sweet Jesus H jumped up Mary and Joseph! If you know ANYTHING about programming, you will know how STUPID the above code is - for those of you not in the know, let me explain.

First, the variables intX, IntY, inMod, IntTemp do NOT need to be initialized before the loop - that code does nothing.

The variables Temp, Mod and ValueOut aren't even used anywhere.

The subtraction of two on each strMod and strTemp calculation serves no purpose since that could be inlined. The multiple redundant calls to the SAME substr function slows the routine to a crawl, as do the repeated calculations of numbers that do not change... and frankly there's no reason to be tracking intX separate from intY.

This is functionally identical - does the EXACT SAME THING:

function myDecode($inString) {
	$result='';
	$t=0;
	while ($t<strlen($inString)) {
		$top=hexdec(substr($inString,$t,2));
		$t+=2;
		$bottom=hexdec(substr($inString,$t,2));
		$t+=2;
		$result.=chr(($t%8)==0 ? $bottom-$top : $top-$bottom);
	}
	return $result;
}

Code (markup):

Mind you, this is PHP, I can see people getting a bit confused in php or lost on the 'complexity' of writing a program - but it gets worse when you see the EXACT SAME STUPIDITY in people's markup.

Time and time again you'll see stuff like: (my apologies for borrowing from a certain forum's code output)

				<span class="links">
<div style="display: none;" class="popup_menu" id="example_popup">
<div class="popup_item_container"><a href="http://www.somesite.com/search.php" class="popup_item">Search</a></div>
<div class="popup_item_container"><a href="http://www.somesite.com/memberlist.php" class="popup_item">Memberlist</a></div>
<div class="popup_item_container"><a href="http://www.somesite.com/calendar.php" class="popup_item">Calendar</a></div>
<div class="popup_item_container"><a href="http://www.somesite.com/misc.php?action=help" class="popup_item">Help</a></div>
<div class="popup_item_container"><a href="#" onclick="MyBB.popupWindow('http://www.somesite.com/misc.php?action=buddypopup', 'buddyList', 350, 350);" class="popup_item">Buddy List</a></div>
</div>
<a href="javascript:;" id="example" class="popup_button">Quick Links <img src="http://www.somesite.com/images/da/dropdown.png"></a>
<script type="text/javascript">
new PopupMenu('example');
</script>
				</span>

Code (markup):

For those of you NOT familiar with what's wrong, lemme spell it out. SPAN is an inline level container, as such it cannot EVER contain block level elements - like DIV. That's invalid markup and we're not even past the first line of this section.

It is quite obviously a list of options - so why is it even done up as div's? The next div has a perfectly good ID AND class, why the inline style="display:none"? NOT that display:none should be used on content if you care about graceful degredation and accessability, there's a reason left:-999em is preferred.

If every single DIV inside #example_popup is going to have that same popup_item_container class on it, why the hell bother with a class in the first place since there are no other div's in here? The same applies to the 'popup_item' class which also serves NO PURPOSE WHATSOEVER. It gets worse thanks the absolute links just chewing bandwidth for NO GOOD REASON, and then to top it off is this stupid anchor tied to javascript for the popup - how 1997 of them.

There is no reason for the markup of that section to be more than:

<div class="quickLinks">
	Quick Links
	<ul>
		<li><a href="search.php">Search</a></li>
		<li><a href="memberlist.php">Member List</a></li>
		<li><a href="calendar.php">Calendar</a></li>
		<li><a href="misc.php?action=help">Help</a></li>
		<li><a href="misc.php?action=buddypopup">Buddy List</a></li>
	</ul>
<!-- .quickLinks --></div>

Code (markup):

EVERYTHING ELSE should be applied via the CSS, with a behavior file to implement :hover in older versions of IE (I would suggest peterned's 'hoveranyhwere' csshover2.htc).

It's train wrecks like this that blow my mind - what are people thinking when writing code like this? Time and time again you see people throwing DIV's, classes and ID's in their code for no good reason.

Another thing you see is tag abuse - repeatedly you see elements that aren't paragraphs being thrown into paragraph tags. Single words and sentance fragments should NOT go into paragraph tags unless they are inline in content flow. A footer copyright line of piecmealed sentence fragments is not a paragraph - an image is a plate, not a paragraph... and whenever you use a tag or attribute ask yourself "DO I NEED THIS TAG" - if the answer is no, LEAVE IT OUT.

Much like the anti-table zealots. There are times to use tables, and times NOT to use tables. To wholesale discard tables for EVERYTHING (which some of the real nutjobs advocate) is outright stupid, because there is such a thing as tabular data (like a forum index). The problem with tables for layouts is not that it didn't work, nor that it's a 'bad idea' or even the bull**** claim about it being a 'hack' - No. The problem was people slapping tables around every blasted layout element even if it resulted in only using a single TD per table - the pinnacle of /FAIL/. You see page after page designed with ten to twenty tables that even if you were using tables for layout would need one or two TOPS.

From this we get the dumbasses who when moving from table based layouts go from endless hordes of pointless nested tables to endless hordes of pointless nested DIV's with presentational classnames - net change 0.

There are three things tables do that CSS cannot:

1) Equal height columns where faux-columns won't 'cut the mustard' or ends up MORE code.

2) 100% min-height page without hacks.

3) vertical centering of a dynamic height element inside a dynamic height container.

If you aren't doing one of those three things, there is no excuse to be using a table for layout unless of course, you are actually presenting tabular data. (like a forum index, calendar or an excel spreadsheet). If you have multiple identical rows of data divided into columns, that's a table.

That said, MOST of the arguements against tables are just plain bull cookies made up by people that do not understand how to control a table via CSS.

"It's more code" - a lot of times it isn't, especially if you use border-collapse instead of that stupid 'cellpadding=0 cellspacing=0 border=0' malarkey and use classes to which multiple values can be assigned instead of wasting time on the deprecated presentational attributes of valign and align.

"It loads slower" - LOADING slower is a factor of filesize, and since as we just said it's often NOT more code but less, that arguement holds water like a steel sieve. What they MEAN to say is 'renders slower' and this is generally NOT the monster concern people seem to think, AND that particular arguement can be completely shot down by simply stating 'table-layout:fixed'! If a 386/40 can render a 50 row 8 field table under IE 4.0 in Windows 3.1 in a reasonable amount of time, these 'render time' arguements are a buch of horse manure in the age of multi-ghz multi-core machines with graphics accelleration and a thousand times the memory.

"It's a hack" - because of course negative margin tricks, using percentage height to trip haslayout, and 64k javascript frameworks that still need 4k of CSS to actually work don't constitute 'hacking'.

"It's not tabular data" - one of the definitions of a table is 'An orderly division of content into rows and/or columns" - Rows and/or Columns?!? That sounds like a website.

Now, I'm not saying run out and start doing all your sites in nothing but tables - what I'm saying is watch out for nonsensical rubbish being spewed forth by ignorant fanboys. Throwing a tool out of your toolbox that was the driving force of web design for a decade and a half is shortsighted and silly, especially since MOST of the arguements against it are FUD.

There are HUGE advantages to not using tables - the ability to re-arrange columns without changing the HTML for example. It is just another tag that you can choose to use 'properly' or throw caution to the wind and bloat out your page with hordes of unneccessary attributes...

----------------------------------------------

To sum up there's good coding, and bad coding... and a lot more of the latter being vomited up daily by people taking sleazeball shortcuts, not being willing to take time to save time, overusing "ain't it neat" technologies, overthinking the solution to every problem and in general failing to grasp that a little work in the here and now means a hell of a lot less work later.

Which is why when people ask for help with layout issues, a lot of the time my advice is to chuck the whole thing and start over from scratch.

 

About your commenting section, does it really matter? It's just a comment and it's easier to just read whats in the

<!- -> 

Code (markup):

than scroll all over to find the

</div>

Code (markup):

 

So THIS:

<!-- Start Main Menu -->
<div id="mm">
<ul class="left cascade">
  <li>Stupid list</li>
</ul>
<!-- End Main Menu -->

Code (markup):

doesn't look stupid to you?

Wait, you say </div>, so ... what? Not even sure what you are saying...

As to if it matters, HTML is for all intents and purposes an interpreted language - as such comments make it run slower and consume bandwidth so they should be kept to a minimum unless they REALLY add something useful. REDUNDANT comments are just being a retard. We know it's the start, that's what <div> means. We know it's the end, that's what </div> means, we can know it's the main menu, that's what id="mainMenu" means - if you can't find that ID quickly and easily, then the entire rest of your formatting sucks donkey (that or you are using a bunch of presentational attributes that have no place in modern markup!). That just leaves finding the end, which proper use of the tab key, and a comment JUST saying the name BEFORE the </div> will do the trick.

Hence 99% of the time that could be simplified down to:

<ul id="mainMenu">
  <li>Stupid list</li>
<!-- #mainMenu --></ul>

Code (markup):

... and if you are aware of IE's introducing undesired formatting and other rendering bugs introduced by COMMENTS (yes, comments!) you know why I put the comment before the </ul> and not after. Could be worse though - you have the real jackasses that double their filesize in comments, but can't be bothered to use the tab key even once... and don't give me that bullshit 'oh, It's output from a script' nonsense either - I've written code for three decades and know full well that in PHP/ASP and damned near other web language you can preserve HTML formatting JUST FINE in your output, and that from a debugging standpoint it's rarely worth the couple hundred bytes to strip them (instead, how about just writing minimalist code in the first damned place?)

Site after site you see fat bloated rubbish using anywhere from 40 to 50k of HTML on less than 2k of content, usually chock full of everything I've outlined as 'wrong' in the above post.

If you indent yer code properly and actually bother using classnames/id's that say WHAT it is, it should stand out like a sore thumb. Again, read the article on IBM's linux site I linked to:
http://www.ibm.com/developerworks/linux/library/l-clear-code/
as it has some really good insights (I'm particulary fond of the 'Oh, now we're done?" comment)

More code does NOT make it easier to read, it does NOT make it run faster, and it makes it more likely for you to make a mistake!

 

Well I do agree with you on pretty much all of that, but say this:

I don't overally care what my code output looks like. When I write the code I conform it to my style guide - which makes it a cinch to read and edit on my end, and if it comes out dodgy on the browser side, who cares? No one will really be reading it it will still render, and it will still validate strict.

We'll take a little look from the code generated on my CMS's setting page. Not the nicest code, and there are a few things bugging me (the class="left" for one)

		
		<form method="post" action="/cms/admin/index.php?page=admin_settings">
		<fieldset>
		<table>
			<tr>
				<th>Setting</th>
				<th>Value</th>
			</tr><tr><td class="left"><label>Site Description</label></td><td>
					<textarea rows="5" cols="10" name="description">Dredgy Content Management System is the most awesome CMS ever.</textarea>
					</td></tr>
<tr><td class="left"><label>Keywords</label></td><td>
					<textarea rows="5" cols="10" name="keywords">Dredgy CMS, Content, Article</textarea>
					</td></tr>
<tr><td class="left"><label>Seo Friendly URLs</label></td>
				<td>
					<label class="check check1">On<input value="1" checked="checked" name="seourls" type="radio" /></label>			
					<label class="check check2">Off<input value="0"  name="seourls" type="radio" /></label>
					<b style="clear:both;"></b>	
				</td></tr>

		<tr>
			<td class="textCentre" colspan="2"><input name="ssubmit" type="submit" value="Save Settings" /></td>
		</tr>
		</table>
		</fieldset>
</form>
		
    </div>

	<script type="text/javascript">
		setupAccordions();
	</script>

Code (markup):

I know your going to go on about my class names describing what the element does instead of what it is, but I just prefer that - if someone wants to make a theme for my CMS they are going to know what "textCentre" does. For me, I like to keep a high standard of code, but I also like people with no coding knowledge to be able to just look at it and know that that centres text.

Still, bloody brilliant guide (though btw you style guide's "Markup validation" segment is incomplete.)

 

Excellent post, ds. Anyone should benefit from taking your rules to heart.

I do have a nit or three to pick, based on my own four and a half decades of experience.

I find tools like HTMLTidy to be worthwhile checks on my work, catching typos, missing closing tags, etc. I put it on a par with spell checkers; eliminating silly, but easy to miss errors. As for syntax color coding, it's so ubiquitous (and I do have to sit down to lesser editors all too often) that not having it in my own editor became distracting. On the whole, it provides limited help.

I believe you're wrong about the use of <p> tags. The <p> is the basic text container. If you consider that html is a structural markup language, and that a paragraph, by definition is a brief composition in one typographical section, a distinct subdivision of text, intended to separate ideas, even a single word, if a separate typographical section, belongs in a <p> element. (Damn! I almost ran out of commas.)

cheers,

gary

 

But when you're debugging your html/css, you have to work with the server's output, that ugly html formatting that you didn't care about.

If outputting well formatted html is difficult, perhaps you're not separating structure, the html, from logic, the PHP/whatever. Just as you should separate structure, presentation and behavior on the client side, so should you separate structure and logic on the server side.

cheers,

gary

 

Well thats the point. I can debug it easily because I have it all written in clean code. I dont go and edit it in the source viewer - I can see what a problem is by looking at the page.

My average PHP variable looks like this:

Sorry, pasting it to a forum post doesn't seem to work.

Code (markup):

Its not that outputting clean HTML is difficult, but in multipart variables like this one, it becomes HARDER to edit because of either more indents (because out of good conscience, I'd have to indent the HTML code inside the indented PHP code, which is just too many indents, and looks out of place on a multipart variable). This is for the backend of the CMS - for the frontend (themes) there is no PHP at all, so what you write is what you get.

 

Very good points made there. Too bad most "programmers" will never see them and never apply them.

Reminds me of my start as a programmer on an Apple II+. At that time there were no standards. So, I developed my own, which I still use today in HTML, Javascript, and FoxPro.

What I discovered then was that the standards I developed made it very easy to see bloated code and very easy to eradicate it.

I remember one time I needed a faster sort routine (None were part of the OS at that time). I found a program in a magazine that promised to be faster than what I was using. And it was. It was a Shell Sort. But, at 250 lines of BASIC code it was still SLOW, it was a memory hog, and it was hard to use on a 16k 1mhz Apple II+.

After I typed in the 250 lines of code and got the bugs out, I started formatting it according to my rules. Wow! Was it ever bloated! By the time I was finished taking the bloat out, I had a routine that was of a magnitude 60 faster, was only THREE (3) lines of BASIC long, and was very easy to set up and use. The resulting 3-liner would do in one minute what the 250-liner would do in one hour and what my previous sort routines would do in days.

Needless to say, I am a fan of standards regardless whether they comply with what other people think or not. And I DETEST spaghetti code and rats-nest code, neither of which can be altered nor maintained no matter how hard you try.

 

99% agreed.

Eh, I'll still use p's for chunks of random text that needs to act like a block. Like in a footer. My other option is a bunch of display: block spans sitting around in the text. Bleh. Not cleaner. I could hack with smalls and bigs and other crap tags. Or I can use a p.

Since HTML5 group has decided to give us "new" tags, why aren't they trying the USEFUL ones?? There's nothing wrong with div id="header" so why f*ck with it? But it would be great to have

<smallprint>Void where prohibited. Sale ends July 2009. Not valid in Arizona, Alaska or Idaho. Sales tax applies. Batteries not included.</smallprint>

<copyright>© 2030 Martian records</copyright>

Or this?
<postcode>
Foolaan 5 <br>
3322ZZ Foostadt<br>
Fooland, Foo
</postcode>

Yesh I'm continuing to abuse HTML elements to my heart's content cause sometimes a doctor's gotta use female contraception for boy's acne, or viagra for heart disease. Off-label use. So, I'm stuck with no proper blocks for short chunks of text or something that almost every website has, an address? Then I'll use the army I have, not the one I want.

Oh, and I rather appreciate my psychedelic colours. Which is faster to find:

the word "green" in a block of text?

or the green word in the block of text?

I can see colours, so the answer is, the latter. It's a good tool.

I don't use the tab key because
        after a few children
                the spaces start to get
                        rather spacey and screwy
                                and hard to work with
                                        and ends up wrapping on even my screen eventually

Code (markup):

spacebarz FTW.

I use ds' method of comments inside the elements (most of the time-- IE7 thinks comments are children and count them with nth-child!), and the start of the comment takes the indent place of the closing tag.

*edit, Hubby wrote this:

function myDecode($inString) {
    $result = '';
    $t      = 0;
    $len    = strlen( $inString );
    while ($t < $len) {
        $top = hexdec( substr( $inString, $t, 2 ) );
        $t += 2;
        $bottom = hexdec( substr( $inString, $t, 2 ) );
        $t += 2;
        $result .= chr( ( $t % 8 ) == 0
            ? $bottom - $top
            : $top - $bottom
        );
    }
    return $result;
}

Code (markup):

 

Oddly enough I found that's one of the few optimizations that while it might make sense on the surface, it does not in fact change the speed of the code (in PHP, Delphi or FPC using string, Java or Python).

Because the resultant value does not change, the bytecode interpreter in php actually stores that value as fixed anyways (unless it sees said value being changed inside the loop), so allocating another variable to it is actually slower... though barely so since it's outside the loop making the difference impossible to even measure.

Though in SOME interpreted language implementations (javascript, C, Delphi or FPC using Pchar) defining length in a variable is faster... All hinges on how your interpreter/compiler is handling storage of fixed results and whether or not those are actually functions, macro's or references.

Much of it comes down to how strings are stored - Wirth style strings (length:data) the string length function isn't even a function, it's a variable pointer. Most databases and complex string handlers use Wirth style strings under the hood because they are more efficient to parse with assembly or even high level languages.

AT&T style strings on the other hand (null terminated) take a good deal more overhead to deal with, are more prone to buffer overflows and take longer to add data to. Never understood why C and company, much less things like old school BIOS calls had such a raging chodo for them.

Oh, and on tabs - set your editor for two space tabs instead of five space. If you end up tabbing in more than six deep, there's probably something wrong with your code... and if you have a GOOD text editor it will auto-indent word-wraps the same as your first tab (crimson editor for example)

On the subject of colour syntax - The default colours in most of editors are below the accessability contrast minimums making them hard to read. Re-assign them to something legible on a white background you can barely see them in the first place... and to me tags stand out like a sore thumb in markup so I don't need it there. (those nice big brackets are a dead giveaway), separation of presentation from content means there aren't enough attributes to worry about that, if there ARE you put them on their own lines, while in CSS I put each property and it's value on it's own line - so syntax highlighting is completely pointless there. Makes me wonder if the people who find colour highlighting to make a difference are punctuation blind.

Though it could be worse, could be the nimrods who format their CSS like this:
body { padding: 12px; margin-right: 0.5px; font: normal 80%/1.2em verdana; color: #000000; background: #E5E5E8; }

One line jumbled mess, excess spaces making it hard to tell properties apart from their values, no fallback font, mixed metric declarations, etc, etc.... I've rarely seen a website where someone did that which didn't have the same value declared more than once because even the person who wrote it couldn't keep it straight.

 

Such long a post. I try to make my html code more beauty and more standard compliant.
That is good habits.

 

http://www.sitepoint.com/forums/showthread.php?t=566637&page=7

This page to page 9. Basically saying that your example of quicklinks is wrong (can't mix inline/block elements). What do you think about the whole everything needs to either all be block or all be inline thing?

 

Dunno, I'm permabanned for life from Sitepoint for daring to disagree with most of their staff on just about everything.

Though they used the excuse of my using the term 'wigger' in reference to basically putting yourself in jail when going to court (pants around the ankles, not taking your hat off, saying "Yo Excellency this shit is whack" - they called it a racial epitaph... I wasn't aware white kid posuers constituted a race.

Though if that's another of their discussions on what constitutes a paragraph and what does not... hang on, having a friend copypasta that for me.

Ok, I'm not sure where the devil Paul got the notion you can't put inline level elements NEXT TO block level. There isn't one bit of well-formedness that says you can't put them NEXT to each other, it's all about putting them INSIDE each-other. Block levels can't go INSIDE inlines - there's not one thing anywhere in the specs about NEXT to them!

But then they seem to be obsessed with wrapping shit in paragraphs for no good reason - elements that in my mind are NOT pargraphs. A sentance fragment that is not in content flow is not a paragraph. A image is usually a plate, not a paragraph (the only time I would put an IMG tag inside a paragraph would be something like a smilie )

But that's arguing semantics - a situation were nobody will ever be on the same page. I come at it from the point of view of someone with a command of the language - they seem to be coming at it from... gee, uhm... where the hell did they come up with this nonsense again? Quite frankly it's a waste of code, and in a lot of cases adds the wrong meaning to the elements being wrapped.

Which is wierd, Paul was one of the few people over there I had the least bit of use for (Dan being the other) - Frankly that whole thread is chock full of bullshit.

(gee, wonder why I got a lifetime perma-ban again? **** sitepoint and the dumbass nubes they rode in on.)

 

DS, it's called a HACK.

Wrapping everything in order to prevent blocks and inlines from being siblings seems to only have a single benefit-- avoiding some IE bugs (including, interestingly, the duplicate content bug--- yes, seriously, I have a demo from when I ran into this bitch on a form).

Doing something that the specs don't say you have to (Tommy argues that this is because the DTD couldn't be written in such-en-such a way and he knows more about the writing of the DTD than I) specifically in order to avoid bugs in a particular browser is called a hack. A safe, valid, semantic hack, but I do think it's still a hack.

While I don't have loose text inside divs, I can't truthfully tell the difference between
<div>
text text text
</div>
and
<p>
text text text
</p>
with the exception that divs MAY also hold blocks while p's can't. And so I generally don't have loose TEXT in divs though I freely mix inlines and blocks, esp if I'm making it display: block in the CSS (which seems to often solve the IE problems too, though not always).

Here's the demo-- you may have seen it before re dup content of hidden stuff between floats, but I accidentally started redoing it to go more with my current style of blocking and automargining submits--- lo and behold, the bug vanished. Even with invisible content still between floats.
http://stommepoes.nl/dupcontent.html

 

See, my answer to that is that I'd never build a form that way. Those aren't multiple blocks so IMHO a linebreak would actually be more appropriate than all those div, I would be nesting my inputs inside their labels, but then I'm not certain why you have that hiddendiv either since that looks like it should be a separate fieldset (possibly a sub-fieldset), much less the wierd two labels for one select thing going on.

Though I'd probably also not need that since I don't use floats inside my forms. I either use negative margins or I use absolute positioning in relation to it's label. (part of why I wrap them) - though some of the problem there could also be blamed on the use of the universal reset when forms are involved, which is why there are such wildly different appearances across multiple browsers in the first place.

 

Emphasis added.

I will put my command of the English language up against anyone's, not excluding yours, ds.

The paragraph is a typographic structural element. It is, as I stated earlier, a brief composition complete in one typographical section. How difficult is that? Do not confuse paragraphs with sentences, and whether they're complete, fragments, or whatever. It is not at all a grammatical element. It is a typographic element.

The lonesome link at the top of the page, pointing to the content is a paragraph. It is a complete composition in a typographic section. The same holds true of images in your page. Think of them in terms of the alternative content, the alt text. That image might well be embedded within a paragraph containing other text if you want to tie the text to the image structurally.

Feel free to mark things up in whatever manner you see the structure as being, but if you don't understand the distinctions, perhaps your command of the language is not as comprehensive as you believe.

gary

 

How could it not be written in that way? I dont' know that much about Doctypes (nor care) however as it's a made up thing, so there is no limitation as to what it can or cannot do.

I'll be lucky to be there another month. I said:
"I'm not in some bizarre country where auxnhasidnaskjdnaskjdnkajsdnkjsndkasndksjandksjandkansdjkasnd is a word"

And didn't sh*t hit the roof! If it wasn't staff no-one would have cared, but as the staff are from countries with big words that was apparently 'offensive' (even though the meaning of bizarre means strange, and to any native English speaker a word that long is very strange, therefore bizarre)

I haven't wrapped them to avoid it, and I've never had an IE bug caused because of it. The cause of the IE bug is more likely to be lousy coding then have a block element after an inline element.

Source: http://en.wikipedia.org/wiki/Paragraph

A unit of discourse... well, "back to top" is a discourse as stupid as it'd be have to wrap it in a <p>. I wouldn't say that an image is a discourse and should be wrapped in a p (and there isn't a real rule saying an image is worth a thousand words, so can't argue that)

 

Which is why I'd only wrap an image in a paragraph if it were in content flow - like in the case of a smilie. "Back to top" is not part of whatever the topic is, it's a control. Controls are not part of 'discourse'.

The same is typical of a lot of content images. Most of the time if the image was not present at all the article still most likely makes sense. If it does not make sense without it, well, you probably shouldn't be using an image (or the image is presentational, in which case it has no place in the markup IMHO)

Let's back that up with dictionary.com
http://dictionary.reference.com/browse/paragraph

Dictionary.com Unabridged (v 1.1)
–noun
1. a distinct portion of written or printed matter dealing with a particular idea, usually beginning with an indentation on a new line.
2. a paragraph mark.
3. a note, item, or brief article, as in a newspaper.

–verb (used with object)
4. to divide into paragraphs.
5. to write or publish paragraphs about, as in a newspaper.
6. to express in a paragraph.

American Heritage
n.
A distinct division of written or printed matter that begins on a new, usually indented line, consists of one or more sentences, and typically deals with a single thought or topic or quotes one speaker's continuous words.
A mark ( ¶ ) used to indicate where a new paragraph should begin or to serve as a reference mark.
A brief article, notice, or announcement, as in a newspaper.

I fail to see how an image qualifies under that definition, nor do I see how something not part of the topic like 'back to top' or even a site footer would qualify as such. They are non-topical elements.

... and neither would people working in print, be it old school or modern in Pagemaker or Quark.

 

I usually put them in the source purely for easy editing later by the client, they just rename it to whatever image they want later and it's done, too easy.

Discourse from memory is a topic. And as "back to top" is it's own topic it warrants it's own paragraph...

However, I'm sticking with just <a href="#">Back to Top</a> until I feel to need to litter my markup with unneeded rubbish.

 

I'd love to get rid of those. Some of our labels were so long that the first line needed to stretch across the form while the second part filled the rest (normal width of the label).

I haven't found a way to use absolute positioning safely in a form-- a text enlarge or the boss changes the text of a label and everything dies.

I currently have my Back to Tops in loose (though absolutely positioned) anchors, as well as the skips at the top.