Please stop using these tags(uitrends.com)
uitrends.com
Please stop using these tags
http://uitrends.com/2009/11/12/uitrends-web-design-tip-1/
8 comments
Agreed. The <b> and <bold> tags are not so great, but tags that only convey meaning rather than style ( like <strong>, <em>, etc...) are definitely far better than using <span class="bold"> for everything.
> Also, if what you need to create is a table of data, then what else would you use beside table.
To be fair, TFAA does specify that his rule is about <table> for layout.
And yeah, <strong> definitely doesn't belong to the list, TFAA's defense of that in the comment is <weak>.
To be fair, TFAA does specify that his rule is about <table> for layout.
And yeah, <strong> definitely doesn't belong to the list, TFAA's defense of that in the comment is <weak>.
I love your use of <weak> there. I know it's a joke, but I would find it useful as a real HTML tag.
There are certain things on the page that are less important than a regular <p> or <li>. It would be nice to add some semantic meaning to the article rather than only making the color lighter in the stylesheet.
There are certain things on the page that are less important than a regular <p> or <li>. It would be nice to add some semantic meaning to the article rather than only making the color lighter in the stylesheet.
I'm into semantics in HTML as much as the next guy, but do you think there is an HTML processor out there that notes a subtle semantic difference between bold and strong? It's pedantic. I don't even know why people still discuss this non-issue when better methods for embedding semantics in markup are _all over the place_.
> but do you think there is an HTML processor out there that notes a subtle semantic difference between bold and strong?
Screen reader might. And anyway, the subtle semantic difference between <strong> and <b> is that <b> has no semantic significance whatsoever.
That's not very subtle.
Screen reader might. And anyway, the subtle semantic difference between <strong> and <b> is that <b> has no semantic significance whatsoever.
That's not very subtle.
HTML 4.01 Transitional DOCTYPE: Perfectly fine, use STRICT for l33t designz bonus points.
<table> (For layout): ok, we heard that one before.
<td>: that could be handy if you like your table to have cells.
<tr>: same, very useful for tables that need rows.
<IFRAME>: sometime useful, that's why you may want to stick to transitional doctypes.
<frame>: see frameset.
<frameset>: ok, don't use that. It's bad UI/UX.
<hr>: fine to use, but hard to style with css.
<br>: line breaks are fine too, just don't confuse them for paragraph breaks.
<font face=”Arial” size=”1″>: yeah, dont' use that, use CSS.
<bold>: use <strong>.
<strong>: use it, it's good semantic (strong emphasis).
<center>: ok, don't use it. Use CSS for presentation.
<map name="Map">: yeah, rarely useful and bad for accessibily/SEO.
<area>: see map.
<b>: use <strong> instead.
<table> (For layout): ok, we heard that one before.
<td>: that could be handy if you like your table to have cells.
<tr>: same, very useful for tables that need rows.
<IFRAME>: sometime useful, that's why you may want to stick to transitional doctypes.
<frame>: see frameset.
<frameset>: ok, don't use that. It's bad UI/UX.
<hr>: fine to use, but hard to style with css.
<br>: line breaks are fine too, just don't confuse them for paragraph breaks.
<font face=”Arial” size=”1″>: yeah, dont' use that, use CSS.
<bold>: use <strong>.
<strong>: use it, it's good semantic (strong emphasis).
<center>: ok, don't use it. Use CSS for presentation.
<map name="Map">: yeah, rarely useful and bad for accessibily/SEO.
<area>: see map.
<b>: use <strong> instead.
While I agree that HTML is acceptable, I personally have never seen how it's better than XHTML.
XHTML definitely makes life easier for the browser vendors, and if they spend less time debugging their HTML parsing engines then they can spend more time adding CSS3 support!
From the coder's perspective, is it really that much harder to write XHTML than plain HTML? Personally I find writing HTML more of a hassle, but that's just because I use XHTML on a daily basis...
XHTML definitely makes life easier for the browser vendors, and if they spend less time debugging their HTML parsing engines then they can spend more time adding CSS3 support!
From the coder's perspective, is it really that much harder to write XHTML than plain HTML? Personally I find writing HTML more of a hassle, but that's just because I use XHTML on a daily basis...
HTML is better than XHTML because the XHTML error handling model (refuse to render) is a poor fit for the web.
Good point. I have yet to encounter a browser that actually sticks to that rule though...
> HTML 4.01 Transitional DOCTYPE: Perfectly fine, use STRICT for l33t designz bonus points.
For even more l33t bonus points, use the HTML5 doctype declaration.
For even more l33t bonus points, use the HTML5 doctype declaration.
Some of these things are IN HTML5, for example <map>
I don't understand what's wrong with the <strong> tag and I want to discuss it here...
I agree. If you want something to stand out in a long paragraph, what would you use?
<span class="highlight">?
I'd much rather use <strong>.
<span class="highlight">?
I'd much rather use <strong>.
I don't think anything is wrong with the <strong> tag. It is interesting that it is listed next to the <b>/<bold> tags, as <strong> is often suggested as a semantically correct alternative to those tags to denote the importance of a specific bit of text.
Perhaps the author feels that only <em> should be used to place "emphasis" on the text in question, and that it should also be used instead of <strong> as strong doesn't give as clear an impression of importance as <em>.
I think you are just fine using <strong> in places where it is appropriate.
Perhaps the author feels that only <em> should be used to place "emphasis" on the text in question, and that it should also be used instead of <strong> as strong doesn't give as clear an impression of importance as <em>.
I think you are just fine using <strong> in places where it is appropriate.
> Perhaps the author feels that only <em> should be used to place "emphasis" on the text in question, and that it should also be used instead of <strong> as strong doesn't give as clear an impression of importance as <em>.
That's a pretty weird take on it, given <strong> is supposed to put a stronger emphasis than <em>.
What would be used instead of <strong>, nested <em>s?
That's a pretty weird take on it, given <strong> is supposed to put a stronger emphasis than <em>.
What would be used instead of <strong>, nested <em>s?
"<strong> is supposed to put a stronger emphasis than <em>"
You are right about that. I suppose I was just speculating on why the author was including <strong> as a no no. That the thought of "I am 'stronging' this text" didn't indicate significance to him while "I am 'emphasizing' this text" related significance to him. In which case, <strong> would seem like just another name for <bold> while not denoting importance.
I myself did not clearly understand that <strong> was actually more "powerful" than <em>. I appreciate you clearly stating the relationship between <strong> and <em>.
You are right about that. I suppose I was just speculating on why the author was including <strong> as a no no. That the thought of "I am 'stronging' this text" didn't indicate significance to him while "I am 'emphasizing' this text" related significance to him. In which case, <strong> would seem like just another name for <bold> while not denoting importance.
I myself did not clearly understand that <strong> was actually more "powerful" than <em>. I appreciate you clearly stating the relationship between <strong> and <em>.
> I appreciate you clearly stating the relationship between <strong> and <em>.
No problem. It's pretty much lifted straight from the HTML4 spec:
> EM: > Indicates emphasis. > STRONG: > Indicates stronger emphasis.
There's a lot of fun stuff in that spec, I don't regret having read it (almost) completely once a long time ago.
No problem. It's pretty much lifted straight from the HTML4 spec:
> EM: > Indicates emphasis. > STRONG: > Indicates stronger emphasis.
There's a lot of fun stuff in that spec, I don't regret having read it (almost) completely once a long time ago.
Heh. I love how this guy is telling people that are comfortable doing layouts in table tags that converting to CSS-only layouts will ... "save them time".
Suuuuuuure it will.
Suuuuuuure it will.
Maybe not right now. But down the line it will save them time.
Using a central stylesheet to manage your layout, as opposed to scattered HTML files containing markup and presentation, can save immense amounts of time in the long run, particularly if the website you're working on is large.
How is there a way in which being able to make global changes in one place won't save you time?
Using a central stylesheet to manage your layout, as opposed to scattered HTML files containing markup and presentation, can save immense amounts of time in the long run, particularly if the website you're working on is large.
How is there a way in which being able to make global changes in one place won't save you time?
Templates can be centralised just as well as stylesheets.
Sure, but pawing through an unfamiliar template that's crowded with tables and presentation is a horrible experience.
Maintainability and readability in my opinion are strongly linked and readability really suffers when markup and presentation are combined. Pure CSS layouts go a long way toward making both the markup and the presentation rules easily readable.
And if anyone argues 'But it's only going to be me making the changes, and I'm already familiar with the code.' If you haven't looked at the code for a year, it's like looking at the code for the first time. And you know what they say:
'Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.' - Rick Osborne
Maintainability and readability in my opinion are strongly linked and readability really suffers when markup and presentation are combined. Pure CSS layouts go a long way toward making both the markup and the presentation rules easily readable.
And if anyone argues 'But it's only going to be me making the changes, and I'm already familiar with the code.' If you haven't looked at the code for a year, it's like looking at the code for the first time. And you know what they say:
'Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.' - Rick Osborne
In principle, I agree with you. However, we also have to allow for the very real fact that tables work pretty much exactly the same across all browsers, and allow for some very fine-tuned control over layout.
CSS, on the other hand, is implemented differently from browser to browser. Depending on the layout, sometimes that's a problem, and sometimes it isn't so much, but it still requires specialized knowledge of CSS and browser-specific quirks.
...to say nothing of all the various css "hacks" that are out there.
Given a complicated site layout, I think I'd rather crawl through some table code than crawl through pages and pages of complicated CSS where declarations at the bottom of the file are subtly dependent on declarations at the top of the file.
Also, let's not forget that CSS was not intended for layout. When it was designed, it was designed for specific purposes, and it's since been warped into a layout language.
So, sure, in principle, I agree that it's better to keep your HTML clean and meaningful, and hide the complexity in a separate CSS file.
But let's not pretend that some designers will save time by switching to CSS only, or that CSS-only is simpler, or that there's anything intrinsically bad about using tables for layout, or that developers have no reason for doing so.
CSS, on the other hand, is implemented differently from browser to browser. Depending on the layout, sometimes that's a problem, and sometimes it isn't so much, but it still requires specialized knowledge of CSS and browser-specific quirks.
...to say nothing of all the various css "hacks" that are out there.
Given a complicated site layout, I think I'd rather crawl through some table code than crawl through pages and pages of complicated CSS where declarations at the bottom of the file are subtly dependent on declarations at the top of the file.
Also, let's not forget that CSS was not intended for layout. When it was designed, it was designed for specific purposes, and it's since been warped into a layout language.
So, sure, in principle, I agree that it's better to keep your HTML clean and meaningful, and hide the complexity in a separate CSS file.
But let's not pretend that some designers will save time by switching to CSS only, or that CSS-only is simpler, or that there's anything intrinsically bad about using tables for layout, or that developers have no reason for doing so.
[deleted]
Yeah, sites like this get under my skin. Virtually every project I work on involves CSS. I've had trouble with "CSS Designers" lately.
- "CSS Designer" integration projects take 2-3x as long. I get blamed because it "looked great" as a static site.
- It's hard to debug "bad" CSS. (ex: too many "special cases".)
- CSS designers make very attractive sites.
- It's easy to have CSS conflicts when two programs share a page.
- CSS drop down menus are great!
- "CSS Designer" integration projects take 2-3x as long. I get blamed because it "looked great" as a static site.
- It's hard to debug "bad" CSS. (ex: too many "special cases".)
- CSS designers make very attractive sites.
- It's easy to have CSS conflicts when two programs share a page.
- CSS drop down menus are great!
XHTML is such a load of garbage. Transitional is bad, sure, but strict HTML 4.01 is the very best.
Do you have a specific issue with XHTML? Personally I would say that it's so good that they should probably do away with any non-xml serializations of the DOM...
> Do you have a specific issue with XHTML?
Most of it is a lie, and when it's not a lie everything breaks (many JS behaviors change quite a bit in XHTML-as-XML).
Also, XML blows goats.
> Personally I would say that it's so good that they should probably do away with any non-xml serializations of the DOM...
Wow…
Most of it is a lie, and when it's not a lie everything breaks (many JS behaviors change quite a bit in XHTML-as-XML).
Also, XML blows goats.
> Personally I would say that it's so good that they should probably do away with any non-xml serializations of the DOM...
Wow…
I need some sort of multiple upvote. :P
I have vacillated back and forth on this over the years.
My current conclusion is this: if you worry about tags in HTML then you're worrying about the wrong thing.
Make a website that does something useful. If you do, then we can talk about ascetics. But until that point? Stop sweating silly crap like this.
My current conclusion is this: if you worry about tags in HTML then you're worrying about the wrong thing.
Make a website that does something useful. If you do, then we can talk about ascetics. But until that point? Stop sweating silly crap like this.
Make something useful, but also make something that you can go back and change easily. Make something that is not quickly deprecated. Making something that scales. Focus on function then form. Make something that works then make something beautiful.
As for the article, after reading it, go down and read the comments. Many people were unhappy with the article.
There are some tags that should never be used. <blink>blinking text</blink> is an example of a tag to never use. This is because such tags are proprietary and only work with specific browsers. However, if the tag represents the functionality you need, it should be used. Divs should not be used for storing tabulated data, for example. Tables were designed for that purpose. There is little harm in doing something such as this, but everyone should have the proper habits.
As for the article, after reading it, go down and read the comments. Many people were unhappy with the article.
There are some tags that should never be used. <blink>blinking text</blink> is an example of a tag to never use. This is because such tags are proprietary and only work with specific browsers. However, if the tag represents the functionality you need, it should be used. Divs should not be used for storing tabulated data, for example. Tables were designed for that purpose. There is little harm in doing something such as this, but everyone should have the proper habits.
What we really need instead is a visibility:blink; CSS property. ;)
I get where you're coming from, but at the same time if you make websites for a living (or earn your living from websites in any way) then the HTML should really be treated you would treat any other source-code. Readability and maintainability are definitely big issues...
So you just make things up as you go along? I don't know. I'd rather write markup that's documented and I know will work.
This linkbait has cost the author more reputation than it was worth.