Separation - the reasoning (fork from another thread)

deathshadow

Code-tard is just discovering the advantages of external stylesheets, so I thought it might be useful to folks if I explained the advantages. I'm also going to explain my conclusions and reasoning for sitebuilding, since I know a lot of my heavy handed authoritative statements confuse people.

If nothing else someone might find my rambling useful.

I'm putting this in HTML because I'm going to end up touching on that as well, and to be frank CSS is only as good as the markup it's applied to... and generally speaking, this first post is going to be about the STYLE tag, STYLE attribute, and LINK attribute. THOSE ARE HTML, even if you are providing CSS with them!

You are going to find me using terms like "generally speaking" and "rule of thumb" -- this is because while the below may be good practice, you have to allow for exceptions; at the same time because there are exceptions that doesn't mean you should ignore good practices on everything else... and when I DO mean the rule is in concrete, I'll bloody well say so.

When it comes to the application of CSS, the advantages of an external stylesheet are simple:

1) It's separation of presentation from content. Keeping what things are SEPARATE from what they look like. What things look like as a rule of thumb has no business in the markup. As I often say, if you choose your tags based on your default appearance, you're choosing the wrong tags for the wrong reason.

This separation also means that you can edit things side-by-side. Even at the earliest development stages having your markup and your style separate in separate editor windows makes development faster and easier -- and it saves you the time of trying to extract it later; which a lot of people who use the style attribute CLAIM they are going to do, but never actually do it.

2) Multiple presentations -- by including differnent files using the MEDIA attribute, you can target different devices. This is why using a stylesheet LINK without the MEDIA attribute is stupid, and using the "all" value is even dumber. There are all sorts of targets for media, and most often the one you want is SCREEN, PROJECTION and TV -- Screen is your normal devices you think of when you design, some kiosks and browsers in full-screen operation ignore screen using projection, or will use a mix of the two; and sadly, there are still some devices that report themselves as TV, and if you don't say TV they'll override your settings with their own. (The version of Opera on the Wii is a great example, as is the now semi-defunct MSN-TV).

Naturally this is the point where some jacktard will say "who cares about those" -- when it's basically including an extra 15 characters to support them, are you really such a lazy foxtrot you can't be bothered? Whiskey tango foxtrot!

Ask yourself this, does your for screen layout and design elements make ANY sense to be sent to print? How about Aural? Media targets exist to customize appearance for targets AND to prevent values that are just screwy from being sent to the wrong devices.

Now ask this -- how exactly do you do that with the STYLE attribute. How do you put a media attribute on another attribute? So much for STYLE as an attribute.

These first two reasons also combine that you can easily have multiple appearances off the same markup; meaning SKINS -- reskin an entire site without even touching the markup? Oorah!

3) Caching. Even if it's just a single page, what if people visit it more than once? You really want return visitors re-downloading the same data over and over again for no reason? This more than any other reason is why the STYLE tag is pointless.

The laugh is things like Google pagespeed are suggesting putting some style back in the markup -- the only situation that would pay ANY benefits in speed or efficiency is if your traffic is all bounce -- a situation I thought we were supposed to be avoiding -- much less that if you're going to have an external sheet anyways, what difference does it make if it's in that or the HTML apart from the HTML not being cached. That's just stupid advice on the part of Google Pagespeed.

4) pre-caching -- if you put the CSS of sub-pages in the same monolithic file for each media target, you are effectively pre-loading the appearance of those pages -- so those sub-pages load AND render faster. Now, the peanut gallery will chime in with "doesn't that make the first-load take longer" -- really if you have enough CSS for all your pages that doing this results in any noticeable difference, you don't know how you use CSS properly.

Generally speaking in all but the rarest of cases, UNCOMPRESSED there is no excuse for even the largest of site templates -- like those of a forums -- to break 48k (and a third that gzipped) other than developer ineptitude, a failure to grasp how to use selectors or HTML, or just plain code bloat garbage like frameworks.

This is another area where people screw up -- first by trying to use tools to "remove unused CSS" that often removes CSS used by subpages just because it's not used on the main page. Then they run around like chickens with their heads cut off that the subpages are screwed up.

Likewise they blindly trust tools like Google Pagespeed when it *****es about "unused css" when their tool doesn't go deep enough into the site for it to even know. More than once I've had to clean up after site owners who blinding followed the advice of tools like that, and gone and completely boned things like forum softwares.

All the above reasons are why (and this is set in concrete) I see no legitimate reason to EVER use the STYLE tag, even in testing. PERIOD. It's just sloppy coding and making more work for yourself later if you take the time to clean things up. It's why whenever I see it in someones markup, I generally conclude they don't know what they are doing.

The STYLE attribute on the other hand there are a handful of corner cases where it does serve a purpose -- and those cases are for when you are actually using style to convey content. Not using the STYLE attribute is one of those 'rules of thumb' -- there ARE legitimate reasons to use it.

Now you might be thinking, "how can style convey content?" -- what about a tag cloud? Sure you could set several levels of classes and set it by class, but that's as big a waste of code on 'font sizes' that likely aren't even going to be static from page to page.

That uses width to convey content. NOTE I still use a text equivalent as you should NEVER rely on visual appearance to convey content unless that's what the content IS (like an image or a video)... still doesn't mean it's no useful to do it -- just have a backup plan.

But unless you're doing something along those lines, just say no to using the STYLE attribute. It's a crutch at worst, disastrously inefficient at best for the majority of usage scenarios.

Not putting it in the markup can pay other benefits -- like faster running server side code. Now, you might be thinking, how can not having style in the markup make the server code faster?

Simple: it's less code for the server to process. If style is in a static file, you don't have to process it in your server-side language -- like in your PHP. ANYTHING you put in PHP -- even stuff outside <?php ?> still has to be parsed by the PHP engine, a waste of time, and waste of memory. Smaller markup == less work for your server side code. It also makes it easier to maintain your server side code as there will be less of it as a result... Playing to a rule I learned decades ago about programming:

The less code you use, the less there is to break!

It also means that if need be, you can alleviate the server load by offloading static files to a 'lightweight' server process on a subdomain, a dedicated separate static server, or even a CDN. You can't offload what's in your PHP/ASP/PERL/whatever to another server or domain!

I'm going to write up a follow up post to this one explaining a number of other things about HTML and CSS and practicing things like separation of presentation from content, progressive enhancement, semantic markup and so forth. There's a lot of disinformation and outright lies being spread about those, mostly as lame excuses by the people who don't practice them... Time to shoot those excuses full of holes.

deathshadow

OH, one other little thing before I make the next "big" post -- notice how I call it "screen.css"? Saying what it's for, specifically it's media target, is far better than the uselessly vague "style.css" or other oddball names people use. In general if it goes in the markup, you should be saying what things ARE -- and I extend that not just to my use of tags, but also the classes, ID's, AND filenames. Too often you'll come into a project and have classes like "clv5", "htvb", or filenames like "r.js" -- USELESS! Oh noes people, you might have to type out a full word or two :/

Which reminds me, maybe I should do a post in this thread about commenting practices while I'm at it.

deathshadow

Alright, let's REALLY talk HTML.

Some people call HTML "easy"; some go so far as to dismiss it's importance outright; some will try to 'abstract' it as if they can't be bothered. ALL of that is just more lame excuses to cover the fact they likely never grasped what it is for or how to leverage it's features properly. Quite often the people who dismiss things like valid markup, STRICT practices, and things like "progressive enhancement" or "semantic markup" generally don't know enough about HTML to be flapping their gums on the subject.

This is because at it's simplest, HTML is the foundation of ANYTHING you build online. Before you pour the foundation of a house, do you build the sides, roof and put siding on it? Of course not. Same with writing your markup; start with your content, then mark it up to say what things ARE.

Saying what things are is often called "Semantic markup" -- I've recently soured on the term as I realized that it's little more than a euphemism people use so as to not offend those not practicing it; and to be frank, to blazes with that type of thinking. "Semantic markup" actually means USING HTML PROPERLY! -- Pesci forbid we come right out and say it!

"Semantic markup" -- the practice of using HTML tags for their actual meanings to say what things ARE on the page or would be in a professionally written document, IS USING HTML PROPERLY, ANYTHING ELSE ISN'T! -- PERIOD, you cannot argue otherwise without being so full of manure you could fertilize an acre of flowers single handed.

It all stems from why Tim Berners Lee created HTML all those years ago; the whole idea was to say what things are or would be in a properly written professional document like a scientific paper, term paper, expose, or new article. Even the 'presentational' <b> and <i> tags actually have the semantic meaning "would be bold or italic grammatically, as in a proper name or book title". NONE of the tags actually meant it had to be shown that way as the whole idea was to let the user-agent (aka browser) best determine how to convey that information within the capabilities of the target device.

At the time there were all sorts of different ways of transmitting information -- teletype, print, screen -- and even different size screens of differing resolution and capabilities. NOTHING like today.... Some of those devices couldn't even show bold or italic, but professional writing used them, so such devices could use color, or prefixed and postfixed characters, or some other means of conveying it.

But bottom line, the whole idea was to say what things are, so that they could be conveyed as best possible within what the device could handle.

UNFORTUNATELY, during the browser wars that got thrown out the window as more and more "what it looks like" garbage was added to HTML. By the latter half of the '90's it had reached a point where various W3C members finally said "ENOUGH" and created a new HTML, HTML 4, that would do away with all the presentation, and using the new concept of "CSS" move all that presentation into something that could be used for specific target device capabilities.

BUT, there was a problem. SO many people had old sites and wanted the new features -- and the rules of HTML 4 meant a lot of the old tags were just going to go away. As such they created HTML 4 Transitional, which would be all the old stuff, many of the browser specific bits of trash that were never part of the specification and the new stuff all mashed together any-old-way, and HTML 4 STRICT, which followed the new rules. Transitional was for letting old sites use the new stuff, 4 Strict was for writing new websites "the right way"

So what did people spend the next decade and a half using? Transitional, because the vast majority of developers never extracted their craniums from 1997's rectum or grasped any of STRICT's concepts. Most writers creating books and tutorials followed suit as they never really got it either, with the result being what's rapidly closing on 20 years of people making crappy, inaccessible, bloated slow websites that are laundry lists of how not to use HTML.

... and those concepts really are a superior, simpler, faster, and easier way to build sites -- YET, every blasted person still sleazing out the outdated code makes the nonsensical claim that what they do is in fact "easier"... which is such a giant load of manure it got dumped into Biff's car.

Those concepts being a return to HTML's original intent -- saying what things ARE. The reasons for this are the same as when HTML was created, so that the appearance can be customized for various different target devices. With the plethora of screen sizes and device capabilities we have today, it makes far, FAR more sense than -- as I explained in the initial post of this thread -- putting the presentation in the markup so you are stuck with one appearance.

It also plays to progressive enhancement -- the notion that you start out with the lowest common denominator: your content be it text or the filenames of the media, then mark it up semantically, and then and ONLY then worry about creating your layouts, and then applying your fancy styling to that content. This way WHEN (not if, WHEN!) those fancy bits are blocked, unavailable or just plain irrelevant, the user still gets a usable page.

Which is "writing for the visitor" -- hey, isn't that what Matt Cutts keeps telling us about search? Write for the user, not the Engine? -- news flash, Search engines don't have eyeballs -- so just like users on screen readers they could give a flying purple fish about your layout, fancy graphics or goofy animations.

Also -- as discussed so far -- it means you can have different appearances for your different media targets... or even multiple easily implemented appearances for a single media target!

Learning to use HTML properly isn't hard -- a good start is a good reference. I always point people at this one:

It's getting long in the tooth, but since HTML 4.01 STRICT, the most recent recommendation hasn't seen a major change since it was introduced in 1998, it's more than adequate. In fact it's one of the best references explaining things in plain english while staying true to the specification. Go through that and learn what all the tags are FOR, so you can use them to say what your content IS. When marking up your page, pay ZERO attention to what you are going to want it to look like, because not every visitor to your site is going to see that!

BUT WAIT, HE'S SAYING HTML 4 NOT 5!?!

You got that right Skippy! Again, 4.01 -- and by extension XHTML 1.0 STRICT --- are the latest W3C recommendations. 5 is still considered draft and/or partial. That said to be brutally frank so far as a markup specification goes HTML 5 offers NO real improvements. There are a handful of neat bits, a handful of bits that are being shoved down our throats by Apple and the FLOSS zealots, but really there's no 'need' for any of it on the vast majority of sites. Worse, it loosens the structural rules and reintroduces a lot of the redundancies 4 STRICT was trying to get rid of!

Finally, HTML 5 is a 'superset' of HTML 4.01, meaning it adds stuff to it without really removing anything (other than some rules that were there for a good reason) so if you learn to use HTML 4 properly first, you'll gain most all the skills you need to use 5. In fact, many people are now advocating the site-building approach of writing the page as XHTML 1.0 STRICT or HTML 4.01 STRICT first, then adding the handful of 5 tags that actually serve a purpose or you're "forced" to use, living with the validator rejecting those so long as the structural errors aren't present -- and then slapping the 5 doctype on it at the last moment for a final validation before deployment.

Now personally unless I HAVE to use one of the tags being shoved down our throats like VIDEO, have no real plans to use HTML 5 any time soon. Most of the really cool stuff people call HTML 5 isn't, that's CSS3 and the new scripting, and guess what? There's no reason you can't use most of it in the older document specifications!

Alright, getting close to the post size limit and bedtime, so I'll end here and tomorrow post up some of the bits of semantics people often mess up, as well as some of the details of semantic tags people make mistakes with like logical heading orders, what tags can go where, and I'll even touch on the use of CSS selectors and how to use them efficiently instead of wasting time throwing classes and DIV at everything for no good reason.

jedaisoul

All the above reasons are why (and this is set in concrete) I see no legitimate reason to EVER use the STYLE tag, even in testing. PERIOD.

Well, there is always an exception, and in this case it is when you don't want the style caching. Consider this fragment:

What this code does is allow a drop-down menu to be hover activated or click activated. They are alternatives, you do not want the hover activation to take place when click activation is active and vice versa. Nor do you want to have to write the menu twice. This uses the same menu code in two different ways.

deathshadow

Sorry, to me that's a class' job... There's so little code involved I'd put both in the CSS and just change the class on the parent. I'd probably also condense their values... and of course I wouldn't be using multiple echo for nothing... and probably not be trying to do numeric math on strings... and probably also check that 'sel' is actually set since all user input shoulld be tested and not blindly assumed.... and I'd probably make it so you only toggle the class 'sel' on and off instead of flipping back and forth between two values.

Also not sure why you're using the lower precedence 'or' operator... Doesn't really make a difference, it's just strange to see.

Has the advantage you could mix both techniques on the same page without filling out the markup, and also means that if you are going to have a different skin/theme (one of the reasons CSS exists) where the colors are different, you won't have to dive into the PHP to change it.

Really if that ~100 bytes difference on firstload is making a big impact overall, you've probably got that bloat I'm talking about. I'm all for not sending code that isn't being used, but using PHP logic to do so is rarely the answer when it's CSS. PARTICULARLY when you have properties that can share values.

Putting selectors together like I just did also being a great example of why I think things like LESS and SASS are a bunch of BS used by people who don't grasp how to use selectors. You have elements with like values where you want to edit them all from one place, PUT THEIR SELECTORS TOGETHER!

jedaisoul

I think that "thanks" is all I can say. I'll study your solution.

deathshadow

Thanks to Jedaisoul I'm gonna make a slight diversion before talking markup and common mistakes, because selectors are one of the things people are ALWAYS screwing up. Well, saying "screwing up" isn't exactly fair -- there are so many ways to use them... I guess what I'm saying is people don't exactly use them efficiently.

A LOT of the advice out there isn't helping, with people who don't know **** about CSS running their mouths with idiocies like "don't use ID's" and "use classes before you use complex selectors" -- they get so hung up on the render time (a relative non-issue for CSS) they start neglecting bandwidth and caching models for it; absurd at best, shooting themselves in the foot at worst.

A great example of this is when you see people writing garbage HTML like this:

So what's wrong with that you ask? There is usually very little you can do to a DIV you can't do to a UL. In the majority of cases someone puts a tag like DIV around a menu UL, they do so for no good reason. Next up if every element inside a parent that has an ID or class is getting the same class, NONE of them need that class. Classes are great when things are DIFFERENT, don't waste time throwing them at things that are the SAME, that's what targeting by tags is for -- something made easier by semantic markup since then you have DIFFERENT tags, not just a bunch of SPAN and DIV. That "active" class is also a really bad idea as there's a pseudoclass of the same name; don't use reserved words as your bloody classnames.

Other than developer ineptitude. View source your average turdpress website to see said developer ineptitude in action. It's effectively 40% less markup, and less markup is ALWAYS going to pay dividends so long as you don't sacrifice accessibility in the process.

Since rewrite to original:

#mainMenu == DIV#mainMenu and .menuUL combined

#mainMenu li == .menuLI

#mainMenu a == .menuA

span == span.menuIcon; doesn't need a class as those are the only SPAN in the section!

The laugh is right now there are a number of folks out there advocating the 'endless pointless classes for nothing' saying it's somehow 'faster'. Apparently these people don't understand how less markup is a good thing or how to use selectors. I'm so sure the 'complexity' of the longer CSS selectors and handful more characters in the CSS is going to be slower than increasing the markup size 50% or more -- NOT!

Sadly even Google's pagespeed tool is now parroting that nonsense

In my rewrite of Jediasoul's example I touched on why I think things like LESS and SASS are bull -- one of the biggest 'features' they're always talking about is 'variables'; where they can add more code so that if elements for example were all the same color, they can edit that one color from one place.

The laugh of this is -- to use the example off Wikipedia:

@color: #4D926F;
#header {
color: @color;
}
h2 {
color: @color;
}

How is that any easier than say...

#header,
h2 {
color:#4D926F;
}

You have properties you want to edit together because they are the same, instead of writing more code and adding some pre-processor bull, JUST PUT THE SELECTORS TOGETHER! Then you can also edit it from one place. The biggest 'feature' people tout doesn't even serve a legitimate purpose other than making the CSS bigger.

"Mixins" are just a confusing mess that's hard to follow and leads you off to find some other point in the code to even figure out what the devil it's doing, while "nesting" is just lazy bull that is no more or less clear than the code it's supposed to replace; much less the inheritance hell it often creates.

Don't even get me started about the functions and operators where if you're too lazy to figure out without them you probably have no business writing CSS in the first place.

Bottom line, your CSS just shouldn't be complex enough to need that type of nonsense. People act like CSS should be this massively complex thing, which is why they end up using hundreds of K of CSS to do 10-20k's job. IF things like LESS and SASS actually provide benefits to you, your CSS is probably poorly written trash and you should go back and learn to use CSS, selectors, inheritance AND semantic markup properly.

Another bit of nonsense people do comes from the "presentation first" mentality that results in code that, well... to be frank, they might as well be writing HTML 3.2... they even now have a name for this idiocy, "OOCSS"

They actually advocate using presentational classes like:

<div class="left clear textCenter red bold sansserif">

Which is so colossally and mind-numbingly stupid you might as well go back to using the CENTER and FONT tags. That's basically putting presentation in the markup, something you shouldn't doing in the first place. I'm so certain those classes mean something for print... or when the media query no longer wants to put that section 'left' or change the alignment.

Sadly, most HTML and CSS frameworks like bootcrap, blueprint and YUI do the same thing with, well -- lets use bootstrap's example template:

Setting aside the pointless Aria role crap that there's no legitimate use for and is nothing more than code bloat, that string of classes for nothing that don't even actually say what it actually IS is so ridiculously moronic, it just proves the people DUMB ENOUGH to use it don't grasp the point of HTML, CSS, much less how to use them properly. The script-tard handles for stuff that shouldn't even be scripted, comment placement that could trip rendering bugs, abuse of a button tag outside of a form basically doing an anchor tag and :target's job, and all the ridiculous pointless DIV for nothing too? HERPAFREAKINGDERP!

Bootcrap and it's kine do NOT make responsive layout easier, does NOT make site development easier, or faster -- it's just pointless sleaze that does the opposite of it's claims -- You find 'frameworks' like that live up to their claims, it's a fairly safe assumption you don't know enough about HTML or CSS to open your trap on the subject.

I'm constantly amazed at how people make more work and more code, then call it "easier" -- just what the devil is in the kool-aid? It's like Otto and Thornton are the new Jim Jones and David Koresh. I mean, I know placebo effect is powerful... but... wow... just.... wow. I lack the words in polite company.

Alright, I'll get started on actually explaining some semantics and common mistakes.

deathshadow

Let's talk semantics, aka "USING HTML PROPERLY"

The tags in HTML exist for a reason, that reason <brokenrecord>is to say what things ARE, not what they look like. If you choose your tags based on their default appearance, you're choosing all the wrong tags for all the wrong reasons!</brokenrecord>

Numbered Headings and the Horizontal Rule

Numbered headings -- H1, H2, H3, down to H6 -- alongside HR exist for the same reason ordered headings and rules exist in professional writing, to indicate the start of subsections of the document. Lower order (higher numbered in HTML) headings mean a subsection of the higher order (lower numbered) heading preceding it. That means H2 is the start of a subsection of the H1, H3 is the start of a subsection of the H2, and so on and so forth. The "horizontal rule" of HR means a major change in topic where heading text is unwarranted or undesired -- like say... right before your page footer. Because of this, H1 is the heading under which everything on the page should be subsections -- which is why the site title (or the presentational affectation of the logo/banner) is the most likely candidate to be your H1.

H1 or H2 do not mean "This is giant text", HR does not mean "draw a line across the screen" -- those are their default appearance, nothing more.

The laugh is when TBL made HTML back in the day, he didn't even feel the need to clarify this as anyone making documents with HTML would have known what heading orders were and what they are for.

Think of your site like a newspaper -- what heading is on every page of the paper? The name of the paper. Sure, it's bigger on the front page, but it's there on every page as the structural anchor to tie together the entire "paper". The main headline on the main page may be shown in even bigger text, but structurally does that make all the other headlines subsections of that one? Of course not. "Woman mugged on Emerald Street", "K-6 get New School Building", "Index" and "Weather" are likely NOT subsections of "MAYOR CAUGHT TAKING BILLION DOLLAR BRIBE[b/]" -- well, unless you live in one really jacked-up town. They'd all be H2, even if the main headline is shown bigger because structurally they're all siblings to each-other.

This is why you really should only have one H1 on a page even if HTML 5's rules are trying to piss all over logical document structure, this is why skipping over heading levels like having a H5 with no H4, h3 or even h2 before it is absolute gibberish, and why pairing a h1 and h2 as a title and tagline is a bunch of halfwit nonsense used by people who never grasped how to use numbered headings properly in the first place!

Paragraphs

The P tag DOES NOT MEAN insert a double-break here. It does NOT mean "this is text" as of course it's text if it's CDATA. It does not even mean it's typographical meaning of a block of content (that's a DIV). P means a grammatical paragraph -- like most of the flow text in this very post. One or two complete sentences or flow text elements. Do NOT slap it around a sentence fragment because you feel like it. Do NOT slap it around tags like images "just because". P goes around grammatical paragraphs and major flow text, and that's IT.

Images

The IMG tag should be used for content images -- aka images that make sense on the page even if all the fancy styling and layout wasn't applied. If an image doesn't meet these meanings it belongs in the CSS. It's that simple -- you don't use images to do padding's job with "spacer.gif" -- you don't put an IMG in the markup if it's a presentational affectation of text... and seriously people, STOP USING IMAGES FOR TEXT CONTENT!Nothing like pissing away bandwidth AND accessibility in one fell swoop!

CITE, B, I, EM and STRONG

First off you'll hear a lot of mouth-breathers spouting the lie that B and I are 'deprecated'. They are not, never were. NOR are you supposed to just blindly use STRONG and EM instead of B and I, as those have a different meaning.

For some reason when the specification "suggests" you use another tag "when the meaning is more appropriate", people magically turn that into "never use this tag, use the other one". THAT'S NOT WHAT THAT MEANS! We'll be covering another example of this shortly!

Bold and Italic have a semantic meaning apart from their seeming presentational role. This stems from the fact that when TBL created HTML many devices were incapable of even showing bold or italic text. In professional writing those affectations are used to convey things like company titles in a reference situation, or book titles when you aren't citing them.

That last part confuses people as, well... examples explain it easily.

<p>I read <i>Moby Dick</i> last night.</p>

<p><q>"Call me Isheal"</q> - <cite>Moby Dick</cite></p>

Basically B and I mean WOULD BE bold or italic in a professionally written document, not that it MUST BE. That's their semantic meaning. Some other tags like SMALL serve a similar purpose, which is why using SMALL for a tagline inside a H1 (for example) is semantically correct, as you are providing de-emphasis.

Get it?

EM and STRONG as mentioned have their own meanings -- emphasis and "with more emphasis" respectively. They are NOT blind replacements for B and I.

Years ago a friend made this example that shows the difference quite clearly:

<i>GURPS,</i> <b>Steve Jackson Games'</b> flagship role-playing game, was first released in 1985. Several licensed adaptations of other companies' games exist for the system, such as <i>GURPS Bunnies and Burrows.</i> However, <b>SJ Games</b> has no connection with <b>Wizards of the Coast</b>, producers of the <i>Dungeons and Dragons</i> RPG. <em>No <i>GURPS,</i> content is open-source.</em> <strong>Do not plagiarize <b>SJ Games</b> work!</strong>

To me that's still the BEST example I've ever seen of explaining exactly where to use them and what B, I, EM and STRONG are for!

TABLES

Ah, tables. So loved, so reviled, and so polarizing in opinion -- and worst of all, so misunderstood and misused.

Tables exist for a reason, to mark up tabular data; data where there are clear headings for rows or columns, and where rows or columns are the same type of data in an organized format.

They do NOT exist to create columnar layouts -- the thing is when we started being told "tables aren't for layout" people started magically transforming that into "NEVER USE TABLES". THAT'S NOT WHAT IT MEANS!See, told you another example was coming.

You can see that particular bit of idiocy in things like several forum skins (vBull, Xenforo) where obviously tabular data is now crapped out in nested lists... removing any semantic relationship, and then they bloat the code out with extra CONTENT CLOAKED text to try and restore that relationship?

One of the justifications for this broken bloated practice is that tables "take longer to render" -- which to be frank ... if a 386/40 running windows 3.1 and IE 4 can render a table in an acceptable amount of time, the "render time" argument means not a blasted thing in the age of multi-ghz multi-core in the palm of your hand. There are plenty of good reasons not to use a tables for layout; you don't need to make up lies about them or not actually use them on tabular data!

Much of the 'problem' with tables just comes from people not grasping how to build one properly. See this train wreck of idiocy that is ridiculously commonplace:

What's wrong with that? Well there are more tags that go into a table than just TR and TD and a whole SLEW of attributes missing. CAPTION goes across the top to describe the table, THEAD goes around your column headings, the SCOPE attribute says if that heading is for the row it's in or the column it's over. TBODY is where your data goes... and none of those should be bold.

That is a properly formed table with all the established semantic relationships. Gee, was that hard? People don't do it either because nobody ever taught them that, or they are just too lazy to care. I can forgive the former, but on the latter...

If you have data that fits this model, use the table. If you just want columns of unrelated data for layout, don't use a table.

Alright, closing in on the post size limit. Next up I'm gonna cover forms. Sorry if I'm rambling a bit, I just want to get this down somewhere.

Code-tard

Hey DS, big thanks for this fantastic thread and going out of your way to break it down for fellow Tards!...

Even so Im completely failed dude ... About 20% I already knew, 30% completely blew my mind!... and about 50% just went right over my head?!...

Its been a week and Ive been right here, you better believe it ... Chipping away at the unknown.. Little things eg.

What is a 'Selector'?.. I swear to god, if thats not a rabbit hole that has no end!... and not to mention the endless miss information out there.. a lot of people need to stop, pick up a damn book and learn the difference between an 'id' & 'class' before the start preaching the word!....

As for the more professional resources (W3C etc) codes a lot easier to understand than whatever though's guys are going on about?..

Anyways.. have managed to get the 50% down to about 20% and fully determined to keep going until I get that down to zero.. If Im not going to run and hide behind wordpress and bootstrap.. I have to!.. End of story....

So this is not so much a feedback but more just a late "thanks" and flyby...

As for the subject at hand "HTML" ... Im no fan of 5 amongst 4 and its extended family.. Knowing little it feels disorganized and underdeveloped... But I do believe that it will grow.. and become the legend 4 has been the last 20yrs, 5 will be the next 20...

On this idea I have to make my html world about 5.. and to be completely prepared for each of its evolution's.. to set the highest of standards and to lead others "the right way".. as you guys have over the years with 4.. thats on me every time you guys help!...

I see 5 as the young over excited cub, amongst the wise old Wolves... Im sure you can see the irony in that! .. and that is the way it is to be...

So Im not just asking for your wisdom.. Im really asking "in your wisdom" please help prepare me/us, for what is to come!.. over the next 2 decades..

And some day when some young pup's all a hurry to know about this new "html6".. I'll teach him/her what you taught me.. A time when you guys wont care because your all getting spoon feed!