- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Fri, 10 Jun 2005 09:50:16 -0400
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?
Received on Friday, 10 June 2005 06:50:16 UTC