Jump to content

html tutorial inaccuracies


croatiankid
 Share

Recommended Posts

From http://www.w3schools.com/html/html_elements.asp

If you want to follow the latest web standards, you should always use lowercase tags.
...XHTML (the next generation HTML)...
XHTML is not the next generation HTML. XHTML is a reformulation of HTML as an XML application.And what do XHTML rules have to do with HTML?
The World Wide Web Consortium (W3C) recommends lowercase tags in their HTML 4 recommendation
No it does not.On the contrary, it suggests element names to be written in uppercase.(from the recommendation)
Element names are written in uppercase letters (e.g., BODY).
http://www.w3schools.com/html/html_primary.asp
You might have noticed that paragraphs can be written without the closing tag </p>. Don't rely on it. The next version of HTML will not allow you to skip ANY closing tags.
This is not true.(from HTML 5 working draft- bolded important parts)
When the steps below require the UA to generate implied end tags, then, if the current node is a dd element, a dt element, an li element, a p element, a td element, a th element, or a tr element, the UA must act as if an end tag with the respective tag name had been seen and then generate implied end tags again.
On http://www.w3schools.com/html/html_forms.asp
<form name="input" action="html_form_action.asp"method="get">Username: <input type="text" name="user"><input type="submit" value="Submit"></form>

Is not valid HTML!http://www.w3schools.com/html/html_backgrounds.asp

The bgcolor, background, and the text attributes in the <body> tag are deprecated in the latest versions of HTML (HTML 4 and XHTML).
Once again, XHTML is not the latest version of HTML. HTML 4.01 and 5 are the latest versions.http://www.w3schools.com/html/html_whyusehtml4.asp
NOTE: The official HTML 4.01 recommends the use of lower case tags.
No. It does not. It recommends the opposite.
XHTML is the "new" HTML.
No. It's not. HTML 5 is the new HTML.http://www.w3schools.com/html/html_summary.asp
XHTML is the "new" HTML. The latest HTML recommendation is HTML 4.01. This is the last and final HTML version.HTML will be replaced by XHTML, which is a stricter and cleaner version of HTML.
No it's NOT! HTML 4.01 is NOT the last and final HTML version. XHTML is not a stricter, cleaner version of HTML, it's a reformulation of it as XML.AndHTML will be replaced by XHTML??? How do you know!?For being w3schools you sure do have a lot of inaccurate information.
Link to comment
Share on other sites

You're forgetting when were the tutorials written. HTML 5 is a pretty new concept, so before it appeared, XHTML was truly believed to be the only de facto new version of HTML. True, it's a reformulation of HTML 4.01 in XML, but it's "like" a new version of HTML, due to it's similarities, so the turorial is not exactly wrong about it (maybe not exactly correct either, but still...).For the lowercase, perhaps they really should say "we advise you..." instead. After all, while W3C doesn't say anything about it in the spec, XML is case sencetive and XHTML is written in lowercase, so it's wise to keep suggesting that.What's wrong with the example? Other then it's not included in a complete page I mean.

Link to comment
Share on other sites

For the lowercase, perhaps they really should say "we advise you..." instead. After all, while W3C doesn't say anything about it in the spec, XML is case sencetive and XHTML is written in lowercase, so it's wise to keep suggesting that.What's wrong with the example? Other then it's not included in a complete page I mean.
This tutorial is not about XML or XHTML though. And the W3C does say about it here.Put the example underneath a DOCTYPE and see the errors for yourself (besides obviously missing TITLE tags).This tutorial was written well after XHTML 1.0 was finished, and there is nothing in it that says, or suggests, that it's the next version of HTML, or that it is replacing it.
Link to comment
Share on other sites

The sample is not valid HTML 4.01 strict, but it is a valid transitional one:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"   "http://www.w3.org/TR/html4/loose.dtd"><html><head><title>test</title></head><body><form name="input" action="html_form_action.asp"method="get">Username:<input type="text" name="user"><input type="submit" value="Submit"></form></body></html>

This tutorial is not about XML or XHTML though
That's not the point. People that have learned HTML should be able to easily pick up XHTML and XML since they are the future (while HTML must remain alive due to it's own legacy).OK. I agree the statement
XHTML 1.0 (the latest version of HTML)
is not correct. Perhaps
XHTML 1.0 (the new HTML)
would be a better way to put it.
Link to comment
Share on other sites

That's also not true though. XHTML is not the new HTML, HTML 5 (incomplete; HTML 4.01) is.You can't use XHTML and HTML interchangebly.
This is true in a technical sense, but as was said before, HTML5 didn't exist when these tutorials were written and whether it was ever said by W3C or not there was a general assumption among a lot of web designers that XHTML would eventually overtake HTML as the dominate language. IE's lack of support for the XHTML mime type really killed XHTML 1.1 and is probably one of the single largest reason XHTML isn't more widely used and considered necessary. That's my opinion anyways.
Link to comment
Share on other sites

This is true in a technical sense, but as was said before, HTML5 didn't exist when these tutorials were written and whether it was ever said by W3C or not there was a general assumption among a lot of web designers that XHTML would eventually overtake HTML as the dominate language. IE's lack of support for the XHTML mime type really killed XHTML 1.1 and is probably one of the single largest reason XHTML isn't more widely used and considered necessary. That's my opinion anyways.
IE doesn't just not support the mime type, it doesn't support XHTML. Almost all browsers have a parsing but that ignores the slash in self closing tags.
Link to comment
Share on other sites

IE doesn't just not support the mime type, it doesn't support XHTML.
Uhhh... I don't really see your point. To actually have XHTML support means to support the MIME type and act accrodingly. This applies to any other language too. If a user agent doesn't support the text/html MIME type, you can say it doesn't have HTML support.The namespaces are the other way for it, but they are really for... let's say "third party viewers" and are only applcable to XML itself. IE doesn't react on the XHTML namespace due to a lack of XHTML support. If it had XHTML support, it was also going to react on the MIME type. User agents only acting on namespaces are very rare if there are any.And IE does render XHTML served as HTML. So it has a sort of support for it. Btw, there IS an advantage of having XHTML syntaxed file over HTML 4.01, even when served with text/html. Even when served like that, you can use XML tools and technologies (think XSLT, S3L XML DOM, etc.) over it, rather then using regular expressions for example.
Link to comment
Share on other sites

IE doesn't just not support the mime type, it doesn't support XHTML.
IE recognizes XHTML. If you change the doctypes, IE will react differently, therefore it recognizes XHTML. It might treat it as HTML instead of XML, but it's not fair to say it just doesn't "support" XHTML, that might lead someone to believe that if they write documents using XHTML then IE will not display them, and that is not the case. If you really want to get into the specifics and be exactly correct with everything they say in the tutorial, then it will become a technical discussion about content types, rendering engines, XML, etc. I believe the point of the tutorial is to give a non-technical beginner an idea about what they will be working with. As far as that goes, the tutorial succeeds. Anyone looking for information about the technical differences between HTML and XHTML should probably just read the specs.If you think you can do better, then rewrite the tutorials the way you want them written and submit them for review.
Link to comment
Share on other sites

And IE does render XHTML served as HTML. So it has a sort of support for it.
No. It renders it as HTML, and the reason it does (without errors/messups) is because of the parsing bug I mentioned (<br /> in HTML should actually output a line break and a greater-than sign because of a thing called shorttags).
Link to comment
Share on other sites

It might treat it as HTML instead of XML, but it's not fair to say it just doesn't "support" XHTML, that might lead someone to believe that if they write documents using XHTML then IE will not display them, and that is not the case.
That's misleading too though, because people think they have an advantage by using text/html sent XHTML over regular HTML.
Btw, there IS an advantage of having XHTML syntaxed file over HTML 4.01, even when served with text/html. Even when served like that, you can use XML tools and technologies (think XSLT, S3L XML DOM, etc.) over it, rather then using regular expressions for example.
How? Mind what I said before (IE uses it as HTML, so if there's something unknown in HTML, it'll ignore it).
Link to comment
Share on other sites

No. It renders it as HTML, and the reason it does (without errors/messups) is because of the parsing bug I mentioned (<br /> in HTML should actually output a line break and a greater-than sign because of a thing called shorttags).
Are you claiming that the reason IE renders XHTML correctly is because of a parsing bug, as opposed to the developers actually intending that behavior? Do Firefox and Opera also happen to have the exact same bug, due to the fact that neither of them will output a greater than sign when they encounter <br /> in HTML?
That's misleading too though, because people think they have an advantage by using text/html sent XHTML over regular HTML.
I would say they do have an advantage, in that their code is more well-formed and they won't have to adapt to anything once browsers actually do support XHTML. But I don't think anyone is claiming that XHTML gives you an implicit advantage over HTML, people are just saying that XHTML is going to be what eventually replaces HTML as the language of choice for web sites.Again, if you think you can do a better job at writing the tutorials, please provide your rewritten versions. If you can write everything so that it is not misleading, then I'm sure we can get Kaijim to update the online versions.
Link to comment
Share on other sites

I don't want to rewrite the tutorials, I want you to correct some incorrect information. This should be taken as a compliment.

Are you claiming that the reason IE renders XHTML correctly is because of a parsing bug, as opposed to the developers actually intending that behavior? Do Firefox and Opera also happen to have the exact same bug, due to the fact that neither of them will output a greater than sign when they encounter <br /> in HTML?
Yes.more info
Link to comment
Share on other sites

How? Mind what I said before (IE uses it as HTML, so if there's something unknown in HTML, it'll ignore it).
I was hoping you'll say that. Run this XSLT file over any XML file:
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"><xsl:output method="html"/><xsl:template match="/"><xsl:copy-of select="document('http://www.w3schools.com')/*"/></xsl:template></xsl:stylesheet>

I haven't tested this, but I believe you should see the W3Schools home page. If it wasn't valid XHTML page (or at least a well formed XML document), you wouldn't be able to. Try to adjust the adress in the document funciton to http://www.google.com/ for example, and you'll see my point. OK... maybe not, as google is not even valid HTML 4. Try the HTML specification itself: http://www.w3.org/TR/html401/. OK, perhaps they may negotiate the MIME type and serve XHTML when needed (I haven't verified this)... try http://htmlhelp.com/tools/validator/doctype.html. It's a static valid HTML 4 page. It will probably not work (I'll be shocked if it does).To make the example a little more usefull, let's try to pinpoint the URL to the CSS stylesheet W3Schools is using:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"><xsl:output method="text"/><xsl:template match="/"><xsl:variable name="w3s" select="'http://www.w3schools.com/'"/><xsl:value-of select="concat($w3s,document($w3s)//linnk[@rel='stylesheet' and @type='text/css']/@href)"/></xsl:template></xsl:stylesheet>

Again, not tested, but should work. Tell me if it doesn't. If it does, then XHTML is actually even more predictable then I thought.Now. Why this works you might ask? It's because functions like document() don't care about the MIME type of the document. They read whatever text the user agent fetches, check if it's a well formed XML document, and if so, perform an XPath expression over it. If not, the whole XSLT fails. HTML 4 pages fail because of self closing tags that don't have a "/". The last page above for example has <img> and <br>. In XML, this defines start tags, and there are no matching closing tags for them. That's what the XML parser sees anyway.

Link to comment
Share on other sites

Section B.3.7 does not give any helpful information or answer any questions related to this discussion. I think you and I differ on our definitions of the word "bug". In this case, this behavior was designed and specifically implemented by several independent browser vendors, and I don't refer to things like that as bugs. Bugs are unforseen side effects that cause problems. This behavior is not an unforseen side effect. Something designed to work in a way you don't agree with is not a bug.
Link to comment
Share on other sites

Might be similar, depending on if it was meant to happen or not. There are a ton of undocumented DOS commands, for example, where there is no documentation on any of them but if you use one the system does not complain, so they do something. In that sense, they are not a bug. But when you use something like mysql_fetch_field, which is not supposed to advance the internal pointer, inside of a loop for mysql_fetch_array and it messes things up, that is an undocumented bug.

Link to comment
Share on other sites

  • 1 month later...
XHTML is not the next generation HTML. XHTML is a reformulation of HTML as an XML application.
XHTML 1.0 is a reformulation of HTML 4.01 as an XML application, and, for example, can be used to store the contents of a blog articles and comments inside enclosing XML files, and then, be served either as XHTML or HTML... A translation from XHTML to HTML being possible, ensuring that bandwidth is saved by omitting useless tags, and using tag minimization.However, HTML5/XHTML5 and XHTML 2.0 seems to fork... In my opinion, this is a bad thing, and may cause many problems. Personally, I don't like the way HTML5 is taking... Making it a non-SGML application because... Just because no browser on earth is correct enough to use a SGML parser... So, this becomes, de facto standard.Nevertheless, HTML5 and XHTML5 will be equivalent languages with different syntaxes.
Once again, XHTML is not the latest version of HTML. HTML 4.01 and 5 are the latest versions.
HTML5 is not the latest version... It's the "next" version, and isn't likely to be released before some time.Well, once, I sent a bug report to some browser vendor for a defect in the support of HTML 4.01, and they answered that it is "irrevelant", because this HTML feature wouldn't be present in HTML5...So, you're somehow right, HTML5 is already in use for not fixing bugs in current browsers, because HTML5 is about admitting that current tools are broken and normalize their current broken behavior. e.g. Microsoft doesn't really participate to this working group, but everything will be done to adapt the standard to make IE conforming.Okay, I stop bashing HTML5. HTML5 has good sides too.
No. It does not. It recommends the opposite.
I understood that the W3C didn't specifically recommend using upper case, but only told that, for the sake of clarity, they would use, in the W3C standard document, uppercase letters for element names and lowercase letters for attributes.This paragraph is in the "Document conventions" section.The point is to make a clear difference, in the standard paper, between these two types of tokens.Similarly, if you read some other standard papers, you may see that, there are conventions such as underlining identifiers and highlighting keywords to make them appear differently... That doesn't mean you must (or even can) do it in real code.However, it's sure that, the W3C endorses this practice, and, a normal author who read the W3C standard, would normally tend to use this canonical notation.Moreover, the sentence "the convention is meant to encourage readability", seems to indicate that this convention is not limited to their document, otherwise I don't see why they would have used the word "encourage".So, you're right.
Even when served like that, you can use XML tools and technologies (think XSLT, S3L XML DOM, etc.) over it, rather then using regular expressions for example.
Or, simply, libsgml... to translate it to an XML document and manipulate it with thousands of XML tools.I agree on the fact that, the XML form is more convenient to process with tools. There are more XML tools available than SGML tools.
IE recognizes XHTML. If you change the doctypes, IE will react differently, therefore it recognizes XHTML.
You're right, although the behavior of IE for an XHTML DOCTYPE, HTML 4.0 Strict DOCTYPE and an unrecognized DOCTYPE is identical.The quirk-mode/strict-mode switch algorithm is available at:http://msdn2.microsoft.com/en-us/library/ms535242.aspxBut that's not real XHTML support. IE just has XHTML in its "non-tag-soup" list of markup languages.
Link to comment
Share on other sites

Well, once, I sent a bug report to some browser vendor for a defect in the support of HTML 4.01, and they answered that it is "irrevelant", because this HTML feature wouldn't be present in HTML5...
Let me guess. The vendor's name started with an "M" and ended with a "icrosoft".
But that's not real XHTML support. IE just has XHTML in its "non-tag-soup" list of markup languages.
Yeah, I wasn't trying to claim that IE supports XHTML in any way, just that it recognizes when the page is identified as such. You cleared up that rather then identifying specifically XHTML, it just generically identifies it as something other then tag soup.
Link to comment
Share on other sites

Even when served like that, you can use XML tools and technologies (think XSLT, S3L XML DOM, etc.) over it, rather then using regular expressions for example.
Or, simply, libsgml... to translate it to an XML document and manipulate it with thousands of XML tools.
That wouldn't be doable in all environments, especially .NET or JAVA ones (I'm implying ASP.NET and ColdFusion here) that aren't based on C like libsgml. Having XHTML document from the start would ease this process. XHTML to HTML being easily doable if available strengthens that.BTW, there isn't XHTML5. Not even plans for such. Not yet anyway.
Link to comment
Share on other sites

Section B.3.7 does not give any helpful information or answer any questions related to this discussion.
It shows that the HTML SGML declaration includes the DATATAG feature (part of the SHORTTAG set of features), which makes:
<element/Some text/

Equivalent to:

<element>Some text</element>

This is not a well known used feature, though that might be useful for things like <em/a few words/.That makes <br/> have different semantics than in XML... In HTML, it is equivalent to: <br>>

In this case, this behavior was designed and specifically implemented by several independent browser vendors, and I don't refer to things like that as bugs.
Browsers are not the only tools to parse HTML.The non-conformance of browsers, make the interpretation by libsgml, or other SGML tools, of HTML code, different.If you think that, non-conforming browsers behavior impose the standard, then, you should recognize that CDATA is not part of HTML, as it's supported by no browser... But Opera, which, from the de facto standard of all other browsers, is buggy.
Bugs are unforseen side effects that cause problems.
That causes problems for:
  • People wishing to use this not-very-much-used feature.
  • People using proper tools such as libsgml.

Something designed to work in a way you don't agree with is not a bug.
Something working in a way that the standard doesn't agree with, and claiming to be conforming to this standard, has a bug.The intent of B.3.7 is to recall to implementors that these uncommonly used SGML features, that had a very poor browser support, are part of the language, and should be implemented, and recall to web authors, that they should be careful as most of them have a pretty bad support currently.I highly doubt you can convince anybody that CDATA is useless and should not be implemented. For example, when HTML code displayed in HTML documents, the bandwidth saved, and the very much increased legibility of source code are worthy.If it has a poor support, it's because browser vendors are more focused on interpreting tag soup and adding new fancy features, than introducing features that don't appear in the "HTML for dummies" book, and so are not used by enough people.
Link to comment
Share on other sites

I wasn't aware of the rules you're talking about, I didn't realize that this is technically valid:<em/a few words/But, I do disagree with you that the representation above is more legible then the longhand equivalent.<em/a few words/<em>a few words</em>The explicit closing tag does make it easier to read, it's immediately obvious what the meaning is to anyone with even a cursory understanding of HTML.<p/Some people think that <i/SGML/ is the same as <b/HTML//<p>Some people think that <i>SGML</i> is the same as <b>HTML</b></p>Granted, it saves a few bytes in size, but I would rather add the closing tag for increased readability for the same reason that I use whitespace to indent. It adds a few bytes across the wire, but it's much easier to read.Obviously that's a personal preference though.

Link to comment
Share on other sites

<p/Some people think that <i/SGML/ is the same as <b/HTML//<p>Some people think that <i>SGML</i> is the same as <b>HTML</b></p>
Strangely, I read the first line quicker and smoother than the second line, while I thought it would be less legible...I didn't expect that.Anyway, used sparingly, it isn't harmful. Personally, I don't like it much, but, it is in the standard, and, if I had to write a browser, I would support in "strict" mode.
Granted, it saves a few bytes in size, but I would rather add the closing tag for increased readability for the same reason that I use whitespace to indent. It adds a few bytes across the wire, but it's much easier to read.
You're allowed to.
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...