you'd probably want
Foo
[17:42:11] If you think in wikitext you're going to have a bad time
[17:42:26] not in the above case. If we have the above thumb and we transform it into block, it's reasonable to assume we actually want the result to be Text text
[17:42:38] Bring the image back into the paragraph it "belongs to"
[17:42:55] s/transform it into block/transform it into inline
[17:43:21] Well no, because it renders as two separate lines. Someone using VE doesn't know about wikitext whitespace
[17:43:27] eranroz, want me to add the bugzilla thing, or can you?
[17:43:52] what if the wikitext was \n\n Foo ? that would convert to the same DM HTML
[17:44:13] we can't let wikitext whitespace affect functionality
[17:44:19] mooeypo, i will
[17:44:50] edsanders, sure, I gave the wikitext example as a way to demonstrate the image belongs to the paragraph, but I think that in general if you added an image into the document in an existing paragraph (and that's how we allow users to do it now, we add the image where their cursor's at) then making the image inline should bring it into the paragraph it was inserted to
[17:45:05] edsanders, right now we can't insert inline images directly; users need to insert a block and then transform it into inline
[17:45:16] if it's block we don't know what paragraph if was inserted into
[17:45:25] if it's between two paragraphs it could've been either
[17:45:49] or neither, it could've been drag-dropped there
[17:46:02] I don't think that case is broken
[17:46:07] (the list case clear is though)
[17:46:11] *clearly
[17:46:31] Yeah, I guess so. I think it makes more sense assuming the image belongs to whatever paragraph preceded it, but it's more of a personal user expectation (mine) than actual logic here. I see what you're saying.
[17:47:15] Okay, so I'll concentrate on the list case only. I'm trying to see how we deal with this in the case of inserting inline templates into lists
[17:47:37] Well I don't mind you adding logic for that, but it shouldn't be at the fixUpInsertion level
[17:47:59] which? the list case or the general paragraph case?
[17:48:05] anything in fixUpInsertion means it's _impossible_ to ever generate a transaction that does that
[17:48:17] oh
[17:48:18] paragraph for now, possible the list case too
[17:48:42] so even if I actually intended to do something, having it in FUI will prevent it
[17:48:53] Oh, I see what you mean.
[17:48:56] Hm.
[17:48:56] 3VisualEditor / 3Initialisation: VisualEditor: From a cold start using debug=true, there's no indication VE is loading for a few seconds; move some init stuff further up? - 10https://bugzilla.wikimedia.org/65453#c1 (10Roan Kattouw) There are a few issues with how things are initialized. The delay until the l...
[17:49:13] Okay, so the case of the list makes sense to be there (we have problems with multiline list items *anyways* )
[17:49:21] well....
[17:49:31] so adding a paragraph to an inline image inside a list is impossible at the moment anyways
[17:49:34] having two paragraphs in a list is fine in html
[17:49:38] just not wikitext
[17:49:47] parsoid's not quite doing that yet though
[17:49:48] so really it's a property of MWListItem (which doesn't exist)
[17:50:06] we do have some MW extensions of core nodes
[17:50:15] oh, I see what you're saying.
[17:50:16] which we use to 'suggest' good HTML practices
[17:50:35] edsanders, but wait, even outside of MW, isn't it more logical to *not* wrap the image in paragraph inside the list?
[17:50:40] such as MWHeadingNode, which says a heading should only have a Document as its parent
[17:50:53] mooeypo: Re hewiki stuff, if you want you can write the patch for that, against the operations/mediawiki-config repo. If not, you can get James to do it
[17:51:10] RoanKattouw, I have no idea how to do that?
[17:51:16] mooeypo, it's the same argument as outside a list
[17:51:29] but you could say that lists should only contain one paragraph in core too
[17:51:35] mooeypo: Edit wmf-config/InitialiseSettings.php in that repo, look for TemplateDataGUI, add 'hewiki' => true
[17:51:42] due to the behaviour of the enter key
[17:51:45] The config format is pretty easy to understand once you see it
[17:52:01] edsanders, not sure, I think lists are different, most times you'd expect a user to want non multiline lists, but I accept this more of a discussion than a fact of life.
[17:52:31] edsanders, yeah I think it makes more sense intuitively, but I can live without that, I can see merit in both cases.
[17:53:11] mooeypo: Ha.
[17:53:24] RoanKattouw, mooeypo: Already done.
[17:53:30] oh, whee!
[17:53:31] https://gerrit.wikimedia.org/r/139155
[17:53:43] James_F, thanks!
[17:53:54] * James_F didn't see the discussions, sorry.
[17:54:05] Got pinged by the bug, did the change, then came here to mention it to mooeypo. :_)
[17:54:08] James_F, thanks :)
[17:54:16] yay :D
[17:54:30] eranroz, and thanks for the help with the process and on-wiki :)
[17:54:59] eranroz: Happy to help.
[17:55:02] mooeypo, so we have been meaning for a while to sort out multiple paragraphs in lists
[17:55:34] we need to still support them incase they are supplied as html
[17:57:12] 3VisualEditor / 3Editing Tools: VisualEditor: Quickly clicking on "Apply Changes" button multiple times on Media Settings throws console error and cannot make any more changes to any media settings dialog after that - 10https://bugzilla.wikimedia.org/66389#c3 (10ryasmeen) Verified the fix on Betalabs
[17:57:17] not sure if you can solve both problems in one go though
[17:59:28] 3VisualEditor / 3Editing Tools: VisualEditor: [Regression pre-wmf9] Hovering over a context menu is not highlighting the entire context menu - 10https://bugzilla.wikimedia.org/66444#c2 (10ryasmeen) Verified the fix in Betalabs
[18:01:28] edsanders, yeah, supporting them in wikitext cases might result in dirty diff
[18:01:58]