RE: Why authors are using Transitional (and target="_blank")

Sam –

You have not addressed the issue at all. To simplify it: “why is a document specification referring to application level events?” I believe that the HTML spec needs to be de-application-i-fied (wow, I just made up a horrid word there) so that Lynx, printers, search engines, etc. *are* considered full user agents. The fact is, any document which counts on user input or interactivity in order to be displayed correctly is not a "document", it is serialized application state.

So, do we want HTML to be a *document* standard, or do we want it to be an *application state serialization* standard? I believe HTML should be a *document* standard (BTW: I *do* want to see mouse events removed from the HTML spec), not a method of serializing application state. It is the only way to guarantee accessibility to the handicapped, preserve internationalization/globalization possibilities, and allow for innovative ways of consuming HTML. The future of application that creatively work with the data within HTML documents is jeopardized when the documents require user input to have data (or the right data) in the document. I do not want a future where Web browsers being used by humans are the only applications that actually receive the content, as opposed to a meaningless (to a non-human) stream of event handlers that then trigger the transmission of the actual content.

J.Ja

From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Sam Kuper
Sent: Thursday, February 21, 2008 8:17 AM
To: HTMLWG
Subject: Re: Why authors are using Transitional (and target="_blank")

On 21/02/2008, Justin James <j_james@mindspring.com> wrote:
I am curious as to why the HTML 5 spec should even *reference* the concept of "clicking". A user agent is not necessarily a Web browser. What should a search engine spider's behavior be? Or Lynx? Or some third party tool that is trying to properly use the semantic nature of HTML?

HTML specs have referred to clicking since at least as far back as 1995. (See http://ftp.ics.uci.edu/pub/ietf/html/rfc1866.txt and http://www.w3.org/TR/REC-html32 for instance.)

I agree that target="_blank" is the best possible approach; Web authors, for better or worse, need to be able to *request* that a *Web browser* (or similar user agent running in a GUI environment) open a new window, tab, or other such viewing area for the contents of the link. target=_blank is also the most inline with the semantic Web approach; it clearly states its intentions in a declarative manner, as opposed to requiring a JavaScript interpreter, working within a Web browser user agent to execute it and the results to be seen by a human to be understood... that is not "semantic Web", that is something else.

Agreed. 

Any conversation which brings JavaScript into the equation is asking for trouble at the accessibility level, the adoption level, and the non-browser user agent level. The entire *point* of the "semantic Web" concept is for non-human consumers of HTML documents to be able to derive some semblance of meaning from them. Any approach that requires JavaScript, the HTML DOM in general, or user intervention is contrary to the semantic Web concept.

I disagree with what you say about the DOM here. "The Document Object Model is not a way of persisting objects to XML or HTML. Instead of specifying how objects may be represented in XML, the DOM specifies how XML and HTML documents are represented as objects, so that they may be used in object oriented programs." (http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/introduction.html) If I want to parse HTML documents for semantic web purposes (with a perl script, say), I could do worse than use the DOM to obtain some of the functionality I might desire. But this is drifting off-topic.

As such, I believe that *any* requirement or reference in the specification to things like "left click" and "right click" or any other functions *specific* to Web browsers running in a GUI really is not something that needs to be in the HTML spec. Let the folks at Opera, Mozilla, Microsoft, Apple, etc. write that into their project specifications. After all, how should Lynx interpret a spec that demands click-based behavior?

Er... one could equally ask how Lynx ought to interpret the targeting of a window other than the current one.* The point is, Lynx isn't a fully fledged UA. Nor are most spiders. And should we get rid of mouse-based event handling (onclick..., onmouseover, ...) and graphics and frames from the HTML spec too, because Lynx doesn't handle them the way a GUI user agent does? I think not... Anyhow, we're off-topic again.

I know, of course, that extremely few people actually browse the Web using Lynx. But the idea is similar to the thermostat or elevator design principle of C; if Lynx (or Google's spider, or a Perl script) can't do it or make sense of it, there is a good chance that it does not belong in the HTML spec.

See rebuttal above.

Regards,

Sam

Received on Friday, 22 February 2008 19:32:18 UTC