Home
sUPL stands for ‘simple Unified Presentation Layer’. It is similar conceptually to a CSS/XHTML framework (like Blueprint for example) except that it is more comprehensive and provides an extensible approach for output XHTML markup of conceivably any type of data. The name ‘simple Unified Presentation Layer’ might seem misleading but it relates to the context that gave birth to it, namely a web development environment (at the Centre for Computing in the Humanities) which involves separately managed JSP/JDBC and XML/XSLT strands, and the desire to put together a common interface library uniting both.
sUPL is ‘simple’ because it does not yet incorporate a configuration environment. Later we plan to develop a web application to handle this, at which point sUPL may have a bedfellow which may be known as ‘cUPL’ or ‘complex’ / ‘configurable’.
What is it?
It’s best to think of sUPL as a macroformat. Why? sUPL isn’t just a CSS framework (a library of pre-written CSS components for page layouts, designed to allow quick web interface development); it’s really more all-encompassing, including markup and styling for a wide range of content. Really sUPL is an overarching approach to web interface building (which is why macroformat seems such a useful term): it’s a set vocabulary of CSS classes and a preset XHTML markup ‘style’ which can be applied to a number of existing situations or extended to accommodate new ones.
- sUPL is designed to extend XHTML’s ability to express / describe structure using a combination of CSS and XHTML structure.
- sUPL tries as much as possible to make semantically appropriate use of XHMTL elements. It uses a vocabulary of CSS classes too but these are conceived of like ‘control codes’: they do have semantic meaning but it is encoded in a two or three letter short form classname, so the meaning is intelligible when used with a glossary. sUPL privileges lightweight output XHTML over human readability; and it a design assumption is that it will primarily be used in a web-application / server side context where much of the code is generated.
- sUPL is deliberately designed to be highly generic. Partly it achieves this by conceiving of XHTML solely as a presentational language. So, data is described in fairly literal terms. If you like your markup to meaningfully describe the information in the page, you may well not like sUPL. One reason for this is that sUPL is designed to take a lot of the thought out of designing markup. There is no point creating new vocabularies and taxonomies of class and id names for every template that’s needed and I’d argue very little real world benefit either: yes, explicit classnames are obvious and clear for someone looking at your code but documentation is clear too and sUPL is documented! sUPL is about being pragmatic and making it easy to decide how best to mark something up so that a) it makes sense in an unstyled context and b) there are sufficient handles (elements, classnames, ids) to allow CSS and client side scripting to be applied effectively and without the need for any (ideally) per website template customisation.
Design Objectives
- Optimisation for file size and efficiency: sUPL is designed to support a wide range of page layouts and types of content in a reusable way but it tries to do so without extraneous markup where possible.
- No CSS hacks. sUPL is designed to work within a server side context; if specific per-browser styling is needed it must be delivered via server side client detection rather than using CSS hacks which are a poor choice for maintainability longer term. sUPL includes a specification and mechanism for one way of achieving this; many CMS systems already allow browser detection and client specific delivery.
- Human readability less important that systematic class/id vocabulary: because of the use of control codes, sUPL takes a bit of getting used to, but it is extremely lightweight.
