GNOME.org
 

Re: [wgo] XHTML1.0 Strict vs HTML 4.01

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thilo Pfennig wrote:
> At some point HTML4 will not be supported by browsers any more. That
> might be far away, but another standard that does exist and may be
> soon (1-2 years) be much better than HTML4. 
But the webpage is to be viewed in the next couple of months.

> We then will not have to go through a conversion process which would
> sure be painful. HTML4 is a dead end that will for some more years
> but has many disadvantages (parsing, no xml compatibility) that will
> be more and more visibile. 
Actually, the conversion from good HTML to XHTML is painless and
automatic (ex. Take a look at HTML tidy).  Even doing it by hand would
be no more than switching a the first two lines (DOCTYPE and <html>
namespace) and replacing a few self-closing elements.

> To convert from HTML4 to XHTML could take weeks or months, because
> there is no easy conversion. We would have to make a HTML that is
> quasi XHTML (more than strict).>
I believe that I've already killed this argument thoroughly...  I'll
even give more specific links:
* http://tidy.sourceforge.net/
* http://tidy.sourceforge.net/docs/quickref.html#output-xhtml
Obviously, we would write our HTML to be well-formed, have lowercase
tags, etc.  to even better facilitate the process.  What's wrong with a
little bit of strictness to help the move to XHTML?

> In my experience if you try that only leeds to complications and is
> very time consuming (to cancel the last 2% of bugs from 98%). It is
> much better to farsighted and advance in some aspects, so you can
> concentrate on other things in some years. The CMS is taking a lot of
> ressources now and I think it should not do so in the future.
First, what bugs/complications?  Assuming that we write "more than
strict" HTML (and tidy can even correct worse/invalid stuff), this isn't
a problem.

> The only argument that I've seen from you is that sending XHTML as
> text/html would be necessary (not having IE to ignore the pages) but
> not following the recommendations. I have not seen one fact to which
> problems using XHTML that is not interpreted 100% as this would lead.
> The only thing I have found is that you can NOT assume UTF-8 as the
> default and have to set it in the page, which is anyway a good idea.
I'm arguing that it simply isn't XHTML in the first place, and
therefore, there isn't any reason to use send XHTML as HTML.  There's no
reason not to use HTML, which you've agreed is the best choice for
today.  Due to the ease of conversion, we can always use the best
standard for the time.

> So from my part i think we can close this thread as no new arguments
> are exchanged.
The only argument that I've seen from you is that HTML is the best
choice for now, but it won't be the best choice in a few years (and
conversion would be "painful").  Now that I've suggested a utility to do
it (not to mention that I'd be glad to do the conversion personally),
there's no reason not to use the best language for the next few years.
Although I appreciate the attempt to reintroduce a newer argument, this
isn't enough to kill HTML as the best choice for now.

Once again, the position of "XHTML works fine" is taken.  Why are we so
narrow-minded as to overlook the fact that HTML works fine *AND* is
well-supported/parsed correctly?

Thanks,
Ricky
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFehQTiXbZ7NjlUcARAlg+AJ9OR1bgre19w3z3wV8jzFII0h0HRQCfZmGB
Cjdtu06v/WbhHvkJoqRcfTE=
=yrAy
-----END PGP SIGNATURE-----
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]