There are still people who think that <b /> has semantic meaning. It could have a little more semantic meaning than <span style="font-weight:bold;" />, 'cause you can style it aurally without the need of an extra class, but that's it. The element b just means 'bold' and what on earth is semantic on that word? Please tell me. It is exactly the same for the i element. You should drop it together with all your useless span elements.
HTML has the replacement for these elements before these presentational elements existed. How does that sound to you? strong and em should be used and these elements exist for a long, long time. Do not make the mistake to convert i to em only because they have the same visual rendering in most browsers. Markup is all about the content and not about visual rendering or 'what looks good'.
Today I came across another example of this. The width and height attribute still exist in XHTML1.1, which is okay in a way, but the possible values these elements can get are limited. I wanted embed SVG (with the object element) on my new layout and specify a height in the length unit em (do not confuse this with the element em). This is possible since CSS is integrated in SVG. The problem is that the width and height do not allow other values than percentages or pixels. So if I want to use a SVG and specify the length values with em it isn't possible within HTML, you would have to do this with CSS. My point is that these attributes should have been removed together with b and i, 'cause these are too limited or and this only counts for the attribute height and width, they should have been improved.
The reason I wanted to use SVG (which doesn't work in my copy of Mozilla, the plugin of Adobe seems only to be installed in IE) on my new layout is that I wanted to follow every single guideline of the W3C and still get the site working in as many browsers as possible, including IE (although I don't care about the graphical header working in every browser and the JavaScript, which only adds some extra fun, but nothing more). I almost achieved this, but the graphics 'kill' me. SVG just isn't ready for deployment on sites (even weblogs) I think. If the Mozilla SVG project was finished and there was proper SVG support I would have done it. Next to the right graphics I have to think about accessibility.
The accessibility guidelines have made a nice checkpoint slideshow. As it stands now (I think I can't use SVG) I fail a little on checkpoint 3.4: use relative rather than absolute units in markup language attribute values and style sheet property values. Unfortunately there is nothing I can do about that, since SVG support is minimal these days. 9.4 and 9.5: create a logical tab order through links, form controls, and objects & provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls could be done of course, but it requires a lot of extra work (which should not be an excuse) and there are better CSS3 alternatives on the move. Also the attribute tabindex has a poorly chosen name, not every device has a 'tab' key. The W3C knows about this and it will be changed to navindex in XHTML2 (CSS3 has also a property called navindex).
General conclusion: my new site won't validate against everything (though it will validate against the XHTML1.1 DTD).
Some words that are to be styled cursive are not emphasized. Somebody mentioned an example one time at alt.html, where he said that shipnames are written cursive. Now, we don't exactly need to blindly copy those 'rules' to internet publishing, nor should there be an element for shipnames. But the point is that when you require styling this type of words the appropriate way, where does semantics stand?
A shipname does not necessarily need emphasis. Because of this situation I believe that the b and i element have survived from deprecation.
What is your stand on that?
I think in that case you could use <cite>, which normally is rendered cursive as well.
HTML has the replacement for these elements before these presentational elements existed.
Wrong. They are not replacements. The function of <b> and <i> (which are still valid in XHTML1.0 Strict and XHTML1.1) is distinctly different from <strong> and <em>.
The previous comment gave one example, and there are many others where you want to style text in boldface or italic, without assigning any strength or emphasize to it. Keywords in bold (<b>) that aid visual scanning is another example. Foreign words or sentences in italic (<i>) are another.
I am afraid posts like this only add to the confusion. In the end, this confusion will result in a less semantic web.
Foreign words need to be marked up with something like <span xml:lang="la">carpe diem</span>
checkpoint 3.4 use relative rather than absolute units in markup language attribute values...
I think one should not be too strict about that, and it is meant you should apply those relative units to elements where it is possible (IE table, td, hr, div etcetera). I don't think they are talking about images here (at least that is what I was told by Kynn Bartlett asking him about this issue..)
<b> and <i>:
If you can come up with a set of semantically-meaningful classes that cover all possible uses of bold and italic text (not including "strong" and "emphasized", which already have dedicated elements), then by all means mark up your site that way. More power to you! My CSS stylesheet is already enough of a rat's nest and, as you concede, <span class="bold"> is a stupid substitute for <b>.
Sizing SVG:
I know you hate inline style attributes, but the way I do it on my blog is
<object type="image/svg+xml" data="/path/to/image.svg" width="100%" height="100%" style="width: 18em; height: 7em;"> <img src="/path/to/image.gif" width= "288" height="106" alt="description" /> </object>
The width and height attributes on the SVG are set to simply fill the allocated box. The actual size of the box is set in relative (em) units using an inline style.
The fallback GIF image is set to have the same size when the text zoom is set to "normal" (1 em = 16 px). But the SVG image will rescale along with the text when you use text-zoom.
Jacques,
I know you use b and i on your site and you style them visually the same as em and strong and aurally. I'm confused...
Ben,
Good point about using the cite element for ship names, although I do not know if it goes for every case.
Lars,
The elements are styled the same that is wat causes the confusion I think. Perhaps you know a place were the distinction between them is explained well?
Using the cite tag for ship names would not be a canonical use of that tag. The cite tag is intended for occasions when you are quoting someone--you wrap the person's name in the cite tag.
Loanwords are another issue. If I say "<i>laissez-faire</i> government," I am speaking English, not French. Wrapping that in a French-language span is semantically incorrect (not to mention a lot more keystrokes).
Looking over the index entry for "Italics" in my Chicago Manual of Style, I see that italics can be used for emphasis, foreign words, genus and species, key terms, legal cases, letters as letters and words as words, letters in enumeration, math, questions (as quotatives), rhyme schemes, ship names, stage directions, subheads, technical terms, theorems, and titles (of books, journals, movies, musical works, paintings, plays, and poems). Among other things. A lot of these are just typographical conventions in English that do not pertain in all other languages. I think this is exactly what the i tag was invented for.
Thanks, Adam!
I was going to post a similar list. You just saved me ... ahem ... a lot of keystrokes.
If you want to be semantically-correct, you could define a class name for each and every item on Adam's list and then mark up your text
<span class="shipname">Queen Mary</span> <span class="loanword">etc.</span>
That, IMHO, is a losing proposition. I will continue happily using the <i> tag for all but the most important of these classes.
Re: ship names. HTML Help says ( http://www.htmlhelp.com/ref... )
titles of magazines or newspapers, ship names, references to other sources, and quotation attributions
I don't see anything in the HTML specification to contradict this.
Yes, "<cite> carries meaning." But you lose that meaning if you misuse it to mark up everything that the Chicago Manual of Style says should be in italics.
Of course there's nothing in the HTML specification that prevents you from misusing <cite> in this fashion. But, then, there's nothing in the HTML specification that prevents you from using <i> either.
That page wins the prize for "stupidest advice from a reputable source."
Okay I think we are getting somewere now (at least I now the issues about i a bit more). Can we say that the b element should be dropped or are there also lists of words that should be boldfaced?
Jacques,
could you please answer my question in comment 7?
I have done some resource on the W3C mailing lists, where else can you find answers to these problems? The answers were using the span element, like Jacques suggest or even better: using a self-created XML language: http://lists.w3.org/Archive...
It is of course discusable if one wants to make his language just for some words, but I still think that the current i (and b) hang to much on presentation.
In my opinion i and b should be deprecated as they are purely presentational and not semantic. Maybe cite is not semantically the best option for all the applications in the i list, but in many it will do and otherwise there is span. Maybe XHTML2 should have a few new semantic tags for things like titles, names and foreign words. I also want one for technical terms (like XHTML element names or MIME-types), because I feel samp is not exactly right for this.
Can we say that the
belement should be dropped?
I can think of one use I have for it. :-p
Sometimes I use the W3C Core stylesheets:
http://www.w3.org/StyleShee...
Those stylesheets style <em> as bold and <strong> as italic. And why not? So if I choose to use one, I use <b> and <i> as here:
http://www.btinternet.com/~...
Otherwise, the visual style would be wrong. :-)
There's also a list of things that are traditionally boldfaced. I don't have a style manual handy.
Why do I style all these things in italics and bold? Because that's what the style manuals and longstanding typographic conventions suggest.
In your brilliantly semantic pages, where everything is marked-up "correctly", you could, instead, style <span class="shipname"> green, and <span class="loanword"> orange and so on.
Since I intend to continue styling them as italics, I cannot be bothered to go to all the extra effort of defining all those classes and marking up all those <span>s.
I'm just lazy that way ...
Could you configure your webserver to send 406 responses in response to user agents who do not understand application/xhtml+xml, rather than just shoving it down their throats - they don't know what to do with it why are you sending it?
Actually I note you're using some sort of Content negotiation, it's broken, I suggest you read up on q values, particularly q=0, and the VARY header.
Anyway that was an aside, after I eventually managed to read the document by switching to another browser... I've got some comments, i and b are not deprecated, they still have use, HTML and XHTML are not rich enough semantic languages, and the use of CSS classes are a hack, certain things like latin names for flowers or animals are by convention italics, and the appropriate mark-up for these is i not the zero meaning span. (a class is likely a good idea in addition though). i and b still have their place.
On including SVG - Object in XHTML is completely broken, there's lots of holes in it, and pointing out others probably ain't too productive right now. (for example aswell as your sizing issues, there's the what does a hyperlink within the included SVG do - replace just the SVG doc, or the parent Doc too? )
Avoid object, use iframe, and suggest the size with your stylesheet using EM's or whatever is appropriate to you, if you really want to include SVG.
SVG certainly isn't ready for deployment within documents, it's great standalone, there are lots of viewers available for it, so if you have an SVG document make it available via a link, and you can even content-negotiate that to give an HTML or raster representation if svg isn't available.
The elements are styled the same that is wat causes the confusion I think.
To some extent yes. I should also say that until very recently I was confused myself. I was even led to believe that <> and <> were deprecated in XHTML, and had to check with the W3C specifications myself to see that this was not the case.
But to style strong text in bold and emphasized text in italics is considered a de facto standard, isn't it? There's not much one can or even should do to change that.
Also, most of the confusion seems to arise when people start talking about <> and <> as deprecated in XHTML, or worse, as evil markup, rather than as a result of their identical rendering.
I am also aware of the markup that "needs" to be used for foreign language, and in an ideal world I would use it. I just don't see the practical point, to be honest. Not now, and not in ten years.
Perhaps you know a place were the distinction between them is explained well?
Unfortunately not. In the same ideal world, I would write it myself I suppose. But if I find it, I will make sure to let you know.
I just noticed Adam Rice's post, and I fully agree.
On a sidenote, I also noticed that HTML in posts doesn't render.
Can we say that the
belement should be dropped or are there also lists of words that should be boldfaced?
I can't. I mentioned the need or desire to mark up "keywords", so as to aid the scanning of a longer text. It would seem that boldface is the best choice for this, so that's a reason not to drop <b>.
I'm quite astonished that this italic and bold issue is still on going. Strong and bold are different and both have their valid uses. Either should not be depreciated. Don't forget that HTML is a markup language and is therefore presentational in it's nature. Use of HTML should be structural and allow for additional presentation via CSS. Avoid overlap when possible. Strong and bold do not overlap!
Getting markup to be entirely semantic is impossible partly for that reason. Semantics uses meaningful markup to present the content, it's relation to content is thus evident. H1 is a main heading, P is a paragraph etc. etc. But usability asks for pages to more easily scanned, this is where typography (<b>) comes in. Presentation is complicated and we should be careful not be dismissive of ways it can be done and who it's done for. Semantics can provide an Internet that is more useful and effective, Google and Amazon have proved that. But as shown here Semantics can be problematic to apply. What is the contents meaning and what is it's context? Never mind what language. This is where I believe Semiotics can provide us with some solutions.