Still learning here! Just styled my first real-world page, updating the class names to something meaningful. I wrongfully assumed that the block class was globally scoped, not restricted to the page. I can see now that I need to create an additional class if I want it to be globally available.
Question 1: can I make/copy the block class styles and make them global, or do I have to recreate them as global classes?
Question 2: What does the dot show/hide toggle in the block class field do? Toggling it, even when there are styles applied to the block class, doesnât appear to toggle the styles on and off?
There is currently an open feature request for this:
Please see this post for a working solution in the meantime:
For classes they automatically become active when any styles are added to them - the dot is there if you want to manually activate the class even before it has become automatically active.
I have upvoted the feature. My instinct is that block classes should be global by default, as they would be when hand coding a page. There isnât really a paradigm for page-specific style sheets in the old world. I suppose it helps reduce bloat which is a good thing. Itâs just not at all obvious that the class style is ONLY loaded on the current page. Perhaps instead of âClassâ being the label, it should be âBlock Classâ or âLocal Classâ, or some such derivative, with the section below being labelled as âGlobal Classesâ.
The dot toggles is still confusing me though⌠it doesnât appear to do anything when styles are set to the class. Literally nothing! What am I missing?
The toggle allows you to have the class/ID appear on the frontend even if there are no styles applied to the block.
Block classes and IDs donât appear by default on the frontend. Only when styles have been added on the block level the class will appear.
If you have styles applied, toggling the class wonât do anything.
For copy/paste block styles to global classes I usually do this:
Why doesnât the dot disappear when styles are applied then? That would give a clue to the user that the feature only applies when there are no styles applied to the block class.
Additionally, I see now how to copy block styles into a global class⌠Is it however not possible to copy âgridâ styles in this manner? They donât seem to carry over.
Why should it?
If anything, it should activate automatically when styles are applied to the block which would result in turning green.
While this would give the user a better idea and direct visual feedback, Iâm not sure if that would be a proper solution, since there are more things to consider in direct relation.
Because, according to the above âIf you have styles applied, toggling the class wonât do anything.â Itâs not an indicator that styles are applied, nor is it a toggle to show/hide the styles in the editor⌠itâs a toggle that optionally enables a class name to be rendered on the element on the front end, in the event that it is empty of styles.
A toggle that behaves like an on/off but doesnât actually do anything in a particular context is quite confusing. It needs to be only visible contextually to make sense, IMO.
Dots elsewhere clear values, which adds further confusion.
But perhaps Iâm still misunderstanding itâs full purpose? Which is kinda my point, and why I asked!
Agreed, like I stated in my previous post, but your proposition doesnât make any sense to me.
Something like this would make more sense. While writing this post, @StrangeTech shared the exact same thought.
Disagreed, there is a clear UI language to differentiate these.
Also, the color is quite descriptive. In addition, there is a tooltip available.
Didnât read something like this here, ever.
Automating it makes total sense. The bit that threw me off entirely was that the control is still visible when there are active styles, but of course doesnât do anything in this state.
I guess that would be alleviated if the control was hidden when styles are added, and only reappears if all styles are removed again. Thatâs assuming I have understood it correctly, and it doesnât serve another function in that state.
Can you explain the differentiated UI language to me? I missed the colour differentiation, but I am colour blind, and tiny spots of colour are indistinguishable. The tooltips are a lifesaver. Iâd be lost without them.
Iâve honestly not come here to criticise, or even propose a solution. My original post was to seek understanding of something I was struggling with. Now (I think) I understand the purpose of the control, that one aspect of the UX pattern seems counter intuitive⌠that the toggle can be showing as âhiddenâ, but the class is actually still active. It would make more sense to me, at least, that the control is invisible in this state, as interacting with it is purposeless.
Thanks, FYI, itâs always good (as per WCAG) to use a visual differentiator as well as colour, for example a change of shape, and underline etc. My colour vision impairment is fairly mild, so I tend to struggle more in low light or when the colour is only present in small amount (like a dot!). Others will have far more difficulty. 1 in 12 men, and 1 in 200 women have some form of colour blindness!
Very important info, thanks!
We are currently trying to improve accessibility within the editor. Please donât hesitate to let us know if you notice other things that stick out.
Very impressed with the frontend accessibility so far, and by Louisâ fast response on the one #a11y issue I did raise. Backend, well, core isnât great to start with is it! I have no idea how someone with a screen reader could begin to use it.
The biggest thing as far as Cwicly is concerned, other than use of colour, would be to consider those with cognitive differences or limited vision.
By that I mean the UI while, very orderly, relies upon developing visual memory of where the various functions are, in which of the various panels they reside, and indeed what the icon for a particular feature is. Without text indicators, this can be an issue for some both in the cognitive and visual realms. Tooltips help of course, but they add friction. It would really benefit from some more text signposts, but I know thatâs not easy.
Itâs a really hard one to balance. I know the original UI featured a more typical âdrawersâ arrangement, and that comes with its own challenges and the current setup is MUCH neater. I donât know what the answer is, to be honest, but thanks for considering it all! Iâm not an expert in this by any stretch, but do do strive for inclusivity in my client work, which is mainly in the not-for-profit sector.
