I may be crucified for asking this, what is the hype with jQuery Mobile? It is a complete mess and a missed opportunity. The framework searches for data attributes and adds CSS classes. Not only does this mean you have to memorize these data attributes, but it is an extra process.
It is still using Sizzle when smart phones support querySelectorAll. I understand its slightly slower when looking up an element by its ID, but how much content are you displaying on a page? Between this and unneeded checks (attachEvent) it makes it more bulky.
I wanted to share this with you. Including the javascript (comparible to jquery but written for a phone) and css, it comes out to a total of 7k. Without the script which is not needed, its about 5k. This includes the 32x2 gradient images (since older Androids do not support gradients in CSS).
You have to remember that jQuery mobile is trying to include support for the Windows phone.. which is running IE7. Windows Mobile 9 is the only phone running IE9...
So, yeah I guess if they drop Windows Mobile 7 support, they could trim down the library a bit.
Thanks. I missed that on the compatibility page. Hopefully they will do a clean up. I still do not agree with the architecture on reading custom data-attributes and adding a class name. Most of this stuff can be handled without that process. It does seem like its a missed opportunity to take advantage over the new HTML 5 semantics.
With the exception of the form controls like the sliders, most correlate with a HTML5 tag. Header, Footer, Section, Nav, Menu, and Details (collapsible content) handle most ui elements. I shouldn't have to write data-role="header" on a header.
In the screens I sent you, I use a common class name for major elements so I don't hijack a users rules.
I know this doesn't handle the count-bubbles and the extras (those are separate classes) but it does handle most ui-controls. I don't want to just pick on Jquery Mobile, because I am seeing many of these frameworks doing the same thing with translating data elements. It makes everything bulkier and there isn't a good reason for it.
Sorry for the ranting to the css-trick users. I have no one to blame but myself and Notepad.
It is still using Sizzle when smart phones support querySelectorAll. I understand its slightly slower when looking up an element by its ID, but how much content are you displaying on a page? Between this and unneeded checks (attachEvent) it makes it more bulky.
I wanted to share this with you. Including the javascript (comparible to jquery but written for a phone) and css, it comes out to a total of 7k. Without the script which is not needed, its about 5k. This includes the 32x2 gradient images (since older Androids do not support gradients in CSS).
Menu with Dividers
Menu inside Section
Am I wrong thinking this?
So, yeah I guess if they drop Windows Mobile 7 support, they could trim down the library a bit.
With the exception of the form controls like the sliders, most correlate with a HTML5 tag. Header, Footer, Section, Nav, Menu, and Details (collapsible content) handle most ui elements. I shouldn't have to write data-role="header" on a header.
In the screens I sent you, I use a common class name for major elements so I don't hijack a users rules.I know this doesn't handle the count-bubbles and the extras (those are separate classes) but it does handle most ui-controls. I don't want to just pick on Jquery Mobile, because I am seeing many of these frameworks doing the same thing with translating data elements. It makes everything bulkier and there isn't a good reason for it.
Sorry for the ranting to the css-trick users. I have no one to blame but myself and Notepad.