Page MenuHomePhabricator

[Beta] Alignment of Q numbers/Primary buttons are not to spec
Closed, DeclinedPublic

Description

User story: N/A

We have this

The Wikidata Q item and primary button are right justified:

We want this

The "dot" divider stays centered in the middle down the line, with the Q item being right-justified from the dot, and the primary button being right justified from the right of the panel/box itself.

Acceptance Criteria:

  • The "dot" divider stays in the middle, regardless of whether a statement is primary or not primary

Spec for reference

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 19 2019, 5:42 PM
Ramsey-WMF triaged this task as High priority.Mar 19 2019, 6:01 PM
Ramsey-WMF added subscribers: Ha78na, egardner, Cparle.

Seems like an easy one. Throwing it out for @Cparle , @egardner , or @Ha78na to grab first dibs :)

Ramsey-WMF moved this task from Untriaged to Next up on the Multimedia board.Mar 19 2019, 6:02 PM
Ha78na claimed this task.Mar 19 2019, 8:35 PM
Ha78na moved this task from To Do to Doing on the Structured-Data-Team-Current-Work board.

Change 497835 had a related patch set uploaded (by Ha78na; owner: Ha78na):
[mediawiki/extensions/WikibaseMediaInfo@master] Styling adjustments on captions and statements tabs

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

Change 497835 abandoned by Ha78na:
Styling adjustments on captions and statements tabs

Reason:
Found out you can use flexbox with mediawiki which changes ... everything. Would have been nice to realize this earlier

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

Is this a *big deal*?
This is a little annoying because we're dealing with other languages: we can't set a fixed length, we don't even know which of the 2 versions is going to be the longest in any given language.

The only way I can think of doing this is to first render both "primary" and "make primary" (or "prominent" and "mark as prominent"), calculate their width, take the largest one, and set that fixed length.
It's not the most complex thing to build (and I'd be happy to, if we care about it), but smells a little like a "too much complexity/brittleness for what it's worth" thing (unless someone knows of a better way to accomplish this)

This comment was removed by Ha78na.
This comment was removed by matthiasmullie.

@matthiasmullie Thanks for calling this out.

I've implemented an initial solution that uses flexbox https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/WikibaseMediaInfo/+/498261/14/resources/statements/ItemWidget.less that has the alignment. There could still be improvements to make on this to enable wrapping if text on either side is very long... @egardner could you take a look too and give any thoughts?

Ha78na reassigned this task from Ha78na to egardner.Mar 28 2019, 2:47 PM

Still working on this best solution this that doesn't effect i18n support. Re-assigning to reflect who is working on it now and moving back to in progress.

Change 498261 had a related patch set uploaded (by Eric Gardner; owner: Eric Gardner):
[mediawiki/extensions/WikibaseMediaInfo@master] Refactor panel styles to use LESS features, Flexbox

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

Unfortunately, getting the dots to align under all circumstances is going to be pretty tricky, and may not be worth the effort required (at least right now). I would argue the first priority should be maximum responsiveness so that we can accommodate different languages, different screen sizes, and arbitrarily long labels.

The current layout of the ItemWidget accomplishes this using Flexbox. Below is a screenshot with the relevant elements highlighted in magenta:

Here's what's going on:

  • The row with the grey background has a variable width based on the size of the panel as well as the presence/absence of the red trash can icon. It will expand or contract so that it plus the icon (if visible) always take up the full width of the panel.
  • Inside of the row, we have two child elements. The label (left-hand side) and the extras (right-hand side). Using Flexbox, it is easy to lay out these elements so they sit at opposite ends of their parent (the grey row), regardless of how long the text on either side becomes. This is all accomplished without any hard-coded values (which could potentially break the layout at small screen sizes or when there is lots of text to display).
  • The problem is that the dots don't line up in all circumstances here. Because the text on the right changes from "Prominent" to "Mark as Prominent", the bullet dot is pushed away from the right edge. The left- and right-hand elements in each gray row do not know about the existence of other rows above or below them, so there is no way to keep them in alignment without sacrificing responsiveness and flexibility. This is exactly the kind of problem that the new CSS Grid standard was created to solve, but I don't think we are allowed to use it yet.

If the visual neatness that comes from getting those dots to always line up properly is still a priority, I can look into trying to add a flex-basis rule to the left- and right-hand elements inside these rows. That would theoretically let you define a "base" width of elements that will be overridden if the content won't fit properly. This can sometimes work but it can also be kind of unpredictable. However, I would argue against just hard-coding an absolute width here because I think that will create more problems than it solves.

Thanks for deep-diving into this @egardner (and @matthiasmullie). Let's go with what we have now that Flexbox is doing its thing.

Flexbox, I'm afraid, also isn't the silver bullet here, I believe.
It would allow both "Prominent" and "Mark as prominent" to get a shared same width in a way that would work for other languages/smaller screens (it'd just adjust to the longest thing)
But it requires both to be there, as I understand it, unless we nail the default width, but we can't do that in a translation/viewport-agnostic way (correct me if I'm wrong, my frontend experience is rusty)
AIUI, unless both "prominent" and "mark as prominent" as displayed, it wouldn't display consistently.
I.e.: if there's only 1 element, it'll just use that one's width. Making it prominent will change that 1 element and it'll expand. Changing it again will also change its width back.

Closing this after chatting with @PDrouin-WMF again today - we can re-visit in the future if necessary.

egardner closed this task as Declined.Apr 8 2019, 9:49 PM
egardner lowered the priority of this task from High to Low.