Hi Johannes, On Mar 28, 2011, at 12:43 PM, jstoldt wrote:

Hi Vincent,

I disagree with deprecating the title parameter. I remember using it a lot for creating floating TOCs in the Wiki I built in the Company I used to work for. Removing the title parameter would require them to edit like 200 pages or so, which is really not desirable, IMO.

Can you explain why you need the title parameter and why my proposal doesn't address your use case? If you're talking only about backward compatibility then it's a different topic. BTW this is why it would be deprecated and not removed. Please keep separate the 2 topics: * what we want to have * how we support existing users

Speaking of which, it might actually be very nice to have a parameter in the TOC macro that displays the TOC in a floating box. Best if it would be possible to display it floating either left or right.

See http://jira.xwiki.org/jira/browse/XRENDERING-61 Thanks -Vincent

Regards, Johannes

On Mar 28, 2011, at 1:53 PM, Luca Anca wrote:

On Mon, 2011-03-28 at 11:59 +0200, Vincent Massol wrote:

...

Hi devs,

I'd like to modify the Box macro in the following manner:

* Deprecate the "title" parameter. I don't believe it's needed right now (it's put below the image and before the content) since it can simply be put in the content

Image too can be put in the content, even positioned in all the ways. I'm not convinced that image makes more sense than title.

Indeed you're right. Example: {{box}} image:icon:tick text here {{/box}}

I'm 0 but I'm still to develop a full opinion about this macro. FTM it feels it needs a bit of work to define the usecases (I mean besides our own macros that extend it), to see how it makes sense for the user. From my pov, not in this way (remove title and improve image support).

Right now I'd be in favor of dropping also the image parameter (again not talking about backward compat here). Any use case where we'd need image or title params? Thanks -Vincent

Thanks, Anca

...

* Add a new parameter for positioning the image with respect to the content. Possible values would be: top (ie before the content) or left (ie left of the content), possibly some others if we want (right)

WDYT?

Thanks -Vincent

PS: Note that one use case I have is to implement http://jira.xwiki.org/jira/browse/XE-723 where I'd like the image to be aligned with the text, left to it. I also find it a bit strange to be able to add any wiki content to the title and I don't see the title as necessary. Also right now if you have a title but no content the macro doesn't work (content is mandatory).

On Mar 28, 2011, at 3:22 PM, Luca Anca wrote:

On Mon, 2011-03-28 at 14:02 +0200, Vincent Massol wrote:

...

On Mar 28, 2011, at 1:53 PM, Luca Anca wrote:

...

On Mon, 2011-03-28 at 11:59 +0200, Vincent Massol wrote:

...

Hi devs,

I'd like to modify the Box macro in the following manner:

* Deprecate the "title" parameter. I don't believe it's needed right now (it's put below the image and before the content) since it can simply be put in the content

Image too can be put in the content, even positioned in all the ways. I'm not convinced that image makes more sense than title.

Indeed you're right. Example:

{{box}} image:icon:tick text here {{/box}}

...

I'm 0 but I'm still to develop a full opinion about this macro. FTM it feels it needs a bit of work to define the usecases (I mean besides our own macros that extend it), to see how it makes sense for the user. From my pov, not in this way (remove title and improve image support).

Right now I'd be in favor of dropping also the image parameter (again not talking about backward compat here).

Then we drop box macro and add border and background color options to the container macro :),

We might not even need those params since they're already supported by using block parameters... (% style="..." %)((( {{container}} .... {{/container}} ))) Note: that's before we add block param support for macros directly (shortcut): (% style="..." %) {{container}} ... {{/container}}

and make those configurable (they're not, for the box).

We need the wysiwyg editor to support adding block parameters.

Since, as we said before, there's not such a big difference between box and container. I think there is a mail about this on the dev list.

Indeed, that's a good option: we deprecate the current Box macro completely (100% backward compat preserved) and instead move to using the container macro. It's just that for end users using a box macro is more obvious than using a container macro IMO from a mnemotechnic POV. Thanks -Vincent

Thanks, Anca

...

Any use case where we'd need image or title params?

Thanks -Vincent

...

Thanks, Anca

...

* Add a new parameter for positioning the image with respect to the content. Possible values would be: top (ie before the content) or left (ie left of the content), possibly some others if we want (right)

WDYT?

Thanks -Vincent

PS: Note that one use case I have is to implement http://jira.xwiki.org/jira/browse/XE-723 where I'd like the image to be aligned with the text, left to it. I also find it a bit strange to be able to add any wiki content to the title and I don't see the title as necessary. Also right now if you have a title but no content the macro doesn't work (content is mandatory).

On Mar 28, 2011, at 3:51 PM, Luca Anca wrote:

On Mon, 2011-03-28 at 15:32 +0200, Vincent Massol wrote:

...

On Mar 28, 2011, at 3:22 PM, Luca Anca wrote:

...

On Mon, 2011-03-28 at 14:02 +0200, Vincent Massol wrote:

...

On Mar 28, 2011, at 1:53 PM, Luca Anca wrote:

...

On Mon, 2011-03-28 at 11:59 +0200, Vincent Massol wrote:

...

Hi devs,

I'd like to modify the Box macro in the following manner:

* Deprecate the "title" parameter. I don't believe it's needed right now (it's put below the image and before the content) since it can simply be put in the content

Image too can be put in the content, even positioned in all the ways. I'm not convinced that image makes more sense than title.

Indeed you're right. Example:

{{box}} image:icon:tick text here {{/box}}

...

I'm 0 but I'm still to develop a full opinion about this macro. FTM it feels it needs a bit of work to define the usecases (I mean besides our own macros that extend it), to see how it makes sense for the user. From my pov, not in this way (remove title and improve image support).

Right now I'd be in favor of dropping also the image parameter (again not talking about backward compat here).

Then we drop box macro and add border and background color options to the container macro :),

We might not even need those params since they're already supported by using block parameters...

Then we remove container at all. The whole idea with the container, at least my idea, is to make it easy _for the user_ to do decoration of some content.

Layouting is different from styling for me. Container macro is mostly about layouting.

Since you cannot set these parameters from Wysiwyg, I'd say we still need a macro to do that. By this rationale we wouldn't need layout either for container either, and I think we all agreed when we added that.

...

(% style="..." %)((( {{container}} .... {{/container}} )))

Note: that's before we add block param support for macros directly (shortcut):

(% style="..." %) {{container}} ... {{/container}}

...

and make those configurable (they're not, for the box).

We need the wysiwyg editor to support adding block parameters.

Even so, I'm not sure a generic mechanism can provide the normal dumb (sorry for the rough word) users a handy enough tool to do that.

Well it's needed for all the other block elements so it wouldn't be different... Nothing prevents the WYSIWYG editor to have a specific custom editor when it finds known parameters such as: html:class html:style etc Actually if you select a block in the wysiwyg and set a color for it (for ex), I'm pretty sure the wysiwyg already uses block parameters so this wouldn't be different: * select the macro * click on the color toolbar button The only harder is when you want to use advanced non visual parameters such as "class" but in this case the wysiwyg editor can have a button to add other params and it can even provide a list of known parameters in addition to allowing the user to enter new ones. You mention border, the wysiwyg editor could offer a border button or a "known style" (as marius has added in 3.0).

E.g. if they want to set border, they need to know css, right? to write a style parameter and inside it, rules for the macro border. Or editing it in wysiwyg means a full visual css editor? If so, I think it's a bit too much...

...

...

Since, as we said before, there's not such a big difference between box and container. I think there is a mail about this on the dev list.

Indeed, that's a good option: we deprecate the current Box macro completely (100% backward compat preserved) and instead move to using the container macro.

It's just that for end users using a box macro is more obvious than using a container macro IMO from a mnemotechnic POV.

We can keep box, I don't mind. We just implement it as a shortcut for container with some parameters (border & bgcolor).

All I would want from this is a clearer relation between box and container, and a more clean/clear box macro.

Indeed we need to brainstorm more and clarify this. IMO the need for a box macro (or container or whatever you want to name it) is to prevent the user from having to specify a technical class name. However it doesn't mean that if the user has to configure more the behavior he has to use macro parameters. He could use block parameters instead. It's a choice and we need to decide if we want to include styling in macro parameters or in block parameters. Advantage of block parameters is that they'll work consistently across the board for all macros whereas macro parameters need to be defined for each macro and each macro has to have code to support them (ie read them and do something with them). Thanks -Vincent

...

Thanks -Vincent

...

Thanks, Anca

...

Any use case where we'd need image or title params?

Thanks -Vincent

...

Thanks, Anca

...

* Add a new parameter for positioning the image with respect to the content. Possible values would be: top (ie before the content) or left (ie left of the content), possibly some others if we want (right)

WDYT?

Thanks -Vincent

PS: Note that one use case I have is to implement http://jira.xwiki.org/jira/browse/XE-723 where I'd like the image to be aligned with the text, left to it. I also find it a bit strange to be able to add any wiki content to the title and I don't see the title as necessary. Also right now if you have a title but no content the macro doesn't work (content is mandatory).

---

Am 28.03.2011 14:14, schrieb Vincent Massol:

IMO we should also deprecate the "cssClass" and "width" box macro parameters.

If the user wants to use a different class or width he can use:

(% class="..." style="width:..." %){{box/}}

or for standalone (before we add a shortcut in the parser, see http://jira.xwiki.org/jira/browse/XRENDERING-75):

(% class="..." style="width:..." %)((( {{box/}} )))

Thanks -Vincent

Hi, my experience is that many macros behave different, when you apply a style: (% class="..." style="width:..." %) {{somemacro/}} As far as i remember its not always enclosed in a <div></div> It would be nice if all *rendering* macros behave in the same consistent manner. Wouldn't it be a better solution if all rendering macros support (at least) a basic set of common parameters ? e.g. 4 html core attributes (class, id, style, title): http://www.w3schools.com/tags/ref_standardattributes.asp Macro implementation should apply those parameters always to the first html markup generated. This would imo make it easier to apply custom styling in a consistent way. btw, Its often a surprise to me how (% ... %) renders. You can highlight one individual header: (% class="highlight" %) = my highlighted header but you can't highlight an item in a list of items the same way: * item * item (% class="highlight" %) * not highlighted - sigh :( bye Andreas

Vincent, could you please clarify ? Your response left me in a state of confusion.

Not exactly.

Block parameters for standalone macro is not supported right now, you need to write:

(% .... %)((( {{macro/}} )))

Is it true when using this group syntax the macro is supposed to *always* enclose its content in a <div> ? If not what is the exact definition of when to enclose it in <div> ?

If you write

(% ... %){{macro/}}

then you're creating an inline macro.

Using this syntax (is inline==standalone ? ) (which is not yet supported if I understand you right ) I might pass parameters to that macro but which parameters the macro supports depends on the macros programmers decision. (there is no common set supported) Right ? thanks for clarification Andreas