Updates to TextileParser; awaiting feedback

25 views
Skip to first unread message

Tobias Pfeiffer

unread,
Oct 13, 2012, 1:48:50 PM10/13/12
to lif...@googlegroups.com
Hi,

as I wanted to have some extended markup possibilities for my users, cf.
<https://groups.google.com/forum/?fromgroups=#!topic/liftweb/eItP8aQcKug>,
I extended the TextileParser a bit, mostly
a) to allow class and style attributes for bullet lists and div
elements,
b) to allow <div> as a toplevel element, such that a full Textile
document can be nested within <div>,
and other things, see https://github.com/liftmodules/textile/pull/6

One consequence of the new/changed <div> behaviour is that the test
"A Textile Parser can deal with multi-line div" does not pass any more.
In the current version,

"""<div class="vcard">
<div class="fn">Joe Doe</div>
<div class="org">The Example Company</div>
<div class="tel">604-555-1234</div>
http://example.com/
</div>"""

is transformed to

<p><div>
<div>Joe Doe</div>
<div>The Example Company</div>
<div>604-555-1234</div>
<a href="http://example.com/">http://example.com/</a>
</div></p>

With my additions w.r.t. (a), classes are allowed in div elements, such
that this would be transformed to

<p><div class="vcard">
<div class="fn">Joe Doe</div>
<div class="org">The Example Company</div>
<div class="tel">604-555-1234</div>
<a href="http://example.com/">http://example.com/</a>
</div></p>

instead, where I think most people would be ok with those changes.
However, my additions for (b) make <div> a toplevel element, i.e. it's
not necessarily surrounded by <p> any more (which is not allowed by HTML
anyway), i.e. the output that my code generates for the above example is
now:

<div class="vcard">
<div class="fn"><p>Joe Doe</p></div>
<div class="org"><p>The Example Company</p></div>
<div class="tel"><p>604-555-1234</p></div>
<p><a href="http://example.com/">http://example.com/</a></p>
</div>

(The nested divs currently must not be indented any more in the input,
but I guess I should be able to fix this.)
However, for some of the users of TextileParser, this might result in
considerable layout changes of the rendered HTML and Diego suggested to
ask on the list if there is anyone who has concerns about this change.
Otherwise I would love to see those changes in the official TextileParser
(after fixing the indentation issue).

Looking forward to receiving your feedback!

Thanks,
Tobias
signature.asc

Richard Dallaway

unread,
Oct 14, 2012, 4:22:11 AM10/14/12
to lif...@googlegroups.com, lif...@googlegroups.com


On 13 Oct 2012, at 18:48, Tobias Pfeiffer <tob...@tesobe.com> wrote:

[...]

However, my additions for (b) make <div> a toplevel element, i.e. it's
not necessarily surrounded by <p> any more (which is not allowed by HTML
anyway), i.e. the output that my code generates for the above example is
now:

<div class="vcard">
  <div class="fn"><p>Joe Doe</p></div>
  <div class="org"><p>The Example Company</p></div>
  <div class="tel"><p>604-555-1234</p></div>
  <p><a href="http://example.com/">http://example.com/</a></p>
</div>


Textile produces pretty odd output at times.  The <p> wrapping seems strange, but it does appear to be what it does.  For example: http://txstyle.org/doc/41/html and select Show HTML output. 

So although I don't like the extra <p> tags I'm noting that we'd no-longer be implementing Textile but Textile-the-way-we-like it which would deviate from other Textile tools. I'm not sure if that's good (progress, possibly making things more useful to users) or bad (non standard).

It'd need to be well documented as a deliberate difference in the wiki and module README at the very least.

Richard 



Peter Petersson

unread,
Oct 16, 2012, 10:33:49 AM10/16/12
to lif...@googlegroups.com
The following seem to bee the textile way of NOT enclosing blocks of code in paragraph tags (a leading space at each line of the block). If the indention thing can be fixed to conform with the official textile parser rules I think having the class attribute option is a great (extension).
----------------

1) To prevent Textile from enclosing complex HTML blocks in paragraph tags, either use a space at the beginning of each line


 <div>
 <span>My div</span>
 </div>

or a notexile.. extended block.

notextile.. <div>
<span>My div</span>
</div>
-------------
best regards
  Peter Petersson

2012/10/14 Richard Dallaway <ric...@dallaway.com>

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
 
 
 

Tobias Pfeiffer

unread,
Oct 20, 2012, 4:01:02 PM10/20/12
to lif...@googlegroups.com
Hi,

thanks for your feedback!

Am Sonntag, 14. Oktober 2012, 10:22 schrieb Richard Dallaway:
> Textile produces pretty odd output at times. The <p> wrapping seems
> strange, but it does appear to be what it does. For
> example: http://txstyle.org/doc/41/html and select Show HTML
> output.

While I agree with Richard that it wouldn't be good to leave the
standard Textile specification, it seems to me as if there is no real
"Textile specification".
While the link to txstyle.org you posted does indeed <p> wrapping of the
<div>, the spec at
https://github.com/textile/textile-spec/blob/master/html.yaml
says that it shouldn't (see the "shopping-cart" example) for that exact
example. The implementation at
http://www.textism.com/tools/textile/index.php
transforms it to something completely absurd, not even respecting the
"h3" block. So if there *was* a specification for Textile, I guess that
no two parsers would behave the same.

Honestly, in this situation, I think the following is the best: Merge
the part of my pull request that deals with "adding classes to <div>s"
and the smaller fixes, do *not* merge the parts that allowed div as a
toplevel element (as not to break other people's implementations) and
I'll search for a different way to allow extended markup to my users.

OK?
Tobias
signature.asc

Peter Petersson

unread,
Oct 21, 2012, 4:16:07 AM10/21/12
to lif...@googlegroups.com
Tobias

If in your pull request you honour the one space indent on the div would it not make it a toplevel element without breaking anything ? (see below) 

I agree the specs dose not seem to cover all corners 

From what I can see reading the spec (and the one space indent note at txstyle.org) and looking at the examples below the second parser respects the one space indent (as dose the first as it dose not enclosing with paragraphs at all)

At http://txstyle.org/doc/41/html :
--This parser is adding paragraphs to plain html blocks if html node is not indented one space.

I do not see any enclosing paragraph tags in the shopping-cart example, but I do recognize that if you indent all lines by one space it dose not respect the h3 tag and the bullet list any more (and it should not ).
Indenting only the enclosing shopping-cart div and the result get a bit compacter (skipping a trailing paragraph) but still no enclosing paragraph tags. Doing the same with the form tag will compact the result future.


At http://www.textism.com/tools/textile/index.php :
--This parser encloses everything not textile (html) with paragraphs if the html node is not indented one space. 

Pasting the chopping-cart and yes I see the enclosing paragraph. Indenting the enclosing shopping-cart div one space and the enclosing paragraph goes away. Also indenting the input line one space and the only remaining paragraph on that line is the specified on.

best regards
   Peter Petersson
Reply all
Reply to author
Forward
0 new messages