Feature request: Make X/Pro really 'pro'

I learned to code in the prehistoric ages where where HTML would be crafted like <font size="2">Hello Dinosaurs</font>. Yet, even in those days, the ‘font’ tag was deprecated. When CSS brought us the split in content and styling, it enabled us to let clients deal with content, while designers and developers dealt with the way it was represented. Lovely.

The issue with X/Pro
In the past years Theme.co released us from the burden of having to develop the same elements again and again, by developing X and Cornerstone, a page builder that actually worked. However, it also reintroduced inline styling. While the CSS is now technically rendered outside the element, the ‘inline’ issue remains apparent.

Let’s slap a button on a page in X. Don’t change any styling and the Chrome inspector will show you the following:

<a class="e1138-6 x-anchor x-anchor-button" tabindex="0" href="#">
  <span class="x-anchor-content">
    <span class="x-anchor-text">
      <span class="x-anchor-text-primary">Hello Dinosaurs</span>
    </span>
  </span>
</a>

And the CSS:

.e1138-6.x-anchor { 
    border-radius: 0.35em;
    font-size: 1em;
    background-color: rgba(255,255,255,1);
    box-shadow: 0em 0.15em 0.65em 0em rgba(0,0,0,0.25);
}

Developing a website with a team implies the use of a code repository, like Github, were you maintain your code. If you want to change, lets say, the border-radius for all the buttons on your website you would regularly to the something like:

a.x-anchor {
	border-radius: 0;	
}

But, since X renders pseudo-inline CSS (in the index file) we’re forced to use !important for every change that we want to be persistent. There is no valid reason for this. We did not add any styling to the element in X. It’s even worse, the roundness of the corners can not be changed in X > options > buttons, nor on a page level where we add the button. If the developers at Theme.co would have put their styling in ‘integrity-light.css’, our code would have priority over stack’s styling.

If we want code clean, we want to avoid using !important. We want to avoid clients making design changes and keep design separate from the content. Effectively X sends us back to the age of ‘Hello Dinosaurs’.

How to fix it
The magic option that would solve all of this would be a global setting:

[ ] enable inline css

Following ThemeCo’s recent philosophy in the way stacks are applied, this would be a ‘default’ for all pages. People with certain roles, like editors, could still be able to to re-enable this on a page-level. We could still have that special campaign page with alternate styling. Authors, or contributors would be able to deal with the content, knowing they will not break the design.

Please, please, pretty please
Start by moving all default styling to the chosen-stack.css file. So we can work in teams and still keep using those awesome features of X/Pro & Cornerstone.

Keep the index free of pseudo inline CSS, unless explicitly defined in X.

Thank you.

1 Like

Hi,

Thank you so much for the feedback and detailed post.

I will forward this to management and our web development team for review.

Have a great day! :slight_smile:

Hi @ctrlspatie

Thanks for writing in about this. In terms of theme architecture we want to keep those static stylesheets as lean as possible. They only contain a minimal amount of CSS for each element to provide structure that isn’t directly customized. The default styling itself is still generated in our dynamic CSS system - this helps us avoid two things. First, we’re not doubling up on styles that will most likely be customized often. Second, our generated styles don’t have to be overly explicit which saves space and makes the CSS generation faster

Regarding the recent announcement about the future of stacks, we’re already following this philosophy for elements. Each element starts with some vanilla reasonable defaults and you can customize everything to make your own designs.

That being said, I can confirm that the way it is now is how it will stay. I would advise looking for new strategies to achieve your desired effects. Let me point you in the direction of a few things that I think will help you avoid these situations and smooth out your workflow.

Per Element CSS
Have you tried the “Element CSS” feature? It sounds like what you’re describing with “Enable Inline CSS”.

First, make sure advanced mode is turned on from your preferences (cog icon in the bar) then inspect an element and click the “Customize” control group. There will be a button called “Element CSS”. This will allow you to write custom styles and directly target that element.

CSS Specificity
There’s certainly no need to use !important wherever you want to override something. Just use a selector that is stronger. For example, if you add a custom class to the element called custom-button you could use this style in a global stylesheet:

a.custom-button.x-anchor {
  border-radius: 0;
}

A body class would work too. You can add classes to the HTML body element on any page from the page level settings. There are also some built in body classes like home-page. Using one of these your CSS could be:

.home-page a.x-anchor {
  border-radius: 0;
}

Either of these methods would make your CSS stronger than than generated CSS.

Default Presets
First, let’s assume you have created a preset for the button element with the border radius removed. If you go to the Template Manager and click the cog icon in the bar you can manage the default presets for each element. Just assign your preset to the button, and now every brand new button you add will have that preset applied. This can be incredibly powerful part your workflow (especially with teams) as you can predesign your element styles first, then quickly build out pages with them without needing to stop and apply each preset along the way.

Hopefully this helps give you some ideas on how to work through the pain points you’re running into.

@alexander

The decision to change the workflow is a tough one.

The speed at which a website can be assembled with X/Pro is amazing and your solition is the most solid and reliable I know.

Yet, the classic way of working (in a child-theme) sometimes has preference, especially for larger projects. We need to have the code in one place. I was looking for a ‘best of both worlds’ solution.

Thank you very much for your clear and extensive reply. Your suggestions certainly help to get the job done for now.

You’re most welcome.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.