[webkit-reviews] review granted: [Bug 96238] Add new function to ChromeClient to manage form validation messages, and use it : [Attachment 163062] Patch 1

[bugzilla-daemon at webkit.org]

Hajime Morrita <morrita at google.com> has granted Kent Tamura
<tkent at chromium.org>'s request for review:
Bug 96238: Add new function to ChromeClient to manage form validation messages,
and use it
https://bugs.webkit.org/show_bug.cgi?id=96238

Attachment 163062: Patch 1
https://bugs.webkit.org/attachment.cgi?id=163062&action=review

------- Additional Comments from Hajime Morrita <morrita at google.com>
(In reply to comment #3)
> (In reply to comment #2)
> > (From update of attachment 163062 [details] [details])
> > Can we make ValidationMessage class an abstract class or an interface and
add this new mechanism as a subclass of it?
> > Also, could it be this new ChromeClient API a supplement?
> > Introducing new ifdefs are sad. It would be great if we can minimize its
impact.
> 
> I can move the changes into ValidationMessage class. However I object making
a subclass and making the ChromeClient API a supplement. I'm going to remove
the current implementation with Shadow DOM when we complete the ChromeClient
API implementation for all platforms.

That makes sense.
What do you think about per-validation-message state tracking?
If WebKit layer needs to maintain element-to-state map, probably we could morph

ValidationMessage to ValidationMessageClient (or something) which is
implemented by 
WebKit layer. Such object could also be used to notify relayout change, etc.