By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,766 Members | 1,261 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,766 IT Pros & Developers. It's quick & easy.

Doctype question from amateur

P: n/a
I'm trying to clean up my website, and it's in pretty good shape now,
but I've gotten confused reading about Doctypes. My site is
http://www.simi-therapy.com
and my CSS is
http://www.simi-therapy.com/simitherapy-screen.css .

My pages all start with

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Language" content="en-us" />

I think this came from the template I am using, but I'm not sure.
Should I be using XHTML strict, or HTML 4.01 strict? And if I should
change it, what exactly do I put in each line?

I should mention that my pages have 2 things that don't validate in
XHTML strict. One is a Google search engine tag, and another is me
using an address block for formatting, because I haven't yet figured out
how to use CSS to get the same result.

Thanks for your help. This group teaches me a lot -- I am amazed at how
much I have learned here.

Deborah
Mar 25 '07 #1
Share this Question
Share on Google+
20 Replies


P: n/a
In article <lX****************@newssvr19.news.prodigy.net>,
Deborah <de*********@sbcglobal.netwrote:
I'm trying to clean up my website, and it's in pretty good shape now,
but I've gotten confused reading about Doctypes. My site is
http://www.simi-therapy.com
and my CSS is
http://www.simi-therapy.com/simitherapy-screen.css .

My pages all start with

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Language" content="en-us" />

I think this came from the template I am using, but I'm not sure.
Should I be using XHTML strict, or HTML 4.01 strict? And if I should
change it, what exactly do I put in each line?

I should mention that my pages have 2 things that don't validate in
XHTML strict. One is a Google search engine tag, and another is me
using an address block for formatting, because I haven't yet figured out
how to use CSS to get the same result.

Thanks for your help. This group teaches me a lot -- I am amazed at how
much I have learned here.

Deborah
You might consider simplifying your code and removing the <div
class="midHeader"</divfrom your html and removing the
associated css, and amalgamating into something like this instead:

..headerTitle {

background-color: rgb(140,170,230);
background-image: url('beach hill long.jpg');
background-repeat: no-repeat;
font-size: 200%;
font-weight: normal;
margin: 0;
padding: 0;
max-height: 100px;min-height: 100px;

}

This sort of thing seems to work nicer under different click
stops for text size adjustments in good browsers. IE6 and below
is not particularly happier I expect. But perhaps they are not
unhappier.

About xhtml. Perhaps leave it as it is for now. In future use
4.01 Strict and read up on how to run write the tags for this.
/Users/tedkroiter/Sites/droovies/test/test3.html:156: The XHTML
specification recommends including a space before the trailing
/> in empty XML elements. (You do not always do this). In 4.01
there is no need for this.

It is a peculiar use of address, yours, for each bit of an
address?? Get rid of the span in which it is enclosed. And I
would say if you use address, use <brto separate the lines, not
more "address".

--
dorayme
Mar 26 '07 #2

P: n/a
Scripsit Deborah:
I'm trying to clean up my website,
Well, there's always someone who rewrites working code, to clean it up or to
speed it up, but why? It's more constructive to orientate to start creating
new pages well.

Please note that this is c.i.w.a.stylesheets, not c.i.w.a.site-design.
Should I be using XHTML strict, or HTML 4.01 strict?
Yes.

Oh, you meant which is better? If you had to ask, then surely HTML 4.01
Strict.
And if I should
change it, what exactly do I put in each line?
You should write a DOCTYPE declaration exactly as specified in the HTML
specifications, mainly to make browsers work in "standards mode", provided
that you create pages that use CSS by the specifications.
I should mention that my pages have 2 things that don't validate in
XHTML strict. One is a Google search engine tag, and another is me
using an address block for formatting, because I haven't yet figured
out how to use CSS to get the same result.
We have a CSS question! The <addresselement indicates, by HTML
specifications, contact information for the author of the document. There is
nothing mystic in its rendering, except that IE oddly renders it in italics
by default. For an address in general (not the document author's address),
it's best to use just <divelements, since there's really no semantic
markup you could use. For example,

<div class="addr">
<div>Families Counseling Center</div>
<div>1633 Erringer Rd. #204</div>
<div>Simi Valley, CA 93065</div>
<div>805-583-3976</div>
</span>

Then simply set any desired styling for the outer <divor maybe for the
inner <div>s (if you want to affect e.g. the wrapping of long lines). If you
want italics (why?), then you'd use

..addr { font-style: italic; }

(The thing that makes your use of <addressinvalid - in the formal sense -
is that you have put it inside <span>. Changing <spanto <divwould fix
this, but the markup would still be semantically wrong.)

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Mar 26 '07 #3

P: n/a
On 26 Mar, 00:51, Deborah <deborah1...@sbcglobal.netwrote:
Should I be using XHTML strict, or HTML 4.01 strict?
HTML 4.01 Strict. Don't even think about it
(If you have to ask, you're most in need of the simple blanket answer)

* There are two entirely separate issues here: XHTML vs. HTML and
Strict vs. Transitional.

* You're doing this largely to make IE use "standards" rendering not
"quirks", rather than for any SGML reasons. Get that working right
first!

* The doctype declaration (what you put in your document) matters as
much as the doctype (what it refers to). Read this: http://hsivonen.iki.fi/doctype/
Use this:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/
TR/html4/strict.dtd" >

* Validation is good, but it's not everything. A skilled author can
still make an invalid page that behaves better than some badly thought-
out but valid pages. Validation's main benefit is that it's objective
and fairly simple. The rules are stated visibly, the tools are free
and easily available. "Quality" is much more subjective! If you're at
all unsure, go with "valid and 0 errors" because then you _know_ it's
valid.

* For most typical legacy pages, typical authors will do better by
switching doctypes to HTML 4.01 Strict straightaway, rather than a
Transitional doctype. The pages where Transitional is better are
actually quite rare: they need to be not only non-valid as Strict but
also well-formed and valid as Transitional. If they're not going to
meet either standard (the most common situation), then you might as
well switch straight to Strict and aim high.

If you switch to standards-based rendering early (even on an old page)
then you probably won't even notice the change. The mistake is to
start tidying up CSS and putting effort in while things are still in
quirks mode, then change later and break work you've already done.
<!-- Navigational metadata for large websites (an accessibility feature):
<link rel="top" href="index.htm" title="Homepage" />
No it isn't, that's just a comment. If you want them to be visible and
usable, then don't comment them out!

using an address block for formatting,
You're actually using multiple address blocks, one for each line.
There are a number of problems here:

* <addressmeans "contact information for an author" according to the
specification. This is OK for the author's personal documents, but is
unclear when they're authoring for a 3rd party. Is this the webmaster,
web designer or the site owner? (This has recently become a
significant legal issue for sites of UK companies).

* It's fairly strongly implied by the spec that there's only one
<addressper document, no matter who it belongs to.

* <addressis certainly not intended to be used line-by-line, as you
have it.

* Your literal validity issue is just that you've placed <address(a
block element) inside <span(an inline context).

On the whole, replace it by something simple like this:

<div class="sideBarText address" >
Families Counseling Center
<br>1633 Erringer Rd. #204
<br>Simi Valley, CA 93065
<br>805-583-3976
</div>

and a CSS fragment of
.address { font-style: italic; }


You'll probably find Joe Clark's accessibility book useful too
http://joeclark.org/book/sashay/serialization/

Mar 26 '07 #4

P: n/a
In article <ba******************@reader1.news.saunalahti.fi >,
"Jukka K. Korpela" <jk******@cs.tut.fiwrote:
The <addresselement indicates, by HTML
specifications, contact information for the author of the document. There is
nothing mystic in its rendering, except that IE oddly renders it in italics
by default. For an address in general (not the document author's address),
it's best to use just <divelements, since there's really no semantic
markup you could use. For example,

<div class="addr">
<div>Families Counseling Center</div>
<div>1633 Erringer Rd. #204</div>
<div>Simi Valley, CA 93065</div>
<div>805-583-3976</div>
It sure is an understandable mistake to use <addressfor an
address. Seems like an unfortunate decision in the standard. What
an oddly quaint _little_ issue, the author's address to be
grabbed by such a word! Now address generally, that is what would
be really useful to be granted an element. Address giving is so
common a task in website communication.

BTW, is there any reason not to just use <brin the above
alternative div suggestion, no inner divs where no different
styling is required for each line.

Be nice to have something like <address-generalFamilies
Counseling Center,1633 Erringer Rd., Simi Valley, CA
93065</address-generalwhere the commas would be rendered as
line breaks.

--
dorayme
Mar 26 '07 #5

P: n/a
In article
<do**********************************@news-vip.optusnet.com.au>,
dorayme <do************@optusnet.com.auwrote:
Be nice to have something like <address-generalFamilies
Counseling Center,1633 Erringer Rd., Simi Valley, CA
93065</address-generalwhere the commas would be rendered as
line breaks.
OK, not commas, maybe something as easy to type.

--
dorayme
Mar 26 '07 #6

P: n/a
Scripsit dorayme:
It sure is an understandable mistake to use <addressfor an
address.
Yes, and common enough to make even proper (specification-conformant) use of
<addressdubitable. For example, _if_ <addresswere used consistently, it
would make sense to have a user style sheet that renders its content
prominently and in a specific position, so that you can always use the
contact information easily. But since <addressmay contain just about
anything - some people use it just to get italics! - the idea is not that
great.
Seems like an unfortunate decision in the standard. What
an oddly quaint _little_ issue, the author's address to be
grabbed by such a word!
It's really the _name_ of the element (the tag name, the Generic Identifier)
that was poorly chosen. It should have been <author>.
Now address generally, that is what would
be really useful to be granted an element. Address giving is so
common a task in website communication.
But there are so many different kinds of addresses. There is little in
common between an email address and a postal address, for example.
BTW, is there any reason not to just use <brin the above
alternative div suggestion, no inner divs where no different
styling is required for each line.
My reason was that <divis slightly more logical (it divides the element
into subelements, as opposite to using separators between fragments of text)
and more suitable for styling (as well as DOM scripting). Maybe you don't
want to style the inner elements, but if you ever decide to, you will have
elements to play with, possibly without any extra markup, possibly with the
addition of class attributes.

For example, even if you expect an address to be rendered in an area wide
enough for every line, it doesn't cost much to prepare for narrower areas.
Using <div>, you can easily specify that if a <div(a logical subdivision
of the address, normally rendered on one line) is broken into several lines,
the second and subsequent lines will be indented a bit to indicate
continuation lines
Be nice to have something like <address-generalFamilies
Counseling Center,1633 Erringer Rd., Simi Valley, CA
93065</address-generalwhere the commas would be rendered as
line breaks.
That would not fit into the HTML and XML model, which have simplistic markup
structure, as opposite to the possibilities of SGML for example.

But if you use <divwith inner <div>s as I suggested (without the commas),
you can specify, in CSS, alternate renderings like the normal by-lines
presentation and a compact presentation as in your proposed _source_ (plus a
trailing period, which of course could be omitted if desired):

..addr div { display: inline; }
..addr div:after { content: ", "; }
..addr div:last-child:after { content: "."; }

(Allow 8 years for delivery of a CSS 3 specification and browser support to
it.)

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Mar 27 '07 #7

P: n/a
On Sun, 25 Mar 2007, Deborah wrote:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Language" content="en-us" />
*Everything* called <meta http-equivis only a poor ersatz,
a cheapo surrogate, a plastic imitation from China. Use the real
HTTP header instead. How to do this depends on your server software.
Ask in the comp.infosystems.www.servers.* groups.

--
In memoriam Alan J. Flavell
http://groups.google.com/groups/sear...Alan.J.Flavell
Mar 27 '07 #8

P: n/a
In article <f%*******************@reader1.news.saunalahti.fi> ,
"Jukka K. Korpela" <jk******@cs.tut.fiwrote:
Now address generally, that is what would
be really useful to be granted an element. Address giving is so
common a task in website communication.

But there are so many different kinds of addresses. There is little in
common between an email address and a postal address, for example.
I take your point. Still, I would have thought that postal
addresses are a big enough thing to be assigned an element. But
it is simple enough otherwise, I have just made a site which
contains a lot of postal addresses and I have used something
along the lines you have previously suggested, namely a div
classed (in my case as "address"). No other fancy inner styling
needed, just all left with breaks.
BTW, is there any reason not to just use <brin the above
alternative div suggestion, no inner divs where no different
styling is required for each line.

My reason was that <divis slightly more logical (it divides the element
into subelements, as opposite to using separators between fragments of text)
and more suitable for styling (as well as DOM scripting). Maybe you don't
want to style the inner elements, but if you ever decide to, you will have
elements to play with, possibly without any extra markup, possibly with the
addition of class attributes.
Fair enough. I should be so pure!

--
dorayme
Mar 27 '07 #9

P: n/a
On 27 Mar, 23:13, dorayme <doraymeRidT...@optusnet.com.auwrote:
I take your point. Still, I would have thought that postal
addresses are a big enough thing to be assigned an element.
They're too big a thing. If we have postal address, why not have phone
numbers and shoe sizes too? Should the "zip code" be US style, or
your own fractal canal-branch identifiers?

HTML is _minimal_ and it represents uniform _documents_. It has
concepts like "body text" and "header" that can be reasonably applied
to any document, but it doesn't have things like "address", "iambic
pentameter" or "computer manual menu description" (and of course
presentation). If you look at DocBook, which _does_ include markup
for such things (including <kitchen-sink>), then you should realise
what a good thing this is.

How to overlay things like addresses onto HTML is a known problem with
some tolerably well-known solutions. They can even disambiguate the
author's address from the publisher's address, from the described
resource's geographical location. Maybe there are a few too many such
protocols, but it's not impractical to use them.
Mar 28 '07 #10

P: n/a
Scripsit Andy Dingley:
HTML is _minimal_
No, it isn't. It has many markup elements and attributes that are far from
minimal.
and it represents uniform _documents_.
I fail to find the meaning (information content) of that statement.
If you look at DocBook, which _does_ include markup
for such things (including <kitchen-sink>), then you should realise
what a good thing this is.
Really? Quite the opposite is true. All the babble about "semantic Web" is
largely based on the observation that there is rather little semantics in
markup (and on a hopeless attempt to solve this by writing treatises on
semantic Web and unrealistic formalisms that are far more complex than any
proposed HTML enhancements ever).
How to overlay things like addresses onto HTML is a known problem with
some tolerably well-known solutions.
The _styling_ problem is solvable, though there is no _natural_ markup to
base the styling on. In simple cases, you could use different markup
elements (<addresswith <br>, <pwith <br>, <divwith <bror inner
<div>, <pre>, or <table>) and achieve the desired appearance using fairly
simple CSS.

But let's not pretend that this is an optimal situation. The address remains
just lines of text, with no defined semantics (except possibly wrong
semantics with <address>!) assigned to it in markup. You can't write a Perl
few-liner that extracts all address blocks from a given set of web pages,
since it cannot know what is an address block. Neither can users write user
style sheets that display addresses the way they prefer,

Besides, from the styling point of view, you cannot be confident about the
rendering in the sense that if your style sheet is not applied, the browser
still displays addresses in a useful way that gives a hint about their being
addresses.

By the way, to return from the markup philosophy to the topic area of this
group, the <preelement is a possible choice for address markup, since CSS
can be used to change its font (from the default monospace). The benefit is
that you don't need to add <divor <brmarkup to indicate line structure.
You could achieve the same using white-space: pre for e.g. a <divelement,
but then the presentation is confusing when CSS is off. So the following is
a reasonable choice:

<pre class="address">
address info here
divided into lines
with no extra markup
</pre>

with

..address { font-family: Arial, sans-serif; }

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Mar 28 '07 #11

P: n/a
On 28 Mar, 13:42, "Jukka K. Korpela" <jkorp...@cs.tut.fiwrote:
Scripsit Andy Dingley:
HTML is _minimal_

No, it isn't. It has many markup elements and attributes that are far from
minimal.
It certainly does, 3.2 far more so than 4.01 However compared to
what it _could_ have been, as exemplified by DocBook, HTML 3.0 or
whatever HTML 3.0 might have spawned as a successor, then it's still
pretty minimal.
and it represents uniform _documents_.

I fail to find the meaning (information content) of that statement.
HTML represents a "document". It makes no claims for anything more
than that, for a simple dictionary compatible meaning of document as
"a formal piece of writing that provides information". It doesn't
express any more semantics than I could find by reading a document in
Suomi: I can recognise paragraphs, sentences, emphasis, headings and
other structures common to Western languages, but the meaning of any
specific contexts applied to sections (such as an "address") is opaque
to me. I can even recognise a mechanical linkage for hypertext, but
there's no useful citation mechanism of the sort essential for
publishing theoretical physics papers.

On the whole, this is an excellent level at which it should have been
pitched. Praise Tim.

If you look at DocBook, which _does_ include markup
for such things (including <kitchen-sink>), then you should realise
what a good thing this is.
I mean of course that HTML's minimalism is a good thing. DocBook
combines the worst of bloat with least of usefulness outside its own
narrow scope.
a hopeless attempt to solve this by writing treatises on
semantic Web and unrealistic formalisms that are far more complex than any
proposed HTML enhancements ever).
The uselesness of SW would presumably be why Yahoo!'s recent "pipes"
fail to work, and are failing to work for thousands of users every
day?
How to overlay things like addresses onto HTML is a known problem with
some tolerably well-known solutions.

The _styling_ problem is solvable, though there is no _natural_ markup to
base the styling on.
As always, your narrow vision for anything outside SGML's narrow
descendants is blinding you to actually building anything
interestting, new or useful. I'm talking about vCard, Dublin Core and
their ilk (it ain't great, but it delivers).
You can't write a Perl
few-liner that extracts all address blocks from a given set of web pages,
since it cannot know what is an address block.
As it happens I have done. Python, many lines, evil piece of cruft,
mines a surprisingly large amount of useful data and is remarkably
accurate (it tends to fail with a null, rather than failing with a
false address).


Mar 28 '07 #12

P: n/a
Scripsit Andy Dingley:
>No, it isn't. It has many markup elements and attributes that are
far from minimal.

It certainly does, 3.2 far more so than 4.01
Are you kidding, or did you just write the exact opposite of what you meant.
However compared to
what it _could_ have been, as exemplified by DocBook, HTML 3.0 or
whatever HTML 3.0 might have spawned as a successor, then it's still
pretty minimal.
I'm afraid you have a private definition for "minimal". It's a Latin-based
word for "smallest", not "smaller".
The uselesness of SW would presumably be why Yahoo!'s recent "pipes"
fail to work, and are failing to work for thousands of users every
day?
Please explain how "Semantic Web" was necessary for "pipes", but please do
that on a forum where such issues are on-topic.
As always, your narrow vision for anything outside SGML's narrow
descendants is blinding you to actually building anything
interestting, new or useful. I'm talking about vCard, Dublin Core and
their ilk (it ain't great, but it delivers).
Blech. Was Dublin Core ever anything but a write-only system for metadata,
at a level that is vaguely defined yet complex enough to make writing real
work? Did it ever have any connection with CSS?
>You can't write a Perl
few-liner that extracts all address blocks from a given set of web
pages, since it cannot know what is an address block.

As it happens I have done.
Hardly. You have redefined the task, making it something sufficiently
trivial (and irrelevant), or you don't actually mean _web_ pages.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Mar 28 '07 #13

P: n/a
In article
<11*********************@p15g2000hsd.googlegroups. com>,
"Andy Dingley" <di*****@codesmiths.comwrote:
On 27 Mar, 23:13, dorayme <doraymeRidT...@optusnet.com.auwrote:
I take your point. Still, I would have thought that postal
addresses are a big enough thing to be assigned an element.

They're too big a thing. If we have postal address, why not have phone
numbers and shoe sizes too? Should the "zip code" be US style, or
your own fractal canal-branch identifiers?
The answer to this is easy enough surely? Because this would be
overkill. At least in my mind, a postal address is much the
better choice for address than authors address. What goes on an
envelope is universally known in form, it is almost beautiful.
Perhaps posting things is a dying art but be careful in
dismissing centuries (by now) of postal culture. Why be barbarian
about these things?

Seriously, I take your point too and yes, less is more powerful
and efficient, it is the basis and power of language (we only
need a few words, the rest is up to the way we put them together,
sure). But really, the context of my remarks was when I saw how
some egomaniac decided to push through "author's address".
Author's address, for god's sake!

Why ponce about styling bits of a reference to some point on the
earth? So no, it is silly to even think of specifying the idea of
postal address element in advance to the level of zip code bits.
The main point is one of meaning, all the text is part of a
location. How it is laid out from there is up to the author.
Personally, I favour no styling beyond line breaks, all left and
no messing about like addressing an average envelope (flat
rectangular paper pack that one can insert material, usually more
paper, and then seal by licking/pressing a pre gummed paper lid)

--
dorayme
Mar 28 '07 #14

P: n/a
In article <so*******************@reader1.news.saunalahti.fi> ,
"Jukka K. Korpela" <jk******@cs.tut.fiwrote:
By the way, to return from the markup philosophy to the topic area of this
group, the <preelement is a possible choice for address markup, since CSS
can be used to change its font (from the default monospace). The benefit is
that you don't need to add <divor <brmarkup to indicate line structure.
You could achieve the same using white-space: pre for e.g. a <divelement,
but then the presentation is confusing when CSS is off. So the following is
a reasonable choice:

<pre class="address">
address info here
divided into lines
with no extra markup
</pre>

with

.address { font-family: Arial, sans-serif; }
This is an excellent suggestion and while I was not so unhappy
with div and <br>s, I was not exactly happy either. Next time I
do address, I will do this pre of yours and see how it feels.

I know the hard-heads around here do not understand this, but for
some of us, authoring is a very emotional business. We need rules
that make us feel calm and steady and happy.

--
dorayme
Mar 28 '07 #15

P: n/a
On Wed, 28 Mar 2007 20:33:54 +0300, "Jukka K. Korpela"
<jk******@cs.tut.fiwrote:
>I'm afraid you have a private definition for "minimal". It's a Latin-based
word for "smallest", not "smaller".
HTML isn't perfectly minimal, but it (4 Strict anyway) is a reasonable
approximation. It's "minimal + legacy cruft", not "deliberately bigger
than minimal". We have absurdities like <varthat simply shouldn't be
there and are thankfully ignored, and we have badly stunted
half-features like <addressand <citethat exist, but not in a form
that's developed enough to be used.

On the brighter side, we've lost the purely presentationals and <em>,
<iand <subhave some justification to survive. It has also managed to
avoid sprouting excresences and protuberances as DocBook has. if you
don't think it's minimal, just think what it _could_ have been! It
might not be there, but its aspirations are in that direction, not the
other.
>Blech. Was Dublin Core ever anything but a write-only system for metadata,
Yes. You shouldn't have stopped paying attention at the end of the '90s.
>>You can't write a Perl
few-liner that extracts all address blocks from a given set of web
pages, since it cannot know what is an address block.

As it happens I have done.

Hardly. You have redefined the task, making it something sufficiently
trivial (and irrelevant), or you don't actually mean _web_ pages.
No, it slurps down arbitrary web pages. Web pages it gets from hints via
supplied FOAF, in an attempt to decorate the FOAF with things that look
like a suspicion of being addresses. As I said, it works surprisingly
well. It's not an address book replacement, but it's an interesting form
of data mining.

--
Cats have nine lives, which is why they rarely post to Usenet.
Mar 28 '07 #16

P: n/a
On Thu, 29 Mar 2007 07:36:24 +1000, dorayme
<do************@optusnet.com.auwrote:
>At least in my mind, a postal address is much the
better choice for address than authors address.
You're comparing apples and fish. Earth vegetables: one because of its
taxonomy in the plant kingdom, the other because it's regarded as food
by some vegetarians.

Equally with addresses: "postal address" is a format, a property of the
object itself, and one that makes no claims about the usage of it (who's
address?). "Author's address" is the address of a defined body (which
might be a script) but it doesn't say whether the format is geographical
or virtual.

I suspect that HTML's <addressis actually a poorly-named dc:creator,
because that's something that is a concept applicable to all HTML pages
and doesn't pre-suppose a format. It's "design by what's easy" rather
than "design for useful purpose".
Mar 28 '07 #17

P: n/a
In article <uq********************************@4ax.com>,
Andy Dingley <di*****@codesmiths.comwrote:
On Thu, 29 Mar 2007 07:36:24 +1000, dorayme
<do************@optusnet.com.auwrote:
At least in my mind, a postal address is much the
better choice for address than authors address.

You're comparing apples and fish. ...
I can't think how you could so misunderstand what I was saying.
Never mind about apples and fish and vegetarians and all this
cute stuff. Someone at some stage thought to make an element for
something about authors. Right? And I am saying they would have
better spent their time on making a different element.

Why don't you go and have a nice juicy steak. I think you need
one.

--
dorayme
Mar 28 '07 #18

P: n/a
On 29 Mar, 00:52, dorayme <doraymeRidT...@optusnet.com.auwrote:
Someone at some stage thought to make an element for
something about authors. Right? And I am saying they would have
better spent their time on making a different element.
Your hypothesis appears to depend on these two axiomatic statements:
"<postal-addresswould have been more useful than <author-address>"
"<postal-addresswould have be comparably difficult to define"

Although I can see some justification for the first, I disagree over
the second.

The problem is that one address is an apple, the other a fish. <author-
addressis defined by its external _usage_ (a fish) but <postal-
addressis defining an internal structure (an apple) without implying
what it's used for. They really have no more "address nature" in
common than the label applied, they're totally different tasks.
<author-addressis a property of the page, not a structure. <postal-
addressis a type definition, not a property.

As a result, the design work need for each of these just isn't
comparable. There's some justification for HTML to include an author
property (all pages have it), although I'd prefer to do it through a
more generalised mechanism like the existing <meta>, with an external
vocabulary like DC to specialise it into authorship. I can only
assume that <author-addresswas added with the aim of making this
visible on the rendered page body, unlike subject or description. A
dubious choice, IMHO.

If HTML sprouted a structural element, like <postal-addressit's a
non-trivial thing to add, mainly though it's a horrible problem for
i18n and it has the risk of making HTML into bloated DocBook. Avoid.

Mar 29 '07 #19

P: n/a
Scripsit Andy Dingley:
HTML isn't perfectly minimal,
Either something is minimal (smallest) or it isn't. Being minimal is by
definition extremal. You were just trying to say that HTML is small; please
admit that. (It's not a correct statement either, but it's relative enough
to be non-ridiculous.)
>Blech. Was Dublin Core ever anything but a write-only system for
metadata,

Yes. You shouldn't have stopped paying attention at the end of the
'90s.
Please show me one practical benefit you get from using Dublin Core on web
pages, but please do it on a forum where it is on-topic.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Mar 29 '07 #20

P: n/a
In article
<11**********************@b75g2000hsg.googlegroups .com>,
"Andy Dingley" <di*****@codesmiths.comwrote:
On 29 Mar, 00:52, dorayme <doraymeRidT...@optusnet.com.auwrote:
Someone at some stage thought to make an element for
something about authors. Right? And I am saying they would have
better spent their time on making a different element.

Your hypothesis appears to depend on these two axiomatic statements:
"<postal-addresswould have been more useful than <author-address>"
"<postal-addresswould have be comparably difficult to define"

Although I can see some justification for the first, I disagree over
the second.

The problem is that one address is an apple, the other a fish. <author-
addressis defined by its external _usage_ (a fish) but <postal-
addressis defining an internal structure (an apple) without implying
what it's used for. They really have no more "address nature"....
OK. It's clearly more complicated than I imagined! So thanks for
this. And I do take your point about keeping HTML as simple as
possible. Truth is, we should all be perfectly happy to style
divs and pres. I just thought ... well, I won't repeat it.

--
dorayme
Mar 29 '07 #21

This discussion thread is closed

Replies have been disabled for this discussion.