Ted Dinklocker Introduction

[Ted Dinklocker]

I just joined the group today, so thought I should introduce myself. My name is 
Ted Dinklocker and I work at Microsoft on the Internet Explorer Platform team. 
I am excited to work with all of you to help drive web interoperability and 
capability! A short bio:

I have worked in technology and software for over 20 years now, but the passion 
was ignited in the 80's typing into my TRS80 computer hooked up to an old TV. I 
have been a developer and a program manager on a variety of software projects 
including a proprietary finite element analysis engineering software, packaged 
productivity software, IT Pro management and analysis software, and automotive 
embedded software. I now work on the Internet Explorer Platform team, focusing 
on input areas including touch events, pointer events, form input controls, and 
other areas.

Re: [IndexedDB] link to Editor's draft is a 404

[Tobie Langel]

On Wed, Feb 4, 2015 at 8:37 AM, Tobie Langel  wrote:

> On Wed, Feb 4, 2015 at 3:35 AM, Michael[tm] Smith  wrote:
> >
> > Arthur Barstow , 2015-02-02 08:47 -0500:
> > > Archived-At: 
> > > On 2/2/15 7:14 AM, Tobie Langel wrote:
> > >
> > > >Would recommend redirecting to the ED of the next version of the spec.
> > >
> > > That makes sense to me.
> >
> > Yup, sorry about thatーI forgot a step when we migrated the repos. But
> I've
> > now set up the redirects and things should be working as expected. If not
> > lemme know.
>
> Thanks! But it looks like you redirected it to the GitHub repo rather than
> the spec itself:
>
> $ curl -I https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html
> HTTP/1.1 302 Found
> Date: Wed, 04 Feb 2015 07:34:26 GMT
> Server: Apache/2.2.16 (Debian)
> Location: http://w3c.github.io/IndexedDB/
> Vary: Accept-Encoding
> Content-Type: text/html; charset=iso-8859-1
>
> Mind fixing that?
>

Ignore the above. Everything is working properly. I'm an idiot. Sorry for
the noise.

--tobie

Re: Shadow tree style isolation primitive

[Olli Pettay]

On 02/03/2015 07:24 PM, Dimitri Glazkov wrote:

Not trying to barge in, just sprinkling data...

On Tue, Feb 3, 2015 at 6:22 AM, Brian Kardell mailto:bkard...@gmail.com>> wrote:



On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay mailto:o...@pettay.fi>> wrote:

On 02/02/2015 09:22 PM, Dimitri Glazkov wrote:

Brian recently posted what looks like an excellent framing of the 
composition problem:


https://briankardell.__wordpress.com/2015/01/14/__friendly-fire-the-fog-of-dom/



This is the problem we solved with Shadow DOM and the problem I 
would like to see solved with the primitive being discussed on this thread.



random comments about that blog post.

[snip]
We need to be able to select mount nodes explicitly, and perhaps 
explicitly say that all such nodes should be selected.
So, maybe, deep(mountName) and deep(*)

Is there a reason you couldn't do that with normal CSS techniques, no 
additional combinator?  something like /mount/[id=foo] ?


That's ::shadow in the scoping spec: 
http://dev.w3.org/csswg/css-scoping/#shadow-pseudoelement



[snip]

"It still needs to be possible from the hosting page to say “Yes, I mean all 
buttons should be blue”"
I disagree with that. It can very well be possible that some component 
really must control the colors itself. Say, it uses
buttons to indicate if traffic light is red or green. Making both those 
buttons suddenly blue would break the whole concept of the
component.


This is still possible, and works in a predictable way with today's styling 
machinery. Use inline styles on the button that you want to be green/red
inside of the scope, and no /deep/ or /mount/ or >>> will be able to affect it: 
http://jsbin.com/juyeziwaqo/1/edit?html,css,js,output ... unless the
war progressed to the stage where "!important" is used as hammer.



Why should even !important work if the component wants to use its own colors?






:DG<

Re: Shadow tree style isolation primitive

[Olli Pettay]

On 02/03/2015 04:22 PM, Brian Kardell wrote:



On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay mailto:o...@pettay.fi>> wrote:

On 02/02/2015 09:22 PM, Dimitri Glazkov wrote:

Brian recently posted what looks like an excellent framing of the 
composition problem:


https://briankardell.__wordpress.com/2015/01/14/__friendly-fire-the-fog-of-dom/



This is the problem we solved with Shadow DOM and the problem I would 
like to see solved with the primitive being discussed on this thread.



random comments about that blog post.

[snip]
We need to be able to select mount nodes explicitly, and perhaps explicitly 
say that all such nodes should be selected.
So, maybe, deep(mountName) and deep(*)

Is there a reason you couldn't do that with normal CSS techniques, no 
additional combinator?  something like /mount/[id=foo] ?


That leaves all the isolation up to the outside world.
If ShadowRoot had something like attribute DOMString name?; which defaults to 
null and null means deep(name) or deep(*) wouldn't be able
to find the mount, that would let the component itself to say whether it can 
deal with outside world poking it CSS.





[snip]

"It still needs to be possible from the hosting page to say “Yes, I mean all 
buttons should be blue”"
I disagree with that. It can very well be possible that some component 
really must control the colors itself. Say, it uses
buttons to indicate if traffic light is red or green. Making both those 
buttons suddenly blue would break the whole concept of the
component.


By the previous comment though it seems you are saying it's ok to reach into 
the mounts,

If mount explicitly wants that


in which case you could do exactly this... Perhaps the

shortness of the sentence makes it seem like I am saying something I am not, 
basically I'm saying it should be possible to explicitly write rules
which do apply inside a mount.

I agree with "it should be possible to explicitly write rules which do apply inside 
a mount" assuming the mount itself has been flagged to allow that.
Otherwise it wouldn't be really explicitlyness, since >>> can just easily 
select randomly any mount.



 CSS already gives you all sorts of tools for someone developing a bit in 
isolation to say how important it is that
this particular rule holds up - you can increase specificity with id-based nots 
or use !important or even the style attribute itself if it is that
fundamental - what you can't do is protect yourself on either end from 
accidental error.  I feel like one could easily over-engineer a solution here
and kill its actual chances of success, whereas a smaller change could not only 
have a good chance of getting done, but have very outsized impact and
provide some of the data on how to improve it further.



Why do we need shadow DOM (or something similar) at all if we expose it easily 
to the outside world.
One could even now just require that elements in "components" in a web page have 
class="component", and then
.component could be used as >>>. Sure, it would require :not(.component) usage 
too.
And from DOM APIs side one could easily implement filtering for the contents of 
"components" using small script libraries.


[Perhaps a bit off topic to the style isolation]
In other words, I'm not very happy to add super complicated Shadow DOM to the 
platform if it doesn't really provide anything new which
couldn't be implemented easily with script libraries and a bit stricter coding 
styles and conventions.



-Olli




If this doesn't seem -hostile- to decent further improvements, finding 
something minimal but
still very useful might be good.






--
Brian Kardell :: @briankardell :: hitchjs.com 

Re: Minimum viable custom elements

[Chris Bateman]

Assuming a situation where a native element – with custom functionality –
is dynamically injected into the page, the basic options I can think of are:

 - 
 -  and a page-level listener
 -  and call a function after it's
injected

Option 3 is really cumbersome, in my opinion. Option 2 could work, except
for A. when I want to execute some functionality right away, and B. when
the native element won't be sending events to hook onto.

An better example of both A and B (than my previous hypothetical) might be
GitHub's  extension:
https://github.com/github/time-elements/.


I'm not certain having two different mechanisms, namely "type" and "is"
> attributes, to specify the type of an input an element expects is a
> desirable approach.




I certainly can't speak to your perspective on this, and you may be right.
An input's probably not be the best example for making is="" look good.
Regardless, I have to trust that devs are smart enough to figure out what's
going on here, and set it up properly.

Chris



On Tue, Feb 3, 2015 at 2:04 PM, Ryosuke Niwa  wrote:

>
> On Feb 3, 2015, at 7:13 AM, Chris Bateman  wrote:
>
> Why don't we just make all input elements support these new attributes
>> we're adding?
>
>
> In my opinion, I'd say because you can't possibly cover every case - what
> about doing the same kind of formatting for social security numbers, credit
> card numbers, phone numbers, or who knows what else? How about other kinds
> of functionality - like a  that automatically resizes itself?
>
>
> That sounds like a slightly different use case. Social security number,
> credit card number, etc… seems like a different input type to me while
> "numerals" or "radix" attributes are extra configurations/options each
> input type may respect.  While I agree allowing author defined input types
> will be useful, I'm not certain having two different mechanisms, namely
> "type" and "is" attributes, to specify the type of an input an element
> expects is a desirable approach.
>
> What kind of initializations does it have to do?
>
>
> Yes, probably just adding a listener in this case – which you certainly
> could handle with event delegation. But maybe someone might want to simply
> execute some functionality when the element is created or attached. An
> input that automatically populates itself with a random number. An awful,
> contrived example for sure - but it wouldn't be possible with delegation
> alone.
>
> Again - simply wanted to make the point that devs do add functionality to
> native elements - so it might be handy to have custom element callbacks to
> assist with it.
>
>
> That sounds rather hypothetical to me.  I would like to know a concrete
> use case in which the initialization of an author defined input type or an
> input configuration/option is impossible or too cumbersome to be
> implemented using existing API.
>
> Adding a new feature to the Web platform incurs an inherently higher cost
> because multiple vendors have to coordinate, and removing or changing the
> behavior of a feature is virtually impossible.
>
> - R. Niwa
>
>

Re: Shadow tree style isolation primitive

[Brian Kardell]

On Wed, Feb 4, 2015 at 7:56 AM, Olli Pettay  wrote:

> On 02/03/2015 04:22 PM, Brian Kardell wrote:
>
>>
>>
>> On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay > o...@pettay.fi>> wrote:
>>
>> On 02/02/2015 09:22 PM, Dimitri Glazkov wrote:
>>
>> Brian recently posted what looks like an excellent framing of the
>> composition problem:
>>
>> https://briankardell.__wordpress.com/2015/01/14/__friendly-
>> fire-the-fog-of-dom/
>> > friendly-fire-the-fog-of-dom/>
>>
>> This is the problem we solved with Shadow DOM and the problem I
>> would like to see solved with the primitive being discussed on this thread.
>
>
[snip]

> If ShadowRoot had something like attribute DOMString name?; which defaults
>> to null and null means deep(name) or deep(*) wouldn't be able
>>
> to find the mount, that would let the component itself to say whether it
> can deal with outside world poking it CSS.


That actually doesn't sound crazy to me.  I mean, it actually fits
pretty nicely into the conceptual model I think and it would add a whole
additional layer of possible protection which is explainable in sort of
"todays terms" with minimal new 'stuff'... the combinator is new anyway and
you're dealing with mount in what seems like a good way there.  I think I
like it.


[snip]

> [Perhaps a bit off topic to the style isolation]
> In other words, I'm not very happy to add super complicated Shadow DOM to
> the platform if it doesn't really provide anything new which
> couldn't be implemented easily with script libraries and a bit stricter
> coding styles and conventions.


I'd suggest that you're radically over-stating - you really can't "easily
solve this problem", even with much stricter coding style, as I explained
in that post.  This is a problem and even without named mount protection
above, this would be a giant leap forward because the -default- thing is to
not match.  Doing 'right' by default is a giant win.  That said, as I say
above, I kinda like the named mount idea...


-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: Minimum viable custom elements

[Anne van Kesteren]

On Wed, Feb 4, 2015 at 3:43 PM, Chris Bateman  wrote:
> An better example of both A and B (than my previous hypothetical) might be
> GitHub's  extension:
> https://github.com/github/time-elements/.

FWIW, I do want subclassing of builtins to work. Maybe not necessarily
at first, but definitely down the line. I just think it would be much
better if that could be .

A problem with this is styling. It seems
https://tabatkins.github.io/specs/css-extend-rule/ offers a way out
there:

  relative-time { @extend time }

Another problem are the logic checks in the implementation, typically
branched on localName. There's two solutions for these:

1. Change localName identity checks with "ignore global instanceof" checks.

2. Reimplement the various features elements have (focus, form
submission, a11y) as protocols that can be inherited.

Although 1) is fairly expensive as bz said various times so far, it's
probably more doable than 2) short term.


-- 
https://annevankesteren.nl/

RE: Minimum viable custom elements

[Domenic Denicola]

I hope others can address the question of why custom element callbacks are 
useful, and meet the bar of being a feature we should add to the web platform 
(with all the UA-coordination that requires). I just wanted to interject into 
this  discussion.

In IRC Anne and I were briefly discussing how type="" is the is="" of Web 
Applications 1.0. That is,  is similar to  
or similar---it has a reasonable fallback behavior, but in reality it is a 
completely different control than the local name indicates.

For  this is accomplished with an ever-growing base class with an 
internal mode switch that makes its various properties/methods meaningful, 
whereas for is="" you get a tidier inheritance hierarchy with the applicable 
properties and methods confined to the specific element and not impacting all 
others with the same local name. I.e., is="" is type="" done right.

The fact that type="" exists and doesn't fit with the is="" paradigm is 
unfortunate. But I don't think we'd be better off trying to somehow generalize 
the type="" paradigm, or pretend it is any good. What is our advice to authors, 
then---they should modify HTMLImgElement.prototype with x-gif-related 
properties and methods, that only work if type="x-gif" is present? That seems 
to be the road that this thread is heading down.

You could imagine plans to try to rationalize type="" on top of is="" (or, 
perhaps better, deprecate  in favor of  or 
something). But those seem pretty speculative.

Re: Shadow tree style isolation primitive

[Ryosuke Niwa]

> On Feb 4, 2015, at 4:56 AM, Olli Pettay  wrote:
> 
> On 02/03/2015 04:22 PM, Brian Kardell wrote:
>> 
>> On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay > > wrote:
>> 
>>On 02/02/2015 09:22 PM, Dimitri Glazkov wrote:
>> 
>>Brian recently posted what looks like an excellent framing of the 
>> composition problem:
>> 
>>
>> https://briankardell.__wordpress.com/2015/01/14/__friendly-fire-the-fog-of-dom/
>>
>> 
>> 
>>This is the problem we solved with Shadow DOM and the problem I would 
>> like to see solved with the primitive being discussed on this thread.
>> 
>> 
>> 
>>random comments about that blog post.
>> 
>>[snip]
>>We need to be able to select mount nodes explicitly, and perhaps 
>> explicitly say that all such nodes should be selected.
>>So, maybe, deep(mountName) and deep(*)
>> 
>> Is there a reason you couldn't do that with normal CSS techniques, no 
>> additional combinator?  something like /mount/[id=foo] ?
> 
> That leaves all the isolation up to the outside world.
> If ShadowRoot had something like attribute DOMString name?; which defaults to 
> null and null means deep(name) or deep(*) wouldn't be able
> to find the mount, that would let the component itself to say whether it can 
> deal with outside world poking it CSS.
> 
> 
>> 
>> 
>> [snip]
>> 
>>"It still needs to be possible from the hosting page to say “Yes, I mean 
>> all buttons should be blue”"
>>I disagree with that. It can very well be possible that some component 
>> really must control the colors itself. Say, it uses
>>buttons to indicate if traffic light is red or green. Making both those 
>> buttons suddenly blue would break the whole concept of the
>>component.
>> 
>> 
>> By the previous comment though it seems you are saying it's ok to reach into 
>> the mounts,
> If mount explicitly wants that
> 
> 
> in which case you could do exactly this... Perhaps the
>> shortness of the sentence makes it seem like I am saying something I am not, 
>> basically I'm saying it should be possible to explicitly write rules
>> which do apply inside a mount.
> I agree with "it should be possible to explicitly write rules which do apply 
> inside a mount" assuming the mount itself has been flagged to allow that.
> Otherwise it wouldn't be really explicitlyness, since >>> can just easily 
> select randomly any mount.
> 
> 
>> CSS already gives you all sorts of tools for someone developing a bit in 
>> isolation to say how important it is that
>> this particular rule holds up - you can increase specificity with id-based 
>> nots or use !important or even the style attribute itself if it is that
>> fundamental - what you can't do is protect yourself on either end from 
>> accidental error.  I feel like one could easily over-engineer a solution here
>> and kill its actual chances of success, whereas a smaller change could not 
>> only have a good chance of getting done, but have very outsized impact and
>> provide some of the data on how to improve it further.
> 
> 
> Why do we need shadow DOM (or something similar) at all if we expose it 
> easily to the outside world.
> One could even now just require that elements in "components" in a web page 
> have class="component", and then
> .component could be used as >>>. Sure, it would require :not(.component) 
> usage too.
> And from DOM APIs side one could easily implement filtering for the contents 
> of "components" using small script libraries.
> 
> 
> [Perhaps a bit off topic to the style isolation]
> In other words, I'm not very happy to add super complicated Shadow DOM to the 
> platform if it doesn't really provide anything new which
> couldn't be implemented easily with script libraries and a bit stricter 
> coding styles and conventions.

I concur.  I don't think introducing something as complex as shadow DOM is 
worth our effort if the only problem we're solving is multiple teams at a large 
company stepping on each other.  They could simply use their own framework or 
library, or even create their own convention, to solve that problem for 
themselves.

- R. Niwa

Re: Minimum viable custom elements

[Ryosuke Niwa]

> On Feb 4, 2015, at 7:59 AM, Domenic Denicola  wrote:
> 
> In IRC Anne and I were briefly discussing how type="" is the is="" of Web 
> Applications 1.0. That is,  is similar to  
> or similar---it has a reasonable fallback behavior, but in reality it is a 
> completely different control than the local name indicates.
> 
> For  this is accomplished with an ever-growing base class with an 
> internal mode switch that makes its various properties/methods meaningful, 
> whereas for is="" you get a tidier inheritance hierarchy with the applicable 
> properties and methods confined to the specific element and not impacting all 
> others with the same local name. I.e., is="" is type="" done right.

While disallowing the type of an element to be changed after the fact as done 
in "is" attribute is a step forward, it's not the only problem "type" attribute 
poses.  The biggest problem with "type" attribute is not that it shares the 
same interface across all types but that it violates the fundamental design 
principle of SGML/XML languages: the name of an element uniquely identifies its 
semantics.

> The fact that type="" exists and doesn't fit with the is="" paradigm is 
> unfortunate. But I don't think we'd be better off trying to somehow 
> generalize the type="" paradigm, or pretend it is any good.

I agree "type" attribute is bad but that doesn't make "is" attribute any better.

> What is our advice to authors, then---they should modify 
> HTMLImgElement.prototype with x-gif-related properties and methods, that only 
> work if type="x-gif" is present? That seems to be the road that this thread 
> is heading down.

This is precisely why we shouldn't be introducing "is" attribute.  Changing the 
interface of an element based on a pretense of an attribute is extremely weird. 
 That's like a class changing its concrete class at runtime based on the value 
of its member variable.

> You could imagine plans to try to rationalize type="" on top of is="" (or, 
> perhaps better, deprecate  in favor of  or 
> something). But those seem pretty speculative.

"is" can't rationalize "type" because Web compatibility requires that authors 
can change "type" at any time.

- R. Niwa

Re: Minimum viable custom elements

[Ryosuke Niwa]

See https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0435.html 
 
first.

> On Feb 4, 2015, at 6:43 AM, Chris Bateman  wrote:
> 
> Assuming a situation where a native element – with custom functionality – is 
> dynamically injected into the page, the basic options I can think of are:
> 
>  - 
>  -  and a page-level listener
>  -  and call a function after it's injected

Or .  Note that the author of 
the custom element can force the markup to have an input element inside by 
making the element not function when there isn't one on the contrary to what 
you said in 
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0410.html 
  
Since custom elements aren't supported by all browsers initially, authors have 
to implement the fallback anyway.

> I'm not certain having two different mechanisms, namely "type" and "is" 
> attributes, to specify the type of an input an element expects is a desirable 
> approach.
> 
> 
> 
> I certainly can't speak to your perspective on this, and you may be right. An 
> input's probably not be the best example for making is="" look good. 
> Regardless, I have to trust that devs are smart enough to figure out what's 
> going on here, and set it up properly.

I'd say that line of thought could be dangerous in that once we say we should 
trust devs to the right thing, we may just say devs should do the right thing 
for accessibility for themselves.  Since the point of Web components is to 
improve developer ergonomics, I don't think we should assume developers to be 
particularly "smart" or "experienced".  We want to make the Web a place where 
everyone can start writing great apps without knowing some weird quirks of the 
platform.

- R. Niwa

Re: Minimum viable custom elements

[Steve Faulkner]

On 4 February 2015 at 16:51, Ryosuke Niwa  wrote:

> 
>

I think if this worked. i.e. hid the styling and allowed styling over top,
while allowing access to the input functionality would be a good solution
for the many many instances of native controls being remade as custom
controls simply to be able to control style.

I made a simple example of using  to host a checkbox, as an
experiment:
http://codepen.io/stevef/pen/OPxvZX

note: am not saying  is a solution, like is= it provides the
ability to make use of built in features of native controls. which is the
outcome I would like to see baked into web components.
--

Regards

SteveF
HTML 5.1 

Re: Minimum viable custom elements

[Chris Bateman]

Yeah, I had noted in that post that wrapping a native element with a custom 
element was an option - only drawback is that the markup isn't as terse (which 
is generally advertised as one of the selling points of Custom Elements). But 
that doesn't seem like a deal breaker to me, if subclassing needs to be 
postponed.




Chris

On Wed, Feb 4, 2015 at 10:51 AM, Ryosuke Niwa  wrote:

> See https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0435.html 
>  
> first.
>> On Feb 4, 2015, at 6:43 AM, Chris Bateman  wrote:
>> 
>> Assuming a situation where a native element – with custom functionality – is 
>> dynamically injected into the page, the basic options I can think of are:
>> 
>>  - 
>>  -  and a page-level listener
>>  -  and call a function after it's 
>> injected
> Or .  Note that the author 
> of the custom element can force the markup to have an input element inside by 
> making the element not function when there isn't one on the contrary to what 
> you said in 
> https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0410.html 
>   
> Since custom elements aren't supported by all browsers initially, authors 
> have to implement the fallback anyway.
>> I'm not certain having two different mechanisms, namely "type" and "is" 
>> attributes, to specify the type of an input an element expects is a 
>> desirable approach.
>> 
>> 
>> 
>> I certainly can't speak to your perspective on this, and you may be right. 
>> An input's probably not be the best example for making is="" look good. 
>> Regardless, I have to trust that devs are smart enough to figure out what's 
>> going on here, and set it up properly.
> I'd say that line of thought could be dangerous in that once we say we should 
> trust devs to the right thing, we may just say devs should do the right thing 
> for accessibility for themselves.  Since the point of Web components is to 
> improve developer ergonomics, I don't think we should assume developers to be 
> particularly "smart" or "experienced".  We want to make the Web a place where 
> everyone can start writing great apps without knowing some weird quirks of 
> the platform.
> - R. Niwa

Re: Minimum viable custom elements

[Brian Kardell]

On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman  wrote:

> Yeah, I had noted in that post that wrapping a native element with a
> custom element was an option - only drawback is that the markup isn't as
> terse (which is generally advertised as one of the selling points of Custom
> Elements). But that doesn't seem like a deal breaker to me, if subclassing
> needs to be postponed.
>
> Chris
>
>
As I pointed out ealier:





seems like barely a ternseness savings worth discussing.



-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: Minimum viable custom elements

[Ryosuke Niwa]

> On Feb 4, 2015, at 9:05 AM, Steve Faulkner  wrote:
> 
> On 4 February 2015 at 16:51, Ryosuke Niwa  > wrote:
> 
> 
> I think if this worked. i.e. hid the styling and allowed styling over top, 
> while allowing access to the input functionality would be a good solution for 
> the many many instances of native controls being remade as custom controls 
> simply to be able to control style.
> 
> I made a simple example of using  to host a checkbox, as an 
> experiment:
> http://codepen.io/stevef/pen/OPxvZX 
> 
> note: am not saying  is a solution, like is= it provides the ability 
> to make use of built in features of native controls. which is the outcome I 
> would like to see baked into web components.


Right.  As I mentioned earlier, shadow DOM or decorator is what provides the 
styling-over-top capability.  And I assure you, Anne and everyone else at each 
browser vendor is interested in solving that problem.

> On Feb 4, 2015, at 9:41 AM, Chris Bateman  wrote:
> 
> Yeah, I had noted in that post that wrapping a native element with a custom 
> element was an option - only drawback is that the markup isn't as terse 
> (which is generally advertised as one of the selling points of Custom 
> Elements). But that doesn't seem like a deal breaker to me, if subclassing 
> needs to be postponed.

Great to hear!  We should make sure custom elements accommodates this 
composition pattern then.

- R. Niwa

Re: Minimum viable custom elements

[Ryosuke Niwa]

> On Feb 4, 2015, at 10:12 AM, Brian Kardell  wrote:
> 
> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman  > wrote:
> Yeah, I had noted in that post that wrapping a native element with a custom 
> element was an option - only drawback is that the markup isn't as terse 
> (which is generally advertised as one of the selling points of Custom 
> Elements). But that doesn't seem like a deal breaker to me, if subclassing 
> needs to be postponed.
> 
> Chris
> 
>  
> As I pointed out ealier:
>  
> 
> 
> 
> 
> seems like barely a ternseness savings worth discussing.

Indeed.  Also, authors are used to the idea of including a fallback content 
inside an element after canvas and object elements and this fits well with 
their mental model.

- R. Niwa

Re: Minimum viable custom elements

[Alice Boxhall]

On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa  wrote:

>
> On Feb 4, 2015, at 10:12 AM, Brian Kardell  wrote:
>
> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman 
> wrote:
>
>> Yeah, I had noted in that post that wrapping a native element with a
>> custom element was an option - only drawback is that the markup isn't as
>> terse (which is generally advertised as one of the selling points of Custom
>> Elements). But that doesn't seem like a deal breaker to me, if subclassing
>> needs to be postponed.
>>
>> Chris
>>
>>
> As I pointed out ealier:
>
> 
>
> 
>
> seems like barely a ternseness savings worth discussing.
>
>
> Indeed.  Also, authors are used to the idea of including a fallback
> content inside an element after canvas and object elements and this fits
> well with their mental model.
>

I'm just trying to get my head around this pattern. In this example, does
the web page author or the custom element developer embed the input? And
who is responsible for syncing the relevant attributes across? In reality,
isn't this going to look more like





or as a slightly contrived example,





Or does the custom element get its state from the embedded element?

Re: Minimum viable custom elements

[Brian Kardell]

On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall  wrote:

> On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa  wrote:
>
>>
>> On Feb 4, 2015, at 10:12 AM, Brian Kardell  wrote:
>>
>> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman 
>> wrote:
>>
>>> Yeah, I had noted in that post that wrapping a native element with a
>>> custom element was an option - only drawback is that the markup isn't as
>>> terse (which is generally advertised as one of the selling points of Custom
>>> Elements). But that doesn't seem like a deal breaker to me, if subclassing
>>> needs to be postponed.
>>>
>>> Chris
>>>
>>>
>> As I pointed out ealier:
>>
>> 
>>
>> 
>>
>> seems like barely a ternseness savings worth discussing.
>>
>>
>> Indeed.  Also, authors are used to the idea of including a fallback
>> content inside an element after canvas and object elements and this fits
>> well with their mental model.
>>
>
> I'm just trying to get my head around this pattern. In this example, does
> the web page author or the custom element developer embed the input? And
> who is responsible for syncing the relevant attributes across? In reality,
> isn't this going to look more like
>
> 
> 
> 
>
> or as a slightly contrived example,
>
> 
> 
> 
>
> Or does the custom element get its state from the embedded element?
>

the custom element uses its contents as input and, in the simplest sense,
just moves it or maps it during creation... In a more complicated world
with something more like shadow dom (a separate topic) it might be
'projected'

-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: Minimum viable custom elements

[Alice Boxhall]

On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell  wrote:

>
>
> On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall  wrote:
>
>> On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa  wrote:
>>
>>>
>>> On Feb 4, 2015, at 10:12 AM, Brian Kardell  wrote:
>>>
>>> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman 
>>> wrote:
>>>
 Yeah, I had noted in that post that wrapping a native element with a
 custom element was an option - only drawback is that the markup isn't as
 terse (which is generally advertised as one of the selling points of Custom
 Elements). But that doesn't seem like a deal breaker to me, if subclassing
 needs to be postponed.

 Chris


>>> As I pointed out ealier:
>>>
>>> 
>>>
>>> 
>>>
>>> seems like barely a ternseness savings worth discussing.
>>>
>>>
>>> Indeed.  Also, authors are used to the idea of including a fallback
>>> content inside an element after canvas and object elements and this fits
>>> well with their mental model.
>>>
>>
>> I'm just trying to get my head around this pattern. In this example, does
>> the web page author or the custom element developer embed the input? And
>> who is responsible for syncing the relevant attributes across? In reality,
>> isn't this going to look more like
>>
>> 
>> 
>> 
>>
>> or as a slightly contrived example,
>>
>> 
>> 
>> 
>>
>> Or does the custom element get its state from the embedded element?
>>
>
> the custom element uses its contents as input and, in the simplest sense,
> just moves it or maps it during creation... In a more complicated world
> with something more like shadow dom (a separate topic) it might be
> 'projected'
>

It seems like it would have to be in the light DOM for things like labels,
forms etc to work. So then how do we treat it as "fallback content" i.e.
un-rendered, while allowing it to be accessible to to the AT layer?

Re: Minimum viable custom elements

[Ryosuke Niwa]

> On Feb 4, 2015, at 10:54 AM, Alice Boxhall  wrote:
> 
> On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa  > wrote:
> 
>> On Feb 4, 2015, at 10:12 AM, Brian Kardell > > wrote:
>> 
>> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman > > wrote:
>> Yeah, I had noted in that post that wrapping a native element with a custom 
>> element was an option - only drawback is that the markup isn't as terse 
>> (which is generally advertised as one of the selling points of Custom 
>> Elements). But that doesn't seem like a deal breaker to me, if subclassing 
>> needs to be postponed.
>> 
>> Chris
>> 
>>  
>> As I pointed out ealier:
>>  
>> 
>> 
>> 
>> 
>> seems like barely a ternseness savings worth discussing.
> 
> Indeed.  Also, authors are used to the idea of including a fallback content 
> inside an element after canvas and object elements and this fits well with 
> their mental model.
> 
> I'm just trying to get my head around this pattern. In this example, does the 
> web page author or the custom element developer embed the input? And who is 
> responsible for syncing the relevant attributes across? In reality, isn't 
> this going to look more like
> 
> 
> 
> 
> 
> or as a slightly contrived example,
> 
> 
> 
> 
> 
> Or does the custom element get its state from the embedded element?


I'd imagine that the better approach is for the custom element to pull values 
out of the fallback element so:




This is similar to how "picture" element sometimes uses the attribute values of 
the containing "img" element to choose the right image to show.

- R. Niwa

Re: Minimum viable custom elements

[Chris Bateman]

Ugh, I forgot about that. Without subclassing -  terseness is a very minor 
drawback, but remapping the interface is a big pain.

On Wed, Feb 4, 2015 at 1:01 PM, Brian Kardell  wrote:

> On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall  wrote:
>> On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa  wrote:
>>
>>>
>>> On Feb 4, 2015, at 10:12 AM, Brian Kardell  wrote:
>>>
>>> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman 
>>> wrote:
>>>
 Yeah, I had noted in that post that wrapping a native element with a
 custom element was an option - only drawback is that the markup isn't as
 terse (which is generally advertised as one of the selling points of Custom
 Elements). But that doesn't seem like a deal breaker to me, if subclassing
 needs to be postponed.

 Chris


>>> As I pointed out ealier:
>>>
>>> 
>>>
>>> 
>>>
>>> seems like barely a ternseness savings worth discussing.
>>>
>>>
>>> Indeed.  Also, authors are used to the idea of including a fallback
>>> content inside an element after canvas and object elements and this fits
>>> well with their mental model.
>>>
>>
>> I'm just trying to get my head around this pattern. In this example, does
>> the web page author or the custom element developer embed the input? And
>> who is responsible for syncing the relevant attributes across? In reality,
>> isn't this going to look more like
>>
>> 
>> 
>> 
>>
>> or as a slightly contrived example,
>>
>> 
>> 
>> 
>>
>> Or does the custom element get its state from the embedded element?
>>
> the custom element uses its contents as input and, in the simplest sense,
> just moves it or maps it during creation... In a more complicated world
> with something more like shadow dom (a separate topic) it might be
> 'projected'
> -- 
> Brian Kardell :: @briankardell :: hitchjs.com

Re: Minimum viable custom elements

[Ryosuke Niwa]

> On Feb 4, 2015, at 11:05 AM, Alice Boxhall  wrote:
> 
> On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell  > wrote:
> 
> On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall  > wrote:
> On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa  > wrote:
> 
>> On Feb 4, 2015, at 10:12 AM, Brian Kardell > > wrote:
>> 
>> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman > > wrote:
>> Yeah, I had noted in that post that wrapping a native element with a custom 
>> element was an option - only drawback is that the markup isn't as terse 
>> (which is generally advertised as one of the selling points of Custom 
>> Elements). But that doesn't seem like a deal breaker to me, if subclassing 
>> needs to be postponed.
>> 
>> Chris
>> 
>>  
>> As I pointed out ealier:
>>  
>> 
>> 
>> 
>> 
>> seems like barely a ternseness savings worth discussing.
> 
> Indeed.  Also, authors are used to the idea of including a fallback content 
> inside an element after canvas and object elements and this fits well with 
> their mental model.
> 
> I'm just trying to get my head around this pattern. In this example, does the 
> web page author or the custom element developer embed the input? And who is 
> responsible for syncing the relevant attributes across? In reality, isn't 
> this going to look more like
> 
> 
> 
> 
> 
> or as a slightly contrived example,
> 
> 
> 
> 
> 
> Or does the custom element get its state from the embedded element?
> 
> the custom element uses its contents as input and, in the simplest sense, 
> just moves it or maps it during creation... In a more complicated world with 
> something more like shadow dom (a separate topic) it might be 'projected'
> 
> It seems like it would have to be in the light DOM for things like labels, 
> forms etc to work. So then how do we treat it as "fallback content" i.e. 
> un-rendered, while allowing it to be accessible to to the AT layer?


Since it's a fallback content, it would certainly be in the regular DOM even if 
we had shadow DOM.  FYI, this whole thread doesn't assume or preclude the 
existence of shadow DOM.  It is the responsibility for custom form elements 
users to put regular input elements inside them.

- R. Niwa

Re: Minimum viable custom elements

[Ryosuke Niwa]

> On Feb 4, 2015, at 11:11 AM, Chris Bateman  wrote:
> 
> Ugh, I forgot about that. Without subclassing -  terseness is a very minor 
> drawback, but remapping the interface is a big pain.

Could you give us a concrete use case in which remapping the interface is 
necessary or hard/impossible to do?

- R. Niwa

Re: Minimum viable custom elements

[Alice Boxhall]

So a web page author would write


and then the custom element would sprout an 
with the attribute values copied across? Then the web page author knows
nothing about the  element, so if they want to programmatically the
value of the custom element, they'd modify an attribute on it, rather than
the , right? So you'd have to keep them in sync regardless.

On Wed, Feb 4, 2015 at 11:14 AM, Ryosuke Niwa  wrote:

>
> On Feb 4, 2015, at 11:05 AM, Alice Boxhall  wrote:
>
> On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell  wrote:
>
>>
>> On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall 
>> wrote:
>>
>>> On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa  wrote:
>>>

 On Feb 4, 2015, at 10:12 AM, Brian Kardell  wrote:

 On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman 
 wrote:

> Yeah, I had noted in that post that wrapping a native element with a
> custom element was an option - only drawback is that the markup isn't as
> terse (which is generally advertised as one of the selling points of 
> Custom
> Elements). But that doesn't seem like a deal breaker to me, if subclassing
> needs to be postponed.
>
> Chris
>
>
 As I pointed out ealier:

 

 

 seems like barely a ternseness savings worth discussing.


 Indeed.  Also, authors are used to the idea of including a fallback
 content inside an element after canvas and object elements and this fits
 well with their mental model.

>>>
>>> I'm just trying to get my head around this pattern. In this example,
>>> does the web page author or the custom element developer embed the input?
>>> And who is responsible for syncing the relevant attributes across? In
>>> reality, isn't this going to look more like
>>>
>>> 
>>> 
>>> 
>>>
>>> or as a slightly contrived example,
>>>
>>> 
>>> 
>>> 
>>>
>>> Or does the custom element get its state from the embedded element?
>>>
>>
>> the custom element uses its contents as input and, in the simplest sense,
>> just moves it or maps it during creation... In a more complicated world
>> with something more like shadow dom (a separate topic) it might be
>> 'projected'
>>
>
> It seems like it would have to be in the light DOM for things like labels,
> forms etc to work. So then how do we treat it as "fallback content" i.e.
> un-rendered, while allowing it to be accessible to to the AT layer?
>
>
> Since it's a fallback content, it would certainly be in the regular DOM
> even if we had shadow DOM.  FYI, this whole thread doesn't assume or
> preclude the existence of shadow DOM.  It is the responsibility for custom
> form elements users to put regular input elements inside them.
>
> - R. Niwa
>
>

Re: Minimum viable custom elements

[Steve Faulkner]

On 4 February 2015 at 19:05, Alice Boxhall  wrote:

> So then how do we treat it as "fallback content" i.e. un-rendered, while
> allowing it to be accessible to to the AT layer?


I suggest as in the working canvas example i provided, it not only be
exposed AT but also to keyboard interaction, and that the content inside
can be targeted for relationships such as





sign up


--

Regards

SteveF
HTML 5.1 

Re: Minimum viable custom elements

[Ryosuke Niwa]

> On Feb 4, 2015, at 11:26 AM, Alice Boxhall  wrote:
> 
> So a web page author would write
> 
> 
> and then the custom element would sprout an  with 
> the attribute values copied across?

No. The page author would write .

- R. Niwa

Are web components *seriously* not namespaced?

[Glen]

I know I'm rather late to the party, but I've been doing a lot of 
reading lately about web components and related technologies, and the 
one thing that confounds me is the fact that web components appear not 
to have any "real" namespacing.


Can someone explain why this is so, and what the justification is? Or is 
it just a case of "it was too complicated, this is good enough"?


I see this has been brought up once before @ 
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0964.html, 
but nothing changed.


It's not going to be long before  has been defined by 1,000,000 
people (slight exaggeration), and you have no idea what it is or where 
it came from without looking through imports/scripts etc. Also you want 
to keep things short, so you call your element  (you work for 
Monkey Solutions LLC), but then someone else on the team is importing 
 from Microsoft, and BAM!, you have another problem.


Why can't we do something like this?



var panel = document.registerElement("panel", {
namespace: "ms https://monkey-solutions.com/namespace";
});




var panel = document.registerElement("panel", {
namespace: "ms https://microsoft.com/namespace";
});






https://microsoft.com/namespace"; 
prefix="msft" />





You could also assign a prefix to all elements within a namespace like this:

https://microsoft.com/namespace"; 
prefix="msft" />


You can override the prefix multiple times and the closest  
definition is used.


Please note that the above syntax is just an example of what could be used.

Another BIG pro here is that IDEs can pull in information about the 
elements by sending an HTTP request to the namespace URI so that a 
tooltip could be displayed with an element description, author, sample 
usage, etc.


I really do hope that it's not too late to make such a change.

Regards,

Glen.

Re: Are web components *seriously* not namespaced?

[Glenn Adams]

On Wed, Feb 4, 2015 at 2:31 PM, Glen  wrote:

> I know I'm rather late to the party, but I've been doing a lot of reading
> lately about web components and related technologies, and the one thing
> that confounds me is the fact that web components appear not to have any
> "real" namespacing.
>

There is a serious antipathy towards XML in some quarters. So I believe the
vocabulary was designed for non-XML namespace aware parsers. Others can
verify my understanding (or not).


>
> Can someone explain why this is so, and what the justification is? Or is
> it just a case of "it was too complicated, this is good enough"?
>
> I see this has been brought up once before @ http://lists.w3.org/Archives/
> Public/public-webapps/2013AprJun/0964.html, but nothing changed.
>
> It's not going to be long before  has been defined by 1,000,000
> people (slight exaggeration), and you have no idea what it is or where it
> came from without looking through imports/scripts etc. Also you want to
> keep things short, so you call your element  (you work for Monkey
> Solutions LLC), but then someone else on the team is importing 
> from Microsoft, and BAM!, you have another problem.
>
> Why can't we do something like this?
>
> 
> 
> var panel = document.registerElement("panel", {
> namespace: "ms https://monkey-solutions.com/namespace";
> });
> 
>
> 
> 
> var panel = document.registerElement("panel", {
> namespace: "ms https://microsoft.com/namespace";
> });
> 
>
> 
> 
>
> 
> https://microsoft.com/namespace";
> prefix="msft" />
>
> 
> 
>
> You could also assign a prefix to all elements within a namespace like
> this:
>
> https://microsoft.com/namespace";
> prefix="msft" />
>
> You can override the prefix multiple times and the closest 
> definition is used.
>
> Please note that the above syntax is just an example of what could be used.
>
> Another BIG pro here is that IDEs can pull in information about the
> elements by sending an HTTP request to the namespace URI so that a tooltip
> could be displayed with an element description, author, sample usage, etc.
>
> I really do hope that it's not too late to make such a change.
>
> Regards,
>
> Glen.
>
>

Re: Are web components *seriously* not namespaced?

[Dimitri Glazkov]

The proposed solution is using registries:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578

The registry API hasn't been spec'd yet.

:DG<

On Wed, Feb 4, 2015 at 1:31 PM, Glen  wrote:

> I know I'm rather late to the party, but I've been doing a lot of reading
> lately about web components and related technologies, and the one thing
> that confounds me is the fact that web components appear not to have any
> "real" namespacing.
>
> Can someone explain why this is so, and what the justification is? Or is
> it just a case of "it was too complicated, this is good enough"?
>
> I see this has been brought up once before @ http://lists.w3.org/Archives/
> Public/public-webapps/2013AprJun/0964.html, but nothing changed.
>
> It's not going to be long before  has been defined by 1,000,000
> people (slight exaggeration), and you have no idea what it is or where it
> came from without looking through imports/scripts etc. Also you want to
> keep things short, so you call your element  (you work for Monkey
> Solutions LLC), but then someone else on the team is importing 
> from Microsoft, and BAM!, you have another problem.
>
> Why can't we do something like this?
>
> 
> 
> var panel = document.registerElement("panel", {
> namespace: "ms https://monkey-solutions.com/namespace";
> });
> 
>
> 
> 
> var panel = document.registerElement("panel", {
> namespace: "ms https://microsoft.com/namespace";
> });
> 
>
> 
> 
>
> 
> https://microsoft.com/namespace";
> prefix="msft" />
>
> 
> 
>
> You could also assign a prefix to all elements within a namespace like
> this:
>
> https://microsoft.com/namespace";
> prefix="msft" />
>
> You can override the prefix multiple times and the closest 
> definition is used.
>
> Please note that the above syntax is just an example of what could be used.
>
> Another BIG pro here is that IDEs can pull in information about the
> elements by sending an HTTP request to the namespace URI so that a tooltip
> could be displayed with an element description, author, sample usage, etc.
>
> I really do hope that it's not too late to make such a change.
>
> Regards,
>
> Glen.
>
>

Re: Are web components *seriously* not namespaced?

[Glen]

It doesn't really matter whether or not it's based on (or at least 
resembles) XML, as long as there is some way to specify (and redefine) 
the prefix of custom elements.


G.

On 2015/02/04 23:39, Glenn Adams wrote:



On Wed, Feb 4, 2015 at 2:31 PM, Glen > wrote:


I know I'm rather late to the party, but I've been doing a lot of
reading lately about web components and related technologies, and
the one thing that confounds me is the fact that web components
appear not to have any "real" namespacing.


There is a serious antipathy towards XML in some quarters. So I 
believe the vocabulary was designed for non-XML namespace aware 
parsers. Others can verify my understanding (or not).



Can someone explain why this is so, and what the justification is?
Or is it just a case of "it was too complicated, this is good enough"?

I see this has been brought up once before @
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0964.html,
but nothing changed.

It's not going to be long before  has been defined by
1,000,000 people (slight exaggeration), and you have no idea what
it is or where it came from without looking through
imports/scripts etc. Also you want to keep things short, so you
call your element  (you work for Monkey Solutions LLC),
but then someone else on the team is importing  from
Microsoft, and BAM!, you have another problem.

Why can't we do something like this?



var panel = document.registerElement("panel", {
namespace: "ms https://monkey-solutions.com/namespace";
});




var panel = document.registerElement("panel", {
namespace: "ms https://microsoft.com/namespace";
});






https://microsoft.com/namespace";
prefix="msft" />




You could also assign a prefix to all elements within a namespace
like this:

https://microsoft.com/namespace";
prefix="msft" />

You can override the prefix multiple times and the closest
 definition is used.

Please note that the above syntax is just an example of what could
be used.

Another BIG pro here is that IDEs can pull in information about
the elements by sending an HTTP request to the namespace URI so
that a tooltip could be displayed with an element description,
author, sample usage, etc.

I really do hope that it's not too late to make such a change.

Regards,

Glen.

Re: Are web components *seriously* not namespaced?

[William Edney]

Glen -

Glenn has the answer.

So we're going to come up with yet-another-registry rather than use one
that already exists and guarantees (at least as far can be guaranteed)
uniqueness: DNS.

The ramifications of not making HTML5 be XHTML5 will be with us for a very
long time indeed.

Cheers,

- Bill

On Wed, Feb 4, 2015 at 3:41 PM, Dimitri Glazkov  wrote:

> The proposed solution is using registries:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578
>
> The registry API hasn't been spec'd yet.
>
> :DG<
>
> On Wed, Feb 4, 2015 at 1:31 PM, Glen  wrote:
>
>> I know I'm rather late to the party, but I've been doing a lot of reading
>> lately about web components and related technologies, and the one thing
>> that confounds me is the fact that web components appear not to have any
>> "real" namespacing.
>>
>> Can someone explain why this is so, and what the justification is? Or is
>> it just a case of "it was too complicated, this is good enough"?
>>
>> I see this has been brought up once before @
>> http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0964.html,
>> but nothing changed.
>>
>> It's not going to be long before  has been defined by 1,000,000
>> people (slight exaggeration), and you have no idea what it is or where it
>> came from without looking through imports/scripts etc. Also you want to
>> keep things short, so you call your element  (you work for Monkey
>> Solutions LLC), but then someone else on the team is importing 
>> from Microsoft, and BAM!, you have another problem.
>>
>> Why can't we do something like this?
>>
>> 
>> 
>> var panel = document.registerElement("panel", {
>> namespace: "ms https://monkey-solutions.com/namespace";
>> });
>> 
>>
>> 
>> 
>> var panel = document.registerElement("panel", {
>> namespace: "ms https://microsoft.com/namespace";
>> });
>> 
>>
>> 
>> 
>>
>> 
>> https://microsoft.com/namespace";
>> prefix="msft" />
>>
>> 
>> 
>>
>> You could also assign a prefix to all elements within a namespace like
>> this:
>>
>> https://microsoft.com/namespace";
>> prefix="msft" />
>>
>> You can override the prefix multiple times and the closest 
>> definition is used.
>>
>> Please note that the above syntax is just an example of what could be
>> used.
>>
>> Another BIG pro here is that IDEs can pull in information about the
>> elements by sending an HTTP request to the namespace URI so that a tooltip
>> could be displayed with an element description, author, sample usage, etc.
>>
>> I really do hope that it's not too late to make such a change.
>>
>> Regards,
>>
>> Glen.
>>
>>
>

Re: Are web components *seriously* not namespaced?

[Glen]

Can either of you provide an example in layman's terms?

I don't quite understand what this will look like.

G.

On 2015/02/05 00:29, William Edney wrote:

Glen -

Glenn has the answer.

So we're going to come up with yet-another-registry rather than use 
one that already exists and guarantees (at least as far can be 
guaranteed) uniqueness: DNS.


The ramifications of not making HTML5 be XHTML5 will be with us for a 
very long time indeed.


Cheers,

- Bill

On Wed, Feb 4, 2015 at 3:41 PM, Dimitri Glazkov > wrote:


The proposed solution is using registries:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578

The registry API hasn't been spec'd yet.

:DG<

On Wed, Feb 4, 2015 at 1:31 PM, Glen mailto:glen...@gmail.com>> wrote:

I know I'm rather late to the party, but I've been doing a lot
of reading lately about web components and related
technologies, and the one thing that confounds me is the fact
that web components appear not to have any "real" namespacing.

Can someone explain why this is so, and what the justification
is? Or is it just a case of "it was too complicated, this is
good enough"?

I see this has been brought up once before @
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0964.html,
but nothing changed.

It's not going to be long before  has been defined by
1,000,000 people (slight exaggeration), and you have no idea
what it is or where it came from without looking through
imports/scripts etc. Also you want to keep things short, so
you call your element  (you work for Monkey
Solutions LLC), but then someone else on the team is importing
 from Microsoft, and BAM!, you have another problem.

Why can't we do something like this?



var panel = document.registerElement("panel", {
namespace: "ms https://monkey-solutions.com/namespace";
});




var panel = document.registerElement("panel", {
namespace: "ms https://microsoft.com/namespace";
});






https://microsoft.com/namespace"; prefix="msft" />




You could also assign a prefix to all elements within a
namespace like this:

https://microsoft.com/namespace";
prefix="msft" />

You can override the prefix multiple times and the closest
 definition is used.

Please note that the above syntax is just an example of what
could be used.

Another BIG pro here is that IDEs can pull in information
about the elements by sending an HTTP request to the namespace
URI so that a tooltip could be displayed with an element
description, author, sample usage, etc.

I really do hope that it's not too late to make such a change.

Regards,

Glen.

Re: Are web components *seriously* not namespaced?

[Tab Atkins Jr.]

On Thu, Feb 5, 2015 at 8:31 AM, Glen  wrote:
> I know I'm rather late to the party, but I've been doing a lot of reading
> lately about web components and related technologies, and the one thing that
> confounds me is the fact that web components appear not to have any "real"
> namespacing.

Prefix-based informal namespacing appears to be more than sufficient
for 90%+ of use-cases.  It works fine, for example, for the huge
collection of jQuery widgets/extensions.  Complicating things further
simply isn't all that necessary.

We do plan to help solve it at some point, as Dimitri says, as there
are some cases where real namespacing is useful.  In particular, if
you have a name that you can assume is globally unique with high
confidence, you can actually share custom elements across documents.
Within a single page, however, prefix-based informal namespaces are
nearly always sufficient.

XML Namespaces are a pox on the platform, however, and they'll
definitely not get reproduced in custom elements.  They have a number
of terrible affordances.

~TJ

Re: Shadow tree style isolation primitive

[Tab Atkins Jr.]

On Wed, Feb 4, 2015 at 11:36 PM, Olli Pettay  wrote:
> Why should even !important work if the component wants to use its own
> colors?

Because that's how !important usually works.  If the author has
progressed to the point of doing !important, we should assume that
they know what they're doing and let it work.  At the end of the day,
it should be possible for the outer page to have some way of styling
any part of a non-sealed (a la inputs, etc) shadow DOM.  Anyone
claiming this isn't necessary should be sentenced to a year of doing
web dev with jQuery components and hostile clients.

~TJ

Re: Shadow tree style isolation primitive

[Tab Atkins Jr.]

On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay  wrote:
> Why do we need shadow DOM (or something similar) at all if we expose it
> easily to the outside world.
> One could even now just require that elements in "components" in a web page
> have class="component", and then
> .component could be used as >>>. Sure, it would require :not(.component)
> usage too.
> And from DOM APIs side one could easily implement filtering for the contents
> of "components" using small script libraries.

Aa;erlhas;dlgpasodifapsldikjf;

I keep hearing this kind of sentiment pop up, and I'm like, have you
ever done serious webdev?  I know a lot of browser devs haven't, and I
don't know if you have or not, but this is the sort of thing that is
plain as day if you have.

You don't need strong isolation primitives to do a lot of good.
Simple composition helpers lift an *enormous* weight off the shoulders
of web devs, and make whole classes of bugs obsolete.  Shadow DOM is
precisely that composition helper right now.  In most contexts, you
can't ever touch something inside of shadow DOM unless you're doing it
on purpose, so there's no way to "friendly fire" (as Brian puts it).

Stronger isolation does solve some problems, sure.  But trying to
imply that those are the only problems we need to solve, because
they're the only problems related to "explaining the current DOM",
shows a serious lack of insight into the types of problems experienced
by webdevs today, when developing complex webapps.

There is no naming scheme that accomplishes this.  There is no amount
of discipline that will help.  Devs are humans, and webpages are very
complicated multi-party computer programs, and helping people organize
and manage that complexity is an enormous win.  Existing Shadow DOM
composition is a tailored solution to that.  If it looks complex, it's
because the platform is complex, and so there's a lot of interface to
deal with.  Its core, though, is just "what if this piece of the
document was hidden from the rest of the document by default", and you
can't cut away much of Shadow DOM without losing that entirely.



-

Separate-but-related rant: And like, the sort of mindset that can just
throw out "Sure, it would require :not(.component) usage too." like it
was just some simple thing, easy to implement and do, is amazing.
You'd need to spam that EVERYWHERE, on NEARLY ALL of your selectors,
and need to do it for EVERY COMPONENT.  Heck, to do it correctly, you
have to do in on EVERY COMPOUND SELECTOR *within* each selector.  It's
optimizing in the exact wrong direction; you have to explicitly say
every time that you don't want to match against a finite set of
components; missing it once, or adding a new component that you
haven't expressed in your
giant-list-of-exclusions-on-every-selector-in-your-page, means you've
got a potential styling bug.

I, just, man.  What.  I'm unclear how to have a productive discussion
when this is entertained as a serious suggestion.

~TJ

Re: Shadow tree style isolation primitive

[Ryosuke Niwa]

> On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr.  wrote:
> 
> On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay  wrote:
>> Why do we need shadow DOM (or something similar) at all if we expose it
>> easily to the outside world.
>> One could even now just require that elements in "components" in a web page
>> have class="component", and then
>> .component could be used as >>>. Sure, it would require :not(.component)
>> usage too.
>> And from DOM APIs side one could easily implement filtering for the contents
>> of "components" using small script libraries.
> 
> Aa;erlhas;dlgpasodifapsldikjf;
> 
> I keep hearing this kind of sentiment pop up, and I'm like, have you
> ever done serious webdev?  I know a lot of browser devs haven't, and I
> don't know if you have or not, but this is the sort of thing that is
> plain as day if you have.

That sounds rather demeaning and insulting [1].  public-webapps, or a mailing 
list of any W3C working group, isn't an appropriate forum to rant.

> You don't need strong isolation primitives to do a lot of good.
> Simple composition helpers lift an *enormous* weight off the shoulders
> of web devs, and make whole classes of bugs obsolete.  Shadow DOM is
> precisely that composition helper right now.  In most contexts, you
> can't ever touch something inside of shadow DOM unless you're doing it
> on purpose, so there's no way to "friendly fire" (as Brian puts it).
> 
> Stronger isolation does solve some problems, sure.  But trying to
> imply that those are the only problems we need to solve, because
> they're the only problems related to "explaining the current DOM",
> shows a serious lack of insight into the types of problems experienced
> by webdevs today, when developing complex webapps.

While I agree those are problems worth solving, let us recognize and respect 
that different participates of the working group care about different use cases 
and are interested in solving different set of problems.

> There is no naming scheme that accomplishes this.  There is no amount
> of discipline that will help.  Devs are humans, and webpages are very
> complicated multi-party computer programs, and helping people organize
> and manage that complexity is an enormous win.  Existing Shadow DOM
> composition is a tailored solution to that.  If it looks complex, it's
> because the platform is complex, and so there's a lot of interface to
> deal with.  Its core, though, is just "what if this piece of the
> document was hidden from the rest of the document by default", and you
> can't cut away much of Shadow DOM without losing that entirely.
...
> Separate-but-related rant: And like, the sort of mindset that can just
> throw out "Sure, it would require :not(.component) usage too." like it
> was just some simple thing, easy to implement and do, is amazing.
> You'd need to spam that EVERYWHERE, on NEARLY ALL of your selectors,
> and need to do it for EVERY COMPONENT.  Heck, to do it correctly, you
> have to do in on EVERY COMPOUND SELECTOR *within* each selector.  It's
> optimizing in the exact wrong direction; you have to explicitly say
> every time that you don't want to match against a finite set of
> components; missing it once, or adding a new component that you
> haven't expressed in your
> giant-list-of-exclusions-on-every-selector-in-your-page, means you've
> got a potential styling bug.

However, the use case we're talking here is multiple teams working on a single 
website potentially stepping on each other's toes; implying the enormous size 
of the entity working on the website.  I have a hard time imagining that any 
organization of that scale to not have a sever-side or pre-deployment build 
step for the website at which point they can add a preprocessing step to modify 
all selectors.  e.g. even a website I worked on with only four other people had 
a build step before we could deploy it.

[1] http://www.w3.org/Consortium/cepc/

- R. Niwa

Re: Shadow tree style isolation primitive

[Olli Pettay]

On 02/05/2015 01:20 AM, Tab Atkins Jr. wrote:

You don't need strong isolation primitives to do a lot of good.
Simple composition helpers lift an *enormous* weight off the shoulders
of web devs, and make whole classes of bugs obsolete.  Shadow DOM is
precisely that composition helper right now.  In most contexts, you
can't ever touch something inside of shadow DOM unless you're doing it
on purpose, so there's no way to "friendly fire" (as Brian puts it).


If we want to just help with composition, then we can find simpler
model than shadow DOM with its multiple shadow root per host and event handling
oddities and what not. (and all the mess with is-in-doc is still something to 
be sorted out etc.)






Stronger isolation does solve some problems, sure.  But trying to
imply that those are the only problems we need to solve,

No one has tried to imply that. I don't know where you got that.

Re: Shadow tree style isolation primitive

[Dimitri Glazkov]

On Wed, Feb 4, 2015 at 3:56 PM, Ryosuke Niwa  wrote:

>
> > On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr.  wrote:
> >
> > On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay  wrote:
> >> Why do we need shadow DOM (or something similar) at all if we expose it
> >> easily to the outside world.
> >> One could even now just require that elements in "components" in a web
> page
> >> have class="component", and then
> >> .component could be used as >>>. Sure, it would require :not(.component)
> >> usage too.
> >> And from DOM APIs side one could easily implement filtering for the
> contents
> >> of "components" using small script libraries.
> >
> > Aa;erlhas;dlgpasodifapsldikjf;
> >
> > I keep hearing this kind of sentiment pop up, and I'm like, have you
> > ever done serious webdev?  I know a lot of browser devs haven't, and I
> > don't know if you have or not, but this is the sort of thing that is
> > plain as day if you have.
>
> That sounds rather demeaning and insulting [1].  public-webapps, or a
> mailing list of any W3C working group, isn't an appropriate forum to rant.
>

+1.


> However, the use case we're talking here is multiple teams working on a
> single website potentially stepping on each other's toes; implying the
> enormous size of the entity working on the website.  I have a hard time
> imagining that any organization of that scale to not have a sever-side or
> pre-deployment build step for the website at which point they can add a
> preprocessing step to modify all selectors.  e.g. even a website I worked
> on with only four other people had a build step before we could deploy it.
>

The need to modify selectors on the server side is highly symptomatic of
the composition problem remaining unsolved. This processing is not due to
the burning desire of the developers to munge their selectors, but rather
due to their inability to reason about the composition of styles, and
having to rely on out-of-band composition.

For all the criticism Shadow DOM receives, it is currently the only
solution that solves this problem. As I mentioned before, I am very open to
using Shadow DOM to extract a simpler primitive that is more focused on
solving the style composition problem in-band.

However, I would like to first understand if that is the problem that the
group wants to solve. It is unclear from this conversation.

:DG<

Re: Shadow tree style isolation primitive

[Tab Atkins Jr.]

On Thu, Feb 5, 2015 at 10:56 AM, Ryosuke Niwa  wrote:
>> On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr.  wrote:
>> On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay  wrote:
>>> Why do we need shadow DOM (or something similar) at all if we expose it
>>> easily to the outside world.
>>> One could even now just require that elements in "components" in a web page
>>> have class="component", and then
>>> .component could be used as >>>. Sure, it would require :not(.component)
>>> usage too.
>>> And from DOM APIs side one could easily implement filtering for the contents
>>> of "components" using small script libraries.
>>
>> Aa;erlhas;dlgpasodifapsldikjf;
>>
>> I keep hearing this kind of sentiment pop up, and I'm like, have you
>> ever done serious webdev?  I know a lot of browser devs haven't, and I
>> don't know if you have or not, but this is the sort of thing that is
>> plain as day if you have.
>
> That sounds rather demeaning and insulting [1].  public-webapps, or a mailing 
> list of any W3C working group, isn't an appropriate forum to rant.

Most browser devs are not webdevs.  This is not an insult nor is it
demeaning.  I've been a member of the W3C for many years, and problems
with browser devs not understanding the issues of real webdevs "on the
ground" have always been rampant.  It's a large part of the reason I
joined the W3C in the first place, so I could help develop CSS specs
that were important for webdevs but being ignored by the browser devs
in the group.

If you find that demeaning, I'm sorry?  It's not something you can
ignore; it's always an elephant in the room when trying to solve
problems that frustrate webdevs.  It really is important to ensure
that browser devs sit down and listen to people with real webdev
experience (such as, for example, Brian Kardell).

>> You don't need strong isolation primitives to do a lot of good.
>> Simple composition helpers lift an *enormous* weight off the shoulders
>> of web devs, and make whole classes of bugs obsolete.  Shadow DOM is
>> precisely that composition helper right now.  In most contexts, you
>> can't ever touch something inside of shadow DOM unless you're doing it
>> on purpose, so there's no way to "friendly fire" (as Brian puts it).
>>
>> Stronger isolation does solve some problems, sure.  But trying to
>> imply that those are the only problems we need to solve, because
>> they're the only problems related to "explaining the current DOM",
>> shows a serious lack of insight into the types of problems experienced
>> by webdevs today, when developing complex webapps.
>
> While I agree those are problems worth solving, let us recognize and respect 
> that different participates of the working group care about different use 
> cases and are interested in solving different set of problems.

That's precisely what I'm getting frustrated with - when people make
suggestions that composition isn't important, and people can "just use
better selectors and some discipline" to solve those problems, it
makes it difficult to have productive conversations.  Composition is a
massive problem with today's webapps.  Isolation is a minor problem
that is important for some valuable use-cases, so it shouldn't be
ignored, but neither should it be elevated to the sole important thing
to be discussed here.

>> There is no naming scheme that accomplishes this.  There is no amount
>> of discipline that will help.  Devs are humans, and webpages are very
>> complicated multi-party computer programs, and helping people organize
>> and manage that complexity is an enormous win.  Existing Shadow DOM
>> composition is a tailored solution to that.  If it looks complex, it's
>> because the platform is complex, and so there's a lot of interface to
>> deal with.  Its core, though, is just "what if this piece of the
>> document was hidden from the rest of the document by default", and you
>> can't cut away much of Shadow DOM without losing that entirely.
> ...
>> Separate-but-related rant: And like, the sort of mindset that can just
>> throw out "Sure, it would require :not(.component) usage too." like it
>> was just some simple thing, easy to implement and do, is amazing.
>> You'd need to spam that EVERYWHERE, on NEARLY ALL of your selectors,
>> and need to do it for EVERY COMPONENT.  Heck, to do it correctly, you
>> have to do in on EVERY COMPOUND SELECTOR *within* each selector.  It's
>> optimizing in the exact wrong direction; you have to explicitly say
>> every time that you don't want to match against a finite set of
>> components; missing it once, or adding a new component that you
>> haven't expressed in your
>> giant-list-of-exclusions-on-every-selector-in-your-page, means you've
>> got a potential styling bug.
>
> However, the use case we're talking here is multiple teams working on a 
> single website potentially stepping on each other's toes; implying the 
> enormous size of the entity working on the website.  I have a hard time 
> imagining that any organization of that scal

Re: Shadow tree style isolation primitive

[Tab Atkins Jr.]

On Thu, Feb 5, 2015 at 11:03 AM, Olli Pettay  wrote:
> On 02/05/2015 01:20 AM, Tab Atkins Jr. wrote:
>> You don't need strong isolation primitives to do a lot of good.
>> Simple composition helpers lift an *enormous* weight off the shoulders
>> of web devs, and make whole classes of bugs obsolete.  Shadow DOM is
>> precisely that composition helper right now.  In most contexts, you
>> can't ever touch something inside of shadow DOM unless you're doing it
>> on purpose, so there's no way to "friendly fire" (as Brian puts it).
>
> If we want to just help with composition, then we can find simpler
> model than shadow DOM with its multiple shadow root per host and event
> handling
> oddities and what not. (and all the mess with is-in-doc is still something
> to be sorted out etc.)

Try to. ^_^

>> Stronger isolation does solve some problems, sure.  But trying to
>> imply that those are the only problems we need to solve,
>
> No one has tried to imply that. I don't know where you got that.

By your statements implying that composition issues can just be
handled by better discipline and some selector modification, in the
message I responded to earlier.  I'm not sure how to interpret those
statement if you didn't mean that composition wasn't worth solving.

~TJ

Re: Are web components *seriously* not namespaced?

[Kurt Cagle]

I predict that sometime around 2025, we will end up redefining namespaces
because the number of jQuery-like components have ballooned into the
millions, the web has descended once again into a sea of interoperability,
and registries will, once again, have proven to be a bottleneck, as they
have EVERY SINGLE TIME they have been implemented.

Of course, they won't be called namespaces, and they'll probably use a dash
instead of a colon , and they definitely won't be XML based because
everyone knows that XML is EVIL ... (sigh) !

Kurt Cagle
Principle Evangelist, Semantic Technologies
Avalon Consulting, LLC
kurt.ca...@gmail.com, personal
cag...@avalonconsult.com, business
443-837-8725



On Wed, Feb 4, 2015 at 2:58 PM, Tab Atkins Jr.  wrote:

> On Thu, Feb 5, 2015 at 8:31 AM, Glen  wrote:
> > I know I'm rather late to the party, but I've been doing a lot of reading
> > lately about web components and related technologies, and the one thing
> that
> > confounds me is the fact that web components appear not to have any
> "real"
> > namespacing.
>
> Prefix-based informal namespacing appears to be more than sufficient
> for 90%+ of use-cases.  It works fine, for example, for the huge
> collection of jQuery widgets/extensions.  Complicating things further
> simply isn't all that necessary.
>
> We do plan to help solve it at some point, as Dimitri says, as there
> are some cases where real namespacing is useful.  In particular, if
> you have a name that you can assume is globally unique with high
> confidence, you can actually share custom elements across documents.
> Within a single page, however, prefix-based informal namespaces are
> nearly always sufficient.
>
> XML Namespaces are a pox on the platform, however, and they'll
> definitely not get reproduced in custom elements.  They have a number
> of terrible affordances.
>
> ~TJ
>
>

Re: Are web components *seriously* not namespaced?

[Tab Atkins Jr.]

On Thu, Feb 5, 2015 at 12:00 PM, Kurt Cagle  wrote:
> I predict that sometime around 2025, we will end up redefining namespaces
> because the number of jQuery-like components have ballooned into the
> millions, the web has descended once again into a sea of interoperability,
> and registries will, once again, have proven to be a bottleneck, as they
> have EVERY SINGLE TIME they have been implemented.

Yes, real namespacing does eventually prove necessary as the
population grows.  That's fine.  It's something that can be added
organically as necessary; letting everything live in the null
namespace first doesn't harm future namespacing efforts.

> Of course, they won't be called namespaces, and they'll probably use a dash
> instead of a colon , and they definitely won't be XML based because everyone
> knows that XML is EVIL ... (sigh) !

There are more namespacing solutions in heaven and earth, Horatio,
than are dreamt of in your XML.  Most of them don't commit the same
mistakes that XML namespaces did.

~TJ

Re: Are web components *seriously* not namespaced?

[Benjamin Goering]

Glad to see this. I was 'checking in' on the professional practicalities of
custom elements earlier this week, and was pretty bummed when I couldn't
use XHTML5 namespaces for my employer's organization.

I build widgets all day. They run in inhospitable that websites I'm not in
control of. They have so many globals I just can't even. I get planning,
execution, and/or distribution friction when the standards prevent be from
creating a truly universal web component that will work in all those
environments.

To Tab's point, I don't think that will prevent a 90%-sufficient solution,
or one that is 99%-sufficient for some subset of the potential market.
But I do agree with Kurt that eventually it seems like 'the right way'.

It seems valuable today to at least standardize and have a spec for XHTML5
Custom Elements (e.g. ). <1% of sites will actually use
these in a way that fully validates against XHTML5. But at least web
authors and developers will be using the web instead of Contrived
JavaScript Embeds.

With a vote of confidence (or better yet spec) on the consistency of XHTML5
Custom Elements, I see no reason why I couldn't in the interim use this,
and sleep at night knowing it will eventually be the way the web actually
works:

https://html.my-vendor.com/elements";>



or

https://html.my-vendor.com/elements";>




One of the cool things about this is: Let's say in that last example I need
to switch vendors or change where in the cloud my elements come from (e.g.
QA, Staging, Production). All I need to change is the xmlns URL in that one
attribute.

Critiques?

--
Benjamin Goering - @bengo
Platform @Livefyre Labs

On Wed, Feb 4, 2015 at 5:15 PM, Tab Atkins Jr.  wrote:

> On Thu, Feb 5, 2015 at 12:00 PM, Kurt Cagle  wrote:
> > I predict that sometime around 2025, we will end up redefining namespaces
> > because the number of jQuery-like components have ballooned into the
> > millions, the web has descended once again into a sea of
> interoperability,
> > and registries will, once again, have proven to be a bottleneck, as they
> > have EVERY SINGLE TIME they have been implemented.
>
> Yes, real namespacing does eventually prove necessary as the
> population grows.  That's fine.  It's something that can be added
> organically as necessary; letting everything live in the null
> namespace first doesn't harm future namespacing efforts.
>
> > Of course, they won't be called namespaces, and they'll probably use a
> dash
> > instead of a colon , and they definitely won't be XML based because
> everyone
> > knows that XML is EVIL ... (sigh) !
>
> There are more namespacing solutions in heaven and earth, Horatio,
> than are dreamt of in your XML.  Most of them don't commit the same
> mistakes that XML namespaces did.
>
> ~TJ
>
>

[Bug 27965] New: [Shadow]: Shadow host with tabindex=-1, all descendent tree should be ignored for tab navigation

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27965

Bug ID: 27965
   Summary: [Shadow]: Shadow host with tabindex=-1, all descendent
tree should be ignored for tab navigation
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: ko...@google.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 14978

In the current Shadow DOM spec, basically focusable nodes in a shadow tree are
inserted after their shadow host in the tab navigation order.

This means that when shadow host has "tabindex=-1", the host itself is skipped
in the order, but right after the host the descendant nodes in its shadow tree
will be visited.

This is probably not the behavior that a component author or user would expect.

-- 
You are receiving this mail because:
You are on the CC list for the bug.