Can someone actually explain why the <center> tag is deprecated?


#1

I know how to use CSS to center elements properly, but it requires a lot more markup and code then simply using <center> tags.

I realize <center> is depreciated and can display differently in certain browsers. But it still works very well in almost all situations that I've encountered and saves me time and markup which makes my code cleaner and easier to read. Right now I am not using <center> because it will prevent my code from validating which is a problem; but couldn't that be changed?

Anyway...can someone explain why the <center> tag is depreciated?

Thanks


#2

The CENTER element is deprecated because basically a it's a purely presentational tag rather than structural and is similar to shorthand for 'DIV align=center' which is better handled via CSS.


#3

Well CSS can take advantage of caching (where as HTML won't - due to loading each page individually), using CSS if it's in a separate file will therefore reduce bandwidth costs (speeding site loading in the process) and the lack of stylistic elements provides better semantics for browsers, search engines and social networks which index the content. Though I've no idea how you think the below seems like more code than center tags stuffed everywhere smile

.items{
      align: center;
}

PS: No you can't trick the validator into letting center elements pass, because their no longer "legal tender" in syntax world and it's a very good thing too!


#4

Thanks for the info. The caching part is quite interesting - I'm going to research that a bit. smiley


#5

No, it doesn't. It usually doesn't require any extra markup. At worst, you'll need a wrapping <div>.

To centre entire block-level elements:

.quotes {
  width:40em; /* or whatever */
  margin-left:auto;
  margin-right:auto;
}

To centre text inside a block-level element:

#nav li {
  text-align:center;
}

It's not depreciated (which would mean that it had lost in value), but deprecated (disapproved).

And the reason is that the purpose of HTML (and the XML version, XHTML) is to mark up semantics (meaning) and structure only. All things to do with presentation belongs to CSS and everything behavioural belongs to JavaScript. The separation of these three tiers is an important principle, not only in web design, but in all sorts of development.

By keeping the markup as clean as possible, it is easier to reuse it in other channels. You also increase the likelihood that you'll be able to redesign your site without having to edit individual pages. Such a thing is a chore for a static, page-based site, but an absolute nightmare if the content resides as data fragments in a CMS database.

The separation of content, presentation and behaviour also helps users who need various types of assistive technology (like screen readers) to perceive web content. And it's beneficial for low-bandwidth devices and for expensive pay-per-byte wireless connections, since it reduces the amount of data that needs to be transferred for each page. Especially taking caching into consideration, as Alex mentioned.


#6

Listen to AutisticCuckoo on this one - spot on. It's presentation, and presentation has NO place in the markup.

It's why I generally say avoid those rubbish CSS frameworks as well (Grid, YUI, etc), since they use presentational classes so to restyle you'd have to edit the markup anyways - DEFEATS THE POINT of using CSS in the first place! If you are going to be adding classes that say what things look like -- "smalltext", "floatLeft", "centered", "width960" for example, the question becomes what the hell are you even bothering with CSS for in the first place?

You also have to remember that more code in the CSS and less in the HTML takes advantage of caching models if said styling is applied across multiple pages - just as AlexDawson said. The more that's 'common' to every page on your site you move into the CSS, the faster all your subpages will load... you can even pre-cache sub-page layouts by loading it with the home page.

It also plays well with CMS - the less markup the CMS has to deal with outputting, the more time it can put towards actually processing data. Inlining presentation in the markup is the enemy of clean coding. (were that most major CMS systems would realize this!)

Lemme give you a real world example of some old HTML 3.2, and how I'd write that today.

The original code vomited up by an old WYSIWYG called "hotmetal" circa 2001

<CENTER><B><SPAN STYLE="Font-Size : 14pt"><FONT FACE="Arial, Helvetica">Clan and Inner Sphere Differences</FONT></SPAN></B></CENTER><SPAN STYLE="Font-Size : 10pt"><FONT FACE="Arial, Helvetica"><BR>
<BR>
Like many groups in the Inner Sphere, individual Clans see themselves as significantly different from their fellows.
Though minor from an Inner Sphere perspective, cultural differences among the Clans frequently threaten to explode
into major rifts. Throughout Clan history, they have prompted everything from long-standing feuds to mini-civil
wars to outright obliteration.<BR>
<BR>
The realms of the Inner Sphere are far more different from each other than are any two Clans. Some are virtually
bubbling over with different cultural groups and political factions. Others hew sharply to a single cultural pattern
and centralized power structure. Yet even the most freewheeling society possesses some sense of unified identity,
and even the least tolerant realm peacefully incorporates nonconformist elements.<BR>
<BR>

How that would be written today using modern semantic markup:

<h2>
	Clan and Inner Sphere Differences
</h2>
<p>
	Like many groups in the Inner Sphere, individual Clans see themselves as significantly different from their fellows. Though minor from an Inner Sphere perspective, cultural differences among the Clans frequently threaten to explode into major rifts. Throughout Clan history, they have prompted everything from long-standing feuds to mini-civil wars to outright obliteration.
</p><p>
	The realms of the Inner Sphere are far more different from each other than are any two Clans. Some are virtually bubbling over with different cultural groups and political factions. Others hew sharply to a single cultural pattern and centralized power structure. Yet even the most freewheeling society possesses some sense of unified identity, and even the least tolerant realm peacefully incorporates nonconformist elements.
</p>

Gee, which one's less code here?

Your html should say what things ARE, NOT what they look like.... I extend this even to my classes and ID's - say what the element IS, NOT what you want for appearance unless it's a presentational hook on a semantically meaningless tag like DIV or SPAN.... and even then I might use 'top' and 'bottom', but never 'left' or 'right' - but then I often write skins that need to work both LTR and RTL.

Presentational markup was a bad idea thrown in as a stopgap by netscape and microsoft, and we've been trying to backpedal from the disaster HTML 3.2 gave us by adopting those ever since. (though it seems like those lessons are completely forgotten in the train wreck known as HTML 5... literally it looks like it's going to be the new HTML 3.2). The tags and attributes deprecated in strict are removed because that **** has no place in your markup. Some of it is just shoving behaviors the user might not want down their throat (TARGET for example), but the lions share of them - CENTER, FONT, ALIGN, VALIGN, BGCOLOR, COLOR - are what leads to people using tens and even hundreds of K of markup to deliver 2-3k of actual text content.

I see it every day people with 60-80k of presentational outdated half-assed markup. Even when they TRY to use modern techniques they don't "GET IT" - as Dan used to say the people who used to make endless nested bloated tables now just make endless nested bloated div's, classes and ID's -- net change? ZERO!


#7

I'm actually with optl on this, a styled wrapper requires both an opening and a closing and/or a class indicator. A presentation tag only requires opening and closing. I fail to see how open and closing a wrapper could be anything but negligibly shorter but potentially much longer than a presentation tag.

That said, AutisticCuckoo brings up the overriding points, the divisions of presentation, behaviour and content are vital, especially if you don't want to create yourself a maintenance nightmare.

And, I'm not sure that use of a head tag (which flirts heavily with flying in the face of the neat divisions we preach IMO) and the lengthening of lines to make your code look shorter is an optimal way to illustrate a point.

Seems to me that the issues
- of deprecation (if a deprecated tag gets unsupported one day, you've just created yourself a TON of unpaid work)
- that presentation/behaviour/content divisions are not simply abject ways to make l33t designers feel good (or conversely you can just get l33ter and feel good too!)
are really the only really salient ones.


#8

I'm assuming that's directed at me. I just reformatted it my normal style without even thinking about what it would look like in the crappy little broken code boxes in vBull.

Even if you reformatted both the same way, it's shaving 90% of the markup from around the content. Outdated presentational crap doesn't belong in the markup which is WHY those tags and attributes were deprecated... and also why using the STYLE tag OR attribute in the markup defeats the point of style sheets.


#9

Exactly. <center> is shorter than <div class="whatever">. But your point about seperating style and structure is definitely valid as well as the caching point. Thanks for the responses guys.


#10

When deciding what does and doesn't belong in HTML you might consider a web reader. If it doesn't make sense in a web reader then it doesn't belong in HTML. After all, how do you say something in <center> differently than if it isn't in that tag?


#11

Though that treads into another failing you see time and time again in people's markup... Much as George Carlin said every ejaculation deserves a name, not every element needs a DIV, SPAN or class on it.

The whole IDEA of strict is to stop wrapping crap in unnecessary containers and instead use tags that actually say what things are - headings, paragraphs, lists, etc.

For example, when people put DIV's around their main menu UL for no good reason. There are times where yes, it deserves a presentational hook or wrapper; but that's fairly rare occurrence in most layouts... I mean you'll see pages where they've got nonsense like:

<div id="pageWrapper">
	<div id="header">
		<div id="logo">
			<img src="images/logo.png" alt="Site Title" />
		</div>
		<div id="nav">
			<ul class="navUL">
				<li class="navItem">
					<a href="#" class="navAnchor">
						Home
					</a>
				</li>
			</ul>
		</div>
	</div>
	<center><b><font size="+2"><span class="myTitle">Welcome to my Site</span></font></b></center>
	<font size="1">Blah blah blah blah Blah blah blah blah Blah blah blah blah</font><br />
	<br />
	<font size="1">Blah blah blah blah Blah blah blah blah Blah blah blah blah</font><br />
	<center><b><font size="+1"><span class="subsectionTitle">We do a lot of things here</span></font></b></center>
	<font size="1">Blah blah blah blah Blah blah blah blah Blah blah blah blah</font><br />
	<br />
</div>

If you don't know what's wrong with that, well... Wish I was making that one up, but that's loosely based on something I rewrote for someone recently -- content changed to protect the guilty

two thirds of the DIV are unnecessary in most layouts, most of the classes are redundant thanks to the 'cascading' part of CSS, presentational image in the markup, font bold and center doing heading tags job, etc, etc, etc...

<div id="pageWrapper">
	<h1>
		Site Title
		<span></span>
	</h1>
	<ul id="mainMenu">
		<li><a href="#">Home</a></li>
	</ul>
	<div id="content">
		<h2>Welcome to my Site</h2>
		<p>
			Blah blah blah blah Blah blah blah blah Blah blah blah blah
		</p><p>
			Blah blah blah blah Blah blah blah blah Blah blah blah blah
		</p>
		<h3>We do a lot of things here</h3>
		<p>
			Blah blah blah blah Blah blah blah blah Blah blah blah blah
		</p>
	</div>
</div>

ALL that's needed providing MORE than enough hooks to apply ALL of the same styling.

I've rarely if ever seen a page using any of the deprecated tags like CENTER that couldn't be made with a fraction the code without it. The mere NOTION of it being more code borders on the absurd.


#12

Then here is a really simple test. You don't get to apply a bunch of extraneous styling to manufacture proof of your point either. Produce just the word "center" in the middle of a page horizontally. It cannot be done with less keystrokes using CSS than it can be with just a center tag. If I'm wrong, please show me. Your CSS definition alone would be longer than the opening and closing center tags.

Now, if the center tag goes (which it could at any time), every instance of that tag will need to be replaced with a new styled wrapper. If you want to center more than one line, your CSS is reusable - you could even simply define that every <p> element be centered. Not at all practical or "correct" on a lengthier page, or a site unfortunately. Now you're forced to use specific classes on your wrapper, and you have to use a class name less than 10 characters long enough times to make up for the keystrokes you used defining it - then you have broken even and you start profiting 4 or 5 keystrokes every time. Keystroke gains would be negligible at best unless you were talking a site big enough that this whole argument is a complete waste of time anyway.

May I humbly suggest brushing up on algorithm analysis, helped me to not get hung up on such low order terms!

The only other option I see is pistols at dawn.

I didn't know sloppy coding made elephants so angry. Learn something new every day!


#13

The simplest test is to take a 1000 page web site and see how long it takes to move all the text from the centre to the left. With CSS about 2 seconds, with <center> tags allow several weeks.


#14

If writing an additional 10-15 bytes of markup seems an insurmountable workload for you, I have to wonder if you are in the right business. Testing beds might be more your thing. smile

Using contextual selectors in CSS you can often forgo lots of classes on descendant elements. For instance,

<blockquote>
  <p>Markup should not contain presentational aspects.</p>
  <p>Semantics is important for accessibility.</p>
</blockquote>

blockquote p {
  width:10em;
  margin:0 auto 1em;
}

#15

CSS is awesome, I get it. Believe me. I believe optl is technically correct using a center tag is less work initially - period. Very simple observation proves that.
As I plainly stated, the largest efficiencies in CSS come from it's reusability and ease of sitewide maintenance, so thanks for reiterating my point felgall.

And thank you Autistic for illustrating my point
that if you were doing a site large enough that your tiny keystroke gains from using a deprecated tag made a big enough difference you actually noticed it, your priority should have long ago shifted to the quality of your organization and you should have an eye to the nightmare you're creating if you want to change something. As I stated, contextual selectors can save you a massive amount of time, but you must cede that they are not always a particularly appropriate or practical solution.

My point was screw conventions that you don't really see the point of AND realize that they have become conventions for a reason; you may do very well to understand them better. If you don't have the cajones to make mistakes (and even costly ones) get a job delinting suits. Or testing beds, but that's a pretty sweet gig, competition might be awfully stiff!


#16

I would argue that while it's less work typing, it's considerably more work in maintenance, you just know somewhere down the line he'll want to alter the style of the website and perhaps not have something centered, and then he'll have to ferret through every single page to make the thing occur globally (rather than using one single value). It's almost like a case for cowboy builders, they cut numerous corners which require the most initial effort or thought but the person whom it always bites is the customer (visitor) who has to suffer the increased file sizes - and when they return to fix the work in the future, it becomes that much more difficult. smile


#17

NOT a real world test. WHY is it being centered? What IS the text? Is it a heading, is it a paragraph? is it part of a list? How many times are you centering an element on the page? How many different pages are you centering it ON?

<h2>Centered</h2>

in the css

h2 { text-align:center; }

Now, that might be more code the FIRST time it's used, but if you use it on a second page? If you use it more than ONCE per page? You only need two accesses to break even.

That's part of what STRICT and semantic markup are about. Don't waste time slapping classes or presentational tags on stuff when you can just use semantic tags or unique tags to a section!

CENTER doesn't tell us anything about the text... and you might not even want it centered on all devices.

Oh, and elephants never forget.


#18

That's funny you mention algorithmic analysis. I'm a computer science major at the University of Maryland and I took an algorithmic analysis class last semester and I'm taking the more advanced one this semester. I believe our backround in algorithmic analysis is what pushed us to understand the point that in some situations the <center>...</center> tag is less markup than

<p class="centerme">.....</p>

p.centerme{ text-align:center }

That situation occurs when the centerme class is only used once; in that case <center> is less markup, period.


#19

Okay, you're right. It is shorter. Now, temporarily accepting the frankly idiotic and presentational class name 'centerme', please show me a use case where saving these 31 bytes would make any real-world difference whatsoever? Perhaps on Google's search page, but is there anywhere else?

And it only takes one more use of that class to eliminate the difference altogether; after that it's pure gain. If you then include CSS caching into the equation you'll save on a single use if at least two visitors return (or a single user visits two pages).

So this hypothetical 31-byte saving, which only occurs under very unlikely circumstances, is most likely not worth the extra maintenance hassle of mixing the content with presentation.


#20

Here's an example. You purchase a product online and are taken to a download page. The page is very simple and only one element is centered on the entire page: <center><a href="...">Download File</a></center>. Clearly, that is less markup than using css to center the anchor tag with a wrapper div no matter how you do it. Caching doesn't come in to play because users are only allowed to visit the page once.

There you go; a real world instance where the center tag would increase the page load speed.