Subtitles and bylines
David Trimboli
4.01? For instance:
TITLE: Subtitles and Bylines in HTML
SUBTITLE: Being an Examination of Semantic Best Practices in the
Creation of Web Pages
BYLINE: by David Trimboli
The title would most likely be an H1. What about the others? They're not
really paragraphs, are they?
David
Stardate 7690.2
Stan Brown
<da...@trimboli.name>:
They could be, with classes of "subtitle" and "byline" respectively.
An alternative is to code
<h1>Title<br><small>Subtitle</small></h1>
if you want the subtitle to be considered part of the title for
citation purposes.
--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you
David E. Ross
> Sun, 9 Sep 2007 16:56:29 -0400 from David Trimboli
> <da...@trimboli.name>:
>> What would be the best way to represent subtitles and bylines in HTML
>> 4.01? For instance:
>>
>> TITLE: Subtitles and Bylines in HTML
>> SUBTITLE: Being an Examination of Semantic Best Practices in the
>> Creation of Web Pages
>> BYLINE: by David Trimboli
>>
>> The title would most likely be an H1. What about the others? They're not
>> really paragraphs, are they?
>
> They could be, with classes of "subtitle" and "byline" respectively.
>
> An alternative is to code
>
> <h1>Title<br><small>Subtitle</small></h1>
>
> if you want the subtitle to be considered part of the title for
> citation purposes.
>
I generally have
title <h1>abc</h1>
subtitle <h2>def</h2>
byline (with copyright notice) <h3>ghi</h3>
--
David E. Ross
<http://www.rossde.com/>
Concerned about someone (e.g., Pres. Bush) snooping
into your E-mail? Use PGP.
See my <http://www.rossde.com/PGP/>
Jukka K. Korpela
> What would be the best way to represent subtitles and bylines in HTML
> 4.01?
All ways are more or less debatable, but some of them make much more sense
than others.
> TITLE: Subtitles and Bylines in HTML
> SUBTITLE: Being an Examination of Semantic Best Practices in the
> Creation of Web Pages
> BYLINE: by David Trimboli
>
> The title would most likely be an H1. What about the others? They're
> not really paragraphs, are they?
No, they are not paragraphs. You could make them <div> elements, probably
with class attributes. You could make the byline an <address> element,
especially if you add some contact info other than just the name, like
e-mail address.
Some people would make the subtitle an <h2> element, but I think it is more
reasonable to treat it as part of <h1>:
<h1>Subtitles and Bylines in HTML<br>
<small>Being an Examination of Semantic Best Practices in the
Creation of Web Pages</small></h1>
Someone might argue that <small> is physical not logical markup, and in
principle that's true. The alternative is to use <span>, which means nothing
(i.e., is semantically empty) and does not affect rendering without CSS.
--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/
André Gillibert
> I generally have
> title <h1>abc</h1>
> subtitle <h2>def</h2>
> byline (with copyright notice) <h3>ghi</h3>
>
As a user of ISO-HTML rules for headings (who are the only ones
semantically meaningful), I don't like that.
h2 mustn't be a subtitle, it must be the heading of a logical subsection
of abc.
So, if h1 is the heading of a scientific article, h2 must be the heading
of individual sections (Abstract, Introduction, Materials & methods,
Results, Discussion).
Using h3 for byline and copyright notices is an error, even for the W3C
HTML 4.01 specification.
From the HTML 4.01 recommandation:
> A heading element briefly describes the topic of the section it
> introduces. Heading information may be used by user agents, for example,
> to construct a table of contents for a document automatically.
The byline doesn't describe the topic of the section it introduces.
You could said that, the three headings, taken together, describes the
topic, but, the W3C says *a heading element*, not several heading elements.
I could think of an HTML processor for printer that would display the h1
element alone on an even page, and the h2 element on a new page.
In practice, there are so few Web developers writing logically correct
code (in part because of CSS wrappers and all that non-sense) that it's
not possible to write alternative HTML processors except for internal use.
That would look weird: A subtitle on the next page!
Unfortunately, HTML doesn't provide any subtitle markup.
Personally, for bylines, I would use a paragraph with an appropriate class
name (e.g. "byline").
For subtitles, a paragraph is ugly, but is acceptable. At least, it
doesn't break the global structure of the document. It is just locally
logically incorrect.
Making the subtitle part of the heading is maybe a better choice.
--
You can contact me at <tabkanDEL...@yahoDELETETHATo.fr>
André Gillibert
> Scripsit David Trimboli:
>> The title would most likely be an H1. What about the others? They're
>> not really paragraphs, are they?
>
> No, they are not paragraphs.
Right.
> You could make them <div> elements, probably with class attributes.
Yes, that's what I would have done, back in time, before I tried to write
a non-CSS HTML processor and discovered that DIV was so semantically empty
that every DIV element was a nightmare to interpret in a document.
Sometimes ignoring DIV elements is the right thing to do. But sometimes
DIV elements should be rendered as separate sections...
> You could make the byline an <address> element, especially if you add
> some contact info other than just the name, like e-mail address.
Yep, this is ADDRESS is supposed to give contact info for the author of
the document or a major part of the document.
> Some people would make the subtitle an <h2> element, but I think it is
> more reasonable to treat it as part of <h1>:
>
I agree.
André Gillibert
> "David E. Ross" <nob...@nowhere.not> writes:
>>>> TITLE: Subtitles and Bylines in HTML
>>>> SUBTITLE: Being an Examination of Semantic Best
>>> <h1>Title<br><small>Subtitle</small></h1>
>> title <h1>abc</h1>
>> subtitle <h2>def</h2>
>
> »There are six levels of headings in HTML with H1 as the
> most important and H6 as the least.« - HTML 4.01 Specification
>
> This might be interpret to support your usage,
> even if this might be a non-standard interpretation.
>
This would be a mis-interpretation of "important" in this context, I think.
A heading introduces a section, and actually, the "importance" of a
heading is relative to the importance of the section it introduces (major
section > sub-section).
> But what would be used as a heading element to
> introduce a /next/ section of the document
> that was titled in this way? h2? h3? h4?
>
h3 would be the choice respecting ISO-HTML rules.
>> byline (with copyright notice) <h3>ghi</h3>
>
> »A heading element briefly describes the topic of the
> section it introduces.« - HTML 4.01 Specification
>
> A byline does not describe a topic.
>
I too overlooked that, at first sight.
David E. Ross specified the byline *outside* of a heading, at the block
level, using HTML 4.01 Transitional or putting it at a place expecting
"flow" markup.
<h3>ghi</h3> represents a subsection of the article.
Putting the byline inside a block-level element of some meaningful type
would be more correct.
André Gillibert
> The byline doesn't describe the topic of the section it introduces.
> You could said that, the three headings, taken together, describes the
> topic, but, the W3C says *a heading element*, not several heading
> elements.
>
Excuse me. I overlooked David E. Ross HTML code. Now, I notice that the
byline was outside of a heading element.
Lars Eighner
talented David Trimboli broadcast on comp.infosystems.www.authoring.html:
If the subtitle belongs to the whole work (and does not distingish the
present work in a series which all share the same title) then it belongs in
H1. Use a colon, BR, and SPAN if you please to style it. This is consistent
with most styles of citation and library catalogs. This may be troublesome
for historic works which have many levels of subtitles and subtitles with
many dozens of words. HTML is not the SGML application of choice for
marking up text for exegesis, but otherwise I expect people will understand
if you have to resort to something expedient. That is, if you are trying to
represent the first folio of something so it can be compared with the first
quarto, where the long esses had better be long esses and every device on
the title page has to represented, HTML is not suitable. But most general
readers will be happy with <H1>King Lear</H1>.
There is no HTML element that is really suited for the byline. There is
something fundamentally wrong in using P, ADDRESS, CITE (in some kind of
block), and so forth. The byline does violence to the logical meaning of
these elements. Fortunately, there is a general element, so use DIV with
a class of byline.
If the subtitle DOES represent parts of a series (for example: American
History: The US to the Civil War; American History: The Civil War to
Present) then use H2, even if you are not doing the whole series or any
other part of it (that is, even if you only have one H2 in your document).
In such a case, the subtitle is a division of the work, even if it happens
that you will not present the other parts.
--
Lars Eighner <http://larseighner.com/> <http://myspace.com/larseighner>
Countdown: 498 days to go.
What do you do when you're debranded?
Jonathan N. Little
I would be more inclined to use SPAN, your could give the SPAN a class
like 'subtitle' but not needed you could just use the association that a
SPAN within the H1 is a sub-heading and uses modifying style. A little
cleaner on the markup.
h1 span {
display: block; margin: 0 .25em; font-size: .8em;
}
.byline {
padding-right: .5em; border-top: 1px solid #555; text-align: right;
}
<h1>
Subtitles and Bylines in HTML
<span>
Being an Examination of Semantic Best Practices in the Creation of
Web Pages
</span>
</h1>
<div class="byline">by David Trimboli</div>
<p>The article ...
--
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
Jonathan N. Little
> to reformat lines 1, 2 and 3?
>
By themselves? SPANS are inline elements that need to be in a block
elements. You would use a SPAN if you wanted to create a block element
within another block element where is is not allowed. You can then
'break the rules' styling the SPAN as block.
You need to research block and inline elements. Try tutorials at htmldog.com
Helpful person
wrote:
>
> - Show quoted text -
One could use the inline span to redefine the various lines in the H1
block (if that is the one to use).
Jukka K. Korpela
>> - Show quoted text -
>
> One could use the inline span to redefine the various lines in the H1
> block (if that is the one to use).
Apparently you did not understand a word of the message that you replied to,
and you indicated this by fullquoting it.
There's nothing helpful in your postings, and you look more and more like a
troll, or completely clueless. In the latter case, find a decent book on web
authoring, read it, and don't post before you have seriously tried to
understand it.
Oh, and please keep using your current fake identity _until_ you have a
clue. Thank you in advance.
Peter J Ross
I think that in this case they're all syntactically part of the title,
so should all be part of the same element.
Example:
<h1>
<span id="title">Subtitles and bylines in
HTML<span class="hidden">:</span></span>
<span id="subtitle">Being an Examination of Semantic Best
Practices in the Creation of Web
Pages<span class="hidden">,</span></span>
<span id="byline">by David Trimboli</span>
</h1>
#title {display: block;}
#subtitle {display: block; font-size: 80%;}
#byline {display: block: font-size: 80%; font-style: italic;}
.hidden {display: none;}
The reason for including hidden punctuation is that it will help
users of non-CSS browsers to make sense of the text.
The "byline" would be separate in terms of syntax if you omitted "by",
in which case <address> might be appropriate markup.
I don't think there's an entirely satisfactory way of marking up your
text semantically, and there may well be better approximations than
mine. HTML's techie origins result in the presence of plenty of tags
like <code> and <samp> and <kbd>, but nothing comparable to them for
literature, such as <subtitle>, <dedication> and <stanza>. The only
practicable way of obtaining such precision is to use XML.
--
PJR :-)
Helpful person
No need to be rude, I asked a simple question. Why not re format the
block element with the inline element? It would be easier to answer
than respond the way you did. I did not offer any advice, just asked
a question.
André Gillibert
> HTML's techie origins result in the presence of plenty of tags
> like <code> and <samp> and <kbd>, but nothing comparable to them for
> literature, such as <subtitle>, <dedication> and <stanza>. The only
> practicable way of obtaining such precision is to use XML.
>
Or DocBook, which exists as an SGML or XML application.
David Trimboli
> David Trimboli <da...@trimboli.name> wrote:
>> What would be the best way to represent subtitles and bylines in HTML
>> 4.01? For instance:
> I think that in this case they're all syntactically part of the title,
> so should all be part of the same element.
>
> Example:
>
> <h1>
> <span id="title">Subtitles and bylines in
> HTML<span class="hidden">:</span></span>
> <span id="subtitle">Being an Examination of Semantic Best
> Practices in the Creation of Web
> Pages<span class="hidden">,</span></span>
> <span id="byline">by David Trimboli</span>
> </h1>
>
> #title {display: block;}
> #subtitle {display: block; font-size: 80%;}
> #byline {display: block: font-size: 80%; font-style: italic;}
> .hidden {display: none;}
>
> The reason for including hidden punctuation is that it will help
> users of non-CSS browsers to make sense of the text.
Ooh, this is very clever! Great idea, Peter.
> The "byline" would be separate in terms of syntax if you omitted "by",
> in which case <address> might be appropriate markup.
Hmm. Does a byline really count as "contact information"? I suppose you
could look at it that way: it's very sparse contact information on the
author of the piece.
Thanks for the reply, Peter.
David
Stardate 7693.0
David Trimboli
> Scripsit David Trimboli:
>> What would be the best way to represent subtitles and bylines in HTML
>> 4.01?
>> The title would most likely be an H1. What about the others? They're
>> not really paragraphs, are they?
>
> No, they are not paragraphs. You could make them <div> elements,
> probably with class attributes. You could make the byline an
> <address> element, especially if you add some contact info other than
> just the name, like e-mail address.
> <h1>Subtitles and Bylines in HTML<br>
> <small>Being an Examination of Semantic Best Practices in the
> Creation of Web Pages</small></h1>
>
> Someone might argue that <small> is physical not logical markup, and
> in principle that's true. The alternative is to use <span>, which
> means nothing (i.e., is semantically empty) and does not affect
> rendering without CSS.
Wouldn't <br> be physical markup too? And wouldn't <div> be as
semantically empty as <span>?
Still, I think you're right: lacking more specific HTML elements, title
and subtitle belong to the same heading level.
Thanks for the response, Jukka!
David
Stardate 7693.0
André Gillibert
> Hmm. Does a byline really count as "contact information"?
Unless it is:
For example: "Written and maintained by FirstName LastName
<some...@somewhere.com>"
> I suppose you could look at it that way: it's very sparse contact
> information on the author of the piece.
Unless it isn't sparse. ;)
Stan Brown
<nob...@nowhere.not>:
> I generally have
> title <h1>abc</h1>
> subtitle <h2>def</h2>
> byline (with copyright notice) <h3>ghi</h3>
But that says (falsely) that "def" is the title of a subdivision of
the document, and "ghi" is the title of a subdivision of "def".
Peter J Ross
-0400, David Trimboli <da...@trimboli.name> wrote:
> Peter J Ross <p...@example.invalid> wrote:
>> David Trimboli <da...@trimboli.name> wrote:
>>> What would be the best way to represent subtitles and bylines in HTML
>>> 4.01? For instance:
>> [...]
>> I think that in this case they're all syntactically part of the title,
>> so should all be part of the same element.
>>
>> Example:
>>
>> <h1>
>> <span id="title">Subtitles and bylines in
>> HTML<span class="hidden">:</span></span>
>> <span id="subtitle">Being an Examination of Semantic Best
>> Practices in the Creation of Web
>> Pages<span class="hidden">,</span></span>
>> <span id="byline">by David Trimboli</span>
>> </h1>
>>
>> #title {display: block;}
>> #subtitle {display: block; font-size: 80%;}
>> #byline {display: block: font-size: 80%; font-style: italic;}
>> .hidden {display: none;}
>>
>> The reason for including hidden punctuation is that it will help
>> users of non-CSS browsers to make sense of the text.
>
> Ooh, this is very clever! Great idea, Peter.
Thanks. I write poetry, some of which is experimental, so I have even
worse problems than yours. A strophe is not a paragraph!
>> The "byline" would be separate in terms of syntax if you omitted "by",
>> in which case <address> might be appropriate markup.
>
> Hmm. Does a byline really count as "contact information"? I suppose you
> could look at it that way: it's very sparse contact information on the
> author of the piece.
If you use <address>, you'll have to include at least an <a
href="mailto:.."> if you want semantic markup.
> Thanks for the reply, Peter.
Thanks for caring about the meaning of your HTML tags, David.
--
PJR :-)
John Hosking
>
> Thanks. I write poetry, some of which is experimental, so I have even
> worse problems than yours.
Isn't _all_ poetry experimental? Or is some of it, um, practical?
> A strophe is not a paragraph!
At least to get to use <br> with a clear conscience. :-)
--
John
Jukka K. Korpela
> If you use <address>, you'll have to include at least an <a
> href="mailto:.."> if you want semantic markup.
No, of course not. The <address> element indicates, in principle, contact
information for the author of the document (or part of document). One might
argue that even the name constitutes contact information (it can really be
useful for contacting the author). Surely a postal address or a phone number
qualifies as contact information. Even if you play the most semantic game,
you are not required to specify any particular type of contact info.
If you decide to include an email address (which is generally a good idea),
it is usually a good idea to make it a mailto link. But this is by no means
part of the semantics of <address>.
André Gillibert
> If you use <address>, you'll have to include at least an <a
> href="mailto:.."> if you want semantic markup.
>
I think that a country, a town, a street and house number, a name, and a
postal code are sufficient.
Any type of contact information is ok.
> Thanks for caring about the meaning of your HTML tags, David.
If HTML had more tags, it would be easier.
Andreas Prilop
> If HTML had more tags, it would be easier.
Many authors are content with one tag - <div>.
:-(
André Gillibert
Sadly, it's possible to write valid (non-conforming) HTML and an
associated stylesheet conveying ZERO semantic information, for any final
rendering with CSS user agents.
Because of the power of the CSS, it's possible to display tables with only
SPAN elements...
Actually, whole pages could be written with a single paragraph and many
span elements.
It would also be possible to randomly nest elements (following the rules
of the W3C DTD and nothing more), uniquely identifying every element (for
styling purpose only) via a random value on a randomly chosen attribute
(like lang, title, etc.), then, with CSS, a specific layout would be given
for every element.
Sadly, there are many authors that write code looking like that.
Jukka K. Korpela
> Many authors are content with one tag - <div>.
> :-(
Well, not quite. Most of them still have <title>, and quite often <meta>
too. And it's hard to imagine authoring these days without <style> or
<link>, unless you are only interested in delivering some content, accepting
popular browsers's crappy rendering defaults.
Even within the document body, they don't quite restrict themselves to
<div>. They probably still use <a>, since they use links of some kind.
The interesting question is why they still use <div> or <span> (or both!)
within the document body, when they could use just <a>. It's so much shorter
and nicer, and it lets you make an element link whenever you want to. Oh,
but here we have nasty artificial restriction that forbids nesting of <a>
elements! But who cares? Both browsers let you nest them at will, don't
they?
So let's use just <a> inside body, and use CSS to define the meanings. Like
this:
<a class="heading1">Hello world</a>
<a class="par">This is a paragraph with some
<a class="em">emphasized text</a>.
Oh, and <a href="click.html">click here</a>!</a>
(Insert an arbitrary number of emoticons or sarcasticons here.)
André Gillibert
> So let's use just <a> inside body, and use CSS to define the meanings.
> Like this:
>
> <a class="heading1">Hello world</a>
> <a class="par">This is a paragraph with some
> <a class="em">emphasized text</a>.
> Oh, and <a href="click.html">click here</a>!</a>
>
Better:
<a lang="a0" dir="a0">Hello world</a> <!-- use a[lang=a0][dir=a0] as CSS
selector -->
<a title="a0" type="a0">This is a paragraph with some
<a charset="a0" coords="a0">emphasized text</a>.
Oh, and <a href="click.html" lang="a0" type="a0">click here</a>!</a>
Using random elements, with the only constraint that they nest as
specified by http://www.w3.org/TR/html4/strict.dtd, it's possible to write
valid non-sense code.
> (Insert an arbitrary number of emoticons or sarcasticons here.)
Same thing here.
Jukka K. Korpela
> <a lang="a0" dir="a0">Hello world</a> <!-- use a[lang=a0][dir=a0] as
> CSS selector -->
Kewl!
> Using random elements, with the only constraint that they nest as
> specified by http://www.w3.org/TR/html4/strict.dtd, it's possible to
> write valid non-sense code.
Well, nesting of <a> elements is forbidden by all HTML 4.01 DTD's.
But let's not worry about that. We can move to XHTML 1.0! Its DTDs allow the
nesting; just the prose forbids it, and who cares about prose these days?
>> (Insert an arbitrary number of emoticons or sarcasticons here.)
>
> Same thing here.
<a dir="x9">Me too</a>
Andy Dingley
> An alternative is to code
> <h1>Title<br><small>Subtitle</small></h1>
That works presentationally, but I don't like the semantics of it.
It's one of those cases where <br> and the whole issue of "Empty
elements considered procedural (and harmful)" actually does make a
difference.
>From a SemWeb PoV (my boundless optimism!), this is far better:
<h1>Title</h1>
<h2>Subtitle</h2>
If you don't like the presentation, then fix it (we all know how to do
that). But don't mess with the markup of the content just to make the
presentation fit.
> if you want the subtitle to be considered part of the title for
> citation purposes.
That's certainly a justification for the "subtitle as child of title"
approach that your example markup demonstrates. However I'm finding it
hard to think why I'd ever want to do this, or why it would ever be
anythin other than inappropriate. Subtitles aren't titles, they're a
separate property. Now it's obvious that some present-generation
spidering and indexing tools can't cope with more than one captioning
property on a resource at a time, but that's their limitation, not
something we should pander to for the future. Otherwise we'll be
forever repeating the old mistakes of the web and the 10 years it has
taken to displace HTML 3.2.
Andy Dingley
> Many authors are content with one tag - <div>.
> :-(
There's nothing _wrong_ with that, it's just not informative.
It's also pretty rare to encounter it. For most people who code in
that style, they're far more likely to be blindly nesting <p>'s all
over the place.
> On Tue, 11 Sep 2007, Andr? Gillibert wrote:
> > If HTML had more tags, it would be easier.
DocBook has more tags, and it clearly isn't.
HTML 4.01 Strict has pretty much enough tags (slightly too many in
fact) to describe any "document", at a level that's appropriate for
"documents" and no more than that.
If you go beyond that your requirements expand _enormously_ rapidly
and it's instantly unworkable. DocBook is the prime example: it's
targeted at a failry narrow marketplace, yet it already has too much
in there to comprehend.
If you're going down the "markup adequate to deal with the application
problem in detail" then you really have to look at an annotational
characterisation that's additional to structure, such as using RDF
Schema or OWL to express some vocabulary that's connected through
attributes on the content elements. Leave the elements themselves and
their DTD deliberately simple, expressing structure alone and not
attempting to do semantics.
You don't _need_ to couple structure and schema like this. It's an
accidental coupling, not a deliberate one and it's certainly rarely
beneficial. If you've done this (by accident) then it simply makes the
structure too complex and too difficult to easily check for validity.
If you try to take things far enough so that a semantically-structured
schema might start to have some benefit (i.e. anything semantically
meaningless would already have been forbidden by the structural
rules), then you find it doesn't actually work (academia passim) and
most importantly you find yourself with an unstable structure and
terrible version-management problems. Any subtle change in semantics
is also likely to invalidate the structural level of your old
documents.
André Gillibert
>> if you want the subtitle to be considered part of the title for
>> citation purposes.
>
> That's certainly a justification for the "subtitle as child of title"
> approach that your example markup demonstrates. However I'm finding it
> hard to think why I'd ever want to do this, or why it would ever be
> anythin other than inappropriate. Subtitles aren't titles, they're a
> separate property.
Headings aren't titles.
Titles *and subtitles* are part of headings, in my opinion.
Do you propose anything better?
<h1>title</h1><h2>subtitle</h2>
Is MUCH more incorrect than putting the subtitle in the heading.
Jukka K. Korpela
> <h1>Title</h1>
> <h2>Subtitle</h2>
Let's see... so Darwin's great work would have
<h1>On the Origin of Species</h1>
<h2>by Means of Natural Selection
or the Preservation of Favoured Races in the Struggle for Life</h2>
or maybe (applying your logic to subsubtitles as well)
<h1>On the Origin of Species</h1>
<h2>by Means of Natural Selection</h2>
<h3>or the Preservation of Favoured Races in the Struggle for Life</h3>
Naturally (no pun intended), the page would have other h2 and h3 elements as
well, for chapter and section headings.
Now, let's ask some software (perhaps a browser) generate a table of
contents for the page, in the apparent way that picks up the h2, h3...
elements. How would it look like?
Do we need any more arguments against your logic?
Peter J Ross
+0200, André Gillibert <tabkanDEL...@yahodeletethato.fr> wrote:
> Peter J Ross wrote:
>
>> If you use <address>, you'll have to include at least an <a
>> href="mailto:.."> if you want semantic markup.
>>
>
> I think that a country, a town, a street and house number, a name, and a
> postal code are sufficient.
> Any type of contact information is ok.
I stand corrected by you and Jukka.
>> Thanks for caring about the meaning of your HTML tags, David.
>
> If HTML had more tags, it would be easier.
As I think I implied, that's what XML is for.
--
PJR :-)
Andy Mabbett
<tabkanDEL...@yahodeletethato.fr> writes
>Peter J Ross wrote:
>
>> If you use <address>, you'll have to include at least an <a
>> href="mailto:.."> if you want semantic markup.
>>
>
>I think that a country, a town, a street and house number, a name, and
>a postal code are sufficient.
>Any type of contact information is ok.
And could, of course, be semantically marked up using the hCard
microformat:
<http://microformats.org/wiki/hcard>
to make them more usefully parsable.
--
Andy Mabbett
* Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>
* Free Our Data: <http://www.freeourdata.org.uk>
* Are you using Microformats, yet: <http://microformats.org/> ?
Andy Dingley
wrote:
> And could, of course, be semantically marked up using the hCard
> microformat:
In HTML? (rather than XHTML)
Andy Mabbett
Dingley <din...@codesmiths.com> writes
Microformats can be used in HTML 4.*, XHTML, RSS/ Atom and more. AFAIK,
they can be used in earlier flavours of HTML, too.