Year: 2010

Categories
HTML5 W3C

Proper language

I am not a subtle person. I tend to be blunt, can be confrontational, and am not always easy to be around. I realize this sometimes costs me jobs, readers, and on rare occasion, a friend. I accept the consequence— even the painful ones.

I’ve been told I’m prickly, bitchy, shrill, hysterical, and otherwise evil from tech people. Some guys seem to have no problem with who I am; others, though, dislike me, and on occasion, hate or despise me. Even some women will feel uncomfortable around me. I’m too blunt, too confrontation, too aggressive. Let’s face it, I’m not the most nurturing woman in technology. Frankly, I don’t aspire to be.

Where this is going…

I have joined, and quit, the W3C HTML5 Working Group twice. Both times I joined only reluctantly.

The first time, I was reluctant, because I wasn’t sure I could devote enough time to the group. I also wasn’t sure about working with people whose sole job is writing specs. I am a web developer and a writer—neither of which is particularly adapted to developing specifications.

The second time I was reluctant to join because I was, and continue to be, immensely uncomfortable in the Working Group. The rules seem to change on a frequent basis: fluctuating based on who you are, what you are, and what “group” you belong. There are no strong guiding principles for the group, or for the HTML5 specification, either. It’s a play-it-by ear situation, with those who are not part of the browser community having to struggle twice as hard just to get heard half as much. It is not a pleasant place to be.

Recently, I expressed interest in writing a change proposal for an issue. Since I was the one that asked for it to be upgraded to an issue, I felt obligated to follow through and write a proposal. I was informed that I would need to be a member of the group in order to write a proposal. This is due to patent issues, and the agreement we all sign when we become part of the group. There is no separate agreement outside of the membership process.

I didn’t want to rejoin. I truly did not want to rejoin. At the same time, the only recourse I have if I can’t write change proposals is to file Formal Objections. I’m not adverse to filing a Formal Objection, which requires Directory intervention. But I believe that every issue should have its day in the HTML WG court.

Most of the time when the HTML5 Editor declines a bug request he does so with little or no rationale. The only way to get good rationales for and against a change, is through the issue process. I believe good rationales for all sides should be present before an item goes to the Director. I also believe every change should get its fair say in the group.

So here I am back, a third time, asking to rejoin. Reluctantly, and determined to keep my participation to a minimum. Enough to submit change proposals, formally write out objections in surveys, and ask for a status on my items every few weeks, so they’re not forgotten.

I did hear back from the W3C representative, and the co-chairs. I gave them forewarning that I was going to make their reply public. It may be the gentlemanly thing to do, to not publish such emails online.

It’s a good thing I’m not a gentleman.

Hi Shelley,

I’m writing in regard to your application to rejoin the HTML
Working Group. I have agreement from the chairs to approve your
application on the condition that the following be made clear:

1. You will be re-joining on a probationary basis.

2. You are asked to avoid filibustering and provocative language
and understand that if you decide to quit from the group again,
you will not be allowed to rejoin it after that.

If you can just let me know that you have received and read this
message, I’ll go ahead and push the button on approving your
application.

–Mike

I replied with:

I had no interest in joining the group, but it was a condition demanded
in order for me to submit change proposals. I felt that change proposals
were less disruptive than filing formal objections, which would then
necessitate Director intervention.

I consider the caveat about what language I can, and cannot use, to be
discriminatory. Dangerously discriminatory.

As for quitting from the group again, is there anything in the charter
or policies of the W3C that provides a baseline for who may or may not
join the group, or controls how often they may leave and return?

In other words, I want a substantiation of these demands based on W3C
policies. Then I will consider whether to agree or not.

Shelley

I am somewhat sympathetic to the caveat about not quitting again. I have done so twice before, and doing so can be disruptive. At the same time, though, there is no policy on this in the W3C. The only policy on Invited Experts in the W3C is that they’re allowed in at the discretion of the chairs.

However, the caveat about filibustering and using provocative language is inexcusable. Tell me, what is filibustering in the working group? writing several emails in a thread on an issue. Like this thread? This thread? This thread? Now, I did participate in this one…but as can be seen, I wasn’t the only, or the one who participated the longest.

This thread? And any of the other hundreds of threads that seem to go forever, in which I have not participated?

And what the hell is a filibuster in a specification group?

Come to that, what is provocative language? Is it something like this? Or this? Or this? How about this?

Did I use provocative language with the email leading to this response? It was challenging. Is that what provocative language is? Language that challenges?

Categories
HTML5 Standards

Strategic designs in a strategy-less environment

Still no updates on my issues at the W3C HTML WG, but the co-chairs did decide on the fate of longdesc, the focus of another issue:

the HTML Working Group hereby adopts the Change Proposal to not include the longdesc attribute in the language. Of the three Change Proposals before us, this one has drawn the weaker objections.

This is a highly controversial decision, not the least of which because the HTML WG Accessibility Task Force had recommended longdesc be kept, and the HTML WG co-chairs have disregarded the recommendations of its own task force. In addition, other standards documents in the W3C, as well as elsewhere, not only recommend longdesc use, but also mandate its use (if appropriate) if a site is to conform to law.

The argument for dropping support for longdesc I found to be most disconcerting is the following:

The weakest proposal was the one that makes longdesc conforming but with a warning. The primary rationale given for this proposal was that a few sites may be using longdesc properly. Many of the objections to both of the other proposals also apply to this one. Additionally, there was a strong argument which is unique to this proposal: if longdesc is conforming, user agents will be required to support it; if there is a validator warning, users will be discouraged from using it. This combination is the worst of all possibilities. Eliminating this proposal early made the process of coming to a resolution simpler.

The existence of implementations was found to be a weak argument for inclusion, the quantify of bad data was found to be weak argument against inclusion. External references (standards, laws, etc) was also found to be a weak argument for inclusion.

The strongest argument against inclusion was the lack of use cases that clearly and directly support this specific feature of the language. The fact that longdesc has little observable uptake amongst users reinforces this: all the evidence indicates that users don’t see this feature to be compelling, and the lack of user demand has been noticed by implementors.

This entire section is extremely confusing, for multiple reasons. The first is that the section is describing what happens when a component of a language is deprecated—a concept that has been successfully utilized in technology for as long I can remember. The whole purpose of deprecation is that an element that has been previously supported is no longer, suddenly, not supported. The sudden cessation of support of an element between two releases of a language, library, or API causes confusion, as well as potentially introducing a great deal of breakage as people advance their applications from the older language or library, to the new.

In a mature, thoughtfully designed language or library, what happens, instead, is that the element is supported in the next version of the language, but a warning is given about its use. The warning instructs the user that they may use the element this one last time, but support for the element will most likely be pulled in a future version of the language, or application. The warning should also inform the individual about the preferred approach to take in the future. The use of deprecation ensures that people can gracefully advance their applications to the new release, and still have time to modify existing uses of the previously supported elements.

So the fact that the one of the proposals recommended deprecating the element rather than just making it suddenly obsolete, was considered a weak argument leaves one to wonder: what could possibly be a strong argument?

Of course, one of the primary problems with deprecation in HTML5 is the fact that deprecation isn’t supported in HTML5. No, we now have the new concept of obsolete, but conforming. Whereby deprecation is long known to be a way of gracefully moving a people from the use of one component to another more preferred approach, obsolete but conforming seems to be a way of saying—well, frankly, I don’t know what it’s supposed to be saying. Something profound and extremely clever, I’m sure.

Another reason I found the earlier quote from the co-chair decision to be confusing is that the existence of external laws and standards requiring support for longdesc is also considered a weak argument.

In what world, my friends?

To disdain external standards, not to mention government mandates, is extremely arrogant and incredibly short sighted. It is as if the HTML WG is attempting to undermine the credibility of the W3C. I don’t believe this is the intent but is, instead, a by-product of the obsessive focus, in both the HTML WG and the WhatWG, on meeting the interests of only one group when it comes to determining what’s in HTML5: the browser companies. The so-called Implementers.

Though it is true the browser companies—Apple, Google, Opera, Microsoft, and Mozilla—need to be on board with whatever is released in HTML5, it should also be a given that the browser companies, themselves, should be interested in meeting the needs of their community of users—and this includes the accessibility community, in addition to web developers, designers, other tool builders, and so on.

The HTML WG co-chair decision was, frankly, poorly reasoned. That people will formally object is a given. That the formal objection will succeed is also a given because the W3C has no choice but to reject this decision. The W3C cannot afford to be so cavalier as to arrogantly pronounce itself above government and other organizational mandates. The browser companies may deem themselves to be above such consideration, but the W3C cannot be so short sighted, and thoughtless. The W3C also cannot possibly afford to undermine its own credibility by introducing conflicts between its own recommendations: to recommend longdesc in one of its documents, while, at the exact same time, making it obsolete in another. The whole point of deprecation is to prevent such anomalies from occurring.

Folly. Pure folly.

Categories
HTML5 Specs W3C

Strategic decisions in a strategy-less environment

Still no updates on my issues at the W3C HTML WG, but the co-chairs did decide on the fate of longdesc, the focus of another issue:

the HTML Working Group hereby adopts the Change Proposal to not include the longdesc attribute in the language. Of the three Change Proposals before us, this one has drawn the weaker objections.

This is a highly controversial decision, not the least of which because the HTML WG Accessibility Task Force had recommended longdesc be kept, and the HTML WG co-chairs have disregarded the recommendations of its own task force. In addition, other standards documents in the W3C, as well as elsewhere, not only recommend longdesc use, but also mandate its use (if appropriate) if a site is to conform to law.

The argument for dropping support for longdesc I found to be most disconcerting is the following:

The weakest proposal was the one that makes longdesc conforming but with a warning. The primary rationale given for this proposal was that a few sites may be using longdesc properly. Many of the objections to both of the other proposals also apply to this one. Additionally, there was a strong argument which is unique to this proposal: if longdesc is conforming, user agents will be required to support it; if there is a validator warning, users will be discouraged from using it. This combination is the worst of all possibilities. Eliminating this proposal early made the process of coming to a resolution simpler.

The existence of implementations was found to be a weak argument for inclusion, the quantify of bad data was found to be weak argument against inclusion. External references (standards, laws, etc) was also found to be a weak argument for inclusion.

The strongest argument against inclusion was the lack of use cases that clearly and directly support this specific feature of the language. The fact that longdesc has little observable uptake amongst users reinforces this: all the evidence indicates that users don’t see this feature to be compelling, and the lack of user demand has been noticed by implementors.

This entire section is extremely confusing, for multiple reasons. The first is that the section is describing what happens when a component of a language is deprecated—a concept that has been successfully utilized in technology for as long I can remember. The whole purpose of deprecation is that an element that has been previously supported is no longer, suddenly, not supported. The sudden cessation of support of an element between two releases of a language, library, or API causes confusion, as well as potentially introducing a great deal of breakage as people advance their applications from the older language or library, to the new.

In a mature, thoughtfully designed language or library, what happens, instead, is that the element is supported in the next version of the language, but a warning is given about its use. The warning instructs the user that they may use the element this one last time, but support for the element will most likely be pulled in a future version of the language, or application. The warning should also inform the individual about the preferred approach to take in the future. The use of deprecation ensures that people can gracefully advance their applications to the new release, and still have time to modify existing uses of the previously supported elements.

So the fact that the one of the proposals recommended deprecating the element rather than just making it suddenly obsolete, was considered a weak argument leaves one to wonder: what could possibly be a strong argument?

Of course, one of the primary problems with deprecation in HTML5 is the fact that deprecation isn’t supported in HTML5. No, we now have the new concept of obsolete, but conforming. Whereby deprecation is long known to be a way of gracefully moving a people from the use of one component to another more preferred approach, obsolete but conforming seems to be a way of saying—well, frankly, I don’t know what it’s supposed to be saying. Something profound and extremely clever, I’m sure.

Another reason I found the earlier quote from the co-chair decision to be confusing is that the existence of external laws and standards requiring support for longdesc is also considered a weak argument.

In what world, my friends?

To disdain external standards, not to mention government mandates, is extremely arrogant and incredibly short sighted. It is as if the HTML WG is attempting to undermine the credibility of the W3C. I don’t believe this is the intent but is, instead, a by-product of the obsessive focus, in both the HTML WG and the WhatWG, on meeting the interests of only one group when it comes to determining what’s in HTML5: the browser companies. The so-called Implementers.

Though it is true the browser companies—Apple, Google, Opera, Microsoft, and Mozilla—need to be on board with whatever is released in HTML5, it should also be a given that the browser companies, themselves, should be interested in meeting the needs of their community of users—and this includes the accessibility community, in addition to web developers, designers, other tool builders, and so on.

The HTML WG co-chair decision was, frankly, poorly reasoned. That people will formally object is a given. That the formal objection will succeed is also a given because the W3C has no choice but to reject this decision. The W3C cannot afford to be so cavalier as to arrogantly pronounce itself above government and other organizational mandates. The browser companies may deem themselves to be above such consideration, but the W3C cannot be so short sighted, and thoughtless. The W3C also cannot possibly afford to undermine its own credibility by introducing conflicts between its own recommendations: to recommend longdesc in one of its documents, while, at the exact same time, making it obsolete in another. The whole point of deprecation is to prevent such anomalies from occurring.

Folly. Pure folly.

Categories
Writing

When last we spoke

When last I posted, I had planned on updating that post with W3C co-chair decisions on my other HTML5 issues. I wasn’t quite expecting to be here, over a month later, still waiting on decisions. Not sure what’s happening with the W3C HTML WG at the moment, other than I think the group is making like an iceberg.

Eventually the decisions will be posted. Since I have a good idea what the decisions will be, no need to continue waiting.

Other than watching pots boil, I’ve been slowly working on my first self-publishing book on HTML5. I say slowly, because I ended up drastically changing the focus of the book, and hence the table of contents.

Though I would love nothing more than to fill 150 pages with details about the various HTML5 exploits, in the end I felt that an exposé on HTML5 isn’t going to be all that useful. Cathartic, maybe, but not useful. On the other hand, I refuse to jump on the “Isn’t HTML5 just peachy keen!” bandwagon, either.

I had to find a delicate balance between HTML5 rant and HTML5 rah-rah. Once found, I then had to dig for actual HTML5 implementation experience, which is a lot more difficult than you would think, given the fooflah about HTML5.

I’m still wrestling with the new TOC, so I don’t have any early peeks, yet. One thing the book won’t have is a discussion about HTML5 the brand. For one, isn’t it time to let the Geolocation folks have a little of the spotlight, all on their own? For another, there’s been enough confusion about HTML5 without conflating a formally defined and delimited specification, with a marketing buzzword.

So in the book, I’ll talk about HTML5…and Web 5.0, and Ajax5, not to mention P2P5, as well as Cloud , and throw in a little DHTML5, for good measure.

Categories
HTML5 Specs W3C

HTML5 Issue decisions

I did hear back from HTML5 co-chairs on my issues, and one of the decisions, on Issue 93, was just published.

No surprises, the decision was to keep the element. I’ll update this post with the status of the other issues as the decisions are published.

Issue 93: