Anca Paula Luca wrote: > Anca Paula Luca wrote: >> Sergiu Dumitriu wrote: >>> Marius Dumitru Florea wrote: >>>> Thomas Mortagne wrote: >>>>> Hi devs, >>>>> >>>>> We have to make a decision about that. >>>>> >>>>> So here are the proposals: >>>>> >>>>> 1) remove the block leading and trainling spaces >>>>> * The main goal is to make source formatting for tables for example >>>>> more readable >>>>> >>>>> 2) make the spaces inside paragraph non meaningfull >>>>> * Meaning an HTML like behavior where multiple spaces give one space >>>>> >>>>> 3) in case of 1) or 2) use ~<space> as non breaking space >>>>> >>>>> WDYT ? >>>> -0, the users will blame the WYSIWYG for messing up their nicely >>>> formatted table/lists/etc. when switching between the editors. This will >>>> make the WYSIWYG unusable for a wiki syntax user. >>>> >>> Why? The renderer should leave spaces as they are, the WYSIWYG editor >>> should not care about them, and the parser should just leave white space >>> alone. ~space is the only one that must be transformed and treaded >>> specially. >> The wysiwyg is sending back the rendered html modified i.e. without >> non-meaningful spaces => the spaces added for nice wiki formatting will be >> lost. > > I hurried a bit with the answer, indeed we can rely on the html processing of > spaces in browsers and *not* strip them off on rendering time, so that we can > pass them safely through the rendered html.
Actually I don't think it would work, because wysiwyg is working with a DOM build from the rendered content, which is then serialized and sent back as the edited content. I don't think browsers parse and store non-meaningfull spaces in DOM, nor serialize them back. > > Still I think the parser would have a problem with reconstructing them in > non-meaningfull text elements (as in before list items). > >>>>> +0,5 for 1) it's not critical for me but i'm not against it and we >>>>> already decided to remove space before list item, headers etc. >>>>> -0 for 2) I don't see the need for that and it's a lot easier for the >>>>> parser to make spaces meaningfull (what to do when you have "test ** >>>>> bold**" and things like that) >>>>> +1 for 3) >>>>> >>>>> On Sat, Feb 28, 2009 at 15:44, Vincent Massol <[email protected]> wrote: >>>>>> Hi, >>>>>> >>>>>> This is our last chance to change this behavior. We've found several >>>>>> places where having meaningful spaces are counter-productive: >>>>>> >>>>>> * in table cells since we can't align table anymore. For example: >>>>>> >>>>>> |= column1 |= column2 >>>>>> | this is some para | second column >>>>>> | hello | world >>>>>> >>>>>> (not sure this will be rendered nicely in mail but you see what I mean) >>>>>> >>>>>> * in scripts since having meaningful spaces prevents us from aligning >>>>>> velocity or groovy scripts. For ex we can't write: >>>>>> >>>>>> #if (....) >>>>>> #if (...) >>>>>> do something >>>>>> # end >>>>>> #end >>>>>> >>>>>> To see a better example have a look at http://tinyurl.com/ahz669 >>>>>> >>>>>> What I think users real want are meaningful new lines but I see cons >>>>>> overweighting pros for having meaningful white spaces. Thus I'm think >>>>>> we should strip whitespaces at beginning and end of lines including >>>>>> for line breaks. >>>>>> I'm slightly less sure for multiple spaces between words but even >>>>>> there I think we could strip them have users use {{{ }}} to put a non >>>>>> breaking space for ex (or introduce a {{space/}} macro or another >>>>>> special syntax although I'd rather we don't introduce a new syntax). >>>>>> >>>>>> WDYT? >>>>>> >>>>>> Thanks >>>>>> -Vincent >>>>>> http://xwiki.com >>>>>> http://xwiki.org >>>>>> http://massol.net >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
