You are currently browsing the HTML5 archives.

Quick Tip: HTML to JSX Conversion

Tuesday, July 19th, 2016

Like many developers, at times I find the need to convert raw HTML to JSX. It was only after I found myself needing to do this a bit more frequently that I considered writing a quick tool to automate the task. However, like most things, I knew there must be something out there which handles this already, and as I suspected, there certainly is: HTMLtoJSX Рa component of React-Magic which does precisely this.

So, if ever you need to quickly convert raw HTML to JSX, be sure to check out the online converter and, for more frequent needs, the converter is also available via NPM and can easily be integrated into part of an existing build pipeline.

Property Change Observers in Polymer

Wednesday, January 6th, 2016

When building Web Components the ability to observe property / attribute changes on custom elements and respond to them accordingly can prove quite useful.

Fortunately, Polymer makes this incredibly easy. Let’s take a quick look …
(note, we’ll be using ES6 here)

Single Property Observers

In it’s most basic form, a Single Property Observer can be defined by simply implementing a method and adding it to the property’s observer configuration:

Now, whenever the property changes, Polymer will automatically invoke the observer method; handily passing two arguments: the updated value, and the previous value:

Try it

Pretty cool, right? It gets even better…

Multi-Property Observers

In addition to Single Property Observers, multiple properties can be observed for changes using the observers array:

The observers array is rather self-explanatory: each item is simply a string representation of the method to be invoked with the observed properties specified as arguments:

Try it.

For more information, see multi-property-observers.

Sub-Property Observers

Similar to Multi-Property Observers, sub-properties can be observed as well (e.g. user.username, or user.account.name, etc.). For instance:

Try it

Deep Sub-Property Observers

As with explicit Sub-Property Observers, (n-level) arbitrary sub-properties can be observed using wildcard notation:

Try it.

Both Sub-Property Observers and Deep Sub-Property Observers differ from Single-Property Observers in that a changeRecord is passed to the observer method as opposed to the updated value. A changeRecord is simply an object which contains the following properties (as per the Polymer Docs):

  • changeRecord.path: Path to the property that changed.
  • changeRecord.value: New value of the path that changed.
  • changeRecord.base: The object matching the non-wildcard portion of the path.

It’s important to keep in mind that Sub-Property, and Deep Sub-Property observations can only be made using either property bindings or the set method.

Array Mutation Observers

Complimentary to Single, Multi, Sub, and Deep Property Observers, Polymer provides Array Mutation Observers which allow for observing Array and Array element properties for changes.

This is where the API requires a little getting used to IMHO, and so I would recommend reading the Docs in detail.

That being said, Array Mutation Observers are quite powerful, for example:

Try it.

When observing Arrays, in order for bindings to reflect properly, Polymer’s Array Mutation Methods must be used. This is quite simple in that the API is the same as that of the corresponding Native Array methods, with the only difference being the first argument is the path to the array which is to be modified. For example, rather than: this.items.splice(...) one would simply use: this.splice('items', ...).

Conclusion

Hopefully this simple introduction to Polymer Observers has demonstrated some of the powerful capabilities they provide. Understanding how each can be implemented will certainly simplify the implementation of your custom elements, therefore leveraging them where needed is almost always a good design decision.

Feel free to explore any of the accompanying examples.

Chuck Norris on Polymer

Wednesday, December 16th, 2015

For the past several months I have been evaluating potential frameworks which could facilitate the implementation of context aware Web Components such that each component can be assembled declaratively into recombinant features and higher-level applications. After a focused period of prototyping each candidate framework, Polymer 1.x has proven to be the most effective approach to satisfy these particular design goals, and many others as well.

While I have also been leveraging Angular 2 for implementing self-contained Web Applications which need not be composed outside the scope of the application’s root component / template, the requirement to provide elements which can be arbitrarily composed within an html document declaratively or imperatively independent of using any one particular framework is one which proves somewhat challenging; yet, can easily be satisfied by leveraging Web Components, and Polymer simplifies the process of doing so considerably.

Polymer 1.x

On a high-level, Polymer provides some much welcomed sugaring over the four Web Component specifications; HTML Templates, Shadow DOM, HTML Imports, and Custom Elements, respectively. The higher level abstraction and API offered by Polymer significantly simplifies the process of Web Component development, while reducing the time and effort required to meet both simple and complex use-cases alike.

Features provided out-of-the-box embrace that which developers have come to expect from a modern library or framework, such as one-way and two-way binding annotations, template helpers, a Local and Light DOM API, declarative and imperative event mappings, declared properties with observers and attribute reflection, and much more.

Add to this the growing Catalog of Elements provided by the Polymer Project, a complete Web Component Testing solution via WCT, optimization features such as Vulcanization with tooling support for Gulp, API Documentation components via Iron Component Page (though still pending ES6 Support) concise documentation with easy to use examples, and developers are afforded a rather elegant solution for building high quality, future facing Web Components, today.

In addition, Polymer comes in three specific layers, each of which builds upon the previous lower-level implementation. This allows for a nice level of flexibility in choosing the most appropriate implementation based on your specific needs. Depending on what is required, one can choose from the mirco-implementation for providing basic custom element sugaring, the mini-implementation for more advanced local DOM and life-cycle hooks, and the standard-implementation which provides the full suite of Polymer features.

Given the capabilities Polymer has to offer, as well as the growing number of organizations using Polymer, and some rather interesting applications being built with Polymer, if you haven’t already, I highly recommend given it a try.

Chuck Norris!

So what does any of this have to do Chuck Norris?

Well, nothing actually.

Except, like Chuck Norris, Polymer is cool – very cool, and so after accidentally coming across the ICNCB service, I thought a simple Web Component which displays some comical facts about Chuck Norris could serve as a useful Polymer example.

And so, if you like to laugh a bit while learning something new, feel free to clone the repo over on Github to get familiar with a few of Polymer’s general capabilities, or simply check out the app here and have a few laughs.

Coming up, Chuck Norris on Angular 2 …

Clearing Web Notifications Permissions in Chrome

Tuesday, December 3rd, 2013

When implementing features which leverage HTML5 Web Notifications, specifically in Chrome, it can be rather convenient to have the ability to clear notification permissions from the host for which the feature is being implemented.

As would be expected, Chrome allows for easily managing any setting; however, one needs to navigate through quite a few of Chrome’s settings in order to locate Web Notification permissions, the path to which being:
Settings > Show advanced settings… > Content Settings > Notifications > Manage Settings…

Navigation of settings can be simplified by using Chrome’s Search box, which allows for quickly navigating to any specific setting:

While Chrome’s settings Search feature is quite useful, it still requires more interactions then desired. Fortunately, there is an even simpler approach for quickly accessing a specific setting, in this case, Notifications.

Simplifying Clearing Web Notification Permissions

Web Notification Settings can be directly accessed for all hosts via the following path:
chrome://settings/contentExceptions#notifications

As with any URL protocol, the above path can be bookmarked, allowing for easy and convenient management of Notifications.

Bookmarking Chrome Settings

While the focus here may be on the topic of managing Web Notification settings, it is important to note that any Chrome setting can be bookmarked as a convenience shortcut for quickly navigating to any given setting. For instance, Chrome’s cache setting can be bookmark at:
chrome://settings/clearBrowserData

Then, commonly used settings can be accessed simply from their respective bookmarks:

HTML5 Input Elements on iOS

Saturday, September 7th, 2013

Perhaps some of the most important UX considerations to make are those surrounding the simplicity with which forms can be completed. This is especially important when taking into account the constraints of Mobile devices.

Input Elements and the iOS Keyboard

While implementing a form for a Mobile Web Application, I found myself in need of a way to control some of the default behaviors of the native iOS Keyboard. Specifically, I found it rather inconvenient on the user’s part to require manual closing of the keyboard of any kind, especially after submitting a form. I also found it inconvenient to have to manually turn off auto capitalization on input elements, or having to work around the default auto-correct behavior on input elements.

Fortunately, these issues (as well as others) have solutions which are readily available, both natively and programmatically.

Turning off auto-caps

By default, the iOS Keyboard displays with Caps Lock on for the first charachter on input elements of type text. For certain use-cases, such as entering usernames, this may not be desirable.

Caps Lock can be turned off by simply defining an autocapitalize attribute with a value of off on input elements:

Turning off auto-correct

As with with Caps Lock, in iOS, by default, input elements of type text have auto-correct enabled. For certain use-cases, again, such as entering usernames, this may not be desirable.

Auto-correct can be disabled by simply defining an autocorrect attribute with a value of off on input elements:

Automatically closing the Keyboard

When submitting a form, at times, the iOS Keyboard may not automatically close. This is quite a usability issue as Users should not be required to manually close the Keyboard for use-cases in which they would otherwise not expect the need do so.

A simple solution for this can be implemented by invoking the blur method on document.activeElement, which effectively allows one to programmatically hide the keyboard:

HTML5 Input Attribute Types

In addition to controlling the default behavior of the iOS Keyboard, specific types of Keyboards can be invoked simply by defining a supported HTML5 input element type.

The following examples demonstrate just how easy it is to display a context specific keyboard:

The Email keyboard can be invoked via the email input type:

The URL keyboard can be invoked via the url input type:

The Telephone keyboard can be invoked via the tel input type:

The Numeric keyboard can also be invoked via the pattern attribute, the value of which being either of the following Regular Expressions [0-9]* or \d*:

You can try the above examples here, or view the gist.

Invoking Native Mobile Applications with URI Schemes

Wednesday, July 10th, 2013

In a previous article, I outlined how the native iOS Keyboard and it’s behaviors can be managed with HTML5 input types. In addition to this, iOS, Android and most A-Grade Mobile platforms implement standard URI Schemes (or parts thereof), which allow for easily launching native applications.

URI Schemes

When considering URI Schemes, more commonly (though incorrectly) referred to as protocols, one typically thinks in terms of the more ubiquitous schemes: http, ftp, file, mailto, about, data:uri and so forth. However, as with these and other common URI Schemes, there are additional schemes which allow for various practical applications in the context of Mobile Web Apps; the most common of which being the ability to invoke a platform’s native phone or messaging application, respectively.

URI Schemes and Mobile Devices

In the context of Mobile Web Applications, the tel, and sms URI Schemes are perhaps the most common and applicable; providing a simple means of invoking their corresponding native applications. The following are basic examples which work across all major mobile platforms.

The tel URI Scheme

The tel URI Scheme allows for launching a device’s native Phone application in the context of the phone number specified:

The sms URI Scheme

The sms URI Scheme allows for launching a device’s native Messaging application to send an sms message, or to send an sms message to the phone number specified:

As can be seen in the above examples, hyphens are used in the same manner as one would typically specify a phone number; however, use of visual separators are purely optional – they can be used to aid in readability if desired, but are otherwise ignored when parsing the URI.

As a general best practice, one should take care to ensure both tel and sms URI Schemes are defined in lowercase, so as to ensure portability across platforms. Additionally, it is important to note that the sms scheme is not implemented to completion against it’s formal definition on any platform (see section 2.2 of rfc5724); thus, an sms message body, or sending an sms message to multiple recipients is not supported.

While there is nothing particularly ground breaking about these URI Schemes, or technically complex for that matter, they do prove to be quite useful in the context of Mobile Web Applications. As such, they are certainly worth noting as each can be leveraged to improve the usability of an application.