Year: 2010

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
Stuff

Skewing old

Amazon released a Kindle 2.5 update this week. The big news about the software upgrade is that it finally includes support for collections—being able to group books based on some criteria. This is the functionality we’ve been asking for since the Kindle was first released. Great!

Great, except that the software upgrade is for Kindle 2 and DX owners, not the Kindle 1. Amazon seemingly perceives the Kindle 1 as an early, failed experiment, and Kindle 1 owners, early adopter guinea pigs who should be content with just being there in the beginning.

When Kindle 1 owners expressed disappointment in the Kindle owner discussion forums, we were told that this is the way it is; that companies don’t support old, obsolete equipment. Instead of bitching about the software update, we were told to upgrade to a shiny new Kindle DX. One wit even quipped that yes, he also wanted support for his Commodore 64.

Ignore for the moment that the Commodore 64 is 28 years old, and my Kindle 1 is a little over 2 years old…

Categories
HTML5 Specs

HTML5: end of one chapter, start of another

I had planned on providing more edits to my change proposals, but doing so is only throwing good time away on a hopeless cause. I can’t even get the HTML5 co-chairs to realize that by allowing those who proposed a counter-proposal to group all of the items in only one response, they’ve made individual discussion on each change proposal, impossible.

I also can’t discuss most things on the list without being told to take it off-list. I feel as if the co-chairs are continuously taking me to the wood shed—it’s been, frankly, a humiliating experience.

I have no recourse but to quit the group. Evidently, the W3C does not find me a useful participant.

I’m not done with HTML5, but I am done with the HTML WG. I think HTML5 has significant problems, and I think the way the specification is currently written is going to cause a lot of confusion and problems in the future. But if I write on HTML5 going forward, it’s as a “citizen”, and not part of a group that says it wants to hear responses from the web community at large, but in actuality, just wants to rubber stamp what some of the browser companies want.

Categories
HTML5 Specs

Remove the Hidden attribute

My change proposal for Issue 95 is about removing the hidden attribute[1]:

The HTML5 specification states the following about this attribute[2]:

All HTML elements may have the hidden content attribute set. The hidden attribute is a boolean attribute. When specified on an element, it indicates that the element is not yet, or is no longer, relevant. User agents should not render elements that have the hidden attribute specified…

The hidden attribute must not be used to hide content that could legitimately be shown in another presentation. For example, it is incorrect to use hidden to hide panels in a tabbed dialog, because the tabbed interface is merely a kind of overflow presentation — one could equally well just show all the form controls in one big page with a scrollbar. It is similarly incorrect to use this attribute to hide content just from one presentation — if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers.

The hidden attribute section provides one example: a game screen is hidden until a person has logged in.

Rationales for Keeping the Attribute

The HTML5 editor, Ian Hickson, wrote the following rationale as reason for rejecting this change in the associated bug[3]

Rationale: hidden=”” is a key part of HTML5’s accessibility story and represents one of the main accessibility improvements over HTML4 for dynamic applications.

A counter-proposal has been provided to keep the attribute. The rational given is[4]:

Authors of web documents and applications often need to temporarily hide certain content from readers and users.

Via a combination of script and CSS, such functionality is possible to build today, and there are hundreds of such implementations extant on the web. It’s clear that hidden=”” Solves Real Problems.

Attempting to implement such functionality with JavaScript and CSS is fundamentally more difficult and error-prone than hidden=””. hidden=”” is literally the simplest thing that could possibly work, and thus we Avoid Needless Complexity in its design.

By making it as easy as possible to author, and by defining uniform UA behavior (unlike bolt-on scripts which emulate this functionality), we preserve our Priority of Constituencies.

Bolt-on emulations of hidden=”” can fail to correctly hide content in a media-independent way, resulting in a degraded experience for users of aural browsers and other AT tools. hidden=”” thus promotes Accessibility more than bolt-on alternatives.

In addition, the Accessibility TF discussed the change proposal[5], and among the benefits discussed were the following:

  • Not so strong on keeping the hidden attribute.
  • Hidden does what the ARIA equivalent does, and seems useful.
  • Could live without it given we will get it in aria.
  • It’s like display:none but without the nasty side effects.
  • It is slightly different from aria-hidden…
  • HTML5 hidden applies to ALL elements
  • Not sure this has an accessibility impact…
  • There is some impact (but not a lot).

The Accessibility Task Force also provided a general statement regarding this element and others:

RATIONALE: The F2F believes these elements are actually useful for accessibility. We note that features similar to the elements in question are today created using elements with different semantics actuated by style and script, whereas we prefer native elements.

Response

I took a best guess effort at summarizing the rationales for keeping the hidden attribute.

  • It provides accessibility support where none existed in HTML4
  • Implementing the hidden functionality with JavaScript and CSS is difficult and error-prone
  • It’s the simplest thing that can work
  • It works with all media
  • It is semantically meaningful

I say “best guess” at summarizing, because the discussion points from the Accessibility TF seem to indicate that some members of the discussion don’t think the hidden attribute is particularly useful.

I do agree with the counter proposals that the hidden attribute is easy to use. From the example in the specification—set the value to true, to hide the element’ contents, false, to display the contents—you can’t get a simpler attribute. I also agree that HTML4 did not have an equivalent functionality built into the specification. However, I do not agree with the other statements given.

The Existing Behavior with JavaScript and CSS, Media, and Simplicity

The HTML5 specifications defines the rendering for the hidden attribute to be equivalent to setting the element’s display property to “none”[6]. You’d get the same effect with the following code:

document.getElementById("elem").style.display="none";

Or the following code:

document.getElementById("elem").setAttribute("style","display:none");

As you would setting the hidden attribute:

document.getElementById("elem").hidden=true;

You could even absolutely, positively, completely ensure the accessibility of the effect, using the following:

[aria-hidden="true"]
{
   display: none;
}
...
document.getElementById("elem").setAttribute("aria-hidden","true");

If any user agents do render content when the element’s display property is set to “none”, it’s the fault of the user agent, not the CSS or aria-hidden attribute. If user agents have problems with display being set to “none”, they will continue to have problems with the hidden attribute because the two are equivalent.

As for simplicity, both approaches are again, exactly equivalent.

The Semantics of Irrelevance

The hidden attribute was once named the irrelevant attribute, supposedly because the attribute is used to mark the contents of whatever element it is attached as “irrelevant”. The attribute was renamed because, a) the irrelevant term was confusing, and b) techs misspell words like “irrelevant”.

Is the content truly irrelevant, though? Consider the definition for the attribute:

Elements in a section hidden by the hidden attribute are still active, e.g. scripts and form controls in such sections still execute and submit respectively. Only their presentation to the user changes.

An irrelevant element is not one that is active, receiving events, participating in the web page, or form submission. The only truly irrelevant page component is one that doesn’t exist. If people want a truly irrelevant page section, they should use the DOM to create and remove the element, as needed. There is nothing about the behavior associated with removing an element from user agent rendering that is made more meaningful using a single-purposed HTML attribute, rather than using a simple combination of CSS property and ARIA attribute. Both have to do with the presentation of the element.

Presentation with the hidden attribute isn’t an incidental purpose, it is the primary purpose of the attribute. Rather than separate presentation and structure, it firmly welds the two.

Accessibility

The hidden attribute is no more accessible than setting the element’s CSS display property to “none”, because the two are equivalent.

However, the hidden attribute can be detrimental to accessibility because there’s nothing in the HTML5 specification that describes the precedence of settings. The ARIA documentation states that ARIA settings, such as aria-hidden, take precedence over settings such as display=”none”. Does the aria-hidden attribute have precedence, then, over the hidden attribute? How about when hidden is set to true, but a CSS stylesheet sets the display property of the element to “block”?

Introducing hidden introduces a redundancy, yet the documentation for hidden does not take such redundancy into account when defining the attribute.

Costs

The costs for an attribute such as hidden, are not as high as a more complex object, such as the details element. However, there are costs. Lint tools and validators now have to ensure conforming use of the attribute, HTML editing tools and WYSIWYG applications have to incorporate the new functionality, libraries have to be modified, books updated, design themes modified, and so on.

Web developers and designers have to spend time trying to figure out when to use CSS, and when to use the hidden attribute. I can imagine the many discussions about ‘irrelevant” content, and what does “irrelevant” mean in one context or another. It is an esoteric concept, and as such adds unnecessary complexity.

If the attribute provided something useful, it might be worth the costs. However, the hidden attribute provides absolutely nothing that we don’t already have.

Categories
HTML5 Specs W3C

On being an HTML5 deletionist

When last I posted, I was confident I would be finished with my change proposals for the HTML5 by now. Little did I suspect at how strong a reaction my proposals would have, or how emotional the discussions would become. Some of the responses were humorous, such as when I was called a “deletionist”, of all things. Most of the responses, though, were not pleasant.

Ian Hickson, the HTML5 editor, framed his replies rejecting my changes in terms of accessibility and that’s how I responded. As was noted by the wise woman in the group, Laura Carlson, the use of accessibility in this regard was likely a red herring. However, when you write a change proposal, all you can do is respond to the presented arguments. Now, there have been additional arguments, and I’m adjusting my response accordingly.

I was disappointed in how my change proposals were treated. I didn’t expect the HTML5 WG co-chairs to encourage people to respond with one counter-proposal for several of my change proposals. Though each of the impacted proposals was about removing an element from the HTML5 spec, each element is unique. Or at least, I though they were unique. The response leads me to wonder: if people respond with a blanket statement about all elements, how unique are they, really? And how useful?

The Accessibility TF responded in support of keeping the elements, but again, grouped all the elements together in the group response. This following from the groups having marked the original bugs as outside of the group’s interest. That this response was inconsistent didn’t seem to matter—built-in elements are better for accessibility, regardless of the elements.

Back in the HTML WG, I have been met with a block of voices all clamoring, “We want the elements”. My first reaction when met with the fairly strong resistance was to bag my change proposals, and just let the overly large HTML5 specification be that much larger. Such a response, though, would not be honest—I genuinely believe that not only are these elements not useful, their costs exceed whatever perceived benefit they may bring.

Now, a few months later, I’m making final edits to my change proposals in response to the blanket counter-proposal and the one paragraph response from the Accessibility TF. You can read my work for the first change proposal I’m editing, related to deleting the details and summary elements. I’ll post my work in progress for the other change proposals as I finish.

Yours truly,

the Deletionist