I shall jump on the XHTML bandwagon.
I run my perfectly good html4/strict pages thru
$ tidy -asxhtml -utf8 #to get:
<!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"> <head><meta
http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta
http-equiv="Content-Language" content="zh-tw" />
knowing all the time as http://hixie.ch/advocacy/xhtml says,
that all I am doing is downgrading my pages from html4/strict.dtd to
quirks mode... (I suppose one day some Prince Charming browser will
come along and detect all this so there will be some actual benefit.)
I will not use any .htaccess files on my web host. No more single
point of failures for me. Anyway my pages are to look the same if read
from file:/// or http://.
Furthermore, I will still use their same .html filenames and not
..xhtml, as I don't want to break everybody's links to me. (I
understand that one needs .xhtml and
content="application/xhtml+xml..." in e.g., firefox to trigger any
XHTML treatment. I am thus far from that.)
For my English pages, even though I could still declare ISO-8859-1, I
shall declare utf-8, being modern and such.
So I suppose my only questions are:
Shall I fear the old browsers of http://www.yourhtmlsource.com/access...xmldeclaration
or go ahead and use tidy --add-xml-decl 1, producing a
<?xml version="1.0"?> or better yet add
<?xml version="1.0" encoding="UTF-8"?>
UTF-8 or utf-8?
Though tidy doesn't, shall I still proceed and bother with the
<html xmlns="..." lang="zh-tw" xml:lang="zh-tw"> lang stuff, or is my
http-equiv line above "equiv" enough? 24  2592 
Dan Jacobson wrote: I shall jump on the XHTML bandwagon.
Please don't - as text/html it is, at best, silly. With the proper
content-type it enjoys little support from browsers, and support is
generally worse then for text/html documents (e.g. say goodbye to
document.write and incremental rendering in Firefox).
that all I am doing is downgrading my pages from html4/strict.dtd to
quirks mode... (I suppose one day some Prince Charming browser will
come along and detect all this so there will be some actual benefit.)
So this browser will check that the document is well formed XML, then push
it through an XML parser instead of a tag soup slurper? Sounds like a lot
of work for ... no benefit.
Furthermore, I will still use their same .html filenames and not
.xhtml, as I don't want to break everybody's links to me. (I
understand that one needs .xhtml and
content="application/xhtml+xml..." in e.g., firefox to trigger any
XHTML treatment. I am thus far from that.)
No. For local files I believe Firefox pays attention to the file extensions,
for remote files only the content-type in the HTTP header counts. The Meta
data is used only to find out the character encoding when webservers fail
to specify it.
For my English pages, even though I could still declare ISO-8859-1, I
shall declare utf-8, being modern and such.
There are characters that one might use in an English language document that
have different locations in ISO-8859-1 and UTF-8. Don't lie about your
content type.
So I suppose my only questions are:
Shall I fear the old browsers of
http://www.yourhtmlsource.com/access...xmldeclaration or go ahead and use tidy --add-xml-decl 1, producing a
<?xml version="1.0"?> or better yet add
<?xml version="1.0" encoding="UTF-8"?>
The text/html spec says that XHTML 1.0 defines a profile of use of XHTML
which is compatible with HTML 4.01 and which may also be labelled as
text/html. Appendix C of the XHTML 1.0 spec (which is the HTML
compatibility[1] guidelines) says that you shouldn't include an XML prolog.
Thus an <?xml etc ?> has no place in a text/html document.
Though tidy doesn't, shall I still proceed and bother with the
<html xmlns="..." lang="zh-tw" xml:lang="zh-tw"> lang stuff, or is my
http-equiv line above "equiv" enough?
http-equiv is also a joke. Use a real content type header. Use a lang
attribute in documents served as text/html. Use a xml:lang attribute in XML
documents.
Just avoid serving XHTML to clients, it is utterly pointless at present.
[1] This is a joke. It only makes it compatible with broken implementations
of HTML in *most* browsers. You get problems if a user agent treats <img />
in a text/html document as per the HTML specs.
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
Dan Jacobson wrote: I shall jump on the XHTML bandwagon.
I invite you to check out my page ..... http://jp29.org/test.php
On Fri, 17 Feb 2006, Dan Jacobson wrote: I shall jump on the XHTML bandwagon.
OK. But could you offer some coherent explanation of what benefit you
hope to gain by serving that out to the WWW ? If you could, I think
you'd be the first.
I run my perfectly good html4/strict pages thru
$ tidy -asxhtml -utf8 #to get:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
Good to see that you chose Strict. Whereas XHTML 1.0 Strict is merely
silly - at least as text/html, XHTML 1.0 Transitional is frankly
absurd, after all this time for the "transition" to be completed.
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html
xmlns="http://www.w3.org/1999/xhtml"> <head><meta
http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta
So you're serving it out as text/html, ergo you are relying on the
dreaded Appendix C.
http-equiv="Content-Language" content="zh-tw" />
we'll come back to that detail later
knowing all the time as http://hixie.ch/advocacy/xhtml says,
that all I am doing is downgrading my pages from html4/strict.dtd to
quirks mode...
Hmmm? As long as you retain the above DOCTYPE, and avoid pre-pending
any <?xml... thingy, I'm under the impression that those browsers
which have a concept of standards versus quirks will be in standards
mode. Am I missing something? Do you have a cite?
(I suppose one day some Prince Charming browser will
come along and detect all this so there will be some actual benefit.)
Well, no, since XHTML/1.0 was *designed* to be functionally equivalent
to HTML/4.01, so there is nothing to be gained, even with an ideal
browser: with the browsers that are currently around, there's a bit to
be lost by changing from HTML to XHTML at *this* level.
XHTML only brings worthwhile benefits when you can go further than
HTML4 (equiv. XHTML/1.0): but that's scarcely feasible yet on the WWW
(except for specialised usages, such as math, svg, ruby-annotation
etc., whose readers can be *expected* to get capable browsers).
I will not use any .htaccess files on my web host. No more single
point of failures for me. Anyway my pages are to look the same if read
from file:/// or http://.
No particular comment, other than to suspect that you are mostly
missing the point...
Furthermore, I will still use their same .html filenames and not
.xhtml, as I don't want to break everybody's links to me.
OK, but there's no compulsion to use *any filename extension at all*:
the WWW was designed to work with *URLs* and with *HTTP
content-types*, irrespective of the local peculiarities of a file
system. It's your responsibility to sort that out with your own HTTPD
configuration (.htaccess and so on).
(I understand that one needs .xhtml and
content="application/xhtml+xml..." in e.g., firefox to trigger any
XHTML treatment. I am thus far from that.)
It wouldn't be of any value to you at the moment anyway - in fact it
has some disadvantages, as you'd know if you'd been reading earlier
discussions.
I must say, the more that I read of your posting, the less convinced I
become that you have bothered to read any of the previous discussions
of any of these issues.
So I suppose my only questions are:
But you seem to have missed all the important questions of principle,
so I'm not sure there's any point in bothering with your questions of
detail.
Shall I fear the old browsers of
http://www.yourhtmlsource.com/access...xmldeclaration
or go ahead and use tidy --add-xml-decl 1, producing a
<?xml version="1.0"?> or better yet add
<?xml version="1.0" encoding="UTF-8"?>
UTF-8 or utf-8?
Don't you fear the "old browser" called MSIE6 and its predecessors?
Though tidy doesn't, shall I still proceed and bother with the
<html xmlns="..." lang="zh-tw" xml:lang="zh-tw"> lang stuff, or is my
http-equiv line above "equiv" enough?
HTTP content-language and (X)HTML language are not the same thing -
they are at different levels of the protocol, for one thing. <meta
http-equiv=...> from HTML's point of view is just an opaque container,
it means nothing to HTML itself. Whether it means anything to XHTML
is even more dubious, IMHO. If you want an HTTP Language, then you'd
be better advised to tell your HTTP server about it. If you want an
HTML language (and the WAI guidelines say that you do) then you need
to put it on the <html...> container. Plus language attributes for
any elements which differ, if you're doing the job properly.
James Pickering wrote: I invite you to check out my page .....
http://jp29.org/test.php
So I visit the page and get ...
application/xhtml+xml D)ownload, or C)ancel
How helpful.
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
On Thu, 16 Feb 2006, David Dorward wrote: James Pickering wrote: I invite you to check out my page .....
http://jp29.org/test.php
So I visit the page and get ...
application/xhtml+xml D)ownload, or C)ancel
I recognise a Lynx response - but I don't understand why that
happened.
My Lynx sends his server a rather elaborate Accept: header, but I note
that it contains text/html explicitly, but does *not* contain
application/xhtml+xml; it ends with "*/*;q=0.01" - but that clearly
should take second place, when text/html is Accept-ed (with default
q). The server headers say:
HTTP/1.1 200 OK
Server: Zeus/3.4
Date: Thu, 16 Feb 2006 23:56:10 GMT
Connection: close
Content-Type: application/xhtml+xml;charset=utf-8
Vary: Negotiate, Accept
X-Powered-By: PHP/4.1.2
The headers (see "Vary:") *do* imply that some kind of negotiation is
happening, but, based on what we see here, it seems to me that the
server-side negotiation is b0rked.
AFAIK, Zeus is based on Apache, and probably has a perfectly good
mod_negotiate built in. Not clear why PHP needs to invent a square
wheel?
Dan Jacobson wrote: I shall jump on the XHTML bandwagon.
Good for you. You'll jump off it again one day when you realise it's
not going anywhere yet.
Although, this endless debate about HTML vs. XHTML that keeps coming up
every few weeks on every related mailing list, newsgroup and forum
around the world is really pointless. The debate was won long ago (HTML
4 was victorious). But in the end, the most important issue is that the
document is accessible and degrades gracefully in older browsers, and
the use of a DOCTYPE that triggers standards mode (i.e. don't use the
XML Declaration, it triggers quirks mode in IE)
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
Do you realise that the meta element is completely useless in XHTML, and
is an inferior substitute for real HTTP headers in HTML?
I will not use any .htaccess files on my web host.
Why?
I think you need to read my article and address all the issues involved
with using XHTML correctly. If you don't, there really is no point in
using XHTML at all. http://lachy.id.au/log/2005/12/xhtml-beginners
--
Lachlan Hunt http://lachy.id.au/ http://GetFirefox.com/ Rediscover the Web http://GetThunderbird.com/ Reclaim your Inbox
On Fri, 17 Feb 2006, Lachlan Hunt wrote: Alan J. Flavell wrote: On Fri, 17 Feb 2006, Lachlan Hunt wrote: http://lachy.id.au/log/2005/12/xhtml-beginners
Aaaargh, microfonts.
[...] Sorry, although then there's nothing stopping you from increasing
it.
Sure - I normally have min. font size in effect (thanks to Mozilla).
I just happened to have disabled that (thanks to Chris Pederick ;-) a
little earlier, to review someone else's site for CSS, and had left it
disabled, otherwise I wouldn't have noticed.
But I was thinking more about the impression it creates for someone
who really is a "beginner". Although, to move the discussion back on
topic for ciwah, it might be that your content is written *for*
experts, even though it's *about* beginners.
best
Alan J. Flavell wrote: On Fri, 17 Feb 2006, Lachlan Hunt wrote:
http://lachy.id.au/log/2005/12/xhtml-beginners
...
Although, to move the discussion back on
topic for ciwah, it might be that your content is written *for*
experts, even though it's *about* beginners.
Yes, that article was aimed more at those so-called "experts" teaching
XHTML to beginners, rather than the beginners themselves. One day I'll
get around to writing a beginners guide to (X)HTML, which will cover
most of that in a more beginner-friendly manner (probably as part of my
book).
--
Lachlan Hunt http://lachy.id.au/ http://GetFirefox.com/ Rediscover the Web http://GetThunderbird.com/ Reclaim your Inbox
Alan J. Flavell <fl*****@physics.gla.ac.uk> wrote: On Fri, 17 Feb 2006, Lachlan Hunt wrote:
http://lachy.id.au/log/2005/12/xhtml-beginners
Aaaargh, microfonts.
yes. std 12 pt font down to 7.5 pt is lovely. 2.66 mm from bottom of y
to top of h.
Document styles:
BODY:
{
font-size: 62.5%;
font-family: Lucida Grande, Verdana, Arial, sans-serif;
background-color: rgb(213, 214, 215);
color: rgb(51, 51, 51);
text-align: center;
}
--
Andy Templeman <http://www.templeman.org.uk/>
Andrew Templeman wrote: font-size: 62.5%;
font-family: Lucida Grande, Verdana,
It boggles the mind why authors choose fonts that are so much larger
than average, then reduce the font-size so it ends up looking even
smaller than average.
There's just no logic to it. :-\
--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.
In article <dt*******************@news.demon.co.uk>,
David Dorward <do*****@yahoo.com> wrote: So this browser will check that the document is well formed XML, then push
it through an XML parser instead of a tag soup slurper? Sounds like a lot
of work for ... no benefit.
I have been wondering whether to attempt to use XHTML (served as
application/xml+xhtml) on those sections of my web site unlikely to be
visited by Internet Explorer users (the bits about Apple OS X, for
example). One excuse for this was that it seemed to me that an XML
parser in a browser could perhaps be expected to render substantially
faster than the tag soup parser.
If so, surely this would be a benefit?
However, I have never seen any convincing evidence that XML is faster
than HTML as rendered by browsers. The browser speed tests I have found http://www.howtocreate.co.uk/browserSpeed.html are reasonably enough
browser vs browser rather than by page type. I wonder whether anyone is
aware of results of an XML vs HTML browser speed comparison for any
common browsers?
As an aside, I have recently noticed that Safari allows substantially
more valid, well formed (HTML) pages in tabbed browsing than it does of
more common web pages (150 without slowdowns, vs only 20 or so for many
common pages). I haven't as yet matched page size, server, and graphic
content, but just finding 150 tabs performed well was not what I had
expected from my normal browsing. Guess I will check first how other
browsers perform with lots of tabs.
-- http://www.ericlindsay.com
Eric Lindsay wrote: I have been wondering whether to attempt to use XHTML (served as
application/xml+xhtml) on those sections of my web site unlikely to be
visited by Internet Explorer users (the bits about Apple OS X, for
example). One excuse for this was that it seemed to me that an XML
parser in a browser could perhaps be expected to render substantially
faster than the tag soup parser.
Perhaps in theory. In practise browsers are optimised for tag soup slurping,
so there might not be much benefit to be had and some (certainly Firefox
and other Gecko-based browsers) can't render XHTML incrementally - so the
*entire* file must be downloaded and parsed before anything is displayed to
the user.
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
On Sat, 18 Feb 2006 14:51:29 +1000, Eric Lindsay
<NO**********@ericlindsay.com> wrote: I have been wondering whether to attempt to use XHTML (served as
application/xml+xhtml) on those sections of my web site unlikely to be
visited by Internet Explorer users
No, this would be bad and wrong. Serve application/xml+xhtml anywhere
on your site, but only if the browser's accept header permits it.
Note that accept just has to permit it, not favour it with a higher
priority. The browser might _prefer_ to receive HTML, but you may still
send it XHTML - it's your site, your choice, and if they dislike it that
much then they could remove it from their accept header altogether.
You now have two choices - what to serve for the
non-{application/xml+xhtml} browsers. Should you serve them this same
XHTML labelled as text/html, or should you offer HTML 4.01 (or specially
transcoded Appendix C XHTML). The first is easy, but requires you to
work with Appendix C throughout the site, even for the fully XML
browsers. The second requires a CMS that can provide two copies of the
source files, or even transcode them on the fly (possible, but more
server load). If you're adopting XHTML for reasons other than fashion,
then it may well be awkward for your internal CMS process to work with
it as Appendix C.
On Sat, 18 Feb 2006, Andy Dingley wrote: No, this would be bad and wrong. Serve application/xml+xhtml
xhtml+xml, Shirley? (I hadn't spotted that earlier, sorry).
anywhere on your site, but only if the browser's accept header
permits it.
Note that accept just has to permit it, not favour it with a higher
priority. The browser might _prefer_ to receive HTML, but you may
still send it XHTML
The most widespread error in hand-knitted negotiations seems to be to
interpret application/xhtml+xml;q=0 to mean "the client mentioned
XHTML, so they must accept it", when in fact it means they won't
accept it under any circumstances.
- it's your site, your choice, and if they dislike it that
much then they could remove it from their accept header altogether.
There's something in what you say, but there is a well-defined
negotiation algorithm. Anyone wanting to do what you suggest, can set
their XHTML source quality as high as they like, with the intention of
defeating any non-zero accept quality setting; but when applied to an
acceptance quality of 0, the answer will always be 0.
Any hand-knitted procedure which violates that principle is arguably
/worse/ than one which simply sends XHTML regardless, since the latter
is protocol-correct (it's a properly-working non-negotiated server),
whereas the former is broken (it purports to be a negotiated server,
but it does not conform to the published rules for negotiation).
Right: nobody gets sent to the Tower for putting a broken server on
the web - but the resulting mess is nevertheless deplorable.
cheers
"Alan J. Flavell" <fl*****@physics.gla.ac.uk> writes: The most widespread error in hand-knitted negotiations seems to be to
interpret application/xhtml+xml;q=0 to mean "the client mentioned
XHTML, so they must accept it", when in fact it means they won't
accept it under any circumstances.
The first most homegrown content negotiation just depends on simple
string matching, (need I say '<! DOCTYPE' ?) after that you take the
quality factor in account at all, then you learn that whitespace is not
prohibited, and if you are still standing there might be even more
parameters to deal with. It's just like XML in general; invoking the
syntax and not using the proper tools infallible indicates the idiot.
--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011
Eric Lindsay <NO**********@ericlindsay.com> writes: I have been wondering whether to attempt to use XHTML (served as
application/xml+xhtml
I wouldn't serve *that* under any circumstances ;)
) on those sections of my web site unlikely to be
visited by Internet Explorer users (the bits about Apple OS X, for
example).
Please don't; this kind of reasoning is really broken. I read Mac bits
on Windows or Linux and all other ways round; one might even want to
download software and documentation on the 'wrong' OS because the right
one does not have a cd burner. And so on.
One excuse for this was that it seemed to me that an XML
parser in a browser could perhaps be expected to render substantially
faster than the tag soup parser.
*Parse*, not necessarily *render* - in Geckos application/xhtml+xml
actually _breaks_ incremental rendering.
--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011
In article <m3************@nntp.bednarz.nl>,
Eric B. Bednarz <be*****@fahr-zur-hoelle.org> wrote: "Alan J. Flavell" <fl*****@physics.gla.ac.uk> writes:
The most widespread error in hand-knitted negotiations seems to be to
interpret application/xhtml+xml;q=0 to mean "the client mentioned
XHTML, so they must accept it", when in fact it means they won't
accept it under any circumstances.
The first most homegrown content negotiation just depends on simple
string matching, (need I say '<! DOCTYPE' ?) after that you take the
quality factor in account at all, then you learn that whitespace is not
prohibited, and if you are still standing there might be even more
parameters to deal with. It's just like XML in general; invoking the
syntax and not using the proper tools infallible indicates the idiot.
Thanks guys. A wonderful sequence of problems. Two out of four of my
sites don't give me any choice about how anything on them is served (and
seem to only serve text/html ). The other two allow access to .htaccess
So if I did do any XHTML 1.1 I could simply ignore negotiation. Or I
could potentially get it wrong. Or I could try some PHP system which
may or may not create valid XML or HTML depending on what the user agent
seems to accept.
To think that I came to these newsgroups to learn HTML because I
couldn't find any tools that would reliably create a valid modern page
with decent search engine position. Until people can be pointed to easy
to use tools, it doesn't seem to me that the proportion of well formed,
valid pages is likely to increase. If any of my pages were done on a
commercial basis, I'd have long ago given up and used whatever page
generator gave the best looking results.
-- http://www.ericlindsay.com
Eric Lindsay <NO**********@ericlindsay.com> writes: Eric B. Bednarz <be*****@fahr-zur-hoelle.org> wrote:
homegrown content negotiation
Or I could try some PHP system which
may or may not create valid XML or HTML depending on what the user agent
seems to accept.
That's what I meant by homegrown. The web is stuffed with tutorials
about that, delivering results that are not HTTP-compliant. OTOH,
proper negotiation requires proper accept headers; the bets are quite
off.
--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011
On Mon, 20 Feb 2006, Eric Lindsay wrote: In article <m3************@nntp.bednarz.nl>,
Eric B. Bednarz <be*****@fahr-zur-hoelle.org> wrote:
"Alan J. Flavell" <fl*****@physics.gla.ac.uk> writes:
The most widespread error in hand-knitted negotiations seems to
be to interpret application/xhtml+xml;q=0 to mean "the client
mentioned XHTML, so they must accept it", when in fact it means
they won't accept it under any circumstances.
The first most homegrown content negotiation just depends on simple
string matching, (need I say '<! DOCTYPE' ?)
(I didn't follow that bit, to be honest.)
[...]
Thanks guys. A wonderful sequence of problems. Two out of four of
my sites don't give me any choice about how anything on them is
served (and seem to only serve text/html ).
Then they have taken the decision for you, and solved your problem of
indecision ;-)
The other two allow access to .htaccess
Well, .htaccess itself is merely a container. The acid test is which
features of Apache they allow you to influence via directives in
..htaccess
So if I did do any XHTML 1.1 I could simply ignore negotiation.
It all comes back to what you are trying to achieve.
Or I could potentially get it wrong. Or I could try some PHP system
which may or may not create valid XML or HTML depending on what the
user agent seems to accept.
If you use XHTML/1.1 to do anything more than can be done with
HTML/4.01 then how on Earth are you going to serve that as (proper)
HTML when you feel like it? (topical topic: Ruby annotation). And if
you aren't going to do anything more with XHTML/1.1, why do you want
to use it at all? But anyway, to get back to the topic of
negotiation...
As far as negotiation is concerned, it's implemented in Apache; so,
*if* you've worked out what it is that you want to negotiate, use
Apache's properly programmed mechanisms to do the negotiation, would
be my advice.
It *might* be feasible to produce a protocol-conforming equivalent in
PHP, but is it worth it? - Google suggests this web page offering some
fairly heroic code as a "work in progress"
http://keystonewebsites.com/articles/mime_type.php , which looks
kind-of plausible, but I haven't fully worked it through. I would
still prefer to do the negotiating part with Apache's purpose designed
module (which can incidentally be negotiating Accept-language etc. at
the same time).
But that's only adapting between XHTML/1.0 and HTML/4.01. And what's
the benefit currently of serving out XHTML/1.0 if you're able to serve
out HTML/4.01? The major effect seems to be slowing down the response
for users who have gecko-based browsers, which can hardly be seen as a
benefit!
If you've got a genuine reason to offer XHTML/1.1, and you want to
follow the W3C guidelines, then you have to offer it as
application/xhtml+xml without the option. Simple and effective -
shuts out the bulk of MSIE users, if that's what you want.
To think that I came to these newsgroups to learn HTML because I
couldn't find any tools that would reliably create a valid modern
page with decent search engine position. Until people can be
pointed to easy to use tools, it doesn't seem to me that the
proportion of well formed, valid pages is likely to increase.
Can't argue with that, but until those tools genuinely take on board
the principle of separation of structure (xHTML markup) from
presentation (stylesheet), no real progress is possible, I don't care
whether they extrude formally-valid code or not. The result needs to
make sense not only syntactically, but also semantically. Any tool
which hides the division between structure and presentation, and
purports to the innocent author that they are merely doing visual DTP,
is doomed to extrude the same /semantic/ nonsense that such tools have
been extruding as long as they have existed, no matter how much (or
how little) care they take over generating correct /syntax/.
regards
"Alan J. Flavell" <fl*****@physics.gla.ac.uk> writes: > The first most homegrown content negotiation just depends on simple
> string matching, (need I say '<! DOCTYPE' ?)
(I didn't follow that bit, to be honest.)
That is understandable, I'm afraid. :)
It *might* be feasible to produce a protocol-conforming equivalent in
PHP, but is it worth it? - Google suggests this web page offering some
fairly heroic code as a "work in progress"
http://keystonewebsites.com/articles/mime_type.php , which looks
Pray let me introduce Bednarz' law:
->
HEAD /articles/mime_type.php HTTP/1.1
Host: keystonewebsites.com
Accept: text/html, application/xhtml+xml; q=0
Connection: Close
<-
HTTP/1.1 200 OK
Date: Tue, 21 Feb 2006 15:00:10 GMT
Server: Apache/1.3.33 (Unix) DAV/1.0.3 mod_fastcgi/2.4.2 mod_gzip/1.3.26.1a PHP/4.4.2 mod_ssl/2.8.22 OpenSSL/0.9.7e
X-Powered-By: PHP/4.4.2
Vary: Accept
Connection: close
Content-Type: application/xhtml+xml;charset=utf-8
--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011
On Tue, 21 Feb 2006, Eric B. Bednarz wrote: fairly heroic code as a "work in progress"
http://keystonewebsites.com/articles/mime_type.php , which looks
Pray let me introduce Bednarz' law:
I know it's a bit late for me to mention it now, but I *had* spotted
their white-space problem already, as it happens, "but I haven't fully
worked it through". It was one of the reasons for my continued
scepticism about the hand-knitted negotiation code.
(But it was specifically your reference to DOCTYPE that had me
confused, since DOCTYPE itself surely isn't the kind of thing that
HTTP should be negotiating? Now if they had ever decided to define
the content type as text/html;version=what.ever , then that *could*
have been something to negotiate - but they never did).
best
OK OK I shall not jump on the XHTML bandwagon. I will stick with this:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"><html lang="en-us"><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta http-equiv="Content-Language" content="en-us">
On zh-tw pages I will say that instead of en-us. tidy -access 3 warns
if we don't use <html lang=...>, so adding. I hope the above is OK.
Hope nothing bad will happen if there is no Content-Language on some
of my en-us pages. Assume "I have no control of what HTTP headers the
server sends, nor do I intend to", and also my files should work from
just file:/// URLs.
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Peter Rohleder |
last post by:
Hi,
I have a few simple questions in order to use modularized xhtml and
getting it to work.
A simple example may make this obviouse:
Lets say we want to create a simple xml-file to reflect...
|
by: Sleepless on the Web |
last post by:
Is there a limit to how many items can be in a jump list?
My script worked fine with 126 items, but at 152 items it just doesn't
work. When I select a page from the drop down menu it will only...
|
by: Amy Young-Leith |
last post by:
So I'm now inspired to jump on the Web standards bandwagon. I've used
CSS for font control for some time, but haven't moved to it for
positioning. Great time to kill two birds with one stone, so I...
|
by: oopaevah |
last post by:
When using innerHTML to insert xhtml IE5+ mangles the xhtml completely.
For example it removes the quotes from attributes. It also does other
ridiculous things like on a <div> it will insert the...
|
by: Mcginkel |
last post by:
I am trying to find a way to load XHTML content in an Iframe.
I use to do this in html by using the following code :
var iframeObject = document.createElement("iframe");...
|
by: robert d via AccessMonster.com |
last post by:
When my app starts up, it creates a temporary database. This temp database
is created from a 'model' database that is in the same folder as the
application. Because there is a model, the creation...
|
by: Todd A. Anderson |
last post by:
I have a function foo of which I need to get the address. The problem
is that when you say "&foo" (or just foo for that matter), you get the
address of this function's entry in a jump table and...
|
by: abracad_1999 |
last post by:
Is it possible to serve valid xhtml with php?
xhtml requires the 1st line:
<?xml version="1.0" encoding="iso-8859-1"?>
But php interprets the opening <? as a php statement.
If I try to echo...
|
by: wavedancer |
last post by:
I am trying to get a link back to the top of the page I'm on.
For the anchor, I've got <a name="topofpage" id="topofpage"></a>
and for the link I've got <p><a href="#topofpage">back to the...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| |
