Categories
Semantics

Pinky and the Markup Brains

What ended up being the ultimate irritation of my brief foray into HTML5 land, is that I found out, after careful perusal of my original use of RDFa, that I wasn’t using it incorrectly. However, by the time I got through listening to all the arguments, back and forth, and round and round, I was beginning to doubt whether an angle bracket really looked like < and >. I am correct, aren’t I? These are angle brackets, right?

Of course not. I call them angle brackets, but others call them diamond brackets, and I’m sure someone else, most likely from the UK, calls them elbow brackets or the Queen’s brackets, or some such thing.

However, the back and forth, and round and round, wouldn’t be an issue, could even be a journey of discovery, if it weren’t for the arrogance of some of the participants. Or, what I perceive to be arrogance. Variations of, “But that’s wrong and here’s why”, followed up with references to other specifications that hurt, actually physically hurt just to look at, given in a tone of, “How could you think otherwise?” Or responses based on some absolutely obscene piece of markup minutia, repeated over and over again, in attempts to hammer the point home to we, the seemingly dense as bricks.

The end product of such discussions, though, is that people like myself flee the discussion—literally flee, as if the hounds of hell were chomping at our butts. The downside of running away, though, is we’re left feeling that we have no input, no control over what the web of the future will, or will not, allow. That the web of the future of the web is designed by and for the web designers, and not thee and me.

The real problem, though, has less to do with communication style, and more to do with differing levels of expertise and interest. People like me, who are consumers of specs, are mixed in with people who create the parsers and the browsers, and live and breath, eat and sleep this stuff. What else can we, the consumers, do, though? There seemingly is no way for those of us, on the dumb side of markup, to communicate our concerns, wishes, and desires to the other side. But when we do venture into the lists, we are quickly overwhelmed with the specs, the references, the minutia. Our interests get lost in the fact that we don’t have the language to participate. Worse, we don’t have the language to participate in a field notorious for being both competitive, and impatient.

Unbeknownst to ourselves, we have become Pinky to the markup Brains.

So we consumers flee the lists and leave them to the developers and designers, and the end result is that we have specifications, and eventually implementations, that, well, frankly, scare the shit out of most of us.

Don’t believe me? How else could you explain the Yellow Screen of Death that appears whenever you make a simple mistake in markup for the post you’re writing? Not a helpful error, or an error that gently points out where and why the problem occurs; an error that tries to work with you to correct the problem.

No, it is an ugly error, an angry error, with red on yellow, that screams, “Bad, Shelley! Bad”, before it invariably trails off to uselessness on the right side of the browser. You don’t think an actual person like you and me would have designed a specification that encourages this behavior, or a browser that implements it, do you?

The true irony, though, is when you do voice concerns, or criticism, you’re typically met with, “If you want something, you need to participate in the email lists working on the specifications”, and the cycle begins anew. Narf.

Categories
Writing

Breaking eggs

I 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.
Categories
SVG

The SVG Feed

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.

Categories
Just Shelley RDF

And with all that

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.

screenshot of Anne being an asshole

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.

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.