Brion vibber wrote:
Individual paragraphs, table cells, etc would be an
even nicer
fine-grained level to do inline editing on, but this requires having a
reliable way to associate parts of rendered output with the parts of
source code which created them.
I'm aware of these difficulties. There are a number of ways I can see this
being tackled. Firstly, only pure wikitext can be edited inline. That is, if
you try to edit some text which is the result of 2 #switch's inside 6 nested
templates being transcluded through 2 articles, then there's just no option
to edit inline. Either that, or attempting to edit that part inline sends
you to an appropriate edit page - either for the article, the template, the
nested template, etc - more difficult.
But focussing on the easy stuff: inline editing on a page with nothing but
nice, pure, transclusion-less wikitext, I don't see this as being so hard.
Obviously the renderer renders the code for inline editing into the output,
so there wouldn't be a correspondence issue.
For instance: for every paragraph, or the contents of every table cell, the
renderer can output some funky code that allows inline editing on that part.
This funky code is ultimately a function with inputs for two numbers that
define a range of characters in the wikitext that will be replaced by the
result of the inline editing. The renderer obviously renders these numbers
into the output as constants when it parses the wikitext.