On Wed, Jan 8, 2014 at 9:01 AM, Elliott Sprehn 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.
--
http://annevankesteren.nl/
On Tue, Jan 7, 2014 at 10:59 PM, Tab Atkins Jr. wrote:
> On Tue, Jan 7, 2014 at 2:42 PM, Elliott Sprehn 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
>> outlined in my original email
On Tue, Jan 7, 2014 at 2:59 PM, Tab Atkins Jr. wrote:
> On Tue, Jan 7, 2014 at 2:42 PM, Elliott Sprehn wrote:
> > On Tue, Oct 29, 2013 at 4:20 AM, Anne van Kesteren
> wrote:
> >> On Tue, Oct 29, 2013 at 7:34 AM, Simon Pieters
> wrote:
> >> > On Tue, 29 Oct 2013 00:54:05 +0100, Anne van Kestere
On Tue, Jan 7, 2014 at 2:42 PM, Elliott Sprehn wrote:
> On Tue, Oct 29, 2013 at 4:20 AM, Anne van Kesteren wrote:
>> On Tue, Oct 29, 2013 at 7:34 AM, Simon Pieters wrote:
>> > On Tue, 29 Oct 2013 00:54:05 +0100, Anne van Kesteren
>> > wrote:
>> >> We are considering not throwing in XML.
>> >
>>
On Tue, Oct 29, 2013 at 4:20 AM, Anne van Kesteren wrote:
> On Tue, Oct 29, 2013 at 7:34 AM, Simon Pieters wrote:
> > On Tue, 29 Oct 2013 00:54:05 +0100, Anne van Kesteren
> > wrote:
> >> We are considering not throwing in XML.
> >
> > Only on getting innerHTML, though, right?
>
> Oh I missed t
On Tue, Oct 29, 2013 at 7:34 AM, Simon Pieters wrote:
> On Tue, 29 Oct 2013 00:54:05 +0100, Anne van Kesteren
> 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 nodes for
ShadowRoot nodes i
On Tue, 29 Oct 2013 00:54:05 +0100, Anne van Kesteren
wrote:
We are considering not throwing in XML.
Only on getting innerHTML, though, right?
--
Simon Pieters
Opera Software
On Mon, Oct 28, 2013 at 10:44 PM, Elliott Sprehn wrote:
> On Thu, Oct 24, 2013 at 1:29 PM, Anne van Kesteren wrote:
>> innerHTML would end up re-throwing the same exception, unless you
>> special-cased parsing. innerHTML throwing is somewhat unexpected though.
>
> We don't really need to special
On Thu, Oct 24, 2013 at 1:29 PM, Anne van Kesteren 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), which sound
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, un
On Wed, Oct 9, 2013 at 2:54 PM, Elliott Sprehn 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 parsing), whic
On Thu, Oct 10, 2013 at 9:30 PM, Dimitri Glazkov wrote:
> On Thu, Oct 10, 2013 at 1:06 AM, Anne van Kesteren 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 could add more hidden state such
On Thu, Oct 10, 2013 at 1:06 AM, Anne van Kesteren wrote:
> On Wed, Oct 9, 2013 at 10:55 PM, Jonas Sicking 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 to Elliott when I saw his
On Wed, Oct 9, 2013 at 10:55 PM, Jonas Sicking 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. Alternatively
On Tue, Oct 8, 2013 at 11:04 PM, Hayato Ito 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 ShadowRoot in the Shad
On Oct 8, 2013 1:48 PM, "Elliott Sprehn" 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 expose a hos
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
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 style
18 matches
Mail list logo
