>>! In T54061#1672245, @cscott wrote:
> In particular, I'm interested in hearing more from @GOIII about:
>> . . .
> Lets get a spec for `<lines>` written down in such a way that we can discuss issues like this:

> * Should the tags be forced to be on their own lines?  (The current implementation doesn't force this.)
Depends. Will the new tag mimic the standard behavior of a <DIV> attribute's //display:block// or the behavior of a <P> attribute's //display:block// under the wiki mark-up/parser/parsoid? 

The whole damnblasted issue comes back first and formost to the auto insertion of an opening <P> tag at every seemingly first detected line start. That's the current quirk; whether or not content placement starts after //or// under the poem tag. In other terms using the basic underlying html when it comes to the <poem> tag, it's ....

<poem>First line
<p>second line</br>
third line</br>
last line</p></poem>

... versus ...

<poem>
<p>First line</br>
second line</br>
third line</br>
last line</p>
</poem>

The 2nd version is //closer// to reflecting normal/expected behavior based on the "substitution" of <poem> for <div> but its still not quite right because of the attributes <p> automatically follows as defined elsewhere by some number of .css files 'handed down' by mediawiki by default. The optimal "underlying" html should behave as a true DIV tag (//display:block//) should and there should be no <P> element or behavior anywhere in play here.

Taking the same two possible placements of content start (immediately after or immediately under) as above but substituting <div> for <poem>, the "underlying" html should go something like this ... 

<div class=poem>First line</br>
second line</br>
third line</br>
last line</br></div>

... versus ...

<div class=poem>
First line</br>
second line</br>
third line</br>
last line</br>
</div>

Obviously, consensus still needs to be reached whether or not there should be a </br> at the end of the 'last line' found immediately before the closing tag, but regardless of //after// or //under// placement by the contributor, both render the same. The takeaway here should be __killing the presence and/or behavior of that mark-up induced opening <p> tag for any of this to truly be worthwhile imho__.
 
> * Can you write `<lines class="foo">`?  Does this override the default "poem" and "mw-lines" classes, or add to them?  Is this sufficient for the different styling @GOIII describes?  (The current implementation doesn't allow extra classes.)
Imho, manually adding a class= statement should add or enhance the default. 

> * What should the Parsoid representation be?
Not sure what exactly you're looking for here

> * What if somebody writes `<pre class="poem mw-lines">` in wikitext?  That's valid wikitext.  Should Parsoid try to re-serialize this as a `<lines>` tag?
Probably not as the <pre> tag introduces background-color and borders which is not likely to be in high demand as far as Wikisource goes. I can't speak for other projects however.

I'm not even sure the current <pre> scheme follows the "new" css3 properties of //white-space: pre-wrap// or //white-space: pre-line// for that matter. 

> * Generally styles hard-coded by mediawiki core are prefixed.  The `poem` class is not.
I would hope the accepted practices and/or appropriate procedures would dictate this.

> * If `<poem>` is aliased to `<lines>`, are we going to break all of wikisource overnight?
Building an all encompassing testbed on //test2.wikipedia.org// to experiment against prior to roll out seems like the logical way to address such concerns in my view. 

> * Is a recursive parse strategy really appropriate?  It means that `<lines>` and `<pre>` are going to grow additional inconsistencies on the edge cases.  For example, `'''foo<lines>bar'''bat` could get rather confused about its `<b>`s. 
I'd need more clarity re: the direction ultimately taken regarding the earlier points to reply here