Hi Nick – I’m sure Jon can weigh in more thoroughly but I think this is similar to some of the concepts he raised here.
The one part that I’d say from the LiveWhale product perspective is, when Jon mentions in the other thread
We are not using Content Layouts v2, because adding things like classes and data attributes to the whole layout using the Formats menu does not work in v2. I’d love to see that change in the future, but for now, we’re sticking with v1.
The tricky piece is this: Content Layout v1 essentially stamps out static HTML blocks into the WYSIWYG page editor. So, once they are saved, that static HTML gets saved with each story/page/event/profile/etc, and so there’s no easy way to guarantee consistent HTML across all instances of a CL. (Once it was stamped out, you were kind of stuck with whatever HTML was used.) 90% of the time, we found in our projects that you’d want to go back and tweak the HTML inside of the content layout .xml file, but it was too late if the CL had already been stamped out dozens or hundreds of times.
That’s why we built Content Layout v2: the stamped out version when saved gets transformed to just a <widget type="content_layout"> behind the scenes with multiple <arg id="editable"> for each editable area within. Then, on front-end rendering, the HTML formatting from the .xml file gets used each time on the front-end, meaning you can change the HTML once (there) and it’ll immediately take effect everywhere that CL was used.
The main compromise to that approach, as you and Jon have both found, is that in order to do that, we essentially “lock” the HTML outside of editable areas so it always matches the .xml content layout definition. That’s why Style Formats and other tricks (Editing source, etc) doesn’t work to add class=“left” or class=“background-blue” to those CLs—on save, CLv2 discards all the preview/outer html and just saves the inner editable content in the <widget> format.
All that being said: I can certainly envision some sort of expansion (CLv3?) that would take the principles of v2 but allow some sort of outer class=“{variable}” to be used, such that editors could pick between picture-left and picture-right, or background-blue and background-orange. But, that’s not currently on our roadmap. Since the concept of “having a few different CLs for the different layout options and/or color schemes” works as-is, I don’t necessarily see that getting prioritized soon. But, always happy to see or participate in further conversation about it!