tag:blogger.com,1999:blog-15626356.post7734667431170665574..comments2012-10-17T10:09:12.903-07:00Comments on ecmanaut: Cooperating Greasemonkey scriptsJohan Sundströmhttp://www.blogger.com/profile/04076097346172610543noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-15626356.post-55284484816617864642008-02-25T06:31:00.000-08:002008-02-25T06:31:00.000-08:00They rather certainly don't, no. I think that your...They rather certainly don't, no. I think that your first gut reaction and mine was/is the same: for the sub-problem of marking up the next url, link[@rel~=next] is a perfect fit, and should be used.<BR/><BR/>That may indeed be true, and it <I>is</I> also what I presently do, both on the format producing and consuming sides, and time might even prove it a healthy design choice. First, I thought I would always get by on link[@rel~=next] aided by <I>two</I> meta tags, but then I found a possible, yet highly unlikely, case where I also needed the XPath expression used to find the next link. Half-catering that case may be over-engineering (says my gut feeling), but when choosing between a minimal, 100% new and 100% orthogonal microformat of three xpath meta tags only, and the 75% new one I implemented with two meta tags and a link, which, in an odd case, needs a third meta tag instead of (or beside) the link, instinct tells me the first one that caters all cases is the better design. The problematic case?<BR/><BR/>If page N is on domain A and page N+1 is on domain B, the same domain barrier prevents me from scooping out whatever data the microformat producers may have leveraged page N+1 with, yet due to some amazing stunts I pull in my <A HREF="http://ecmanaut.googlecode.com/svn/trunk/lib/gm/wget.js" REL="nofollow">wget lib</A>, I can still XPath scan it, and to find the next link, I then still need the XPath with which to do it, and that XPath must be known already on page N, so I can scoop up the next link myself, rather than delegating to producers to do it for me.<BR/><BR/>The present implementation does not make either choice, so you could consider it implementing both the minimal 3-meta standard, the also minimal yet only 95%(?) capable 2-meta+link[@rel~=next] standard, and the maximal, yet overlapping / bloated 3+1 standard. Producers of all three kinds (I think mine are all of the latter kind, though due to an oversight in one of my mini libs, were of the second kind the first hour after publishing), but nothing prevents 3rd parties from doing the minimal work only.<BR/><BR/>This is the slippery slope standards walk on their way to bloat and over-engineering that is mostly counter-productive and leads to the ugly cases where incomplete implementations (say, the 2+1 case, faced with the ugly cross domain problem) lead to complex breakage. I've seen it happen before, hence my realizing that I might actually prefer the 3-meta standard myself, despite not leveraging a good present standard practice (and the fact that I have no other consumers for the link[@rel~=next] standard at present subtracts from the potential value I might have of producing it, just in case, paying with slight producer bloat).<BR/><BR/>(That lesson about standards may be just as valuable as the other bits I describe in the post -- possibly even more so.)Johan Sundströmhttps://www.blogger.com/profile/04076097346172610543noreply@blogger.comtag:blogger.com,1999:blog-15626356.post-61632703620044415722008-02-25T04:54:00.000-08:002008-02-25T04:54:00.000-08:00Do any sites use your proprietary metatags by defa...Do any sites use your proprietary metatags by default? No? Then how does generating that help you over generating a|link[@rel~=next] ?<BR/><BR/>Why not use the standard for the applicable value and the METAs for the xpath, etc?Singpolymahttps://www.blogger.com/profile/14267910391550235126noreply@blogger.com