“long-term we are trying to make template nesting more sane.”
for now, do you have a list that which templates should emit properly nested output?
On Thu, Sep 19, 2013 at 8:01 PM, wikitext-l-request@lists.wikimedia.orgwrote:
Send Wikitext-l mailing list submissions to wikitext-l@lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.wikimedia.org/mailman/listinfo/wikitext-l or, via email, send a message with subject or body 'help' to wikitext-l-request@lists.wikimedia.org
You can reach the person managing the list at wikitext-l-owner@lists.wikimedia.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Wikitext-l digest..."
Today's Topics:
- Re: Wikitext-l Digest, Vol 36, Issue 6 (C. Scott Ananian)
Message: 1 Date: Wed, 18 Sep 2013 10:34:34 -0400 From: "C. Scott Ananian" cananian@wikimedia.org To: Parsoid and wikitext discussion wikitext-l@lists.wikimedia.org Subject: Re: [Wikitext-l] Wikitext-l Digest, Vol 36, Issue 6 Message-ID: <CAK5kH3xtBdkd4MEKCV2wgxnZNoZws= Fa+LWahncb4tZ--hKdYQ@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
On Wed, Sep 18, 2013 at 7:51 AM, Feng Yi zlfengyi@google.com wrote:
I have another two question:
- According to the roadmap, you will research the “HTML-only wiki
support” and “DOM-based templating”. Does it mean that if you launch
these
functions, wikitext will no longer be supported, even the round-trip doesn’t work?
At least initially, HTML-only wiki support will mean that it is *possible* to install an HTML-only wiki, not that it is required.
DOM-based templating is an orthogonal issue; long-term we are trying to make template nesting more sane.
- In “MediaWiki_DOM_spec” there are a lot of discussing and implemented
status. Will the parsoid output change a lot in the future? What is the approximate percentage?
Sections which are not explicitly marked w/ discussion or 'implementing' are expected to remain stable. We reserve the right to change the spec if needed, but most of it is in production use and working satisfactorily and is not expected to change. The most in-flux bits are the bits which are not currently implemented and/or supported by Visual Editor. Our process is to work out a spec proposal with the Visual Editor team, implement it in Parsoid, then implement support for the new feature in Visual Editor. During these stages the spec is often found deficient in some way and is fixed. Once the feature lands in Visual Editor and is deployed, we have reasonable confidence that the spec is correct and will not need to be changed further.
--scott
On Thu, Sep 26, 2013 at 2:37 AM, Feng Yi zlfengyi@google.com wrote:
“long-term we are trying to make template nesting more sane.”
for now, do you have a list that which templates should emit properly nested output?
We do not, yet. We hope at some point to have some tools to automatically flag improper nesting in templates.
https://www.mediawiki.org/wiki/Parsoid/limitations and https://www.mediawiki.org/wiki/Parsoid/Broken_wikitext_tar_pit provide some guidelines.
But basically: if templates open a new HTML element, they should also close it. The most common 'broken' template types have separate templates, one of which starts a table, and the other one closes the table. This is very hard to express in an tree-structured DOM, and complicates DOM fixup after templates are updated.
--scott
We do not, yet. We hope at some point to have some tools to automatically flag improper nesting in templates.
https://www.mediawiki.org/wiki/Parsoid/limitations [1] and https://www.mediawiki.org/wiki/Parsoid/Broken_wikitext_tar_pit [2] provide some guidelines.
But basically: if templates open a new HTML element, they should also close it. The most common 'broken' template types have separate templates, one of which starts a table, and the other one closes the table. This is very hard to express in an tree-structured DOM, and complicates DOM fixup after templates are updated.
--scott
Didn't read the whole discussion but wnat to say that if you make a single template for some tasks you end up with writing {{Template|1= ... text ... }} - because if text contains '=' then it is splitted on it and the first part is taken as the template name. And this is not to mention vertical bar character (|) which is """escaped""" as {{!}}. Not very convenient )
Yes, this is a long-term project.
One suggestion I've made is to add some additional syntactic sugar for templates. Something like:
{{>Template}} foo {{<Template}}
which would pass all the content between {{>Template}} and {{<Template}} as a single parameter. This would work around all the splitting/escape issues and allow us to rewrite {{table-start}} / {{table-end}} template pairs as {{>table}} / {{<table}} -- ie, minimal changes to to the wikitext would be required, but the result would be a properly nested template invocation. (This idea is stolen from http://handlebarsjs.com/ .)
This is still highly speculative, but I'm interested in discussion. --scott
On 09/25/2013 11:37 PM, Feng Yi wrote:
“long-term we are trying to make template nesting more sane.”
for now, do you have a list that which templates should emit properly nested output?
All of them should, but for some we'll have to be backwards-compatible for a while.
Identifying unbalanced template-affected content is relatively easy. In our DOM format, transclusion-affected content is marked as mw:Transclusion and a data-mw attribute contains a 'parts' array of involved transclusions and page wikitext. When there are unbalanced templates involved, there will be more than one template in this array. Typically the first and last template in this list will be wrapper-style unbalanced templates. As template output can depend on the input, the time and other varying data we'll have to do statistics for a robust classification of templates.
See https://www.mediawiki.org/wiki/Parsoid/Roadmap#Research_.2F_prototype:_Enfor... for the roadmap on this. The idea we have been kicking around for a while was to wrap unbalanced content in a <domparse> tag like this:
<domparse> {{echo|unbalanced<table>}} .. {{echo|</table>}} </domparse>
This covers any content including transclusions and extensions, and can be implemented as a tag extension in the PHP parser. Content inside it will be parsed to a balanced DOM fragment.
This is easy to apply manually from now on, but we'll have to find a good solution that also works for old revisions. HTML diffing against those should work as expected.
Gabriel
wikitext-l@lists.wikimedia.org