Updating to Bootstrap 2.3.1, to solve Dropdown on iPad and iPhone

[Anibal]

Hi,

Current Bootstrap 2.3.1 have fixed several bugs. For example this one about Dropdown on iPad and iPhone http://forwebonly.com/fix-for-twitter-bootstrap-dropdown-on-ipad-and-iphone/

As Joomla 3 is distributing Bootstrap Bootstrap v2.1.0, is it going to be updated in the next versions? Or, do we have to apply the fix to local files?

Thanks,

Anibal

[elin]

Have you tested on master?

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=29957

Elin

[Bakual]

I think there is a PR to get BS updated to the current release. It needs proper testing and then it can be included for 3.2.
However it's clear that Joomla has to stick with BS 2.x for the whole Joomla 3.x series. Updating to BS 3 can only be done for Joomla 4.0 as it is not backward compatible.

[Bakual]

Also note that nobody for es you to use BS in your template. You can use your own CSS, override output and even override Javascript files if you don't like those.

[pepperstreet]

Am Samstag, 1. Juni 2013 07:37:06 UTC+2 schrieb Bakual:

Also note that nobody for es you to use BS in your template. You can use your own CSS, override output and even override Javascript files if you don't like those.

Yes and no. Maybe I used the wrong words or a too short explanation... more or less you have no real choice: Since Joomla! relies on 3rdparty extensions, and extensions make use of JUI... they tend to use it for frontend stuff like forms or scripts etc. So, BS is also present and loaded on frontend. In most cases, it makes simply no sense to use another framework. It would more than double the load and possible conflicts are not far away.  

 

[Bakual]

Actually, extensions should not "load" Bootstrap at all. They use Bootstrap markup as a defined set of classes which can be used for styling, but they don't load (or should not) any CSS files from Bootstrap. That's what the template is responsible for. Of course the template should support the Bootstrap classes, but how the template does this is up to the template. The nice thing about Bootstrap is that a template designer can pick the elements he likes and build the stuff himself he doesn't like about Bootstrap. Simply by picking the LESS files he wants and compile them together with his own files.

And of course it gives extension developers finally a well-known set of CSS classes where they can count on for styling.

[Seth Warburton]

I would not count on classes in your extension being styled by the template. As you rightly say; these things are ultimately decided by the template designer. I don't use Bootstrap at all in my own projects, though I do provide support for *some* Bootstrap classes. Because I don't use Bootstrap, I remove all Bootstrap markup from my output and I'm certainly not the only one who does this.

Unfortunately, because of the way Bootstrap markup is implemented in core outputs and 3rd-party extensions it will always be very hard to update, and require significant effort on each occasion. Because Bootstrap markup (as do documentation and code examples) changes from version to version, updating will always potentially require updates to every extension using Bootstrap markup and every file containing Bootstrap markup in core. Updating the Bootstrap framework will always result in a break in backward compatibility.

Best,

Seth

[Seth Warburton]

Actually, it's more accurate to say: “Updating the Bootstrap framework is likely to always create backward compatibility issues.”

Seth

[Matt Thomas]

Seth,

I've seen discussions about namespacing with Bootstrap to help address these issues. Are you familiar with this, and do you see that as a possible solution? If not, is there one? IMO, this is a major issue and essentially negates all benefits from using BS.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

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

[Michael Babker]

FYI, Bootstrap 2.3.2 has been merged into the CMS, so it will ship with 3.1.2.  For those with a direct interest, *PLEASE* test against the master branch on GitHub to ensure that there won't be major issues with this change so that they can be addressed before shipping 3.1.2.

[pepperstreet]

On Tuesday, 4 June 2013 12:09:24 UTC+2, Bakual wrote:

Actually, extensions should not "load" Bootstrap at all. ...

I totally agree with you... but theory and reality are two different stories ;-)

The understanding and usage is so mixed in some template frameworks and on extension developer side.

In regards of extensions (including views/templates for it) ... what is best practice? Even a solid visual appearance is hard to get: If they make use of BS they can utilize J!3 JUI... this means BS2.1. Which has issues. How to support templates/frameworks that have no BS at all? Mix own classes and default CSS with BS classes? And what about Jommla! 2.5 LTS? Build a specific extension for it? Or at least one without BS classes at all... I think, you get the idea.

[pepperstreet]

On Tuesday, 4 June 2013 15:20:47 UTC+2, Michael Babker wrote:

FYI, Bootstrap 2.3.2 has been merged into the CMS, so it will ship with 3.1.2.

Many thanks for the heads-up! 

[pepperstreet]

On Tuesday, 4 June 2013 15:13:44 UTC+2, betweenbrain wrote:

I've seen discussions about namespacing with Bootstrap to help address these issues. 

As far as CSS issues and collisions with other extensions and template frameworks are concerned...

I think at least the grid and layout classes should have a unique BS namespace. In my first steps with BS I always wondered why they are so common and generic (i.e. row, span6 etc.).

FYI - i assume you already knew this article:

Please stop embedding bootstrap classes in your HTML

To be honest, its beyond my knowledge and current understanding of BS. And I don´t agree with some statements in the article. Personally, i think a "namespace" is most suitable and reasonable.    

[Bakual]

I thought the goal of including BS into core was to provide some standard "well-known" CSS classes which extensions can use. Finally extensions can be written so they fit well into any templates and provide a consistent look over the whole site. If you don't support these CSS classes in your template, then this whole selling point of Joomla 3.x is gone.
From Joomla.org (http://www.joomla.org/3):

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

And also:

• Build a Component with Zero CSS
 
• Style a Site with 1 CSS File
 
• Icomoon Font Icon

This all doesn't work if a template isn't at least supporting the Bootstrap CSS classes. It doesn't mean they need to include the Bootstrap CSS files. They can as well use their own rules, but the classes should be supported.

Imho it's a big selling point of Joomla 3 and should not be thrown away easy.

[Michael Babker]

Using Bootstrap, we have found that standard.  And it's good for many.  But for folks like Seth who don't like how Bootstrap is implemented, there are issues with not using Bootstrap in the CMS.  It pretty much comes from how it was implemented.

JLayout came about very late in the 3.0 development cycle (minutes to spare in the 11th hour basically) and is a game changer.  It lets us move HTML markup out of static and difficult to override PHP methods to easy to customize layout files.  This was done in 3.1 with JHtmlIcons (the helper that supports the quick icons in admin, compare Hathor and Isis to see this).  Add in now that we don't have to deal with upstream communication with the old Platform in the JHtml helpers, we now have the flexibility to do more work like this.  Our toolbar rendering would benefit greatly from this for example.

To sum up: Bootstrap is good as it gives us a widely used standard, but we need to keep up our core flexibility and let those advanced users like Seth implement sites without being forced to use Bootstrap.  We can get there with some effort.

--

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

--
- Michael

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

[Matt Thomas]

Michael,

Just to confirm, I assume that the effort you speak of is implementing more of JLayout to move HTML markup out of these PHP methods, correct?

Best,

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

Composed and delivered courtesy of Nexus 7.

[Michael Babker]

Correct.

[Seth Warburton]

I think that will be a great solution, and will allow us in future to simply re-map (changed)Bootstrap classes to the (existing)Joomla-Bootstrap classes. At the very least it will ensure that the vast majority of the work involved in updating the Bootstrap library can easily be done in a single place.

Best,

Seth

[Seth Warburton]

@Michael - Thanks to you and Anibal for your work in making this happen it's a big improvement and one we are all glad to see. #jpositiv

@Pepperstreet - Yes, I know that article and I agree with much of it. I believe a class should always try to describe what an element does, not what it looks like, this is one of the cornerstones of scalable and maintainable OOCSS. Bootstrap does this only in a few places though. With classes applied in markup instead of using mixins there will also be situations where the markup is simply misleading. For example; 

<a class="readmore"> - Good class name. I know from looking at the markup what this link does. What it looks like is irrelevant in the markup.

<a class="btn"> - Bad class name. I have no clue what the function is, and can only guess at the appearance. The same markup will also be horribly misleading when the template designer does this:

.btn {... clear all default button styles here ...}

@Bakual - It is this third example that I fear some extension developers do not fully appreciate, simply because you include the style .table-bordered is no guarantee that you will get a bordered table. That has always, and will always, be decided ultimately by the template designer and end-user. This was the point of my first reply to you, I think it unsafe to ‘rely‘ on the fact that the designer will style something the way you want them to.

Personally, as a designer, I like to do my own designing and that includes placing buttons where *I* want. I don't think this is unusual.

Just to make clear, again, I'm not advocating the removal of Bootstrap at all. I would like to see it integrated less tightly with core though, as I fear we create another strong dependancy and create further work for our future selves whenever it comes to updating. Name spacing Bootstrap would largely remove much of the effort of updating Bootstrap in future I think, and that can only be a good thing.

@Michael - JLayouts look pretty awesome from where I'm standing! I'm really happy to see them.

Best regards,

Seth

[Nikolaos K. Dionysopoulos]

I only have one question. This will mean that my extension will create different markup and, as a result, different DOM trees depending on the template in use. The corollary is that my Javascript will be broken unless it's overly simplistic and uses tons of IDs which end up slowing down the browser and me getting a rap from designers and integrators for slowing down their sites. So, I have to remove that Javascript. But is it worth removing the dynamic features of our components for design flexibility, especially those which create HTML on the fly based on raw data fetched over AJAX (which seems to be the ultimate goal of the Web Services effort in Joomla)?

It's also very disconcerting that we were promised that once we move to BS markup we wouldn't have to worry about design and now we're finding ourselves in a situation where we have to redesign our components' output from scratch, all over again. Can we please specify a standard and stick with it? Like, for real this time?

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Matt Thomas]

In other words Nic, markup changes are also a backwards compatability issue.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Nikolaos K. Dionysopoulos]

Yep. And one that's very expensive (in terms of time) to solve. Also very difficult to cater for when we're dealing with multiple Joomla! versions.

Trying to cater for all arbitrary markup output standards in our view templates and Javascript would take forever and we'd probably fail. IMHO, for anything more complex than com_weblinks such an abstraction is very taxing on developers and works against them. It would be best to have a Joomla! markup standard instead and stick with, without putting developers in the impossible situation of providing working Javascript for an unknown DOM – how can someone develop, test, debug and support against something that's completely arbitrary, unknown and ultimately up to a third party?

Besides, with web services in the core the endgame is the core to provide raw data and have the Javascript render it. How can this be possible if the markup standard is up to the designer of each template? Will designers –and, by implication, site integrators and novice end users– provide all the front-end business logic for all Joomla! extensions, past, present and future? Or are developers supposed to write custom Javascript for each and every possible markup output standard? None of these solutions sounds very promising and it gives me the impression that JLayout won't survive past the 4.0 release.

I'm thinking out loud. I'd guess (hope?) that this is thought of already and there's a solution already planned as the result of developers and designers working together.

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[pbass]

It would be best to have a Joomla! markup standard instead and stick with, without putting developers in the impossible situation of providing working Javascript for an unknown DOM – how can someone develop, test, debug and support against something that's completely arbitrary, unknown and ultimately up to a third party?

Sounds like working with WordPress!

[Amy Stephen]

On Tuesday, June 4, 2013 8:20:47 AM UTC-5, Michael Babker wrote:

FYI, Bootstrap 2.3.2 has been merged into the CMS, so it will ship with 3.1.2.  For those with a direct interest, *PLEASE* test against the master branch on GitHub to ensure that there won't be major issues with this change so that they can be addressed before shipping 3.1.2.

 
Good advise, Michael.

[Seth Warburton]

I totally understand where you are coming from Nicholas, really I do. But, without some change *somewhere* (either with name spacing Bootstrap or with extensive markup updates in core *and* 3-party extensions) Joomla is locked into a single, outdated, version of Bootstrap. That's bad for everyone I think.

Extension devs cannot consult the Bootstrap docs and trust what they find there if Joomla's version of Bootstrap is out of sync. End users will complain. Devs, front and back end, will complain.

There will be markup changes with Bootstrap updates, that is inevitable. Either we absorb those changes through some sort of abstraction layer, or we re-write core markup and ask extension devs to re-write theirs with each update, or we keep Joomla on an outdated, and buggy, version of Bootstrap. Personally, I see only one of those options as being sustainable in the longer term.

It is for these reasons that I have, only recently, become very concerned with the maintainability and robustness of my own code. I don't want to have to keep re-writing everything from scratch either. It sucks.

On Wednesday, 5 June 2013 16:21:47 UTC+1, Nicholas Dionysopoulos wrote:

I only have one question. This will mean that my extension will create different markup and, as a result, different DOM trees depending on the template in use. The corollary is that my Javascript will be broken unless it's overly simplistic and uses tons of IDs which end up slowing down the browser and me getting a rap from designers and integrators for slowing down their sites. So, I have to remove that Javascript. But is it worth removing the dynamic features of our components for design flexibility, especially those which create HTML on the fly based on raw data fetched over AJAX (which seems to be the ultimate goal of the Web Services effort in Joomla)?

It's also very disconcerting that we were promised that once we move to BS markup we wouldn't have to worry about design and now we're finding ourselves in a situation where we have to redesign our components' output from scratch, all over again. Can we please specify a standard and stick with it? Like, for real this time?

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

On 5 Ιουν 2013, at 17:20 , Seth Warburton <se...@internet-inspired.com> wrote:

I think that will be a great solution, and will allow us in future to simply re-map (changed)Bootstrap classes to the (existing)Joomla-Bootstrap classes. At the very least it will ensure that the vast majority of the work involved in updating the Bootstrap library can easily be done in a single place.

Best,

Seth

On Tuesday, 4 June 2013 14:13:44 UTC+1, betweenbrain wrote:

Seth,

I've seen discussions about namespacing with Bootstrap to help address these issues. Are you familiar with this, and do you see that as a possible solution? If not, is there one? IMO, this is a major issue and essentially negates all benefits from using BS.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

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

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

[Nikolaos K. Dionysopoulos]

Hello Seth and thank you for the reply. We are pretty much on the same page, mate :)

My biggest concern is the DOM model resulting from the markup itself. Having a markup standard (e.g. Bootstrap) or being in control of the generated markup (like in the Wild West era of Joomla! 1.5) allows us to know with certainty how the DOM looks like. This has important corollaries as far as Javascript is concerned:

• I can show/hide/modify elements without each and every one of them having an ID, as I can do a selector like $('#foo div.controls input').addClass('error')
• I can generate HTML markup on the fly based on raw data. This allows me for rich interactive elements which only sip tiny amounts of bandwidth, e.g. showing related FAQs when someone submits a ticket.

With JLayout I have no idea what the generated markup looks like, therefore the DOM is a mystery to me. As a result I cannot write the necessary Javascript for dynamic page interaction. If we have to regenerate the page for every small action the site will be dead slow and, naturally, the blame goes to the developers for not providing a better solution, even though one is not possible. If "other sites" do it, why can't we do it? That's the typical argument of users.

That's why I am saying this again. Instead of providing a generic method which produces arbitrary(*) markup and makes it impossible to create dynamic sites maybe, I say maybe, we should consider a Joomla! markup standard? Not necessarily Bootstrap. Just something that makes sense, is predictable and unlikely to undergo quantum changes in a year.

(*) Even if Joomla! itself only ever provides a single markup output, nothing stops a template developer from overriding it (still being within what Joomla! allows them to do without a crude hack), breaking many extensions which rely on Javascript. This is currently impossible unless the template designer does template overrides for a specific extension. Overrides are easy to deactivate and troubleshoot. A JLayout override would break the template if removed and break extensions if it's left in place, leading to an impasse in troubleshooting.

Cheers,

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

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

[Seth Warburton]

I think we are on the same page :)

Agree, 100% that arbitrary markup is not good for anyone, and in that respect Bootstrap has really been an eye-opener to many about how things can be handled in a reliable and predictable fashion, producing the stability we all require. 

JLayouts essentially removes the repeated and often used markup structures present in large numbers of views and keeps them in one place. These markup 'modules' can then be called on from anywhere, keeping things DRY. This, to my mind at least, makes the markup structure even more predictable, not less. For example, we could then be confident that the tags markup was the same in article views as it was in blog views, as it would always be rendered by the same markup. Contrast this with say the article info where previously this would have been rendered by (potentially different) markup in at least 3 different places, article, blog-item, featured-item.

We definitely need reliability and predictability but what's become clear to me is that although Bootstrap appears to offer this in the short-term, in the long-term it does not. The updates discussed in this thread are minor in comparison to the changes that have already been committed in Bootstrap 3.0, and that presents us all with a huge problem. I don't know the best way to solve this problem, but I do know we should start thinking about it now. 

Personally, I would love to see a Joomla markup standard, as part of a larger initiative to create a 'style guide' which specified not only coding standards but also the overall 'vision' for the tasks we face. I imagine this as giving guidance like, for example:

“Module class suffix and module caching options must always be presented, in isolation, in the last options tab. This options tab should be named ‘Advanced module options’.”

In terms of something that always makes sense, I love the BEM approach, http://bem.info/; it's semantic, logical and unlimited in scope. However, I think that discussion of a Joomla Markup Standard is a topic worthy of it's own thread, and I can't say it's one I am particularly keen to start.

Best,

Seth

[brian teeman]

I definitely agree that we need a style guide but thats really a topic on its own

[Nikolaos K. Dionysopoulos]

Hello Seth,

I think we are on the same page :)

Good :)

JLayouts essentially removes the repeated and often used markup structures present in large numbers of views and keeps them in one place. These markup 'modules' can then be called on from anywhere, keeping things DRY. This, to my mind at least, makes the markup structure even more predictable, not less. For example, we could then be confident that the tags markup was the same in article views as it was in blog views, as it would always be rendered by the same markup. Contrast this with say the article info where previously this would have been rendered by (potentially different) markup in at least 3 different places, article, blog-item, featured-item.

So, let me see if I understand it correctly: JLayout will always output the same markup for a given "module" in a specific Joomla! minor release (e.g. the entire 3.5 series) and will not be overridable by the template? Because for me consistency of the markup is a nice thing to have, but predictability of the DOM tree across all templates and all sites is absolutely necessary. The latter is required for my Javascript to work.

We definitely need reliability and predictability but what's become clear to me is that although Bootstrap appears to offer this in the short-term, in the long-term it does not. The updates discussed in this thread are minor in comparison to the changes that have already been committed in Bootstrap 3.0, and that presents us all with a huge problem. I don't know the best way to solve this problem, but I do know we should start thinking about it now. 

Agreed. And that's why we are both saying the following:

Personally, I would love to see a Joomla markup standard, as part of a larger initiative to create a 'style guide' which specified not only coding standards but also the overall 'vision' for the tasks we face. I imagine this as giving guidance like, for example:

“Module class suffix and module caching options must always be presented, in isolation, in the last options tab. This options tab should be named ‘Advanced module options’.”

In terms of something that always makes sense, I love the BEM approach, http://bem.info/; it's semantic, logical and unlimited in scope. However, I think that discussion of a Joomla Markup Standard is a topic worthy of it's own thread, and I can't say it's one I am particularly keen to start.

You should talk to Angie Radtke. You are pretty much on the same page. When she explained me (in the Dutch Joomla! Days) the long term benefits of such an approach I was all in for it – even though it means a ton of work for me in the short term.

[Seth Warburton]

So, let me see if I understand it correctly: JLayout will always output the same markup for a given "module" in a specific Joomla! minor release (e.g. the entire 3.5 series) and will not be overridable by the template? Because for me consistency of the markup is a nice thing to have, but predictability of the DOM tree across all templates and all sites is absolutely necessary. The latter is required for my Javascript to work.

Yes and no. Implementation is a little patchy at the moment, but once fully implemented that is the intention of JLayout I believe. Pull repeated markup chunks into discrete 'objects' that can be re-used anywhere that needs that output. They will definitely bring consistency. They are easily overridable in the template though, in the same way as views traditionally have been, e.g.: 

templates/my_template/html/layouts/content/tags

Troubleshooting for you would still require renaming the html folder to disable all such overrides.

I hope to chat with Angie very soon, I know already that we are very much in agreement on a number of things!

Best,

Seth

[Nikolaos K. Dionysopoulos]

OK, everything sounds fine. Hopefully clients will understand that a template can and will break the Javascript on their extensions and it's not the developer's job to provide them with template-specific Javascript files. That remains to be proven :)

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

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

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

[Amy Stephen]

I would not be surprised if some *mistakenly* believe this thread is about how JLayout broke Templates and the Bootstrap upgrade lost the Joomla customizations so now developers have to code their components from scratch again. And oh, we're finally getting a style guide. So, Yea! for that. lol! (Those things were said in this discussion - and of course - not in a "this really happened" way but in speculation, a distinction that can be hard to communicate when most read very little of a post while their attention veers towards the dramatic. We need to be a little more careful, yes?)

The real message is a little boring, but very important if you want to make sure your extension does not break:

On Tuesday, June 4, 2013 8:20:47 AM UTC-5, Michael Babker wrote:

FYI, Bootstrap 2.3.2 has been merged into the CMS, so it will ship with 3.1.2.  For those with a direct interest, *PLEASE* test against the master branch on GitHub to ensure that there won't be major issues with this change so that they can be addressed before shipping 3.1.2.

Cheers guys.

[Nikolaos K. Dionysopoulos]

Considering that Bootstrap is the current Joomla! markup standard and that Michael did mention that JLayout will supersede it I don't see how our conversation is off topic. Besides, Amy, you'll see that not only the expressions used were carefully chosen (that part you seem to get it) but we did agree with Seth that we are on the same page. Where's the drama when everyone agrees? Calmly presenting arguments is not called "drama" it's called "discussion". The lack of discussion is what provokes drama. Actually, this discussion had positive results. No drama there, except in your imagination.

As to whether that was off topic, do remember that this is a mailing list, not a pinboard for announcements. Having conversation spring from an announcement is natural on a mailing list. Discussions don't spring out of thin air; they need a reason to start them.

So, yes, we need to be a bit more careful... and not troll a rare, constructive discussion. Thanks.

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Michael Babker]

Sorry if I misspoke or was misunderstood.  JLayout can't replace Bootstrap, it isn't a CSS framework ;-)

The intent with JLayout is to replace rendering markup in non-overrideable PHP classes with rendering markup in overrideable layout files.

[WP4J]

OK let me try and understand what this is all about... because I just wasted a few hours trying to get the simple bootstrap nav responsive menu to work on the frontend and for the life of me I could not work out why the submenus would start in an uncollapsed state and no matter what I did would they collapse. So then I created a test case and used the latest version of bootstrap and all of a sudden it worked fine...

This worked fine:

  <link rel="stylesheet" href="/media/com_foo/bootstrap/css/bootstrap.min.css" type="text/css" />

  <link rel="stylesheet" href="/media/com_foo/bootstrap/css/bootstrap-responsive.min.css" type="text/css" />

  <script src="/media/com_foo/bootstrap/js/bootstrap.min.js" type="text/javascript"></script>

  

this is all fraked up:

  <link rel="stylesheet" href="/media/jui/css/bootstrap.min.css" type="text/css" />

  <link rel="stylesheet" href="/media/jui/css/bootstrap-responsive.min.css" type="text/css" />

  <script src="/media/jui/js/bootstrap.min.js" type="text/javascript"></script>

So I take it the bootstrap that ships with Joomla has been hacked? Surely this nav must have worked even in the old version of Bootstrap? To be honest I don't really care as long as you keep consistency and NOT hack standalone frameworks, to do this is REALLY bad because it means people like me have to waste time trying to realise what the hell is going on and why stuff is just not working...

On Monday, May 13, 2013 6:43:55 PM UTC-3, Anibal wrote:

Hi,

Current Bootstrap 2.3.1 have fixed several bugs. For example this one about Dropdown on iPad and iPhone http://forwebonly.com/fix-for-twitter-bootstrap-dropdown-on-ipad-and-iphone/

As Joomla 3 is distributing Bootstrap Bootstrap v2.1.0, is it going to be updated in the next versions? Or, do we have to apply the fix to local files?

Thanks,

Anibal

[Amy Stephen]

On Thu, Jun 6, 2013 at 6:22 PM, WP4J <wp4j...@gmail.com> wrote:

 So then I created a test case and used the latest version of bootstrap and all of a sudden it worked fine...

 

By "latest version" - do you mean 2.3.2? If so, that's not in core.

Try 2.3.1 - that is what has been installed.

[Michael Babker]

Core's updated to 2.3.2, see this diff

As for hacking the core of Bootstrap, it is something we have had to do.  This is in a very isolated number of cases though and mostly works around our current state of almost always loading MooTools and jQuery.  There's some conflicts in the Bootstrap JS in this environment that won't be fixed in Bootstrap, leaving us no choice but to work around it.

[Amy Stephen]

On Thu, Jun 6, 2013 at 6:41 PM, Michael Babker <michael...@gmail.com> wrote:

Core's updated to 2.3.2, see this diff

Ooops. Thanks!

[Seth Warburton]

Hi Amy, 

I'm not quite sure why you have taken exception to this discussion. Yes, we got to talking about JLayout, because some of the Bootstrap markup now found in component views will live there. I think JLayouts will ease the difficulty of making Bootstrap updates in future as they reduce the number of places in which the same markup will appear.

I think we can all agree that it is important that we try as hard as possible to keep our version of Bootstrap in line with the Bootstrap project.

A style guide was mentioned because creating a defined markup standard is the one method of allowing this that I think could really work long-term. By insulating core markup from changes in Bootstrap we could quickly and easily drop in a new version of Bootstrap with only minimal effort. That isn't the case today. Yes, Bootstrap provides a defined markup standard; the problem for us all is that they keep changing it. A style guide was also discussed by a number of people at JAB, so not just some totally random idea I chose to drop on screen to annoy you.

The issue of having an outdated version of Bootstrap in Joomla isn't fixed once and for all now that someone stepped up to the plate and made all the required changes on this occasion. The root of the issue remains and it's set to get a lot worse with Bootstrap 3, unless we put our heads together and do something about it. 

Like Nicholas, I believe these groups are a natural place to have such discussions and like him I also think the discussion has remained on-topic and constructive.

I'm certain that any constructive input you might have would be welcome here Amy. If you have a plan about how we can save developers a lot of pain with future Bootstrap updates please save us all a discussion and share them with us. Mocking other people's suggestions and ideas isn't helpful.

Regards,

Seth

[Niv Froehlich]

Following this thread, and prepping and 'Intro to Bootstrap' presentation for user group in Toronto, I admit am a little lost with the questioning whether or not we should be embedding Bootstrap classes in HTML code.   The article cited in this thread http://ruby.bvision.com/blog/please-stop-embedding-bootstrap-classes-in-your-html cites the following as 'bad practice'

<div class="row">
  <div class="span6">...</div>
  <div class="span6">...</div>
</div>

The reason cited is 'bad semantics' and I think everybody on this thread get's that without further explanation.

But, as I understand it, the big selling point for Joomla! in standardizing on Bootstrap was not to produce pretty 'text-book' code - but to take advantage of standardization in the mark-up code (HTML) - standardization on a front-end code base that is already tested across common browsers widely used.

It seems to me that removing bootstrap classes from HTML would defeat the very reason it was adopted by Joomla.

What is the 'recommended practice' from the Joomla! project?

Consider:

1) CSS3 is still rapidly evolving and becoming more robust

2) HTML5 is still a working draft (am I mistaken on this)?

3) jQuery, which is tightly married to Bootstrap, has dropped support for I.E. 8 (old news now)
4) Bootstrap itself will likely through several iterations.

All of these factors will, of course, invariably lead to mark up which will need to be updated (i.e. no such thing as 'future proof' HTML classes!)

In this context, I agree with Seth that "By insulating core markup from changes in Bootstrap we could quickly and easily drop in a new version of Bootstrap with only minimal effort"

My question is, is that possible?  How is that done while maintaining the 'sought after standardization' for designer/developers?

I'd love to know (there a heck of a lot of people a lot smarter and more experienced than myself on this thread - so I'm not saying it can't be done - I'd love some insight).

But the next question is, why are we adopting Bootstrap if we are not going to standardize the markup we are using?

Bootstrap may have bugs, but is there such a thing as 'bug free front-end RWD SDK'?

IMO - Bootstrap seems like the best thing we got - inclusive of 'embedding Bootstrap classes' but I am very curious from this thread about that and to hear some more opinions.

N

[Seth Warburton]

Hi Niv, 

Some great questions! Really though, the issue of how we use Bootstrap (via mixins or via embedded classes) is really separate from the update issue. Whether you embed span-6 in your markup or you apply it in your css with something like; 

.my-awesome-module {.span-6}

when Bootstrap decides they will change the syntax to .col-6 then we have a problem either way and we need to reflect those changes either in extension code and core markup (in the case of embedded classes) or within our templates less/css files (in the mixins case).

The approach I suggest would take any new changes and map them via mixins to the existing classes we all know and love. Done correctly this would mean;

a) Our (J)Bootstrap classes do not change over time, irrespective of what Bootstrap does,

b) Any work in mapping new>old would happen in only one place,

c) You could use both existing (J)Bootstrap classes and any new Bootstrap classes,

d) You could either embed those classes in markup or apply them via mixins, as you can now. 

E.g.; 

jboot-buttons.less could import all current/new Bootstrap files, without any J! alteration and then use a mixin to map any forward changes to our existing Bootstrap markup; 

.btn,

.button {.button;}

This for me, seems the least painful approach as is means we will never again make updates in core markup (or ask extension devs to do that).

On the other question, it is my experience that the most future-proof html classes are the ones you never write. I'll only use a class when there is no other way to target an element, often there is, e.g.: 

[role="navigation"] {

    .navbar; /* Applies a navbar style to the primary nav element */

    ul {

        .nav; /* Throws the list into the nav style */

    }

}

A side benefit is that my markup stays shiny, clean and light and is completely framework agnostic.

Best,

Seth

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

[Bakual]

The only way to be future proof and have "good" CSS classes in our output would be to have some "abstraction" layer. This means we would need to create our own "style guide" as mentioned already.

However if we do that, there is indeed no longer a need to include Bootstrap into core. The style guide would be our "new" Bootstrap.

While this would of course be the "best" solution, the problem is that we would have to develop everything ourself. We would need to define the standards, provide examples of how to include it, write good documentation and everything. All that is already lacking in Joomla for years and I doubt we could come close to the quality Bootstrap offers already for free.

So while it may not be the best solution, it's for sure the one that works :-)

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

[Niv Froehlich]

Seth,

Thank you - I really appreciate your response.   My shortcoming in this discussion is having only a cursory understanding of LESS, but even as CSS3 continues to evolve, it also becomes easier to target elements without the necessity of classes or ids.

N

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

[Mark Dexter]

I may be missing something basic here. If Bootstrap lacks something we
need (e.g., for accessibility), would it make sense for us to fix this
in Bootstrap and then try to contribute this back to the Bootstrap
core? I don't think it's realistic for us to create our own markup
standard. Just look at how challenging it has been for Bootstrap, and
that is their main mission. Our main missing is making a great CMS,
not a markup standard.

The #1 reason for adopting Bootstrap was to have a markup standard
that 3pd's could use with the reasonable expectation that template
makers could style their markup without a lot of individual work for
each component. Of course Bootstrap will evolve and change, and we
will have to "suck it up" when they do -- and try (as much as
possible) to time major Bootstrap updates with major Joomla versions.
But imo having an imperfect standard is still a whole lot better than
no standard, and Bootstrap seems to be as good as it gets.

My .02. Mark

[Amy Stephen]

On Fri, Jun 7, 2013 at 4:30 AM, Seth Warburton <se...@internet-inspired.com> wrote:

Hi Amy, 

I'm not quite sure why you have taken exception to this discussion.

I don't take exception to this discussion and I apologize if my attempt at humor came off as mocking. 

What I find concerning is that people who have put time in to update Bootstrap and have opened this discussion for the purpose of reaching out to the community to enlist their involvement in testing aren't able to keep this one channel clear for that purpose.

There's a pattern of interruptions that begin with frustration expressed about how change negatively impacts developers and users, then others join in to help ease the frustration, or share their perspectives, and good discussion ensues. But left in the wake is an unanswered call for testing -- which ironically could help address those quality assurance concerns to begin with. I just that we need to find a better way.

I guess the answer is to somehow balance these diverse activities in such a way that the discussions around broader themes are supported and encouraged, but we also try to nurture and protect the specific efforts and try not to interrupt either but recognize -- these discussions really can't co-exist in the same thread without creating problems for the other. If we can do that, it would go a long ways, I believe, towards easing that frustration with change.

Thanks for your efforts, Seth.

[Niv Froehlich]

Mark,

That's my understanding of why Bootstrap was adopted, even with it's imperfections - my thoughts to cope with customization are that it's better to rely on Bootstrap classes, but add our own custom classes into the mark up in addition when needed as not interfere with 3pd's expectation of how their components will render.

So for example, I like my form inputs to stretch the full-width of available screen size on smaller devices  (most of my forms take up 1/3 to 1/2 the screen width for large displays, to 100% for smaller media, and Bootstrap sets fixed-widths).   If I put in custom CSS without an additional new 'namespaced or unique' class  and mess around with Bootstraps fixed-widths, this will cause unexpected results for 3pd mark up.   So I am adding more classes, not less, to the HTML in order to preserve Bootstrap's expected behaviour.

I'm still trying to figure out best-practices - but my thoughts are, intuitively, to preserve Bootstrap's classes and native behaviour as much as possible first and foremost, worry about 'pretty semantic market' as a distant second.'

This, to my mind, achieves the goal, as you state, "#1 reason for adopting Bootstrap was to have a markup standard that 3pd's could use with the reasonable expectation that template makers could style their markup without a lot of individual work for each component."    Having expected results means sticking with the Bootstrap classes as much as possible.

I also imagine we might be putting more effort into making the HTML 'future proof against Bootstrap revisions' rather than fixing any issues after the fact.

I'm not sure if this is the common experience - but with Bootstrap, most of my time and effort is spent figuring what 'behaviour and layouts' I want in the context of RWD - once that's figured out, the   actual process of getting the HTML/CSS is fast, especially since we are working with 'expected behaviour' and know what adjustments to make to the CSS to 'band-aid' Bootstrap quirks.

Anyways, I'm just learning - so these discussions are invaluable to me as I try to figure out and adopt best-practices that jive with the Joomla! community so I really appreciate everybody's thoughts and input.

N

[Anibal]

As a side note about the near future, upcoming Bootstrap 3 motto is "mobile-first", we can begin checking the impacts here:

http://rc.getbootstrap.com/

Thanks,

Anibal

[Niv Froehlich]

I'm liking the proposed changes for 3.0 - thanks for the link! 

Bootstrap 3.0 markup (i.e. classes) may not play nicely in the sandbox with previous versions - so that will likely affect the JUI efforts.

It'll be interesting to see approaches to how that's handled.

N

Thanks,

Anibal

--

[Seth Warburton]

@Mark - Totally understand where you are coming from, the problem is that a standard that is constantly changing is barely any more useful than no standard.

The changes coming with Bootstrap 3 are so extensive that is wil be extremely painful to adopt them given the current implementation. There will be changes to almost every single view, front and back end and changes for every extension. These changes of course will also break backward compatibility. 

It is my opinion that such extensive re-writes can't realistically continue to happen. I'd like us  to be in a position where every major release of Joomla does not require rewrites of all core outputs and all 3rd party extensions. The maintenance burden of that  approach simply isn't sustainable, IMO.

@Amy - Thanks for clarifying. I think you're right, these discussions should continue on new threads rather than dilute this one.

Best,

Seth

>>>> an email to joomla-dev-general+unsub...@googlegroups.com.

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

>> email to joomla-dev-general+unsub...@googlegroups.com.

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

> email to joomla-dev-general+unsub...@googlegroups.com.

[Mark Dexter]

"Constantly changing" is an interesting term. From what I can tell,
Bootstrap 2 was released January 2012 and Bootstrap 3 is going to be
released in the near future. So that's 18-24 months between major
releases. That sounds familiar to me.

As far as a changing standard, I think this is unavoidable whether we
are talking bootstrap, Joomla, or any other markup standard. The world
keeps changing. From what I can see, Bootstrap 3 is trying to keep
pace with the fact that mobile devices are taking over with respect to
web access and will soon outnumber computers in that regard.

From a developer point of view, it seems to me that we are better off
with a standard, even if it changes with major releases, than we are
without one. And the arguments for adopting Bootstrap in the first
place still seem perfectly valid to me. If we adopt Bootstrap 3 for
Joomla version 4, that makes sense to me. We are breaking b/c with
Joomla v4 in any case. It means we are stuck with the "old" bootstrap
for a bit longer than ideal on Joomla 3.x perhaps, but that doesn't
seem too bad.

If devs have to update their markup for Joomla 4 / Bootstrap 3, that
doesn't seem like the end of the world, especially if it means that
there is a standard for how to write markup for Joomla v4.

Do we really think that we will come up with a better standard than
Bootstrap? Do we really think we will create a standard that doesn't
require changes to keep up with changes in the web?

Mark

On Mon, Jun 10, 2013 at 3:32 AM, Seth Warburton

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

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

>> >> email to joomla-dev-gene...@googlegroups.com.

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

>> > email to joomla-dev-gene...@googlegroups.com.

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

> email to joomla-dev-gene...@googlegroups.com.

[Websiteconcepts]

+1 for Mark

Ruud van Zuidam
M  DE :  +4915730448257 oder  NL : +31637170938

[Ove]

+1
Is there an alternative? Guess No.

[WP4J]

I don't mind this and agree with Mark, but one thing I would like to ask is that whoever implements bootstrap in whatever form takes the time to test it on the frontend. From what I am seeing navigation components are basically unusable on the frontend due to the whatever hacks have been made. 

Twitter provides this page: http://twitter.github.io/bootstrap/components.html

And I would suggest that any template or hacked version of bootstrap that is shipped with Joomla fully complies with this, ie make a component that just outputs that markup and loads whatever components required from the bootstrap library and it should look right, I would even go as far as say make a component that displays all of the test / examples located on http://twitter.github.io/bootstrap/ . This will give a resource for core devs to check against as well as 3PD theme developers. 

I want to be able to use twitters documentation on bootstrap as I know Joomla's docs will never be up to the same standard (and shouldn't have to be).

[Niv Froehlich]

@ WPJ4 agreed - further to what to you say, it is probably good
practice to keep any Bootstrap components 'as simple as possible,'
minimizing customization and CSS overrides

This would lead to greater consistency and make any 'bug-fixes' easier.

@Amy - we are so off topic from the original thread - mea culpa - apologies.

[Anibal Sanchez]

Hi,

In the PR with the update to Bootstrap 2.3.2, you can check that Bootstrap is almost unmodified (no mayor hacks). It was only changed to support Mootools compatibility (div.model and hideme).

Of course, each template can override the default definitions or add new behaviours. Eg ChosenJs.

Thanks,
Anibal

2013/6/10 Niv Froehlich <nivs...@gmail.com>

You received this message because you are subscribed to a topic in the Google Groups "Joomla! General Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-general/HFqD0q1U2vk/unsubscribe?hl=en-GB.
To unsubscribe from this group and all of its topics, send an email to joomla-dev-gene...@googlegroups.com.

[WP4J]

This is why we need the bootstrap display template so that consistency can be retained - if you look at WordPress you see that they have a theme unit test which allows template designers to confirm that their theme outputs properly in all situations. The bootstrap examples are virtually a readymade solution for us to use to achieve the same thing.

It has been stated in the past that the inclusion of Bootstrap was in effort to gain consistency for UI elements and this consistency implies a constant and that constant can be the examples on http://twitter.github.io/bootstrap/ . This is a great opportunity to make things a hell of a lot easier for everyone.

2013/6/10 Niv Froehlich <nivs...@gmail.com>

> email to joomla-dev-general+unsub...@googlegroups.com.

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

--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! General Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-general/HFqD0q1U2vk/unsubscribe?hl=en-GB.

To unsubscribe from this group and all of its topics, send an email to joomla-dev-general+unsub...@googlegroups.com.

[Niv Froehlich]

Agreed: To add, visit: http://jui.kyleledbetter.com/bootstrap

This looks the beginning of a JUI Library based on Bootstrap - anyone
know if this initiative has been taken any further towards completion?

Also, on that page, Kyle states the following:

- "Component developers have to be able to believe that their markup
and UI will load all the time, consistently. This is *why the JUI must
always be there for them*

and

-

"Developers can Develop (think SDK)

Most Joomla dev teams are tiny and don't have the benefit of a UI/UX
person. This results in longer dev cycles as the devs *try* and create
a UI instead of focusing on the core features of their component. With
Bootstrap, devs can rapidly prototype and develop their component and
leave the theming up to the template, where it belongs. Prime example:
AkeebaBackup (and all of Akeeba's awesome tools). They provide stellar
features but a less than perfect UI. We can now give them the UI
options they need. This will attract devs to Joomla as Apple's SDK did
to iOS."

N

>>> > email to joomla-dev-gene...@googlegroups.com.

>>> > To post to this group, send an email to joomla-de...@googlegroups.com.
>>>
>>> > Visit this group at
>>> > http://groups.google.com/group/joomla-dev-general?hl=en-GB.
>>> > For more options, visit https://groups.google.com/groups/opt_out.
>>> >
>>> >
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Joomla! General Development" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/joomla-dev-general/HFqD0q1U2vk/unsubscribe?hl=en-GB.
>>> To unsubscribe from this group and all of its topics, send an email to

>>> joomla-dev-gene...@googlegroups.com.

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

> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to joomla-dev-gene...@googlegroups.com.

[WP4J]

Well the way I see it is that we don't actually need a "JUI Library Based on Bootstrap" because we can use the existing one, it basically has most of the tools that one would need. The more custom stuff we add, the more problems we get with compatibility and more code to maintain - if we can stick to using the core bootstrap framework with minimal hacking it will be, in my opinion, better. 

If we can agree on some basic requirements for the Bootstrap Unit Test (for want of a better name) component that I have mentioned above, i would be happy to create it. My approach would be to create a simple component that mirrors the markup presented in the examples at http://twitter.github.io/bootstrap/ - just a simple affair to run all these example thru JUI. I think with this in place core developers and template devs alike will have a constant to test their work against to make sure nothing is getting "broken". Plus it is a good resource for extension devs to basically copy from to include in their own work - of course they can just go to the bootstrap site, but many might not realize or know about the inclusion of bootstrap or be unsure how to use it. An "in your face" example running inside Joomla would really clarify things I believe.

>>> > email to joomla-dev-general+unsub...@googlegroups.com.

>>> > To post to this group, send an email to joomla-de...@googlegroups.com.
>>>
>>> > Visit this group at
>>> > http://groups.google.com/group/joomla-dev-general?hl=en-GB.
>>> > For more options, visit https://groups.google.com/groups/opt_out.
>>> >
>>> >
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Joomla! General Development" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/joomla-dev-general/HFqD0q1U2vk/unsubscribe?hl=en-GB.
>>> To unsubscribe from this group and all of its topics, send an email to

>>> joomla-dev-general+unsub...@googlegroups.com.

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

> email to joomla-dev-general+unsub...@googlegroups.com.

[Niv Froehlich]

Just note that even the www.getbootstrap.com site has custom mark up.

Having the JUI - i.e. what we see at Kyle's web site, could serve as a
repository, or library, of commonly used elements and corresponding
mark up that developers could access and implement at their option.

This would lend to consistency and speed of development, taking the
guess work out designing UI's.

Of course, those who want to customize, can do so.

The same site can also serve as a 'test-bed' and include any patches
or workarounds needed.

N

>> >>> > email to joomla-dev-gene...@googlegroups.com.

>> >>> > To post to this group, send an email to
>> >>> > joomla-de...@googlegroups.com.
>> >>>
>> >>> > Visit this group at
>> >>> > http://groups.google.com/group/joomla-dev-general?hl=en-GB.
>> >>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >>> >
>> >>> >
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to a topic in the
>> >>> Google Groups "Joomla! General Development" group.
>> >>> To unsubscribe from this topic, visit
>> >>>
>> >>> https://groups.google.com/d/topic/joomla-dev-general/HFqD0q1U2vk/unsubscribe?hl=en-GB.
>> >>> To unsubscribe from this group and all of its topics, send an email to

>> >>> joomla-dev-gene...@googlegroups.com.

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

>> > email to joomla-dev-gene...@googlegroups.com.

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

> email to joomla-dev-gene...@googlegroups.com.

[Seth Warburton]

Mark, 

I've been suggesting that we simply lock-in the existing standard to isolate both Joomla core and 3rd party extensions from forward changes in Bootstrap.

I'm not sure everyone here appreciates the scale of the changes that v3 will bring. Do we really want to re-write everything with every major Joomla release if we don't have to?

>> >>>> an email to joomla-dev-general+unsub...@googlegroups.com.

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

>> >> email to joomla-dev-general+unsub...@googlegroups.com.

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

>> > email to joomla-dev-general+unsub...@googlegroups.com.

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

> email to joomla-dev-general+unsub...@googlegroups.com.

[Bakual]

If you can really make a standard which will survive Joomla 4.x, then this for sure would be nice. But given the current discussion, I don't think that's realistic.

2 years are a long time in informatics and the webtrends are changing fast. The CMS standard would need to reflect those changes. That's probably also the reason why Bootstrap 3 has so many changes in it with backward compatibility breaks.

I don't really mind if I have to update my layouts for Joomla 4.x. I will probably have to do a lot more changes within my code which will be harder to figure out. The layouts are most likely the smallest problem.

Of course I also don't mind if it isn't needed, but I don't believe in that. "Mobile first", web services, UCM, JLayouts and many more ideas float around which all will most likely impact our layouts.

[Anibal]

I understand Seth's current opinion about front-end framework stability. We are still migrating to Joomla 3 and Bootstrap 2.

Checking my crystal ball, I think Bootstrap 3 most probably be the required as mandatory for Joomla 4 ;-) .... or to the next trendy front-end framework LOL

Thanks,

Anibal

[Mark Dexter]

I think we need to understand why Bootstrap 3 is being released with
so many changes. I am NOT especially knowledgeable about UI/UX/HTML
5/Mobile (sadly the list goes on and on ...). From the little I have
read on the Bootstrap website it appears that they believe that fully
accommodating mobile devices required extensive changes. It would be
really great imo if some folks who ARE knowledgeable about this stuff
could evaluate Bootstrap 3 purely on the merits. If it really is just
"change for change's sake" then perhaps we should think about another
approach. However, if it is really well thought out and will position
Joomla to work really well on phones and tablets (which, after all,
appear to be the future of the internet at this point), then the idea
of adopting Bootstrap 3 for Joomla V4 seems sound to me.

I have been impressed as a Bootstrap user with the simplicity of using
it and the great documentation they have. It seems to me to be very
well thought out and I would guess that Bootstrap 3 is also well
thought out. But it would be great to hear more informed opinions on
this subject.

I think we would all agree that using a solid and popular standard has
many advantages over a "roll your own" approach, but only if that
standard is really good.

Mark

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to joomla-dev-gene...@googlegroups.com.

[Niv Froehlich]

1) This discussion really needs it's own dedicated thread - can we do
that? Might I suggest we start a new thread called "JUI/Bootstrap
Roadmap"

2) I've been informed that Seth is the lead on this project - Seth,
I'd love to work with you on this.

3) I don't share the concerns about having to update when Bootstrap 3
comes into play. Here's why (IMO):

- I'm currently preparing a workshop with exercise files for the JUGT
- Bootstrap 101 - Introduction to Bootstrap for RWD

- Once you get familiar with the code base, BOOM -> RAPID UI
Development results. That's one of the biggest advantages with
Bootstrap. Whatever the changes, we can count the ability for rapid
implementation.

- We should be working on some provisions (and there have been some
great suggestions) in order to make that transition

- With UI's, I've found that 80-90% of the effort is in establishing
layout and behaviour (UX), especially with RWD, once that's done, the
rest is academic. For example, as a front-end developer, if you gave
me a screen shot of what you wanted the UI to look like, you've done
90% of my work for me - coding it up is fast. If we have a library
that establishes these items, then changes to the underlying code is
not a big deal.

4) I would like to see the continued development of Kyle's Joomla!
User Interface Library (see http://jui.kyleledbetter.com/). I
understand from Kyle that b/c his new work obligations, he is not able
to contribute in the same way as before.

How can get up to speed and help out? (Seth, as you are the lead -
this one is directed at you).

I have a great deal of gratitude for your efforts - I certainly see
the benefits and want to be a part of this initiative.

Best,

Niv

[Seth Warburton]

Bootstrap 2 is far from perfect and has serious issues in a number of respects, which is why Bootstrap 3 is being developed. If it was perfect there would clearly be no need to develop it further.

Bootstrap 3 is a huge improvement with many, very welcome, modifications. It's certainly not a case of change for changes sake. A great deal more attention has been paid to performance, semantics, architecture  and standards than in previous releases and it would be a very great shame if Joomla did not benefit, as rapidly as possible, from those improvements. 

That said, there are many areas I can still see for improvement and, as Bootstrap is a very active project and evolving quickly I think we can also expect to see major, and again welcome, changes for Bootstrap 4. 

It is for these reasons that I want us to consider how we can best rapidly incorporate future updates. Though some people are apparently suggesting that re-writing everything with each major release of Joomla is just fine, I don't think it sensible at all. I'd rather see developer effort go into actively improving Joomla, not simply expending energy treading water.

I'd like to see a future where we could drop Bootstrap 6.1 (or indeed the then current framework of the moment) into Joomla 4.5, without any modification to Joomla code or 3rd party extensions.

Best,

Seth

> email to joomla-dev-general+unsub...@googlegroups.com.

[Matt Thomas]

+1 Seth. In sorts, it almost seems like we need a markup abstraction layer, like RAD for software.

Any thoughts on how that can be done? Would introducing some sort of system like moustache (
http://mustache.github.io) help, in place of common markup, or am I missing it completely?

Best,

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

Composed and delivered courtesy of Nexus 7.

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

[Mark Dexter]

It is an interesting concept. I think Christophe Demko at one time
proposed creating a series of JHtml classes to do something along
these lines (pre-bootstrap iirc but similar idea). I think he had some
proof-of-concept code, but no idea where it would be now or if it
would be useful at this point.

So, if I am understanding this, we would ask devs to use JHtml classes
(or something equivalent) to create some or all of the HTML markup,
instead of writing raw HTML. Then we could change the JHtml classes as
needed to create the newer Bootstrap output, but the dev's source code
would be unchanged. Is that about right?

If so, what would really help me better understand this would be a
proof-of-concept. If we could for example identify one specific
example where we have this issue -- either with current 2.x or between
2.x and 3.0 -- then someone could put together a POC showing what the
JHtml class would look like and how it would work for this example.

One downside I can see off the top of my head (besides the obvious one
of developing and maintaining this layer) is that devs would need to
know when to use raw Bootstrap HTML and when to use our "compatibility
layer". For example, we could only provide these helper classes in
specific areas where we have the issue, or we could try to provide
helpers to create most or all of the output.

If someone wants to run with this and whip up a POC, that would be great. Mark

[Anibal Sanchez]

I think HTML is a very flexible language, and there's no way to build a structure of classes to model it. You end tied to an basic practice.

For example, yesterday, I've just discovered how AngularJS frameworks works adding ng-* attributes and syntaxis for templating. Eg:

<ul class="phones">
 <li ng-repeat="phone in phones | filter:query | orderBy:orderProp">
  {{phone.name}}
  <p>{{phone.snippet}}</p>

 </li>
</ul>

If I have to translate it to JClasses.... very complex, and you lost the readability.


Thanks,
Anibal

2013/6/12 Mark Dexter <dexter...@gmail.com>

You received this message because you are subscribed to a topic in the Google Groups "Joomla! General Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-general/HFqD0q1U2vk/unsubscribe?hl=en-GB.
To unsubscribe from this group and all of its topics, send an email to joomla-dev-gene...@googlegroups.com.