[Webkit-unassigned] [Bug 188878] [iOS] Support the inputmode attribute on contenteditable elements

[bugzilla-daemon at webkit.org]

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

--- Comment #12 from Daniel Bates <dbates at webkit.org> ---
(In reply to Ryosuke Niwa from comment #10)
> Comment on attachment 347898 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=347898&action=review
> 
> > Source/WebCore/html/HTMLElement.h:113
> > +    const AtomicString& inputMode() const;
> > +    void setInputMode(const AtomicString& value);
> 
> I don't think it makes much sense for these functions to take & return
> AtomicString
> since setInputMode does a case-insensitive comparison. Just use String
> instead.
> 

I take it you meant to say that inputMode() does a case-insensitive comparison. Regardless, having either one of these functions (or both) take or return a String requires conversion (though it may be implicit and even optimized away). It is most natural for both of these functions to operate on- and return a- const lvalue reference to an AtomicString. The setter, setInputMode(), turns around and calls Element::setAttributeWithoutSynchronization() passing the new value and Element::setAttributeWithoutSynchronization() expects an AtomicString; => the setter needs to pay the conversion cost to AtomicString anyway; => the setter should take a const AtomicString&. For the getter, inputMode(), it is most natural (i.e. avoids conversion) to return a const AtomicString& because all of the WebCore::InputModeNames::*() (e.g. InputModeNames::text()) return a const AtomicString&. Therefore, it is most natural for both the setter and getter to take and return a const AtomicString&.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180823/63ab70ed/attachment.html>