I'd be in favor of ii) as well for the sake of consistency & coherence.
Guillaume

On Mon, Oct 27, 2008 at 3:22 PM, Vincent Massol <[EMAIL PROTECTED]> wrote:

>
> On Oct 27, 2008, at 2:01 PM, Vincent Massol wrote:
>
> >
> > On Oct 27, 2008, at 12:44 PM, Anca Paula Luca wrote:
> >
> >> 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.
> >>
> >> Since there is no way currently to set an attribute for an inline
> >> element (for
> >> the <a> element itself and not a wrapping span), I'd go for adding
> >> the
> >> parameters syntax, provided that we can do it for *all* inline
> >> elements and
> >> maybe also make it available, as an alternative, to block elements,
> >> where this
> >> method could be applied.
> >
> > I'm not sure I understand what you mean. Basically there are now 2
> > possibilities:
> >
> > i) using a special syntax for parameters for links and images. For
> > links that could be [[label>>reference>>>parameters]]. Note that we
> > might also need such a special syntax for inline verbatim blocks.
> > ii) using 2 generic syntaxes for parameters:
> >
> > (% ... %) for applying parameters only to the next element
> > {% ... %} ... {%%} for applying parameters to the elements inside
> >
> > Which one do you prefer?
> >
> > I think we have an issue for i) anyway (for verbatim inline elements
> > for example).
> >
> > My preference goes to i).
>
> Sorry I mistyped. My preference goes to ii), not i) (although it's a
> close call but I prefer the homogeneity - my hesitation is that it's
> slightly more complex for users). Note that I haven't though yet on
> how to implement it so I might find some surprises there too ;)
>
> Thanks
> -Vincent
>
> >> so
> >> +1 for 1)a) only if we can do it for all inline elements.
> >>
> >> Which brings us to images:
> >> I find a wiki syntax quite suitable, for consistency reasons (with
> >> links, for
> >> example). ! is a pretty used character, even duplicated, so I'd go
> >> for another
> >> one: pipe (hard to find on some kbds, though), @ (semantically
> >> associated with
> >> emails, though), # (already taken), & ?
> >>
> >> so
> >> +1 for wiki syntax for 2)
> >>
> >> Happy coding,
> >> Anca
> >>
> >>>
> >>> Thanks
> >>> -Vincent
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>



-- 
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://blog.xwiki.com/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to