Listitem title, subtitles, links should be marked up with class names, not implied

[gitToad]

Currently list items are marked up with a mixture of implied and explicit markup.

For example, the first A tag is used to markup a linked list
The second A tag is used in a split button list
P tags are marked as subtext
H1-H6 tags are marked as main text
the first IMG tag triggers a list to be a thumbnail list

However,
count indicators are done by adding a ui-li-count class
supplemental right hand side information is supplied by adding a ui-li-aside class
inset lists and icons (vs thumbnails) are also done via explicit class names

1. This is somewhat inconsistent
2. explicit class names for A,P,H,IMG would be more readable code, even if slightly longer
3. the enhance code in the listview plugin (Navigation from one page back to multi-page template #2406 - Fixes #2541 — Properly applies “disabled” styling and logic to custom form inputs. #2711) does a "deep" lookup of the A, IMG etc .tags. So if you want to include ANY image (like rating stars or a RSS feed icon next to your text etc.) it will interpret that as signaling that you want a thumbnail list item.
   I think this kind of markup enhancement is very error prone and inflexible.

At least do positional markup so only direct descendants of the LI trigger the various list item modes ie LI > IMG and LI > P etc.

Preferable imho would be explicit semantic markup in the LI direct descendants:
<IMG class='ui-li-thumbnail' ...>
<A class='ui-li-link' ... > for "where clicking on the li should take me"
<A class='ui-li-link-alt'....> for "alternate right hand side split button list link"
This means that you can then also create collapsible list items, whose content can be independently marked up and will not cause bogus li style changes just because deep down there is a IMG or A

[toddparker]

I think we need to figure out ways of adding flexibility without requiring people to write a bunch of extra markup or classes for the standard configs. We'll give this some thought and feel free to refine your proposed ideas here.

[scottjehl]

Using data- attributes would be preferable here, as we really want to get any classes out of the foundation markup (c-grade browsers shouldn't get a half-styled page).

Listview is the worst offender for this, but ui-body classes tend to creep into our demos frequently as well.

For the listview aside class, we could probably use an html5 aside element, but there are other situations we'll need to work through that you posted above.

We'll give it some thought but I like your idea for using descendent selectors as a starting point at least.

[gitToad]

Wouldn't explicitly assigning classes (even though admittedly a bit more typing) also allow some better default styling through css in case the browser is not running javascript and the enhancer never gets called ?

[scottjehl]

perhaps, but we'd need to prevent our a-grade styles from applying on those devices, since they'd likely result in an unusable experience in many cases. The data- system we use everywhere else makes that division quite clean, and it's foolproof for devs to configure.

[gitToad]

Todd, Scott
thanks for responding. You guys are doing an awesome job on JQ Mobile. We are all drooling for all the other controls you tempted us with in the original design mockups: http://jquerymobile.com/designs/ :)

Meanwhile, some other comments re enhance() in my exploration about integrating jQ UI widgets into jQMobile. In particular, the results of a sleepless night trying to make DatePicker work in mobile. (It does, now)
http://forum.jquery.com/topic/mixing-jquery-mobile-with-jquery-ui-widgets-don-t#14737000001701900
Perhaps, in addition to more explicit markup (data-X etc.) we can also have some form of "dont touch this" that can be applied to imported 3rd party plugins. I experimented with a ui-no-enhance class for this purpose...

[scottjehl]

Nice work gitToad :)

We had done some static work on a mobile-based datepicker theme: http://jquerymobile.com/test/experiments/ui-datepicker/

you can see in the HTML source we've made a few JS changes to bring the theming up to speed, but they only work for the initial view until they're actually baked into the plugin itself. Is this something you'd be interested in taking on?

On the topic of "don't touch this", see data-role="none" or the page plugin's keepNative option. Is that what you're looking for? Doc here: http://jquerymobile.com/test/#docs/forms/docs-forms.html

[gitToad]

Ah thats great, I really should read the docs more :)

Tried it and indeed makes those 3 changes I had in jquery.mobile.js unnecessary. Nice.
I updated my post so I don't lead people down the wrong path, also added a little hack to prevent the Safari "dipping address bar" when selecting a date.

[gitToad]

Some more on list styling, css
http://forum.jquery.com/topic/your-thoughts-on-list-elements-and-styling

[matthew-dean]

I think the fact that jQuery Mobile relies on JavaScript for styling is it's biggest failure point right now.

[scottjehl]

I think we're going to close this one out, as overall, people seem pleased with the ease of configuration that listviews provide. Listviews are, in essense, merely a convenience mechanism for adding classes to markup, so we want to avoid having to assign classes from the start where possible.

If you need something custom, you can override the CSS that listview provides, or not even use the plugin at all, as the markup additions are fairly simple to reproduce without using JS at all. Thanks!