dorayme said:He has one good practical point and that is that you should test your
website in different browsers to see what others will see, you should
also change the text size as you do this and you should change the
browser size - in other words take it for a test run.
But you cannot test your website in browsers that have not been
created. It is almost logically impossible. Nor can you predict
changes to browsers.
Only to a validator. Browers only care whether you have a doctype
or not, and will correspondingly operate either in standards or quirks
mode.
Tim Streater said:...the substance of my point is that despite various
standards bodies insisting that this or that feature of html is
"deprecated", I'm not aware of any feature that has actually been
removed (except perhaps things that were put in ahead of standards and
later removed).
despite various standards bodies insisting that this or that feature of
html is "deprecated", I'm not aware of any feature that has actually
been removed (except perhaps things that were put in ahead of standards
and later removed).
Jukka K. Korpela said:As regards to removing features from specs, e.g. XHTML 1.1 dropped a
large number of features (almost all presentational features), as
compared with XHTML 1.0 and HTML 4.01. It did not become a success, and
this may be related to that move, at least in part.
HTML 4 dropped <xml>, which was flagged as deprecated in HTML 3.2 (and
in HTML 2.0). But browsers have kept supporting it.
So is there features that have been in HTML specifications and have been
implemented but later removed from *browsers*? Not many. The only thing
that comes into my mind is <listing>, but even it is still supported,
but with interpretation essentially different from the original, so one
might say that the *original* <listing> has been dropped. But it has
been used very, very little.
Tim said:And so I rest my case. Remember: there are lots more guys involved in
writing browsers than there are writing validators.
And so I rest my case. Remember: there are lots more guys involved in
writing browsers than there are writing validators.
Tim Streater said:And so I rest my case. Remember: there are lots more guys involved in
writing browsers than there are writing validators.
Christoph Becker said:Tim Streater wrote:
And there are even more guys involved in writing HTML. If these would
not use deprecated features, new browser versions would not have to
support these features anymore (at least sometimes in the future), what
might simplify the codebase of the browsers, so the developers could
focus on more important aspects.
Tim Streater said:The chance of people stopping using deprecated features, and just as
importantly, going back and changing existing sites, is vanishingly
small.
Tim Streater said:And so I rest my case. Remember: there are lots more guys involved in
writing browsers than there are writing validators.
The chance of people stopping using deprecated features, and just as
importantly, going back and changing existing sites, is vanishingly
small.
There was already an attempt to enforce a cleanup: XHTML, which tried to
insist that browsers should not do error correction in the case of badly
formed source, but that instead the browser should just give an error
message saying "bad page" or something. The browser writers ignored
this,
for the same reason that anyone else would: there are billions of
pages already in existence which are full of errors.
Instead, the browser writers figured out how to recover from HTML errors
in a consistent way. AIUI, this is even documented now.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.