Reducing JS dependency for Presentation

[scottjehl]

In the first (and current) version of the framework, we used a combination of data attributes and JS feature testing to ensure enhancements – both JS and CSS – were not applied in unqualified environments. This allowed us to leave C-Grade environments un-enhanced, and usable, both visually and behaviorally. The gist of it was we'd apply a data attribute to an element, say data-role=listview, and in JS, we'd run our baseline feature qualification of CSS3 Media Query support, and in supporting environments, we'd add classes to that element that the CSS would style (and also add behavior with JS at that point too).

Fortunately, we've found better ways to qualify CSS application since then. One simple way is to just qualify the CSS itself by ensuring it is always wrapped in an inline media query (or a media attribute on the link element). @media only all is a media query we can use to say, "if media queries are supported," within CSS itself:

<link rel="stylesheet" href="https://github.com/jqm.css" media="only all">

or...

@media only all {
    ...CSS here is qualified to media-query-supporting browsers
}

If we take that further, we would ideally have styles that are written against markup attributes that are already present when the markup is delivered, rather than having to wait for them to be added through JS. This is typical of custom web development patterns, but has been harder for us to do in a framework setting due to the complexity of some of the markup our components use.

This should be addressed in a couple of ways: both by simplifying the markup for our components so that they're easier to serve directly from the server-side, and considering choosing either classes or data attributes as our mechanism for configuring widgets - but not both. And then styling against one or the other from the start.

[toddparker]

Moved this to 1.4 since we're going to tackle bigger CSS and HTML changes there.

[pillex]

not sure if i fully understand this, but i strongly support it ;-)

despite the really sexy UI, the overall performance hit makes jQM an irresistible hooker you barely can afford.

there seems to be a contradiction: the heavy use of javascript to serve older hardware not only slows down older hardware tremendously, it also makes current hardware unresponsive,

this will fade away in some years, when the performance of mobiles quadrupled. in google chrome for desktop the responsiveness is perfect. but until then:

please drop the use of javascript for page-init and initial decoration AS MUCH AS POSSIBLE.

browser css styling seems to be much faster than cycling the dom with JS, applying classes - when the browser would already be finished.

[pillex]

a real world example:

the site, basically a listview with 30 entries and a menu on top.

samsung H1 running megoo linux. top notch hardware 2 years ago. on this hardware the site is a bit laggy but still usable. on a iphone 3gs it's fast and responsive.

than a change to jQM. looks much, much better. much easier markup for much hotter widgets than before. great! thanx a lot guys!

the downside: on the samsung phone everything still looks good, but it's so slow that it's almost not usable anymore. on the iphone you suddenly have to wait for everything.

i changed to lab.js which loads .js files in parallel with html. now i have the " flash of unstyled content". what's interesting, you can see how fast the browser is and how slow jQM.

no matter if only the small login form or the long list-view:

-the page, styled with css gradients and box-shadows and everything css can offer, appears very quickly.

-then jQM kicks in, the page goes blank and you WAIT WAIT WAIT WAIT and finally you see the page. and when you start scrolling immediately you realize that jQM is still working. it just doesn't feel good.

the point: the iphone browser can display complex css styled content very quickly, but styling with JS makes it look old and poor.

so yeah, go for Reducing JS dependency for Presentation

[woutervanwijk]

I complety agree with pillex.
I use JQM for my Mopidy Webclient project ( https://github.com/woutervanwijk/Mopidy-Webclient ). JQM is just too complex, since it applies all kinds of classes to all kinds of elements when rendering. It not only gets real slow because of that, even on new devices, but it also makes modifying it to suit your needs amazingly difficult. Because all kinds of classes are added at runtime, often the styles you apply in a sheet, don't work very well. That's really annoying. It also makes inspecting rendered elements in the browser more complex.

This is not necessary, Bootstrap works very well and its way more speedy. Though I really like the project (listviews, truncation, panels, etc), and the possibilities I would only recommend using JQM for simple sites, unless this is solved.
If all this complex stuff is necessary for older devices and you really want to keep supporting older devices, maybe it's good to create JQM light or something?

[jaspermdegroot]

Here is an update.

Reducing the markup has been tackled in branch "next" which we will merge into master soon. Especially buttonMarkup was generating a lot of markup and that is completely gone. This means that the framework adds the classes to markup that is already there so users could add those classes themselves.

There are still some widgets that need a wrapper that also has the classes for presentation. We will work on an option that allows users to not have the framework generate the wrapper so users can add the wrapper including classes in their markup.

We discussed styling against data- attributes, but that isn't possible because we support namespacing.

Wrapping our CSS in a media query instead of running a support test sounds like a good plan. This would also resolve this problem: #6057 (comment)
Some things to look into. IE8 that doesn't support media queries, but should be A-grade anyway (IE7 will be C-grade as from 1.4). Because we are going to use pseudo element for icons, supporting this is another condition for becoming A-grade.

[jaspermdegroot]

Because we need to test pseudo class support and support IE8 as A-grade we can't use a media query at the moment. Closing this ticket as fixed.