Lambda the Ultimate

For quoting inline there is the q element, although it's not styled italic yet.

You can change this in your user stylesheet. Not sure how you do this in Mozilla, but in Safari there's an option in the Advanced preferences to specify a user stylesheet. I have mine quite heavily customized. The relevant CSS is:

q { font-style: italic; }

Character entities should be fine. Whether a client has a font which can display the given character is another issue. Is there a set of character entities which clients are required to be able to display? The ⇒ entity displays fine in Safari for me.

If blockquotes would become blue, links in the quoted text would not longer stand out.

We'll use some other color, then, or maybe a different colored background.

It seems that I have no taste in these manners, so I will accept whatever others think best.

I also think the blue looks good. Blockquotes could certainly be formatted differently depending on where they appear.

Yes. The <blockquote> element should be used for block quotes, naturally. For inline quotes, I think we'll use the Q element, although I see it's been deprecated/removed in XHTML 2 (but its replacement isn't yet supported by browsers).

Until you serve the content as one of the XHTML content types, it doesn't matter how well you adhere to the XHTML DTDs, because browsers will treat your page as a form of Tag Soup anyway. Ian Hickson gives a good explanation of why this is the case, and why browsers can't automatically detect an XHTML document served as text/html.

You would, in fact, be better off serving your page as HTML4.01 Strict, because IE at least understands that. If you're not catering to the lowest common denominator, then you should serve with the correct content type, else you lose more by using XHTML markup than you gain.

(Note the page renders just fine. It's not broken. But there's no need to worry about standards adherence when you're using the wrong content type anyway, and there's no support of the right content type planned for IE - XHTML appears to be a stillborn!)

Until you serve the content as one of the XHTML content types, it doesn't matter how well you adhere to the XHTML DTDs, because browsers will treat your page as a form of Tag Soup anyway.

You would, in fact, be better off serving your page as HTML4.01 Strict, because IE at least understands that. If you're not catering to the lowest common denominator, then you should serve with the correct content type, else you lose more by using XHTML markup than you gain.

But there's no need to worry about standards adherence when you're using the wrong content type anyway, and there's no support of the right content type planned for IE - XHTML appears to be a stillborn!)

I'm interested in alignment with future standards for semantic markup, because in say five years time, the message source format might not have changed, but the tools serving it could be replaced entirely, as just happened in the transition from Manila.

Underlying my thinking on this is the fact that I've done a conversion of the Manila messages, and run into many of these kinds of issues, which is why that conversion hasn't been published yet.

We're considering some options in that area, but I think it'll be a while yet before anything is done.

It's just a question of priorities. I don't see any reason we should be rushing to install an image upload capability, and the approach we choose to provide that (e.g. Drupal module or something else) will be affected by other plans we're considering.

No one proposed a rush or priority inversion. No one else has the priority list, so how could we? Your answer is too vague for anyone to help with Drupal problems.

It could be done completely outside of Drupal as an FTP drop with username/password as per LtU user accounts. In fact that is probably the best way to do it.

The semantic richness of LtU would be vastly improved by the additional (visual) mode of communication. I keep hearing how we want Q and BLOCKQUOTE to track semantic content, not just formatting. Well, visual communication is orders of magnitude above all that, and rather easily implemented....

...whenever priorities allow, of course.

Your answer is too vague for anyone to help with Drupal problems.

We're not having any Drupal problems, other than the few minor limitations that have been raised in this forum.

It could be done completely outside of Drupal as an FTP drop with username/password as per LtU user accounts. In fact that is probably the best way to do it.

FTP is not enabled on the server, and there are no plans to enable it.

The semantic richness of LtU would be vastly improved by the additional (visual) mode of communication. I keep hearing how we want Q and BLOCKQUOTE to track semantic content, not just formatting. Well, visual communication is orders of magnitude above all that,

In that vein, I think something like MediaWiki's math markup might be even more useful. But you don't need to convince me that images are a good thing.

and rather easily implemented....

...whenever priorities allow, of course.

Right. The point about "easily implemented" is that there are many ways to add all sorts of features, some more easily than others, but we want them all to operate together coherently. Perhaps instead of priorities, I should have said dependencies: image upload is a little way down the critical path.