When the input element's direction is RTL, icons should be rendered on the opposite side. e.g. speech icon on the left instead of right, and clear (x) mark on the left instead of right, etc...
This was what I was talking about, thanks Ryosuke :)
related chromium bug: http://code.google.com/p/chromium/issues/detail?id=87045
The speech decorations are added in TextFieldInputType::createShadowSubtree() . First the TextControlInnerElement is appended to the container and then the speech element. A possible fix here would be to add the speech decoration before the TextControlInnerElement in the case of RTL. dglazkov, tkent: Am I missing anything? Does that sound OK to you?
(In reply to comment #3) > The speech decorations are added in TextFieldInputType::createShadowSubtree() . > > First the TextControlInnerElement is appended to the container and then the speech element. > > A possible fix here would be to add the speech decoration before the TextControlInnerElement in the case of RTL. > > dglazkov, tkent: Am I missing anything? Does that sound OK to you? direction change is something that's dynamic, right? Would this mean that we'd have to rebuild the shadow tree every time it changes?
(In reply to comment #4) > direction change is something that's dynamic, right? Would this mean that we'd have to rebuild the shadow tree every time it changes? Yes. Because the text direction can be changed by CSS, it would mean that we'd have to re-order elements after every style-recalc but mutating DOM itself can cause a style-recalc as well. So I think what we need to do instead is to use some CSS tricks to re-order elements based on the text direction.
(In reply to comment #5) > Yes. Because the text direction can be changed by CSS, it would mean that we'd have to re-order elements after every style-recalc but mutating DOM itself can cause a style-recalc as well. > > So I think what we need to do instead is to use some CSS tricks to re-order elements based on the text direction. Wait a minute, all these elements are inline so if the shadow root had the same text direction as the shadow host, this would automatically work, no?
rniwa: yep, in fact if I change html.css to: input::-webkit-textfield-decoration-container { direction: rtl; ... Then the microphone decoration is placed correctly. rniwa, dglazkov: Do you have any idea why direction isn't propagated from the input element to the container, even if I add the following to the default style sheet the container direction stays at it's initial value: input[dir=rtl]::-webkit-textfield-decoration-container {direction: rtl;}
Correction, adding that line to the default stylesheet does fix the issue, now just to move to the correct position when the Microphone Icon is on the left...
(In reply to comment #8) > Correction, adding that line to the default stylesheet does fix the issue, now just to move to the correct position when the Microphone Icon is on the left... Sorry, I don't really understand what you mean here. Could you clarify?
rniwa: What I mean is that if I add input[dir=rtl]::-webkit-textfield-decoration-container {direction: rtl;} to html.css, this causes the shadow dom container to inherit dir=rtl and correctly orders the field decorations in RTL. e.g. the Microphone icon comes out on the left. The only problem I'm having with this is that it causes the 'X' to draw on top of the magnifying glass for <input type=search>. Once I fix that I'll post a patch.
Created attachment 100485 [details] Screenshot with patch
This has something to do with the styling of the results [magnifying glass] button element, if I substitue the speech element [InputFieldSpeechButtonElement instead of a SearchFieldResultsButtonElement] in SearchInputType::createShadowSubtree, everything is drawn correctly.
Is NSSearchField flipped in RTL environment? The search field rendering in Mac is very special. The magnifier location seems to be determined by NSSearchField::searchButtonRectForBounds().
Created attachment 101114 [details] Patch
Comment on attachment 101114 [details] Patch Splitting off to a separate bug.
Moving Microphone icon issue discussion to 64668 and leaving this as a master bug.
InputFieldSpeechButtonElement <-- It is gone via below: https://github.com/WebKit/WebKit/commit/2b450c7100036302f28fd23a3b5d36bf3d023be2 While 'SearchFieldResultsButtonElement' do exist.