332773 - Drop XLink support

Status: RESOLVED FIXED

(Core :: XML, defect)

Description

[Hixie (not reading bugmail)]

I'd like to propose that we drop XLink support. Our implementation of XLink is incomplete, clashes with SVG, and is not really useful on the Web. It is also redundant with <html:a>, which is usable in the same contexts as Simple XLink (which is all we support) and which is easier to use.

I think removing XLink would save us a tiny amount of download size and would reduce the complexity of our code, as well as making our platform simpler overall. For SVG we can hard-code support for the XLink attributes instead of attempting to have "generic XLink support" in SVG (since it isn't clear how that is supposed to work anyway).

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'm not entierly against this idea, though there are some things in the previous comment that aren't exactly right.

First of all our current xlink implementation does have a bit more features then a normal <html:a>. We additionally support actuate="onload". However the same thing can be accomplished using <script>window.location=...</script>.

Also, with some proper refactoring (which jwatt is currently doing) there is faily little code overhead in the current support. Especially if we drop support for actuate="onload" which i'm all for.

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

> same thing can be accomplished using <script>window.location=...</script>.

that requires javascript to be enabled and is therefore not fully equivalent...

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Ah, true, there is is the meta-refresh though.

Comment 4

[Hixie (not reading bugmail)]

Making our platform simpler is a good thing.

If we don't remove XLink, then IMHO we should at least document what we think "supporting XLink" actually means. The spec sure isn't detailed enough to explain what we do exactly.

Comment 5

[Alex Vincent [:WeirdAl]]

Is there a newsgroup thread for discussing this?  We should probably discuss this in some detail before acting on this; instinctively, I'm uncomfortable, but Hixie's arguments make some sense.

Comment 6

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I thought our XLink support was well defined for vanilla XML and XHTML: we support simple XLinks (http://www.w3.org/TR/xlink/#simple-links). I think the unimplemented part is/was xlink:show="embed" which AFAIK has never really been explained well enough to be unambiguously implementable.

I don't know much about other SVG etc. to say how XLinks would fit or not fit there.

In any case, the XLink support in Mozilla was among my first Mozilla contributions and it does show, so it would be nice if that was at least cleaned up etc.

Hixie, you might also want to take a look at the code that scrolls to an anchor on a page (http://lxr.mozilla.org/seamonkey/ident?i=GoToAnchor). A long, long time ago I added code that selects the link anchor as you traverse to it if a certain pref is set. That could probably be removed pretty safely, and CSS has the target formatting stuff as well nowadays... Btw, that piece of code also handles XPointer and FIXptr. If XLink was removed, those would make no sense.

Comment 7

[Henri Sivonen (:hsivonen)]

It seems that XLink on MathML is already not linkified in Firefox 3 and trunk.

The red letters in http://www.nag.co.uk/numeric/FL/manual/xhtml/C06/c06eaf.xml are all links in Firefox 2. In Firefox 3, only the XHTML links work as links but the XLink links don't.

I don't like XLink, but I think MathML should have *some* linking story.

Comment 8

[Henri Sivonen (:hsivonen)]

One way to address existing MathML content would be treating the href attribute in the MathML namespace specially on MathML elements like the href attribute in the MathML namespace is treated specially on SVG elements.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment 7 is basically running into bug 211916. We only support xlink on "generic" XML elements, and we stopped treating MathML as generic in Firefox 3.  This should be filed as a separate bug, since as you point out it's a regression for MathML that laves it with no linking story.

Comment 10

[Henri Sivonen (:hsivonen)]

Oops s/MathML namespace/XLink namespace/ in comment 8.

Filed bug 448526.

Comment 11

[Henri Sivonen (:hsivonen)]

We discussed the HTML5 tree builder integration layer today and identified XLink autolink handling as something that should be removed from both XML and HTML5 tree building.

For legacy reasons, MathML and SVG nodes need to do stuff with attributes named href in the XLink namespace, but XLink support in general should go away.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Isn't this done now?  I see nothing obvious supporting generic xlink anymore...

Comment 13

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase

This shows a link in 3.5 and 3.6, but not on trunk.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Testcase says this is fixed.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Ah, this was fixed in bug 516906.