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 20150 - [Shadow]: "Nested tree" is defined, but "nesting tree" is only implied
Summary: [Shadow]: "Nested tree" is defined, but "nesting tree" is only implied
Status: RESOLVED WORKSFORME
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 18428
  Show dependency treegraph
 
Reported: 2012-11-29 08:32 UTC by Sergey G. Grekhov
Modified: 2013-02-01 10:22 UTC (History)
1 user (show)

See Also:


Attachments

Description Sergey G. Grekhov 2012-11-29 08:32:00 UTC
There's a contradiction in @host @-rule matching criteria. Here https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#styles specification reads:

"The @host @-rule matches a shadow host in the nesting tree."

But below https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#host-at-rule there are the following:

"The declarations of the rules in a @host @-rule must only be matched against the shadow host of the shadow tree in which the style is specified"

So this is a contradiction. If there's a shadow tree containing the nested tree should @host rule be applied to the nested tree or to the shadow tree itself only?
Comment 1 Dimitri Glazkov 2012-12-07 18:39:08 UTC
(In reply to comment #0)
> There's a contradiction in @host @-rule matching criteria. Here
> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.
> html#styles specification reads:
> 
> "The @host @-rule matches a shadow host in the nesting tree."
> 
> But below
> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.
> html#host-at-rule there are the following:
> 
> "The declarations of the rules in a @host @-rule must only be matched
> against the shadow host of the shadow tree in which the style is specified"
> 
> So this is a contradiction. If there's a shadow tree containing the nested
> tree should @host rule be applied to the nested tree or to the shadow tree
> itself only?

Ah! I think I know what the problem is. I started using the term "nesting tree" as the opposite of "nested tree" but never captured this in writing. I think you're reading "nesting" and "nested" as being the same thing and thus seeing a contradiction. Let me fix this.
Comment 2 Dimitri Glazkov 2012-12-07 19:01:29 UTC
http://dvcs.w3.org/hg/webcomponents/rev/1c3901041ed5
Comment 3 Sergey G. Grekhov 2012-12-10 06:47:28 UTC
Now it's clear thank you. But... I was unable to create working @host @-rule. I'm not sure if this is an implementation issue or I was wrong in the syntaxis. An example of how @host rule should work would be very helpful.

That's what I tried:

var d = document;

    d.body.innerHTML = 
    	'<ul class="cls">' +
    		'<li id="li1" class="shadow">1</li>' +
    		'<li id="li2" class="shadow2">2</li>' +
    		'<li id="li3" class="shadow">3</li>' +
    		'<li id="li4">4</li>' +
    		'<li id="li5" class="shadow">5</li>' +
    		'<li id="li6" class="shadow2">6</li>' +
    	'</ul>';

    var host = d.querySelector('.cls');
    //Shadow root to play with
    var s = new SR(host);
	
    var div = d.createElement('div');	
    div.innerHTML ='<ul><content select=".shadow"></content></ul>'; 
    s.appendChild(div);	
		
   var style = d.createElement('style');
   style.innerHTML = '' + 
			'@host {' +
				'ul {display:none;}' +
			'}';
   s.appendChild(style);


What should be correct @host rule that makes shadow host content invisible?
I also tried
			'@host {' +
				'div {display:none;}' +
			'}';

But this don't work anyway. So, please, add the example.
Comment 4 Sergey G. Grekhov 2012-12-10 09:23:08 UTC
Forgot to add that I really read 'nesting' as 'nested' at first...
Comment 5 Sergey G. Grekhov 2013-02-01 09:44:25 UTC
Works in Chrome Canary. Closed
Comment 6 Olli Pettay 2013-02-01 10:22:27 UTC
That is not a reason to close a spec bug.
Is the spec ok now?