<strong> is not a better <b>

Lest anyone think I’m not an equal-opportunity ranter, I’ll pull this out of my comments:

The default WordPress theme includes vertical bars in the “postmetadata” section, between the category (and the “Edit this” link if you are logged in) and the number of comments, with


which, as I said, would seem to be trying to say as semantically as it can, “No, really, dude, I mean it: vertical bar!”

Repeat after me: <strong> is not a “better” <b>, <em> is not a “better” <i>, both <b> and <i> still appear in the DTDs for XHTML 1.0 and XHTML 1.1’s Presentation Module, they are not deprecated or worse than their semantic cousins with the same usual screen presentation, they are different. If you want to say something strongly or with emphasis, use the appropriate element, but if you only want it to be bold or italic, again, use the appropriate element. Screen readers should not be told to read “Posted in carping VERTICAL BAR fifteen comments.”

And, yes, this time I did file a bug rather than just ranting.


Comment by Daniel Cater #
2005-11-06 14:14:15

I agree that strong is the wrong markup, however, strong is still better than b in general for semantic reasons. span id=”pipe” or similar id/class methods should be used instead, with CSS rules.

Comment by Phil Ringnalda #
2005-11-06 14:58:11

in general for semantic reasons

Did you just say ”strong is a better b”?

What semantic reasons? In what way do you think I want to strongly say ”vertical bar, dude!” to separate items of metadata? The semantic meaning of b is ”in visual presentations, I would like this to be bold” which seems to be precisely the intended meaning.

As to whether it’s better to turn a one pixel line into a two pixel line with seven characters, or with fifty, I’ll take seven, thanks. There are times when using generic markup and CSS makes sense, but doing it to turn one or two characters bold strikes me as just fetishism.

Comment by Daniel Cater #
2005-11-07 07:07:49

> Did you just say “strong is a better b“?

No. Maybe I should have used ’usually’ instead of generally, for I meant that in most cases strong is better than b, for it’s usual use is to bolden text in order to make it stand out more. I _agree_ with you that b makes more sense than strong in this case, as you want the pipe to be bold, not more ’prominent’. However, b is presentational markup, and is as such bad IMO. I do like Aristotle’s solution below. Very neat, as it is extensible to further additions to the inline-list.

Comment by James Kew #
2005-11-06 15:17:16

But telling a screen reader to say ”posted in carping vertical-bar fifteen comments” isn’t a whole lot better. Ideally, you’d want to tell screen readers that the vertical bar is decorative fluff and should be rendeded simply as a pause.

So probably Daniel has it right above: style it with CSS, and apply a suitable @media aural rule for screenreaders…

Comment by Mark #
2005-11-06 18:47:58

style it with CSS, and apply a suitable @media aural rule for screenreaders

Ha ha. No, don’t do that.

Audio? You can handle audio, kind of. You’ve certainly ripped MP3s to compact disc. Now, though, your boss (or the World Wide Web Consortium, whichever is worse) wants you to craft computer voices, position them in three-dimensional space, and specify background music and tones for special components.

You simply don’t have that training. Nor should anyone expect you to have it. Nor is there anywhere you can get that training.

Comment by Phil Ringnalda #
2005-11-06 19:19:57

Re: third-party tools not having access to the stylesheets: the future is now. (Well, is rc1 now.)

Comment by Mark #
2005-11-06 18:56:02

Oh, also, the only screen reader that supports aural stylesheets is Emacspeak, which kind of limits their effectiveness to the set of people who are T.V. Raman, who, incidentally, is one of the only people who should be allowed to make a home page for his dog.

Comment by Phil Ringnalda #
2005-11-06 19:12:50

So, despite not being new here, and knowing that the answer is Mu, what’s reasonable markup for punctuation used as ASCII art? Define mostly empty classes for wpasciiart, wpseparator, wpquotesasarrows, and whatever other junktuation is used, and span them all, so that Ramen can define a stylesheet for them if he develops a taste for reading WordPress weblogs? And how does a screen reader say ”<b>|</b>”?

Comment by Aristotle Pagaltzis #
2005-11-06 19:26:34

If you really want to do this semantically correctly, you’ll use an <ol> and use CSS to styled it to a single-line pipe-separated appearance.

Out of curiosity I checked to see how painful it would be, but it appears not very:

ol, ol > li { display: inline; padding: 0 }
ol > li + li:before { content: ' | ' }

(The non-cheating variant with a real border-left requires an addition rule and more tweaking to make it look decent.)

Comment by Aristotle Pagaltzis #
2005-11-06 19:28:48

And I can string three words together anymore without grossly violating whatever language I’m writing in.

Comment by Aristotle Pagaltzis #
2005-11-07 20:08:22

Which was supposed to say “can’t,” which just goes to show. Sigh.

Comment by Phil Ringnalda #
2005-11-07 20:31:26

I just used ”compeletely” in a comment (luckily, I get to edit my, even if I have to re-sign them): I think the font in the comment form is too small, and with no preview you don’t even get a second chance. Maybe I’ll default it to one click larger, and see if a bump in font-size makes it possible to see what you’re typing.

Comment by Phil Ringnalda #
2005-11-07 20:42:51

Jesus, Mary and Joseph! I get to edit *mine. That’s it, bigger fonts.

Comment by Mark #
2005-11-07 07:42:59

What Aristotle said. Stop thinking ”how do I mark up my meaningless separators?” and start thinking ”how do I mark up my meaningful content?”

For larger chunks of ASCII art (such as those in specifications), include a skip link before the art offering to skip past the following ASCII art.

Comment by Phil Ringnalda #
2005-11-07 09:36:44

Roughly Matt’s solution: ”if you’re going to argue that much about what color we paint the bikeshed, we just won’t paint the damn thing at all!”

And of course the final change in that set is vastly more interesting than any of the others.

Comment by Anne van Kesteren #
2005-11-07 14:11:03

Did you also file a bug on that H2 element having a class name of ”center”. Now I am aware that this is not technically a bug (class names have no meaning until someone designs a profile for them), but it looks stupid. (Especially if you think about redesigning/realigning/non-visual users et cetera.)

Comment by Phil Ringnalda #
2005-11-07 14:38:48

Nope, I’m a markup nazi but not a CSS nazi, and for no good reason I put class names on the CSS side of the line. I see that there’s also alignright and alignleft classes that were patiently waiting for me to discover how they want me to include floated images in posts. I suppose I should replace them with something like imageodd and imageeven or imagetextmoreimportant and imagetextlessimportant, but I’m afraid I’m usually so confused and unsure of what will happen with CSS that I find having a few classes that just flat out say ”this will put it right over there” comforting.

Comment by Matt #
2005-11-07 20:48:00

Less is less.

Comment by Phil Ringnalda #
2005-11-07 21:09:32

When someone’s head goes on the block, my question is not ”how many?” but ”whose?”

Comment by Phil Ringnalda #
2005-11-07 10:39:32

I haven’t looked: am I already using some ”sucks to be you, IE” CSS? The ol rather than ul aspect of actually numbering the metadata in IE seems particularly ugly.

Comment by Aristotle Pagaltzis #
2005-11-07 19:53:49

Not sure what you mean. If you mean IE insists on rendering numbers, then I’d imagine you can use list-style to fix that. Which is wrong, anyway, since it’s reserved for display: list-item, and the rule I wrote says display: inline, but we all know IE wasn’t made for CSS.

Comment by Phil Ringnalda #
2005-11-07 20:16:19

I mean: in IE neither one of those style rules is applied at all, it’s the exact equivalent of not having any CSS, just a default numbered list of sentences. And since there’s really no order inherent in ”here’s the category, here’s a link to the comments” having a numbered list that displays as a numbered list is quite jarring. I might do it if I already look wrong in IE, but if I haven’t made that first hurdle of giving up on it, then I’d need to look for selectors that work to make a inline list with no item markers, and content before all but the first item, in both IE and real browsers, and the sad truth of the matter is that I’m not enough of a believer in the sematic value of lists to go down that path unless someone just hands me the working CSS on a platter.

There are two reasons I use default templates most of the time: I have no design talent at all, and cross-browser CSS makes me want to hit something, very hard. Again and again, until my knuckles bleed, but still feeling that sweet rush as the impact shock runs up my arm and down the length of my spine… um.

Thanks for the offered CSS, but at least as of today I’m not willing to completely give up on working in IE.

Comment by Aristotle Pagaltzis #
2005-11-08 07:09:46

I mean: in IE neither one of those style rules is applied at all, it’s the exact equivalent of not having any CSS, just a default numbered list of sentences.

Ah! I didn’t think of that. IE understands neither the child nor the sibling selector. You can make it render as a single-line list by simply selecting all <li> descendents by using something like #tools li instead of #tools > li, but you can’t realistically make the separating pipes work because you really need the sibling selector to prevent prepending the pipe to the first list item.

As for ordered/unordered, I’ve just gotten into the habit of using more ordered lists these days, since many “unordered” lists you see on the web are actually “ordered list rendered with bullets.” But yeah, you’re right, this one really is an unordered list.

Comment by Scott #
2005-11-06 22:58:14

Hmm, maybe the decision whether to pause or to shout at a vertical bar is best left to Amazon’s Mechanical Turk…

Comment by David House #
2005-11-07 14:01:52

I was very confused when I came across this article in google reader. The title was apparently ’is not a better’. :)

Comment by Phil Ringnalda #
2005-11-07 14:40:29

Sorry, mine too. Long, drawn out post telling you more than you want to know about it to come, once I finish this bloody plugin for MT

Comment by Matt #
2005-11-07 20:47:43

Hopefully with more patches? ;)

Comment by Phil Ringnalda #
2005-11-07 21:12:25

Probably not yet: I still don’t have a feel for the flow and style. More like twenty thousand words as I talk my way through the code path, without the twenty characters of code that would solve it.

Comment by Phil Ringnalda #
2005-11-08 01:32:31

Only if you will accept the only patch which will work: an Atom 1.0 template, some svn deletes, and redirects from all the URLs that WP has used for RSS feeds in the past. Otherwise you’re stuck on the horns of invalid or silent data loss.

Comment by Matt #
2005-11-08 10:55:14

Drama queen!

Comment by Phil Ringnalda #
2005-11-08 13:00:01

Yeah, I know.

I’ve been told for four years now that nobody has the slightest interest in whether or not I can use a less-than in a title, I really shouldn’t get carried away just because I have to find a way to use them in titles for a large percentage of 300,000 items. It’s all good, it really doesn’t matter that WP produces feeds with titles that will partly disappear in most aggregators, and will be interpreted as (generally quite broken) HTML in others.

After all, it’s valid: if they can’t handle it, and would have to mishandle most other feeds to unbreak themselves, that’s their problem, right?

Comment by Phil Ringnalda #
2005-11-08 01:28:35

I can’t believe how many times I have to relearn this fact. It must be a survival instinct, that makes me keep forgetting about this huge impossible to shift elephant in the middle of the room.

If you need to use the character ”<” in a feed title, which I only sort-of do in my weblog, but which another rather large project I’m peripherally involved with absolutely does, you have three choices: produce valid RSS which will fail with the classic ”silent data loss” in virtually every reader currently available, knowingly produce invalid RSS because it will work perfectly in virtually every reader, and will not fail silently in the remaining ones, or, the only happy choice, use Atom instead since this problem is actually one of the primary reasons it started.

RSS, it’s been a great run, but I’m outta here: as soon as I’ve got a workable Atom 1.0 template and a patched up version of Magpie behind my aggregator, all of my RSS URLs will be redirected to Atom feeds.

Comment by Aristotle Pagaltzis #
2005-11-08 08:30:45

FWIW, the updated title of this entry now reads <strong> is not a better <b> in my aggregator, because your Atom feed says <title type="html"><![CDATA[<strong> is not a better <b>]]></title>, ie the angle brackets are triple-escaped.

(Btw, <q> tags being permitted in your comments would be nice.)

(PS.: I just caught my “tripe-escaped” typo at the last moment. More of the same aphorism?)

Comment by Phil Ringnalda #
2005-11-08 08:48:40

And then, akismet decided to call you comment spam, and I’m guessing that along the way at least one level of escaping was eaten, since I don’t have literal ”<” characters in the CDATA section and you sound more like you’re telling me I got it wrong than that I got it right (which doesn’t surprise me much, since I did it at 3am). It passes my ”do my aggregator and at least two big online aggregators interpret it correctly?” test, but I’m not newb enough to think that actually means anything.

Comment by Phil Ringnalda #
2005-11-08 09:35:32

Hmm. It looks right to me: the content is ampersand hash six zero semicolon, type=”html” says ”stick what your XML parser gives you directly into an HTML <div>,” and since it’s in a CDATA section, the parser should give you exactly that untouched: <. Am I being stupid again?

Comment by Phil Ringnalda #
2005-11-08 09:38:21

Okay, that could get on my nerves: whose idea was it to have my typed ”ampersand a m p semicolon hash six zero semicolon” actually interpreted? One unescape by the browser is enough, WP shouldn’t be touching that.

Comment by Aristotle Pagaltzis #
2005-11-08 12:44:52

No, it’s correct now. It was intermittently broken – then all the entry IDs changed, and these newly IDed entries are correctly escaped exactly twice. Previously there were double-escaped, but then also wrapped inside a CDATA section, ie effectively tripple-escaped.

I thought my comment got chomped by whatever change caused your IDs to change, and since the newly IDed entries were correctly escaped, I thought I’d just leave it at that.

Anyway, it’s all okay now.

Comment by Phil Ringnalda #
2005-11-08 21:49:44

And you’re right, <q> tags being permitted would be nice. In fact, I have a whole list:

  1. <ol>
  2. <ul>
  3. <dl>

Anything else we’re used to using that I forgot to allow? I’m undecided about <pre>, partly because I haven’t yet checked how destructive it might be.

Comment by Jacques Distler #
2005-11-08 21:58:17

Well, if you want me to post code samples, you’d better allow <pre>. My list is here. Of course, you can skip all the stuff in red.

Comment by Jacques Distler #
2005-11-08 22:03:32

Naturally, the signature-verification for the above comment is hopelessly spooged.

Even in the textarea, target=’_blank’ rel=’external’ attributes are added to the link, and the <pre> appears unescaped (whereas it was escaped in my posted comment).

Comment by Phil Ringnalda #
2005-11-08 22:52:57

Yeah, sorry, I seem to have broken something somewhere, that’s giving us a double-decode at times. That I’m willing to take the blame for, for sure; the target I’m disclaiming any knowledge of or responsiblity for, right up until I realize what I broke. Things appear to be fine in the db, it’s just a display issue, so you should be fine just ignoring it and carrying on.

Comment by Phil Ringnalda #
2005-11-09 22:34:29

Status: Good Signature

And ooh! Not my fault in either case; it’s a wonder it ever worked. The plugin’s signature-popup.php retains the original WordPress comments-popup.php’s use of add_filter('comment_text', 'popuplinks');, which inserts the target and rel, and then although the comment text is put into a textarea so HTML doesn’t get parsed, that doesn’t stop character entity references from being replaced. A quick trip through htmlspecialchars($comment_text,ENT_NOQUOTES) and all’s good (unless there’s a problem with that I haven’t thought of yet, which is why it isn’t a bug report against the plugin yet).

Then there’s the nofollow problem. I just dropped in a no-nofollow plugin without looking at it closely, and it wasn’t clearing them out soon enough, because the PGP plugin runs at priority 8 and it wasn’t running until 15. Easily fixed, but it forced me to look at just how horribly ham-fisted WordPress’s nofollow implementation is: the bloody thing inserts them before the comment is saved, which is absolutely unacceptable, since it’s then impossible to tell which were original and intentional ones, as we link to things where we want a condom around our links, and which were hopeless attempts at ocean-boiling that shouldn’t have been there in the first place, and should be removed. So, todo number n+1, terminate that bit of code. Meanwhile, please don’t sign a comment if you need to nofollow a link, because I can’t promise not to break your signature.

Comment by Phil Ringnalda #
2005-11-09 22:49:19

Ah, my own fault for picking a plugin written by someone who doesn’t seem to have RTFM where it says that to remove a filter that was set with a priority, you have to include the priority in the call to remove_filter(). … and the creek don’t rise, this ought to make it cleanly into the db.

Comment by Phil Ringnalda #
2005-11-09 00:28:40

Eh, what’s the worst that can happen with a <pre>? Eventually I’ll remember to make sure overflow’s defined for it.

No <tt> though: if you want monospace, you have to give me a reason with <code>, <kbd> or <samp>. And if you think you’ll feel the need to baffle me with Hebrew you can have the BiDi stuff, but otherwise it’s probably just going to add to the confusion level for casual commenters.

Comment by Jacques Distler #
2005-11-09 07:42:42

And if you think you’ll feel the need to baffle me with Hebrew you can have the BiDi stuff…

Actually, that’s pretty much superfluous. I now understand a lot more about Unicode’s Bidi support than I did then. You can do pretty much everything you want with super-secret non-printing Unicode characters, instead of those dedicated elements and attributes. I’ll have to try that out on your blog sometime.

Comment by Phil Ringnalda #
2005-11-09 09:22:24

Heh. I think I’ll consider that a bug report.

Four questions:

  1. Why is ”Reply to this comment” rtl in the source, but ltr in the display?
  2. What’s the difference between embedding and override?
  3. Would a ”no reversal” scanner just increment a counter for every U+202A, U+202B, U+202D, and U+202E, and decrement it for every U+202C, and then insert $counter U+202Cs at the end, or is it more complicated than that?
  4. Do they only apply to the parent block element, so rather than doing a complicated scanner I should just move my stuff out of your <div>? (Though there’s still the notification email to deal with…)
Comment by Jacques Distler #
2005-11-09 12:26:40

What’s the difference between embedding and override?

Unicode’s Bidi support divides characters between LTR, RTL and Neutral (like punctuation marks). If you are sailing along through some LTR text, and hit an RTL character, you switch directionality. You keep the directionality switched until you hit the next Neutral or LTR character, at which point you switch back. But, sometimes, we’d like to associate the punctuation marks with the RTL text (ie, not switch back as soon as we hit a punctuation mark). That’s what the enbedding characters are for.

Sometimes, we just want to override Unicode’s natural directionality and print some LTR letters in RTL order. That’s what the override characters are for.

Why is “Reply to this comment” rtl in the source, but ltr in the display?

That’s because, in (X)HTML, the directionality of the text reverts as soon as you close the element containing the text. When you ”view source”, you’re getting the pure Unicode algorithm, unsullied by the special meaning assigned to XHTML tags.

Would a “no reversal” scanner just increment a counter …

That’s basically right (once you keep in mind the difference between embedding and override characters).

Still, if you close your <div> immediately after my input, you don’t have to worry about any subsequent text.

Comment by Jacques Distler #
2005-11-10 08:00:24

More spooging of comment text invalidates PGP signatures and produces invalid XHTML.

I typed <blockquote><p>…</p></blockquote> for all three quotes above. WordPress, apparently, removes the <p>&lt/p> when storing to the database (thus invalidating the signature), and re-inserts <p>&lt/p> tags in two of the three quotes. Evidently, it screws up if the blockquote is the first thing in the comment.

No, I’m not gonna bother to sign this. WordPress seem to do far to much in the way of comment-spooging to make signatures useful.

Comment by Phil Ringnalda #
2005-11-10 08:47:45


That would be the ”correct ’invalid’ XHTML” feature, wouldn’t it? It knows it isn’t very good and isn’t even as good as it thinks it is.

At least I’ve patched around munging ¾ (I think). And I’m getting better about finding where things happen: with MT, I thought I knew where things were done, so I would scan the file I suspected; here, I have no clue, so I have to grep and wind up finding more, faster.

Comment by Phil Ringnalda #
2005-11-10 09:31:37

That would be the ”correct ’invalid’ XHTML” feature, wouldn’t it?

Heh. No, that would be me failing to include <p> in my list of allowed elements, wouldn’t it? One of these days I’ll learn that my first guess about what’s wrong is always wrong.

Comment by Jacques Distler #
2005-11-10 10:34:49

No, I think it’s both. You forgot to allow <p>. WordPress adds <p> to the output (even when, as in a signature-verification, you don’t want it to. But its algorithm for doing so is screwed-up, and it fails to add it when the blockquote is the first thing in the comment.

My general experience with playing around with WordPress is that it is hopeless in that regard, constantly mucking with the content, and storing its misbegotten idea of what the content should look like to the database. Bad, bad, bad.

Comment by Phil Ringnalda #
2005-11-10 11:34:35

Oh, I doubt that it’s hopeless: so far as I know, every bit of mucking comes from lines along the order of add_filter('perfectly_good_comment', 'muck_it_up'); which can easily be removed with remove_filter('perfectly_good_comment', 'muck_it_up'); in a plugin. Since I already pulled wp_rel_nofollow that only leaves a paired stripslashes at the start and addslashes at the end, and wp_filter_kses (the stripper of unallowed HTML) and balanceTags, which sometimes does.

I would hope that the slash-mucking isn’t actually required there to avoid SQL injection (in fact, I’m pretty sure it isn’t, since I see a sweep of always using the $wpdb->escape() function in the Subversion history), just trying to put things in a constant state for mangling, and I would hope that there aren’t any pages that display comments without reference to built in things with hooks like comment_text, so if that all proves right I should be able to do the right thing by removing those pre-storage filters, and adding them back (to the extent I want them at all) as display filters, except in the verification popup.

Probably it does make sense in the general case to have them as pre-save manglers, though: most people will never serve application/xhtml+xml, will never support PGP-signed comments, and will only rarely get comments with complex HTML, and even more rarely notice that it was mangled: having to fix things in the db by hand isn’t a problem for them, because they won’t ever do it anyway, and being able to later correct a mangling in an updated version of the program isn’t likely to please them more than speed today.

Comment by Jacques Distler #
2005-11-10 11:57:23

Accepting data and then screwing with the data before sticking it in the database, without beforehand showing the user the result of that mangling (who the *$#% needs a PREVIEW function? And, no, the lame-ass javascript ”live preview” thingie that some people use in WP gives you no indication of what will actually get stored in the database, much less what will be subsequentlly displayed) is wrong.


I don’t care if ”most” people won’t get bitten by it most of the time. It ’s unforgivably bad architecture, and when ”granny” gets bitten by it (as she sooner or later will), she’ll have even less idea how to fix the problem than Phil Ringnalda.

Comment by Aristotle Pagaltzis #
2005-11-10 20:24:03

If you want speed, you trade it for space by using some sort of caching mechanism. But you always keep a pristine copy of your input. That’s a cardinal rule. All else is madness.

Comment by Randy #
2005-11-19 11:47:18

I have never laughed out loud so many times while reading a blog than I have in the past 20 minutes while reading your blog.

You’re silly. I like that :)

Comment by Phil Ringnalda #
2005-11-22 21:06:32

Just a content-free comment because I need one from this post in the feed. Sorry, but apparently I’m silly, a description I don’t really remember being applied to me while I was sober in the last thirty-odd years.

2006-05-16 12:25:39

[…] Algunos van más allá y, aunque en la interfaz dicen claramente negrita, insertan en realidad elementos <STRONG>. Pues ésto tampoco tiene ningún sentido. ”Negrita” y ”resaltado” no son lo mismo. <STRONG> is not a better <B>. Para dar énfasis fuerte a algunas palabras se utiliza <strong>. <B> es puramente presentacional. Confundirlo puede dar lugar a errores gravísimos como el del enlace que he puesto anteriormente. […]


Sorry, the comment form is closed at this time.