Author Archives: Chris Minnick

About Chris Minnick

Chris Minnick is an accomplished published author, trainer, web developer, and co-founder of WatzThis?. Chris has overseen the development of hundreds of web and mobile projects for customers ranging from small businesses to some of the world's largest companies. Books he's authored or co-authored include: Beginning HTML5 and CSS3 for Dummies, Webkit for Dummies, CIW eCommerce Certification Bible, and XHTML. Since 2001, Chris has trained thousands of Web and mobile developers in HTML, JavaScript, CSS, SEO, and full-stack web development. His current online courses, Creating Mobile Apps with HTML5 and Achieving Top Search Engine Placements are consistently among the most popular courses offered by online training provider Ed2Go.com. In addition to his role with WatzThis?, Chris is the winemaker at a micro-winery (Bad Astronauts Winery), contributor to several blogs (including chrisminnick.com), and an avid swimmer, cook, and musician.

What is CSS Regions, and Why Does Google Want to Kill It?

CSS Regions is a technology invented by Adobe in order to allow magazine-style layouts in web browsers. CSS Regions would solve one of the biggest problems with web layouts, which is that there’s no way to flow content from one area of a web page into another area, such as has been possible in desktop publishing for as long as desktop publishing has existed.

To understand the need for CSS Regions, take a look at any magazine — content flows around pictures, is continued on the next page, and moves to the left and right of images and pull-quotes.

Now look at a typical web site. Article content flows in one column, no matter how wide the browser window is. Separate regions of text are separate from each other. As a simple example, look at an article that spans multiple pages on a website. Those pages aren’t connected to each other. Each is an island of content — if you resize your browser window to be thinner, the same number of words still appear on page 1 and copying and dragging to highlight the content in an article doesn’t span to page 2, or even necessarily around pull quotes.

Content on web pages is fragmented into different regions in order for it to fit nicely and look good. The result is that the sort of layouts that are routine in print are impossible or highly inconvenient on the web.

CSS Regions would solve this problem by allowing web page designers to connect different parts of a web page and flow text dynamically into them. The idea is simple and intuitive.

When Adobe first proposed CSS Regions, progress was made on getting it implemented in the WebKit browser engine and even in Internet Explorer. However, Google’s decision to fork WebKit to create their own browser engine, Blink, changed everything.

Google announced earlier this year that they’re no longer pursuing support for CSS Regions, because their priority is to simplify Blink in the interest of increasing performance, particularly on mobile devices.

While performance is certainly a noble goal, I have no doubt that Google could make CSS Regions work in a performant way if they wanted to. It may be that Google has just judged CSS Regions to be too complicated (it’s really not) and is working on a better solution. Or, it may be that Google doesn’t want to have to compete with Safari and mobile Safari (which both support CSS Regions) and announcing that the most popular browser (currently Chrome) won’t support it is certainly an effective way to make sure that developers don’t start using it and get attached to how well it works in Apple’s browsers.

I certainly hope that Google changes it’s mind, or that Google and Adobe can work together to find a way to implement the functionality of CSS Regions in Chrome. In the meantime, if you’re interested in trying out CSS Regions, Adobe has released a polyfill that will enable the functionality of CSS Regions in every browser, using JavaScript.

Should you bother with semantic elements?

Do Web Developers Need To Know HTML?

The other day, I was having a conversation with some of the best and smartest programmers and web developers I’ve ever met about my favorite topic: the future of the web. During the course of the conversation, the following statement was made:

“In the future, web developers won’t need to know HTML.”

As a person who who has been writing HTML for 20 years and who has written several books on HTML, I was more than a little interested in this statement. I remember Microsoft FrontPage, Flash, and many other tools over the years making the same promise.

But, are things different today?

The person who made this prediction cited front-end JavaScript frameworks (such as AngularJS), which can significantly increase developer productivity and produce fantastic web site user interfaces with much less code than raw HTML5, CSS3, and JavaScript.

JavaScript frameworks typically extend HTML to enable functionality. For example, take this simple AngularJS template:

<html ng-app="phonecatApp">
<head>
  ...
  <script src="bower_components/angular/angular.js"></script>
  <script src="js/controllers.js"></script>
</head>
<body ng-controller="PhoneListCtrl">

  <ul>
    <li ng-repeat="phone in phones">
    {{phone.name}}
    <p>{{phone.snippet}}</p>
    </li>
  </ul>

</body>
</html>

This is HTML, with some special attributes. If you didn’t know HTML, you would need to learn it prior to learning Angular, unless you use a WYSIWYG tool. My personal experience with WYSIWYG tools, however, is that, sooner or later, you need to write code by hand. Without a knowledge of the underlying syntax of HTML and Angular, you’d be sunk.

Saying that web developers don’t need to know HTML struck me as similar to saying that English speakers don’t need to know the alphabet. I just can’t accept it. But, perhaps I’m too close to the subject.

What do you think? Will web developers of the future need to learn HTML?

Monetizing Mobile

phone A new study by eMarketer, released this week, finds that adults in the U.S. are spending more time on their mobile devices than on desktop and laptop computers.

The same study estimates that mobile ad spending has more than doubled in 2013, while desktop ad spending has grown only 1.7%.

This should be a wake-up call. Now is the time to focus on your mobile strategy and to prepare for monetizing mobile websites in 2014, which promises even faster growth. Here are some of the things I recommend that everyone with a website, but especially everyone with a website that includes advertising, should do right now:

1. Visit your website with a smartphone. If you don’t have a smartphone handy, visit http://www.mobilephoneemulator.com/ to simulate the experience of using your site on a smartphone. If your site was redesigned more than a couple years ago, chances are good that it’s not going to look good, or that it will require the user to zoom to view it (certainly a less-than-ideal user experience).

2. Read this study from IDC, which found that 79% of 18 to 44-year-olds have their phones on them or near them for all but 2 hours of their waking day. Furthermore, the same percentage (79%) say that the first thing they do when they wake up each day is to check their smartphone. Among 18-24 year-olds only, the percentage that reach for their phone before they do anything else is 89%.

3. Read this article which compares mobile ad click-through rates with desktop ads. Or, if you don’t have time to read it right now, let me give you the executive summary: mobile ads have much higher click-through rates than desktop ads.

The trend towards mobile computing is clear, and now’s the time to do the work necessary to take advantage of it!

Sincerely,

Chris Minnick

p.s. A new session of my online class, Creating Mobile Apps with HTML5 just started! Visit our site to sign up or to view the first lesson!

The HTML5 Browser Dilemma

As we speed towards the year that HTML5 will become an official recommendation, let’s take a look at the current level of browser support. Here are a couple images that we all need to be familiar with. The first is from HTMLtest.com, a site that ranks browsers based on how well they support the HTML5 spec. The highest possible score is currently 555.

The next chart is from W3Counter.com, which tracks current browser usage. Here are the numbers from November 2013:

While it’s great news that browsers that are highly compliant with the HTML5 standard represent nearly 50% of the market share, it’s troubling that browsers that are so far behind as IE9 and older still account for about a quarter of all browsers in use today.

So, what are we to do about this? Here are our recommendations for web developers (and those who employ web developers) everywhere:

1. Write all web pages in HTML5, according to the latest version of the spec. Browsers are continually getting better, and even the most late of late adopters are gradually graduating to better browsers. When you’re feeling down, notice the complete lack of a certain version of a certain browser from Microsoft on the above chart!

2. Learn about and use Modernizr and Polyfills for any feature that might not be supported by every browser. Modernizr is a JavaScript library for detecting whether a user’s browser supports features. Polyfills are JavaScript replacements for HTML5 features which you can load conditionally based on the test results from Modernizr. For example, if you want to use the HTML5 video tag on your site, but you don’t want to leave behind users with old browsers, simply test for <video> support and include one of the several <video> polyfills. You can then use <video> as you normally would…the polyfill will take care of the rest! It’s like magic, except it’s not.

HTML5 represents a major improvement to the web, and it holds the promise of reducing and perhaps even eliminating browser incompatibilities at some point. But, not just yet. In the meantime, however, it’s fully possible to support nearly every user of your site and to smooth over browser incompatibilities by using simple and free tools. So, why wouldn’t you?

On Shelves Now: Beginning HTML5 and CSS3 For Dummies!

Leave a reply

I’m proud to announce that the latest book is in stores and online everywhere now. As the new co-author for this long-running and very popular series, I thought I’d take a moment to introduce myself and tell you what makes this book special.

My education as a web developer started prior to the first edition of HTML For Dummies, but I do vividly remember first learning HTML way back in 1993. The entire process of writing and publishing web pages was new to me (and to almost everyone) back then, and I had many questions.

I remember the frustration of following a tutorial and realizing that there was some required piece of knowledge that wasn’t being mentioned. Without that one piece of the puzzle, which I didn’t even know how to ask about, there seemed to be no hope of me making the leap from web user to web author.

Eventually, however, I would have an “ah-ha” moment that would carry me to the next stumbling block and I’d be forced to bumble around in the dark a while longer. Over time, I got really good at learning new web development skills — but it wasn’t the most efficient way to learn.

When books on HTML and web development started coming out, I gobbled them up. Before we even met, several of Ed Tittel’s books were indispensable references during the first decade of my career as a web developer.

I met Ed in 2000, when I was teaching Cold Fusion and Active Server Pages at Austin City College, and he helped me get my start as a computer book author. After writing and co-writing several books, I got burned out on writing books and took some time off…about 10 years, to be more precise.

I came out of my book-writing retirement to write WebKit For Dummies in 2011. Working with the team at Wiley was a great experience, and contributing to the For Dummies series is quite an honor for me. When Ed asked me to step in as his co-author for Beginning HTML5 and CSS3 For Dummies, I replied “YES!” within 1 minute of getting his email.

I had already been thinking about how I would approach writing a new HTML book, and I was excited to find that Ed’s vision for the book was very close to mine and both of us were very much in line with the vision of the editors at Wiley.

Our first decision was: This should be a book for beginners. We wanted to reach way back into our memories and remember every frustration we had when we were getting started, and figure out a better and more complete way to teach the basics.

Next, we decided that this should be an HTML5 book, and XHTML would be mentioned as little as possible (and preferably not at all). I felt (and still feel) very strongly about this issue. Without going into the details (I’ll save that for a later post), XHTML is the markup language that very nearly killed the web. With HTML5 now widely supported by web browsers, there’s really no reason for anyone to learn, or try to use, XHTML.

Finally, we decided that nearly all coverage of JavaScript would be cut. This was not an easy decision, since JavaScript is more important to web development today than it’s ever been (and it’s only getting more important). However, this is a beginner’s book about HTML5 and CSS3 and these are both giant topics to cover in only 400 pages. We decided in the end that we could either do a really good job of covering as much of HTML5 and CSS3 as possible, or we could do an inadequate job of covering HTML5, CSS3, and JavaScript. We picked the former.

Of all the books that I’ve worked on with other authors, this one was the smoothest and most enjoyable. It is truly a pleasure to work with Ed, and I’m confident that we put together a fantastic book.

I hope you enjoy reading and learning from Beginning HTML5 and CSS For Dummies as much as we enjoyed writing it. If you have any comments or questions, please let us know!