Re: Shadow tree style isolation primitive
On Feb 4, 2015, at 4:56 AM, Olli Pettay o...@pettay.fi 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 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/ 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
On Feb 4, 2015, at 7:59 AM, Domenic Denicola d...@domenic.me wrote: In IRC Anne and I were briefly discussing how type= is the is= of Web Applications 1.0. That is, input type=date is similar to img is=x-gif or similar---it has a reasonable fallback behavior, but in reality it is a completely different control than the local name indicates. For input type 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 input type= in favor of control is= 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
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 rn...@apple.com wrote: See https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0435.html https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0435.html first. On Feb 4, 2015, at 6:43 AM, Chris Bateman chrisb...@gmail.com 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: - input is=my-custom-formatter - input class=my-custom-formatter and a page-level listener - input class=my-custom-formatter and call a function after it's injected Or my-custom-formatterinput/my-custom-formatter. 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 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. input type=text is=my-custom-formatter 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
On 4 February 2015 at 16:51, Ryosuke Niwa rn...@apple.com wrote: my-custom-formatterinput/my-custom-formatter 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 canvas to host a checkbox, as an experiment: http://codepen.io/stevef/pen/OPxvZX note: am not saying canvas 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 http://www.w3.org/html/wg/drafts/html/master/
Re: Minimum viable custom elements
See https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0435.html https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0435.html first. On Feb 4, 2015, at 6:43 AM, Chris Bateman chrisb...@gmail.com 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: - input is=my-custom-formatter - input class=my-custom-formatter and a page-level listener - input class=my-custom-formatter and call a function after it's injected Or my-custom-formatterinput/my-custom-formatter. 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 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. input type=text is=my-custom-formatter 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
Ted Dinklocker Introduction
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: Minimum viable custom elements
On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com wrote: On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com wrote: On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com wrote: On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com 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: input is=x-foo x-fooinput/x-foo 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 x-checkbox checked=true input type=checkbox checked=true /x-checkbox or as a slightly contrived example, x-slider min=-100 max=100 value=0 step=5 input type=range min=-100 max=100 value=0 step=5 /x-slider 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
So a web page author would write x-slider min=-100 ... etc. and then the custom element would sprout an input type=range ...etc with the attribute values copied across? Then the web page author knows nothing about the input element, so if they want to programmatically the value of the custom element, they'd modify an attribute on it, rather than the input, right? So you'd have to keep them in sync regardless. On Wed, Feb 4, 2015 at 11:14 AM, Ryosuke Niwa rn...@apple.com wrote: On Feb 4, 2015, at 11:05 AM, Alice Boxhall aboxh...@google.com wrote: On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell bkard...@gmail.com wrote: On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com wrote: On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com wrote: On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com wrote: On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com 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: input is=x-foo x-fooinput/x-foo 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 x-checkbox checked=true input type=checkbox checked=true /x-checkbox or as a slightly contrived example, x-slider min=-100 max=100 value=0 step=5 input type=range min=-100 max=100 value=0 step=5 /x-slider 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
On Feb 4, 2015, at 11:26 AM, Alice Boxhall aboxh...@google.com wrote: So a web page author would write x-slider min=-100 ... etc. and then the custom element would sprout an input type=range ...etc with the attribute values copied across? No. The page author would write x-sliderinput min=-100 …/x-slider. - R. Niwa
Re: Minimum viable custom elements
On Feb 4, 2015, at 10:54 AM, Alice Boxhall aboxh...@google.com wrote: On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com mailto:bkard...@gmail.com wrote: On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com mailto:chrisb...@gmail.com 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: input is=x-foo x-fooinput/x-foo 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 x-checkbox checked=true input type=checkbox checked=true /x-checkbox or as a slightly contrived example, x-slider min=-100 max=100 value=0 step=5 input type=range min=-100 max=100 value=0 step=5 /x-slider 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: x-checkboxinput type=checkbox checked=true/x-checkbox x-sliderinput type=range min=-100 max=100 value=0 step=5/x-slider 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
On Feb 4, 2015, at 11:11 AM, Chris Bateman chrisb...@gmail.com 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
On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com 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: input is=x-foo x-fooinput/x-foo seems like barely a ternseness savings worth discussing. -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Minimum viable custom elements
On Feb 4, 2015, at 9:05 AM, Steve Faulkner faulkner.st...@gmail.com wrote: On 4 February 2015 at 16:51, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: my-custom-formatterinput/my-custom-formatter 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 canvas to host a checkbox, as an experiment: http://codepen.io/stevef/pen/OPxvZX http://codepen.io/stevef/pen/OPxvZX note: am not saying canvas 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 chrisb...@gmail.com 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
On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell bkard...@gmail.com wrote: On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com wrote: On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com wrote: On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com wrote: On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com 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: input is=x-foo x-fooinput/x-foo 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 x-checkbox checked=true input type=checkbox checked=true /x-checkbox or as a slightly contrived example, x-slider min=-100 max=100 value=0 step=5 input type=range min=-100 max=100 value=0 step=5 /x-slider 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
On 4 February 2015 at 19:05, Alice Boxhall aboxh...@google.com 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 label x-checkbox input type=checkbox checked=true /x-checkbox sign up /label -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
Re: Minimum viable custom elements
On Feb 4, 2015, at 11:05 AM, Alice Boxhall aboxh...@google.com wrote: On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell bkard...@gmail.com mailto:bkard...@gmail.com wrote: On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com mailto:aboxh...@google.com wrote: On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com mailto:bkard...@gmail.com wrote: On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com mailto:chrisb...@gmail.com 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: input is=x-foo x-fooinput/x-foo 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 x-checkbox checked=true input type=checkbox checked=true /x-checkbox or as a slightly contrived example, x-slider min=-100 max=100 value=0 step=5 input type=range min=-100 max=100 value=0 step=5 /x-slider 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
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 bkard...@gmail.com wrote: On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com wrote: On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com wrote: On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com wrote: On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com 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: input is=x-foo x-fooinput/x-foo 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 x-checkbox checked=true input type=checkbox checked=true /x-checkbox or as a slightly contrived example, x-slider min=-100 max=100 value=0 step=5 input type=range min=-100 max=100 value=0 step=5 /x-slider 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
Are web components *seriously* not namespaced?
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 x-tabs 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 ms-panel (you work for
Monkey Solutions LLC), but then someone else on the team is importing
ms-panel from Microsoft, and BAM!, you have another problem.
Why can't we do something like this?
!-- /scripts/monkey-solutions/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://monkey-solutions.com/namespace;
});
/script
!-- /scripts/microsoft/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://microsoft.com/namespace;
});
/script
!-- Uses last defined element, as it currently works. --
ms-panel
!-- Redefine the namespace prefix for one of the custom elements. --
element name=panel namespace=https://microsoft.com/namespace;
prefix=msft /
ms-panel
msft-panel
You could also assign a prefix to all elements within a namespace like this:
element name=* namespace=https://microsoft.com/namespace;
prefix=msft /
You can override the prefix multiple times and the closest element
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?
On Wed, Feb 4, 2015 at 2:31 PM, Glen 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.
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 x-tabs 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 ms-panel (you work for Monkey
Solutions LLC), but then someone else on the team is importing ms-panel
from Microsoft, and BAM!, you have another problem.
Why can't we do something like this?
!-- /scripts/monkey-solutions/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://monkey-solutions.com/namespace;
});
/script
!-- /scripts/microsoft/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://microsoft.com/namespace;
});
/script
!-- Uses last defined element, as it currently works. --
ms-panel
!-- Redefine the namespace prefix for one of the custom elements. --
element name=panel namespace=https://microsoft.com/namespace;
prefix=msft /
ms-panel
msft-panel
You could also assign a prefix to all elements within a namespace like
this:
element name=* namespace=https://microsoft.com/namespace;
prefix=msft /
You can override the prefix multiple times and the closest element
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?
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 glen...@gmail.com
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.
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 x-tabs 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 ms-panel (you work for Monkey Solutions LLC),
but then someone else on the team is importing ms-panel from
Microsoft, and BAM!, you have another problem.
Why can't we do something like this?
!-- /scripts/monkey-solutions/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://monkey-solutions.com/namespace;
});
/script
!-- /scripts/microsoft/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://microsoft.com/namespace;
});
/script
!-- Uses last defined element, as it currently works. --
ms-panel
!-- Redefine the namespace prefix for one of the custom elements. --
element name=panel namespace=https://microsoft.com/namespace;
prefix=msft /
ms-panel
msft-panel
You could also assign a prefix to all elements within a namespace
like this:
element name=* namespace=https://microsoft.com/namespace;
prefix=msft /
You can override the prefix multiple times and the closest
element 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: Minimum viable custom elements
Assuming a situation where a native element – with custom functionality – is dynamically injected into the page, the basic options I can think of are: - input is=my-custom-formatter - input class=my-custom-formatter and a page-level listener - input class=my-custom-formatter 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 time is=relative-time 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. input type=text is=my-custom-formatter 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 rn...@apple.com wrote: On Feb 3, 2015, at 7:13 AM, Chris Bateman chrisb...@gmail.com 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 textarea 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: Minimum viable custom elements
On Wed, Feb 4, 2015 at 3:43 PM, Chris Bateman chrisb...@gmail.com wrote:
An better example of both A and B (than my previous hypothetical) might be
GitHub's time is=relative-time 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 relative-time.
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
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 input discussion. In IRC Anne and I were briefly discussing how type= is the is= of Web Applications 1.0. That is, input type=date is similar to img is=x-gif or similar---it has a reasonable fallback behavior, but in reality it is a completely different control than the local name indicates. For input type 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 input type= in favor of control is= or something). But those seem pretty speculative.
Re: Shadow tree style isolation primitive
On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay o...@pettay.fi 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
On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay o...@pettay.fi 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
On Thu, Feb 5, 2015 at 10:56 AM, Ryosuke Niwa rn...@apple.com wrote: On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay o...@pettay.fi 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 scale to not have a sever-side or pre-deployment build step for the website at which point
Re: Shadow tree style isolation primitive
On Thu, Feb 5, 2015 at 11:03 AM, Olli Pettay o...@pettay.fi 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: Shadow tree style isolation primitive
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
On Wed, Feb 4, 2015 at 3:56 PM, Ryosuke Niwa rn...@apple.com wrote: On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay o...@pettay.fi 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: Are web components *seriously* not namespaced?
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 dglaz...@google.com 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 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 x-tabs 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 ms-panel (you work for Monkey
Solutions LLC), but then someone else on the team is importing ms-panel
from Microsoft, and BAM!, you have another problem.
Why can't we do something like this?
!-- /scripts/monkey-solutions/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://monkey-solutions.com/namespace;
});
/script
!-- /scripts/microsoft/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://microsoft.com/namespace;
});
/script
!-- Uses last defined element, as it currently works. --
ms-panel
!-- Redefine the namespace prefix for one of the custom elements. --
element name=panel namespace=https://microsoft.com/namespace;
prefix=msft /
ms-panel
msft-panel
You could also assign a prefix to all elements within a namespace like
this:
element name=* namespace=https://microsoft.com/namespace;
prefix=msft /
You can override the prefix multiple times and the closest element
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?
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 dglaz...@google.com
mailto:dglaz...@google.com 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 glen...@gmail.com
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 x-tabs 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 ms-panel (you work for Monkey
Solutions LLC), but then someone else on the team is importing
ms-panel from Microsoft, and BAM!, you have another problem.
Why can't we do something like this?
!-- /scripts/monkey-solutions/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://monkey-solutions.com/namespace;
});
/script
!-- /scripts/microsoft/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://microsoft.com/namespace;
});
/script
!-- Uses last defined element, as it currently works. --
ms-panel
!-- Redefine the namespace prefix for one of the custom
elements. --
element name=panel
namespace=https://microsoft.com/namespace; prefix=msft /
ms-panel
msft-panel
You could also assign a prefix to all elements within a
namespace like this:
element name=* namespace=https://microsoft.com/namespace;
prefix=msft /
You can override the prefix multiple times and the closest
element 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?
On Thu, Feb 5, 2015 at 8:31 AM, Glen 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. 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?
On Thu, Feb 5, 2015 at 12:00 PM, Kurt Cagle kurt.ca...@gmail.com 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?
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. jackalm...@gmail.com wrote: On Thu, Feb 5, 2015 at 8:31 AM, Glen 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. 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
[Bug 27965] New: [Shadow]: Shadow host with tabindex=-1, all descendent tree should be ignored for tab navigation
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.
Re: Shadow tree style isolation primitive
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 bkard...@gmail.com mailto:bkard...@gmail.com wrote: On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay o...@pettay.fi 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/ 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: [IndexedDB] link to Editor's draft is a 404
On Wed, Feb 4, 2015 at 8:37 AM, Tobie Langel tobie.lan...@gmail.com wrote: On Wed, Feb 4, 2015 at 3:35 AM, Michael[tm] Smith m...@w3.org wrote: Arthur Barstow art.bars...@gmail.com, 2015-02-02 08:47 -0500: Archived-At: http://www.w3.org/mid/54cf7fe0.6090...@gmail.com 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
On 02/03/2015 04:22 PM, Brian Kardell wrote: On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay o...@pettay.fi 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/ 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 http://hitchjs.com/
Re: Shadow tree style isolation primitive
On Wed, Feb 4, 2015 at 7:56 AM, Olli Pettay o...@pettay.fi 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 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/ 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. [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: Shadow tree style isolation primitive
On Wed, Feb 4, 2015 at 11:36 PM, Olli Pettay o...@pettay.fi 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: Are web components *seriously* not namespaced?
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. my-vendor:jquery/). 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: html xmlns:my-vendor=https://html.my-vendor.com/elements; span is=my-vendor:jquery / /html or div xmlns=https://html.my-vendor.com/elements; span is=jquery@~2.9 / span is=react@^1.3 / /div 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. jackalm...@gmail.com wrote: On Thu, Feb 5, 2015 at 12:00 PM, Kurt Cagle kurt.ca...@gmail.com 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
