Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Book Review: Mobile HTML5

samzenpus posted about 10 months ago | from the read-all-about-it dept.

Book Reviews 37

Michael Ross (599789) writes "Web designers and developers nowadays are familiar with the critical decision they face each time before building an application intended for mobile devices: whether to target a particular device operating system (e.g., iOS) and create the app using the language dictated by the OS (e.g., Objective-C), or try to build an operating system-agnostic app that runs on any device equipped with a modern web browser (primarily using HTML5, CSS3, and JavaScript), or try to do a combination of both (using a library such as PhoneGap). The second option offers many advantages, and is the approach explored in the book Mobile HTML5, authored by Estelle Weyl, an experienced front-end developer." Keep reading for the rest of Michael's review.This title was published on 14 November 2013 under the ISBN 978-1449311414, by O'Reilly Media (who graciously provided me with a review copy). The book's material, spanning 480 pages, is grouped into 14 chapters and an appendix, as well as an introduction in which the author presents the advantages of web apps versus native apps, a brief history of both categories (focusing on iPhone development), and an even briefer overview of the HTML5 APIs that are covered in depth in the chapters that follow. Prospective readers may want to first check the publisher's website, where they will find the table of contents, book details, author biography, and a list of errata (only eight as of this writing). In addition, the example code used in the book is available on the author's site. Oddly, the introduction does not specify the requisite knowledge that readers should possess to get the most out of the book. However, a solid understanding of HTML, CSS, and JavaScript would be most helpful; but prior exposure to HTML5 and CSS3 is unneeded, as is any knowledge of any JavaScript libraries, because the author intentionally eschews them in her presentation.

The first chapter, titled "Setting the Stage to Learn Mobile HTML5, CSS3, and JavaScript APIs," continues the discussion begun in the Introduction — largely focusing on the development and testing tools used throughout the book and needed by the reader if he desires to replicate the work described in the narrative. The author's sharp words against IE 6 will be especially appreciated by those designers and developers who have lost countless hours — from both their work schedules and possibly their lifespans — as a result of the rage-inducing layout quirks and other flaws of that demonic browser. Some readers may be confused by the author's instructions for accessing the developer tools in Google Chrome (View > Developer > Developer Tools); with the traditional menu bar now gone, the steps would be the menu icon > Tools > Developer tools.

The next two chapters provide fast-paced coverage of the HTML5 syntax and the new elements and attributes introduced in this latest version of the standard. There are only a few minor blemishes: The author sometimes backtracks, repeating information noted earlier, but worded somewhat differently. For instance, in the second chapter, readers are presented with the syntax of an HTML element (page 25), which is repeated ten pages later. More noticeably, the reader is told six times that the "title" element is required. In the next chapter, the discussion of the "details" and "summary" elements is quite repetitive. Incidentally, on page 76, the author mentions that the "iframe" element has a new attribute, "srcdoc," whose values should not include double quotes, which should be escaped with the """ entity; more accurately, they should be replaced entirely with that entity. Lastly, the explanation of the "sandbox" attribute values is inadequate; readers will need to consult other sources to understand the full meaning of those allowed values. Nevertheless, HTML authors of all levels of experience should be able to benefit from these two chapters.

Forms are an essential component of any dynamic website, and are covered in great detail in the fourth chapter, which explicates the many new features introduced in HTML5, such as validation and error messaging, which significantly reduce the prior reliance upon JavaScript for such functionality. The author does a fine job of explaining these promising new improvements to form elements. The only weakness is, again, redundant explanations — for instance, in the first three sections: "Attributes of <input>," "<input> Types and Attributes," and "New Values for <input> Type." A glaring example is found on page 96, where the second reader tip is echoed in the paragraph that follows it. Screenshots are provided showing the specialized keyboards displayed on the leading handheld devices for the email, URL, phone, number, search, and datetime input types. The chapter concludes with a discussion of form field validation (including use of the validity state object) and the remaining form-related elements, both new and old.

The next two chapters focus on the APIs introduced with HTML5 that were relatively well-defined at the time the book was written, beginning with those that implement SVG, canvas, audio, and video functionality within a webpage, and concluding with application cache, local storage, SQL database storage, geolocation, Web workers, microdata, and ARIA. Most of the narrative should be clear to the reader, although one problem is that sometimes the example code does not reflect the recommendations in the text. For instance, on page 136, the author notes that SVG image accessibility can be enhanced by using the "aria-label" attribute, and that the height and width need not be specified in the "embed" and "object" elements — and yet the code presented does not adhere to these guidelines. Also, on page 175, the author refers to forking code, but the code in question is not forked to a different project or revision; rather, she means different code is executed depending upon the chosen HTML5 database.

Chapters 7 through 10 focus on CSS3, including its unique selectors, color values, units of measurement, box model properties, gradients, shadows, transitions, and animations. It all begins with a review of CSS basics, including media queries and best practices — which makes this book even more viable as a single source for learning HTML and CSS coding. Media queries are touched upon only briefly, because they are covered in depth in a later chapter. Readers will likely find interesting the discussion of maximizing website performance by balancing the number of HTTP requests, the use of embedded styles, and the use of local storage of previously-downloaded CSS and JavaScript files. Oddly, there is inconsistency in the formatting of the example CSS code — for instance, three different formats on a single page (205). Nonetheless, the explanations are for the most part quite clear, aside from the "p:first-of-type" (on page 215). The many snippets of example markup and CSS clearly illustrate how cascading works, and how one can avoid overuse of IDs (and any use of !"important"). The coverage of pseudo-classes and pseudo-elements is quite thorough, with plenty of examples.

The last four chapters employ many of the topics covered earlier and apply them to responsive web design (RWD). Chapter 11 demonstrates how to use CSS 2 and CSS3 capabilities for building websites and web apps that can work and appear as best as possible on device viewports of any size — including those that have yet to be implemented. The information is valuable, marred only by a lack of CSS code showing how the examples were created (e.g., on page 343), prior to discussing the allowed property names and values, and their shorthand notation. Readers learn how to utilize multiple columns, border images, flexbox, @supports, and responsive images. That last topic is arguably the most unresolved aspect of RWD images, and perhaps that is the reason why the author does not discuss the emerging "srcset" attribute and "picture" element for handling the challenge of serving images whose file sizes are optimal for the device's viewport and connection speed. The last three chapters discuss various design and performance considerations one should bear in mind when developing for mobile devices. Most of the initial narrative is at a high level, while the later chapters get into the details of screen sizes, hardware, testing, battery life, and latency. Incidentally, the "meta" element on page 386 was probably not intended to be struck out. The book concludes with an appendix devoted to CSS selectors and specificity.

As with most technical books of this length, this one contains numerous errata: "on ithe Phone" (page xiii), "Chapters Chapter" (xxii), "a[n] OOCSS" (xxv), "that [the] Sources" (12), "never[-]used" (42), "developers that" (44; should read "developers who"), "spammers last millennium" (47; we wish!), "When [the] favicon" (51), "favico.ico" (ditto), "at [the] site" (ditto), "so [it] has" (66), "on [the] same" (77), "<detail>" (80; should read "<details>"), "Barn[e]s" (80), "])){" (95; should read "]){"), "seperate" (101), "override [the] default appearance" (102), "rangUnderflow" (121), "form control[']s value" (121), "requiredlist" (124, 125), "an list" (124), "pros of cons" (146), "first from" (149; should read "first frame"), "when [the] game" (168), "function [is] initially" (169), and "via [a] banner" (179). At this point, roughly halfway through the book, I stopped recording errata.

Most of the writing is clear and straightforward. However, some of the phrasing is a bit confusing, e.g., "is in the last call" (page 101). Other phrasing may come across as too flippant, e.g., "Duh!" (page 48). Some terms are used much earlier than when explained, e.g., "shadow DOM" (page 100). A few terms are used that can have various meanings depending upon the context, but in this book their intended meanings are not defined and likely would not be obvious to the average reader. For example, in Chapter 3, several times the author refers to the "outline" of a (presumably HTML) document and a "node" that one might create, but does not explain what is meant by those terms in these cases.

Most books that use some sort of example project to illustrate the ideas being presented, will weave it into the narrative when appropriate and/or as much as possible. The example project for this book, CubeeDoo, is mentioned countless times, but apparently not explained in its entirety, nor is discussed the stitching together of the code snippets into a complete application. As a consequence, the example project adds less instructional value to the book than could be expected given the amount of space devoted to it. Arguably, it would have been better to either make full use of the project as a teaching resource, or use a simpler application if the first option would have been overwhelming, or simply exclude it altogether from the text and, optionally, post it online for readers who wish to examine the code on their own.

In terms of the layout and presentation of the text, this book, like so many other O'Reilly Media titles, oftentimes has too little space between adjacent words, making it more difficult to read the text at a rapid pace and to quickly locate individual words known to be present on any given page (such as words found in the index). In some cases, attribute names are chopped off midway and continued on the next line, but without the standard hyphen to indicate word continuation (e.g., "ac / cesskey" on page 30). The same is occasionally done for JavaScript method names (e.g., "se / tAttribute" on page 39). Admittedly, for keywords such as element names and attributes, as well as JavaScript names, adding any hyphen might be even more misleading, as some readers might erroneously conclude that the hyphen is part of the name when not broken over two lines.

The book's primary problem is the repetition of information, not just within each chapter, but oftentimes even on the same page. This is true not only within the main text, but also in the reader tips, which sometimes present new and useful information, but far too often repeat the information found in the paragraph preceding the tip — sometimes an almost-verbatim repeat of the paragraph's last sentence. This is not of great consequence, and may be helpful to readers who miss an important point the first time it is presented. Some of it may be unavoidable, given the overlap among the various topics. But it certainly does add to the (nontrivial) length of the book.

Regardless, these are not overly important flaws. Suffused with the author's honest writing style — as well as her obvious experience and enthusiasm — Mobile HTML5 is a substantial and instructive treatment of the primary new techniques for building mobile-ready websites and web apps.

Michael Ross is a freelance web developer and writer.

You can purchase Mobile HTML5 from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page.

Sorry! There are no comments related to the filter you selected.

TL;DR (-1)

Anonymous Coward | about 10 months ago | (#46686351)

First Post from my iPhone bitches

Woah, Flashback (1, Insightful)

holophrastic (221104) | about 10 months ago | (#46686365)

Is anyone else caught in a flashback? Welcome back to the '90s. Same conversation, same observations, same decisions, same results.


Re:Woah, Flashback (0)

Anonymous Coward | about 10 months ago | (#46688005)

Yep, that's right. Everyone, even in Alaska and Greenland, is going to have high-speed internet at all times, so your app can live on a server. Servers will never go down, either. It's Netscape all over again!

Re:Woah, Flashback (1)

holophrastic (221104) | about 10 months ago | (#46688695)

Who said anything about netscape? Read harder please. Mobile app vs site is congruent to desktop application vs site.

And, quite frankly, the resolutions are exactly the same as they were too.

Put your name to your arguments, are I'm done with you.

Re:Woah, Flashback (1)

Tablizer (95088) | about 10 months ago | (#46688245)

So we'll see the equivalent of Mobile GeoCities with flashing & spinning labels and gizmos as people Use Every Gimmick Available until they become so cliche and obnoxious that even the clue-less get it?

Re:Woah, Flashback (1)

holophrastic (221104) | about 10 months ago | (#46688719)

I love it. Geocities returns! MobileCities? I wonder if my very first web-page ever would come back. A thousand dollars says it'll work perfectly on mobile today, with not a single byte of HTML changed. v0.9 to v5.0 in only 2 decades!

Re:Woah, Flashback (0)

Anonymous Coward | about 10 months ago | (#46690565)

The most important part of developing a mobile "app" is not developing it at all.

Every few days someone emails/spams one of my clients with offers to do mobile apps for their sites, but none of my clients need, or even want a mobile app, they want people to visit the site. The problem this entails is that malicious ads keep entering the system targeting the mobile users to either get them to install candy-crapper-game-number-42 or drive by download to Android devices.

Android devices are absolutely horrible devices, all the support issues we have are because of users running old Android versions and we can't tell them to upgrade because there isn't just "one" Android to upgrade to. It's a nightmare and so Android users need to suffer for being so cheap.

Timely... (2)

ackthpt (218170) | about 10 months ago | (#46686437)

We're moving development into HTML5 and CSS3, with more users interested in apps which they can use on tabs or mobiles.

Big trick is figuring how to make apps work on a smaller screen and not totally suck (like fb does.)

Re:Timely... (2, Informative)

Anonymous Coward | about 10 months ago | (#46686727)

Yes, we spent much time designing platform specific apps.. Wasted time..

PhoneGap and Mosync (couple examples) have come a long way in supporting the native features and giving access to them via javascript.

It's nice to be able to design one app and compile it against many target platforms.

Re:Timely... (1)

schneidafunk (795759) | about 10 months ago | (#46687365)

The last app I built was in PhoneGap and it was so much nicer than objective-C. Plus we had a website ready to go at the same time to match the app, minus a couple of phone specific features.

Re:Timely... (0)

Anonymous Coward | about 10 months ago | (#46687513)

"It's nice to be able to design one app and compile it against many target platforms."

Having software work on competing hardware is contrary to the goals of Apple, Samsung et al. Expect to see less software working as we go forward - it's a more efficient way of selling hardware.

Re:Timely... (0)

renimar (173721) | about 10 months ago | (#46691579)

It's nice to be able to design one app and compile it against many target platforms.

Didn't Java once promise 'write once, compile many', too? Look how that ended up.

Back to the 90s indeed.

Re:Timely... (0)

Anonymous Coward | about 10 months ago | (#46690769)

I have never seen an HTML 5 app that doesn't suck terribly. Performance is bad, features are bad, the UI is not smooth or responsive.

Facebook dumped HTML5 for a reason.

Re:Timely... (1)

AmiMoJo (196126) | about 10 months ago | (#46692689)

Does it say how to fix Slashdot Mobile?

Affiliate link (1)

Anonymous Coward | about 10 months ago | (#46686479)

That amazon link contains the affiliate code for Slashdot, which gives them a cut of any books purchased from clicking on that link. That's not necessarily a problem, but a little more transparency would be nice.

Re:Affiliate link (1)

Mandrel (765308) | about 10 months ago | (#46690051)

Yes, all Slashdot book reviews have Amazon affiliate links. I agree that Slashdot would benefit from labelling them as such, because transparency inspires goodwill.

My only other problem with such links is that they endorse and prefer one specific (behemoth) vendor. Links to other vendors should be added, even if there's a bias to ones who pay affiliates. Sort of like smartURL [smarturl.it] , that chooses a list of music affiliates based on IP, but for books.

Device-specific functionality (1)

Joey Vegetables (686525) | about 10 months ago | (#46686547)

Many mobile apps use functionality not easily available in HTML5. Is there some reason one could not write a native app to serve as a front end to this functionality, and then communicate with it within HTML5 via WebSocket or some similar mechanism?

Re:Device-specific functionality (1)

Anonymous Coward | about 10 months ago | (#46686691)

Yes; the process model and browser security model.

But PhoneGap and Cordoba provide a browser shell with a richer array of objects (for prepackaged HTML5 apps).

Re:Device-specific functionality (1)

Anonymous Coward | about 10 months ago | (#46686693)

'Many mobile apps use functionality not easily available in HTML5.'

PhoneGap and MoSync already wrap these features in nice methods and make them available via javascript.

Re:Device-specific functionality (0)

Anonymous Coward | about 10 months ago | (#46686871)

PhoneGap and MoSync already wrap these features in methods lazy developers and make them suck for end users via javascript.

Re:Device-specific functionality (0)

Anonymous Coward | about 10 months ago | (#46688805)

Write once, suck everywhere.

fuck38 (-1)

Anonymous Coward | about 10 months ago | (#46686673)

butts are exposed open platform, truTh, for all

uh... wat?! (1)

vdoogs (765125) | about 10 months ago | (#46686805)

"...as is any knowledge of any JavaScript libraries, because the author intentionally eschews them in her presentation" Who goes on a rant about how terrible IE6 is and also intentionally eschews all the commonly used solutions? What a disservice to readers. Honestly, I don't know a single programming who codes user-facing javascript without a library (like say jQuery) at this point helping you out with all the quirks and browser differences. It's pretty much a silly thing to do, and a massive waste of time for anything but the simplest scripts.

Re:uh... wat?! (1)

narcc (412956) | about 10 months ago | (#46687589)

Welcome to 2014. jQuery and similar libraries are not only unnecessary, they actually make writing cross-browser code harder. jQuery, in particular, has never been cross-platform and even now only claims to support an even smaller subset of browsers.

It's not 2006. You need to update your talking points. (I date not ask you to actually learn anything new. Getting you to attach to a new meme is a lofty enough.)

Re:uh... wat?! (0)

Anonymous Coward | about 10 months ago | (#46690765)

I don't use any javascript libraries thank you very much. jQuery isn't evil, but it adds an absurd amount of browser overhead that I don't ever want to see it used on a mobile device.

Read Reviews (1)

wjcofkc (964165) | about 10 months ago | (#46686819)

I trust Amazon comments on matters like these:

http://www.amazon.com/Mobile-H... [amazon.com]

Re:Read Reviews (1)

MikeTheGreat (34142) | about 10 months ago | (#46688175)

LOL. There's 4 reviews there (4/7/2014, 2pm PST).

While I agree that Amazon is actually a really good source of reviews I'm not 100% sure that the four (just 4!) reviews really offers a convincing sample size :)

Related to Hermann Weyl? (0)

Anonymous Coward | about 10 months ago | (#46687013)

News for nerds and no mention if the author is related to Hermann Weyl? :)

Oh, beautiful irony (2)

wonkey_monkey (2592601) | about 10 months ago | (#46687529)

As with most technical books of this length, this one contains numerous errata

The word you're looking for is "errors." Errata are corrections to errors.

Re:Oh, beautiful irony (1)

Hognoxious (631665) | about 10 months ago | (#46687763)

At least he didn't say there was an exponential amount of them.

Re:Oh, beautiful irony (1)

Desler (1608317) | about 10 months ago | (#46688857)

Yep Michael Ross always gives 8s an 9s to books he says are poorly-written and/or full of errors.

Re:Oh, beautiful irony (1)

smarkham01 (896668) | about 10 months ago | (#46690523)

'Errata' was the correct choice. After all, if the correction appears in the same edition as the error, there is no error! BTW, I gave up on O'riley in the 90s, mostly rubbish that wouldn't make it by a decent editor.

Re:Oh, beautiful irony (1)

wonkey_monkey (2592601) | about 10 months ago | (#46691599)

'Errata' was the correct choice. After all, if the correction appears in the same edition as the error, there is no error!

The first usage is correct, but not the bit I quoted. The review itself states there are eight errata on the website, then later lists a lot more "errata" that the reviewer found.

Re:Oh, beautiful irony (1)

smarkham01 (896668) | about 10 months ago | (#46693545)

Now smile, go back and think of it comical terms! Ya know - errata as an admission of error. BTW, my feeble attempt at irony (notice the misspelling of O'Reilly) seems to have failed, too.

why not actionscript? (1)

tatman (1076111) | about 10 months ago | (#46687549)

Completely overlooked in this book was Adobe's product: actionscript. It is a java-like language with java-like capabilities: real classes, interfaces, events, web services, XML, json.....you name it..... Compiled, actionscript becomes native applications for both Android, Windows, all browsers (and iOS, but I guess iOS support is still beta) with single code base. I cannot say where I have this functioning as described, however, if you live in the USA you have probably already experienced such implementations as described above.

Re:why not actionscript? (1)

narcc (412956) | about 10 months ago | (#46687669)

real classes

"Uses the more complicated and less powerful approach!" is not a good selling point.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?