Nested XLinks don't work consistently

NEW
Unassigned

Status

()

17 years ago
9 years ago

People

(Reporter: rubydoo123, Unassigned)

Tracking

({testcase})

Trunk
Future
x86
All
testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(5 attachments, 1 obsolete attachment)

(Reporter)

Description

17 years ago
The above mentioned nested xlink test displays an error in mozilla processing. 
If you hover over the links, the displayed target in the status bar all point to 
the a.xml document. If you left-click on each link, the resulting target for all 
links is a.xml. If you context menu select each target, they all go to the 
correct locations : a=a.xml, b=b.xml, c=c.xml

I will attach all of the related files with this test case, just in case it gets 
removed from the site.
(Reporter)

Comment 1

17 years ago
Created attachment 58417 [details]
the xml test file : nested_xlink.xml

This is the xml test case, the three css files that I am attaching are
associated with this file. If you copy everything to your system, you will need
to adjust the paths for the css files.
(Reporter)

Comment 2

17 years ago
Created attachment 58423 [details]
one of three css files : abc.css

This is one of three css files mentioned in the test file : abc.css
(Reporter)

Comment 3

17 years ago
Created attachment 58424 [details]
two of three css files : xhtml2.css

This is the second fo three css files mentioned in the test file
(Reporter)

Comment 4

17 years ago
Created attachment 58425 [details]
three of three css files : xhtml-default.css

This is the third and final css file mentioned in the test file
The left-click (and hover but that is only because XML Base has not been used)
behaviour is the correct one. XLinks don't nest; the outermost link is the only
link there is.
(Reporter)

Comment 6

17 years ago
I contacted the HTML WG W3C rep, and this was his response to the not able to 
nest xlinks comment:

That is NOT true.  Unfortunately this is not obvious from the XLink REC,
but resolution of XLink issue #25 [1] says:

    Resolution:

    Allow nested links, add non-normative examples to make sure
    implementors don't miss the point.

though, it seems editors forgot to add appropriate examples :-(

A good example is SVG, SVG's `a' element uses simple XLink [2] and
it can be nested.  Existing SVG implementations, such as Adobe's
SVG Viewer, do behave correctly with those nested links.

[1] http://www.w3.org/XML/2000/12/LinkingIssueList.html#XL25
[2] http://www.w3.org/TR/SVG/linking.html#Links

Regards,
-- 
Masayasu
W3C - World Wide Web Consortium
*goes back to check the REC* You are right, I misread the REC. The REC states:
"If a simple-type element contains nested XLink elements, such contained
elements have no XLink-specified relationship to the parent link." I read that
carelessly to read no nested links. Sorry about the confusion.

Changing summary to "Nested XLinks don't work consistently".
Summary: Links navigate to incorrect location using xlink → Nested XLinks don't work consistently
Target Milestone: --- → Future
QA Contact: petersen → ian

Comment 8

15 years ago
Created attachment 152342 [details]
Attachment 58417 [details] updated to use CSS files also hosted as attachments to this bug
Attachment #58417 - Attachment is obsolete: true

Comment 9

15 years ago
Also reproduced using FF 0.9.1 on Win XP; setting OS=All.
Keywords: testcase
OS: Windows 98 → All

Comment 10

14 years ago
Created attachment 174285 [details]
testcase (nested xhtml:a links)

The behavior of nexted XLinks should eventually be similar to nested xhtml:a
links. I do not think we want to special-case either.

Updated

14 years ago
Blocks: 61664
Assignee: hjtoi-bugzilla → xml
QA Contact: ian → ashshbhatt
Should eventually be fixed by bug 211916.
Actually this seems to have been fixed on trunk by something else. I don't know by what, or when it happened. It's completely fixed in SeaMonkey trunk, and the only reason it's not fixed in Firefox trunk is because of a hack that bug 325652 exists to back out. The backout may actually take place in bug 331959.

I don't have time to investigate myself, but if someone else does, I'd be very interested to know what fixed this.
*** Bug 297558 has been marked as a duplicate of this bug. ***
Assignee: xml → nobody
QA Contact: ashshbhatt → xml
You need to log in before you can comment on or make changes to this bug.