BurningbirdI have an egg. A perfect egg. I am lost in admiration of my perfect egg. But I am hungry. I must break the egg. I break the egg. It is awful. Slimy, wet, with a bulbous yellow eye. And I am sad. But look! I have an omelet! A perfect omelet! I am lost in admiration of my perfect omelet. But I am still hungry. I must eat the omelet. I eat the omelet. It is good. But now it is gone, all gone, every bite. And I am sad.
I had originally created a Planet SVG in order to bring together a feed of SVG items. Once the SVG IG created Planet SVG web site, for all things SVG, I redirected planetsvg.org to it.
I still wanted a feed of SVG-related items, so I created the SVG Feed. Currently, the application queries SVG feeds once a day, including my own Delicious SVG-related feed. The latter was my way of ensuring that items related to SVG that aren’t accessible via a feed, or the related feed isn’t specific to SVG, get included.
The SVG Feed has it’s own feed, and uses Planet and Venus software. It only updates daily, as there are not enough items for more frequent updates. If you know of an SVG feed that should be included, send me an email.
And with all the unpleasantness this weekend, including a comment breaking my XHTML, captured for posterity by the playful, puckish, Anne, I find that I have misunderstood one key element of the RDFa specification, and have embarrassed myself greatly.
Why is every time I touch anything to do with the W3C or associated mailing lists, I always come away feeling like the idiot child who has just wasted the time of her elders? It has gotten to the point, where I don’t want to write anything about technology online.
Now, I have to re-visit my XHTML formatting for my comments, for yet another use case that is slipping through the filters.
update Another set of test cases bites the dust. I now have two modules, HTML Purifier and htmLawed implemented, in addition to the built-in URL converter and automatic line break functionality. The order these are implemented is important and the following seems to create a compatible effect: HTML Purifier, htmLawed, URL converter, line break. I’ll have to do other testing, but two particular use cases that came up yesterday—yes, two— both seem to be trapped with these changes.
second update Based on request from from the htmLawed creator, I attempted to reduplicate the original errors. One was quite simple: the use of <self-close /> caused the Drupal built-in HTML corrector to over correct, adding a </self-close >. I’m not sure why I had the built-in HTML corrector active, anyway, as it does conflict with htmLawed. Removing it removed the problem.
The second test case didn’t get corrected by htmLawed, when I tested with the original comment, so I added HTML Purifier. However, when I went to duplicate the test case, I couldn’t, so I had documented the test case for duplication incorrectly. I’ve since turned off HTML Purifier, and if the case occurs again, will leave it to show the htmLawed creator. It doesn’t hurt to use both modules, and I only use them with comments, but if I don’t need two, I’d rather not use two.
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.
I have spent too much time worrying about specifications managed by people who, frankly, don’t have a lot of respect for what I have to say. I am not a browser developer, specification author, nor do I fit within the narrow parameters of “people who are seen to be contributors”.
Years ago, I defined the term Coders-Only-Club, to designated the seeming feeling of being an outsider, unless one acts a certain way, or does a certain thing. I can definitely say unequivocally that writing books or weblog posts does not ensure entry into the Coders-only-Club, or perhaps I should term it, “Contributors-Only-Club”. To be honest, writing simple tutorials or examples, helping people, or answering questions doesn’t gain one entry, either.
What’s absurd about the whole thing is I’m fighting for something I don’t really need, because I do have viable alternatives I can use with my own work. I deliver every page at my web sites as application/xhtml+xml, which gives me singular power to accomplish wonderful things. I doubt, very much, that any browser is going to drop XHTML support for many, many years to com, so I can continue to incorporate SVG, or RDFa, or any number of new vocabularies that haven’t even been invented yet.
Frankly, I’m just wasting my time worrying about things I can’t change.