After discussing with Anca and Marius, here's another potential  
solution:

* use (% param=value %) notation to set the params on the element  
following it
* use {% param=value %}... {%%} notation to create a span and thus set  
the params on whatever is inside it

This makes it consistent with block level params which are set on the  
next element.

We would still need to define the syntax for images.

Thanks
-Vincent

On Oct 27, 2008, at 10:59 AM, Vincent Massol wrote:

> Hi,
>
> There are 2 features I need to finish implementing for the new
> rendering and I have some doubts.
>
> 1) Parameters for links
>
> Problem
> =======
>
> We decided to use the (% param=value %)[[link]] notation. However this
> is raising some issues.
>
> First the user needs to close the parameter list so that it doesn't
> affect other elements coming after.
>
> For example:
>
> (% rel="_blank" %)[[link]](%%) hello
>
> is different from:
>
> (% rel="_blank" %)[[link]] hello
>
> In the second case the rel="_blank" applied to both the link, the
> space and the word "hello".
>
> However if we consider the params to only apply the link then we
> cannot set params anymore that span more than the link.
>
> For example: (% style="color:red" %)[[link]] and some text(%%)
>
> Note that technically the params currently generate a <span> element
> with the params as attributes. Thus right now using rel="_blank" is
> set on the span and not on the <a> element which means it doesn't  
> work.
>
> Solutions
> =======
>
> a) Add again the notion of parameters inside the link syntax:
> [[label>>reference>>>param=value...]] (or using some other separator)
> b) Use a different syntax for link parameters, for ex: {% param=value
> %}[[link]] (but I really don't like it)
> c) Force the params in the (% %)[[link]] notation to always apply only
> to the link and thus force users to use a space if they want to start
> a styled portion of text beginning with a link:
> (% param=value %) [[link]] something else %)
>
> As much as I hate having to recode what I've removed, I think the best
> solution is a).
>
> 2) Syntax for images
>
> Problem
> =======
>
> We had decided to use the following syntax:
> image:wiki:Space.Page^my.png (note: not sure we agreed about the use
> of ^ but that's a detail - I couldn't find the email where we
> discussed that)
>
> The question is how do we set parameters for images. For example: alt,
> title, width, height, etc?
>
> We have the exact same problem as for links but it's even worse since
> we don't have the ability to define the parameters inside the image
> syntax since the image syntax is too limited.
>
> Solutions
> =======
>
> a) Use a different syntax such as:
>
> !!label>>image>>>param=value...!!
>
> (note that there are several wikis using the !! notation for images,
> including confluence)
>
> Ex:
> !!my.png!!
> !!my image>>my.png!!
> !!wiki:Space.Page^my.png>>>width=100 height=200!!
>
> b) Decide not to have a syntax for images and instead use an image
> macro.
>
> Ex:
> {{image name="my.png" document="wiki:Space.Page" width="100"
> height="200"/}}
>
> Note that there's one problem with not having a syntax for images in
> the grammar: it makes it harder to convert from one syntax for
> another. For example people using wikimodel wouldn't be able to
> convert from xwiki to another syntax easily and viceversa. In XWiki
> itself we would need to have some extra handling code to handle the
> fact that the image is a macro to convert it to another syntax but
> that's possible (not the easiest but possible).
>
> WDYT for 1) and 2)?
>
> My choice:
>
> 1) a)
>
> For 2) I'd prefer to have a syntax for images (for the conversion
> between syntaxes issue and for the fact that the syntax wouldn't be
> complete - We've added tables in the syntax so it would be a pity not
> to have a syntax for images IMO). There's only possibility though:
> that we add {{image...}} in the syntax, so it would generate an
> onImage() event in XWiki and we would just convert it internally to an
> image macro. Ideally I'd still prefer a clean syntax but that'd be my
> second choice.
>
> 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

Reply via email to