Saturday, December 29, 2007
Niall's Suggestion
Niall Kennedy gave a great suggestion in the comments about using HTML's standard BLOCKQUOTE and Q tags along with the 'cite' attribute for Purple Include. Modifying what he suggested a bit, this is what it would look like:
<q cite="http://codinginparadise.org/paperairplane#quote(Start of range...End of range)"></q>
He also provided a test page that showed some of what he was thinking (BTW, he ran into a known bug in Purple Include where if you include something from the same page twice the second time you just see the spinning icon -- I need to fix this).
Niall suggested using the 'title' attribute to hold the span; I want to keep the full address in the URL 'cite' attribute however for several reasons. One, it really is a full URL: the anchor at the end actually specifies a range within the document. Just as everything to the left of the anchor specifies a given file/resource to grab, everything after the anchor is an infile-address.
This will become more clear in later iterations as I tie this into granular addressability where you can "jump through" the quote into the larger document, causing the browser to scroll to this quoted text; creating "out-of-band" links where you can annotate and create links inside a document without having to change it even while someone is looking at it by specifying the ranges of where the links should be; and other fun hypertext geekiness/madness.
Alot of this hypertext work is just to have fun and see how far we can push the hypertext model on the web, finding out what stands and can be useful and what falls over, similar to how I was pushing Ajax in wierd/new directions around history, storage, offline, etc.
Soon I'll roll Niall's suggestions in and remove the 'href' attribute I was using before. Thanks for the great suggestion Niall!
<q cite="http://codinginparadise.org/paperairplane#quote(Start of range...End of range)"></q>
He also provided a test page that showed some of what he was thinking (BTW, he ran into a known bug in Purple Include where if you include something from the same page twice the second time you just see the spinning icon -- I need to fix this).
Niall suggested using the 'title' attribute to hold the span; I want to keep the full address in the URL 'cite' attribute however for several reasons. One, it really is a full URL: the anchor at the end actually specifies a range within the document. Just as everything to the left of the anchor specifies a given file/resource to grab, everything after the anchor is an infile-address.
This will become more clear in later iterations as I tie this into granular addressability where you can "jump through" the quote into the larger document, causing the browser to scroll to this quoted text; creating "out-of-band" links where you can annotate and create links inside a document without having to change it even while someone is looking at it by specifying the ranges of where the links should be; and other fun hypertext geekiness/madness.
Alot of this hypertext work is just to have fun and see how far we can push the hypertext model on the web, finding out what stands and can be useful and what falls over, similar to how I was pushing Ajax in wierd/new directions around history, storage, offline, etc.
Soon I'll roll Niall's suggestions in and remove the 'href' attribute I was using before. Thanks for the great suggestion Niall!
Labels: purple include
Comments:
Links to this post:
<< Home
Hmm, I'm not sure that's what cite or q should be used for.
I'd recommend just adding a src attribute to your HTML tags. That would be consistent with the semantics of src (i.e., inlining external content) on existing elements that support it, such as script and img.
Sure it won't validate today, but doing something just to be structurally valid (and pass parsers) while still being semantically invalid (and thus fooling parsers) isn't really a win.
You may also want to bounce this off of Ian Hickson and the rest of the WHATWG HTML5 list and see what they think.
I'd recommend just adding a src attribute to your HTML tags. That would be consistent with the semantics of src (i.e., inlining external content) on existing elements that support it, such as script and img.
Sure it won't validate today, but doing something just to be structurally valid (and pass parsers) while still being semantically invalid (and thus fooling parsers) isn't really a win.
You may also want to bounce this off of Ian Hickson and the rest of the WHATWG HTML5 list and see what they think.
Hey.
If you could add a CSS class to this I will try to add support for this to Spinn3r.
They you can point out that it's used by some BIG companies for their crawl data.
The opportunity here is that while Javascript is only client side if you have enough include semantics in the markup robots can perform the same includes internally.
Onward!
If you could add a CSS class to this I will try to add support for this to Spinn3r.
They you can point out that it's used by some BIG companies for their crawl data.
The opportunity here is that while Javascript is only client side if you have enough include semantics in the markup robots can perform the same includes internally.
Onward!
@dewitt: Hi! Great to see you here :) Hope your New Years holiday is going well.
I have to disagree about the not using the Q and BLOCKQUOTE tags. I think Niall's suggestion is a good one, not because I believe in semantic purity (I actually dislike the XHTML cargo cult in general), but because it makes sense. Those tags already have a 'cite' attribute that gives a URI of what you are citing. URIs can specify not just full documents, but fragments and ranges as well (basically everything after the hash mark).
The one problem I see is that if we use BLOCKQUOTEs and Qs then we don't have a way to differentiate these from the ones that you want to have be 'live' and do a Purple Inclusion. Any thoughts? There are some different possibilities:
* Have a special 'class' attribute. I'm not a huge fan of using the 'class' attribute for such things, but it is pragmatic
* Have a new attribute, embed="true".
* Be XLinky about things and have a show="embed" attribute.
Best,
Brad
I have to disagree about the not using the Q and BLOCKQUOTE tags. I think Niall's suggestion is a good one, not because I believe in semantic purity (I actually dislike the XHTML cargo cult in general), but because it makes sense. Those tags already have a 'cite' attribute that gives a URI of what you are citing. URIs can specify not just full documents, but fragments and ranges as well (basically everything after the hash mark).
The one problem I see is that if we use BLOCKQUOTEs and Qs then we don't have a way to differentiate these from the ones that you want to have be 'live' and do a Purple Inclusion. Any thoughts? There are some different possibilities:
* Have a special 'class' attribute. I'm not a huge fan of using the 'class' attribute for such things, but it is pragmatic
* Have a new attribute, embed="true".
* Be XLinky about things and have a show="embed" attribute.
Best,
Brad
@burtonator: Hey, that would be cool to get this into Spinn3r. I should put together a super-simple one page specy kind of thing for you to lean on. I'll put together a straw man proposal on here.
@burtonator: I proudly give you a straw man Purple Include spec for you to crunch on, available here: http://codinginparadise.org/weblog/2007/12/straw-man-proposal-for-purple-include.html
Post a Comment
Links to this post:
<< Home
Subscribe to Posts [Atom]
