| From | alexandre.fayolle at logilab dot fr |
| To | syt at logilab dot fr |
| CC | alf at logilab dot fr |
| Date | 2010/08/04 12:02 |
| Subject | Re: [logilab-mtconverter] new comment for ticket #37276: [text2html] better line handling |
On Wednesday 04 August 2010 11:45:19 Sylvain Thénault wrote:
> On 04 août 11:34, Alexandre Fayolle wrote:
> > >>> On 2010/08/04 10:37 - acampeas wrote :
> > >>> arguments heard _against_:
> > >>>
> > >>> * what we can do with css
> > >>> * use a <pre> tag (and there is a related ticket on this in the
> > >>> cubicweb forge)
> > >>> * the role of <p> is to let the browser decide where to line jump and
> > >>> if we add <br>s it doesn't work any more
> > >>
> > >> On 2010/08/04 10:45 - acampeas wrote :
> > >> I contend that none if this is relevant.
> > >>
> > >> * css cannot guess when it is right to line feed if we remove the
> > >> information from the transformed html
> > >> * we probably do not want to special case transform html output based
> > >> on the input content format
> > >> * the role of <p> is to build paragraphs, the role of <br> is to force
> > >> line feeds (they have different, but definitely not conflicting
> > >> semantics)
> > >>
> > >> When a text snippet author puts a single \n within his text, it is a
> > >> semantic information that must be preserved. That we interpret \n\n
> > >> as <p> is arguable (but acceptable), but I still fail to see one
> > >> reason to not correctly encode single \n.
> > >
> > > On 2010/08/04 11:11 - sthenault wrote :
> > > Here is the point. '\n' is imo not a *semantinc* information. It's more
> > > usually formatting information, and most often which has meaning *when
> > > you type the text* in. Eg in the textarea, which doesn't behave like
> > > the final, html formatted, text.
> > >
> > > Now the point is probably to make a compromise to get what *most*
> > > people expect (eg, not necessarily me nor you). I tend to think people
> > > usually expect more likely the behaviour you describe, not mine... Is
> > > there some people following this story with an opinon on this ?
> >
> > The standard user using plain text format and not wanting to learn will
> > be happy to use acampeas' solution, and is disappointed by the current
> > solution. You cannot expect such users to adhere to emacs/vim
> > conventions (sentences_ ending with dot space space, paragraphs_ ending
> > with double LF, etc.). The closer you are in display to what the user
> > was seeing when he typed his message, the better (think of cut and
> > pasted stack traces from a terminal...)
> >
> > The advanced user will use ReST and be happy with it.
> >
> > The evil user will use HTML and do nasty stuff.
>
> so be it then.
>
> Though I still disagree this is *semantinc* :p
I don't care if you call it semantic or not. I just want this to work, and not
to have to edit external users comment on CW sites when their formatting is
garbled.
If you insist, you may change the name "plain text" to something else".
--
Alexandre Fayolle LOGILAB, Paris (France)
Formations Python, CubicWeb, Debian : http://www.logilab.fr/formations
Développement logiciel sur mesure : http://www.logilab.fr/services
Informatique scientifique: http://www.logilab.fr/science
> On 04 août 11:34, Alexandre Fayolle wrote:
> > >>> On 2010/08/04 10:37 - acampeas wrote :
> > >>> arguments heard _against_:
> > >>>
> > >>> * what we can do with css
> > >>> * use a <pre> tag (and there is a related ticket on this in the
> > >>> cubicweb forge)
> > >>> * the role of <p> is to let the browser decide where to line jump and
> > >>> if we add <br>s it doesn't work any more
> > >>
> > >> On 2010/08/04 10:45 - acampeas wrote :
> > >> I contend that none if this is relevant.
> > >>
> > >> * css cannot guess when it is right to line feed if we remove the
> > >> information from the transformed html
> > >> * we probably do not want to special case transform html output based
> > >> on the input content format
> > >> * the role of <p> is to build paragraphs, the role of <br> is to force
> > >> line feeds (they have different, but definitely not conflicting
> > >> semantics)
> > >>
> > >> When a text snippet author puts a single \n within his text, it is a
> > >> semantic information that must be preserved. That we interpret \n\n
> > >> as <p> is arguable (but acceptable), but I still fail to see one
> > >> reason to not correctly encode single \n.
> > >
> > > On 2010/08/04 11:11 - sthenault wrote :
> > > Here is the point. '\n' is imo not a *semantinc* information. It's more
> > > usually formatting information, and most often which has meaning *when
> > > you type the text* in. Eg in the textarea, which doesn't behave like
> > > the final, html formatted, text.
> > >
> > > Now the point is probably to make a compromise to get what *most*
> > > people expect (eg, not necessarily me nor you). I tend to think people
> > > usually expect more likely the behaviour you describe, not mine... Is
> > > there some people following this story with an opinon on this ?
> >
> > The standard user using plain text format and not wanting to learn will
> > be happy to use acampeas' solution, and is disappointed by the current
> > solution. You cannot expect such users to adhere to emacs/vim
> > conventions (sentences_ ending with dot space space, paragraphs_ ending
> > with double LF, etc.). The closer you are in display to what the user
> > was seeing when he typed his message, the better (think of cut and
> > pasted stack traces from a terminal...)
> >
> > The advanced user will use ReST and be happy with it.
> >
> > The evil user will use HTML and do nasty stuff.
>
> so be it then.
>
> Though I still disagree this is *semantinc* :p
I don't care if you call it semantic or not. I just want this to work, and not
to have to edit external users comment on CW sites when their formatting is
garbled.
If you insist, you may change the name "plain text" to something else".
--
Alexandre Fayolle LOGILAB, Paris (France)
Formations Python, CubicWeb, Debian : http://www.logilab.fr/formations
Développement logiciel sur mesure : http://www.logilab.fr/services
Informatique scientifique: http://www.logilab.fr/science