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.
The other major question I have is what to do with these:
...if you're serving a page as XHTML, you SHOULD use the XHTML 1.0 or 1.1 doctype.
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.
Originally Posted by Mr Initial Man
The other major question I have is what to do with these... HTML5 doesn't seem to like the values of those name and rel attributes.
Do you know of any practical reason to keep them? Or were you inserting code just because it was valid?
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.
Last edited by Mr Initial Man; 04-02-2012 at 03:29 PM.
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.
HTML 5 is all about using the minimal amount of code.
HTML Code:
<!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.
Last edited by Mr Initial Man; 04-03-2012 at 12:33 AM.
HI ! i am one of the lovers of jquery. Jquery is not for amateurs. May be i am not able to use good coding standard but lot of my seniors are also interested in jquery.
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).
My first thought was that since you're already manually coding the hierarchy in the form of meta tags, I wonder if there's any reason you couldn't manually code the outline itself instead?
But if there's some reason I'm not aware of why that wouldn't work, then you could also define the book's hierarchy as a JSON data structure:
My first thought was that since you're already manually coding the hierarchy in the form of meta tags, I wonder if there's any reason you couldn't manually code the outline itself instead?
But if there's some reason I'm not aware of why that wouldn't work, then you could also define the book's hierarchy as a JSON data structure:
In that case, you could still use JSON or YAML to define the relationships between sections and chapters (instead of meta tags), and still parse each page for subheadings.
In that case, you could still use JSON or YAML to define the relationships between sections and chapters (instead of meta tags), and still parse each page for subheadings.
Originally Posted by Mr Initial Man
Reply With Quote
on a page.
Bookmarks