[whatwg] Re: About XHTML 2.0
mattraymond at earthlink.net
Fri Jun 10 06:50:16 PDT 2005
James Graham wrote:
> Matthew Raymond wrote:
>>>But the point is that HTML does such an
>>>astonishingly poor job of marking up fiction (and a wide variety of
>>>other document types too, no doubt) that arguing over whether
>>>seperators should be empty elements or not is just semantic
>> No, because the extensive use of separators, particularly <hr>, in
>>web pages clearly show that people are accustom to the concept.
>>Therefore, dropping the entire concept of separator elements increases
>>the learning curve and makes the use of CSS a requirement for having
>>separators in the first place.
> Note I expressed no opinion on whether seperators as a concept are good
> or not, only the opinion that arguments over their precise form are
Note that I disagree. Problems with the precise form have plagued a
lot of elements, such as <img>.
> [Ultimately] the absolute worst that can happen, even if an
> author fails to use a semantic seperator and instead uses a graphic or
> somesuch is that people using speech browsers miss out on a two-second
> pause between sections and people using a text only browser fail to see
> "* * *".
Well, probably in XHTML 2.0, but the only way that that would happen
in HTML is if you intentionally used CSS alone for the separator.
Remember that |alt| is required for <img>, so unless the author
intentionally leaves out the "* * *", it will be visible in text-only
browsers, and intelligent aural browsers could interpret the string as a
> Annoying? Yes, a little. Earthshatteringly awful? No, not
> really. Given that the total absence of a seperator is at worst
> irritating, protracted discussion about how best to represent them in
> markup is unnecessary.
Well, actually there's a high potential for confusing readers, and a
dramatic pause is not necessarily communicated by the boundary between
sections. So, as worst, you've compromised the intended meaning of that
portion of the document.
>>>Where are all the
>>>people using AJAX (Worst. Name. Ever.) but going "oh I could do all
>>>this cool stuff if only I had feature X"?
>> Anyone skilled enough to use AJAX is skilled enough to implement
>>most of the features they want using DHTML. That isn't to say that
>>they aren't asking for "cool stuff", as I haven't exactly been polling
>>people on the subject, but it's clear that demand for new markup is
>>less likely to come from those with the skills to implement similar
>>functionality on their own.
> Well, they could hardly implement XMLHttpRequest in DHTML. That's sort
> of thing that makes new applications happen. There must be things that
> people are having to hack around now that have an elegant solution
> (indeed the spec already has a few examples - server sent DOM events,
> canvas, the DOMContentLoaded event (though I can't see that in the spec
> text yet...) and a few others.) Where are the ideas like those?
I believe we've discussed a lot of those ideas right here in the
WHATWG mailing list. Is there a specific area you feel has been neglected?
More information about the whatwg