Categories
Specs

Best of luck finding a suitable employer

Roger Johansson

I believe having more content creators and ”authors”, i.e. web designers and web developers, in the HTML Working Group would be good. Unfortunately I think it’s hard to find web professionals who can spare the time unless they get paid to participate. I know I can’t.

When I mentioned something virtually identical to Ian Hickson, he told me

I am sorry you feel that you need to be compensated for your participation in the standards community, and wish you the best of luck in finding a suitable employer.

Can’t wait to read Ian Hickson telling Roger Johansson, “…best of luck in finding a suitable employer.”

Categories
Specs

IE’s compatibility view

There’s been a lot of confusion about IE8’s compatibility view. To address the confusion, the IE Blog posted a note to clarify how compatibility view works. I think the site did a good job laying all the variations, though I’m not necessarily overjoyed about Microsoft’s decision to create a list of sites that are IE7 compatibility view, by default.

To see which sites will be displayed in IE mode, rather than standards mode, type the following into the IE address bar:

res://iecompat.dll/iecompatdata.xml

Netflix, Forbes, CNN, several Google sites in various countries, SF Gate, Facebook, microsoft.com…there are a significant number of sites in “compatibility view”. I appreciate that Microsoft is holding on to a tiger that is currently biting its butt, but protecting sites that need to update just keeps crappy stuff around that much longer.

For those sites not on the list, you can click a button on the toolbar to view it in compatibility view. However, the button will not display if the site uses a meta element to specifically say the site is IE8 standards compatible. If you access most of my sites with IE8, you won’t see the button. If you do, it’s only because I’ve forgotten to add the meta tag— my sites all work with both IE7 and IE8. IE6, too, but rather plainly.

I wish we didn’t have these browser version games, as they limit the advances we can make on the web. The IE compatibility view reminds me of the recently approved US DTV switch delay: they penalize the prepared and reward the procrastinator.

Categories
Diversity RDF W3C

The intent speaks louder than words

Recovered from the Wayback Machine.

I was thinking about taking a shot at writing my own use case or use cases for RDFa in HTML5 until I spotted the recent entry at Last Week in HTML. The site posts an excerpt from an IRC discussion related to the ongoing exchange about RDFa and HTML5.

* hsivonen is surprised to see Shelley Powers use a pharse like ” most pedantic specification ever derived by man”
hsivonen: (the “by man” part)

annevk: hsivonen, what is special about that part?

hsivonen: annevk: she has a history of pointing out sexism, and expressions like “by man” where ‘man’ means humans in general are generally frowned upon by English-language feminists

annevk: oh, didn’t know that

Rather than respond to any of the arguments and concerns expressed in several comments at Sam’s, or my own long writings on the issue of RDFa and HTML5, the only part of my writing that’s mentioned or referenced in this ongoing discussion is the fact that I used the generic “Man”, to represent humankind.

Actually most English-language feminists aren’t necessarily uptight about the use of “Man” when used in the generic sense, such as in the common phrase, “known to Man”. Or, at a minimum, the use of this common phrase isn’t one of our more pressing concerns. We’re more uptight about our work, writings, and opinions being undermined via the use of irrelevancies. To the true feminist, intent means more than words.

So, to return to the use case: I could spend a considerable amount of time trying to recap the issues related to Qnames and CURIEs, technical concerns versus biases, and generate a longer, thoughtful use case, but unless I use a Word in it, or perhaps a humorous misspelling or funny use of grammar, the work would most likely be disregarded.

Categories
HTML5

HTML4 is to markup

In an interview at WebScienceMan titled, XHTML Users: Grow up!, the interviewee, Sitepoint’s Tommy Olsson answers a question as to whether he likes XHTML with, Grow up! 🙂 Seriously, XHTML is long dead, due to a decade of horrible abuse. Not even the bleached bones remain..

Mr. Olsson believes that we should be using HTML 4, strict HTML 4, because HTML5 is still a bit of whimsy, and XHTML is a pile of dead bones. As I wrote in comments, HTML 4 is to markup, like 8-track is to music.

8-track cartridge

Categories
HTML5

HTML5: Put up or shut up

Sam Ruby

I question the presumption implicit in the notions of “the” editor, and “the” spec. I reluctantly accept the notion that any individual spec development process need not employ processes requiring consensus or voting, but I reject any implication, however subtle, of inevitability or entitlement.

Simply put, there needs to be a recourse if a person or a group disagrees with a decision made by the editor of the WHATWG document. That recourse is forking.

I realize that that is a very high bar, and will say that is intentionally so. Simply put, specs don’t write themselves… I don’t care how good you think your idea is, either you need to step up and directly write the spec text yourself, or accept that you need to be persuasive.

Quite simply, that is the most absurd set of statements I have ever read. What Sam is saying, if you don’t like it, fork, or shut up.

Have to be persuasive? How can one be persuasive when there are underlying biases and prejudices in play that makes it impossible to ever…ever persuade the gatekeepers to change their mind? Or even open their minds?

So the alternative that Sam allow us, is to fork the entire HTML specification. Contrary to some people involved in this discussion, most of us are not employed by large corporations and can spend all of our time reading mailing lists or participating in specification work. Most of us have to do other things in order to pay the rent, or buy food.

But we are still dependent on the same specifications, still concerned that what comes out of a group such as the HTML5 working group is the best specification for as many people as possible—not just representatives from one or two companies who control the HTML5 specification development with a fist clad in an arrogance as dense as the thickest iron.

As for contributing to the group, the HTML5 editor did put something out, recently, on the mailing list about other editors. The requirements demanded for these voluteers were such that few of us could even consider applying. I can’t guarantee I have 20+ hours to devote every week. I can’t guarantee that I can fly to meetings with other editors, no, not even once a year. The most I, and others like me, can guarantee is that we would try our best, but keeping the roofs over our heads has to be our first priority. When was the last time the powers-to-be behind the HTML5 effort opened their windows and got a good whiff of our troubled times?

I also resent the assumption that those of us not directly contributing to the editing of a specification are not contributing. Contrary to what Sam seems to believe, we don’t need to be a member of a specification group, or an editor of a specification, to contribute to the overall success of the specification. People who write about the specifications, in books or articles, or who provide tutorials, example applications, libraries, help others—we contribute just as much as those who formally create the specs. The only difference is that our names don’t get listed, we rarely get credit, and evidently, according to Sam, we shouldn’t express any concerns, or frustrations, either.

Well, perhaps that is the way of the world for HTML5, but thankfully it hasn’t been that way for any other web specification I use, including XHTML, CSS, RDF, SVG, and so on. Oh, we still may not be able to influence these specifications, but I’ve not seen any of these groups give so much power over the direction of the specifications to so few. I’ve not heard once, from any of the people behind the specifications, to either put up, or shut up.