On Tue, Jan 7, 2014 at 10:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Jan 7, 2014 at 2:42 PM, Elliott Sprehn espr...@gmail.com wrote:
If dropping them is too gross we might want to just consider this a lost
cause and warn authors away from putting text in there due to the issues I
On Tue, Jan 7, 2014 at 2:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Jan 7, 2014 at 2:42 PM, Elliott Sprehn espr...@gmail.com wrote:
On Tue, Oct 29, 2013 at 4:20 AM, Anne van Kesteren ann...@annevk.nl
wrote:
On Tue, Oct 29, 2013 at 7:34 AM, Simon Pieters sim...@opera.com
On Wed, Jan 8, 2014 at 9:01 AM, Elliott Sprehn espr...@gmail.com wrote:
And have textNode.textContent or nodeValue throw an exception if you try to
make it into a non-whitespace node? That could work.
We would not actually make them part of the final tree I think.
--
On Tue, Oct 29, 2013 at 4:20 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Oct 29, 2013 at 7:34 AM, Simon Pieters sim...@opera.com wrote:
On Tue, 29 Oct 2013 00:54:05 +0100, Anne van Kesteren ann...@annevk.nl
wrote:
We are considering not throwing in XML.
Only on getting
On Tue, Jan 7, 2014 at 2:42 PM, Elliott Sprehn espr...@gmail.com wrote:
On Tue, Oct 29, 2013 at 4:20 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Oct 29, 2013 at 7:34 AM, Simon Pieters sim...@opera.com wrote:
On Tue, 29 Oct 2013 00:54:05 +0100, Anne van Kesteren ann...@annevk.nl
On Tue, 29 Oct 2013 00:54:05 +0100, Anne van Kesteren ann...@annevk.nl
wrote:
We are considering not throwing in XML.
Only on getting innerHTML, though, right?
--
Simon Pieters
Opera Software
On Tue, Oct 29, 2013 at 7:34 AM, Simon Pieters sim...@opera.com wrote:
On Tue, 29 Oct 2013 00:54:05 +0100, Anne van Kesteren ann...@annevk.nl
wrote:
We are considering not throwing in XML.
Only on getting innerHTML, though, right?
Oh I missed that. In that case throwing if you include text
On Thu, Oct 24, 2013 at 1:29 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Thursday, October 24, 2013, Dimitri Glazkov wrote:
Woke up in the middle of the night and realized that throwing breaks
ShadowRoot.innerHTML (or we'll have to add new rules to hoist/drop text
nodes in parsing),
On Mon, Oct 28, 2013 at 10:44 PM, Elliott Sprehn espr...@gmail.com wrote:
On Thu, Oct 24, 2013 at 1:29 PM, Anne van Kesteren ann...@annevk.nl wrote:
innerHTML would end up re-throwing the same exception, unless you
special-cased parsing. innerHTML throwing is somewhat unexpected though.
We
On Wed, Oct 9, 2013 at 2:54 PM, Elliott Sprehn espr...@gmail.com wrote:
shadowRoot.appendChild(new Text()) should probably throw an exception.
Woke up in the middle of the night and realized that throwing breaks
ShadowRoot.innerHTML (or we'll have to add new rules to hoist/drop text
nodes in
On Thursday, October 24, 2013, Dimitri Glazkov wrote:
Woke up in the middle of the night and realized that throwing breaks
ShadowRoot.innerHTML (or we'll have to add new rules to hoist/drop text
nodes in parsing), which sounds bad.
innerHTML would end up re-throwing the same exception,
On Thu, Oct 10, 2013 at 9:30 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Thu, Oct 10, 2013 at 1:06 AM, Anne van Kesteren ann...@annevk.nl wrote:
Either that or let it have its own node type if it's going to be
incompatible with DocumentFragment in terms of behavior. Alternatively
we
On Wed, Oct 9, 2013 at 10:55 PM, Jonas Sicking jo...@sicking.cc wrote:
Maybe it's time to reconsider if ShadowRoot should be an element rather than
a DocumentFragment again?
Either that or let it have its own node type if it's going to be
incompatible with DocumentFragment in terms of behavior.
On Thu, Oct 10, 2013 at 1:06 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 9, 2013 at 10:55 PM, Jonas Sicking jo...@sicking.cc wrote:
Maybe it's time to reconsider if ShadowRoot should be an element rather
than
a DocumentFragment again?
Actually, that's the first thing I said
Good points. All you pointed out make sense to me.
But I am wondering what we should do for these issues:
A). Discourage developers to use direct text children of ShadowRoot.
B). Disallow direct text children of ShadowRoot in the Shadow DOM spec.
C). Find a nice way to style direct text children
On Oct 8, 2013 1:48 PM, Elliott Sprehn espr...@gmail.com wrote:
Direct text children of ShadowRoot are full of sadness:
1) You can't call getComputedStyle on them since that's only allowed for
Elements, and the old trick of parentNode doesn't work since that's a
ShadowRoot. ShadowRoot doesn't
On Tue, Oct 8, 2013 at 11:04 PM, Hayato Ito hay...@chromium.org wrote:
Good points. All you pointed out make sense to me.
But I am wondering what we should do for these issues:
A). Discourage developers to use direct text children of ShadowRoot.
B). Disallow direct text children of
Direct text children of ShadowRoot are full of sadness:
1) You can't call getComputedStyle on them since that's only allowed for
Elements, and the old trick of parentNode doesn't work since that's a
ShadowRoot. ShadowRoot doesn't expose a host property so I can't get
outside to find the host
18 matches
Mail list logo
