Re: [jcms] Completely disable Bootstrap

4,378 views
Skip to first unread message

Youjoomla LLC

unread,
Dec 12, 2012, 1:55:17 PM12/12/12
to joomla-...@googlegroups.com
Use MVC Template overrides ,  and remove calls for bootstrap 

On Wed, Dec 12, 2012 at 1:02 PM, Alex Crawford <awc...@gmail.com> wrote:
I am creating a template from scratch. I am using Foundation Zurb as it is much better than Bootstrap. I've removed any trace of JHtml::_('bootstrap.etc); from my template's index.php, and only have in place JHtml::_('jquery.framework', false);.

* The problem: This is still showing up in my <head>...
<script src="/media/jui/js/bootstrap.min.js" type="text/javascript"></script>

I see many components load bootstrap or a piece of bootstrap, such as JHtml::_('bootstrap.tooltip');

I tried creating a plugin which onAfterRender() { would parse $doc->getHeadData();. However, Bootstrap DOES NOT appear. Somehow, Bootstrap is being added AFTER onAfterRender() {...

Please, I need any suggestion or workaround to prevent bootstrap from loading at all.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/3x5FnvQtdr0J.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.




--
Best Regards
Dan Casky
Youjoomla Customer Service
+1727-388-6653
5044 17th street N
Saint Petersburg ,FL
33714
-------------------------------
Youjoomla LLC
www.youjoomla.com
Professional Joomla Web Design Services

Youjoomla LLC

unread,
Dec 12, 2012, 1:59:09 PM12/12/12
to joomla-...@googlegroups.com
Here is example
http://docs.joomla.org/How_to_override_the_output_from_the_Joomla!_core

Bakual

unread,
Dec 12, 2012, 2:08:39 PM12/12/12
to joomla-...@googlegroups.com
Since the script usually is loaded with JHtml::Script, you should be able to override the script itself with your own version. This could also be an empty file. This way you don't have to remove anything.
 
But then it's probably a bad idea to remove a core feature from Joomla 3.0. It's almost certain that some extensions will not work properly. That's ok if you only develop a template for yourself, but if you're going to share your template then you just ask for problems here I guess.

Chad Windnagle

unread,
Dec 12, 2012, 2:12:21 PM12/12/12
to joomla-...@googlegroups.com
You might be able to do it from within the index.php file for your template and unset of the scripts:

Check out Matt Thomas' code here:


It uses the unset to remove things. You should be able to remove the script this way. Since the template will be the last thing to fire before you output the <jdoc:include type="header" /> head scripts. 

-Chad

Regards,
Chad Windnagle
Fight SOPA

Chris Davenport

unread,
Dec 12, 2012, 2:43:31 PM12/12/12
to Joomla! CMS Development
PHP code in the template is not necessarily the last to fire before the jdoc head.  It's likely that if a module uses JHtml or JDocument::addScript to add anything to the head, that that will fire after the PHP code in the template.  The safest way to manipulate the head array is to hang a plugin on the onBeforeCompileHead event.  That really is the last thing to fire before the jdoc head.

See: http://docs.joomla.org/Plugin/Events/System#onBeforeCompileHead

Chris.

--
Chris Davenport
Joomla Production Leadership Team

Chad Windnagle

unread,
Dec 12, 2012, 2:44:32 PM12/12/12
to joomla-...@googlegroups.com
Nice Tip! Thanks Chris.

Regards,
Chad Windnagle
Fight SOPA



Alonzo Turner

unread,
Dec 13, 2012, 10:20:05 AM12/13/12
to joomla-...@googlegroups.com
As Chris suggested use the OnBeforeCompileHead event. Here is some sample code that will help you to filter javascript. I don't think it will work out of the box for you, but it should be helpful.


Seth Warburton

unread,
Dec 14, 2012, 4:50:19 AM12/14/12
to joomla-...@googlegroups.com
There is a larger issue here, and one that I have become quite concerned with lately, and that is the issue of Bootstrap markup in core outputs.

I guess not everyone realises that Bootstrap markup is not clean, semantic html. The core now outputs a lot of Bootstrap-specific markup which is also extremely difficult to remove. A lot of standard Bootstrap markup elements are non-semantic, poorly constructed and fly in the face of accepted web standards; moreover *it is Bootstrap specific*. You can choose, or build, a template based on whatever you like, *but you will have Bootstrap markup*.

As well as struggling to prevent unused Bootstrap assets from loading I am now writing *a lot* of overrides only for the purpose of producing clean markup. That is the only way to correct markup issues and personally, I think that is a little crazy. It is the total reverse of what should be happening. In my opinion, core should out-put clean, semantic, and standards-based markup and then the 'add-ons' (Bootstrap, Foundation, etc...) should be layered on top, to the presentation layer. Progressive enhancement??

Before I am accused of simply player-hating I would like to say that there is a lot I do like about Bootstrap, but I don't like the poorly constructed markup that it requires in many cases and I do not like the current implementation of it in Joomla. It effectively forces everyone down the Bootstrap path whether they like it or not. Such integration takes away choices and freedoms of front-end developers and site owners rather than add to them.

It is my firm belief that Bootstrap should be integrated only at the template level. *All* templates require html, and that should be the foundation of core output; clean standard html. Nothing more, nothing less.




Seth

Roberto Segura

unread,
Dec 14, 2012, 6:54:17 AM12/14/12
to joomla-...@googlegroups.com
I'm a coder but I think that you are right. Probably we should adapt bootstrap to Joomla! and not the other way. When bootstrap was adopted I didn't know this was possible.

This is a link that I think should be the main idea about what's Seth saying:


I'm sure that this will be the way that Joomla! will follow in future versions. The actual state is the first bootstrapped version and the simplest way to implement bootstrap was using the default markup . 

Count on me in the future to solve that bootstrap frontend dependancy.

Seth Warburton

unread,
Dec 14, 2012, 7:49:25 AM12/14/12
to joomla-...@googlegroups.com
+1000 Yes!!

Got it in one. Thanks for posting that link Roberto, that is exactly how I believe it should be done.  

Using classes that serve only as styling hooks is bad practice, as it blurs the separation between content and style and rapidly becomes non-sensical. What use is the class .hidden-mobile at a desktop resolution? None, so it shouldn't be there. 

LESS makes is so easy to properly apply these styles as appropriate and without the extra classes. Here, for example is how I create a grid with a 25% width module, right-aligned, in my banner: 

[role="banner"] section {
  .column(4);
  .push(8);
}

My markup is only: 

        <div class="banner">
            <header id="banner" role="banner">
                <jdoc:include type="modules" name="banner" style="gangnam" />
            </header>
        </div>

The banner is one of only two places I use an element ID and that is only there as a .js hook, it never appears in my css.

Critically, my markup is framework agnostic. You can apply whatever style you want, however the hell you want. No fuss, no limitations and no loss of functionality. The template css alone will decide the front-end style and I believe that is exactly how it should be. That is what templates are for afterall....



Seth

Victor Drover

unread,
Dec 14, 2012, 7:53:58 AM12/14/12
to joomla-...@googlegroups.com
+1

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/ZJxv1hGRTLgJ.

Seth Warburton

unread,
Dec 14, 2012, 7:57:55 AM12/14/12
to joomla-...@googlegroups.com
A quick example of just how elegant LESS can make applying styles:

The markup: <a class="readmore">This is my readmore Bro!</a>

The LESS: .readmore {.btn;}



Seth

On Friday, 14 December 2012 11:54:17 UTC, Roberto Segura wrote:

Matt Thomas

unread,
Dec 14, 2012, 8:41:12 AM12/14/12
to joomla-...@googlegroups.com

+1000

Best,

Matt Thomas
Founder betweenbrain™
Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

Composed and delivered courtesy of Nexus 7.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/f0xHqAdZ0SkJ.

sasi varnakumar

unread,
Dec 14, 2012, 8:47:51 AM12/14/12
to joomla-...@googlegroups.com
Hello Seth and Roberto,
    Really a good point man, i will stop using direct bootstrap classes and make my own css as the link and you guyz suggested. This was helpful, need to spread soon so each component developer realizes it and since joomla followed same way i though that's right. Ok need to change. :)
Best Regards
Sasi varna kumar
Lead developer - J2Store


--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/f0xHqAdZ0SkJ.

To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.



--
  keep smiling ..!! 
S.Sasi varna kumar ( 9952661702 )
Facebook  ||  Twitter  ||  Wordpress


Youjoomla LLC

unread,
Dec 14, 2012, 3:15:16 PM12/14/12
to joomla-...@googlegroups.com
+1000 Seth, 
The approach I went for is adapting our template /extension to look same with or without Bootstrap ,
and making sure that there is no bootstrap markup by default
and Bootstrap should have been optional and not as is now in core components. 

All of a sudden everyone thinks that they cant live without bootstrap. Have we 
forgotten how to style our own buttons , or how to use our own css font icons? 

I would understand making a admin template based on bootstrap , but using it so much , it is a joke. 

And in time j30 was released BS version used was  2.1.1 ,   now it is 2.2.2 with A LOT of fixes , which 
are still not applied in Joomla.  Just today I fund over 400 css lines RTL fixes, Yesterday, navbar responsive menu in 
2.1.1  is completely different in 2.2.2. and so on...

The way it is right now it is horrible .


Seth Warburton

unread,
Dec 14, 2012, 3:41:25 PM12/14/12
to joomla-...@googlegroups.com
Just to make clear, I'm not arguing against Bootstrap in general (there are some very good parts), but I do think the current method of implementation is sensible.

I would like to see it implemented only in the presentation layer though. Everything that is done currently now can be done without any modification to core markup, so I think that such extensive modification to core markup is not sensible for three reasons; 
  1. It dilutes the code quality in general by introducing bad markup and requiring poor coding practice.
  2. It ties Joomla so tightly to Bootstrap that it is inseparable in practical terms (we have removed user choice). If you choose Joomla, you choose Bootstrap whether you like it or not.
  3. In harming code quality it damages accessibility and usability.
Bootstrap is a fantastic toolkit, but we should always remember that users and developers might want to use their own tools. If it were implemented in a template each of the problems above are easily remedied by the developer. Users get choice. I'm arguing for choice and flexibility.

Michael Babker

unread,
Dec 14, 2012, 3:41:35 PM12/14/12
to joomla-...@googlegroups.com
The CMS also has a responsibility to users of Bootstrap in the CMS to not perform a major upgrade of the Bootstrap framework mid-cycle.  So, IMO, it would be a bad idea to update from 2.1.1 to 2.2.2 between Joomla! 3.0.2 and 3.0.3, especially if it has the potential to break sites.  That update is better suited for 3.1 in March IMO.

That said, I'm personally on the fence on this.  On the one hand, I think the markup has gotten a bit cleaner over what we had before.  On the other hand, it is difficult to impossible to get around using Bootstrap elements.  I'd like to hope by 3.5's release, that we get a lot of these kinks worked out of the system and overall improve on the first implementation of Bootstrap in the CMS.  Every little bit will help.

Bakual

unread,
Dec 14, 2012, 3:48:41 PM12/14/12
to joomla-...@googlegroups.com
I don't see that much of a problem with this. In contrary. Yes it is partly against the design rule to have design and content separated. But then this is Joomla, a framework where we have developers of extensions and developers of templates and finally the users. The extension developer has no way of knowing what templates will be used at the end, the template developer has no way of knowing which classes will be used and what extensions will probably be used. The user finally has no clue of everything and just expect it to work and look nicely.

So far every extension developer made their own classes and CSS files and just hoped the template will not break the page. I am myself a mediocre coder, but a horrible designer. So my extensions usually didn't look fancy as I just did some basic CSS and hoped the template will support my classes (copied from core extensions), which often failed due to overrides and such.

Bootstrap brings us a well known set of classes which allows an extension developer to apply some basic styling to the output of the extension. As an example he can create a two column layout very easily by just using two classes (span6) without even using own CSS. I don't care much if it's bootstrap or Joomla own classes, but I really like the idea of having well-known classes which will be supported by every template.
If Joomla decides to create own classes/markup, I'm sure the documentation will be lacking and templates will not support all of them, shooting us back to where we were in Joomla 1.5 / 2.5.

This well-known classes give us two main advantages:
  1. The resulting site will look consistent over the various extensions
  2. There is only one CSS file that gets loaded, and not one for each extension.
If you can achieve the same with a different approach, I'm all for it. But I don't really see how that would work.

Youjoomla LLC

unread,
Dec 14, 2012, 3:53:14 PM12/14/12
to joomla-...@googlegroups.com
Sure we all love it , no one says different , but with current way of implementation just like Michael says , 
 especially if it has the potential to break sites.
we should have thought of that in the first place and not allow Joomla to marry Bootstrap, Bootstrap should have been a step child :) 

Sorry for using this thread and might been steering away from main question but 
another issue , I spoke to few fellows template club owners , are you guys aware that over 80% our customers and I 
am sure plenty global Joomla users are web dev/css/html/..... beginners?

People who are just starting with web development. And now we are all kinda forced 
to trow LESS CSS and Bootstrap at them where we are sure they will be lost. 
I LOVE LESS , makes it so easy for me , but I see that  when I release new template 80% 
of my customers wont understand it if it is 100% based on new tech. 

Sure it is our job to teach them and we all do that but are they willing to learn if they just want a informational website? 

I see few clubs reverted 100% to LESS CSS and Boostrap, or Just made Boostartp
supportive templates for 3.x, which in my eyes is betrayal of their own customers. Yes we should 
teach them new way , but on their own pace and we should make all of that extra mambo/jumbo optional for end users. 

brian teeman

unread,
Dec 14, 2012, 4:01:54 PM12/14/12
to joomla-...@googlegroups.com, youjoo...@gmail.com
Where were all of you during the development of Joomla 3. If bootstrap is such a terrible idea or the implementation of bootstrap is so bad, or it should be only in the administrator then the development phase was the time to speak out. 

I have my issues with some of the bootstrap stuff and I did raise them and some of them were or are being addressed. Thats the whole point about open development its open for everyone to look at and participate with at any time during its development. This isnt the closed source world where we can all moan at the changes introduced behind a closed door

Bakual

unread,
Dec 14, 2012, 4:06:30 PM12/14/12
to joomla-...@googlegroups.com, youjoo...@gmail.com
I don't think you need to explain LESS CSS to your users. I understand LESS mainly as a tool for developing. In the end you have a single compiled CSS file which the browser reads. This file can be adjusted and extended like any CSS file so far. So for the end user, nothing really changes. He doesn't need to know how it was built.

Youjoomla LLC

unread,
Dec 14, 2012, 4:14:18 PM12/14/12
to joomla-...@googlegroups.com
@Bakula , do you know how many templates are actually used as they were released. I say none. 
And that means that every template gets redone after the download. Point of single CSS file is the end result of LESS
in order for them to make changes and adopt it to their own way they must know more than just " there is 1 css file". 
Especially when generated file including Bootstrap is more than 5000 lines . 

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/un48gWRBZR8J.

To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

brian teeman

unread,
Dec 14, 2012, 4:20:58 PM12/14/12
to joomla-...@googlegroups.com, youjoo...@gmail.com


On Friday, 14 December 2012 21:14:18 UTC, Youjoomla LLC wrote:
@Bakula , do you know how many templates are actually used as they were released. I say none. 

And my experience says the oposite. Ive trained hundreds of newbie webmasters and the vast majority never touch a line of css or even know what css is.

My point. Generalisations are fun but they are meaningless

Bakual

unread,
Dec 14, 2012, 4:52:33 PM12/14/12
to joomla-...@googlegroups.com, youjoo...@gmail.com
My experience in supporting my extensions says most user just use a template "as is". They just install a template and expect everything to work. I need to tell them the most basic things if they like to change something. They usually don't even know how to use the development tools included in their browser.
 
Even if it were true that they change a template, it's sufficient if they just change the code in the single final CSS. There is no need for them to browse through the LESS files.
 
It's also what I do myself. I install a template, use the options provided by it and then I just look up what I want to have changed with the development tools and change the line the tool points me to.
Till now this even was needed because templates usually had more than one CSS file loaded. LESS makes this easier since you only have one single file now.

Nick Savov

unread,
Dec 14, 2012, 5:20:35 PM12/14/12
to joomla-...@googlegroups.com
Hi Seth, Roberto, and others,

Can we implement those changes in a backward compatible manner? If so,
let's get that going.

Seth, could you start some documentation on the wiki that would help
educate people about this concept? The more people know about this, the
more likely it is to get used.

Kind regards,
Nick
>> escribi�:
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-cms/-/ZJxv1hGRTLgJ.

Roberto Segura

unread,
Dec 14, 2012, 5:25:23 PM12/14/12
to joomla-...@googlegroups.com, youjoo...@gmail.com
In my opinion bootstrap was a great decision, probably the best possible. 

Thanks to bootstrap (and the work of all the contributors) we have the best backend in the CMS world with the best browser compatibility possible. We all shouldn't doubt about that. Bootstrap is not a mistake.

But we have to go on improving Joomla! Users should be able to disable bootstrap. Also if we can create a clean HTML markup framework independant ... why not? Let's do what template developers are asking keeping the good that we have now. Isn't that compatible?

Of course, template developers should be the first collaborating to bring what they are asking into Joomla!

As I'm not a designer I've been searching info about what should be changed in the markup. Someone posted on Twitter this link:


Seems that after all bootstrap markup isn't as bad. 90% is semantically correct.

As professionals: what do Joomla! template developers think about it? Is that true? What needs Joomla! HTML markup in your opinion? 

Maybe we can do it easily. Maybe it isn't doable. Knowing the requirements is the first step.

Gary Mort

unread,
Dec 14, 2012, 6:31:43 PM12/14/12
to joomla-...@googlegroups.com


On Wednesday, December 12, 2012 1:02:36 PM UTC-5, Alex Crawford wrote:
I am creating a template from scratch. I am using Foundation Zurb as it is much better than Bootstrap. I've removed any trace of JHtml::_('bootstrap.etc); from my template's index.php, and only have in place JHtml::_('jquery.framework', false);.

* The problem: This is still showing up in my <head>...
<script src="/media/jui/js/bootstrap.min.js" type="text/javascript"></script>

I see many components load bootstrap or a piece of bootstrap, such as JHtml::_('bootstrap.tooltip');

I tried creating a plugin which onAfterRender() { would parse $doc->getHeadData();. However, Bootstrap DOES NOT appear. Somehow, Bootstrap is being added AFTER onAfterRender() {...

Please, I need any suggestion or workaround to prevent bootstrap from loading at all.


Your designing a template?  In that case your wasting your time with plugins, you already have everything you need.

JHtml::_('bootrrap.framework') will call:
JHtml::_('jquery.framework');
JHtml::_('script', 'jui/bootstrap.min.js', false, true, false, false, $debug);

Skipping 2 the second half, that loads the bootstrap javascript.

 The important bits here are:
the path is 'jui/bootstrap.min.js'
and the $relative flag has been set to true.

This means it is going to end up calling:
JHtml::includeRelativeFiles

The string min. is in the string, so the ACTUAL file it looks for will be either:
'bootstrap.js'
'bootstrap.min.js'

Depending on whether or not your in debug mode.

But where does it look?  Well, the very first place it will look is in:
template/{templatename}/js/jui

So you can provide your own empty bootstrap.js and bootstrap.min.js files in your template and thus "disable" it.


The same holds true for CSS files.  Most times when Joomla tries to load a css file, it will first check
in template/{templatename}/css/

So if you want to change any existing javascript or css behavior, 9 out of 10 times you can do it with a template.

Gary Mort

unread,
Dec 14, 2012, 7:18:21 PM12/14/12
to joomla-...@googlegroups.com


On Friday, December 14, 2012 4:50:19 AM UTC-5, Seth Warburton wrote:
 
Before I am accused of simply player-hating I would like to say that there is a lot I do like about Bootstrap, but I don't like the poorly constructed markup that it requires in many cases and I do not like the current implementation of it in Joomla. It effectively forces everyone down the Bootstrap path whether they like it or not. Such integration takes away choices and freedoms of front-end developers and site owners rather than add to them.


Keep in mind that many other users are asking for the opposite.  They WANT additional classes added to the built in CMS components.  As it is right now, they have a lot of trouble applying a style for just one specific component/screen and not hitting lots of other areas.

More classes gives more option.  Whether these are bootstrap classes or joomla defined classes - end users want and need them.

Mind you, I did struggle a bit with conflicts between bootstrap and jquery-ui when integrating the raptor editor into my own site. But once learned it wasn't so bad.

Daniel Dimitrov

unread,
Dec 15, 2012, 5:08:27 AM12/15/12
to joomla-...@googlegroups.com
Hey @everyone,
I'm a little late to the discussion, but I thought that I should add my 2 cents anyway.
There is a big gap between theory and practice. In theory I love the the ideas in "Designing with web standards" - in practice - no thanks (just have a look at the discussions for the above mentioned article http://ruby.bvision.com/blog/please-stop-embedding-bootstrap-classes-in-your-html )...
The biggest problem that we developers had until version 3 was how to write our html and css & make it look nice on dark, white, yellow and whatever designs... Some templates use head, other use header, another are going for my-monster-header classes. Maybe the markup of bootstrap is not semantically correct (<i> tag anyone????), but it solves our biggest problem - we can write code and be sure that the designer can do whatever he sees fit.
Having those common classes - as bad as they are named is a HUUUUGE improvement. We as developers now know what classes we can use, what elements we can use and this way we basically outsource the design to the designers...
If you try to implement bootstrap with LESS then what markup should I use? We are again going to a situation where I have no idea if you've styled a H2 as a H2 and not as a <p>...
Cheers,
Daniel

elin

unread,
Dec 15, 2012, 12:50:41 PM12/15/12
to joomla-...@googlegroups.com
I had my reservations about Bootstrap but one reason I came around was that Kyle convinced me we as individuals or as a project can be contributors to improving the quality of the markup they produce both in terms of web standards and accessibility, and we have already been able to do that.  He also pointed out that if they stop being responsive to those improvements or if they basically die as a project (always possible) we could simply fork and continue down a positive road on our own.

Many of the problems of the core markup in 3 are not due to Bootstrap they are due to the incorrect implementation in the layouts.  We had beautiful outputs in 1.6+ and now have regressed somewhat but thanks to Angie and others we are on the road to moving back in the right direction on that. So my suggestion would be to continue working on improving those steadily while not breaking sites.

In terms of disabling, it's something a webmaster should be able to do as should som ne designing a 100% custom installation but it is not something that developers of plug and play extensions should do if they want to have a decent reputation with end users and the same goes for retail templaters if they want to make money over the long term.   

Elin

Youjoomla LLC

unread,
Dec 15, 2012, 1:03:35 PM12/15/12
to joomla-...@googlegroups.com
Kyle did an awesome Job , but all overrides of the frontend core components to accommodate Bootrstrap ,
should have been done in template overrides and not in extensions itself. 
@Alex , Silviu 
 is poking in 3.0 to disable BS completely. Will let you know. 


--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/3J5cOY0LnwQJ.

To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

Bakual

unread,
Dec 15, 2012, 1:55:14 PM12/15/12
to joomla-...@googlegroups.com, youjoo...@gmail.com
If you don't use Bootstrap in core extensions and only leave that to template overrides, then there is no reason to include Bootstrap at all into Joomla. You can do this already with Joomla 2.5 if you want.
The main improvement is that 3rd party developers can count on that Bootstrap is available and don't have to produce own markups and CSS files for everything. That is a very huge improvement for everyone, extension developer, designers and users.
Your templates will miss an important feature of Joomla 3.x if you exlude Bootstrap. Just saying. They will be only usefull if the user only uses core extensions, which are porobably only a few users.

Youjoomla LLC

unread,
Dec 15, 2012, 2:00:17 PM12/15/12
to joomla-...@googlegroups.com
You don't understand my point Bakula , 
With 1 line in index.php  you can call Bootstrap which will be present in any component.
This way you can control if Bootstrap is present or not and that is what Alex is asking for.


To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/0rt6SPzRg1IJ.

To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

Youjoomla LLC

unread,
Dec 15, 2012, 2:04:34 PM12/15/12
to joomla-...@googlegroups.com
Nice one Christina +1000 , that is how it should work . 
Sample frontend template with and sample frontend template without Bootstrap. 

As is right now we soon will have hands full with same questions when Mootools was introduced. 





On Sat, Dec 15, 2012 at 12:44 PM, Cristina Solana <c...@nightshiftcreative.com> wrote:
Good afternoon everyone,

I normally don't spend much time responding to threads, but I thought that maybe I could simplify this for some action.

When I first heard that Bootstrap was going to be integrated with Joomla my response was: great for the backend template, but please keep it out of the frontend. I think it's great for the backend because you have a UI with a unified UX across the board, not the disjointed mess it is when you have the core UI + different UIs for each additional extension (not always, but fairly frequently the case) making it unintuitive to the end user.

For the frontend, leaving it out is my desire because I, like most frontend developers, am very particular about class naming and frequency at which classes are included with elements. Seth and I, who tend to agree on a lot, could probably find 101 possible particulars of frontend development techniques that we would disagree on. Frontend development is incredibly involved and rapidly changing. A frontend developer wants complete control, from HTML elements to class names.

I think what is usually missing from these conversations is focus on who the target audience is. Most of us are business people here and understand that if you try to be all things to all people you usually fail miserably. We can not reconcile the needs of both frontend developers and DIYers. No, that's not true in this case. This is easily resolved if we can all agree:

1. Joomla's core output should not be tightly coupled with any framework.
2. Create a Bootstrap template. Bootstrap can be the default template just like Beez and others had been in the past. The HTML overrides happen at the template level. I say make it default because I wholeheartedly think that the vast majority of users are not frontend developers (though a number rather than a gut feeling would be more helpful.)
3. Also include a barebones template with stripped down overrides, no classes possibly not even any HTML elements with exception of the body tag and up. Depends on how barebones we want to get.

The benefit: we are able to do what is often impossible, make two groups on polar opposites of the needs and skills spectrum happy. I can't see any downsides at the moment. Please point any out if I missed them.

If that is an option I would be happy to contribute time to making it happen because I will likely need to do it anyway for a client very soon. :)

Please pardon any misspellings or poor grammar, on mobile.

Cheers,

Cristina Solana

"Functional Hacker: Think like a fundamentalist, code like a pragmatist." - @headinthebox


--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/eQNbf1VPZ9QJ.

To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

Michael Babker

unread,
Dec 15, 2012, 2:08:41 PM12/15/12
to joomla-...@googlegroups.com
Agree fully.  IMO, the markup in core should make it so that if someone wants to use Bootstrap in their template, it's enabled there.  At the same time, you take away the Bootstrap flare, you should still have a fully functional output that is easy to customize.  I'm sure we can get there.  But, as all things go in the code world, nothing's perfect on the first implementation, 3.0 being that first implementation.

I think we're all in agreement on what we want the end state to be, so how about putting some of this discussion effort into code?

From: Youjoomla LLC <youjoo...@gmail.com>
Reply-To: <joomla-...@googlegroups.com>
Date: Saturday, December 15, 2012 1:04 PM
To: <joomla-...@googlegroups.com>
Subject: Re: [jcms] Re: Completely disable Bootstrap

Youjoomla LLC

unread,
Dec 15, 2012, 2:18:01 PM12/15/12
to joomla-...@googlegroups.com
Silviu is poking on code to disable it from template index.php which will be a hack but it will help Alex at this point , 
so far I see all we need is to remove JHtml::_('bootstrap.framework'); from core extensions and let templates take over , 

Youjoomla LLC

unread,
Dec 15, 2012, 2:24:22 PM12/15/12
to joomla-...@googlegroups.com
As for template overrides that one is bit more complex since bootstrap markup is there already , 
but I just came to think , since MVC , Joomla or no one except I think YooTheme ( with own markup ) has released 
overrides examples for core , there are docs , but I think what would help everyone is 
sample overrides with core markup that they can use and make own from there. Hm i might get on that

Michael Babker

unread,
Dec 15, 2012, 3:00:00 PM12/15/12
to joomla-...@googlegroups.com
bootstrap.framework is only instantiated a handful of times, either in support methods or directly in the templates.  That's not the issue.  What is, however, is which elements of Bootstrap are used where.

A quick search for "bootstrap." shows about 400 results.  The most commonly used is bootstrap.tooltip.  bootstrap.modal and the accordion methods (used to replace JHtmlSliders and JHtmlTabs) are the next commonly used items.  Of those ~400 uses, it looks like ~35 are actually called in the front end.  So, in terms of the front end being forced to use Bootstrap and it's helpers, I think you can get around it.  The markup is a bit more difficult to get around, agreed, and that is where folks should focus on improving the core.

There is one area that will be difficult to impossible to get around, and that's with the library files that produce markup (JForm and JHtml specifically).  Those are mostly admin helpers though, so shouldn't make much of a hassle for the front end.  But, I do think that Bootstrap's form markup (and the use of Chosen) is an improvement, and would probably argue strongly against reverting some of those changes.

Youjoomla LLC

unread,
Dec 15, 2012, 3:05:50 PM12/15/12
to joomla-...@googlegroups.com
I am on it , just made set of overrides for default 
and now looking on overrides that don't include calls for bootstrap 


these are core defaults. I am not sure if I should change markup in NOBS files , but 
working on disabling it for now 

Youjoomla LLC

unread,
Dec 15, 2012, 3:16:33 PM12/15/12
to joomla-...@googlegroups.com
Worked fine for core , 
all calls for JHtml::_('bootstrap.tooltip'); in extensions are loading Bootsrtrap again so commenting those
and JHtml::_('bootstrap.framework') from template index , kills BS 
here is the list 
and here is source 


one I have small issue with is contacts but will find a solution

Nick Savov

unread,
Dec 15, 2012, 3:53:11 PM12/15/12
to joomla-...@googlegroups.com
Hi Cristina,

Great thoughts!

Key question, can those things be done in 3.1 without breaking
compatibility? If not, they'll have to wait until Joomla 4.0 if that's
the direction the community wants to go.

If they can be done without breaking compatibility, then let's go for it.
At that point, I would suggest opening up a new thread with your proposed
changes (since this one will be hard to find) and allow some time for
people to comment on it, then start coding.

The important thing to keep in mind, as Brian mentioned, is that everyone
had an opportunity determine the direction of Joomla 3 before it arrived.
Now that we're three months into Joomla 3, we have responsibility to
maintain backward compatibility for everyone that's on Joomla 3 and has
started developing for Joomla 3. We can't break things mid-way and every
effort will be made to make sure that 3.1 is backward compatible with 3.0.

In short, I look forward to the ideas that you come up with and I'd like
to help move things along so that everyone can get the best slice of cake
:)

Kind regards,
Nick

Gary Mort

unread,
Dec 15, 2012, 3:54:13 PM12/15/12
to joomla-...@googlegroups.com, youjoo...@gmail.com


On Saturday, December 15, 2012 2:18:01 PM UTC-5, Youjoomla LLC wrote:
Silviu is poking on code to disable it from template index.php which will be a hack but it will help Alex at this point , 
so far I see all we need is to remove JHtml::_('bootstrap.framework'); from core extensions and let templates take over , 


For template wide disablement of bootstrap, simple add 2 files to your template:
bootstrap.js
bootstrap.min.js
These should be empty files[unless there is some element of bootstrap that you wish to use without using all of it.  

Place those 2 files in the js/jui directory.  For example, I copied the protostar template and renamed it gmortstar.  I then created those 2 files and made gmortstar my default template.  Bootstrap will still be "loaded" - but it is the template's bootstrap javascript that takes priority[just like with html overrides].

Similarly, if your developing a template for a specific website, and you know everything your using is Bootstrap 2.2 compatible, you can place the latest Bootstrap libraries there and have them loaded instead.  [Everything seems to work when I do it].  Note you will need to build these files via concatinating the individual files into 1 big file.

Lastly, you CAN over-ride Bootstrap from a plugin but then it gets very very.....interesting.  I'm not sure if I pushed my raptor repository up to github yet or not.  Raptor is an HTML5 editor that uses jquery-ui  In case not, here is my gist for 'overriding' a bootstrap function:  By the same token, you could enable the bootstrap framework, and then load your own custom bootstrap javascript file to disable/delete all those functions.

There is a known conflict between jquery-ui-button and bootstrap button.  They both use the same function name, Button to dynamically create buttons[note DYNAMICALLY.. ie they look for divs on the page with specific classes, and add a span inside those divs with the button class to display a toolbar button...  As near as I can tell, MOST Joomla code generates these buttons through JHtml so they don't need the function.]

What I did was quite simple:
1) Make sure the browser loads bootstrap.js first.   This means that on page load, when Bootstrap is loaded it will create a function called Button.
2) Load jquery-ui-button AFTER bootstrap.js.  In this manner, when the ui-button script is loaded, it will define it's own Button function, deleting the previous Button function.
3) Lastly, I created a special javascript file which merely contains the Bootstrap.js button definition WITH A NEW NAME.  This is loaded last.    

The result is a page that now has 2 functions:
Button:  jquery-ui-button
CraftyBootstrapButton: Bootstrap's button

In addition, I've included Bootstrap's domReady event so after the page is ready, CraftyBootstrapButton will be applied to all the classes.

This means that:
1) Anything using jquery-ui-button will work properly. This is important for Raptor because it subclasses the Button function for all it's editor buttons and creates those buttons dynamically by parsing json encoded config data. IE: if the "Bold" plugin is loaded, and the "Bold" plugin is enabled, then when you enable your textarea field to edit it will create the toolbar with the Bold button/

2) Anything using Bootstrap's button CSS styles work out of the box.

3) Anything using Bootstrap's button initializing CSS styles work out of the box because CraftyBootstrapButton will enable them.

4) Any OTHER Javascript which tries to call the Bootstrap Button function EXTERNALLY*1 will instead call the the jquery-ui-button function. 
See http://docs.joomla.org/Javascript_Frameworks and please expand it for more details.


*1: By externally I mean a function call to "Button() which is used to attach a button object to a dom element.  If you call $('#mybutton').button.someFunction THAT will work.  Thats because your not calling the Button function, your calling the Button object attached to #mybutton[which makes my head spin]


Youjoomla LLC

unread,
Dec 15, 2012, 3:58:46 PM12/15/12
to joomla-...@googlegroups.com
@Garry , did not test your approach but if placing empty files will override the call of BS defaults JS , seems that we will end up calling empty files in 
head for no reason. 
Am I wrong here? 

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/00M4apzVb_QJ.

To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

Nick Savov

unread,
Dec 15, 2012, 3:59:34 PM12/15/12
to joomla-...@googlegroups.com
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-cms/-/eQNbf1VPZ9QJ.

Gary Mort

unread,
Dec 15, 2012, 4:50:06 PM12/15/12
to joomla-...@googlegroups.com, youjoo...@gmail.com


On Saturday, December 15, 2012 3:58:46 PM UTC-5, Youjoomla LLC wrote:
@Garry , did not test your approach but if placing empty files will override the call of BS defaults JS , seems that we will end up calling empty files in 
head for no reason. 
Am I wrong here? 

The reason is to disable Bootstrap for a specific template.   Or to upgrade it to the latest version.  Or to change small functionality of code.

Think of it this way - on an existing website, there is a module which displays the latest stock price for 3 site defined stocks.   This is a 3rd party module from Company A.   For your website, you want to give users the option to not view that module and you don't want to pay Company A to add functionality just for your website.

You add a profile field using the handy Joomla Profile plugin to allow users to disable the module.

Then in your template, you copy the module layout file, delete the existing code, add some code to the top of the layout to check the user's profile and return if the user disabled it[display "blank" data], and then add some code to load the module layout file.

That is one of the powers Joomla! gives you - you have the ability CHANGE what a module or component displays to a user WITHOUT changing the module code.  So if Company A releases a new version, you can upgrade your module and get the new functionality without having to re-do all your changes.

That same power is extended to CSS and Javascript.   You can add your own javascript file which overrides OR AUGMENTS the default file.

Disabling/replacing the default JS, CSS, or Layout is the trivial use case.  More power is that you can augment the original by loading your own code, followed by inserting the original.

Which is easier/better: adding an html override for every file which asks Joomla to include bootstrap.js on the page - or adding ONE file which is blank and gets used in place of bootstrap.js so not only is it disabled for now - any future modules installed cannot change this behavior?


Youjoomla LLC

unread,
Dec 15, 2012, 4:58:34 PM12/15/12
to joomla-...@googlegroups.com
Garry , I understand how overrides work but again , makes no sense to  me to load an empty js file if that 
is what your suggestion does. Instead we need to disable the call to bootstrap from core extensions
 completely and call it from template 
not from extensions.  And with 

if(JFactory::getApplication()->input->get('cmd') =='com_contact'){
   JHtml::_('bootstrap.framework');
}


or 


if(JFactory::getApplication()->input->get('cmd') !='com_contact'){
   JHtml::_('bootstrap.framework');
}
you can restrict what extension will load it and all this can be done from template index.php



--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/gJmxBNF_SKQJ.

To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

Youjoomla LLC

unread,
Dec 15, 2012, 5:00:24 PM12/15/12
to joomla-...@googlegroups.com
Correction 


if(JFactory::getApplication()->input->get('option') =='com_contact'){
   JHtml::_('bootstrap.framework');
}


or 


if(JFactory::getApplication()->input->get('option') !='com_contact'){
   JHtml::_('bootstrap.framework');
}

On Sat, Dec 15, 2012 at 4:58 PM, Youjoomla LLC <youjoo...@gmail.com> wrote:
if(JFactory::getApplication()->input->get('cmd') =='com_contact'){
   JHtml::_('bootstrap.framework');
}


or 


if(JFactory::getApplication()->input->get('cmd') !='com_contact'){
   JHtml::_('bootstrap.framework');
}



Youjoomla LLC

unread,
Dec 15, 2012, 5:35:18 PM12/15/12
to joomla-...@googlegroups.com
Alex here are overrides if you need them

Gary Mort

unread,
Dec 15, 2012, 10:32:39 PM12/15/12
to joomla-...@googlegroups.com, youjoo...@gmail.com


On Saturday, December 15, 2012 4:58:34 PM UTC-5, Youjoomla LLC wrote:
Garry , I understand how overrides work but again , makes no sense to  me to load an empty js file if that 
is what your suggestion does. Instead we need to disable the call to bootstrap from core extensions
 completely and call it from template 
not from extensions. 

Hmm, while I have no problem with someone doing that, I feel loading an empty file is the appropriate path if you want to really disable it.

Doing it this way will work until such time as a new extension is installed which enables bootstrap.  Once that happens your stuck tracking down where it makes that call and using an override if possible.

Ideally the behavior mechanism would be a bit smarter so that when an extension calls  JHtml::_('bootstrap.framework'); the method would return either true or false.  True meaning "ok, it's enabled and you can count on it" - while false would provide some mechanism for Joomla to check to see if that framework/behaviour is disabled - and of course some way for plugins, templates, etc to disable a framework.  Something like:
JFactory::getApplication()->disableHtml('bootstrap.framework')

But that sort of feature is best left til the next version of Joomla.

Certainly it is best if at least the Joomla Components themselves don't go around forcing the loading of the framework if it is not needed - and moving the current calls outside the components is great.  I just would not depend on it.


 

Kyle Ledbetter

unread,
Dec 15, 2012, 10:49:17 PM12/15/12
to joomla-...@googlegroups.com
I respect many of the opinions here but I think you all are judging a solution that hasn't been fully realized yet. The fact is, with all the different frontend component UI out there, you need an extremely versatile, extensive, flexible and widely adopted UI framework to keep it all sane. That's what you get with Bootstrap, which is still by far the most popular choice out there.

The fact is, almost all component devs agree that 3.0 development is easier. Just look at the adoption of 3.0 and the speed at which components are updating. We're talking weeks and months instead of years like Joomla 1.0 -> 1.5.

Also, once all the new versions of the popular components are out (very soon) such as K2, Jomsocial, Kunena, etc, I think you will all see the light and be singing praises of Bootstrap in Joomla 3.0 frontend layouts.

Once you template devs get to experience all the popular components popping right into your template and automatically taking on your template styles with little to no work, you'll be thanking the JUX team and if you have clients, they'll be thanking you.

If we didn't use Bootstrap in the core frontend views, component devs wouldn't have adopted them as they are. It's how Joomla has always worked as a community. If you don't like the core markup, just create HTML overrides in your template instead of complaining about them being in the core.

Also, if you don't want to use Bootstrap, then don't. Your template has the power and option to use LESS, jQuery, Bootstrap, etc. Just don't include it if you don't want it. That's why I put in the template. To give you the choice. If you don't load Bootstrap all you're left with is standard markup and classes across the core and all components, which is a much better place thank Joomla as ever been before.

Also, I think you're all forgetting the value of free and automatic responsive layouts in the frontend. This is a huge attraction for the common end user considering Joomla.

I live in all areas of Joomla from template designer to component developer to completely custom implementations from the ground up and every day my life if 1000x easier because of Bootstrap being in Joomla.

That all being said I really do wish there was a way to easily swap out entire UI frameworks so you could easily change from Bootstrap to Foundation to jQuery Mobile, etc, but honestly the core of the Joomla cms as we know it can't handle it. You really need a modern framework that completely abstracts the layouts with something like Angular js, Node js, etc, but that will be the future of Joomla and the platform, and not the current cms which is basically an advanced version of Mambo...

3.0's paint is still very wet. Semantics, accessibility and standards are already improving thanks to some of the great people in this thread. Wait to pass final judgement until all the popular components release truly native 3.x versions and then you're free to complain :)

Youjoomla LLC

unread,
Dec 15, 2012, 11:41:38 PM12/15/12
to joomla-...@googlegroups.com
Kyle , no one says we don't want it , we "all" do want it , but we need option to disable it on demand and not being "forced' to use it . That is all 
and that is what Alex is asking for. I have it in my framework just like others do but components should not control if it is loaded. Template should do that 
or at least template should be able to disable it. 

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/DG9Nfi1joaUJ.

To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

Kyle Ledbetter

unread,
Dec 15, 2012, 11:53:44 PM12/15/12
to joomla-...@googlegroups.com, youjoo...@gmail.com
Gotcha thanks for clarifying. Still, templates aren't forced to use it, it's all optional to include in your template

Dragan Todorovic

unread,
Dec 15, 2012, 11:55:49 PM12/15/12
to joomla-...@googlegroups.com
No templates are not but here an example. Don't load it in template but load breadcrumbs module and since there is call for bootstrap.tooltip the bootstrap gets loaded. That is the issue Alex is running in to 


Best Regards
Dan Casky
Youjoomla Customer Service
5044 17th street N
Saint Petersburg ,FL
33714
-------------------------------
Youjoomla LLC
Professional Joomla Web Design Services
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/-BoH94iJrlcJ.

Michael Babker

unread,
Dec 16, 2012, 12:02:21 AM12/16/12
to joomla-...@googlegroups.com
You're right, but since the call to Bootstrap is in the layout file for the module, you can do a layout override to exclude it.  Yes, it's extra work, but IMO, the loading of Bootstrap is handled in the proper place so that it can be overridden if desired.

From: Dragan Todorovic <nocni...@gmail.com>
Reply-To: <joomla-...@googlegroups.com>
Date: Saturday, December 15, 2012 10:55 PM
To: "joomla-...@googlegroups.com" <joomla-...@googlegroups.com>
Subject: Re: [jcms] Re: Completely disable Bootstrap

Dragan Todorovic

unread,
Dec 16, 2012, 12:05:33 AM12/16/12
to joomla-...@googlegroups.com
Than we should simplify it somehow. What I noticed when calling behavior.framework is if u don't use true it wont load mootools-more.js 
so having something like  false when calling bootstrap to disable it could do the trick. 


Best Regards
Dan Casky
Youjoomla Customer Service
5044 17th street N
Saint Petersburg ,FL
33714
-------------------------------
Youjoomla LLC
Professional Joomla Web Design Services

Cristina Solana

unread,
Dec 16, 2012, 12:11:00 AM12/16/12
to joomla-...@googlegroups.com
Nick,

I think it would have to be a 4.0 project unless someone else has ideas about how to maintain backwards compatibility and make the move. In my mind it would certainly break backwards compatibility for anyone using Protostar and possibly others who've created a custom template using the classes in the core views.

Kyle,

I hope you don't think I am suggesting that we should get rid of Bootstrap. I'm not, I am merely suggesting it belongs in a different layer of the CMS. Admittedly, I haven't read all of the posts here so just want to make sure you aren't referring to my comments. :)

What would be the downside of moving Bootstrap classes (also js/css refs) from the core views and making it the default Joomla template via template overrides?

Cheers,

Cristina

Michael Babker

unread,
Dec 16, 2012, 12:12:21 AM12/16/12
to joomla-...@googlegroups.com
I'm always iffy to put something like that into the API.  I see folks then arguing that one place calls to enable Bootstrap and another wants to disable it.  Who wins in those cases?  To me, that's something kinda advanced that should really be left to the template if they truly want to prevent Bootstrap from being used at all.  Or a plugin like what Roberto has released to control when MooTools is loaded.  It's an explicit decision made by the user in that instance, not forced on us (which is what this discussion started about, having something forced on us).

FWIW, the behavior.framework method will always load mootools-core.js, regardless of what other params you pass to it.

Dragan Todorovic

unread,
Dec 16, 2012, 12:13:51 AM12/16/12
to joomla-...@googlegroups.com
I said mootools More not core. 


Best Regards
Dan Casky
Youjoomla Customer Service
5044 17th street N
Saint Petersburg ,FL
33714
-------------------------------
Youjoomla LLC
Professional Joomla Web Design Services

Dragan Todorovic

unread,
Dec 16, 2012, 12:17:18 AM12/16/12
to joomla-...@googlegroups.com
Than we cant advertise it like "if you don't want it in template it wont be loaded ".  We should say it is alway there and some extensions will force load it  even if you don't want it. 


Best Regards
Dan Casky
Youjoomla Customer Service
5044 17th street N
Saint Petersburg ,FL
33714
-------------------------------
Youjoomla LLC
Professional Joomla Web Design Services

Dragan Todorovic

unread,
Dec 16, 2012, 12:23:06 AM12/16/12
to joomla-...@googlegroups.com
" Who wins in those cases?"
I say admin which in this case is Alex and he cant do what he wants
without workarounds / hacks / plugins etc...

Best Regards
Dan Casky
Youjoomla Customer Service
+1727-388-6653
5044 17th street N
Saint Petersburg ,FL
33714
-------------------------------
Youjoomla LLC
www.youjoomla.com
Professional Joomla Web Design Services

Michael Babker

unread,
Dec 16, 2012, 12:24:11 AM12/16/12
to joomla-...@googlegroups.com
You can't control what extension devs do.  If they're playing well with others, they're loading Bootstrap in their layouts like the core does as present and those layouts will be overridable.  If you truly do not want Bootstrap in your template, there's ways to do it.  Takes some work, more than necessary at times, but it can be done.  How many folks have come up with methods to exclude MooTools over the years?  Those same methods can go towards the Bootstrap media.

Michael Babker

unread,
Dec 16, 2012, 12:27:35 AM12/16/12
to joomla-...@googlegroups.com
How's the API to know who's the admin?

I haven't worked with these types of situations, so all I know is what
I've heard from various template and extension developers about what
they've done to control what media is loaded on their sites. The joy of
Joomla is you have the ability to do that, unfortunately that solution
isn't always a clean one.

On 12/15/12 11:23 PM, "Dragan Todorovic" <nocni...@gmail.com> wrote:

>" Who wins in those cases?"
>I say admin which in this case is Alex and he cant do what he wants
>without workarounds / hacks / plugins etc...
>
>Best Regards
>Dan Casky
>Youjoomla Customer Service
>+1727-388-6653
>5044 17th street N
>Saint Petersburg ,FL
>33714
>-------------------------------
>Youjoomla LLC
>www.youjoomla.com
>Professional Joomla Web Design Services
>
>On Dec 16, 2012, at 12:12 AM, Michael Babker <michael...@gmail.com>
>wrote:
>
>> Who wins in those cases?
>

Dragan Todorovic

unread,
Dec 16, 2012, 12:29:47 AM12/16/12
to joomla-...@googlegroups.com
That is the point Michael. Why do we need so many workarounds for something so simple? For disabling call for one  mootools file we have to make plugins or hacks or whatever. Guy wants 3 lines from his head tag gone and he must jump trough hoops to do that.


Best Regards
Dan Casky
Youjoomla Customer Service
5044 17th street N
Saint Petersburg ,FL
33714
-------------------------------
Youjoomla LLC
Professional Joomla Web Design Services

Michael Babker

unread,
Dec 16, 2012, 12:40:58 AM12/16/12
to joomla-...@googlegroups.com
The concept in the API is that if it is wanted by someone, it is explicitly enabled.  We don't have APIs to disable the media after they're enabled, IMO for good reason; unpredictable results.  In a way, that's why I prefer these hacks over an API method because it's a deliberate and controlled decision.  It's dangerous to put calls into the API to disable media after it's been enabled by someone else.  For example, if I use the Bootstrap carousel in an extension and you have an extension that disables Bootstrap JS because it conflicts with the jQuery UI library you're using, now I get messages saying my extension isn't working for reasons I can't reproduce working in a clean environment (clean being core code plus my extension(s)).

That is an API endpoint that has high potential for abuse if included in the core.  Like I said before, who wins when calling an endpoint to disable media after it's been enabled?  A developer should be reasonably sure that once they've explicitly enabled something, it is present for their use.  With such an endpoint, developers would have to work around conditions where the media isn't enabled, and the API wouldn't function as advertised.  Hard to advertise an API as "when called, this media is enabled, unless someone else disables it somewhere, but you have no idea if that's going to happen, so be prepared to get complaints your extension doesn't work because you're expecting media you've loaded to be present".

The media is all loaded in core layouts.  The cleanest solution as a template dev is to override every layout.  I get that it adds overhead to your package and workload to your team, but until core changes to never load Bootstrap (or any other media library) itself, this is one of the better solutions that doesn't involve hacks.

Dragan Todorovic

unread,
Dec 16, 2012, 12:46:16 AM12/16/12
to joomla-...@googlegroups.com
Why are you taking about my team and my work? This post has nothing to do with me
Alex asked question, I made 2 sets of template overrides for him and everyone else and trying to help 
a guy that is asking  us for support. None of this has anything to do with me , my team or our templates and framework. Please read all post before jumping to conclusion. 


Best Regards
Dan Casky
Youjoomla Customer Service
5044 17th street N
Saint Petersburg ,FL
33714
-------------------------------
Youjoomla LLC
Professional Joomla Web Design Services

Michael Babker

unread,
Dec 16, 2012, 12:48:33 AM12/16/12
to joomla-...@googlegroups.com
It wasn't intended to be jumping to a conclusion, but more of a generalized statement towards all developers.  Apologies if it wasn't conveyed in that way.

Dragan Todorovic

unread,
Dec 16, 2012, 12:52:14 AM12/16/12
to joomla-...@googlegroups.com
My bad 1am.  Any way overrides are the way to go for now but there should be
better solutions. 


Best Regards
Dan Casky
Youjoomla Customer Service
5044 17th street N
Saint Petersburg ,FL
33714
-------------------------------
Youjoomla LLC
Professional Joomla Web Design Services

Bakual

unread,
Dec 16, 2012, 4:07:13 AM12/16/12
to joomla-...@googlegroups.com, youjoo...@gmail.com
If your templates uses any javascript itself, you could of course put that into your own bootstrap.js, which would make it not empty :)
Of course you would be forced to use this filename for your javascript code. But that shouldn't be such a big problem.

Bakual

unread,
Dec 16, 2012, 4:16:25 AM12/16/12
to joomla-...@googlegroups.com, youjoo...@gmail.com
My issue with making bootstrap optional is what will happen to 3rd party extensions.
I'm sure you will make a very nice template where all core extensions work, with fancy overrides for all kind of output. But what happens to 3rd party extensions that will not have your overrides available? Will you make sure Bootstrap is enabled for this extensions where you don't provide overrides and will they fit into your template as well?
 
Maybe I'm a bit hypersensitive but I have this kind of issues when I'm supporting my extensions. Because the most fancy templates (like those from RocketTheme) tend to break the output from my extension. It works for their overrides of the core extensions, but looks horribly for most 3rd party extensions.

Am Samstag, 15. Dezember 2012 20:00:17 UTC+1 schrieb Youjoomla LLC:
You don't understand my point Bakula , 
With 1 line in index.php  you can call Bootstrap which will be present in any component.
This way you can control if Bootstrap is present or not and that is what Alex is asking for.


On Sat, Dec 15, 2012 at 1:55 PM, Bakual <werbe...@bakual.ch> wrote:
If you don't use Bootstrap in core extensions and only leave that to template overrides, then there is no reason to include Bootstrap at all into Joomla. You can do this already with Joomla 2.5 if you want.
The main improvement is that 3rd party developers can count on that Bootstrap is available and don't have to produce own markups and CSS files for everything. That is a very huge improvement for everyone, extension developer, designers and users.
Your templates will miss an important feature of Joomla 3.x if you exlude Bootstrap. Just saying. They will be only usefull if the user only uses core extensions, which are porobably only a few users.

Am Samstag, 15. Dezember 2012 19:03:35 UTC+1 schrieb Youjoomla LLC:
Kyle did an awesome Job , but all overrides of the frontend core components to accommodate Bootrstrap ,
should have been done in template overrides and not in extensions itself. 
@Alex , Silviu 
 is poking in 3.0 to disable BS completely. Will let you know. 


On Sat, Dec 15, 2012 at 12:50 PM, elin <elin....@gmail.com> wrote:
I had my reservations about Bootstrap but one reason I came around was that Kyle convinced me we as individuals or as a project can be contributors to improving the quality of the markup they produce both in terms of web standards and accessibility, and we have already been able to do that.  He also pointed out that if they stop being responsive to those improvements or if they basically die as a project (always possible) we could simply fork and continue down a positive road on our own.

Many of the problems of the core markup in 3 are not due to Bootstrap they are due to the incorrect implementation in the layouts.  We had beautiful outputs in 1.6+ and now have regressed somewhat but thanks to Angie and others we are on the road to moving back in the right direction on that. So my suggestion would be to continue working on improving those steadily while not breaking sites.

In terms of disabling, it's something a webmaster should be able to do as should som ne designing a 100% custom installation but it is not something that developers of plug and play extensions should do if they want to have a decent reputation with end users and the same goes for retail templaters if they want to make money over the long term.   

Elin


On Saturday, December 15, 2012 5:08:27 AM UTC-5, Daniel Dimitrov wrote:
Hey @everyone,
I'm a little late to the discussion, but I thought that I should add my 2 cents anyway.
There is a big gap between theory and practice. In theory I love the the ideas in "Designing with web standards" - in practice - no thanks (just have a look at the discussions for the above mentioned article http://ruby.bvision.com/blog/please-stop-embedding-bootstrap-classes-in-your-html )...
The biggest problem that we developers had until version 3 was how to write our html and css & make it look nice on dark, white, yellow and whatever designs... Some templates use head, other use header, another are going for my-monster-header classes. Maybe the markup of bootstrap is not semantically correct (<i> tag anyone????), but it solves our biggest problem - we can write code and be sure that the designer can do whatever he sees fit.
Having those common classes - as bad as they are named is a HUUUUGE improvement. We as developers now know what classes we can use, what elements we can use and this way we basically outsource the design to the designers...
If you try to implement bootstrap with LESS then what markup should I use? We are again going to a situation where I have no idea if you've styled a H2 as a H2 and not as a <p>...
Cheers,
Daniel



On Wednesday, December 12, 2012 7:02:36 PM UTC+1, Alex Crawford wrote:
I am creating a template from scratch. I am using Foundation Zurb as it is much better than Bootstrap. I've removed any trace of JHtml::_('bootstrap.etc); from my template's index.php, and only have in place JHtml::_('jquery.framework', false);.

* The problem: This is still showing up in my <head>...
<script src="/media/jui/js/bootstrap.min.js" type="text/javascript"></script>

I see many components load bootstrap or a piece of bootstrap, such as JHtml::_('bootstrap.tooltip');

I tried creating a plugin which onAfterRender() { would parse $doc->getHeadData();. However, Bootstrap DOES NOT appear. Somehow, Bootstrap is being added AFTER onAfterRender() {...

Please, I need any suggestion or workaround to prevent bootstrap from loading at all.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/3J5cOY0LnwQJ.

To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.



--
Best Regards
Dan Casky
Youjoomla Customer Service
+1727-388-6653
5044 17th street N
Saint Petersburg ,FL
33714
-------------------------------
Youjoomla LLC
www.youjoomla.com
Professional Joomla Web Design Services

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/0rt6SPzRg1IJ.

To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

Dragan Todorovic

unread,
Dec 16, 2012, 4:22:56 AM12/16/12
to joomla-...@googlegroups.com
This should be a simple option available to anyone who wants it disabled. And if someone like Alex wants that he also understands that he is disabling it for all extensions on his install. And bootstrap disabled wont kill your extension it will only look different and than again Alex can decide how he wants it to look like. Don't get to excited. I have over 70 extensions that are getting bootstrap style but what is right is give admin the power and not us 3rd party devs.  


Best Regards
Dan Casky
Youjoomla Customer Service
5044 17th street N
Saint Petersburg ,FL
33714
-------------------------------
Youjoomla LLC
Professional Joomla Web Design Services
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/poDT1lYaUg0J.

Seth Warburton

unread,
Dec 16, 2012, 6:39:56 AM12/16/12
to joomla-...@googlegroups.com
Hi Kyle, 

Thanks for responding, it is very much appreciated. While there has been a lot of responses to this thread, I'm not certain we are all talking about the same things and there are clearly some on this thread (not you) who have misunderstood my point totally. 

I'm really glad that this discussion is provoking such a great response though. It shows that people do care about these things and that we all care about the future of Joomla! I want Joomla to become the best CMS on the block, smarter, faster and more flexible than the competition. That will only happen if we examine potential issues and work together to eradicate them. I know we can do this because Joomla! Rocks!

In that spirit I'd like to respond to some of your comments. In fact, there's really one that is the crux of all of these issues: 

On Sunday, 16 December 2012 03:49:17 UTC, Kyle Ledbetter wrote:
...


Also, if you don't want to use Bootstrap, then don't. Your template has the power and option to use LESS, jQuery, Bootstrap, etc. Just don't include it if you don't want it. That's why I put in the template. To give you the choice. If you don't load Bootstrap all you're left with is standard markup and classes across the core and all components, which is a much better place thank Joomla as ever been before.


If this were true, you would not hear another word from me. The template has these options as you say, but the core does not. If I do not choose to load Bootstrap assets (which for a variety of reasons I don't) in my template I'm left with the following issues in my front-end output:

  1. Non-standard mark-up (Bootstrap uses standardised mark-up, not standard mark-up and there is a very large difference). Core components are outputting mark-up that does not meet standards specified by the W3C. I'm talking about the html specifications, both existing and draft (html5).
  2. Boostrap classes in mark-up - While there are many classes that could arguably be called standard (and semantically are fine) there is no choice available as to how and when these are implemented. The choice has been removed and I think that any such removal of freedom of choice is detrimental to end users. Such classes can, and should, be implemented via the template only.
  3. Broken and missing functionality. There are many instances where standard Joomla component functionality is horribly broken without Bootstrap assets loaded. For me this is totally unacceptable.
  4. Numerous components forcibly loading Bootstrap assets (despite both template designer and administrator choosing against this. 
Bootstrap is all presentational layer stuff and that is where it should be implemented. I have numerous issues with the code quality and implementation methods employed in Bootstrap, but these would all just be personal issues (and easily remedied) if these deep core integrations did not exist. It would, and it should, simply be a matter of informed choice in behalf of either template designer, component developer or end user. I'm arguing for choice. 

Other developers may not care about the quality of their code, web-standards or accessibility issues but those who do should be able to make such choices without either crippling Joomla or re-writing views for every single component and module (even that isn't enough to fix all of these issues as not every output has a view). 

I'll provide some examples, in another post, that I hope will clearly illustrate the issues noted above. I don't want this to become a 4000 word post though....


Seth
 

Seth Warburton

unread,
Dec 16, 2012, 6:44:23 AM12/16/12
to joomla-...@googlegroups.com
Thanks Cristina, 

This would be the perfect solution IMO. Freedom of choice is restored and nothing is lost for those whose choice is Bootstrap.

I too do not suggest that Joomla drop Bootstrap, but I do suggest that Joomla does not become Bootstrap.


Seth

On Sunday, 16 December 2012 05:11:00 UTC, Cristina Solana wrote:
...

Seth Warburton

unread,
Dec 16, 2012, 6:59:24 AM12/16/12
to joomla-...@googlegroups.com
Hey Daniel, 

With all due respect that is entirely how it should be, the appearance should be decided entirely by the css and most probably by a designer. Your markup should only ever reflect its actual purpose, not how you think it should look. This is the very basis of web standards.

If you have a 2nd level heading use <h2> if you have a paragraph use <p>, it will always be correct. You shouldn't have any idea how an end user, or template designer, would choose to style your h2, how could you?

Please note, I'm also not arguing against the use of common classes I would simply like to see them implemented in the correct manner placing styling into the presentation layer.

On Saturday, 15 December 2012 10:08:27 UTC, Daniel Dimitrov wrote:
...

Seth Warburton

unread,
Dec 16, 2012, 7:46:59 AM12/16/12
to joomla-...@googlegroups.com
I think it's easier to recognise some of these issues with concrete examples, so while each issue I describe below is by no means an isolated occurrence it will hopefully clarify some of the issues I previously mentioned:

1) Non-standard markup:

<i> is not a tag for icons. Never has been, never will be, and so clearly it's use to place icons is incorrect. Here's the current (HTML4.01) http://www.w3.org/TR/REC-html40/present/graphics.html#edef-I and draft (html5) http://www.w3.org/html/wg/drafts/html/master/text-level-semantics.html#the-i-element specifications definitions of the <i> element. Any mention of icons, or even anything that could reasonably be construed as such, is notably absent.

2)  Bootstrap classes in markup: 

While it can easily be argued that certain BS classes are both standard (beyond Bootstrap) and semantic, placing them within markup removes freedom of choice. Let's take as an example an article readmore: 

<a class="btn" href="/302default/index.php/park-blog/18-second-blog-post"> <i class="icon-chevron-right"></i> Read more: Second Blog Post</a>

There is nothing wrong with using .btn per se, but has anyone considered that I might not want a readmore styled as a button? Where are my choices?

I could write in my own css .btn {.. styles that remove all button styles ..} but this is patently ridiculous as it clearly makes no sense to have a class called .btn that makes things *not* look like buttons. It also kills all my button styles elsewhere, as it is very difficult to target only the readmore. Not good. 

I can implement the exact same button styles in a semantic and pro-choice manner by using:

<a class="readmore"> 

and in my LESS: 

.readmore {.btn}

Now my Bootstrap button style is applied to my readmore button, the class describes the function (semantic bonus points!), not the appearance and I am still using default Bootstrap styles. I can also choose to have my readmore not styled like a button without unwriting button styles. win=win=win.

3) Broken and missing functionality

mod_login. If I don't load Bootstrap JS there are no password remind / reset links. Nothing. This is extremely harmful to both accessibility, usability and user experience. Why does this happen? The assumption is that BS assets will *always* be present. As this assumption will not always be true, let's not hang critical functionality on it.


4) This shouldn't happen as core components should never require BS to function (as with mod_login). If they do, there isn't a choice of frameworks. Mod_login, for example, should function with or without bootstrap.js. As a user I can reasonably expect that I will no longer get BS icons or button styles, but I cannot reasonably expect that I will no longer be able to recover my password. 

If BS weren't required for critical core functionality then there is no need for all these components to try and load Bootstrap. It's either there or it isn't. Both core and 3rd-party components should be built to expect this and to respect a users choice in this matter. 

I think it quite acceptable for a 3rd party developer to say "You will need to have Bootstrap loading on the front-end to use our extension.", but I don't find it acceptable for core components to do that. 

Currently we are saying that you can choose, when you can't. If you don't want Bootstrap on your front-end your current choices are Joomla or not Joomla. Let's either resolve such issues or revise our marketing message.

Amy Stephen

unread,
Dec 16, 2012, 11:13:24 AM12/16/12
to joomla-...@googlegroups.com
Good ideas. Now, someone has to do the work. That's easy to get started. Someone needs to get a github repository, post the link, collaborate with others interested to advance what's in core. Looks like there is a good collection of frontend devs who definitely have the coding chops to do it.

Moving from 'article-info muted' to <article> would make a very big and important difference for Joomla. But, 99 posts do not code make. It's going to take some considerable effort -- people who really want to see it happen, not just talk about it, folks who will follow through to the bitter end, and who are also able to handle the criticism that follows. 

Consider yourselves triple-dog dared. Make it happen, folks.

Gary Mort

unread,
Dec 16, 2012, 11:58:17 AM12/16/12
to joomla-...@googlegroups.com


On Sunday, December 16, 2012 4:22:56 AM UTC-5, Dan YJ wrote:
This should be a simple option available to anyone who wants it disabled. And if someone like Alex wants that he also understands that he is disabling it for all extensions on his install. 

I'm failing to understand how adding 2 empty files to the template is not "simple".

I'll agree that it's ugly....as the proverb goes "Perfect is the enemy of the Good" http://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good

This is simple, easy, and works 100% of the time in a template.  I would not suggest it for a commercial template, but on a specific website, where you specifically want to disable bootstrap globally, this will work and you won't have the website owner calling you in 6 months because some new extension suddenly started enabling bootstrap.

I'm still all for making it a simpler/easier option with some way of configuring it - but that is something that is unlikely to be released in 3.0 and only will make it into 3.1 if those who want it code the feature and add a feature request for it.

Gary Mort

unread,
Dec 16, 2012, 12:40:05 PM12/16/12
to joomla-...@googlegroups.com


On Sunday, December 16, 2012 7:46:59 AM UTC-5, Seth Warburton wrote:
2)  Bootstrap classes in markup: 

While it can easily be argued that certain BS classes are both standard (beyond Bootstrap) and semantic, placing them within markup removes freedom of choice. Let's take as an example an article readmore: 

<a class="btn" href="/302default/index.php/park-blog/18-second-blog-post"> <i class="icon-chevron-right"></i> Read more: Second Blog Post</a>

There is nothing wrong with using .btn per se, but has anyone considered that I might not want a readmore styled as a button? Where are my choices?

I could write in my own css .btn {.. styles that remove all button styles ..} but this is patently ridiculous as it clearly makes no sense to have a class called .btn that makes things *not* look like buttons. It also kills all my button styles elsewhere, as it is very difficult to target only the readmore. Not good. 

I can implement the exact same button styles in a semantic and pro-choice manner by using:

<a class="readmore"> 


Joomla could also produce:
<a class="readmore btn"> 

This would be both backwards compatible with the current 3.0 so no breakage, and for version 3.5 a review of all classes should be made to decide what to keep.

For versions >= 3 and <= 3.5 no breakage should be made.  Ie if a css class is there now, it should remain there.  But I think going a little class happy and adding semantic information to the classes would be a big benefit.

2.5 and 3.5 are LTS, their the releases that should be the most stable and the most standards-compliant.

At least, since I've started using Ubuntu on the desktop that is how I'm viewing things.

Ubuntu ver 10.04 is a LTS and was very stable, very functional...and very boring.
Ubuntu ver 11.10 and 12.04 pre-release were unstable, very functional, added a lot of exciting new features....and included a lot of ill-conceived ideas.  The Unity Dash with the ability to add search dashlets and search numerous online references and your local computer instantly was great.   The inclusion of search dashlets which checked Canoical's online movies and music for sale was interesting.  The not including an end user friendly way to disable searching their online store was ill-conceived.

But those were not LTS, those were previews of where the feature set was going and a chance to change it.  12.04 when released was pretty good...had some warts but a giant leap forward from 10.04

12.10 continues the cycle of exciting and ill-conceived changes.  

I would really like to see the CMS follow the same pattern.  Use these non LTS releases to pile on and experiment with features.  Only keep the best ones in the LTS release.

It would also help if the features and CMS specific classes are marked.  Perhaps in addition to using  @deprecated in code, adding an @experimental tag to note features that are not complete.


4) This shouldn't happen as core components should never require BS to function (as with mod_login). If they do, there isn't a choice of frameworks. Mod_login, for example, should function with or without bootstrap.js. As a user I can reasonably expect that I will no longer get BS icons or button styles, but I cannot reasonably expect that I will no longer be able to recover my password. 



This issue has existed since Mambo.  Only the names have changed.
Joomla 1.0 required mootools for some components
Joomla 1.5 required mootools for some components
Joomla 1.7 required mootools for some components
Joomla 2.5 required mootools for some components
Joomla 3.0 has components which require mootools, bootstrap, jquery, and jquery-ui[not all in the same component]

At a glance, that seems like things are getting worse.  However, in 2.5 and below the mootools library used did not support namespace/no-conflict mode.  This is WHY there is a migration away from it.  Bootstrap and Jquery are the new format - where jQuery is being loaded in noConflict mode but Bootstrap is polluting the global namespace.

Ideally all these libraries should be optional and everything should work without them.  In practice, someone has to sit down and write the code for that.  Those programmers interested in getting rid of mootools aren't going to drop their goals to work on your needs for free.   However, since it is recognized that this is a problem - I believe that any patches submitted to remove dependencies on javascript libraries will not only be welcomed, but can be incorporated into the current 3.0 branch.   Any patches to add additional css classes to core component output should also be able to be applied in 3.0.  Any removal of existing css classes will likely not be accepted for 3.0 but could be added to 3.1.

So if your serious about wanting this, submit the patches.  In my experience it is very difficult to get "half" a patch accepted - so if you try to do everything in one feature request/patch it will likely languish.  Submit multiple requests and patches and they can be applied to the appropriate versions.

Youjoomla LLC

unread,
Dec 16, 2012, 12:53:54 PM12/16/12
to joomla-...@googlegroups.com

Joomla could also produce:
<a class="readmore btn"> 
That is exactly what I did in my framework. Simply added classes for bootstrap so that our templates are 
25/3.x with Bootstrap , with JBootstrap plugin or without compatible. 

@ Seth , Amy and others  who are for this , I already made the overrides for all core 3.0 extensions, 


do you suggest I go forward and remove the bootstrap markup from Pack2 and post this on GIT ? 


On Sun, Dec 16, 2012 at 12:40 PM, Gary Mort <jooml...@gary.mort.net> wrote:
Joomla could also produce:
<a class="readmore btn"> 



Youjoomla LLC

unread,
Dec 16, 2012, 1:00:14 PM12/16/12
to joomla-...@googlegroups.com
Or what I think is better , move Pack2 template override to Protostar and remove markup from extensions. 
Let me know.

Nick Savov

unread,
Dec 16, 2012, 2:39:48 PM12/16/12
to joomla-...@googlegroups.com
Hi Seth,

1) In practice, the icons issue is in my opinion a non-issue, because it
doesn't break anything if you're not using bootstrap, correct?
Furthermore, if you are using it, browsers render it correctly, so again
it's a non-issue.

Perhaps you have a better example?

2) The issue here appears to be one of what's used rather than an issue
with Bootstrap. If Boostrap wasn't used and it was left as .btn, you'd
still be faced with the same issue.

Please report this as a bug and add a patch for it that's backwards
compatible and also solves your issue. e.g. you could make the
class="readmore btn" or you could do something more creative with the
mixins. I'm not really sure, but just make it backwards compatible ;)

3) Please report this as a bug as well. I'm sure a backwards compatible
solution can be found.

4) See #3.

Hope this helps!

Kind regards,
Nick
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-cms/-/pAAVLM1Pnv4J.

Amy Stephen

unread,
Dec 16, 2012, 2:47:33 PM12/16/12
to joomla-...@googlegroups.com

I think it's understood, improvements can not remove this capability => http://kyleledbetter.com/jui/ nor can any changes impact existing templates. That's a given.

The essence of problem is that the presentation layer in Joomla is, and has been since 1.5, hard-wired into the application. That's a fact and that's what you are reacting too. Frankly, it's good to see more awareness.

It's important to accept that today, users have far better options than they did in 1.6+. That is an important step forward. Cannot over emphasize that. But, the same approach was used to build in the Bootstrap capabilities as were used to provide Mootools. To be clear, it is no worse today. (In fact, there are some minor improvements which help address flexibility.)

So, why was the same approach used?

If you guys really start digging in here, it'll become very obvious that it's no small task to build in good abstraction between the presentation layer and the application. In part, that's why we see the framework project taking hold. They are working on a more flexible architecture.

If you really want to do what the first post is asking, and that is offer choice in presentation layer options, then there is a great deal of work in front of you.

You'll have to figure out where all the places are that bootstrap is wired in and design an approach to make those connections using parameters, rather than hard-wired options. Or, build an API that interacts with an installed library -- more of the approach used to implement caching options, for example.

You'll have to look at how the Template is loaded, how JS and CSS are brought in, each of the JHTML elements, the helper files, and the layouts. An excellent first step would be to simply inventory of all the locations in the application that are impacted.

Then, estimate the size of the elephant and see if people are still around, committed to solving the problem.

Maybe you'll find people are most willing to address the semantic ids and classes. Provided you can find a way to do that while ensuring backwards compatibility, that might be as far as you go. Maybe it will be by offering a set of layouts that can be installed like an extension, that's an approach that was used in 1.5 when YouTheme offered layouts absent table markup. It wasn't ideal, but it helped.

Maybe there will be enough hands on deck to truly create an abstracted presentation layer. Again, as long as the current options continue to be offered and existing templates are not impacted, this would be a great goal.

I see this as largely an architectural problem that will only be completely solved with "Joomla Next" and I am encouraged to see a level of understanding as to the implications of poor separation. I totally agree with those of you calling for these changes, it's the right thing to do.

As people continue to dig at this issue, there will be a more and more appreciation the scope of this issue and understanding as to why things were done the way they were.  It's awesome to see frontend devs who passionately care about markup. My challenge was genuine. Get started with it, keeping in mind you can't reduce available features or blow away anyone's template. These are good goals.

Michael Babker

unread,
Dec 16, 2012, 2:53:13 PM12/16/12
to joomla-...@googlegroups.com
IMO, 1) is an issue. If the goal is proper use of the standard HTML
elements, then using the <i> tag for icons is clearly incorrect. Not
knowing the standards as well as Seth, I'd venture to guess that <span>
would probably be a better (if not the best/correct) choice.

2 thru 4 IMO are a result of this being a first cut of the Bootstrap use
and can and should be improved on, including making elements usable
without Bootstrap. So, indeed, these items should be patched.

FWIW, I'm not 100% on whether going to strong use of LESS is a point we're
at right now. I still explain often how the CSS files are compiled using
LESS (i.e. The various imports); I'm not quite sure how well the use of
mixins would be taken as that would be another difficult one to really
explain. I personally think they're pretty cool and would love to make
more use of mixins and LESS as a whole, but we have to remember that all
of our contributors don't necessarily know what any of this is.

Bakual

unread,
Dec 16, 2012, 2:53:42 PM12/16/12
to joomla-...@googlegroups.com
Actually I don't care about 1. Rules are there to break them. The <i> tag doesn't break anything if not supported, it just doesn't show.

I see the point in 2. Adding a second class "readme" would be the fix for me. It can be done with template overrides already but it doesn't hurt if it's placed in the core. But leave the "btn" class there.

Point 3 is a typical scenario for a template override in my opinion. You choose to not use Bootstrap, then you build your own functionality for your users. The choice is yours, it's not taken away. It doesn't even necessary need to be an override, you could even build your own module which replaces the default one.

Point 4 is there since Joomla has a JS library included. The same would apply to mootools or JQuery. The libraries are there and meant to be used. You're free to use overrides here as well.

But that's just my opinion of course. I just really don't see the big problem here. I see more problems raising if a template could disable things, an extension told to load. A tooltip function is not a design question, it's something the extension developer wants to have as part of his working extension. It may even be an important thing. How this tooltip will look in the end, this is a design question the template is responsible for. An icon also is not a design question, the icon may be important for a working extension. How this icon looks exactly, this is something the template decides. The "if" is given by the extension, the "how" is decided by the template. So disabling Bootstrap (or any other library) by the template should only be allowed if an alternative is provided, namely a template override. And this is already possible as far as I see it.

Seth Warburton

unread,
Dec 16, 2012, 3:13:47 PM12/16/12
to joomla-...@googlegroups.com
No one said it wasn't simple. It is ugly and it is a hack. I don't so ugly hacks, I want to see Joomla improved.

Youjoomla LLC

unread,
Dec 16, 2012, 3:17:24 PM12/16/12
to joomla-...@googlegroups.com
What I suggest is this;
Move extra markups just as they are right now to template overrides , 
Remove them from core extensions 
Give joomla users/devs overrides that are same as current extensions views ( which as I just tested does not break anything)
Remove calls for bootstrap.tooltips and bootstrap from core extensions , and leave them in overrides 

This way , not 1 line of core needs to be redone , custom markup is moved where it should be and that is overrides
you don't need to hack your way trough if you want something gone ( just use the overrides ) 
core extensions stay clean of extra markup.

3rd party devs can do what they like with their markup , if admin wants to remove bootstrap from 3rd party extensions 
he should do so in template overrides. 


--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/RkGo7aRihRMJ.

To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

Nick Savov

unread,
Dec 16, 2012, 3:17:46 PM12/16/12
to joomla-...@googlegroups.com
Hi Gary,

First, I don't believe we've spoken before, but I've read a lot of your
posts in the mailing-lists and enjoy reading your writing. Keep up the
good work! :)

You wrote ">=3 and <=3.5" but it sounds like you were explaining ">=3 and
<3.5" (note the difference between the equal sign before the 3.5).

There should actually be no non-backward compatible changes until 4.0. So
people that start on 3.0 should have a smooth experience until 4.0, at
which point in 4.0 they will likely encounter non-backward compatible
changes. This is seen within Joomla's development strategy in the "Strong
Backward Compatibility Support" section:
http://developer.joomla.org/strategy.html#backwardcompatibility

This is also in keeping with semantic versing:
http://semver.org/

3.0, 3.1, and 3.2 are not developer releases and they are not for
experimentation. They are stable releases and new sites should be
encouraged to build on them. As such, we should treat 3.0, 3.1, 3.2, and
3.5 with fragility.

As to Ubuntu, I don't know that much about it, but I know that their LTS
is supported for 5 years. Our LTS is only supported for about 2 years.
Thus, our LTS can't be the only version that's non-experimental. It's far
too short of a time period and Joomla would become known for being
"unstable".

If we save non-backwards compatible changes until major versions, then
we're providing about for years of support with no backward breaks. So
someone that starts in 3.0 can expect their site to work until 3.5 is EOL
around June of 2016. That person would just one-click upgrade to 3.5 with
no issues. At 3.1, that person would get new features that would be
backward compatible, as would he/she at 3.2, as would he/she at 3.5. It's
only at 4.0 that non-backward compatible changes would occur.

Hope this helps!

Kind regards,
Nick

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-cms/-/8sEmxNHYEh0J.

Youjoomla LLC

unread,
Dec 16, 2012, 3:19:47 PM12/16/12
to joomla-...@googlegroups.com
, not 1 line of core needs to be redone
talking about core bootstrap framework methods 

On Sun, Dec 16, 2012 at 3:17 PM, Youjoomla LLC <youjoo...@gmail.com> wrote:
, not 1 line of core needs to be redone



Youjoomla LLC

unread,
Dec 16, 2012, 3:24:43 PM12/16/12
to joomla-...@googlegroups.com
+1

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/rqmu5HWe6QMJ.

To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

Seth Warburton

unread,
Dec 16, 2012, 3:28:52 PM12/16/12
to joomla-...@googlegroups.com
Thanks Michael, 

You clearly understand that there are issues here and you are open to exploring fixes for those issues. Thank you. 

span, while not ideal would not actually be incorrect as <i> is, so it would be a huge step forward. 2 - 4; this is exactly why I mention these issues. There's room for improvement here and these are some of the areas in which I feel improvement is required. I propose such changes more for the benefit of the project than for myself. I already have overrides for the core outputs I make use of and I'm already building lightweight, semantic templates that conform to current best practice. I don't want to see Joomla fall behind in these areas. 

The compiled LESS files will always be a user-editable css file, whether we apply Bootstrap classes with mixins or not. Compiled out to css it really makes no difference. The difference is that, if we do it in a smart manner, we do not encumber core outputs with markup that is specific to a particular framework. We get Bootstrap gloss *and* lovely clean markup. I see that as a big win.

Bootstrap may not exist in 3 years time, html certainly will. Done on the way I am suggesting the html in core outputs will be valid now, in 2024 and (should time-travel ever be possible) in 1999. There are no downsides to using standards based markup.

Seth Warburton

unread,
Dec 16, 2012, 3:41:10 PM12/16/12
to joomla-...@googlegroups.com
Hey Nick,

1) It is markup that doesn't conform to the html specification. I call that wrong because the W3C call that wrong. There is a reason there's an html specification, we can't just make this stuff up as we go along. Because 'that's the way Bootstrap does it' isn't justification enough for ignoring established specifications in my opinion. 

I have many such examples of badly constructed markup.

2) .btn should not be there. How backwards compatible should it be? All previous versions used .readmore and if we still had .readmore (I do of course thanks to the magic of overrides) then we could simply apply Bootstrap button styles to readmore links. I fail to see how there is any downside to this approach. The upsides are many.

3) The backward compatible solution is to restore the markup of previous versions, that worked with .js disabled and was not, as has been suggested, dependant on Mootools or any other library. It relied on a simple, good old-fashioned anchor tag. The <a> for mod_login have no content, there is nothing to display. Not for screen readers and not for browsers. I call this broken.

brian teeman

unread,
Dec 16, 2012, 3:51:18 PM12/16/12
to joomla-...@googlegroups.com
didnt the accessibility team led by angie just submit a patch to change the <i> issue and many more

Seth Warburton

unread,
Dec 16, 2012, 3:58:00 PM12/16/12
to joomla-...@googlegroups.com
To all those suggesting we just add the class readmore to article readmores, in addition to the button class, it's completely ignoring the fact that an end user, or template dev, might not want a readmore to be styled as a button!

"If you choose Joomla your article links *will be buttons*, on this there can be no compromise!" Is that the message? Really?


Bakual

unread,
Dec 16, 2012, 4:04:17 PM12/16/12
to joomla-...@googlegroups.com
If the link has both classes, you can style it whatever you want. And it doesn't break anything for existing templates. I don't see any downside to it.

Seth Warburton

unread,
Dec 16, 2012, 4:13:33 PM12/16/12
to joomla-...@googlegroups.com
Thankfully yes! And I shall continue to work with Angie to ensure that such things are recognised as issues and help wherever I can to fix things. I'd very much like to see more people care about the basics of accessibility and web-standards. 

The things like <i> tags are easier to tackle because they are clearly, and unarguably wrong. Some of my other suggestions are really in the line of 'Guys, there is a better way to do this...' and these things are harder to change. Step 1 in trying to change such things is to encourage discussion, in the hope that with a greater understanding of these issues we might be able to work together to solve them. We can't have change in these areas without understanding, consensus and the desire to improve. Coding them is the easy bit. 


Seth

Seth Warburton

unread,
Dec 16, 2012, 4:22:41 PM12/16/12
to joomla-...@googlegroups.com
You have a link with a class that defines it as a button (so button styles get applied) that you then have to target in your css to remove those styles. This means I am writing styles for a .btn class to make a link *not look like a button* and I have a link element in my markup with a .btn class that doesn't look like a button!! You don't see any downside to that?? Both markup and css are totally back-to-front (the polite term) in this case. 

Moreover, there is *no reason for it at all*! I can apply Bootstrap button styles to any element without adding a .btn class to it.

Gary Mort

unread,
Dec 16, 2012, 4:23:40 PM12/16/12
to joomla-...@googlegroups.com


On Sunday, December 16, 2012 3:58:00 PM UTC-5, Seth Warburton wrote:
To all those suggesting we just add the class readmore to article readmores, in addition to the button class, it's completely ignoring the fact that an end user, or template dev, might not want a readmore to be styled as a button!


Erm, that wasn't my suggestion.

My suggestion was that you code, submit a patch, and get it tested to add the class readmore to article readmoes in 3.0 - that will give you the IMMEDIATE benefit of being able to use that class to redefine the readmore link and disable to button styles - it won't be a button.

At the same time, submit a second feature request/patch to remove the btn class from the link in version 3.1 - about 4-6 months away.

This avoids fighting over whether or not it should have the btn class and gives an immediate fix...or if it is not possible to add it into some hypothetical 3.0.x version - it still could end up in 3.1

While for some future release of Joomla! you become involved now in the decision of what css classes different items will have.

Granted, I've posted in another thread about my frustration with the process....but at the very least try to follow the process before complaining.    I've vented, I got good feedback, I'm trying to change my ways to follow the process.  If it works, great.  If it doesn't, I probably did something wrong.  And at the very least I feel comfortable that I'm trying.

Nick Savov

unread,
Dec 16, 2012, 4:25:50 PM12/16/12
to joomla-...@googlegroups.com
Hi Seth, et. al,

1) I completely understand semantically. I'm just a very practical guy
though. That code will continue to work from here to 2024+ (as long as
HTML and CSS exist), because it's just standard HTML and CSS (tag and
class). Thus, I don't see the big deal. It's a very brilliant, in my
opinion, and simple trick by Bootstrap's developers that's compatible with
older and new browsers and will be with future browsers. There's simply
no harm done, so it's not worth fight over or getting worked-up over, in
my opinion. That's why I was looking for a different, more useful example
to understand your viewpoint better.

2) Ok, so someone made a simple mistake and it could have been done
better. Can you put your thoughts to code and provide a backward
compatible patch for it?

3) Great! Mind reporting it in the tracker and providing a patch so that
we can test?

Honestly, I'm just trying to help you and front-end developers get what
you want, while still giving everyone else what they want and have come to
like. If anyone goes 3 hours late to the party, they get whatever snacks
are left. If they wanted the best snacks at the party, they could have
helped set up or been there on time.

Coming late to Joomla 3 and arguing (without providing patches) about what
should have, could have, would have happened is a bit useless at this
point. Everyone had the opportunity to help get things "right" before 3.0
was released and now everyone has the opportunity to provide patches in a
backward compatible manner.

We're all in this together.

Kind regards,
Nick
>> joomla-...@googlegroups.com<javascript:>.
>>
>> > To unsubscribe from this group, send email to
>> > joomla-dev-cm...@googlegroups.com <javascript:>.
>> > For more options, visit this group at
>> > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> >
>> >
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-cms/-/zYwaZxeysB8J.

Bakual

unread,
Dec 16, 2012, 4:37:10 PM12/16/12
to joomla-...@googlegroups.com
Yes, you will have to do as you wrote (or build an override). But it is possible and will not break anything for others.
Yes, it may be better practice to only have a "readmore" class, which a template may be style as a button. But since it's there now, you can't take it away without breaking it. So it has to stay. It's also only an issue for people looking at the code and have a flair for "nice coding". So it's probably not something which justifies breaking other templates ;-)
 
You can get it removed for Joomla 4.x. I would even support that as I agree with you in this case. But not for Joomla 3.x.

Victor Drover

unread,
Dec 16, 2012, 4:39:24 PM12/16/12
to joomla-...@googlegroups.com
Isn't this the exact perfect time to break things? Once we get to 3.2/3.5, that's when things get firm, yes?

-V

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/UNR02UFsuo4J.

Seth Warburton

unread,
Dec 16, 2012, 4:41:10 PM12/16/12
to joomla-...@googlegroups.com
Nick, 

I've been complaining about such things for a looong time, way before 3 was released as I've been a semantics/accessibility/responsive nut since day 1. 

I put forward dozens of patches pre 3.0, in an attempt to 'get it right' all of which were ignored. I've re-written core views more time than I care to remember and I've volunteered on numerous occasion to help put down code, that apparently didn't help either.

I'm not sure how you can really say I've come late to J3..


On Sunday, 16 December 2012 21:25:50 UTC, Nick Savov wrote:
...
It is loading more messages.
0 new messages