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
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
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
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
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
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
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
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
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
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
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
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
. 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
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:
-
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:
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
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
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
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
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,
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
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
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:
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()
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
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
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
27 matches
Mail list logo
