Re: [webcomponents]: Re-imagining shadow root as Element
AFAICT this has several ramifications: .) Being an element, you now have a render box for each shadowroot, in addition to the render box for the host element. Those may be beneficial or just superfluous by themselves, but they may result in cases where there is a gap between the host's box and the shadowroot's box. We had rich text editing bugs because of such scenarios, e.g., when the user clicked within such a gap. .) Being an element, can a shadowroot can itself have a shadowroot?. Contrast: div shadowroot.../shadowroot shadowroot.../shadowroot vs: div shadowroot shadowroot .) Similar to the above: can content and shadow have shadowroot children? .) Behavior of a DocumentFragment being inserted into the document also needs twizzling if it contains a shadowroot. - Roland On Tue, Mar 19, 2013 at 6:59 AM, Rafael Weinstein rafa...@google.comwrote: FWIW (and I'm not sure if this is good or bad) it would be consistent with the template element if -shadowroot serialized by default with innerHTML -shadowroot, when parsed is lifted and pushed onto the parent element's shadowroot stack -appendChild(shadowroot) doesn't throw, but doesn't do what you probably want (e.g. shadowroot is simply display:none if not attached to a host). (I imagine there would be imperative API on element, so that the correct imperative operation was to directly push a new shadowroot() onto an element, rather than using appendChild. Of course, if serialization round-tripping is non-lossy, this raises the question about implicit shadow roots (i.e. the element is registered and *creates* its shadowroots whenever it is created). On Mon, Mar 18, 2013 at 2:38 PM, Scott Miles sjmi...@google.com wrote: Sorry if I'm clobbering this thread, I promise to stop after this, but I solved my own mental model. Namely, I decide to treat shadowroot like outerHTML. If I define (pseudo): div id=A shadowroot span id=B shadowroot ... The A.innerHTML == span id=Bshadowroot... I don't see A's shadowroot, because it's really part of it's outer-ness. It's part of what makes A, it's not part of A's content. Now I can send A's innerHTML to B with no problem. Or roundtrip A's content with no problem. I realize I've broken several standard laws, but in any event it seems consistent to itself. On Mon, Mar 18, 2013 at 2:08 PM, Scott Miles sjmi...@google.com wrote: Ok, well obviously, there are times when you don't want the shadowroot to be in innerHTML, so I was correct that I was grossly over simplifying. I guess this is where the second kind of innHTML accessor comes in. Sorry! It's still A though. :) On Mon, Mar 18, 2013 at 2:05 PM, Scott Miles sjmi...@google.com wrote: I'm already on the record with A, but I have a question about 'lossiness'. With my web developer hat on, I wonder why I can't say: div id=foo shadowroot shadow stuff /shadowroot light stuff /div and then have the value of #foo.innerHTML still be shadowroot shadow stuff /shadowroot lightstuff I understand that for DOM, there is a wormhole there and the reality of what this means is new and frightening; but as a developer it seems to be perfectly fine as a mental model. We web devs like to grossly oversimplify things. :) Scott On Mon, Mar 18, 2013 at 1:53 PM, Dimitri Glazkov dglaz...@google.com wrote: Last Friday, still energized after the productive Mozilla/Google meeting, a few of us (cc'd) dug into Shadow DOM. And boy, did that go south quickly! But let's start from the top. We puzzled over the the similarity of two seemingly disconnected problems: a) ShadowRoot is a DocumentFragment and not an Element, and b) there is no declarative way to specify shadow trees. The former is well-known (see http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg356 ). The latter came into view very early as a philosophical problem (provide declarative syntax for new imperative APIs) and much later as a practical problem: many modern apps use a freeze-drying performance technique where they load as-rendered HTML content of a page on immediately (so that the user sees content immediately), and only later re-hydrate it with script. With shadow DOM, the lack of declarative syntax means that the content will not appear as-rendered until the script starts running, thus ruining the whole point of freeze-drying. We intentionally stayed away from the arguments like well, with custom elements, all of this happens without script. We did this precisely because we wanted to understand what all of this happens actually means. Trapped between these two problems, we caved in and birthed a new element. Let's call it shadowroot (Second Annual Naming Contest begins in 3.. 2.. ).
Re: [webcomponents] HTML Parsing and the template element
On Thu, Feb 9, 2012 at 13:45, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Feb 8, 2012 at 8:16 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Feb 8, 2012 at 7:31 PM, Brian Kardell bkard...@gmail.com wrote: Then why not something like template id=aworld/template template id=bhello partial with=a/template Right. If we were to disallow nested templates, that's the way to go. The question is whether we should disallow nested templates or not. Okay, I am changing my mind. I don't think we should gate this discussion on whether nested template elements should be allowed. First, it's a very drastic design decision that will do doubt hinder the developers of templating libraries. Honestly, I wonder if we should always aim to avoid making these types of decisions at a platform level. Second, it possibly doesn't even matter. If and only if we decide that the contents of template element MUST be perceived as a string--not a DOM subtree--will we face the question of disallowing nested templates. As demonstrated in IDEA 2, we can still totally still produce usable--nested or not--inert chunks of DOM, per initial requirements. So I think we should get back to answering the question: is it crucial that template contents are parsed as a character stream? From there, we can walk either toward puzzling over nested templates or just moving along, nothing to see here. In my experience, things like asymmetrical templates (e.g., containing an opening tag only) look very useful at first, but turn out to cause more headaches than they are worth in the long run. E.g., causing ugly errors when you instantiate a start template, but not an end template, or even simply the point of time between instantiating the start and the end. You cannot clone such a template's content, etc. To raise another facet (and please excuse if this has already been discussed and settled): Do we want to be able to manipulate the contents of a template via JS? This would seem more useful to me than character streams. I remember good arguments pro and contra on this a while back. Cheers, - Roland
Re: querySelectorAll() -- selecting _immediate_ children of element
This has actually been discussed quite a bit on this list, in various
contexts - for example see
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0277.html(except
that you have to substitute :scope for your proposed :this).
Cheers,
- Roland
On Mon, Jan 9, 2012 at 23:46, Marat Tanalin | tanalin.com
mtana...@yandex.ru wrote:
querySelector() and querySelectorAll() methods are exciting features, but
they do not allow select _immediate_ children of reference element.
To address this lack, we could use following syntax:
var divs = refElement.querySelectorAll(' DIV');
Here 'divs' variable contains list of DIV elements that are immediate
children (not just descendant elements) of reference element (refElement).
This syntax is extremely intuitive and BTW is supported in jQuery.
Other combinators (e.g. adjacent-sibling combinator) would have sense too,
for example:
var span = h1.querySelector('+ H2 SPAN');
'span' variable here contains DOM reference to SPAN elements inside H2
element which is next sibling of H1 element:
h1.../h1
h2... span.../span .../h2
But fundamental missing demanded feature is ability to select _child_
elements of reference element ( querySelectorAll(' DIV') ).
Since usecases are purely script-level, CSSWG has nothing to do with this
syntax. From selectors perspective, there is nothing new here: we have
reference element (in CSS, a selector is used in place of concrete
element), standard selector (DIV), and standard combinator between them.
An acceptable alternative to implied reference element would be using
':this' pseudoclass:
var divs = refElement.querySelectorAll(':this DIV');
var span = h1.querySelector(':this + H2 SPAN');
Furthermore, :this pseudoclass would give us additional possibilities such
as selecting descendant elements via selectors _all_ parts of which matches
to descendants of reference element.
For example, following code will select all links that are descendants of
_any_ paragraph (not necessarily descendants of reference element):
refElement.querySelectorAll('P A');
As opposed, this code:
refElement.querySelectorAll(':this P A');
would select links that are inside of paragraphs which _themselves_ are
descendants of the reference element.
Probably most DRY, usable, and flexible solution would be to allow both
syntaxes: implied reference element to use with combinators (where :this
would be just redundant), and explicit :this to use in conjunction with
descendant selectors (where it really gives additional useful possibilities
missing in current querySelector spec and implementations).
Thanks.
P.S. The proposal has been originally posted in public-script-coord (
http://lists.w3.org/Archives/Public/public-script-coord/2012JanMar/0078.html)
but it seems public-webapps is probably more appropriate place for this.
Re: [Component Model] Decorator Challenges
On Tue, Nov 29, 2011 at 11:15, Roland Steiner rolandstei...@google.comwrote: If we are considering worker-like decorators, then AFAICT it doesn't have to be an actual worker - it's enough if it's a separate object that can be attached and detached. As long as we define the interfaces nicely, FWIW this object could even hold internal state, etc. I should point out that we already have exactly such an interface in the form of the host element - ShadowRoot boundary! Essentially, one could view Decorators as shadow DOM where scripts are only allowed in the shadow side. - Roland
Re: [Component Model] Decorator Challenges
On Tue, Nov 29, 2011 at 02:18, Dimitri Glazkov dglaz...@chromium.orgwrote: On Thu, Nov 24, 2011 at 6:40 PM, Roland Steiner rolandstei...@google.com wrote: (FWIW, I'm also not convinced that it'd have to have high performance overhead - in the best case it could be as little as just one more level of indirection.) The startup time of a worker is non-trivial. Similarly, the shutdown won't be trivial. And the memory footprint of a worker isn't trivial either. If we're aiming for decorators to be fast and lean, we'll have to think of ways around those costs If we are considering worker-like decorators, then AFAICT it doesn't have to be an actual worker - it's enough if it's a separate object that can be attached and detached. As long as we define the interfaces nicely, FWIW this object could even hold internal state, etc. And in the isolation case this interface serves as a convenient boundary. Now the drawback with this is that the decorator is a separate object - i.e., in its code, event handlers, etc., you can't access the decorated element directly, 'this' is not the element, etc. etc. However, I argue that is actually a feature - and even a requirement if we want to have non-trivial decorators, to address the very problems you stated. In this model, consider the decorator as the glittering glass ornament that is being hung on the christmas DOM tree - it decorates the tree, but it isn't the tree, nor an actual part of it. It can be detached (and potentially even hung somewhere else) without affecting the tree proper. ^_- Roland
Re: [Component Model] Decorator Challenges
On Wed, Nov 23, 2011 at 08:05, Dimitri Glazkov dglaz...@chromium.orgwrote: Even if we attempt to separate the state of a decorator from the element and its document using an iframe- or worker-like machinery, we’ll still have similar issues of managing decorator instances that are no longer relevant, but don’t know that yet -- in addition to the performance costs of such high-isolation approach. I don't quite follow what you mean with the above - could you go into more detail on this point? E.g., why would it be a problem if a worker-like decorator that got detached sits around for a little while longer, doing last timeouts and other stuff that no longer really matters? (FWIW, I'm also not convinced that it'd have to have high performance overhead - in the best case it could be as little as just one more level of indirection.) Cheers, - Roland
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com wrote: Yehuda Katz (ph) 718.877.1325 On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/21/11 11:31 AM, Tab Atkins Jr. wrote: 1) Make sense. 2) Not break existing content. 3) Be short. .matches .is I like .is, the name jQuery uses for this purpose. Any reason not to go with it? IMHO 'is' seems awfully broad in meaning and doesn't very well indicate that the parameter should be a selector. Inasmuch I like .matches better. Also, FWIW, an 'is' attribute on elements was/is in discussion on this ML as one possibility to specify components. Cheers, - Roland
Re: QSA, the problem with :scope, and naming
On Thu, Oct 20, 2011 at 14:08, Tab Atkins Jr. jackalm...@gmail.com wrote:
style scoped should (I think) have three cases:
1. Selector without :scope - same as .find
2. Selector with :scope - Same as #1, but also including the context node.
3. Selector in @global - run the selector across the entire document,
filter the results to only be the context node and its descendants.
(Some people disagree with me on this, and think that #1 and #2 should
be merged to always include the context node. That's acceptable, but
I don't like it as much.)
The - very valid IMHO - main argument for style scoped to always include
the scoping element was to allow for easy migration. I.e., where currently
you'd use
style
#menu .foo { color: green }
/style
div id=menu
div class=foo
Will be green
/div
/div
div class=foo
Will NOT be green
/div
You could just stick the stylesheet under the div and add 'scoped':
div id=menu
style scoped
#menu .foo { color: green }
/style
div class=foo
Will be green
/div
/div
div class=foo
Will NOT be green
/div
In browsers that don't support 'scoped', this would still work. Where
'scoped' is supported, this doesn't change much per se, except that those
style rules don't need to be checked outside the scope. Once a majority of
browsers support style scoped one can then proceed to simplify the rules
and remove '#menu' (admitted caveat: where this then doesn't create an
ambiguity with the scoping div).
- Roland
Re: QSA, the problem with :scope, and naming
On Thu, Oct 20, 2011 at 14:52, Jonas Sicking jo...@sicking.cc wrote:
style scoped should (I think) have three cases:
1. Selector without :scope - same as .find
2. Selector with :scope - Same as #1, but also including the context
node.
3. Selector in @global - run the selector across the entire document,
filter the results to only be the context node and its descendants.
(Some people disagree with me on this, and think that #1 and #2 should
be merged to always include the context node. That's acceptable, but
I don't like it as much.)
I think it's perfectly okay that these two APIs have different cases.
I'm not sure I understand what you are proposing here. Are you saying that
div
style scoped
:scope {
background: green;
}
/style
/div
should set the background of the div green? This does seem intuitive
I agree, but it might also lead to strange behavior since the
rendering of the div will change once the stylesheet is parsed. In
other words, it's very easy to get flash-of-unstyled-content behavior.
Hixie's - again valid IMHO - counterargument for this was that, with the
above proposal:
div { background-color-green }
would not color the scoping element, while the more specific (!)
div:scope { background-color: green }
would. I.e., a more specific selector suddenly selecting MORE elements than
a not so specific one.
- Roland
Re: Gave a try to the Component Model
Hi Julien, Thanks a lot for your interest and feedback! If I understand your example correctly, it is very similar to the time-zone selection example Hixie gave on this mailing list. As it so happens, I just added that as a use case for components at http://wiki.whatwg.org/wiki/Component_Model_Use_Cases. Regarding sharing of data in your examples: I'm not sure it can work exactly as you described, because of confinement considerations (a component should not be able to access 'window', nor 'document', nor the DOM, without the embedding document's consent), but we are in the middle of writing a proposal that should address most of that (confinement, declarative syntax, data sharing, to be precise), which should be forthcoming soon. Cheers, - Roland On Mon, Oct 10, 2011 at 17:43, Julien Richard-Foy jul...@richard-foy.frwrote: Hi, I’m interested in the component model proposal [1] and tried to imagine what architecture patterns our apps would follow by using it. I wrote my notes here [2] and I’d like you to read and comment them. The most difficult problem to solve seems to be the way components will be bound together since we don’t control how they are instanciated and configured. Regards, Julien [1] http://wiki.whatwg.org/wiki/Component_Model [2] http://substance.io/julienrf/dom-component-model/1
Re: Behavior Attachment Redux, was Re: HTML element content models vs. components
On Tue, Oct 11, 2011 at 04:58, Ian Hickson i...@hixie.ch wrote: On Tue, 4 Oct 2011, Roland Steiner wrote: On a second note, what you essentially seem to demand is swapping out entire HTML sub-branches based on presentation. It's not how I would describe it (I wouldn't expect the shadow trees to be written using HTML), but to a first approximation, sure. Intriguing - could you elaborate on the above? Do you mean shadow trees should not use HTML, but something different? (If so, what instead? pure JS?) Or do you mean shadow trees should not be defined in the HTML of the main DOM and then swapped into the shadow trees? If the latter, I fully agree. Cheers, - Roland
[components] Summary of open questions
Hi all, To give a broader overview over the everything involved with components, I summarized all open questions (as far as we see it) at http://wiki.whatwg.org/wiki/Component_Model_Discussion . Please chime in with opinions on any item and/or stuff you think is missing and should belong on the list. Cheers, - Roland
Re: Behavior Attachment Redux, was Re: HTML element content models vs. components
On Tue, Oct 4, 2011 at 12:38 PM, Ian Hickson i...@hixie.ch wrote:
* Any case of taking an element with existing semantics (e.g. a select
showing a list of countries) and replacing its presentation with
something completely different (e.g. a map selector), where the exact
binding could depend based on media queries (e.g. different UIs for
tablets vs TVs) or alternative style sheet selections (e.g. the user
picking a high-contrast view rather than a custom cool one).
Well for one we already have HTML elements that do more or less the same
(select vs. input type=radio, button vs. input type=button), so it
doesn't seem such a stretch to me to allow select vs. select
is=mapselect.
On a second note, what you essentially seem to demand is swapping out entire
HTML sub-branches based on presentation. It is IMHO not entirely a given
that it's components who have to fulfill this mechanism. IOW, components
could be seen as a neat, simple wrapping of a complex DOM structure under a
single element name (or binding attribute), and the task of switching out
different HTML trees (whether containing components or not) could be handled
by another, yet-to-be-specified mechanism. This incidentally would also
solve the security issue you mentioned in conjunction with CSS bindings.
On Mon, 3 Oct 2011, Roland Steiner wrote:
X-MYWIDGET
Pros:
- element name is inherently immutable
- can provide arbitrary API, can (but does not have to) derive from
arbitrary HTML element
- best performance (in instantiation, CSS selector matching)
I don't see why it would be more performant, can you elaborate on that?
Instantiation: for button is=mywidget I assumed there is a gap during
parsing when a button is instantiated, then later is expanded/replaced
when the is attribute is read. This may or may not be the case, though. In
any case, x-mywidget does not suffer from this.
CSS Selector matching: WebKit at least has a fast path for element names,
but not for attribute matches. So button[is=mywidget] { color: red; }
would be slower than x-mywidget { color: red; }. (The former also requires
up to 2 comparisons - attribute value and element name - besides.)
button IS=MYWIDGET
Pros:
- fallback behavior as per HTML element
- accessibility as per HTML element + shadow tree contents
- binding only at creation, or immediately thereafter
- API is that of host element, +alpha
Cons:
- add'l APIs ignored for accessibility
I'm not sure what this means. I would have thought the with-binding
accessibility would be at least as good as the x-foo case; better if you
bind to an element that already has some semantics and just augment them.
That's what I meant to say under Pros. It's the augmentations that are
ignored. But that's the case in all scenarios, so I shouldn't have singled
it out here.
button { BINDING: MYWIDGET; }
Pros:
- fallback behavior as if un-styled
- accessibility
- mutability depending on medium, etc.
- host element stays unchanged
Cons:
- dynamic binding is hard to implement
It doesn't have to be. In particular, now that we have the event loop
specified we can just specify how this works asynchronously.
- shadow DOM dependent on rendering tree (something we explicitly wanted
to avoid)
It's dependent on the style resolution, not the rendering tree.
Right, but the point still stands: We'd have a DOM tree hanging off (be
dependent on) something that isn't the DOM. This was the case previously in
WebKit before we started with the whole shadow DOM approach, and caused a
lot of headaches.
- unclear what happens if a HTML element with (intrinsic or explicit)
shadow DOM is assigned a CSS binding as well
It doesn't have to be unclear, it just has to be defined. There are two
obvious options: replace it, or augment it. XBL2 supported both.
TBH, XBL2's answer to multiple bindings felt rather hand-wavey to me - it
assumed that an arbitrary intrinsic order would work in all circumstances,
and that the various bindings wouldn't end up clobbering each other on
application.
Specifics aside, it's also a fundamental question how to address multiple
applicable CSS bindings that may be mutually exclusive - e.g., a layout
manager component gets both a vertical and horizontal layout binding
from different rules. For these reasons I would argue that replacing or
ignoring additional bindings is the only feasible way to go, but that OTOH
will easily lead to arbitrary results.
Cheers,
- Roland
Re: Behavior Attachment Redux, was Re: HTML element content models vs. components
If I may briefly summarize the pros and cons of every approach discussed:
X-MYWIDGET
Pros:
- element name is inherently immutable
- can provide arbitrary API, can (but does not have to) derive from
arbitrary HTML element
- best performance (in instantiation, CSS selector matching)
Cons:
- accessibility only for shadow tree contents, no accessibility for host
element unless ARIA roles are specified
- parsing issues in special circumstances (table, auto-closing p, etc.)
- no/limited fallback (limited: user provides fallback as content of
X-MYWIDGET, won't work in special places like within tables)
- makes it easy to conflate semantics and representation
button IS=MYWIDGET
Pros:
- fallback behavior as per HTML element
- accessibility as per HTML element + shadow tree contents
- binding only at creation, or immediately thereafter
- API is that of host element, +alpha
Cons:
- add'l APIs ignored for accessibility
- harder to implement: there's a window during parsing (before reading the
button) where it's still an ordinary button, requiring binding to be added
afterwards
- immutability of 'is' attribute not immediately obvious to authors
- unclear what happens if a HTML element with intrinsic shadow DOM is
assigned a CSS binding
button { BINDING: MYWIDGET; }
Pros:
- fallback behavior as if un-styled
- accessibility
- mutability depending on medium, etc.
- host element stays unchanged
Cons:
- dynamic binding is hard to implement
- shadow DOM dependent on rendering tree (something we explicitly wanted to
avoid)
- API immutable that of host element
- unclear what happens if a HTML element with (intrinsic or explicit) shadow
DOM is assigned a CSS binding as well
Does the above look about right?
- Roland
Re: Notes from a component model pow-wow
For reference, I wrote down all different variants of rendering and styling of the host element/shadow root I could think of at: http://wiki.whatwg.org/wiki/Component_Model_Discussion:_Rendering Cheers, - Roland On Wed, Sep 28, 2011 at 5:14 AM, Julien Richard-Foy jul...@richard-foy.frwrote: Hi, If I understand correctly you are planing to allow shadow dom to be styled by users stylesheets. I’m not sure it will be a good idea since it would break encapsulation. Regards, Julien
HTML element content models vs. components
Expanding on the general web component discussion, one area that hasn't been touched on AFAIK is how components fit within the content model of HTML elements. Take for example a list ( http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#the-ul-element ): ol and ul have Zero or more li elements as content model, while li is specified to only be usable within ol, ul and menu. Now it is not inconceivable that someone would like to create a component x-li that acts as a list item, but expands on it. In order to allow this, the content model for ol, ul, menu would need to be changed to accomodate this. I can see this happening in a few ways: A.) allow elements derived from a certain element to always take their place within element content models. In this case, only components whose host element is derived from li would be allowed within ol, ul, menu, whether or not it is rendered (q.v. the Should the shadow host element be rendered? thread on this ML). B.) allow all components within all elements. While quite broad, this may be necessary in case the host element isn't rendered and perhaps derivation isn't used. Presumably the shadow DOM in this case contains one - or even several - li elements as topmost elements in the tree. C.) Just don't allow components to be used in places that have a special content model. Thoughts? - Roland
Re: Web Components use cases, was Re: Notes from a component model pow-wow
On Fri, Sep 23, 2011 at 1:58 AM, Charles Pritchard ch...@jumis.com wrote: [...] We have an opportunity now to document the sub-elements of single form controls. That is certainly a very valid goal. For example, it would really be great if an author could create his/her own video element and be able to re-use parts of the built-in video controls. One way could be to assemble larger components from smaller ones, and make those accessible to derived components. However, getting all vendors to agree on a unified set of controls and layouts for the various form and media elements will certainly take time, and IMHO is only possible when the need for such arises. Until we can express what existing form controls do, I see no compelling case to leap forward and try to express new components. This I don't agree with. Authors currently can and do use various frameworks to create what are essentially components, e.g., layout managers - undaunted by the fact that the internal structure of, say, input isn't specced out. It does seem plausible that these selectors, in context, can unify CSS Element names and DOM Element ids. I think that will be possible only in the simplest of cases. For more complex components I don't think there necessarily will be a 1:1 mapping of a pseudo-element name to an actual element. Cheers, - Roland
Re: Notes from a component model pow-wow
A neat side effect of not rendering the host element (whether by display: transparent, or implicitly) is that encapsulated styling of a component becomes trivial. I.e., one may want a component be isolated (i.e., not be able to access the main document by default, and vice versa), but still style the host element somehow. At the moment this requires 2 style-sheets: one to style the host element, and one to style the contents of the component. If the host element doesn't get a render box, only the latter remains, which is easy to encapsulate by putting a style [scoped] inside the component tree. - Roland On Wed, Sep 21, 2011 at 3:20 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/20/11 11:15 PM, Tab Atkins Jr. wrote: I think this is properly a CSS issue. You want an element to not exist in the box tree, but to still have its children in the tree, which should be controllable with a display value, perhaps called 'transparent'. I believe that would be an acceptable solution to this use case, yes. If it ever happens. -Boris
Re: xdash name prefixes (was Re: Component Model Update)
On Fri, Aug 26, 2011 at 11:18 AM, Adam Barth w...@adambarth.com wrote: Doesn't it seem more likely that the third-party will do the registration in whatever script you include that implements the Like button, or whatever? That's just a matter of convention, no? I don't think it's unreasonable to frame it as in order to use a component you need to load its source and register a suitable element name for it.. OTOH, there's nothing to prevent a package from doing the registering in one go. But if such a package then really leads to a clash, I'd prefer to first ask the authors to sort it out. Cheers, - Roland
Re: xdash name prefixes (was Re: Component Model Update)
On Wed, Aug 31, 2011 at 12:57 PM, Dominic Cooney domin...@chromium.orgwrote: I think for convenience registration probably should be carried around with the component, because: 1. It is convenient for the author using the component. 2. If the component library reuses its own abstractions, it probably expects them to have a specific element name. Putting registration in the hands of the author using the component jeopardizes that. That is actually a good point. Something declarative like module imports and exports, with scoped renaming, for registered tag names would be nice. This avoids these two problems, and is pretty convenient (particularly if import * gets you all of the exports by default.) Wouldn't that be effectively namespaces by another name/mechanism? Also, there's probably a limit to how far renaming can avoid clashes, e.g., if a sub-components can also be utilized by a page's author. In any case, until modules become a reality I think teaching component authors to use pseudo-namespaces (e.g., x-rogersoft-button vs. x-delilahsoft-button) for stuff that might clash is not unreasonable. Cheers, - Roland
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
Unless I'm misunderstanding something, I believe this actually is - or at least touches upon - several questions in disguise: .) Do we want to allow decoration of elements that are already in the DOM tree? - which is for all intents and purposes a corollary of: .) Do we allow calling of new ShadowRoot outside of an element constructor? If no, then we don't have a problem with dead elements, because the author can only declare new elements (and use encapsulation), but not meddle with existing ones. FWIW, I don't think there is any real use-case for calling new ShadowRoot within the constructor twice. However, in this case we have to answer how encapsulation can address the stated use cases for decoration. This probably means answering: .) How is attribute forwarding handled from the host element to a nested (form) element? .) How can components participate in forms (and other fun)? ... or just leave decoration out for the time being (which I think is quite reasonable). OTOH, if the answer to the decorators question is yes, then the above mentioned issues with multiple shadow roots arise.
Re: Component Model Update
On Thu, Aug 25, 2011 at 4:24 PM, Dominic Cooney domin...@google.com wrote: Here is a quick first cut: How about use cases like these: - Extension that wants to inspect input type=password and warn you when you are entering you password in an insecure form (from abarth earlier in the thread.) - Password manager that wants to find anything that looks like a login panel and decorate it/fill it. - Extension that removes formatting from a page to make it easier for on-screen reading. - Extension that finds phone numbers in a page and embosses them with links to a crank call service. - Extension that replaces all ads in a page with pictures of kittens. Or an extension that detects pictures of kittens and monetizes them with ads. - Extension that on hover looks up dictionary/thesaurus/translation/urban dictionary/wikipedia/etc. This is a great list! As for allowing extensions to inspect the shadow DOM: unless we want to break isolation/confinement again, I believe this should be handled by the relevant browser APIs for extensions, along the lines of shadow = extensions.getShadowFor(element). If the extension shouldn't be able to mess with shadows, it can be blocked at this point.
Re: xdash name prefixes (was Re: Component Model Update)
On Thu, Aug 25, 2011 at 9:12 AM, Adam Barth w...@adambarth.com wrote: On the other hand, it seems likely that some of these xdash names will come into multi-party use. For example, the following use cases involve xdash names chosen by one party and then used by another: http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Widget_Mix-and-Match http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Contacts_Widget http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Like.2F.2B1_Button Since the components that are used on a page are under the control of the page's author, it should be possible to avoid clashes by separating a component's definition (potentially pulled from third party) from its tag registration (done by page author), e.g. // Importing component definition for Facebook Like button // Importing component definition for Google+ +1 button // ... later: Element.register(x-fb, Facebook.LikeButton) Element.register(x-gg, GooglePlus.PlusOneButton) That's something like 40% of the use cases... I don't have much of a better suggestion. You're running up against all the usual distributed extensibility issues. We could use namespaces... *ducks and runs* :D Cheers, - Roland
Components/constructable DOM elements: mandatory tag registration?
From the discussion about x- prefixed names another question crossed my
mind: Suppose an author defines a component, but doesn't register a tag
name. AFAICT, at this point nothing prevents him from inserting such a new
element into the DOM. E.g.:
div id=div/div
script
function MyNewElement() {
HTMLElement.call(this);
// ...
}
var div = document.getElementById(div);
div.appendChild(new MyNewElement());
// ... Look Ma, no Element.register() call!
var text = div.innerHTML; // - what does this return?
/script
Cheers,
- Roland
Re: Element.create(): a proposal for more convenient element creation
On Tue, Aug 2, 2011 at 4:36 PM, Jonas Sicking jo...@sicking.cc wrote: This doesn't explain why a factory method is better than explicit constructors though? The above could be written as new HTMLParagraphElement(null, foo, ...); It's not a general use case, but at least when it comes to XBL-like components, having a factory method that does all the lookup and binding behing the scenes probably is easier to implement than hooking a constructor (FWIW). However I'm not sure what to do in situations where we don't have an explicit interface for an element, such as both ins and del both using HTMLModElement, and the long list of elements which only use HTMLElement as interface. cc'ing Alex Russel who is often a strong advocate for constructors over factory functions and who might have thought about this problem. Cheers, - Roland
Re: Overview of behavior attachment as a general problem on the Web
On Sat, Jul 9, 2011 at 1:42 PM, John J. Barton johnjbar...@johnjbarton.comwrote: [...] The Behavior Attachment Methods section is also super, but at the end I was puzzled. I thought the Shadow DOM proposal only allowed one binding, and thus it would exclude exactly the Decorator pattern we need to compose multiple frameworks. I understand how you can solve the Dojo or Sencha or jQuery problem better, but I don't see how you can solve the 'and' version. IMHO there is a difference between altering the functionality of a component or decorating it. In the first case you need deep knowledge of the component's internas and thus cannot afford a random order in the inheritance chain. OTOH, in the decorator case you are explicitly not interested in internas, and have no control over order of application. I would therefore argue that inheritance (as, e.g., proposed by XBL2) is the wrong vehicle for decoration. For example, what if a decorator omits the inherited element in its tree? It seems to me it should be sufficient to only give a rough outline where the decoration should go, perhaps similar to CSS's ::before and ::after. Conversely, a decoration should _not_ be able to see, or even modify, anything inside the original component, nor use inherited or content. Cheers, - Roland
Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)
On Fri, Jul 1, 2011 at 7:01 AM, Dimitri Glazkov dglaz...@google.com wrote: On Thu, Jun 30, 2011 at 2:50 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/30/11 5:45 PM, Dimitri Glazkov wrote: There's a very interesting distinction here. You don't attach components to DOM elements. DOM elements _are_ components. The only way to make a component is by sub-classing it from an existing element. In this case, there is no distinction between native and non-native implementations. If I sub-class from HTMLTextareaElement, I can either reuse or override its shadow DOM. Back up. In this particular case, there may well be behavior attached to the textarea that makes assumptions about the shadow DOM's structure. This seems like a general statement about components. So if you override a shadow DOM, you better override the behavior too, right? Ouch. This one is tricky. I now see it. We can't really expect the author to design to this level of decoupling. I don't think that's insurmountable. Since we don't do aspect oriented components, a component's tree is always the same - either at the root, or attached to some inherited element of a sub-class component. So the behavior can work on that tree without having to know whether it's used vanilla, or within a sub-class. Now, if the sub-class doesn't in fact use inherited, that means its component tree in effect overrides the original component's tree. The original tree and it's attached behavior are just ignored and go hide in a corner. However, (later on) we may need then to also allow sub-classing the behavior, i.e., handing off of the interface of the original component to its sub-class. That in turn may have security implications - you probably don't want a component to be able to sub-class a file-upload control and hijack events, etc. Cheers, - Roland
