5.2.0. Beta 1 - Initial feedback

[Misho]

Hi @alexander!

I got the chance to play a bit with the Beta, but it’s getting late in EU so I will get back to it tomorrow.

At this point, I must say that this is a fantastic step forward.

Masks are very cool, and I like how they are implemented.

It is possible that I ran into some instabilities and bugs in Components, but it is the Beta, so it doesn’t matter. Having sets that hold multiple designs is extremely useful!

Parameters are an integral part of the new system and I am eager to use them. I just have the feeling that they will be overwhelming for many users.

Yes, the theme is titled “Pro” which is a fair warning, but still…

I think that users would want every bit of assistance they can get to make this as painless as possible. A few things come to my mind:

1. List the {{dc:param:}} alongside other dynamic content so it can be inserted. I think it is not there.
2. Provide a JSON builder.

Back in the days we had the shortcode builder which was a convenient way to take the complexity out of the way. Currently, even writing simple key/value pairs can be tedious, especially when using JSON loopers. In an attempt to speed up the process, I tried doing it in Google sheets and exporting the JSON, but I have trouble doing it when there are arrays added.

I then saw the draft of the Parameters document. That escalated quickly.

I didn’t understand a word of it on the first read. Yes, I will get to the bottom of it all, and it will all make sense in time. But what about the less determined and less experienced users? In such a case, a guided wizard or Builder would be extremely useful.

I’ll do some more testing!

Thanks!

[devinelston]

@Misho

I then saw the draft of the Parameters document…

I didn’t understand a word of it on the first read.

Same.

I also tried plugging a bunch of the examples into the parameter editor, and most of them didn’t work - especially the stuff around lists, which just show up as empty in the UI, and don’t respond to clicks on the +.

[deranaloge]

@Misho

Provide a JSON builder.

i have to agree that a json builder would take some of the complexity out. it can get confusing very quickly.
cheers

[alexander]

Thanks for sharing all this. I agree wholeheartedly with all you’re saying here. We’re in a bit of a chicken/egg situation, at the moment so the sequencing will unfortunately prohibit us from implementing changes to provide some of the relief you’re pointing out is needed. Once we have them, I think Parameters will become a more popular feature, but for now it might be something left in the hands of more advanced users. The docs are definitely WIP (the current draft was primarily written as an internal reference and we added a few notes) and there will be video training as well which may help communicate the concepts more concretely.

I probably should have put some roadmap notes in the announcement thread, but I’ll elaborate here with some loosely formed roadmap thoughts. What we’ve been referring to as the “Theme Options Reboot” is a monster scope of work that represents building several new systems. Pro 6.0 will be the crowning release that ties everything together, but we’re trying to roll out a few cycles like Pro 5.1, 5.2, etc. as we build out these new foundations.

As one of those larger requirements under the hood, we created what’s effectively a mini virtual machine in Cornerstone that can keep track of different stacks and scopes of data. It’s how you can define a parameter on an element and access it on nested elements. This system is actually going to power a new feature called “Globals” as well, which is a key part of our Theme Options Reboot. Those Globals will be like site wide Parameters. Instead of just having colors and fonts, you’ll be able to define the shape and structure of all your Global settings. It’s really like being able to map your own Theme Options. This will all be done in a visual editor. The same visual editor will be reutilized for Parameters, but it will be in addition to JSON parameters (both options will always be available).

On the current trajectory, the heart of the Theme Options reboot will be a new yet to be named featured that we’re calling the “Styler” internally. Where Components and Parameters are a good way to create abstractions for content, the Styler will let you manage abstractions of CSS. We haven’t even started the exploration process here, but our goal is to create some kind of visual building experience that generates CSS. I think “CSS Hero” is the closest product I can think of that is in line with what we want to do. There will be ways to create sets of Global styles, and also use the same tool on individual elements to add one-off styles. We want to allow deep access to CSS properties. We also want it to be possible to in one click say “Add Table Styles” and it adds a large preconfigured set of styles that make tables simply look nice, and you can tweak from there. So it’s one of our more ambitious projects on the horizon.

Creating the visual editor for Globals/Parameters isn’t something we wanted to crack open until we had built out some of the more foundational parts in case they influenced any of the editor mechanics. I can’t say at this time how the following will be broken out into actual releases, but here’s how we’ve prioritized things:

• Slider Element
• Virtual Machine - provides ability to use JSON Parameters. Also lays the foundation for Improved Dynamic Content
• Components
• Templating - We’re going to revisit how templates work in Cornerstone and make the experience more consistent.
• Styler - Visually define global and per element styles
• Forms - New Form elements and backend that let you design and create forms directly in the builder.
• Globals - Will include the visual UI for Parameters.
• Improved Dynamic Content - Will allow combining multiple values using math or string formatting functions.
• Rivet - Front end javascript augmentation for elements.

So that’s a birds eye view. Very preliminary and subject to reordering as we keep moving forward and exploring the different ideas, but it shows most of what we’re trying to accomplish with the Theme Options reboot project.

Of all the potential releases we may do on this path, the current one of Components and Parameters does feel the most “lacking” to me, but only in respect to how it’s missing integration with these yet to be created features. I’m really excited for the day when I can jump into the component builder and design a contact form, then just drop that in as an element on whatever pages I need. This cycle admitingly provides lots of raw power without context.

Please keep the feedback coming! Everything you’re sharing with us is invaluable to help polish the current docs and understand what kind of video training will be needed. Thank you!

[alexander]

@devinelston, wanted to drop a separate comment here to confirm that the lists are broken. We’ll look into that.

[strobley]

Thanks @alexander for sharing the direction and momentous leap into the future… glad to part of this journey in incremental refinement.

@alexander

We want to allow deep access to CSS properties.

Seeking a little elaboration on the above quote if possible. As you understand the real power of CSS is CSS Custom Properties (aka CSS Variables). Do the plans for Styler include users being able to name, define and set CSS Custom Properties to form part the deep access?

[alexander]

Right, so what I’m getting at there has to do with how coupled are current elements are. If you inspect any element, you’ll see all these styling controls but the end result can be pretty arbitrary. Somehow CSS is getting applied to HTML, but it’s different from case to case.

Part of the “Styler” will be letting you add any CSS rule you want. Kinda like a visual builder for Element CSS. Another example would be the power offered by Oxygen’s Selector Detector although this isn’t 1:1 what we’re going for. I’m just pointing out that Cornerstone lacks the ability to style any HTML with any CSS, unless you just hand write the CSS. We’re approaching the problem from managing site wide global styles first, then coming back to allowing that same power to be used at the individual element level.

When I say “any CSS rule” that will absolute include the ability to create custom properties, and we’ll be using custom CSS properties heavily behind the scenes. In the “Add Table Styles” example I gave above. That will add a bunch of controls for you to tweak how the tables styles are generated. There might be a value like “Row Y spacing” which under the hood is --tco-table-row-y-spacing: .5em; Then we would use that value in several places to account for peculiarities in how to make responsive HTML table markup. Our goal is to provide solid approachable control sets for common patterns like typography, tables, forms etc. but at the end of the day it’s built on a system that will let you have raw access when you need it and just throw whatever styles you want in there.

Hopefully that helps clear some things up. It’s still all very conceptual at this point though. We’ve not explored it much more than identifying some goals, and identifying the right starting points for further research. We’ll be diving into all the technical details at some point during the Pro 5.3 cycle or just after.

[strobley]

Thanks @alexander, appreciate the insight and understand concrete answers are long way off conceptual ideas.

Styler sounds interesting, though I’m not a fan of Oxygen’s Selector Detector because it leads to CCS bloat through overriding styles as both styles are loaded, first the base and the override Selector Detector. Also Oxygen’s demo video it’s not clear if the Selector Detector generated CSS is output globally including pages that do not have any WP-Forms as per the example. A challenge with all plugins I guess, each loads their own CSS and JS which inevitably need to be overridden and generate additional markup.

I don’t mind having to handwrite element CSS in Cornerstone and don’t see as a short coming of the builders. Now with Components and Parameters, it makes handwritten CSS even more reusable and efficient as the element CSS is only output when the element is on the page. I think if I were to repeat the same component twenty times on a page, this would result in only one set of element CSS for all twenty - correct?

Having a visual editor sounds great, though understand the complexities in try to cater for the many permutations of native syntax for selectors, pseudo-elements and states… often it feels easier to write the CSS code than forever pointing and clicking around an editor. As Pro is indeed more developer centric, most would know how to do this.

It is a balance of usability vs performance and as you note, going from the global to element approach further challenges this… I certainly do not have the answer. To be honest, I dequeue most plugins CSS as well as Pro’s generated and enqueued CSS - thanks for being able to do this with hooks by way, I hope this ability remains even after the Theme Options reboot. Dequeuing has so far proved invaluable on two counts. Firstly, I’m not fighting the plugin or Pro theme CSS. Secondly, it removes bloat of unnecessary CSS.

The utility V3 elements you mentioned on another thread sound interesting, by further reducing unnecessary markup. As the web enters the next chapter I think most of us are seeing the bulk of intricate sites can be created with a handful of well thought through responsive reusable components. I hope proper support for responsive images as part of the image element is tucked somewhere in the priority list.

Couple of quick Q’s if I may.

1. Shall Globals also include support for users to name, define and set to CSS Custom Properties for any Global and reset --tco vars for example:

   –my-space: 1em;
   –tco-table-row-y-spacing: var(–my-space);

   –my-big-space: calc(var(–my-space) * 1.5);
   –my-global-bg-color: #f00;

2. A feature request, to extend Headlines, Buttons, Toggles etc. that allow a Graphic as part of the element to allow Raw content an icon for SVGs.

[Misho]

@strobley

A feature request, to extend Headlines, Buttons, Toggles etc. that allow a Graphic as part of the element to allow Raw content an icon for SVGs.

Ah, that reminded me of my old feature request. I’d really love to see this.

Feature Request: Icon Picker with an SVG Field?

Hi! Many elements like headings have the “graphics” set of settings. The key part is the Icons picker that shows the selected Font Awesome icons. It would be fantastic if one of the tabs in the picker is custom SVG. Clicking it would open the field where we could paste the SVG code such as this one: <svg aria-hidden="true" role="img" height="1em" width="1em" viewbox="0 0 512 512" xmlns="http://www.w3.org/2000/svg"><path fill="currentColor" d="M173.898 439.404l-166.4-166.4c-9.997-9.997-9.997-2…

[alexander]

Styler sounds interesting, though I’m not a fan of Oxygen’s Selector Detector because it leads to CCS bloat through overriding styles as both styles are loaded, first the base and the override Selector Detector.

Even though you get more CSS, it’s a great escape hatch to quickly adding some styles to markup from third party plugins that you have on your page. I’m not sure how their’s works, but in our case it would be something like:

• Add Form Integration Element and configure it to pull through
• On the Form Integration Element, open Styler from Customize (or wherever it ends up) and add styles targeting the third party markup
• Any styles that created are treated very similar to Element CSS (not global)

I don’t mind having to handwrite element CSS in Cornerstone and don’t see as a short coming of the builders. Now with Components and Parameters, it makes handwritten CSS even more reusable and efficient as the element CSS is only output when the element is on the page. I think if I were to repeat the same component twenty times on a page, this would result in only one set of element CSS for all twenty - correct?

It’s somewhat reduced, whenever possible they will share the same class names. Each component instance still has a unique ID because when the “Allow Customize” option is used you can add more Element CSS one one-off instances.

1. Shall Globals also include support for users to name, define and set to CSS Custom Properties for any Global and reset --tco vars for example:

Globals, like Parameters will just be data. They don’t do anything unless you recall them via Dynamic Content somehow. Dynamic content works in custom and Element CSS, so that’s one way to do it. The “Styler” will also be a way to generate CSS, so you could reference your Globals from there resulting in custom properties. It’s still really early to speak conclusively here since none of these things actually exist yet, so we’ll know more as that develops.

2. A feature request, to extend Headlines, Buttons, Toggles etc. that allow a Graphic as part of the element to allow Raw content an icon for SVGs.

Yes! Still one we’ve got in the backlog but hasn’t materialized yet. (thanks Misho for linking over the previous conversation.

[Misho]

@strobley

I hope proper support for responsive images as part of the image element is tucked somewhere in the priority list.

There is a very interesting approach to responsive images and applying filters. Here’s an example:

https://img.ebdcdn.com/product/frame/gray/pl5827_3.jpg?im=Resize,width=360,height=180,aspect=fill;UnsharpMask,sigma=1.0,gain=1.0&q=85

The above parameters are producing a 360px wide image, which is also sharpened.

If I remove the filter parameters:

the image is now blurrier.

If I remove all the parameters:

It’s a full size image.

Very, very interesting.

On a sidenote, we can sharpen images in Pro if we duplicate the image and overlay the two, with these settings:

Photoshop in a browser.

[Maratopia_Digital]

@Misho

https://img.ebdcdn.com/product/frame/gray/pl5827_3.jpg?im=Resize,width=360,height=180,aspect=fill;UnsharpMask,sigma=1.0,gain=1.0&q=85

Took me a while to understand what you were doing here but just had a big moment!

Would love to see the backend of this and how it looks in terms of the JSON and Parameters. I’m still taking babysteps with the whole parameters world and trying to understand it so it would be awesome if you or anyone has anymore interesting use cases for parameters.

[alexander]

@Misho,

Woah, I’ve never seen that sharpen technique with filters. Very cool!

@Maratopia_Digital, it looks like those URLs are coming from a CDN that allows dynamic image processing based on the URL. If you had something like that available you might be able to create width and height parameters and put width={{dc:param:width}} as part of the URL. It wouldn’t be able to change responsively though, so multiple images might be needed.

[strobley]

Thanks @Misho awesome find! Also digging the Photoshop in a browser with Pro.

As @alexander notes this is dynamic CDN image processing.

I guess what I’m getting in terms of responsive images is the Image element serving just one “best” dimension / file size from the available Media Gallery images based on the user device. Possibly also second placeholder very small low-quality / low-resolution image, but the goal is one best image. Currently the image element is one size fits all which has been old hat and bad for performance for sometime.

@alexander

Globals, like Parameters will just be data. They don’t do anything unless you recall them via Dynamic Content somehow. Dynamic content works in custom and Element CSS,

When say the above @alexander, does this mean after adding CSS variables to Element/Page/Site CSS, the Global can then be defined as (understanding the syntax is not correct):

{
"Primary Color"	: "var(--my-primary-color)",
"Space"	: "var(--my-space)"
}

Also, I totally see what your saying @alexander on Styler being a quick way to override design changes. I think were I struggle is this is simply walking the DOM tree for an element and grabbing classes and IDs, something easy and quick enough to do with any browser Developer Tools. Then it’s just writing CSS rules based on the selected classes and ID from the tree, again something very easily done without a visual tool.

Don’t get me wrong, I understand fully the X/Pro themes must cater for every kind of user and ability - what is easy for me may be challenging for others, and what is challenging for me may be easy for others. I’ve used Oxygen and many others, though end up back X/Pro because of what it offers above these. Every theme offers some means of being able to add CSS where as proper responsive images, rock solid accessibility features and capability for every element, and JSON-LD schema markup has a far more material impact on web ranking and usage than yet another way to generate CSS.

Realise this is getting a little off topic from @Misho’s original post and appreciate it is a distraction from dealing with bugs on this release cycle so don’t mean to take up unnecessary time

[alexander]

To your code example above, I don’t see any reason why that wouldn’t work. While Styler will fill the gap of visually adding arbitrary CSS, the main purpose will be to solve consistent global styling. Things like:

• Typography
• Long form content (consistent styling across text content without needing to create it all in the builder)
• Forms
• Tables

At the moment, you get all those styles from Stacks which are opinionated and bring lots of styles you may not want or need. Years ago when X was launched, Stacks were popular because you could quickly start with a finished design. We want to remain true to that, but prevent having to hard code lots of specific customization options. It’s a bit hard to fully articulate without having explored it ourselves - right now we’re just working with an end goal in mind. We want you to be able to pick and choose entire sets of finished CSS, but also richly customize it at any level. So the main focus isn’t individual elements, although they will benefit greatly from this new system by being able to opt-in to it.

[strobley]

Thanks @alexander this makes a lot of sense.

A feature request would be to disable CSS generation on parts of the future entire sets of finished CSS. Much like how the toggles work in the builders to keep the output as lean as possible. This is one of the reasons I dequeue the stacks and disable Theme Options generated CSS.

[alexander]

Definitely. That’s part of our thinking as well. Don’t need table styles? Then don’t add them. There will be some very foundational thinks like root font size (at all breakpoints) which are always output, but things like forms, tables, blog content styles etc. should be opt-in. There will be one static CSS file to create some structure and utilities but it will be much smaller than any of the current stack stylesheets.

On the topic of optimizations, have a look in cornerstone/includes/integration/wordpress.php in the beta. If you add apply_filters( 'cs_disable_wp_extraneous', true ); in a child theme it’s a quick way to unhook a bunch of WordPress output that isn’t needed on sites that don’t utilize Gutenburg.

[strobley]

Awesome! Thanks for the tip, funnily enough I apply all the same removals myself and it took a longtime to find them all.

I have an addition to the list in cornerstone/includes/integration/wordpress.php. It appears that duotone SVG tags are added to the frontend even when duotone is disabled. This seems to be since WP 5.9.1 and currently only removable with remove_action('wp_body_open', 'wp_global_styles_render_svg_filters'); though I think there is an issue to disable as part of disabling duotone so this may take a while. Scanning Github, it looks like this must be after wp_body_open to have the desired effect.

I tried using apply_filters( 'cs_disable_wp_extraneous', true ); works perfectly except for the removing SVG markup.

[alexander]

Nice find, thanks for sharing that! I didn’t notice they added it in 5.9.1. I’ve updated our integration to unhook that as well. Luckily it’s working fine just adding it with the other remove_action calls in that integration file.

[Maratopia_Digital]

@strobley

I dequeue the stacks and disable Theme Options generated CSS

Hey @strobley, that is a really cool idea. Would you be able to tell me how you did this and also if it caused your website to look funky because you’ve disabled the theme options CSS and dequeued the stacks?