DateTimeNumericFieldElement should use Localizer functions. In the result of fast/forms/time-multiple-fields/time-multiple-fields-localization.html, "ar" locale doesn't use native digits at all.
Passing a Localizer for the host <input> to DateTimeNumericFieldElement is troublesome. We had better introduce Element::computeInheritedLanguageOverShadowBoundary() or something.
Created attachment 165950 [details] Patch
Comment on attachment 165950 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=165950&action=review > Source/WebCore/html/shadow/DateTimeNumericFieldElement.cpp:116 > + Element* host = shadowHost(); I think it is better to have a new function in FieldOwner interface, e.g. FieldOwner::localizer(). Implementation of DateTimeEditElement localizer() calls DateTimeEditElement::EditControlOwner::localizer(). We know DateTimeFieldElement always in shadow tree, but it is better to reduce number of assumptions.
Comment on attachment 165950 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=165950&action=review >> Source/WebCore/html/shadow/DateTimeNumericFieldElement.cpp:116 >> + Element* host = shadowHost(); > > I think it is better to have a new function in FieldOwner interface, e.g. FieldOwner::localizer(). > Implementation of DateTimeEditElement localizer() calls DateTimeEditElement::EditControlOwner::localizer(). > > We know DateTimeFieldElement always in shadow tree, but it is better to reduce number of assumptions. Is it better to have DateTimeEditOwner::localizeNumber() API? We don't need to have full Localizer in DateTimeNumericFieldElement. Also, we may need to rename "Localizer" sometimes in future. So, reducing number of reference to Localizer will help us.
Created attachment 165971 [details] Patch 2 Add callbacks
(In reply to comment #3) > I think it is better to have a new function in FieldOwner interface, e.g. FieldOwner::localizer(). > Implementation of DateTimeEditElement localizer() calls DateTimeEditElement::EditControlOwner::localizer(). I wanted to avoid it (See Comment #1) because we need to check nullness of m_fieldOwner and m_editControlOwner and to return fallback Localizer. Using locale identifier strings instead of Localizer objects is simpler (Patch 2). > Is it better to have DateTimeEditOwner::localizeNumber() API? I don't think so. We'll need other Localizer functions in the future.
(In reply to comment #6) > (In reply to comment #3) > > I think it is better to have a new function in FieldOwner interface, e.g. FieldOwner::localizer(). > > Implementation of DateTimeEditElement localizer() calls DateTimeEditElement::EditControlOwner::localizer(). > > I wanted to avoid it (See Comment #1) because we need to check nullness of m_fieldOwner and m_editControlOwner and to return fallback Localizer. > Using locale identifier strings instead of Localizer objects is simpler (Patch 2). > > > > Is it better to have DateTimeEditOwner::localizeNumber() API? > > I don't think so. We'll need other Localizer functions in the future. ACK
Comment on attachment 165971 [details] Patch 2 View in context: https://bugs.webkit.org/attachment.cgi?id=165971&action=review > Source/WebCore/html/shadow/DateTimeNumericFieldElement.h:75 > + Localizer& localizer() const; Can the return value be const?
Comment on attachment 165971 [details] Patch 2 View in context: https://bugs.webkit.org/attachment.cgi?id=165971&action=review >> Source/WebCore/html/shadow/DateTimeNumericFieldElement.h:75 >> + Localizer& localizer() const; > > Can the return value be const? It can't. Localizer member functions are not const because of lazy initialization, and we need to call them.
I think it is better that EditControlOwner returns Localizer instead of locale identifier to improve modulelaity and to hide how to get Localizer in DateTimeFieldElement.
Comment on attachment 165971 [details] Patch 2 Clearing flags on attachment: 165971 Committed r129832: <http://trac.webkit.org/changeset/129832>
All reviewed patches have been landed. Closing bug.