(redirecionado de Oblivion.YamlIntegration)
This recipe will be about integration of yaml trough smaller modules.
The modules will integrate yaml and new functionality will be built around it.
A especial tmpl file has to be used to take adavantage of all the features provided by Yaml.
We will start with the yaml core to load css files in proper order and sent to the right places, with options checked and markups processed, to configure it the right way:
- base-rtl.min.css upon verification of user and admin requests
- make available css files with all possible variations in columns, to be loaded upon verification of user and admin requests.
- iehacks.min.css sent to
$HTMLHeaderFmtwith specific code for IEs.
- basic print stylesheet
- linearization is not needed here
Some of the files could be could merged and minified, creating 2 or three combinations of minified files.
The combinations would be mostly base with rtl and print.
Forms module - forms theme
Forms could be integrated, but to really use it we would have to change a some of pmwiki's current styles, wich are close to none, and also put on the html tags used in forms a yaml class accordingly.
That could be done from the recipe, the basic styling of forms is done on base.css. The gray-theme.css makes forms better looking.
- gray-theme could be loaded from here
- linearization could be taken from pagelayout files mostly for tabular and inline forms (turn tabular in inline).
Yaml has some good styles for basic navigational elements wich are horizontal list and vertical list, named respectivelly hlist.css and vlist.css.
use of this could be done by just linking to where the stylesheets are.
Perhaps create a file with the two merged and minified.
- linearization could be taken from pagelayout files
- user theme based on skin name
Yaml has different grids available to the designer. The first one comes from base.css and includes equalization, direction and 11 options for boxes.
Yaml also has a port of 960gs grids, with 12 and 16 boxes.
Integration is possible, just have to load the files properly to
- Yaml grids are loaded with base.css
- Grids from 960gs port will be loaded upon admin and user permissions and requests.
- Linearization for both could be taken from pagelayout files
- user patches
Here is were we get into "screen" realm.
Yaml provides options to configure typography-rtl too.
But typography and page layout (the section bellow) are the two parts that make me unconfortable to do as modules, as I believe this two are part of the theming/skining process and the designer should only take yaml files as an example.
if we do the module:
- typography.css could be included by default
- typography-rtl.css admin and user requests have to be checked
- pagelayout changes here for different screen sizes
Here is where a lot of magical stuff happens, like linearization and configuration of page layout to fit different screen sizes.
Yaml4 embraced RWD, AFAIK, wich means Responsive Web Design, and it is a series of rules/practices, to design a website for different devices with different screen resolutions AND orientations.
One of the first rules of RWD is to design for mobiles first! Wich means, no need for a separated mobile site.
I'm not completly sure how this would go for pmwiki. Pm chose very sensible defaults at first, we (I) users asked for stuff and did stuff for the appearance part, not knowing that the choices he had made for it, were based on studies about accessibility. BUT surely, Pm tried to make PmWiki as accessible as possible, but not device independent and for mobiles first.
The first pmwiki skin was narrow, I believe it was smaller than 800 pixels ... (pmwiki skin checked) ... it was width:720px and left aligned on version 1.0.0 .
Designing for mobiles first creates a series of small problems wich a designer has to solve, as an example, a designer has to work on how to load and display ads from mobiles to desktops.
I'm not completly sure if it is a good idea to turn this into a module, I guess from this part forward, the skin designer has to think about what he will implement or not, and chose to follow Yaml's decisions or not.