Mailing List Archive

Hi Bernard,

Am 23.09.2004 um 22:10 schrieb Bernard Quatermass:
> Having deployed trac in a number of places over the past few months I
> came across a need to make links more informative and since I had
> previously used the tool-tip library 'overlib' from
> http://www.bosrup.com/web/overlib/ I decided to integrate the two.

Does this do anything that the 'title' attribute of HTML links (and in
fact any other element) doesn't do -- except not looking native?

I would be in favor of adding support for setting the titles of links,
but don't see a reason for using something like 'overlib'.

Cheers, Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de

> Does this do anything that the 'title' attribute of HTML links (and in
> fact any other element) doesn't do -- except not looking native?
>
> I would be in favor of adding support for setting the titles of links,
> but don't see a reason for using something like 'overlib'.

Ah, yeah I meant to make this point too. On http://www.epitonic.com/
they make use of overlib and do some formatting in the popups (see "new
on epitonic") that titles wouldn't do. However, yes in general titles
are quite sufficient and are a better choice. They're a standard part
of HTML and are well supported by browsers, and can be handled
appropriately by alternate browsers (e.g. text-only or text-to-speech).
Adding support for link titles would be nice to have in Trac, and if
people want to use overlib I suppose they're quite free to use a custom
macro to do so.

--
Matthew Good <trac@matt-good.net>

Christopher Lenz wrote:

>
> Does this do anything that the 'title' attribute of HTML links (and in
> fact any other element) doesn't do -- except not looking native?

No, nothing at all to do with the title. But that wasn't my reason for
attempting to solicit help.

What I was after was some pointers or help with what I feel are two of
the most common issues that will be met by anyone attempting to create
macros, that of parsing the arguments, and of producing correctly
escaped output.

I feel it would help greatly with the creation of new macros if these
two areas could be addressed in a standard manner.

Consider a macro

[[Bodge(arg)]]

The handling in that case is fairly obvious, but things become a lot
more complicated once you consider variations like

[[Bodge(some arg,'and another', 'with a long one, containing commas')]]

or even

[[Bodge(arg,'oh,dear','with \' more fun" and, games','to)follow')]]

If there were some standard routine to call to deal with these
variations it would provide a clearer and more consistent approach to
macro use, and would provide a greater chance of cross-pollenisation
between published macros. It is unfair to require a person editing a
wiki page to know which variation in quoting syntax is required for a
given macro. The burden of the basic syntax is bad enough without
complicating by having different modules handle parameters in different
ways.


--
Bernard Quatermass.

> Christopher Lenz wrote:
>
> >
> > Does this do anything that the 'title' attribute of HTML links (and in
> > fact any other element) doesn't do -- except not looking native?
>
> No, nothing at all to do with the title. But that wasn't my reason for
> attempting to solicit help.

The point here was that overlib is overkill. If I write a link like <a
href="..." title="descriptive text">click here</a>, the "descriptive
text" will appear in a popup when I hover my mouse over the link. The
title attribute is actually permitted on any tag. It's a nice
standardized way of achieving the same effect as overlib, so it should
be the preferred way to get this functionality.

> What I was after was some pointers or help with what I feel are two of
> the most common issues that will be met by anyone attempting to create
> macros, that of parsing the arguments, and of producing correctly
> escaped output.

The function for escaping HTML is trac.util.escape().

> I feel it would help greatly with the creation of new macros if these
> two areas could be addressed in a standard manner.
>
> Consider a macro
>
> [[Bodge(arg)]]
>
> The handling in that case is fairly obvious, but things become a lot
> more complicated once you consider variations like
>
> [[Bodge(some arg,'and another', 'with a long one, containing commas')]]
>
> or even
>
> [[Bodge(arg,'oh,dear','with \' more fun" and, games','to)follow')]]
>
> If there were some standard routine to call to deal with these
> variations it would provide a clearer and more consistent approach to
> macro use, and would provide a greater chance of cross-pollenisation
> between published macros. It is unfair to require a person editing a
> wiki page to know which variation in quoting syntax is required for a
> given macro. The burden of the basic syntax is bad enough without
> complicating by having different modules handle parameters in different
> ways.

If you have a function to do this that you'd like to see added, submit
it and I imagine some people will be interested. However, for my
purposes split() has been sufficient.

--
Matthew Good <trac@matt-good.net>