ArticlesDear Web,
I am having trouble getting my head around a new technology, and I just needed someone to take it through with, until I understand.
If I can explain my problem clearly, perhaps I will see the solution myself – or at least get the part of my brain that comes up with solutions in the shower to start thinking about it.
In the EmailShroud 2.0 plugin, I use a couple of non-standard attributes on the anchor tag.
While that means it doesn’t validate, I expect everyone’s browser to ignore the attributes they don’t understand; I was happy to deliver with that.
I didn’t even bother to fix it in EmailShroud 2.1 (currently being alpha tested on this site – let me know if you see any odd behaviour).
However, now I am looking at cleaning it up and ensure it exhibits nothing but pure validation goodness for the release after next.
Option 1
I could remove the use of custom attributes, and try to tunnel the same information through existing attributes, such as class or id. It might be possible to get this to mostly work, but it would be not The Right Thing™.
I need to weave some DTD magic here. Let’s get the incantations ready.
Option 2
I could reference the external DTD, and then add some extra attributes with an additional “Internal DTD”, i.e. add the extra attributes via incantations on each page.
This works in Opera, but Firefox and IE7 leave an unsightly “]>” mess at the top of the page. [Ref + testing] It seems odd that they both have the same bug – have I missed something here?
Option 3
I could find the original DTD for XHTML and modify it to include the new attributes. Then I could host it on SomethinkOdd, and have the plugin point to this DTD in the header of each HTML.
This idea has several flaws.
-
The plugin would need to locate the old value for the DTD in the page and insert the new one. WordPress’s architecture gives plugins many hooks to insert their own “filters” in the stream, to modify parts of the page (EmailShroud is built on this technology.) However, the DTD link is owned by the theme, I don’t believe it is passed through any filters before being sent out. Ergo, I would have to make the end-user modify their theme file manually if they wanted their page to validate.
Hmm…. I’ve just realised this would also impact option 2
- There are at least nine different public standard DTDs for web-pages [Ref], and I would need to support at least four of them (XHTML 1.1, XHTML 1.0 Strict, XHTML 1.0 Transitional, HTML 4.01 Strict). That’s starting to pile up. What’s more, I can’t assume that some other plugin isn’t making similar demands on the user. What if both plugins demand you change the theme?
- I do not want every EmailShroud-protected web-page to trigger a fetch of a DTD from my site. Too much bandwidth, too little revenue! So now I need to work out how to get the plugin to serve its own DTD files (feasible) and get the user to point to the right one (tricky).
- The W3C Validator will decline to validate DTDs outside the well-known public ones. [Ref] While it might be secretly well-formed, it will be hard to prove to people.
Put together, these flaws suggest to me that I am headed towards either a failure to deliver – or even worse – a successful delivery plus a world of pain in support.
Option 4
So what is option 4?
Comment by Alastair on April 8, 2007
Option 2 is clearly the way that XML/SGML geeks would intend you to do this. However, the spurious ]> characters are a problem. I understand that Firefox will render correctly for XHTML, *iff* the content is served with the correct MIME type, namely
application/xhtml+xml. However this brings its own problems and in any case doesn’t solve the ]> problem for IE.So perhaps the next best option is option 1. How about adding a level of indirection, through the id attribute? So instead of adding an attribute X to element A, you instead use a single associative array keyed on the ID attribute of A. In your javascript you get the ID of the current element, and look it up in the associative array to get the new attribute you’re interested in.
Does that make sense?
Comment by Julian on April 8, 2007
Alastair,
Excellent idea. I think we agree it’s not The Right Thingâ„¢, but it should be quite workable.
Looks like I am throwing XHTML onto the same pile as SVG, auto-feed discovery, web-colours, CSS markup and HTML headings.
Is there any web standard I like?
Comment by Aristotle Pagaltzis on April 8, 2007
I think you’re using a completely wrong approach here. All the information is already in the
hrefvalue you generate and it’s very easy to parse out in Javascript. There is no need for those custom attributes, much less for heavy-handed interventions like playing tricks the internal DTD subset.Off the cuff:
function Query(querystring) {
var pairs = querystring.split('&');
for(var i = 0; i < pairs.length; ++i) {
var kv = pairs[i].split('=',2);
this[decodeURIComponent(kv[0])]=decodeURIComponent(kv[1]);
}
return this;
}
Then the
onclickhandler then contains this somewhere:var param = new Query(this.href.replace(/^[^?]\??/, ''));And then it basically does its thing with
param.Comment by Julian on April 10, 2007
Aristotle,
I started to respond by saying I got your idea but there was a flaw. Not so much a flaw, as a wrinkle that made it more complex than it seemed. (EmailShroud doesn’t always output anchors tags. Sometimes it outputs “transformed” addresses) Then I thought of a solution to that complexity. Then another problem. Then another solution.
My point here is that my silence isn’t that I am ignoring you. It is that I am still weighing up the two approaches.
Thanks muchly for the suggestion!