+1 Thomas Mortagne wrote:
Since i suggested it I'm +1 too :)
I did not sent the mail because i'm not a css expert and I wanted to have more input on that idea, and Dan is working on Box macro so it's his baby now ;)
On Mon, Jan 5, 2009 at 10:50 AM, Dan Miron <[email protected]> wrote:
Hi! I've been suggested the following:
"............................................................. I'm thinking of a modification on box macro [Sat Jan 3 2009 17:02:10] … currently when you extends it you can define the class: "code" in place of "box" for exemple [Sat Jan 3 2009 17:03:34] … the problem is that it means having two different css classes: box and code when the second one is basically a copy part of the first with some more things like monospace [Sat Jan 3 2009 17:04:27] … so I propose to change the box macro to add the cutom class in place of replace box class with it: class="box code" [Sat Jan 3 2009 17:04:37] … that way you will have in css: [Sat Jan 3 2009 17:05:00] … #xwikimaincontainerinner .box { margin: 1em 0; padding: 0 1px; overflow: auto; background-color: #F1F7FF; border: 1px dotted #555555; }
#xwikimaincontainerinner .code { font-family: courier, courier new, monospace; white-space: pre; } [Sat Jan 3 2009 17:05:10] … same for other macro extending box [Sat Jan 3 2009 17:05:41] … this is way cleaner and easier to change the graphical box for all box macros [Sat Jan 3 2009 17:05:44] … WDYT ? ..................................................... " Personally, I'm +1 for that, so if anyone has a different opinion, please let me know.
Dan Miron wrote:
Vincent Massol wrote:
On Dec 28, 2008, at 11:45 PM, Dan Miron wrote:
Vincent Massol wrote:
............................................................
> Reason: > The goal is to reuse the boxMacro in for implementing RssMacro, > Warning > and Error macros. The most complex of them being the RssMacro. So, > a RSS > feed should be rendered as follows: > --------------------------------------- > optional image (provided as an URL to an image stored outside the > wiki, > anywhere in the web) > > How do you implement this? If it's optional what happens if it's not specified?
Could you show us an example of using the macro?
Dan I was actually talking about the Box macro.
My question was: what's your design for providing an image to display or not. More specifically where can the image come from? If the answer is: from a document then I think it's too restrictive since we can have some images located in the skin on the filesystem for ex. Image the info, error and warning macros. I don't think their images should come from a document.
Thanks -Vincent
Well, I've just found out that for rendering the error and the warning macros we actually don't need to explicitly specify an image to be displayed, the icon which they show up is specified in their CSS sheets. Therefore, I'm thinking of letting the image come from an external URL only, in the Box Macro, in order to use it for the RssMacro. I've been suggested to allow wiki syntax for specifying the image, so if anyone still finds this useful, take these matters into account, please let me know.
Thanks, Dan
I'm willing to preserve the behavior of the old RssMacro as much as possible, except for the new syntax, of course. So, given the feed's URL, we check if it has an image or not. Then, we invoke the boxMacro, in which we pass as parameters the following: the title is the feed's title (i don't know whether there can be RSS feeds without a title, but in the assumption that there is no title, we don't place anything in this field), the image is the one we just picked before (if there is one, of course; if there isn't, we just don't put anything there). As for the body, for each article from our feed, we invoke again the boxMacro for building the "small boxes" in a similar manner, just like I described in the previous message.
For more details we can talk tomorrow when I get at the office.
> title (which can be a static text or a link to a web location > containing > the full news article) > > This should be optional.
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs