Active On, Status No

Bloke · 2023-03-31 16:40:09

Slight snag with option 2 (Pages/Forms layout) is that it’s designed such that the <form> is in the bigger area. The smaller sidebar is only for switching content and isn’t part of the form submission itself. In the Plugin panel case, all fields need to be in the form.

I’m not sure if it’s possible to hack it so the form spans the two div containers, e.g.

<form class="txp-layout">
   <div class="txp-layout-4col-3span">
       // main 3 textareas
   </div>
   <div class="txp-layout-4col-alt">
      // smaller form fields in here
   </div>
</form>

If I can figure it out, I’ll try that. If not, we may have to fall back on a layout like in the Images panel.

EDIT: Oooh, it seems to work okay.

Last edited by Bloke (2023-03-31 17:15:22)

Bloke · 2023-03-31 19:19:48

I’ve tweaked the layout as a sort of hybrid between the Pages and Image Edit panels.

The save/cancel buttons are rendering a little oddly. Not entirely sure how to fix that at present: I’ve probably missed a class name. Edit: I did.

I also need to push some changes to the UI library so CheckboxSets (and probably RadioSets) can take some optional glue – such as non-breaking space – to avoid them rendering strangely.

Last edited by Bloke (2023-03-31 23:12:18)

phiw13 · 2023-04-01 02:05:54

A quick look on dev demo site – looks good I think.

A non-breaking space between checkbox and <label /> ?

Bloke · 2023-04-01 06:19:02

phiw13 wrote #335230:

A non-breaking space between checkbox and <label /> ?

Yes but it needs to be done in the UI library. Gotta figure out how to do that

Bloke · 2023-05-01 10:07:05

phiw13 wrote #335230:

A non-breaking space between checkbox and <label /> ?

This is really annoying me. I’ve just pushed a commit that changes the way checkbox and radio sets are rendered. Instead of being two side by side elements, I’m wrapping the input and its associated text in a <label> tag. The theory being that if they’re wrapped like that, they might stay together, as the browser considers them as a unit.

Nope. It renders this markup:

<div class="txp-form-field-label">
    <label for="flags">flags</label>
</div>
<div class="txp-form-field-value">
    <label for="flags-1"><input class="checkbox" id="flags-1" name="flags[]" type="checkbox" value="1">&#160;plugin_has_prefs</label>
    <label for="flags-2"><input class="checkbox" id="flags-2" name="flags[]" type="checkbox" value="2">&#160;plugin_lifecycle_notify</label>
</div>

That looks right to me (although maybe the for attribute is redundant in this construct? Not sure on the correct usage) but the checkbox still appears on its own, and the label wraps to the next line on the second pairing. Baffled. Maybe there’s some admin CSS that’s overriding this and preventing the nbsp from taking hold? Any ideas why this may be occurring and what we can do about it?

If we can get it working at the UI library level here, I’ll consider adding some $glue parameter, or repurpose the break property perhaps in CheckboxSet/RadioSet so it acts as the join between input and label.

Side note: is the approach of wrapping the input and label in a <label> tag good practice? Or is it better if they’re separate and side-by side, as it was? Or is there any other markup we can consider that would help lay this out in a satisfactory manner?

phiw13 · 2023-05-01 11:43:14

(i haven’t tried your recent commit yet)

Side note: is the approach of wrapping the input and label in a <label> tag good practice?

Yes, that is a good (and valid) practice – and in this case, it will help solve the issue.

Given the label tag wrapped around both radio/checkbox and label-text, add this to your custom.css ( or add to textpattern.css)

label[for*="flags-"] {display:inline-block; background: cyan;}

(or check the mock-up here)

There might still be problems, e.g. with a language where the string is long without spaces.

Technically, the for attribute is not needed in that case/pattern, but it doesn’t hurt to leave it.

BTW: in this

<div class="txp-form-field-label">
    <label for="flags">flags</label>
</div>

the <label for="flags"> is not needed (and can be confusing for AT I suspect), you set the <label /> directly around the radio/checkbox – see the pattern on the Preferences panel.

–^–

PS – for the whole plugin edit panel, you need to make your the for attribute on the <label /> has a corresponding id attribute on the <input /> or <textarea /> – both need to be the same value. Currently the id are all missing.

Or is that an issue with the new UI-widget library? I now see the same problem on other recently updated panels.

Bloke · 2023-05-01 11:57:37

Ah okay thanks. So maybe something in our stylesheet is stopping it wrapping, or something needs explicitly adding to make a non-breaking space not break! I’ll add your CSS and give it a whirl. The only thing I’d prefer is if we could not specifically target these elements but make a wrapper class that we can hook into so the CSS pattern can be applied elsewhere.

Regarding, the for, I think it adds that automatically if we pass in an ID to the constructor, but I wonder if it’s adding it when one hasn’t been supplied. I’ll check that, thanks for the sanity check. It’ll be a UI library thing I need to chase down.

Bloke · 2023-05-01 12:07:20

Oooh, one other thing. As it stands, I’ve got:

input.sp.label

inside the <label> tag wrapper. That’s hard coded for now and I may expose the separator as mentioned above. Or maybe if the CSS tweaks fix it, the nbsp might not be needed at all.

Either way, if one were to pick an RTL language, would that practice break things? Or is the browser clever enough to reverse the order of elements?

Maybe separating them like they were is better? Or adding some markup to them to indicate how to treat them in RTL cases is necessary? I know we have a bunch of RTL rules in our stylesheet so maybe that covers it. Best practice here is a bit outside my sphere of knowledge.

Last edited by Bloke (2023-05-01 12:08:50)

phiw13 · 2023-05-01 12:14:11

Either way, if one were to pick an RTL language, would that practice break things? Or is the browser clever enough to reverse the order of elements?

Do nothing and let the browser do the necessary magic!

Ref the non-breaking space, if you go with the suggested markup (<label /> around radio/checkbox) you can omit it I think.

Bloke · 2023-05-01 12:25:09

phiw13 wrote #335388:

Do nothing and let the browser do the necessary magic!

I like this answer.

Ref the non-breaking space, if you go with the suggested markup (<label /> around radio/checkbox) you can omit it I think.

Thank you. I’ll l try that in the next commit once I’ve tested the CSS.

Bloke · 2023-05-01 13:26:38

This CSS works a treat using the new wrapper class:

.txp-form-field-set {
    display: inline-block;
}

Unfortunately, I built the code in my local textpattern-hive-admin-theme repo, compiled it, but when I pulled it into core, a whole bunch of ther stuff came with it… and the changes I made weren’t part of it. Odd. So I backed that out. But it does work and will work, it just needs someone cleverer than me to merge everything in properly.

Bloke · 2023-05-01 21:41:57

phiw13 wrote #335385:

the <label for="flags"> is not needed (and can be confusing for AT I suspect)

Fixed, with luck. Thank you.

Bloke wrote #335390:

[CSS change] does work and will work, it just needs someone cleverer than me to merge everything in properly.

I’ve created Pull Requests 1 and 2 for this, so when Phil merges those, we can pull the changes into core.

Textpattern CMS

Textpattern CMS support forum

#37 2023-03-31 16:40:09

Re: Active On, Status No

#38 2023-03-31 19:19:48

Re: Active On, Status No

#39 2023-04-01 02:05:54

Re: Active On, Status No

#40 2023-04-01 06:19:02

Re: Active On, Status No

phiw13 wrote #335230:

#41 2023-05-01 10:07:05

Re: Active On, Status No

phiw13 wrote #335230:

#42 2023-05-01 11:43:14

Re: Active On, Status No

#43 2023-05-01 11:57:37

Re: Active On, Status No

#44 2023-05-01 12:07:20

Re: Active On, Status No

#45 2023-05-01 12:14:11

Re: Active On, Status No

#46 2023-05-01 12:25:09

Re: Active On, Status No

phiw13 wrote #335388:

#47 2023-05-01 13:26:38

Re: Active On, Status No

#48 2023-05-01 21:41:57

Re: Active On, Status No

phiw13 wrote #335385:

Bloke wrote #335390:

Board footer