Re: [xml-dev] Xlink Isn't Dead

["Alexander Johannesen" <alexander.johannesen@gmail.com>]

Hi,

> >Not sure I follow you here. What scripting tricks? What is the *trick*?

On 9/23/06, Ben Trafford <ben@prodigal.ca> wrote:
>          I mean this code on your site:
>          How much work went into creating the Javascript to display that sidebar?

Work for me? Little; copy and paste. Work for them? Who knows. But why
do you call this a "trick"? What's tricky about it? Not markup?
Neither is CSS.

>  Wouldn't it have been much nicer to simply say:
>          <flickrBar userID="93544306" />
> And have CSS do the rest by intelligent placing an embedded, "onLoad" link?

Why? By that you're placing arbitrary code in two places instead of
one. And what about translation rules for the markup of the badge?
CSS1|2 doesn't create markup, so you might be looking to things like
XSLT maybe or CSS3, which, in my personal opinion, is a poor way to
fiddle with content! Is moving the transformation out of the markup
and into the presentation layer a good thing at all, though?

> ><confused> Which part of "80/20 of linking" doesn't xhtml:href cover? </confused>
>
>          Actuation and display of anything beyond single, unidirectional links.

But that's assuming there's more than a 80% need for that, which is
what I'm asking; what is that assumption based on?

>          Examples:
>
>          A menubar link - one click gives you multiple choices.
> Sounds like a multi-ended resource to me!

Why? This problem could easily be solved through an embedded (in
browsers) JS object with multiple link support in it. We currently
solve it through custom JS, of course. I know what you're suggesting,
though, but it could be as easy as <a href="http://somewhere
http://somewhere-else http://another-place";>...</a>

>          Embedding dynamic content into a document - like your Flickr sidebar.

Not sure I follow you here. You want something generic and dynamic
which isn't a generic and dynamic programming language? Why is your
CSS version better than a JS version?

>          When we think of rendering links, we need to think beyond
> "click and you go there," and we need to think beyond <a>. When
> defining where the 80/20 is on links, we need to look at how
> resources are being used today -- not how <a> links are being used,
> but <img>, <object> and more to the point, the host of scripting
> tricks commonly used on the Web.

Well, you don't need to convince me about where we should take links
in general, but in practice I think only automatic parsing benefits
from all the extra work that would go into it, and hence, since the
successful web is built by lazy people, I don't see it happening that
way. If we're to make systems that works best for automata, let's not
hide it in human forms, I'd say. But I fear I just don't understand
what you're trying to say, so there you go ... :)


regards,

Alex
-- 
"Ultimately, all things are known because you want to believe you know."
                                                         - Frank Herbert
__ http://shelter.nu/ __________________________________________________