[whatwg] Re: About XHTML 2.0

[Matthew Raymond]

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 
>>>navel-gazing.
>>
>>  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 
> worthless.

    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 
pause.

> 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?