|
|
Posted by Bone Ur on 11/06/07 10:06
Well bust mah britches and call me cheeky, on Tue, 06 Nov 2007 09:45:27
GMT David Dorward scribed:
>> Well, I didn't know some of that, particularly that XML can be parsed
>> without accessing a dtd. But xhtml "needs" a dtd, or is it just
>> because of the compatibility issues with appendix c et al?
>
> The spec requires that XHTML documents have a Doctype.
>
> Not having a Doctype triggers Quirks mode in many browsers.
>
> Appendix C has nothing to do with this.
>
>> And if in the context
>> of what you said there's a meaningful difference between XML and
>> xhtml, the logical question is can SGML (not html) be parsed without
>> a dtd also?
>
> When I said 'XML', I meant "a given dialect of XML".
>
> Given a dialect of SGML, and no DTD, it isn't possible to know which
> elements have optional start tags, which have optional end tags, and
> which have forbidden end tags. If we use HTML for example:
>
> <title>foo</title>
> <p>Hello, world
> <div>Goodbye, world</div>
>
> Without knowing HTML (via a DTD or otherwise), the parser has no way
> to know that it needs to insert an HTML, HEAD and BODY elements, or
> that the P element should end before the DIV and not after it.
Excepting the situation with the <p> element, don't xhtml parsers have
the same problem? Or is that "built in" whereas it isn't with sgml
parsers?
>> Anyway, I'm still not impressed. What's wrong with making <img
>> src="my.png">Look at me.</img> the "right way to do it" and getting
>> rid of the stupid "alt" attribute?
>
> It would be nice, and HTML 4.01 has:
>
> <object type="image/png" src="my.png">Look at me.</object>
>
> ... but browser support is weak.
>
> <img> is legacy from HTML 3.2 and earlier.
Uh huh, and I think "my idea" came from some recommendation (from
somewhere) to use the <object> element for images. But as you suggest,
browser support is pitiful. However, (jumping ahead a little,) I think
this is one thing that could be fixed without too much "upsetting the
apple cart".
>> that's for sure, and if compatibility is the issue which is
>> inhibiting innovation, the solution is obviously to go another way.
>> Well, it's obvious to me.
>
> The problem with abandoning everything we have already is that you
> have to get browser vendors to support the new thing (nobody is using
> it, where's the demand?) and authors to use the new thing (the old
> thing does what I want, and nothing supports the new thing).
Which is why, in effect, browser vendors control the markup. I suppose
I've been a little hard on the w3c for they _are_ "fighting city hall" in
an ironic way, but it's just so flabbergasting that it seems to take eons
to fix these things. Anyway, I'm out of ideas so thanks for your input.
Perhaps you've tempered my frustration just a bit. :)
> Which is
> why XHTML 2 is likely to fail on the web.
Agreed.
--
Bone Ur
Cavemen have formidable pheromones.
Navigation:
[Reply to this message]
|