If I had heard or read about IE9 and xhtml, I’d forgotten. If it comes to pass, the semantic potential is amazing.
Nah. To introduce yourself through intelligent posts is more than sufficient.
Aha! Thanks for the new idea. I never thought of that, I’ve always used <pre> for preformatted code.
Another example of preformatted text is found in poetry and verse markup.
It’s OT, but what do you think of HTML5’s microdata, then? Don’t you like being able to download a company’s vcard and all? The reason why I like microformats is because it gives semantic value to items for both machine and the people.
[ot]There is an [ot] bbcode tag. FYI.
I lost interest in keeping current with html5 when they veered so vehemently onto the pave-the-cowpath um, path. I suggest that xhtml provides a better technology. The many and sundry values are beyond any reasonable scope of a structural markup language standard. On the other hand, a standardized set of xhtml schemata are, by definition* modifiable by the author to fit his own needs.
Regarding vcards, I use them on some of my own email accounts, and do appreciate corespondents who attach them to their own messages. The same machine readability may be had by the use of semantic element tags, were we able to take advantage of the capability. The concept of v- or hcards is a good one. It’s just a damned shame we have to use such a clumsy kluge of a work-around.
schema: an organization of concepts and actions that can be revised by new information about the world.
The STRONG element is for when semantic importance and strength is needed in context of the content, the B element is for when the contents importance needs to be stated with no semantic value… the SPAN on the other hand is purely for no importance needs to be conveyed (as denoted in the HTML Reference). If the content (as I said) is PURELY for stylistic reasons (and not for offsetting text for importance - semantically or otherwise) then SPAN is the more appropriate element.
I’ve never seen a lot of need for that - far better to dive straight in!
Aha! Thanks for the new idea. I never thought of that, I’ve always used <pre> for preformatted code.
You can use <pre> for any section that needs to be laid out in a particular way - and if the text doesn’t need to line up vertically then you can set it to a serif or sans-serif font (rather than monospace) in the CSS, which will look better.
However - I would generally avoid <pre> and instead just stick a <br> in where you need a line break. It’s generally accepted that two examples of content where a <br> is exactly the right element to use to force a new line are postal addresses and poetry - in both cases, the new line is an integral and essential part of the content, so it’s right to use an HTML element that sets a new line.
That sounds a bit muddled to me … how can it be considered more important, without attaching semantic value to it?
w3.org says “B: Renders as bold text style”. And that’s all it says. The <b> element makes things bold, end of story. So if you have text that you want to make physically bold, but without any structural or semantic importance attached to it, you can use <b>. While <span style=“font-weight:bold;”>…</span> does exactly the same job, I don’t see any reason to waste 32 characters to achieve exactly the same thing!
It may be generally accepted; that does not imply it is correct. In the case of poetry, not only are there rhyme and meter, but there is also typographic or visual rhythm. I strongly suggest you study the examples in the link I posted above.
While I am not comfortable with a blanket endorsement of the br element for marking up addresses, I will stipulate there are cases where it is sufficient.
While for some poetry the visual layout is important and goes beyond simple lines of text separated by line breaks, for most of it there is no more than that. A number of stanzas, which can be described by <p> elements, each formed of several lines of poetry, which can be separated by <br>s.
Where the poetry is of a simple form and lends itself to this style of markup, it is far preferable to use <br>s to separate the lines than to wrap the whole lot in a <pre> block, for just the same reason as tables should be marked up with table elements and not faked with <pre> - the markup describes the contents much better that way.
What Stevie meant is if the text didn’t require preserving of whitespace or displaying in a specific manner then it would be perfectly acceptable to use a <br /> (in some special circumstances). I also assume he wasn’t just talking about poetry or verse.
An address would be an example where you could use a <br /> generally speaking it doesn’t make a great deal of difference between an address; separated by comma; on one single line or forcing a break. That’s all he meant nothing more hopefully that clarifies things.
I know what he meant, xhtmlcoder. I give him the line breaks on most addresses, but poetry is formatted text by convention, if not also definition, thus pre is the semantic container for formatted text.
Far from it - I’m saying we should use HTML elements to encode structure into the poetic formatting.
Yes, there may be a small number of cases where that isn’t appropriate, and where <pre> is the best mechanism to preserve the precise layout that the author requires.
However, I maintain that in the vast majority of cases, paragraphs (which are analogous to stanzas) and line breaks are precisely the sum total of poetic formatting required (possibly with the addition of inline formatting such as italics, which is perfectly compatible with what I’m suggesting). The vast majority of poetry is simply made up of lines - the author never intended them to be set out in a precise and particular way, except that there would be line breaks and stanza breaks in certain places. That is precisely and exactly what using <p> and <br> achieves.
Using <pre>, on the other hand, is a kludge that should only ever be considered as a last resort, when the need to replicate a precise physical form outweighs any need to attach semantically relevant information to the contents.
