James Forrester jforres...@wikimedia.org writes:
There's also #3 – doing all the dozens of things that the wikitext parser
does on ingestion. All the redlinks and categories tables, building a
user-land (not UI) HTML template system for transclusions, media updates,
*etc.* Not a trivial
Tim Starling tstarl...@wikimedia.org writes:
HTML storage would be a pretty simple feature, and would allow
third-party users to use VE without Parsoid.
I've been thinking about how to implement an alternative to Parsoid
so that users of MW could use VE without standing up a node.js server.
Hi!
2. HTML validation - our current security model relies on the HTML
being generated server-side by a wikitext parser. If we cut wikitext
out of the loop, we'll need some other way of ensuring that people
can't inject arbitrary Javascript/Flash embedding/Java
applet/ActionScript/iframe
On Tue, Jan 20, 2015 at 10:54 AM, Mark A. Hershberger m...@nichework.com
wrote:
Tim Starling tstarl...@wikimedia.org writes:
HTML storage would be a pretty simple feature, and would allow
third-party users to use VE without Parsoid.
I've been thinking about how to implement an alternative to
On 20 January 2015 at 11:08, Rob Lanphier ro...@wikimedia.org wrote:
On Tue, Jan 20, 2015 at 10:54 AM, Mark A. Hershberger m...@nichework.com
wrote:
Tim Starling tstarl...@wikimedia.org writes:
HTML storage would be a pretty simple feature, and would allow
third-party users to use VE
