"Layout" Nodes (again) #106
Description
What are 'Layouts'
A "layout" component is a generic set of blocks/columns which have been used to create various editorial components. These are published as <experimental> bodyXML components since Spark, but also existed in Methode.
Underlying "Layout" components
- Layout: a "box" that can be shaded, and contains a flexible number of slots, and an optional heading/image
- LayoutSlot: a "column" inside the "box"
- LayoutImage: a hack to represent an image used inside a Layout. Needed because of publishing constraints with
<experimental>(see LayoutImage #93 )
Is it possible to produce these in Spark
Not on their own, but Spark has more defined editorial components which use these layout elements underneath. These are:
Editorial use cases
- Infobox/Explainer: a box with copy, often used to promote other content, newsletters etc. Sometimes used for editorial purposes (i.e. an aside). (44833 uses in Spark)
- Image Pair: a pair of images (8245 uses in Spark)
- Comparison: comparing things (6092 uses in Spark )
- In Numbers: three big numbers together (316 uses in Spark)
- Timeline: a timeline of events (317 uses in Spark)
Challenges
Neither the Layout node nor the editorial use cases have ever actually been defined in the bodyXML schema. They were originally published as <div> elements via Methode, and subsequently not added in that state to the Generic Publishing APIs. When migrating to Spark, we decided (foolishly) to publish them in their expected <div> state, using the <experimental> tag to bypass validation.
This has two consequences:
- The structure we publish isn't immediately/obviously mappable to the editorial use cases (for example, it's difficult to distinguish whether something is an image-pair or a comparison block just looking at the divs)
- Images inside these blocks are treated weirdly (see LayoutImage #93 )
Options
- Define the Editorial Use Cases
Create new InfoBox, ImagePair, Comparison etc nodes in Content Tree
In order for this to work, I think we must either (in order of increasing difficulty):
a) Map what we can from the existing structure, accepting there might be some lossy transformations
b) Republish from Spark, including a new attribute data-component-name="infobox" and use that to aide transformations
c) temporarily define equivalent bodyXML structures in the bodyXML schema, and republish everything from Spark to that new structure
- Define the raw Layout nodes
Pro: simpler, less up-front work (schema work already mostly done)?
Con: breaks our rule of "everything in content-tree is supported by Spark" - Layout as a node doesn't really make sense or reflect what the components are.
- Default to "CardLayout" and incrementally add other components.
Define the "layout" nodes #31 (comment)