xhtml file extension

[flamencouk]

I am in the process of re-writing one of my sites in XHTML 1.1. I want to serve it properly as xhtml+xml to the agents that understand, and am therefore changing all my page extensions to .xhtml. I'm going to use a mod rewrite in the .htaccess to serve text/html to IE.

My question is: will the main search engines have any issues with the extension change ( assuming I keep the actual page names the same) as far as indexing/page rank etc. are concerned?

Also if any of you guys have experience of serving xhtml "properly" across browsers, is mod rewrite a sensible way to go for Apache? I've read about using php headers, but this somehow seems "cleaner"

[lemons]

don't know if this helps but my site is all xhtml 1.0 transitional and all code is valid and displays as intended across browsers but all files are as .htm extensions apart from the index page which is .html extension

[webado]

It doesn't matter what the extension is, only what the content is served as.

IE cannot handle XHTML 1.1.

If you want to manage that in .htaccess keep in mind it has to be set conditionally based on the browser.

I'd rather do it by php script directly at the top of the page itself and generate the doctype and content type and whatnot that way, based on user agent.

Never mind that I am clueless on the specifics anyway :lol:

[flamencouk]

It doesn't matter what the extension is, only what the content is served as.

So Google could then see mysite/index.html as a different page from mysite/index.xhtml for indexing purposes if I served one as text/html and the other as application/xhtml+xml, even if the content was the same?

If that's the case then I'd better stick with 1.0 and save myself the potential problem of losing ranking. I could always validate as 1.1 and just serve as text/html (as most sites do), keeping the html extension.

Probably just trying to be too clever :lol:

[webado]

The robot is not a browser. It's not like it will see it sometimes one way and other times another way.

In any case the code needs to be valid for the doctype used. Beyond that the robot parses to get the content. The markup doesn't count as content as long as it's valid and doesn't get scrambled up as content.

[flamencouk]

Thanks Chris.
It's only a static site so I don't really "need" to make use of xml advantages, but it's nice to know that if I did change my page names to .xhtml filenames, it wouldn't be an issue :)

[webado]

Changing the file name (even if just the extension) will be ok as long as you also implement 301 redirections from old to new.

[donecweb]

Christina, are you saying that if you replace say a page named index.html with index.xhtml or index.php you should implement 301 redirections from old to new?

[jamesicus]

From time to time over the past several years I have served my Home page as XHTML 1.0 with Content-Type text/html to IE Browsers and with Content-Type application/xhtml+xml to Browsers that recognize that content type -- via Content Negotiation.

My current Home Page (http://jp29.org/) is served in this manner. I compose the great majority of my pages using HTML 4.01 Markup (a few using ISO-HTML) and they are naturally served as text/html.

I actually started using Content Negotiation for XHTML documents as an experiment to see how the concept worked in practice -- I continue to do so mainly just for fun -- I am growing old and need some diversions from serious work!

I also employ Content Negotiation for -- my XHTML+RDFa test page (http://jp29.org/rdfaprimerx.php) -- there is no "Appendix C" provision (ala XHTML 1.0) in the W3C RDFa in XHTML Syntax and Processing document (http://www.w3.org/TR/2008/WD-rdfa-syntax-20080221/) -- if XHTML+RDFa documents are served as text/html the W3C Validator adds the following generic note to the successful validation report (quote):

"Warning Conflict between Mime Type and Document Type

The document is being served with the text/html Mime Type which is not a
registered media type for the XHTML + RDFa Document Type. The recommended media type for this document is: application/xhtml+xml"

I note that the W3C is currently serving some of their XHTML+RDFa documents as Content-Type text/html.

James

[flamencouk]

I don't really want to have to implement redirects - I'd rather just create valid XHTML 1.1 and serve it as text/html for the time being, converting to application/xhtml+xml at some point in the future.

It would be satisfying to serve application/xhtml+xml to the relevant browsers (everything except IE, it seems) via Content Negotiation. I have got this working with a .htaccess mod-rewrite and it all validates in WC3 with no MIME warning, but it obviously requires an xhtml file extension to achieve this.

Am I right in this thinking? :confused:

[jamesicus]

Let us go through all this one step at a time:

I don't really want to have to implement redirects - I'd rather just create valid XHTML 1.1 and serve it as text/html for the time being, converting to application/xhtml+xml at some point in the future ..........
XHTML 1.1 should not be served as Content-Type text/html, in fact, it should be served as application/xhtml+xml IAW with the W3C specification. XHTML 1.0 may be served as text/html IAW Appendix C of the W3C specification -- but such documents are then HTML documents -- they should be served as application/xhtml+xml in order to render xml content as specified.


......... It would be satisfying to serve application/xhtml+xml to the relevant browsers (everything except IE, it seems) via Content Negotiation. I have got
this working with a .htaccess mod-rewrite and it all validates in WC3 with no MIME warning, but it obviously requires an xhtml file extension to achieve this. Am I right in this thinking? :confused:
Do not use .htaccess mod-rewrite for Content Negotiation -- that does not produce the correct weighted values for the HTTP request header. Instead, use PHP on the server side something like this:

<?php

# For MSIE browsers
if (stristr($_SERVER["HTTP_USER_AGENT"],"MSIE")) {
$mime = "text/html";
$charset = "utf-8";
$prolog_type = "<!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-us' lang='en-us'>";
}

# For other browsers
else {
$mime = "application/xhtml+xml";
$charset = "utf-8";
$prolog_type = "<?xml version='1.0' encoding='$charset'?> <?xml-stylesheet href='home.css' type='text/css'?>
<!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-us' lang='en-us'>";
}

# Generate the mime type and prolog type
header("Content-Type: $mime; charset=$charset");
header("Vary: Negotiate, Accept");
print $prolog_type;

?>

The above code can be modified to incorporate other User-Agents as needed. In any case, it is associated with the index page and served as index.php -- example: http://jp29.org/index.php (Note: in actuality, http://jp29.org/)


Do not rely on Validators to confirm how content is being served -- use a "View HTTP Request and Response Header" -- there are examples and links on my home page.

You don't have to use .xhtml as an extension for XHTML pages served as Content-Type application/xhtml+xml, although you may have to provide an extension association via .htaccess depending how your web server software is configured. For instance, my Web Service Providers use both Apache and Zeuss software. Both associate .htm and .html extensions with HTML and XHTML documents served as Content-Type text/html. In order to be able to serve both text/html and application/xhtml+xml, I inserted the following line in my .htaccess file:

AddType application/xhtml+xml html

Now any document with the extension .htm is automatically served as text/html and any with the extension .html is served as application/xhtml+xml. You can check this using my "ISO-HTML" page: http://jp29.org/iso.htm and my "Serving XHTML" page 2: http://jp29.org/testx.html

You don't have to use a re-direct for an index file if the proffered URI does not include an extension. Most (all?) servers follow an index file extension hierarchy -- .html, .htm, .php ..... etc. That comes in handy -- I can (and do) change the "flavor" of my index page by loading different content type versions up to my server as the spirit moves me.

James

[webado]

Christina, are you saying that if you replace say a page named index.html with index.xhtml or index.php you should implement 301 redirections from old to new?

Yes. It's best.

[webado]

I don't really want to have to implement redirects - I'd rather just create valid XHTML 1.1 and serve it as text/html for the time being, converting to application/xhtml+xml at some point in the future.

It would be satisfying to serve application/xhtml+xml to the relevant browsers (everything except IE, it seems) via Content Negotiation. I have got this working with a .htaccess mod-rewrite and it all validates in WC3 with no MIME warning, but it obviously requires an xhtml file extension to achieve this.

Am I right in this thinking? :confused:


The redirects are only necessary if you are changing file names in any way. When you change the extension you are changing file names. If you aren't changing file names obviously no redirection need be involved at all.

[jamesicus]

Let me clarify index file usage by Search Engines via examples. I currently maintain two versions of my index page on my server: index.htm -- HTML 4.01
(Strict), served as text/html, and index.php -- XHTML 1.0 (Strict), served via Content Negotiation as text/html or application/xhtml+xml. The .htm page is preferentially rendered as http:// jp29.org/ and a Google search for the page title "Pickering Pages" results in a link that points to http:// jp29.org/ (index.htm). If I change the index page on the server to, say, indexx.htm then index.php is then rendered as http:// jp29.org/ and a Google search for the page title "Pickering Pages" now results in a link that points to http:// jp29.org/ (index.php).

James

[flamencouk]

Thanks for all this, James.

This is as much an intellectual exercise for me as anything else (and I'm just at the start of the xhtml learning curve, so forgive my dumb questions).

There is no real need for me to use xml; it would just be the sense of satisfaction in serving 1.1 as it's meant to be! In any case I'm not sure how far get with this as I intend to use both lightbox javascript and embedded flash video on my site using SWFObject, and I've just read that this would cause a problem if served with application/xhtml+xml....... but anyway:

After your comment that I don't actually need to change the html extensions in any case, I was all ready to do the "Content Negotiation" thing via this addition in my .htaccess:

AddType application/xhtml+xml .xhtml
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_URI} \.xhtml$
RewriteCond %{HTTP_USER_AGENT} MSIE [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml\s*;\s*q=0\.?0*(\s|,|$)
RewriteRule .* - [T=text/html]
</IfModule>

but you're saying that this "does not produce the correct weighted values for the HTTP request header". I don't pretend to know what this means, but I'm getting the firm impression I ought to go down the php header route, which would mean a change from index.html to index.php for my index page and everything else.

When you say you don't have to use a re-direct for an index file if the preferred URI does not include an extension, what exactly do you mean, and would this apply to all my other pages? Again, sorry for the noobiness of the question, but it seems that I wouldn't be able to serve XHTML1.1 properly keeping .html filenames and an htaccess modification :lol:

[jamesicus]

.......... There is no real need for me to use xml; it would just be the sense of satisfaction in serving 1.1 as it's meant to be! ..........

Again, I think you really mean XHML 1.0 not XHTML 1.1 which must be served as Content-Type application/xhtml+xml -- easily done (but not very practical) via .htaccess file type assignment (if necessary).

.......... I was all ready to do the "Content Negotiation" thing via this addition in my .htaccess .......... but you're saying that this "does not produce the correct weighted values for the HTTP request header" ..........

There is presently an exhaustive interchange relating to Content Negotiation processing on the W3C Validator Discussion Forum (of which I am a member). The issue of using .htaccess was raised and to me the following summarises that discussion:

> In PHP, it is possible to implement a full standard
> content negotiation mechanism, but it is not possible using a simple
> rewrite rule in a .htaccess.

.......... I'm getting the firm impression I ought to go down the php header route, which would mean a change from index.html to index.php for my
index page and everything else ...........

Yes, that is correct.

.......... When you say you don't have to use a re-direct for an index file if the preferred URI does not include an extension, what exactly do you mean, and would this apply to all my other pages? ..........

Refer to: http://webtips.dan.info/subdir.html -- Dan's Web Tips: Directories and Default Index Files. As pointed out previously, you would indeed have to use re-directs for all your other files with changed file extensions.

.......... it seems that I wouldn't be able to serve XHTML1.1 properly keeping .html filenames and an htaccess modification ..........

Again, I think you really mean XHTML 1.0. Regardless, if you use .htaccess to associate .html files with Content-Type application/xhtml+xml, then all XHTML
version files (ie, bearing a XHTML Doctype) will be so served. Caveat : In this case, you may have to associate .htm files with Content-Type text/html -- depending on the configuration of you Web Service Provider server software.

Again, do not rely on Validators to confirm how content is being served -- use the Web Sniffer View HTTP Request and Response Header (http://web-sniffer.net/) utility. The W3C Validator does include Content Type information in the Verbose mode output, but it uses an accept-header that is presently undergoing modification.

I apologise for not responding earlier, but 95% of my web traffic involves my Practical Italic Handwriting, Practical Craft Bookbinding, Roman Imperial Coins
& WW2 Remembrance pages -- I devote most of my time to the upkeep of those pages and the discussions they engender (I am presently also two months behind schedule on my Calligraphy and Bookbinding projects!). My Web Authoring pages are hold-overs from my days as a Technical Advisor for the AWDD (Access World Design & Development -- Web Authoring for People with Disabilities) -- I keep them current for general reference and because I enjoy working on them -- when I can spare the time.

So please excuse me if I am tardy with future responses.

James

[flamencouk]

Thank you once again, and no explaination of delays in responding is necessary. In fact I congratulate you on your diverse interests. I have developed a huge deal of respect for bookbinding lately following the death of a friend of my fathers, who was an authority on the subject (his opinion being sought by the likes of the British Museum and Southeby's). In fact his particular interest was the bibliography of bookbinding and his collection (now sadly split following his demise) was a complete joy.

Anyway, back to the matter in hand, I was meaning 1.1 throughout, and following your comprehensive comments will now get down to serving it with the correct MIME type in the correct way.

I just hope the javascript I intend to use plays along nicely, because I cannot write the stuff myself...we will see :lol:

[jamesicus]

.......... I was meaning 1.1 tlhroughout, and following your comprehensive comments will now get down to serving it with the correct MIME type in the correct way ...........

Oh, OK. Then content negotiation does not come in to play. All you need to do is check with your Web service provider to see if their server software associates MIME type application/xhtml+xml with a particular file extension. If not, then you can create an association via .htaccess as outlined previously.

You confused me because you kept referring to serving xhtml 1.1 as text/html (incorporated in content negotiation) which, of course, is incorrect.

Of course, be aware that IE Browsers will not render any xml content in your pages.

Primary Reference relating to serving xhtml 1.0 (includes information relating to difference in serving xhtml 1.0 and xhtml 1.1): W3C Tutorial (http://www.w3.org/International/tutorials/tutorial-char-enc/#Slide0140)

James

[jamesicus]

One other consideration: In order to be fully compatible with XML methodology for defining CSS rules, an XML stylesheet (prolog) declaration, example .....

<?xml-stylesheet href="filename.css" type="text/css"?>

..... should be employed for pages served as content type application/xhtml+xml. CSS is utilized somewhat differently for XML content compared to how it is for HTML content. For example, body backgound color will only fill the body area of the page in XML compliant XHTML -- the HTML element must be styled in addition for the background color to fill the entire page window.

Information relating to Document encoding: W3C Tutorial (http://www.w3.org/International/tutorials/tutorial-char-enc/#Slide0240)

James

[flamencouk]

...and there I was all confident and ready to go until I started reading about css rendition in xml and - heavens forbid - XSLT :lol:

Hopefully though, all I need to is add the processing instruction in the document prolog. No need to alter my css in any way, right?

[jamesicus]

Up to this point I have refrained from attempting to dissuade you from "converting pages to XHTML 1.1 and serving them (correctly) as Content-Type application/xhtml+xml". But I believe I would be doing you a disservice if I did not point out some serious pitfalls you will be facing if you go that route:

1. I note you are presently using XHTML 1.0 (transitional) Doctypes for all (?) of your pages -- if you convert them to XHTML 1.1 (which employs exclusively strictly compliant elements and attributes) you will undoubtably have to re-write some of your Markup (due to existing deprecated Markup).

2. You are presently employing iso-8859-1 encoding for all of your pages. The default encoding (as utilized by the W3C Markup Validator) for XHTML 1.1 is utf-8.

3. Even if you do not provide any xml content, your pages will automatically render in quirks mode for IE 6 users -- CSS layout prescriptions (for instance, content centering) may produce weird or unintended results.

4. Your Web Host server software is presently serving .html files as Content-type text/html. You are going to have to be very careful how you go about serving your new XHTML 1.1 pages as Content-Type application/xhtml+xml (via .htaccess or scripting?) in order to avoid file handling problems such as 301 redirections.

5. You may have to re-write some of your CSS (see below).


Some of the above problems accrue from the following XHTML 1.1 document requirements (that you will have to implement):


In the prolog of the XHTML 1.1 Document include:

<?xml version="1.0" encoding="UTF-8"?>

<?xml-stylesheet href="filename.css" type="text/css"?> (example)


At the top of the CSS File(s) include:

@charset "utf-8"; (before any content, including comments).

Note: The Meta tag -- <meta http-equiv="Content-type" content="application/xhtml+xml;charset=UTF-8" /> (example) is now not needed.


.......... Hopefully though, all I need to is add the processing instruction in the document prolog. No need to alter my css in any way, right?

I am afraid it may not be that simple. Refer to the above, and carefully read and study the W3C tutorials referenced in my preceding posts and additionally:

Serving XHTML Documents (http://jp29.org/test.php)
Serving XHTML as Content-Type application/xhtml+xml (http://jp29.org/testx.html)

I am not trying to predict inevitable dire consequences for your venture, flamencouk, I am just attempting to forewarn you of some possible sticky problems. I will say this -- if you do succeed in producing a site consisting of properly functioning XHTML 1.1 pages that are satisfactorily usable by all visitors, your site will most likely be unique on the Web! :)

James

[jamesicus]

Just for the heck of it, here is an XHTML 1.1 version of my Home page (http://jp29.org/index11.html) (Validated) served, of course, as Content (MIME) type application/xhtml+xml.

James

[flamencouk]

Up to this point I have refrained from attempting to dissuade you from "converting pages to XHTML 1.1 and serving them (correctly) as Content-Type application/xhtml+xml"
Not to worry, I've been trying to dissuade myself most of the time, but this morning seem to be more in a "What the hell, let's try it and see" sensibility. After all, it should be a fairly simple matter to go back to XHTML 1.0.

Anyway, I'm not "converting", I'm re-building from the ground up, using UTF-8 and attempting to avoid any deprecated markup. In fact if you have a moment I wouldn't mind you taking a quick look at an example of work-in-progress at:

http://www.flamencodancer.co.uk/showreel1.php

I am using an .xhtml file extension for the time being, and have the appropriate MIME-type addition in the .htaccess, and am presently using a mod-rewrite to serve to IE, (although this will be changed to a php sidescript as you suggested). Just a quick look will be fine to let me know I'm on the right lines with this and not completely wasting my efforts :lol:

When you say:
Your Web Host server software is presently serving .html files as Content-type text/html. You are going to have to be very careful how you go about serving your new XHTML 1.1 pages as Content-Type application/xhtml+xml (via .htaccess or scripting?) in order to avoid file handling problems such as 301 redirections.

can you elaborate a little? I was looking to use 301 redirections via .htaccess. I intend to keep my page names the same, so it will just be a question of redirecting my .html pages to .php ones. What do I need to be careful of?

[jamesicus]

Not to worry, I've been trying to dissuade myself most of the time, but this morning seem to be more in a "What the hell, let's try it and see" sensibility. After all, it should be a fairly simple matter to go back to XHTML 1.0 ..........

Yes, that is correct.

.......... Anyway, I'm not "converting", I'm re-building from the ground up, using UTF-8 and attempting to avoid any deprecated markup. In fact if you have a moment I wouldn't mind you taking a quick look at an example of work-in-progress at:

http://www.flamencodancer.co.uk/Working_test/showreel1.xhtml..........

In my opinion that is a well authored page -- very pleasing layout -- validated semantic Markup -- I like it -- well done!

.......... I am using an .xhtml file extension for the time being, and have the appropriate MIME-type addition in the .htaccess, and am presently
using a mod-rewrite to serve to IE, (although this will be changed to a php sidescript as you suggested). Just a quick look will be fine to let me know I'm
on the right lines with this and not completely wasting my efforts ..........

Well, your implementation does not square with your original vowed goal and intentions ..........

.......... I am in the process of re-writing one of my sites in XHTML 1.1. I want to serve it properly as xhtml+xml .......... and ..........

There is no real need for me to use xml; it would just be the sense of satisfaction in serving 1.1 as it's meant to be! ..........

.......... you are now using content negotiation to serve XHTML 1.1 as content (MIME) type text/html (not the way it's meant be!) to IE Browsers and as content (MIME) type application/xhtml+xml (the way it's meant to be!) to xml compliant Browsers. As I have emphasized several times previously, and IAW with various W3C documents, it is never correct to serve XHTML 1.1 as content (MIME) type text/html, which is not a registered MIME type for XHTML 1.1.

I recommend you use your present methodology to serve your pages as XHTML 1.0 -- Appendix C of that W3C specification permits serving it as either content (MIME) type text/html or content (MIME) type application/xhtml+xml -- via content negotiation.

.......... can you elaborate a little? I was looking to use 301 redirections via .htaccess. I intend to keep my page names the same, so it will just be a question of redirecting my .html pages to .php ones. What do I need to be careful of?

In light of the methodology you are employing you can ignore that caveat.

James

[flamencouk]

Like I said, James, this is work in progress and by no means the finished article 8-). I just wanted some feedback on whether it is worth my continuing with my original intentions!

Thank you for your kind comments on the markup, though.

I have now implemented a php server side script that should serve 1.1 to compliant agents, and 1.0 Strict to the others.

http://www.flamencodancer.co.uk/Working_test/showreel1.php

[jamesicus]

Like I said, James, this is work in progress and by no means the finished article 8-). I just wanted some feedback on whether it is worth my continuing with my original intentions! .......... I have now implemented a php server side script that should serve 1.1 to compliant agents, and 1.0 Strict to the others.

http://www.flamencodancer.co.uk/Working_test/showreel1.php

Yes, that is one way to do it. However, your XHML 1.1 is not being served to xml compliant Browsers (Firefox, Opera, Safari, et al) but rather XHTML 1.0 (strict) as content(MIME) type text/html .......... HTTP request & response header depiction for Opera 9.2 (http://web-sniffer.net/?url=http%3A%2F%2Fwww.flamencodancer.co.uk%2FWorki ng_test%2Fshowreel1.php&submit=Submit&http=1.1&gzip=yes&type=GET&uak=4 ) .......... so some tweaking of your PHP scripting is needed. Also, your XHTML 1.0 Markup doesn't Validate (IE 7 Browser -- 24 errors) -- but you are certainly on the right track.

James

[flamencouk]

Sorry - forgot to remove the mod rewrite from the .htaccess.

I believe the HTTP Request and Response Headers should return appropriately now.

One quick question at this point: the page validates in XHTML 1.1. Bearing in mind I am using exactly the same content and just changing the doctype declaration dynamically, how am I going to achieve 1.0 validation without creating two pages?

[jamesicus]

You are on the cusp!

..........I believe the HTTP Request and Response Headers should return appropriately now ...........

Yes, it does.

.......... the page validates in XHTML 1.1 ..........

Not quite, you have one error -- eliminate one lang='en' from the namespace -- <html xmlns='http://www.w3.org/1999/xhtml' xml:lang='en' lang='en'> -- the one you are employing is for XHTML 1.0

.......... Bearing in mind I am using exactly the same content and just changing the doctype declaration dynamically, how am I going to achieve 1.0 validation without creating two pages?

You mean from within IE when the Validator uses web sniffing for validation?

The easiest way is to install the free WAT IE Developer toolbar extension -- This is an excellent facility that is reminiscent of Chris Pederick's Web Developer Extension for the Firefox Browser. In this case, you can use it to perform the Validation you need.

WAT IE Toolbar Information, including download (http://www.paciellogroup.com/resources/wat-ie-about.html)

Jim Thatcher's notes relating to this Toolbar (http://www.jimthatcher.com/news-061507.htm)

James

[flamencouk]

You are on the cusp!

..praise indeed! :lol:

From what I can see this page is now looking promising, and serving valid XHTML 1.1 and 1.0 respectively.

Thanks to your help, I have learned a lot and now have the confidence to start building the complete site now :-D

[jamesicus]

.......... From what I can see this page is now looking promising, and serving valid XHTML 1.1 and 1.0 respectively ..........
Yes, congratulations! :)

.......... Thanks to your help ..........
You are most welcome!

Just by way of summary and for general information: When serving XHTML via content negotiation or as content (MIME) type application/xhtml+xml use the following to be safe:


In the prolog of the XHTML Document include:

<?xml version="1.0" encoding="UTF-8"?> (default)

<?xml-stylesheet href="filename.css" type="text/css"?> (example)


At the top of the CSS File(s) include:

@charset "utf-8"; (before any content, including comments).


Note relating to <meta http-equiv="Content-type" content="application/xhtml+xml;charset=UTF-8" /> (example):

In all cases, the content entry is only the author's advisory notation and has no bearing on how the Markup is actually being served -- that is determined by the server configuration. It can be omitted altogether (although it is a good idea to include it for general information) thus: <meta http-equiv="Content-type" charset="UTF-8" /> or any text of the author's choosing can be used thus: <meta http-equiv="Content-type" content="manure;charset=UTF-8" /> without affecting Validation.

See my example pages: no content entry included (http://jp29.org/screen1.htm) and "garbage" content entry (http://jp29.org/screen2.htm) -- check the source code and validation.

The charset entry is only required When serving text/html (default encoding) or when the encoding prolog is not used -- when the encoding prolog is used
<meta http-equiv="Content-type" content="application/xhtml+xml;charset=UTF-8" /> (example) is not needed at all.

James

[flamencouk]

The charset entry is only required When serving text/html (default encoding) or when the encoding prolog is not used

In fact I had just added a charset entry to my php page for when it is served as text/html to IE before reading this.

You did allude to potential issues with 301 redirects in an earlier post, but can I assume that, when the time comes, I can joyfully implement 301 re-directs via .htaccess from my .html pages to the .php ones?

Be assured I'll leave you in peace very shortly (disasters permitting) 8-)

[jamesicus]

.......... You did allude to potential issues with 301 redirects in an earlier post, but can I assume that, when the time comes, I can joyfully implement 301 re-directs via .htaccess from my .html pages to the .php ones?..........
Joyfully indeed :) -- I know you will be able to get all the help and guidance you need here.

James