An expansion upon the ideas originally put forward in the CMS Group: https://groups.google.com/d/msg/joomla-dev-cms/7ommekXwB-w/Gy1BxOq9nkUJ

Joomla: A proposal for responsible and sustainable dependency management

The crux of this proposal is the removal of the initimate connection between Joomla's core and third-party libraries on which it relies, in order to provide independence and robustness to each, enabling greater flexibility and strength in Joomla. Hopefully the benefits are largely self-evident.

There are really only a couple of key components to this proposal which, while they may proving challenging to implemnent, should conceptually be easy to grasp;

1. PROTECT THE INTEGRITY OF THIRD-PARTY ASSETS
2. CONFINE VENDOR-SPECIFIC CODE TO VENDOR-SPECIFIC IMPLEMENTATIONS
______________________________________________

1. PROTECT THE INTEGRITY OF THIRD-PARTY ASSETS
There's little point in adopting a popular library, like Bootstrap or jQuery, if it is then adapted in-situ. It is, at that point, no longer the popular third-party library that was adopted, it is a derivative. The burden of maintaining, supporting and developing such derivatives then falls the to Joomla project and this is a burden that can ill be afforded. Divergence hurts us.

I propose that such third-party assets remain untouched, without exception, so that they remain carbon copies of their upstream counterparts. Contrast this to the situation we have now; Joomla does not use Bootstrap 2.3, Joomla uses the JUI a derivative of BS2.3. This makes it difficult to update, adds a maintenance burden and means that one of they prime selling points given for the adoption of this standard (ubiquity) is not true.

Wherever it as seen as necessary to modify these libraries all such modification must happen outside the asset in question. To give a clear example; JUI should not use icomoon font icons, as Bootstrap does not. This one change is a comptibility break and could be avoided very easily in Protostar's template LESS by not importing the Bootstrap icon LESS and instead declaring icomoon icons within the template. The same for Isis of course. No loss of functionality, no unused code, no compatibility break with Bootstrap.

Such an approach will also mean that multiple, and alternate, versions of such assets can all be incuded, side-by-side and without conflict. Bower makes it incredibly simple to maintain dependencies in this manner and I'd recommend it's use in this case.

In practical terms my suggestion would mean replacing (initially deprecating):

	/media/jui/

with:

	/media/bower-components/bootstrap2.3.2
	/media/bower-components/bootstrap3.1.1
	/media/bower-components/jquery1.9.2
	/media/bower-components/chosen

Of course, with such an implementation it's also trivial to include, for example:

	/media/bower-components/bootstrap-sass3.1.1
	/media/bower-components/foundation5
	/media/bower-components/pure0.4.3-pre

	/media/bower-components/jquery1.10.1

___________________________________

2. CONFINE VENDOR-SPECIFIC CODE TO VENDOR-SPECIFIC IMPLEMENTATIONS
Bootstrap 2.3 specific markup is desirable only to views that are using BS2.3 and, in fact, may be deliterious to outputs that are not. Templates are the boundary layer delimiting final output, so it is only logical that anything required, and specific to, the final rendered output be implemented there.

Currently, we have vendors-specific markup generated at the component level when such markup is only relevant at the template level. There is no guarantee that the template will even support these markup patterns and there can never be (rightly so IMO).

The relationship between generated output and any libraries it may require can only properly be set within the final point-of-truth for that output, the template. Therefore I would suggest that all vendor-specific patterns be confined to vendor-specific templates. Such an impementation would allow a huge degree of flexibility and allow fast innovation and improvement. It would, for example, be trivial to update the default Joomla output to use Boostrap3, without any breaks in backward or forward compatibility, something that we would dearly love but simply cannot do today. Protostar v1 is dependant on BS2.3, Joomla should not be. 

Vendor (and version) specific template implementations would mean Joomla is not vendor and version specific, reducing fragility, maintaining independence and promoting forward development of the CMS.

In practice this would mean removing all BS2.3 flavoured markup from core views and layouts and placing it in template overrides.

I general, I like the approach.

One small issue I don't like is the folder naming. Does it have to be named /media/bower-components/bootstrap2.3.2? Wouldn't media/bootstrap2.3.2 make more sense?
I don't know bower, so I may miss something here since I don't know Bower. But since the files in media will end up as assets loaded by the browser, I don't like an implementation specific folder name there :)

Another thing to consider: While multiple templates will work for core extensions where we can create overrides for each output and make them bootstrapped, what will you do for 3rd party extensions?
As I understand it core would have a clean HTML output with some semantic CSS class names, and 3rd party extensions would be expected to do the same.
Protostar would then add overrides for each view and add Bootstrap2 stuff to it to make it look nice. Protostar V2 for example would then add overrides for each view and add Bootstrap3 stuff to it.
3rd party extensions would look like crap then on both templates as long as you don't add overrides for the extensions views. But the user will not know this and blame the extension. And what happens next? The extension dev will add his own classes, build his own CSS file and load it on every pageload for his extension. His extension will look nice again, but doesn't fit at all into the theme of any template. We will be back to J1.5 days.

This is why I think it was great that extensions standardised on Bootstrap markup for their outputs. As long as the user uses a BS2 template, the output will look nice and fit nicely into the template theme without the extension loading an own CSS file. If the template doesn't use BS2, it may again look crappy and the user needs to create overrides. Since those templates already exist, the users again went to the extension dev (not the template designer) and complain that the extension looks like crap. And what happend? Extension developers went and included Bootstrap by themself, since they couldn't rely on the template designer doing it. Resulting in the same mess we had in J1.5, but instead they now load a complete framework instead.

That's why I think we need some standard set of CSS classes which extension developers can use and which template designers will support. Like a class "warning" which will add emphasis on a message. A "well" class (doesn't have to be named like this) to add some visual box around the content to make it distinct from the surrouning. Maybe "label" and "badge" classes and so on. This is what I like the most about Bootstrap. I was able to get rid of most my CSS rules for my own extension.
I actually don't want to design, I want to code. I am doing really bad at designing stuff. Thus if designers can come up with some nice CSS classes which we coders can use and which will make our extensions look beautiful automatigally, then I'm sure extension developers will love you :)

Thanks for the feedback @Bakual :)

I can see what you mean but I do quite like that it is immediately obvious these assets are managed with Bower, so I see that file path clue as an advantage. It's no big deal though, of course it could as easily be just /media/ if that was preferred.

Regarding third-party extensions we wouldn't need to do anything, it isn't needed. As you say:

“As long as the user uses a BS2 template, the output will look nice and fit nicely into the template theme without the extension loading an own CSS file.”

The template is already a dependency of the extension, it simply isn't labelled as such. Extension developers would simply need to state if their extension is ‘built for Bootstrap 2.3.2.’ or ‘Built for Bootstrap 3’, or whatever. A user simply needs to ensure that their template and extension versions match. That is already the case, but because there is no requirement to make that clear everyone feels they can't rely on core and so loads their own. We can't easily support both BS versions at the moment simply because of the way that Bootstrap is not implemented in the template.

This proposal would allow all extension devs to really be certain that the assets they need exist and will work as expected. That isn't the case today given that templates are not framework-specific.

Actually, as a designer all that I want is that extension developers provide the function and I do the styling. You don't need to consider classes like .label .well or .badge, these are all stylistic decisions that have nothing to do with the functionality and should be left to the designer. It's debatable that such classes should ever appear in markup, style should be implemented in css.

.warning and .alert describe the function so these give me valuable information I can use to make such decisions. It should be for the designer to decide upon the design of the warning alert. This is how I'd see a set of core classes being created and extension developers could easily follow the same principles.

<a class="readmore", for example, is infinitely more useful to me as a designer (and I believe to you as an extension dev) than <a class="btn btn-default" will ever be. Both of us can see from the markup what that element is for and we can both handle it accordingly.

Seth,

Thanks for this great write up. Thomas has essentially covered most of what I had in a draft already. With that being the case, on a very basic, simplified level, would one way to summarize your proposal be that the goal is uncouple and simplify the markup generated by the core of Joomla so that it is easier for template developers / designers to implement other CSS frameworks and/or to use the clean, semantic, simple core markup with CSS directly?

You don't need to consider classes like .label .well or .badge, these are all stylistic decisions that have nothing to do with the functionality and should be left to the designer. It's debatable that such classes should ever appear in markup, style should be implemented in css.

That's why I think designers should define a set of CSS classes, and not coders like me 😄
Currently I use the "well well-small" class to display small messages/information blocks in an upload form. One is to show the current upload limits and another one the path where the file will be stored. I guess a class like "notice" or "info" would fit better then. I actually don't care how it's styled. I just want it to be separated a bit from the rest of the form so it stands out a bit but doesn't distract.

would one way to summarize your proposal be that the goal is uncouple and simplify the markup generated by the core of Joomla so that it is easier for template developers / designers to implement other CSS frameworks and/or to use the clean, semantic, simple core markup with CSS directly?

Yes, that is one of the benefits that I can see. Others include:

1. Freeing Joomla of the maintenance burden of modified 3rd-party libs.
2. Providing extension developers the certainty that these libs are 100% reliable, e.g. that Joomla BS2.3.2 is 100% BS2.3.2.
3. Allowing upgrades of core assets and outputs, mid-cycle, without any BC breaks.
4. Ensuring compatibility issues were limited to a single location, the template.
5. Allowing mid-cycle upgrades of the front-end environment without BC issues.
6. Allowing, for example, 3.2 extensions to be run in a 6.2 site.

All of these become possible when we think of the template as becoming the compatibility layer. Crucially, all such compatibility issues would be managed in a single location.

I guess a class like "notice" or "info" would fit better then. I actually don't care how it's styled. I just want it to be separated a bit from the rest of the form so it stands out a bit but doesn't distract.

Exactly. Bootstrap's .alert and .alert-info are a great fit for such a use case. They allow me to understand exactly what you intended of those elements and I can style them accordingly.