I think that Foundation is better in the sense that it doesn’t dictate the overall look as much as Bootstrap does. 
Since this is a matter of taste, Yii 2.0 ought to make it easier to plug in support for new frameworks.
I think that Foundation is better in the sense that it doesn’t dictate the overall look as much as Bootstrap does.
Since this is a matter of taste, Yii 2.0 ought to make it easier to plug in support for new frameworks.
Zurb Foundation doesn’t have a main menu like the one of Bootstrap, it has less form styles (i.e. it doesn’t have a green field for “success” etc.), it doesn’t have a breadcrumb component, it doesn’t have a native table columns sorter etc. etc. Foundation has - at the moment - some advantages over Bootstrap, but it is not as “complete” as Bootstrap (talking about UI components).
That’s exactly the reasons why I prefer Foundation.
And why Bootstrap sites tends to look so much alike.
That can be true for a production site. But for a webapp skeleton generated by Yii/Gii, I think that Boostrap could be a good candidate as you can already find a standard component for every component (breadcrumbs, tables with columns sorter etc., "success styled" forms) that Yii actually uses, while Zurb Foundation lacks some UI components.
This is just my point of view, Foundation is nice too (indeed I suggested it in the other thread).
bootstrap and foundation have slightly different aims, bootstrap allows you to get a polished looking application up and running quickly, but as stated by others, most bootstrap sites have a very similar look, it’s hard to build something totally unique with bootstrap. Foundation is different in that it’s built for building prototypes quickly that are flexible enough to be customized and tweaked to become real products later. So while foundation doesn’t provide everything, it provides most of what you need but in a way that can be built upon in future without being restrictive. To me this is very similar to Yii’s goals.
It’s not surprising because Bootstrap was made by Twitter to ensure a consistent interface across their internal apps.
Ultimately, the only one who can decide on this is the Yii team.
It looks almost the same as bootstrap for me And once again I want to note: we are not talking (or are we?) about a frontend (which almost always has a unique design), but about an admin part (backend), which (in my opinion) must look as good as possible. The current appearance (blue and grey) is nice and I always use it for backend, but it needs more modern elements (especially forms).
It would be better to have a comparison table instead of saying "this is better than that, because…"
btw, i like blueprint
mbi
Good idea. Can you start it in google docs?
no, but maybe the most active people on this topic
I can make it Friday or Saturday
I think this a very important topic, please see also this thread about ‘Questions about modules development’, Chris83 raised similar questions about themeing and dependencies.
IMHO the problem at the moment is, that there’s no convention which CSS or UI framework should be used. Blueprint is kinda default for the grid and jQuery UI also, but the problem is not which framework to use, but how to apply and change them.
I also want to point out, that there’s huge difference between frontend components and backend modules. I explicitly say components for the frontend part and modules for the backend, because I think usually you’ll use modules to reuse code of admin user interfaces, like RBAC, users or media management.
While your frontent layout is usually a very custom thing, maybe also with a background image or something, which can make it harder to use your default main layout also for a module, the focus in the backend lies more on usability and layout consistency (e.g. you want something like a top bar menu to switch between your administrative tasks).
In conclusion it would be very nice to have convention which CSS and/or grid framework should be used at least for backend modules. While I would vote for bootstrap - which is available in a very nice yii extension - I also want to point out, that using this extension raises other customization problems.
For example there are custom components to render specific grids or the menu bar - now if you’re not happy with bootstrap, you could easily adjust the views and layouts with a theme, but you’d have find a solution, how to use these custom components, if you don’t want to loose the cool features, like a top bar menu.
I think Yii itself should be a customizable as possible, it really does not matter with which grid-system you start developing your app. What does matter are the extended UI components (calendar, slider, accordion, …) which are often encapsulated in components and therefore not easily portable to another theme, also there’s no feature to theme widgets … and the backend part.
I really would like to create an extended set of module conventions with other developers who are interested in this topic!
The basics are already there, see [1] and [2].
Here’s quick list of the topics I would like to address: Package Management; Dependencies (Extensions in Extensions); Prefixing/Namespaces; Configuration; Installation; Authentication and Permissions; CSS/Grid, UI Components; Views, Layouts and Themes; Themeing widgets with skins; Navigation.
Please PM me if you’re interested.
Best regards,
schmunk
Maybe a better alternative, instead of requiring or binding to a CSS and/or grid framework, is to have standard semantics.
Then, instead of having to use predefined CSS and/or grid frameworks, one could add these classes to his stylesheet and use whatever framework.
That is exactly what I do.
It means I can freely use whatever grid I want to use - and can even change it dynamically (in response to media queries, script, etc).
+1
Don’t you encounter problems when you have to adjust or translate a - let’s say - 24-column blueprint layout to a 18-column foundation CSS file?
And doesn’t this break the initial idea of having a predefined grid, where you can easily add a CSS class, without defining it in advance?
Please remember, my remarks mainly apply to backend modules.
[update]
@mentel: Could you give me a little example of your standard semantics?
It could be done, for example, adopting some common semantics from the most used frameworks.
There’s no “my” example, since I don’t use standard semantics.
–
Note that my goal here is to propose an alternative path, not a concrete solution.
A secondary goal is to counter your proposal, because I don’t like the idea of being tied to a CSS/grid framework chosen by a thirdy-party.
But how would you accomplish this, e.g. blueprint uses ‘span-8’, while zurb foundation uses ‘eight columns’.
And they’re even not of the same size! So would you add class, e.g. ‘half-width’ and they add this class into the corresponding section of the css file of the framework.
Me neither, but I would like to evaluate the pros and cons of the alternatives.
I also don’t like to be tied to a specific framework, but even with the current options, you’re able to overwrite the views for your modules … and more important: if you develop a module, you have to choose some kind off CSS, styling your module. So why create or adopt new semantics, while there are already plenty very good ones out there? It’s like creating CSS framework-framework
Yii as a framework doesn’t take care of this, it just gives you all the options to configure your app layout and style.
But thinking about backend(!) modules I really would like to have a convention, because even if someone does not use the standard CSS framework for his module, you’d just have to provide a few themed views to integrate it seamlessly into your application.
And this would have a huge impact on pluggability of modules!
Joomla does some good job when it comes to backend modules. Every component basically provides xml files, that describe the data provided/ needed by the component’s objects. The UI is then generated using this information.
I think something similar could be built using Yii’s form builder. It would then be the job of some custom theme, including renderers for the form builder to generate a consistent look and feel for all available packages that provide form configurations.
Are you sure you understand what ‘semantic’ means?
It simply means that those layout specifics are taken out of the views and put into the style sheet.
I am currently using Sass/Compass with Susy (grid). And it has semantic support.
Sass/Compass also supports Blueprint semantically.
So, instead of using ‘span-8’, use a meaningful, semantic name.
And deal with it in the stylesheet.