Especially important for newly inserted ones, as at the moment we have no idea what they are going to be so we just assume inline.
Version: unspecified
Severity: enhancement
Especially important for newly inserted ones, as at the moment we have no idea what they are going to be so we just assume inline.
Version: unspecified
Severity: enhancement
Possible solution may involve removing distinction between block & inline transclusion types in the DM, replacing with hybrid type, and have CE work out how to render it properly.
Parsoid says they now have a public wt2html API that we can use instead of action=parse. That would at least allow use to let Parsoid determine whether it is inline or block (instead of sniffing the html result, though that's fairly trivial, just <span> vs. everything else, right? Maybe a few other inline elements nodes that we use, or do we wrap them all?)
However we still need to then find a way to swap the data model node instance in that case. Having 1 datamodel type would be nice indeed. We could make it similar to extension tags in that templates have their own class, but it wouldn't be specific to an element type, we can still swap it dynamically (just like we can change lists from UL to OL).
(In reply to comment #5)
Parsoid says they now have a public wt2html API that we can use instead of
action=parse. That would at least allow use to let Parsoid determine whether
it
is inline or block (instead of sniffing the html result, though that's fairly
trivial, just <span> vs. everything else, right? Maybe a few other inline
elements nodes that we use, or do we wrap them all?)However we still need to then find a way to swap the data model node instance
in that case. (..)
From ve.dm.MWTransclusionBlockNode to ve.dm.MWTransclusionInlineNode or visa versa.
Inez talked to me about this long-standing problem today. He worked on a solution that involves waiting for the preview to come back before inserting the template, displaying a spinner in the meantime. His code is at https://github.com/Wikia/app/pull/4932/files . It looks a bit rough and it only deals with insertion, but I think the general approach could work out pretty well. If nothing else, it could be a stop-gap until we have collaborative editing and having a transclusion reevaluate its type asynchronously would not be a big deal.
Change 288813 had a related patch set uploaded (by Esanders):
[BREAKING CHANGE] Evalute block/inline state when inserting a transclusion node
Change 288813 merged by jenkins-bot:
[BREAKING CHANGE] Evalute block/inline state when inserting a transclusion node