28 Mar
2011
28 Mar
'11
4:11 p.m.
On Mar 28, 2011, at 3:51 PM, Luca Anca wrote:
On Mon, 2011-03-28 at 15:32 +0200, Vincent Massol
wrote:
Layouting is different from styling for me. Container macro is mostly about layouting.
On Mar 28, 2011, at 3:22 PM, Luca Anca wrote:
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. On Mon, 2011-03-28 at 14:02 +0200, Vincent Massol
wrote:
We might not even need those params since they're already supported by using block
parameters...
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 :), 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.
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).
(% style="..." %)(((
{{container}}
....
{{/container}}
)))
Note: that's before we add block param support for macros directly (shortcut):
(% style="..." %)
{{container}}
...
{{/container}}
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. and make those configurable (they're not,
for
the box).
We need the wysiwyg editor to support adding block parameters. 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...
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
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).
> _______________________________________________