mediawiki-extensions-Visual.../modules/ve/test
Catrope 7bcf35e0e8 (bug 43056) Inline tags like <span> are block-alienated sometimes
This happens when the <span> is the start of unwrapped content. The
converter logic to look at the tag name in wrapping mode doesn't kick in
because we're not yet in wrapping mode at that point.

The core issue was that previously, we relied on the document
structure/state to choose between alienBlock and alienInline, and only
used the tag name where the document structure was ambiguous (wrapping).
Changed this to be the other way around: we now rely primarily on the
tag name, and if that doesn't match what we expect based on the document
structure, we work around that if possible. Specifically:
* inline tag in our wrapper --> inline alien
* block tag in our wrapper --> close wrapper, block alien
* inline tag in wrapper that's not ours --> inline alien
* block tag in wrapper that's not ours --> *inline* alien
* inline tag in structural location --> open wrapper, inline alien
* block tag in structural location --> block alien
* inline tag in content location --> inline alien
* block tag in content location --> *inline* alien
only in the fourth and the last case do we need to use the "wrong" alien type to
preserve document validity, and it will always be inline where block was
expected, which should reduce UI issues.

The condensed version of the above, which is used in the code, is:
* If in a non-wrapper content location, use inline
* If in a wrapper that's not ours, use inline
* Otherwise, decide based on tag name
* Open or close wrapper if needed

ve.dm.Converter:
* Replace isInline logic in createAlien() with the above
* Factor out code to start wrapping (was duplicated) into startWrapping()
* Call startWrapping() if createAlien() returns an alienInline and we're
  in a structural location

Tests:
* Add test cases with aliens at the start and end of unwrapped content
** The first one failed prior to these changes and now passes, the
   second one was already passing
* Fix about group test case, was exhibiting the bug that this commit fixes

Change-Id: I657aa0ff5bc2b57cd48ef8a99c8ca930936c03b8
2012-12-22 12:27:11 +01:00
..
ce (bug 42555) Fixed onUpdate over-writing in ve.ce.HeadingNode 2012-11-30 11:39:46 -08:00
dm (bug 43056) Inline tags like <span> are block-alienated sometimes 2012-12-22 12:27:11 +01:00
init init.Platform: Refactor parsed messages. 2012-12-04 07:56:41 +01:00
image.png
index.php Phase out $.toJSON, use JSON.stringify directly. 2012-12-13 01:33:46 +01:00
ve.BranchNode.test.js
ve.Command.test.js Replaced command factory with new command class 2012-11-07 15:47:03 -08:00
ve.Document.test.js Fix constructor names; remove redundant hasOwnProperty. 2012-10-08 06:15:20 +02:00
ve.example.js Add parentOuterRange to selectNodes() output 2012-10-19 15:28:26 -07:00
ve.Factory.test.js Added multiple name registration to ve.Factory 2012-10-12 17:43:04 -07:00
ve.LeafNode.test.js Fix constructor names; remove redundant hasOwnProperty. 2012-10-08 06:15:20 +02:00
ve.Node.test.js Fix constructor names; remove redundant hasOwnProperty. 2012-10-08 06:15:20 +02:00
ve.qunit.js Store the data model element in the DM tree 2012-11-27 14:36:29 -08:00
ve.Range.test.js Test: Enforce # of expected assertions. 2012-10-25 22:06:07 +02:00
ve.test.js Only apply HTML attributes to DOM nodes that are "safe" 2012-11-27 14:34:29 -08:00