Category: Standards

Web and tech standards

Categories
Specs

RSS and disappointment

Recovered from the Wayback Machine.

I am disappointed.

I am disappointed that the work I did yesterday to show that RDF can work well within a simplified RSS environment is for naught because assumptions have already been made, decisions sealed. Jon Udell writes, paraphrasing Sam Ruby, Assuming that the RSS core is now frozen…. Why is there an assumption that the core is frozen? Why is there an assumption that Userland owns RSS 2.0? Because Dave Winer says so? Because a few – a very few– other people say so?

What of the community, who must continue to be faced with issues of two different RSS specifications; who will have to face the difficulties inherent with this again in the future?

I’m disappointed because assumptions have been made that the efforts of the RSS 1.0 working group and Userland can never merge. The result of this assumption is that those who wish to write or read RSS in the future must bear the burden of both groups lack of cooperation.

I am disappointed because we were starting to see such good questions from the user community — questions such as those that appeared in the comments attached to my postings. Questions that allow us to define why some of these issues are important to many of us. Questions and comments that serve to make technologists take a good hard look at what we arrogantly decide is ‘good’ for the community.

Both RSS groups have been working far too long in a vacuum, and this week the lid got popped and fresh air came in. And I have never seen groups, normally so diametrically opposed, work together so well as these two did this week, trying to put that lid back on as quickly as possible.

I am disappointed that the RDF working group didn’t join the debate and benefit from such an open discourse with the user community, in addition to taking this opportunity to clarify much of the confusion and complexity about RDF. However, the debate was so short, the working group may not even be aware that it happened.

 

 

 

Categories
Specs

RSS Summary

Recovered from the Wayback Machine.

Folks, to all intents and purposes both RSS groups are continuing along on their separate paths. Whether the RSS 1.0 group continues using RDF in their specification is an open question, which I hope they will resolve as this indecision leaves confusion in its wake.

I think the community loses by this divergence, but I have done all that I can to try and influence this and haven’t been successful. I will continue to answer questions about my interpretation of any of this, but won’t continue my direct efforts in this regard, not because I’m angry and am picking up my marbles and going home, but because I am going to need to focus my time on those things I can influence, such as making a living.

I did appreciate those questions about the use of RDF within the simplified RDF RSS 2.0 specification. Those were a treat, and I thank you. Please feel free to continue asking questions, privately, via email.

On to other things.

Categories
Standards

Alt attributes

Mark Pilgrim’s tip for today Providing text equivalents for images is one of the few tips that I do follow, or at least attempt for follow.

All of the images in this weblog should have a text equivalent.

Categories
Semantics Standards

Up, down, charm, strange, top, bottom

Recovered from the Wayback Machine.

The markup folks are going to be the weblogging death of me yet. It’s a variation on the classic differences between the back-end or server-side developer and the front-end designer/developer.

All front-end folks know that we back-end folks are slobs when it comes to proper markup, clean web pages, and so on. And all back-end folks know that the front-end people are anal (in the nicest possible way of course). And for a client, this is the perfect combination – the back-end folks should focus on their area of expertise – back-end development – and leave the front-end to the experts.

Of course, when a back-end developer has a weblog, then all you see is sloppy markup, improper use of tags, and so on. I know. Bad Me.

(Still, I know of a front-end person or two who has needed my help for back-end issues, but we won’t quibble over that, will we?)

I know I’m a markup slob, a hopeless case if there was one. However, in recent discussions, I’m left unsure if what I’m doing is “wrong” from a technical viewpoint, or only “wrong” from an esthetic viewpoint. In particular, I’ve been reading Dorothea’s and Jonathon’s weblogs about CSS style sheets, markup, use of bold for hypertext links and so on.

Am I wrong in my use of markup? Or is this a case of pure esthetic differences? Am I a slob? Or is Jonathon, as an example, being an effete snob (saying this in the nicest possible way, of course)?

For instance, there’s the sweeping statement that underline for hypertext links is ugly. Well, ugly or not, the underline has been used to designate hypertext links since the dawn of web time. And underline is still used, by default, to mark links.

In some of my web sites, I use bold to mark hypertext links; in others, such as this weblog, I use underline within the content, bold in the sidebars. I will admit the bold un-underlined hypertext links within the content is elegant and tasteful. However, though ugly, there’s no accessibility issue or problem with using underlines within the posting, is there?

(Side question: what’s with the blue/gray in all the weblogs lately? Is this a civil war thing?)

Today, another issue arose about emphasis and the strong, em, b, and i elements. Jonathon asked the question of Dorothea about the proper use of the <strong>, <em>, <b>, <i> tags. In response, Dorothea provided a very, very nice discussion of the history, purpose, use of these particular tags.

From Dorothea’s response, I believe I am using the strong element correctly. I use it when I want to bold something – when I want to make it more noticeable, to stand out, to strongly emphasis a point, a line, a statement. I tend to use the em element to emphasis something that I don’t want to stand out if a person does a quick sweep of the eye down the page.

However, I use the strong element specifically because it is bold, and the em element because it does result in italic text. I never use <b> or <i>. Though the result is correct, is my underlying behavior incorrect? What happens in this mix when a blind person reads the page?

Sigh. At this point, I am faced with two choices: I can spend all my time fretting on these issues; or I can work on ThreadNeedle, accept the fact that I’m a hopeless web page slob who will never have an elegant weblog page, and hope that folks like Dorothea and Jonathon will specifically let me know when I’m doing something that makes my material inaccessible, or makes it break within a browser.

Categories
Standards Web

Issues of accessibility

Recovered from the Wayback Machine.

Unless you’ve been living under a rock, you’ve probably heard about Mark Pilgrim’s Thirty Days to a more Accessible Web. The series covers basic steps we can take to make sure our weblogs and web sites are accessible.

His first tip is on DOCTYPES.

I tested my weblog against the 508 accessibility test at Bobby and according to the results, not necessarily trivially easy to read, I should meet this standard. However, I don’t meet the Web Content Accessibility Guidelines 1.0 standard.

Does anyone meet the Web Content Accessibility Guidelines 1.0 standard?

Once I’m settled, I’m enlisting the help of experts among my virtual neighbors (weblog translation – I’m whining, begging, and groveling for help because everyone knows I’m a back-end developer and know shit about front end stuff) to make sure my weblog and web sites are accessible.

If you have a weblog, don’t you have something to do about now?

(And once you’re done with that, move your tushie over to AKMA’s and give him some requirements and suggestions for Thread the Needle.)