Load the attached testcase and type something in the input in the second column. The text will be garbled and placed below the first column.
Created attachment 13582 [details] Testcase
This affects many form widgets, though I suppose this is covered under the original blog post on the feature with "At this time any stacking context children like relative positioned content or content that uses opacity will position impoperly (as though the column didn’t exist)" (one of these day's I'll learn to read...)
This definitely needs to be fixed before releasing Safari. Changing to P1 and adding NeedsRadar keyword.
Created attachment 13584 [details] Testcase with more form elements Expanded testcase with more form elements. If you remove the padding on the columns, the selects behave properly.
Layers ignore columns.
The columns spec is probably going to change completely before it's released (people are actively proposing different syntax etc. in the WG right now). I'm not sure why this needs to be P1.
(In reply to comment #6) > The columns spec is probably going to change completely before it's released > (people are actively proposing different syntax etc. in the WG right now). I'm > not sure why this needs to be P1. I marked it P1 because it just looks really, really bad. Have you tried typing in the right-hand text box in the first test case (Attachment 13582 [details])? Unless column support is going to be removed as part of the stabilization spree, I think this should be fixed. Obviously, that's just my opinion.
Something that looks really bad but is based on a relatively new experimental feature is not a P1. It would be nice to fix, but isn't a showstopper problem like a crash or hang or regression.
Fixed when I added self-painting overflow layers.