[Webkit-unassigned] [Bug 77610] Introduces BuiltinShadowRoot and methods.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=77610





--- Comment #8 from MORITA Hajime <morrita at google.com>  2012-02-06 16:19:55 PST ---
(In reply to comment #7)
> Does this not seem like an idea worth pursuing? Don't get me wrong, I don't want to block your progress. But if we can't _explain_ things as trivial as input elements in terms the current Shadow DOM spec, perhaps this should be viewed as a deficiency of the spec, not an implementation quirk? Just thinking outloud here. WDYT?

TL;DR:
- Let's start from more trivial shadow implementations like <media> and <summary>
   which doesn't swap shadows dynamically. Then come back here.
- Allowing access to non-last ShadowRoot looks reasonable. But allowing to replace it 
   may be doubtful.

---

Some existing elements, especially <input> family, are implemented on an shadow dom concept
of early day's, which allows us to replace shadow DOM, doesn't have multiple shadows, etc. 
Such conceptual gaps make it tricky to adopt multiple shadows.

Ideally, we should refactor stuff to match the latest model. It will be easy for most of 
WebCore internal use. But maybe <input> is harder than average. 
At least we need to reshape the <input> shadow trees.

On introducing new member that Dominic mentioned, it's conceptually more natural,
that means it doesn't need any backdoor.
But in C++, maintaing any extra reference tends to cause a trouble.

So I prefer to allow  C++ implementation only to reach ShadowRoot chain to get "hidden" pointer,
but not to allow replacing such ShadowRoots dynamically. that looks an abuse of WebCore authority. 
It's like a __proto__ in JavaScript. We should be cautious about issuing it.

But anyway, we can start from more trivial part like <media> and <summary>.
The multiple shadows concept is a wild where anyone hasn't stepped in.
We need to learn how it should be programmed by dogfooding it ;-)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.