39598 - Implement show="embed" for simple XLink

Status: RESOLVED WONTFIX

(Core :: XML, defect, P3)

Description

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

Currently default action is to ignore this if actuate="onLoad". Manual click 
will treat this as show="replace".

Comment 1

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

Adding [NEED INFO] status. I would like to get some opinions (or hard facts if 
possible) on how to treat the embed links.

Specifically: how should embedded content be styled?

a) Should the content keep the style it had at the original place?
b) Should the content get style completely from the parent that embeds it?
c) a) and b), i.e. should the content get the style from the original place but 
let the embedidng parent override (cascade) its style?

I am thinking that if the parent element is styled as display:inline, then the 
linked content should be styled as inline as well, regardless of what the actual 
content style says. Likewise, if the parent element style says display block it 
should override the content display property.

Another problem: I am thinking the content should replace what shows in place of 
the linking element. The link would not change the DOM, it would act pretty much 
like the styles :before and :after, except it would be something like 
:replace-content. Opinions on that?

I would also need some implementation advice on where to start. Layout folks?

Comment 2

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

This bug has been marked "future" because the original netscape engineer
working on this is over-burdened. If you feel this is an error, that you or
another known resource will be working on this bug,or if it blocks your work in
some way -- please attach your concern to the bug for reconsideration.

Comment 3

[Brad Marshall]

As a scientific user, I think that if we can use show="embed" to integrate data,
it would really allow the integration of data over the web to begin in earnest.
 This is the one feature that I would really like to see show up soon in
mozilla.  Unfortunately it doesn't look like this will happen for Netscape 6,
eh?  Damn, I should have spoken up earlier...

Brad Marshall
[e-mail]
bioxml.org

Comment 4

[Paul Gartside]

I'd just like to add my encouragement that xlink embedding be implemented, real
soon! Aggregating data using xlink will be a big big step forward.

Comment 5

[Chris Petersen]

XLINK related. Changing QA contact to [e-mail]

Comment 6

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

*** Bug 92971 has been marked as a duplicate of this bug. ***

Comment 7

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

*** Bug 79576 has been marked as a duplicate of this bug. ***

Comment 8

[Lachlan]

I'd like to urge that this bug be regarded as a priority for Moz. WRT the
styling issue -- with some types of content you obviously won't get styles (eg
images), and with others you'll get default styles for everywhere that the
document author may be specifically overriding in this document, so taking it's
initial styles from it's source and overriding them in the document sounds good.

Comment 9

[Alex Vincent [:WeirdAl]]

I was just thinking: if the data returned the xlink:href is an image, XLink 
suggests just inserting the image, not where.  But if the data returned is an 
XML fragment, that means DOM modification.  It's a little confusing to a simple 
guy like me, at least from reading the related part of the XLink 1.0 REC.

There's been no significant work on this bug in quite a long time.  I 
appreciate the engineer being overburdened.  Is there a volunteer willing to 
take this bug over and see it through to completion?

Comment 10

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

What makes this tricky is that "embedding affects only the presentation of the
relevant resources; it does not dictate permanent transformation of the starting
resource". See Section 5.6.1, "embed".

If you want something that will change the DOM of the original document you want
XInclude.

Comment 11

[Anne (:annevk)]

I think that if bug 215083 is fixed, this can be implanted using CSS3 (that's
the way IMG etc. should be (re-)implanted as well).

Comment 12

[Boris Zbarsky [:bzbarsky]]

So basically, <xlink show="embed"> should be treated like <object> is?

Comment 13

[Hixie (not reading bugmail)]

depends whom you ask, but if you ask me, yes.

Comment 14

[Boris Zbarsky [:bzbarsky]]

So if I have:

  <html:img xlink:show="embed" src="whatever" xlink:href="somethingelse" />

Or something along those lines, what should happen?

Or what if I have a <mathml:whatever> element with an xlink:show="embed" on it?
 Should the element just ignore all its contents?

Comment 15

[Hixie (not reading bugmail)]

<img src=""> should win. But in general, parallel what we do for:

   <a href="" xlink:href="" xlink:type="simple"> ... </a>

Comment 16

[Boris Zbarsky [:bzbarsky]]

> But in general, parallel

Nothing there to parallel.  See bug 211916.

Comment 17

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

I was thinking about this the other day and thought this might be doable with
XBL. Unfortunately I don't know enough about XBL to say for certain.

Comment 18

[Hixie (not reading bugmail)]

XBL would not be the right way to do this for many reasons.