No bootstrap on Joomla 3

[Allon Moritz]

Some users which are using my extensions on Joomla 3 with a self made template do not support bootstrap. I thought it is a must requirement, that a template for Joomla 3 must provide bootstrap. In Joomla 3 this is the code to load bootstrap or?

JHtml::_('bootstrap.framework')

Is there some kind of fallback when the template doesn't provide bootstrap?

Or I am on the wrong track?

[Bakual]

Bootstrap consists of two parts. One is the CSS part with its LESS files and the other one is the JavaScript framework.

 

The JHTML function loads the Bootstrap framework, which means it loads the JavaScript framework together with JQuery.

This framework should be loaded by the extension which uses it. The template doesn't know if the JavaScript is being used or not, and it doesn't make sense to load it always. Of course a template may use it itself and load it anyway. So call it in your extension when needed. At least that's my understanding.

 

The CSS stuff is what the templates have to provide.

It's my understanding that templates *should* support at least the main Bootstrap CSS classes. If they do this by including the whole Bootstrap CSS rules or by doing their own stuff (or mixing together what they like) is up to them. But the classes should be supported.

Of course a template designer may choose to not support them and to their own overrides and everything. But then he is responsible if a 3rd party extension doesn't look well.

[Guilherme Albuk]

   You can use JHtmlBootstrap::loadCSS that "Loads CSS files needed by Bootstrap".

   It's quick and simple and in general it works fine with non-bootstrapped templates.

   Cheers!

   Gui Albuk

2013/7/8 Allon Moritz <allon....@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.
To post to this group, send an email to joomla-de...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Donald Gilbert]

That is correct, although there's debate on how to access it. Some prefer direct class access, like JHtmlBootstrap::loadCss() over the JHtml::_('bootstrap.loadcss');

Both approaches are valid, although the first option (direct class access) does offer benefits when using a proper IDE. Most (I'd say all?) have no idea what to offer for parameter hinting when using the JHtml::_() version.

As for my opinion on that? I would prefer direct class use. It removes ambiguity and would possibly allow us to drop that silly JHtml::_() method.

[Matt Thomas]

It's also worth noting that when using JHtml::_('bootstrap.loadcss'); you can pass the language direction for RTL support. JHtml::_('bootstrap.loadcss');  defaults to LTR.

Best,

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

Sent from mobile. Please excuse any typos and brevity.

[Donald Gilbert]

You can also do that with JHtmlBootstrap::loadCss($includeMainCss, $direction);

:P

[Matt Thomas]

Ugh, sorry! That's what I meant to type. Damn fat fingers ;-)

Best,

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

Sent from mobile. Please excuse any typos and brevity.

[Michael Babker]

IIRC, that underscore method was supposed to be tied to some other methods in JHtml to have some sort of smart loader to allow overridding.  I've never actually used it used so if anyone's got anything showing that, I'd love to review it.

[Allon Moritz]

Thanks for the reply's. Was not aware about JHtmlBootstrap::loadCss(). It works perfect. When I test it with protostar it looks like the protostar template is loading the same content in templates/protostar/css/template.css. Does it mean bootstrap will be loaded twice?

Loading the classes directly is a nice hint (was still using JHtml::_ code), makes the code much more readable by outsiders...:-)

[Clubnite]

You can call the load commands as often as you like. The method responsible for loading checks for their existence and doesn't load anything if the requested files were already loaded. This applies to all the core loader methods of this kind.

[laoneo]

I know that I can call them multiple times...my question was if bootstrap is loaded twice, because of JHtmlBootstrap::loadCSS? It looks like it is loaded in the template.css file of the protostar template and bootstrap.min.css. For example the login module looks different when only the template is loaded or when addidionally JHtmlBootstrap::loadCSS is called....

[Matt Thomas]

In the case of Protostar, which is a template that uses a compiled stylesheet based on bootstrap, bootstrap styles will potentially be loaded more than once.

This is one of those edge-cases that I predict that we'll see more of. Not everyone wants to use Bootstrap for their templates. I'm not sure how best to handle it, but one option would be to compile your own bootstrap-based stylesheet and use a wrapper/container class in your extension to be sure that your component's stylesheet targets only it.

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.

--

[Allon Moritz]

But this would result in a mess like in the ages where jQuery was not included into Joomla core, every extension loaded it's own jQuery version and now we have to the same with bootstrap!! I thought it has to be a requirement for template developers that bootstrap has to be included into their template for a unified user experience. With JHtmlBootstrap::loadCSS the login module looks like on the screenshot below (the arrow is loaded twice)

I tested it with my extensions and all the icons are loaded twice as well....I think something is missing here which I don't understand...

[Keith Mountifield]

Sorry if I’m playing catch-up here, I’m not that experienced with bootstrap and J3 yet, but isn’t there a way that an extension can check to see if bootstrap is loaded, and if not load it? The problem with jQuery over the years wasn’t Joomla’s issue, it was developers assuming that it wasn’t loaded and simply adding it to the the head ‘will nilly’ rather than checking and only loading it if required.

 

It’s important for the continued growth of Joomla that as much flexibility as possible be maintained.

[Matt Thomas]

I agree about the potential mess.

Your example is a good one where compiling core stylesheets can be an issue. The problem, as I understand it, is that compiled stylesheets can customize the core bootstrap styles for the specific template. The issue you see is that you are now loading the core JUI (bootstrap) library, which then applies default styles to these same elements. In other words, while you're both using bootstrap, one version is a modified version applying global styles, and the other applies unmodified styles globally. In both cases, you're still using bootstrap.

With this being potentially the case, I don't see how extension developers can rely on using JHtmlBootstrap::loadCSS without possibly introducing issues like the one you describe. The only definite solution I see is for extension developers to compile their own extension-specific stylesheets.

The only other alternative I see is for everyone, including templates, to use JHtmlBootstrap::loadCSS, and then add an extra stylesheet for their specific look.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Ove]

Nice thread Allon. Made my eyes open to the fact that the Css and Js problems remains in J 3.x.  i.e. development and testing with Protostar as template is not enough.

Bootstraped extensions obviously still have to load Css and Javascript as needed (parameter controlled!)
As for the Css, the code suggested may not be enough. e.g. if you use i-tags I think you have to load it extra.
As for Js, we have a problem if the template loads a not complete bootstrap version. e.g. if you in your extension use a carousel that part may be missing.

Yes, I think there is a big risk for getting Css and Js loaded twice even if you use a parameter setting.

As I understand it, the Protostar template.css is compiled including the complete Bootstrap and Joomla code and with Icomoon.

On Dienstag 09.07.2013 11:25, Allon Moritz wrote:

[Matt Thomas]

Keith,

JHtmlBootstrap::loadCSS will do just that. The issue here is that the core template doesn't use JHtmlBootstrap::loadCSS, and instead uses a compiled stylesheets based on bootstrap.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Keith Mountifield]

Ah, thanks Matt,

 

That’s a  useful snippet of info to store away :o)

 

From: joomla-de...@googlegroups.com [mailto:joomla-de...@googlegroups.com] On Behalf Of Matt Thomas
Sent: 09 July 2013 10:51
To: Joomla! General Development
Subject: Re: [jgen] No bootstrap on Joomla 3

 

Keith,

[Matt Thomas]

Cheers!

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Bakual]

I didn't know the loadCSS function and now I really don't like the existance of it. I'd say it will introduce more problems than it probably can solve. Especially if it's used by extensions. It's fine as long as it is only used by templates.

If it's used by an extension, it will almost certainly break the template. So if you plan to use this, make it an option which defaults to off and with a warning that users turn it on on their own risk :-)

Personally I'm building my extension with Bootstrap classes and rely on the templates to support those classes (either by including BS or their own rules). If they don't, I will blame the template developers and redirect the users to their support.

By the way: Protostar does use JHtml::_('bootstrap.loadCss', false, $this->direction);

Am Dienstag, 9. Juli 2013 11:04:51 UTC+2 schrieb betweenbrain:

In the case of Protostar, which is a template that uses a compiled stylesheet based on bootstrap, bootstrap styles will potentially be loaded more than once.

This is one of those edge-cases that I predict that we'll see more of. Not everyone wants to use Bootstrap for their templates. I'm not sure how best to handle it, but one option would be to compile your own bootstrap-based stylesheet and use a wrapper/container class in your extension to be sure that your component's stylesheet targets only it.

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.

On Jul 9, 2013 4:48 AM, "laoneo" <allon....@gmail.com> wrote:

I know that I can call them multiple times...my question was if bootstrap is loaded twice, because of JHtmlBootstrap::loadCSS? It looks like it is loaded in the template.css file of the protostar template and bootstrap.min.css. For example the login module looks different when only the template is loaded or when addidionally JHtmlBootstrap::loadCSS is called....

On Tuesday, July 9, 2013 10:34:54 AM UTC+2, Clubnite wrote:

You can call the load commands as often as you like. The method responsible for loading checks for their existence and doesn't load anything if the requested files were already loaded. This applies to all the core loader methods of this kind.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.

[Matt Thomas]

On Tue, Jul 9, 2013 at 6:07 AM, Bakual <werbemails@bakual.ch> wrote:

So if you plan to use this, make it an option which defaults to off and with a warning that users turn it on on their own risk :-)

That's a good suggestion.

 

By the way: Protostar does use JHtml::_('bootstrap.loadCss', false, $this->direction);

Yes it does. But, only for RTL support[1] (as confusing as that is). It loads the compiled stylesheet just before that - see https://github.com/joomla/joomla-cms/blob/master/templates/protostar/index.php#L42

[Allon Moritz]

Sorry but a parameter is not the way to go, otherwise all extension developers have to add a turn on/off bootstrap parameter to their code. I'm wondering why this issue was not raised before the implementation of Joomla 3 started, to have an unified way to go, I mean this issue is obvious.

Do I have the right impression that the template providers have to override the bootstrap classes instead of providing the complete bootstrap CSS code in their template? From this thread I think as extension developer we are safe. We can just load Bootstrap CSS and then we are fine. The display issues will be up to the template providers....I hear my users complaining already :-)

Now I understand why the template providers could make their templates so fast ready for Joomla 3 ;-)

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.

[Matt Thomas]

I do agree that this is an area that can be improved, and one that I have been concerned about from when LESS was introduced. From what I understand, the root cause stems from how Bootstrap is customized by all extensions, including templates.

From my perspective, non-template extension developers have three options:

1. Rely on the template to provide the proper Bootstrap CSS.
2. Provide an option to load JHtmlBootstrap::loadCss.
3. Compile and load an extension specific stylesheet.

The only certain solution seems to be #3.

That said, templates should have the final say in styling. That is, if you load an extension specific stylesheet, it should be done in such a way that it can be disabled it (i.e. a switch, or view override...etc.) so that they necessary styles can be compiled into a single stylesheet.

I think that your example shows that non-template extensions shouldn't use JHtmlBootstrap::loadCss without the option to turn it off. In fact, I offer that option in my template framework.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Rouven Weßling]

My 2ct:

We should probably just deprecate loadCss. I think extension developers should be able to assume, that Bootstrap is present. Template developers should be encouraged to use less or they can manually include the bootstrap CSS (though to be honest I'd like the global bootstrap files to disappear too). If I recall correctly there was some talk about brining JLess and lessphp out of build and into the CMS - maybe that would be a good time to deprecate JHtmlBootstrap::loadCss().

As for RTL, it's one call to JHtml, I don't think we need a helper for that.

Best regards
Rouven

[Matt Thomas]

Rouven,

I think we're thinking along the same lines. Ultimately, I see the best solution being one where extensions provide nothing more than LESS files for compilation.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Allon Moritz]

As I understood it the main purpose of Joomla 3 was to unify the look and feel of the site that all the different extensions look harmonized. When now every extension should come with it's own bootstrap version it looks like a mess as before.

Deprecating is for me not an option as we need to have bootstrap. What I think should be the way to go is that the template providers can accept that bootstrap is in the core and that they can restyle it with their own template files. But honestly I don't think so they will do it because the big players have their own frameworks...

[Michael Babker]

A lot of frameworks are adopting Bootstrap actually, it's the ones who aren't that cause headaches.  So long as they use the Bootstrap CSS classes, then there shouldn't be an issue; extension developers are designing around a known standard and templates are implementing said standard.  At least, that's a perfect world scenario.

On Tue, Jul 9, 2013 at 6:53 AM, Allon Moritz <allon....@gmail.com> wrote:

[Allon Moritz]

What about a real world scenario :-) But now I have an answer I can give to my users with self made templates....

JHtmlBootstrap::loadCss will not work with a template which uses the full bootstrap code, means the default template protostar is buggy already...

[Michael Babker]

Not necessarily.  With that first param being false, the default bootstrap.css files aren't being loaded by the loadCss method.  It's actually using that method to determine whether the RTL file should be loaded.

[Donald Gilbert]

Maybe a simpler approach would require a new template parameter in the templateDetails.xml that informs the CMS whether or not it includes bootstrap compatible classes and markup. Then, we could have a helper that checks if the current template supports bootstrap. That way, extension developers could do something like:

```

$app = JFactory::getApplication();

$template = $app->getTemplate();

$tparams = $template->getParams();

// Load bootstrap css if the current template doesn't offer it, and my extension needs it.

if ($tparams->supportsBootstrap() === false)

{

    JHtmlBootstrap::loadCss();

}

```

[Donald Gilbert]

Change that to:

```

$app = JFactory::getApplication();

$template = $app->getTemplate();

// Load bootstrap css if the current template doesn't offer it, and my extension needs it.

if ($template->supportsBootstrap() === false)

{

    JHtmlBootstrap::loadCss();

}

```

[Allon Moritz]

I think the problem is not when a template doesn't support bootstrap but when a template delivers it (as the protostar does). That breaks stuff...I'm not sure if

if ($template->supportsBootstrap() === false)

{

    JHtmlBootstrap::loadCss();

}

would solve it? If yes then the if condition should be inside the JHtmlBootstrap::loadCss function like

public static function loadCss($includeMainCss = true, $direction = 'ltr', $attribs = array())

{

$app = JFactory::getApplication();

$template = $app->getTemplate();

// Load bootstrap css if the current template doesn't offer it, and my extension needs it.

if ($template->supportsBootstrap() !== false)

{

    return;

}

// Load Bootstrap main CSS

if ($includeMainCss)

{

JHtml::_('stylesheet', 'jui/bootstrap.min.css', $attribs, true);

JHtml::_('stylesheet', 'jui/bootstrap-responsive.min.css', $attribs, true);

JHtml::_('stylesheet', 'jui/bootstrap-extended.css', $attribs, true);

}

// Load Bootstrap RTL CSS

if ($direction === 'rtl')

{

JHtml::_('stylesheet', 'jui/bootstrap-rtl.css', $attribs, true);

}

}

--

[Rouven Weßling]

On 09.07.2013, at 13:53, Matt Thomas <ma...@betweenbrain.com> wrote:

> I think we're thinking along the same lines. Ultimately, I see the best solution being one where extensions provide nothing more than LESS files for compilation.

That's probably a good goal to aim for.

On 09.07.2013, at 13:53, Allon Moritz <allon....@gmail.com> wrote:

> As I understood it the main purpose of Joomla 3 was to unify the look and feel of the site that all the different extensions look harmonized. When now every extension should come with it's own bootstrap version it looks like a mess as before.

Actually no, the purpose of Joomla 3 was not to unify the look and feel (that'd be incredibly boring) to to unify the markup. If we go to less compiling (like the templates we ship have) it will always be the Bootstrap version we ship. (BTW 2.3.2 is supposed to be the last release of the 2.x series so the fear of several Bootstrap versions is slim from now on)

> Deprecating is for me not an option as we need to have bootstrap. What I think should be the way to go is that the template providers can accept that bootstrap is in the core and that they can restyle it with their own template files. But honestly I don't think so they will do it because the big players have their own frameworks...

I think it's established, that Bootstrap is the markup standard. But there a lot of things I can control trough less variables in bootstrap (mainly color, but also how round corners are) not to mention the advantage of a single CSS file. Why should we give that up?

On 09.07.2013, at 14:25, Donald Gilbert <dilber...@gmail.com> wrote:

> Maybe a simpler approach would require a new template parameter in the templateDetails.xml that informs the CMS whether or not it includes bootstrap compatible classes and markup.

I wouldn't do that. Bootstrap is the standard. If you go beyond that as template developer it's your responsibility to deal with it.


Best regards
Rouven

[Donald Gilbert]

So extension developers just use bootstrap markup and hope for the best? I think we can do better than that....

[Nikolaos K. Dionysopoulos]

Hi Don,

This is something the JUX code sprint team is trying to solve. I know as I had a Skype conference yesterday morning with them, trying to brainstorm a solution. It's a tough situation. We can't invent our own "Joomla! CSS framework" because who's going to maintain it. We can't drop Bootstrap 3 in it as it will break existing extensions. We can't load multiple versions of Bootstrap (2 and 3) at the same time. We have to make sure that the solution produces predictable DOM structures (otherwise developers will have to kiss Javascript goodbye and get back to Web 1.0). Some things are easier said than done. If you have any ideas feel free to get in contact with the JUX code sprint guys. I tried to think of a solution but came up empty :( Seriously, any help is more than welcome.

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

On 9 Ιουλ 2013, at 15:55 , Donald Gilbert <dilber...@gmail.com> wrote:

So extension developers just use bootstrap markup and hope for the best? I think we can do better than that....

[Ove]

Matt,

think of users as non technical. The extension has to be "plug and play"

I use an option to exclude extension specific css for those who know how
to handle it. The file only includes a couple of margins and paddings.
I'll probably still rely on the template to load the "standard" css but
will give it a thought.

But who is responsible for loading the Javascript? I know, it will only
be loaded once if it's loaded from the media/jui path but what happens
if the template loads it from a CDN in the "cloud". My guess here is
that the Joomla specific hacks are not needed for the frontend. Right?

Ove

[Donald Gilbert]

Ove, 

That's a great question and something I wanted to solve last year, but got rejected. :(

IMO, Joomla should have the ability to register scripts by name and location, and then queue them up for inclusion in the head by name, much like WordPress does. Well, not exactly like WP, because there are shortcomings, but they are on the right track I think.

So a template or extension, when needed to include a script, would register it first. JHtml::registerScript('jquery-cycle', $path, array('jquery'));

The first is the name, the second param is the location of that script, and then the third is an array of dependencies that must be loaded first if the named script is ever queued for inclusion.

Then, on the views there I needed jquery-cycle, I would just say JHtml::enqueueScript('jquery-cycle') and the logic would make sure all dependencies have been loaded, and then pull in the cycle script as well.

This approach has limits as well. Who gets to determine the location of a script? Who get's the final say? These are all questions that could be answered once we started to move in this direction and got more people on board. More advanced solutions that built off this simple approach would be great. Maybe you have a resource loader that scans all installed extensions and templates and determines what scripts are required and then the user can pick the one that works best for them from a list. Who knows? I'm sure someone does, but without support for it, no one will take time to try to figure it out.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.
To post to this group, send an email to joomla-dev-general@googlegroups.com.

[Bakual]

Actually, it was discussed before Joomla 3 released. Joomla 3 clearly has Bootstrap built-in and obviously Templates and extensions should use it. But not everyone follows the recommendations. This is fine, but those have to deal with the problems they raise by not following the standard.

Templates don't necessary need to override Bootstrap. They can include the whole Bootstrap, or pick the LESS files they want and compile their own version. Or they can build something from scratch. They can even override all output from extensions if they don't like the Bootstrap classes. Whatever they do, they should make sure 3rd party extensions work as well. The easiest way to do this is by including Bootstrap ;-)

I didn't say a parameter is the way to go. I said extensions shouldn't use it at all. But if you really want to use it, make it an option. It will most likely break a template if you load the Bootstrap CSS in an extension. CSS really is what templates should do, not extensions.

Am Dienstag, 9. Juli 2013 12:53:42 UTC+2 schrieb laoneo:

Sorry but a parameter is not the way to go, otherwise all extension developers have to add a turn on/off bootstrap parameter to their code. I'm wondering why this issue was not raised before the implementation of Joomla 3 started, to have an unified way to go, I mean this issue is obvious.

Do I have the right impression that the template providers have to override the bootstrap classes instead of providing the complete bootstrap CSS code in their template? From this thread I think as extension developer we are safe. We can just load Bootstrap CSS and then we are fine. The display issues will be up to the template providers....I hear my users complaining already :-)

Now I understand why the template providers could make their templates so fast ready for Joomla 3 ;-)

On Tue, Jul 9, 2013 at 12:17 PM, Matt Thomas <ma...@betweenbrain.com> wrote:

On Tue, Jul 9, 2013 at 6:07 AM, Bakual <werbemails@bakual.ch> wrote:

So if you plan to use this, make it an option which defaults to off and with a warning that users turn it on on their own risk :-)

That's a good suggestion.

 

By the way: Protostar does use JHtml::_('bootstrap.loadCss', false, $this->direction);

Yes it does. But, only for RTL support[1] (as confusing as that is). It loads the compiled stylesheet just before that - see https://github.com/joomla/joomla-cms/blob/master/templates/protostar/index.php#L42

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.

[Bakual]

I don't really think we can. And I don't think we should.
The best we can do is define a standard and recommend that people follow the standard. That's what we did.

We are now searching for a solution for those who don't follow the defined standard. And honestly I don't think that makes a lot of sense.

[Donald Gilbert]

You don't think we should do better than code and pray? Good to know....

"The best we can do" is very subjective. IMO, simply recommending a standard is no where near "the best we can do."

[Bakual]

I just don't think there is a better way. Standards are important and are there to follow.

Imagine there were no standards for electrical plugs. It's bad enough we have different standards in each country, but what if every machine and every building would have their own plug system? Translate country to CMS, machine to extension and building to template and you see the issue :-)

It would solve nothing if we have a variable where we see if Bootstrap is supported by the template or not. If I only load Bootstrap CSS files in my component when it's not supported by the template, it would still break the template CSS in most cases.

The only certain way is to create own markup and own CSS files. But that is what we had so far and what we tried to solve with Bootstrap.

[Matt Thomas]

For what it's worth, the most common feedback I receive from my template presentations is that Bootstrap itself presents a major learning curve to most people creating custom templates. Most of those individuals tend to clam up and nearly have a heart attack when they think about needing to learn, setup and use LESS. From my experience, adding an additional stylesheet, that contains extension specific bootstrap overrides, tends to be the easiest method for most general users.

While I feel that using compiled stylesheets is the best (most performant) way to go, it's not the easiest.

That begs the question, who are we building Joomla for and why?

In my opinion, beyond recommending a standard, we should answer who the target user is and make it easiest for that group. I personally don't like Bootstrap, and it's adoption makes my life more difficult, but I'm also willing to accept that it helps others and would like to see it's adoption improved.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

--

[Donald Gilbert]

Your analogy breaks down though. The electrical industry has years of training and qualification tests and licenses that can be revoked and inspection agencies that mandate the standard be followed. We have none of those things in the extension development world. don't get me wrong, I think it would be great. But in reality it doesn't work that way.

--

[Sergio Manzi]

Talking about standards (and sorry if this is a bit off-topic) I just
realized that the Boostrap framework included wit Joomla 3.1.1 is based
on a quite outdated (2.1.0 and there has been 6 more 2.x releases after
that), but what is worse is that it has been highly modified (there is a
lot of "JUI" code in it).

Personally while developing a Bootstrap based template and an extension
(a Bootstrap optimized mod_menu) I encountered problems that have been
solved with Bootstrap 2.3.2 and I tried to substitute that in JUI, but
while everything was OK in the front-end (at least for what I've seen),
there were load of problems and hiccups in the back-end, starting from
the fact that the top menu bar in Isis was not working anymore.

Now, don't you think that it would be wiser to base Joomla! on
"standard" Tweeter Bootstrap, so that new versions can be adopted
earlier without having to perform any customization specific to Joomla!?

Is Bootstrap so bad that it can't be used "as is" for Joomla! back-end
and front-end?

Hoping this is not too much O.T.,

Regards

Sergio Manzi

[Bakual]

Bootstrap will be updated with Joomla 3.2.

The changes are mostly to support RTL languages and such things. And there are some fixes in it which are now fixed in Bootstrap as well. At least I understood it like this.

[Michael Babker]

First, 3.1.2 will ship Bootstrap 2.3.2, so that issue is addressed.

Joomla couldn't adopt Bootstrap out of the box because Bootstrap assumes you're in a pure jQuery + Bootstrap environment.  That caused issues for our existing MooTools based scripts and in some Bootstrap scripts.  As for changes on the CSS side of things, IIRC, very few are made in the main Bootstrap LESS files but are left to templates to handle.  I may be wrong on the number, but I don't think there are very many.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.
To post to this group, send an email to joomla-de...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/groups/opt_out.

--
- Michael

Please pardon any errors, this message was sent from my iPhone.

[Sergio Manzi]

Thanks for clarifying, Bakual and Michael,

In my case I'm quite sure the problem was in the CSS part because it
went away using an (horror!) hybrid Bootstrap with 2.1.0 JS and 2.3.2 CSS

Nice to know that J! 3.1.2 will come with BS 2.3.2, anyway.

I really can't comment on the necessity of maintaining MoooTools
compatibility: I'll leave that to the real developers!

Thanks again,

Sergio

On 2013-07-09 16:23, Bakual wrote:

Bootstrap will be updated with Joomla 3.2.
The changes are mostly to support RTL languages and such things. And
there are some fixes in it which are now fixed in Bootstrap as well. At
least I understood it like this.

[Amy Stephen]

On Tuesday, July 9, 2013 8:57:44 AM UTC-5, Bakual wrote:

I just don't think there is a better way. Standards are important and are there to follow.

The standard was for the Administrator. There was no standard to exclusively use Bootstrap on the Frontend.

I understand the desire for extension developers to have this all settled and nailed shut but that's one group of users in the Joomla world. There is another group of users -- frontend developers -- who should definitely not be excluded from setting standards on the frontend related to markup and CSS. They don't always want to use Bootstrap.

In all honesty, frontend extensions should have basic structure -- ability to define classes easily and not a lot more. If you want to release extensions styled a certain way, then those extensions should likely be released with a Template.

I've also seen some talk about not staying current with Bootstrap. To those advocating such a position -- might I suggest you revisit the impact of that thinking when it was used to defend not updating Mootools? There is only one thing worse than being forced into a specific frontend framework, and that's being forced to use one that is out of date that the world is longer creating extensions for.

Try to build in choice on the frontend, I know it creates challenges but if your frontend developer community dries completely up (and it has significantly already), that's bad news since those are your site builders. And, whatever is included in core should be kept up to date. Or, take it out.

I realize those opinions are contra to many being voiced in this thread but ask yourself -- why are the frontend devs so quiet? How has this POV been received?

[Allon Moritz]

What is for you a frontend dev?

--

[Bakual]

In all honesty, frontend extensions should have basic structure -- ability to define classes easily and not a lot more. If you want to release extensions styled a certain way, then those extensions should likely be released with a Template.

 

Some advertisment from http://www.joomla.org/3/en:

 

Spend less time coding and building interfaces with Joomla 3. The Joomla User Interface (JUI) library gives you a standardized backend & frontend interface. LESS CSS and jQuery means you can write less code and the Icomoon font icon library provides a wealth of retina-optimized Icons.

• Build a Component with Zero CSS
• Style a Site with 1 CSS File 

To me this sounds like a defined Standard also in the frontend. Maybe it wasn't meant this way originally but it sure sounds like this on the page.

 

As an extension developer I don't really care how exactly my output looks. But I expect the template to support classes like row-fluid, span6, pull-left, btn, alert and such things. If I think the output should be left-aligned or look like an alert message or behave like a button, there is probably a reason for it. How this alert message or the button is styled is not something I care.

[Allon Moritz]

I totally agree, the overall goal should be that the site looks in harmony. And this can only be achieved with standardized classes and syntax (if bootstrap or not is an other question).

• Build a Component with Zero CSS
• Style a Site with 1 CSS File 

That would be a dream, imagine the page speed!!

--

[Amy Stephen]

On Tue, Jul 9, 2013 at 11:44 AM, Bakual <werbe...@bakual.ch> wrote:

In all honesty, frontend extensions should have basic structure -- ability to define classes easily and not a lot more. If you want to release extensions styled a certain way, then those extensions should likely be released with a Template.

 

Some advertisment from http://www.joomla.org/3/en:

 

First, I don't see the word "Standard." I also don't see any claim that there will never, ever, ever be a Foundation Template built for Joomla 3, either.  More importantly, the marketing team does not set development standards. A link to a discussion in the CMS list or a link to coding standards on the Developer site would have the authority required.

I do agree with the marketing team's assertion that components can be built with zero CSS. In fact, if I were to propose a standard -- that'd be it. Extensions should not have any CSS, period, unless they are included with a template.

And you are right, Bootstrap wasn't meant to be the only CSS ever to be used with Joomla which means it wasn't discussed and agreed upon, either. That should matter in a community.

 

 

As an extension developer I don't really care how exactly my output looks. But I expect the template to support classes like row-fluid, span6, pull-left, btn, alert and such things.

 

You see, and that's kind of the point. A good frontend dev would beg to differ that using row-fluid, pull-left and span6 should even be in a delivered solution, let alone something that you can count on them to use. They care about semantics and we should care about what frontend experts think about the frontend.

Where I will agree is that the frontend be standardized in some sense. We've always had that http://docs.joomla.org/Using_Class_Suffixes

One of Joomla's biggest strengths has been frontend templating. Since the beginning, there have been a set of standard classes and IDs that everyone used.

No reason frontend devs can't define a set of semantic class values, likely adopting a lot of what HTML5 has already laid out, that can be baked into Bootstrap and shared in core. That means those standards -- logical standards -- not vendor lock-in -- could also be used with Foundation or Gantry or whatever and developers would have clear instruction.

Like Allon - who just posted - said. +1,000,000.

[Keith Mountifield]

Hi All,

 

Wow, this has become quite an interesting thread, from technical not to conceptual. :o)

 

I would describe myself as a front-end dev. Most of my work is building bespoke template for individual clients. I don’t build templates that are for resale, if I need an extension, be it module, component or plugin, that can’t be satisfied by anything already out there, I build it. But at this point I haven’t released anything to general consumption (though I have a few bits that might make the grade, so maybe in the next few months. J

 

But, to throw my FED view into the mix here…

 

I totally understand and agree with t need for standards. I get really frustrated if I’m using a 3^rd party extension that tries to force me to use their styles. Yes, great, provide some styles for non-dev users, but anything visual provided as part of an extension should be optional, allowing the FEDs who have the time, knowledge and requirement, to switch them off and just take the classes into their own style sheet. You could even provide a blank style sheet template with a list of the classes that can be defined.

 

So the idea of Extensions just defining (and documenting, please) classes & ids and a single style sheet (though potentially an absolute nightmare to manage) would be great.

 

I would be interested to know, is there anywhere that best practises for template creation are actually defined and easily accessible? If not, maybe that could be a good subject to cover in the next Joomla Magazine. I’m just transitioning to 3.1 and I know that I would find that a really useful read.

 

Cheers

 

Keith

--

[Matt Thomas]

Along the lines of the current direction of this thread, Michael Babker shared with me a technique that I'd like to consider a "best practice" for extensions. Essentially, the concept is for the extension to check for a CSS or JS overrides within the template before loading the ones shipped with the extension. You can see an example at https://github.com/betweenbrain/K2-Related-Lists/blob/develop/mod_k2_related_lists.php#L48

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Niv Froehlich]

If you see Kyle Ledbetter's presentation

Joomla! 3.0 takes a big leap into the mobile space with a total overhaul of both its *frontend* design and administrator interface. With the adoption of the Bootstrap framework...

http://youtu.be/gEl3vb_UGso 

I believe the intent of Joomla!'s adoption of Bootstrap certainly includes the frontend in addition to admin

Also see

http://youtu.be/OXEx5wMF4fo

From my perspective, as someone new to Joomla!, Responsive Design and jQuery - the Bootstrap Framework is certainly flattening the learning curve.

I also quite like the idea of the Joomla! User Interface Library http://jui.kyleledbetter.com/ - I hope it continues to expand and I hope to fully take advantage of it for rapid development and my own customized templates.

I can understand, however, how those who are very advanced UI designers would want to do their own thing, and especially the 'template houses,' who have developed their own remarkable frameworks, might be hindered.

Best,

Niv

On Tue, Jul 9, 2013 at 4:35 PM, Keith Mountifield <qua...@gmail.com> wrote:

[Niv Froehlich]

Along the lines of the current direction of this thread, Michael Babker shared with me a technique that I'd like to consider a "best practice" for extensions. Essentially, the concept is for the extension to check for a CSS or JS overrides within the template before loading the ones shipped with the extension. You can see an example at https://github.com/betweenbrain/K2-Related-Lists/blob/develop/mod_k2_related_lists.php#L48

Thanks Matt!  You answered my q just as I was about to ask.

Are there any good docs or guidelines for customization? (i.e. I am wondering if adding 'additional' classes, done correctly (allowing for graceful degradation) ) would allow the addition of styling attributes without interfering with other component developers UI's.

It also brings about the question of namespacing for classes (Bootstrap's classes are effectively de facto namespaced) but to avoid collisions, perhaps a unique prefix would be advised?

[Michael Babker]

You know if you'd use the media folder, you could knock that down to one line ;-)

[Donald Gilbert]

Matt, if you use JHtml::script() (as well as the stylesheet() method), Joomla will do that searching for you instead of having to code it yourself.

The benefit of that is if the files are present but empty, one could effectively disable a components included stylesheets. It does, however, add an empty file to the head that still needs to be requested by the browser, even though it's empty.

On Tue, Jul 9, 2013 at 4:06 PM, Matt Thomas <ma...@betweenbrain.com> wrote:

[Donald Gilbert]

You could also abstract it a bit more: https://gist.github.com/phproberto/4615320 :P

[Matt Thomas]

@Michael - Absolutely! The problem is, I still need to support 1.5.

Glad I could set you up for that link ;-)

@Don - Thanks! Another gem worth noting.

Best,

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

Sent from mobile. Please excuse any typos and brevity.

[Michael Babker]

On Tue, Jul 9, 2013 at 4:48 PM, Matt Thomas <ma...@betweenbrain.com> wrote:

@Michael - Absolutely! The problem is, I still need to support 1.5.

Oh, well, carry on then.  Never mind the guy behind the keyboard. 

[Ove]

Nice, should be used. An option in the extension not to load anything would be a complement. For J! 2.5 based extensions this probably would be enough. But what if the extension is based on 3.0 and responsive Bootstrap? I do not see any way to check what is loaded by the template. It's a little bit "the other way around".

To me it though looks like it's easier for site implementors to modify output if there is less extension dependent css. If neccessary override the html output. Am I wrong?

[Amy Stephen]

On Tue, Jul 9, 2013 at 4:14 PM, Niv Froehlich <nivs...@gmail.com> wrote:

If you see Kyle Ledbetter's presentation

Joomla! 3.0 takes a big leap into the mobile space with a total overhaul of both its *frontend* design and administrator interface. With the adoption of the Bootstrap framework...

http://youtu.be/gEl3vb_UGso 

OK, watched the video.

15 minutes of Ebay datahub.

15 minutes of Kyle talking about Bootstrap. Nothing he said suggested it is a standard that all templates use Bootstrap on the frontend. Yes, there is a sample frontend template in Bootstrap. Yes, Kyle enthusiastically recommends it's use broadly. No problem with that. But, no, I did not hear him even suggest frontend devs may not use something else on the frontend. 

Last 15 minutes were Mark on language install (yea!), contribution process, and his only reference to Bootstrap was holding Kyle's efforts up as an example of how to impact change.
 

Back to the original question, my response is developers should *not* expect Templates to load Bootstrap.

If it's a standard, the core should load it. (In fact, maybe that should happen, anyway, as long as it can be unloaded. Most people will use Bootstrap -- probably no reason it shouldn't be loaded.)

Last comment and point -- know your strengths, right? Since the start, Joomla's strength in templating is unparalleled in any other open source CMS. We have enjoyed a very long history of commercial templating that was built on an agreement of a set of classes and IDs that allowed frontend devs to build a consistently look using core and community extensions. It worked. The challenge in the admin is now solved with Bootstrap -- that's good because the MT's approach was not holding up and it must be consistent. But, be careful restricting the frontend more than is absolutely necessary just to make things easier for devs or I fear you'll lose more frontend devs -- and those people are an important population of leaders for sitebuilders. I would try to involve them and make them happy too -- while ensuring that consistency. It's that balance of populations that keeps things moving forward.

OK, that's it for me.

[Niv Froehlich]

@Amy - sorry you had to watch the whole thing (I'm familiar with it b/c I prepared a Bootstrap workshop for the JUGT)

see

http://youtu.be/gEl3vb_UGso?t=24m59s (you'll notice 'Front End' in 'Phase II Improve UX)

also see at
http://youtu.be/gEl3vb_UGso?t=28m48s (this is were Kyle speaks to the intent of implementation and standardization on Bootstrap for the front-end)

So I think it should be clear that 'intent' was there for both the 'back-end' and the 'front-end.'

As far as the 'merits' or 'pros and cons' of that decision - that's a whole other discussion - and I am not in disagreement, in fact, I am very sympathetic to exactly everything you have to say.

From a very pragmatic point of view, I had to make a decision to either a) develop my own CSS/HTML/Javascript; b) learn an existing Framework (there are a lot of ones that look awesome and seem really well-engineered); or c) choose the one that the Joomla! Project standardized on.

It seems the obvious choice is c) (unless of course you are a highly experienced front-end ninja) so that leaves figuring out how this is all intended to work - so as to work within the intended system.

There is also the issue that you want your GUI components to 'play nice in the sandbox' with those developed by others.

That said, it was some really cool, dynamic and innovative looking templates that initially grabbed my attention and made Joomla! an exciting proposition for 'non-coders' - and to have that kind of innovation and creativity stifled or hindered in exchange for 'standardization' and 'rapid development' is a bitter pill to swallow - again, good move or bad move, I don't know.

But from my point of view, I'm just trying to make the most of it, more fully understand the intention and also how to implement Bootstrap/Joomla! according to best-practices.

I'm also finding the Bootstrap framework to be so efficient that I am effectively using it to virtually wire-frame web sites on the fly.

Another consideration is that Bootstrap is 'free' and 'open-source' - one is not charged to access documentation or to join a club or a support forum - that's another really practical problem - how many 'club' memberships can one afford (I'm not rich)? Why should anybody be tied down to one or two, or have to effectively fork out thousands?

As I understand it, Joomla! was never about the template clubs (although they add tremendous value) so have a free open-source, widely used front-end framework with oodles of free support channels and contributions just seems to me to 'fit' with my understanding of what OS and Joomla! is all about.

N

--

[Niv Froehlich]

@ Matt

For what it's worth, the most common feedback I receive from my template presentations is that Bootstrap itself presents a major learning curve to most people creating custom templates. Most of those individuals tend to clam up and nearly have a heart attack when they think about needing to learn, setup and use LESS.

I took on a challenge.   Learn the Bootstrap framework, and then turn around and teach a 'hands-on' workshop to our local user group - and did it on a rapid timeline.

My workshop, including exercise files, is available to download at http://www.formula1hosting.com/  and for anybody to use, either personally or as a workshop for their local user groups.

IMHO - I cannot think of a more complete, more robust front-end framework with a flatter learning curve - it's really quick to learn and folks from the user group have already began to use it.

Also, the next 'hands-on' workshop is on LESS - quick learning curve - huge payoff - I'll make that available too for any user groups (although I'm not a pro and there are great sources out there).

I actually, highlight as one of the benefits of Bootstrap - that it is great starting point to learn HTML/CSS(LESS)/jQuery - i.e. you can  learn the Bootstrap framework really quickly with virtually 'instant joy' - and then expand your knowledge and experience into HTML, CSS, and jQuery from there.

N

[Keith Mountifield]

Hi Niv,

 

Just tried the link in your email and got a 404 :o)

 

Sorry,

 

Keith

 

From: joomla-de...@googlegroups.com [mailto:joomla-de...@googlegroups.com] On Behalf Of Niv Froehlich
Sent: 10 July 2013 05:53
To: joomla-de...@googlegroups.com
Subject: Re: [jgen] No bootstrap on Joomla 3

 

@ Matt

[Allon Moritz]

I think we are on a point now where we have to go back and try to find a solution about the actual problem with the setup we have right now. I've set up a demo site which illustrates the problem

http://g4j.digital-peak.com/bsp

my concern is that when I start to ship my extensions with JHtmlBootstrap::loadCss() it will break the layouts of some sites. For me the only way to go is to fix the protostar template (as IMO it should be the reference) that it doesn't load the full botstrap stack but it should extend media/jui/css/bootstrap.min.css. Is this the way that the template providers have to follow as well?

@Amy since bootstrap css is shipped with Joomla, the argumentation that the template designer should decide if he wants to use bootstrap or not is not valid anymore. When an extension is calling JHtmlBootstrap::loadCss() it decides if bootstrap is loaded or not.

[Niv Froehlich]

or www.formula1hosting.com/TB_JUGT_June18_13.zip

note it is a large download - please let me know if that works - I think gmail bounces any attachments over 8 megs

On Wed, Jul 10, 2013 at 2:10 AM, Niv Froehlich <nivs...@gmail.com> wrote:

@Kieth

Just tried the link in your email and got a 404 :o)

My apologies - see attached.

N 

[Kannan Naidu]

Thanks, the new link works like a charm :)

Kannan Naidu
www.kannannaidu.com
twitter.com/kannannaidu
youtube.com/kannannaidu
My Google + [Add me to your circle]
My Facebook

[Keith Mountifield]

Ace! Thanks Niv

 

From: joomla-de...@googlegroups.com [mailto:joomla-de...@googlegroups.com] On Behalf Of Kannan Naidu
Sent: 10 July 2013 07:19
To: joomla-de...@googlegroups.com
Subject: Re: [jgen] No bootstrap on Joomla 3

 

Thanks, the new link works like a charm :)

[Bakual]

I still really don't think extensions should load Bootstrap. To rephrase it: DON'T DO IT.

It's not the job of an extension. It's the job of the template.

Protostar doesn't need to be changed to use loadCSS. It's perfectly fine as it is. Protostar doesn't load the default Bootstrap file for a reason. Protostar is a template based on Bootstrap, but it's not a pure Bootstrap template. It has additions and adjustments in it and all these are compiled from the many LESS files into one template.css file. And this is exactly how it should be done.

If you're going to use loadCSS, then you're breaking designs on purpose. There is no reason to do that, and in fact I believe the function should not be there to begin with.

If you're going to load a CSS file within your extension, you have to make sure it doesn't affect other output from the template or other modules. There is only one way to avoid that: namespacing. You can do that easy by having a toplevel container with a unique id/class and then adjust the rules to only match everything within this container. Everything else will break a site sooner than later.

I still think extensions should use Bootstrap markup in their output. If the template supports (not necessary uses!) Bootstrap, then the site will look consistent. If the template doesn't support the markup, then the user will have to create overrides for the extension layouts which match their markup or provide an (optional) CSS file for it.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.

To post to this group, send an email to joomla-de...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.

[Allon Moritz]

I've added a pull request https://github.com/joomla/joomla-cms/pull/1448 and a tracker item http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31402

If you're going to use loadCSS, then you're breaking designs on purpose.

Why was it added then? In my extensions I use something like

<div class="row-fluid"><div class="span8">My awesome text</div><div class="span4">More text</div></div> and then I expect it is rendered correct. To ensure it probably the loadCSS function was introduced. 

 then the user will have to create overrides for the extension layouts which match their markup or provide an (optional) CSS file for it.

Do you really want to let the user to have to create overrides for your extension? I thought it was a decision to support bootstrap in Joomla 3 so let's do it and don't look back :-). If we really go the way that every extension should come with it's own namespaced bootstrap then you will have a bloated site and at the end probably the same war like it was with jQuery in pre Joomla 3 ages.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.

[Bakual]

Your PR breaks the Protostar template as the Bootstrap CSS would be loaded after the template.css. Also it would load four CSS files instead of one, the template.css, the bootstrap.min.css, the bootstrap-responsive.min.css and the bootstrap-extended.css.

In Protostar, the template.css already includes the full Bootstrap. Have a look at /templates/protostar/less/template.less to see how it is built. The first imports are the Bootstrap LESS files, and after that are the Protostar specific CSS rules. This is compiled into the css/template.css file when Joomla is released so the template only uses one single file.

As said already in this thread. Joomla doesn't enforce you to use Bootstrap itself. A template developer may choose to use a different framework or use own rules built from scratch. He could also use only parts of Bootstrap (easy by picking the wanted LESS files) and build the rest himself. He may also want to override the extension output to match his chosen framework.

The only thing I agree with you is that the Bootstrap markup should be our standard for outputs. If a template loads Bootstrap, part of Bootstrap, an own set of rules or a different framework is up to them. If a template doesn't support Bootstrap markup, it has to use template overrides and deal with customer complaints.

If an extension developer wants to provide an (probably optional) own CSS file, this has to be "namespaced" or you will get complaints from your users due to breaking their sites.

Personally I don't see any good reason to use loadCSS at all. The template should instead use a precompiled template.css file and the extensions shouldn't load them at all.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsubscribe@googlegroups.com.

To post to this group, send an email to joomla-de...@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsubscribe@googlegroups.com.

To post to this group, send an email to joomla-de...@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Amy Stephen]

On Wed, Jul 10, 2013 at 1:43 AM, Allon Moritz <allon....@gmail.com> wrote:

Do you really want to let the user to have to create overrides for your extension? I thought it was a decision to support bootstrap in Joomla 3 so let's do it and don't look back :-). If we really go the way that every extension should come with it's own namespaced bootstrap then you will have a bloated site and at the end probably the same war like it was with jQuery in pre Joomla 3 ages.

Except -- you are describing a situation where there are problems for you as an extension developer with two core 3.0 templates (post war in your scenario) -- both of which use Bootstrap, but they do so differently.

So, the plan isn't working perfectly.

Would the answer now be to not only require vendor lock in, but specify HOW it's used, too?

In my opinion, that would be a step in the right direction because in the end, it will be discovered that compatibility is achieved on a common set of classes and IDs.

Like we have always had. And that's not limited to one vendor.

The point on Jquery and MT's is a different one than CSS.

From your previous post:

@Amy since bootstrap css is shipped with Joomla, the argumentation that the template designer should decide if he wants to use bootstrap or not is not valid anymore. When an extension is calling JHtmlBootstrap::loadCss() it decides if bootstrap is loaded or not.

Is it really a problem for frontend devs if extensions can call JHtmlBootstrap::loadCSS? Or, is that something that's within a frontend devs control as he or she select extensions for install on their site build? ;-)

[Allon Moritz]

I'm also not a friend of vendor lock in but there was a decision made that Joomla comes with bootstrap so we have to live with it. What I try to solve is the problem that there is a bootstrap.css file which can be loaded from an extension. So the question is how should this be handled from the template point of view? I mean when I add JHtmlBootstrap::loadCSS() to my code it breaks the default protostar template...this is a fact and I'm trying to solve this case as reference for the future. Because I think when the protostar template comes with a bug  it is bad for Joomla...

I absolutely don't say that the template devs are forced to use bootstrap but they have to live with the fact that it can be loaded not namespaced trough JHtmlBootstrap::loadCSS().

he or she select extensions for install on their site build?

True, but would mean I can't install my absolutely favorite extension because it loads the global bootstrap?

I think having a global bootstrap file is fine as we extension developers are not forced to create our own namespaced bootstrap files (will reduce page size and requests). But more and more we are discusing it here I think the Joomla bootstrap file should be namespaced which will not interfere with the rest of the site.

Means this would work

<div class="jcontainer">
  <div class="row-fluid">
    <div class="span4">...</div>
    <div class="span8">...</div>
  </div>


</div>

and this not

<div class="container">
  <div class="row-fluid">
    <div class="span4">...</div>
    <div class="span8">...</div>
  </div>


</div>

what about this approach?

[Sergio Manzi]

Reading this thread has been very informative and important to me,
thanks to everybody.
I would like to add some personal considerations:

1) In general terms, I think it is simply not feasible that extension
are "stylesheetless" (no pun intended). I'm thinking, e.g., to an image
gallery extension I've just written for one of my sites where I wanted
to style thumbnails so as they looked as old 35mm slides. I had to use a
template.css for that. I think I handled the situation quite nicely and
added an option to *not* load my template.css and another to load an
optional "custom.css". Everybody (well just me for the time being, as at
this time this is a private extension) can choose to load my template
and have my look-and-feel, or write its own css, styling the gallery in
a complete different way. I didn't need BS for that particular
extension, but in case, I think the best I could have done is to add an
option to load the BS framework or not.

2) Even basic Joomla! modules assume that BS is loaded. Try even
mod_login without BS: it will look like crap.

3) Users, and I'm talking of normal persons downloading Joomla! and
expecting to get a functional CMS, should get that expectation
fulfilled, at least with a basic nice looking, functional and compatible
template.

4) As BS has been chosen as the "standard" framework for Joomla! CMS (a
good idea, IMHO) the above mentioned template should be *totally*
compatible with standard BS. That is, if Protostar is broken by standard
BS, then Protostar *must* be fixed and *it must* load standard BS by
default. This will make up the reference platform. Extension writers
should write their code to be compatible with that reference platform
and in case of need (see point 1 above) load additional stylesheets *as
an option*.

5) If the above points are met, a template developer *could* decide,
basically for performance reasons, to *not load* standard BS but a
custom, optimized version of it. If this will be the case, then it will
be his responsibility to guarantee compatibility for all loaded
extensions that in turn could have their "Load Bootstrap" option
switched off.

So, basically, my proposal is:

1) Let the template decide if to load BS or not (but basically at least
a subset of it or anything else providing the same functionality should
be assumed as even core J! CMS needs it).
2) For extensions needing it, always provide an option to not load BS
(or any other stylesheet whatsoever)

Does that makes sense?

Sergio

[Allon Moritz]

Adding an option to all 6000 extension would be a nightmare. I've updated the pull request and added a namespaced version of bootstrap, check out the comment here https://github.com/joomla/joomla-cms/pull/1448#issuecomment-20731147. What about this approach?

Sergio

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.

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

[Sergio Manzi]

Well, I don't think there are 6000 extension loading BS in wild... and
of course I was talking about newly designed extensions.

But another (maybe better) way to get the same result could be to have a
"master override" switch in the backend (or programmaticaly callable by
the template) so that extensions loading BS through
JHtmlBootstrap::loadCss(); will not really have BS loaded and the
template designer could decide what to load.

A namespaced BS? You mean that it will be a Joomla! specific BS with its
own namespace? Not a good idea, IMHO...

[Bakual]

The point is, it's not a bug with the Protostar template. You shouldn't load this CSS file in your extension at all. You're not supposed to do that.

Not everything which CAN be done, SHOULD be done :-)

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.

[Bakual]

Just a comment on your first point: If you use JHtml::stylesheet() and put your template.css into the media folder, then each user can simply override your CSS file within the template.

Read http://www.babdev.com/blog/139-use-the-media-folder-allow-overridable-media

No need for an option at all :-)

[Bakual]

Creates huge backward compatibility issues. Breaking all templates based on Bootstrap? Creating a nightmare for future Bootstrap updates and documentation issues? Only to solve an issue where you load Bootstrap within your extension (which you're not supposed to do at all). I don't think that's a good idea.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsubscribe@googlegroups.com.
To post to this group, send an email to joomla-de...@googlegroups.com.

[Sergio Manzi]

Bakual, forgive my ignorance, I didn't know about that, but...

this will also mean that an (probably empty) override CSS will be needed
for each extension and the HTTP requests will anyway be made.

IMHO the "master override" switch is not that bad at all...

[Michael Babker]

If you're writing your extension using Bootstrap based markup, there is absolutely zero need to forcibly load the default Bootstrap CSS within said extension.  A template will take care of the CSS and your extension design will fall in line with that very quickly without issue.

No, it is not a bug IMO that the use of loadCss breaks Protostar.  Protostar is a pure Bootstrap based template, including having the full stack compiled into its template.css file.  Loading the default bootstrap.css then customizing it with overrides in the template.css file is not an efficient option either.  If I want to customize the font size/color, how many items do I have to override when it can be done once in the variables.less file?

At this point in the game, it is safe to assume that extension devs are expecting a certain markup standard when they write their code, that being Bootstrap.  Templates implementing Bootstrap will have no issue rendering those extensions.  The front end developers who aren't implementing Bootstrap do so knowing what they'll have to do to build and maintain their design.  Extension developers who are forcing Bootstrap on everyone by forcibly loading the full framework CSS within their code are going to cause headaches down the road for others, evidence of that is in this thread.

Lastly, loadCss was a mistake IMO.  It is at best a shortcut to let folks lazy load Bootstrap then hack away as desired instead of compiling a proper CSS based on the LESS files.  It works for absolute beginners who know very little about that stuff as a whole, but it's just as easy for them to directly load the media in their template instead of calling a helper method to do it for them.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.

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

[Allon Moritz]

But what do you tell your customers when they don't include bootstrap in their template? Sorry my extension looks so crap because you don't load bootstrap....

Extension developers who are forcing Bootstrap on everyone by forcibly loading the full framework CSS within their code are going to cause headaches down the road for others, evidence of that is in this thread.

That's the point, when Joomla comes with loadCss it should be at least namespaced (which means the CSS styles are only applied within a certain container).

When loadCss is for beginners why was it added then? There must be a purpose....does somebody know the developer of the commit https://github.com/joomla/joomla-cms/commit/4749574ac7e4a592d68d4840022360115cfa50c4 perhaps he knows the story behind the commit.

I don't know where all this will end as the solution looks relatively easy for all involved parties....just use a namespaced bootstrap version and let the templates override it. Means it will not break any template, bootstraped or not.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.
To post to this group, send an email to joomla-de...@googlegroups.com.

[Sergio Manzi]

Michael, I've never tried to see what happens loading full BS with
Protostar, so I may have made false assumptions based on someone's else
experience, but it is my understanding that if you do, then Protostar
will not render correctly. If this is the case it would mean (from my
pow) that, yes Protostar can be technically defined as a "Bootstrap
based" template, but it will not probably be the best reference design
for Joomla! CMS that comes packaged with full BS (albeit modified and
this another story, but I've understood that this was somehow unavoidable).

Point taken that it is not at all needed to call
JHtmlBootstrap::loadCSS() from extensions, although maybe if a were a
"professional" extension designer I will include a (turned off by
default) option to do that... just in case...

What as a FED designer I would like to have is something like:

JHtml::purgestylesheet()
JHtmlBootstrap::UnloadCSS()

To "unload" every already "loaded" stylesheet, then I can take care of
everything with *my* CSS (very likely to be less compiled, BS based) and
it will be my responsibility to have everything working.

Not to open another can of worms, but on the same line of though, maybe
something like that can be useful for JS scripts...

Sergio

[Bakual]

Aye, that's true. If you want to disable the whole file, an empty file would be needed. This isn't optimal as you said. For this case an option to disable the CSS file would be nice indeed.

[Bakual]

+1

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsubscribe@googlegroups.com.
To post to this group, send an email to joomla-de...@googlegroups.com.

[Matt Thomas]

Is this where JHtmlBootstrap::loadCss could be useful? For example, if extensions where to call it, a template could call 
JHtmlBootstrap::UnloadCss if the template is going to handle the styling.

Best,

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

Sent from mobile. Please excuse any typos and brevity.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.

[Bakual]

But what do you tell your customers when they don't include bootstrap in their template? Sorry my extension looks so crap because you don't load bootstrap....

 

Yep, that's exactly what I will tell them, because it's true and the source of the problem.

 

I don't know where all this will end as the solution looks relatively easy for all involved parties....just use a namespaced bootstrap version and let the templates override it. Means it will not break any template, bootstraped or not.

It's not easy, as your suggestion breaks all existing templates, makes updating Bootstrap a huge task and it makes the official Bootstrap doc invalid for Joomla.

[Bakual]

What as a FED designer I would like to have is something like:

     JHtml::purgestylesheet()
     JHtmlBootstrap::UnloadCSS()

To "unload" every already "loaded" stylesheet, then I can take care of
everything with *my* CSS (very likely to be less compiled, BS based) and
it will be my responsibility to have everything working.

Not to open another can of worms, but on the same line of though, maybe
something like that can be useful for JS scripts...

 

I'd say that should already be possible using a system plugin. As I understand it the CSS and JS files are all stored in array before the whole document is rendered. A system plugin which acts before the page is rendered should be able to process those files, purge them and/or remove them.

I'd even guess something like this already exists :-)

[Bakual]

I'd even guess something like this already exists :-)

See http://extensions.joomla.org/extensions/core-enhancements/performance/site-performance/12088 :-) 

[Donald Gilbert]

If you're going to use loadCSS, then you're breaking designs on purpose. There is no reason to do that, and in fact I believe the function should not be there to begin with.

With that logic, we should remove JHtml::script() and JHtml::stylesheet() as well as remove the ability for plugins to hook into and modify the body in JResponse so they can't manually insert arbitrary CSS and JS links into the document head.

That would be ludicrous, and we are obviously not going to do that.

The fact of the matter is, no matter how hard we try, people are going to do whatever they want. If an extension dev develops an extension that requires bootstrap css to look right, and they do nothing to make sure that bootstrap css is loaded, then they are doing it wrong. How could they, in good conscience, tell their end users "It's not my fault I'm not loading the CSS that my component requires in order to be styled correctly! Go talk to your template dev!!!!!!!!!"

As much as I would love it if every template club (RocketTheme, RSJoomla, JoomlaJunkie, ProThemer, YOOTheme, JoomlaBambo, JoomlART, etc etc) would use and properly load Bootstrap in all their templates, it's _____just not possible_____ to expect that.

If we want to build a new CMS that _______REQUIRES________ Bootstrap markup and support in all templates, then we can make that choice, but as it is now; It. Will. Never. Happen.

*phew*

Rainbows and Unicorns,

Don Gilbert

PS: That's the most times I've used Bootstrap in a post and spelled it correctly each time. YAY ME!

[Sergio Manzi]

Probably yes, quite easy. But I think this correctly belong to the respective classes, JHtml and JHtmlBootstrap.

And sorry if I'm diverting from the main topic but thinking about what you explained me about css overrides and my objection about useless HTTP requests for empty files, wouldn't it be possible to extend the override mechanism so that if it finds an ovverride css but with a .off suffix (imagine /templates/mytemplate/css/his_extension/template.css.off) it just unload that template from the stack and be done with it?

Sergio

[Sergio Manzi]

On 2013-07-10 14:07, Bakual wrote:

I'd even guess something like this already exists :-)

See http://extensions.joomla.org/extensions/core-enhancements/performance/site-performance/12088 :-) 

--
  

From the description it seems it just merge and compress things, but I'll give it a try, thanks!

[Ove]

I agree with Bakual.
It's a pitty that we can't tell the user that most of the extensions require Bootstrap. This because many older ones are backward compatible with J 2.5 and loads their very own css. I had a look in one popular extension. It loads 70k css extra.

You and your customer have though at least 4 options discussed here.
1. The customer loads the Bootstrap css with his template.
2. The customer copies the views to the html override and adds Bootstrap css loading there.
3. The customer copies the views to the html override and modifies them as needed.  (advanced)
4. You add an option to load Bootstrap css to your extension. If you have any other own css you should as "best practice" also have an option to exclude it. 

On Mittwoch 10.07.2013 13:17, Allon Moritz wrote:

[Michael Babker]

I've argued before that there should *NOT* be an API endpoint to unload media.  I stand by that.  It can be done via direct access to class properties (many template folks know this already).  If I am loading Bootstrap carousels in my extension and properly loading the media via the API, then I expect full well that the media will be there.  If there's an API endpoint to unload that media, we might as well jump on the bandwagon Don suggested and pull out all the API endpoints that load media and tell everyone "you're on your own to figure out how to inject this stuff into the document".  Unloading media after someone loads it is even more dangerous than not loading the Bootstrap CSS in your extension and having a template that doesn't implement Bootstrap.

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.
To post to this group, send an email to joomla-de...@googlegroups.com.

[Sergio Manzi]

On 2013-07-10 14:53, Michael Babker wrote:
> I've argued before that there should *NOT* be an API endpoint to
> unload media. I stand by that. It can be done via direct access to
> class properties (many template folks know this already). If I am
> loading Bootstrap carousels in my extension and properly loading the
> media via the API, then I expect full well that the media will be
> there. If there's an API endpoint to unload that media, we might as
> well jump on the bandwagon Don suggested and pull out all the API
> endpoints that load media and tell everyone "you're on your own to
> figure out how to inject this stuff into the document". Unloading
> media after someone loads it is even more dangerous than not loading
> the Bootstrap CSS in your extension and having a template that doesn't
> implement Bootstrap.
>

I beg to disagree. I understand your reasons, but you can't force your
media down the user's (or FED's) throats. Of course it will then be the
user's (or FED's) responsibility to have things working. Overrides (at
every level) are an important part of Joomla! CMS just for that. It's
all about freedom, I guess.

Sergio

[Bakual]

http://extensions.joomla.org/extensions/core-enhancements/performance/site-performance/20075 may be another one. There are various of this kind as it looks.

[Michael Babker]

There's a difference between forcing media down a user's throat and using the API correctly.  It's a fine line that we toe, but it is there.  If I'm using the API as intended and calling Bootstrap carousels, I'd be pretty pissed if someone were unloading it for their own benefit.  Also, every media file loaded by the core JHtml helpers is 100% overridable.  So if you truly want, you can override bootstrap.js in every way you want, but if you do so, PLEASE ensure you're implementing the available JS endpoints that are provided by Bootstrap in your override (who wants angry customers because you didn't implement Bootstrap alerts in your override JS?).

My definition of forcing media on a user: inline your media declarations in your code or placing your media files in locations that don't use the API to allow them to be extended/overwritten.  Activity along those lines should get you publicly named and shamed IMO, that is *NOT* collaboration in the best interests of users and the community at large.  Every one of my extensions either uses the API to allow media/layout overrides or I've provided this functionality on my own (in cases where the code doesn't exist to support that).

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.
To post to this group, send an email to joomla-dev-general@googlegroups.com.