cite workfunction makeCiteWork(){
// this really should be done with XBL, but whatever
// the links generated here also violate several accessibility requirements
var i, bq = document.getElementsByTagName('blockquote');
for(i = 0; i < bq.length; i++){
if(bq[i].cite != "")
bq[i].innerHTML += "<p class=\"source\"><a href=\"" + bq[i].cite + "\" title=\"Visit source\">➔</a></p>";
}
bq = null;
return false;
}
Bonus points for the XBL implementation. Additional bonus points for meeting the accessibility requirements. Although when this is done in XBL that is no longer an issue anymore I suppose. (On error handling contains some (nested) examples of usage.)
If anyone questions my usage of application/javascript: RFC 4329 baby!
There is a (GPLed) User JavaScript for enhancing blockquotes that does what this script does, and then more.
Nice, but why do you use innerHTML instead of DOM-methods? And you should definately use getAttribute instead of .cite.
Do you have a link to that RFC? The closest I can find is a note that the draft was approved.
Chris, using the cite DOM attribute is perfectly fine. See the HTMLQuoteElement interface. Using innerHTML is just so much more convenient than using DOM methods for this and it’s about to become standardized so I don’t really see a problem there either.
Milo, the RFC number has been assigned already. It will most likely be published this month. See this Google search for documents that point to it. Where “it” equals the version most likely being published this month.
Everything old really is new again... here's
:)
Chris, innerHTML has better browser support. And is just easier.
Welcome to the large crowd Anne. :P
Frenzie, yeah, this was really about application/javascript of course. Or perhaps I should switch to application/ecmascript. Haven’t decided yet. And because I would like to see an XBL implementation of it, but given that I am in some W3C working group (more on that later I hope) that does something with XBL perhaps I should do it myself…
I did this a long time ago: http://wargers.org/home.hccnet.nl/bookmarklets/blockquote.htm xbl file: http://wargers.org/home.hccnet.nl/bookmarklets/linkcite.xml Not really sure why I did it in such a strange way, using the xul:description element. Why do I need to put everything in p-tags, just to make a comment?
I did the same thing using XSLT (http://tetlaw.id.au/view/blog/more-mojo-from-spring-cms/). However I decided to place the source link immediately proceeding the blockquote to preserve the notion that the text inside the blockquote was the exact quoted text.
I also used the title attribute of the blockquote to create the link text for the source link.
I know of the advantages of innerHTML, but it's still a bit of a hack to insert elements into the DOM that way. I won't argue that it's in most cases far more convenient.
Chris, using the
citeDOM attribute is perfectly fine. See theHTMLQuoteElementinterface.
In the same document, they also say:
The attributes are exposed as properties for compatibility with DOM Level 0. This usage is deprecated because it can not be generalized to all possible attribute names for XML. We recommend the use of generic methods on the core Element interface for setting, getting and removing attributes.
But to be quite honest, I didn't read the whole document, so correct me if I'm wrong.
The part about it being deprecated is more or less superceded by HTML 5. They are convenient ways to get and set attribute values. Regarding innerHTML, if that would be the case a normal file containing some XML or HTML could be considered a hack as well. It is just some other form of serialization, in my humble opinion.
the "javascript bible" to the rescue (David Flanagan, _JavaScript, the Definitive Guide_, 4th edition), page 294:
The innerHTML property is particularly useful when you want to insert large or complex chunks of HTML text into a document. For simple fragments of HTML, using DOM methods is more efficient because no HTML parser is required. Note that appending bits of text to the innerHTML property with the += operator is usually not efficient.
if w3 dom methods require no HTML parser, i'm confused as to why ppk's stats show how much slower implementations are with it: Benchmark - W3C DOM vs. innerHTML.
and is innerHTML an accessibility issue? see Avoid document.write() and innerHTML() (from draft: Client-side Scripting Techniques for WCAG 2.0, 2.2 Dynamic content generation).
-p
XBL?
By the way, as you only put an <abbr> element without title around your ‘XBL’ abbreviation, I couldn’t really tell whether you meant Mozilla’s Extensible Binding Language, or W3C’s XML Binding Language. As the latter does not really have an implementation, I assume you meant the first :).
~Grauw
if w3 dom methods require no HTML parser, i'm confused as to why ppk's stats show how much slower implementations are with it: Benchmark - W3C DOM vs. innerHTML.
With innerHTML the JS/DOM boundary is crossed once for the whole table and the parsing plus tree generation runs as native code. With the DOM methods the JS/DOM boundary is crossed twice times per element.
and is innerHTML an accessibility issue? see Avoid document.write() and innerHTML() (from draft: Client-side Scripting Techniques for WCAG 2.0, 2.2 Dynamic content generation).
My bogometer is twiching. Perhaps you can make a non-tree DOM in Trident using innerHTML. I have not tested. However, in Gecko and WebCore (and in Presto, I would expect), any result produced by innerHTML could be produced using the DOM methods as well.