Knut Kristian Johansen’s blog

jQuery Mobile and client generated pages

knutkj — Sun, 22 Jan 2012 23:48:35 +0000

Normally you would use jQuery Mobile for server generated pages. But you can also create the pages dynamically with JavaScript in the browser. To make this work we need to do a little jQuery Mobile configuration and call some utility methods our self.

In this sample todo list web app we will have this data in local storage:

var todos = [
    { title: "Buy milk", desc: "Remember to buy milk tomorrow." },
    { title: "Call Will", desc: "Will expects a call at 8." },
    { title: "Pay the bill", desc: "Pay the electric bill today." }
];
localStorage.setItem("todos", JSON.stringify(todos));

We will have this HTML5 page to start with:



    Todo list app

Note that we do not have any content at all. The body is completely empty.

jQuery Mobile will do a lot of stuff for us when loaded. This is how the document looks like when done:



    
    
    Todo list app
    
    
    
    
    


    
    
    
        
        loading

Most importantly a page has been created. When jQuery Mobile loads a document without a page, a page will be created. We can also see that this has been made the active page by the ui-page-active CSS class. We need to stop jqm from doing this. We want to create our own page, and make this generated page the active one. The autoInitializePage option has to be set to false on the mobileinit event:

        // jQuery Mobile initialization …
        $(document).bind("mobileinit", function () {
            $.mobile.autoInitializePage = false;
        });

Now the only thing that happens is that the head base elements gets added like in the previous case. Now we need to create our first dynamic page, which is going to be the page with the list of todos, and make it current:

        // Page generation …
        function createPage (title, content) {
            return $([
                '',
                    '',
                        "", title, "",
                    "",
                    '',
                        content,
                    "",
                ""
            ].join("")).appendTo("body");
        }

        var items = JSON.parse(localStorage.getItem("todos")) || [];
        function createList () {
            var list = [ '' ];
            $.each(items, function (i) {
                list.push(
                    "",
                        '', this.title, "",
                    ""
                );
            });
            list.push("");
            return list.join("");
        }

        $(function () {
            createPage("Todos", createList()).attr("id", "list");
            $.mobile.initializePage();
        });

Here we create our first page with an id of list that we append to the body element. The page contains a list view with all the todo items. Each item has a URL with a hash. We will use this hash to figure out what dynamic page to generate. The hash looks like #todos/{itemId}. The last thing we do is to initalize the page. The page looks like this:

When we click a todo we get this error message:

jQuery Mobile is trying to load our page from http://host/todos/0. This is clearly not our intention. We want to generate the details pages for our items dynamically, not fetch them using AJAX. We also want to use a hash, but jQuery Mobile has changed our hash into pointing to a real document on the server side. Lets take some control of page changing by subscribing to the pagebeforechange event:

If $.mobile.activePage is undefined we know that it is the first page we are going to change to. We let jQuery Mobile do its thing in this case. Lets click an item in the todos list:

Here we can see that this is not the first page. We also look for the flag byUs that we will use later to indicate that the page has been changed by us. If none of these are present we stop jQuery Mobile from doing anything. Now our first page works as expected, but nothing happens if we click a todo item in the todo list.

We want full control of page changing and use hash changes to figure out what to do. jQuery Mobile includes Ben Alman’s hashchange special event plugin. First lets do some jqm configuration:

        // jQuery Mobile initialization …
        $(document)
            .bind("mobileinit", function () {
                $.extend($.mobile, {
                    autoInitializePage: false,
                    linkBindingEnabled: false,
                    pushStateEnabled: false,
                    hashListeningEnabled: false
                });
            })
            .bind("pagebeforechange", function (e, data) {
                var firstPage = !$.mobile.activePage,
                    changedByUs = !!data.options.byUs,
                    firstPageOrChangedByUs = firstPage || changedByUs;
                if (!firstPageOrChangedByUs) {
                    e.preventDefault();
                }
            });

Here we make sure to stop jQuery Mobile from:

Auto initialize our page
Add custom behaviour to our list items
Rewrite our hashes into real server documents
Listen to hash changes

Next thing to do is to subscribe to the hashchange event and change to dynamically generated pages:

        // Page generation …
        function createPage (title, content) { … }

        var items = JSON.parse(localStorage.getItem("todos")) || [];
        function createList () { … }

        $(function () {
            createPage("Todos", createList()).attr("id", "list");
            $.mobile.initializePage();
            $(window).bind("hashchange", function () {
                var url = window.location.href,
                    hash = $.mobile.path.parseUrl(url).hash;
                route(hash);
            });
        });

        var pattern = /\/(\d+)/;
        function route (route) {
            var match = pattern.exec(route);
            var showList = match === null;
            if (showList) {
                changePage($("#list"));
            } else {
                var itemId = match[1];
                changePage(getItemPage(itemId));
            }
        }

        function changePage (page) {
            $.mobile.changePage(page, {
                byUs: true,
                transition: "none",
                changeHash: false
            });
            $.mobile.urlHistory.stack = [];
        }

        function getItemPage (id) {
            var existingItemPage = $("#item" + id);
            if (existingItemPage.size() === 1) {
                return existingItemPage;
            }
            var item = items[id];
            return createPage(item.title, item.desc)
                .attr("id", "item" + id);
        }

Here we:

Search for an todo list item id in the hash
If we do not find an item we show the todo list page
If we find an item id we create an item page
Make sure not to recreate the list page and item pages by searching for pages with specific ids
Use jQuery Mobile’s $.mobile.changePage method to change to the found page

When we change the page we make sure to:

Set the byUs flag to true so that we know not to prevent default in the pagebeforechange event
Prevent transitions because the URL history of jQuery Mobile does not match our custom routing
Make sure that jQuery Mobile does not change our hash

Our first item page looks like this:

Note the URL with the hash. There is still an issue to take care of. If we refresh the web app with this URL it will be staying. The problem is that we render the list page as the first page without checking the URL. Lets fix this last problem and then we are done:

        // jQuery Mobile initialization …
        $(document)
            .bind("mobileinit", function () { … })
            .bind("pagebeforechange", function (e, data) {
                var changedByUs = !!data.options.byUs;
                if (!changedByUs) {
                    e.preventDefault();
                }
            });

Here we make sure to never change any page if not changed by us. But this also prevents us from changing into our first page. Fix:

        // Page generation …
        function createPage (title, content) { … }

        var items = JSON.parse(localStorage.getItem("todos")) || [];
        function createList () { … }

        $(function () {
            createPage("Todos", createList()).attr("id", "list");
            $.mobile.initializePage();
            $(window)
                .bind("hashchange", function () {
                    var url = window.location.href,
                        hash = $.mobile.path.parseUrl(url).hash;
                    route(hash);
                })
                .trigger("hashchange");
        });

        var pattern = /\/(\d+)/;
        function route (route) { … }

        function changePage (page) { … }

        function getItemPage (id) { … }

To solve this last problem we just trigger a hash change when our web app gets loaded.

You can try the complete todo list HTML5 web app here:

http://www.kkj.no/apps/todo-list/index.htm.

The source for the demo can be found here:

https://github.com/knutkj/kkj/blob/master/src/apps/todo-list/index.htm.

Tagged: JavaScript, jQuery Mobile

Windows Phone SVG Icon Generator

knutkj — Mon, 07 Nov 2011 11:16:12 +0000

When you submit a Windows Phone app you need to specify the app’s icon in different resolutions:

Application Icon (62 x 62)
Application Tile Image (173 x 173)
Device application icon for Windows Phone Marketplace catalog (99 x 99)
Device application icon for Windows Phone Marketplace catalog (173 x 173)
Desktop application icon for Windows Phone Marketplace catalog (200 x 200)

It’s great to create icons using a vector format so that it is easy to scale it later on. Windows Phone apps usually have simple icons, and that makes vector graphics to be an even better choice.

Scalable Vector Graphics (SVG) is the vector markup language for the web. In HTML5 you can have inline SVG. That means you can create web apps with SVG functionality. I have created a Windows Phone SVG Icon Generator that makes it easy to create the icons required by the Windows Phone Marketplace. Take a look at the video demo below.

The generator is currently supported in:

Latest Firefox
Latest Google Chrome
Internet Explorer 9+
Opera 12+ (Opera 12 is currently in alpha)
Latest Safari

When you hit the “generate icons” button the SVG markup gets saved into HTML5 storage.

In the generator app there is a textarea where you add the SVG markup. When you hit the “generate icons” button this markup gets wrapped into the following SVG template:

Then it gets added to a zero size SVG element. There are five other SVG elements on the page. They look like this:

…



…



…



…



…



…

So I just use the SVG use element to reference the defined icon. I also scale all the icons so that they match the Windows Phone Marketplace requirements. Just remember to use a 100 by 100 coordinate system that has the origin point 0,0.

The animation of the initial Windows Phone lookalike loading screen is created using Synchronized Multimedia Integration Language (SMIL). Here is the markup:



    
    
    


    generate icons...

Hope you like the Windows Phone SVG Icon Generator!

Tagged: HTML, HTML5, SMIL, SVG

The HTML class attribute: for styling purposes only?

knutkj — Tue, 02 Aug 2011 20:17:22 +0000

Introduction
Early specifications
The www-style mailing list
Later specifications
Pulling it all together
Conclusion
Side note

Introduction

Cascading Style Sheets (CSS) has the HyperText Markup Language (HTML) language specific class selector. The CSS rule below applies to an HTML element which has a class attribute with the value name:

*.name { color: gray; }

Without the class selector you would have to use the attribute selector. The rule below is equivalent to the rule in the previous example:

*[style~=name] { color: gray; }

Then a question arises. Was the HTML class attribute added to HTML 4.0 in 1997 just to make it more convenient to write CSS files? To answer this question we have to dig into World Wide Web Consortium (W3C) specifications and mailing lists.

If you don’t want the details you can skip right to my conclusion.

Early specifications

This quote from the W3C Working Draft HTML and Style Sheets: W3C Working Draft 24-Mar-97, which doesn’t tie HTML to any particular style sheet language, states that the two elements div and span was added to HTML 4.0 to make it easier to style an HTML document:

To make it easier to apply a style to parts of a document, two new elements for use in the body of an HTML document are defined: DIV and SPAN. The first is to enclose a division (chapter, section, etc.) of a document, making it possible to give a whole section a distinctive style. The latter is used within paragraphs, similarly to EM, but in cases where none of the other HTML elements (EM, STRONG, VAR, CODE, etc.) apply.

These two quotes from the same document states that the HTML class attribute was added to support effective use of style sheets with HTML documents:

To support effective use of style sheets with HTML documents a number of common attributes are proposed. These can be used with most HTML elements. In general, all attribute names and values in this specification are case insensitive, except where noted otherwise.

A space separated list of class names. CLASS names specify that the element belongs to the corresponding named classes. These may be used by style sheets to provide class dependent renderings. Note that white space characters are permitted within class names, and that one or more contiguous white space characters should be treated as the same as a single space character (decimal 32).

In this quote from Cascading Style Sheets, level 1: W3C Recommendation 17 Dec 1996 we can read that the class attribute was added to HTML to increase the control of elements:

To increase the granularity of control over elements, a new attribute has been added to HTML [2]: ‘CLASS’. All elements inside the ‘BODY’ element can be classed, and the class can be addressed in the style sheet

It is also interesting to read in the same document that:

CSS gives so much power to the CLASS attribute, that in many cases it doesn’t even matter what HTML element the class is set on — you can make any element emulate almost any other. Relying on this power is not recommended, since it removes the level of structure that has a universal meaning (HTML elements). A structure based on CLASS is only useful within a restricted domain, where the meaning of a class has been mutually agreed upon.

These two documents are the result of work from several people. The W3C mailing lists gives us a unique opportunity to find information from discussions that led into adding the class attribute. You will find lot’s of quotes from the www-style mailing list from the year 1995 below:

The www-style mailing list

http://lists.w3.org/Archives/Public/www-style/1995May/0012.html:

… One example of such an (unwanted, IMHO) dependency is the fact that
Hakon's style language currently presupposes the existence of an
attribute CLASS, because that's what the notation `H1.punk' means. To
fix this, I proposed a global declaration `@archform CLASS', to be
inserted at the start of the style sheet, so that applications would
now what the dot stands for. (Btw. a `.' is maybe not a good choice,
since the dot is often used a name character in SGML; that's why I
used `@' instead.) …

http://lists.w3.org/Archives/Public/www-style/1995Jul/0016.html:

… Of these, CLASS is the one that is important, since it allows people
to create new elements at will, without it having any effect on
applications that don't know the new element. For example, I can add
tags for CITY, PERSON, DATE, INSTRUCTION, EVENT, NUMBER, etc., simply
by using , , etc. Some
applications would do special things with this information, others
would simply recognize it as legal HTML but subsequently ignore it. …

http://lists.w3.org/Archives/Public/www-style/1995Jul/0017.html:

… It only makes sense to define extra styles if they are attached to new
pseudo-elements.  Attaching arbitaray styles to a single element is a
regression to Word for Windows style formatting, e.g. 
, .  This is just Netscape
extensions with a more verbose syntax.

I also oppose , however.  Any new element should be based on an old
one.

Think of it this way: what would be the easiest way to turn a Word for Windows
document into a "correct" HTML 3.0 document:


Text text

We must not allow this.  If we force them to use real HTML elements then
we can show users the output and explain to them why it is wrong:
"look it used an emphasis tag when you didn't really want emphasis.  Look
it used an address tag to enclose something that is not an address."

If we create a tag with no semantics it can be used anywehere without
ever being wrong.  We must force authors to properly tag the semantics
of their document.  We must force editor vendors to make that choice
explicit in their interfaces.

http://lists.w3.org/Archives/Public/www-style/1995Jul/0019.html:

… With generic character-level elements, the source for the database could
be written *in HTML* with key fields (i.e. Department) inside generic
elements subclassed appropriately:
 .... Proffessor X teaches the following courses in the
Mathematics department: ...
Unless a specific stylesheet hint for STRING[CLASS=Department] existed,
this would render as normal text, which is probably the desired effect.
The database search engine, however, can now search for all professors
from a given department by looking at the HTML. This allows the source
files for the database to be in a relatively human-readable form, and
allows hand-editing without special software. …

… secondary purpose of the generic text entity is to allow special
rendering hints for certain semantic elements. For example, the
names of individual products in a searchable catalog could be rendered in
a different font …

http://lists.w3.org/Archives/Public/www-style/1995Jul/0025.html:

I'm also getting a handle on how the classes are done in the style sheet.
This is really useful, not only to hint at the presentation, but also for
showing more precisely what a tag means.

address.street: font.color = #FFF;
address.street: back.color = #000;
address.email: font.color = #00C;

7125 Riverwood Dr, Columbia, MD
Mike Batchelor 


This very nicely highlights the difference between the two kinds of
addresses, in the tags, and in the browser.

http://lists.w3.org/Archives/Public/www-style/1995Jul/0087.html:

… I next want to consider just how we intend to use the class
attribute. I've not been on the www-html list for long, but as people
who read my earlier posts on the subject of alternative media
representations for table data (i.e, drawing charts instead of
tables!), I have argued (or at least inferred) in the past that there
are occassions when using the class attribute for some kind of purely
presentational descriptor is almost as bad as having added a
presentational tag to the spec. Better to use

Chris.Tilbury@estate.warwick.ac.uk
(to steal an oft quoted example of the use of the SGML name tokens)

than 

Chris.Tilbury@estate.warwick.ac.uk

if for no other reason than that HTML is such a massively generic
application of SGML that people wishing to more descriptively markup
their content (in this I include myself) will or may want to use the
class tag for content orientated purposes rather than purely
presentational ones. …

http://lists.w3.org/Archives/Public/www-style/1995Jul/0095.html:

                                      … if you believe that CLASS is
useless on non-stylesheet browsers, then you have misunderstood what CLASS
is for.  Style sheets are merely one application of the CLASS attribute.
They are useful for precisely the application you have in mind, which is
to further specify the kind of data enclosed within a tag.  That
stylesheets can take advantage of this is a happy consequence of a good
idea. …

http://lists.w3.org/Archives/Public/www-style/1995Jul/0099.html:

… >I realize that CLASS is not just for stylesheets, but are we going to
>build a library of CLASS names with suggested meanings (and some suggested
>renderings)? If so, then I would use CLASS, but this hasn't been done so
>far as I know...

I think that it would be premature to standardize CLASSes until we see what
people want to do with them. …

… The CLASS and ID attributes should also be added to HTML as soon as possible
(HTML 2.1?).  A useful style sheet language can be developed which does not
depend on them, but can use them when they are present. …

…        encourage the usage of CLASS, which would contribute to its usage in
robots and other software.
        allow us to judge how people use CLASS so that we can think about
standardizing some usages.
        increase the awareness of platform portability issues.
        put the IETF and W3C back in the driver's seat with respect to the
direction of HTML and the Web. …

http://lists.w3.org/Archives/Public/www-style/1995Jul/0103.html:

… I believe that CLASSes should *never* be standardized
in the sense that you describe, i.e., such that a browser
would give elements special treatment based on CLASS
attribute values without an explicit instruction from
the author.

Authors must be free to use whatever CLASS names they
come up with without fear that Somebody Else's Browser
might do something unexpected with their document.

Domain- or organization- specific "conventional standards"
would be quite useful, but these should not be hardwired into
browsers.

> The CLASS and ID attributes should also be added to HTML as soon as possible
> (HTML 2.1?).  A useful style sheet language can be developed which does not
> depend on them, but can use them when they are present.  

Yes, definitely.  Also DIV. …

http://lists.w3.org/Archives/Public/www-style/1995Dec/0048.html:

… CLASS is a way of semantically subclassing elements.  Applying a style is
just one reason you would want to subclass an element.  Creating CLASSes
with types of "big" or "blue" or "five_point" are just as bad as creating
elements named "" or "".  If you absolutely must put style
information directly in your HTML document, and that style information does
not correspond to a semantic subclass, then you should use some other
attribute, such as STYLE. …

http://lists.w3.org/Archives/Public/www-style/1995Dec/0053.html:

… >> Why use STYLE as the name of the attribute instead of CLASS? Because it
>> matches the