Goals
General
Create a new, non-default core theme that includes and leverages either a rapid prototyping framework like Twitter Bootstrap, or a general front-end framework like Zurb Foundation.
By Audience
- New to Drupal front end developers: Give an example of an existing front end framework integrating seamlessly with Drupal.
- Developers who have a project that matches the use case of the chosen framework: Attract them to Drupal, give a base theme to get a quick start with.
- Front end beginners (including new learners and developers that work primarily on the back end): Provide a theme to learn with using the framework's documentation and resources, or create a prototype or minimally viable product by using the framework's existing components.
Similar projects currently in contrib
Original issue by Sun:
Blockers
- https://github.com/twitter/bootstrap/issues/2054 - Dual-license Bootstrap
- #1445226: Add Twitter Bootstrap to whitelist
Goal
- Adopt the web tech best practices early, or earlier.
Details
- The Twitter Bootstrap front-end framework implements the most current, most sensible approaches to produce a consistent, well-crafted, and well-designed web site [output], leveraging HTML5, CSS3, latest ECMA, front-end libraries, and whatnot.
- Bootstrap already implements the idea of a generic Theme Component Library (see also related core issues).
- We can learn a lot by simply trying to integrate Bootstrap as a simple theme for Drupal. Don't re-invent the wheel.
- The focus must be on "simple", because the Bootstrap framework is overly nitpicky about proper/compatible markup. The underlying case: Make our markup better.
Proposed solution
-
Add a theme to Drupal core that is based on Bootstrap.
Primary goal: Leverage and expose Bootstrap's components/features in Drupal, ideally with close to zero theme function overrides.
There's absolutely nothing wrong with having it look and feel like the Bootstrap base theme experience, which is visible on countless of project websites. Bear in mind, the goal is not fancy — the goal is modern markup and web standards.
Related issues
- #1382350: [discussion] Theme/render system problems
- #1484720: [Meta] Reduce the number of theme functions/templates
Prior art
- http://drupal.org/project/twitter_bootstrap
- http://drupal.org/project/twitter_bootstrap_ui
- http://drupal.org/project/bh_bootstrap
- http://drupal.org/project/bh_bootstrapextras
Deadlines
-
2012-10-15 Working theme/implementation + ready patch for Drupal core (requires license blocker to be resolved)
Why this early? The primary purpose of this challenge is to identify markup, output, and shortcomings in Drupal that should be improved. Stuff like dropbuttons (quite) potentially need to be re-implemented to use proper markup. Ditto for other stuff like tabs, actions, etc. Changing/improved that stuff can be considered as "feature", so any improvements need to happen before feature freeze.
- 2012-12-01 Feature freeze.
Comment | File | Size | Author |
---|---|---|---|
#128 | tweme.zip | 110.41 KB | anydigital |
Comments
Comment #1
bensnyder CreditAttribution: bensnyder commentedSun - thanks for pushing this. Would anyone like to team up with me? We would need to do this in tandem with the work being done to integrate Twig.
Comment #1.0
bensnyder CreditAttribution: bensnyder commentedUpdated issue summary.
Comment #2
sunI've added Prior art and also Deadlines to the issue summary. The provided reasoning hopefully explains why I asked for a time-frame of 1-2 weeks (given that 8 weeks remain in total).
Comment #2.0
sunUpdated issue summary.
Comment #3
RobLoachThis would be absolutely huge for Drupal.
Comment #4
bensnyder CreditAttribution: bensnyder commentedThe theme ecosystem would EXPLODE if TB was available in core.
Comment #4.0
bensnyder CreditAttribution: bensnyder commentedReplaced an impolite word.
Comment #5
sunI've clarified the Proposed solution.
Comment #6
webchickIsn't this a no-go because of the license? :( AFAIK Apache Public License and GPL v2 are not compatible. http://www.gnu.org/licenses/license-list.html#apache2
EDIT: Oh, ok. It looks like according to https://github.com/twitter/bootstrap/issues/2054#issuecomment-9090952 that this has been re-opened for discussion as of an hour ago. Yay! Still, trying to get all contributors to Twitter Bootstrap to sign a CLA in time for our feature freeze sounds ... not likely to happen. :(
Comment #7
sun@webchick: See issue summary.
Comment #8
cweagans@sun, are you thinking that this should be a public-facing theme? Or an admin theme?
Comment #9
sun@cweagans: In light of the primary purpose and goals, I don't really care. But yeah, I thought of a public-facing theme. Less special, less use-case specific. Just Drupal on Bootstrap steroids. (whereas "just" is relative and involves tons of work.)
Comment #10
cweagans@bensnyder, I'd love to work with you on this. Jump on IRC at some point tonight or tomorrow and we can chat about it :)
A public-facing theme seems to be, in my mind, a better demonstration of how bootstrap is likely to be used, though if we're already changing up a bunch of markup to work nicely with Bootstrap, an admin theme wouldn't be too difficult to do.
Comment #11
bensnyder CreditAttribution: bensnyder commented@cweagans sweet. would probably be easier to plan over skype? hit me up @ benpsnyder
Et al - definitely start with a public-facing theme. PHPTemplate? Twig? Will the work being done on Twig hold us up?
Comment #12
c4rl CreditAttribution: c4rl commentedI am currently opposed to this proposition. Reasons follow.
1. It is problematic in principle that the stated Goal of this issue is very vague, and the stated Solution is very specific.
2. The Details listed are simply some nice-to-haves that Bootstrap provides. I don't see any real problems listed that integrating TB would solve. The justifications above could be applied to other front-end frameworks; I could imagine these justifications being used similarly to propose adding 960 to core a few years ago when 960 became popular.
3. There are enough problems with the existing Drupal theme system having *too much* in it that I am opposed to *adding* anything new that doesn't solve an existing issue until we have taken care of the existing issues of consistency and consolidation. Until things listed in #1788918: [GTD] [META] Prepare for Twig main engine core inclusion until December 1 are in the clear, it seems unwise to focus efforts on putting *more* into core theme API at this juncture especially something "overly nitpicky about proper/compatible markup." It's clear that having too much in the theme API has caused problems and frustration.
4. The existing projects on d.o that utilize TB have, at most, an install base around 2000 sites in aggregate, which is not nearly ubiquitous enough as to be a clear choice to include into core (compared to, for example, CCK or Views).
Comment #13
cweagansWell, if nothing else, it will help us get a generic component library into core. If the markup for those components happens to be consistent with the markup for Twitter Bootstrap, then I see that as a good thing.
Comment #14
sign CreditAttribution: sign commentedRight now I am against this. Bootstrap is evolving very quickly and the version integrated into D8 will be already outdated when released I guess. Which might bring in frustration, for people who are used to twitter bootstrap and fully leveraging it (including JS functionality - not sure @sun if you want to add these too). So they might be thinking, oh, Drupal has twitter bootstrap, but then they will be like :-O and start from scratch.
But I am all up for standardizing the output. In fact we can take the bootstrap as an example, but I wouldn't market it as that Twitter Bootstrap has been integrated into Drupal. Willing to help with this. Doing this every day unfortunately on clients sites.
Comment #15
fubhy CreditAttribution: fubhy commentedCleaning up and standardizing the output is always a very noble undertaking. Applying a widely accepted, external library in a theme and thereby identifying the bottlenecks in the current template and theme function implementations is also a good idea. However, building a core theme on top of something that is evolving as fast as Twitter Bootstrap is not. Additionaly I would hate to see a Twitter Bootstrap theme in core considering that there are much cleaner and lightweight solutions out there that just don't get that much attention as Bootstrap does because, well, they don't come from twitter. Take, for example, ZURB Foundation. While I usually don't use such libraries (or, if I do, just parts of them) my first resource would be Foundation - Not Bootstrap. First of all, it's built with SASS, secondly as mentioned before, it's much cleaner and lightweight. So you see, now we are arguing which framework is better - And, whichever framework we choose, people will complain.
So... Building a a theme on top of an external, highly optimized and best-practices Framework and then using that as a tool to identify the wtf's in the current templates/theme functions/css/js is a great idea. Keeping that in core afterwards is not :) (imo).
Comment #16
kpa CreditAttribution: kpa commentedHi people,
Have a look at www.ja.net. I implemented this earlier this year - and whilst it's not a perfect implementation, there are a number of hooks, some from http://drupal.org/sandbox/rerooting/1429486 which add necessary markup to render the elements in the correct 'twitter bootstrap' way.
I'm in the process of cleaning it up for another project at the moment, hopefully I can sandbox it by the end of the week if anyone's interested.
Points of note:
- It relies on Omega as well, which we'd want to get rid of. Given this - and how strongly the 960gs is set up, I've made some overrides for 'TwBs responsiveness', but it still largely uses the 960gs.
- My CSS is HUGE - I'm in the process of tidying this up as well.
I'd be interested in working on this if it becomes a viable option.
Comment #17
LewisNyman CreditAttribution: LewisNyman commentedThis feels like a good exercise in exposing how difficult and painful our theming system is, but we already know that right?
Having said that, the use case for a distribution of Drupal aimed at rapid prototyping and a minimum viable product is huge. I've been singing the praises of Drupal for tech start ups in London and the ability to create decent functionality and UI without writing code would be huge.
Huge
Comment #18
timmillwoodI think bootstrap is a great framework and with the creator moving to github (http://markdotto.com/2012/09/30/github-bound/), Twitter are moving bootstrap into it's own organisation on github.
This means that bootstrap becomes more of an independent open source project rather than a Twitter project.
I would love to see it in core.
Comment #19
bensnyder CreditAttribution: bensnyder commented@fubhy - /methinks me loves ZURB Foundation. Wow. Hadn't seen the recent 3.x release. They did a great job with that... and yes, much cleaner than TB... and... with SASS. (I hate having to use sass-twitter-bootstrap all the time.) Hmm.
/meneeds to think about this some more.
@lewisnyman spot on.
Comment #20
crizI am not sure. Of course it would be awesome when Drupal would be shipping with a Twitter Bootstrap theme, on the other hand I see the issues like some of you:
- Up-2-dateness and core updating process: For example Bootstrap 2.0 needs jQuery 1.7+, as a consequence the twitter_bootstrap d7 theme is not working without jquery_update or similar. If Drupal core is not even able to ship the latest jQuery, I don't see a way for an up-2-date Bootstrap Framework.
- Though I like Twitter Bootstrap and it is probably one of the most adopted frameworks worldwide (e.g. also Joomla 3.0 now uses Twitter Bootstrap for the backend), it is right that there are some other frameworks that could be considered too.
- And yes, standardizing html and theme components is the way to go. But Twitter Bootstrap uses it's own markup and classes. Good (and similar) core theme components would help to adopt to Twitter Bootstrap markup I guess, but a lot of theming functions and overwrites would be needed anyway. See for example what d7 twitter_bootstrap theme is doing: http://drupalcode.org/project/twitter_bootstrap.git/tree/6f1ca9f41d04483...
In my opinion Drupal core should first try to make the work with state-of-the-art markup frameworks most convenient as possible. So that contributed base themes like http://drupal.org/project/twitter_bootstrap or http://drupal.org/sandbox/ishmaelsanchez/1332338 can provide good solutions and people can use it without jQuery issues or something like this.
But I fully agree with the idea to have a great Twitter Bootstrap Drupal 8 theme available, as early as possible. Only that I don't know if it should be in core (under this conditions), though it would be a great marketing gag when Drupal 8 would ship with a Twitter Bootstrap theme... ;)
On the other hand: Having a always most current Twitter Bootstrap theme in Drupal core, and with just the markup needed by the framework (without all the maybe-somebody-needs-it-sometimes-somehow-classes and a most lean html output as possible), THIS WOULD BE A DREAM! ... and would be a great best-practise showcase for other framework adoptions in contrib.
Comment #21
c4rl CreditAttribution: c4rl commentedI'm changing the priority to Normal since it seems more appropriate for this issue.
Here's another thought I had about this, which is not a criticism of Bootstrap specifically, but just a thought on core themes in general. Most sites do not use a core theme, nor a singular contrib theme, because the diversity of design need is so wide. As a result of this, we ended up with several out-of-date themes in D6 core that had to be removed simply because Drupal had grown up and the vast majority of design attention was being put toward custom work in Drupal sites.
The theme layer differs considerably from modules in this way, in that the labor of a particular site's theme does not translate to other projects as flexibly as, say, fixing bugs that affect the modules of that particular site. And so, core modules improve and change because their improvement translates across all Drupal sites whereas core themes atrophy simply because people aren't using them.
Whilst I agree the intention of having a framework is a nice idea, we have to consider the practicality of this, especially given the timeline. I would like to see more effort put toward a solid contrib Bootstrap theme before further considering core inclusion.
Comment #22
fubhy CreditAttribution: fubhy commentedOkay.. So we got Stark, Bartik and Seven in core.
Stark being a really cool theme for development, testing, etc. because, well, it's basically empty.
Seven being the default admin theme because it's simple, although not as simple as Stark, optimized to work well with all the admin pages, looks good in the overlay and in general simply provides quite a nice backend look&feel.
Bartik being the arguably better-looking alternative to Stark basically when quickly setting up a website for a demo or for a simple personal blog.
We have to ask ourselves: How does a that twitter bootstrap(?) / foundation(?) / any other prototype based theme fit into core.
From my gut feeling I would say: Only as a replacement for Bartik. I am not sure if there is an issue for that yet, but giving D8 a new out-of-the-box face would not be a bad idea after all if you ask me. That way we would visually distinguish standard profile installs D7 vs. D8. At the same time, while implementing a new theme from scratch we would be able to dummy-test and validate our latest theming changes in D8 with a close look on the best practices shown by those prototyping frameworks.
Let's not put MORE themes in core. Maybe replace Bartik / Move Bartik back to contrib and put that new theme in? After all it's a new major version!
Really think about how much sense bootstrap actually makes. I think there are better alternatives...
Let's give D8 theming a test-spin and fix the issues as we go.
Comment #23
dcrocks CreditAttribution: dcrocks commentedReally don't think this should get into core. There are alternative libraries, there is no actual theme being proposed to judge on its wow factor, and there is no evaluation as to whether drupal should choose ANY theme library as best practice for its users. Is this so great that drupal should lock itself into this library? Bartik was chosen from amongst alternatives for drupal 7. I don't know if there is a project to choose a best and new base theme for drupal 8. I think this should all be in contrib. It already is for drupal 7.
I know you wouldn't be able to get such a library into core after feature freeze. Maybe this should be redone as a request to add theme builder tool sets to core before feature freeze.
Comment #24
dcrocks CreditAttribution: dcrocks commentedActually, there is an issue, #1087784: Add new theme to Drupal 8.1.x or another minor version, but it seems dormant.
Comment #25
Snugug CreditAttribution: Snugug commentedI have very strong concerns with this proposal starting with the general premise and going straight through implementation. This is going to be a long post, so be prepared.
First, let start with the stated goal of this proposal: about the web tech best practices early, or earlier. This is something I actually agree with, but this goal is very very broad. What are we actually talking about? There are backend best practices, frontend best practices, JS best practices, CSS best practices. Best practices for responsive web design, best practices for static web development, best practices for web apps, best practices for brochure sites. What are we talking about? Based on the proposed solution, I assume the best practices you're concerned with are responsive web design and reusable CSS. If this is indeed the case, let me be the first to tell you that Bootstrap is not a best practice in Front End, it is a front end framework for back end developers. As a Drupal community, and as a front end community, we have access to great front end developers to deliver a properly best practice solution as opposed to using the Fad-ish Bootstrap. Please don't take this as a "Not Invented Here" thing, Bootstrap really doesn't implement best practices and we can do better.
Second, details. As goes the saying, the devil is in the details, and Bootstrap is Satan himself (excuse the hyperbole). While the first bullet claims that Bootstrap implements "the most current, most sensible approaches to produce a consistent, well-crafted, and well-designed web site [output], leveraging HTML5, CSS3, latest ECMA, front-end libraries, and whatnot", please allow me to explain how that is, in fact, wrong. I'm going to be going through the Bootstrap site heading by heading to explain why this statement is wrong.
Let's start with Bootstrap Scaffolding. The very very first thing that Bootstrap explains, in the very first example, is how to enable font size Less mixins. I'm going to get back to Less, but the fact that Bootstrap in its core is written in it should present a giant warning to any attempt to bring it into Core. Going down Scaffolding, they use Normalize, which I agree is the better way to go, but Reset vs Normalize is a design decision and as such isn't a best practice per se. Next, we move onto their grid. Their basic grid is a static grid, which is in fact not a best practice, is available only at 12 columns, which is again not a best practice, in fact it's a bad practice to constrain our designs to a grid not created for our design. The grids are static grids instead of fluid grids (which actually is a best practice) and below 767px (aka a Desktop first approach to device breakpoints, both of which have been rejected as best practices in favor of Mobile First and content based breakpoints). The grid system is a class based grid system, so all of the work we're doing to clean up the class system is going to go for not. In fact, class based grid systems are very rapidly being replaced by semantic, pure CSS grid systems which allow you to change your actual column count at different sizes without messing with your classes (this is the emerging best practice. See Zen Grids, Susy, or Singularity). And their entire default grid system is built in PX, not even EMs, which is the furthest thing from a modern bet practice. Next, let's take a look at their Responsive grid. Bootstrap itself is designed to not be responsive by default, meaning the default mentality going into Bootstrap is that of a static website. This is actually the opposite of a best practice. If you take a look at what they consider supported devices, they are all Desktop first, device based (and wrong at that) media queries with static grid layouts at 768px and up, which is, again, all sorts of not best practice. Oh, and they also set background color of body to white, which is neither a best or worst practice, just a strange one, and yet one more piece of CSS we need to override.
Next, let's take a look at Typography. The key to good typography is setting what's right for your font size, and requires lots of detail work. Their default is 14px/20px size/line height. Sizing fonts in PX is actually a worst practice; for accessibility, fonts should always be set in EMs. The rest of their typographic decisions are fairly basic and we don't need Bootstrap to handle. When we get to tables, while their table styles are interesting, they are not responsive and frankly, are a design decision. We've got lots and lots of tables in Drupal, we don't need use their designs. Their color coded rows for paragraphs and tables are all design decisions that we don't need bootstrap to deal with (and we deal with in Drupal already). Possibly the most compelling thing from Typography that Bootstrap offers to us is their Form stuff, which while mostly good, do make many design decisions for us that I'm not sure we want in Drupal core. This is especially true for their default buttons, which are all design decisions, some of which many of our designers won't agree with, which now is again even more CSS we need to override (this is going to be a reoccurring theme if the idea of adding Bootstrap is to add a Component Library). It's also hard to determine just how well these will work responsively because their site doesn't use fluid grids that we can really test using best practices with. When it comes to the iconography they use, the way it's implemented is totally inaccessible for many of their examples, and in fact doesn't even use best practices for font icons. Take a look at Symbolset for the current best practice icon font.
Next we move over to Components. Starting with their drop down menu, the basic one is, again, inaccessible with a tab index of -1. Their JS for their menus is not touch friendly, which makes it fairly useless for touch based mobile devices (again, not a best practice) and in fact, their examples for button drop down menus simply do not work on touch devices. The targets for their combo buttons are too small for touch devices. Most of what's on their site isn't optimized (or really usable) on Touch, a combination of JS and CSS issues. Skipping down a bit, their pagination isn't responsive, nor is their hero unit, search stuff, page header, or really most of their components (because of this, none of these components are things we should use). Their clearfix is fine though.
Now on to Javascript. First, modals not only don't work for small screen, their modal just straight is broken on iOS. Hell, it totally breaks if you're not on a landscape orientation! I can't begin to believe this is acceptable for a Drupal core theme. Likewise, their JS drop downs don't work well on touch. Their tooltips don't work for Touch, requiring you to actually click the links/item, a bad practice and broken practice. Popovers, too, have no concept of screen real-estate. Their carousel doesn't respond very well and doesn't have touch interactions. If you are looking for a good example of a proper, accessible, and progressively enhanced carousel, look at Flexslider.
So with all of these issues, I hope it's fairly clear Bootstrap is in fact not the modern awesome framework that it's described in the first bullet point. Let's now talk about bullet point 2, the Theme Component Library that Jacine has proposed. I think the Bootstrap solution misses the point that Jacine was trying to make; we need less css in Core and more standard HTML components with easy to hook into classes. Unfortunately, much of her demo is incomplete, so without her directly chiming in I can't speak to her full intents, but from conversations I've had with her and other front ends in Drupal, the real issue we have is unpredictable, non standard HTML output which is then hard to theme, not our inherit ability to actually theme something. To this extent, while I would really love to see a standard component library in Drupal, many many more of our complaints about the frontend, and in fact seemingly many of Jacine's complaints from that blog, are going to get remedied with the move to Twig. This is where resources should be going, to make sure that system rocks. If we combine that with a SMACSS approach to our core CSS and our CSS frontend best practices many of the CSS issues we hate in Drupal will potentially go away.
Now, a word on the Less CSS preprocessor and the implicit acceptance of it by introducing Twitter Bootstrap. In the world of CSS Preprocessors and the wider front end community, of the three major CSS Preprocessors, the majority of the top front end developers uses Sass, not Less, and in the Drupal community the preferred CSS Preprocessor is Sass as well. The implicit nod to Less that implementing Bootstrap runs counter to what is being used by the Drupal frontend community and the wider frontend community. We've actually had this discussion before over at Add a CSS Preprocessor to Core to no avail. Please take note though of the themers (beside myself) who prefer Sass: Jacine, John, Morten, Sebastian, Richard, Mason, Chris Ruppel, Lewis Nyman to name a few. After looking over all of the options, the current upgrade to D7 for d.o is being written in Sass. This is a Drupal best practice and rapidly becoming a frontend best practice, with people like Chris Coyier and Paul Irish championing it as their preferred CSS Preprocessor. This is something that should be considered whenever talking about a front end framework, and if we do decide to go with any front end framework that uses a CSS Preprocessor, we should only be looking at ones that are native to Sass and Compass.
1713 words later, I think I'm done. Hopefully this helps.
Comment #26
JacobSingh CreditAttribution: JacobSingh commentedSnugug's technical critique not-withstanding, I see a few really compelling reasons to make core's Admin theme based on bootstrap.
Okay, cons..
The last con is why I think it's *GREAT* for the default admin theme, but terrible for anything else.
k, 2c provided.
Anyone who is willing to put in work can TOTALLY DISREGARD my comment since I am not.
Comment #27
effulgentsia CreditAttribution: effulgentsia commentedI don't really know enough about the pros and cons of different front-end frameworks to comment meaningfully on whether the problems of adding Twitter bootstrap to core would outweigh the benefits. I just want to suggest two things though:
- Twig should not factor into the discussion. I think the problem space is entirely different, and a theme coded in PHPTemplate now can be converted to Twig later, after feature freeze, if basic Twig implementations land in core before then. Meanwhile, a problem space that this effort (or any type of generic component library) would hit on is #1484720: [Meta] Reduce the number of theme functions/templates, something the Twig effort would also love to see happen, but has not yet worked on in depth, so these two efforts would be each valuable on their own, compatible with each other, and should be done completely in parallel.
- If this isn't done in core, but rather as a sandbox / to-be-contrib theme, is it still possible to do it now, so that any improvements to the theme/render system figured out by the effort could still be submitted as standalone patches to core while there's still time?
Comment #28
fubhy CreditAttribution: fubhy commentedThanks for the detailed review of Twitter Bootstrap @Snugug, you nailed it... very informative.
Please note everyone: After reading all the previous comments once more I think we can safely say that noone is opposed to reviving #1087784: Add new theme to Drupal 8.1.x or another minor version. Considering @Snugug's Front-end expertise and his detailed review of Twitter Bootstrap as well as the comments from various other renown themers (comments from mortendk on Twitter, etc.). We can safely say that we can actually do better than Twitter Bootstrap (no offense).
So I would still vote +1 for creating a new theme for D8 as a joint effort from everyone involved with theming. But let's use the expertise that we have in our community to actually properly investigate how such a theme should look instead of blindly going for a random framework just because it's currently 'hip'. :)
Comment #29
RobLoachThe biggest benefit Drupal would get out of a framework like Bootstrap/Foundation is the common markup and CSS base. The out-of-the-box responsive design makes its adoption attractive to the Mobile Initiative.
If you're looking for a LESS compiler for PHP, there's LESSPHP, which also integrates quite nicely with Assetic. Of course, we won't need to compile it ourselves as Bootstrap ships compiled copies of it for us. Leafo also has a SCSS compiler writen in PHP too, so either LESS or SASS/SCSS work fine if they were to be adopted by Drupal. LESS/SASS/SCSS all accomplish pretty much the same things. Despite the FUD, they all have the same goals, it just comes down to syntax.
Comment #30
Snugug CreditAttribution: Snugug commentedI would actually say that depends on what the goal of the Bootstrap theme is. If it's very simply a theme, then, as Sebastian just pointed out, we can do better, and we should revive that discussion. If the goal of Bootstrap, on the other hand, is to introduce the concept of a Component Library to Drupal Core, it has everything to do with Twig as it now walks into the "new theme system" talk.
Comment #31
Snugug CreditAttribution: Snugug commentedI would actually say that depends on what the goal of the Bootstrap theme is. If it's very simply a theme, then, as Sebastian just pointed out, we can do better, and we should revive that discussion. If the goal of Bootstrap, on the other hand, is to introduce the concept of a Component Library to Drupal Core, it has everything to do with Twig as it now walks into the "new theme system" talk.
Comment #32
RobLoachTwig is simply a templating engine. What markup it outputs is up to us. We can format the markup however we want. Twig does not care whether or not we're using Foundation/Bootstrap. I may have misunderstood what you were saying...
Comment #33
Snugug CreditAttribution: Snugug commentedMy understanding of the Twig initiative from DrupalCon Munich, as opposed to simply the engine itself, was much more broad in scope than simply writing a tempting engine and would wind up touching many other systems including the process/preprocess functions. If that is not correct, that is good to know, but also doesn't take away from the many shortcomings of Bootstrap.
Comment #34
tlattimore CreditAttribution: tlattimore commentedRe #33: This is correct. The scope of the twig initiative is quite broad and much more that just dropping in a new template engine. It will be touching process/preprocess functions, as well as completely changing the current implementation of theme_* functions.
Comment #35
RobLoachYes, I understand that. But it's unrelated to Bootstrap/Foundation. Having a framework like Foundation/Bootstrap is completely front-end, while Twig/PHPTemplate is backend markup formatting... Rather unrelated topics.
Are you refering to having Twig compile the SASS/SCSS/LESS for us? Because Twig's integration with Assetic will let us do that. Likely not do that for Drupal 8 though.
Comment #36
Snugug CreditAttribution: Snugug commentedThe reason I pointed to the Twig initiative was a question of what the purpose of this was. If it's simply a theme, I agree that Twig is irrelevant, but if it's really about a Component Library as the 2nd details bullet suggests, that's all Twig.
Comment #37
RobLoachAh, I understand where you were going now. Thanks for the clarification.
Do we really need a new wheel? Proudly Found Elsewhere is already tagged. If it's missing something we need, then let's work with them to fix what it's missing. Either that or allow its extension to give us that opportunity.
Comment #38
Snugug CreditAttribution: Snugug commentedThe "We can do better" isn't a "Not found here" thing, it's a this really isn't what we need thing. We need to examine what we want out of Bootstrap the solution.
If, what we want out, it better markup, it does not provide that. We should look to HTML5 Boilerplate, and we already have the HTML5 initiative in place for that. Bootstrap provides Bootstrap markup, which isn't what we want. We want best practice HTML5, and this is not it.
If it's responsive front end built on best practices, again Bootstrap falls flat. See my big post above. It's not simply a question of contributing back upstream to fix these issues, it's that it's actually easier and better for the Drupal community to do it the right way the first time.
If it's getting the idea of CSS Preprocessors into a Core theme, the front end community (both Drupal and wider) prefer Sass to Less when it comes to anything that's not Bootstrap. Additionally, saying that both are equivalent is functionally not true, with Less being far inferior. If we want to promote a CSS Preprocessor, we should be doing it with Sass, not Less, and there are plenty of "Proudly Found Elsewhere" in Sass for us to leverage.
If, though, it's about a Component Library system for Drupal, this theme is irrelevant, this should be a different topic, and again, we should look to what makes sense for us.
When it comes to frontend, "Proudly Found Elsewhere" isn't always a good thing, especially for many of the cutting edge things that move super quick. When it comes to CSS Frameworks, because of their need to confirm to general usecases, they tend not to follow best practices, or practices you would implement if you were building by hand. This is very much so the case with Bootstrap. Just because a lot of people use it doesn't mean it's the right solution. We shouldn't be turning away "Invented Here" solutions just because someone has done something else somewhere else. We should be findig the best solution to meet our needs, and Bootstrap is not that.
Comment #39
effulgentsia CreditAttribution: effulgentsia commentedThe Twig initiative does intersect with some aspects of the theme system other than just the engine itself. For example, just as we submitted an Attributes class independent of Twig itself, now that that's landed, we may also submit a patch for removing process functions, which would also be independent of Twig. We still need to figure out how to turn preprocess functions from push to pull (i.e., preprocess variables only after the template uses it rather than spending those CPU cycles preparing variables that the template doesn't even output), and allow presentation-oriented variable manipulation more easily doable within the template itself so that easy things don't require the themer to do any PHP coding at all, but I don't see that as something that should be a dependency for Twitter bootstrap work, or something that would be hard to incorporate into Twitter bootstrap work after both things got figured out independently.
Related to a Theme Component Library, the major thing needed there is stuff like #1484720: [Meta] Reduce the number of theme functions/templates, and in general, better reuse/organization between a markup pattern (e.g., lists, containers, etc.) and their use cases in Drupal (e.g., book navigation, tasks, menu links, nodes, comments, blocks). One appeal of Twitter bootstrap is it already has this organization that we can model off of whether we use it directly or copy its ideas. At different times, some of the people working on the Twig initiative also tried to tackle this re-organization issue, but not much progress has been made on that, and there's no reason that work needs to be linked to Twig other than some of the people interested in that work are also interested in Twig. Regardless of how this Twitter bootstrap issue progresses, if anyone wants to breathe new life into that meta issue, that would be so awesome.
Comment #40
dasjoi'd strongly vote against using php-ports of SASS/LESS compilers as they tend to be outdated. better use the original versions of those tools, save bugs and keep up-to-date with such constantly evolving technologies.
Comment #41
chrisjlee CreditAttribution: chrisjlee commentedI normally don't voice my opinions that much in drupal core but i vehemently oppose this for the following reasons:
Comment #42
RowboTony CreditAttribution: RowboTony commented@snugug is right about everything he said. Please don't put twbootstrap in Drupal. I don't comment on many of these D8 issues, but this one is very important to me as a sitebuilder. A shared component library is a fine idea, twbootstrap ain't the answer. Zurb Foundation, or roll our own is the way to go. In the time allotted - Foundation is the best choice, plus Foundation is SASS, twbootstrap is LESS and inferior in the general consensus. I've been using Foundation over the past 6 months and have easily plugged-in the style components to several base themes config.rb including Zen, Aurora, Omega, and my final favorite AdaptiveTheme base, which the AT code is so fast and clean that I don't know why AT base isn't being considered for the new base theme. That's my 2 cents.
Comment #43
RowboTony CreditAttribution: RowboTony commentedFurthermore, Foundation also has 8 HTML templates available right now that someone can easily Twig-up a prototype in an afternoon - http://foundation.zurb.com/templates.php
Comment #44
Dries CreditAttribution: Dries commentedOne of my long time goals for Drupal is to foster a thriving themer community. I don’t think we are there yet, relative to our module developer community. I see a theme based on a strong front-end framework, like Twitter Bootstrap, in core as a step in the right direction. I'm impartial about whether we choose Twitter Bootstrap, Zurb, or another popular framework so let's just assume Twitter Bootstrap (TB) for the sake of this comment.
People shouldn’t need to go to Contrib to find out that Drupal works well with front-end frameworks.
I’d love to see a minimal implementation here. Specifically, let's add one new non-default base theme that is based on TB, or try and create a version of Bartik on TB. (We don't really have time to design a new theme from scratch.) It will be a model for others who want to use TB and Drupal. People who don’t like TB can just ignore this theme. Folks who want to use a newer version of TB are free to do that. While implementing, we might want to change some core markup to be TB friendly. We can make those changes in core or in the new theme. Lets just use best judgement there.
Before we do much more, we should reach out to caniszczyk and see if we can overcome the Licensing issue. I see this has already been started at https://github.com/twitter/bootstrap/issues/2054, so that is great.
Comment #45
Snugug CreditAttribution: Snugug commentedI'm very happy to hear that you're interested in fostering a thriving themer community. Unfortunately, I don't believe that TB, even as a non-default Core theme, would be the way to go about that.
Twitter Bootstrap is, colloquy, most commonly used by individuals who do not have the front end/themer talent to create something from scratch. It is for this very reason that those themers who do have that capability do not use Bootstrap and are generally against it as a proper theming tool; it's OK for prototyping, but never good for final product. To me, the common Bootstrap user's usecase, wanting a nice theme but not having the ability to make one, is the definition of what Contrib is for. While I can appreciate wanting to show off that Drupal can play nice with front end frameworks, I fear Bootstrap is the wrong framework to do it with, not only because of its poor Responsive support but because of the general lack of support from our existing front end community.
Truthfully though, all of the frameworks, be it Bootstrap, Zen, Skeleton, or others, are all designed to be backend agnostic. I don't understand the benefit in general of having a default theme built to a specific framework; it's all just CSS. The biggest issue with implementing frameworks with Drupal is the load of extra CSS we need to overcome from Core and Contrib modules, and the dirty class/HTML output we get, which is a focus of Twig to fix. I really, truly believe that the stigma around theming for Drupal is not that we can't use Zurb or Bootstrap with it, because very clearly we can, but rather that the output takes an almost Herculean effort to wrangle properly. Because of this, I do not believe that saying "Look! We've wrangled Bootstrap (or Zurb or Skeleton) into a Drupal base theme!" is not going to help foster the Drupal themer community, better core Markup and CSS is, and that's not going to come from building a Framework powered theme, that's going to come from having frontend experts like those working on the HTML5 and Twig initiatives fix the theme layer's output, something we can and should do in a CSS Framework agnostic way.
Comment #46
lightsurge CreditAttribution: lightsurge commentedThere definitely seems to be a lot of interest in a proper twitter bootstrap base theme for Drupal #1594508: Merge in other d.o Bootstrap projects and if all that effort had gone into one place I would definitely think that Drupal 8 should have a subtheme of that as it's default theme.. that's not come about though, it's all dissipated and only just in the process of merging.
If I was to pick out the most obvious great thing it's be the fixed header menu, where I find those on sites I really appreciate them, especially mobile.
For that reason at this stage I definitely think that if those awesome people working towards a theme for Drupal 8 could pick up on details like that I'll be really pleased, even if we don't end up with a base of bootstrap in its entirety.
Comment #47
lightsurge CreditAttribution: lightsurge commentedWhen I say I think bootstrap would be a great default theme for 8.x, I mean by way that it's so beautifully well documented (partly down to the theme the documentation's on!), and it's such a brilliant start for people making a great site.
But it's not 'one to rule them all', the bootstrap examples look very bootstrappy-recognisable to me (http://builtwithbootstrap.tumblr.com/) and while they look great they look a very specific kind of great which seems to dissolve Drupal's individuality, yes as all the other sites built off same base themes might be, adaptive, omega etc, but these have had more investment on drupal.org, have grown with it, aren't yet in core and still look great. And they're more individual to Drupal.
The best thing in terms of themes is variety of which there's plenty to choose from on drupal.org and sadly no stable twitter bootstrap base ones on drupal.org right now.
But smash and grab what's good about it I say, without getting sued ;-)
Comment #48
cweagansWell, that might be a good thing. Drupal sites are usually easily identified. If we can prove that Drupal can make websites look like anything else on the web, then maybe front end devs will be more interested.
Comment #49
xtfer CreditAttribution: xtfer commentedI think, if you've actually tried to work with Bootstrap and Drupal, you will probably have serious concerns about this proposal. It's a nice look, for what its worth, but it's Twitter's look, and it doesnt match with Drupal without some work.
Ember is developing as a nice admin backend, and for the front-end, maybe if you are interested in a good twitter bootstrap base theme, you should focus on building one that works well in contrib first, or just making Stark a bit more attractive out of the box.
Comment #50
lightsurge CreditAttribution: lightsurge commented@#48 Yea... I see how by the act of forcing through a bootstrap theme it could batter Drupal into being able to take shapes it couldn't before. Sort of like a theme 'intervention'.
Comment #51
Snugug CreditAttribution: Snugug commentedIt's this comment, and those like it, that concern me and lead me to believe those advocating for this as a solution don't actually spend much time with the larger frontend community. The front end that we're trying to attract is not the frontend that like Bootstrap, they are the ones laughing about the fact that tent.io, a startup Twitter competitor, is using Bootstrap. They're the one creating Built With Bootstrap, not as a showcase of good examples, but rather because building with bootstrap is an easy way out for design and therefore easily recognizable. They're the ones out there pushing what frontend means. Do we honestly believe that the people who decry "This site looks like Drupal" are going to turn and praise us because "This site looks like Bootstrap?". No. All we've done there is replace "Drupal" with "Bootstrap". While "This looks like Drupal" may be a blemish in the wider community, in part due to its overuse, in part due to its ease of recognition, and in part due to its flattening of design, Bootstrap, amongst frontend at large (now I'm including front end devs and designers here) is seen more as a scarlet letter than a job well done.
Innovative talent begets innovative talent, good design begets good design, best practices beget better ones. Showcasing that we know a fad CSS framework when we see one doesn't help bring talent in to Drupal.
We can always think about it in another way: is any of Drupal frontend thinking of jumping ship to Joomla! now that it ships with Bootstrap in its core? I think you'll find of the caliber we're looking to attract, and even amongst Drupal frontend as a whole, not a soul is moved by that advance. You may in fact find many have a lower opinion of the frontend decisions of the project now. I know I do.
Comment #52
RobW CreditAttribution: RobW commentedSnugug's going hard here, but he makes some very valid points (especially about the caliber of front end developer Drupal is trying to attract).
I think Bootstrap has a lot of value as a base theme, as long as it's a base theme that aligns with Bootstrap's purpose. As Lightsurge pointed out, "these are prototyping frameworks; they allow you to get something out of the box quickly." Bootstrap describes itself in a similar fashion:
Once a product is mature enough to rate the extra development hours, Bootstrap is meant to be tweaked, revised, and replaced with project specific code until what you have left is a perfectly fitting custom css system. If this issue is about building a base theme for rapid prototyping that incorporates Bootstrap, that's great. If anyone is talking about using Bootstrap to define html and class structure and provide the canonical interface element library for all of Drupal, that would be a mistake. That's not what Bootstrap is for.
Comment #53
fubhy CreditAttribution: fubhy commentedAnd that's why we should try to use the great expertise of our own, existing, front-end community. Blindly jumping on the TB train now that Joomla! adopted it and it's being moved to github is something that we would regret in the long run. @Snugug outlined several reasons why TB is a bad choice. I would like to see how Joomla! decided to use TB - Apparently (https://twitter.com/webchick/status/253671617790615552) Joomla! discussed that in private. We should probably contact them in order to find out how they came to that decision.
What we actually want is proper, quality markup and CSS. We won't get that by building a theme on top of TB. As @Snugug pointed out it doesn't even follow modern best practices. I am not bashing TB, it certainly has its niche but we certainly don't want to restrict ourselves to that niche.
That pretty much nails it.
We don't have to do it before feature freeze. After all, a theme basically is somewhat isolated from the rest of the system and won't interfere with anything. So considering that we would actually have quite a few months left for such an undertaking. However, we might still be a bit late for creating a completely new design from scratch... Maybe.
Maybe we could foster a proper workflow/release cycle for themes in core. Out of my gut feeling I would always expect Stark (basically, a completely "empty" theme), an admin theme (currently Seven), the last versions "main" theme (for D8 that would be Bartik), plus a NEW main theme in each new major version of Drupal. That way we would basically have some kind of LTS for the previous main theme while moving forward with each major version. After all, a new design is always something exciting that will draw a lot of attention. Also, by building such a theme for each major version, we would be able to identify the flaws in the current system and perfection our underlying theme system and output in terms of the latest web standards.
Actually, I think that the effort of creating such a theme could happen outside of core with theme and template overrides right there until we are done. Porting whatever fixes we come up with to core and, at the same time, fixing the other (affected) core themes is a minor problem and won't take up much time.
That is correct, however, we won't reach that goal by squeezing and battering Drupal into "Insert Framework Name Here". We will reach that goal by providing lean and clean output and base CSS that is Framework agnostic.
Anyways... what Snugug and I are trying to say here basically is: If we do this, we should do it right. We got the expertise in our community, thus we should leverage it.
Comment #54
RowboTony CreditAttribution: RowboTony commentedDries said in post #44
I think that's quite reasonable to include a Bootstrap theme as long as it is not the default theme. I think it would be a mistake to bend the core markup to accommodate the Bootstrap framework, or to have TB takeover the admin backend. TB isn't my personal choice for anything, but if it doesn't affect core and there are people eager to work on it - knock yourselves out Bootstrappers!
Comment #55
webchickI have two things to say in this thread.
The first is that I don't actually believe we currently have a front-end community capable of defining our own "more betterer" standard UI patterns in core, as much as I would love to believe that was the case. Jacine tried to spear-head it first, she got completely burnt out since no one stepped up to help implement her ideas. Then the Drupal.org D7 port of Bluecheese got completely stalled out because the people who insisted on porting it using best practices like SASS and whatnot, which it turns out no one except for extremely busy people with no time to contribute to it know how it works. :\
Now, I'd love to be proven wrong on this, and that we do indeed have a strong kernel of front-end devs who would be ready and willing to take on "Twitter Bootstrap, but better, and for Drupal, and in time for feature freeze." Unfortunately, what I've seen so far from our front-end community is a lot of very strong opinions about we ought to do / not to do, but not a lot of code / long-term maintenance on that code. :\ That doesn't bode well for approaching this from a "NiH" stance. We've gotten a lot more leverage historically on choosing solutions that have a lot of critical mass behind them already and that non-experts can pick up easily (e.g. jQuery).
But please, do prove me wrong! I'd love to see our front-end community more deeply involved in Drupal core development, rather than just cursing at us when we invariably get it wrong. :)
The second is that I tried to inquire on Twitter as to how Joomla! got Bootstrap into their CMS, which is a GPLv2+ licensed thing like Drupal's. There's unfortunately no definitive reference to an "official" decision (which apparently happens behind closed doors :\), but opinions ranged from the + in GPLv2 is an "or" rather than an "and" (which seems dodgy to me... it removes the choice of the licensee to use GPLv2 if they so choose) to Twitter Bootstrap is "media", not "code", to "I dunno, ask so and so." :)
Amy Stephen, who seemed to be the most definitive source, pointed me at http://wordpress.org/news/2009/07/themes-are-gpl-too/ which was the SFLC's response to what qualifies as derivative works within WordPress. They say CSS/images are "media" (which is our stance too, and why businesses such as Top Notch Themes can exist, as long as their base theme w/ PHP code is GPL).
As you can see from that blog post, WordPress took a similar route we did, and declared all themes GPL in order to keep things simple. Even though Joomla!'s root LICENSE.txt file reads GPLv2, apparently if you go trawling through source code you can find individual files with different licenses. The thinking is that since JS/images/CSS never share the same memory space as PHP, they don't get "infected" with GPL. It's unclear to me how they reconcile Twitter Bootstrap markup generation from PHP, but hey, that's not my fight to fight. :)
Now, Drupal.org of course enforces a hard requirement of all files/code/etc. being uploaded here being GPLv2+, the same as Drupal, in order to eliminate any licensing questions. This is not a mandate from the SFLC/FSF, this is our own community's cultural rule, which Amy recommended we change to be more inline with industry standards. This rule could be changed, but that would be a much broader discussion, probably involving the SFLC and the DA and some other legal counsel.
So all of that said, IMO we have two options if we want to use Twitter Bootstrap (Zurb Foundation is MIT so no worries there, but Github also lists it as a Ruby project, which gives me pause):
1) Wait for upstream to relicense their code as MIT so we can re-license it as GPLv2+
2) Start an enormous bikeshed discussion on whether we should exempt CSS and images (and JS?) from GPLv2+ on Drupal.org.
I'd prefer to do #1, or choose a different front-end framework that's more compatibly-licensed, personally. #2 feels like an enormous distraction right now (and should not be discussed in this issue in any case).
Comment #56
dodorama CreditAttribution: dodorama commentedAs Snugug pointed out in #25 most of the components are either inaccessible or plain broken on mobile (the modal, the dropdown, the navbar, etc.) I dont think anybody here is comfortable to bring broken code into core. What remains then? A not really flexible grid, a little bit of typography.
I haven't seen any major website developed with Bootstrap. And there's a reason for that. If Drupal front end developers can't agree on a framework that's because a framework isn't really appropriate for a project like Drupal and the code is usually not good enough to be included in core.
Bootstrap is great for prototyping not as good for production (and very difficult to customize). IMHO it belongs in contrib. if we need a theme that makes easy to prototype websites let's do it the Drupal way. What would be the use case of abootstrap based theme ? What are the advantages?
Comment #57
steveburge CreditAttribution: steveburge commentedAs a heavy user of Drupal, Joomla and Bootstrap, I find this discussion fascinating and it brings a sense of deja vu. There was a lot of very similar back-and-forth in the Joomla community before the decision was made to adopt Bootstrap.
Some links:
http://ux.joomla.org/forum/Visual-Design/481-UI-Options-and-Bootstrap?li...
http://ux.joomla.org/forum/JUI/271-Use-Bootstrap-20-As-Base-For-JUI
http://ux.joomla.org/forum/Visual-Design/481-UI-Options-and-Bootstrap
One caveat is that they were trying to address a slightly different set of needs than those that Drupal has. For example, one need was a consistent admin UI. Like WordPress, many developers made their own admin UIs. Drupal doesn't have that problem as much, so using Bootstrap for the admin isn't such a concern.
@Webchick Twitter isn't the place to get good answers on these issues. I know Joomla took this licensing issue seriously and they got detailed answers from the Software Freedom Law Centre. Email one of your contacts on the Open Source Matters board and I'm sure they'll fill you in on the legal advice they got from the SFLC.
Comment #58
fubhy CreditAttribution: fubhy commentedThanks for the links Steve.
I just got an e-mail response from Andrea Tarr of Joomla! after being redirected to her from Brian Teeman. This is the content of the e-mail:
Comment #59
smileyj68 CreditAttribution: smileyj68 commentedHey folks, Jonathan from ZURB here. Cool to see Foundation coming up in the conversation here and, for our part, we'd love to see Foundation integration with Drupal. If there's anything we can do to help please just let us know - Foundation is in active development toward 3.2 and then 4, so if there's things we can include in those releases that simplify this for the community we'd like to hear it.
Comment #60
dodorama CreditAttribution: dodorama commentedAs I said I'm not necessarily a big fan of frameworks but if I have to pick Foundation has my preference.
Personal preferences apart having the developers on board would mean a lot to me so that we can build something bigger together and take the chance to do more than just serve a theme based on a framework but leverage it for other initiatives as well (I'm thinking layout and responsive grid UI).
What about the accessibility of the components?
What about Sass/Less ? How would that integration work for drupal? A php port?
Comment #61
effulgentsia CreditAttribution: effulgentsia commentedRegardless of whether we have a TB theme in core or a ZF theme in core, we'd be missing a really important opportunity if D8 core ships with default markup, default CSS, or organization of theme functions / templates / render array types, that make creating a TB theme or ZF theme any harder than doing so would be for a non-Drupal site. We all know that Drupal theming isn't as easy as we could imagine it to be, and so our front-end community has only grown thanks to remarkable perseverence of front-end devs who stuck with it anyway. Frameworks present an opportunity to get not-yet-expert front-end developers making nice themes. Let's do what we can to minimize the barrier that Drupal imposes to people who want to use those frameworks. I'm not a front-end guy, so I have no concrete idea on how to do that, only generalities like "better default markup", "better default css", "more reuse and less duplication of markup patterns across bazillions of theme functions". I'd love to see specific issues opened for "change markup A to B" or "change CSS X to Y", or "change implementation of render element type foo to xyz", or "consolidate templates A, B, C, and D". And explanations in such issues for how that would get Drupal into better alignment with popular markup/css frameworks.
Comment #62
dodorama CreditAttribution: dodorama commentedI believe the markup has been improved a lot already in D8. We have full support for HTML5 now and responsive themes.
But the struggles of developing a theme for drupal are, in my opinion, because of the broad range of use cases that drupal covers as a framework/cms.
It's easier to develop a theme for Wordpress because it is more focused as a product. Your dealing with very specific needs. This is not necessarily a bad thing but that's how it is. I've been trying to develop a generic theme for Drupal many times but I always gave up and I now have a framework theme that I reuse which is tailored on the very specific customized profile/distribution that I built for my use case (personal portfolios).
In general, building themes for distributions rather than Drupal core seems to me a scenario for the future, unless the standard profile gains more focus as a product.
This is very important to understand for those who don't have front end experience with Drupal. It is not just that the front end community is lazy or the system too difficult for themers.
Comment #63
RobW CreditAttribution: RobW commentedTHIS^^
As a front end guy, I can say that the way these frameworks work is by defining re-usable html patterns (sometimes referred to as html objects) and applying a set of pre-defined classes to them. The biggest barrier that front end developers new to Drupal face, whether implimenting one of these frameworks or creating their own html/css framework (which is what SMACSS, OOCSS, and responsive design are all centered around, really) is the theme function. Put that *ish* in templates. Front end developers love template files -- we love writing our OCD markup and adding classes, data attributes, etc. directly, and have those files (that we understand and control) be the only thing that is creating markup on the site. I am ecstatic for twig. If we decide to become more adept at Drupal and become hybrid developers, we don't mind programmatically altering some of these values (preproccess woo), or learning how the render array works and how to use it.
As a front end guy that uses Drupal almost exclusively, I can say that the thing we hate most is spending 1/2 of our development hours removing "sensible" defaults from Drupal theme code (thank you, Mothership), or writing patches and hacking modules to pull all markup in template files so that we and the rest of our team can edit them. Actually, doing that for the last three years is how I learned to code in PHP, so there's some benefit. So what we don't want is Drupal as a whole deciding to add a canonical Drupal prototyping framework and bending all of it's code around that project's markup and classes without addressing the ease of editing concerns above.
Drupal's theme system at its core is really one of the best out there -- it has the ability to control every piece of markup in tiny semantic chunks, has a great template overriding and cascading process, and is hugely extensible. I love it. But the implementation of that system is often not the best. That's what needs to be fixed.
Comment #64
Noyz CreditAttribution: Noyz commented+100 for Foundation in Core. It's a brilliant framework that would start to set the stage for a standard definition of classes - both from a responsive point of view as well as a feature POV (e.g. tabs, buttons, tables, etc.).
Comment #65
Snugug CreditAttribution: Snugug commentedRobW has put it just about perfectly, and his reasoning is precisely why I believe this story should be "Make Twig awesome" and "talk about a Component library for Contrib". Bootstrap doesn't belong in Core, nor do any frameworks. We want semantic, modern, unbloated, easy to override markup coming out of Core, not more crap for us to override. That's exactly what Twig is doing; we should close this topic and send all development resources over to Twig to make what frontend really needs a reality.
Comment #66
lightsurge CreditAttribution: lightsurge commentedThe typography in Zurb sometimes seems to go strangely small.. I notice the difference only by having waded through a dozen bootstrap themes and quite like the typography.
Then I looked at the examples in the Zurb foundation footer:
http://projection.pixar.com/
http://codesign.lanl.gov/
http://www.zurb.com/
I know it's nitpicking but all those three examples which are the first three examples in the footer just look like some of the text should be bigger.. is it just me? In contrast I struggle to find similar characteristics in bootstrap, all the text tends to be quite readable:
http://builtwithbootstrap.tumblr.com/
Comment #67
cweagans@Snugug, This issue is not about Twig. This issue is about adding another theme to core. If you don't like the theme, you don't have to enable it. No harm done. Please stop trying to shut down discussion here.
Comment #68
Snugug CreditAttribution: Snugug commentedSee, I disagree this thread is about adding a theme to Drupal. I think the reasoning as given in the original post speaks to underlying issues. I'm arguing for the forest, not the trees.
As an aside, Zurb vs Bootstrap is, likewise, missing the forest for the trees IMO.
Comment #69
Snugug CreditAttribution: Snugug commentedAs an aside, because Jacine's work on Component Libraries are specifically mentioned in the OP, a quote from Jacine herself:
Comment #70
cweagansWell, the title of the issue is "Add a Twitter Bootstrap-based theme to Drupal core". That seems pretty well defined to me. While I appreciate your viewpoint, can I recommend that you open an issue identifying a plan of action to make the theme system more suitable for front end developers (and specifically, how that correlates with the efforts on the Twig conversion)?
Comment #71
RobW CreditAttribution: RobW commentedTo be fair, the conversation has drifted back and forth from adding another theme to core, to adding a css/prototyping framework as the basis of markup to core. I can see how opinions could flare, especially among front end developers who don't have the ability (or maybe time) to write core patches, and therefore see this as their only opportunity for input.
And to clarify my position, I think an optional bootstrap non-default theme would be an amazing thing to ship with core, as Dries suggests in #44. Maybe not so amazing that I'm going to work on it though ;).
Comment #72
DamienMcKennaGiven the fact that Bootstrap is currently incompatible with our community's stance on licenses, the fact that there's a lot of other front-end dev plumbing needing to be done, and the fact that our front-end development community are saying it sucks (to paraphrase), why is this even being considered? It sounds like a great contrib project, not something for core.
For inclusion in Drupal core any piece of functionality should have high standards and match the requirements & needs of the people who will be using it. If the JavaScript developers said a new library sucked would we try to push for it to be included? If a new API architecture sounded neat (OAuth 2 anyone) would we shove it in anyway or listen to the sound arguments that say it sucks?
Comment #73
DamienMcKennaAn additional thought: correct me if I'm wrong, but isn't a goal of Drupal 8 to resolve many long-standing problems by doing things right, by giving us powerful & well built functionality that many have been looking for? Adding functionality that our community's topical experts are saying is the wrong way of approaching the topic would go against this goal.
Comment #74
cweagansIf somebody wants to point me to this mysterious list of things that really need to be done to make the theme system not suck, please feel free. I'd love to help. I'm not sure why it has to be Twig OR this issue, or [that list of issues] OR this issue, but evidently, that's how it is.
It seems like every time I see an issue like this one, people get pissed off about the proposal because it's not "pure", people insist on building their own thing for the same reason, shut down discussion, and then nothing ever gets done because the people clamoring for the opportunity to build their own thing never do.
As I said: I'd love to help make Drupal better, but "the theme system sucks" is not actionable.
/me unfollows.
Comment #75
RainbowArrayEverything that Snugug, fubhy and Damien McKenna said: +1.
I'd just like to also add that I also think it's unnecessary to create a core theme in Flash, just because it might look cool and would attract Flash developers to Drupal.
That's said in jest, but seriously, Drupal needs clean, standards-based code, with less CSS cruft, that is responsive and multi-device friendly out of the box. From everything that's been detailed about Bootstrap above, I don't understand the desire to have this in core. Create a contrib theme if you really like Bootstrap. Make a quick prototyping distribution that includes it, if that's the goal. But why put something with so many demonstrable problems in Core? Because Joomla did it?
Sure, Bootstrap "looks cool" now. But D8 won't be released for another year. And if D7 is an example, many won't upgrade to D8 for another year after that, when enough contrib modules are available. And then at that point those folks will see a core theme with a two-year old version of Bootstrap? Precisely because Bootstrap is easy for some to use, I would expect that the visual style of Bootstrap will feel like an overused fad at that point. Common design styles just don't stay fresh for all that long.
As a site builder and front end developer, I wouldn't find it at all attractive to have a Bootstrap theme in core. I'd much rather see efforts go into Twig and other initiatives, like Mobile and Layout, which will have a far bigger impact on making Drupal friendly to front end developers for years to come.
Code freeze is coming up quick. It seems strange to throw resources at a project like this, which front end developers don't want, when so much work is necessary on successfully completing initiatives that front end developers do want.
Comment #76
laura s CreditAttribution: laura s commentedCommenting as one of those who's been too busy this past year to pitch in (boo), but has a strong interest and follows as much as she can, especially when it comes to Drupal's theming layer.... I find myself agreeing with @Snugug, @c4rl and others who oppose the broader proposal of incorporating Bootstrap into core.
As for making it into a core theme, my question is: What does Bootstrap as a core theme basis do that it can't do in contrib? What problem does Bootstrap solve? Is it more important than Twig?
Whether as a theme, a prototyping framework, or a cutting edge (in 2012) way of presenting content, wouldn't a Bootstrap endeavor thrive more in the free and fast-moving contrib world? As others have noted, core moves slowly, but the front-end world is evolving incredibly rapidly. The Drop is always moving, but FED is moving much quicker. By the time D8 comes out, we'll be talking in the FED world about a dozen new tools, frameworks, best practices, etc. The front-end world isn't going to wait for Drupal core.
Comment #77
c4rl CreditAttribution: c4rl commentedIn the event cweagans didn't actually unfollow this issue and would in fact like to be pointed to some more pressing issues I think #1788918: [GTD] [META] Prepare for Twig main engine core inclusion until December 1 is a good start (as I mentioned way back in comment #12).
Any objections to marking this issue postponed or closed (won't fix)?
Comment #78
catchNone from me.
Comment #79
RobW CreditAttribution: RobW commentedNo preference on whether we close now or give it a day or two.
Here's a rough tl;dr summary, taking into account discussions on the twittersphere:
1. Most front end developers here are not in favor of core markup being specifically revised for Bootstrap, or for Bootstrap to be a requirement for core interface elements or default Drupal themes (Seven or the primary D8 admin theme, Bartik or the primary D8 front end theme).
2. Wider issues for the theme system all deserve their own issues, many of which exist.
3. A prototyping theme that includes Bootstrap could be included with core, as long as Bootstrap was sandboxed into that theme alone (i.e., unless you're using the Bootstrap theme, Bootstrap components aren't used in Drupal).
4. If you want to work on a non-required Bootstrap theme for core, great. If you want to work on the twig integration and core markup cleanup, great too. Most front end developers see the twig and core markup issues as higher priority.
Comment #80
webchickI was informed that my comment in #55 could be misconstrued to say I disagree with or am dismissing the recurring premise from the prominent members of the Drupal front-end community that frameworks like Twitter Bootstrap are not what they want. I feel this is misrepresentative of my views, so let me try this from a different angle.
Let's start with a premise I think we can all agree on: Front-end code written by back-end developers frustrates the living hell out of front-end developers. :) Can we all agree to that? :D
If so, we're left with two options:
A) Grow a maintainer team around Drupal core's markup of front-end developers who take charge of ensuring that Drupal's markup is semantic, easy to override, and sensible. Jacine worked her ass off to do this as HTML5 initiative lead, and the results are very impressive. Drupal 8 core ships with native HTML5 output, we've removed many cases of "div-itis" in favour of semantic tags such as "article," theme functions that were 99% duplicative have in several cases been consolidated down to single ones, etc. However, Jacine has stepped away, and no one (and ideally, many more than one) has stepped in to fill this gap. So we're left with MAINTAINERS.txt listing two people as Markup maintainers, when in reality one is gone and the other is busy maintaining the other 900 subsystems in core.
B) Own up to the fact that we as backend developers who largely comprise the current Drupal core developer team will never write front-end code that doesn't make front-end developers miserable, and so rely on emulating a blueprint/template that was written by front-end developers to drive us. Once again, Jacine paved the way during her tenure as HTML5 initiative lead and developed a really solid start on this at http://jacine.net/post/19652705220/theme-system. But no one picked up where she left off. So in absence of leadership here, it's natural we turn to outside sources, even if they have their flaws, since they're definitely going to be better than what a bunch of back-end programmers can cook up.
The fact that we don't have A is what makes B compelling, from a core developer team perspective. If we were to solve the problem with A, then hell yeah, let's do it! But what we see in evidence here is not front-end developers banding together to solve A, but rather front-end developers banding together to yell at the well-meaning (and, granted, ultimately misguided) back-end developers for trying to do something better than the status quo. And I fear that if/when we merely bury this issue, what we'll be left with is just what we started with: Front-end code written by back-end developers, that frustrates the living hell out of front-end developers. :(
I do think that Snugug did a very good job in #25 of enumerating the reasons why Twitter Bootstrap is probably not the right choice for us, even given our goals of B. So if this issue is to be closed, what I would strongly suggest as a follow-up item to get some interested parties from this issue hacking on the markup, CSS, javascript, html5 and mobile queues, and then get those folks listed in MAINTAINERS.txt so we have leadership around core's markup once again. Such a team could then help educate the back-end developers on what they need, spin up issues and help to get them done, and become part of the core developer team, rather than feeling victims of it.
And then we'd end up with Drupal 8 markup written by front-end developers, for front-end developers and world domination is just a few clicks away. ;)
Comment #81
effulgentsia CreditAttribution: effulgentsia commentedFor anyone interested in following / helping out on Twig related work, #1696786: Integrate Twig into core: Implementation issue is the current core patch for getting the first template (node.tpl.php) and the first theme function (theme_datetime) converted to twig templates, which is a key issue, since that's what sets up the proper Drupal / Twig engine glue code to enable follow-up core patches to convert the other dozens of templates and hundreds of functions.
Meanwhile, those conversions have already been happening in a sandbox. There's plenty left, so dig into that sandbox's issue queue. The more that's done in parallel while the engine work is being reviewed in the core queue, the faster follow up core patches can be moved through the process, since it'll just be generating patches from the sandbox and posting them to the core queue.
If the Twig work goes smoothly, and our expectations about performance are borne out, we'll no longer have the theme function / template dichotomy, it'll all be twig templates, addressing one of the points in #63.
But, we'll have a couple hundred twig templates, and each contrib module will add more (as has been the case for theme functions / php templates in D5, D6, and D7). Making it tedious to customize every single piece of markup for a site with a known list of modules, and impossible to create a theme that customizes every single piece of markup for an open-ended set of contrib modules (as has been the case with D5, D6, and D7). To address this issue, we need a theme component library, so that for all but edge cases, modules stop adding new templates, and reuse existing ones. If you can help with that, looks like the Theme Component Library tag is where the action is. This work does not need to be blocked on Twig. It needs vision of how to organize reusable markup patterns, and work to implement that vision and move it through the core patch process. I would have expected Twitter Bootstrap and/or Zurb Foundation to provide us a leg up in creating this Theme Component Library. If that's true, let's use/copy what makes sense. If that's not true, then I look forward to seeing what Drupal's front-end community can come up with in its place.
Comment #82
chx CreditAttribution: chx commentedThis is going to be a chx comment, so some disclaimers apply: one, these are my thoughts only noone else's. Two, try to (i know this is a futile request) take heed of my thoughts not my wording of them.
Anyone arguing for including SASS in core, consider yourself enlisted for supporting Ruby installs on the machines of frontend developers. Mac people, form the queue at door #1, thanks, windows people at door #2. Why there is noone at #2? hey!
Comment #83
jessebeach CreditAttribution: jessebeach commentedAgreed laura s, great point.
Comment #84
Snugug CreditAttribution: Snugug commentedSo lots of comments on the above, gonna dive in kinda last to first:
chx, to your point about Sass. Yes, adding a Sass powered anything anywhere in Core is going to be met with the Ruby challenge, and as those of us who love Sass have come to agree with you, it's no easy feat to convince Frontend or new developers that Ruby now needs to be part of their workflow. With that said, it's not insurmountable; there are lots of GUIs for Mac, Windows, and Linux to compile Sass, and you can do command line on Windows via Ruby Installer. Additionally (and this is specifically not meant to be a plug for my Drupal work, rather for the documentation I've done with regard to Sass), in the Readme PDF that comes w/my Aurora theme I've got install instructions for all 3 platforms plus IIRC links to GUI compiling apps for all platforms. With all this said, I believe this is a separate topic of discussion and one we don't need to have here.
effulgentsia, I can truly appreciate the want of a Theme Component Library but I truly believe, considering the time constraints, the massive amount of IA and coding that would need to go into it to get it right, and the fact that most of Frontend who know the D8 theme layer well enough to effectively pull it off are currently working on Twig, I strongly believe this is something that we need to vet out in Contrib first (or hold off on releasing D8 until we can get both Twig and a fully realized TCL into Core, plus I'd argue Blocks Everywhere is a big part of this too). I believe something that would make this closer to a reality in Contrib is #474684: Allow themes to declare dependencies on modules, which I had done some work on, but due to the fact that Core moves faster than I have time to catch up and that I don't totally grok the graph stuff used for the Module page, is not finished yet. Again, this is something to be discussed elsewhere.
Additionally, while "a couple hundred twig templates" sounds daunting on the outset, the reason we'll have that many is so that frontend can have the fine graine control over the markup that we've always wanted. That's the tradeoff. Many, many of those won't ever need to be touched, and it won't effectively be more work to customize every nook and cranny than it is now; same amount of pieces, just presented in a different way. This really should be a non-issue.
As for a CSS Framework providing us a leg up in the Theme Component Library, this seems to be a misunderstanding of the actual wants of frontend and of what CSS Frameworks provide. They do not provide markup but rather, in the worst of cases, assume very specific markup. At best, they provide styling that can be applied in a markup agnostic way (in fact, that's the sign of a good CSS Framework, that it makes no assumptions about your markup). Additionally, the last thing Frontend wants is more CSS to override or hack out of their theme. Any Component Library we build should be for markup only; no CSS in sight. It can include SMACSS style classes with easy ways of hooking in to make changes to classes/IDs/markup if needed/wanted, but it should not include CSS. It should be a frontend solution, not a sitebuilder solution.
webchick, I'm not entirely sure we don't have A, I just happen to think (from what I saw in Munich anyway) that most of the people who would fall into A are busy with Twig. If we're lacking resources to simply ensure that our HTML output is up to snuff, that's something that should be easily remedied, and I'll make a point of looking over Core's templates to make sure everything HTML5 happy. Again, to the point above, while I like the idea of a Theme Component Library, I don't think frontend has the time or resources to do it for D8 given the current known unknowns and the time frame we have. That being said, if there are backend developers who want to help with suss out the IA and implementation with direction given by frontend, that makes it more do-able, but again, I don't think it's going to happen for D8 and it could probably benefit from time in Contrib to work through issues. You're right in saying frontend doesn't have the raw numbers to get stuff done in Core like backend does and because of this, I strongly believe that frontend's time should be used where we believe it's most effective and if backend wants to implement a frontend solution, they should make a point of trying to pull current frontend in instead of making assumptions about what frontend would like or what's best for them. IIRC, that's how Twig came about to begin with.
Finally, to answer c4rl's objections question, and baring in mind webchick's and chx's comments, I'd like to see this marked closed (won't fix).
Comment #85
AmyStephen CreditAttribution: AmyStephen commentedSteve -
Angie asked for a link to the Joomla discussion on licensing related to inclusion of Twitter Bootstrap in 3.0. I know Joomla leadership discussed this issue (and I believe the SFLC was consulted), but the discussion was between leadership team members was not public, it was private, and therefore a link is not available to share with Angie.
My response to Angie was consistent with the response provided by Andy. In my opinion, open discussion of those topics is preferred to private emails as many of us need to be aware of the issues related to code we write and submit for use by our communities.
It's understood (I lived through the Joomla GPL talks) that licensing discussions can be difficult, but Angie and my discussion was unemotional and not 'religious', it was simply an exchange of our knowledge about the specifics of this issue as that issue related to projects in which we participate.
I agree, BTW, with your conclusion about the difference between the benefits of Twitter Bootstrap for Joomla versus Drupal. Not a big surprise as I tend to agree with you most of the time. ;-)
Thanks.
Amy
Comment #86
KrisBulman CreditAttribution: KrisBulman commentedPretty cool that Zurb has offered support, if anything comes out of that I hope at least a Zurb contrib prototyping theme does.
I think there's enough documentation around Sass installation around that anyone who calls themselves a frontend developer should be able to tackle, not to mention the growing number of GUI apps out there for getting around the ruby problem (scout, compass.app, etc). I know it wasn't the point of chx's comment, but I'd gladly help anyone on linux, windows or mac get up and going with Sass & Compass. :)
I don't see much of a point for Sass being included in core though, except for maybe the benefit of core devs making module updates easier. And especially not a php compiler, which runs the risk of quickly being outdated.
However, if there was a good base theme solution in core modeled against something like Zen with a nice "starterkit" option to build out a subtheme from, I see great advantage of providing a handy inclusion of well written Sass files, along with some hand adjusted CSS that new themers could choose between.
effulgentsia made some great points in #81 around a theme component library, thanks for the tag! I could definitely see a benefit of a core style guide to help with the organization of reusable markup patterns.
Comment #87
chx CreditAttribution: chx commentedBased on #77/#78 and #84, this story is over.
Comment #88
pcoffey CreditAttribution: pcoffey commentedhttp://basethe.me is my implementation of Twitter Bootstrap. I think we should all participate in a project like basethe.me, and not worry about putting one in core. there are licensing issues with putting Twitter Bootstrap in core, I believe.
Comment #89
dasjo#88 also has a project application awaiting review: #1713614: Base Building Blocks
Comment #90
timmillwoodThe main reason I would like to see a framework such as bootstrap in core is to resolve the issue of Drupalisms.
We could remove 90% of the core module's CSS and replace with bootstrap.css. Then all forms and other page elements will look good (and the same) across the site and any contrib modules will be able to follow the same design patterns.
When a frontend dev builds out the site's custom theme many elements such as the login form are left unchanged making the site look very much like Drupal. Would it not be better to make these elements look like Bootstrap?
Comment #91
DamienMcKenna@timmillwood: That sounds like a great idea for contrib projects during D8 and then consider something for core for D9.
Comment #92
moshe weitzman CreditAttribution: moshe weitzman commentedEr, Dries has said that he wants this for D8. He explained why, and how (a non-default, new theme). I encourage someone to implement what he said let the Dries and catch decide. It is pretty clear that we have no consensus even among the committers and thats OK.
Comment #93
jwilson3Update issue title to relate the impartiality to the chosen framework emphasized by Dries.
Two things stand out in my mind:
* There is still not a lot of consensus on the target audience for this addition. Is it existing front end drupal devs? Is it to attract new front end devs? Is it to make the life of existing/new backend devs easier?
* There is still not a lot of consensus on whether Twitter Bootstrap or Zerb Foundation or X would best suit the needs of the target audience. Lots of votes for TB and for ZF, but also a couple very valid points against each. We have buy-in from a ZF developer, but TB is ubiquitous. Its a toss up to me.
UPDATE: also note that one person who's actually developed a twitter bootstrap theme for drupal still believes it is something for Contrib space, which sounds like it counts for something.
Comment #94
DamienMcKennaAs I mentioned on twitter, be careful of adding something in haste just so that it can be seen to have something. There's not a lot of time remaining prior to the feature freeze, many front-end developers are working on getting Twig into core, adding something that many of the target audience don't want out of a sense of haste would be the wrong thing to do.
Picking a framework-based theme needs to come from the front-end developers, helping them to identify their needs, then identifying something that matches their needs, is stable and GPL2-compatible; unless these goals are met we'll be doing a disservice to the people the functionality is purported to be for.
So, starting from square one: what are the needs that a framework-based theme would need to fulfill? Clean HTML5 output? Responsive layout? Easy to work with? Which of them are GPL2-compatible?
Comment #95
bleen CreditAttribution: bleen commented@moshe ... isn't it kindof a lot to ask for someone to create an entire (core-worthy) theme first and THEN to let Dries+Catch+Community decide wether its something that we should be working on in core?
I agree with chx that this issue should be closed unless the community AND the committers do come to some consensus that this is worthwhile to have in core.
And for the record, for several of the reasons pointed out by @snugug as well as @laura s's excellent observations in #76 I think this effort would be much better suited for contrib.
Comment #96
catchI've opened #1804614: [meta] Consolidate theme functions and properly use theme suggestions in core.
Comment #97
webchickJust to clarify, and maybe this is some of the disconnect...
"* There is still not a lot of consensus on the target audience for this addition. Is it existing front end drupal devs? Is it to attract new front end devs? Is it to make the life of existing/new backend devs easier?"
This addition would help the following audiences:
a) Back-end developers who couldn't make a decent-looking theme to save their souls.
b) Junior front-end developers who know their way around but not all the advanced stuff like responsive, WCAG, etc.
c) People already familiar with TB / Zurb who do not know Drupal's theme system yet.
It is definitely NOT for the following audience:
d) Highly experienced front-end developers, especially those who know their way around Drupal's theming system and how to get the markup they want out of it.
There is a huge representation of d) in this thread, which explains the enormous pushback that you're seeing. It also explains why it's compelling to Dries, since there are a lot more of a, b, and c than there are d.
Comment #98
DamienMcKenna@webchick: Thank you for clarifying. I would, however, suggest that we have input from group d to help identify the best option, they'll be the ones best able to recommend the best option.
Also, for the question "which theming framework is suitable for including in Drupal core" it should also be acceptable that for D8 the answer is "nothing".
Comment #99
webchickAnd FTR, I'm not opposed to using a framework in an optional core theme ("Stark - Zurb version" or whatever). I think that's a relatively low-risk way to introduce it, and it could always be swapped/augmented in later releases (probably even stable releases, given the direction proposed in #1787222-18: [meta] Strategy for updating vendor JS libraries within a major stable version) for the next hottt framework, if applicable. You have to realize that "There's a contrib for that!" is probably the worst answer you can give someone with zero Drupal experience. :\
However, I am definitely not convinced that it's a good idea though to go as far as the issue summary suggests and start modeling core's default markup after one of these frameworks, unless there's a clear winner out there. On those points, Sam et al are exactly right. We don't want to bake in the particulars of framework X into core's *.tpl.phps (or *.twigs ;)) unless it's something completely ubiquitous and all front-end developers agree on it, and from what I have observed there is no such thing. :D
It would be interesting though to get a similar technical run-down as #25 on Zurb Foundation. It's MIT, so we can use it without license concerns. The project lead is offering to help assist us as well.
Comment #100
c4rl CreditAttribution: c4rl commentedA clarification: As a member of audience (d) mentioned in #97, I am also very familiar with the current problems that the theme system has, and can say that my pushback is more based on trying to focus effort on fixing the existing problems and not bringing on board new equipment that does not necessarily solve existing problems and potentially causes new problems. My opposition to the proposition is not material to the object of the proposition, but rather affected by the existing environment (i.e. the state of core theme system in D7).
The core theming system we currently have has come about due to a very organic process of "Let's add X to core because X seems like a good idea" and after several years, there are too many options, too many APIs, not enough consistency. Additions made in haste have not proven virtuous. This current proposition feels like one of those moments, and after many years of saying "Yes" it's time to say "Let's wait."
Core has a valance attached to it. A newcomer might think: "If it's part of core, it must be good." Thus, if something is to be added, let it be something proven and robust. Contrib is a great proving ground.
With regard to core, while adding a front-end framework potentially helps audiences (a), (b), and (c), focusing efforts on fixing existing problems helps audiences (a), (b), (c), *and* (d).
Comment #101
c4rl CreditAttribution: c4rl commentedI must say I disagree. When I first started using Drupal and took my first steps checking out the contrib space, it really opened my eyes to the dynamic and multi-faceted nature of Open Source. Contrib is what makes for a thriving community, IMHO.
Plenty of successful projects have come of age in contrib (Views, anyone?), and the first steps one takes to developing their own project will likely come about in a contrib or sandbox project. An advantage of which being when you want to create something, it won't be subject to 100+ comment discussion. :)
Comment #102
mjohnq3 CreditAttribution: mjohnq3 commentedI didn't see this mentioned here, and I haven't looked at it yet, but there is an active sandbox project for a Zurb Foundation 3.0 based theme - http://drupal.org/sandbox/ishmaelsanchez/1332338
Comment #103
laura s CreditAttribution: laura s commented#90:
Oh no, I hope not! Battling core css assumptions is something every themer faces in just about every project, and replacing it with betterer css isn't the solution. If we want OOTB pretty css in core, let it ALL live in Pretty Theme(TM) and let the rest of core be clean and free of presentational assumptions.
#97:
That sounds like a problem with welcome wagon and culture, not with core. Is there an overarching goal of trying to make core into The Friendly Gigundo Monster That Won't Scare N00bs? The appeal of Drupal, as I see it, lies in its flexibility and extensibility via contrib.
Analogy: Nobody buys a smartphone and expects it to have all the apps they will ever want -- everyone understands that adding apps is expected. Can't we assume and cultivate the same understanding for people adopting Drupal, get them up to what us "old timers" have known and understood and embraced for years?
Comment #104
DamienMcKenna@webchick:
You'll have to excuse me if I pretend you didn't say that.
Core can't be expected to cover everything, that path is laden with gold-colored bricks.
Comment #105
webchickLOL I see that comment did not make a proper translation from my head to my fingers, so just ignore it. :) The point is, the default experience core offers matters. It's the same reason c4rl and others are understandably nervous about picking the wrong framework here, and especially as making Drupal core's default markup conform to it. It's also the same reason Dries and others advocating for those not in category D) feel strongly about offering it as an option out of the box.
Comment #106
RobW CreditAttribution: RobW commentedSo we don't keep on saying the same things, can we all agree that:
If so I'll write a new issue summary so people don't get the wrong idea from the current one.
Comment #107
Crell CreditAttribution: Crell commentedIf the end result of this discussion is "just another core theme that just so happens to use Bootstrap/Zurb/Zen Grids/Whatever to prove that it can be done", build it in a sandbox and submit it later. Don't work directly in core for that. Since that's not new *features* I could even see that post-1 December. If it doesn't get in, fine, we have D8's first contrib them ready to go.
The idea that having a major-CSS-framework-based-theme in core that is self-contained to just that theme somehow makes Drupal automatically friendlier toward CSSers is, I think, silly. If someone wants to use such a base system they should certainly be able to do so (as one of those backenders who couldn't design a theme himself to save his life, I can see where I'd find it useful). But that wouldn't mean they know Drupal, just that they know they could use Bootstrap with Drupal. As they say on Twitter:
Putting another theme in core prematurely only makes more work for the Twig conversion folks, and slowing *that* down is the worst possible thing we could do, especially with less than 2 months to feature freeze.
Comment #108
markabur CreditAttribution: markabur commented#88 shows what it takes to use Twitter Bootstrap in D7. It's worth a look. It does a lot of contortions to bend Drupal's html to fit with TB's css. I don't know if it is a good demo of how easily Drupal's output can be tweaked to fit a framework; however, it does show that (a) it's possible, and (b) it's possible without hacking core.
I never actually heard of Twitter Bootstrap before this issue, and in general I'm unfamiliar with the world of premade themes (my projects always have custom ones), but I can see the attraction: if your CMS emits Bootstrap-compatible HTML, then you can simply download a premade stylesheet from a site such as http://bootswatch.com and restyle your whole site without any coding effort at all.
I have no idea if TB stylesheets are easy to create, or if the TB layout system is flexible enough to be used for custom theming, or if its CSS is a hassle to override, but I don't think any of those things matter if the main goal is to make it possible in Drupal to use a theme from Bootswatch.com (or whoever).
With this in mind, I tried making a subtheme of #88, like so:
...and included the "Cyborg" bootstrap.min.css file from Bootswatch. I did get some subtheme-related errors about missing tpl files, but overall it worked fairly well -- enough at least to see the potential.
Considering that subtheming is pretty advanced stuff, and the person who downloads a theme from Bootswatch is probably not an advanced themer, I feel like subtheming is a bad fit as a general approach to Twitter Bootstrap in Drupal.
I think that ideally the theme would have a filefield so you can upload the bootstrap.min.css file you've downloaded from wherever, and *bam* your site is restyled. I wonder if this would be a way around the licensing issues -- what if the Drupal TB theme is just a compatibility layer and doesn't actually contain bootstrap.css until a user uploads it? (Though I guess we still have to include the standard icons, and possibly the javascript.)
Comment #109
DamienMcKennaHow about we postpone this, let everyone focus on a) finishing the twig support for the code freeze and b) work on some example code in separate sandboxes, and reconvene later on to see what's worth considering?
Comment #109.0
DamienMcKennaUpdated issue summary.
Comment #109.1
RobW CreditAttribution: RobW commentedrevise with current state of issue
Comment #110
pcoffey CreditAttribution: pcoffey commentedCan you make an issue on github for the errors you found while using Base Building Blocks as a parent theme? I'm trying to get all the kinks worked out. :)
Are there others on board with a filefield upload of the bootstrap.min.css file? The main problem with this is it would make it difficult for you to edit Bootstrap's less files. I was thinking about using a grunt file for less compiling and everything, but I never considered having users upload their own bootstrap stuff. Is that something others would want?
Also, Base Building Blocks does a lot of work to make it easy for people to theme drupal. It makes it easy to make content-type, and node ID based template files, adds the Chrome Frame and IE edge as an option, includes a set of default media queries to encourage responsive design, has a really nice Bootstrap administration menu, includes cool stuff like Font Awesome, Modernizr, and HTML5 Boilerplate. It has been a helpful tool for me. But I'd really like to make it better, so is it possible that you guys could hit me up with some ideas? I'm working on building a new version of http://basethe.me, with better documentation, and I'm even working on adding some new features, like automatically generated Apple Icons, more retina (hi-res) image help, google tools, some default administration blocks, and a better role-based admin menu. but it would be really helpful for people to submit ideas and collaborate. It's a pretty good start I think, and I like it a lot better than Omega, or Adaptive Themes, but we could make it into something that is awesome. Just hit up the github and lets collab on it!
Comment #111
pcoffey CreditAttribution: pcoffey commentedSee #110. :)
Comment #112
lightsurge CreditAttribution: lightsurge commentedI love Base Building Blocks apart from that it doesn't provide an end-user top navbar, only an admin navbar. And even the admin navbar is not sticky by default.
That seems a real shame to me, because the sticky top navbar is a big selling point for twitter bootstrap, as I find it looks great and improves usability on both desktops and tablets/smartphones. And I've seen in a few places these menus being touted as a big improvement of user experience, and it seems to take that best practice into account. Here's one:
http://uxdesign.smashingmagazine.com/2012/09/11/sticky-menus-are-quicker...
In the lullabot bootstrap fork of drupal.org/project/twitter_bootstrap I have such a navbar I can utilize ootb without any coding.
https://github.com/Lullabot/lullabot_bootstrap
It would be good to see the best bits of all three going into the existing bootstrap theme project on drupal.org.
@#56
I honestly haven't had this experience at all with bootstrap. The navbar worked differently on mobile, rather than sticking links across the bar it mimicked a smartphone 'settings' icon in the top right which then dropped down to show the menu contents... which seems like a neat idea to me! It avoids the alternative of having device spanning pills that users have to scroll past before getting to any actual content. Didn't try the modal though.
As far as Zurb goes, looks great as well although it'd be nice if like bootstrap we had some kind of example of it being used with Drupal.
Comment #113
moshe weitzman CreditAttribution: moshe weitzman commentedPlease don't bully people into working on projects that are important to you, and working outside the core issue queue. I understand that some folks think that Twig is more important than this issue. Thats fine, they should work over at #1696786: Integrate Twig into core: Implementation issue. Everyone scratches their own itch. If we get the Twig engine into D8, I will personally convert this theme to it.
Comment #114
Snugug CreditAttribution: Snugug commentedMoshe,
The issue a bunch of us have with this is that, despite the fact Dries wants this, it's not something that Drupal Frontend thinks is beneficial to Drupal and doesn't seem to actually solve the problems presented. That's why Frontend is directing people toward Twig. Saying that we shouldn't be directing people to the actual Twig issues needed to accomplish Twig and instead pointing them to Core issues that require Twig finished seems silly to me; putting the cart before the horse so to speak. The real work on Twig is being done outside the Core issue queue (as VDC was) and therefore IMO it's totally fine to point people there.
If, however, you'd truly like to stay in the Core issue queue, and you'd like to solve the actual underlying issues that brought this issue to light, what we should be pointing people to is #1804488: [meta] Introduce a Theme Component Library. Moreover, considering this thread is actually now a duplicate of #1087784: Add new theme to Drupal 8.1.x or another minor version (another Core issue), shouldn't we bring the conversation back over there, mark this as Closed (Duplicate), and move on? Actually, come to think of it, I'm going to be a good Drupal citizen and do just that.
Comment #115
pcoffey CreditAttribution: pcoffey commentedI created the navbar as an admin bar only, because it's easy for users to create their own navbars. I'll make it sticky though, good idea!
Comment #116
moshe weitzman CreditAttribution: moshe weitzman commentedThat thread has no Summary, no activity, no plan. This one has all of those things, including approval from Dries. Further, that one is about a pretty design, whereas this one is about adding a prototyping and tech demonstration theme. The design is not a critical component. These are not dupes IMO. Once we have a Theme Component Library, we can close this issue.
Comment #117
Snugug CreditAttribution: Snugug commentedThat, to me, sounds like one of two things: either marking this as postponed until #1804488: [meta] Introduce a Theme Component Library is complete for us to close it then, or closed (won't fix) with the understanding that #1804488: [meta] Introduce a Theme Component Library takes precedence over this, makes this irrelevant, and is more useful to Drupal as a whole. That quote says basically one and only one thing to me: this shouldn't be active.
Comment #118
RobLoachSo let's post-pone this discussion then? Would be unfortunate to lose the opportunity to work with other communities.
Comment #119
lightsurge CreditAttribution: lightsurge commented#115 @pcoffey
I'm guessing you mean just adding navbars via markup? That's not exactly what I meant, I meant users adding a non-admin menu navbar through the core menu system without having to write any script. It doesn't look that trivial to me to for end users to add bootstrap navbars that integrate with the menu module eg.
https://github.com/Lullabot/lullabot_bootstrap/blob/master/includes/modu...
and in your theme it doesn't look like you had a particular easy time either:
https://github.com/patrickocoffeyo/BaseBuildingBlocks/blob/master/functi...
https://github.com/patrickocoffeyo/BaseBuildingBlocks/blob/master/templa...
https://github.com/patrickocoffeyo/BaseBuildingBlocks/blob/master/templa...
Seems there's a lot of disdain for this sort of thing to go in 8.x right now, though, which is over my head, but for what it's worth (which is probably very little, really), I figure all themes have to make certain contortions to make them work, so that's not out of the ordinary.. this one would create plenty of contortions, but if the theme component library is intended to alleviate those contortions, what's wrong with having another more varied working example in core of the contortions that need to be alleviated? Once they are those contortions can just be removed? And if the theme component library doesn't make it into 8.x, having this sort of theme in core could help along interest in developing the theme component library in contrib, in order to remove unwieldy code?
Don't know if the answer to that might still be 'no, it's still better in contrib', but part of the release of a product, to non-techies anyway, is (perhaps unfortunately) also about what's visibly new rather than just what's more streamlined. I know that's a pain because the less immediately visible stuff is generally harder to do and a bigger achievement... but if someone's wanting to work on this to such tight deadlines and will make it core-polished in that time, I don't see what harm it can do... especially since most of the argument against seems to be about the effort being better placed elsewhere, if that's not going to happen anyway and instead this effort just gets frustrated, I don't see the point in that. I'd rather have a new theme in core instead, I don't see how that would be the end of the world.
If the group behind this issue don't need the help of those that think other projects are more important, rather than postponing this why not let them create a patch, and if still passionate about it being detrimental, give it a grilling review instead? :)
I would put this back active but I'm a bit scared (and don't really have the conviction of my understanding!).. and the to-ing and fro-ing seems to have got a bit silly.
Comment #120
effulgentsia CreditAttribution: effulgentsia commented+1. Regardless of the status of this issue, what I think is non-controversial is that a TB base theme and a Zurb Foundation base theme being available (ignoring for the moment whether it's in core or not) when D8 ships would be appreciated by lots of people, and could greatly help adoption of Drupal. So I highly encourage people who want to make this happen and have the needed time and skills to contribute to organize and do so. Looks like there are already a couple overlapping repositories where this is underway, which is fine, but if folks here can agree on a canonical one or two and link them in this issue's summary, that might help channel energies better. Once there's a concrete implementation that enough people are excited about, I see no reason not to at that time re-open this issue for whether to add it to core or not, and meanwhile, if in the process of creating this, problems with core's markup, css, or theme system are identified, please submit those issues to the core queue.
Comment #121
pcoffey CreditAttribution: pcoffey commentedI condensed all navbar-related functions into a re-useable function, so by printing BaseBuildingBlocks_build_navbar('menu-name'), you will print a navbar of the name passed in.
Concerning putting bootstrap into Drupal as core, I don't think it's a good idea. It's easy enough to build a bootstrap theme and add it to your site.
If Drupal is going to make any changes related to the theming system, it would only make sense for them to make the theming layer easier to use and more (easily) pliable so that we could build bootstrap themes easier, but adding a theme in there that does the fancy footwork for you, well, there's no reason to have that in core.
Comment #122
lightsurge CreditAttribution: lightsurge commentedBrilliant, thanks!
It's no big deal for me whether this is in contrib or core, but I don't deny the 'saleability' logic. Drupal theming revolution aside, we already have Bartik/Garland, the look of which I agree has probably become synonymous with Drupal, and the traits of Drupal's theming evolution naturally spider off into contrib as well. Which is fine, but like I say there might be some benefit in having a theme that bears none of the traits that specifically betray a Drupal theme, in order to broaden out the range of Drupal's initial stock themes. Sort of like 'here's a Drupal theme example (default and with pride), and here's a mainstream, non Drupal-centric, theme example, Drupal can do both'. As you've proved :)
Comment #123
jwilson3Not to derail, but just a side note of where things are going:
Lots of the theme functions eg, for generating menu lists, is already being considered... Meditating on this, its almost a great example of where expanded use of template suggestions could work on theme functions in *specific regions* via template inheritance. like...
UPDATE: Here's a link to RobW's comment about template inheritance via theme suggestions. Amazing work there.
Comment #124
lightsurge CreditAttribution: lightsurge commentedAnother sidenote, I've been championing bootstrap's fixed menus on mobile, so thought I ought to point out I'm in error there, it's not supported.
https://github.com/twitter/bootstrap/issues/1617
This appears to have become relatively stable on jquery mobile (with the expectation that it'll still look miserable on certain devices) with just graceful fallback to static positioning where position:fixed is known unsupported:
http://jquerymobile.com/test/docs/toolbars/bars-fixed.html
but it's no surprise it'll take longer for desktop/mobile responsive frameworks to follow suit. Crud :(
Comment #125
pcoffey CreditAttribution: pcoffey commentedThat's pretty easy to do with a little css...
Comment #126
lightsurge CreditAttribution: lightsurge commented@pcoffey so long as you only apply that css for devices that support it, I ended up using the blacklist function in jquery mobile.
Comment #127
pcoffey CreditAttribution: pcoffey commentedCheckout the @media queries in Base Building Blocks app.less file. :)
Comment #128
anydigital CreditAttribution: anydigital commentedI've just created Tweme - alternative responsive theme based on Twitter Bootstrap.
It contains much less lines of code than twitter_bootstrap theme does, but also integrates basic theme elements and even provides automatic built-in ScrollSpy navigation for content region.
May be it could be a good candidate for core theme in the future.
Comment #129
Crell CreditAttribution: Crell commentedIt looks like we're past the 15 October deadline mentioned in the issue summary, and there's still no resolution on the licensing front (per the github issue linked above). That means this issue still cannot move forward, legally.
I think that torpedoes this issue, and also blocks contrib themes, too.
Comment #130
cweagansYep.
Comment #131
anydigital CreditAttribution: anydigital commentedSo, correct me if I'm wrong. Could we use Twitter Bootstrap in contrib themes?
I mean if TB will not be in the package and user should download it separately.
Comment #132
hixster CreditAttribution: hixster commentedShould be correct - isn't that how the Twitter Bootstrap theme deals with this already?
Comment #133
wundo CreditAttribution: wundo commentedYes it's.
The user has to manually download bootstrap files when he installs the theme.
Comment #134
sunIt is sad to see that almost no one read the issue summary, and literally no one understood the actual purpose of this proposal. Neither themers nor developers.
Both groups will continue to complain, and whine, hard, in the future.
Both groups will continue to re-invent fancy wheels, to introduce new Drupalisms.
But yet, either group does not care for any other, and fails to see the actual problem space.
You forgot about usability. You forgot about design. You forgot about common sense.
You forgot about countless of currently existing issues with more than 100+ comments, each, which are trying hard to make sense of patterns and utterly fail to do so. Because they do not know better. Because they are lacking guidance. Because they fail to see beyond the horizon of Drupal. Because they fail to see that there are a plethora of things that everyone and the world knows about and takes for a given. Just not Drupal. They have to re-invent — each and every effin' wheel — all over again.
That's the stuff you will have to deal with. All of you.
Almost all of the nay-sayers are not involved in any of those issues. It is beyond my understanding why you even commented here.
All I know is that you made sure to allow yourself to continue the whining and complaining. I'd remind you of this issue, but you do not participate in any of the other issues and thus you don't try to solve any of Drupal's actual problems either way.
You're scratching your own itch. That's all you do. And you're smart enough to think the world is flat.
You successfully prevented Drupal core to advance. See you again in 2016. And don't forget to wear this badge.
Comment #135
c4rl CreditAttribution: c4rl commented@sun I understand that you are frustrated. Despite this, comment #134 is provocative, overly dramatic, and criticizes of the participation of others. It doesn't add value or clarify anything about this issue, nor does it encourage others to support the issue proposition. I would encourage that you review the Drupal Code of Conduct. http://drupal.org/dcoc
Furthermore, you haven't participated in the issue comments since the day the issue was posted, which indicates to me a lack of effort on your part to clarify or explain the proposal better in order to assist those who did not understand the "actual purpose of this proposal." In the future, I would encourage that you participate more to dispel others' misunderstanding.
With regard to the actual issue itself, I think a stronger presence of a ubiquitous Bootstrap-driven contrib theme would likely garner more support for inclusion in core in the future (Drupal 9, perhaps).
Comment #136
DamienMcKenna@sun: We read the *original* issue summary and disagreed with it based on the merits of the *original* request, i.e. the people who had actually examined the Bootstrap theme thought it sucked. Per @crell in #129, the requisite analysis was not done to identify the best option, thus no action was taken.
Comment #137
sunUnderstood. Please also understand that I can't be everywhere, and also, that I'm actively listening to concerns, and that I do not propose any changes without prior in-depth consideration, unless otherwise stated. That said:
Let me turn it around:
TB would have helped to provide web/design/UX guidance that's hard to find for a lot of issues. Since we won't be able to learn from it directly, we will do so indirectly.
Let me abuse this issue to reference other issues that are struggling with common concepts and patterns. I'll try to keep you posted, but can't promise to hit 'em all.
The tour starts with: #1238484-116: Ability to mark the form buttons to be of a specific type (so that they can be styled differently)
Additionally, make sure to frequently check and follow the Needs Themer Review queue. Issues will get tagged with that. Changes lacking reviews ultimately will get committed, regardless of themer review.
Comment #138
sunEven better.
Comment #139
moshe weitzman CreditAttribution: moshe weitzman commentedFYI, the license issue is resolved. TB has moved to the MIT License which we can relicense as GPL in our repo. See https://github.com/twitter/bootstrap/issues/2054.
Would be great if someone picked this back up. Hopefully the Twig folks can just do their own thing and let folks work on what they think is interesting.
Comment #140
moshe weitzman CreditAttribution: moshe weitzman commentedReopening since license issue is resolved.
Comment #141
cweagansTB hasn't relicened yet, as far as I can tell.
Also, I think the reason that this was won't fixed was the level of pissing and moaning about how Twitter Bootstrap wasn't "the best" and how frontend developers hate it. Personally, I think this should still happen, but seeing how we're only a few days away from Feature Freeze, I don't see how it can.
Comment #142
tim.plunketthttps://github.com/twitter/bootstrap/issues/2054
Let's let others decide on what they want to work on, now that it's legally feasible.
Comment #143
cweagansAm I missing something? The license still isn't changed. There has been no movement. We can't do this yet, so if won't fix doesn't work for you, then postponed.
I'm assuming that you guys are seeing the GPLv2 license link at the bottom. That's unrelated to Bootstrap licensing - that's for lessphp
Comment #144
dodorama CreditAttribution: dodorama commentedThis issue was marked as a Won't fix because way beyond the Oct 15th deadline established in the issue summary.
Given that and the animated discussion that it created, I think it is starting to be rude to keep re-opening it.
Bootstrap is awesome and everything but it's a huge, complex framework and it's irrational to believe that it can be integrated 4 days before feature freeze. Those who still believe and want to keep this going need to break this in smaller, actionable issues, create consensus and being mindful about the frontend community.
Comment #145
Crell CreditAttribution: Crell commentedPer that thread, cweagans is correct. Bootstrap is still not legal to include in Drupal core.
Looking to Bootstrap for design suggestions is all well and good, but that can happen in other issues. This issue is still legally not possible, so cannot move forward. Any other "moaning and whining" is irrelevant.
Comment #146
lightsurge CreditAttribution: lightsurge commentedI think people may be getting distracted by the last comment in the github thread quoted, which relates to lessphp being gplv2 compatible and therefore not a blocker to twitter bootstrap being relicensed.
I say this because when I initially saw that comment, I briefly got excited that bootstrap had become compatible, but that's not the case.
Comment #147
amaree CreditAttribution: amaree commentedThis is a great move... however I feel that one template is not enough... Joomla 3 is out and it has bootstrap integrated into the backend as well as front end I have right now a complete responsive admin interface to give to clients from Joomla3 and they have also gone the way of including admin UI components so extension developers do not have to create there own HTML/CSS etc they can use core calls? I am concerned that Drupal is touting mobile friendliness but it will only be half implemented?
Comment #148
DamienMcKenna@amaree: You don't need Bootstrap to have a responsive admin theme, there's other work going on to make the admin interface fully mobile friendly.
Comment #149
LewisNyman CreditAttribution: LewisNyman commented@amaree, One of the aims of the Mobile Initiative is not just to implement a responsive admin theme, it's to make a great mobile UX. Simply integrating a responsive framework does not guarantee a useable experience. The work we are doing in Spark and the Mobile initiative got way beyond simply unfloating everything.
But you do make a good point about a more robust admin UI framework, providing enough components so contib developers don't need to write any CSS would result in a better and more consistent experience.
Comment #150
charlie charles CreditAttribution: charlie charles commentedI thought this was a good article
why not to use bootstrap theme
5 Reason Not To Use Bootstrap
http://www.zingdesign.com/5-reasons-not-to-use-twitter-bootstrap
Everyone saying at moment sass is
better than less
sass vs less
http://www.hongkiat.com/blog/sass-vs-less/
http://css-tricks.com/sass-vs-less/
Bootstrap only use's less while
Omega use's sass already
Twitter Bootstrap 3 vs Foundation 4 – Which One Should You Use?
http://abetteruserexperience.com/2013/08/twitter-bootstrap-3-vs-foundati...
Foundation 4 offer better features than bootstrap 3
Comment #150.0
charlie charles CreditAttribution: charlie charles commentedFormatting.
Comment #151
JohnAlbinGiven that Drupal 8's new semantic versioning makes it possible to add a new base theme in a later 8.[1,2,3,…].0 release, we could add a new hot-framework-of-the-moment base theme to Drupal 8.1.0 without changing any APIs.
Given the contentious conversation in the comments above about specific frameworks and whether or not it would be the default theme implementation, let's create a new, clean issue to continue the discussion.
See #2289619: Add a new framework base theme to Drupal core
Comment #152
sonicthoughts CreditAttribution: sonicthoughts commentedok - 2 years after this discussion began and 1%+ of the web is now using Twitter Bootstrap. Technical arguments aside, it is a great bridge to attract non-drupal devs and allow system builders to move far without involving developers.
Comment #153
giorgio79 CreditAttribution: giorgio79 commentedMaybe for 8.1?
Bootstrap is now relicensed! https://github.com/twbs/bootstrap/issues/2054
Just like the argument was made at many other places, eg
Drupal should not be in the business of creating front end frameworks. Perhaps 2-3 core themes based on bootstrap, foundation etc would be great and that's it.
Comment #154
bill richardson CreditAttribution: bill richardson as a volunteer commentedIMHO is is unreasonable to expect core to maintain any additional themes -- contrib will provide themes based on Bootstrap or whichever frontend framework is popular NOW! or in the future.
The changes made by the consensus banana team will make it easier for contrib to achieve this.
Joomla was raised as an example -- they only maintain two themes ( admin / frontend ) , and even though bootstrap is used in Joomla core most of the Joomla template shops have designed their own frontend framework to build the themes that they sell ( ie. not bootstrap -- T3, Warp, Gantry5, etc ).
Comment #155
joelpittetAgree with Bill 100%
Comment #156
markhalliwellI do not agree at all.
However, I'm only closing this issue (to its original status) because(edit: heh Joel beat me to it) there is another open issue about this #2289619: Add a new framework base theme to Drupal core. I will post my reply there.