Closed Bug 294570 Opened 20 years ago Closed 19 years ago

link elements in the head section do not support intrinsic events like onclick

Categories

(Core :: DOM: Events, enhancement)

Product:
Core
Component:
DOM: Events
Platform:
x86
Windows XP
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: daniel.appelt, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Link elements in the head section of a html document which are exposed to the
user through the Firefox user interface currently do not support intrinsic
events like onclick. These attributes are part of the HTML 4.01 Recommendation
as shown here

http://www.w3.org/TR/html4/struct/links.html#h-12.3

and should therefore be supported in case that such a link is accessible through
the user interface. This includes links to stylesheets and rss feeds.


Reproducible: Always

Steps to Reproduce:
1.) One of the possible applications is to add onclick attributes to stylesheet
links in order to set a cookie to remember the user's selected stylesheet:

<link rel="stylesheet" type="text/css" title="design1" href="design1.css"
onclick="document.cookie='style=design1;'" />
<link rel="alternate stylesheet" type="text/css" title="design2"
href="design2.css" onclick="document.cookie='style=design2;'" />

2.) These stylesheet alternatives are exposed to the user through the "View" ->
"Use Style" Menu. A click on one of the menu entries does not affect the
document.cookie variable that is the event handler in general does not seem to
be executed.
Actual Results:  
document.cookie is not changed.

Expected Results:  
document.cookie is either equal to "style=design1" or "style=design2" depending
on the style menu entry which gets clicked.

Also happens with the latest trunk build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050517
Firefox/1.0+
There appears to be no suggestion of what should happen with events on links in
html 4, but in xhtml 1.1 the event attributes no longer exist on the link
element. Personally I would say that events only apply in the browser, not on
any UI elements that may be derived from the html, there is certainly no example
I can think of where this already happens.

The events defined in
http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-events-1.mod are included in
the XHTML 1.1 driver and therefore also part of the link element in this DTD.
True, my mistake. The second part of my comment still applies though.

Out of interest, does any other browser do this?
Concerning support in other browsers:

Mozilla, Opera 8, Konqueror 3.3.2 - no support (at least for stylesheet links)
Internet Explorer does not expose such links to the user front-end.

As elements of the head section are not considered to be part of the document's
content it is up to the user agent to decide which elements of the head section
to render and how to render them. In the case that they are rendered I think the
intended behaviour should be to support all defined attributes for those
elements. Otherwise the definition of these attributes would be useless.


Concerning the given example:

A work-around to save the user's selected stylesheet in a cookie can be achieved
using the body element's onunload event. One can look up the stylesheet link
which is not disabled in this event's handler and save this information in a cookie.

Nonetheless there are still examples where the intrinsic events on link elements
can be useful. The stylesheet switcher described in
http://www.alistapart.com/articles/bodyswitchers/ for example.
The main intention is to define different styles in one single stylesheet and to
switch styles by changing the class attribute of the body element. One advantage
of this technique is instant access to all styles as they are all defined in a
single file. To make this styleswitcher available to the user one would
intuitively define something like the following stylesheet links:

<link rel="stylesheet" type="text/css" title="design1" href="design.css"
onclick="document.body.className='design1'" />
<link rel="alternate stylesheet" type="text/css" title="design2"
href="design.css" onclick="document.body.className='design2'" />
Assignee: nobody → events
Component: General → DOM: Events
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
By far, the biggest problem here is how to implement this securely.  There is no
way that this would directly control the onclick of the menu, other than to
dispatch a synthetic click event to the element, but the value of this approach is
questionable since most browsers simply don't support this, and its not an
obvious answer to the spec, nor a required one that I can make out.

The better goal is to make this selection persist in the browser without need for
cookies, but the how has yet to be established, and won't be for Firefox 1.5.
This is invalid.  If you actually render the link in-page (by setting head and
the link to not have display:none), click events on it work fine.  What's shown
in the browser UI is just metadata gleaned from the <link> elements; that's not
the <link> elements rendering.

Put another way, should clicking the title bar fire a click event on the <title>
element?  No, for the same reasons.

Ian, care to verify?  And possibly clarify in HTML5?
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
(In reply to comment #6)
> This is invalid.  If you actually render the link in-page (by setting head and
> the link to not have display:none), click events on it work fine.

Could you provide an example html page for this. I can not reproduce this
behaviour. Link elements are empty elements. What should be rendered in this case?

>  What's shown
> in the browser UI is just metadata gleaned from the <link> elements; that's not
> the <link> elements rendering.

But it is still a rendering of the element.

> Put another way, should clicking the title bar fire a click event on the <title>
> element?  No, for the same reasons.

No, the title element has no associated event handler attributes according to
the recommendation...
> Could you provide an example html page for this.

http://web.mit.edu/bzbarsky/www/  -- switch to "Debug style".

> Link elements are empty elements.

They can have children in an XML document, and they can have generated content
in HTML, as the page above demonstrates.

> But it is still a rendering of the element.

Not really.  It's a presentation of information gleaned from the element.

> the title element has no associated event handler attributes

But you can add event handlers to it via DOM2 Events addEventListener.  The
event handler attributes thing is really just another way to implicitly call
addEventListener.
(In reply to comment #8)
> > Could you provide an example html page for this.
> 
> http://web.mit.edu/bzbarsky/www/  -- switch to "Debug style".
> 
> > Link elements are empty elements.
> 
> They can have children in an XML document, and they can have generated content
> in HTML, as the page above demonstrates.

I do not believe that you can build an XML document which has content inside a
title element and which validates against any of the W3C's XHTML DTDs or XML
Schema definitions for XHTML. I only saw it being defined with empty content
everywhere I looked.

On the other hand your example is very nice. I did not know that one could
render any element in the head section as part of the normal rendering canvas
using an appropriate value for the CSS display property and CSS generated
content where necessary - reconsidering it, this seems to be the most reasonable
behaviour.
A nice possibility that I will investigate further.
Unfortunately the recommendations do not define any default behaviour when
activating any of the head section's elements other than through event handlers.
Thinking about it I would now consider it rather an essential feature to trigger
an appropriate action when clicking on a link element which is rendered in such
a way ;-)
Clicking on a stylesheet link for example could switch to the associated
stylesheet exactly as it happens when using the analogous menu entry.

> > But it is still a rendering of the element.
> 
> Not really.  It's a presentation of information gleaned from the element.

Quoting the HTML 4.01 Recommendation:

Although LINK has no
content, it conveys relationship information that may be rendered by user agents
in a
variety of ways (e.g., a tool-bar with a drop-down menu of links).

> > the title element has no associated event handler attributes
> 
> But you can add event handlers to it via DOM2 Events addEventListener.  The
> event handler attributes thing is really just another way to implicitly call
> addEventListener.

Okay. In this case the event should be triggered if we would play strict by the
rules. From the user's stand-point it would not make much sense anyhow as nobody
would expect an interaction when clicking on (the document's title in) the title
bar other than that defined by the underlying operating system.
For the onclick event on link elements which link to stylesheets or rss feeds
this is different as these elements are actually rendered in the Firefox UI to
be clicked on by the user...
(In reply to comment #9)
> I do not believe that you can build an XML document which has content inside a
> title element and which validates against any of the W3C's XHTML DTDs or XML
> Schema definitions for XHTML. I only saw it being defined with empty content
> everywhere I looked.

I rather meant the link element in this case...
bz is right; the HTML5 spec will probably clarify it.
Clarified.
You need to log in before you can comment on or make changes to this bug.