Categories
HTML5 Technology

Too much crap

I tried to find a web page to link in my last story, about the recent discussion surrounding Apple’s new HTML5 demo that deliberately prevents other browsers from accessing the examples. I finally had to link my own Twitter note about the problem, because every site that wrote about the issue had too much crap in their pages.

Don’t have to take my word, just search on “apple html5 demo blocks”, and you’ll find site after web site that covers the story, true, but the story is pushed down by headers that manage to link in half a dozen ads, and multiple Google links to boot. Or, just as you finally dig out the real stuff, some stupid overlay ad or “survey” hides everything, and you have to search for the little bitty close text, just to get rid of the damned thing.

Then there’s the Twitter tweets, and the Facebook notes, and the links to this application and that application; this widget and that. Are we afraid that people will think no one likes us if our web pages aren’t full of moving, annoying bits?

I watch my browser status bar as dozens of different domains have to be looked up, just to read one or two paragraphs of text. If my ISP’s DNS server is running slow, I never get to the stories.

I’m sure someone is making money from all of this. How much money are these sites really making, though, if after minutes of nothing, I hit the stop button and return to the searches to find a site that may actually provide the story, load relatively quickly, and not exhaust my DNS server in the process.

Folks have talked about wanting native semantics in HTML5 because they don’t want to have to load the big bad JavaScript frameworks, such as jQuery. “Give us date pickers and color pickers”, they say, “Because the JavaScript is too big! It hurts the web!” What’s absolutely absurd about all of this, is that the JavaScript framework libraries are probably the only thing in any of these sites that load quickly.

What Google, Yahoo, and Bing need to start printing in search results is how many domains will have to be looked up, how much external crap will have to be loaded, if we click that link. Frankly, I would find that much more helpful than a warning that the site could potentially be a source of malware. At least malware is a straightforward attack, which is better than this killing of our time waiting on these bloated, useless sites, where every ad company in the entire world has staked a claim, leaving tiny pieces of the page for actual, useful stuff.

Categories
JavaScript Writing

Future. Perfect.

I finished copy edits on my JavaScript Cookbook, which now enters the production process.

The first half of the book focuses on the basic components of JavaScript, while the latter half gets into the more complex material. I touch on the basic JavaScript objects, such as String and Number, but also spend a considerable amount of time covering new ECMAScript 5 and HTML5 scripting features: HTML5 drag and drop, postMessage, the Files API, worker threads, the wonderful new object methods, and so on.

I devoted one chapter to covering ARIA, Accessible Rich Internet Applications, as well as some other accessibility features. The more I work with ARIA, the more I view it as more of a rendering semantics than something purely for screen readers. For a data person like myself, ARIA is a very comfortable technology to use. I’ll have more on ARIA in later writings at MyTech.

Speaking of which, I’ve added ARIA landmarks to my web sites. Use View->Source to look for the role attribute, which is how ARIA landmarks are added. It was easy to update the Drupal templates to incorporate the new material. Unfortunately, the pages don’t validate, but I no longer care about validation. Frankly, the days of trying to code your pages to meet some validation criteria are over. Nowadays, pragmatism is the word in web development.

I am at work on my next book, but it’s not going to be for O’Reilly. Instead, I’m going to try my hand at self-publication, which is why I’m spending so much time working with ePub and other eBook formats. I’m also trying to strengthen my self-editing skills. After 18 books, I’ve become dependent on copy editors—my writing has become sloppy, and full of typos. Speaking of which, I strongly recommend, Paula LaRocque’s “The Book on Writing: The Ultimate Guide to Writing Well.” LaRocque’s book has proven invaluable as I root out my bad writing habits.

Categories
Money People Technology

An Appleless future

It is time to buy new computers.

My desktop Windows computer is a 4+ year old Dell laptop with a burnt out LCD that I hook up to an external monitor. It’s running Windows XP, and could potentially be upgraded to Windows 7, but only with much wailing and gnashing of teeth.

My laptop is the last of the PowerPC PowerBooks running Leopard, since Snow Leopard only runs on the Intel machines. I’ve had to replace the Airport card, and the hard drive, but both were covered under warranty. The keyboard is starting to get mushy, but still works. The real problem is the growing lack of support for the old PowerPC architecture.

If July royalties go well, then I’ll look at replacing at least one, possibly both. When I do, though, I won’t be replacing either with an Apple computer.

Why an Apple-free future? One reason is cost: I can replace both my desktop and laptop with good, relatively powerful Windows machines for the cost of one 13 inch Macbook Pro. The days of having money to burn for “sexy” machines are over—now I want solid machines with good software support that are competitively priced.

Another reason to move from Mac back to Windows is I don’t need a Mac. All of the applications I use have a Windows-based version. I stopped using MacPorts a while back when I got tired of the continuous round of upgrades. I don’t run a web server on my home machines anymore, doing all my development out at my web site. Besides, you can run a web server on a Windows machine as easily as a Mac.

Ease of use isn’t an issue for me, as I’m comfortable with both environments. I haven’t tried Windows 7 but whatever quirks it has, I’ll learn and adapt. I used to be able to work with DOS and the old VAX/VMS—I can handle a new operating system.

Security used to be a big reason to stay with the Mac, but nowadays Apple is as much of a target as Windows. Besides, most security problems arise because of applications, and cross OS boundaries. Relying on using a lesser used OS to protect you from problems isn’t an effective approach: a secure system is 95% common sense, 5% other. So, save some money and use common sense.

My Photoshop installation is CS3 on the Mac, but supposedly I can cross-grade my license, and swap it for a Windows license. If I have spare change from buying a new machine (i.e., you all buy more of my books) I’ll upgrade to CS5, and cross-grade the license to Windows. If Adobe doesn’t let me port my license to Windows, well, then it’s time to move all of my graphics work to GIMP. Besides, I primarily like Photoshop because I like Adobe Bridge for editing metadata and viewing my images. There are alternatives.

A last reason for not staying with Apple is I’m tired of the company. I’m tired of hearing about it. I’m tired of seeing people in line, waiting for a phone. I’m weary of the Apple cult, Apple lawsuits, Apple prototypes, Apple mystic, and stark black and white.

I am no longer enamored of devices where form takes precedence over function. What other manufacturer could get away with providing devices where you can’t replace the batteries?

Worse is the lock-in. If you want to develop for the iPhone or iPad, you have to own a new Macbook Pro just to use the relevant SDK, and then you have to purchase the SDK. It also peeves me to see people buying into what is nothing more than a horrifically closed, obsessively controlled environment. You have to use the Apple code, develop to the Apple model, think the Apple mindset, which embraces puritanical censorship and nowadays lacks both perspective, and sense of humor.

The Steve Jobs of yesteryear was arrogant, but innovative. The Steve Jobs of today is just plain arrogant. I don’t want to give him my money.

Categories
Graphics/CSS HTML5 JavaScript

Declarative Elements versus JavaScript and CSS

Over time as I looked at several of the new elements in HTML5, I saw a trend: many of the elements are single purpose derivations of popular, and commonly occurring, JavaScript and CSS applications. Consider the following list:

  • the progress element
  • the meter element
  • the hidden attribute
  • the details element
  • the telephone input type
  • the email input type
  • the search input type
  • the color picker
  • various date pickers

As I wrote in one of the change proposals, any one of these would have be welcome ten years ago, when HTML4 was released. But now, after we’ve come so far with using JavaScript and CSS, not to mention SVG and the Canvas element—what is the lesson we’re learning from these additions?

Ten years ago, support for CSS and JavaScript was poor enough that something like a color picker was almost impossible, unless you used Flash. Now, though, there are dozens of good libraries available that can implement a color picker. Drupal’s color picker is based on the jQuery UI, but it’s not the only option.

We’ve also had date pickers for years, too. Date pickers in all shapes and sizes, and most configurable by the user so they can get the absolute best date picking experience. The same can be said for progress bars, and if meter is supposed to represent a gauge, there are libraries that provide gauges, too.

As for the input types, such as telephone and email, most of the validation for these types of values can be handled with one line a code and a regular expression. The types also beg the question: where does it end? If we need single purpose data types such as telephone and email, why stop there? What about social security number for people in the states, or zip and/or postal codes?

One of the primary reasons for regular expressions in JavaScript is to ensure that a given string fits a given format. If we don’t know how to use regular expressions, that’s OK, because just like the iPhone, there’s a app for that. There are many libraries that automate the format validation for us. All we have to is assign a class to the relevant input fields.

The new elements, attribute, and input types aren’t just treading in JavaScript and CSS territory. Supposedly the reason for the hidden attribute is accessibility, as is a reason for several of the other elements. Yet the WAI-ARIA effort has provided the exact same functionality and semantics that can be used and reused with any number of elements.

ARIA is to accessibility, as JavaScript is to behavior, as CSS is to style, as RDFa/Microformats/Microdata are to semantics, and as HTML is to structure. Except, suddenly, HTML is no longer about structure. The clean separation between the various domains that has worked so well in the past is seemingly no longer of interest to the HTML WG. Consider the following statement in the HTML5 specification:

Authors are encouraged to use declarative alternatives to scripting where possible, as declarative mechanisms are often more maintainable, and many users disable scripting.

For example, instead of using script to show or hide a section to show more details, the details element could be used.

Why?

The arguments I’ve read are that declarative alternatives can be used by non-developers, but they’re no easier for non-developers to use than most of the JavaScript libraries I know, which usually only require adding a class to an element.

I’ve also read that declarative alternatives aren’t impacted when JavaScript is turned off, but in my opinion, that’s not a good thing. People have become used to JavaScript-based functionality on the web. They know if a section is exposed via JavaScript that turning off the JavaScript should display the section by default. People can control JavaScript and Flash in their browsers, which means they can control the behavior of the web page. They can also turn off CSS, if they wish. But they have no control over declarative elements and animations.

Consider, too, the costs involved with all these new elements and other objects. Rather than browser developers focused on making the most efficient JavaScript engine, the most secure browser, adding support for SVG and Canvas, Video, WebGL, and any of the other new technologies, the developers now have to focus on what is nothing more than a duplication of functionality already available via libraries, apps, and widgets. Which they also have to support through the core technologies of CSS and JavaScript.

Then consider all of the HTML editors and WYSIWYG tools that now have to add several new input types and elements, including having to provide a live preview of the functionality. Implementing all these new elements, attributes, and input types must seem a daunting task.

How about the web authors and designers? New toys, eh?

New toys that lack both the sophistication and customization capability that we’ve had with our existing libraries. New toys that aren’t accessible until we can convince the screen readers that no, seriously, not only do they have to support ARIA, they have to support all these other new things, too.

Categories
SVG Technology Writing

Snowing

I’ve not been the best at keeping up with my writing at my various sites. I have been writing, though.

I have a two-part article up at A List Apart: Using SVG for Flexible, Scalable, and Fun Backgrounds, Part 1 and Part 2. Though Microsoft still hasn’t implemented SVG in IE, with the company’s new membership in the SVG Working Group, there’s new hope for the future. And I cover how to use a JavaScript library, SVGWeb, to work around the lack.

I’m also finishing a new book for O’Reilly: the JavaScript Cookbook. It promises to be a big book, which isn’t surprising, considering how much JavaScript has advanced. I’m also incorporating the relevant bits from the HTML5 specification, though I have to be careful, as we don’t know which bits will remain, and which removed before Last Call.

Speaking of which, I’ve been spending an inordinate amount of time with the HTML WG. I have about a dozen Change Proposals coming up in March, which I’ll write about here, when finished. Among them is one to remove one of the more recent additions, the iframe srcdoc attribute. This example for this new attribute is the following, for weblog comments (the use case for the new attribute):

<article>
 <h1>I got my own magazine!</h1>
 <p>After much effort, I've finally found a publisher, and so now I
 have my own magazine! Isn't that awesome?! The first issue will come
 out in September, and we have articles about getting food, and about
 getting in boxes, it's going to be great!</p>
 <footer>
  <p>Written by <a href="/users/cap">cap</a>.
  <time pubdate>2009-08-21T23:32Z</time></p>
 </footer>
 <article>
  <footer> At <time pubdate>2009-08-21T23:35Z</time>, <a href="/users/ch">ch</a> writes: </footer>
  <iframe seamless sandbox="allow-same-origin" srcdoc="<p>did you get a cover picture yet?"></iframe>
 </article>
 <article>
  <footer> At <time pubdate>2009-08-21T23:44Z</time>, <a href="/users/cap">cap</a> writes: </footer>
  <iframe seamless sandbox="allow-same-origin" srcdoc="<p>Yeah, you can see it <a href=&quot;/gallery/cover/1&quot;>in my gallery</a>."></iframe>
 </article>
 <article>
  <footer> At <time pubdate>2009-08-21T23:58Z</time>, <a href="/users/ch">ch</a> writes: </footer>
  <iframe seamless sandbox="allow-same-origin" srcdoc="<p>hey that's earl's table.
<p>you should get earl&amp;amp;me on the next cover."></iframe>
 </article>

Just in case you’re curious, no, I’m not particularly fond of weblog comments as escaped HTML within an attribute on an iFrame.

I’ve also been playing with the new Drupal 7 alpha in my copious spare time. I won’t be moving my sites over to Drupal 7 until a stable release, but I do have a “play” site. I like the new release, though I wasn’t terribly fond of the admin overlay. However, the new admin overlay can be turned off. In addition, I re-posted all of the pages, and comments, from my older WordPress weblog. It takes up little room, and ensures I can find, and link, some of my older work. Plus, folks can find their comments. I was impressed with the fact that WordPress was able to upgrade my old site, without a hitch.

So much to write, so little time. Today, though, it’s snowing, and I haven’t had a walk outside since the weekend. Enjoy the articles at A List Apart, and more writing here, soon.