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.

Categories
SVG

Celebrating the first day of SVGOpen

Wordle Image of RealTech front page, captured using Skitch and saved as PNG.

PNG file opened in Inkscape, and Trace Bitmap applied. Bitmap options: Multiple Scans, Colors, 5 Scans, with options to stack the scans, and remove background.

SVG finished by running Scour, saving 52.1% of the SVG file size. SVG made cross-browser friendly, via SVGWeb.

Categories
Specs W3C XHTML/HTML

The HTML5 silly season

Cynthia Shelly released an alternative proposed HTML5 draft that addresses the table summary attribute. The responses to her draft have been less than edifying, and demonstrate rather succinctly most things wrong with the HTML WG.

If you follow along in the thread, you’ll see Apple’s Maciej and IBM’s Sam Ruby go back and forth on protocol, a discussion Maciej ends with a suggestion to focus on salvaging a “proposal” from the work. The thing is, providing alternative text in a specification is the proposal, the only that is deemed acceptable to the HTML WG. At least, that’s what we’ve been told in the past.

Not that Cynthia is demanding that the text be used as is. This was a suggested text, addressing how summary could be discussed in the HTML5 specification, in order to ensure proper use. The proposal also removes summary from the obsolete list. Cynthia proposed this alternative text in order to generate discussion, leading to its refinement; to encourage team effort. Simple enough to understand, but then we’re subjected to the typical Ian Hickson disingenuous approach to anything he disagrees with: pretend he doesn’t understand what the proposal is all about.

I couldn’t find any description of what problem this proposal is trying to solve. Could you point me to the description of the issue that is being resolved here? Why is the text currently in the HTML5 spec not considered acceptable middle ground?

It is difficult to evaluate proposals without understanding what problems they are trying to solve.

Incidentally, I believe the process that we are supposed to be following these days is that when there is a problem in the spec, a bug should be filed describing the problem, so that the issue can be tracked. If you could file a bug (or point me to the relevant bug if one is already filed), that would be very helpful.

(At this point I would like to inform my readers: everyone can file a bug, you don’t have to be a member of any W3C organization to do so.)

So, HTML WG team members are told by one of the HTML WG Chairs to provide alternative specification text, while the HTML5 author countermands such a recommendation, with a note that we file bugs, instead. Seriously, I keep expecting the third stooge to enter the scene, stage left.

And he does. The author of validator.nu, worker extraordinaire for Mozilla, Henri Sivonen, puts on his court jester cap to derail even the potential for worthwhile discussion:

Further quotes are from the proposed text--not from Maciej:
> Summary is one way to provide explanatory information about tables  
> that consist of more than just a grid of cells with headers in the  
> first row and headers in the first column.
>
Does this intend to say that using @summary is categorically  
unnecessary when headers appear in the first column and/or first row?  
If so, it would be good to make this clear.
> Such explanatory information should introduce the purpose of the  
> table,
>
Shouldn't the purpose be stated to all readers?
> outline its basic cell structure,
>
Shouldn't this be generated by the AT from the table model?
> The information provided by the summary is needed by users who  
> cannot see the table, but would usually be redundant for those who  
> can.
>
This sentence sticks out as non-spec-like. It doesn't state a  
requirement, so it looks odd in the middle of a paragraph that states  
requirements.
> This must be done in a way that is associated with the table via  
> markup, such that user agents and assistive technology can  
> programmatically determine the relationship.
>
This sentence could make sense in WCAG-like contexts where things are  
defined in terms of what available software happens to support. It  
doesn't make sense in a spec that defines what software must support.  
(Furthermore, "programmatically determine" is a special term from  
other specs but isn't defined as part of the special vocabulary of the  
HTML5 spec.)

The proposed text seems to imply (in the edits done on examples) that  
having the explanation in a paragraph preceding the table isn't  
sufficient without an explicit aria-describedby link (misspelled in  
the proposed text as aria-described-by). Why is that not sufficient?
> When using summary in combination with another technique, authors  
> must not use the duplicate text, but instead use summary for the  
> parts of the description that are only useful to users who cannot  
> see the table.
>
What about duplicating information that AT should be able to voice  
based on the table model?
> <table summary="The table is divided into six columns: Map number,  
> Date, Area or stream with flooding, Reported deaths, Approximate  
> costs (uninflated), and Comments. The rows are grouped by flood  
> types into six subcategories: Regional flood, Flash flood, Ice-jam  
> flood, Storm-surge flood, Dam-failure flood and Mudflow flood." 
>
In this case, the first sentence clearly duplicates information that  
are trivially programmatically determinable by the AT from the table  
model (given proper <th> markup). As for the second sentence, I think  
it would be worth investigating if the salient content of the second  
sentence is also realistically programmatically determinable from the  
table model. On the face of it, discovering the content of the second  
sentence from the table model doesn't seem like an overly hard  
software problem.

So, the text of the proposal that Cynthia provides is addressed to humans, which Henri rejects, because Cynthia’s text should be addressed to machines. She discusses declarative markup, and addresses this discussion to people, in order to ensure that the summary attribute is properly used by web page authors and designers. Henri reduces the whole to algorithms, care and feeding of.

This is a perfect lead in to another discussion about HTML5 taking place elsewhere, in the W3C TAG, which has ultimate responsibility for ensuring the many specifications such as HTML5 work in a complementary manner for the web. The focus of the TAG at this time is detailing issues this group has with the current HTML5 draft, a discussion generating a typically mature level of discussion in the WhatWG IRC channel.

One such issue, as I have noted, as others have noted, is the fact that the specification is given in algorithmic terms, rather than as declarative text—based on discussions of a Document Object Model (DOM) with HTML markup given as a distant secondary item (barely covered, and leaving ripples of confusion in its wake).

The current rendering of the specification is considered more precise for the browser companies, for Mozilla, Google, Microsoft, Opera, and Apple, but the precision completely obfuscates the information needed by thousands, perhaps millions of web page authors and designers.

In the past, the main specification would be about the markup, with a secondary document describing the DOM. And oddly enough, this has worked, if we can believe the evidence of our eyes. Evidently, this wasn’t to the taste of the browser companies, who believe that it is more important that their needs be met, rather than the needs of the thousands, perhaps millions of web page authors and designers.

In addition, rather than leave many decisions up to the implementors of the specification, the editor’s draft seeks to detail, in minute detail, how everything is to be handled by implementors. Precise, very precise. Good luck with the 50,000 or so test cases.

So far, I have submitted three HTML5 bugs:

  1. When Web Workers was removed from the spec, orphan references were left – clean up is needed
  2. To remove the Microdata section, as it isn’t necessary, nor widely supported
  3. To allow other namespaced elements in SVG, since the use of these elements is valid within SVG

And I just submitted a bug for table summary. There will be others. Too bad I’m not one of the elite.