If you have a some sort of an external process (a link manager, for example) that can traverse your document structure and mark elements to be links, there is no way to indicate this to the user. CSS allows you to say: :link { /* some style*/ } but depending on the interpretation of the CSS2 spec that could mean elements that are defined as links in the DTD (for example A in HTML 4.0) or it could be that as long as the system recognizes that something is a link the above should format it. I marked this as an enhancement, but depending on the interpretation of the CSS2 spec this might actually be a bug. Sample: <?xml version="1.0"?> <!DOCTYPE sample > <sample> <title>Here is title</title> <para>This is a normal para.</para> <para>Somehow the system has determined that this para is a link. If you click here it will take you somewhere. But there is no way to inform the user that this para is somehow different from the other paras.</para> <para>And here is again a normal para.</para> </sample>

I would interpret the spec liberally and thus let the :link and :visited pesudo- classes apply to any element which will act as a link. This fails to cope for the situation where the link spans multiple elements or only a subsection of an element -- maybe the :link/:visited pseudos should be able to become pseudo- elements as well as pesudo-classes, depending on the situation. Hmm. Maybe this should be brought up in www-style... Peter - how does layout currently decide what is and what is not a link? How does the style system decide what :link/:visited pseudos apply to?

I suspect layout does not know about links at all, except maybe HTML A links. You can use CSS rules to make any element appear as a link (mouse cursor changes etc.) although nothing would happen if you clicked on it. The behaviour of the link happens in nsXMLElement (if I remember correctly, for XML) where the class has a data member mIsLink. It is set in SetAttribute method. In onMouseOver and onLeftClick events that member is checked and if it is true then the system tries to do the link processing. Style system has nothing to do with the behaviour. To fix this "bug" the style system would need information from somewhere else, like the nsXMLElement class or link manager in a more general sense, to be able to react correctly to :link style.

I'm tentatively marking this as a {css1} bug, to aid tracking.

Peter: here is something else for you to think about... Generated content on the <link> element should act as a link. See bug 2800. Hence the :link and :visited pseudo classes should also apply to <link>, and the following should work: head { display: block; } link { display: list-item; } link:link:after { content: attr(title); } link:visited:after { content: attr(title) ' [visited]'; } link[rel=~stylesheet] { display: none; } link[rel=~alternate]:before { content: 'Alternate: '; } link[rel=prev]:before { content: 'Previous page: '; } link[rel=next]:before { content: 'Next page: '; } link[rev=next]:before { content: 'Previous page: '; } link[rev=prev]:before { content: 'Next page: '; } link[rel=index]:before { content: 'Index: '; } I'll write an evil test for this soon...

Note - all XLinks should also act as links and be recognised as :link and :visited elements. So, for example, the following CSS snippet: author:link { color: lime } ...used with the following XML snippet: <author xml:link="simple" show="replace" href="http://www.mozilla.org/"> Written by Mozilla! </author> ...should make the 'Written by Mozilla!' text green.

Pushing off non-beta 1 issues

Reassigning peterl's bugs to myself.

Accepting peterl's bugs that have a Target Milestone

Note: There are some rather vague issues here, but this is also the only bug open on the fact that :link does not match simple XLinks. That is a clear, simple, bug.

See also bug 15086, tracking XLink support.

The AREA element in HTML is also a link and should act as such if it has generated content or is otherwise visible. In summary, we need a link manager and the following should be considered links: XLinks (very important!) html:a html:link html:area Other elements as decided by some other process.

Pushing my M15 bugs to M16

Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz} radars should now be considered deprecated in favour of keywords. I am *really* sorry about the spam...

Pushing again: M18. Reassigned to attinasi. Marc, you can start with the comment from [David Baron 1999-11-02] and [Ian Hickson 1999-11-18], then make sure XLinks work (I think they do: Nisheeth worked on it lately) and verify that the sample code from [Ian Hickson 1999-06-22] works correctly.

This bug has been marked "future" because we have determined that it is not critical for netscape 6.0. If you feel this is an error, or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.

Whoa! We definitely need the html:link and html:area elements to be considered links by FCS. We can style them now, so if they appear in unexpected positions (such as display:block with generated content for the LINK element) then they must act as links if we are to comply with HTML4 and CSS1. Removing Future milestone. It's ok, as far as I am concerned, for the "link manager" stuff to be delayed till a Future release, but for FCS, LINK and AREA _must_ act as links and match :link and :visited.

Ian, I'm mightily confused here... From my limited understanding, the html:link element is in the HEAD and has no representation in the page, so what is the point in trying to style it? If we were to display them in the menu or toolbar or something then I could imagine the desire to style it, although the chrome would probably want to apply its own style to make it look like the rest of the chrome. As for the html:area element, I understand them to be used in image maps to define the link associated with an are in an image. Since there is no text to present for the link represented by an AREA element styling it does not make any sense. Please help me to understand this better if I am wrong. I'll admit right here that I have almost no familiarity with the html:link or the html:area elements, and all of my knowledge of them is from the HTML 4.01 spec. Detecting the link and area elements is not a big deal (just like the XLink detection, easy and safe) but it still does not seem to me to be relevant. I'll go out on a limb and attach a testcase I created using the HTML:LINK and HTML:AREA elements, snagged from the HTML 4.01 spec... maybe I'm using them wrong?

After re-reading Ian's comments I think I understand his concerns - I had neglected to consider the possibility of generated content... It is easy enough to consider LINK and AREA element's links, so I propose introducing a new method in nsCSSStyleSheet.cpp that determines if an element is a link. That method can do the anchor and xlink tests that are currently handled, and can also check for html:link and html:area elements. This is an easy change, and later when a more sophisticated method of link detection is in place the method can be re-implemented to take that into account.

Woohoo! :-D

I've attached a patch that introduces a new routine to nsCSSStyleSheet.cpp that tests whether an element is a valid link and if so returnes a canonicalized HREF value to use in link state management. This also causes AREA and LINK to be treated as links. I tested it with Ian's super-duper evil test: http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/link2.html The LINK'd document have visible 'buttons' that are styled as links, however clicking on them does nothing :( I'm looking for a test for the AREA element now...

nominating nsbeta2 for css1 compliance, and because the patch is ready and is pretty straight-forward and low-risk.

Putting on [nsbeta2+] radar for beta2 fix.

Fix checked in: nsCSSStyleSheet.cpp We now resolve Xlinks, <A>, <AREA>, and <LINK> as link-pseudos (and we check for valid HREF attributes on the HTML elements). If there is still a desire for an external link processor can we open a new bug on that?

I am ok with how things are now (dunno when I'll have time to verify though, someone else could do that...) There are a couple of shortcomings still, but they cannot be resolved yet: 1. ID/IDREF XML link. Our parser does not recognize ID/IDREF/IDREFS attribute types, so we cannot do this yet. ID/IDREF link was also Futured (bug 32833). If/when that bug gets fixed we can think about styling those kinds of links. 2. Out-of-line links (link manager stuff). We don't even have a bug for out-of-line XLinks. If/when it gets implemented, we can think about styling those kinds of links.

Need testcase to verify. py8ieh? Any luck with those yet? (Going by Status Whiteboard comments...)

Ok, test case is at: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/linktests.html I've VERIFIED that this works on Windows NT, using Mozilla Win32 night build 2000062920. However, it exposes three more bugs: * Hovering over a LINK element does not cause the URI to be shown in the status bar. * Clicking on generated content of a LINK element does not cause an event to be bubbled to the LINK (so clicking on LINK:before text does not cause the LINK element to match the :active pseudo-class) * Clicking on a LINK element does not lead to its target like clicking an A element. These are all collectively known as "The LINK element is not a LINK!", which is now filed as bug 44396 against the Layout component.