This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24003 - [Imports]: Element removed flag's behavior is not clear if multiple HTMLLinkElement refers to the same import
Summary: [Imports]: Element removed flag's behavior is not clear if multiple HTMLLink...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 20683
  Show dependency tree / graph
 
Reported: 2013-12-05 12:23 UTC by Gabor Krizsanits
Modified: 2014-02-07 18:14 UTC (History)
3 users (show)

See Also:

Attachments

Description Gabor Krizsanits 2013-12-05 12:23:01 UTC 
It is not clear to me what should happen if multiple link elements in the same import tree refers to the same import, and only one of them is removed from the DOM tree for example. Shouldn't this flag be on the HTMLLinkElement instead of the import? Does it make sense to have such a flag on it at all?
Comment 1 Dimitri Glazkov 2014-01-27 20:45:09 UTC 
Hmmm, good question. Morrita-san?
Comment 2 Morrita Hajime 2014-01-30 03:02:57 UTC 
Right. The flag should be on <link> side.
And the flag could have better name then.
Comment 3 Blake Kaplan 2014-01-31 23:18:35 UTC 
(In reply to Morrita Hajime from comment #2)
> Right. The flag should be on <link> side.
> And the flag could have better name then.

What is the flag attempting to accomplish? If we put it on the <link>, then couldn't we simply check if the link is in a document (i.e. currentDocument is non-null)?
Comment 4 Morrita Hajime 2014-02-02 05:53:07 UTC 
The flag is one-way. Once it is set it isn't set again even after
the node comes back into the document.

The intention of the behaviour is to clarify the one-shot characteristics
of imports. We might want to revise that policy if we have better model here.
Comment 5 Gabor Krizsanits 2014-02-02 16:45:55 UTC 
(In reply to Morrita Hajime from comment #4)
> The intention of the behaviour is to clarify the one-shot characteristics
> of imports. We might want to revise that policy if we have better model here.

I'm not sure I fully understand this. So the idea is that even though we do not remove the import document from the cache/manager when the referring link element is removed from the tree, when we put it back it will not work? What's the purpose of this behaviour?
Comment 6 Morrita Hajime 2014-02-03 18:16:25 UTC 
(In reply to Gabor Krizsanits from comment #5)
> (In reply to Morrita Hajime from comment #4)
> > The intention of the behaviour is to clarify the one-shot characteristics
> > of imports. We might want to revise that policy if we have better model here.
> 
> I'm not sure I fully understand this. So the idea is that even though we do
> not remove the import document from the cache/manager when the referring
> link element is removed from the tree, when we put it back it will not work?
> What's the purpose of this behaviour?

I'm sorry to be unclear.
I don't think we should remove the document from the manager.
The manager thing was out of consideration when the section was written.

Thinking more about that, I'm now inclining to get rid of the flag thing.
I need to think about that a bit more how to spec it out though.
Comment 7 Morrita Hajime 2014-02-06 00:54:43 UTC 
Trying to clarify the point. Now the flag is gone.

https://github.com/w3c/webcomponents/commit/3170e1c8e7bd7133da4131c766aa27dc0cc42638
https://github.com/w3c/webcomponents/commit/3170e1c8e7bd7133da4131c766aa27dc0cc42638

Closing for now. Feel free to reopen or file another bug to continue conversation.