Page tree
Skip to end of metadata
Go to start of metadata

Purpose

Problem

The current STK is three things, a master page template, a rich set of components which are compatible with the master page template, and a few technologies that support them like imaging, variations, and abstract template classes and definitions.

Some of these things are generally useful, and are not really tied to using the all of templates, but people do not get this and so miss some of the benefits of the STK functionality, that they could be getting. 

Because the STK is so many things, its easy to miscommunicate about it - as one person might be referring to all of the functionality, while another is only referring to the template set.

Proposal

Integrate STK features into Magnolia platform. 

  • Move at least Site & SiteManager classes to corestk-core should only contain: imaging, variations, STKTemplatingFunctions, abstract template classes and definitions
  • Separate template set from stk base. People are overwhelmed by everything included in STK. Separating out the template set will help people understand that they dont need to use it.

  • Navigation overhaul. Navigation has several problems, overall it must be more flexible.

  • Imaging: Deprecate CSS variations. 

  • Imaging: Responsive Imaging techniques. It must be easy to specify variations for responsive websites where different image sizes are deliverd based on browser size. Also the stk must have mechanism to load the appropriate image. Also high pixel resolution devices (retina display) must be easy to support - ie mechanisms to support "@2x" quadrupal sized images display automatically on high res screens. Also SVG images should be supported.

  • Unique page css class. A unique ID or class should be inserted in body element tag of every page to assist with css styling. Could be based on node UUID. (optional additional editor specified id.)

Standard Templating Kit remains as simply a collection of templates.

Implementation

TBD.

  • No labels

1 Comment

    • Unique page css class/id: I'm guessing the path (with dashes instead of slashes if slashes aren't ok for class names) would be a bit more helpful to css guys than a meaningless uuid ?