... because I really think this would be a great step forward...
http://view.jquerymobile.com/1.3.2/dist/demos/widgets/panels/panel-fixed.html
... because I really think this would be a great step forward...
http://view.jquerymobile.com/1.3.2/dist/demos/widgets/panels/panel-fixed.html
I really want to add my +100 to this although I know that the chances of anything happening here are a million to one. I don't see why it has to be YUI or jQuery. I think personally it is about best tool for the right rob. And by that reasoning I see both as useful.
The current status quo is as good as I think it will get. As long as Moodle continues to have jQuery stored in lib and make it easy for me to dynamically load modules. Then that is a great bonus for us theme developers. If themes like Essential continue to gain traction with users then HQ will need to decide to that constantly want to port jQuery to YUI (aka the bootstrap code), leave all jQuery dependant code as plugins or make a philosophy shift based on what the community wants. In short the demand and need will both need to be greater before I see any such shift being contemplated.
That being said, I am working on a new theme at the moment that uses a great set of jQuery plugins. These will include:
Each of these provide great functionality and visual flair with minimal impact on load. The jQuery development community is flourishing with many fantastic plugins such as these. It is for this reason that I am a huge fan. To do this in YUI, well, I would not even want to think about it.
Julian
As an almost capable user, I am sorry to say that the list of yui scripts posted by Dougiamas didn't do much to convince me that yui is the way forward. Seems mostly like eye-candy. Currently, I don't use jquery on moodle, mainly because it is not recommended. But I find many more jquery routines that offer user interactive options not seen in yui. Of course, the best option would be to have the both, and may the best javascript win. But not likely.
@Martin, what are you actually saying here? That there are enough functions in YUI that there should be no complaints? or??
@Julian: are you saying what you want to do (effectively and fast and powerfully with style) cannot be done with YUI? Or is it just difficult to do? Or fiddly?
@whoever: Is YUI quite difficult to learn, or just different to JQuery?
---
I guess my basic question to MoodleHQ has to do with why there are so few really nice looking themes in the core? Is it just priorities, or are there no coders with the inclination to do it?
Why is something like Essential not in core? Can it be coded in YUI and come with a shiney new core Moodle install??
@You guys wanting JQuery: can YUI really not cut it to get nice looking themes?
I kind of wonder how rational talented literate wonderful smart hardworking coders cannot get themselves together and create something in core us pond scum end users can actually live with on a daily basis and like. Really like.
I may regret making this post, but I am curious, having just spent a little while trawling the docs and it is not really clear.
-Derek
@Derek
For a typical moodler both jQuery and YUI are difficult to learn and write and that's why many of us want to use ready-to-use widgets and scripts if we can easily modify them...
http://w3techs.com/technologies/history_overview/javascript_library tells something - developer forums may give some other reasons for using yui instead of jQuery.
The YUI / jQuery debate could go on for years with each faction buffeting against the other. A Catch-22. Given the current state of play, the only workable solution is for core to be YUI only and contributed plugins permitted to use jQuery, as it currently is. Then when the JavaScript Framework arms race is resolved, then so can this feud.
I think more effort needs to be expended on refactoring base / bootstrapbase core CSS to reduce and remove duplications, more renderers.... etc. My New Years wish list
Will do as much as I can, and have started already -> https://github.com/bmbrands/theme_bootstrap/pull/74 . Please see my comment on https://github.com/bmbrands/theme_bootstrap/pull/80.
Just seen the bit about the FONTS why is no one is using the setting that Petr added?
url([[font:theme|glyphicons-halflings-regular.eot]]) format('embedded-opentype');
Also what is the point of CDN fonts if we can use the above font setting and add fonts to the theme?
If the font is not stored in a theme...then yes I can see an advantage, however, I did read somewhere that these linked to fonts can slow Moodle down.
Cheers
Mary
Trying to use Petr's code Mary, see new comment on https://github.com/bmbrands/theme_bootstrap/pull/80 - snag being a combination of two variables https://github.com/bmbrands/theme_bootstrap/blob/master/less/bootstrap3/variables.less#L70. Use of CDN fonts should be a theme setting.
MD has made his position clear, and being his project I respect that. Having core rely purely on YUI is his call and I even understand the reasons.
What I a happy about is that jQuery is in moodle's lib and is easily accessible from theme's. This is a great win for us still and allows us to do the "edgy" stuff that we want. Sure, it means it won't get into core, but judging by the downloads of Essential alone (over 47,000) and the other jQuery using themes I think it really matters not.
My last comment, which I have made before, is that MD has been known to change his mind when there has been strong community push for certain features. So I say we keep building cool themes, see if the community gets on board, then and only then can we make a big push for change.
In the meantime, lets focus o fixing core. The icons is a great start, next should be a focus on new renderers and better css guidelines. I think that would help us far more.
Julian
on an internal cms a colleague used to have nice pictures of snowmen, easter eggs and other seasonal gifs depending on the time of year.
managers complained it was off brand etc, so he restricted the display of the images to not be visible to their IP address.
if (!$moodlehq) {
<script src="//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min.js"></script>
}
simples.
Indeed! Contributed code does not suffer from some of the constraints that core code has upon it.
YUI is a powerful library. But jQuery has its place too. I sort of get the reasons that HQ does not want to support yet another technology as have been stated in other threads. So, perhaps lets see how things go. Perhaps by 2020, Moodle will be written in Node.js and served portably on our wrist watches over WiFi.
There is something inherently wrong with this article - https://medium.com/cool-code-pal/e030d01321ec.
I think its missing the understanding of the nature of the client / server architecture. PHP is run server side and JavaScript (YUI / jQuery.... frameworks) client side. At the server end, PHP is dynamic and is used to produce static content which is then passed to the client. The client can have no knowledge what so ever that the content was ever produced using PHP (or Java, Python, C++ or COBOL - yes somebody has made a COBOL web server with templating technology - etc.) or is in a position to dynamically adapt the content in PHP. Hence the use of a different technology - JavaScript - to add dynamism to the static content.
Therefore as you have greater control over the server, you do as much as possible there, but to add dynamism at the client end you have to use JS or any other client side technology. Its all about where the 'execution of code' takes place, so to simply say to ditch all jQuery and do everything in PHP is misguided and in fact wrong. You will end up with the static web pages of the 1990's.
Unless somebody comes up with client side PHP where the server dispatches 'snippets' of code to be executed at the client end. But this would mean internal browser support and a whole mine field of security issues to be sorted.
P.S. This is the COBOL thing I was blabbering on about: http://azac.pl/cobol-on-wheelchair/.