Bug 6464 – Unclickable cite reference

• Component: CSS
• Status: NEW

[David Latapie]

cite attibute, albeit perfectly valid, is not supported by browsers.
- A common workaround is CSS autogeneration: http://www.holovaty.com/blog/archive/
2002/12/20/0454
- But the end result is not clickable. Second workaround: it is possible to make it clickable with a special 
Opera XML rule (but it would only work with Opera, neither Mozilla nor WebCore).
- Third workaround: duplicating information with a sentence explicitely stating where a quotation comes 
from, at the cost of losing some semantics.

For the reason of these three workarounds, I assign a P3 severity status instead of P2.
Some additionnal informations in French: http://blog.empyree.org/?282-des-cite-et-des-sites

[David Latapie]

(In reply to comment #0)
a sort of testcase : http://blog.empyree.org/?873-flash-pour-ceux-qui-n-ont-rien-dire

[Michael J. Cohen]

occurs for me on r11976

[Joost de Valk (AlthA)]

Created attachment 5598 [details]
testcase

[Joost de Valk (AlthA)]

added a testcase showing that this is indeed not clickable. But since it's not intended to as far as the spec 
is concerned ( http://www.w3.org/TR/html4/struct/text.html#h-9.2.1 ), i'm closing this as invalid. Neither 
FireFox or IE/Win make this a clickable link whatsoever. Maybe Ian Hickson can shed some light on what 
it's supposed to do :)

[David Latapie]

(In reply to comment #4)
> added a testcase showing that this is indeed not clickable. But since it's not intended to as far as the 
spec 
> is concerned ( http://www.w3.org/TR/html4/struct/text.html#h-9.2.1 ), i'm closing this as invalid. 
Neither 
> FireFox or IE/Win make this a clickable link whatsoever. Maybe Ian Hickson can shed some light on 
what 
> it's supposed to do :)

It is not supposed to be clickable, according to the specs. That is why I referenced the CSS trick as a 
*workaround*. The basic problem is that browser do not offer any way to go (or even to display) the 
value of the cite attribute). Hence the Opera workaround, by inserting a bit of xml.

The bug is still OK: the first line is the bug ("cite attibute, albeit perfectly valid, is not supported by 
browsers.")
The rest is imperfects worlarounds.

I reopen the bug, please tell me if I should not do this.

[Alexey Proskuryakov]

I would say: please open a new bug, asking for cite attribute support, ideally providing a testcase for it. 
This bug can be referenced for additional info on workarounds.

[Alexey Proskuryakov]

Sorry, please disregard my previous comment.

[Alexey Proskuryakov]

Created attachment 5601 [details]
cite in blockquote testcase

Do I understand it right that you are suggesting that the cite attribute should
be rendered somehow, although no other browser does this? If so, do you have a
suggestion about how it should be rendered (link? tooltip?), so that
compatibility wouldn't be broken?

Was this ever discussed before (perhaps, even in Mozilla bugzilla)? I guess, it
should have been.

[David Latapie]

Hi,

Well

1. making blockquote cite visible is all too easy
http://www.holovaty.com/blog/archive/2002/12/20/0454/

2. making them selectable is native with Opera, which is able to select auto-generated content

3. making it clickable is possible with a minor xml rule Opera provides

q[cite], blockquote[cite] {
	-o-link: attr(cite);
	-o-link-source:current;
	cursor: pointer
}

I systematicaly use blockquote cite instead of a non-semantic dedicated paragraph.  Alexey, do I answer your question?

[Alexey Proskuryakov]

Thank you!

Putting aside the general problem of non-selectable generated content, which is not specific to citations in any way, I see two issues here:
1) No built-in rendering for cite attribute. Firefox provides access to this attribute via a properties item in its context menu; Opera, Safari and WinIE don't seem to provide any access at all.
2) No support for Opera-only attributes "-o-link" and "-o-link-source".

I'm confirming this bug (and changing severity to enchancement), although it will need to be separated in two if both these features are deemed necessary in WebKit.

See also:
https://bugzilla.mozilla.org/show_bug.cgi?id=1995
https://bugzilla.mozilla.org/show_bug.cgi?id=3662

[Alexey Proskuryakov]

Created attachment 5834 [details]
-o-link test case

[David Latapie]

Hi,

You seem to be more knowledgeable than me on this topic. Could I ask you to report the two bugs? Or maybe just the first one, as I don't think Firefox should handle any proprietary feature

BTW the description of these features is here <http://www.opera.com/docs/specs/>

[Alexey Proskuryakov]

Me, knowledgeable? :)
I've even misnamed those CSS properties as attributes, sorry for that.

[Alexey Proskuryakov]

See also: <http://annevankesteren.nl/2006/01/cite>.

[David Latapie]

Reacted: http://annevankesteren.nl/2006/01/cite#comment-5148

[Nicholas Shanks]

I suggest making elements with a cite attribute (where that cite attribute is a URL) produce a contextual menu items such as ‘Open Citataion in Current Tab’ and ‘Open Citataion in New Tab’.
When the mouse is hovering over a <q> or <b.q.> element, change the cursor to an arrow with menu beside it.
You may also want to add a default style to html4.css for q[cite] and b.q.[cite]

[David Latapie]

(In reply to comment #10)
> Putting aside the general problem of non-selectable generated content, which is
> not specific to citations in any way, I see two issues here:
> 1) No built-in rendering for cite attribute. Firefox provides access to this
> attribute via a properties item in its context menu; Opera, Safari and WinIE
> don't seem to provide any access at all.
> 2) No support for Opera-only attributes "-o-link" and "-o-link-source".
> 
> I'm confirming this bug (and changing severity to enchancement), although it
> will need to be separated in two if both these features are deemed necessary in
> WebKit.
> 
> See also:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1995
> https://bugzilla.mozilla.org/show_bug.cgi?id=3662
> 

I have some new information related to the Opera technology; they are not using their own technology, but rather implemtenting a Y2K proposal called CLINK. You can check on Håkon’s very interesting (and legible) PHD: http://people.opera.com/howcome/2006/phd/#h-349

(In reply to comment #16)
> I suggest making elements with a cite attribute (where that cite attribute is a
> URL) produce a contextual menu items such as ‘Open Citation in Current Tab’
> and ‘Open Citation in New Tab’.
> When the mouse is hovering over a <q> or <b.q.> element, change the cursor to
> an arrow with menu beside it.
> You may also want to add a default style to html4.css for q[cite] and
> b.q.[cite]
> 

I have to say I don't really like the Opera solution: they allow one link to be in another (a blockquote  with a set cite attribute may still have another link inside, like <blockquote cite="foo.html">this is a <a href="bar.html">link</a></blockquote>. If you click on "link", you'll go to bar.html. If you click anywhere else on the blockquote, you will go at foo.html).

In my humble opinion, this is both overkill and a bad idea. What we really want is to have a "source" link at the bottom of the quote; to make the whole quote clickable is confusing.

The contextual menu idea is suboptimal, once again, IMHO (BTW, a contextual menu is available with Opera too). According to the principle of least surprise, the best appears to me to be a "generated area" (:after for the name, like content:"Click for the source"). Would we have to emulate the link behaviour (:hover {cursor:pointer}, text-decoration:underline…) or would it come free, the area being natively considered as a link? I favour the second way as more elegant, but I have no idea whether or not this is hard to do.

I'm not sure I'm clear, please ask for any clarification (BTW, a preview feature would be great).