Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Regarding HTML5
14 views
Skip to first unread message
Gus Richter
Nov 29, 2012, 9:48:38 PM11/29/12
to
I'm going to give it one last try to enlighten Thomas PointedEars Lahn
and at the same time eradicate any misconception he may have caused.
<!DOCTYPE html> is the one and only doctype for HTML5.
It is required for HTML documents, but optional for XHTML documents,
although Henri Sivonen recommends to not use a doctype at all for XHTML
where the parser recognizes XHTML by being served as application/xml or
application/xhtml+xml (being rendered in XML mode, automatically means
strict).
It is the shortest/simplified doctype in order to keep all browsers out
of Quirks mode.
It triggers Standards mode in all browsers just as some much longer
versions do with Public and System identifier parts.
It is shorter - simplified by not including the unnecessary fluff.
It enables you to validate new HTML5 features and achieve more precise
validation of old features.
It is in Standards Compliance Mode or simply as Standards mode. Also
referred to as Non-Quirks mode.
Standards mode means that the document will conform to the specification
(Standards) - HTML Living Standard =or= W3C's HTML5, where the new
elements in HTML5 are supported (depending on specific browser support).
Standards mode is the only one in HTML5. This means that it is, as it
was previously known, Strict mode. In order to get away from possibly
sugesting different Modes, it is not referred to as Strict mode, but as
Standards mode. There can only be one.
In pre-HTML5, there was Strict mode doctype which meant that the
document will conform to the HTML4.1 specification for example.
In pre-HTML5, there also was Quirks mode doctype, or no doctype at all,
which did not conform to the specification.
In pre-HTML5, there also was Almost Strict mode which meant that Table
Cells were not as per standards - hence using Quirks mode for Table
Cell, etc.
In pre-HTML5, Quirks mode also meant that different browsers implemented
their Quirks differently.
In pre-HTML5, Transitional meant, depending on its flavour, either
Quirks or Almost Strict - all Quirks or partial Quirks.
If you write according to HTML4.01 Strict, you can still use <!DOCTYPE
html> right now as a replacement for the Strict doctype, keeping in mind
the caveat regarding new HTML5 elements and validation.
With the new doctype, the type may be ignored, as in: <style> and
<script> since the type is assumed.
<!DOCTYPE html> Triggers standards-based rendering in all browsers. It�s
2011; stop relying on �quirks mode�! It's more apropos now in 2012 See:
<http://diveinto.html5doctor.com/peeks-pokes-and-pointers.html> where it
said back then in 2011 to stop using Quirks mode and use Standards mode
instead.
Since <!DOCTYPE html> is simply a shortened down version, with all the
unnecessary fluff removed, from the Strict doctype, it may be used as a
replacement for the Strict doctype, keeping in mind the caveat regarding
new HTML5 elements and validation.
If in disagreement with any portion (Thomas PointedEars Lahn and anyone
else), please give your reasons and avoid any derogatory statements like:
"you have no clue what you are talking about" or "You have not
understood what you are talking about".
--
Gus' understanding as gleaned from reading the specs and elsewhere.
Jukka K. Korpela
Nov 30, 2012, 1:55:27 AM11/30/12
to
2012-11-30 4:48, Gus Richter wrote:
> I'm going to give it one last try to enlighten Thomas PointedEars Lahn
Such persistence would be worth a nobler and a more realistic cause.
> I'm going to give it one last try to enlighten Thomas PointedEars Lahn
> and at the same time eradicate any misconception he may have caused.
and to be honest, not all of them have been caused by the troll.
> <!DOCTYPE html> is the one and only doctype for HTML5.
are allowed as well:
http://www.w3.org/TR/html5/syntax.html#the-doctype
> It is shorter - simplified by not including the unnecessary fluff.
complicated and people often make mistakes with them. A typo of a single
character usually throws browsers to quirks mode.
> It enables you to validate new HTML5 features and achieve more precise
> validation of old features.
checkers perform checks of completely different kind. Instead of
strictly defined and DTD-driven validation, they run checks against what
was their authors' best understanding (at some moment of time) of some
unspecified version of the W3C HTML5 draft or the highly mutable
document with the oxymoronic name "HTML Living Standard".
Of course, this means that they try to process the proposed novelties,
which may violate existing DTDs and therefore be flagged as errors in
validation proper (DTD-based validation). They may also detect some
constructs that are errors according to current HTML specifications such
as HTML 4.01 but cannot be described in a DTD, or just have not been
described in a DTD.
But on the other hand, they report many constructs as errors, even
though they are valid by current HTML specifications, such as <meta
name=foo value=bar> (literally) or <td align=right>. Many old features
are flagged just because they have not been included into (some version
of) HTML5 drafts. And this may cause so many errors that you will have
hard time in distinguishing real errors among them.
> Standards mode means that the document will conform to the specification
> (Standards) - HTML Living Standard =or= W3C's HTML5,
that the document conforms to the "standards". Or, rather, the browser
makes its best attempt at processing the document by the "standards",
except in cases where it willfully deviates from that.
> where the new elements in HTML5 are supported
all. There have been statements of such dependency in one browser for
some feature in the past, and this may well have been true, but this was
fixed long ago. Anyone knowing about such evidence in currently used
versions should stand up now to reveal the secrets.
> Standards mode is the only one in HTML5.
http://quirks.spec.whatwg.org/
Far from abandoning quirks mode, it is being turned to a well-defined
mode of operation. Of course the result is not the same as quirk mode in
browsers, since quirks mode varies greatly across browsers. But WHATWG
people seem to believe in changing this, and this would effectively mean
standardizing quirks mode!
> This means that it is, as it
> was previously known, Strict mode.
reflect them, but not completely. Browsers modes are something
completely different.
> In pre-HTML5, there was Strict mode doctype which meant that the
> document will conform to the HTML4.1 specification for example.
The Strict doctype declaration simply refers to a specific DTD, and the
Transitional doctype declaration refers to another DTD. As far as
specifications are concerned, that's all. The difference between the two
doctypes consists of the differences between the DTDs. Doctype sniffing
is something different, and it is based on dirty games on doctype
declarations as strings, not as references to DTDs.
> In pre-HTML5, there also was Quirks mode doctype,
> In pre-HTML5, there also was Almost Strict mode
HTML versions, and surely not defined in specifications.
> In pre-HTML5, Quirks mode also meant that different browsers implemented
> their Quirks differently.
There is no definition for it now, just descriptions of browser behavior.
> In pre-HTML5, Transitional meant, depending on its flavour, either
> Quirks or Almost Strict - all Quirks or partial Quirks.
violation of the specification.
> If you write according to HTML4.01 Strict, you can still use <!DOCTYPE
> html> right now as a replacement for the Strict doctype,
can use <!DOCTYPE html> if you like, independently of the kind of HTML
you are actually using, if you want browsers to operate in "standards mode".
> Since <!DOCTYPE html> is simply a shortened down version, with all the
> unnecessary fluff removed, from the Strict doctype,
adequately call it. It has completely lost the meaning of a document
type declaration and become just an incantation used to trigger
"standards mode".
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Gus Richter
Nov 30, 2012, 4:51:41 AM11/30/12
to
On 11/30/2012 1:55 AM, Jukka K. Korpela wrote:
> 2012-11-30 4:48, Gus Richter wrote:
>
>> I'm going to give it one last try to enlighten Thomas PointedEars Lahn
>
> Such persistence would be worth a nobler and a more realistic cause.
>
>> and at the same time eradicate any misconception he may have caused.
>
> Well, that's more realistic. And there surely are misconceptions around,
> and to be honest, not all of them have been caused by the troll.
>
>> <!DOCTYPE html> is the one and only doctype for HTML5.
>
> Not correct. It is the recommended one, but a "DOCTYPE legacy string"
> are allowed as well:
> http://www.w3.org/TR/html5/syntax.html#the-doctype
The short, simple doctype is the right thing to use unless you have a
> 2012-11-30 4:48, Gus Richter wrote:
>
>> I'm going to give it one last try to enlighten Thomas PointedEars Lahn
>
> Such persistence would be worth a nobler and a more realistic cause.
>
>> and at the same time eradicate any misconception he may have caused.
>
> Well, that's more realistic. And there surely are misconceptions around,
> and to be honest, not all of them have been caused by the troll.
>
>> <!DOCTYPE html> is the one and only doctype for HTML5.
>
> Not correct. It is the recommended one, but a "DOCTYPE legacy string"
> are allowed as well:
> http://www.w3.org/TR/html5/syntax.html#the-doctype
specific reason to avoid it, but you are correct that there are a few
legacy permitted strings which the spec describes as
"obsolete/deprecated permitted Doctype strings", which Authors "should
not use", including <!DOCTYPE html SYSTEM "about:legacy-compat"> which
may be used in the case of HTML generators that cannot output HTML
markup with the short HTML5 doctype and otherwise should not be used.
>> It is shorter - simplified by not including the unnecessary fluff.
>
> I would add the practical point that the longer alternatives are fairly
> complicated and people often make mistakes with them. A typo of a single
> character usually throws browsers to quirks mode.
>> It enables you to validate new HTML5 features and achieve more precise
>> validation of old features.
>
> No, it rather makes the http://validatot.w3.org and http://validator.nu
> checkers perform checks of completely different kind. Instead of
> strictly defined and DTD-driven validation, they run checks against what
> was their authors' best understanding (at some moment of time) of some
> unspecified version of the W3C HTML5 draft or the highly mutable
> document with the oxymoronic name "HTML Living Standard".
<section>, <header>, and <footer>.
Obsolete elements are still supported, but won�t validate.
> Of course, this means that they try to process the proposed novelties,
> which may violate existing DTDs and therefore be flagged as errors in
> validation proper (DTD-based validation). They may also detect some
> constructs that are errors according to current HTML specifications such
> as HTML 4.01 but cannot be described in a DTD, or just have not been
> described in a DTD.
>
> But on the other hand, they report many constructs as errors, even
> though they are valid by current HTML specifications, such as <meta
> name=foo value=bar> (literally) or <td align=right>. Many old features
> are flagged just because they have not been included into (some version
> of) HTML5 drafts. And this may cause so many errors that you will have
> hard time in distinguishing real errors among them.
>> Standards mode means that the document will conform to the specification
>> (Standards) - HTML Living Standard =or= W3C's HTML5,
>
> No, it is just a browser's mode of operation, based on the assumption
> that the document conforms to the "standards". Or, rather, the browser
> makes its best attempt at processing the document by the "standards",
> except in cases where it willfully deviates from that.
browsers try to give conforming documents the specification-wise correct
treatment to the extent implemented in a particular browser."
"specification-wise" - conforming to the specification standards in as
far as the browser implements the specs.
> > where the new elements in HTML5 are supported
>
> Support to new elements and attributes does not depend on the DOCTYPE at
> all. There have been statements of such dependency in one browser for
> some feature in the past, and this may well have been true, but this was
> fixed long ago. Anyone knowing about such evidence in currently used
> versions should stand up now to reveal the secrets.
>> Standards mode is the only one in HTML5.
>
> There is an ongoing activity aimed at defining quirks mode:
> http://quirks.spec.whatwg.org/
> Far from abandoning quirks mode, it is being turned to a well-defined
> mode of operation. Of course the result is not the same as quirk mode in
> browsers, since quirks mode varies greatly across browsers. But WHATWG
> people seem to believe in changing this, and this would effectively mean
> standardizing quirks mode!
>> This means that it is, as it
>> was previously known, Strict mode.
>
> There is no Strict mode. There are Strict DTDs, and HTML5 drafts mostly
> reflect them, but not completely. Browsers modes are something
> completely different.
commonly referred to as Strict Mode.
My use of Strict/Standards, Almost Strict/Standards, Transitional and
Quirks Mode refers to the browsers rendering mode.
>> In pre-HTML5, there was Strict mode doctype which meant that the
>> document will conform to the HTML4.1 specification for example.
>
> HTML 4.01, you mean, or HTML 4.0; there is no HTML4.1.
> The Strict doctype declaration simply refers to a specific DTD, and the
> Transitional doctype declaration refers to another DTD. As far as
> specifications are concerned, that's all. The difference between the two
> doctypes consists of the differences between the DTDs. Doctype sniffing
> is something different, and it is based on dirty games on doctype
> declarations as strings, not as references to DTDs.
>
>> In pre-HTML5, there also was Quirks mode doctype,
>
> No, there is no such doctype.
Ref. <http://hsivonen.iki.fi/doctype/>
>> In pre-HTML5, there also was Almost Strict mode
>
> There is still a mode called that way in browsers. It is not a matter of
> HTML versions, and surely not defined in specifications.
into Quirks Mode. Ref. <http://hsivonen.iki.fi/doctype/>
>> In pre-HTML5, Quirks mode also meant that different browsers implemented
>> their Quirks differently.
>
> They still do, even though HTML5 activities aim at defining quirks mode.
> There is no definition for it now, just descriptions of browser behavior.
of the modes varies from browser to browser"
>> In pre-HTML5, Transitional meant, depending on its flavour, either
>> Quirks or Almost Strict - all Quirks or partial Quirks.
>
> Using a Transitional DTD without a URL is not a flavour, it is a
> violation of the specification.
Transitional doctype. Some put it in Quirks and some in Almost Strict,
where Almost Strict means that a portion is in Quirks.
>> If you write according to HTML4.01 Strict, you can still use <!DOCTYPE
>> html> right now as a replacement for the Strict doctype,
>
> No, you cannot; using <!DOCTYPE html> does not conform to HTML 4.01. You
> can use <!DOCTYPE html> if you like, independently of the kind of HTML
> you are actually using, if you want browsers to operate in "standards
> mode".
�Upgrading� to HTML5 can be as simple as changing your doctype.
Validation is another matter. A few simple changes will resolve this.
>> Since <!DOCTYPE html> is simply a shortened down version, with all the
>> unnecessary fluff removed, from the Strict doctype,
>
> No, it is a completely ad-hoc magic string, "DOCTYPE string" as they
> adequately call it. It has completely lost the meaning of a document
> type declaration and become just an incantation used to trigger
> "standards mode".
description of how he arrived at the final doctype. The final doctype
was the minimum necessary for the specific purpose of keeping the
browser out of Quirks Mode (and place it in Standards Mode).
--
Gus
Guillaume Dargaud
Nov 30, 2012, 6:25:35 AM11/30/12
to
> The short, simple doctype is the right thing to use unless you have a
> specific reason to avoid it, [...]
So <!DOCTYPE html> basically means "use the HTML of today" (HTML5).
But then when 6 or whatever comes along, it may be that your site will no
longer works because at this point it will mean "use HTML6" but your code
won't have changed. Right ?
--
Guillaume Dargaud
http://www.gdargaud.net/
Denis McMahon
Nov 30, 2012, 9:08:45 AM11/30/12
to
On Fri, 30 Nov 2012 12:25:35 +0100, Guillaume Dargaud wrote:
>> The short, simple doctype is the right thing to use unless you have a
>> specific reason to avoid it, [...]
>
> So <!DOCTYPE html> basically means "use the HTML of today" (HTML5).
>
> But then when 6 or whatever comes along, it may be that your site will
> no longer works because at this point it will mean "use HTML6" but your
> code won't have changed. Right ?
Worse.
>> The short, simple doctype is the right thing to use unless you have a
>> specific reason to avoid it, [...]
>
> So <!DOCTYPE html> basically means "use the HTML of today" (HTML5).
>
> But then when 6 or whatever comes along, it may be that your site will
> no longer works because at this point it will mean "use HTML6" but your
> code won't have changed. Right ?
HTML 5 next week might be different than HTML 5 this week. So your
compliant website (this week) could be non compliant (next week).
Rgds
Denis McMahon
Jukka K. Korpela
Nov 30, 2012, 9:40:51 AM11/30/12
to
2012-11-30 16:08, Denis McMahon wrote:
> HTML 5 next week might be different than HTML 5 this week.
Yes, though that's not very probable if you regard W3C HTML5 as HTM5.
> HTML 5 next week might be different than HTML 5 this week.
The document http://www.w3.org/TR/html5/ was last updated 25 October 2012.
If you regard HTML "Living Standard" as HTML5 (though its authors do not
call it HTML5), then your HTML5 next week will almost certainly be
different from your HTML5 today. The document
http://www.whatwg.org/specs/web-apps/current-work/multipage/ was last
updated 29 November 2012, i.e. yesterday (by some time zones).
> So your
> compliant website (this week) could be non compliant (next week).
between a document and a draft or a "living standard"? When the criteria
are set by a mutable definition, then compliance is a relevant term only
as relating to some specific version of the definition, and then it
becomes rather irrelevant.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
David Stone
Nov 30, 2012, 9:42:31 AM11/30/12
to
In article <k996qa$ur9$1...@dont-email.me>,
Gus Richter <gusri...@netscape.net> wrote:
> I'm going to give it one last try to enlighten Thomas PointedEars Lahn
Who? ;)
> I'm going to give it one last try to enlighten Thomas PointedEars Lahn
Chris F.A. Johnson
Nov 30, 2012, 11:44:29 AM11/30/12
to
David Stone
Nov 30, 2012, 12:37:49 PM11/30/12
to
In article <dc4no9-...@cfa.johnson>,
"Chris F.A. Johnson" <cfajo...@gmail.com> wrote:
> On 2012-11-30, David Stone wrote:
> > In article <k996qa$ur9$1...@dont-email.me>,
> > Gus Richter <gusri...@netscape.net> wrote:
> >
> >> I'm going to give it one last try to enlighten Thomas PointedEars Lahn
> >
> > Who? ;)
>
> Tommy
Wizard!
> On 2012-11-30, David Stone wrote:
> > In article <k996qa$ur9$1...@dont-email.me>,
> > Gus Richter <gusri...@netscape.net> wrote:
> >
> >> I'm going to give it one last try to enlighten Thomas PointedEars Lahn
> >
> > Who? ;)
>
> Tommy
Denis McMahon
Nov 30, 2012, 12:39:51 PM11/30/12
to
want to recycle the number of electrons needed to express the matter in
detail.
As far as I'm concerned, when there is a ratified html 5 standard I'll
start using it, until then, I'm sticking with 4.01.
At the moment, I'm not even sure if the various groups involved even know
how they're going to ratify html 5 (they may think they know this, but
the last time I looked into the issue, admittedly a few months ago, they
seemed to think different things), so I'm not holding my breath!
Rgds
Denis McMahon
Andreas Prilop
Nov 30, 2012, 1:11:55 PM11/30/12
to
On Fri, 30 Nov 2012, Chris F.A. Johnson wrote:
>>> Thomas PointedEars Lahn
>>
>> Who? ;)
>
> Tommy
Timmy!
>>> Thomas PointedEars Lahn
>>
>> Who? ;)
>
> Tommy
Gus Richter
Nov 30, 2012, 1:34:18 PM11/30/12
to
backward compatible and is intended to remain so. If it worked yesterday
in HTML 4, it will work today in HTML5 and what works today in HTML5
will work in the future.
The WHATWG puts out a "Living Standard"
<http://www.whatwg.org/specs/web-apps/current-work/> simply titled HTML
containing no versioning, but with additions, changes and deletions
ongoing to the same document.
The W3C puts out a "snapshot in time version"
<http://www.w3.org/TR/html5/> titled HTML5 in keeping with previous
methods - Draft to Recommendation.
If a feature is implemented by browsers it will be supported and solid.
If not implemented by all or not as per specs, then it is cutting edge
and you could get hurt. Once implemented, the feature is very unlikely
to be removed. Possibly modified later, yes, but what worked yesterday
will work today and tomorrow. If the browsers do not implement a
feature, then it will be removed from the Living Standard. Browser
implementation is the key ingredient. What is in the "snapshot in time
version" is supported and solid. The Living Standard tracks
implementation in the margin. A very fine site "Can I use"
<http://caniuse.com/> also tracks this information.
HTML5 is here to stay <http://diveintohtml5.info/>
--
Gus
Jukka K. Korpela
Nov 30, 2012, 1:57:08 PM11/30/12
to
2012-11-30 20:34, Gus Richter wrote:
> The big thing about HTML5 (as in previous versions) is that it is
> backward compatible and is intended to remain so. If it worked yesterday
> in HTML 4, it will work today in HTML5 and what works today in HTML5
> will work in the future.
HTML5 has little to do with continuity. Browsers keep their legacy
> The big thing about HTML5 (as in previous versions) is that it is
> backward compatible and is intended to remain so. If it worked yesterday
> in HTML 4, it will work today in HTML5 and what works today in HTML5
> will work in the future.
processing of documents simply because a) that's the simplest way and b)
there is, or might be, loads of pages that rely on it, so by refusing to
display it as intended, browsers would take unnecessary risks in the
race between browsers.
> The WHATWG puts out a "Living Standard"
> <http://www.whatwg.org/specs/web-apps/current-work/> simply titled HTML
> containing no versioning, but with additions, changes and deletions
> ongoing to the same document.
twice a day. Calling it a "standard" is ridiculous.
> The Living Standard tracks
> implementation in the margin.
how HTML should be enhanced, partly implemented in browsers and partly
not. It also includes a quasi-religious agenda of declaring some
features of legacy HTML as "obsolete" or simply wrong.
That's a much more practical site, though far from complete in
documenting browser practices.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Stan Brown
Nov 30, 2012, 8:26:55 PM11/30/12
to
On Fri, 30 Nov 2012 08:55:27 +0200, Jukka K. Korpela wrote:
> 2012-11-30 4:48, Gus Richter wrote:
>
> > I'm going to give it one last try to enlighten Thomas PointedEars Lahn
>
> Such persistence would be worth a nobler and a more realistic cause.
>
> > and at the same time eradicate any misconception he may have caused.
>
> Well, that's more realistic.
>
Funny: both of your reactions match mine to the same points.
> 2012-11-30 4:48, Gus Richter wrote:
>
> > I'm going to give it one last try to enlighten Thomas PointedEars Lahn
>
> Such persistence would be worth a nobler and a more realistic cause.
>
> > and at the same time eradicate any misconception he may have caused.
>
> Well, that's more realistic.
>
--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you
Jukka K. Korpela
Dec 1, 2012, 10:55:07 AM12/1/12
to
2012-11-30 11:51, Gus Richter wrote:
> [<!DOCTYPE html>]
error messages if you don't use the HTML5 doctype (or a suitable custom
DTD).
> Obsolete elements are still supported, but won’t validate.
And this is a problem, if you wish to use them _and_ use a validator.
Remember that "obsolete" means just "what some version of HTML5 / HTML
Living Standard declares as obsolete".
>>> Standards mode means that the document will conform to the specification
>>> (Standards) - HTML Living Standard =or= W3C's HTML5,
>>
>> No, it is just a browser's mode of operation, based on the assumption
>> that the document conforms to the "standards". Or, rather, the browser
>> makes its best attempt at processing the document by the "standards",
>> except in cases where it willfully deviates from that.
>
> Henri Sivonen describes Standards Mode: "In the Standards mode the
> browsers try to give conforming documents the specification-wise correct
> treatment to the extent implemented in a particular browser."
Yes, that's what "standards mode" means, except that "conforming" is not
relevant here. It does not imply by any means that the document actually
conforms to anything.
Browsers do not stop processing an HTML document, or even switch mode,
when they encounter an obsolete, deprecated, or completely nonstandard
construct. They just do their best with the part they understand. When
they see <foo>bar</foo>, they render "bar" pretending that <foo> and
</foo> are not there - except that modern browsers generally still add a
note for a <foo> element in the document tree, so it can be styled or
processed with a script. Using "custom tags" might not be safe enough,
but that's a different issue. And browsers still recognize and implement
tags that haven't been in the specs for ages, even as obsoleted, such as
<xmp>.
"Standards mode" is mostly about interpreting CSS rather than HTML, as
indicated by my (non-exhaustive) list of what happens in "quirks mode":
http://www.cs.tut.fi/~jkorpela/quirks-mode.html
> My use of Strict/Standards, Almost Strict/Standards, Transitional and
> Quirks Mode refers to the browsers rendering mode.
It's better to use the common phrases "standards mode" and "quirks mode"
to avoid further confusion (in addition to the unavoidable confusion
that browsers have created).
> Ref. <http://hsivonen.iki.fi/doctype/> you will find 5 "flavours" of the
> Transitional doctype. Some put it in Quirks and some in Almost Strict,
> where Almost Strict means that a portion is in Quirks.
The HTML 4.01 specification specifies that the doctype declaration shall
be one of three alternatives, Strict, Transitional, and Frameset. Any
variation in the Transitional doctype is either variation across
specifications or nonstandard.
>>> If you write according to HTML4.01 Strict, you can still use <!DOCTYPE
>>> html> right now as a replacement for the Strict doctype,
>>
>> No, you cannot; using <!DOCTYPE html> does not conform to HTML 4.01. You
>> can use <!DOCTYPE html> if you like, independently of the kind of HTML
>> you are actually using, if you want browsers to operate in "standards
>> mode".
>
> Ref> <http://diveintohtml5.info/introduction.html>
> “Upgrading” to HTML5 can be as simple as changing your doctype.
When you use <!DOCTYPE html>, you are not writing according to HTML4.01
Strict, simply because it requires a different doctype. It is true that
in simple cases, an HTML 4.01 Strict document becomes an HTML5 document
just by changing the doctype, but this is rather pointless and not an
upgrade in any sense.
> Validation is another matter. A few simple changes will resolve this.
I'm afraid there are many things that need consideration, as people have
observed when trying to "upgrade to HTML5" (usually for no good reason).
The rather restrictive policy on <meta> tags in HTML5 is perhaps the
most common issue. (Most <meta> tags are write-only noise, but they are
commonly used still.)
> I searched and searched in vain for Ian Hickson's interesting
> description of how he arrived at the final doctype. The final doctype
> was the minimum necessary for the specific purpose of keeping the
> browser out of Quirks Mode (and place it in Standards Mode).
I don't remember having read the story, but I suppose it was a matter of
checking how browsers dealt with doctypes, and taking <!doctype html> as
triggering "standards mode" was probably more or less accidental.
Browsers use "standards mode" when a custom doctype is used, like
<!DOCTYPE HTML SYSTEM "http://www.cs.tut.fi/~jkorpela/html/tagsoup.dtd">
and it just happened that browsers don't require the word SYSTEM and the
quoted string. (IE does not even require the string HTML, but Firefox does.)
--
Yucca, http://www.cs.tut.fi/~jkorpela/
> [<!DOCTYPE html>]
> allows you to use and validate new semantic elements like <article>,
> <section>, <header>, and <footer>.
I can use them with any doctype. In validation, they of course cause
> <section>, <header>, and <footer>.
error messages if you don't use the HTML5 doctype (or a suitable custom
DTD).
> Obsolete elements are still supported, but won’t validate.
And this is a problem, if you wish to use them _and_ use a validator.
Remember that "obsolete" means just "what some version of HTML5 / HTML
Living Standard declares as obsolete".
>>> Standards mode means that the document will conform to the specification
>>> (Standards) - HTML Living Standard =or= W3C's HTML5,
>>
>> No, it is just a browser's mode of operation, based on the assumption
>> that the document conforms to the "standards". Or, rather, the browser
>> makes its best attempt at processing the document by the "standards",
>> except in cases where it willfully deviates from that.
>
> Henri Sivonen describes Standards Mode: "In the Standards mode the
> browsers try to give conforming documents the specification-wise correct
> treatment to the extent implemented in a particular browser."
relevant here. It does not imply by any means that the document actually
conforms to anything.
Browsers do not stop processing an HTML document, or even switch mode,
when they encounter an obsolete, deprecated, or completely nonstandard
construct. They just do their best with the part they understand. When
they see <foo>bar</foo>, they render "bar" pretending that <foo> and
</foo> are not there - except that modern browsers generally still add a
note for a <foo> element in the document tree, so it can be styled or
processed with a script. Using "custom tags" might not be safe enough,
but that's a different issue. And browsers still recognize and implement
tags that haven't been in the specs for ages, even as obsoleted, such as
<xmp>.
"Standards mode" is mostly about interpreting CSS rather than HTML, as
indicated by my (non-exhaustive) list of what happens in "quirks mode":
http://www.cs.tut.fi/~jkorpela/quirks-mode.html
> My use of Strict/Standards, Almost Strict/Standards, Transitional and
> Quirks Mode refers to the browsers rendering mode.
to avoid further confusion (in addition to the unavoidable confusion
that browsers have created).
> Ref. <http://hsivonen.iki.fi/doctype/> you will find 5 "flavours" of the
> Transitional doctype. Some put it in Quirks and some in Almost Strict,
> where Almost Strict means that a portion is in Quirks.
be one of three alternatives, Strict, Transitional, and Frameset. Any
variation in the Transitional doctype is either variation across
specifications or nonstandard.
>>> If you write according to HTML4.01 Strict, you can still use <!DOCTYPE
>>> html> right now as a replacement for the Strict doctype,
>>
>> No, you cannot; using <!DOCTYPE html> does not conform to HTML 4.01. You
>> can use <!DOCTYPE html> if you like, independently of the kind of HTML
>> you are actually using, if you want browsers to operate in "standards
>> mode".
>
> Ref> <http://diveintohtml5.info/introduction.html>
When you use <!DOCTYPE html>, you are not writing according to HTML4.01
Strict, simply because it requires a different doctype. It is true that
in simple cases, an HTML 4.01 Strict document becomes an HTML5 document
just by changing the doctype, but this is rather pointless and not an
upgrade in any sense.
> Validation is another matter. A few simple changes will resolve this.
observed when trying to "upgrade to HTML5" (usually for no good reason).
The rather restrictive policy on <meta> tags in HTML5 is perhaps the
most common issue. (Most <meta> tags are write-only noise, but they are
commonly used still.)
> I searched and searched in vain for Ian Hickson's interesting
> description of how he arrived at the final doctype. The final doctype
> was the minimum necessary for the specific purpose of keeping the
> browser out of Quirks Mode (and place it in Standards Mode).
checking how browsers dealt with doctypes, and taking <!doctype html> as
triggering "standards mode" was probably more or less accidental.
Browsers use "standards mode" when a custom doctype is used, like
<!DOCTYPE HTML SYSTEM "http://www.cs.tut.fi/~jkorpela/html/tagsoup.dtd">
and it just happened that browsers don't require the word SYSTEM and the
quoted string. (IE does not even require the string HTML, but Firefox does.)
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Martin Leese
Dec 1, 2012, 11:46:28 AM12/1/12
to
Denis McMahon wrote:
...
wanting to offer video, but that does not
include me.
--
Regards,
Martin Leese
E-mail: ple...@see.Web.for.e-mail.INVALID
Web: http://members.tripod.com/martin_leese/
...
> As far as I'm concerned, when there is a ratified html 5 standard I'll
> start using it, until then, I'm sticking with 4.01.
Me too. Things are different for people
> start using it, until then, I'm sticking with 4.01.
wanting to offer video, but that does not
include me.
--
Regards,
Martin Leese
E-mail: ple...@see.Web.for.e-mail.INVALID
Web: http://members.tripod.com/martin_leese/
Gus Richter
Dec 1, 2012, 2:08:28 PM12/1/12
to
On 12/1/2012 10:55 AM, Jukka K. Korpela wrote:
> 2012-11-30 11:51, Gus Richter wrote:
>
>> [<!DOCTYPE html>]
> > allows you to use and validate new semantic elements like <article>,
>> <section>, <header>, and <footer>.
>
> I can use them with any doctype. In validation, they of course cause
> error messages if you don't use the HTML5 doctype (or a suitable custom
> DTD).
>
>> Obsolete elements are still supported, but won�t validate.
> 2012-11-30 11:51, Gus Richter wrote:
>
>> [<!DOCTYPE html>]
> > allows you to use and validate new semantic elements like <article>,
>> <section>, <header>, and <footer>.
>
> I can use them with any doctype. In validation, they of course cause
> error messages if you don't use the HTML5 doctype (or a suitable custom
> DTD).
>
>
> And this is a problem, if you wish to use them _and_ use a validator.
> Remember that "obsolete" means just "what some version of HTML5 / HTML
> Living Standard declares as obsolete".
I don't see it as a problem. I'm informed that there is a new and better
> And this is a problem, if you wish to use them _and_ use a validator.
> Remember that "obsolete" means just "what some version of HTML5 / HTML
> Living Standard declares as obsolete".
method and hence the old element is obsolete, after exhaustive
discussions by all interested parties, so using the obsoleted element
will not validate because the validator recognized the element to be
obsolete. On the other hand, in order to facilitate backwards
compatibility so that the existing old legacy pages won't break, the
browsers still support the obsoleted element. Sounds good to me.
>>>> Standards mode means that the document will conform to the
>>>> specification
>>>> (Standards) - HTML Living Standard =or= W3C's HTML5,
>>>
>>> No, it is just a browser's mode of operation, based on the assumption
>>> that the document conforms to the "standards". Or, rather, the browser
>>> makes its best attempt at processing the document by the "standards",
>>> except in cases where it willfully deviates from that.
1. The author uses <!DOCTYPE html> and intends therefore to write such
that the document will conform to the HTML5 specification. (Such was my
train of thought above.)
2. The browser notes the doctype and renders the document in the
Standards mode (and as you say, making its best attempt according to the
standards).
>>>> If you write according to HTML4.01 Strict, you can still use <!DOCTYPE
>>>> html> right now as a replacement for the Strict doctype,
>>>
>>> No, you cannot; using <!DOCTYPE html> does not conform to HTML 4.01. You
>>> can use <!DOCTYPE html> if you like, independently of the kind of HTML
>>> you are actually using, if you want browsers to operate in "standards
>>> mode".
>>
>> Ref: <http://diveintohtml5.info/introduction.html>
>
> When you use <!DOCTYPE html>, you are not writing according to HTML4.01
> Strict, simply because it requires a different doctype. It is true that
> in simple cases, an HTML 4.01 Strict document becomes an HTML5 document
> just by changing the doctype, but this is rather pointless and not an
> upgrade in any sense.
>
>> Validation is another matter. A few simple changes will resolve this.
>
> I'm afraid there are many things that need consideration, as people have
> observed when trying to "upgrade to HTML5" (usually for no good reason).
> The rather restrictive policy on <meta> tags in HTML5 is perhaps the
> most common issue. (Most <meta> tags are write-only noise, but they are
> commonly used still.)
Please expand on this. I found nothing much untoward here:
> When you use <!DOCTYPE html>, you are not writing according to HTML4.01
> Strict, simply because it requires a different doctype. It is true that
> in simple cases, an HTML 4.01 Strict document becomes an HTML5 document
> just by changing the doctype, but this is rather pointless and not an
> upgrade in any sense.
>
>> Validation is another matter. A few simple changes will resolve this.
>
> I'm afraid there are many things that need consideration, as people have
> observed when trying to "upgrade to HTML5" (usually for no good reason).
> The rather restrictive policy on <meta> tags in HTML5 is perhaps the
> most common issue. (Most <meta> tags are write-only noise, but they are
> commonly used still.)
<http://dev.w3.org/html5/html4-differences/>
--
Gus
Denis McMahon
Dec 1, 2012, 5:04:28 PM12/1/12
to
On Fri, 30 Nov 2012 13:34:18 -0500, Gus Richter wrote:
> The big thing about HTML5 (as in previous versions) is that it is
> backward compatible and is intended to remain so. If it worked yesterday
> in HTML 4, it will work today in HTML5 and what works today in HTML5
> will work in the future.
That's an interesting assertion, but what do you mean by "backwards
> The big thing about HTML5 (as in previous versions) is that it is
> backward compatible and is intended to remain so. If it worked yesterday
> in HTML 4, it will work today in HTML5 and what works today in HTML5
> will work in the future.
compatible"?
Because the way I see it, there's a whole raft of ways of defining
backwards compatibility.
For example, can I server any html 4.x compliant html using <!DOCTYPE
html> and expect it to work with no problems or quirks?
Because if not, the html standard is /*not*/ backwards compliant, even if
the browsers are backwards compliant in that, given an appropriate
doctype, they are able to display previous versions!
Rgds
Denis McMahon
Jukka K. Korpela
Dec 1, 2012, 5:47:20 PM12/1/12
to
2012-12-02 0:04, Denis McMahon wrote:
> For example, can I [serve] any html 4.x compliant html using <!DOCTYPE
There is really no *guarantee* of this, though. Doctype sniffing is a
real mess, and browser vendors might get fancy ideas about implementing
some "HTML5 mode" where things work differently.
For example, Firefox has switched to an "HTML5 parser", see
https://developer.mozilla.org/en-US/docs/HTML/HTML5/HTML5_Parser
They _could_ have done this so that the parsing mode is selected
according to the doctype. They didn't, but other vendors might think
otherwise.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
> For example, can I [serve] any html 4.x compliant html using <!DOCTYPE
> html> and expect it to work with no problems or quirks?
Yes, just as if you had an HTML 4.01 doctype.
There is really no *guarantee* of this, though. Doctype sniffing is a
real mess, and browser vendors might get fancy ideas about implementing
some "HTML5 mode" where things work differently.
For example, Firefox has switched to an "HTML5 parser", see
https://developer.mozilla.org/en-US/docs/HTML/HTML5/HTML5_Parser
They _could_ have done this so that the parsing mode is selected
according to the doctype. They didn't, but other vendors might think
otherwise.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Gus Richter
Dec 3, 2012, 12:02:49 AM12/3/12
to
On 12/1/2012 5:47 PM, Jukka K. Korpela wrote:
> 2012-12-02 0:04, Denis McMahon wrote:
>
>> For example, can I [serve] any html 4.x compliant html using <!DOCTYPE
>> html> and expect it to work with no problems or quirks?
>
> Yes, just as if you had an HTML 4.01 doctype.
+1 And in support:
> 2012-12-02 0:04, Denis McMahon wrote:
>
>> For example, can I [serve] any html 4.x compliant html using <!DOCTYPE
>> html> and expect it to work with no problems or quirks?
>
> Yes, just as if you had an HTML 4.01 doctype.
Regarding "BAckwards Compatibility":
<http://www.w3.org/TR/html-design-principles/#compatibility>
"This dual nature of the (HTML5) spec allows us to have a relatively
clean and understandable language for authors, while at the same time
supporting existing documents that make use of older or nonstandard
constructs, and enabling better interoperability in error handling."
Likewise in talking about HTML6 "Backward Compatibility":
<http://blog.whatwg.org/html6-plan>
"We firmly believe that new HTML version should maintain backwards
compatibility ..." This shows the commitment for the immediate future at
least.
<!DOCYPE html> can be used today because it works everywhere - the
shortest doctype to trigger every browser to render in Standards Mode.
Don't think of it as the HTML5 doctype because browser engines don't
care about HTML5, HTML4, XHTML1.0, CSS3, ECMASCRIPT 5 since all they
care about is if they support what is being sent or not. Remember that
death and taxes is the only certain thing.
> There is really no *guarantee* of this, though. Doctype sniffing is a
> real mess, and browser vendors might get fancy ideas about implementing
> some "HTML5 mode" where things work differently.
>
> For example, Firefox has switched to an "HTML5 parser", see
> https://developer.mozilla.org/en-US/docs/HTML/HTML5/HTML5_Parser
> They _could_ have done this so that the parsing mode is selected
> according to the doctype. They didn't, but other vendors might think
> otherwise.
Any browser that declares its support of HTML5 must use a Parser that
complies with normative requirement in the HTML specification in which
regard this document informs that since Gecko2 an HTML5 Parser is used
(i.e. since Firefox 4, Thunderbird 3.3, SeaMonkey 2.1).
Any browser that purports to support HTML5 must use an HTML5 Parser. The
line, "In other words, in supporting HTML5, Gecko, WebKit, and Internet
Explorer (IE) will behave more consistently with each other." indicates
to me that Webkit, IE (<http://caniuse.com/#feat=svg-html5> reports that
Inline SVG in HTML5 is supported in IE9+) and now Gecko all use an HTML5
Parser. I'm surprised that Opera is not mentioned - I'm certain that if
Opera does not yet use an HTML5 Parser, it will shortly. So this covers
all the big 5. BTW, Opera renders the below demos perfectly well.
<http://caniuse.com/#cats=HTML5> shows that it is important to check for
support in all browsers, IE8 and IE9 have not much HTML5 support with IE
10 being still the worst of the big 5.
My demo demonstrating mainly inline SVG support in HTML5:
<http://www3.bell.net/monique.richter/Layers_in_HTML5.html>
--
Gus
0 new messages