Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Columns Block: Make responsive, make editor and theme match #10541
This PR does a number of things.
There is some overlap with the column blocks due to the fact that this PR makes them more or less lose their footprint, which makes the hover outlines overlap at times. Perhaps the longer term fix here is to make those blocks actual pass-through blocks so they don't have hover outlines, or can be selected. But in the mean time, this PR intends to make the columns block ship-ready for 5.0.
Please test it thoroughly and decide if you agree!
referenced this pull request
Oct 12, 2018
Some other things that don't quite work as expected:
Edit: that's actually not an issue, it's a feature, you need to click on the block first, sorry about confusion :(
Edit: I can't reproduce anymore after rebasing with
I'm getting totally lost trying to sift through the columns here and to suss out what CSS is targeting what. I don't think this is a regression—I've gotten painfully lost every time I've tried to test the columns block, but it's making it super difficult for me to provide helpful feedback and/or suggestions here.
I'm seeing a lot of overlapping elements:
I'm not sure if this is intended behaviour, but it's contributing to the overall feeling of lost-ness.
Hiding all the placeholder content (so both "Write your story" and "Add text or type / to add content") would help clean things up a bit, since this seems to pop up all over the place and often in unexpected spots.
I can't select the ellipsis menu for any of the individual columns at the right, or those columns that are below another column block, and I have a lot of difficulty selecting the parent column block:
What's the rationale behind making each individual column selectable, as well as the parent column? Is this an extensability thing, or is it just so you can apply CSS classes to the columns individually? Can we simplify by removing this ability? Would it make sense to include a hairline outline of the columns, so that people could explicitly see the column structure at work and better understand where each column begins and ends?
Using an embed block seems to break the columns out of the editor window:
Columns don't span the full width of the screen if the content in them is short—this may also be by design, but I would have expected a full-width sort of deal here:
I'm not certain how much of this is helpful or specific to this PR at this stage, but I can test a bit more later today to see if I can't suss out some of these issues in more detail. Offhand, I wonder if using grid instead of flexbox might make some of these behaviours a bit more consistent and reliable.
Yep, that's what happening here. Since it isn't a regression it's probably not strictly important to fix here. I tried fixing it by applying an
As the parent column is also a block, it needs to be selectable for accessibility reasons (keyboard nav) but also so you can select it to change settings.
Some of these seem less regressions since they work on master. There is a lot of stuff to test here.
@sarahmonster showed me (in-person) thus far the only fix that consistently works needs to be applied high enough in the DOM that it clips the block toolbar
The tricky thing here is that UI freeze is tomorrow. If we can get this in, we can fix bugs later. If we don't get this in, I'm not sure.
The css here is complex, and the block as a whole needs love in phase 2. However for basic things it's hugely valuable.
If we feel this PR improves what's in master and doesn't introduce new issues, I feel it's worth merging as an iterative improvement and then track anything missing.
@mtias any thoughts?
Oct 18, 2018
Responsiveness looks good!
I have a few other minor things that I noticed...
Inserting a block inside the column is not done so on the left side as it the usual approach but on the right side. It would be good to keep it consistent.