Joomla and Twitter Bootstrap 3.x

[Kai Røen]

I was wondering when Twitter Bootstrap 3 will be included in Joomla. There is so much great new improvements and features in TW3, and it would be so great to have a updated version in next version of Joomla.

What about have a option in Joomla administrator to choose TW2 or TW3?

[Bakual]

Unfortunately BS3 isn't compatible with BS2. Thus it would break each existing template which works without overrides. And maybe also 3rd party extensions.

If you find an easy way how this could be solved, I would be interested :)

Am Mittwoch, 12. Februar 2014 22:53:47 UTC+1 schrieb Kai Røen:

[Kai Røen]

But at some point TW2 must be replaced. There is no point of using TW if it's not upgraded to latest version. I really don't care about 3rd party extensions, because they will adapt the changes if the Dev team announces this in a early stage.

This is very frustrating when developing themes.

[WooDzu]

Hi Kai,
The earliest time I would imagine for this to happen would be version 4.0 where Joomla can break backward-compatibility... unless there is a bright idea for a workaround.

[wdburgdorf]

On my most recent site I use Bootstrap 3 (using a template by Joostrap), and it worked fine. But it's a very simple site with few extensions. Anyway, I will surely continue to use BS3, it's so much improved.

I understand that BS2 cannot be replaced in J!3.x core, it's been discussed before. I just hope that for J!4.x there will be a better idea than just integrating BS3 instead of BS2. As soon as BS3 is integrated, there will be BS4, and so on. 

Actually, it would be much less of a problem, if extension developers stuck more to good practices regarding overrides. Then template and extension developers could "simply" provide overrides for BS3 or BS4 or anything else. After all, moving from BS2 to BS3 mostly means changing a few classes. But as long as some developers use inline styles and non-overridable css, that's what I find much more frustrating than the current BS2 integration ...

[Bakual]

Am Donnerstag, 13. Februar 2014 06:00:41 UTC+1 schrieb Kai Røen:

I really don't care about 3rd party extensions, because they will adapt the changes if the Dev team announces this in a early stage.

Here lies the problem. You don't care. But I do and Joomla has to do. Neither extension developer nor templaters want to redo their whole output for a minor release.

[Niv Froehlich]

My $0.02

1) Let's start at the beginning - the need for standardization.

The Joomla! CMS needed to standardize on 'one' front-end framework.  The primary reason for this was so that the thousands of extensions available could rely on that particular standard to ensure consistency in the styling and behaviour of their modules when site owners integrate those extensions.   Without a 'standard' - say good-bye to that advantage and hello to extensions that do not have a consistent look and feel when you integrate them into your site.

To the best of my knowledge, nobody has come up with a winning alternative - although some appear to have been suggested and perhaps some alternative solutions are in the works.


2)  Bootstrap 2.3 vs. Bootstrap 3

I work with both Bootstrap 2.3 and Bootstrap 3.  Each versions have their advantages and disadvantages.  The 'latest version' doesn't necessary equate to the 'best version.'   For example, Bootstrap 3 has adopted a 'mobile first' approach, and in doing so, adopted a very unappealing and boring 'flat design' for performance reasons.  This makes Bootstrap 2.3 more aesthetic 'out-of-the-box' - and for most intents and purposes, the performance difference is 'un-noticeable.' 

In fact, if you gave the me the option today of which Bootstrap version to standardize on for Joomla!, I'd still choose 2.3.  Call it personal taste, but while some people might like the 'flat design,' I'd be adding style elements - that means more work to make 3.x look have decent.

The first question I ask somebody when they bring up Bootstrap 3.x is "Why exactly do you want to use Bootstrap 3.x?"

Usually the only answer that I get in response is, "Because it's the latest version."   When I inquire as to what advantages Bootstrap 3.x has over 2.3, the person, more often than not, doesn't know.

Now I'm not saying that Bootstrap 3.x doesn't have it's advantages and there may be very legitimate reasons for opting for the 3.x version - but if one doesn't know specifically what those are, then IMHO, simply wanting to adopt Bootstrap 3.x for the sole sake of it being the 'latest version' is not a good reason at all.

3)  Growing number of Bootstrap 3.x Templates available

I'm seeing more and more Bootstrap 3.x Templates available, and more will become available.   I see that sometimes these templates are advertised with utterly meaningless marketing lines such as "Full of Bootstrap 3 Goodness!!!" (really, no word of a lie - I see these templates marketed with that line).  Yet the template designers advertise Bootstrap 3.x without identifying a single advantage that Bootstrap 3.x provides over 2.3.

What is it that these Bootstrap 3.x templates could do now that they couldn't do before?

I'm begging you, show me one example that is so mission critical that you can no longer deem Bootstrap 2.3 to be acceptable.

Nonetheless, template designers not only need to be savvy marketers (how many people will purchase templates because their template is now 'Bootstrap 3'?), but, also template designers need to be forward thinking and the fact that Bootstrap 3 templates are available and becoming more prominent is, IMHO, a good thing - I agree that extension developers will follow as the resulting demand increases.

4)  What about extensions and extension developers?

Importantly, extension developers are also promised that their extensions won't break until at least the next x.0 release of the Joomla! CMS - so while you can be reasonably assured that Joomla! 3.x compatible extensions will work with Bootstrap 2.3 - there is no such assurance if you are using a Bootstrap 3.x template.

While on one hand this may be limiting to extension developers who want to use the latest version of Bootstrap, on the other, it would be completely unfair to demand that extension developers code for every possible iteration of Bootstrap to ensure that their extensions will work with your template - just because you've decided to chose a different version Bootstrap.


5) Nothing critically wrong with Bootstrap 2.3

The Bootstrap framework is certainly not the pinnacle of best-practices (i.e. the semantics do not follow text-book coding practices, but if this is important - you can certainly add your own styles on top of the core Bootstrap - it's very doable depending on the way you organize your LESS files).

Other than that, I have yet to hear anything that is so critically wrong with Bootstrap 2.3 that is not 'professional grade.'

It's not perfect - but it does it's job - and that is to provide a comprehensive, standardized front-end framework.


6)  Use Bootstrap 3 if you want

Nothing prevents anybody from using Bootstrap 3.   If you are an extension developer - go ahead.  Just make sure you have a version that works with Bootstrap 2.3.   If you organize your code the right way - it shouldn't be a lot of extra work.

Conversely, if you are using Bootstrap 3 for your template - make sure that a) your extensions will be compatible; or b) that you are willing to roll up your sleeves and make any necessary modifications.


7) Joomla!'s standardization on Bootstrap 2.3 is not a 'crisis'

Again, without being able to identify any or fundamental which will prevent a site from achieving mission critical objectives (i.e. a good example would be if 2.3 had no responsive capabilities), IMHO, the Bootstrap 2.3 framework remains a sound technological choice for the Joomla! CMS 3.x life-cycle. 

N

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

[brian teeman]

On Thursday, 13 February 2014 15:00:07 UTC, Niv Froehlich wrote:

My $0.02

That's not 2c thats a full dollar

[Niv Froehlich]

touche

[Troy]

does 2.3 have a EOL announced?  I know their documentation has been archived.  If so then its time to start the migration to abandon 'twitter bootstrap" completely as maintaining 2.3 ourselves will mean its no longer "twitter boostrap".

Bear

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4259 / Virus Database: 3697/7088 - Release Date: 02/12/14

[Niv Froehlich]

@ Troy

According to the Twitter Bootstrap docs, 

Heads up! These docs are for v2.3.2, which is no longer officially supported. 

(See http://getbootstrap.com/2.3.2/)

N 

[Bakual]

We don't maintain it. We just use it. It's a difference.

As said already. If someone has a good idea how we can move to BS3 without breaking all existing templates and extensions which are based on BS2, then we are all listening.

To my knowledge, there is no easy solution for that, but I may be wrong of course.

Also it's a bit different from what Joostrap does. They are working from a template level and have to support old BS2 markup with their CSS. If they even do that and don't override everything. I don't know.

The CMS (and all extensions) would have to do it the other way around, supporting both BS2 and BS3 markup in core output. Which to my knowledge is tricky.

[Troy]

Bear

On 2/13/2014 15:00, Bakual wrote:
> We don't maintain it. We just use it. It's a difference.
>

but if we stay with 2.x and twitter has made it EOL aren't we committing
to maintaining it?

> As said already. If someone has a good idea how we can move to BS3
> without breaking all existing templates and extensions which are based
> on BS2, then we are all listening.
> To my knowledge, there is no easy solution for that, but I may be
> wrong of course.
>

since even the existing bs2 breaks some templates i think its an
impractical thing to try to please both versions.
as it is some of the larger frameworks like yootheme can't work well
with core boostrap. The cms and joostrap are the only 2 i know of that
are actually using bootstrap and not some variant of it.

[Niv Froehlich]

I think we are suffering from an acute case of  incurable "Versionitis."

That's the trade-off

1) Don't follow the standard (i.e. Bootstrap 2.3.2) set by Joomla! CMS is favour of your own flavour - kiss consistency among extensions good-bye - in other words, it's back to square one on this; or

2) Follow the prescribed standard, accept that we are using a legacy version of Bootstrap, and hope that the extension developers follow suit - gaining that consistency.

Which set of problems is the 'lesser evil'?

Personally, I'm still waiting for a specific 'drawback' of BS 2.3.2 to be identified - i.e. some kind of bug or shortcoming that makes BS 2.3.2 unfit for professional grade production sites.

This may come - but I haven't heard of anything yet.  

Yes 2.3.2 is no longer officially supported by the kids at Bootstrap, but there is a broad community using it, so in it's ubiquity, if there are any major bugs discovered there will be solutions available.

To the best of my knowledge, at this point in time no major bugs or shortcomings have been identified with BS 2.3.2) that make the 2.3.2 version less than 'professional grade.'

IMHO, that's a pretty good red light indicator of when switching to a more recent version of Bootstrap changes from being a luxury to a necessity.

N

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

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

[Troy]

Niv dont' get me wrong, I love that j! has standardized on a particular framework.  Especially such a powerful yet easy to use one.  infact I'm disappointed in all the variants of bootstrap because it takes away from this very standardization.  I honestly don't care which we use.
I was simply responding to the 2.3 > 3.x statement.  I'm not smart enough about ether version to even begin to argue their merits.

Bear

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

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

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

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

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

No virus found in this message.

Checked by AVG - www.avg.com

Version: 2014.0.4335 / Virus Database: 3705/7091 - Release Date: 02/13/14

[Niv Froehlich]

Troy - I get it - and kudos for asking the tough questions - they need to be asked and you make some valid points to which I'm very sympathetic (and in truth - often on the fence about).

I imagine, hypothetically speaking, if Joomla! forked Bootstrap 2.3.2. (call it JomStrap (Joostrap is already taken and Jockstrap sounds...well...just plain wrong)) - and made some improvements to the framework.  We would have then standardized on JomStrap 1.x - nobody would be concerned that the core does not ship with JomStrap 2.x - because it wouldn't have existed (hence would be using the 'latest and greatest' version of the framework) - and that in itself probably would have solved the 'Joomla!/Bootstrap versionitis' problem.

I'm not suggesting that course of action would have been the right one - but it seems that there is no way of getting around the 'freeze and standardize - then revolutionize on the next major version iteration' approach - I think within the Joomla! ecosystem, we have to remember to focus on the benefits of that approach - it does provide some much needed level predictably and stability - as I see it, those benefits far outweigh and perceived drawbacks.

N

[Chad Windnagle]

Hi All:

Niv I want to respond to you specifically regarding some of the things I feel Bootstrap 3 does better than Bootstrap 2. The biggest / main reason IMHO is semantics.

If you are a developer and you want to build highly customized sites (everything from a custom PSD to Joomla template, tons of overrides for core stuff and a few potential 3rd party overrides), and you care about semantics in your class names, BS3 is far easier to work with. Here's an example of how that works (using LESS)

BS2:

.products-row { // makes a row

.make-row();

 .product-item {

     .make-column(4);

  }

}

This is going to generate a grid-like CSS with something like a row and then within that row of the grid you'll have items that are something like 320-ish pixels each (I'm guessing on the PX but hopefully you get the idea and it's not that important).

The problem here is now we have some nice semantic names for a class. But it only works at one viewport size. If you wanted to have 'different' column widths for different viewports you then are having to custom write each of the media queries:

@media (min-width: 960px) {

 .products-row { // makes a row

.make-row();

 .product-item {

     .make-column(3);

  }

}

}

And then again for a tablet at say 767px, and then possibly again for a phone where you might decide to give up the grid and just go 100% for each item. 

How does BS3 fix that? It has a much nicer column build method:

.products-row {

.make-row();

  .product-item {

    .make-sm-column(6); // less room so larger columns side by side

    .make-lg-column(4); // more room so more columns

   }

}

No additional media queries are necessary here. The .make-xx-column methods allow you to simple reference the column width based on extra small, small, medium, and large devices. This can potentially reduce repeated LESS code (not compiled CSS really) by a factor of 3x if you are writing a media query for 3 different break points. 

In addition to this semantic improvement I also feel there are improvements for support of things like screen readers and other accessibility related concerns. A lot of this work still has to be done manually by a developer but there are some useful things like the .sr-only command (screen reader only). 

Finally there is the 'flat design' reason. If you've ever had to create a design based on BS2 and had to do all the work to remove all the extra bevels and shadows and whatnot, the flat design is a major breath of fresh air! It allows you to avoid spending your time clearing out all sorts of values for things like buttons and focus on getting the design right. Then if you want the bevels it's as easy as overriding the .btn class and adding it in. 

Regarding some BS2 bugs: there is used to be a bit of an issue with navigation in BS2 and click-events for top level menu items. Here's some detailed information on the bug:

https://github.com/twbs/bootstrap/issues/4550

I'm not sure if this is fixed in Joomla or not, I know I saw some javascript that attempted to fix it but I do recall still having some issues. I'm unsure if it's still an ongoing issue (It was on 3.1, but not sure about 3.2).

--

My thoughts:

I agree focusing on 'version' of this that we are using is not a good position. I also completely understand the issue that it would introduce to template developers who have used the API and written their code to be BS2 compliant. Something we all begged them to do a few short months ago. Personally I'm actually building a site now on Joomla 1.5 (don't ask!) on BS3 and its actually been easier than building a template and site on Joomla 3 with BS2. It might be the design that I have to work with that makes it easier but I know some of it are the code-related reasons cited above. 

But I also recognize that once Joomla 3.5 hits, we are stuck with whatever we've got. In my opinion, changing now so that when we  do reach 3.5 we are using something that is both great to work with from a developer's perspective, not out-dated from a code-library perspective would be best time to make such a move. I'm torn whether or not I think we actually should, though. 

I don't know how backwards compatible we could be. I'm fairly certain CSS / LESS wise, we could write a LESS sheet that simple took some removed BS2 class names and keyed them into the new BS3 classnames. That wouldn't be hard at all. 

I think the hardest part would be the javascript and any markup changes. Any of the JS calls that use the same method names but act differently or require different markup would definitely be broken without much fix. So I see issues there.

On the whole, i'm on the fence. Part of me wants to be able to use the latest and greatest of BS3, part of me want to stay committed to our development strategy to not introduce known non-BC code into the core and support our developers. 

-Chad

Regards,
Chad Windnagle

[Beat]

Thanks Chad for bringing very strong and good arguments for Bootstrap 3.

That said, it is possible to have both bootstrap 2 and 3, using CSS namespacing in the Less file for the content parts that want Bootstrap 3.

We have successfully done that for Community Builder 2.0 in frontend and backend. Simply add a class e.g. "jbs3" on the enclosing DOM element to which bootstrap 3 should apply and have a special LESS file for bootstrap 3.

Then add an API call like we have for bootstrap2, so that components that want bootstrap3 can load it.

Thus depending on component(s) and module(s) executing you can load one of them or both.

That allows at same time backwards compatibility and progressive conversion to bootstrap 3 and could be introduced in Joomla 3.3 already, imho.

Best Regards,
Beat
http://www.joomlapolis.com/

[Bakual]

That sounds interesting!

[Angie Radtke]

Hi


What we can do to make BS3 BWC is something like that


variables.less

@columns: ".col-1,span1,.col-2,.span2..........";
@column1: ".col-1,.span1";
@column2: ".col-2,.span2";
........

grid.less

(~'@{columns}')
{
position: relative;
// Prevent columns from collapsing when empty
min-height: 1px;
// Inner gutter via padding
padding: @box-padding-top;
padding-left: (@grid-gutter-width / 2);
padding-right: (@grid-gutter-width / 2);
padding-bottom:@box-padding-bottom;
}


(~'@{column2}') { width: percentage((2 /
@grid-columns))-(@grid-gutter-width); }
(~'@{column3}') { width: percentage((3 /
@grid-columns))-(@grid-gutter-width); }
(~'@{column4}') { width: percentage((4 /
@grid-columns))-(@grid-gutter-width); } ...etc Bye Angie

[Markus Bopp]

+1 on prefixing BS3 to keep BS2 compatibility and having a smooth transition.

[Niv Froehlich]

There are some really amazing ideas being presented here.  I've been unfortunately too tied up the last few days to really explore these further (esp. what Angie is proposing above).

Some questions that I would have, which would require some testing, is

1) What 'unforeseen' and 'unexpected' results might happen?

2) Given the ubiquity of Bootstrap, surely others out there must be working on the same type of bridge (i.e. CSS/LESS that will make allow both 2.3 and 3 to play together).

That said:

a) Googling 'migrating bootstrap 2 to 3' (and other related terms) brings up a lot of useful and helpful info - at least part of the work is done - but I haven't found anything that shows a bona fide solution (however, if somebody does, please share!!!)

b) One of the Bootstrap developers popped on the Joomla! Forum about 6 to 8 months ago - I can't find the exact post - but he did make it clear that he is interest in feedback from the Joomla! community - so perhaps we can pose the question of how to maintain BWC for 2.3 while transitioning.

Once I can come up for air, I'll formulate a problem desc for the Bootstrap Google Group (twitter-...@googlegroups.com) - stir the pot and see what comes up!

N

On Mon, Feb 17, 2014 at 11:56 AM, Markus Bopp <koeln...@gmail.com> wrote:

+1 on prefixing BS3 to keep BS2 compatibility and having a smooth transition.

--

[Youjoomla.com]

I am getting ready to release and update for our framework and only way I could solve BS2.BS3 issue

is by adding a switch in template manager and give users option to switch 

http://prntscr.com/2tlaru

Note , we are not using Joomla default BS but have both versions inside the plugin. 

This is work in progress and buttons can be transitioned by adding extra class name 

http://prntscr.com/2t1s5w

This is last on my agenda and I am sure markup is changed for some css components but I rather add extra class 

than have extra sets of components overrides files for each bs version. 

If I find better solution I will post here but a bs2/bs3 switch is not a bad idea so far.

--

Best Regards
Dan Casky
Youjoomla Customer Service
1670 Southgate Mill DR NW
Duluth ,GA
30096
-------------------------------
www.youjoomla.com
Professional Joomla Web Design Services

[Niv Froehlich]

+1 on the bs2/bs3 switch idea.

Anybody look at the Bootstrap roadmap?  This problem (which I've labelled "Bootstrap Versionitis") does not end with Bootstrap 3 - what happens with the next iteration?

See http://blog.getbootstrap.com/ for the release of 3.1.1

There is now a SASS port (BS 3.1 is available in both LESS and SASS - but will BS maintain both or opt to transistion to SASS) - we're going to have to cross that bridge when it comes (I don't have experience with SASS, but see it's advantages and it seem folks who use both prefer SASS) - so that might also be a change coming down the pipeline. 

I think that incorporating a switch is a great idea, some 'quick check' features in the admin to show, at glance which templates and which extensions support which version of Bootstrap, and extension developers providing updates for the latest Bootstrap version might be a great way to solve this problem - it's not perfect but at least provides a unified way to allow for 'early adopters' to begin the transitioning process and stay ahead of the curve.

If we keep the current standard at 2.3.2 (which is understood to be set in stone) (i.e. design first for 2.3, then begin to provide an accepted process and easy-to-use features to identify available updates) - this might be a very effective way to transition - and perhaps an acceptable method for a) having a defined standard (as the minimum requirement); while b) allowing forward thinking template designers and extensions developers to start integrating new versions of Bootstrap without being held-back; and c) without breaking BWC.

N 

[Philip Locke]

Thought it was about time I chimed in, seeing as Joostrap.com has been mentioned several times.

I can't give any 'eureka' statements - I just wanted to give you some of my finding since moving Joostrap to BS3 and my thoughts.

Firstly, as you know:

a) Joostrap is just a frontend template.

b) The template doesn't call or use any BS related media items from core in it's latest templates/backbone.

c) All BS/Jquery/etc is called from within the template, or from the respective cdn's via template param switches. This means I don't have to wait for core BS updates and I can give Joostrap users the latest & greatest BS code via a new release as soon as it is out there.

d) All of the main or required com_whatever items have been over ridden in the html folder to accommodate BS3.

From testing & experience I can also tell you that I have had very few issues running both BS2/BS3 together on the frontend. 

i.e. one of the extensions I have exhaustively tested is JomSocial which runs on BS2.

(see BS2/BS3 example here: http://www.youtube.com/watch?v=IpAcgiUWvg0)

Because Joostrap is BS3 based and runs almost autonomously to the core (you know what I mean, from a frontend perspective), I am in a position where I actually don't care about the BS version in core, it doesn't effect me <--- obviously not true, I do care. 

BS3 would give the Admin & 3pd's such a cool experience moving forward, with mobile first, etc... 

I personally think & agree that incorporating a switch is a great idea, via a 'quick check/lookup' in the admin. 

I also think that keeping BS v2.3.2 is important to allow people to transition over time and for things to be BWC.

Adding the 'quick check/lookup' will give people the knowledge of what's installed/required. Then using Youjoomla's approach with both BS versions via a plugin, they then can switch to one or the other.

Phil

Philip Locke

www.Joostrap.com
www.FastnetWebDesign.co.uk

Joomla! CMS Specialists 
Mobile: 07960 155539 Mail: ph...@fastnetwebdesign.co.uk
Philip Locke an ex-member on the Board of Directors for the Joomla/OSM Project

[Hannes Papenberg]

And among all this discussion, I don't understand why people don't push
more towards a distribution approach. With that approach, we would have
the infrastructure to provide different core outputs for the extensions,
allowing people to choose a different, pre-made output. The different
subprojects could provide a BS2 and a BS3 output and maybe even more,
which you can drag&drop into your template overrides and presto, you
have your BS3. By default we ship with BS2 and keep our backwards
compatibility promise and at the same time we provide those more
adventurous, the means to use BS3.

Hannes

> <mailto:twitter-...@googlegroups.com>) - stir the

> pot and see what comes up!
>
> N
>
>
> On Mon, Feb 17, 2014 at 11:56 AM, Markus Bopp
> <koeln...@gmail.com <mailto:koeln...@gmail.com>> wrote:
>
> +1 on prefixing BS3 to keep BS2 compatibility and
> having a smooth transition.
> --
> You received this message because you are subscribed
> to the Google Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving
> emails from it, send an email to
> joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

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

> <mailto:joomla-...@googlegroups.com>.

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

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

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

> <mailto:joomla-...@googlegroups.com>.

> Visit this group at
> http://groups.google.com/group/joomla-dev-cms.
> For more options, visit
> https://groups.google.com/groups/opt_out.
>
>
>
>
> --
> Best Regards
> Dan Casky
> Youjoomla Customer Service
> 1670 Southgate Mill DR NW
> Duluth ,GA
> 30096
> -------------------------------

> www.youjoomla.com <http://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 unsubscribe from this group and stop receiving emails from
> it, send an email to
> joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

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

> <mailto:joomla-...@googlegroups.com>.

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

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

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

> <mailto:joomla-...@googlegroups.com>.

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

> *Philip Locke*
> *www.Joostrap.com <http://www.joostrap.com/>
> **www.FastnetWebDesign.co.uk <http://www.fastnetwebdesign.co.uk/>*
> *Joomla! CMS Specialists*

> Mobile: 07960 155539 Mail: ph...@fastnetwebdesign.co.uk

> <mailto:ph...@fastnetwebdesign.co.uk>

> Philip Locke an ex-member on the Board of Directors for the Joomla/OSM
> Project

[Youjoomla.com]

+1 Hannes but this is going back to the old issue where none of us 

contributed to the question " Should we add bootstrap in frontend?" when that was in making. 

Our silence is now giving us trouble. I was one of the silent ones.

[Troy]

isn't this entire discussion kinda like arguing over whether 2.5 code should be supported in 3.x?/ 4.x?
if 2.3.2 is EOL then why are we pushing to keep it?  Its like arguing to keep J! 2.5.x in active dev.

Bear

No virus found in this message.

Checked by AVG - www.avg.com

Version: 2014.0.4335 / Virus Database: 3705/7102 - Release Date: 02/17/14

[Michael Babker]

Nobody's arguing to keep it outside the 3.x series as far as I can tell.  But, we can't just up and rip out Bootstrap 2.3.2 and replace it with 3.1 and tell extension developers to deal with it or go write code for WordPress; some of the changes are just too great to deal with without breaking B/C, hence this discussion.

[Niv Froehlich]

Is there anybody who feels that providing a 'switch' as suggested by YooJoomla and Philip is not a good idea?

What would be the downsides?

(to quote Philip)

I personally think & agree that incorporating a switch is a great idea, via a 'quick check/lookup' in the admin. 

I also think that keeping BS v2.3.2 is important to allow people to transition over time and for things to be BWC.

Adding the 'quick check/lookup' will give people the knowledge of what's installed/required. Then using Youjoomla's approach with both BS versions via a plugin, they then can switch to one or the other.

This could handled in the XML manifest with one element (allowing site owners to check their extensions, when updated, for compatibility and then switch).

It also allows extension developers to get into production without delay - and then provide an update when ready.

This an approach that could also be carried forward for future versions of Bootstrap.

Right now this seems like the winning solution - it respects BWC, while opening the door and encouraging forward progression.

I think the key is, at this point, to make B2.3 compatibility mandatory, and provide for an 'optional' B3.x version (right now BS is at 3.1.1)

It also solves the problem of potentially bloated CSS/LESS which tries to incorporate both sets of styles from BS 2.3 and BS 3 (although this suggestion is not bad either).

At some point in time, 2.3 can be deprecated, for example, with J! v4+ 

This is not a bad imposition on template and extension developers - CSS and associated frameworks are constantly progressing, so it's expected anyways that folks will be updating their UI's to keep up.

N

[Matt Thomas]

On Tue, Feb 18, 2014 at 12:41 PM, Niv Froehlich <nivsemail@gmail.com> wrote:

Is there anybody who feels that providing a 'switch' as suggested by YooJoomla and Philip is not a good idea?

I can't answer that question until I see how it's implemented. For example, how does that account for all of the core views?

Best,

Matt Thomas

203.632.9322
http://betweenbrain.com/

[Youjoomla.com]

I am not sure if anyone here is on the same page as I am right now ( conversion BS2/BS3 ) but 

I will see all details in few days thus I will also be able to answer  Matt's question " For example, how does that account for all of the core views?" 

since we always had core overrides in templates http://prntscr.com/2tnxcv.

Thinking out loud only thing that I might be concerned is com_contact where accordion was used. I think that changed. 

Other than that I found plenty of btn class names that just need a sibling class defining the size of the button.

Like said few more days and I will know more. Will advise A.S.A.P.

--

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

[Niv Froehlich]

@ Matt - you folks are far more talented and experienced than I (by miles and miles), but I imagine that would be the extension developers' issue to deal with, and that the core views will be 'locked in' for the J! 3.x life-cycle.

But again...the details, are of course in the implementation...

--

[G.D. Speer]

>"I imagine that would be the extension developers' issue"

My sense it that it should not be something that extension developers deal with because they deal with it inconsistently.  I thought the central goal of adopting BS in the first place was to harmonize the HTML and class syntax put out by all aspects of the rendered page.  To have consistent element structures so that one set of styling rules using BS as a glossary of class names to be styled would produce consistent results for any extension.  Thus whether BS is actually loaded or not, the front end stylist has a consistent set of class names and element structures to style.  Drop in a new extension and it just works with existing template CSS.  BS not being BC causes challenges because the negotiated interface (front end API) changes, but a superset of BS 2+3 classes, where BS allows that to work, seems to solve most plug and play issues.  Am I off target?  I see BS as a step toward reaching a predictable and consistent semantic.org fron end interface designers API

Looking forward to YouTheme's analysis.

/D


----- Original Message -----

[Hannes Papenberg]

I am not happy with adding a switch. It means that you have to implement
2 different outputs for each layout for a component. While that might
not be a "big" issue to implement for the core, I can already guarantee
you, that we will have a divide by this in the community. There will be
the extensions that stick to 2.3 and those that will provide outputs
only for 3.1 and also a third group that provides for both. What do you
do as a user when you want to use extensions that only support 2.3
together with those only supporting 3.1? I also don't believe that
yet-another-option is the answer to every little problem that we have.
It is actually the opposite. Options will be the death of us. (tongue in
cheek)

Let me give you a different example: Imagine Joomla goes the
distribution way and we make it easy to adopt new extensions. Now there
are maybe 30 extensions out there to add google analytics to your site.
Joomla decides "We clean that up and provide this as a community
supported extension". Now there are 2 possible outcomes. Either Joomla
really provides an extension and everybody switches over to that or you
now have 31 extensions that add google analytics to your site. While in
this example, there is a 50/50 chance of the former to happen, I already
know that an option to switch between BS2 and BS3 will a) confuse people
and b) raise the next round of requests to extend that to
the-next-big-css-framework.

In theory, I don't care which CSS framework we standardize on. I might
even prefer BS3 over BS2, since BS2 requires me to reset more stuff back
to what I really want instead of BS3. But I know one thing for sure: We
need to definitely standardize on ONE framework! Not 2, not 3, but on
one. (Yes, I wrote that we could provide more flexibility in a
distribution system earlier, which I take back in hindsight. Take it as
an attempt to push the distribution idea in the community.) We need to
find a healthy set of options and a healthy attitude towards overrides
and handcrafted solutions.

All that said: We standardized on BS2 for Joomla 3.x and that is what we
should stick to until the end of the 3.x series.

Hannes

>> <hack...@googlemail.com <mailto:hack...@googlemail.com>>

>> > <mailto:nivs...@gmail.com

>> <mailto:youjoo...@gmail.com

>> <mailto:nivs...@gmail.com> <mailto:nivs...@gmail.com

>> > <mailto:twitter-...@googlegroups.com

>> <mailto:twitter-...@googlegroups.com>>) - stir the
>> > pot and see what comes up!
>> >
>> > N
>> >
>> >
>> > On Mon, Feb 17, 2014 at 11:56 AM, Markus Bopp
>> > <koeln...@gmail.com
>> <mailto:koeln...@gmail.com>

>> <mailto:koeln...@gmail.com

>> <mailto:koeln...@gmail.com>>> wrote:
>> >
>> > +1 on prefixing BS3 to keep BS2
>> compatibility and
>> > having a smooth transition.
>> > --
>> > You received this message because you
>> are subscribed
>> > to the Google Groups "Joomla! CMS
>> Development" group.
>> > To unsubscribe from this group and stop
>> receiving
>> > emails from it, send an email to
>> >
>> joomla-dev-cm...@googlegroups.com
>> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>
>> >

>> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com
>> <mailto:joomla-dev-cms%252Buns...@googlegroups.com>>.

>> > To post to this group, send an email to
>> > joomla-...@googlegroups.com
>> <mailto:joomla-...@googlegroups.com>

>> > <mailto:joomla-...@googlegroups.com

>> <mailto:joomla-...@googlegroups.com>>.
>> > Visit this group at
>> >
>> http://groups.google.com/group/joomla-dev-cms.
>> > For more options, visit
>> > https://groups.google.com/groups/opt_out.
>> >
>> >
>> > --
>> > You received this message because you are
>> subscribed to
>> > the Google Groups "Joomla! CMS Development"
>> group.
>> > To unsubscribe from this group and stop
>> receiving emails
>> > from it, send an email to
>> > joomla-dev-cm...@googlegroups.com
>> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>
>> >

>> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com
>> <mailto:joomla-dev-cms%252Buns...@googlegroups.com>>.

>> > To post to this group, send an email to
>> > joomla-...@googlegroups.com
>> <mailto:joomla-...@googlegroups.com>

>> > <mailto:joomla-...@googlegroups.com

>> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com
>> <mailto:joomla-dev-cms%252Buns...@googlegroups.com>>.

>> > To post to this group, send an email to
>> > joomla-...@googlegroups.com
>> <mailto:joomla-...@googlegroups.com>

>> > <mailto:joomla-...@googlegroups.com

>> <mailto:joomla-...@googlegroups.com>>.
>> > Visit this group at
>> http://groups.google.com/group/joomla-dev-cms.
>> > For more options, visit
>> https://groups.google.com/groups/opt_out.
>> >
>> >
>> > --
>> > You received this message because you are
>> subscribed to the Google
>> > Groups "Joomla! CMS Development" group.
>> > To unsubscribe from this group and stop receiving
>> emails from it,
>> > send an email to
>> joomla-dev-cm...@googlegroups.com
>> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>
>> >

>> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com
>> <mailto:joomla-dev-cms%252Buns...@googlegroups.com>>.

>> > To post to this group, send an email to
>> > joomla-...@googlegroups.com
>> <mailto:joomla-...@googlegroups.com>

>> > <mailto:joomla-...@googlegroups.com

>> <mailto:joomla-...@googlegroups.com>>.
>> > Visit this group at
>> http://groups.google.com/group/joomla-dev-cms.
>> > For more options, visit
>> https://groups.google.com/groups/opt_out.
>> >
>> >
>> >
>> >
>> > --
>> > *Philip Locke*

>> > *www.Joostrap.com <http://www.Joostrap.com>
>> <http://www.joostrap.com/>
>> > **www.FastnetWebDesign.co.uk
>> <http://www.FastnetWebDesign.co.uk>

>> <http://www.fastnetwebdesign.co.uk/>*
>> > *Joomla! CMS Specialists*
>> > Mobile: 07960 155539 Mail: ph...@fastnetwebdesign.co.uk
>> <mailto:ph...@fastnetwebdesign.co.uk>

>> > <mailto:ph...@fastnetwebdesign.co.uk

>> <mailto:ph...@fastnetwebdesign.co.uk>>
>> > Philip Locke an ex-member on the Board of Directors for
>> the Joomla/OSM
>> > Project
>> > --
>> > You received this message because you are subscribed to
>> the Google
>> > Groups "Joomla! CMS Development" group.
>> > To unsubscribe from this group and stop receiving
>> emails from it, send

>> > an email to joomla-dev-cm...@googlegroups.com

>> <mailto:joomla-dev-cm...@googlegroups.com>.

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

>> No virus found in this message.
>>
>>

>> Checked by AVG - www.avg.com <http://www.avg.com>

>> Version: 2014.0.4335 / Virus Database: 3705/7102 - Release
>> Date: 02/17/14
>
> --
> You received this message because you are subscribed to the
> Google Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to

> joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.
> To post to this group, send an email to
> joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.
> To post to this group, send an email to
> joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --

[Chad Windnagle]

I'm not sold on the switch idea purely because I'm not sure I understand what it will do yet.

Will the switch have several states that load bootstrap 2, bootstrap 3, or both versions of bootstrap? If someone selects both what version will the JHtml APIs use? (in terms of markup and javascript). If I could get some clarity on the intentions that would help me be a yay or nay on this. 

Regards,
Chad Windnagle

[Hannes Papenberg]

That switch can only switch between BS2 and BS3 output of the
extensions. Loading any CSS is the job of the template, not of Joomla.

> <http://semantic.org> fron end interface designers API

>
> Looking forward to YouTheme's analysis.
> /D
>
>
> ----- Original Message -----
>

> *From:* Niv Froehlich <mailto:nivs...@gmail.com>
> *To:* joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>
> *Sent:* Tuesday, February 18, 2014 10:51 AM
> *Subject:* Re: [jcms] Re: Joomla and Twitter Bootstrap 3.x

>
> @ Matt - you folks are far more talented and experienced than
> I (by miles and miles), but I imagine that would be the
> extension developers' issue to deal with, and that the core
> views will be 'locked in' for the J! 3.x life-cycle.
>
> But again...the details, are of course in the implementation...
>
>
> On Tue, Feb 18, 2014 at 12:44 PM, Matt Thomas
> <ma...@betweenbrain.com <mailto:ma...@betweenbrain.com>> wrote:
>
> On Tue, Feb 18, 2014 at 12:41 PM, Niv Froehlich
> <nivs...@gmail.com <mailto:nivs...@gmail.com>> wrote:
>
> Is there anybody who feels that providing a 'switch'
> as suggested by YooJoomla and Philip is not a good idea?
>
>
> I can't answer that question until I see how it's
> implemented. For example, how does that account for all of
> the core views?
>
> Best,
>
> Matt Thomas
> 203.632.9322

> http://betweenbrain.com/ <http://betweenbrain.com/>

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

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

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

> <mailto:joomla-...@googlegroups.com>.

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

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

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

> <mailto:joomla-...@googlegroups.com>.

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

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

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

> <mailto:joomla-...@googlegroups.com>.

[Troy]

Thanks hannes that kinda what I was thinking... my simplistic brain says
to use the same verbage for all extensions but of course that won't work
if we are using different engines.
you covered alot of what I was thinking.
Bear

[Bakual]

The API call loads Bootstrap JavaScript, not CSS ;)

[kisswebdesign]

Ideally the core should not add any style or HTML, just provide content and let the template handle ALL the front end stuff.

I get why Joomla has done things the way it has, but I would really want to decouple the back end stuff from the front end.

Devs can forget about HTML and CSS and concentrate on providing content/data to the template.

This way there would not be any discussions about which framework to standardise on. That decision is the template designers' to make.

Back to the present...

Converting to/from BS versions could be handled by a plugin, replace bs2 class names with bs3 class names.
Replace the bs2 JS (from JUI) with bs3 JS.
Restructure the HTML where necessary (accordion, menu, etc).
Thus giving the illusion of bs3 - of course this is resource expensive, writing the output twice before rendering.
There could be plugins for any framework.
Not easy to do, but should be possible, and is a one off install.

Or override every view of every core and extention, and maintain them in line with any updates (but that's a big and ongoing undertaking).

I firmly believe that the long term goal should be to remove any style, HTML or JS from the core (and extentions) and allow the template designers full control over the site design (UI, UX, etc).

I would love to see the output to the template be JSON, with a defined structure for giving the template an idea of what the functions are...

form
Field
Label: name
Type: text
Field
Label: email
Type: email
Button
Type: submit
Entrypoint: /com_mine/form/subscribe

for example - very quick and dirty example.

Or

Article
Options
Type: xxx
Permissions: 1.0 2.1 3.0
Etc...
Content
String: "exact copy of the article content, including any images HTML, special tags, etc."
Plugins
Myplugin
TagInString: [MYPLUG]
Type:
Etc.
Meta
Author: me
Date: dd/mmm/yyyy
Etc.

Everything is still rendered server side, no need to change that, unless someone wants to do it client side if course - but that opens up a whole load of new challenges.

The specification of the format would be the hardest part, then getting all the extention devs and template designers to implement such a huge and non bc change - not to mention the core.

This does make template design and development a lot more complicated, but template frameworks could make that much simpler for new designers - or a couple of example starter templates maintained in the joomla GitHub account - along with some detailed documentation (yeah, I know).

For now though, I'd prefer plugins to rewrite the output for whatever framework you want to support.

If this has rambled a bit it's because I'm writing on my phone, so have pity :-)

Chris.

[G.D. Speer]

What if its a plugin that searches for BS2 patterns and replaces with
equivalent BS3 patterns?

----- Original Message -----
From: "Hannes Papenberg" <hack...@googlemail.com>
To: <joomla-...@googlegroups.com>

[Bakual]

Actually, what we really would need is a semantic standard unrelated to any framework. So any template could just assign the framework classes to the core classes using mixins.

I know some people are trying to do that, but it's a lot of work.

>>             <mailto:joomla-dev-cms%252Bunsubscribe@googlegroups.com>>.

>>             >                 To post to this group, send an email to
>>             >                 joomla-...@googlegroups.com
>>             <mailto:joomla-...@googlegroups.com>
>>             >                 <mailto:joomla-...@googlegroups.com
>>             <mailto:joomla-...@googlegroups.com>>.
>>             >                 Visit this group at
>>             >                
>>             http://groups.google.com/group/joomla-dev-cms.
>>             >                 For more options, visit
>>             >                 https://groups.google.com/groups/opt_out.
>>             >
>>             >
>>             >             --
>>             >             You received this message because you are
>>             subscribed to
>>             >             the Google Groups "Joomla! CMS Development"
>>             group.
>>             >             To unsubscribe from this group and stop
>>             receiving emails
>>             >             from it, send an email to
>>             >             joomla-dev-cm...@googlegroups.com
>>             <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>
>>             >            
>>             <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com

>>             <mailto:joomla-dev-cms%252Bunsubscribe@googlegroups.com>>.

>>             <mailto:joomla-dev-cms%252Bunsubscribe@googlegroups.com>>.

>>             >         To post to this group, send an email to
>>             >         joomla-...@googlegroups.com
>>             <mailto:joomla-...@googlegroups.com>
>>             >         <mailto:joomla-...@googlegroups.com
>>             <mailto:joomla-...@googlegroups.com>>.
>>             >         Visit this group at
>>             http://groups.google.com/group/joomla-dev-cms.
>>             >         For more options, visit
>>             https://groups.google.com/groups/opt_out.
>>             >
>>             >
>>             >     --
>>             >     You received this message because you are
>>             subscribed to the Google
>>             >     Groups "Joomla! CMS Development" group.
>>             >     To unsubscribe from this group and stop receiving
>>             emails from it,
>>             >     send an email to
>>             joomla-dev-cm...@googlegroups.com
>>             <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>
>>             >    
>>             <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com

>>             <mailto:joomla-dev-cms%252Bunsubscribe@googlegroups.com>>.

>>         <mailto:joomla-dev-cms+unsub...@googlegroups.com>.

[Paul Orwig]

+1 for the idea of a semantic standard unrelated to any framework.

If agreement can be reached for that or another option, perhaps a code sprint could be organized to help get the work completed.

Thanks,

paul

[Michael Babker]

On Tue, Feb 18, 2014 at 2:19 PM, kisswebdesign <chris.jo...@kisswebdesign.co.uk> wrote:

Devs can forget about HTML and CSS and concentrate on providing content/data to the template.

 

While good in theory, it does cripple devs in terms of support and documentation.  If we don't know how templates are rendering our data, how can we provide support, documentation, demos, etc.?

 

I would love to see the output to the template be JSON, with a defined structure for giving the template an idea of what the functions are...

 

So, out of the box, how would the CMS work?  If there is a dependency on a template actually being installed, does the CMS still ship one?  Who decides how it should work (framework, JS dependencies, etc.)?

[brian teeman]

Sorry but everyone talking about going back to the days of a free forall in terms of out out is living in cloud cookoo land. Have you forgotten that before a standardised system (which happens to be BS2) templates had to have styling for every extension on the site. Extension developers produced really really bad markup etc etc

[Roberto Segura]

I'm already using a custom solution: layout suffixes/prefixes. For example:

I specify on my template to use a BS3 prefix. Layouts would be searched on this order:

layouts/bootstrap3/joomla/.....
layouts/joomla/....

so we are telling layouts to search a specific bootstrap3 layout and if not rely on the default ones. Same thing can be used with suffixes:

layouts/joomla/content/tags.bs3.php

layouts/joomla/content/tags.php

if tags.bs3.php doesn't exist it will load the default layout.

For views it can be done the same way:

mod_search/default.bs3.php

mod_search/default.php

I think I would use prefixes because you have all the bootstrap3 files under the same folder.

For views it can be done the same way:

mod_search/default.bs3.php

mod_search/default.php

It's only add 10-15 lines of code.

I'm already using this solution and works perfectly. For fields I also have introduced the layout system (which would be required to make all this work). JFormField has a default function getLayout() that returns an instance of JLayoutFile (which also allow 3rd part developers to override the class returned while it implements JLayout). Then you can insert there any prefixes you want. In fact for fields I'm using an specific attribute layout="field.whatever". This allows you to fully change the behavior of JFormFieldList without having to write a new field. You just specify a different layout for the same field (that can load BS3, BS2 / whatever).

So a simple parameter in the templates will enable the BS3, Zurb5, whatever magic. If all is 100% overridable (we should ensure it is) it should be ok.

About namespacing bootstrap2 & bootstrap3 the only issue with that is in modals that are automatically appended before </body> tag. That makes namespacing not work for them. So we will need to search a different solution (maybe tweaking JS).

El miércoles, 12 de febrero de 2014 22:53:47 UTC+1, Kai Røen escribió:

I was wondering when Twitter Bootstrap 3 will be included in Joomla. There is so much great new improvements and features in TW3, and it would be so great to have a updated version in next version of Joomla.

What about have a option in Joomla administrator to choose TW2 or TW3?

[Neil Forrester]

as it was proposed back in 2012, the only acceptable solution is to create a native joomla css framework and get independent in this key-part of the cms. that stance still stands today and anything else is irresponsible and harmful to the project. as you can see now.

if a project like joomla is able to build an entire cms and a fully fledged php framework, then it should be able to build a reliable css framework. end of story.

[WooDzu]

On Tuesday, February 18, 2014 11:04:55 PM UTC, Neil Forrester wrote:

as it was proposed back in 2012, the only acceptable solution is to create a native joomla css framework and get independent in this key-part of the cms. that stance still stands today and anything else is irresponsible and harmful to the project. as you can see now.

This is the best suggestion I've seen in this tread. Someone has already mentioned there might be great Bootstrap 4 and even better 5 in the future adding the same sort of b/c like version 3 now.

[Michael Babker]

So to be blunt for a minute, Joomla isn't well known for finding and holding onto frontend developers for contributing to the core.  Folks come and go quite often.  If Joomla were to even consider building its own CSS framework, there would need to be a strong commitment from frontend folks to help build and maintain it.  If you leave it in the hands of PHP developers to maintain, it won't be very usable for very long.

[kisswebdesign]

1.
Me>

Devs can forget about HTML and CSS and concentrate on providing content/data to the template.

MB>

While good in theory, it does cripple devs in terms of support and documentation. If we don't know how templates are rendering our data, how can we provide support, documentation, demos, etc.?

Me>
Docs and demos can be done with a default template (one supplied with the CMS).
Support is a more difficult one, although first step in troubleshooting would be "is it the same in the default template?"
If no, it's your template (contact them). If yes, investigate further.
Docs for the back end would be the same as now (at least in my head) as the admin would stick with one default framework.

2.
Me>

I would love to see the output to the template be JSON, with a defined structure for giving the template an idea of what the functions are...

MB>

So, out of the box, how would the CMS work? If there is a dependency on a template actually being installed, does the CMS still ship one? Who decides how it should work (framework, JS dependencies, etc.)?

Me>
OK, I see it like this:
The CMS ships with a template, which is built using the same framework as the back end - eg bs2 at the moment.
Who decides on the framework used now? I guess the same person / people / process would do it.

---

Support from devs would be harder, no doubt, maybe the site debug option could include the actual JSON by module / component / plugin making it easier to provide support if the support request included this data.
Even if there was a debug flag for each extension that produces a log of it's output that can be included on a support request, rather than putting the whole site into debug mode.

There are plenty more issues I've not though about, along with others I have but are not relevant here.

And my thoughts are just the germ of an idea, there are other ways to decouple the content from the style / markup. Some have been proposed before, I'm sure.

[Mathew Lenning]

As a component developer I thought I could chime in here. I think we are really talking about two different problems. The first would be rendering the back-end, the second would be rendering the front-end. 

From my standpoint the only place that I need the CMS to be consistent with the CSS styling is the back-end. If someone is building an administrative template then they should be required to use the BS version currently supported by the CMS. If they choose not to, then having components broken on their site isn't the CMS's problem. 

As for the front-end, this should be left up to the template designer. I would argue that the CMS shouldn't load any CSS. Component developers should also refrain from adding styling to their components, instead they would be better serving their supporters by adding a component prefixed container and then teaching supporters how to tweak their components via the template CSS. 

Of course if you need special CSS for JavaScript functionality, just prefix your class names with "js-" and declare your styles. Since these cases are unique to each component, there is no need to have a standardized framework in place. 

My 2 cents     

[Bakual]

Just want to comment on that

Ideally the core should not add any style or HTML, just provide content and let the template handle ALL the front end stuff.

I get why Joomla has done things the way it has, but I would really want to decouple the back end stuff from the front end.

Devs can forget about HTML and CSS and concentrate on providing content/data to the template

... 

I firmly believe that the long term goal should be to remove any style, HTML or JS from the core (and extentions) and allow the template designers full control over the site design (UI, UX, etc).

I would love to see the output to the template be JSON, with a defined structure for giving the template an idea of what the functions are... 

Actually, that is what we do already. Yes we serve a template file with each extension, but a template isn't forced to use it. It's basically an example output which can be used, and it serves as a fallback if the template has no file for a specific extension / view.

All the raw data is available for the template, usually as an object $this->item or $this->items.

Why would you want the output to be json? You'd have to decode it again and end up with the exact same object you already can use as of today.

I agree that extensions should load the JavaScript withint a layout file, so it can be overriden by the template. That's already possible today and good practice.

The thing to consider is also that there are a lot of 3rd party extensions. If we would remove the HTML output from extensions and only server an JSON output, I'm sure those extensions would become unusable. Templates just can't provide the HTML / JS / CSS output for each extension the user may use. So we need a way to include example / fallback output in case the template doesn't provide its own.

And this is exactly how our current system works :)

[Angie Radtke]

Hi,


I think this topic is one of the most discussed once the last months /
last year.
If we take a look back, we see lots of different arguments and concerns
pro and contra using bootstrap.
There were very good hints how we can solve this issue and on the
other hand justified reasons what we should care about (BWC etc.)
But at the end of all these discussions there is no commitment for a
possible working solution.

The reason for that is: It is lots of work providing a solid solution
for that issue. We need a reliable and robust solution our users can
work with.
For me it it is important that we offer a well structured, good
organized and semantic correct markup( attaching a nice looking styles
/CSS).
Our core markup should have a role model function ( I don't know
the right english word I mean: german-> Vorbildfunktion)

Joomla is used some many times and we can change the quality of all
these websites build on Joomla!.
My focus is based on my thoughts about the importance of accessibilty.
It is great that people are caring about accessibilty building up
their own or customers websites, but this is drop in the ocean.
If we provide well structured markup we can lay down the foundation
stone for more accessible websites all over the world. But this is only
my motivation.

For the most of the others SEO optimization is the more effective
argument.

I think Michael was right. If we want to make evolutionary and
innovative changes in that area we need people working on that topic.
It is not a one man / woman show.

Bye Angie

[Seth Warburton]

Joomla has, unfortunately, become a CMS that is extremely difficult, or almost impossible, for any serious professional front-ender to work with so I don't really expect the situation Michael describes to change any time soon. This is a great shame.

Yes, Bootstrap is the most popular front-end development framework, with that I have no argument. McDonald's is the most popular restaurant in the world. Could we expect a Michelin star chef be happy presenting dishes created with items sourced from the McDonald's menu?

McDonald's certainly has it's place in the word, as does Bootstrap, and both make a lot of people very happy by meeting all of their requirements and standards. Joomla has, in my opinion, chosen to not offer anything to the gourmand front-ender.

The most upsetting aspect for me is that it simply doesn't have to be this way; Joomla can serve both Eggs Benedict and Egg McMuffins. There's no real reason to fix the menu permanently and in doing so we've limited the appeal of the cms, hampered the ability to quickly innovate on the front-end and hamstrung the ability to keep up with current best practices.

I see only one viable, long-term, solution to these and other issues and that is to move the presentation layer to the template. That allows the front-end to use Bootstrap, Pure, Foundation or KISSframework. It would mean that we could, for example, easily update to Bootstrap 3.x (or v5.8) at any point with no break in backward compatibility, it would be as simple as adding a Bootstrap 3 template.

I think if we are all honest with ourselves we'll see that the utopian ideal of a universally adopted standard simply hasn't materialised. Personally, I can't see how it possibly can. I don't know of a single template developer that isn't including their own version of Bootstrap in their templates (if they include Bootstrap at all) and even Joomla core backend does not follow Bootstrap markup examples (either v2 or v3). Yes, Bootstrap provides sample markup but it doesn't dictate when and how to use them, so one extension developers markup can be wildly different from each others despite an 'accepted standard'.

Even if it was decided to say 'screw you' to professional front-end developers I'd still suggest that it is easier to maintain a dependency like Bootstrap in a single place, and for the front-end that place is the template. 

“Can I update to Bootstrap 6?” 

“Sure, just update the assets and markup in the Bootstrap 5 template and we'll add the Bootstrap 6 template in the next minor release”.

“Won't that cause a BC break?”

“No. We won't make the new template the default until the next major release, Joomla 5.5.”

”Wow. Joomla Rocks!”

“It sure does Jimmy, it sure does.”

This is my vision of an inclusive modern CMS.

Regards,

Seth 

[brian teeman]

Visions are lovely but where is the code

[Seth Warburton]

We used to have exactly this…

[Neil Forrester]

brian, your bootstrap vision is now adding another layer of fragmentation on top the joomla project. one, joomla itself, is already enough as we have 2 parallel joomla versions and a release schedule that no user isnt willing to accept any longer.

just admit that using bootstrap has been a wrong strategic decision and let people outline their visions. it is the job of the joomla leadership to start sub projects like a native joomla css framework and call for volunteers but not playing it down in initial discusions and idea exchanges. it worked well for the php framework why should it fail on css? or  is it probably your personal preferences that you are trying to protect instead of doing some objective measurements and accept what is good for the project?

there are hundreds if not thousands of professional css gurus and template vendors who would love to participate. instead, and it is actually happening right now, template developers are now building bootstrap 3 templates, giving not much on extension developers markup. do you want to blame extension developers for that again? you already blamed extension developers enough for bad markups as all they were able to address were a few lousy button css classes until joomla 3.

if the fragmentation continues like that, upcoming projects like yootheme pagekit will overrun joomla in an instant. they gonna repeat wordpress DOS and avoid joomla DONTS while they are focusing on the marketshare of joomla. you should be warned and prepared.

[Amy Stephen]

People can mock this or hear it, either way, it's the truth.

[Vic Drover]

Agree.

Cheers,

Victor Drover
Founder and CEO, Anything Digital LLC (BBB Accredited)
Co-founder, Watchful.li & jInbound.com
262-309-4140
Facebook: AnythingDigital | watchfulli | JInbound
Twitter: @AnythingDig | @watchfulli | @JoomlaInbound

[brian teeman]

Neil I have no vision for using Bootstrap

I do have a vision for creating a CMS suitable for all. 99% of our userbase are in the mass marketplace. They do not have the luxury of crafting a custom template for every site. Currently the ONLY option on the table is the current bootstrap 2 option. 

Its all well and good stating that there are "hundreds if not thousands of professional css gurus and template vendors who would love to participate." the facts are different. There is NOTHING stopping anyone contributing. The reality is that they don't.

[Paul Orwig]

I agree with the recommendations from Angie and Seth.

I would like to see us looking for ways to give designers, developers and users more reasons for choosing (and eventually contributing to) Joomla, instead of other platforms.

I don't see Bootstrap as a mistake, I see it as a big step forward. But I also think it would be a mistake if we tell ourselves it was the final step.

For a challenge of this scale, I don't think it's realistic to expect volunteers a code a solution purely on hope/speculation.

I hope that PLT will consider the options, make a decision about what they feel is the best path forward, announce that decision and then give it their full support (including one or more code sprints if that decision is to adopt a new approach).

Thanks,

paul

--

[Leo Lammerink]

I agree basically Paul if we can overcome the limitations not being upwards (!) compatible in the Bootstrap framework. Whatever way we choose that for sure is an issue which has highest priority imho

Leo

[Markus Bopp]

Hi,

how do we know the PLT is discussing the options? Will they post possible options here or release an official announcement?

[Matt Thomas]

Speaking on behalf of myself, and not the entire PLT, it would be helpful if those that are proposing solutions do so as a gist or Google Doc so that we can organise and evaluate them equally. It's honestly quite hard to pluck them out of an email thread like this. I would also hope that those proposing the potential solutions are also making a commitment to make them a reality.

Best,

Matt Thomas

203.632.9322
http://betweenbrain.com/

[Niv Froehlich]

@ Leo

I agree basically Paul if we can overcome the limitations not being upwards (!) compatible in the Bootstrap framework. Whatever way we choose that for sure is an issue which has highest priority imho

+1 on this

The nature of our environment, whether discussing back-end or front-end technology, is one of constant change.

It seems that this accommodation (i.e. of being upwards (!) compatible) is a 'no brainer' for the back-end work going on, but for some reason, we have yet to agree on transitional approach for the front-end framework - and I find that dichotomy to be rather strange.  I struggle to understand the resistance to exploring and adopting viable solutions.

As an example, the current use of Legacy MVC and the work going on in that area is rooted in providing a reliable standard while allowing for forward progress - and I don't see any reason why the same thinking is unworkable for a UI solution.

@ Brian

Its all well and good stating that there are "hundreds if not thousands of professional css gurus and template vendors who would love to participate." the facts are different. There is NOTHING stopping anyone contributing. The reality is that they don't.

First of all Brian, thank you for your tireless efforts an all of our behalf!

To my mind, "they don't" doesn't necessarily equate to "they won't."  A highly respect friend has a great saying, "Can't lives on Won't Street."

What we need is good leadership and a clear path on this particular issue (i.e. forward compatibility for a front-end framework) - exactly the very same type of leadership that has brought the Joomla! project this far with such amazing success.

There have been some amazing ideas presented by so many in this thread - my personal favourite so far is the 'switch.'

N

On Wed, Feb 19, 2014 at 11:30 AM, Markus Bopp <koeln...@gmail.com> wrote:

[Philip Locke]

I have no issues with the idea of moving the presentation layer to the template - I have done this already with my own front-end templates ignoring all core BS files. I also use unhacked CSS/JS bootstrap v3 files in all of my front-end templates - I may be the minority, but it allows me to update my templates extremely quickly as soon as BS does a new release.

Just a bit confused about what's being said, as if 'one' considers himself/herself to be a professional front-end developer & know's Joomla then surely 'one' should be capable of not being hand-tied to the Joomla BS version. But this seems to have turned into a Joomla wide BS version issue, for the core, both for front-end templates & the backend and that's a much bigger issue.

I maybe think it's an education thing 1st off, rather than jumping into decisions that could effect the masses, users & 3pd's.

@Kai's original question could have been answered with "what are you wanting to do & why?"

...It turns out that he was talking about a front-end template... well that's easily solved today.

[Paul Orwig]

Thanks Phil. My thought is this discussion has expanded a bit from the original question. I would say the good work you are doing with Joostrap is pushing the current boundaries, and this discussion is also talking about changing the current boundaries to make it easier for front enders to have more flexibility and control.

Matt said:

Speaking on behalf of myself, and not the entire PLT, it would be helpful if those that are proposing solutions do so as a gist or Google Doc so that we can organise and evaluate them equally. It's honestly quite hard to pluck them out of an email thread like this. I would also hope that those proposing the potential solutions are also making a commitment to make them a reality.

Thanks Matt, I think that is a good suggestion.

@All - In my mind, Matt's request is the crossroads where this good discussion will either fade away or gain momentum.

It seems to me that it would help to define a few things to help those who want PLT to consider different ideas:

• An easy way to help connect those who want to work together on a writeup/proposal for a different idea
• A common way and place for those people to work together and share their work
• A deadline to help motivate people to get this done and to give PLT confidence that they are reviewing the options that have the most support
• Maybe there are some additional points to add...

I guess the process points above could be discussed and agreed to in this thread, unless there are other suggestions on how to best turn this good discussion into something clear that PLT can review.

Thanks,

paul

[Seth Warburton]

Thank you Paul, I appreciate the support.

I realise I spoke previously only from the perspective of a front-end developer, but I believe that there is also a broader question of how we manage package dependencies generally. My own recent experiences with the package manager Bower have made me realise there are better ways to incorporate 3rd-party libraries; simple, maintainable and sustainable ways.

In fact, I read a good article this morning that I think describes very well how it is helpful to ring-fence 3rd-party dependencies: Bower all the things.

I also don't see Bootstrap's use as a mistake, but I do see a lot of ways it's implementation could be improved, to the benefit of us all. After all, we all want a stronger, fitter and more popular Joomla.

Thanks for listening. 

Seth

[Michael Babker]

This gets into long term planning for CMS architecture, but I've spent the last couple of hours thinking about the architecture of the CMS and comparing it against the architecture of Framework based applications I've been toying with, including how we could reach a goal some would like where templates ultimately have full control over the display.

 

For those unfamiliar with the Framework architecture, there are two packages heavily relied upon in the CMS that aren't in the Framework; JDocument and JHtml.  For good reason I believe.

 

JDocument has essentially opened up the document output (and the various components of it; CSS, JS, metadata, etc.) to be modified anywhere in the application stack.  A controller can inject a JavaScript snippet into the document, and without hacking core code or the usual unset() tricks, templates are stuck with it.

 

JHtml IMO was well envisioned, but has become an abused package.  Most of what it does today is create HTML "widgets" for various functions, and it helps by creating consistent and reusable object markup for different things in the CMS.  I don't have to consistently paste in the markup for the batch modal in the admin; I call a couple of utility methods in JHtmlBatch and the rest is done for me.  These methods are great, aside from having non-overridable markup.  JHtml predates JLayout, which is overridable.  So, one could help make JHtml's HTML widgets flexible by working on removing the hard coded markup from the various methods and replacing it with calls to JLayout objects.

 

With the praise of JHtml out of the way, now we get into its flaw, and what really gets developers in trouble with templaters I think; its media handling methods.  JHtmlBehavior, JHtmlBootstrap, and JHtmlJquery (to name the main suspects) are mostly classes which load media; the various JavaScript helpers, the MooTools and jQuery frameworks, and Bootstrap's JavaScript architecture.  The objects that are created in this class are useful I do believe and again help with reducing code redundancy, but that's where the benefits stop.  Templaters don't want anyone forcing media upon them.  Be it something a component needs to function (which is probably loading its own dependencies from another source and causes 2 or 3 copies of jQuery to be loaded) or a full CSS framework stack.

 

In Framework applications I work on, in place of a global document object, I use a rendering interface designed to be accessed only within a view class that was built initially for the Issue Tracker (still to be shared upstream to the Framework itself).  This interface allows me to choose a rendering engine (be it Joomla's "classic" PHP based templates or an engine like Twig) and handle templates how I want to.  A typical view (https://github.com/mbabker/framework-status/blob/master/src/View/Dashboard/DashboardHtmlView.php) fetches data from the model and injects it into the rendering object, in some ways similar to how the CMS handles views now (but different in that component layouts are still within the scope of a PHP class; whatever you can do in your view class can be done in your layout still).  With my rendering object, my layout is decoupled from my view class.

 

In this application's case, I'm using Twig for my engine, so my view layout (https://github.com/mbabker/framework-status/blob/master/templates/dashboard/dashboard.index.twig) fills in blocks for the main template (https://github.com/mbabker/framework-status/blob/master/templates/index.twig).  Notice there are no calls to load media here; the template is in control.

 

A more advanced example is with the Issue Tracker itself.  Using our issue edit view (https://github.com/joomla/jissues/blob/master/templates/tracker/issue.edit.twig), you'll see several more containers to fill in for the base template (https://github.com/joomla/jissues/blob/master/templates/index.twig), including media.  But, note that the media is defined in the layout; it's not injected into the template anywhere else.  For those looking for ways to manage dependencies, the Issue Tracker is using Bower (https://github.com/joomla/jissues/blob/master/bower.json) but without a UI as what you would most likely need in the CMS.

 

I point these examples out to show that it is indeed possible for Joomla to separate layers and give templates full control of presentation.  But, to get there in the CMS, there needs to be a lot of thought about the architecture.  JDocument and JHtml don't fit into this workflow, neither does JForm in all honesty (but it could theoretically if refactored properly).

 

One last thought about why JDocument isn't that great for the CMS future architecture IMO; it doesn't adapt well to introducing new view formats.  With my Framework apps, to switch from HTML to JSON is a new view class; I don't need a separate controller to route it, or separate methods in my model to load the data.  Ultimately, the application shouldn't care what the format is (the exception to that rule is if you have a top level exception handler and want to return format appropriate data; like https://github.com/mbabker/framework-status/blob/master/src/Application.php#L43-L93 is doing).

[Bakual]

I'm not aware we ever had this.

I heard about some standard classes, but it seemed to me they were only existant in a doc page somewhere. They sure were not used by most templates and extensions.

[Bakual]

Umm, you can already do that with Joomla. There are templates which use Bootstrap 3 without problems. You just need to override the core outputs.

There are a few things which can't be overriden yet, like some formfields. But we are working on those.

The big problem as I see it is that a template would have to provide overrides for every extension the user uses. That's easy doable for a custom template. It's not so easy for template clubs, they usually only do it for core extensions and maybe a selection of the most used 3rd party extensions. It fails for all others. And each kind of presentation layer will face that exact same problem as well. At least I don't see how that would help here.

[kisswebdesign]

Question: where is the best place to change the output of joomla globally?

ie I want to change the bs2 CSS classes used to bs3 (or any framework) classes (and HTML structures, if necessary) by scanning the page output before it is displayed.

It would also swap out the default bs CSS and JS files for whichever framework is being used.

I'm thinking it's onAfterRender but I'm not sure.

I'm thinking this would be a system plugin (preferred), but it could be part of a template.

My idea is to avoid writing overrides for every component, just have one global 'override'.

How quick, resource intensive, etc. this would be is anybodies guess. It may not even be practical or usable, but I'm going to give it a go anyway - even if it doesn't work I'll learn plenty in the process.

Any constructive advice is appreciated.

Chris.

[Saurabh Shah]

Good question Chris, perhaps I am looking for the same instead of just frontend template changes.
Big discussions here but as we all know that code is now on Github and we can always Fork and change the things around and try to propose a solution.

May be someone can Fork , add BS3 & change al lclasses and necessary things as needed and propose a solution.

I am sure people will be there to jump in to help you out and get BS3 code ready to use in may be some next J version. ...

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

--

Thanks and regards,

Saurabh Shah

Joomla! Evangelist | Mozilla Rep (ReMo)

Social : 
Skype:  saurabh.cloudaccess.net | saurabh.ds16

[Seth Warburton]

Just to make clear exactly what I am proposing, as I think there is some confusion. I'm not talking about updating Joomla core views to incorporate Bootstrap 3 I'm talking about totally rethinking the implementation so we could in future update/remove/add 3rd-party libraries without having to rebuild Joomla accordingly. 

We can't do that today as these dependencies are built right into Joomla's heart. We don't have a responsible, or sustainable, long-term solution yet.

I'm well aware that this would involve considerable effort to implement initially, but this is how I suggest we could reduce the breadth of these dependencies and reduce fragility. I'll talk here about Bootstrap, but the same principles and methods could extend to all 3rd-party libraries: 

1. Maintain Bootstrap's integrity by ring-fencing it, an untouchable asset.
2. Replace proprietary markup in Joomla's core outputs with W3C flavoured semantic html and css (a Bootstrap-free core).
3. Move existing Bootstrap (and other) behaviours to the default template (The default Joomla:Bootstrap experience).
4. Update the Joomla's Bootstrap version with the release of a new, updated, template.

What would this give us? If this happened today there would be no changes apparent to Joomla users, but it would give us a high degree of future-proofing.

• We wouldn't have a situation where updating core Joomla isn't possible because of the dependency on a 3rd-party library, Joomla would no longer be limited by that library. 
• A user could have a Joomla:Foundation5, Joomla:Bootstrap2.3, Joomla:Bootstrap6, Joomla:Pure or Joomla:XHTML experience simply by changing their template.
• Updating / adding 3rd party libs would be as easy as pulling their github repo into Joomla's assets directory.
• Updating the default Joomla:Bootstrap experience (e.g. Joomla3.2.3.:Bootstrap3.2) would only require a new template version (no BC issues).
• Template and extension developer could actually rely on Joomla's 3rd-party assets and not need to import their own.
• Removing a dependency would be as simple as deprecating the template (no FC issues).

Obviously, the breadth of these changes is beyond what I'd be willing to start sending PRs for given that I can't get even the most basic improvements past the gatekeepers. So, suggestions that I might like to code it all prior to a full discussion are not very helpful. 

I think that we should try to achieve some sort of general consensus over the future direction we want to move in, with clear direction from leadership teams, before we start asking people to code-up. Sometimes a little talking can save a whole lot of unneeded, and unwelcome, code from being written.

Best,

Seth

[brian teeman]

Please correct me if I am wrong but wont

1. Move existing Bootstrap (and other) behaviours to the default template (The default Joomla:Bootstrap experience).

potentially break all existing templates as they would now need to implement overrides for something they didnt need to override before 

[Seth Warburton]

You are not wrong. This is obviously something we can't do with a minor release, this is planning properly for the future.

[Niv Froehlich]

@ Seth

We don't have a responsible, or sustainable, long-term solution yet.

+1

While. IMO, we've benefited immensely for incorporating a standard (i.e. BS 2.3.2) and shipping it with the core, where we've come up short is the failure is to factor in a sustainable way to transition.  

This a surprising oversight because we live and breath in an environment where 3 things in life are guaranteed: 1) Death; 2) Taxes; and 3) Coding standards (and in this case frameworks version) will change.

I think that we should try to achieve some sort of general consensus over the future direction we want to move in, with clear direction from leadership teams, before we start asking people to code-up. Sometimes a little talking can save a whole lot of unneeded, and unwelcome, code from being written.

100% agreed!!!

I would still like to see a 'standard' shipped with core as an 'untouchable asset' - along with a well thought out strategy to smooth the transition to new versions.

N

--

[brian teeman]

On Thursday, 20 February 2014 15:47:46 UTC, Seth Warburton wrote:

What would this give us? If this happened today there would be no changes apparent to Joomla users, but it would give us a high degree of future-proofing.

 

So just to be clear then - this statement above is not correct 

[Bakual]

I think it's agood plan for 4.0.

[Seth Warburton]

It is as true as it is today. If they use a Bootstrap-powered template, made for the Joomla version in question, any Bootstrap expectant extension will continue to function as it did previously.

[brian teeman]

On Thursday, 20 February 2014 17:23:28 UTC, Seth Warburton wrote:

It is as true as it is today. If they use a Bootstrap-powered template, made for the Joomla version in question, any Bootstrap expectant extension will continue to function as it did previously.

But not the core. If you are moving bootstrap markup from the core components then unless the template is already overriding the core output of the core components the template will not function as it dod before

[brian teeman]

On Thursday, 20 February 2014 17:21:12 UTC, Bakual wrote:

I think it's agood plan for 4.0.

Agreed for 4.0+ - it's a sensible plan with many benefits 

[Youjoomla.com]

As I promised few days ago here is roundup BS2 to BS3 Joomla frontend.

Keep in mind that we used extensions overrides J25/J3.x 

Since we had to think about all 90k+ users 103 current templates  and j versions, J1.7, J2.5, J3.x 

I was forced either to make several sets of files or to simply add missing class names to elements. 

I decided for the adding class names. 

Same set of files for any J1.7 and UP version. Also remember that we use our framework system plugin that allows user to switch to 

BS2/BS3  http://prntscr.com/2u90dw

We dont use Joomla core bootstrap files or calls. 

I was surprised that it was not more but still checking the rest. 

1. Found all instances of class name btn respectively btn btn-mini and just added class btn-xs or btn-sm   so the class ended up being  btn btn-small btn-sm readon ( notice the readon from j1.5 :) )

2. Sliders and Tabs. This was one of the hardest tasks and honestly I have no idea how an average Joe can keep up with us. 

This is Joomla 3.x component contact view https://github.com/joomla/joomla-cms/blob/staging/components/com_contact/views/contact/tmpl/default.php

Many of us that contributed to this post  understand that code but an average Joomla beginner does not.  It is beyond me why we have crammed 3 different layouts in 1 file. 

To make same files work for J2.5/J3.x I separated  Plain , Tabs, Sliders in own files http://prntscr.com/2u8s48 and was forced  to use pure html markup instead of JHtml::_('bootstrap. like in 3x

This way same files work on J25/3.x and again all I had to do is add additional class names . Example for sliders 

<div class="accordion panel-group" id="accordion2">

  <div class="accordion-group panel panel-default">

    <div class="accordion-heading panel-heading">

      <a class="accordion-toggle" data-toggle="collapse" data-parent="#accordion2" href="#collapseOne">

        Collapsible Group Item #1

      </a>

    </div>

    <div id="collapseOne" class="accordion-body panel-collapse collapse in">

      <div class="accordion-inner panel-body">

        Anim pariatur cliche...

      </div>

    </div>

  </div>

</div>

I tested above markup and it works same in BS2/BS3 but I just did not like it , so at the end  I made my own collapsible to make sure that future BS version would not force me 

to add more classes. 

Tabs and plain  layout work out of the box. 

3.  Some css declaration had to be adjusted and I added own mixins to BS3 , this way I dont brake the BS3 core but just add things  I was missing . 8 extra declarations make it work ok. 

a.modal{}

label, input, button, select, textarea {}

.radio.inline, .checkbox.inline {}

 // Focus state

  &:focus {}

textarea:focus:required:invalid,

select:focus:required:invalid {}

.form-horizontal .control-label {}

.form-horizontal .controls {}

legend {}

--

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

--

Best Regards
Dan Casky
Youjoomla Customer Service
1670 Southgate Mill DR NW
Duluth ,GA
30096
-------------------------------
www.youjoomla.com
Professional Joomla Web Design Services

[Youjoomla.com]

And before I forget , all forms used in J needed an extra css class name for example form-inline , the rest can be kept as it was in BS2

[Youjoomla.com]

As far as JS issues 

this was added in 

http://prntscr.com/2u94xl

to avoid conflicts with mootols-more.js

[brian teeman]

Thanks for sharing that Dan

BTW it should be "which Bootstrap version" not "what ...." http://prntscr.com/2u90dw

[Youjoomla.com]

Thnx Brian :) Changed!

[Leo Lammerink]

Oh Dan,
THAT is looking mighty cool! Did I miss a link to test this "crap" (hohohoho)

Leo

[Youjoomla.com]

@ Leo lol, soon :). Did not want to push it here , Just show examples :)

[Matt Thomas]

On Wed, Feb 19, 2014 at 12:56 PM, Paul Orwig <paul.orwig@opensourcematters.org> wrote:

It seems to me that it would help to define a few things to help those who want PLT to consider different ideas:

• An easy way to help connect those who want to work together on a writeup/proposal for a different idea
• A common way and place for those people to work together and share their work
• A deadline to help motivate people to get this done and to give PLT confidence that they are reviewing the options that have the most support
• Maybe there are some additional points to add...

I guess the process points above could be discussed and agreed to in this thread, unless there are other suggestions on how to best turn this good discussion into something clear that PLT can review.

Paul is spot on with this suggestion as it does seems to be "the crossroads where this good discussion will either fade away or gain momentum"

Is there is someone in the community that can commit to taking this on to the point of helping organize those that want to contribute so that we can have at least substantive proposals to consider? I think having a single person that can be a point of contact would be extremely beneficial in making this a reality.

Best,

Matt Thomas

203.632.9322
http://betweenbrain.com/

 

[Mathew Lenning]

First I have to say +1 to Seth's plan, I think it would be a great improvement to the CMS.

However I wanted to hear more about the administrative side of this proposal. 

Do you intend to move all BS out of the administrative area? This is important to extension devs, because I've operated with the assumption that in 3.x BS is included by default (which I'm sure others have too). 

So if all of a sudden this was not the case, we'd end up with extension devs going J!1.5 retro and loading their own CSS in the admin area. the whole standardization of the administrative area would be out the window and the end user would have to learn a new UX for every extension they installed. 

If we are going to move the all the styling to the presentation layer (which is a good idea, that I support 100%), I think we need to implement a element id naming standard (not class names) for the primary elements of the admin area. 

Not every element mind you, but the top level containers and then perhaps key elements. Just of the top of my head: 

• Side bar
• Main content container (one for forms, one for lists)
• Main content list Table
• The filters container in the left side bar
• The filters container on the top of the main container

By implementing a standardized ID naming convention for these key elements, the template developer (including the core) could use progressive enhancement to add the appropriate CSS classes to the elements dynamically. So if the template uses BS2 instead of having class="table table-striped" in the administrative table markup, the developer can leave the class alone and add id="jAdminList" (or whatever), then the template designer could had JavaScript that does the equivalent of 

document.getElementById('jAdminList').className = "table table-striped";

The benefit here is that first as an extension developer I can stop thinking about the styling all together, so long as my component uses the id standard and the template designer has full control without a bunch of extensions loading their own framework. 

Of course I haven't tested this solution, so I don't know how resource intensive it would be.

However in combination with Seth's proposal we could actually do a complete separation of markup and style.

=^D 

 

[Adam Rifat]

+1 for Seth's suggestion.

How do we make it happen?

[Bakual]

I'd say the backend is different. Most people just use Isis here (anyone really using Hathor?). There are a few backend templates available but I think the inclusion of BS into the backend isn't really an issue. The gains we have with standarising here was a big success imho.

Of course if we can come up with a good solution for the frontend, this can be applied to the backend as well if needed. But we will likely not change the backend like this during 3.x.

[Angie Radtke]

Hi together,

I think it will be great if we can find a working solution for that
topic soon .
The tasks of a CMS is managing data in the back and displaying content
in the front.
We are talking about a very big part of the CMS framework, which is
responsible for the general usage and the success of the whole system.
So our responsibility here is very high and our decision should be very
well thought out.
On the other hand this topic needs knowledge from various specialists,
with various competences.
We need software architects and php programmers, frontend specialists
knowing HTML, CSS, CSS-preprocessors very well , we need accessibility
guys and last very good JS coders.
And all these guys have to work hand in hand.
This is only possible if we have a very good documentated plan, what we
will do and how we do that.

I have my ideas how we can work on that issue, I'm not sure if there is
a better plan and if I miss some things.

I think we should spilt the work in parts otherwise it will take to
much time.
So my idea first caring about the frontend and don't touch the backend
for now. ( later we should do that)
This has the benefit that all the components using BS2 will still
work in the backend.

For me as a webdesigner the frontend is the most important part. To be
open here for everything will be great.

We need very well structured HTML as basis and should build our own
CSS Framework on top.

Based on all the good ideas we can find in BS, Foundation, CSSKIT or
whatever else.
I think it is possible to make that framework BWC to BC2.
We need a very good documentation as well, because I heard that argument
may times for using BS.
I think it can't be so hard to do that. We have a great documentation
team, right?

There can be 2 or 3 Frontend - Templates.
One ins using our own framework and the core output.
One can use BS3: our core- output with additional BS3 classes and the
related JS.
And if we still have problems with the bwc of our own framework, we can
add a BS2 one as well, but I think this is not neccessary.
If all is running well, we can add our framework to the backend as well
with the goal to make it more accessible.

This is a a short summary of my thoughts.
Attachend you will find a list with all comments in this thread order by
arguments ( I hope I don't forgot one) , the red marked stuff are my
notes and a scribble how I can imagine the structure.
This structure is only an idea and a wish. I habe no clue if this is
technical possible. This is a part for architects and php programmers.

Thanks Angie

[Mathew Lenning]

For full disclosure, I haven't read your attached documents yet, but I'm against any proposal that pushes for the creation of a custom CSS framework. The mission should be to leave that to the designers not the CMS dev.

Sincerely,
Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors

> --
> You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/7ommekXwB-w/unsubscribe.
> To unsubscribe from this group and all of its topics, send an email to joomla-dev-cm...@googlegroups.com.

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

> <joomla1.pdf>
> <Bootstrap.pdf>

[Christian Matthew]

Please GET RID of Bootstrap in the FRONT END.

I have a novel idea. Let people i.e. extension devs get a download of bootstrap and take the parts they want and then develop their extensions with the class structure. Then when applying the extension give the css its own direct along with any jquery they are using. Like normal HTML extensions and plugins.

Then, I can take their code and alter it directly if I want. Once, I am done I can add that css to my custom style sheet and min it up... same with JS...

Why is this not the perfect solution? Am I crazy or something?

[Christian Matthew]

Yes but are you suggesting bootstrap still be baked in?

[Adam Rifat]

Let's hold onto Seth's idea for a moment.

The gist of which is to move all markup into the template.

Obviously, there has to be a default template for an 'out of the box' joomla install to work.

But I think the idea is that you could ship multiple templates each of which override (provide?) the core html. That way you could incorporate whatever framework you like simply by writing a new template. But you would need some sort of base css for the default template, unless you want the default template to use version of BS or some other framework and then you're back to square 1.

You would probably need a basic css framework for the default joomla install.

How would you go about moving all html into the template? For example with com_content? Just delete all the views from that component and move them to the template...would that work?

[Mathew Lenning]

I think I've missed something here. I was under the impression that the goal was to move all the styling into the template which is what the template is there for. The Mark up however should still be the responsibility of the extension.

The goal should be that views

create clean markup without consideration of which CSS framework is being used. Then the template (AKA the designers) can use whatever suits their fancy. 

Building a quality CSS framework is no small endeavor, and since the biggest issue in the community is lack of involvement, even if we managed to piece together a solution it would without question quickly be out dated and we'd be having the same discussion that lead to BS being included in the first place. 

I really think dynamic setting of CSS framework class names via JS would require the least amount of work and give template developers the freedom and control they deserve. It would also free us extension developers from worrying if the designers are using BS or some other framework (I honestly don't know any others by name) 

If we can just add an id to the top level container an roll with semantic markup, there would be far more quality components for the Joomla! CMS and a more uniform UX

I'm actually going to try and implement this in one of my components (straight markup with JS plugging in the class names based on IDs. I'll post my results. 

Sincerely,

Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors