If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I've been doing some experiments and I've found a serious reason why, if you're serving a page as XHTML, you SHOULD use the XHTML 1.0 or 1.1 doctype.

To quote my book (I was talking about XML namespaces), "Yes, this does mean that the Doctype isn't quite sufficient and can even be done away with—but without a Doctype, good luck validating your markup and you can kiss almost all your character entity references goodbye."

Doing an experimental conversion of XHTML 1.0 to XHTML5 taught me that the hard way.

I'll take your word on that. No doubt actually serving the page as XHTML would change a lot of things. Though, by and large, people don't do that, because then your page won't render in IE8.

I tried it as an experiment, and got an "undefined entity reference" in FireFox. I can't believe it took until IE9 for XHTML to be supported. If only it had done this even 6 years ago when XHTML was still... at least warm.

Originally Posted by Jeff Mott

Do you know of any practical reason to keep them? Or were you inserting code just because it was valid?

I have a PHP program that goes through my pages and builds an outline. "<meta name="Section" content="[section name]" />" lets it know when a new section is starting. The rest, well, I thought the info would be of actual help.

When you say that HTML5 doesn't like them, do you mean you're seeing rendering issues? Or validation issues?

If it's just a validation issue, I'd say, who cares? If the browser sees an attribute it doesn't recognize, it won't through a fit like the validator does. It'll just ignore it. Or, if you really want to be a stickler for the rules and you're preprocessing the page with PHP anyway, just strip the problem attributes out when the page is being assembled for the browser. And how you go about differentiating between the browser and your PHP scripts -- depends on your site architecture, I'd say.

ADDENDUM: But personally, I've left non-spec attributes tags on "business critical" pages for server-side use without any repercussions. Pages that've been the landing page for large marketing efforts, event registration, etc. I have yet to get a call or an email from someone b/c the page doesn't validate or render correctly.

I have a PHP program that goes through my pages and builds an outline. "<meta name="Section" content="[section name]" />" lets it know when a new section is starting. The rest, well, I thought the info would be of actual help.

The parts that your PHP program uses, you can leave in, and ignore the validator errors. Remember that the validator is a tool to help you find mistakes. If you know that the errors it reports are not mistakes, then you can safely ignore them.

That being said, there are probably easier ways to feed data to your PHP script than HTML meta tags. It may be worth your while to explore other implementation options.

<!DOCTYPE html><meta charset="utf-8"><title>My First Page</title><pre>HELLO WORLD!
*Welcome!* This is my -first- webpage!
It's a fairly simple webpage, but it -is- a complete webpage.</pre>

So I have achieved HTML5 mastery?

Originally Posted by svidgen

Wait, what? You think that's what HTML5 is all about?

I agree, the above example may be emphasizing lean code a tad much. Completely valid, though!

Originally Posted by Jeff Mott

That being said, there are probably easier ways to feed data to your PHP script than HTML meta tags. It may be worth your while to explore other implementation options.

What would you suggest? The way I've got the program set up, it opens each page in series (that series is defined by the <link rel="next"> tags; I only have to tell the program where to start).

Originally Posted by svidgen

If it's just a validation issue, I'd say, who cares?

I do. If I publish this on a CD as a series of pages, I'd like to be able to stick those pretty little badges on each chapter so that whoever looks at my code is not led astray. If they want to create non-complying pages, that's fine (in fact, in one chapter, I say validation is not everything, and the demonstration of that is a completely valid and equally horrible webpage). But I've had a course where the examples WEREN'T properly done, and it got in the way of me learning. Drove me CRAZY. So, if nothing else, at least THIS series of webpages will be completely valid. I hope that makes sense.