Re: Event model for <A> element

On Sat, 12 Jul 1997, Scott Matthewman wrote:

> Because there haven't been any event handlers in the HTML spec before, each
> UA has effectively had to go its own way in terms of defining event
> handlers. What we're all doing in devising the HTML 4.0 spec is saying
> which event handlers a UA should support to comply with the spec.

Otherwise compliant browsers such as Lynx would be excluded.

> Now, in theory UAs could add more event handlers if they wanted to, but as
> a web writer I wouldn't be able to rely on those extra handlers being
> present. However, I *will* be able to bind code to the defined event
> handlers in the knowledge that all HTML 4.0-compliant browsers will be able

What about scripting language? The spec says nothing of this. So if you
hardcode the event-handling code into the various elements (as it is now),
you would make the document scripting-language-dependent. (of course this
defeats the structural principle of HTML)

> to handle them. So if anything, bringing event handlers into the HTML model
> will *prevent* the proliferation of event handlers, IMHO.

CSS1 didn't bring attributes (is that what they're called?) to the HTML
model and there was not a proliferation of HTML attributes. Mainly because
an ideal HTML document should not incorporate any presentation style. Since
scripting/event handling is as media-dependent (e.g. onClick, onBlur) as
presentation style, these should be separated. However, like CSS1, only a
single attribute (e.g. EVENT or SCRIPT) should exist to support cases where
separation of content and presentation is not desired. In addition, nothing
prevents you from using the SCRIPT element to insert event handling code.

--
Steve Cheng
elmert@ipoline.com
http://www.ipoline.com/~elmert/

Received on Saturday, 12 July 1997 16:04:58 UTC