with a very generic feature with odd semantics that only
make sense for one narrow use-case.
--
Blake Kaplan
of the spec.
--
Blake Kaplan
, as well,
that Mozilla's XBL implementation of these features worked correctly
in the static case, but is completely wrong in the dynamic case, so we
don't have any real data on how slow doing that stuff correctly is.
--
Blake Kaplan
that it's a
concern.
--
Blake Kaplan
a simple bug fix take days or weeks to
track down all of the (ab)users of the easier API. This is a classic
problem in computer science and there's a reason that it's taught in
many CS 101 courses. I don't have any specific anecdotes on the web,
but they simply must exist.
--
Blake Kaplan
by explicitly asking for
existing shadowRoot of element and than work with it?
I've always taken exposing internals to mean providing an API to
access the shadow DOM of a component. I don't think that anybody is
arguing that shadow elements should appear in queries on the bound
document.
--
Blake Kaplan
it would be much
less surprising to make this stuff explicit *somewhere* (i.e. in the
actual components rather than in the engine).
--
Blake Kaplan
to be the case. Shadows can be private by default
with a well defined and consistent API to override the default.
--
Blake Kaplan
to explicitly set the
bit that says let other people poke at my internals. I don't think
that this one use-case needs to trump the good programming practices
of every other library.
--
Blake Kaplan
