Hi scoob… I’m not sure about the original intentions of adding this level of CSS support in 1.x and it makes me wonder if it really should be in the framework. In reading this thread, the thought struck me more than once that what may really be needed is a Layout Designer module and a wrapper to run the editor as a widget. Coupled with the above CSS Editor and a user’s choice of HTML editors, this might be a better solution and should eliminate the need to incorporate a CSS platform in the core framework. A module also provides a replaceable solution to this need, allowing other developers to build there own competing solutions.
How would you get the two editors to communicate, possibly provide some drag and drop support for applying styles, and provide other inter-component communication might be better solved with 2.0 core development, perhaps by developing an event-driven macro language, allowing the two editors to communicate based on the publish and subscribe pattern (observer and observable).
I’m currently converting and refactoring much of code for a lightweight portal originally designed to run on top of CodeIgniter. The Yii version of this portal is going to be the underlying foundation for my future Yii projects, including five large modules developed for other frameworks that I plan to run on top of the portal. The latter four of the five modules are layout intensive and have options allowing the user to select canned layouts to meet their needs. It would be nice to provide users the option of creating their own layouts, edit existing layouts, tweak them as they find problems, and also perform similar operations with themes.
There were several remarks earlier about Foundation or Bootstrap not supporting this and that. Well my friends, the solution to this in line with the designer module above is to refactor many of the existing widgets as portlets (menus, submenus, toolbars, breadcrumb, login, related (content, topics, products, etc), popular (downloads, content, posts, etc.), random (images, products, etc.), tag clouds, weather, whos online, counters, and other such widgets. This allows them to be used in conjunction with any layout by associating collections of portlets with theme or layout regions (containers) via menu items. Then a user will see a specific set of portlets when a specific layout or theme appears and another set when a new layout is displayed. I’m working in this direction with my portal project and hope to start passing on some extensions soon.
I would much rather see Qiang, Wei and the gang invest their time on an abstract layout manager (and associated navigation) interface solution to make it easier control the management of the physical presentation of a site’s modules and portlets (with less emphasis in the style of a site).