17487 Posts in 4473 Topics by 1978 members
|Go to End|
28 September 2007 at 12:30pm
committed the following to trunk:
refactored css and requirements: created more specific css-files to reduce side-effects and ease debugging, moved generic form-styling from cms/css/cms_*.css into sapphire/css/Form.css. ordered Requirement-inclusions in CMSMain/LeftAndMain to be more coherent (avoiding duplicate requirement-calls)
this means you get a lot of form-styling "for free" by including Form.css, and relying on the Requirements added by the used formfields, instead of tricking cms_right.css to apply to your markup, or copy&pasting everything.
Form.css isn't included by default in any form, but is there in case you need it.
I've tried to come up with scenarios where you need to adapt legacy code once switching to the next release including these changes:
- custom requirements: if you relying on cms_right.css to contain all form-styling, you need to include sapphire/css/Form.ss now
- custom backend-modules with cleared requirements: just have a look at whats included in LeftAndMain/CMSMain now
- formfield-usage outside of cms: new css-requirements have been added to several formfields, which might affect the styling on your site. use Requirements::clear(<cssfile-path>) to undo those changes in your specific case.
in case you feel that other rules belong into the generic Form.css as well (or some are too cms-specific for Form.css), please discuss here - or patch on trunk
by the way: we still have project-specific Requirements in LeftAndMain::init() - i vaguely remember somebody working on a more flexible solution to inject Requirements, does anybody know specifics here?
|Go to Top|