Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Polish datetime popover. #18235
The popover inherited a min-width of 260, which is insufficient, then overrode it just for the edit-post-schedule flow. This means the datetime component looks fine in the sidebar, but no-where else.
This PR changes to use a padding in the component itself, making it work everywhere.
Example of component used outside of sidebar, before:
Thank you, Riad, for the review in #18235 (review).
As you can see from the ensuing discussion I tried my best to work outside the baked in padding. However I failed to do so, and I see no way of fixing this issue without throwing out the calendar 3rd party library entirely and picking a different one. It's just not that good and has so many hardcoded inline styles that are necessary for it to function.
The good news is, I've applied a bunch of polish to this PR:
Same-height inputs, more cohesive padding and spacing. It looks way better, and it fixes the issue.
The only price is, when you mean to use the datetime component inline, as in the postpublish dialog, you have to unset the left and right paddings.
I think that's a small price to pay to move forward, without a total refactor. Let me know what you think. I've rebased and squashed this nicely so it should be easy to re-review.
Fair pushback, I suppose I didn't fully explain why I prefer this. It has to do with the following:
The date component adds a horizontal scrollbar if the popover is smaller than 255px + 2x13px added further up that hierarchy. The min-width for popovers is 260px, defined elsewhere. Which leaves us two ways to avoid a horizontal scrollbar when used outside of the sidebar:
I can't stress how ugly the code for the date time library is — you kind of have to inspect it to understand why. I mean a third option is to add additional CSS classes or wrappers for any third party that means to use the component inside the popover, and set that class to 280px width. But it's hack upon hack.
That is how the date-time component looks if you don't apply the following CSS:
In other words, if the date time component is used in a popover outside of
Sure, that's an option — but it feels like it optimizes the date time component to be used inline, vs. used in a popover, and I would suggest the latter is far more likely.
Ok, I understand better, sorry for the back and forth.
I think all components in
That said, I checked deeper and yeah, the issue is the negative margins. I think we can probably remove them and find a way to remove the big padding that calendar has but I'm fine with this PR making an exception to the rule above.
The popover inherited a min-width of 260, which is insufficient, then overrode it just for the edit-post-schedule flow. This means the datetime component looks fine in the sidebar, but no-where else. This PR changes the base inherited minwidth to 270, so the component can be used outside of the sidebar.
The DateTime component as it exists, references a 3rd party library that uses lots of inline styles and hard-coded widths and dimensions. Having explored various other approaches now, there are only two ways to fix this. 1. Actually add the padding to the component itself. This is the only way to make it work inside popovers when used outside of WordPress. 2. Do a major refactor to include a different datetime library. In order to move forward, I'm therefore embracing the padding.
Rebased to see if that makes the checks pass.
Thanks so much for the reviews, Riad. Every question you've asked is right, and honestly I wanted to address them. But the way the datetime component is built, it really deserves a bigger refactor to make this all possible. The problem with those negative margins is that it's a horizontally sliding calendar sheet that's built in a roundabout way. If we tinker with the margin, this sliding effect breaks when you press "next", which means the styles that are set inline need to be overridden also, and at some point we've reimplemented the whole thing in overriding CSS
But I do believe there is a ticket to revisit the datetime component entirely, that will be a good opportunity to make this better.