Page MenuHomePhabricator

Touching fields with rounded corners
Closed, ResolvedPublic

Description

Starting a new topic I see two or three components (if I'm not logged in). The middle 'topic' component either needs a margin above and below, or needs to not have rounded corners.


Update 2017-01-05

Details

Related Gerrit Patches:
mediawiki/extensions/Flow : masterSeparate message boxes from round-corner input widget group
mediawiki/extensions/Flow : masterFix adjacent input widget border radii

Event Timeline

Esanders raised the priority of this task from to Needs Triage.
Esanders updated the task description. (Show Details)
Esanders added a subscriber: Esanders.
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Volker_E closed this task as Resolved.Jan 5 2017, 7:20 PM
Volker_E claimed this task.
Volker_E updated the task description. (Show Details)
Volker_E added a subscriber: Volker_E.

Seems resolved as of today:

Catrope changed the task status from Resolved to Declined.Jan 6 2017, 9:01 PM
Catrope added a subscriber: Catrope.

Per T154762 the lack of a gap was deliberate, and has been restored.

Catrope reopened this task as Open.Jan 6 2017, 9:03 PM
Catrope added a subscriber: Pginer-WMF.

Hmm, I see the concern here was not just about the gap but also about the fact that there are touching boxes that have rounded corners. I'll let @Pginer-WMF respond to that.

Pginer-WMF added a comment.EditedJan 10 2017, 5:26 PM

I think it makes sense for stacked elements to use straight corners to make them look as part of the same component. Similar to what happens with button groups with respect to regular buttons that are not grouped.

OK, so for components like the Flow editor, are you saying that would ideally have rounded corners when there isn't a notice stacked on top of it, but straight corners at the top if there is a notice?

This can be fiddly to do with components that are optionally visible and aren't direct siblings. If they are all always visible you can hard code the corner radii, and if they are all siblings you can use :first-child and :last-child, but I think neither applies in this case.

OK, so for components like the Flow editor, are you saying that would ideally have rounded corners when there isn't a notice stacked on top of it, but straight corners at the top if there is a notice?

Yes. The intention of the Flow message editor was to present these fields as a single editing component, like an extended text input area.
The exterior corners should be rounded while the rest of the corners should be straight to be understood as divisions of the element. The specific corners will be different depending on (a) whether there is a logged-out banner and (b) whether the input is for replying (one field) or creating anew topic (two fields).

This can be fiddly to do with components that are optionally visible and aren't direct siblings. If they are all always visible you can hard code the corner radii, and if they are all siblings you can use :first-child and :last-child, but I think neither applies in this case.

The "flow-newtopic-container" HTML class may help distinguishing the new topic from the regular reply case. For the anonymous case, reflecting the status in the container as a similar class could simplify the CSS selector. Conceptually the anonymous condition affects the whole reply form (e.g., it makes the submit button to have a different label too) so it may make sense to tag the whole thing with a class (although I don't know if that goes against OOJS architecture).

In the short term, we can also think on some approximation such as overlapping some elements such as the logged-out notice could avoid the rough edges visually.

In the long term, we can define these elements (multi-field input areas with integrated warnings and toolbars) as real components, if we thing that (a) this is a pattern makes sense and (b) may be reused in other places.

As there are four separate message fields (anon, canedit, error, captcha) this is going to be problematic. You can either:

  • Use :first-child/:last-child selectors and ensure unused elements are detached. This makes attaching the message boxes in the correct order very problematic.
  • Apply border radius to the container and user overflow:hidden - this would clip popups and wouldn't render the corners correctly.
  • Do something with classes - as we have up to 6 components this would be a real mess.

Instead I suggest using rounded corners for the two inputs, and then keeping the message boxes square and slightly separated as in Volker's mockup.

Change 338794 had a related patch set uploaded (by Esanders):
Fix adjacent input widget border radii

https://gerrit.wikimedia.org/r/338794

Change 338795 had a related patch set uploaded (by Esanders):
Separate message boxes from round-corner input widget group

https://gerrit.wikimedia.org/r/338795

Instead I suggest using rounded corners for the two inputs, and then keeping the message boxes square and slightly separated as in Volker's mockup.

A slightly separation makes it look like a worse glitch than the original 1px problem we were trying to fix in my opinion.

The separation looks deliberate. The glitch looks wrong. Unless you have any better solutions...

The separation looks deliberate. The glitch looks wrong. Unless you have any better solutions...

The proposed separation seems too little, making it look like it accidentally broke. That's at least how it looked to me and the reason I thought it was an accidental regression when I reported it at T154762. If we want it separate, we may need to separate it a bit more. However, I think it works better connected.

Looking back, this solution was a replacement on the way to signal issues in the text fields. Originally a tooltip at the side pointing to the text field was used and it was not working. Users were not noticing it and complaining about their messages being posted anonymously by accident. Once we showed the message visually as part of the text area, the issue was solved.

I think the message is strongly connected conceptually to the post (telling who the author for your content will be), and it makes sense to show it connected to it. The more contextual the less it will look as a random banner and less likely to ignore.

Maybe it could be possible to have a specific component that extends the text input elements to have integrated warnings. Maybe by actually making it a single component it is easier to deal with the logic about when corner roundness should be applied. Another option is to postpone the fixes until technology caches up and a more elegant solution is possible.

The patch adds 0.5em which is a little larger. I think this is better than the current buggy look for an interim solution.

Before:

After:

Change 338794 merged by jenkins-bot:
Fix adjacent input widget border radii

https://gerrit.wikimedia.org/r/338794

The patch adds 0.5em which is a little larger. I think this is better than the current buggy look for an interim solution.

Ok, works for me.

Change 338795 merged by jenkins-bot:
[mediawiki/extensions/Flow@master] Separate message boxes from round-corner input widget group

https://gerrit.wikimedia.org/r/338795

Checked in betalabs - the gap is present for the anon warning for new topic/reply/edit Board description

Proper corner rounding is in place:

QA Recommendation: Resolve

jmatazzoni closed this task as Resolved.Apr 26 2017, 1:47 AM