Mock History
| Current Revision | |
|---|---|
Event Timeline
We don't really need a hover state for input fields. Its not a standard either, any reason we are doing this? Consistency with other elements?
What is an active state for text inputs?
@Prtksxna, that's right, for the sake of consistency.
I would say it's the same reason why we want hover states on buttons and other components—to show the interactivity of an element among other things. I can see why hover states wouldn't be necessary when tabbing through the page with keyboard though.
What I was trying to get through with "active" state is when there isn't a button to submit the form but the "enter" key on the keyboard. As a feedback to show that the form input has been submitted. What can we name this better?
It might be a better idea to be consistent with the what the users already knows, and not necessarily be consistent with the rest of the controls. Users already see the text cursor when they hover over a text field and that is cue enough for them to understand that they need to type. Changing on hover might give the false expectation of interaction with mouse, as all other elements that have hover states allow interaction with a mouse.
I don't follow what you mean by the active state. Could you give a concrete example?
When I'm hovering over my Gmail text field, for example, I didn't feel like I had any false expectations. Can you expand on what it's like having an expectation like that? I'm curious what are the different expectations you get when hovering over a buttons vs. text field.
Here's an example for the active state:
The reason why we have active state for buttons—to inform what they just clicked on and where they last left off.
Some text fields don't have a "submit" button to submit the form. An example would be the store's search bar at the very top of the page. To submit your search, you click enter on your keyboard instead of a button. So to inform you of what you just "clicked" on and where you last left off, there needs to be an indication on the active state with the same importance as a button.
@Prtksxna Just to clarify, there's an :active state with modern browsers like Chrome and Firefox on input[type=text] elements, when you click into the field it's changing to an :active:focus state – but we should probably merge the visual appearance of :focus and :active in the mockups as the state difference in browsers doesn't really add to users' orientation. So for the next update of M101 @violetto, I think it would make sense to change the text field states from ": Hover & : Active" to ": Hover" and ": Focus & : Active".
And building an extra state via JS like last-focussed is an overkill right now IMHO.
@Prtksxna Providing :hover state functionality does help users orientate in their task and in the interface.
As some users are not as proficient with mouse usage or have visual impairments, it helps them to more easily identify where they are moving their mouse.
@violetto We are trying to update the style for the new search input on www.wikipedia.org so that it has:
padding: 0.5em 1em; font-size: 16px; line-height: 1.6;
Same for the button according to M31
Related task: T125564
And Jan is @Jdrewniak
@violetto Starting from T126307: Design for login form without constructive buttons I wanted to ask for the reasoning of changing the normal state border-color from #777 to #111 in M101 recently. It's clear, that it was part of an ongoing unification, but it might be considered as involving further problems like visually outstanding widget elements in skins like Vector or Minerva.
Adding here as well:
Italic font style in placeholder was removed in https://gerrit.wikimedia.org/r/#/c/285231/ with notice “aren't safe to apply in general (breaks CJK and other languages) and are implicit anyway.”
It was merged before getting a chance to reconsider alternatives or language-specific handling. To be revisited in future.
Some further reading: http://www.kt.rim.or.jp/~tyamamot/aboutitalicsinJapanese_E.html
Legend