Feature:

How to make an HTML5 developer smile: A Google Web Designer wish list

On June 4th, 2013, Neal Mohan, Google’s Vice President of Display Advertising, made a single
mention in the official DoubleClick
Advertiser blog about a new software development tool that is about to emerge "in the coming
months" called "Google Web Designer (GWD)." The blog entry was pretty nascent on details, other
than to state that GWD is intended "to help advertisers and publishers more seamlessly unlock the
potential of cross-device programs." Since the development community can only speculate about the
functions and features this new tool will provide, speculate is exactly what the industry will do.
The following is a wish list of the top five features that would seriously go a long way towards
simplifying cross device, HTML5
web development and should be included in any, modern day web development and design tool.

1. Vendor prefix aggregation and consolidation

If GWD wants to provide a new tool for developing cross-device, HTML5 applications,
they first need to create a tool that can seamlessly deal with all of the incompatible prefixes
that various browsers use to implement modern features. While the big players in the browser market
can boast about support for various HTML5 and CSS3 constructs, their dirty little secret is that
the implementation is done in a non-standard way. Take a look at the following monstrosity of code
that is required to perform a simple, three dimensional transformation on a solitary DIV
element.

Exactly what Google Web Designer will be when it is released
remains a mystery.

Cameron McKenzie, Editor-in-Chief of TheServerSide

The various vendor prefixes that are required are verbose and unmanageable. Furthermore, their
mere multitude introduces a greater potential for coding errors to occur, making maintenance and
troubleshooting much more difficult than it needs to be. Sure, there are excellent third party
tools on the market such as CSSPlease and Prefixr that can be used to help generate vendor prefixes, but they
are just that: third party. If Google wants to simplify web design and development, advanced CSS3
prefix support, maintenance and migration capabilities must be fist order functions of the
tooling.

2. Pre-compilation tools for stylesheets

Another glaring issue with the stylesheet snippet above is the repetitive nature of the literal
values of -25 and -50. Finding out that the transition on both the Z and Y axis should be -30,
instead of -25 and -50 respectively, means ten changes to the code. This theoretically could be
achieved simply by performing a Find and Replace for this example, but as stylesheets become
more complicated, and common settings span across multiple text files, the Find and Replace
method runs out of steam pretty quickly. Again, there are third party alternatives available that
perform these functions, with Syntactically Awesome Stylesheets
(saas) and lesscss being two of the most popular, but whether
it's the fact that saas requires a Ruby based installer, or the added complexity of using a third
party tool like Less, web developers find the need for installing tool after tool after tool to be
tedious and cumbersome. A CSS3 preprocessor and pre-compiler is an absolute necessity for any
modern web development tool.

3. Transparent feature checking

Worse than the proliferation of vendor prefixes is the fact that there are still a variety of CSS3
and HTML5 features still are not globally supported, regardless of the availability of vendor
prefixes. Something as basic as decorating content with a simple, image based border is completely
hit and miss with the latest browsers. It's an effect that works great with Firefox, but current
versions of Safari and Chrome lack an implementation altogether. Predicting browser support becomes
even more difficult when prior versions, increments and browser updates are factored into the mix.
It would seem that the JavaScript library modernizr is
currently the go-to standard for performing HTML5 feature checking in modern browsers, but not
everybody is interested in adding another open-source JavaScript library into their mix. Whether
Google Web Designer leverages this library internally, or they take a more proprietary approach,
the requirement persists.

Google is a company that is interested in advertising dollars,
and every project they promote pads that bottom line.

Cameron McKenzie, Editor-in-Chief of TheServerSide

Of course, identifying the various features that a browser will support is only half of the
HTML5 development battle, which takes us to our next requirement, which involves the art of how to
deal with browsers that don't implement the HTML5 features that are required.

4. Graceful feature degradation

Being able to identify the various features that an older browser might not support is a good
start, but it is just that: a start. Effective web developers know that discovering a given HTML5
or CSS3 feature is not where their job ends, but it is actually where the tough part of their job
begins. For example, a browser might not support HTML5 drag and drop functionality. If that's the
case, there should be a fallback plan where a YUI or jQuery library is loaded and used to implement the same, but perhaps
limited, functionality. Given the number of features that are defined by the HTML5
specification, along with the multitude of ways to implement those features with JavaScript,
Java Applets or other browser based technologies, a web developer can be easily overwhelmed. If
Google Web Designer really wants to bring feature full web development to the masses, they should
be paying a great deal of attention on how to ensure all users, regardless of the browser or
version they are using, will enjoy the greatest, feature filled experience possible.

5. WYSYWIG Responsive Design Tooling

Responsive
design, a development approach that allows a single user interface to realign and contort
itself so that it can be rendered effectively on everything from a 1080p big screen television to
the smallest
of handheld devices is a vision that has become a reality through HTML5 flexible boxes, CSS3
media queries and to a lesser extent, JavaScript frameworks like Twitter's Bootstrap.js and Zurb's
Foundation. These technologies are incredibly effective, but they do come with a requisite
learning curve. Furthermore, maintaining and updating a responsive design that may have been
created by a fellow developer can be a challenge. Any new web development and design tool not only
needs to support the technologies that make responsive designs happen, but they must also provide
effective, visual tools that make maintenance and feature enhancements a more standardized process.
A WYSYWIG
responsive design creation and development tool is an absolute must.

Of course, exactly what Google Web Designer will be when it is released is still a mystery. At
it's core, Google is a company that is interested in advertising dollars, and every project they
promote has padding the bottom line as the primary, if not sometimes obfuscated, directive.
Despite what the development community might be wishing for in a new web design studio from
Mountain View, Google Web Designer may be nothing more than a cross-platform plugin that simply
makes it easier to drop DoubleClick ads into Android
and iPhone applications. But until it's eventual release, there's nothing wrong with hoping for
a feature filled development tool that will empower the web developer to create the next generation
of HTML5
based web applications.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.