fantasai wrote:
> I'd rather see an element than an element.
> It is more generally useful.
Can you explain what the difference would be? Would an
element include copyright holders as opposed to creators? If so, I think
bundling them together makes gathering citation data much more
difficult.
On Mar 7, 2007, at 7:09 AM, Michael(tm) Smith wrote:
...
Amen.
It's really amusing to see people continuing to trot out
matter-of-fact statements dismissing XHTML. Those statements seem
to fall into two basic types that can be paraphrased as either:
- The only people who author documents i
Benjamin Hawkes-Lewis wrote:
An element might kill several of these birds with one stone.
I'd rather see an element than an element.
It is more generally useful.
~fantasai
On Wed, 07 Mar 2007 23:30:05 +0100, Anne van Kesteren <[EMAIL PROTECTED]>
wrote:
Yeah, I suppose that could work.
Cool. So do I. :)
FYI: my site is still .nl:
http://annevankesteren.nl/2004/06/standard-compliant-ie
Yea, sorry. And thanks for the pointer to the old discussion.
--
Asb
Benjamin Hawkes-Lewis skrev:
When I talked to WebKit developers about this, it seemed they considered
their support for real XHTML less reliable than their support for HTML
at that point. So while Safari's Accept header may be suboptimal,
there's nothing terribly wrong with interpreting it the sa
Simon Pieters wrote:
A conforming XHTML 1.0 document must conform to the DTD, which
effectively disallows xml:base and a whole bunch of other things
(including, say, namespace prefixes).
http://www.w3.org/TR/xhtml1/#strict
I am moving this discussion to the help list, as it is more about
On Thu, 08 Mar 2007 05:04:20 +0100, Michael Day <[EMAIL PROTECTED]> wrote:
> One downside of using HTML is that errors in the document can cause odd
> behaviour and can be harder to track down than errors in XML/XHTML.
Using an HTML4 validator or HTML5 conformance checker to ensure that the
docu