> This would be an appropriate point if the SGML-parsers weren't lossy in
> this regard.
> I've read lots of HTML-markup and often ran into problems when people
> didn't take care of well-formedness.
> Often, they run into quirks and their Browser's SGML-parser fixes them.
> However, there's no guarantee another Browser would do the same and
> damn, don't ever try to modify the markup later!
> This is not an edge-case. I run into these problems day by day.
I see why you wish for a stricter approach. I don't believe this will
happen anytime soon.
> > That's why HTML uses only a subset of SGML.
>
> The point is that they allow ambiguity.
I'm not sure about that. SGML has DTDs that describe what you're allowed
to do and what not. So in theory browsers could reject non-validating
HTML pages as well. No need to switch to XML for that. But I would doubt
that browsers would do this.
> I really don't see your point why exactly XML should be bad for the
> web.
Not bad for the web. Bad for me! :) I write lots of HTML at work. I tend
to write validating HTML usually - except when encountering features
that can't be described with valid HTML (HTML5 fixes this thou, at least
for me). If I had to write XHTML I would get very angry pretty fast.
> If you write proper, well-formed markup, nothing really changes for
> you, except that the browser _knows_ it's dealing with proper markup
> and doesn't have to "fire up" it's forgiving but sloppy SGML-parser.
As said before, browsers could reject non-validating HTML as well.
So in the end we disagree because of personal preference. That's fine
with me.
--
Eckehard Berns
Received on Fri Feb 21 2014 - 14:40:44 CET