X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/7978216fb67c9b3c6cc40647f79f7e4a472fdb4a..c47839389abb8e21a94606a2c105e5c1ecf6ed32:/doc/todo/CSS_classes_for_links.mdwn?ds=sidebyside diff --git a/doc/todo/CSS_classes_for_links.mdwn b/doc/todo/CSS_classes_for_links.mdwn index df4d8fc4d..29ed3770e 100644 --- a/doc/todo/CSS_classes_for_links.mdwn +++ b/doc/todo/CSS_classes_for_links.mdwn @@ -32,4 +32,107 @@ for external links is enough for me :) Please look at my example: My best regards, ---Pawel \ No newline at end of file +--[[Paweł|ptecza]] + +> If you did not already know, you can achieve similar results using CSS3 +> selectors. Eg: `a[href="http://www.foobar.com/"] { foobar: css }` or +> `a[title~="Mail"] {text-decoration: none; }`. See +> for a complete list. + +>> Hi Charles, +>> +>> Thanks for the hint! I don't know CSS3 yet :) What modern and popular +>> WWW browsers do support it now? +>> +>>> Safari supports it. Firefoz&Co support most of it. IE6 did not, but IE7 +>>> supports a fair part of CSS3, ans is said to support selectors. +>>> +>>> Example on how to use selectors here: http://www.kryogenix.org/days/2002/08/30/external +>>> +>>> I also think this should be in an external plugin, not in ikiwiki. +>>> + +I find CSS3 support still spotty... Here are some notes on how to do this in IkiWiki with jQuery: --[[sabr]] + +> If you need to achieve this in IkiWiki itself, I imagine you could create a +> plugin which runs in the `format` phase of rendering and search/replaces +> specific link patterns. This should be a fairly simple exercise in regular +> expressions. +> +> --CharlesMauch + +>> I've never written plugin for ikiwiki, but I can try if it's simple job :) +>> +>> --[[Paweł|ptecza]] + +> I wouldn't mind adding a _single_ css class to ikiwiki links, but it +> would have to be a class added to all internal, not all external, links. +> Reason is that there are many ways for external links to get into an +> ikiwiki page, including being entered as raw html. The only time ikiwiki +> controls a link is when an internal link is added using a WikiLink. +> +> (Note that tags get their own special +> [[rel_attribute|rel_attribute_for_links]] now that CSS can use.) +> +> --[[Joey]] + +>> I had a little look at this, last weekend. I added a class definition to +>> the `htmllink` call in `linkify` in `link.pm`. It works pretty well, but +>> I'd also need to adjust other `htmllink` calls (map, inline, etc.). I found +>> other methods (CSS3 selectors, etc.) to be unreliable. +>> +>> Would you potentially accept a patch that added `class="internal"` to +>> various `htmllink` calls in ikiwiki? +>> +>> How configurable do you think this behaviour should be? I'm considering a +>> config switch to enable or disable this behaviour, or possibly a +>> configurable list of class names to append for internal links (defaulting +>> to an empty list for backwards compatibility)> +>> +>> As an alternative to patching the uses of `htmllink`, what do you think +>> about patching `htmllink` itself? Are there circumstances where it might be +>> used to generate a non-internal link? -- [[Jon]] + +>>> I think that the minimum configurability to get something that +>>> can be used by CSS to style the links however the end user wants +>>> is the best thing to shoot for. Ideally, no configurability. And +>>> a tip or something documenting how to use the classes in your CSS +>>> to style links so that eg, external links have a warning icon. +>>> +>>> `htmllink` can never be used to generate an external link. So, +>>> patching it seems the best approach. --[[Joey]] + +>>>> I had a quick look to this issue. Internal links are generated at +>>>> 11 places in the Perl code and would need to be patched (this +>>>> number could be lowered a bit if a htmllink-like function existed +>>>> for CGI urls; such a function would use `cgiurl`, and be used in +>>>> most places where `cgiurl` is currently called by plugins). +>>>> +>>>> Also, more than 30 `` links appear in templates, most of those +>>>> being internal links. +>>>> +>>>> Sure, patching those few dozen places is trivial. On the other +>>>> hand, I'm wondering how doable it would be to make sure, on the +>>>> long run, any generated internal link has the right CSS class +>>>> applied. One would need to write tests running against the code +>>>> with all plugins enabled, all templates put to work, in order to +>>>> ensure consistency is maintained. --[[intrigeri]] + +----- +If you're going to be patching htmllink anyway, might I suggest something more flexible, like being able to configure the link format? +(Yes, PmWiki allows this, that's where I got the idea) +That is, rather than having "<a href=". blah . blah ... +one could use a sprintf with a default format which could be configured in the setup file. + +For example: + + $format = ($config{createlink_format} + ? $config{createlink_format} + : '?%s'); + return sprintf($format, + cgiurl(do => "create", page => lc($link), from => $lpage), + $linktext); + +I admit, I've been wanting something like this for a long time, because I dislike the existing createlink format... + +--[[KathrynAndersen]]