wikimedia/mediawiki-extensions-VisualEditor
1
0
Fork 0
mirror of https://gerrit.wikimedia.org/r/mediawiki/extensions/VisualEditor synced 2024-11-15 10:35:48 +00:00
Code Issues Packages Projects Releases Wiki Activity
mediawiki-extensions-Visual.../modules/ve/test/dm/ve.dm.example.js

2097 lines
55 KiB
JavaScript
Raw Normal View History

JSDuck: Generated code documentation! See CODING.md for how to run it. Mistakes fixed: * Warning: Unknown type function -> Function * Warning: Unknown type DOMElement -> HTMLElement * Warning: Unknown type DOM Node -> HTMLElement * Warning: Unknown type Integer -> Mixed * Warning: Unknown type Command -> ve.Command * Warning: Unknown type any -> number * Warning: Unknown type ve.Transaction -> ve.dm.Transaction * Warning: Unknown type ve.dm.AnnotationSet -> ve.AnnotationSet * Warning: Unknown type false -> boolean * Warning: Unknown type ve.dm.AlienNode ve.dm doesn't have a generic AlienNode like ve.ce -> Unknown type ve.dm.AlienInlineNode|ve.dm.AlienBlockNode * Warning: Unknown type ve.ve.Surface -> ve.ce.Surface * ve.example.lookupNode: -> Last @param should be @return * ve.dm.Transaction.prototype.pushReplace: -> @param {Array] should be @param {Array} * Warning: ve.BranchNode.js:27: {@link ve.Node#hasChildren} links to non-existing member -> (removed) * Warning: ve.LeafNode.js:21: {@link ve.Node#hasChildren} links to non-existing member -> (removed) Differences fixed: * Variadic arguments are like @param {Type...} [name] instead of @param {Type} [name...] * Convert all file headers from /** to /*! because JSDuck tries to parse all /** blocks and fails to parse with all sorts of errors for "Global property", "Unnamed property", and "Duplicate property". Find: \/\*\*([^@]+)(@copyright) Replace: /*!$1$2 * Indented blocks are considered code examples. A few methods had documentation with numbered lists that were indented, which have now been updated to not be intended. * The free-form text descriptions are parsed with Markdown, which requires lists to be separated from paragraphs by an empty line. And we should use `backticks` instead of {braces} for inline code in text paragraphs. * Doc blocks for classes and their constructor have to be in the correct order (@constructor, @param, @return must be before @class, @abstract, @extends etc.) * `@extends Class` must not have Class {wrapped} * @throws must start with a {Type} * @example means something else. It is used for an inline demo iframe, not code block. For that simply indent with spaces. * @member means something else. Non-function properties are marked with @property, not @member. * To create a link to a class or member, in most cases the name is enough to create a link. E.g. Foo, Foo.bar, Foo.bar#quux, where a hash stands for "instance member", so Foo.bar#quux, links to Foo.bar.prototype.quux (the is not supported, as "prototype" is considered an implementation detail, it only indexes class name and method name). If the magic linker doesn't work for some case, the verbose syntax is {@link #target label}. * @property can't have sub-properties (nested @param and @return values are supported, only @static @property can't be nested). We only have one case of this, which can be worked around by moving those in a new virtual class. The code is unaltered (only moved down so that it isn't with the scope of the main @class block). ve.dm.TransactionProcessor.processors. New: * @mixins: Classes mixed into the current class. * @event: Events that can be emitted by a class. These are also inherited by subclasses. (+ @param, @return and @preventable). So ve.Node#event-attach is inherited to ve.dm.BreakNode, just like @method is. * @singleton: Plain objects such as ve, ve.dm, ve.ce were missing documentation causing a tree error. Documented those as a JSDuck singleton, which they but just weren't documented yet. NB: Members of @singleton don't need @static (if present, triggers a compiler warning). * @chainable: Shorthand for "@return this". We were using "@return {classname}" which is ambiguous (returns the same instance or another instance?), @chainable is specifically for "@return this". Creates proper labels in the generated HTML pages. Removed: * @mixin: (not to be confused with @mixins). Not supported by JSDuck. Every class is standalone anyway. Where needed marked them @class + @abstract instead. Change-Id: I6a7c9e8ee8f995731bc205d666167874eb2ebe23
2013-01-04 08:54:17 +00:00
/*!
Major Documentation Cleanup * Made method descriptions imperative: "Do this" rather than "Does this" * Changed use of "this object" to "the object" in method documentation * Added missing documentation * Fixed incorrect documentation * Fixed incorrect debug method names (as in those VeDmClassName tags we add to functions so they make sense when dumped into in the console) * Normalized use of package names throughout * Normalized class descriptions * Removed incorrect @abstract tags * Added missing @method tags * Lots of other minor cleanup Change-Id: I4ea66a2dd107613e2ea3a5f56ff54d675d72957e
2013-01-15 23:38:49 +00:00
* VisualEditor DataModel example data sets.
Removed some whitespace And added a license to some files that didn't have it yet Change-Id: I3a7e60374d1198d369a0475b8f65f7415012a337
2012-07-19 21:25:16 +00:00
*
Bump copyright notice year range to -2013 over -2012 199 files touched. Whee! Change-Id: Id82ce4a32f833406db4a1cc585674f2bdb39ba0d
2013-02-19 23:37:34 +00:00
* @copyright 2011-2013 VisualEditor Team and others; see AUTHORS.txt
Changed to use MIT license per agreement with the VisualEditor team This license change is aimed at maximizing the reusability of this code in other projects. VisualEditor is more than just an awesome editor for MediaWiki, it's the new editor for the entire internet. Added license and author files, plus mentions of the license to all VisualEditor PHP, JavaScript and CSS files. Parser files have not been modified but are effectively re-licensed since there's no overriding license information. 3rd party libraries are not changed, but are all already MIT licensed. Change-Id: I895b256325db7c8689756edab34523de4418b0f2
2012-07-19 00:11:26 +00:00
* @license The MIT License (MIT); see LICENSE.txt
*/
JSDuck: Generated code documentation! See CODING.md for how to run it. Mistakes fixed: * Warning: Unknown type function -> Function * Warning: Unknown type DOMElement -> HTMLElement * Warning: Unknown type DOM Node -> HTMLElement * Warning: Unknown type Integer -> Mixed * Warning: Unknown type Command -> ve.Command * Warning: Unknown type any -> number * Warning: Unknown type ve.Transaction -> ve.dm.Transaction * Warning: Unknown type ve.dm.AnnotationSet -> ve.AnnotationSet * Warning: Unknown type false -> boolean * Warning: Unknown type ve.dm.AlienNode ve.dm doesn't have a generic AlienNode like ve.ce -> Unknown type ve.dm.AlienInlineNode|ve.dm.AlienBlockNode * Warning: Unknown type ve.ve.Surface -> ve.ce.Surface * ve.example.lookupNode: -> Last @param should be @return * ve.dm.Transaction.prototype.pushReplace: -> @param {Array] should be @param {Array} * Warning: ve.BranchNode.js:27: {@link ve.Node#hasChildren} links to non-existing member -> (removed) * Warning: ve.LeafNode.js:21: {@link ve.Node#hasChildren} links to non-existing member -> (removed) Differences fixed: * Variadic arguments are like @param {Type...} [name] instead of @param {Type} [name...] * Convert all file headers from /** to /*! because JSDuck tries to parse all /** blocks and fails to parse with all sorts of errors for "Global property", "Unnamed property", and "Duplicate property". Find: \/\*\*([^@]+)(@copyright) Replace: /*!$1$2 * Indented blocks are considered code examples. A few methods had documentation with numbered lists that were indented, which have now been updated to not be intended. * The free-form text descriptions are parsed with Markdown, which requires lists to be separated from paragraphs by an empty line. And we should use `backticks` instead of {braces} for inline code in text paragraphs. * Doc blocks for classes and their constructor have to be in the correct order (@constructor, @param, @return must be before @class, @abstract, @extends etc.) * `@extends Class` must not have Class {wrapped} * @throws must start with a {Type} * @example means something else. It is used for an inline demo iframe, not code block. For that simply indent with spaces. * @member means something else. Non-function properties are marked with @property, not @member. * To create a link to a class or member, in most cases the name is enough to create a link. E.g. Foo, Foo.bar, Foo.bar#quux, where a hash stands for "instance member", so Foo.bar#quux, links to Foo.bar.prototype.quux (the is not supported, as "prototype" is considered an implementation detail, it only indexes class name and method name). If the magic linker doesn't work for some case, the verbose syntax is {@link #target label}. * @property can't have sub-properties (nested @param and @return values are supported, only @static @property can't be nested). We only have one case of this, which can be worked around by moving those in a new virtual class. The code is unaltered (only moved down so that it isn't with the scope of the main @class block). ve.dm.TransactionProcessor.processors. New: * @mixins: Classes mixed into the current class. * @event: Events that can be emitted by a class. These are also inherited by subclasses. (+ @param, @return and @preventable). So ve.Node#event-attach is inherited to ve.dm.BreakNode, just like @method is. * @singleton: Plain objects such as ve, ve.dm, ve.ce were missing documentation causing a tree error. Documented those as a JSDuck singleton, which they but just weren't documented yet. NB: Members of @singleton don't need @static (if present, triggers a compiler warning). * @chainable: Shorthand for "@return this". We were using "@return {classname}" which is ambiguous (returns the same instance or another instance?), @chainable is specifically for "@return this". Creates proper labels in the generated HTML pages. Removed: * @mixin: (not to be confused with @mixins). Not supported by JSDuck. Every class is standalone anyway. Where needed marked them @class + @abstract instead. Change-Id: I6a7c9e8ee8f995731bc205d666167874eb2ebe23
2013-01-04 08:54:17 +00:00
/**
* @class
* @singleton
* @ignore
*/
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
ve.dm.example = {};
JSDuck: Generated code documentation! See CODING.md for how to run it. Mistakes fixed: * Warning: Unknown type function -> Function * Warning: Unknown type DOMElement -> HTMLElement * Warning: Unknown type DOM Node -> HTMLElement * Warning: Unknown type Integer -> Mixed * Warning: Unknown type Command -> ve.Command * Warning: Unknown type any -> number * Warning: Unknown type ve.Transaction -> ve.dm.Transaction * Warning: Unknown type ve.dm.AnnotationSet -> ve.AnnotationSet * Warning: Unknown type false -> boolean * Warning: Unknown type ve.dm.AlienNode ve.dm doesn't have a generic AlienNode like ve.ce -> Unknown type ve.dm.AlienInlineNode|ve.dm.AlienBlockNode * Warning: Unknown type ve.ve.Surface -> ve.ce.Surface * ve.example.lookupNode: -> Last @param should be @return * ve.dm.Transaction.prototype.pushReplace: -> @param {Array] should be @param {Array} * Warning: ve.BranchNode.js:27: {@link ve.Node#hasChildren} links to non-existing member -> (removed) * Warning: ve.LeafNode.js:21: {@link ve.Node#hasChildren} links to non-existing member -> (removed) Differences fixed: * Variadic arguments are like @param {Type...} [name] instead of @param {Type} [name...] * Convert all file headers from /** to /*! because JSDuck tries to parse all /** blocks and fails to parse with all sorts of errors for "Global property", "Unnamed property", and "Duplicate property". Find: \/\*\*([^@]+)(@copyright) Replace: /*!$1$2 * Indented blocks are considered code examples. A few methods had documentation with numbered lists that were indented, which have now been updated to not be intended. * The free-form text descriptions are parsed with Markdown, which requires lists to be separated from paragraphs by an empty line. And we should use `backticks` instead of {braces} for inline code in text paragraphs. * Doc blocks for classes and their constructor have to be in the correct order (@constructor, @param, @return must be before @class, @abstract, @extends etc.) * `@extends Class` must not have Class {wrapped} * @throws must start with a {Type} * @example means something else. It is used for an inline demo iframe, not code block. For that simply indent with spaces. * @member means something else. Non-function properties are marked with @property, not @member. * To create a link to a class or member, in most cases the name is enough to create a link. E.g. Foo, Foo.bar, Foo.bar#quux, where a hash stands for "instance member", so Foo.bar#quux, links to Foo.bar.prototype.quux (the is not supported, as "prototype" is considered an implementation detail, it only indexes class name and method name). If the magic linker doesn't work for some case, the verbose syntax is {@link #target label}. * @property can't have sub-properties (nested @param and @return values are supported, only @static @property can't be nested). We only have one case of this, which can be worked around by moving those in a new virtual class. The code is unaltered (only moved down so that it isn't with the scope of the main @class block). ve.dm.TransactionProcessor.processors. New: * @mixins: Classes mixed into the current class. * @event: Events that can be emitted by a class. These are also inherited by subclasses. (+ @param, @return and @preventable). So ve.Node#event-attach is inherited to ve.dm.BreakNode, just like @method is. * @singleton: Plain objects such as ve, ve.dm, ve.ce were missing documentation causing a tree error. Documented those as a JSDuck singleton, which they but just weren't documented yet. NB: Members of @singleton don't need @static (if present, triggers a compiler warning). * @chainable: Shorthand for "@return this". We were using "@return {classname}" which is ambiguous (returns the same instance or another instance?), @chainable is specifically for "@return this". Creates proper labels in the generated HTML pages. Removed: * @mixin: (not to be confused with @mixins). Not supported by JSDuck. Every class is standalone anyway. Where needed marked them @class + @abstract instead. Change-Id: I6a7c9e8ee8f995731bc205d666167874eb2ebe23
2013-01-04 08:54:17 +00:00
/* Methods */
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
/**
* Convert arrays of shorthand annotations in a data fragment to AnnotationSets with real
* annotation objects.
*
* Shorthand notation for annotations is:
* [ 'a', [ { 'type': 'link', 'data': { 'href': '...' }, 'htmlTagName': 'a', 'htmlAttributes': { ... } } ] ]
*
* The actual storage format has an instance of ve.dm.LinkAnnotation instead of the plain object,
* and an instance of ve.AnnotationSet instead of the array.
*
JSDuck: Generated code documentation! See CODING.md for how to run it. Mistakes fixed: * Warning: Unknown type function -> Function * Warning: Unknown type DOMElement -> HTMLElement * Warning: Unknown type DOM Node -> HTMLElement * Warning: Unknown type Integer -> Mixed * Warning: Unknown type Command -> ve.Command * Warning: Unknown type any -> number * Warning: Unknown type ve.Transaction -> ve.dm.Transaction * Warning: Unknown type ve.dm.AnnotationSet -> ve.AnnotationSet * Warning: Unknown type false -> boolean * Warning: Unknown type ve.dm.AlienNode ve.dm doesn't have a generic AlienNode like ve.ce -> Unknown type ve.dm.AlienInlineNode|ve.dm.AlienBlockNode * Warning: Unknown type ve.ve.Surface -> ve.ce.Surface * ve.example.lookupNode: -> Last @param should be @return * ve.dm.Transaction.prototype.pushReplace: -> @param {Array] should be @param {Array} * Warning: ve.BranchNode.js:27: {@link ve.Node#hasChildren} links to non-existing member -> (removed) * Warning: ve.LeafNode.js:21: {@link ve.Node#hasChildren} links to non-existing member -> (removed) Differences fixed: * Variadic arguments are like @param {Type...} [name] instead of @param {Type} [name...] * Convert all file headers from /** to /*! because JSDuck tries to parse all /** blocks and fails to parse with all sorts of errors for "Global property", "Unnamed property", and "Duplicate property". Find: \/\*\*([^@]+)(@copyright) Replace: /*!$1$2 * Indented blocks are considered code examples. A few methods had documentation with numbered lists that were indented, which have now been updated to not be intended. * The free-form text descriptions are parsed with Markdown, which requires lists to be separated from paragraphs by an empty line. And we should use `backticks` instead of {braces} for inline code in text paragraphs. * Doc blocks for classes and their constructor have to be in the correct order (@constructor, @param, @return must be before @class, @abstract, @extends etc.) * `@extends Class` must not have Class {wrapped} * @throws must start with a {Type} * @example means something else. It is used for an inline demo iframe, not code block. For that simply indent with spaces. * @member means something else. Non-function properties are marked with @property, not @member. * To create a link to a class or member, in most cases the name is enough to create a link. E.g. Foo, Foo.bar, Foo.bar#quux, where a hash stands for "instance member", so Foo.bar#quux, links to Foo.bar.prototype.quux (the is not supported, as "prototype" is considered an implementation detail, it only indexes class name and method name). If the magic linker doesn't work for some case, the verbose syntax is {@link #target label}. * @property can't have sub-properties (nested @param and @return values are supported, only @static @property can't be nested). We only have one case of this, which can be worked around by moving those in a new virtual class. The code is unaltered (only moved down so that it isn't with the scope of the main @class block). ve.dm.TransactionProcessor.processors. New: * @mixins: Classes mixed into the current class. * @event: Events that can be emitted by a class. These are also inherited by subclasses. (+ @param, @return and @preventable). So ve.Node#event-attach is inherited to ve.dm.BreakNode, just like @method is. * @singleton: Plain objects such as ve, ve.dm, ve.ce were missing documentation causing a tree error. Documented those as a JSDuck singleton, which they but just weren't documented yet. NB: Members of @singleton don't need @static (if present, triggers a compiler warning). * @chainable: Shorthand for "@return this". We were using "@return {classname}" which is ambiguous (returns the same instance or another instance?), @chainable is specifically for "@return this". Creates proper labels in the generated HTML pages. Removed: * @mixin: (not to be confused with @mixins). Not supported by JSDuck. Every class is standalone anyway. Where needed marked them @class + @abstract instead. Change-Id: I6a7c9e8ee8f995731bc205d666167874eb2ebe23
2013-01-04 08:54:17 +00:00
* @method
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
* @param {Array} data Linear model data. Will be modified.
*/
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
ve.dm.example.preprocessAnnotations = function ( data ) {
var i, key;
for ( i = 0; i < data.length; i++ ) {
key = data[i].annotations ? 'annotations' : 1;
if ( ve.isArray( data[i][key] ) ) {
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
data[i][key] = ve.dm.example.createAnnotationSet( data[i][key] );
}
}
};
/**
* Create an annotation object from shorthand notation.
JSDuck: Generated code documentation! See CODING.md for how to run it. Mistakes fixed: * Warning: Unknown type function -> Function * Warning: Unknown type DOMElement -> HTMLElement * Warning: Unknown type DOM Node -> HTMLElement * Warning: Unknown type Integer -> Mixed * Warning: Unknown type Command -> ve.Command * Warning: Unknown type any -> number * Warning: Unknown type ve.Transaction -> ve.dm.Transaction * Warning: Unknown type ve.dm.AnnotationSet -> ve.AnnotationSet * Warning: Unknown type false -> boolean * Warning: Unknown type ve.dm.AlienNode ve.dm doesn't have a generic AlienNode like ve.ce -> Unknown type ve.dm.AlienInlineNode|ve.dm.AlienBlockNode * Warning: Unknown type ve.ve.Surface -> ve.ce.Surface * ve.example.lookupNode: -> Last @param should be @return * ve.dm.Transaction.prototype.pushReplace: -> @param {Array] should be @param {Array} * Warning: ve.BranchNode.js:27: {@link ve.Node#hasChildren} links to non-existing member -> (removed) * Warning: ve.LeafNode.js:21: {@link ve.Node#hasChildren} links to non-existing member -> (removed) Differences fixed: * Variadic arguments are like @param {Type...} [name] instead of @param {Type} [name...] * Convert all file headers from /** to /*! because JSDuck tries to parse all /** blocks and fails to parse with all sorts of errors for "Global property", "Unnamed property", and "Duplicate property". Find: \/\*\*([^@]+)(@copyright) Replace: /*!$1$2 * Indented blocks are considered code examples. A few methods had documentation with numbered lists that were indented, which have now been updated to not be intended. * The free-form text descriptions are parsed with Markdown, which requires lists to be separated from paragraphs by an empty line. And we should use `backticks` instead of {braces} for inline code in text paragraphs. * Doc blocks for classes and their constructor have to be in the correct order (@constructor, @param, @return must be before @class, @abstract, @extends etc.) * `@extends Class` must not have Class {wrapped} * @throws must start with a {Type} * @example means something else. It is used for an inline demo iframe, not code block. For that simply indent with spaces. * @member means something else. Non-function properties are marked with @property, not @member. * To create a link to a class or member, in most cases the name is enough to create a link. E.g. Foo, Foo.bar, Foo.bar#quux, where a hash stands for "instance member", so Foo.bar#quux, links to Foo.bar.prototype.quux (the is not supported, as "prototype" is considered an implementation detail, it only indexes class name and method name). If the magic linker doesn't work for some case, the verbose syntax is {@link #target label}. * @property can't have sub-properties (nested @param and @return values are supported, only @static @property can't be nested). We only have one case of this, which can be worked around by moving those in a new virtual class. The code is unaltered (only moved down so that it isn't with the scope of the main @class block). ve.dm.TransactionProcessor.processors. New: * @mixins: Classes mixed into the current class. * @event: Events that can be emitted by a class. These are also inherited by subclasses. (+ @param, @return and @preventable). So ve.Node#event-attach is inherited to ve.dm.BreakNode, just like @method is. * @singleton: Plain objects such as ve, ve.dm, ve.ce were missing documentation causing a tree error. Documented those as a JSDuck singleton, which they but just weren't documented yet. NB: Members of @singleton don't need @static (if present, triggers a compiler warning). * @chainable: Shorthand for "@return this". We were using "@return {classname}" which is ambiguous (returns the same instance or another instance?), @chainable is specifically for "@return this". Creates proper labels in the generated HTML pages. Removed: * @mixin: (not to be confused with @mixins). Not supported by JSDuck. Every class is standalone anyway. Where needed marked them @class + @abstract instead. Change-Id: I6a7c9e8ee8f995731bc205d666167874eb2ebe23
2013-01-04 08:54:17 +00:00
* @method
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
* @param {Object} annotation Plain object with type, data, htmlTagName and htmlAttributes properties
* @return {ve.dm.Annotation} Instance of the right ve.dm.Annotation subclass
*/
ve.dm.example.createAnnotation = function ( annotation ) {
var ann, annKey;
ann = ve.dm.annotationFactory.create( annotation.type );
for ( annKey in annotation ) {
if ( annKey !== 'type' ) {
ann[annKey] = annotation[annKey];
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
}
}
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
return ann;
};
/**
* Create an AnnotationSet from an array of shorthand annotations.
*
* This calls ve.dm.example.createAnnotation() for each element and puts the result in an
* AnnotationSet.
*
JSDuck: Generated code documentation! See CODING.md for how to run it. Mistakes fixed: * Warning: Unknown type function -> Function * Warning: Unknown type DOMElement -> HTMLElement * Warning: Unknown type DOM Node -> HTMLElement * Warning: Unknown type Integer -> Mixed * Warning: Unknown type Command -> ve.Command * Warning: Unknown type any -> number * Warning: Unknown type ve.Transaction -> ve.dm.Transaction * Warning: Unknown type ve.dm.AnnotationSet -> ve.AnnotationSet * Warning: Unknown type false -> boolean * Warning: Unknown type ve.dm.AlienNode ve.dm doesn't have a generic AlienNode like ve.ce -> Unknown type ve.dm.AlienInlineNode|ve.dm.AlienBlockNode * Warning: Unknown type ve.ve.Surface -> ve.ce.Surface * ve.example.lookupNode: -> Last @param should be @return * ve.dm.Transaction.prototype.pushReplace: -> @param {Array] should be @param {Array} * Warning: ve.BranchNode.js:27: {@link ve.Node#hasChildren} links to non-existing member -> (removed) * Warning: ve.LeafNode.js:21: {@link ve.Node#hasChildren} links to non-existing member -> (removed) Differences fixed: * Variadic arguments are like @param {Type...} [name] instead of @param {Type} [name...] * Convert all file headers from /** to /*! because JSDuck tries to parse all /** blocks and fails to parse with all sorts of errors for "Global property", "Unnamed property", and "Duplicate property". Find: \/\*\*([^@]+)(@copyright) Replace: /*!$1$2 * Indented blocks are considered code examples. A few methods had documentation with numbered lists that were indented, which have now been updated to not be intended. * The free-form text descriptions are parsed with Markdown, which requires lists to be separated from paragraphs by an empty line. And we should use `backticks` instead of {braces} for inline code in text paragraphs. * Doc blocks for classes and their constructor have to be in the correct order (@constructor, @param, @return must be before @class, @abstract, @extends etc.) * `@extends Class` must not have Class {wrapped} * @throws must start with a {Type} * @example means something else. It is used for an inline demo iframe, not code block. For that simply indent with spaces. * @member means something else. Non-function properties are marked with @property, not @member. * To create a link to a class or member, in most cases the name is enough to create a link. E.g. Foo, Foo.bar, Foo.bar#quux, where a hash stands for "instance member", so Foo.bar#quux, links to Foo.bar.prototype.quux (the is not supported, as "prototype" is considered an implementation detail, it only indexes class name and method name). If the magic linker doesn't work for some case, the verbose syntax is {@link #target label}. * @property can't have sub-properties (nested @param and @return values are supported, only @static @property can't be nested). We only have one case of this, which can be worked around by moving those in a new virtual class. The code is unaltered (only moved down so that it isn't with the scope of the main @class block). ve.dm.TransactionProcessor.processors. New: * @mixins: Classes mixed into the current class. * @event: Events that can be emitted by a class. These are also inherited by subclasses. (+ @param, @return and @preventable). So ve.Node#event-attach is inherited to ve.dm.BreakNode, just like @method is. * @singleton: Plain objects such as ve, ve.dm, ve.ce were missing documentation causing a tree error. Documented those as a JSDuck singleton, which they but just weren't documented yet. NB: Members of @singleton don't need @static (if present, triggers a compiler warning). * @chainable: Shorthand for "@return this". We were using "@return {classname}" which is ambiguous (returns the same instance or another instance?), @chainable is specifically for "@return this". Creates proper labels in the generated HTML pages. Removed: * @mixin: (not to be confused with @mixins). Not supported by JSDuck. Every class is standalone anyway. Where needed marked them @class + @abstract instead. Change-Id: I6a7c9e8ee8f995731bc205d666167874eb2ebe23
2013-01-04 08:54:17 +00:00
* @method
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
* @param {Array} annotations Array of annotations in shorthand format
* @return {ve.AnnotationSet}
*/
ve.dm.example.createAnnotationSet = function ( annotations ) {
var i;
for ( i = 0; i < annotations.length; i++ ) {
annotations[i] = ve.dm.example.createAnnotation( annotations[i] );
}
return new ve.AnnotationSet( annotations );
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
};
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
/* Some common annotations in shorthand format */
ve.dm.example.bold = { 'type': 'textStyle/bold', 'htmlTagName': 'b', 'htmlAttributes': {} };
ve.dm.example.italic = { 'type': 'textStyle/italic', 'htmlTagName': 'i', 'htmlAttributes': {} };
ve.dm.example.underline = { 'type': 'textStyle/underline', 'htmlTagName': 'u', 'htmlAttributes': {} };
(bug 42487) Don't crash the converter for "<span>\n<p>Foo</p></span>" The converter was misbehaving when handling <p>s inside <span>s. This can't be expressed in the linmod, but it would try to anyway. <span><p> would result in too many paragraph closing elements, leading to an exception in ve.dm.Document complaining about unbalanced input. <span>\n<p> would result in an exception in the converter itself while trying to perform whitespace preservation on the newline. This change makes the converter detect these scenarios and alienate the offending node. So <span><p>Foo</p></span> converts to a wrapper paragraph containing an alienInline whose HTML is "<p>Foo</p>" and which is annotated with a TextStyleSpanAnnotation. ve.dm.Converter.getDomFromData(): * Change the criteria for alienBlock vs alienInline ** Only infer from the node type if we're in wrapping mode AND we're at the same level where the wrapping started (wrappingIsOurs). If the latter isn't the case, we can't split the wrapper in the block case because we're at the wrong level. ** Use alienInline not only if the branch is a content branch, but also if there are active annotations. This catches e.g. <li><b><p> (and generally <span><p> on the top level). * Before converting a child element, check that the child isn't "bad". Bad children are non-content children in content branches, and non-content children encountered within a wrapper that we can't split. Only good children are converted, and bad children are alienated (cue Santa/Sinterklaas jokes). * Add childIsContent and rename branchIsContent to branchHasContent Change-Id: If420ae80ab0777424a9a5517335ef9d0170e87ae
2012-12-05 22:35:10 +00:00
ve.dm.example.span = { 'type': 'textStyle/span', 'htmlTagName': 'span', 'htmlAttributes': {} };
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
/**
* Serialized HTML.
Removed trailing whitespace in multi-line comment blocks JSHint and various git tools complain about this, so let's just do away with them altogether Change-Id: I731866bd21f1ee0088fb0a71df3abf92692aca23
2012-05-14 22:05:09 +00:00
*
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
* This is what the parser will emit.
Strip generated <p> tags in dataToDom domToData wraps bare content in paragraph elements, which were then converted to <p> tags by domToData. With this fix, HTML with "missing" <p> tags actually round-trips through the editor correctly now, rather than having <p> tags added wherever VE believes they should exist. * Mark generated paragraph elements with .internal.generated = 'wrapper' ** This signifies the wrapper was generated but its contents were not, so the right thing to do when converting back to HTML is to remove the wrapper and keep the contents. We might want to use other values of generated in the future. * Unwrap nodes with generated=wrapper when converting to HTML Tests: * Add 'generated': 'wrapper' as appropriate. Only affects 1 test * Remove 'normalizedHtml' for this test because it is no longer needed ** Need to keep 'normalizedHtml' for now because we normalize hrefs * Eventually the main example should test bare content, but that requires touching a lot of stuff. The main example could use some beefing up anyway. Change-Id: I277ad5fe3f64e07c1bbf49007d6bbaecc90b7466
2012-08-16 20:06:18 +00:00
* TODO remove some of the <p>s here to test automatic wrapping
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
*/
ve.dm.example.html =
'<h1>a<b>b</b><i>c</i></h1>' +
'<table>' +
'<tr>' +
'<td>' +
'<p>d</p>' +
'<ul>' +
'<li>' +
Kill all but one of the Parsoid compat hacks, we don't need them any more Also remove traces of Parsoid workarounds in tests. Tests are now passing, yay :) Change-Id: I8a59fc92c567c3595849e3e9377ce6eb6acde280
2012-08-03 19:12:09 +00:00
'<p>e</p>' +
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
'<ul>' +
'<li>' +
Kill all but one of the Parsoid compat hacks, we don't need them any more Also remove traces of Parsoid workarounds in tests. Tests are now passing, yay :) Change-Id: I8a59fc92c567c3595849e3e9377ce6eb6acde280
2012-08-03 19:12:09 +00:00
'<p>f</p>' +
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
'</li>' +
'</ul>' +
'</li>' +
'</ul>' +
'<ol>' +
'<li>' +
Kill all but one of the Parsoid compat hacks, we don't need them any more Also remove traces of Parsoid workarounds in tests. Tests are now passing, yay :) Change-Id: I8a59fc92c567c3595849e3e9377ce6eb6acde280
2012-08-03 19:12:09 +00:00
'<p>g</p>' +
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
'</li>' +
'</ol>' +
'</td>' +
'</tr>' +
'</table>' +
Split Broke DefinitionListNode out of ListNode and DefinitionListItemNode out of ListItemNode * Makes it simpler in the linear model because we don't have to use style: "item" for regular list items and style: "definition" for definition lists * Enforces correct nesting through existing node rules systems * Updates tests accordingly Change-Id: I64d80af938e325f1961226505bdc386bb35ccdda
2012-05-04 18:56:32 +00:00
'<pre>h<img src="image.png">i</pre>'+
'<dl>' +
'<dt>' +
'<p>j</p>' +
'</dt>' +
'<dd>' +
'<p>k</p>' +
'</dd>' +
Added merge test for ve.dm.TransactionProcessor Also added 2 paragraphs at the end of the example document and updated related tests accordingly Change-Id: Idd294cbe3975d0a04069e55682a91417160e538a
2012-05-16 20:33:27 +00:00
'</dl>' +
'<p>l</p>' +
'<p>m</p>';
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
/*
* Linear data.
Removed trailing whitespace in multi-line comment blocks JSHint and various git tools complain about this, so let's just do away with them altogether Change-Id: I731866bd21f1ee0088fb0a71df3abf92692aca23
2012-05-14 22:05:09 +00:00
*
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
* This is what we convert serialized HTML from the parser into so we can work with it more easily.
Removed trailing whitespace in multi-line comment blocks JSHint and various git tools complain about this, so let's just do away with them altogether Change-Id: I731866bd21f1ee0088fb0a71df3abf92692aca23
2012-05-14 22:05:09 +00:00
*
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
* There are three types of components in content data:
Removed trailing whitespace in multi-line comment blocks JSHint and various git tools complain about this, so let's just do away with them altogether Change-Id: I731866bd21f1ee0088fb0a71df3abf92692aca23
2012-05-14 22:05:09 +00:00
*
JSDuck: Generated code documentation! See CODING.md for how to run it. Mistakes fixed: * Warning: Unknown type function -> Function * Warning: Unknown type DOMElement -> HTMLElement * Warning: Unknown type DOM Node -> HTMLElement * Warning: Unknown type Integer -> Mixed * Warning: Unknown type Command -> ve.Command * Warning: Unknown type any -> number * Warning: Unknown type ve.Transaction -> ve.dm.Transaction * Warning: Unknown type ve.dm.AnnotationSet -> ve.AnnotationSet * Warning: Unknown type false -> boolean * Warning: Unknown type ve.dm.AlienNode ve.dm doesn't have a generic AlienNode like ve.ce -> Unknown type ve.dm.AlienInlineNode|ve.dm.AlienBlockNode * Warning: Unknown type ve.ve.Surface -> ve.ce.Surface * ve.example.lookupNode: -> Last @param should be @return * ve.dm.Transaction.prototype.pushReplace: -> @param {Array] should be @param {Array} * Warning: ve.BranchNode.js:27: {@link ve.Node#hasChildren} links to non-existing member -> (removed) * Warning: ve.LeafNode.js:21: {@link ve.Node#hasChildren} links to non-existing member -> (removed) Differences fixed: * Variadic arguments are like @param {Type...} [name] instead of @param {Type} [name...] * Convert all file headers from /** to /*! because JSDuck tries to parse all /** blocks and fails to parse with all sorts of errors for "Global property", "Unnamed property", and "Duplicate property". Find: \/\*\*([^@]+)(@copyright) Replace: /*!$1$2 * Indented blocks are considered code examples. A few methods had documentation with numbered lists that were indented, which have now been updated to not be intended. * The free-form text descriptions are parsed with Markdown, which requires lists to be separated from paragraphs by an empty line. And we should use `backticks` instead of {braces} for inline code in text paragraphs. * Doc blocks for classes and their constructor have to be in the correct order (@constructor, @param, @return must be before @class, @abstract, @extends etc.) * `@extends Class` must not have Class {wrapped} * @throws must start with a {Type} * @example means something else. It is used for an inline demo iframe, not code block. For that simply indent with spaces. * @member means something else. Non-function properties are marked with @property, not @member. * To create a link to a class or member, in most cases the name is enough to create a link. E.g. Foo, Foo.bar, Foo.bar#quux, where a hash stands for "instance member", so Foo.bar#quux, links to Foo.bar.prototype.quux (the is not supported, as "prototype" is considered an implementation detail, it only indexes class name and method name). If the magic linker doesn't work for some case, the verbose syntax is {@link #target label}. * @property can't have sub-properties (nested @param and @return values are supported, only @static @property can't be nested). We only have one case of this, which can be worked around by moving those in a new virtual class. The code is unaltered (only moved down so that it isn't with the scope of the main @class block). ve.dm.TransactionProcessor.processors. New: * @mixins: Classes mixed into the current class. * @event: Events that can be emitted by a class. These are also inherited by subclasses. (+ @param, @return and @preventable). So ve.Node#event-attach is inherited to ve.dm.BreakNode, just like @method is. * @singleton: Plain objects such as ve, ve.dm, ve.ce were missing documentation causing a tree error. Documented those as a JSDuck singleton, which they but just weren't documented yet. NB: Members of @singleton don't need @static (if present, triggers a compiler warning). * @chainable: Shorthand for "@return this". We were using "@return {classname}" which is ambiguous (returns the same instance or another instance?), @chainable is specifically for "@return this". Creates proper labels in the generated HTML pages. Removed: * @mixin: (not to be confused with @mixins). Not supported by JSDuck. Every class is standalone anyway. Where needed marked them @class + @abstract instead. Change-Id: I6a7c9e8ee8f995731bc205d666167874eb2ebe23
2013-01-04 08:54:17 +00:00
* {string} Plain text character
Removed more trailing whitespace in multi-line comment blocks Continues cleanup work done in e0de881a8a102155f8e4b0a1e5226e7adaeba80f Change-Id: I7165a8f8c4b468793d936fe695de92335c106271
2012-05-15 00:15:28 +00:00
*
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
* {Array} Annotated character
JSDuck: Generated code documentation! See CODING.md for how to run it. Mistakes fixed: * Warning: Unknown type function -> Function * Warning: Unknown type DOMElement -> HTMLElement * Warning: Unknown type DOM Node -> HTMLElement * Warning: Unknown type Integer -> Mixed * Warning: Unknown type Command -> ve.Command * Warning: Unknown type any -> number * Warning: Unknown type ve.Transaction -> ve.dm.Transaction * Warning: Unknown type ve.dm.AnnotationSet -> ve.AnnotationSet * Warning: Unknown type false -> boolean * Warning: Unknown type ve.dm.AlienNode ve.dm doesn't have a generic AlienNode like ve.ce -> Unknown type ve.dm.AlienInlineNode|ve.dm.AlienBlockNode * Warning: Unknown type ve.ve.Surface -> ve.ce.Surface * ve.example.lookupNode: -> Last @param should be @return * ve.dm.Transaction.prototype.pushReplace: -> @param {Array] should be @param {Array} * Warning: ve.BranchNode.js:27: {@link ve.Node#hasChildren} links to non-existing member -> (removed) * Warning: ve.LeafNode.js:21: {@link ve.Node#hasChildren} links to non-existing member -> (removed) Differences fixed: * Variadic arguments are like @param {Type...} [name] instead of @param {Type} [name...] * Convert all file headers from /** to /*! because JSDuck tries to parse all /** blocks and fails to parse with all sorts of errors for "Global property", "Unnamed property", and "Duplicate property". Find: \/\*\*([^@]+)(@copyright) Replace: /*!$1$2 * Indented blocks are considered code examples. A few methods had documentation with numbered lists that were indented, which have now been updated to not be intended. * The free-form text descriptions are parsed with Markdown, which requires lists to be separated from paragraphs by an empty line. And we should use `backticks` instead of {braces} for inline code in text paragraphs. * Doc blocks for classes and their constructor have to be in the correct order (@constructor, @param, @return must be before @class, @abstract, @extends etc.) * `@extends Class` must not have Class {wrapped} * @throws must start with a {Type} * @example means something else. It is used for an inline demo iframe, not code block. For that simply indent with spaces. * @member means something else. Non-function properties are marked with @property, not @member. * To create a link to a class or member, in most cases the name is enough to create a link. E.g. Foo, Foo.bar, Foo.bar#quux, where a hash stands for "instance member", so Foo.bar#quux, links to Foo.bar.prototype.quux (the is not supported, as "prototype" is considered an implementation detail, it only indexes class name and method name). If the magic linker doesn't work for some case, the verbose syntax is {@link #target label}. * @property can't have sub-properties (nested @param and @return values are supported, only @static @property can't be nested). We only have one case of this, which can be worked around by moving those in a new virtual class. The code is unaltered (only moved down so that it isn't with the scope of the main @class block). ve.dm.TransactionProcessor.processors. New: * @mixins: Classes mixed into the current class. * @event: Events that can be emitted by a class. These are also inherited by subclasses. (+ @param, @return and @preventable). So ve.Node#event-attach is inherited to ve.dm.BreakNode, just like @method is. * @singleton: Plain objects such as ve, ve.dm, ve.ce were missing documentation causing a tree error. Documented those as a JSDuck singleton, which they but just weren't documented yet. NB: Members of @singleton don't need @static (if present, triggers a compiler warning). * @chainable: Shorthand for "@return this". We were using "@return {classname}" which is ambiguous (returns the same instance or another instance?), @chainable is specifically for "@return this". Creates proper labels in the generated HTML pages. Removed: * @mixin: (not to be confused with @mixins). Not supported by JSDuck. Every class is standalone anyway. Where needed marked them @class + @abstract instead. Change-Id: I6a7c9e8ee8f995731bc205d666167874eb2ebe23
2013-01-04 08:54:17 +00:00
* 0: {string} Character
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
* 1: {Object} List of references to immutable annotation objects, keyed by JSON
* serializations of their values (hashes)
Removed more trailing whitespace in multi-line comment blocks Continues cleanup work done in e0de881a8a102155f8e4b0a1e5226e7adaeba80f Change-Id: I7165a8f8c4b468793d936fe695de92335c106271
2012-05-15 00:15:28 +00:00
*
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
* {Object} Opening or closing structural element
JSDuck: Generated code documentation! See CODING.md for how to run it. Mistakes fixed: * Warning: Unknown type function -> Function * Warning: Unknown type DOMElement -> HTMLElement * Warning: Unknown type DOM Node -> HTMLElement * Warning: Unknown type Integer -> Mixed * Warning: Unknown type Command -> ve.Command * Warning: Unknown type any -> number * Warning: Unknown type ve.Transaction -> ve.dm.Transaction * Warning: Unknown type ve.dm.AnnotationSet -> ve.AnnotationSet * Warning: Unknown type false -> boolean * Warning: Unknown type ve.dm.AlienNode ve.dm doesn't have a generic AlienNode like ve.ce -> Unknown type ve.dm.AlienInlineNode|ve.dm.AlienBlockNode * Warning: Unknown type ve.ve.Surface -> ve.ce.Surface * ve.example.lookupNode: -> Last @param should be @return * ve.dm.Transaction.prototype.pushReplace: -> @param {Array] should be @param {Array} * Warning: ve.BranchNode.js:27: {@link ve.Node#hasChildren} links to non-existing member -> (removed) * Warning: ve.LeafNode.js:21: {@link ve.Node#hasChildren} links to non-existing member -> (removed) Differences fixed: * Variadic arguments are like @param {Type...} [name] instead of @param {Type} [name...] * Convert all file headers from /** to /*! because JSDuck tries to parse all /** blocks and fails to parse with all sorts of errors for "Global property", "Unnamed property", and "Duplicate property". Find: \/\*\*([^@]+)(@copyright) Replace: /*!$1$2 * Indented blocks are considered code examples. A few methods had documentation with numbered lists that were indented, which have now been updated to not be intended. * The free-form text descriptions are parsed with Markdown, which requires lists to be separated from paragraphs by an empty line. And we should use `backticks` instead of {braces} for inline code in text paragraphs. * Doc blocks for classes and their constructor have to be in the correct order (@constructor, @param, @return must be before @class, @abstract, @extends etc.) * `@extends Class` must not have Class {wrapped} * @throws must start with a {Type} * @example means something else. It is used for an inline demo iframe, not code block. For that simply indent with spaces. * @member means something else. Non-function properties are marked with @property, not @member. * To create a link to a class or member, in most cases the name is enough to create a link. E.g. Foo, Foo.bar, Foo.bar#quux, where a hash stands for "instance member", so Foo.bar#quux, links to Foo.bar.prototype.quux (the is not supported, as "prototype" is considered an implementation detail, it only indexes class name and method name). If the magic linker doesn't work for some case, the verbose syntax is {@link #target label}. * @property can't have sub-properties (nested @param and @return values are supported, only @static @property can't be nested). We only have one case of this, which can be worked around by moving those in a new virtual class. The code is unaltered (only moved down so that it isn't with the scope of the main @class block). ve.dm.TransactionProcessor.processors. New: * @mixins: Classes mixed into the current class. * @event: Events that can be emitted by a class. These are also inherited by subclasses. (+ @param, @return and @preventable). So ve.Node#event-attach is inherited to ve.dm.BreakNode, just like @method is. * @singleton: Plain objects such as ve, ve.dm, ve.ce were missing documentation causing a tree error. Documented those as a JSDuck singleton, which they but just weren't documented yet. NB: Members of @singleton don't need @static (if present, triggers a compiler warning). * @chainable: Shorthand for "@return this". We were using "@return {classname}" which is ambiguous (returns the same instance or another instance?), @chainable is specifically for "@return this". Creates proper labels in the generated HTML pages. Removed: * @mixin: (not to be confused with @mixins). Not supported by JSDuck. Every class is standalone anyway. Where needed marked them @class + @abstract instead. Change-Id: I6a7c9e8ee8f995731bc205d666167874eb2ebe23
2013-01-04 08:54:17 +00:00
* type: {string} Symbolic node type name, if closing element first character will be "/"
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
* [attributes]: {Object} List of symbolic attribute name and literal value pairs
*/
ve.dm.example.data = [
// 0 - Beginning of heading
{ 'type': 'heading', 'attributes': { 'level': 1 } },
// 1 - Plain "a"
'a',
// 2 - Bold "b"
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
['b', [ ve.dm.example.bold ]],
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
// 3 - Italic "c"
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
['c', [ ve.dm.example.italic ]],
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
// 4 - End of heading
{ 'type': '/heading' },
// 5 - Beginning of table
{ 'type': 'table' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 6 - Beginning of body
{ 'type': 'tableSection', 'attributes': { 'style': 'body' } },
// 7 - Beginning of row
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
{ 'type': 'tableRow' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 8 - Beginning of cell
Make tableCell represent both <td> and <th> Adding a 'style' attribute which is set to either 'data' or 'header' This breaks even more tests because of missing style attributes Change-Id: I0a75d8c1578b4414eeae8c484f6c4d6f8a59472a
2012-06-08 05:02:25 +00:00
{ 'type': 'tableCell', 'attributes': { 'style': 'data' } },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 9 - Beginning of paragraph
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
{ 'type': 'paragraph' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 10 - Plain "d"
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
'd',
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 11 - End of paragraph
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
{ 'type': '/paragraph' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 12 - Beginning of bullet list
Fixed mistakes in the linear and tree example models Change-Id: Id19ac7b2efb5c5f3147a4abf5e62fab3044b5fd7
2012-05-03 21:54:27 +00:00
{ 'type': 'list', 'attributes': { 'style': 'bullet' } },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 13 - Beginning of list item
Removed unused attributes in example data Change-Id: I0ce52456113e6efc5d879041270e06fd0b6bdebe
2012-05-04 22:50:32 +00:00
{ 'type': 'listItem' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 14 - Beginning of paragraph
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
{ 'type': 'paragraph' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 15 - Plain "e"
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
'e',
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 16 - End of paragraph
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
{ 'type': '/paragraph' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 17 - Beginning of nested bullet list
Fixed mistakes in the linear and tree example models Change-Id: Id19ac7b2efb5c5f3147a4abf5e62fab3044b5fd7
2012-05-03 21:54:27 +00:00
{ 'type': 'list', 'attributes': { 'style': 'bullet' } },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 18 - Beginning of nested bullet list item
Remainder JSHint fixes on modules/ve/* [jshint] ce/ve.ce.Surface.js: line 670, col 9, Too many var statements. ce/ve.ce.Surface.js: line 695, col 6, Missing semicolon. ce/ve.ce.Surface.js: line 726, col 22, Expected '===' and instead saw '=='. ce/ve.ce.Surface.js: line 726, col 41, Expected '===' and instead saw '=='. ce/ve.ce.Surface.js: line 733, col 13, Too many var statements. ce/ve.ce.Surface.js: line 734, col 24, Expected '===' and instead saw '=='. ce/ve.ce.Surface.js: line 1013, col 13, Too many var statements. ce/ve.ce.Surface.js: line 1019, col 17, Too many var statements. ce/ve.ce.Surface.js: line 1023, col 18, Too many ar statements. ce/ve.ce.Surface.js: line 1027, col 13, Too many var statements. dm/annotations/ve.dm.LinkAnnotation.js: line 70, col 52, Insecure '.'. dm/ve.dm.Converter.js: line 383, col 29, Empty block. dm/ve.dm.Converter.js: line 423, col 33, Empty block. Commands: * jshint . * ack '(if|else|function|switch|for|while)\(' * Sublime Text 2: Find(*): (if|else|function|switch|for|while)\( Replace: $1 ( * ack ' ' -Q # double spaces, except in certain comments Change-Id: I8e34bf2924bc8688fdf8acef08bbc4f6707e93be
2012-09-02 21:45:01 +00:00
{ 'type': 'listItem' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 19 - Beginning of paragraph
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
{ 'type': 'paragraph' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 20 - Plain "f"
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
'f',
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 21 - End of paragraph
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
{ 'type': '/paragraph' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 22 - End of nested bullet list item
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
{ 'type': '/listItem' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 23 - End of nested bullet list
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
{ 'type': '/list' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 24 - End of bullet list item
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
{ 'type': '/listItem' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 25 - End of bullet list
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
{ 'type': '/list' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 26 - Beginning of numbered list
Fixed mistakes in the linear and tree example models Change-Id: Id19ac7b2efb5c5f3147a4abf5e62fab3044b5fd7
2012-05-03 21:54:27 +00:00
{ 'type': 'list', 'attributes': { 'style': 'number' } },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 27 - Beginning of numbered list item
Removed unused attributes in example data Change-Id: I0ce52456113e6efc5d879041270e06fd0b6bdebe
2012-05-04 22:50:32 +00:00
{ 'type': 'listItem' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 28 - Beginning of paragraph
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
{ 'type': 'paragraph' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 29 - Plain "g"
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
'g',
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 30 - End of paragraph
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
{ 'type': '/paragraph' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 31 - End of item
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
{ 'type': '/listItem' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 32 - End of list
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
{ 'type': '/list' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 33 - End of cell
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
{ 'type': '/tableCell' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 34 - End of row
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
{ 'type': '/tableRow' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 35 - End of body
{ 'type': '/tableSection' },
// 36 - End of table
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
{ 'type': '/table' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 37 - Beginning of preformatted
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
{ 'type': 'preformatted' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 38 - Plain "h"
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
'h',
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 39 - Beginning of inline image
Change the HTML attribute prefix from html/ to html/0/ This means that <p data-foo="bar"> will now be converted to a paragraph with attributes {"html/0/data-foo":"bar"} rather than {"html/foo":"bar"} This paves the way for multi-element node (about group) handling in the node API: nodes representing multiple DOM elements will have html/i/attr to represent an attribute of the i'th DOM element. Change-Id: Iea52bdccd721942ca708c8f9f47e934524809845
2013-02-06 19:47:52 +00:00
{ 'type': 'image', 'attributes': { 'html/0/src': 'image.png' } },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 40 - End of inline image
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
{ 'type': '/image' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 41 - Plain "i"
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
'i',
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 42 - End of preformatted
Split Broke DefinitionListNode out of ListNode and DefinitionListItemNode out of ListItemNode * Makes it simpler in the linear model because we don't have to use style: "item" for regular list items and style: "definition" for definition lists * Enforces correct nesting through existing node rules systems * Updates tests accordingly Change-Id: I64d80af938e325f1961226505bdc386bb35ccdda
2012-05-04 18:56:32 +00:00
{ 'type': '/preformatted' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 43 - Beginning of definition list
Split Broke DefinitionListNode out of ListNode and DefinitionListItemNode out of ListItemNode * Makes it simpler in the linear model because we don't have to use style: "item" for regular list items and style: "definition" for definition lists * Enforces correct nesting through existing node rules systems * Updates tests accordingly Change-Id: I64d80af938e325f1961226505bdc386bb35ccdda
2012-05-04 18:56:32 +00:00
{ 'type': 'definitionList' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 44 - Beginning of definition list term item
Split Broke DefinitionListNode out of ListNode and DefinitionListItemNode out of ListItemNode * Makes it simpler in the linear model because we don't have to use style: "item" for regular list items and style: "definition" for definition lists * Enforces correct nesting through existing node rules systems * Updates tests accordingly Change-Id: I64d80af938e325f1961226505bdc386bb35ccdda
2012-05-04 18:56:32 +00:00
{ 'type': 'definitionListItem', 'attributes': { 'style': 'term' } },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 45 - Beginning of paragraph
Split Broke DefinitionListNode out of ListNode and DefinitionListItemNode out of ListItemNode * Makes it simpler in the linear model because we don't have to use style: "item" for regular list items and style: "definition" for definition lists * Enforces correct nesting through existing node rules systems * Updates tests accordingly Change-Id: I64d80af938e325f1961226505bdc386bb35ccdda
2012-05-04 18:56:32 +00:00
{ 'type': 'paragraph' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 46 - Plain "j"
Split Broke DefinitionListNode out of ListNode and DefinitionListItemNode out of ListItemNode * Makes it simpler in the linear model because we don't have to use style: "item" for regular list items and style: "definition" for definition lists * Enforces correct nesting through existing node rules systems * Updates tests accordingly Change-Id: I64d80af938e325f1961226505bdc386bb35ccdda
2012-05-04 18:56:32 +00:00
'j',
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 47 - End of paragraph
Split Broke DefinitionListNode out of ListNode and DefinitionListItemNode out of ListItemNode * Makes it simpler in the linear model because we don't have to use style: "item" for regular list items and style: "definition" for definition lists * Enforces correct nesting through existing node rules systems * Updates tests accordingly Change-Id: I64d80af938e325f1961226505bdc386bb35ccdda
2012-05-04 18:56:32 +00:00
{ 'type': '/paragraph' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 48 - End of definition list term item
Split Broke DefinitionListNode out of ListNode and DefinitionListItemNode out of ListItemNode * Makes it simpler in the linear model because we don't have to use style: "item" for regular list items and style: "definition" for definition lists * Enforces correct nesting through existing node rules systems * Updates tests accordingly Change-Id: I64d80af938e325f1961226505bdc386bb35ccdda
2012-05-04 18:56:32 +00:00
{ 'type': '/definitionListItem' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 49 - Beginning of definition list definition item
Split Broke DefinitionListNode out of ListNode and DefinitionListItemNode out of ListItemNode * Makes it simpler in the linear model because we don't have to use style: "item" for regular list items and style: "definition" for definition lists * Enforces correct nesting through existing node rules systems * Updates tests accordingly Change-Id: I64d80af938e325f1961226505bdc386bb35ccdda
2012-05-04 18:56:32 +00:00
{ 'type': 'definitionListItem', 'attributes': { 'style': 'definition' } },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 50 - Beginning of paragraph
Split Broke DefinitionListNode out of ListNode and DefinitionListItemNode out of ListItemNode * Makes it simpler in the linear model because we don't have to use style: "item" for regular list items and style: "definition" for definition lists * Enforces correct nesting through existing node rules systems * Updates tests accordingly Change-Id: I64d80af938e325f1961226505bdc386bb35ccdda
2012-05-04 18:56:32 +00:00
{ 'type': 'paragraph' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 51 - Plain "k"
Write better test for DocumentFragment getAnnotationsFromOffset Fix errors in example test data Remove whitespace Change-Id: Ibb2b5c0851d6abac9974035753b95354b3c8dd5e
2012-05-11 17:29:09 +00:00
'k',
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 52 - End of paragraph
Split Broke DefinitionListNode out of ListNode and DefinitionListItemNode out of ListItemNode * Makes it simpler in the linear model because we don't have to use style: "item" for regular list items and style: "definition" for definition lists * Enforces correct nesting through existing node rules systems * Updates tests accordingly Change-Id: I64d80af938e325f1961226505bdc386bb35ccdda
2012-05-04 18:56:32 +00:00
{ 'type': '/paragraph' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 53 - End of definition list definition item
Split Broke DefinitionListNode out of ListNode and DefinitionListItemNode out of ListItemNode * Makes it simpler in the linear model because we don't have to use style: "item" for regular list items and style: "definition" for definition lists * Enforces correct nesting through existing node rules systems * Updates tests accordingly Change-Id: I64d80af938e325f1961226505bdc386bb35ccdda
2012-05-04 18:56:32 +00:00
{ 'type': '/definitionListItem' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 54 - End of definition list
Added merge test for ve.dm.TransactionProcessor Also added 2 paragraphs at the end of the example document and updated related tests accordingly Change-Id: Idd294cbe3975d0a04069e55682a91417160e538a
2012-05-16 20:33:27 +00:00
{ 'type': '/definitionList' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 55 - Beginning of paragraph
Added merge test for ve.dm.TransactionProcessor Also added 2 paragraphs at the end of the example document and updated related tests accordingly Change-Id: Idd294cbe3975d0a04069e55682a91417160e538a
2012-05-16 20:33:27 +00:00
{ 'type': 'paragraph' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 56 - Plain "l"
Added merge test for ve.dm.TransactionProcessor Also added 2 paragraphs at the end of the example document and updated related tests accordingly Change-Id: Idd294cbe3975d0a04069e55682a91417160e538a
2012-05-16 20:33:27 +00:00
'l',
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 57 - End of paragraph
Added merge test for ve.dm.TransactionProcessor Also added 2 paragraphs at the end of the example document and updated related tests accordingly Change-Id: Idd294cbe3975d0a04069e55682a91417160e538a
2012-05-16 20:33:27 +00:00
{ 'type': '/paragraph' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 58 - Beginning of paragraph
Added merge test for ve.dm.TransactionProcessor Also added 2 paragraphs at the end of the example document and updated related tests accordingly Change-Id: Idd294cbe3975d0a04069e55682a91417160e538a
2012-05-16 20:33:27 +00:00
{ 'type': 'paragraph' },
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 59 - Plain "m"
Added merge test for ve.dm.TransactionProcessor Also added 2 paragraphs at the end of the example document and updated related tests accordingly Change-Id: Idd294cbe3975d0a04069e55682a91417160e538a
2012-05-16 20:33:27 +00:00
'm',
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 60 - End of paragraph
Added merge test for ve.dm.TransactionProcessor Also added 2 paragraphs at the end of the example document and updated related tests accordingly Change-Id: Idd294cbe3975d0a04069e55682a91417160e538a
2012-05-16 20:33:27 +00:00
{ 'type': '/paragraph' }
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
// 61 - End of document
Added tests for transactions that deal with removing alien nodes Change-Id: Id36413c62386dbe5ebc8c8b3a1d3c5e301a8175a
2012-06-04 22:59:04 +00:00
];
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
ve.dm.example.preprocessAnnotations( ve.dm.example.data );
Added tests for transactions that deal with removing alien nodes Change-Id: Id36413c62386dbe5ebc8c8b3a1d3c5e301a8175a
2012-06-04 22:59:04 +00:00
ve.dm.example.alienData = [
// 0 - Open alienBlock
{ 'type': 'alienBlock' },
// 1 - Close alienBlock
{ 'type': '/alienBlock' },
// 2 - Open paragraph
{ 'type': 'paragraph' },
// 3 - Plain character 'a'
'a',
// 4 - Open alienInline
{ 'type': 'alienBlock' },
// 5 - Close alienInline
{ 'type': '/alienBlock' },
// 6 - Plain character 'b'
'b',
// 7 - Close paragraph
{ 'type': '/paragraph' },
// 8 - Open alienBlock
{ 'type': 'alienBlock' },
// 9 - Close alienBlock
{ 'type': '/alienBlock' }
// 10 - End of document
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
];
Introduce meta-linmod * ve.dm.Converter still generates metaInline/metaBlock elements as before, it's not affected by this change * ve.dm.Document constructor splits its input into "real" data and metadata ** Metadata is stored in this.metadata (the meta-linmod) as a sparse array of arrays, with an element for each offset in this.data ** this.data itself does not contain the metadata ** This means the node tree also doesn't contain the metadata ** Which means CE doesn't know about it at all * All splice operations on the linear model are sent through ve.dm.Document.spliceData(), which performs the splice and syncs the meta-linmod ** Metadata in the removed range is reaped and added to the metadata for the offset immediately following the removal * ve.dm.Document.getFullData() splices the linmod and meta-linmod back into each other; this "full data" is then fed back to ve.dm.Converter Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
2012-10-30 01:42:12 +00:00
ve.dm.example.withMeta = [
(bug 42124) Store comments in the meta-linmod * Make converter generate meta nodes with 'style': 'comment' * Handle style==='comment' in MetaBlockNode toDOM converter * Add some comments to the meta test case ** Update other tests accordingly * Change getDomElementSummary() to actually assert presence of comment nodes (specifically, all non-text child nodes) Change-Id: Ieef9418f4c47df3541477d9420aa2ab8df6e3df1
2012-11-20 04:01:09 +00:00
{
'type': 'metaBlock',
'attributes': {
'style': 'comment',
'text': ' No content conversion '
}
},
{ 'type': '/metaBlock' },
Introduce meta-linmod * ve.dm.Converter still generates metaInline/metaBlock elements as before, it's not affected by this change * ve.dm.Document constructor splits its input into "real" data and metadata ** Metadata is stored in this.metadata (the meta-linmod) as a sparse array of arrays, with an element for each offset in this.data ** this.data itself does not contain the metadata ** This means the node tree also doesn't contain the metadata ** Which means CE doesn't know about it at all * All splice operations on the linear model are sent through ve.dm.Document.spliceData(), which performs the splice and syncs the meta-linmod ** Metadata in the removed range is reaped and added to the metadata for the offset immediately following the removal * ve.dm.Document.getFullData() splices the linmod and meta-linmod back into each other; this "full data" is then fed back to ve.dm.Converter Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
2012-10-30 01:42:12 +00:00
{
'type': 'metaBlock',
'attributes': {
'style': 'meta',
(bug 45062) Implement the new node API in the converter This changes the node API to work with multiple elements, so we can support about groups. Instead of passing in and returning single DOM elements, we use arrays of DOM elements. ve.dm.Converter: * Pass modelRegistry into the constructor * Remove onNodeRegister handler and its data * Remove getDataElementFromDomElement() and getDataAnnotationFromDomElement(). Most logic moved into getDataFromDom(), some into createDataElement() * Remove createAlien(), replaced with createDataElement( ve.dm.AlienNode, ... ) * Replace doAboutGrouping() (which wrapped about groups) with getAboutGroup() (which returns an array of the nodes in the group) * Put in a hack so <meta>/<link> elements with an mw: property aren't alienated * Remove about group wrapping behavior in favor of just outputting multiple nodes ve.dm.AlienNode.js: * For multi-element aliens, only choose inline if all elements are inline, not just the first one ve.dm.example.js: * Add html/0 stuff for meta nodes * Fix test case to reflect new alien behavior Change-Id: I40dcc27430f778bc00a44b91b7d824bfb2718be6
2013-02-16 02:37:50 +00:00
'key': 'mw:PageProp/nocc',
'html/0/property': 'mw:PageProp/nocc'
Introduce meta-linmod * ve.dm.Converter still generates metaInline/metaBlock elements as before, it's not affected by this change * ve.dm.Document constructor splits its input into "real" data and metadata ** Metadata is stored in this.metadata (the meta-linmod) as a sparse array of arrays, with an element for each offset in this.data ** this.data itself does not contain the metadata ** This means the node tree also doesn't contain the metadata ** Which means CE doesn't know about it at all * All splice operations on the linear model are sent through ve.dm.Document.spliceData(), which performs the splice and syncs the meta-linmod ** Metadata in the removed range is reaped and added to the metadata for the offset immediately following the removal * ve.dm.Document.getFullData() splices the linmod and meta-linmod back into each other; this "full data" is then fed back to ve.dm.Converter Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
2012-10-30 01:42:12 +00:00
}
},
{ 'type': '/metaBlock' },
{ 'type': 'paragraph' },
'F',
'o',
'o',
{
'type': 'metaInline',
'attributes': {
'style': 'link',
'key': 'mw:WikiLink/Category',
(bug 45062) Implement the new node API in the converter This changes the node API to work with multiple elements, so we can support about groups. Instead of passing in and returning single DOM elements, we use arrays of DOM elements. ve.dm.Converter: * Pass modelRegistry into the constructor * Remove onNodeRegister handler and its data * Remove getDataElementFromDomElement() and getDataAnnotationFromDomElement(). Most logic moved into getDataFromDom(), some into createDataElement() * Remove createAlien(), replaced with createDataElement( ve.dm.AlienNode, ... ) * Replace doAboutGrouping() (which wrapped about groups) with getAboutGroup() (which returns an array of the nodes in the group) * Put in a hack so <meta>/<link> elements with an mw: property aren't alienated * Remove about group wrapping behavior in favor of just outputting multiple nodes ve.dm.AlienNode.js: * For multi-element aliens, only choose inline if all elements are inline, not just the first one ve.dm.example.js: * Add html/0 stuff for meta nodes * Fix test case to reflect new alien behavior Change-Id: I40dcc27430f778bc00a44b91b7d824bfb2718be6
2013-02-16 02:37:50 +00:00
'value': './Category:Bar',
'html/0/href': './Category:Bar',
'html/0/rel': 'mw:WikiLink/Category'
Introduce meta-linmod * ve.dm.Converter still generates metaInline/metaBlock elements as before, it's not affected by this change * ve.dm.Document constructor splits its input into "real" data and metadata ** Metadata is stored in this.metadata (the meta-linmod) as a sparse array of arrays, with an element for each offset in this.data ** this.data itself does not contain the metadata ** This means the node tree also doesn't contain the metadata ** Which means CE doesn't know about it at all * All splice operations on the linear model are sent through ve.dm.Document.spliceData(), which performs the splice and syncs the meta-linmod ** Metadata in the removed range is reaped and added to the metadata for the offset immediately following the removal * ve.dm.Document.getFullData() splices the linmod and meta-linmod back into each other; this "full data" is then fed back to ve.dm.Converter Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
2012-10-30 01:42:12 +00:00
}
},
{ 'type': '/metaInline' },
'B',
'a',
'r',
{
'type': 'metaInline',
'attributes': {
'style': 'meta',
'key': 'mw:foo',
(bug 45062) Implement the new node API in the converter This changes the node API to work with multiple elements, so we can support about groups. Instead of passing in and returning single DOM elements, we use arrays of DOM elements. ve.dm.Converter: * Pass modelRegistry into the constructor * Remove onNodeRegister handler and its data * Remove getDataElementFromDomElement() and getDataAnnotationFromDomElement(). Most logic moved into getDataFromDom(), some into createDataElement() * Remove createAlien(), replaced with createDataElement( ve.dm.AlienNode, ... ) * Replace doAboutGrouping() (which wrapped about groups) with getAboutGroup() (which returns an array of the nodes in the group) * Put in a hack so <meta>/<link> elements with an mw: property aren't alienated * Remove about group wrapping behavior in favor of just outputting multiple nodes ve.dm.AlienNode.js: * For multi-element aliens, only choose inline if all elements are inline, not just the first one ve.dm.example.js: * Add html/0 stuff for meta nodes * Fix test case to reflect new alien behavior Change-Id: I40dcc27430f778bc00a44b91b7d824bfb2718be6
2013-02-16 02:37:50 +00:00
'value': 'bar',
'html/0/content': 'bar',
'html/0/property': 'mw:foo'
Introduce meta-linmod * ve.dm.Converter still generates metaInline/metaBlock elements as before, it's not affected by this change * ve.dm.Document constructor splits its input into "real" data and metadata ** Metadata is stored in this.metadata (the meta-linmod) as a sparse array of arrays, with an element for each offset in this.data ** this.data itself does not contain the metadata ** This means the node tree also doesn't contain the metadata ** Which means CE doesn't know about it at all * All splice operations on the linear model are sent through ve.dm.Document.spliceData(), which performs the splice and syncs the meta-linmod ** Metadata in the removed range is reaped and added to the metadata for the offset immediately following the removal * ve.dm.Document.getFullData() splices the linmod and meta-linmod back into each other; this "full data" is then fed back to ve.dm.Converter Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
2012-10-30 01:42:12 +00:00
}
},
{ 'type': '/metaInline' },
'B',
'a',
(bug 42124) Store comments in the meta-linmod * Make converter generate meta nodes with 'style': 'comment' * Handle style==='comment' in MetaBlockNode toDOM converter * Add some comments to the meta test case ** Update other tests accordingly * Change getDomElementSummary() to actually assert presence of comment nodes (specifically, all non-text child nodes) Change-Id: Ieef9418f4c47df3541477d9420aa2ab8df6e3df1
2012-11-20 04:01:09 +00:00
{
'type': 'metaInline',
'attributes': {
'style': 'comment',
'text': ' inline '
}
},
{ 'type': '/metaInline' },
Introduce meta-linmod * ve.dm.Converter still generates metaInline/metaBlock elements as before, it's not affected by this change * ve.dm.Document constructor splits its input into "real" data and metadata ** Metadata is stored in this.metadata (the meta-linmod) as a sparse array of arrays, with an element for each offset in this.data ** this.data itself does not contain the metadata ** This means the node tree also doesn't contain the metadata ** Which means CE doesn't know about it at all * All splice operations on the linear model are sent through ve.dm.Document.spliceData(), which performs the splice and syncs the meta-linmod ** Metadata in the removed range is reaped and added to the metadata for the offset immediately following the removal * ve.dm.Document.getFullData() splices the linmod and meta-linmod back into each other; this "full data" is then fed back to ve.dm.Converter Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
2012-10-30 01:42:12 +00:00
'z',
{ 'type': '/paragraph' },
{
'type': 'metaBlock',
'attributes': {
'style': 'meta',
'key': 'mw:bar',
(bug 45062) Implement the new node API in the converter This changes the node API to work with multiple elements, so we can support about groups. Instead of passing in and returning single DOM elements, we use arrays of DOM elements. ve.dm.Converter: * Pass modelRegistry into the constructor * Remove onNodeRegister handler and its data * Remove getDataElementFromDomElement() and getDataAnnotationFromDomElement(). Most logic moved into getDataFromDom(), some into createDataElement() * Remove createAlien(), replaced with createDataElement( ve.dm.AlienNode, ... ) * Replace doAboutGrouping() (which wrapped about groups) with getAboutGroup() (which returns an array of the nodes in the group) * Put in a hack so <meta>/<link> elements with an mw: property aren't alienated * Remove about group wrapping behavior in favor of just outputting multiple nodes ve.dm.AlienNode.js: * For multi-element aliens, only choose inline if all elements are inline, not just the first one ve.dm.example.js: * Add html/0 stuff for meta nodes * Fix test case to reflect new alien behavior Change-Id: I40dcc27430f778bc00a44b91b7d824bfb2718be6
2013-02-16 02:37:50 +00:00
'value': 'baz',
'html/0/content': 'baz',
'html/0/property': 'mw:bar'
Introduce meta-linmod * ve.dm.Converter still generates metaInline/metaBlock elements as before, it's not affected by this change * ve.dm.Document constructor splits its input into "real" data and metadata ** Metadata is stored in this.metadata (the meta-linmod) as a sparse array of arrays, with an element for each offset in this.data ** this.data itself does not contain the metadata ** This means the node tree also doesn't contain the metadata ** Which means CE doesn't know about it at all * All splice operations on the linear model are sent through ve.dm.Document.spliceData(), which performs the splice and syncs the meta-linmod ** Metadata in the removed range is reaped and added to the metadata for the offset immediately following the removal * ve.dm.Document.getFullData() splices the linmod and meta-linmod back into each other; this "full data" is then fed back to ve.dm.Converter Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
2012-10-30 01:42:12 +00:00
}
},
{ 'type': '/metaBlock' },
(bug 42124) Store comments in the meta-linmod * Make converter generate meta nodes with 'style': 'comment' * Handle style==='comment' in MetaBlockNode toDOM converter * Add some comments to the meta test case ** Update other tests accordingly * Change getDomElementSummary() to actually assert presence of comment nodes (specifically, all non-text child nodes) Change-Id: Ieef9418f4c47df3541477d9420aa2ab8df6e3df1
2012-11-20 04:01:09 +00:00
{
'type': 'metaBlock',
'attributes': {
'style': 'comment',
'text': 'barbaz'
}
},
{ 'type': '/metaBlock' },
Introduce meta-linmod * ve.dm.Converter still generates metaInline/metaBlock elements as before, it's not affected by this change * ve.dm.Document constructor splits its input into "real" data and metadata ** Metadata is stored in this.metadata (the meta-linmod) as a sparse array of arrays, with an element for each offset in this.data ** this.data itself does not contain the metadata ** This means the node tree also doesn't contain the metadata ** Which means CE doesn't know about it at all * All splice operations on the linear model are sent through ve.dm.Document.spliceData(), which performs the splice and syncs the meta-linmod ** Metadata in the removed range is reaped and added to the metadata for the offset immediately following the removal * ve.dm.Document.getFullData() splices the linmod and meta-linmod back into each other; this "full data" is then fed back to ve.dm.Converter Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
2012-10-30 01:42:12 +00:00
{
'type': 'metaBlock',
'attributes': {
'style': 'link',
'key': 'mw:WikiLink/Category',
(bug 45062) Implement the new node API in the converter This changes the node API to work with multiple elements, so we can support about groups. Instead of passing in and returning single DOM elements, we use arrays of DOM elements. ve.dm.Converter: * Pass modelRegistry into the constructor * Remove onNodeRegister handler and its data * Remove getDataElementFromDomElement() and getDataAnnotationFromDomElement(). Most logic moved into getDataFromDom(), some into createDataElement() * Remove createAlien(), replaced with createDataElement( ve.dm.AlienNode, ... ) * Replace doAboutGrouping() (which wrapped about groups) with getAboutGroup() (which returns an array of the nodes in the group) * Put in a hack so <meta>/<link> elements with an mw: property aren't alienated * Remove about group wrapping behavior in favor of just outputting multiple nodes ve.dm.AlienNode.js: * For multi-element aliens, only choose inline if all elements are inline, not just the first one ve.dm.example.js: * Add html/0 stuff for meta nodes * Fix test case to reflect new alien behavior Change-Id: I40dcc27430f778bc00a44b91b7d824bfb2718be6
2013-02-16 02:37:50 +00:00
'value': './Category:Foo#Bar baz%23quux',
'html/0/href': './Category:Foo#Bar baz%23quux',
'html/0/rel': 'mw:WikiLink/Category'
Introduce meta-linmod * ve.dm.Converter still generates metaInline/metaBlock elements as before, it's not affected by this change * ve.dm.Document constructor splits its input into "real" data and metadata ** Metadata is stored in this.metadata (the meta-linmod) as a sparse array of arrays, with an element for each offset in this.data ** this.data itself does not contain the metadata ** This means the node tree also doesn't contain the metadata ** Which means CE doesn't know about it at all * All splice operations on the linear model are sent through ve.dm.Document.spliceData(), which performs the splice and syncs the meta-linmod ** Metadata in the removed range is reaped and added to the metadata for the offset immediately following the removal * ve.dm.Document.getFullData() splices the linmod and meta-linmod back into each other; this "full data" is then fed back to ve.dm.Converter Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
2012-10-30 01:42:12 +00:00
}
},
{ 'type': '/metaBlock' },
{
'type': 'metaBlock',
'attributes': {
'style': 'meta',
'key': null,
Change the HTML attribute prefix from html/ to html/0/ This means that <p data-foo="bar"> will now be converted to a paragraph with attributes {"html/0/data-foo":"bar"} rather than {"html/foo":"bar"} This paves the way for multi-element node (about group) handling in the node API: nodes representing multiple DOM elements will have html/i/attr to represent an attribute of the i'th DOM element. Change-Id: Iea52bdccd721942ca708c8f9f47e934524809845
2013-02-06 19:47:52 +00:00
'html/0/typeof': 'mw:Placeholder',
'html/0/data-parsoid': 'foobar'
Introduce meta-linmod * ve.dm.Converter still generates metaInline/metaBlock elements as before, it's not affected by this change * ve.dm.Document constructor splits its input into "real" data and metadata ** Metadata is stored in this.metadata (the meta-linmod) as a sparse array of arrays, with an element for each offset in this.data ** this.data itself does not contain the metadata ** This means the node tree also doesn't contain the metadata ** Which means CE doesn't know about it at all * All splice operations on the linear model are sent through ve.dm.Document.spliceData(), which performs the splice and syncs the meta-linmod ** Metadata in the removed range is reaped and added to the metadata for the offset immediately following the removal * ve.dm.Document.getFullData() splices the linmod and meta-linmod back into each other; this "full data" is then fed back to ve.dm.Converter Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
2012-10-30 01:42:12 +00:00
}
},
{ 'type': '/metaBlock' }
];
ve.dm.example.withMetaPlainData = [
{ 'type': 'paragraph' },
'F',
'o',
'o',
'B',
'a',
'r',
'B',
'a',
'z',
{ 'type': '/paragraph' }
];
ve.dm.example.withMetaMetaData = [
[
(bug 42124) Store comments in the meta-linmod * Make converter generate meta nodes with 'style': 'comment' * Handle style==='comment' in MetaBlockNode toDOM converter * Add some comments to the meta test case ** Update other tests accordingly * Change getDomElementSummary() to actually assert presence of comment nodes (specifically, all non-text child nodes) Change-Id: Ieef9418f4c47df3541477d9420aa2ab8df6e3df1
2012-11-20 04:01:09 +00:00
{
'type': 'metaBlock',
'attributes': {
'style': 'comment',
'text': ' No content conversion '
}
},
Introduce meta-linmod * ve.dm.Converter still generates metaInline/metaBlock elements as before, it's not affected by this change * ve.dm.Document constructor splits its input into "real" data and metadata ** Metadata is stored in this.metadata (the meta-linmod) as a sparse array of arrays, with an element for each offset in this.data ** this.data itself does not contain the metadata ** This means the node tree also doesn't contain the metadata ** Which means CE doesn't know about it at all * All splice operations on the linear model are sent through ve.dm.Document.spliceData(), which performs the splice and syncs the meta-linmod ** Metadata in the removed range is reaped and added to the metadata for the offset immediately following the removal * ve.dm.Document.getFullData() splices the linmod and meta-linmod back into each other; this "full data" is then fed back to ve.dm.Converter Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
2012-10-30 01:42:12 +00:00
{
'type': 'metaBlock',
'attributes': {
'style': 'meta',
(bug 45062) Implement the new node API in the converter This changes the node API to work with multiple elements, so we can support about groups. Instead of passing in and returning single DOM elements, we use arrays of DOM elements. ve.dm.Converter: * Pass modelRegistry into the constructor * Remove onNodeRegister handler and its data * Remove getDataElementFromDomElement() and getDataAnnotationFromDomElement(). Most logic moved into getDataFromDom(), some into createDataElement() * Remove createAlien(), replaced with createDataElement( ve.dm.AlienNode, ... ) * Replace doAboutGrouping() (which wrapped about groups) with getAboutGroup() (which returns an array of the nodes in the group) * Put in a hack so <meta>/<link> elements with an mw: property aren't alienated * Remove about group wrapping behavior in favor of just outputting multiple nodes ve.dm.AlienNode.js: * For multi-element aliens, only choose inline if all elements are inline, not just the first one ve.dm.example.js: * Add html/0 stuff for meta nodes * Fix test case to reflect new alien behavior Change-Id: I40dcc27430f778bc00a44b91b7d824bfb2718be6
2013-02-16 02:37:50 +00:00
'key': 'mw:PageProp/nocc',
'html/0/property': 'mw:PageProp/nocc'
Introduce meta-linmod * ve.dm.Converter still generates metaInline/metaBlock elements as before, it's not affected by this change * ve.dm.Document constructor splits its input into "real" data and metadata ** Metadata is stored in this.metadata (the meta-linmod) as a sparse array of arrays, with an element for each offset in this.data ** this.data itself does not contain the metadata ** This means the node tree also doesn't contain the metadata ** Which means CE doesn't know about it at all * All splice operations on the linear model are sent through ve.dm.Document.spliceData(), which performs the splice and syncs the meta-linmod ** Metadata in the removed range is reaped and added to the metadata for the offset immediately following the removal * ve.dm.Document.getFullData() splices the linmod and meta-linmod back into each other; this "full data" is then fed back to ve.dm.Converter Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
2012-10-30 01:42:12 +00:00
}
}
],
undefined,
undefined,
undefined,
[
{
'type': 'metaInline',
'attributes': {
'style': 'link',
'key': 'mw:WikiLink/Category',
(bug 45062) Implement the new node API in the converter This changes the node API to work with multiple elements, so we can support about groups. Instead of passing in and returning single DOM elements, we use arrays of DOM elements. ve.dm.Converter: * Pass modelRegistry into the constructor * Remove onNodeRegister handler and its data * Remove getDataElementFromDomElement() and getDataAnnotationFromDomElement(). Most logic moved into getDataFromDom(), some into createDataElement() * Remove createAlien(), replaced with createDataElement( ve.dm.AlienNode, ... ) * Replace doAboutGrouping() (which wrapped about groups) with getAboutGroup() (which returns an array of the nodes in the group) * Put in a hack so <meta>/<link> elements with an mw: property aren't alienated * Remove about group wrapping behavior in favor of just outputting multiple nodes ve.dm.AlienNode.js: * For multi-element aliens, only choose inline if all elements are inline, not just the first one ve.dm.example.js: * Add html/0 stuff for meta nodes * Fix test case to reflect new alien behavior Change-Id: I40dcc27430f778bc00a44b91b7d824bfb2718be6
2013-02-16 02:37:50 +00:00
'value': './Category:Bar',
'html/0/href': './Category:Bar',
'html/0/rel': 'mw:WikiLink/Category'
Introduce meta-linmod * ve.dm.Converter still generates metaInline/metaBlock elements as before, it's not affected by this change * ve.dm.Document constructor splits its input into "real" data and metadata ** Metadata is stored in this.metadata (the meta-linmod) as a sparse array of arrays, with an element for each offset in this.data ** this.data itself does not contain the metadata ** This means the node tree also doesn't contain the metadata ** Which means CE doesn't know about it at all * All splice operations on the linear model are sent through ve.dm.Document.spliceData(), which performs the splice and syncs the meta-linmod ** Metadata in the removed range is reaped and added to the metadata for the offset immediately following the removal * ve.dm.Document.getFullData() splices the linmod and meta-linmod back into each other; this "full data" is then fed back to ve.dm.Converter Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
2012-10-30 01:42:12 +00:00
}
}
],
undefined,
undefined,
[
{
'type': 'metaInline',
'attributes': {
'style': 'meta',
'key': 'mw:foo',
(bug 45062) Implement the new node API in the converter This changes the node API to work with multiple elements, so we can support about groups. Instead of passing in and returning single DOM elements, we use arrays of DOM elements. ve.dm.Converter: * Pass modelRegistry into the constructor * Remove onNodeRegister handler and its data * Remove getDataElementFromDomElement() and getDataAnnotationFromDomElement(). Most logic moved into getDataFromDom(), some into createDataElement() * Remove createAlien(), replaced with createDataElement( ve.dm.AlienNode, ... ) * Replace doAboutGrouping() (which wrapped about groups) with getAboutGroup() (which returns an array of the nodes in the group) * Put in a hack so <meta>/<link> elements with an mw: property aren't alienated * Remove about group wrapping behavior in favor of just outputting multiple nodes ve.dm.AlienNode.js: * For multi-element aliens, only choose inline if all elements are inline, not just the first one ve.dm.example.js: * Add html/0 stuff for meta nodes * Fix test case to reflect new alien behavior Change-Id: I40dcc27430f778bc00a44b91b7d824bfb2718be6
2013-02-16 02:37:50 +00:00
'value': 'bar',
'html/0/content': 'bar',
'html/0/property': 'mw:foo'
Introduce meta-linmod * ve.dm.Converter still generates metaInline/metaBlock elements as before, it's not affected by this change * ve.dm.Document constructor splits its input into "real" data and metadata ** Metadata is stored in this.metadata (the meta-linmod) as a sparse array of arrays, with an element for each offset in this.data ** this.data itself does not contain the metadata ** This means the node tree also doesn't contain the metadata ** Which means CE doesn't know about it at all * All splice operations on the linear model are sent through ve.dm.Document.spliceData(), which performs the splice and syncs the meta-linmod ** Metadata in the removed range is reaped and added to the metadata for the offset immediately following the removal * ve.dm.Document.getFullData() splices the linmod and meta-linmod back into each other; this "full data" is then fed back to ve.dm.Converter Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
2012-10-30 01:42:12 +00:00
}
}
],
undefined,
(bug 42124) Store comments in the meta-linmod * Make converter generate meta nodes with 'style': 'comment' * Handle style==='comment' in MetaBlockNode toDOM converter * Add some comments to the meta test case ** Update other tests accordingly * Change getDomElementSummary() to actually assert presence of comment nodes (specifically, all non-text child nodes) Change-Id: Ieef9418f4c47df3541477d9420aa2ab8df6e3df1
2012-11-20 04:01:09 +00:00
[
{
'type': 'metaInline',
'attributes': {
'style': 'comment',
'text': ' inline '
}
}
],
Introduce meta-linmod * ve.dm.Converter still generates metaInline/metaBlock elements as before, it's not affected by this change * ve.dm.Document constructor splits its input into "real" data and metadata ** Metadata is stored in this.metadata (the meta-linmod) as a sparse array of arrays, with an element for each offset in this.data ** this.data itself does not contain the metadata ** This means the node tree also doesn't contain the metadata ** Which means CE doesn't know about it at all * All splice operations on the linear model are sent through ve.dm.Document.spliceData(), which performs the splice and syncs the meta-linmod ** Metadata in the removed range is reaped and added to the metadata for the offset immediately following the removal * ve.dm.Document.getFullData() splices the linmod and meta-linmod back into each other; this "full data" is then fed back to ve.dm.Converter Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
2012-10-30 01:42:12 +00:00
undefined,
[
{
'type': 'metaBlock',
'attributes': {
'style': 'meta',
'key': 'mw:bar',
(bug 45062) Implement the new node API in the converter This changes the node API to work with multiple elements, so we can support about groups. Instead of passing in and returning single DOM elements, we use arrays of DOM elements. ve.dm.Converter: * Pass modelRegistry into the constructor * Remove onNodeRegister handler and its data * Remove getDataElementFromDomElement() and getDataAnnotationFromDomElement(). Most logic moved into getDataFromDom(), some into createDataElement() * Remove createAlien(), replaced with createDataElement( ve.dm.AlienNode, ... ) * Replace doAboutGrouping() (which wrapped about groups) with getAboutGroup() (which returns an array of the nodes in the group) * Put in a hack so <meta>/<link> elements with an mw: property aren't alienated * Remove about group wrapping behavior in favor of just outputting multiple nodes ve.dm.AlienNode.js: * For multi-element aliens, only choose inline if all elements are inline, not just the first one ve.dm.example.js: * Add html/0 stuff for meta nodes * Fix test case to reflect new alien behavior Change-Id: I40dcc27430f778bc00a44b91b7d824bfb2718be6
2013-02-16 02:37:50 +00:00
'value': 'baz',
'html/0/content': 'baz',
'html/0/property': 'mw:bar'
Introduce meta-linmod * ve.dm.Converter still generates metaInline/metaBlock elements as before, it's not affected by this change * ve.dm.Document constructor splits its input into "real" data and metadata ** Metadata is stored in this.metadata (the meta-linmod) as a sparse array of arrays, with an element for each offset in this.data ** this.data itself does not contain the metadata ** This means the node tree also doesn't contain the metadata ** Which means CE doesn't know about it at all * All splice operations on the linear model are sent through ve.dm.Document.spliceData(), which performs the splice and syncs the meta-linmod ** Metadata in the removed range is reaped and added to the metadata for the offset immediately following the removal * ve.dm.Document.getFullData() splices the linmod and meta-linmod back into each other; this "full data" is then fed back to ve.dm.Converter Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
2012-10-30 01:42:12 +00:00
}
},
(bug 42124) Store comments in the meta-linmod * Make converter generate meta nodes with 'style': 'comment' * Handle style==='comment' in MetaBlockNode toDOM converter * Add some comments to the meta test case ** Update other tests accordingly * Change getDomElementSummary() to actually assert presence of comment nodes (specifically, all non-text child nodes) Change-Id: Ieef9418f4c47df3541477d9420aa2ab8df6e3df1
2012-11-20 04:01:09 +00:00
{
'type': 'metaBlock',
'attributes': {
'style': 'comment',
'text': 'barbaz'
}
},
Introduce meta-linmod * ve.dm.Converter still generates metaInline/metaBlock elements as before, it's not affected by this change * ve.dm.Document constructor splits its input into "real" data and metadata ** Metadata is stored in this.metadata (the meta-linmod) as a sparse array of arrays, with an element for each offset in this.data ** this.data itself does not contain the metadata ** This means the node tree also doesn't contain the metadata ** Which means CE doesn't know about it at all * All splice operations on the linear model are sent through ve.dm.Document.spliceData(), which performs the splice and syncs the meta-linmod ** Metadata in the removed range is reaped and added to the metadata for the offset immediately following the removal * ve.dm.Document.getFullData() splices the linmod and meta-linmod back into each other; this "full data" is then fed back to ve.dm.Converter Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
2012-10-30 01:42:12 +00:00
{
'type': 'metaBlock',
'attributes': {
'style': 'link',
'key': 'mw:WikiLink/Category',
(bug 45062) Implement the new node API in the converter This changes the node API to work with multiple elements, so we can support about groups. Instead of passing in and returning single DOM elements, we use arrays of DOM elements. ve.dm.Converter: * Pass modelRegistry into the constructor * Remove onNodeRegister handler and its data * Remove getDataElementFromDomElement() and getDataAnnotationFromDomElement(). Most logic moved into getDataFromDom(), some into createDataElement() * Remove createAlien(), replaced with createDataElement( ve.dm.AlienNode, ... ) * Replace doAboutGrouping() (which wrapped about groups) with getAboutGroup() (which returns an array of the nodes in the group) * Put in a hack so <meta>/<link> elements with an mw: property aren't alienated * Remove about group wrapping behavior in favor of just outputting multiple nodes ve.dm.AlienNode.js: * For multi-element aliens, only choose inline if all elements are inline, not just the first one ve.dm.example.js: * Add html/0 stuff for meta nodes * Fix test case to reflect new alien behavior Change-Id: I40dcc27430f778bc00a44b91b7d824bfb2718be6
2013-02-16 02:37:50 +00:00
'value': './Category:Foo#Bar baz%23quux',
'html/0/href': './Category:Foo#Bar baz%23quux',
'html/0/rel': 'mw:WikiLink/Category'
Introduce meta-linmod * ve.dm.Converter still generates metaInline/metaBlock elements as before, it's not affected by this change * ve.dm.Document constructor splits its input into "real" data and metadata ** Metadata is stored in this.metadata (the meta-linmod) as a sparse array of arrays, with an element for each offset in this.data ** this.data itself does not contain the metadata ** This means the node tree also doesn't contain the metadata ** Which means CE doesn't know about it at all * All splice operations on the linear model are sent through ve.dm.Document.spliceData(), which performs the splice and syncs the meta-linmod ** Metadata in the removed range is reaped and added to the metadata for the offset immediately following the removal * ve.dm.Document.getFullData() splices the linmod and meta-linmod back into each other; this "full data" is then fed back to ve.dm.Converter Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
2012-10-30 01:42:12 +00:00
}
},
{
'type': 'metaBlock',
'attributes': {
'style': 'meta',
'key': null,
Change the HTML attribute prefix from html/ to html/0/ This means that <p data-foo="bar"> will now be converted to a paragraph with attributes {"html/0/data-foo":"bar"} rather than {"html/foo":"bar"} This paves the way for multi-element node (about group) handling in the node API: nodes representing multiple DOM elements will have html/i/attr to represent an attribute of the i'th DOM element. Change-Id: Iea52bdccd721942ca708c8f9f47e934524809845
2013-02-06 19:47:52 +00:00
'html/0/typeof': 'mw:Placeholder',
(bug 45062) Implement the new node API in the converter This changes the node API to work with multiple elements, so we can support about groups. Instead of passing in and returning single DOM elements, we use arrays of DOM elements. ve.dm.Converter: * Pass modelRegistry into the constructor * Remove onNodeRegister handler and its data * Remove getDataElementFromDomElement() and getDataAnnotationFromDomElement(). Most logic moved into getDataFromDom(), some into createDataElement() * Remove createAlien(), replaced with createDataElement( ve.dm.AlienNode, ... ) * Replace doAboutGrouping() (which wrapped about groups) with getAboutGroup() (which returns an array of the nodes in the group) * Put in a hack so <meta>/<link> elements with an mw: property aren't alienated * Remove about group wrapping behavior in favor of just outputting multiple nodes ve.dm.AlienNode.js: * For multi-element aliens, only choose inline if all elements are inline, not just the first one ve.dm.example.js: * Add html/0 stuff for meta nodes * Fix test case to reflect new alien behavior Change-Id: I40dcc27430f778bc00a44b91b7d824bfb2718be6
2013-02-16 02:37:50 +00:00
'html/0/data-parsoid': 'foobar'
Introduce meta-linmod * ve.dm.Converter still generates metaInline/metaBlock elements as before, it's not affected by this change * ve.dm.Document constructor splits its input into "real" data and metadata ** Metadata is stored in this.metadata (the meta-linmod) as a sparse array of arrays, with an element for each offset in this.data ** this.data itself does not contain the metadata ** This means the node tree also doesn't contain the metadata ** Which means CE doesn't know about it at all * All splice operations on the linear model are sent through ve.dm.Document.spliceData(), which performs the splice and syncs the meta-linmod ** Metadata in the removed range is reaped and added to the metadata for the offset immediately following the removal * ve.dm.Document.getFullData() splices the linmod and meta-linmod back into each other; this "full data" is then fed back to ve.dm.Converter Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
2012-10-30 01:42:12 +00:00
}
}
]
];
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
/**
* Sample content data index.
Removed trailing whitespace in multi-line comment blocks JSHint and various git tools complain about this, so let's just do away with them altogether Change-Id: I731866bd21f1ee0088fb0a71df3abf92692aca23
2012-05-14 22:05:09 +00:00
*
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
* This is part of what a ve.dm.DocumentFragment generates when given linear data.
Removed trailing whitespace in multi-line comment blocks JSHint and various git tools complain about this, so let's just do away with them altogether Change-Id: I731866bd21f1ee0088fb0a71df3abf92692aca23
2012-05-14 22:05:09 +00:00
*
Split Broke DefinitionListNode out of ListNode and DefinitionListItemNode out of ListItemNode * Makes it simpler in the linear model because we don't have to use style: "item" for regular list items and style: "definition" for definition lists * Enforces correct nesting through existing node rules systems * Updates tests accordingly Change-Id: I64d80af938e325f1961226505bdc386bb35ccdda
2012-05-04 18:56:32 +00:00
* (21) branch nodes
Fixed length calculations and added tests for node tree Image nodes are leafs, so providing an empty array to their children/length "contents" constructor argument ends up setting the numeric length to [], which casts to an empty string in arithmetic, causing all further calculations to be concatenations instead of additions. Change-Id: I40e1ea2295f6095318bc4c24185cadfdfb684557
2012-04-30 20:23:46 +00:00
* (01) document node
* (01) heading node
* (01) table node
* (01) tableRow node
* (01) tableCell node
Split Broke DefinitionListNode out of ListNode and DefinitionListItemNode out of ListItemNode * Makes it simpler in the linear model because we don't have to use style: "item" for regular list items and style: "definition" for definition lists * Enforces correct nesting through existing node rules systems * Updates tests accordingly Change-Id: I64d80af938e325f1961226505bdc386bb35ccdda
2012-05-04 18:56:32 +00:00
* (06) paragraph nodes
Fixed length calculations and added tests for node tree Image nodes are leafs, so providing an empty array to their children/length "contents" constructor argument ends up setting the numeric length to [], which casts to an empty string in arithmetic, causing all further calculations to be concatenations instead of additions. Change-Id: I40e1ea2295f6095318bc4c24185cadfdfb684557
2012-04-30 20:23:46 +00:00
* (03) list nodes
* (03) listItem nodes
* (01) preformatted node
Split Broke DefinitionListNode out of ListNode and DefinitionListItemNode out of ListItemNode * Makes it simpler in the linear model because we don't have to use style: "item" for regular list items and style: "definition" for definition lists * Enforces correct nesting through existing node rules systems * Updates tests accordingly Change-Id: I64d80af938e325f1961226505bdc386bb35ccdda
2012-05-04 18:56:32 +00:00
* (01) definitionList node
* (02) definitionListItem nodes
* (10) leaf nodes
* (09) text nodes
Fixed length calculations and added tests for node tree Image nodes are leafs, so providing an empty array to their children/length "contents" constructor argument ends up setting the numeric length to [], which casts to an empty string in arithmetic, causing all further calculations to be concatenations instead of additions. Change-Id: I40e1ea2295f6095318bc4c24185cadfdfb684557
2012-04-30 20:23:46 +00:00
* (01) image node
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
*/
Fixed node tree example * Indexes for attribute references were off (the comments that were previously wrong before were relied on and cause this to also be wrong) * Tree should start with a document node Change-Id: Ia8e4faa4bcb25db797ff97f6e798ba253adfe535
2012-04-30 19:37:08 +00:00
ve.dm.example.tree = new ve.dm.DocumentNode( [
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
// Heading with "abc"
Store the data model element in the DM tree This is cleaner than passing around the attributes separately, and it allows us to access the annotations in dm.LeafNode as well. Change-Id: Ie5b90988114835831cbe5cdccf63c7cd45719e31
2012-11-23 23:16:08 +00:00
new ve.dm.HeadingNode( [new ve.dm.TextNode( 3 )], ve.dm.example.data[0] ),
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
new ve.dm.TableNode( [
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
new ve.dm.TableSectionNode( [
new ve.dm.TableRowNode( [
new ve.dm.TableCellNode( [
// Paragraph with "d"
Store the data model element in the DM tree This is cleaner than passing around the attributes separately, and it allows us to access the annotations in dm.LeafNode as well. Change-Id: Ie5b90988114835831cbe5cdccf63c7cd45719e31
2012-11-23 23:16:08 +00:00
new ve.dm.ParagraphNode( [new ve.dm.TextNode( 1 )],
ve.dm.example.data[9] ),
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
new ve.dm.ListNode( [
// 1st level bullet list item with "e"
new ve.dm.ListItemNode( [
Store the data model element in the DM tree This is cleaner than passing around the attributes separately, and it allows us to access the annotations in dm.LeafNode as well. Change-Id: Ie5b90988114835831cbe5cdccf63c7cd45719e31
2012-11-23 23:16:08 +00:00
new ve.dm.ParagraphNode(
[new ve.dm.TextNode( 1 )],
ve.dm.example.data[14]
),
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
new ve.dm.ListNode( [
// 2nd level bullet list item with "f"
new ve.dm.ListItemNode( [
Store the data model element in the DM tree This is cleaner than passing around the attributes separately, and it allows us to access the annotations in dm.LeafNode as well. Change-Id: Ie5b90988114835831cbe5cdccf63c7cd45719e31
2012-11-23 23:16:08 +00:00
new ve.dm.ParagraphNode(
[new ve.dm.TextNode( 1 )],
ve.dm.example.data[19]
)
], ve.dm.example.data[18] )
], ve.dm.example.data[17] )
], ve.dm.example.data[13] )
], ve.dm.example.data[12] ),
Add a tableSection to the example data and update offsets and stuff in almost all tests This fixes the converter tests. Change-Id: I72f6d6c103c3a8bbee201c070a2f7c1bfe401235
2012-06-08 05:08:49 +00:00
new ve.dm.ListNode( [
// Numbered list item with "g"
new ve.dm.ListItemNode( [
Store the data model element in the DM tree This is cleaner than passing around the attributes separately, and it allows us to access the annotations in dm.LeafNode as well. Change-Id: Ie5b90988114835831cbe5cdccf63c7cd45719e31
2012-11-23 23:16:08 +00:00
new ve.dm.ParagraphNode(
[new ve.dm.TextNode( 1 )],
ve.dm.example.data[28]
)
], ve.dm.example.data[27] )
], ve.dm.example.data[26] )
], ve.dm.example.data[8] )
], ve.dm.example.data[7] )
], ve.dm.example.data[6] )
], ve.dm.example.data[5] ),
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
// Preformatted with "h[image.png]i"
new ve.dm.PreformattedNode( [
new ve.dm.TextNode( 1 ),
Store the data model element in the DM tree This is cleaner than passing around the attributes separately, and it allows us to access the annotations in dm.LeafNode as well. Change-Id: Ie5b90988114835831cbe5cdccf63c7cd45719e31
2012-11-23 23:16:08 +00:00
new ve.dm.ImageNode( [], ve.dm.example.data[39] ),
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
new ve.dm.TextNode( 1 )
Store the data model element in the DM tree This is cleaner than passing around the attributes separately, and it allows us to access the annotations in dm.LeafNode as well. Change-Id: Ie5b90988114835831cbe5cdccf63c7cd45719e31
2012-11-23 23:16:08 +00:00
], ve.dm.example.data[37] ),
Split Broke DefinitionListNode out of ListNode and DefinitionListItemNode out of ListItemNode * Makes it simpler in the linear model because we don't have to use style: "item" for regular list items and style: "definition" for definition lists * Enforces correct nesting through existing node rules systems * Updates tests accordingly Change-Id: I64d80af938e325f1961226505bdc386bb35ccdda
2012-05-04 18:56:32 +00:00
new ve.dm.DefinitionListNode( [
// Definition list term item with "j"
new ve.dm.DefinitionListItemNode( [
Store the data model element in the DM tree This is cleaner than passing around the attributes separately, and it allows us to access the annotations in dm.LeafNode as well. Change-Id: Ie5b90988114835831cbe5cdccf63c7cd45719e31
2012-11-23 23:16:08 +00:00
new ve.dm.ParagraphNode( [new ve.dm.TextNode( 1 )], ve.dm.example.data[45] )
], ve.dm.example.data[44] ),
Split Broke DefinitionListNode out of ListNode and DefinitionListItemNode out of ListItemNode * Makes it simpler in the linear model because we don't have to use style: "item" for regular list items and style: "definition" for definition lists * Enforces correct nesting through existing node rules systems * Updates tests accordingly Change-Id: I64d80af938e325f1961226505bdc386bb35ccdda
2012-05-04 18:56:32 +00:00
// Definition list definition item with "k"
new ve.dm.DefinitionListItemNode( [
Store the data model element in the DM tree This is cleaner than passing around the attributes separately, and it allows us to access the annotations in dm.LeafNode as well. Change-Id: Ie5b90988114835831cbe5cdccf63c7cd45719e31
2012-11-23 23:16:08 +00:00
new ve.dm.ParagraphNode( [new ve.dm.TextNode( 1 )], ve.dm.example.data[50] )
], ve.dm.example.data[49] )
], ve.dm.example.data[43] ),
new ve.dm.ParagraphNode( [new ve.dm.TextNode( 1 )], ve.dm.example.data[55] ),
new ve.dm.ParagraphNode( [new ve.dm.TextNode( 1 )], ve.dm.example.data[58] )
Fixed node tree example * Indexes for attribute references were off (the comments that were previously wrong before were relied on and cause this to also be wrong) * Tree should start with a document node Change-Id: Ia8e4faa4bcb25db797ff97f6e798ba253adfe535
2012-04-30 19:37:08 +00:00
] );
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
ve.dm.example.conversions = {
'definitionListItem term': {
Cleaned up some useless/unused functions Change-Id: I6aa5d0ed3d21993ed653ee64b4928ef98874db2d
2012-06-07 22:02:25 +00:00
'domElement': ve.example.createDomElement( 'dt' ),
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
'dataElement': { 'type': 'definitionListItem', 'attributes': { 'style': 'term' } }
},
'definitionListItem definition': {
Cleaned up some useless/unused functions Change-Id: I6aa5d0ed3d21993ed653ee64b4928ef98874db2d
2012-06-07 22:02:25 +00:00
'domElement': ve.example.createDomElement( 'dd' ),
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
'dataElement': { 'type': 'definitionListItem', 'attributes': { 'style': 'definition' } }
},
'definitionList definition': {
Cleaned up some useless/unused functions Change-Id: I6aa5d0ed3d21993ed653ee64b4928ef98874db2d
2012-06-07 22:02:25 +00:00
'domElement': ve.example.createDomElement( 'dl' ),
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
'dataElement': { 'type': 'definitionList' }
},
'heading level 1': {
Cleaned up some useless/unused functions Change-Id: I6aa5d0ed3d21993ed653ee64b4928ef98874db2d
2012-06-07 22:02:25 +00:00
'domElement': ve.example.createDomElement( 'h1' ),
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
'dataElement': { 'type': 'heading', 'attributes': { 'level': 1 } }
},
'heading level 2': {
Cleaned up some useless/unused functions Change-Id: I6aa5d0ed3d21993ed653ee64b4928ef98874db2d
2012-06-07 22:02:25 +00:00
'domElement': ve.example.createDomElement( 'h2' ),
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
'dataElement': { 'type': 'heading', 'attributes': { 'level': 2 } }
},
'heading level 3': {
Cleaned up some useless/unused functions Change-Id: I6aa5d0ed3d21993ed653ee64b4928ef98874db2d
2012-06-07 22:02:25 +00:00
'domElement': ve.example.createDomElement( 'h3' ),
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
'dataElement': { 'type': 'heading', 'attributes': { 'level': 3 } }
},
'heading level 4': {
Cleaned up some useless/unused functions Change-Id: I6aa5d0ed3d21993ed653ee64b4928ef98874db2d
2012-06-07 22:02:25 +00:00
'domElement': ve.example.createDomElement( 'h4' ),
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
'dataElement': { 'type': 'heading', 'attributes': { 'level': 4 } }
},
'heading level 5': {
Cleaned up some useless/unused functions Change-Id: I6aa5d0ed3d21993ed653ee64b4928ef98874db2d
2012-06-07 22:02:25 +00:00
'domElement': ve.example.createDomElement( 'h5' ),
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
'dataElement': { 'type': 'heading', 'attributes': { 'level': 5 } }
},
'heading level 6': {
Cleaned up some useless/unused functions Change-Id: I6aa5d0ed3d21993ed653ee64b4928ef98874db2d
2012-06-07 22:02:25 +00:00
'domElement': ve.example.createDomElement( 'h6' ),
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
'dataElement': { 'type': 'heading', 'attributes': { 'level': 6 } }
},
'image': {
Fixed multi-auto-wrapping issue and added tests to track regressions Roan mostly wrote this Change-Id: Id292c84a4da97d6608aa7c17ab6a4cf5a2e3f409
2012-06-08 22:16:55 +00:00
'domElement': ve.example.createDomElement( 'img' ),
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
'dataElement': { 'type': 'image' }
},
'listItem': {
Cleaned up some useless/unused functions Change-Id: I6aa5d0ed3d21993ed653ee64b4928ef98874db2d
2012-06-07 22:02:25 +00:00
'domElement': ve.example.createDomElement( 'li' ),
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
'dataElement': { 'type': 'listItem' }
},
'list bullet': {
Cleaned up some useless/unused functions Change-Id: I6aa5d0ed3d21993ed653ee64b4928ef98874db2d
2012-06-07 22:02:25 +00:00
'domElement': ve.example.createDomElement( 'ul' ),
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
'dataElement': { 'type': 'list', 'attributes': { 'style': 'bullet' } }
},
'list number': {
Cleaned up some useless/unused functions Change-Id: I6aa5d0ed3d21993ed653ee64b4928ef98874db2d
2012-06-07 22:02:25 +00:00
'domElement': ve.example.createDomElement( 'ol' ),
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
'dataElement': { 'type': 'list', 'attributes': { 'style': 'number' } }
},
'paragraph': {
Cleaned up some useless/unused functions Change-Id: I6aa5d0ed3d21993ed653ee64b4928ef98874db2d
2012-06-07 22:02:25 +00:00
'domElement': ve.example.createDomElement( 'p' ),
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
'dataElement': { 'type': 'paragraph' }
},
'preformatted': {
Cleaned up some useless/unused functions Change-Id: I6aa5d0ed3d21993ed653ee64b4928ef98874db2d
2012-06-07 22:02:25 +00:00
'domElement': ve.example.createDomElement( 'pre' ),
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
'dataElement': { 'type': 'preformatted' }
},
'tableCell': {
Cleaned up some useless/unused functions Change-Id: I6aa5d0ed3d21993ed653ee64b4928ef98874db2d
2012-06-07 22:02:25 +00:00
'domElement': ve.example.createDomElement( 'td' ),
Make tableCell represent both <td> and <th> Adding a 'style' attribute which is set to either 'data' or 'header' This breaks even more tests because of missing style attributes Change-Id: I0a75d8c1578b4414eeae8c484f6c4d6f8a59472a
2012-06-08 05:02:25 +00:00
'dataElement': { 'type': 'tableCell', 'attributes': { 'style': 'data' } }
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
},
'table': {
Cleaned up some useless/unused functions Change-Id: I6aa5d0ed3d21993ed653ee64b4928ef98874db2d
2012-06-07 22:02:25 +00:00
'domElement': ve.example.createDomElement( 'table' ),
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
'dataElement': { 'type': 'table' }
},
'tableRow': {
Cleaned up some useless/unused functions Change-Id: I6aa5d0ed3d21993ed653ee64b4928ef98874db2d
2012-06-07 22:02:25 +00:00
'domElement': ve.example.createDomElement( 'tr' ),
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
'dataElement': { 'type': 'tableRow' }
},
Change the HTML attribute prefix from html/ to html/0/ This means that <p data-foo="bar"> will now be converted to a paragraph with attributes {"html/0/data-foo":"bar"} rather than {"html/foo":"bar"} This paves the way for multi-element node (about group) handling in the node API: nodes representing multiple DOM elements will have html/i/attr to represent an attribute of the i'th DOM element. Change-Id: Iea52bdccd721942ca708c8f9f47e934524809845
2013-02-06 19:47:52 +00:00
'paragraph with data-mw attribute': {
Cleaned up some useless/unused functions Change-Id: I6aa5d0ed3d21993ed653ee64b4928ef98874db2d
2012-06-07 22:02:25 +00:00
'domElement': ve.example.createDomElement( 'p', { 'data-mw': '{"test":1234}' } ),
Change the HTML attribute prefix from html/ to html/0/ This means that <p data-foo="bar"> will now be converted to a paragraph with attributes {"html/0/data-foo":"bar"} rather than {"html/foo":"bar"} This paves the way for multi-element node (about group) handling in the node API: nodes representing multiple DOM elements will have html/i/attr to represent an attribute of the i'th DOM element. Change-Id: Iea52bdccd721942ca708c8f9f47e934524809845
2013-02-06 19:47:52 +00:00
'dataElement': { 'type': 'paragraph', 'attributes': { 'html/0/data-mw': '{"test":1234}' } }
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
},
Added implementation for ve.dm.Converter.getDataFromDom Change-Id: I8561d4a00ba630b86fb7bcd3e347fe2c6c2f6aa3
2012-06-07 00:47:27 +00:00
'paragraph with style attribute': {
Cleaned up some useless/unused functions Change-Id: I6aa5d0ed3d21993ed653ee64b4928ef98874db2d
2012-06-07 22:02:25 +00:00
'domElement': ve.example.createDomElement( 'p', { 'style': 'color:blue' } ),
Change the HTML attribute prefix from html/ to html/0/ This means that <p data-foo="bar"> will now be converted to a paragraph with attributes {"html/0/data-foo":"bar"} rather than {"html/foo":"bar"} This paves the way for multi-element node (about group) handling in the node API: nodes representing multiple DOM elements will have html/i/attr to represent an attribute of the i'th DOM element. Change-Id: Iea52bdccd721942ca708c8f9f47e934524809845
2013-02-06 19:47:52 +00:00
'dataElement': { 'type': 'paragraph', 'attributes': { 'html/0/style': 'color:blue' } }
Added getHtmlElementFromDataElement and getDataElementFromHtmlElement Change-Id: Ie5f4fd86612b5a6c34b5843d1e9a521edc626a63
2012-06-06 17:17:30 +00:00
}
};
Test getDomFromData using getDataFromDom's tests Move the test cases for getDataFromDom out into ve.dm.example and use them to test getDomFromData as well Change-Id: Ib33854a7a1e8cb6a8ebf2c5b88cd5c17e25644b2
2012-06-08 05:00:25 +00:00
ve.dm.example.domToDataCases = {
'paragraph with plain text': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><p>abc</p></body>',
Clean up a few commas and some indentation The commas were resulting from converting this: var foo = 3, bar = 5; to this: foo = 3, bar = 5; Change-Id: I0223b34a30d947c6a51f0601727b0c3850239e66
2012-08-10 23:49:14 +00:00
'data': [
{ 'type': 'paragraph' },
'a',
'b',
'c',
{ 'type': '/paragraph' }
]
},
'annotated text with bold, italic, underline formatting': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><p><b>a</b><i>b</i><u>c</u></p></body>',
Clean up a few commas and some indentation The commas were resulting from converting this: var foo = 3, bar = 5; to this: foo = 3, bar = 5; Change-Id: I0223b34a30d947c6a51f0601727b0c3850239e66
2012-08-10 23:49:14 +00:00
'data': [
{ 'type': 'paragraph' },
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
['a', [ ve.dm.example.bold ]],
['b', [ ve.dm.example.italic ]],
['c', [ ve.dm.example.underline ]],
Clean up a few commas and some indentation The commas were resulting from converting this: var foo = 3, bar = 5; to this: foo = 3, bar = 5; Change-Id: I0223b34a30d947c6a51f0601727b0c3850239e66
2012-08-10 23:49:14 +00:00
{ 'type': '/paragraph' }
]
},
'image': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><img src="image.png"></body>',
Clean up a few commas and some indentation The commas were resulting from converting this: var foo = 3, bar = 5; to this: foo = 3, bar = 5; Change-Id: I0223b34a30d947c6a51f0601727b0c3850239e66
2012-08-10 23:49:14 +00:00
'data': [
Fix bug where inline nodes didn't trigger wrapping When encountering an inline node (i.e. content node that's not a text node) within a branch node that's not a content branch node, the converter should start a wrapper. But it doesn't do this, it only opens wrappers for text nodes and annotations. Fixed this in the converter, added a test for it, and fixed an existing test that asserted the broken behavior. Change-Id: I6e143e21e68b68f0d85b8772e24a2d3a5d465410
2013-02-02 00:06:17 +00:00
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
Change the HTML attribute prefix from html/ to html/0/ This means that <p data-foo="bar"> will now be converted to a paragraph with attributes {"html/0/data-foo":"bar"} rather than {"html/foo":"bar"} This paves the way for multi-element node (about group) handling in the node API: nodes representing multiple DOM elements will have html/i/attr to represent an attribute of the i'th DOM element. Change-Id: Iea52bdccd721942ca708c8f9f47e934524809845
2013-02-06 19:47:52 +00:00
{ 'type': 'image', 'attributes' : { 'html/0/src' : 'image.png' } },
Fix bug where inline nodes didn't trigger wrapping When encountering an inline node (i.e. content node that's not a text node) within a branch node that's not a content branch node, the converter should start a wrapper. But it doesn't do this, it only opens wrappers for text nodes and annotations. Fixed this in the converter, added a test for it, and fixed an existing test that asserted the broken behavior. Change-Id: I6e143e21e68b68f0d85b8772e24a2d3a5d465410
2013-02-02 00:06:17 +00:00
{ 'type' : '/image' },
{ 'type': '/paragraph' }
Clean up a few commas and some indentation The commas were resulting from converting this: var foo = 3, bar = 5; to this: foo = 3, bar = 5; Change-Id: I0223b34a30d947c6a51f0601727b0c3850239e66
2012-08-10 23:49:14 +00:00
]
},
'paragraph with alienInline inside': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><p>a<tt class="foo">b</tt>c</p></body>',
Clean up a few commas and some indentation The commas were resulting from converting this: var foo = 3, bar = 5; to this: foo = 3, bar = 5; Change-Id: I0223b34a30d947c6a51f0601727b0c3850239e66
2012-08-10 23:49:14 +00:00
'data': [
{ 'type': 'paragraph' },
'a',
{
'type': 'alienInline',
Remove references to data-mw-gc data-mw-gc is ancient and unused. We do need to detect and alienate generated nodes, but that is now based on RDFa types. Removing the data-mw-gc stuff for now because it doesn't work anyway, will replace it with proper detection later. Replaced instances of data-mw-gc in the test suite with unregistered node types. Change-Id: If3f5898d382a436fa57929013264c53af5e840ba
2012-08-21 00:44:55 +00:00
'attributes': { 'html': '<tt class="foo">b</tt>' }
Clean up a few commas and some indentation The commas were resulting from converting this: var foo = 3, bar = 5; to this: foo = 3, bar = 5; Change-Id: I0223b34a30d947c6a51f0601727b0c3850239e66
2012-08-10 23:49:14 +00:00
},
{ 'type': '/alienInline' },
'c',
{ 'type': '/paragraph' }
]
},
'paragraphs with an alienBlock between them': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><p>abc</p><figure>abc</figure><p>def</p></body>',
Clean up a few commas and some indentation The commas were resulting from converting this: var foo = 3, bar = 5; to this: foo = 3, bar = 5; Change-Id: I0223b34a30d947c6a51f0601727b0c3850239e66
2012-08-10 23:49:14 +00:00
'data': [
{ 'type': 'paragraph' },
'a',
'b',
'c',
{ 'type': '/paragraph' },
Remove references to data-mw-gc data-mw-gc is ancient and unused. We do need to detect and alienate generated nodes, but that is now based on RDFa types. Removing the data-mw-gc stuff for now because it doesn't work anyway, will replace it with proper detection later. Replaced instances of data-mw-gc in the test suite with unregistered node types. Change-Id: If3f5898d382a436fa57929013264c53af5e840ba
2012-08-21 00:44:55 +00:00
{ 'type': 'alienBlock', 'attributes': { 'html': '<figure>abc</figure>' } },
Clean up a few commas and some indentation The commas were resulting from converting this: var foo = 3, bar = 5; to this: foo = 3, bar = 5; Change-Id: I0223b34a30d947c6a51f0601727b0c3850239e66
2012-08-10 23:49:14 +00:00
{ 'type': '/alienBlock' },
{ 'type': 'paragraph' },
'd',
'e',
'f',
{ 'type': '/paragraph' }
]
},
Handle annotated inline nodes in the converter Was broken both on the way in and on the way out. * Move alien restoration (data->DOM) out of the main getDomFromData() function and into getDomElementFromDataElement(). This means the comment about District 9 is gone (sniff), but moving this here ensures all code paths hit it (previously, it was assumed annotated nodes could never be aliens). * In the DOM->data converter, add annotation application to getDataElementFromDomElement() (for content nodes) and createAlien() (for aliens). Previously, these nodes would not get annotations. ** ve.AnnotationSet doesn't have a constructor that takes an array, we should fix that. Change-Id: I65f8e9a322111ca3af275bf9997b0b1e7ee93769
2012-11-24 02:44:54 +00:00
'annotated inline nodes': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><p>a<b><tt class="foo">b</tt><i><span typeof="mw:Entity">c</span></i></b>' +
'<i><br/>d</i>e</p></body>',
Handle annotated inline nodes in the converter Was broken both on the way in and on the way out. * Move alien restoration (data->DOM) out of the main getDomFromData() function and into getDomElementFromDataElement(). This means the comment about District 9 is gone (sniff), but moving this here ensures all code paths hit it (previously, it was assumed annotated nodes could never be aliens). * In the DOM->data converter, add annotation application to getDataElementFromDomElement() (for content nodes) and createAlien() (for aliens). Previously, these nodes would not get annotations. ** ve.AnnotationSet doesn't have a constructor that takes an array, we should fix that. Change-Id: I65f8e9a322111ca3af275bf9997b0b1e7ee93769
2012-11-24 02:44:54 +00:00
'data': [
{ 'type': 'paragraph' },
'a',
{
'type': 'alienInline',
'attributes': { 'html': '<tt class="foo">b</tt>' },
'annotations': [ ve.dm.example.bold ]
},
{ 'type': '/alienInline' },
{
'type': 'MWentity',
Change the HTML attribute prefix from html/ to html/0/ This means that <p data-foo="bar"> will now be converted to a paragraph with attributes {"html/0/data-foo":"bar"} rather than {"html/foo":"bar"} This paves the way for multi-element node (about group) handling in the node API: nodes representing multiple DOM elements will have html/i/attr to represent an attribute of the i'th DOM element. Change-Id: Iea52bdccd721942ca708c8f9f47e934524809845
2013-02-06 19:47:52 +00:00
'attributes': { 'character': 'c', 'html/0/typeof': 'mw:Entity' },
Handle annotated inline nodes in the converter Was broken both on the way in and on the way out. * Move alien restoration (data->DOM) out of the main getDomFromData() function and into getDomElementFromDataElement(). This means the comment about District 9 is gone (sniff), but moving this here ensures all code paths hit it (previously, it was assumed annotated nodes could never be aliens). * In the DOM->data converter, add annotation application to getDataElementFromDomElement() (for content nodes) and createAlien() (for aliens). Previously, these nodes would not get annotations. ** ve.AnnotationSet doesn't have a constructor that takes an array, we should fix that. Change-Id: I65f8e9a322111ca3af275bf9997b0b1e7ee93769
2012-11-24 02:44:54 +00:00
'annotations': [ ve.dm.example.bold, ve.dm.example.italic ]
},
{ 'type': '/MWentity' },
{
'type': 'break',
'annotations': [ ve.dm.example.italic ]
},
{ 'type': '/break' },
['d', [ ve.dm.example.italic ]],
'e',
{ 'type': '/paragraph' }
]
},
Wrap inline elements properly The HTML "1<br/>2" was being converted to a linmod that looked like "<p>1</p><br></br><p>2</p>". This commit fixes the wrapping logic such that the result is "<p>1<br></br>2</p>" instead. In general, inline nodes (content nodes) should not interrupt the wrapping, but block nodes should. This creates a problem for alien nodes: normally, we determine whether an alien node is a block alien or an inline alien based on context, but if we're in wrapping mode we're unsure of the context. We can't tell the difference between "1<tt>Foo</tt>2" (should be wrapped as one, because tt is inline) and "1<figure></figure>2" (1 and 2 should be wrapped separately, because figure is block) using context alone, so in these cases (and ONLY in these cases) we look up whether the HTML tag in question is an inline tag or a block tag and use that to decide. Change-Id: I75e7f3da387dd401d9b93e09a21751951eccbb83
2012-10-16 06:05:29 +00:00
'wrapping of bare content': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body>abc</body>',
Wrap inline elements properly The HTML "1<br/>2" was being converted to a linmod that looked like "<p>1</p><br></br><p>2</p>". This commit fixes the wrapping logic such that the result is "<p>1<br></br>2</p>" instead. In general, inline nodes (content nodes) should not interrupt the wrapping, but block nodes should. This creates a problem for alien nodes: normally, we determine whether an alien node is a block alien or an inline alien based on context, but if we're in wrapping mode we're unsure of the context. We can't tell the difference between "1<tt>Foo</tt>2" (should be wrapped as one, because tt is inline) and "1<figure></figure>2" (1 and 2 should be wrapped separately, because figure is block) using context alone, so in these cases (and ONLY in these cases) we look up whether the HTML tag in question is an inline tag or a block tag and use that to decide. Change-Id: I75e7f3da387dd401d9b93e09a21751951eccbb83
2012-10-16 06:05:29 +00:00
'data': [
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'a',
'b',
'c',
{ 'type': '/paragraph' }
]
},
'wrapping of bare content with inline node': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body>1<br/>2</body>',
Wrap inline elements properly The HTML "1<br/>2" was being converted to a linmod that looked like "<p>1</p><br></br><p>2</p>". This commit fixes the wrapping logic such that the result is "<p>1<br></br>2</p>" instead. In general, inline nodes (content nodes) should not interrupt the wrapping, but block nodes should. This creates a problem for alien nodes: normally, we determine whether an alien node is a block alien or an inline alien based on context, but if we're in wrapping mode we're unsure of the context. We can't tell the difference between "1<tt>Foo</tt>2" (should be wrapped as one, because tt is inline) and "1<figure></figure>2" (1 and 2 should be wrapped separately, because figure is block) using context alone, so in these cases (and ONLY in these cases) we look up whether the HTML tag in question is an inline tag or a block tag and use that to decide. Change-Id: I75e7f3da387dd401d9b93e09a21751951eccbb83
2012-10-16 06:05:29 +00:00
'data': [
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'1',
{ 'type': 'break' },
{ 'type': '/break' },
'2',
{ 'type': '/paragraph' }
]
},
Fix bug where inline nodes didn't trigger wrapping When encountering an inline node (i.e. content node that's not a text node) within a branch node that's not a content branch node, the converter should start a wrapper. But it doesn't do this, it only opens wrappers for text nodes and annotations. Fixed this in the converter, added a test for it, and fixed an existing test that asserted the broken behavior. Change-Id: I6e143e21e68b68f0d85b8772e24a2d3a5d465410
2013-02-02 00:06:17 +00:00
'wrapping of bare content starting with inline node': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><img src="foo.jpg">12</body>',
Fix bug where inline nodes didn't trigger wrapping When encountering an inline node (i.e. content node that's not a text node) within a branch node that's not a content branch node, the converter should start a wrapper. But it doesn't do this, it only opens wrappers for text nodes and annotations. Fixed this in the converter, added a test for it, and fixed an existing test that asserted the broken behavior. Change-Id: I6e143e21e68b68f0d85b8772e24a2d3a5d465410
2013-02-02 00:06:17 +00:00
'data': [
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
Change the HTML attribute prefix from html/ to html/0/ This means that <p data-foo="bar"> will now be converted to a paragraph with attributes {"html/0/data-foo":"bar"} rather than {"html/foo":"bar"} This paves the way for multi-element node (about group) handling in the node API: nodes representing multiple DOM elements will have html/i/attr to represent an attribute of the i'th DOM element. Change-Id: Iea52bdccd721942ca708c8f9f47e934524809845
2013-02-06 19:47:52 +00:00
{ 'type': 'image', 'attributes': { 'html/0/src': 'foo.jpg' } },
Fix bug where inline nodes didn't trigger wrapping When encountering an inline node (i.e. content node that's not a text node) within a branch node that's not a content branch node, the converter should start a wrapper. But it doesn't do this, it only opens wrappers for text nodes and annotations. Fixed this in the converter, added a test for it, and fixed an existing test that asserted the broken behavior. Change-Id: I6e143e21e68b68f0d85b8772e24a2d3a5d465410
2013-02-02 00:06:17 +00:00
{ 'type': '/image' },
'1',
'2',
{ 'type': '/paragraph' }
]
},
Wrap inline elements properly The HTML "1<br/>2" was being converted to a linmod that looked like "<p>1</p><br></br><p>2</p>". This commit fixes the wrapping logic such that the result is "<p>1<br></br>2</p>" instead. In general, inline nodes (content nodes) should not interrupt the wrapping, but block nodes should. This creates a problem for alien nodes: normally, we determine whether an alien node is a block alien or an inline alien based on context, but if we're in wrapping mode we're unsure of the context. We can't tell the difference between "1<tt>Foo</tt>2" (should be wrapped as one, because tt is inline) and "1<figure></figure>2" (1 and 2 should be wrapped separately, because figure is block) using context alone, so in these cases (and ONLY in these cases) we look up whether the HTML tag in question is an inline tag or a block tag and use that to decide. Change-Id: I75e7f3da387dd401d9b93e09a21751951eccbb83
2012-10-16 06:05:29 +00:00
'wrapping of bare content with inline alien': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body>1<tt class="bar">baz</tt>2</body>',
Wrap inline elements properly The HTML "1<br/>2" was being converted to a linmod that looked like "<p>1</p><br></br><p>2</p>". This commit fixes the wrapping logic such that the result is "<p>1<br></br>2</p>" instead. In general, inline nodes (content nodes) should not interrupt the wrapping, but block nodes should. This creates a problem for alien nodes: normally, we determine whether an alien node is a block alien or an inline alien based on context, but if we're in wrapping mode we're unsure of the context. We can't tell the difference between "1<tt>Foo</tt>2" (should be wrapped as one, because tt is inline) and "1<figure></figure>2" (1 and 2 should be wrapped separately, because figure is block) using context alone, so in these cases (and ONLY in these cases) we look up whether the HTML tag in question is an inline tag or a block tag and use that to decide. Change-Id: I75e7f3da387dd401d9b93e09a21751951eccbb83
2012-10-16 06:05:29 +00:00
'data': [
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'1',
{
'type': 'alienInline',
'attributes': { 'html': '<tt class="bar">baz</tt>' }
},
{ 'type': '/alienInline' },
'2',
{ 'type': '/paragraph' }
]
},
'wrapping of bare content with block alien': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body>1<figure class="bar">baz</figure>2</body>',
Wrap inline elements properly The HTML "1<br/>2" was being converted to a linmod that looked like "<p>1</p><br></br><p>2</p>". This commit fixes the wrapping logic such that the result is "<p>1<br></br>2</p>" instead. In general, inline nodes (content nodes) should not interrupt the wrapping, but block nodes should. This creates a problem for alien nodes: normally, we determine whether an alien node is a block alien or an inline alien based on context, but if we're in wrapping mode we're unsure of the context. We can't tell the difference between "1<tt>Foo</tt>2" (should be wrapped as one, because tt is inline) and "1<figure></figure>2" (1 and 2 should be wrapped separately, because figure is block) using context alone, so in these cases (and ONLY in these cases) we look up whether the HTML tag in question is an inline tag or a block tag and use that to decide. Change-Id: I75e7f3da387dd401d9b93e09a21751951eccbb83
2012-10-16 06:05:29 +00:00
'data': [
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'1',
{ 'type': '/paragraph' },
{
'type': 'alienBlock',
'attributes': { 'html': '<figure class="bar">baz</figure>' }
},
{ 'type': '/alienBlock' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'2',
{ 'type': '/paragraph' }
]
},
(bug 42119) Handle alienation in wrapping mode properly When alienating in wrapping mode, we need to look at the type of tag to decide whether to create a wrapped alienInline, or to interrupt the paragraph for an alienBlock. This was being done just fine for the general alienation case (unrecognized tag), but not for the special cases (mw:unrecognized, about groups). * Centralize the logic for ending a wrapper in stopWrapping() * Move the wrapping-contingent block/inline detection logic into createAlien() * Simplify the terrible if statement to decide whether a future decision requires us to stop wrapping. Instead, detect the cases in each code path separately and call stopWrapping() as appropriate * Add tests Change-Id: I4054584ae05e7d5daa71edead3e6a6588cf5d3bb
2012-11-20 04:26:54 +00:00
'wrapping of bare content with mw:unrecognized inline alien': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body>1<span typeof="mw:Placeholder">baz</span>2</body>',
(bug 42119) Handle alienation in wrapping mode properly When alienating in wrapping mode, we need to look at the type of tag to decide whether to create a wrapped alienInline, or to interrupt the paragraph for an alienBlock. This was being done just fine for the general alienation case (unrecognized tag), but not for the special cases (mw:unrecognized, about groups). * Centralize the logic for ending a wrapper in stopWrapping() * Move the wrapping-contingent block/inline detection logic into createAlien() * Simplify the terrible if statement to decide whether a future decision requires us to stop wrapping. Instead, detect the cases in each code path separately and call stopWrapping() as appropriate * Add tests Change-Id: I4054584ae05e7d5daa71edead3e6a6588cf5d3bb
2012-11-20 04:26:54 +00:00
'data': [
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'1',
{
'type': 'alienInline',
'attributes': { 'html': '<span typeof="mw:Placeholder">baz</span>' }
},
{ 'type': '/alienInline' },
'2',
{ 'type': '/paragraph' }
]
},
'wrapping of bare content with mw:unrecognized block alien': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body>1<div typeof="mw:Placeholder">baz</div>2</body>',
(bug 42119) Handle alienation in wrapping mode properly When alienating in wrapping mode, we need to look at the type of tag to decide whether to create a wrapped alienInline, or to interrupt the paragraph for an alienBlock. This was being done just fine for the general alienation case (unrecognized tag), but not for the special cases (mw:unrecognized, about groups). * Centralize the logic for ending a wrapper in stopWrapping() * Move the wrapping-contingent block/inline detection logic into createAlien() * Simplify the terrible if statement to decide whether a future decision requires us to stop wrapping. Instead, detect the cases in each code path separately and call stopWrapping() as appropriate * Add tests Change-Id: I4054584ae05e7d5daa71edead3e6a6588cf5d3bb
2012-11-20 04:26:54 +00:00
'data': [
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'1',
{ 'type': '/paragraph' },
{
'type': 'alienBlock',
'attributes': { 'html': '<div typeof="mw:Placeholder">baz</div>' }
},
{ 'type': '/alienBlock' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'2',
{ 'type': '/paragraph' }
]
},
(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-20 00:59:58 +00:00
'wrapping of bare content starting with mw:unrecognized inline alien': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><span typeof="mw:Placeholder">Foo</span>Bar</body>',
(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-20 00:59:58 +00:00
'data': [
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
{
'type': 'alienInline',
'attributes': { 'html': '<span typeof="mw:Placeholder">Foo</span>' }
},
{ 'type': '/alienInline' },
'B',
'a',
'r',
{ 'type': '/paragraph' }
]
},
'wrapping of bare content ending with mw:unrecognized inline alien': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body>Foo<span typeof="mw:Placeholder">Bar</span></body>',
(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-20 00:59:58 +00:00
'data': [
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'F',
'o',
'o',
{
'type': 'alienInline',
'attributes': { 'html': '<span typeof="mw:Placeholder">Bar</span>' }
},
{ 'type': '/alienInline' },
{ 'type': '/paragraph' }
]
},
(bug 42119) Handle alienation in wrapping mode properly When alienating in wrapping mode, we need to look at the type of tag to decide whether to create a wrapped alienInline, or to interrupt the paragraph for an alienBlock. This was being done just fine for the general alienation case (unrecognized tag), but not for the special cases (mw:unrecognized, about groups). * Centralize the logic for ending a wrapper in stopWrapping() * Move the wrapping-contingent block/inline detection logic into createAlien() * Simplify the terrible if statement to decide whether a future decision requires us to stop wrapping. Instead, detect the cases in each code path separately and call stopWrapping() as appropriate * Add tests Change-Id: I4054584ae05e7d5daa71edead3e6a6588cf5d3bb
2012-11-20 04:26:54 +00:00
'wrapping of bare content with about group': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body>1<tt about="#mwt1">foo</tt><tt about="#mwt1">bar</tt>2</body>',
(bug 42119) Handle alienation in wrapping mode properly When alienating in wrapping mode, we need to look at the type of tag to decide whether to create a wrapped alienInline, or to interrupt the paragraph for an alienBlock. This was being done just fine for the general alienation case (unrecognized tag), but not for the special cases (mw:unrecognized, about groups). * Centralize the logic for ending a wrapper in stopWrapping() * Move the wrapping-contingent block/inline detection logic into createAlien() * Simplify the terrible if statement to decide whether a future decision requires us to stop wrapping. Instead, detect the cases in each code path separately and call stopWrapping() as appropriate * Add tests Change-Id: I4054584ae05e7d5daa71edead3e6a6588cf5d3bb
2012-11-20 04:26:54 +00:00
'data': [
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'1',
{
(bug 45062) Implement the new node API in the converter This changes the node API to work with multiple elements, so we can support about groups. Instead of passing in and returning single DOM elements, we use arrays of DOM elements. ve.dm.Converter: * Pass modelRegistry into the constructor * Remove onNodeRegister handler and its data * Remove getDataElementFromDomElement() and getDataAnnotationFromDomElement(). Most logic moved into getDataFromDom(), some into createDataElement() * Remove createAlien(), replaced with createDataElement( ve.dm.AlienNode, ... ) * Replace doAboutGrouping() (which wrapped about groups) with getAboutGroup() (which returns an array of the nodes in the group) * Put in a hack so <meta>/<link> elements with an mw: property aren't alienated * Remove about group wrapping behavior in favor of just outputting multiple nodes ve.dm.AlienNode.js: * For multi-element aliens, only choose inline if all elements are inline, not just the first one ve.dm.example.js: * Add html/0 stuff for meta nodes * Fix test case to reflect new alien behavior Change-Id: I40dcc27430f778bc00a44b91b7d824bfb2718be6
2013-02-16 02:37:50 +00:00
'type': 'alienInline',
(bug 42119) Handle alienation in wrapping mode properly When alienating in wrapping mode, we need to look at the type of tag to decide whether to create a wrapped alienInline, or to interrupt the paragraph for an alienBlock. This was being done just fine for the general alienation case (unrecognized tag), but not for the special cases (mw:unrecognized, about groups). * Centralize the logic for ending a wrapper in stopWrapping() * Move the wrapping-contingent block/inline detection logic into createAlien() * Simplify the terrible if statement to decide whether a future decision requires us to stop wrapping. Instead, detect the cases in each code path separately and call stopWrapping() as appropriate * Add tests Change-Id: I4054584ae05e7d5daa71edead3e6a6588cf5d3bb
2012-11-20 04:26:54 +00:00
'attributes': { 'html': '<tt about="#mwt1">foo</tt><tt about="#mwt1">bar</tt>' }
},
(bug 45062) Implement the new node API in the converter This changes the node API to work with multiple elements, so we can support about groups. Instead of passing in and returning single DOM elements, we use arrays of DOM elements. ve.dm.Converter: * Pass modelRegistry into the constructor * Remove onNodeRegister handler and its data * Remove getDataElementFromDomElement() and getDataAnnotationFromDomElement(). Most logic moved into getDataFromDom(), some into createDataElement() * Remove createAlien(), replaced with createDataElement( ve.dm.AlienNode, ... ) * Replace doAboutGrouping() (which wrapped about groups) with getAboutGroup() (which returns an array of the nodes in the group) * Put in a hack so <meta>/<link> elements with an mw: property aren't alienated * Remove about group wrapping behavior in favor of just outputting multiple nodes ve.dm.AlienNode.js: * For multi-element aliens, only choose inline if all elements are inline, not just the first one ve.dm.example.js: * Add html/0 stuff for meta nodes * Fix test case to reflect new alien behavior Change-Id: I40dcc27430f778bc00a44b91b7d824bfb2718be6
2013-02-16 02:37:50 +00:00
{ 'type': '/alienInline' },
(bug 42119) Handle alienation in wrapping mode properly When alienating in wrapping mode, we need to look at the type of tag to decide whether to create a wrapped alienInline, or to interrupt the paragraph for an alienBlock. This was being done just fine for the general alienation case (unrecognized tag), but not for the special cases (mw:unrecognized, about groups). * Centralize the logic for ending a wrapper in stopWrapping() * Move the wrapping-contingent block/inline detection logic into createAlien() * Simplify the terrible if statement to decide whether a future decision requires us to stop wrapping. Instead, detect the cases in each code path separately and call stopWrapping() as appropriate * Add tests Change-Id: I4054584ae05e7d5daa71edead3e6a6588cf5d3bb
2012-11-20 04:26:54 +00:00
'2',
{ 'type': '/paragraph' }
]
},
Wrap inline elements properly The HTML "1<br/>2" was being converted to a linmod that looked like "<p>1</p><br></br><p>2</p>". This commit fixes the wrapping logic such that the result is "<p>1<br></br>2</p>" instead. In general, inline nodes (content nodes) should not interrupt the wrapping, but block nodes should. This creates a problem for alien nodes: normally, we determine whether an alien node is a block alien or an inline alien based on context, but if we're in wrapping mode we're unsure of the context. We can't tell the difference between "1<tt>Foo</tt>2" (should be wrapped as one, because tt is inline) and "1<figure></figure>2" (1 and 2 should be wrapped separately, because figure is block) using context alone, so in these cases (and ONLY in these cases) we look up whether the HTML tag in question is an inline tag or a block tag and use that to decide. Change-Id: I75e7f3da387dd401d9b93e09a21751951eccbb83
2012-10-16 06:05:29 +00:00
'wrapping of bare content between structural nodes': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><table></table>abc<table></table></body>',
Wrap inline elements properly The HTML "1<br/>2" was being converted to a linmod that looked like "<p>1</p><br></br><p>2</p>". This commit fixes the wrapping logic such that the result is "<p>1<br></br>2</p>" instead. In general, inline nodes (content nodes) should not interrupt the wrapping, but block nodes should. This creates a problem for alien nodes: normally, we determine whether an alien node is a block alien or an inline alien based on context, but if we're in wrapping mode we're unsure of the context. We can't tell the difference between "1<tt>Foo</tt>2" (should be wrapped as one, because tt is inline) and "1<figure></figure>2" (1 and 2 should be wrapped separately, because figure is block) using context alone, so in these cases (and ONLY in these cases) we look up whether the HTML tag in question is an inline tag or a block tag and use that to decide. Change-Id: I75e7f3da387dd401d9b93e09a21751951eccbb83
2012-10-16 06:05:29 +00:00
'data': [
{ 'type': 'table' },
{ 'type': '/table' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'a',
'b',
'c',
{ 'type': '/paragraph' },
{ 'type': 'table' },
{ 'type': '/table' }
]
},
'wrapping of bare content between paragraphs': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><p>abc</p>def<p></p></body>',
Wrap inline elements properly The HTML "1<br/>2" was being converted to a linmod that looked like "<p>1</p><br></br><p>2</p>". This commit fixes the wrapping logic such that the result is "<p>1<br></br>2</p>" instead. In general, inline nodes (content nodes) should not interrupt the wrapping, but block nodes should. This creates a problem for alien nodes: normally, we determine whether an alien node is a block alien or an inline alien based on context, but if we're in wrapping mode we're unsure of the context. We can't tell the difference between "1<tt>Foo</tt>2" (should be wrapped as one, because tt is inline) and "1<figure></figure>2" (1 and 2 should be wrapped separately, because figure is block) using context alone, so in these cases (and ONLY in these cases) we look up whether the HTML tag in question is an inline tag or a block tag and use that to decide. Change-Id: I75e7f3da387dd401d9b93e09a21751951eccbb83
2012-10-16 06:05:29 +00:00
'data': [
{ 'type': 'paragraph' },
'a',
'b',
'c',
{ 'type': '/paragraph' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'd',
'e',
'f',
{ 'type': '/paragraph' },
{ 'type': 'paragraph' },
{ 'type': '/paragraph' }
]
},
(bug 42121) Change markers lost for first paragraph on new page When editing a new page, or loading an empty page into the editor, the converter generates a paragraph so the document isn't completely empty. This paragraph is then unwrapped on the way out, potentially destroying change markers and generally producing strange HTML output. Mark this paragraph with generated=empty rather than generated=wrapper, and only unwrap it on the way out if it's still empty. This means we cleanly round-trip empty documents (and empty list items and the like), but if the user enters text, we create a paragraph like we're supposed to. Change-Id: Id0241221a67b769445676b833b5741320d99ea5f
2012-11-17 03:37:38 +00:00
'wrapping prevents empty list items': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><ul><li></li></ul></body>',
(bug 42121) Change markers lost for first paragraph on new page When editing a new page, or loading an empty page into the editor, the converter generates a paragraph so the document isn't completely empty. This paragraph is then unwrapped on the way out, potentially destroying change markers and generally producing strange HTML output. Mark this paragraph with generated=empty rather than generated=wrapper, and only unwrap it on the way out if it's still empty. This means we cleanly round-trip empty documents (and empty list items and the like), but if the user enters text, we create a paragraph like we're supposed to. Change-Id: Id0241221a67b769445676b833b5741320d99ea5f
2012-11-17 03:37:38 +00:00
'data': [
{ 'type': 'list', 'attributes': { 'style': 'bullet' } },
{ 'type': 'listItem' },
{ 'type': 'paragraph', 'internal': { 'generated': 'empty' } },
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': '/list' }
]
},
'empty document': {
'html': '',
'data': [
{ 'type': 'paragraph', 'internal': { 'generated': 'empty' } },
{ 'type': '/paragraph' }
]
},
'empty document with content added by the editor': {
'html': null,
'data': [
{ 'type': 'paragraph', 'internal': { 'generated': 'empty' } },
'F',
'o',
'o',
{ 'type': '/paragraph' }
],
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'normalizedHtml': '<body><p>Foo</p></body>'
(bug 42121) Change markers lost for first paragraph on new page When editing a new page, or loading an empty page into the editor, the converter generates a paragraph so the document isn't completely empty. This paragraph is then unwrapped on the way out, potentially destroying change markers and generally producing strange HTML output. Mark this paragraph with generated=empty rather than generated=wrapper, and only unwrap it on the way out if it's still empty. This means we cleanly round-trip empty documents (and empty list items and the like), but if the user enters text, we create a paragraph like we're supposed to. Change-Id: Id0241221a67b769445676b833b5741320d99ea5f
2012-11-17 03:37:38 +00:00
},
'empty list item with content added by the editor': {
'html': null,
'data': [
{ 'type': 'list', 'attributes': { 'style': 'bullet' } },
{ 'type': 'listItem' },
{ 'type': 'paragraph', 'internal': { 'generated': 'empty' } },
'F',
'o',
'o',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': '/list' }
],
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'normalizedHtml': '<body><ul><li><p>Foo</p></li></ul></body>'
(bug 42121) Change markers lost for first paragraph on new page When editing a new page, or loading an empty page into the editor, the converter generates a paragraph so the document isn't completely empty. This paragraph is then unwrapped on the way out, potentially destroying change markers and generally producing strange HTML output. Mark this paragraph with generated=empty rather than generated=wrapper, and only unwrap it on the way out if it's still empty. This means we cleanly round-trip empty documents (and empty list items and the like), but if the user enters text, we create a paragraph like we're supposed to. Change-Id: Id0241221a67b769445676b833b5741320d99ea5f
2012-11-17 03:37:38 +00:00
},
Clean up a few commas and some indentation The commas were resulting from converting this: var foo = 3, bar = 5; to this: foo = 3, bar = 5; Change-Id: I0223b34a30d947c6a51f0601727b0c3850239e66
2012-08-10 23:49:14 +00:00
'example document': {
'html': ve.dm.example.html,
'data': ve.dm.example.data
},
'list item with space followed by link': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><ul><li><p> <a rel="mw:WikiLink" href="Foo_bar" data-rt="{&quot;sHref&quot;:&quot;foo bar&quot;}">bar</a></p></li></ul></body>',
Clean up a few commas and some indentation The commas were resulting from converting this: var foo = 3, bar = 5; to this: foo = 3, bar = 5; Change-Id: I0223b34a30d947c6a51f0601727b0c3850239e66
2012-08-10 23:49:14 +00:00
'data': [
{ 'type': 'list', 'attributes': { 'style': 'bullet' } },
{ 'type': 'listItem' },
Rename fringeWhitespace to internal This allows us to put other internal data in there in the future. Also passing it through the Node constructor properly now. * ve.dm.Node ** Rename fringeWhitespace property to internal ** Add internal parameter to constructor ** Remove setFringeWhitespace() * Increase the number of parameters passed through by ve.Factory to 3 * Pass through .internal from linmod to nodeFactory in ve.dm.Document * ve.dm.Converter ** Rename .fringeWhitespace to .internal.whitespace and make it an array ** Store a temporary reference to .internal in domElement.veInternal * Add internal to all node constructors except TextNode Tests: * Update for fringeWhitespace->internal rename * Add third parameter to ve.Factory tests * Add .internal to getNodeTreeSummary Change-Id: If20c0bb78fee3efa55f72e51e7fc261283358de7
2012-08-16 17:53:33 +00:00
{ 'type': 'paragraph', 'internal': { 'whitespace': [ undefined, ' ' ] } },
Clean up a few commas and some indentation The commas were resulting from converting this: var foo = 3, bar = 5; to this: foo = 3, bar = 5; Change-Id: I0223b34a30d947c6a51f0601727b0c3850239e66
2012-08-10 23:49:14 +00:00
[
Test getDomFromData using getDataFromDom's tests Move the test cases for getDataFromDom out into ve.dm.example and use them to test getDomFromData as well Change-Id: Ib33854a7a1e8cb6a8ebf2c5b88cd5c17e25644b2
2012-06-08 05:00:25 +00:00
'b',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
[ {
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'type': 'link/MWinternal',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
'data': {
'title': 'Foo bar',
Fix tests for fda2e6c1b54a0139a3123de413f672e895ff3352 Change-Id: I2725f3f775e092bafe7aa9dca71d2a9022f16db8
2012-11-23 18:56:00 +00:00
'origTitle': 'Foo_bar',
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'hrefPrefix': ''
},
'htmlTagName': 'a',
'htmlAttributes': {
'data-rt': '{"sHref":"foo bar"}',
'href': 'Foo_bar',
'rel': 'mw:WikiLink'
Fixed multi-auto-wrapping issue and added tests to track regressions Roan mostly wrote this Change-Id: Id292c84a4da97d6608aa7c17ab6a4cf5a2e3f409
2012-06-08 22:16:55 +00:00
}
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
} ]
Clean up a few commas and some indentation The commas were resulting from converting this: var foo = 3, bar = 5; to this: foo = 3, bar = 5; Change-Id: I0223b34a30d947c6a51f0601727b0c3850239e66
2012-08-10 23:49:14 +00:00
],
[
'a',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
[ {
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'type': 'link/MWinternal',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
'data': {
'title': 'Foo bar',
Fix tests for fda2e6c1b54a0139a3123de413f672e895ff3352 Change-Id: I2725f3f775e092bafe7aa9dca71d2a9022f16db8
2012-11-23 18:56:00 +00:00
'origTitle': 'Foo_bar',
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'hrefPrefix': ''
},
'htmlTagName': 'a',
'htmlAttributes': {
'data-rt': '{"sHref":"foo bar"}',
'href': 'Foo_bar',
'rel': 'mw:WikiLink'
Fixed multi-auto-wrapping issue and added tests to track regressions Roan mostly wrote this Change-Id: Id292c84a4da97d6608aa7c17ab6a4cf5a2e3f409
2012-06-08 22:16:55 +00:00
}
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
} ]
Clean up a few commas and some indentation The commas were resulting from converting this: var foo = 3, bar = 5; to this: foo = 3, bar = 5; Change-Id: I0223b34a30d947c6a51f0601727b0c3850239e66
2012-08-10 23:49:14 +00:00
],
[
'r',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
[ {
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'type': 'link/MWinternal',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
'data': {
'title': 'Foo bar',
Fix tests for fda2e6c1b54a0139a3123de413f672e895ff3352 Change-Id: I2725f3f775e092bafe7aa9dca71d2a9022f16db8
2012-11-23 18:56:00 +00:00
'origTitle': 'Foo_bar',
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'hrefPrefix': ''
},
'htmlTagName': 'a',
'htmlAttributes': {
'data-rt': '{"sHref":"foo bar"}',
'href': 'Foo_bar',
'rel': 'mw:WikiLink'
Fixed multi-auto-wrapping issue and added tests to track regressions Roan mostly wrote this Change-Id: Id292c84a4da97d6608aa7c17ab6a4cf5a2e3f409
2012-06-08 22:16:55 +00:00
}
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
} ]
Clean up a few commas and some indentation The commas were resulting from converting this: var foo = 3, bar = 5; to this: foo = 3, bar = 5; Change-Id: I0223b34a30d947c6a51f0601727b0c3850239e66
2012-08-10 23:49:14 +00:00
],
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': '/list' }
]
Strip and preserve inner leading&trailing whitespace in the linear model This makes things like == Foo == * Bar render without the leading and trailing spaces, while still round-tripping those spaces. * Added a .fringeWhitespace property to the linear model and ve.dm.Node ** Object containing innerPre, innerPost, outerPre, outerPost ** Only inner* are used right now, outer* are planned for future use ** Like .attributes , it's suppressed if it's an empty object * In getDataFromDom(): ** Store the stripped whitespace in .fringeWhitespace ** Move emptiness check up: empty elements with .fringeWhitespace have to be preserved ** Move paragraph wrapping up: .fringeWhitespace has to be applied to the generated paragraph, not its parent ** Add wrapperElement to keep track of the element .fringeWhitespace has to be added to; this is either dataElement or the generated paragraph or nothing, but we can't modify dataElement because it's used later * In getDomFromData(): ** When processing an opening, store the fringeWhitespace data in the generated DOM node ** When processing a closing, add the stored whitespace back in * In the ve.dm.Document constructor, pass through .fringeWhitespace from the linear model data to the generated nodes Tests: * Change one existing test case to account for this change * Add three new test cases for this behavior * Add normalizedHtml field so I can test behavior with bare content Change-Id: I0411544652dd72b923c831c495d69ee4322a2c14
2012-08-10 21:09:04 +00:00
},
Also strip ./ in addition to ../ This is necessary because Parsoid is now prefixing all hrefs with ./ Change-Id: I18c4b7470cfa1dd174e25cc921bf7d4daf5ffc55
2012-08-23 21:29:43 +00:00
'internal link with ./ and ../': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><p><a rel="mw:WikiLink" href="./../../../Foo/Bar">Foo</a></p></body>',
'normalizedHtml': '<body><p><a rel="mw:WikiLink" href="./../../../Foo/Bar">Foo</a></p></body>',
Update LinkAnnotation for Parsoid href changes Because the Parsoid prefix format changed from /mw:Foo to /mw/Foo , the href format for internal links has changed from "/Foo" to "Foo". So the href is now simply the title, except that it may be preceded by one or more "../" if the title of the page we're on contains a '/'. So instead of stripping the leading slash from internal link hrefs and putting it back on the way out, only strip any leading "../"s and dump the titles directly into the hrefs on the way out. Also update the link test case for this, and add a test case for the ../ stripping. Change-Id: I3e0bdde20f22cda34eb45fc351de5e780419b6a2
2012-08-14 00:59:16 +00:00
'data': [
{ 'type': 'paragraph' },
[
'F',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
[ {
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'type': 'link/MWinternal',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
'data': {
'title': 'Foo/Bar',
Fix tests for fda2e6c1b54a0139a3123de413f672e895ff3352 Change-Id: I2725f3f775e092bafe7aa9dca71d2a9022f16db8
2012-11-23 18:56:00 +00:00
'origTitle': 'Foo/Bar',
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'hrefPrefix': './../../../'
},
'htmlTagName': 'a',
'htmlAttributes': {
'href': './../../../Foo/Bar',
'rel': 'mw:WikiLink'
Update LinkAnnotation for Parsoid href changes Because the Parsoid prefix format changed from /mw:Foo to /mw/Foo , the href format for internal links has changed from "/Foo" to "Foo". So the href is now simply the title, except that it may be preceded by one or more "../" if the title of the page we're on contains a '/'. So instead of stripping the leading slash from internal link hrefs and putting it back on the way out, only strip any leading "../"s and dump the titles directly into the hrefs on the way out. Also update the link test case for this, and add a test case for the ../ stripping. Change-Id: I3e0bdde20f22cda34eb45fc351de5e780419b6a2
2012-08-14 00:59:16 +00:00
}
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
} ]
Update LinkAnnotation for Parsoid href changes Because the Parsoid prefix format changed from /mw:Foo to /mw/Foo , the href format for internal links has changed from "/Foo" to "Foo". So the href is now simply the title, except that it may be preceded by one or more "../" if the title of the page we're on contains a '/'. So instead of stripping the leading slash from internal link hrefs and putting it back on the way out, only strip any leading "../"s and dump the titles directly into the hrefs on the way out. Also update the link test case for this, and add a test case for the ../ stripping. Change-Id: I3e0bdde20f22cda34eb45fc351de5e780419b6a2
2012-08-14 00:59:16 +00:00
],
[
'o',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
[ {
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'type': 'link/MWinternal',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
'data': {
'title': 'Foo/Bar',
Fix tests for fda2e6c1b54a0139a3123de413f672e895ff3352 Change-Id: I2725f3f775e092bafe7aa9dca71d2a9022f16db8
2012-11-23 18:56:00 +00:00
'origTitle': 'Foo/Bar',
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'hrefPrefix': './../../../'
},
'htmlTagName': 'a',
'htmlAttributes': {
'href': './../../../Foo/Bar',
'rel': 'mw:WikiLink'
Update LinkAnnotation for Parsoid href changes Because the Parsoid prefix format changed from /mw:Foo to /mw/Foo , the href format for internal links has changed from "/Foo" to "Foo". So the href is now simply the title, except that it may be preceded by one or more "../" if the title of the page we're on contains a '/'. So instead of stripping the leading slash from internal link hrefs and putting it back on the way out, only strip any leading "../"s and dump the titles directly into the hrefs on the way out. Also update the link test case for this, and add a test case for the ../ stripping. Change-Id: I3e0bdde20f22cda34eb45fc351de5e780419b6a2
2012-08-14 00:59:16 +00:00
}
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
} ]
Update LinkAnnotation for Parsoid href changes Because the Parsoid prefix format changed from /mw:Foo to /mw/Foo , the href format for internal links has changed from "/Foo" to "Foo". So the href is now simply the title, except that it may be preceded by one or more "../" if the title of the page we're on contains a '/'. So instead of stripping the leading slash from internal link hrefs and putting it back on the way out, only strip any leading "../"s and dump the titles directly into the hrefs on the way out. Also update the link test case for this, and add a test case for the ../ stripping. Change-Id: I3e0bdde20f22cda34eb45fc351de5e780419b6a2
2012-08-14 00:59:16 +00:00
],
[
'o',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
[ {
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'type': 'link/MWinternal',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
'data': {
'title': 'Foo/Bar',
Fix tests for fda2e6c1b54a0139a3123de413f672e895ff3352 Change-Id: I2725f3f775e092bafe7aa9dca71d2a9022f16db8
2012-11-23 18:56:00 +00:00
'origTitle': 'Foo/Bar',
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'hrefPrefix': './../../../'
},
'htmlTagName': 'a',
'htmlAttributes': {
'href': './../../../Foo/Bar',
'rel': 'mw:WikiLink'
Update LinkAnnotation for Parsoid href changes Because the Parsoid prefix format changed from /mw:Foo to /mw/Foo , the href format for internal links has changed from "/Foo" to "Foo". So the href is now simply the title, except that it may be preceded by one or more "../" if the title of the page we're on contains a '/'. So instead of stripping the leading slash from internal link hrefs and putting it back on the way out, only strip any leading "../"s and dump the titles directly into the hrefs on the way out. Also update the link test case for this, and add a test case for the ../ stripping. Change-Id: I3e0bdde20f22cda34eb45fc351de5e780419b6a2
2012-08-14 00:59:16 +00:00
}
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
} ]
Update LinkAnnotation for Parsoid href changes Because the Parsoid prefix format changed from /mw:Foo to /mw/Foo , the href format for internal links has changed from "/Foo" to "Foo". So the href is now simply the title, except that it may be preceded by one or more "../" if the title of the page we're on contains a '/'. So instead of stripping the leading slash from internal link hrefs and putting it back on the way out, only strip any leading "../"s and dump the titles directly into the hrefs on the way out. Also update the link test case for this, and add a test case for the ../ stripping. Change-Id: I3e0bdde20f22cda34eb45fc351de5e780419b6a2
2012-08-14 00:59:16 +00:00
],
{ 'type': '/paragraph' }
]
},
Recognize annotation types with multiple slashes correctly Annotation types with more than one slash such as 'link/ExtLink/URL' weren't being processed correctly because .split( '/', 2 ) throws away everything after the second slash. Instead, don't pass a limit to .split(); the code for reconstructing a slash-separated string from multiple components was already in place. Also add test cases for URL links and numbered links. (Do you like the lines-of-code to lines-of-test ratio in this commit, Trevor? ;) ) Change-Id: I7add87396447a01b1c23a4f9bfd63d2e8fd861ce
2012-08-14 00:50:43 +00:00
'numbered external link': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><p><a rel="mw:ExtLink/Numbered" href="http://www.mediawiki.org/">[1]</a></p></body>',
Recognize annotation types with multiple slashes correctly Annotation types with more than one slash such as 'link/ExtLink/URL' weren't being processed correctly because .split( '/', 2 ) throws away everything after the second slash. Instead, don't pass a limit to .split(); the code for reconstructing a slash-separated string from multiple components was already in place. Also add test cases for URL links and numbered links. (Do you like the lines-of-code to lines-of-test ratio in this commit, Trevor? ;) ) Change-Id: I7add87396447a01b1c23a4f9bfd63d2e8fd861ce
2012-08-14 00:50:43 +00:00
'data': [
{ 'type': 'paragraph' },
[
'[',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
[ {
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'type': 'link/MWexternal',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
'data': {
Remove trailing commas JSHint doesn't detect this (this is an open bug against jshint), but Eclipse does Change-Id: Iebfc0f9c6263f60898739c9d19400357a65da0e9
2013-02-01 22:45:35 +00:00
'href': 'http://www.mediawiki.org/'
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
},
'htmlTagName': 'a',
'htmlAttributes': {
'href': 'http://www.mediawiki.org/',
'rel': 'mw:ExtLink/Numbered'
Recognize annotation types with multiple slashes correctly Annotation types with more than one slash such as 'link/ExtLink/URL' weren't being processed correctly because .split( '/', 2 ) throws away everything after the second slash. Instead, don't pass a limit to .split(); the code for reconstructing a slash-separated string from multiple components was already in place. Also add test cases for URL links and numbered links. (Do you like the lines-of-code to lines-of-test ratio in this commit, Trevor? ;) ) Change-Id: I7add87396447a01b1c23a4f9bfd63d2e8fd861ce
2012-08-14 00:50:43 +00:00
}
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
} ]
Recognize annotation types with multiple slashes correctly Annotation types with more than one slash such as 'link/ExtLink/URL' weren't being processed correctly because .split( '/', 2 ) throws away everything after the second slash. Instead, don't pass a limit to .split(); the code for reconstructing a slash-separated string from multiple components was already in place. Also add test cases for URL links and numbered links. (Do you like the lines-of-code to lines-of-test ratio in this commit, Trevor? ;) ) Change-Id: I7add87396447a01b1c23a4f9bfd63d2e8fd861ce
2012-08-14 00:50:43 +00:00
],
[
'1',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
[ {
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'type': 'link/MWexternal',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
'data': {
Remove trailing commas JSHint doesn't detect this (this is an open bug against jshint), but Eclipse does Change-Id: Iebfc0f9c6263f60898739c9d19400357a65da0e9
2013-02-01 22:45:35 +00:00
'href': 'http://www.mediawiki.org/'
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
},
'htmlTagName': 'a',
'htmlAttributes': {
'href': 'http://www.mediawiki.org/',
'rel': 'mw:ExtLink/Numbered'
Recognize annotation types with multiple slashes correctly Annotation types with more than one slash such as 'link/ExtLink/URL' weren't being processed correctly because .split( '/', 2 ) throws away everything after the second slash. Instead, don't pass a limit to .split(); the code for reconstructing a slash-separated string from multiple components was already in place. Also add test cases for URL links and numbered links. (Do you like the lines-of-code to lines-of-test ratio in this commit, Trevor? ;) ) Change-Id: I7add87396447a01b1c23a4f9bfd63d2e8fd861ce
2012-08-14 00:50:43 +00:00
}
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
} ]
Recognize annotation types with multiple slashes correctly Annotation types with more than one slash such as 'link/ExtLink/URL' weren't being processed correctly because .split( '/', 2 ) throws away everything after the second slash. Instead, don't pass a limit to .split(); the code for reconstructing a slash-separated string from multiple components was already in place. Also add test cases for URL links and numbered links. (Do you like the lines-of-code to lines-of-test ratio in this commit, Trevor? ;) ) Change-Id: I7add87396447a01b1c23a4f9bfd63d2e8fd861ce
2012-08-14 00:50:43 +00:00
],
[
']',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
[ {
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'type': 'link/MWexternal',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
'data': {
Remove trailing commas JSHint doesn't detect this (this is an open bug against jshint), but Eclipse does Change-Id: Iebfc0f9c6263f60898739c9d19400357a65da0e9
2013-02-01 22:45:35 +00:00
'href': 'http://www.mediawiki.org/'
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
},
'htmlTagName': 'a',
'htmlAttributes': {
'href': 'http://www.mediawiki.org/',
'rel': 'mw:ExtLink/Numbered'
Recognize annotation types with multiple slashes correctly Annotation types with more than one slash such as 'link/ExtLink/URL' weren't being processed correctly because .split( '/', 2 ) throws away everything after the second slash. Instead, don't pass a limit to .split(); the code for reconstructing a slash-separated string from multiple components was already in place. Also add test cases for URL links and numbered links. (Do you like the lines-of-code to lines-of-test ratio in this commit, Trevor? ;) ) Change-Id: I7add87396447a01b1c23a4f9bfd63d2e8fd861ce
2012-08-14 00:50:43 +00:00
}
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
} ]
Recognize annotation types with multiple slashes correctly Annotation types with more than one slash such as 'link/ExtLink/URL' weren't being processed correctly because .split( '/', 2 ) throws away everything after the second slash. Instead, don't pass a limit to .split(); the code for reconstructing a slash-separated string from multiple components was already in place. Also add test cases for URL links and numbered links. (Do you like the lines-of-code to lines-of-test ratio in this commit, Trevor? ;) ) Change-Id: I7add87396447a01b1c23a4f9bfd63d2e8fd861ce
2012-08-14 00:50:43 +00:00
],
{ 'type': '/paragraph' }
]
},
'URL link': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><p><a rel="mw:ExtLink/URL" href="http://www.mediawiki.org/">mw</a></p></body>',
Recognize annotation types with multiple slashes correctly Annotation types with more than one slash such as 'link/ExtLink/URL' weren't being processed correctly because .split( '/', 2 ) throws away everything after the second slash. Instead, don't pass a limit to .split(); the code for reconstructing a slash-separated string from multiple components was already in place. Also add test cases for URL links and numbered links. (Do you like the lines-of-code to lines-of-test ratio in this commit, Trevor? ;) ) Change-Id: I7add87396447a01b1c23a4f9bfd63d2e8fd861ce
2012-08-14 00:50:43 +00:00
'data': [
{ 'type': 'paragraph' },
[
'm',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
[ {
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'type': 'link/MWexternal',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
'data': {
Remove trailing commas JSHint doesn't detect this (this is an open bug against jshint), but Eclipse does Change-Id: Iebfc0f9c6263f60898739c9d19400357a65da0e9
2013-02-01 22:45:35 +00:00
'href': 'http://www.mediawiki.org/'
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
},
'htmlTagName': 'a',
'htmlAttributes': {
'href': 'http://www.mediawiki.org/',
'rel': 'mw:ExtLink/URL'
Recognize annotation types with multiple slashes correctly Annotation types with more than one slash such as 'link/ExtLink/URL' weren't being processed correctly because .split( '/', 2 ) throws away everything after the second slash. Instead, don't pass a limit to .split(); the code for reconstructing a slash-separated string from multiple components was already in place. Also add test cases for URL links and numbered links. (Do you like the lines-of-code to lines-of-test ratio in this commit, Trevor? ;) ) Change-Id: I7add87396447a01b1c23a4f9bfd63d2e8fd861ce
2012-08-14 00:50:43 +00:00
}
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
} ]
Recognize annotation types with multiple slashes correctly Annotation types with more than one slash such as 'link/ExtLink/URL' weren't being processed correctly because .split( '/', 2 ) throws away everything after the second slash. Instead, don't pass a limit to .split(); the code for reconstructing a slash-separated string from multiple components was already in place. Also add test cases for URL links and numbered links. (Do you like the lines-of-code to lines-of-test ratio in this commit, Trevor? ;) ) Change-Id: I7add87396447a01b1c23a4f9bfd63d2e8fd861ce
2012-08-14 00:50:43 +00:00
],
[
'w',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
[ {
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'type': 'link/MWexternal',
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
'data': {
Remove trailing commas JSHint doesn't detect this (this is an open bug against jshint), but Eclipse does Change-Id: Iebfc0f9c6263f60898739c9d19400357a65da0e9
2013-02-01 22:45:35 +00:00
'href': 'http://www.mediawiki.org/'
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
},
'htmlTagName': 'a',
'htmlAttributes': {
'href': 'http://www.mediawiki.org/',
'rel': 'mw:ExtLink/URL'
Recognize annotation types with multiple slashes correctly Annotation types with more than one slash such as 'link/ExtLink/URL' weren't being processed correctly because .split( '/', 2 ) throws away everything after the second slash. Instead, don't pass a limit to .split(); the code for reconstructing a slash-separated string from multiple components was already in place. Also add test cases for URL links and numbered links. (Do you like the lines-of-code to lines-of-test ratio in this commit, Trevor? ;) ) Change-Id: I7add87396447a01b1c23a4f9bfd63d2e8fd861ce
2012-08-14 00:50:43 +00:00
}
Manage annotations in ve.AnnotationSet object Introduced the ve.AnnotationSet class to manage sets of annotations. This is a generalization of ve.OrderedHashSet, a class that manages a set using an array and an object keyed by hash. Converted everything that stores, tracks or passes around annotations to use ve.AnnotationSet. In particular, this means the linear model now contains AnnotationSets instead of hash-keyed objects. This allows us to maintain the order of annotations in the linear model, and will help fix bugs with annotation ordering and splitting. Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-08-24 02:06:36 +00:00
} ]
Recognize annotation types with multiple slashes correctly Annotation types with more than one slash such as 'link/ExtLink/URL' weren't being processed correctly because .split( '/', 2 ) throws away everything after the second slash. Instead, don't pass a limit to .split(); the code for reconstructing a slash-separated string from multiple components was already in place. Also add test cases for URL links and numbered links. (Do you like the lines-of-code to lines-of-test ratio in this commit, Trevor? ;) ) Change-Id: I7add87396447a01b1c23a4f9bfd63d2e8fd861ce
2012-08-14 00:50:43 +00:00
],
{ 'type': '/paragraph' }
]
},
Strip and preserve inner leading&trailing whitespace in the linear model This makes things like == Foo == * Bar render without the leading and trailing spaces, while still round-tripping those spaces. * Added a .fringeWhitespace property to the linear model and ve.dm.Node ** Object containing innerPre, innerPost, outerPre, outerPost ** Only inner* are used right now, outer* are planned for future use ** Like .attributes , it's suppressed if it's an empty object * In getDataFromDom(): ** Store the stripped whitespace in .fringeWhitespace ** Move emptiness check up: empty elements with .fringeWhitespace have to be preserved ** Move paragraph wrapping up: .fringeWhitespace has to be applied to the generated paragraph, not its parent ** Add wrapperElement to keep track of the element .fringeWhitespace has to be added to; this is either dataElement or the generated paragraph or nothing, but we can't modify dataElement because it's used later * In getDomFromData(): ** When processing an opening, store the fringeWhitespace data in the generated DOM node ** When processing a closing, add the stored whitespace back in * In the ve.dm.Document constructor, pass through .fringeWhitespace from the linear model data to the generated nodes Tests: * Change one existing test case to account for this change * Add three new test cases for this behavior * Add normalizedHtml field so I can test behavior with bare content Change-Id: I0411544652dd72b923c831c495d69ee4322a2c14
2012-08-10 21:09:04 +00:00
'whitespace preservation in headings': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><h2>Foo</h2><h2> Bar</h2><h2>Baz </h2><h2> Quux </h2></body>',
Strip and preserve inner leading&trailing whitespace in the linear model This makes things like == Foo == * Bar render without the leading and trailing spaces, while still round-tripping those spaces. * Added a .fringeWhitespace property to the linear model and ve.dm.Node ** Object containing innerPre, innerPost, outerPre, outerPost ** Only inner* are used right now, outer* are planned for future use ** Like .attributes , it's suppressed if it's an empty object * In getDataFromDom(): ** Store the stripped whitespace in .fringeWhitespace ** Move emptiness check up: empty elements with .fringeWhitespace have to be preserved ** Move paragraph wrapping up: .fringeWhitespace has to be applied to the generated paragraph, not its parent ** Add wrapperElement to keep track of the element .fringeWhitespace has to be added to; this is either dataElement or the generated paragraph or nothing, but we can't modify dataElement because it's used later * In getDomFromData(): ** When processing an opening, store the fringeWhitespace data in the generated DOM node ** When processing a closing, add the stored whitespace back in * In the ve.dm.Document constructor, pass through .fringeWhitespace from the linear model data to the generated nodes Tests: * Change one existing test case to account for this change * Add three new test cases for this behavior * Add normalizedHtml field so I can test behavior with bare content Change-Id: I0411544652dd72b923c831c495d69ee4322a2c14
2012-08-10 21:09:04 +00:00
'data': [
{ 'type': 'heading', 'attributes': { 'level': 2 } },
'F',
'o',
'o',
{ 'type': '/heading' },
{
'type': 'heading',
'attributes': { 'level': 2 },
Rename fringeWhitespace to internal This allows us to put other internal data in there in the future. Also passing it through the Node constructor properly now. * ve.dm.Node ** Rename fringeWhitespace property to internal ** Add internal parameter to constructor ** Remove setFringeWhitespace() * Increase the number of parameters passed through by ve.Factory to 3 * Pass through .internal from linmod to nodeFactory in ve.dm.Document * ve.dm.Converter ** Rename .fringeWhitespace to .internal.whitespace and make it an array ** Store a temporary reference to .internal in domElement.veInternal * Add internal to all node constructors except TextNode Tests: * Update for fringeWhitespace->internal rename * Add third parameter to ve.Factory tests * Add .internal to getNodeTreeSummary Change-Id: If20c0bb78fee3efa55f72e51e7fc261283358de7
2012-08-16 17:53:33 +00:00
'internal': { 'whitespace': [ undefined, ' ' ] }
Strip and preserve inner leading&trailing whitespace in the linear model This makes things like == Foo == * Bar render without the leading and trailing spaces, while still round-tripping those spaces. * Added a .fringeWhitespace property to the linear model and ve.dm.Node ** Object containing innerPre, innerPost, outerPre, outerPost ** Only inner* are used right now, outer* are planned for future use ** Like .attributes , it's suppressed if it's an empty object * In getDataFromDom(): ** Store the stripped whitespace in .fringeWhitespace ** Move emptiness check up: empty elements with .fringeWhitespace have to be preserved ** Move paragraph wrapping up: .fringeWhitespace has to be applied to the generated paragraph, not its parent ** Add wrapperElement to keep track of the element .fringeWhitespace has to be added to; this is either dataElement or the generated paragraph or nothing, but we can't modify dataElement because it's used later * In getDomFromData(): ** When processing an opening, store the fringeWhitespace data in the generated DOM node ** When processing a closing, add the stored whitespace back in * In the ve.dm.Document constructor, pass through .fringeWhitespace from the linear model data to the generated nodes Tests: * Change one existing test case to account for this change * Add three new test cases for this behavior * Add normalizedHtml field so I can test behavior with bare content Change-Id: I0411544652dd72b923c831c495d69ee4322a2c14
2012-08-10 21:09:04 +00:00
},
'B',
'a',
'r',
{ 'type': '/heading' },
{
'type': 'heading',
'attributes': { 'level': 2 },
Rename fringeWhitespace to internal This allows us to put other internal data in there in the future. Also passing it through the Node constructor properly now. * ve.dm.Node ** Rename fringeWhitespace property to internal ** Add internal parameter to constructor ** Remove setFringeWhitespace() * Increase the number of parameters passed through by ve.Factory to 3 * Pass through .internal from linmod to nodeFactory in ve.dm.Document * ve.dm.Converter ** Rename .fringeWhitespace to .internal.whitespace and make it an array ** Store a temporary reference to .internal in domElement.veInternal * Add internal to all node constructors except TextNode Tests: * Update for fringeWhitespace->internal rename * Add third parameter to ve.Factory tests * Add .internal to getNodeTreeSummary Change-Id: If20c0bb78fee3efa55f72e51e7fc261283358de7
2012-08-16 17:53:33 +00:00
'internal': { 'whitespace': [ undefined, undefined, ' ' ] }
Strip and preserve inner leading&trailing whitespace in the linear model This makes things like == Foo == * Bar render without the leading and trailing spaces, while still round-tripping those spaces. * Added a .fringeWhitespace property to the linear model and ve.dm.Node ** Object containing innerPre, innerPost, outerPre, outerPost ** Only inner* are used right now, outer* are planned for future use ** Like .attributes , it's suppressed if it's an empty object * In getDataFromDom(): ** Store the stripped whitespace in .fringeWhitespace ** Move emptiness check up: empty elements with .fringeWhitespace have to be preserved ** Move paragraph wrapping up: .fringeWhitespace has to be applied to the generated paragraph, not its parent ** Add wrapperElement to keep track of the element .fringeWhitespace has to be added to; this is either dataElement or the generated paragraph or nothing, but we can't modify dataElement because it's used later * In getDomFromData(): ** When processing an opening, store the fringeWhitespace data in the generated DOM node ** When processing a closing, add the stored whitespace back in * In the ve.dm.Document constructor, pass through .fringeWhitespace from the linear model data to the generated nodes Tests: * Change one existing test case to account for this change * Add three new test cases for this behavior * Add normalizedHtml field so I can test behavior with bare content Change-Id: I0411544652dd72b923c831c495d69ee4322a2c14
2012-08-10 21:09:04 +00:00
},
'B',
'a',
'z',
{ 'type': '/heading' },
{
'type': 'heading',
'attributes': { 'level': 2 },
Rename fringeWhitespace to internal This allows us to put other internal data in there in the future. Also passing it through the Node constructor properly now. * ve.dm.Node ** Rename fringeWhitespace property to internal ** Add internal parameter to constructor ** Remove setFringeWhitespace() * Increase the number of parameters passed through by ve.Factory to 3 * Pass through .internal from linmod to nodeFactory in ve.dm.Document * ve.dm.Converter ** Rename .fringeWhitespace to .internal.whitespace and make it an array ** Store a temporary reference to .internal in domElement.veInternal * Add internal to all node constructors except TextNode Tests: * Update for fringeWhitespace->internal rename * Add third parameter to ve.Factory tests * Add .internal to getNodeTreeSummary Change-Id: If20c0bb78fee3efa55f72e51e7fc261283358de7
2012-08-16 17:53:33 +00:00
'internal': { 'whitespace': [ undefined, ' ', ' ' ] }
Strip and preserve inner leading&trailing whitespace in the linear model This makes things like == Foo == * Bar render without the leading and trailing spaces, while still round-tripping those spaces. * Added a .fringeWhitespace property to the linear model and ve.dm.Node ** Object containing innerPre, innerPost, outerPre, outerPost ** Only inner* are used right now, outer* are planned for future use ** Like .attributes , it's suppressed if it's an empty object * In getDataFromDom(): ** Store the stripped whitespace in .fringeWhitespace ** Move emptiness check up: empty elements with .fringeWhitespace have to be preserved ** Move paragraph wrapping up: .fringeWhitespace has to be applied to the generated paragraph, not its parent ** Add wrapperElement to keep track of the element .fringeWhitespace has to be added to; this is either dataElement or the generated paragraph or nothing, but we can't modify dataElement because it's used later * In getDomFromData(): ** When processing an opening, store the fringeWhitespace data in the generated DOM node ** When processing a closing, add the stored whitespace back in * In the ve.dm.Document constructor, pass through .fringeWhitespace from the linear model data to the generated nodes Tests: * Change one existing test case to account for this change * Add three new test cases for this behavior * Add normalizedHtml field so I can test behavior with bare content Change-Id: I0411544652dd72b923c831c495d69ee4322a2c14
2012-08-10 21:09:04 +00:00
},
'Q',
'u',
'u',
'x',
{ 'type': '/heading' }
]
},
'whitespace preservation in list items': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><ul><li>Foo</li><li> Bar</li><li>Baz </li><li> Quux </li></ul></body>',
Strip and preserve inner leading&trailing whitespace in the linear model This makes things like == Foo == * Bar render without the leading and trailing spaces, while still round-tripping those spaces. * Added a .fringeWhitespace property to the linear model and ve.dm.Node ** Object containing innerPre, innerPost, outerPre, outerPost ** Only inner* are used right now, outer* are planned for future use ** Like .attributes , it's suppressed if it's an empty object * In getDataFromDom(): ** Store the stripped whitespace in .fringeWhitespace ** Move emptiness check up: empty elements with .fringeWhitespace have to be preserved ** Move paragraph wrapping up: .fringeWhitespace has to be applied to the generated paragraph, not its parent ** Add wrapperElement to keep track of the element .fringeWhitespace has to be added to; this is either dataElement or the generated paragraph or nothing, but we can't modify dataElement because it's used later * In getDomFromData(): ** When processing an opening, store the fringeWhitespace data in the generated DOM node ** When processing a closing, add the stored whitespace back in * In the ve.dm.Document constructor, pass through .fringeWhitespace from the linear model data to the generated nodes Tests: * Change one existing test case to account for this change * Add three new test cases for this behavior * Add normalizedHtml field so I can test behavior with bare content Change-Id: I0411544652dd72b923c831c495d69ee4322a2c14
2012-08-10 21:09:04 +00:00
'data': [
{ 'type': 'list', 'attributes': { 'style': 'bullet' } },
{ 'type': 'listItem' },
Strip generated <p> tags in dataToDom domToData wraps bare content in paragraph elements, which were then converted to <p> tags by domToData. With this fix, HTML with "missing" <p> tags actually round-trips through the editor correctly now, rather than having <p> tags added wherever VE believes they should exist. * Mark generated paragraph elements with .internal.generated = 'wrapper' ** This signifies the wrapper was generated but its contents were not, so the right thing to do when converting back to HTML is to remove the wrapper and keep the contents. We might want to use other values of generated in the future. * Unwrap nodes with generated=wrapper when converting to HTML Tests: * Add 'generated': 'wrapper' as appropriate. Only affects 1 test * Remove 'normalizedHtml' for this test because it is no longer needed ** Need to keep 'normalizedHtml' for now because we normalize hrefs * Eventually the main example should test bare content, but that requires touching a lot of stuff. The main example could use some beefing up anyway. Change-Id: I277ad5fe3f64e07c1bbf49007d6bbaecc90b7466
2012-08-16 20:06:18 +00:00
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
Strip and preserve inner leading&trailing whitespace in the linear model This makes things like == Foo == * Bar render without the leading and trailing spaces, while still round-tripping those spaces. * Added a .fringeWhitespace property to the linear model and ve.dm.Node ** Object containing innerPre, innerPost, outerPre, outerPost ** Only inner* are used right now, outer* are planned for future use ** Like .attributes , it's suppressed if it's an empty object * In getDataFromDom(): ** Store the stripped whitespace in .fringeWhitespace ** Move emptiness check up: empty elements with .fringeWhitespace have to be preserved ** Move paragraph wrapping up: .fringeWhitespace has to be applied to the generated paragraph, not its parent ** Add wrapperElement to keep track of the element .fringeWhitespace has to be added to; this is either dataElement or the generated paragraph or nothing, but we can't modify dataElement because it's used later * In getDomFromData(): ** When processing an opening, store the fringeWhitespace data in the generated DOM node ** When processing a closing, add the stored whitespace back in * In the ve.dm.Document constructor, pass through .fringeWhitespace from the linear model data to the generated nodes Tests: * Change one existing test case to account for this change * Add three new test cases for this behavior * Add normalizedHtml field so I can test behavior with bare content Change-Id: I0411544652dd72b923c831c495d69ee4322a2c14
2012-08-10 21:09:04 +00:00
'F',
'o',
'o',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
Preserve whitespace between elements This commit fully utilizes all four positions in the internal.whitespace array. Outer whitespace is now preserved as well, and is duplicated either in the adjacent sibling (one node's outerPost is the next sibling's outerPre) or in the parent (a branch node's innerPre is its first child's outerPre, and its innerPost is its last child's outerPost). Before restoring saved whitespace, we check that these two agree with each other, and if they disagree we assume the user has been moving stuff around and don't restore any whitespace in that spot. The whitespace at the very beginning and the very end of the document (i.e. the first node's outerPre and the last node's outerPost) isn't duplicated anywhere, nor is inner whitespace in content nodes. The basic outline of the implementation is: * When we encounter whitespace, strip it and store it in the previous node's outerPost. Also store it in nextWhitespace so we can put it in the next node's outerPre once we encounter that node. * When we encounter whitespace in wrapped bare text, we don't know in advance if it's gonna be succeeded by more non-whitespace (in which case it needs to be output verbatim), or not (in which case it's leading whitespace and needs to be stripped and stored). The fact that annotations are nodes in HTML makes this trickier. So we write the whitespace to the temporary linmod and store it in wrappedWhitespace, then if it turns out to be trailing whitespace we take it back out of the data array and record it the usual way. * Because text nodes can contain any combination of leading whitespace actual text and trailing whitespace, and because we may or may not already have opened a wrapping paragraph, there are a lot of different combinations to handle. We handle all of them but the resulting code is pretty dense and verbose. More low-level list of changes: In getDataFromDom(): * Added helper function addWhitespace() for storing whitespace for an element * Added helper function processNextWhitespace() for processing any whitespace passed on from the previous node via the nextWhitespace var * Rename paragraph to wrappingParagraph. Make wrapping default to alreadyWrapped so we can simplify wrapping||alreadyWrapped and !wrapping&&!alreadyWrapped. Add wrappingIsOurs to track whether the wrapping originated in this recursion level (needed for deciding when to close the wrapper). * Add prevElement to track the previous element so we can propagate whitespace to it, and nextWhitespace so we can propagate whitespace to the next element. * Remove previous newline stripping hacks * Integrate the logic for wrapping bare content with the outer whitespace preservation code * Remove wrapperElement, no longer needed because we have a dedicated variable for the wrapping paragraph now and what was previously inner whitespace preservation for wrapper paragraphs is now covered by the outer whitespace preservation code. In getDomFromData(): * Reinsert whitespace where appropriate ** outerPre is inserted when opening the element ** This covers outerPost as well except for the last child's outerPost, which is handled as the parent's innerPost when closing the parent. ** innerPre and innerPost are inserted when closing the element. Care is taken not to insert these if they're duplicates of something else. * Propagate each node's outerPost to the next node (either the next sibling or the parent) using parentDomElement.lastOuterPost. We can't get this using .lastChild because we will have destroyed that child's .veInternal by then, and we can't tell whether a node will be its parent's last child when we process it (all other processing, including first child handling is done when processing the node itself, but this cannot be). * Special handling is needed for the last node's outerPost, which ends up in the container's .lastOuterPost property. Tests: * Allow .html to be null in data<->DOM converter tests. This indicates that the test is a one-way data->DOM test, not a DOM->data->DOM round-trip test. The data will be converted to HTML and checked against .normalizedHtml * Update existing tests as needed * Add tests for outer whitespace preservation and storage * Add test for squashing of whitespace in case of disagreement (this requires .html=null) Change-Id: I4db4fe372a421182e80a2535657af7784ff15f95
2012-08-21 00:37:42 +00:00
{ 'type': 'listItem', 'internal': { 'whitespace': [ undefined, ' ' ]} },
{ 'type': 'paragraph', 'internal': { 'whitespace': [ ' ' ], 'generated': 'wrapper' } },
Strip and preserve inner leading&trailing whitespace in the linear model This makes things like == Foo == * Bar render without the leading and trailing spaces, while still round-tripping those spaces. * Added a .fringeWhitespace property to the linear model and ve.dm.Node ** Object containing innerPre, innerPost, outerPre, outerPost ** Only inner* are used right now, outer* are planned for future use ** Like .attributes , it's suppressed if it's an empty object * In getDataFromDom(): ** Store the stripped whitespace in .fringeWhitespace ** Move emptiness check up: empty elements with .fringeWhitespace have to be preserved ** Move paragraph wrapping up: .fringeWhitespace has to be applied to the generated paragraph, not its parent ** Add wrapperElement to keep track of the element .fringeWhitespace has to be added to; this is either dataElement or the generated paragraph or nothing, but we can't modify dataElement because it's used later * In getDomFromData(): ** When processing an opening, store the fringeWhitespace data in the generated DOM node ** When processing a closing, add the stored whitespace back in * In the ve.dm.Document constructor, pass through .fringeWhitespace from the linear model data to the generated nodes Tests: * Change one existing test case to account for this change * Add three new test cases for this behavior * Add normalizedHtml field so I can test behavior with bare content Change-Id: I0411544652dd72b923c831c495d69ee4322a2c14
2012-08-10 21:09:04 +00:00
'B',
'a',
'r',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
Preserve whitespace between elements This commit fully utilizes all four positions in the internal.whitespace array. Outer whitespace is now preserved as well, and is duplicated either in the adjacent sibling (one node's outerPost is the next sibling's outerPre) or in the parent (a branch node's innerPre is its first child's outerPre, and its innerPost is its last child's outerPost). Before restoring saved whitespace, we check that these two agree with each other, and if they disagree we assume the user has been moving stuff around and don't restore any whitespace in that spot. The whitespace at the very beginning and the very end of the document (i.e. the first node's outerPre and the last node's outerPost) isn't duplicated anywhere, nor is inner whitespace in content nodes. The basic outline of the implementation is: * When we encounter whitespace, strip it and store it in the previous node's outerPost. Also store it in nextWhitespace so we can put it in the next node's outerPre once we encounter that node. * When we encounter whitespace in wrapped bare text, we don't know in advance if it's gonna be succeeded by more non-whitespace (in which case it needs to be output verbatim), or not (in which case it's leading whitespace and needs to be stripped and stored). The fact that annotations are nodes in HTML makes this trickier. So we write the whitespace to the temporary linmod and store it in wrappedWhitespace, then if it turns out to be trailing whitespace we take it back out of the data array and record it the usual way. * Because text nodes can contain any combination of leading whitespace actual text and trailing whitespace, and because we may or may not already have opened a wrapping paragraph, there are a lot of different combinations to handle. We handle all of them but the resulting code is pretty dense and verbose. More low-level list of changes: In getDataFromDom(): * Added helper function addWhitespace() for storing whitespace for an element * Added helper function processNextWhitespace() for processing any whitespace passed on from the previous node via the nextWhitespace var * Rename paragraph to wrappingParagraph. Make wrapping default to alreadyWrapped so we can simplify wrapping||alreadyWrapped and !wrapping&&!alreadyWrapped. Add wrappingIsOurs to track whether the wrapping originated in this recursion level (needed for deciding when to close the wrapper). * Add prevElement to track the previous element so we can propagate whitespace to it, and nextWhitespace so we can propagate whitespace to the next element. * Remove previous newline stripping hacks * Integrate the logic for wrapping bare content with the outer whitespace preservation code * Remove wrapperElement, no longer needed because we have a dedicated variable for the wrapping paragraph now and what was previously inner whitespace preservation for wrapper paragraphs is now covered by the outer whitespace preservation code. In getDomFromData(): * Reinsert whitespace where appropriate ** outerPre is inserted when opening the element ** This covers outerPost as well except for the last child's outerPost, which is handled as the parent's innerPost when closing the parent. ** innerPre and innerPost are inserted when closing the element. Care is taken not to insert these if they're duplicates of something else. * Propagate each node's outerPost to the next node (either the next sibling or the parent) using parentDomElement.lastOuterPost. We can't get this using .lastChild because we will have destroyed that child's .veInternal by then, and we can't tell whether a node will be its parent's last child when we process it (all other processing, including first child handling is done when processing the node itself, but this cannot be). * Special handling is needed for the last node's outerPost, which ends up in the container's .lastOuterPost property. Tests: * Allow .html to be null in data<->DOM converter tests. This indicates that the test is a one-way data->DOM test, not a DOM->data->DOM round-trip test. The data will be converted to HTML and checked against .normalizedHtml * Update existing tests as needed * Add tests for outer whitespace preservation and storage * Add test for squashing of whitespace in case of disagreement (this requires .html=null) Change-Id: I4db4fe372a421182e80a2535657af7784ff15f95
2012-08-21 00:37:42 +00:00
{ 'type': 'listItem', 'internal': { 'whitespace': [ undefined, undefined, ' ' ] } },
{ 'type': 'paragraph', 'internal': { 'whitespace': [ undefined, undefined, undefined, ' ' ], 'generated': 'wrapper' } },
Strip and preserve inner leading&trailing whitespace in the linear model This makes things like == Foo == * Bar render without the leading and trailing spaces, while still round-tripping those spaces. * Added a .fringeWhitespace property to the linear model and ve.dm.Node ** Object containing innerPre, innerPost, outerPre, outerPost ** Only inner* are used right now, outer* are planned for future use ** Like .attributes , it's suppressed if it's an empty object * In getDataFromDom(): ** Store the stripped whitespace in .fringeWhitespace ** Move emptiness check up: empty elements with .fringeWhitespace have to be preserved ** Move paragraph wrapping up: .fringeWhitespace has to be applied to the generated paragraph, not its parent ** Add wrapperElement to keep track of the element .fringeWhitespace has to be added to; this is either dataElement or the generated paragraph or nothing, but we can't modify dataElement because it's used later * In getDomFromData(): ** When processing an opening, store the fringeWhitespace data in the generated DOM node ** When processing a closing, add the stored whitespace back in * In the ve.dm.Document constructor, pass through .fringeWhitespace from the linear model data to the generated nodes Tests: * Change one existing test case to account for this change * Add three new test cases for this behavior * Add normalizedHtml field so I can test behavior with bare content Change-Id: I0411544652dd72b923c831c495d69ee4322a2c14
2012-08-10 21:09:04 +00:00
'B',
'a',
'z',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
Preserve whitespace between elements This commit fully utilizes all four positions in the internal.whitespace array. Outer whitespace is now preserved as well, and is duplicated either in the adjacent sibling (one node's outerPost is the next sibling's outerPre) or in the parent (a branch node's innerPre is its first child's outerPre, and its innerPost is its last child's outerPost). Before restoring saved whitespace, we check that these two agree with each other, and if they disagree we assume the user has been moving stuff around and don't restore any whitespace in that spot. The whitespace at the very beginning and the very end of the document (i.e. the first node's outerPre and the last node's outerPost) isn't duplicated anywhere, nor is inner whitespace in content nodes. The basic outline of the implementation is: * When we encounter whitespace, strip it and store it in the previous node's outerPost. Also store it in nextWhitespace so we can put it in the next node's outerPre once we encounter that node. * When we encounter whitespace in wrapped bare text, we don't know in advance if it's gonna be succeeded by more non-whitespace (in which case it needs to be output verbatim), or not (in which case it's leading whitespace and needs to be stripped and stored). The fact that annotations are nodes in HTML makes this trickier. So we write the whitespace to the temporary linmod and store it in wrappedWhitespace, then if it turns out to be trailing whitespace we take it back out of the data array and record it the usual way. * Because text nodes can contain any combination of leading whitespace actual text and trailing whitespace, and because we may or may not already have opened a wrapping paragraph, there are a lot of different combinations to handle. We handle all of them but the resulting code is pretty dense and verbose. More low-level list of changes: In getDataFromDom(): * Added helper function addWhitespace() for storing whitespace for an element * Added helper function processNextWhitespace() for processing any whitespace passed on from the previous node via the nextWhitespace var * Rename paragraph to wrappingParagraph. Make wrapping default to alreadyWrapped so we can simplify wrapping||alreadyWrapped and !wrapping&&!alreadyWrapped. Add wrappingIsOurs to track whether the wrapping originated in this recursion level (needed for deciding when to close the wrapper). * Add prevElement to track the previous element so we can propagate whitespace to it, and nextWhitespace so we can propagate whitespace to the next element. * Remove previous newline stripping hacks * Integrate the logic for wrapping bare content with the outer whitespace preservation code * Remove wrapperElement, no longer needed because we have a dedicated variable for the wrapping paragraph now and what was previously inner whitespace preservation for wrapper paragraphs is now covered by the outer whitespace preservation code. In getDomFromData(): * Reinsert whitespace where appropriate ** outerPre is inserted when opening the element ** This covers outerPost as well except for the last child's outerPost, which is handled as the parent's innerPost when closing the parent. ** innerPre and innerPost are inserted when closing the element. Care is taken not to insert these if they're duplicates of something else. * Propagate each node's outerPost to the next node (either the next sibling or the parent) using parentDomElement.lastOuterPost. We can't get this using .lastChild because we will have destroyed that child's .veInternal by then, and we can't tell whether a node will be its parent's last child when we process it (all other processing, including first child handling is done when processing the node itself, but this cannot be). * Special handling is needed for the last node's outerPost, which ends up in the container's .lastOuterPost property. Tests: * Allow .html to be null in data<->DOM converter tests. This indicates that the test is a one-way data->DOM test, not a DOM->data->DOM round-trip test. The data will be converted to HTML and checked against .normalizedHtml * Update existing tests as needed * Add tests for outer whitespace preservation and storage * Add test for squashing of whitespace in case of disagreement (this requires .html=null) Change-Id: I4db4fe372a421182e80a2535657af7784ff15f95
2012-08-21 00:37:42 +00:00
{ 'type': 'listItem', 'internal': { 'whitespace': [ undefined, ' ', ' '] } },
Strip and preserve inner leading&trailing whitespace in the linear model This makes things like == Foo == * Bar render without the leading and trailing spaces, while still round-tripping those spaces. * Added a .fringeWhitespace property to the linear model and ve.dm.Node ** Object containing innerPre, innerPost, outerPre, outerPost ** Only inner* are used right now, outer* are planned for future use ** Like .attributes , it's suppressed if it's an empty object * In getDataFromDom(): ** Store the stripped whitespace in .fringeWhitespace ** Move emptiness check up: empty elements with .fringeWhitespace have to be preserved ** Move paragraph wrapping up: .fringeWhitespace has to be applied to the generated paragraph, not its parent ** Add wrapperElement to keep track of the element .fringeWhitespace has to be added to; this is either dataElement or the generated paragraph or nothing, but we can't modify dataElement because it's used later * In getDomFromData(): ** When processing an opening, store the fringeWhitespace data in the generated DOM node ** When processing a closing, add the stored whitespace back in * In the ve.dm.Document constructor, pass through .fringeWhitespace from the linear model data to the generated nodes Tests: * Change one existing test case to account for this change * Add three new test cases for this behavior * Add normalizedHtml field so I can test behavior with bare content Change-Id: I0411544652dd72b923c831c495d69ee4322a2c14
2012-08-10 21:09:04 +00:00
{
'type': 'paragraph',
Preserve whitespace between elements This commit fully utilizes all four positions in the internal.whitespace array. Outer whitespace is now preserved as well, and is duplicated either in the adjacent sibling (one node's outerPost is the next sibling's outerPre) or in the parent (a branch node's innerPre is its first child's outerPre, and its innerPost is its last child's outerPost). Before restoring saved whitespace, we check that these two agree with each other, and if they disagree we assume the user has been moving stuff around and don't restore any whitespace in that spot. The whitespace at the very beginning and the very end of the document (i.e. the first node's outerPre and the last node's outerPost) isn't duplicated anywhere, nor is inner whitespace in content nodes. The basic outline of the implementation is: * When we encounter whitespace, strip it and store it in the previous node's outerPost. Also store it in nextWhitespace so we can put it in the next node's outerPre once we encounter that node. * When we encounter whitespace in wrapped bare text, we don't know in advance if it's gonna be succeeded by more non-whitespace (in which case it needs to be output verbatim), or not (in which case it's leading whitespace and needs to be stripped and stored). The fact that annotations are nodes in HTML makes this trickier. So we write the whitespace to the temporary linmod and store it in wrappedWhitespace, then if it turns out to be trailing whitespace we take it back out of the data array and record it the usual way. * Because text nodes can contain any combination of leading whitespace actual text and trailing whitespace, and because we may or may not already have opened a wrapping paragraph, there are a lot of different combinations to handle. We handle all of them but the resulting code is pretty dense and verbose. More low-level list of changes: In getDataFromDom(): * Added helper function addWhitespace() for storing whitespace for an element * Added helper function processNextWhitespace() for processing any whitespace passed on from the previous node via the nextWhitespace var * Rename paragraph to wrappingParagraph. Make wrapping default to alreadyWrapped so we can simplify wrapping||alreadyWrapped and !wrapping&&!alreadyWrapped. Add wrappingIsOurs to track whether the wrapping originated in this recursion level (needed for deciding when to close the wrapper). * Add prevElement to track the previous element so we can propagate whitespace to it, and nextWhitespace so we can propagate whitespace to the next element. * Remove previous newline stripping hacks * Integrate the logic for wrapping bare content with the outer whitespace preservation code * Remove wrapperElement, no longer needed because we have a dedicated variable for the wrapping paragraph now and what was previously inner whitespace preservation for wrapper paragraphs is now covered by the outer whitespace preservation code. In getDomFromData(): * Reinsert whitespace where appropriate ** outerPre is inserted when opening the element ** This covers outerPost as well except for the last child's outerPost, which is handled as the parent's innerPost when closing the parent. ** innerPre and innerPost are inserted when closing the element. Care is taken not to insert these if they're duplicates of something else. * Propagate each node's outerPost to the next node (either the next sibling or the parent) using parentDomElement.lastOuterPost. We can't get this using .lastChild because we will have destroyed that child's .veInternal by then, and we can't tell whether a node will be its parent's last child when we process it (all other processing, including first child handling is done when processing the node itself, but this cannot be). * Special handling is needed for the last node's outerPost, which ends up in the container's .lastOuterPost property. Tests: * Allow .html to be null in data<->DOM converter tests. This indicates that the test is a one-way data->DOM test, not a DOM->data->DOM round-trip test. The data will be converted to HTML and checked against .normalizedHtml * Update existing tests as needed * Add tests for outer whitespace preservation and storage * Add test for squashing of whitespace in case of disagreement (this requires .html=null) Change-Id: I4db4fe372a421182e80a2535657af7784ff15f95
2012-08-21 00:37:42 +00:00
'internal': { 'whitespace': [ ' ', undefined, undefined, ' ' ], 'generated': 'wrapper' }
Strip and preserve inner leading&trailing whitespace in the linear model This makes things like == Foo == * Bar render without the leading and trailing spaces, while still round-tripping those spaces. * Added a .fringeWhitespace property to the linear model and ve.dm.Node ** Object containing innerPre, innerPost, outerPre, outerPost ** Only inner* are used right now, outer* are planned for future use ** Like .attributes , it's suppressed if it's an empty object * In getDataFromDom(): ** Store the stripped whitespace in .fringeWhitespace ** Move emptiness check up: empty elements with .fringeWhitespace have to be preserved ** Move paragraph wrapping up: .fringeWhitespace has to be applied to the generated paragraph, not its parent ** Add wrapperElement to keep track of the element .fringeWhitespace has to be added to; this is either dataElement or the generated paragraph or nothing, but we can't modify dataElement because it's used later * In getDomFromData(): ** When processing an opening, store the fringeWhitespace data in the generated DOM node ** When processing a closing, add the stored whitespace back in * In the ve.dm.Document constructor, pass through .fringeWhitespace from the linear model data to the generated nodes Tests: * Change one existing test case to account for this change * Add three new test cases for this behavior * Add normalizedHtml field so I can test behavior with bare content Change-Id: I0411544652dd72b923c831c495d69ee4322a2c14
2012-08-10 21:09:04 +00:00
},
'Q',
'u',
'u',
'x',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': '/list' }
]
},
'whitespace preservation with annotations': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><p> <i> Foo </i> </p></body>',
Strip and preserve inner leading&trailing whitespace in the linear model This makes things like == Foo == * Bar render without the leading and trailing spaces, while still round-tripping those spaces. * Added a .fringeWhitespace property to the linear model and ve.dm.Node ** Object containing innerPre, innerPost, outerPre, outerPost ** Only inner* are used right now, outer* are planned for future use ** Like .attributes , it's suppressed if it's an empty object * In getDataFromDom(): ** Store the stripped whitespace in .fringeWhitespace ** Move emptiness check up: empty elements with .fringeWhitespace have to be preserved ** Move paragraph wrapping up: .fringeWhitespace has to be applied to the generated paragraph, not its parent ** Add wrapperElement to keep track of the element .fringeWhitespace has to be added to; this is either dataElement or the generated paragraph or nothing, but we can't modify dataElement because it's used later * In getDomFromData(): ** When processing an opening, store the fringeWhitespace data in the generated DOM node ** When processing a closing, add the stored whitespace back in * In the ve.dm.Document constructor, pass through .fringeWhitespace from the linear model data to the generated nodes Tests: * Change one existing test case to account for this change * Add three new test cases for this behavior * Add normalizedHtml field so I can test behavior with bare content Change-Id: I0411544652dd72b923c831c495d69ee4322a2c14
2012-08-10 21:09:04 +00:00
'data': [
{
'type': 'paragraph',
Rename fringeWhitespace to internal This allows us to put other internal data in there in the future. Also passing it through the Node constructor properly now. * ve.dm.Node ** Rename fringeWhitespace property to internal ** Add internal parameter to constructor ** Remove setFringeWhitespace() * Increase the number of parameters passed through by ve.Factory to 3 * Pass through .internal from linmod to nodeFactory in ve.dm.Document * ve.dm.Converter ** Rename .fringeWhitespace to .internal.whitespace and make it an array ** Store a temporary reference to .internal in domElement.veInternal * Add internal to all node constructors except TextNode Tests: * Update for fringeWhitespace->internal rename * Add third parameter to ve.Factory tests * Add .internal to getNodeTreeSummary Change-Id: If20c0bb78fee3efa55f72e51e7fc261283358de7
2012-08-16 17:53:33 +00:00
'internal': { 'whitespace': [ undefined, ' ', ' ' ] }
Strip and preserve inner leading&trailing whitespace in the linear model This makes things like == Foo == * Bar render without the leading and trailing spaces, while still round-tripping those spaces. * Added a .fringeWhitespace property to the linear model and ve.dm.Node ** Object containing innerPre, innerPost, outerPre, outerPost ** Only inner* are used right now, outer* are planned for future use ** Like .attributes , it's suppressed if it's an empty object * In getDataFromDom(): ** Store the stripped whitespace in .fringeWhitespace ** Move emptiness check up: empty elements with .fringeWhitespace have to be preserved ** Move paragraph wrapping up: .fringeWhitespace has to be applied to the generated paragraph, not its parent ** Add wrapperElement to keep track of the element .fringeWhitespace has to be added to; this is either dataElement or the generated paragraph or nothing, but we can't modify dataElement because it's used later * In getDomFromData(): ** When processing an opening, store the fringeWhitespace data in the generated DOM node ** When processing a closing, add the stored whitespace back in * In the ve.dm.Document constructor, pass through .fringeWhitespace from the linear model data to the generated nodes Tests: * Change one existing test case to account for this change * Add three new test cases for this behavior * Add normalizedHtml field so I can test behavior with bare content Change-Id: I0411544652dd72b923c831c495d69ee4322a2c14
2012-08-10 21:09:04 +00:00
},
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
[ ' ', [ ve.dm.example.italic ] ],
[ ' ', [ ve.dm.example.italic ] ],
[ 'F', [ ve.dm.example.italic ] ],
[ 'o', [ ve.dm.example.italic ] ],
[ 'o', [ ve.dm.example.italic ] ],
[ ' ', [ ve.dm.example.italic ] ],
[ ' ', [ ve.dm.example.italic ] ],
[ ' ', [ ve.dm.example.italic ] ],
Strip and preserve inner leading&trailing whitespace in the linear model This makes things like == Foo == * Bar render without the leading and trailing spaces, while still round-tripping those spaces. * Added a .fringeWhitespace property to the linear model and ve.dm.Node ** Object containing innerPre, innerPost, outerPre, outerPost ** Only inner* are used right now, outer* are planned for future use ** Like .attributes , it's suppressed if it's an empty object * In getDataFromDom(): ** Store the stripped whitespace in .fringeWhitespace ** Move emptiness check up: empty elements with .fringeWhitespace have to be preserved ** Move paragraph wrapping up: .fringeWhitespace has to be applied to the generated paragraph, not its parent ** Add wrapperElement to keep track of the element .fringeWhitespace has to be added to; this is either dataElement or the generated paragraph or nothing, but we can't modify dataElement because it's used later * In getDomFromData(): ** When processing an opening, store the fringeWhitespace data in the generated DOM node ** When processing a closing, add the stored whitespace back in * In the ve.dm.Document constructor, pass through .fringeWhitespace from the linear model data to the generated nodes Tests: * Change one existing test case to account for this change * Add three new test cases for this behavior * Add normalizedHtml field so I can test behavior with bare content Change-Id: I0411544652dd72b923c831c495d69ee4322a2c14
2012-08-10 21:09:04 +00:00
{ 'type': '/paragraph' }
]
Preserve whitespace between elements This commit fully utilizes all four positions in the internal.whitespace array. Outer whitespace is now preserved as well, and is duplicated either in the adjacent sibling (one node's outerPost is the next sibling's outerPre) or in the parent (a branch node's innerPre is its first child's outerPre, and its innerPost is its last child's outerPost). Before restoring saved whitespace, we check that these two agree with each other, and if they disagree we assume the user has been moving stuff around and don't restore any whitespace in that spot. The whitespace at the very beginning and the very end of the document (i.e. the first node's outerPre and the last node's outerPost) isn't duplicated anywhere, nor is inner whitespace in content nodes. The basic outline of the implementation is: * When we encounter whitespace, strip it and store it in the previous node's outerPost. Also store it in nextWhitespace so we can put it in the next node's outerPre once we encounter that node. * When we encounter whitespace in wrapped bare text, we don't know in advance if it's gonna be succeeded by more non-whitespace (in which case it needs to be output verbatim), or not (in which case it's leading whitespace and needs to be stripped and stored). The fact that annotations are nodes in HTML makes this trickier. So we write the whitespace to the temporary linmod and store it in wrappedWhitespace, then if it turns out to be trailing whitespace we take it back out of the data array and record it the usual way. * Because text nodes can contain any combination of leading whitespace actual text and trailing whitespace, and because we may or may not already have opened a wrapping paragraph, there are a lot of different combinations to handle. We handle all of them but the resulting code is pretty dense and verbose. More low-level list of changes: In getDataFromDom(): * Added helper function addWhitespace() for storing whitespace for an element * Added helper function processNextWhitespace() for processing any whitespace passed on from the previous node via the nextWhitespace var * Rename paragraph to wrappingParagraph. Make wrapping default to alreadyWrapped so we can simplify wrapping||alreadyWrapped and !wrapping&&!alreadyWrapped. Add wrappingIsOurs to track whether the wrapping originated in this recursion level (needed for deciding when to close the wrapper). * Add prevElement to track the previous element so we can propagate whitespace to it, and nextWhitespace so we can propagate whitespace to the next element. * Remove previous newline stripping hacks * Integrate the logic for wrapping bare content with the outer whitespace preservation code * Remove wrapperElement, no longer needed because we have a dedicated variable for the wrapping paragraph now and what was previously inner whitespace preservation for wrapper paragraphs is now covered by the outer whitespace preservation code. In getDomFromData(): * Reinsert whitespace where appropriate ** outerPre is inserted when opening the element ** This covers outerPost as well except for the last child's outerPost, which is handled as the parent's innerPost when closing the parent. ** innerPre and innerPost are inserted when closing the element. Care is taken not to insert these if they're duplicates of something else. * Propagate each node's outerPost to the next node (either the next sibling or the parent) using parentDomElement.lastOuterPost. We can't get this using .lastChild because we will have destroyed that child's .veInternal by then, and we can't tell whether a node will be its parent's last child when we process it (all other processing, including first child handling is done when processing the node itself, but this cannot be). * Special handling is needed for the last node's outerPost, which ends up in the container's .lastOuterPost property. Tests: * Allow .html to be null in data<->DOM converter tests. This indicates that the test is a one-way data->DOM test, not a DOM->data->DOM round-trip test. The data will be converted to HTML and checked against .normalizedHtml * Update existing tests as needed * Add tests for outer whitespace preservation and storage * Add test for squashing of whitespace in case of disagreement (this requires .html=null) Change-Id: I4db4fe372a421182e80a2535657af7784ff15f95
2012-08-21 00:37:42 +00:00
},
'outer whitespace preservation in a list with bare text and a wrapper paragraph': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body>\n<ul>\n\n<li>\n\n\nBa re\n\n\n\n</li>\n\n\n\n\n<li>\t<p>\t\tP\t\t\t</p>\t\t\t\t</li>\t\n</ul>\t\n\t\n</body>',
Preserve whitespace between elements This commit fully utilizes all four positions in the internal.whitespace array. Outer whitespace is now preserved as well, and is duplicated either in the adjacent sibling (one node's outerPost is the next sibling's outerPre) or in the parent (a branch node's innerPre is its first child's outerPre, and its innerPost is its last child's outerPost). Before restoring saved whitespace, we check that these two agree with each other, and if they disagree we assume the user has been moving stuff around and don't restore any whitespace in that spot. The whitespace at the very beginning and the very end of the document (i.e. the first node's outerPre and the last node's outerPost) isn't duplicated anywhere, nor is inner whitespace in content nodes. The basic outline of the implementation is: * When we encounter whitespace, strip it and store it in the previous node's outerPost. Also store it in nextWhitespace so we can put it in the next node's outerPre once we encounter that node. * When we encounter whitespace in wrapped bare text, we don't know in advance if it's gonna be succeeded by more non-whitespace (in which case it needs to be output verbatim), or not (in which case it's leading whitespace and needs to be stripped and stored). The fact that annotations are nodes in HTML makes this trickier. So we write the whitespace to the temporary linmod and store it in wrappedWhitespace, then if it turns out to be trailing whitespace we take it back out of the data array and record it the usual way. * Because text nodes can contain any combination of leading whitespace actual text and trailing whitespace, and because we may or may not already have opened a wrapping paragraph, there are a lot of different combinations to handle. We handle all of them but the resulting code is pretty dense and verbose. More low-level list of changes: In getDataFromDom(): * Added helper function addWhitespace() for storing whitespace for an element * Added helper function processNextWhitespace() for processing any whitespace passed on from the previous node via the nextWhitespace var * Rename paragraph to wrappingParagraph. Make wrapping default to alreadyWrapped so we can simplify wrapping||alreadyWrapped and !wrapping&&!alreadyWrapped. Add wrappingIsOurs to track whether the wrapping originated in this recursion level (needed for deciding when to close the wrapper). * Add prevElement to track the previous element so we can propagate whitespace to it, and nextWhitespace so we can propagate whitespace to the next element. * Remove previous newline stripping hacks * Integrate the logic for wrapping bare content with the outer whitespace preservation code * Remove wrapperElement, no longer needed because we have a dedicated variable for the wrapping paragraph now and what was previously inner whitespace preservation for wrapper paragraphs is now covered by the outer whitespace preservation code. In getDomFromData(): * Reinsert whitespace where appropriate ** outerPre is inserted when opening the element ** This covers outerPost as well except for the last child's outerPost, which is handled as the parent's innerPost when closing the parent. ** innerPre and innerPost are inserted when closing the element. Care is taken not to insert these if they're duplicates of something else. * Propagate each node's outerPost to the next node (either the next sibling or the parent) using parentDomElement.lastOuterPost. We can't get this using .lastChild because we will have destroyed that child's .veInternal by then, and we can't tell whether a node will be its parent's last child when we process it (all other processing, including first child handling is done when processing the node itself, but this cannot be). * Special handling is needed for the last node's outerPost, which ends up in the container's .lastOuterPost property. Tests: * Allow .html to be null in data<->DOM converter tests. This indicates that the test is a one-way data->DOM test, not a DOM->data->DOM round-trip test. The data will be converted to HTML and checked against .normalizedHtml * Update existing tests as needed * Add tests for outer whitespace preservation and storage * Add test for squashing of whitespace in case of disagreement (this requires .html=null) Change-Id: I4db4fe372a421182e80a2535657af7784ff15f95
2012-08-21 00:37:42 +00:00
'data': [
{ 'type': 'list', 'attributes': { 'style': 'bullet' }, 'internal': { 'whitespace': [ '\n', '\n\n', '\t\n', '\t\n\t\n' ] } },
{ 'type': 'listItem', 'internal': { 'whitespace': [ '\n\n', '\n\n\n', '\n\n\n\n', '\n\n\n\n\n' ] } },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper', 'whitespace': [ '\n\n\n', undefined, undefined, '\n\n\n\n' ] } },
'B',
'a',
' ',
'r',
'e',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': 'listItem', 'internal': { 'whitespace': [ '\n\n\n\n\n', '\t', '\t\t\t\t', '\t\n' ] } },
{ 'type': 'paragraph', 'internal': { 'whitespace': [ '\t', '\t\t', '\t\t\t', '\t\t\t\t' ] } },
'P',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': '/list' }
]
},
'outer whitespace preservation in a list with bare text and a sublist': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><ul>\n<li>\n\nBa re\n\n\n<ul>\n\n\n\n<li> <p> P </p> </li>\t</ul>\t\t</li>\t\t\t</ul></body>',
Preserve whitespace between elements This commit fully utilizes all four positions in the internal.whitespace array. Outer whitespace is now preserved as well, and is duplicated either in the adjacent sibling (one node's outerPost is the next sibling's outerPre) or in the parent (a branch node's innerPre is its first child's outerPre, and its innerPost is its last child's outerPost). Before restoring saved whitespace, we check that these two agree with each other, and if they disagree we assume the user has been moving stuff around and don't restore any whitespace in that spot. The whitespace at the very beginning and the very end of the document (i.e. the first node's outerPre and the last node's outerPost) isn't duplicated anywhere, nor is inner whitespace in content nodes. The basic outline of the implementation is: * When we encounter whitespace, strip it and store it in the previous node's outerPost. Also store it in nextWhitespace so we can put it in the next node's outerPre once we encounter that node. * When we encounter whitespace in wrapped bare text, we don't know in advance if it's gonna be succeeded by more non-whitespace (in which case it needs to be output verbatim), or not (in which case it's leading whitespace and needs to be stripped and stored). The fact that annotations are nodes in HTML makes this trickier. So we write the whitespace to the temporary linmod and store it in wrappedWhitespace, then if it turns out to be trailing whitespace we take it back out of the data array and record it the usual way. * Because text nodes can contain any combination of leading whitespace actual text and trailing whitespace, and because we may or may not already have opened a wrapping paragraph, there are a lot of different combinations to handle. We handle all of them but the resulting code is pretty dense and verbose. More low-level list of changes: In getDataFromDom(): * Added helper function addWhitespace() for storing whitespace for an element * Added helper function processNextWhitespace() for processing any whitespace passed on from the previous node via the nextWhitespace var * Rename paragraph to wrappingParagraph. Make wrapping default to alreadyWrapped so we can simplify wrapping||alreadyWrapped and !wrapping&&!alreadyWrapped. Add wrappingIsOurs to track whether the wrapping originated in this recursion level (needed for deciding when to close the wrapper). * Add prevElement to track the previous element so we can propagate whitespace to it, and nextWhitespace so we can propagate whitespace to the next element. * Remove previous newline stripping hacks * Integrate the logic for wrapping bare content with the outer whitespace preservation code * Remove wrapperElement, no longer needed because we have a dedicated variable for the wrapping paragraph now and what was previously inner whitespace preservation for wrapper paragraphs is now covered by the outer whitespace preservation code. In getDomFromData(): * Reinsert whitespace where appropriate ** outerPre is inserted when opening the element ** This covers outerPost as well except for the last child's outerPost, which is handled as the parent's innerPost when closing the parent. ** innerPre and innerPost are inserted when closing the element. Care is taken not to insert these if they're duplicates of something else. * Propagate each node's outerPost to the next node (either the next sibling or the parent) using parentDomElement.lastOuterPost. We can't get this using .lastChild because we will have destroyed that child's .veInternal by then, and we can't tell whether a node will be its parent's last child when we process it (all other processing, including first child handling is done when processing the node itself, but this cannot be). * Special handling is needed for the last node's outerPost, which ends up in the container's .lastOuterPost property. Tests: * Allow .html to be null in data<->DOM converter tests. This indicates that the test is a one-way data->DOM test, not a DOM->data->DOM round-trip test. The data will be converted to HTML and checked against .normalizedHtml * Update existing tests as needed * Add tests for outer whitespace preservation and storage * Add test for squashing of whitespace in case of disagreement (this requires .html=null) Change-Id: I4db4fe372a421182e80a2535657af7784ff15f95
2012-08-21 00:37:42 +00:00
'data': [
{ 'type': 'list', 'attributes': { 'style': 'bullet' }, 'internal': { 'whitespace': [ undefined, '\n', '\t\t\t' ] } },
{ 'type': 'listItem', 'internal': { 'whitespace': [ '\n', '\n\n', '\t\t', '\t\t\t' ] } },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper', 'whitespace': [ '\n\n', undefined, undefined, '\n\n\n' ] } },
'B',
'a',
' ',
'r',
'e',
{ 'type': '/paragraph' },
{ 'type': 'list', 'attributes': { 'style': 'bullet' }, 'internal': { 'whitespace': [ '\n\n\n', '\n\n\n\n', '\t', '\t\t' ] } },
{ 'type': 'listItem', 'internal': { 'whitespace': [ '\n\n\n\n', ' ', ' ', '\t' ] } },
{ 'type': 'paragraph', 'internal': { 'whitespace': [ ' ', ' ', ' ', ' '] } },
'P',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': '/list' },
{ 'type': '/listItem' },
{ 'type': '/list' }
]
},
'whitespace preservation leaves non-edge content whitespace alone': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><p> A B <b> C\t</b>\t\tD\t\t\t</p>\nE\n\nF\n\n\n<b>\n\n\n\nG </b> H </body>',
Preserve whitespace between elements This commit fully utilizes all four positions in the internal.whitespace array. Outer whitespace is now preserved as well, and is duplicated either in the adjacent sibling (one node's outerPost is the next sibling's outerPre) or in the parent (a branch node's innerPre is its first child's outerPre, and its innerPost is its last child's outerPost). Before restoring saved whitespace, we check that these two agree with each other, and if they disagree we assume the user has been moving stuff around and don't restore any whitespace in that spot. The whitespace at the very beginning and the very end of the document (i.e. the first node's outerPre and the last node's outerPost) isn't duplicated anywhere, nor is inner whitespace in content nodes. The basic outline of the implementation is: * When we encounter whitespace, strip it and store it in the previous node's outerPost. Also store it in nextWhitespace so we can put it in the next node's outerPre once we encounter that node. * When we encounter whitespace in wrapped bare text, we don't know in advance if it's gonna be succeeded by more non-whitespace (in which case it needs to be output verbatim), or not (in which case it's leading whitespace and needs to be stripped and stored). The fact that annotations are nodes in HTML makes this trickier. So we write the whitespace to the temporary linmod and store it in wrappedWhitespace, then if it turns out to be trailing whitespace we take it back out of the data array and record it the usual way. * Because text nodes can contain any combination of leading whitespace actual text and trailing whitespace, and because we may or may not already have opened a wrapping paragraph, there are a lot of different combinations to handle. We handle all of them but the resulting code is pretty dense and verbose. More low-level list of changes: In getDataFromDom(): * Added helper function addWhitespace() for storing whitespace for an element * Added helper function processNextWhitespace() for processing any whitespace passed on from the previous node via the nextWhitespace var * Rename paragraph to wrappingParagraph. Make wrapping default to alreadyWrapped so we can simplify wrapping||alreadyWrapped and !wrapping&&!alreadyWrapped. Add wrappingIsOurs to track whether the wrapping originated in this recursion level (needed for deciding when to close the wrapper). * Add prevElement to track the previous element so we can propagate whitespace to it, and nextWhitespace so we can propagate whitespace to the next element. * Remove previous newline stripping hacks * Integrate the logic for wrapping bare content with the outer whitespace preservation code * Remove wrapperElement, no longer needed because we have a dedicated variable for the wrapping paragraph now and what was previously inner whitespace preservation for wrapper paragraphs is now covered by the outer whitespace preservation code. In getDomFromData(): * Reinsert whitespace where appropriate ** outerPre is inserted when opening the element ** This covers outerPost as well except for the last child's outerPost, which is handled as the parent's innerPost when closing the parent. ** innerPre and innerPost are inserted when closing the element. Care is taken not to insert these if they're duplicates of something else. * Propagate each node's outerPost to the next node (either the next sibling or the parent) using parentDomElement.lastOuterPost. We can't get this using .lastChild because we will have destroyed that child's .veInternal by then, and we can't tell whether a node will be its parent's last child when we process it (all other processing, including first child handling is done when processing the node itself, but this cannot be). * Special handling is needed for the last node's outerPost, which ends up in the container's .lastOuterPost property. Tests: * Allow .html to be null in data<->DOM converter tests. This indicates that the test is a one-way data->DOM test, not a DOM->data->DOM round-trip test. The data will be converted to HTML and checked against .normalizedHtml * Update existing tests as needed * Add tests for outer whitespace preservation and storage * Add test for squashing of whitespace in case of disagreement (this requires .html=null) Change-Id: I4db4fe372a421182e80a2535657af7784ff15f95
2012-08-21 00:37:42 +00:00
'data': [
{ 'type': 'paragraph', 'internal': { 'whitespace': [ undefined, ' ', '\t\t\t', '\n' ] } },
'A',
' ',
' ',
'B',
' ',
' ',
' ',
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
[ ' ', [ ve.dm.example.bold ] ],
[ ' ', [ ve.dm.example.bold ] ],
[ ' ', [ ve.dm.example.bold ] ],
[ ' ', [ ve.dm.example.bold ] ],
[ 'C', [ ve.dm.example.bold ] ],
[ '\t', [ ve.dm.example.bold ] ],
Preserve whitespace between elements This commit fully utilizes all four positions in the internal.whitespace array. Outer whitespace is now preserved as well, and is duplicated either in the adjacent sibling (one node's outerPost is the next sibling's outerPre) or in the parent (a branch node's innerPre is its first child's outerPre, and its innerPost is its last child's outerPost). Before restoring saved whitespace, we check that these two agree with each other, and if they disagree we assume the user has been moving stuff around and don't restore any whitespace in that spot. The whitespace at the very beginning and the very end of the document (i.e. the first node's outerPre and the last node's outerPost) isn't duplicated anywhere, nor is inner whitespace in content nodes. The basic outline of the implementation is: * When we encounter whitespace, strip it and store it in the previous node's outerPost. Also store it in nextWhitespace so we can put it in the next node's outerPre once we encounter that node. * When we encounter whitespace in wrapped bare text, we don't know in advance if it's gonna be succeeded by more non-whitespace (in which case it needs to be output verbatim), or not (in which case it's leading whitespace and needs to be stripped and stored). The fact that annotations are nodes in HTML makes this trickier. So we write the whitespace to the temporary linmod and store it in wrappedWhitespace, then if it turns out to be trailing whitespace we take it back out of the data array and record it the usual way. * Because text nodes can contain any combination of leading whitespace actual text and trailing whitespace, and because we may or may not already have opened a wrapping paragraph, there are a lot of different combinations to handle. We handle all of them but the resulting code is pretty dense and verbose. More low-level list of changes: In getDataFromDom(): * Added helper function addWhitespace() for storing whitespace for an element * Added helper function processNextWhitespace() for processing any whitespace passed on from the previous node via the nextWhitespace var * Rename paragraph to wrappingParagraph. Make wrapping default to alreadyWrapped so we can simplify wrapping||alreadyWrapped and !wrapping&&!alreadyWrapped. Add wrappingIsOurs to track whether the wrapping originated in this recursion level (needed for deciding when to close the wrapper). * Add prevElement to track the previous element so we can propagate whitespace to it, and nextWhitespace so we can propagate whitespace to the next element. * Remove previous newline stripping hacks * Integrate the logic for wrapping bare content with the outer whitespace preservation code * Remove wrapperElement, no longer needed because we have a dedicated variable for the wrapping paragraph now and what was previously inner whitespace preservation for wrapper paragraphs is now covered by the outer whitespace preservation code. In getDomFromData(): * Reinsert whitespace where appropriate ** outerPre is inserted when opening the element ** This covers outerPost as well except for the last child's outerPost, which is handled as the parent's innerPost when closing the parent. ** innerPre and innerPost are inserted when closing the element. Care is taken not to insert these if they're duplicates of something else. * Propagate each node's outerPost to the next node (either the next sibling or the parent) using parentDomElement.lastOuterPost. We can't get this using .lastChild because we will have destroyed that child's .veInternal by then, and we can't tell whether a node will be its parent's last child when we process it (all other processing, including first child handling is done when processing the node itself, but this cannot be). * Special handling is needed for the last node's outerPost, which ends up in the container's .lastOuterPost property. Tests: * Allow .html to be null in data<->DOM converter tests. This indicates that the test is a one-way data->DOM test, not a DOM->data->DOM round-trip test. The data will be converted to HTML and checked against .normalizedHtml * Update existing tests as needed * Add tests for outer whitespace preservation and storage * Add test for squashing of whitespace in case of disagreement (this requires .html=null) Change-Id: I4db4fe372a421182e80a2535657af7784ff15f95
2012-08-21 00:37:42 +00:00
'\t',
'\t',
'D',
{ 'type': '/paragraph' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper', 'whitespace': [ '\n', undefined, undefined, ' ' ] } },
'E',
'\n',
'\n',
'F',
'\n',
'\n',
'\n',
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
[ '\n', [ ve.dm.example.bold ] ],
[ '\n', [ ve.dm.example.bold ] ],
[ '\n', [ ve.dm.example.bold ] ],
[ '\n', [ ve.dm.example.bold ] ],
[ 'G', [ ve.dm.example.bold ] ],
[ ' ', [ ve.dm.example.bold ] ],
Preserve whitespace between elements This commit fully utilizes all four positions in the internal.whitespace array. Outer whitespace is now preserved as well, and is duplicated either in the adjacent sibling (one node's outerPost is the next sibling's outerPre) or in the parent (a branch node's innerPre is its first child's outerPre, and its innerPost is its last child's outerPost). Before restoring saved whitespace, we check that these two agree with each other, and if they disagree we assume the user has been moving stuff around and don't restore any whitespace in that spot. The whitespace at the very beginning and the very end of the document (i.e. the first node's outerPre and the last node's outerPost) isn't duplicated anywhere, nor is inner whitespace in content nodes. The basic outline of the implementation is: * When we encounter whitespace, strip it and store it in the previous node's outerPost. Also store it in nextWhitespace so we can put it in the next node's outerPre once we encounter that node. * When we encounter whitespace in wrapped bare text, we don't know in advance if it's gonna be succeeded by more non-whitespace (in which case it needs to be output verbatim), or not (in which case it's leading whitespace and needs to be stripped and stored). The fact that annotations are nodes in HTML makes this trickier. So we write the whitespace to the temporary linmod and store it in wrappedWhitespace, then if it turns out to be trailing whitespace we take it back out of the data array and record it the usual way. * Because text nodes can contain any combination of leading whitespace actual text and trailing whitespace, and because we may or may not already have opened a wrapping paragraph, there are a lot of different combinations to handle. We handle all of them but the resulting code is pretty dense and verbose. More low-level list of changes: In getDataFromDom(): * Added helper function addWhitespace() for storing whitespace for an element * Added helper function processNextWhitespace() for processing any whitespace passed on from the previous node via the nextWhitespace var * Rename paragraph to wrappingParagraph. Make wrapping default to alreadyWrapped so we can simplify wrapping||alreadyWrapped and !wrapping&&!alreadyWrapped. Add wrappingIsOurs to track whether the wrapping originated in this recursion level (needed for deciding when to close the wrapper). * Add prevElement to track the previous element so we can propagate whitespace to it, and nextWhitespace so we can propagate whitespace to the next element. * Remove previous newline stripping hacks * Integrate the logic for wrapping bare content with the outer whitespace preservation code * Remove wrapperElement, no longer needed because we have a dedicated variable for the wrapping paragraph now and what was previously inner whitespace preservation for wrapper paragraphs is now covered by the outer whitespace preservation code. In getDomFromData(): * Reinsert whitespace where appropriate ** outerPre is inserted when opening the element ** This covers outerPost as well except for the last child's outerPost, which is handled as the parent's innerPost when closing the parent. ** innerPre and innerPost are inserted when closing the element. Care is taken not to insert these if they're duplicates of something else. * Propagate each node's outerPost to the next node (either the next sibling or the parent) using parentDomElement.lastOuterPost. We can't get this using .lastChild because we will have destroyed that child's .veInternal by then, and we can't tell whether a node will be its parent's last child when we process it (all other processing, including first child handling is done when processing the node itself, but this cannot be). * Special handling is needed for the last node's outerPost, which ends up in the container's .lastOuterPost property. Tests: * Allow .html to be null in data<->DOM converter tests. This indicates that the test is a one-way data->DOM test, not a DOM->data->DOM round-trip test. The data will be converted to HTML and checked against .normalizedHtml * Update existing tests as needed * Add tests for outer whitespace preservation and storage * Add test for squashing of whitespace in case of disagreement (this requires .html=null) Change-Id: I4db4fe372a421182e80a2535657af7784ff15f95
2012-08-21 00:37:42 +00:00
' ',
' ',
'H',
{ 'type': '/paragraph' }
]
},
'whitespace preservation with non-edge content whitespace with nested annotations': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><p> A B <b> C\t<i>\t\tD\t\t\t</i>\t\t\t\tE\n</b>\n\nF\n\n\n</p></body>',
Preserve whitespace between elements This commit fully utilizes all four positions in the internal.whitespace array. Outer whitespace is now preserved as well, and is duplicated either in the adjacent sibling (one node's outerPost is the next sibling's outerPre) or in the parent (a branch node's innerPre is its first child's outerPre, and its innerPost is its last child's outerPost). Before restoring saved whitespace, we check that these two agree with each other, and if they disagree we assume the user has been moving stuff around and don't restore any whitespace in that spot. The whitespace at the very beginning and the very end of the document (i.e. the first node's outerPre and the last node's outerPost) isn't duplicated anywhere, nor is inner whitespace in content nodes. The basic outline of the implementation is: * When we encounter whitespace, strip it and store it in the previous node's outerPost. Also store it in nextWhitespace so we can put it in the next node's outerPre once we encounter that node. * When we encounter whitespace in wrapped bare text, we don't know in advance if it's gonna be succeeded by more non-whitespace (in which case it needs to be output verbatim), or not (in which case it's leading whitespace and needs to be stripped and stored). The fact that annotations are nodes in HTML makes this trickier. So we write the whitespace to the temporary linmod and store it in wrappedWhitespace, then if it turns out to be trailing whitespace we take it back out of the data array and record it the usual way. * Because text nodes can contain any combination of leading whitespace actual text and trailing whitespace, and because we may or may not already have opened a wrapping paragraph, there are a lot of different combinations to handle. We handle all of them but the resulting code is pretty dense and verbose. More low-level list of changes: In getDataFromDom(): * Added helper function addWhitespace() for storing whitespace for an element * Added helper function processNextWhitespace() for processing any whitespace passed on from the previous node via the nextWhitespace var * Rename paragraph to wrappingParagraph. Make wrapping default to alreadyWrapped so we can simplify wrapping||alreadyWrapped and !wrapping&&!alreadyWrapped. Add wrappingIsOurs to track whether the wrapping originated in this recursion level (needed for deciding when to close the wrapper). * Add prevElement to track the previous element so we can propagate whitespace to it, and nextWhitespace so we can propagate whitespace to the next element. * Remove previous newline stripping hacks * Integrate the logic for wrapping bare content with the outer whitespace preservation code * Remove wrapperElement, no longer needed because we have a dedicated variable for the wrapping paragraph now and what was previously inner whitespace preservation for wrapper paragraphs is now covered by the outer whitespace preservation code. In getDomFromData(): * Reinsert whitespace where appropriate ** outerPre is inserted when opening the element ** This covers outerPost as well except for the last child's outerPost, which is handled as the parent's innerPost when closing the parent. ** innerPre and innerPost are inserted when closing the element. Care is taken not to insert these if they're duplicates of something else. * Propagate each node's outerPost to the next node (either the next sibling or the parent) using parentDomElement.lastOuterPost. We can't get this using .lastChild because we will have destroyed that child's .veInternal by then, and we can't tell whether a node will be its parent's last child when we process it (all other processing, including first child handling is done when processing the node itself, but this cannot be). * Special handling is needed for the last node's outerPost, which ends up in the container's .lastOuterPost property. Tests: * Allow .html to be null in data<->DOM converter tests. This indicates that the test is a one-way data->DOM test, not a DOM->data->DOM round-trip test. The data will be converted to HTML and checked against .normalizedHtml * Update existing tests as needed * Add tests for outer whitespace preservation and storage * Add test for squashing of whitespace in case of disagreement (this requires .html=null) Change-Id: I4db4fe372a421182e80a2535657af7784ff15f95
2012-08-21 00:37:42 +00:00
'data': [
{ 'type': 'paragraph', 'internal': { 'whitespace': [ undefined, ' ', '\n\n\n' ] } },
'A',
' ',
' ',
'B',
' ',
' ',
' ',
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
[ ' ', [ ve.dm.example.bold ] ],
[ ' ', [ ve.dm.example.bold ] ],
[ ' ', [ ve.dm.example.bold ] ],
[ ' ', [ ve.dm.example.bold ] ],
[ 'C', [ ve.dm.example.bold ] ],
[ '\t', [ ve.dm.example.bold ] ],
[ '\t', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ '\t', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ 'D', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ '\t', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ '\t', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ '\t', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ '\t', [ ve.dm.example.bold ] ],
[ '\t', [ ve.dm.example.bold ] ],
[ '\t', [ ve.dm.example.bold ] ],
[ '\t', [ ve.dm.example.bold ] ],
[ 'E', [ ve.dm.example.bold ] ],
[ '\n', [ ve.dm.example.bold ] ],
Preserve whitespace between elements This commit fully utilizes all four positions in the internal.whitespace array. Outer whitespace is now preserved as well, and is duplicated either in the adjacent sibling (one node's outerPost is the next sibling's outerPre) or in the parent (a branch node's innerPre is its first child's outerPre, and its innerPost is its last child's outerPost). Before restoring saved whitespace, we check that these two agree with each other, and if they disagree we assume the user has been moving stuff around and don't restore any whitespace in that spot. The whitespace at the very beginning and the very end of the document (i.e. the first node's outerPre and the last node's outerPost) isn't duplicated anywhere, nor is inner whitespace in content nodes. The basic outline of the implementation is: * When we encounter whitespace, strip it and store it in the previous node's outerPost. Also store it in nextWhitespace so we can put it in the next node's outerPre once we encounter that node. * When we encounter whitespace in wrapped bare text, we don't know in advance if it's gonna be succeeded by more non-whitespace (in which case it needs to be output verbatim), or not (in which case it's leading whitespace and needs to be stripped and stored). The fact that annotations are nodes in HTML makes this trickier. So we write the whitespace to the temporary linmod and store it in wrappedWhitespace, then if it turns out to be trailing whitespace we take it back out of the data array and record it the usual way. * Because text nodes can contain any combination of leading whitespace actual text and trailing whitespace, and because we may or may not already have opened a wrapping paragraph, there are a lot of different combinations to handle. We handle all of them but the resulting code is pretty dense and verbose. More low-level list of changes: In getDataFromDom(): * Added helper function addWhitespace() for storing whitespace for an element * Added helper function processNextWhitespace() for processing any whitespace passed on from the previous node via the nextWhitespace var * Rename paragraph to wrappingParagraph. Make wrapping default to alreadyWrapped so we can simplify wrapping||alreadyWrapped and !wrapping&&!alreadyWrapped. Add wrappingIsOurs to track whether the wrapping originated in this recursion level (needed for deciding when to close the wrapper). * Add prevElement to track the previous element so we can propagate whitespace to it, and nextWhitespace so we can propagate whitespace to the next element. * Remove previous newline stripping hacks * Integrate the logic for wrapping bare content with the outer whitespace preservation code * Remove wrapperElement, no longer needed because we have a dedicated variable for the wrapping paragraph now and what was previously inner whitespace preservation for wrapper paragraphs is now covered by the outer whitespace preservation code. In getDomFromData(): * Reinsert whitespace where appropriate ** outerPre is inserted when opening the element ** This covers outerPost as well except for the last child's outerPost, which is handled as the parent's innerPost when closing the parent. ** innerPre and innerPost are inserted when closing the element. Care is taken not to insert these if they're duplicates of something else. * Propagate each node's outerPost to the next node (either the next sibling or the parent) using parentDomElement.lastOuterPost. We can't get this using .lastChild because we will have destroyed that child's .veInternal by then, and we can't tell whether a node will be its parent's last child when we process it (all other processing, including first child handling is done when processing the node itself, but this cannot be). * Special handling is needed for the last node's outerPost, which ends up in the container's .lastOuterPost property. Tests: * Allow .html to be null in data<->DOM converter tests. This indicates that the test is a one-way data->DOM test, not a DOM->data->DOM round-trip test. The data will be converted to HTML and checked against .normalizedHtml * Update existing tests as needed * Add tests for outer whitespace preservation and storage * Add test for squashing of whitespace in case of disagreement (this requires .html=null) Change-Id: I4db4fe372a421182e80a2535657af7784ff15f95
2012-08-21 00:37:42 +00:00
'\n',
'\n',
'F',
{ 'type': '/paragraph' }
]
},
'whitespace preservation with tightly nested annotations': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><p> A B <b><i>\t\tC\t\t\t</i></b>\n\nD\n\n\n</p></body>',
Preserve whitespace between elements This commit fully utilizes all four positions in the internal.whitespace array. Outer whitespace is now preserved as well, and is duplicated either in the adjacent sibling (one node's outerPost is the next sibling's outerPre) or in the parent (a branch node's innerPre is its first child's outerPre, and its innerPost is its last child's outerPost). Before restoring saved whitespace, we check that these two agree with each other, and if they disagree we assume the user has been moving stuff around and don't restore any whitespace in that spot. The whitespace at the very beginning and the very end of the document (i.e. the first node's outerPre and the last node's outerPost) isn't duplicated anywhere, nor is inner whitespace in content nodes. The basic outline of the implementation is: * When we encounter whitespace, strip it and store it in the previous node's outerPost. Also store it in nextWhitespace so we can put it in the next node's outerPre once we encounter that node. * When we encounter whitespace in wrapped bare text, we don't know in advance if it's gonna be succeeded by more non-whitespace (in which case it needs to be output verbatim), or not (in which case it's leading whitespace and needs to be stripped and stored). The fact that annotations are nodes in HTML makes this trickier. So we write the whitespace to the temporary linmod and store it in wrappedWhitespace, then if it turns out to be trailing whitespace we take it back out of the data array and record it the usual way. * Because text nodes can contain any combination of leading whitespace actual text and trailing whitespace, and because we may or may not already have opened a wrapping paragraph, there are a lot of different combinations to handle. We handle all of them but the resulting code is pretty dense and verbose. More low-level list of changes: In getDataFromDom(): * Added helper function addWhitespace() for storing whitespace for an element * Added helper function processNextWhitespace() for processing any whitespace passed on from the previous node via the nextWhitespace var * Rename paragraph to wrappingParagraph. Make wrapping default to alreadyWrapped so we can simplify wrapping||alreadyWrapped and !wrapping&&!alreadyWrapped. Add wrappingIsOurs to track whether the wrapping originated in this recursion level (needed for deciding when to close the wrapper). * Add prevElement to track the previous element so we can propagate whitespace to it, and nextWhitespace so we can propagate whitespace to the next element. * Remove previous newline stripping hacks * Integrate the logic for wrapping bare content with the outer whitespace preservation code * Remove wrapperElement, no longer needed because we have a dedicated variable for the wrapping paragraph now and what was previously inner whitespace preservation for wrapper paragraphs is now covered by the outer whitespace preservation code. In getDomFromData(): * Reinsert whitespace where appropriate ** outerPre is inserted when opening the element ** This covers outerPost as well except for the last child's outerPost, which is handled as the parent's innerPost when closing the parent. ** innerPre and innerPost are inserted when closing the element. Care is taken not to insert these if they're duplicates of something else. * Propagate each node's outerPost to the next node (either the next sibling or the parent) using parentDomElement.lastOuterPost. We can't get this using .lastChild because we will have destroyed that child's .veInternal by then, and we can't tell whether a node will be its parent's last child when we process it (all other processing, including first child handling is done when processing the node itself, but this cannot be). * Special handling is needed for the last node's outerPost, which ends up in the container's .lastOuterPost property. Tests: * Allow .html to be null in data<->DOM converter tests. This indicates that the test is a one-way data->DOM test, not a DOM->data->DOM round-trip test. The data will be converted to HTML and checked against .normalizedHtml * Update existing tests as needed * Add tests for outer whitespace preservation and storage * Add test for squashing of whitespace in case of disagreement (this requires .html=null) Change-Id: I4db4fe372a421182e80a2535657af7784ff15f95
2012-08-21 00:37:42 +00:00
'data': [
{ 'type': 'paragraph', 'internal': { 'whitespace': [ undefined, ' ', '\n\n\n' ] } },
'A',
' ',
' ',
'B',
' ',
' ',
' ',
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
[ '\t', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ '\t', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ 'C', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ '\t', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ '\t', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ '\t', [ ve.dm.example.bold, ve.dm.example.italic ] ],
Preserve whitespace between elements This commit fully utilizes all four positions in the internal.whitespace array. Outer whitespace is now preserved as well, and is duplicated either in the adjacent sibling (one node's outerPost is the next sibling's outerPre) or in the parent (a branch node's innerPre is its first child's outerPre, and its innerPost is its last child's outerPost). Before restoring saved whitespace, we check that these two agree with each other, and if they disagree we assume the user has been moving stuff around and don't restore any whitespace in that spot. The whitespace at the very beginning and the very end of the document (i.e. the first node's outerPre and the last node's outerPost) isn't duplicated anywhere, nor is inner whitespace in content nodes. The basic outline of the implementation is: * When we encounter whitespace, strip it and store it in the previous node's outerPost. Also store it in nextWhitespace so we can put it in the next node's outerPre once we encounter that node. * When we encounter whitespace in wrapped bare text, we don't know in advance if it's gonna be succeeded by more non-whitespace (in which case it needs to be output verbatim), or not (in which case it's leading whitespace and needs to be stripped and stored). The fact that annotations are nodes in HTML makes this trickier. So we write the whitespace to the temporary linmod and store it in wrappedWhitespace, then if it turns out to be trailing whitespace we take it back out of the data array and record it the usual way. * Because text nodes can contain any combination of leading whitespace actual text and trailing whitespace, and because we may or may not already have opened a wrapping paragraph, there are a lot of different combinations to handle. We handle all of them but the resulting code is pretty dense and verbose. More low-level list of changes: In getDataFromDom(): * Added helper function addWhitespace() for storing whitespace for an element * Added helper function processNextWhitespace() for processing any whitespace passed on from the previous node via the nextWhitespace var * Rename paragraph to wrappingParagraph. Make wrapping default to alreadyWrapped so we can simplify wrapping||alreadyWrapped and !wrapping&&!alreadyWrapped. Add wrappingIsOurs to track whether the wrapping originated in this recursion level (needed for deciding when to close the wrapper). * Add prevElement to track the previous element so we can propagate whitespace to it, and nextWhitespace so we can propagate whitespace to the next element. * Remove previous newline stripping hacks * Integrate the logic for wrapping bare content with the outer whitespace preservation code * Remove wrapperElement, no longer needed because we have a dedicated variable for the wrapping paragraph now and what was previously inner whitespace preservation for wrapper paragraphs is now covered by the outer whitespace preservation code. In getDomFromData(): * Reinsert whitespace where appropriate ** outerPre is inserted when opening the element ** This covers outerPost as well except for the last child's outerPost, which is handled as the parent's innerPost when closing the parent. ** innerPre and innerPost are inserted when closing the element. Care is taken not to insert these if they're duplicates of something else. * Propagate each node's outerPost to the next node (either the next sibling or the parent) using parentDomElement.lastOuterPost. We can't get this using .lastChild because we will have destroyed that child's .veInternal by then, and we can't tell whether a node will be its parent's last child when we process it (all other processing, including first child handling is done when processing the node itself, but this cannot be). * Special handling is needed for the last node's outerPost, which ends up in the container's .lastOuterPost property. Tests: * Allow .html to be null in data<->DOM converter tests. This indicates that the test is a one-way data->DOM test, not a DOM->data->DOM round-trip test. The data will be converted to HTML and checked against .normalizedHtml * Update existing tests as needed * Add tests for outer whitespace preservation and storage * Add test for squashing of whitespace in case of disagreement (this requires .html=null) Change-Id: I4db4fe372a421182e80a2535657af7784ff15f95
2012-08-21 00:37:42 +00:00
'\n',
'\n',
'D',
{ 'type': '/paragraph' }
]
},
'whitespace preservation with nested annotations with whitespace on the left side': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><p> A B <b>\n\t<i>\t\tC\t\t\t</i></b>\n\nD\n\n\n</p></body>',
Preserve whitespace between elements This commit fully utilizes all four positions in the internal.whitespace array. Outer whitespace is now preserved as well, and is duplicated either in the adjacent sibling (one node's outerPost is the next sibling's outerPre) or in the parent (a branch node's innerPre is its first child's outerPre, and its innerPost is its last child's outerPost). Before restoring saved whitespace, we check that these two agree with each other, and if they disagree we assume the user has been moving stuff around and don't restore any whitespace in that spot. The whitespace at the very beginning and the very end of the document (i.e. the first node's outerPre and the last node's outerPost) isn't duplicated anywhere, nor is inner whitespace in content nodes. The basic outline of the implementation is: * When we encounter whitespace, strip it and store it in the previous node's outerPost. Also store it in nextWhitespace so we can put it in the next node's outerPre once we encounter that node. * When we encounter whitespace in wrapped bare text, we don't know in advance if it's gonna be succeeded by more non-whitespace (in which case it needs to be output verbatim), or not (in which case it's leading whitespace and needs to be stripped and stored). The fact that annotations are nodes in HTML makes this trickier. So we write the whitespace to the temporary linmod and store it in wrappedWhitespace, then if it turns out to be trailing whitespace we take it back out of the data array and record it the usual way. * Because text nodes can contain any combination of leading whitespace actual text and trailing whitespace, and because we may or may not already have opened a wrapping paragraph, there are a lot of different combinations to handle. We handle all of them but the resulting code is pretty dense and verbose. More low-level list of changes: In getDataFromDom(): * Added helper function addWhitespace() for storing whitespace for an element * Added helper function processNextWhitespace() for processing any whitespace passed on from the previous node via the nextWhitespace var * Rename paragraph to wrappingParagraph. Make wrapping default to alreadyWrapped so we can simplify wrapping||alreadyWrapped and !wrapping&&!alreadyWrapped. Add wrappingIsOurs to track whether the wrapping originated in this recursion level (needed for deciding when to close the wrapper). * Add prevElement to track the previous element so we can propagate whitespace to it, and nextWhitespace so we can propagate whitespace to the next element. * Remove previous newline stripping hacks * Integrate the logic for wrapping bare content with the outer whitespace preservation code * Remove wrapperElement, no longer needed because we have a dedicated variable for the wrapping paragraph now and what was previously inner whitespace preservation for wrapper paragraphs is now covered by the outer whitespace preservation code. In getDomFromData(): * Reinsert whitespace where appropriate ** outerPre is inserted when opening the element ** This covers outerPost as well except for the last child's outerPost, which is handled as the parent's innerPost when closing the parent. ** innerPre and innerPost are inserted when closing the element. Care is taken not to insert these if they're duplicates of something else. * Propagate each node's outerPost to the next node (either the next sibling or the parent) using parentDomElement.lastOuterPost. We can't get this using .lastChild because we will have destroyed that child's .veInternal by then, and we can't tell whether a node will be its parent's last child when we process it (all other processing, including first child handling is done when processing the node itself, but this cannot be). * Special handling is needed for the last node's outerPost, which ends up in the container's .lastOuterPost property. Tests: * Allow .html to be null in data<->DOM converter tests. This indicates that the test is a one-way data->DOM test, not a DOM->data->DOM round-trip test. The data will be converted to HTML and checked against .normalizedHtml * Update existing tests as needed * Add tests for outer whitespace preservation and storage * Add test for squashing of whitespace in case of disagreement (this requires .html=null) Change-Id: I4db4fe372a421182e80a2535657af7784ff15f95
2012-08-21 00:37:42 +00:00
'data': [
{ 'type': 'paragraph', 'internal': { 'whitespace': [ undefined, ' ', '\n\n\n' ] } },
'A',
' ',
' ',
'B',
' ',
' ',
' ',
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
[ '\n', [ ve.dm.example.bold ] ],
[ '\t', [ ve.dm.example.bold ] ],
[ '\t', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ '\t', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ 'C', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ '\t', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ '\t', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ '\t', [ ve.dm.example.bold, ve.dm.example.italic ] ],
Preserve whitespace between elements This commit fully utilizes all four positions in the internal.whitespace array. Outer whitespace is now preserved as well, and is duplicated either in the adjacent sibling (one node's outerPost is the next sibling's outerPre) or in the parent (a branch node's innerPre is its first child's outerPre, and its innerPost is its last child's outerPost). Before restoring saved whitespace, we check that these two agree with each other, and if they disagree we assume the user has been moving stuff around and don't restore any whitespace in that spot. The whitespace at the very beginning and the very end of the document (i.e. the first node's outerPre and the last node's outerPost) isn't duplicated anywhere, nor is inner whitespace in content nodes. The basic outline of the implementation is: * When we encounter whitespace, strip it and store it in the previous node's outerPost. Also store it in nextWhitespace so we can put it in the next node's outerPre once we encounter that node. * When we encounter whitespace in wrapped bare text, we don't know in advance if it's gonna be succeeded by more non-whitespace (in which case it needs to be output verbatim), or not (in which case it's leading whitespace and needs to be stripped and stored). The fact that annotations are nodes in HTML makes this trickier. So we write the whitespace to the temporary linmod and store it in wrappedWhitespace, then if it turns out to be trailing whitespace we take it back out of the data array and record it the usual way. * Because text nodes can contain any combination of leading whitespace actual text and trailing whitespace, and because we may or may not already have opened a wrapping paragraph, there are a lot of different combinations to handle. We handle all of them but the resulting code is pretty dense and verbose. More low-level list of changes: In getDataFromDom(): * Added helper function addWhitespace() for storing whitespace for an element * Added helper function processNextWhitespace() for processing any whitespace passed on from the previous node via the nextWhitespace var * Rename paragraph to wrappingParagraph. Make wrapping default to alreadyWrapped so we can simplify wrapping||alreadyWrapped and !wrapping&&!alreadyWrapped. Add wrappingIsOurs to track whether the wrapping originated in this recursion level (needed for deciding when to close the wrapper). * Add prevElement to track the previous element so we can propagate whitespace to it, and nextWhitespace so we can propagate whitespace to the next element. * Remove previous newline stripping hacks * Integrate the logic for wrapping bare content with the outer whitespace preservation code * Remove wrapperElement, no longer needed because we have a dedicated variable for the wrapping paragraph now and what was previously inner whitespace preservation for wrapper paragraphs is now covered by the outer whitespace preservation code. In getDomFromData(): * Reinsert whitespace where appropriate ** outerPre is inserted when opening the element ** This covers outerPost as well except for the last child's outerPost, which is handled as the parent's innerPost when closing the parent. ** innerPre and innerPost are inserted when closing the element. Care is taken not to insert these if they're duplicates of something else. * Propagate each node's outerPost to the next node (either the next sibling or the parent) using parentDomElement.lastOuterPost. We can't get this using .lastChild because we will have destroyed that child's .veInternal by then, and we can't tell whether a node will be its parent's last child when we process it (all other processing, including first child handling is done when processing the node itself, but this cannot be). * Special handling is needed for the last node's outerPost, which ends up in the container's .lastOuterPost property. Tests: * Allow .html to be null in data<->DOM converter tests. This indicates that the test is a one-way data->DOM test, not a DOM->data->DOM round-trip test. The data will be converted to HTML and checked against .normalizedHtml * Update existing tests as needed * Add tests for outer whitespace preservation and storage * Add test for squashing of whitespace in case of disagreement (this requires .html=null) Change-Id: I4db4fe372a421182e80a2535657af7784ff15f95
2012-08-21 00:37:42 +00:00
'\n',
'\n',
'D',
{ 'type': '/paragraph' }
]
},
'whitespace preservation with nested annotations with whitespace on the right side': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><p> A B <b><i>\t\tC\t\t\t</i>\n\t</b>\n\nD\n\n\n</p></body>',
Preserve whitespace between elements This commit fully utilizes all four positions in the internal.whitespace array. Outer whitespace is now preserved as well, and is duplicated either in the adjacent sibling (one node's outerPost is the next sibling's outerPre) or in the parent (a branch node's innerPre is its first child's outerPre, and its innerPost is its last child's outerPost). Before restoring saved whitespace, we check that these two agree with each other, and if they disagree we assume the user has been moving stuff around and don't restore any whitespace in that spot. The whitespace at the very beginning and the very end of the document (i.e. the first node's outerPre and the last node's outerPost) isn't duplicated anywhere, nor is inner whitespace in content nodes. The basic outline of the implementation is: * When we encounter whitespace, strip it and store it in the previous node's outerPost. Also store it in nextWhitespace so we can put it in the next node's outerPre once we encounter that node. * When we encounter whitespace in wrapped bare text, we don't know in advance if it's gonna be succeeded by more non-whitespace (in which case it needs to be output verbatim), or not (in which case it's leading whitespace and needs to be stripped and stored). The fact that annotations are nodes in HTML makes this trickier. So we write the whitespace to the temporary linmod and store it in wrappedWhitespace, then if it turns out to be trailing whitespace we take it back out of the data array and record it the usual way. * Because text nodes can contain any combination of leading whitespace actual text and trailing whitespace, and because we may or may not already have opened a wrapping paragraph, there are a lot of different combinations to handle. We handle all of them but the resulting code is pretty dense and verbose. More low-level list of changes: In getDataFromDom(): * Added helper function addWhitespace() for storing whitespace for an element * Added helper function processNextWhitespace() for processing any whitespace passed on from the previous node via the nextWhitespace var * Rename paragraph to wrappingParagraph. Make wrapping default to alreadyWrapped so we can simplify wrapping||alreadyWrapped and !wrapping&&!alreadyWrapped. Add wrappingIsOurs to track whether the wrapping originated in this recursion level (needed for deciding when to close the wrapper). * Add prevElement to track the previous element so we can propagate whitespace to it, and nextWhitespace so we can propagate whitespace to the next element. * Remove previous newline stripping hacks * Integrate the logic for wrapping bare content with the outer whitespace preservation code * Remove wrapperElement, no longer needed because we have a dedicated variable for the wrapping paragraph now and what was previously inner whitespace preservation for wrapper paragraphs is now covered by the outer whitespace preservation code. In getDomFromData(): * Reinsert whitespace where appropriate ** outerPre is inserted when opening the element ** This covers outerPost as well except for the last child's outerPost, which is handled as the parent's innerPost when closing the parent. ** innerPre and innerPost are inserted when closing the element. Care is taken not to insert these if they're duplicates of something else. * Propagate each node's outerPost to the next node (either the next sibling or the parent) using parentDomElement.lastOuterPost. We can't get this using .lastChild because we will have destroyed that child's .veInternal by then, and we can't tell whether a node will be its parent's last child when we process it (all other processing, including first child handling is done when processing the node itself, but this cannot be). * Special handling is needed for the last node's outerPost, which ends up in the container's .lastOuterPost property. Tests: * Allow .html to be null in data<->DOM converter tests. This indicates that the test is a one-way data->DOM test, not a DOM->data->DOM round-trip test. The data will be converted to HTML and checked against .normalizedHtml * Update existing tests as needed * Add tests for outer whitespace preservation and storage * Add test for squashing of whitespace in case of disagreement (this requires .html=null) Change-Id: I4db4fe372a421182e80a2535657af7784ff15f95
2012-08-21 00:37:42 +00:00
'data': [
{ 'type': 'paragraph', 'internal': { 'whitespace': [ undefined, ' ', '\n\n\n' ] } },
'A',
' ',
' ',
'B',
' ',
' ',
' ',
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
[ '\t', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ '\t', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ 'C', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ '\t', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ '\t', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ '\t', [ ve.dm.example.bold, ve.dm.example.italic ] ],
[ '\n', [ ve.dm.example.bold ] ],
[ '\t', [ ve.dm.example.bold ] ],
Preserve whitespace between elements This commit fully utilizes all four positions in the internal.whitespace array. Outer whitespace is now preserved as well, and is duplicated either in the adjacent sibling (one node's outerPost is the next sibling's outerPre) or in the parent (a branch node's innerPre is its first child's outerPre, and its innerPost is its last child's outerPost). Before restoring saved whitespace, we check that these two agree with each other, and if they disagree we assume the user has been moving stuff around and don't restore any whitespace in that spot. The whitespace at the very beginning and the very end of the document (i.e. the first node's outerPre and the last node's outerPost) isn't duplicated anywhere, nor is inner whitespace in content nodes. The basic outline of the implementation is: * When we encounter whitespace, strip it and store it in the previous node's outerPost. Also store it in nextWhitespace so we can put it in the next node's outerPre once we encounter that node. * When we encounter whitespace in wrapped bare text, we don't know in advance if it's gonna be succeeded by more non-whitespace (in which case it needs to be output verbatim), or not (in which case it's leading whitespace and needs to be stripped and stored). The fact that annotations are nodes in HTML makes this trickier. So we write the whitespace to the temporary linmod and store it in wrappedWhitespace, then if it turns out to be trailing whitespace we take it back out of the data array and record it the usual way. * Because text nodes can contain any combination of leading whitespace actual text and trailing whitespace, and because we may or may not already have opened a wrapping paragraph, there are a lot of different combinations to handle. We handle all of them but the resulting code is pretty dense and verbose. More low-level list of changes: In getDataFromDom(): * Added helper function addWhitespace() for storing whitespace for an element * Added helper function processNextWhitespace() for processing any whitespace passed on from the previous node via the nextWhitespace var * Rename paragraph to wrappingParagraph. Make wrapping default to alreadyWrapped so we can simplify wrapping||alreadyWrapped and !wrapping&&!alreadyWrapped. Add wrappingIsOurs to track whether the wrapping originated in this recursion level (needed for deciding when to close the wrapper). * Add prevElement to track the previous element so we can propagate whitespace to it, and nextWhitespace so we can propagate whitespace to the next element. * Remove previous newline stripping hacks * Integrate the logic for wrapping bare content with the outer whitespace preservation code * Remove wrapperElement, no longer needed because we have a dedicated variable for the wrapping paragraph now and what was previously inner whitespace preservation for wrapper paragraphs is now covered by the outer whitespace preservation code. In getDomFromData(): * Reinsert whitespace where appropriate ** outerPre is inserted when opening the element ** This covers outerPost as well except for the last child's outerPost, which is handled as the parent's innerPost when closing the parent. ** innerPre and innerPost are inserted when closing the element. Care is taken not to insert these if they're duplicates of something else. * Propagate each node's outerPost to the next node (either the next sibling or the parent) using parentDomElement.lastOuterPost. We can't get this using .lastChild because we will have destroyed that child's .veInternal by then, and we can't tell whether a node will be its parent's last child when we process it (all other processing, including first child handling is done when processing the node itself, but this cannot be). * Special handling is needed for the last node's outerPost, which ends up in the container's .lastOuterPost property. Tests: * Allow .html to be null in data<->DOM converter tests. This indicates that the test is a one-way data->DOM test, not a DOM->data->DOM round-trip test. The data will be converted to HTML and checked against .normalizedHtml * Update existing tests as needed * Add tests for outer whitespace preservation and storage * Add test for squashing of whitespace in case of disagreement (this requires .html=null) Change-Id: I4db4fe372a421182e80a2535657af7784ff15f95
2012-08-21 00:37:42 +00:00
'\n',
'\n',
'D',
{ 'type': '/paragraph' }
]
},
Fix bugs in whitespace preservation for aliens This was broken in three different ways: * On the way in, we were applying whitespace to an array of elements rather than the actual element, so the whitespace wasn't stored. * Whitespace processing on the way out was skipped for aliens because they had their own code path. Refactored this so alien openings and regular openings share much more code, including whitespace output. * Somewhat unrelatedly, innerPost output was broken for paragraphs containing inline elements, because the inline elements' processing polluted lastOuterPost. Discovered this because my test with inline aliens also happened to be the first test of whitespace preservation in paragraphs with inline content elements. Fixed by explicitly skipping content nodes when outputting whitespace. Fixed these issues and added a test case. Change-Id: I8edb61a008e60ace886b1a841b3417682ec39c32
2012-09-07 21:58:27 +00:00
'whitespace preservation with aliens': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body> <p typeof="mw:Placeholder"> <br> </p> <p>\tFoo\t\t<tt>\t\t\tBar\t\t\t\t</tt>\nBaz\n\n<span typeof="mw:Placeholder">\n\n\nQuux\n\n\n\n</span> \tWhee \n</p>\t\n<figure>\n\tYay \t </figure> \n </body>',
Fix bugs in whitespace preservation for aliens This was broken in three different ways: * On the way in, we were applying whitespace to an array of elements rather than the actual element, so the whitespace wasn't stored. * Whitespace processing on the way out was skipped for aliens because they had their own code path. Refactored this so alien openings and regular openings share much more code, including whitespace output. * Somewhat unrelatedly, innerPost output was broken for paragraphs containing inline elements, because the inline elements' processing polluted lastOuterPost. Discovered this because my test with inline aliens also happened to be the first test of whitespace preservation in paragraphs with inline content elements. Fixed by explicitly skipping content nodes when outputting whitespace. Fixed these issues and added a test case. Change-Id: I8edb61a008e60ace886b1a841b3417682ec39c32
2012-09-07 21:58:27 +00:00
'data': [
{
'type': 'alienBlock',
'attributes': {
'html': '<p typeof="mw:Placeholder"> <br> </p>'
},
'internal': {
'whitespace': [ ' ', undefined, undefined, ' ' ]
}
},
{ 'type': '/alienBlock' },
{ 'type': 'paragraph', 'internal': { 'whitespace': [ ' ', '\t', ' \n', '\t\n' ] } },
'F',
'o',
'o',
'\t',
'\t',
{ 'type': 'alienInline', 'attributes': { 'html': '<tt>\t\t\tBar\t\t\t\t</tt>' } },
{ 'type': '/alienInline' },
'\n',
'B',
'a',
'z',
'\n',
'\n',
{
'type': 'alienInline',
'attributes': {
'html': '<span typeof="mw:Placeholder">\n\n\nQuux\n\n\n\n</span>'
}
},
{ 'type': '/alienInline' },
' ',
'\t',
'W',
'h',
'e',
'e',
{ 'type': '/paragraph' },
{
'type': 'alienBlock',
'attributes': {
'html': '<figure>\n\tYay \t </figure>'
},
'internal': {
'whitespace': [ '\t\n', undefined, undefined, ' \n ' ]
}
},
{ 'type': '/alienBlock' }
]
},
Flag pre nodes as having significant whitespace This causes the converter not to strip inner whitespace in them, and causes CE to suppress the whitespace mangling logic that is normally applied (↵ for newlines, ➞ for tabs, alternating &nbsp;s for spaces). Change-Id: I738a750c91a4ca4836c485e282865bb7525bf30a
2012-11-07 20:03:58 +00:00
'whitespace preservation not triggered inside <pre>': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body>\n<pre>\n\n\nFoo\n\n\nBar\n\n\n\n</pre>\n\n\n\n\n</body>',
Flag pre nodes as having significant whitespace This causes the converter not to strip inner whitespace in them, and causes CE to suppress the whitespace mangling logic that is normally applied (↵ for newlines, ➞ for tabs, alternating &nbsp;s for spaces). Change-Id: I738a750c91a4ca4836c485e282865bb7525bf30a
2012-11-07 20:03:58 +00:00
'data': [
{ 'type': 'preformatted', 'internal': { 'whitespace': ['\n', undefined, undefined, '\n\n\n\n\n' ] } },
'\n',
'\n',
'F',
'o',
'o',
'\n',
'\n',
'\n',
'B',
'a',
'r',
'\n',
'\n',
'\n',
'\n',
{ 'type': '/preformatted' }
(bug 42469) Leading newlines in <pre>s get eaten HTML DOM has annoying behavior for <pre>s where .innerHTML eats the first newline in a <pre>. Work around this by explicitly adding a newline in the data->DOM converter if the <pre> already contained a newline. There is a separate bug in Parsoid that causes the newline to be lost anyway, filed as bug 42666 Change-Id: Ia26cd4a4c61afbe439b0562deb7f24ee8b8147d7
2012-12-04 00:43:47 +00:00
],
// pre newline hack
// TODO we should test this using a better, more .innerHTML-based mechanism for
// comparing DOM trees
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'normalizedHtml': '<body>\n<pre>\n\n\n\nFoo\n\n\nBar\n\n\n\n</pre>\n\n\n\n\n</body>'
Flag pre nodes as having significant whitespace This causes the converter not to strip inner whitespace in them, and causes CE to suppress the whitespace mangling logic that is normally applied (↵ for newlines, ➞ for tabs, alternating &nbsp;s for spaces). Change-Id: I738a750c91a4ca4836c485e282865bb7525bf30a
2012-11-07 20:03:58 +00:00
},
Preserve whitespace between elements This commit fully utilizes all four positions in the internal.whitespace array. Outer whitespace is now preserved as well, and is duplicated either in the adjacent sibling (one node's outerPost is the next sibling's outerPre) or in the parent (a branch node's innerPre is its first child's outerPre, and its innerPost is its last child's outerPost). Before restoring saved whitespace, we check that these two agree with each other, and if they disagree we assume the user has been moving stuff around and don't restore any whitespace in that spot. The whitespace at the very beginning and the very end of the document (i.e. the first node's outerPre and the last node's outerPost) isn't duplicated anywhere, nor is inner whitespace in content nodes. The basic outline of the implementation is: * When we encounter whitespace, strip it and store it in the previous node's outerPost. Also store it in nextWhitespace so we can put it in the next node's outerPre once we encounter that node. * When we encounter whitespace in wrapped bare text, we don't know in advance if it's gonna be succeeded by more non-whitespace (in which case it needs to be output verbatim), or not (in which case it's leading whitespace and needs to be stripped and stored). The fact that annotations are nodes in HTML makes this trickier. So we write the whitespace to the temporary linmod and store it in wrappedWhitespace, then if it turns out to be trailing whitespace we take it back out of the data array and record it the usual way. * Because text nodes can contain any combination of leading whitespace actual text and trailing whitespace, and because we may or may not already have opened a wrapping paragraph, there are a lot of different combinations to handle. We handle all of them but the resulting code is pretty dense and verbose. More low-level list of changes: In getDataFromDom(): * Added helper function addWhitespace() for storing whitespace for an element * Added helper function processNextWhitespace() for processing any whitespace passed on from the previous node via the nextWhitespace var * Rename paragraph to wrappingParagraph. Make wrapping default to alreadyWrapped so we can simplify wrapping||alreadyWrapped and !wrapping&&!alreadyWrapped. Add wrappingIsOurs to track whether the wrapping originated in this recursion level (needed for deciding when to close the wrapper). * Add prevElement to track the previous element so we can propagate whitespace to it, and nextWhitespace so we can propagate whitespace to the next element. * Remove previous newline stripping hacks * Integrate the logic for wrapping bare content with the outer whitespace preservation code * Remove wrapperElement, no longer needed because we have a dedicated variable for the wrapping paragraph now and what was previously inner whitespace preservation for wrapper paragraphs is now covered by the outer whitespace preservation code. In getDomFromData(): * Reinsert whitespace where appropriate ** outerPre is inserted when opening the element ** This covers outerPost as well except for the last child's outerPost, which is handled as the parent's innerPost when closing the parent. ** innerPre and innerPost are inserted when closing the element. Care is taken not to insert these if they're duplicates of something else. * Propagate each node's outerPost to the next node (either the next sibling or the parent) using parentDomElement.lastOuterPost. We can't get this using .lastChild because we will have destroyed that child's .veInternal by then, and we can't tell whether a node will be its parent's last child when we process it (all other processing, including first child handling is done when processing the node itself, but this cannot be). * Special handling is needed for the last node's outerPost, which ends up in the container's .lastOuterPost property. Tests: * Allow .html to be null in data<->DOM converter tests. This indicates that the test is a one-way data->DOM test, not a DOM->data->DOM round-trip test. The data will be converted to HTML and checked against .normalizedHtml * Update existing tests as needed * Add tests for outer whitespace preservation and storage * Add test for squashing of whitespace in case of disagreement (this requires .html=null) Change-Id: I4db4fe372a421182e80a2535657af7784ff15f95
2012-08-21 00:37:42 +00:00
'mismatching whitespace data is ignored': {
'html': null,
'data': [
{ 'type': 'list', 'attributes': { 'style': 'bullet' }, 'internal': { 'whitespace': [ ' ', ' ', ' ', ' ' ] } },
{ 'type': 'listItem', 'internal': { 'whitespace': [ ' ', ' ', ' ', ' ' ] } },
{ 'type': 'paragraph', 'internal': { 'whitespace': [ ' ', '\t', '\n', ' ' ] } },
'A',
{ 'type': '/paragraph' },
{ 'type': 'paragraph', 'internal': { 'whitespace': [ ' ' ] } },
'B',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': '/list' }
],
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'normalizedHtml': '<body> <ul><li><p>\tA\n</p> <p>B</p></li></ul> </body>'
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
},
'order of nested annotations is preserved': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><p><b><a rel="mw:WikiLink" href="Foo"><i>Foo</i></a></b></p></body>',
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
'data': [
{ 'type': 'paragraph' },
[
'F',
[
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
ve.dm.example.bold,
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
{
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'type': 'link/MWinternal',
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
'data': {
Fix order-of-annotation tests for hrefPrefix Change-Id: I9fffad6cd0b186a070fec34fd0f827a5875a5d67
2012-09-06 22:40:41 +00:00
'hrefPrefix': '',
Fix tests for fda2e6c1b54a0139a3123de413f672e895ff3352 Change-Id: I2725f3f775e092bafe7aa9dca71d2a9022f16db8
2012-11-23 18:56:00 +00:00
'origTitle': 'Foo',
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'title': 'Foo'
},
'htmlTagName': 'a',
'htmlAttributes': {
'href': 'Foo',
'rel': 'mw:WikiLink'
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
}
},
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
ve.dm.example.italic
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
]
],
[
'o',
[
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
ve.dm.example.bold,
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
{
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'type': 'link/MWinternal',
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
'data': {
Fix order-of-annotation tests for hrefPrefix Change-Id: I9fffad6cd0b186a070fec34fd0f827a5875a5d67
2012-09-06 22:40:41 +00:00
'hrefPrefix': '',
Fix tests for fda2e6c1b54a0139a3123de413f672e895ff3352 Change-Id: I2725f3f775e092bafe7aa9dca71d2a9022f16db8
2012-11-23 18:56:00 +00:00
'origTitle': 'Foo',
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'title': 'Foo'
},
'htmlTagName': 'a',
'htmlAttributes': {
'href': 'Foo',
'rel': 'mw:WikiLink'
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
}
},
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
ve.dm.example.italic
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
]
],
[
'o',
[
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
ve.dm.example.bold,
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
{
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'type': 'link/MWinternal',
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
'data': {
Fix order-of-annotation tests for hrefPrefix Change-Id: I9fffad6cd0b186a070fec34fd0f827a5875a5d67
2012-09-06 22:40:41 +00:00
'hrefPrefix': '',
Fix tests for fda2e6c1b54a0139a3123de413f672e895ff3352 Change-Id: I2725f3f775e092bafe7aa9dca71d2a9022f16db8
2012-11-23 18:56:00 +00:00
'origTitle': 'Foo',
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'title': 'Foo'
},
'htmlTagName': 'a',
'htmlAttributes': {
'href': 'Foo',
'rel': 'mw:WikiLink'
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
}
},
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
ve.dm.example.italic
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
]
],
{ 'type': '/paragraph' }
]
},
'nested annotations are closed and reopened in the correct order': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><p><a rel="mw:WikiLink" href="Foo">F<b>o<i>o</i></b><i>b</i></a><i>a<b>r</b>b<u>a</u>z</i></p></body>',
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
'data': [
{ 'type': 'paragraph' },
[
'F',
[
{
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'type': 'link/MWinternal',
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
'data': {
Fix order-of-annotation tests for hrefPrefix Change-Id: I9fffad6cd0b186a070fec34fd0f827a5875a5d67
2012-09-06 22:40:41 +00:00
'hrefPrefix': '',
Fix tests for fda2e6c1b54a0139a3123de413f672e895ff3352 Change-Id: I2725f3f775e092bafe7aa9dca71d2a9022f16db8
2012-11-23 18:56:00 +00:00
'origTitle': 'Foo',
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'title': 'Foo'
},
'htmlTagName': 'a',
'htmlAttributes': {
'href': 'Foo',
'rel': 'mw:WikiLink'
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
}
}
]
],
[
'o',
[
{
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'type': 'link/MWinternal',
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
'data': {
Fix order-of-annotation tests for hrefPrefix Change-Id: I9fffad6cd0b186a070fec34fd0f827a5875a5d67
2012-09-06 22:40:41 +00:00
'hrefPrefix': '',
Fix tests for fda2e6c1b54a0139a3123de413f672e895ff3352 Change-Id: I2725f3f775e092bafe7aa9dca71d2a9022f16db8
2012-11-23 18:56:00 +00:00
'origTitle': 'Foo',
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'title': 'Foo'
},
'htmlTagName': 'a',
'htmlAttributes': {
'href': 'Foo',
'rel': 'mw:WikiLink'
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
}
},
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
ve.dm.example.bold
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
]
],
[
'o',
[
{
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'type': 'link/MWinternal',
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
'data': {
Fix order-of-annotation tests for hrefPrefix Change-Id: I9fffad6cd0b186a070fec34fd0f827a5875a5d67
2012-09-06 22:40:41 +00:00
'hrefPrefix': '',
Fix tests for fda2e6c1b54a0139a3123de413f672e895ff3352 Change-Id: I2725f3f775e092bafe7aa9dca71d2a9022f16db8
2012-11-23 18:56:00 +00:00
'origTitle': 'Foo',
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'title': 'Foo'
},
'htmlTagName': 'a',
'htmlAttributes': {
'href': 'Foo',
'rel': 'mw:WikiLink'
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
}
},
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
ve.dm.example.bold,
ve.dm.example.italic
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
]
],
[
'b',
[
{
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'type': 'link/MWinternal',
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
'data': {
Fix order-of-annotation tests for hrefPrefix Change-Id: I9fffad6cd0b186a070fec34fd0f827a5875a5d67
2012-09-06 22:40:41 +00:00
'hrefPrefix': '',
Fix tests for fda2e6c1b54a0139a3123de413f672e895ff3352 Change-Id: I2725f3f775e092bafe7aa9dca71d2a9022f16db8
2012-11-23 18:56:00 +00:00
'origTitle': 'Foo',
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'title': 'Foo'
},
'htmlTagName': 'a',
'htmlAttributes': {
'href': 'Foo',
'rel': 'mw:WikiLink'
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
}
},
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
ve.dm.example.italic
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
]
],
[
'a',
[
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
ve.dm.example.italic
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
]
],
[
'r',
[
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
ve.dm.example.italic,
ve.dm.example.bold
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
]
],
[
'b',
[
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
ve.dm.example.italic
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
]
],
[
'a',
[
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
ve.dm.example.italic,
ve.dm.example.underline
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
]
],
[
'z',
[
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
ve.dm.example.italic
Add tests asserting ordering of annotations works Change-Id: Iada85b95914a8728ca809ebab9a42723c1e7a02c
2012-08-31 19:22:40 +00:00
]
],
{ 'type': '/paragraph' }
]
Add a node type for meta nodes This node type represents <meta> or <link> (transparently, based on the style attribute). I had to make two node types for this and hack the toData conversion code directly into ve.dm.Converter, because we don't have native support for node types that can be both inline and block. (We should add this in the node API rewrite.) The CE implementation renders a placeholder (with the same styles as an alien node) right now. I'm not sure how nice that is, but it's better than rendering raw <meta>/<link> tags. This whole thing is a total pile of hacks to make VE deal with <meta>/<link> tags until we have a proper node types API. Change-Id: Id6783fcfc35a896db088ff424ff9faaabcaff716
2012-09-06 21:07:39 +00:00
},
'document with meta elements': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><!-- No content conversion --><meta property="mw:PageProp/nocc" /><p>Foo' +
Add a node type for meta nodes This node type represents <meta> or <link> (transparently, based on the style attribute). I had to make two node types for this and hack the toData conversion code directly into ve.dm.Converter, because we don't have native support for node types that can be both inline and block. (We should add this in the node API rewrite.) The CE implementation renders a placeholder (with the same styles as an alien node) right now. I'm not sure how nice that is, but it's better than rendering raw <meta>/<link> tags. This whole thing is a total pile of hacks to make VE deal with <meta>/<link> tags until we have a proper node types API. Change-Id: Id6783fcfc35a896db088ff424ff9faaabcaff716
2012-09-06 21:07:39 +00:00
'<link rel="mw:WikiLink/Category" href="./Category:Bar" />Bar' +
(bug 42124) Store comments in the meta-linmod * Make converter generate meta nodes with 'style': 'comment' * Handle style==='comment' in MetaBlockNode toDOM converter * Add some comments to the meta test case ** Update other tests accordingly * Change getDomElementSummary() to actually assert presence of comment nodes (specifically, all non-text child nodes) Change-Id: Ieef9418f4c47df3541477d9420aa2ab8df6e3df1
2012-11-20 04:01:09 +00:00
'<meta property="mw:foo" content="bar" />Ba<!-- inline -->z</p>' +
'<meta property="mw:bar" content="baz" /><!--barbaz-->' +
Add a node type for meta nodes This node type represents <meta> or <link> (transparently, based on the style attribute). I had to make two node types for this and hack the toData conversion code directly into ve.dm.Converter, because we don't have native support for node types that can be both inline and block. (We should add this in the node API rewrite.) The CE implementation renders a placeholder (with the same styles as an alien node) right now. I'm not sure how nice that is, but it's better than rendering raw <meta>/<link> tags. This whole thing is a total pile of hacks to make VE deal with <meta>/<link> tags until we have a proper node types API. Change-Id: Id6783fcfc35a896db088ff424ff9faaabcaff716
2012-09-06 21:07:39 +00:00
'<link rel="mw:WikiLink/Category" href="./Category:Foo#Bar baz%23quux" />' +
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'<meta typeof="mw:Placeholder" data-parsoid="foobar" /></body>',
Introduce meta-linmod * ve.dm.Converter still generates metaInline/metaBlock elements as before, it's not affected by this change * ve.dm.Document constructor splits its input into "real" data and metadata ** Metadata is stored in this.metadata (the meta-linmod) as a sparse array of arrays, with an element for each offset in this.data ** this.data itself does not contain the metadata ** This means the node tree also doesn't contain the metadata ** Which means CE doesn't know about it at all * All splice operations on the linear model are sent through ve.dm.Document.spliceData(), which performs the splice and syncs the meta-linmod ** Metadata in the removed range is reaped and added to the metadata for the offset immediately following the removal * ve.dm.Document.getFullData() splices the linmod and meta-linmod back into each other; this "full data" is then fed back to ve.dm.Converter Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
2012-10-30 01:42:12 +00:00
'data': ve.dm.example.withMeta
Add change marking for Parsoid's benefit * Add map of change markers per offset to Transaction * Map is populated by TransactionProcessor * Markers are reversed on rollback * Removals aren't marked, Parsoid can detect these using DSR discontinuities Change-Id: I2290886ab411c6ad6162044ed85c091313613e51
2012-10-23 00:53:58 +00:00
},
'change markers': {
'html': null,
'data': [
{ 'type': 'paragraph', 'internal': { 'changed': { 'content': 1 } } },
'F',
'o',
'o',
{ 'type': 'image', 'internal': { 'changed': { 'attributes': 2 } } },
{ 'type': '/image' },
{ 'type': '/paragraph' },
{ 'type': 'paragraph', 'internal': { 'changed': { 'created': 1 } } },
'B',
'a',
'r',
(bug 41947) Propagate change markers when unwrapping generated nodes Editing the text of a list item results in a change marker on the paragraph within that list item. However, that paragraph usually isn't present in the HTML, so the converter unwraps it when converting back to HTML, and the change markers are lost. Instead, transfer the change markers to the <li>. Change-Id: Id675075d19c08d69bc8e990174841dc393b749fc
2012-11-16 23:39:35 +00:00
{ 'type': '/paragraph' },
{ 'type': 'list', 'attributes': { 'style': 'bullet' } },
{ 'type': 'listItem' },
{
'type': 'paragraph',
'internal': {
'generated': 'wrapper',
'changed': { 'content': 1 }
}
},
'B',
'a',
'z',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': '/list' }
Add change marking for Parsoid's benefit * Add map of change markers per offset to Transaction * Map is populated by TransactionProcessor * Markers are reversed on rollback * Removals aren't marked, Parsoid can detect these using DSR discontinuities Change-Id: I2290886ab411c6ad6162044ed85c091313613e51
2012-10-23 00:53:58 +00:00
],
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'normalizedHtml': '<body><p data-ve-changed="{&quot;content&quot;:1}">' +
Add change marking for Parsoid's benefit * Add map of change markers per offset to Transaction * Map is populated by TransactionProcessor * Markers are reversed on rollback * Removals aren't marked, Parsoid can detect these using DSR discontinuities Change-Id: I2290886ab411c6ad6162044ed85c091313613e51
2012-10-23 00:53:58 +00:00
'Foo<img data-ve-changed="{&quot;attributes&quot;:2}" />' +
(bug 41947) Propagate change markers when unwrapping generated nodes Editing the text of a list item results in a change marker on the paragraph within that list item. However, that paragraph usually isn't present in the HTML, so the converter unwraps it when converting back to HTML, and the change markers are lost. Instead, transfer the change markers to the <li>. Change-Id: Id675075d19c08d69bc8e990174841dc393b749fc
2012-11-16 23:39:35 +00:00
'</p><p data-ve-changed="{&quot;created&quot;:1}">Bar</p>' +
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'<ul><li data-ve-changed="{&quot;content&quot;:1}">Baz</li></ul></body>'
Add basic support for about groups About groups are HTML structures like the following: <div about="#mwt1">....</div> <span about="#mwt1">...</span> <div about="#mwt1">...</div> When about groups are alienated, they are now merged into one alien node, rather than producing a separate alien node for each sibling. This is very basic about group handling, because it only works for groups of directly adjacent siblings (text nodes are permitted in between, but nothing else) assumes all about groups are aliens (which is currently true). * Before processing an element in the DOM->data converter, perform about grouping on its children. This temporarily wraps about groups in <div data-ve-aboutgroup="value of about attribute"> * Extended createAlien() to handle single nodes as well as wrappers holding multiple nodes. * In the data->DOM converter, temporarily wrap multi-node aliens in <div data-ve-multi-child-alien-wrapper="true"> . This makes the rest of the algorithm easier. Change-Id: I2df5f62bc222b570fc11a89fe43d353f8363ead8
2012-11-08 02:03:05 +00:00
},
'about grouping': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><div typeof="mw:Placeholder" about="#mwt1">Foo</div>' +
Add basic support for about groups About groups are HTML structures like the following: <div about="#mwt1">....</div> <span about="#mwt1">...</span> <div about="#mwt1">...</div> When about groups are alienated, they are now merged into one alien node, rather than producing a separate alien node for each sibling. This is very basic about group handling, because it only works for groups of directly adjacent siblings (text nodes are permitted in between, but nothing else) assumes all about groups are aliens (which is currently true). * Before processing an element in the DOM->data converter, perform about grouping on its children. This temporarily wraps about groups in <div data-ve-aboutgroup="value of about attribute"> * Extended createAlien() to handle single nodes as well as wrappers holding multiple nodes. * In the data->DOM converter, temporarily wrap multi-node aliens in <div data-ve-multi-child-alien-wrapper="true"> . This makes the rest of the algorithm easier. Change-Id: I2df5f62bc222b570fc11a89fe43d353f8363ead8
2012-11-08 02:03:05 +00:00
'<figure typeof="mw:Placeholder" about="#mwt1">Bar</figure>' +
'<figure typeof="mw:Placeholder" about="#mwt2">Baz</figure>' +
'<span typeof="mw:Placeholder" about="#mwt2">Quux</span>' +
'<p>Whee</p><span typeof="mw:Placeholder" about="#mwt2">Yay</span>' +
'<div typeof="mw:Placeholder" about="#mwt2">Blah</div>' +
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'<span typeof="mw:Placeholder" about="#mwt3">Meh</span></body>',
Add basic support for about groups About groups are HTML structures like the following: <div about="#mwt1">....</div> <span about="#mwt1">...</span> <div about="#mwt1">...</div> When about groups are alienated, they are now merged into one alien node, rather than producing a separate alien node for each sibling. This is very basic about group handling, because it only works for groups of directly adjacent siblings (text nodes are permitted in between, but nothing else) assumes all about groups are aliens (which is currently true). * Before processing an element in the DOM->data converter, perform about grouping on its children. This temporarily wraps about groups in <div data-ve-aboutgroup="value of about attribute"> * Extended createAlien() to handle single nodes as well as wrappers holding multiple nodes. * In the data->DOM converter, temporarily wrap multi-node aliens in <div data-ve-multi-child-alien-wrapper="true"> . This makes the rest of the algorithm easier. Change-Id: I2df5f62bc222b570fc11a89fe43d353f8363ead8
2012-11-08 02:03:05 +00:00
'data': [
{
'type': 'alienBlock',
'attributes': {
'html': '<div typeof="mw:Placeholder" about="#mwt1">Foo</div>' +
'<figure typeof="mw:Placeholder" about="#mwt1">Bar</figure>'
}
},
{ 'type': '/alienBlock' },
{
'type': 'alienBlock',
'attributes': {
'html': '<figure typeof="mw:Placeholder" about="#mwt2">Baz</figure>' +
'<span typeof="mw:Placeholder" about="#mwt2">Quux</span>'
}
},
{ 'type': '/alienBlock' },
{ 'type': 'paragraph' },
'W',
'h',
'e',
'e',
{ 'type': '/paragraph' },
{
'type': 'alienBlock',
'attributes': {
'html': '<span typeof="mw:Placeholder" about="#mwt2">Yay</span>' +
'<div typeof="mw:Placeholder" about="#mwt2">Blah</div>'
}
},
{ 'type': '/alienBlock' },
(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-20 00:59:58 +00:00
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
Add basic support for about groups About groups are HTML structures like the following: <div about="#mwt1">....</div> <span about="#mwt1">...</span> <div about="#mwt1">...</div> When about groups are alienated, they are now merged into one alien node, rather than producing a separate alien node for each sibling. This is very basic about group handling, because it only works for groups of directly adjacent siblings (text nodes are permitted in between, but nothing else) assumes all about groups are aliens (which is currently true). * Before processing an element in the DOM->data converter, perform about grouping on its children. This temporarily wraps about groups in <div data-ve-aboutgroup="value of about attribute"> * Extended createAlien() to handle single nodes as well as wrappers holding multiple nodes. * In the data->DOM converter, temporarily wrap multi-node aliens in <div data-ve-multi-child-alien-wrapper="true"> . This makes the rest of the algorithm easier. Change-Id: I2df5f62bc222b570fc11a89fe43d353f8363ead8
2012-11-08 02:03:05 +00:00
{
(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-20 00:59:58 +00:00
'type': 'alienInline',
Add basic support for about groups About groups are HTML structures like the following: <div about="#mwt1">....</div> <span about="#mwt1">...</span> <div about="#mwt1">...</div> When about groups are alienated, they are now merged into one alien node, rather than producing a separate alien node for each sibling. This is very basic about group handling, because it only works for groups of directly adjacent siblings (text nodes are permitted in between, but nothing else) assumes all about groups are aliens (which is currently true). * Before processing an element in the DOM->data converter, perform about grouping on its children. This temporarily wraps about groups in <div data-ve-aboutgroup="value of about attribute"> * Extended createAlien() to handle single nodes as well as wrappers holding multiple nodes. * In the data->DOM converter, temporarily wrap multi-node aliens in <div data-ve-multi-child-alien-wrapper="true"> . This makes the rest of the algorithm easier. Change-Id: I2df5f62bc222b570fc11a89fe43d353f8363ead8
2012-11-08 02:03:05 +00:00
'attributes': {
'html': '<span typeof="mw:Placeholder" about="#mwt3">Meh</span>'
}
},
(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-20 00:59:58 +00:00
{ 'type': '/alienInline' },
{ 'type': '/paragraph' }
Add basic support for about groups About groups are HTML structures like the following: <div about="#mwt1">....</div> <span about="#mwt1">...</span> <div about="#mwt1">...</div> When about groups are alienated, they are now merged into one alien node, rather than producing a separate alien node for each sibling. This is very basic about group handling, because it only works for groups of directly adjacent siblings (text nodes are permitted in between, but nothing else) assumes all about groups are aliens (which is currently true). * Before processing an element in the DOM->data converter, perform about grouping on its children. This temporarily wraps about groups in <div data-ve-aboutgroup="value of about attribute"> * Extended createAlien() to handle single nodes as well as wrappers holding multiple nodes. * In the data->DOM converter, temporarily wrap multi-node aliens in <div data-ve-multi-child-alien-wrapper="true"> . This makes the rest of the algorithm easier. Change-Id: I2df5f62bc222b570fc11a89fe43d353f8363ead8
2012-11-08 02:03:05 +00:00
]
},
'whitespace preservation with an about group': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body> <div typeof="mw:Placeholder" about="#mwt1">\tFoo\t\t</div>\t\t\t' +
'<div typeof="mw:Placeholder" about="#mwt1"> Bar </div> </body>',
Add basic support for about groups About groups are HTML structures like the following: <div about="#mwt1">....</div> <span about="#mwt1">...</span> <div about="#mwt1">...</div> When about groups are alienated, they are now merged into one alien node, rather than producing a separate alien node for each sibling. This is very basic about group handling, because it only works for groups of directly adjacent siblings (text nodes are permitted in between, but nothing else) assumes all about groups are aliens (which is currently true). * Before processing an element in the DOM->data converter, perform about grouping on its children. This temporarily wraps about groups in <div data-ve-aboutgroup="value of about attribute"> * Extended createAlien() to handle single nodes as well as wrappers holding multiple nodes. * In the data->DOM converter, temporarily wrap multi-node aliens in <div data-ve-multi-child-alien-wrapper="true"> . This makes the rest of the algorithm easier. Change-Id: I2df5f62bc222b570fc11a89fe43d353f8363ead8
2012-11-08 02:03:05 +00:00
'data': [
{
'type': 'alienBlock',
'attributes': {
'html': '<div typeof="mw:Placeholder" about="#mwt1">\tFoo\t\t</div>\t\t\t' +
'<div typeof="mw:Placeholder" about="#mwt1"> Bar </div>'
},
'internal': {
'whitespace': [ ' ', undefined, undefined, ' ' ]
}
},
{ 'type': '/alienBlock' }
]
(bug 42218) Add MWEntityNode <span typeof="mw:Entity"> tags are now correctly represented in the model, and rendered in CE. There are still issues with cursor movement etc. in CE. Because the prioritization mechanism for annotations vs nodes is broken in the current "node API", I had to hack two special cases for mw:Entity into the converter. I also had to change the converter to ignore the children of inline nodes (this was a legitimate bug, but had never come up before). Change-Id: Ib9f70437c58b4ca06aa09f7272bf51d9c41b18f2
2012-11-20 23:37:06 +00:00
},
'mw:Entity': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><p>a<span typeof="mw:Entity">¢</span>b<span typeof="mw:Entity">¥</span><span typeof="mw:Entity">™</span></p></body>',
(bug 42218) Add MWEntityNode <span typeof="mw:Entity"> tags are now correctly represented in the model, and rendered in CE. There are still issues with cursor movement etc. in CE. Because the prioritization mechanism for annotations vs nodes is broken in the current "node API", I had to hack two special cases for mw:Entity into the converter. I also had to change the converter to ignore the children of inline nodes (this was a legitimate bug, but had never come up before). Change-Id: Ib9f70437c58b4ca06aa09f7272bf51d9c41b18f2
2012-11-20 23:37:06 +00:00
'data': [
{ 'type': 'paragraph' },
'a',
Change the HTML attribute prefix from html/ to html/0/ This means that <p data-foo="bar"> will now be converted to a paragraph with attributes {"html/0/data-foo":"bar"} rather than {"html/foo":"bar"} This paves the way for multi-element node (about group) handling in the node API: nodes representing multiple DOM elements will have html/i/attr to represent an attribute of the i'th DOM element. Change-Id: Iea52bdccd721942ca708c8f9f47e934524809845
2013-02-06 19:47:52 +00:00
{ 'type': 'MWentity', 'attributes': { 'character': '¢', 'html/0/typeof': 'mw:Entity' } },
(bug 42218) Add MWEntityNode <span typeof="mw:Entity"> tags are now correctly represented in the model, and rendered in CE. There are still issues with cursor movement etc. in CE. Because the prioritization mechanism for annotations vs nodes is broken in the current "node API", I had to hack two special cases for mw:Entity into the converter. I also had to change the converter to ignore the children of inline nodes (this was a legitimate bug, but had never come up before). Change-Id: Ib9f70437c58b4ca06aa09f7272bf51d9c41b18f2
2012-11-20 23:37:06 +00:00
{ 'type': '/MWentity' },
'b',
Change the HTML attribute prefix from html/ to html/0/ This means that <p data-foo="bar"> will now be converted to a paragraph with attributes {"html/0/data-foo":"bar"} rather than {"html/foo":"bar"} This paves the way for multi-element node (about group) handling in the node API: nodes representing multiple DOM elements will have html/i/attr to represent an attribute of the i'th DOM element. Change-Id: Iea52bdccd721942ca708c8f9f47e934524809845
2013-02-06 19:47:52 +00:00
{ 'type': 'MWentity', 'attributes': { 'character': '¥', 'html/0/typeof': 'mw:Entity' } },
(bug 42218) Add MWEntityNode <span typeof="mw:Entity"> tags are now correctly represented in the model, and rendered in CE. There are still issues with cursor movement etc. in CE. Because the prioritization mechanism for annotations vs nodes is broken in the current "node API", I had to hack two special cases for mw:Entity into the converter. I also had to change the converter to ignore the children of inline nodes (this was a legitimate bug, but had never come up before). Change-Id: Ib9f70437c58b4ca06aa09f7272bf51d9c41b18f2
2012-11-20 23:37:06 +00:00
{ 'type': '/MWentity' },
Change the HTML attribute prefix from html/ to html/0/ This means that <p data-foo="bar"> will now be converted to a paragraph with attributes {"html/0/data-foo":"bar"} rather than {"html/foo":"bar"} This paves the way for multi-element node (about group) handling in the node API: nodes representing multiple DOM elements will have html/i/attr to represent an attribute of the i'th DOM element. Change-Id: Iea52bdccd721942ca708c8f9f47e934524809845
2013-02-06 19:47:52 +00:00
{ 'type': 'MWentity', 'attributes': { 'character': '™', 'html/0/typeof': 'mw:Entity' } },
(bug 42218) Add MWEntityNode <span typeof="mw:Entity"> tags are now correctly represented in the model, and rendered in CE. There are still issues with cursor movement etc. in CE. Because the prioritization mechanism for annotations vs nodes is broken in the current "node API", I had to hack two special cases for mw:Entity into the converter. I also had to change the converter to ignore the children of inline nodes (this was a legitimate bug, but had never come up before). Change-Id: Ib9f70437c58b4ca06aa09f7272bf51d9c41b18f2
2012-11-20 23:37:06 +00:00
{ 'type': '/MWentity' },
{ 'type': '/paragraph' }
]
},
'wrapping with mw:Entity': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body>a<span typeof="mw:Entity">¢</span>b<span typeof="mw:Entity">¥</span><span typeof="mw:Entity">™</span></body>',
(bug 42218) Add MWEntityNode <span typeof="mw:Entity"> tags are now correctly represented in the model, and rendered in CE. There are still issues with cursor movement etc. in CE. Because the prioritization mechanism for annotations vs nodes is broken in the current "node API", I had to hack two special cases for mw:Entity into the converter. I also had to change the converter to ignore the children of inline nodes (this was a legitimate bug, but had never come up before). Change-Id: Ib9f70437c58b4ca06aa09f7272bf51d9c41b18f2
2012-11-20 23:37:06 +00:00
'data': [
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'a',
Change the HTML attribute prefix from html/ to html/0/ This means that <p data-foo="bar"> will now be converted to a paragraph with attributes {"html/0/data-foo":"bar"} rather than {"html/foo":"bar"} This paves the way for multi-element node (about group) handling in the node API: nodes representing multiple DOM elements will have html/i/attr to represent an attribute of the i'th DOM element. Change-Id: Iea52bdccd721942ca708c8f9f47e934524809845
2013-02-06 19:47:52 +00:00
{ 'type': 'MWentity', 'attributes': { 'character': '¢', 'html/0/typeof': 'mw:Entity' } },
(bug 42218) Add MWEntityNode <span typeof="mw:Entity"> tags are now correctly represented in the model, and rendered in CE. There are still issues with cursor movement etc. in CE. Because the prioritization mechanism for annotations vs nodes is broken in the current "node API", I had to hack two special cases for mw:Entity into the converter. I also had to change the converter to ignore the children of inline nodes (this was a legitimate bug, but had never come up before). Change-Id: Ib9f70437c58b4ca06aa09f7272bf51d9c41b18f2
2012-11-20 23:37:06 +00:00
{ 'type': '/MWentity' },
'b',
Change the HTML attribute prefix from html/ to html/0/ This means that <p data-foo="bar"> will now be converted to a paragraph with attributes {"html/0/data-foo":"bar"} rather than {"html/foo":"bar"} This paves the way for multi-element node (about group) handling in the node API: nodes representing multiple DOM elements will have html/i/attr to represent an attribute of the i'th DOM element. Change-Id: Iea52bdccd721942ca708c8f9f47e934524809845
2013-02-06 19:47:52 +00:00
{ 'type': 'MWentity', 'attributes': { 'character': '¥', 'html/0/typeof': 'mw:Entity' } },
(bug 42218) Add MWEntityNode <span typeof="mw:Entity"> tags are now correctly represented in the model, and rendered in CE. There are still issues with cursor movement etc. in CE. Because the prioritization mechanism for annotations vs nodes is broken in the current "node API", I had to hack two special cases for mw:Entity into the converter. I also had to change the converter to ignore the children of inline nodes (this was a legitimate bug, but had never come up before). Change-Id: Ib9f70437c58b4ca06aa09f7272bf51d9c41b18f2
2012-11-20 23:37:06 +00:00
{ 'type': '/MWentity' },
Change the HTML attribute prefix from html/ to html/0/ This means that <p data-foo="bar"> will now be converted to a paragraph with attributes {"html/0/data-foo":"bar"} rather than {"html/foo":"bar"} This paves the way for multi-element node (about group) handling in the node API: nodes representing multiple DOM elements will have html/i/attr to represent an attribute of the i'th DOM element. Change-Id: Iea52bdccd721942ca708c8f9f47e934524809845
2013-02-06 19:47:52 +00:00
{ 'type': 'MWentity', 'attributes': { 'character': '™', 'html/0/typeof': 'mw:Entity' } },
(bug 42218) Add MWEntityNode <span typeof="mw:Entity"> tags are now correctly represented in the model, and rendered in CE. There are still issues with cursor movement etc. in CE. Because the prioritization mechanism for annotations vs nodes is broken in the current "node API", I had to hack two special cases for mw:Entity into the converter. I also had to change the converter to ignore the children of inline nodes (this was a legitimate bug, but had never come up before). Change-Id: Ib9f70437c58b4ca06aa09f7272bf51d9c41b18f2
2012-11-20 23:37:06 +00:00
{ 'type': '/MWentity' },
{ 'type': '/paragraph' }
]
},
'whitespace preservation with mw:Entity': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><p> a <span typeof="mw:Entity"> </span> b <span typeof="mw:Entity">¥</span>\t<span typeof="mw:Entity">™</span></p></body>',
(bug 42218) Add MWEntityNode <span typeof="mw:Entity"> tags are now correctly represented in the model, and rendered in CE. There are still issues with cursor movement etc. in CE. Because the prioritization mechanism for annotations vs nodes is broken in the current "node API", I had to hack two special cases for mw:Entity into the converter. I also had to change the converter to ignore the children of inline nodes (this was a legitimate bug, but had never come up before). Change-Id: Ib9f70437c58b4ca06aa09f7272bf51d9c41b18f2
2012-11-20 23:37:06 +00:00
'data': [
{ 'type': 'paragraph', 'internal': { 'whitespace': [ undefined, ' ' ] } },
'a',
' ',
' ',
Change the HTML attribute prefix from html/ to html/0/ This means that <p data-foo="bar"> will now be converted to a paragraph with attributes {"html/0/data-foo":"bar"} rather than {"html/foo":"bar"} This paves the way for multi-element node (about group) handling in the node API: nodes representing multiple DOM elements will have html/i/attr to represent an attribute of the i'th DOM element. Change-Id: Iea52bdccd721942ca708c8f9f47e934524809845
2013-02-06 19:47:52 +00:00
{ 'type': 'MWentity', 'attributes': { 'character': ' ', 'html/0/typeof': 'mw:Entity' } },
(bug 42218) Add MWEntityNode <span typeof="mw:Entity"> tags are now correctly represented in the model, and rendered in CE. There are still issues with cursor movement etc. in CE. Because the prioritization mechanism for annotations vs nodes is broken in the current "node API", I had to hack two special cases for mw:Entity into the converter. I also had to change the converter to ignore the children of inline nodes (this was a legitimate bug, but had never come up before). Change-Id: Ib9f70437c58b4ca06aa09f7272bf51d9c41b18f2
2012-11-20 23:37:06 +00:00
{ 'type': '/MWentity' },
' ',
' ',
' ',
'b',
' ',
' ',
' ',
' ',
Change the HTML attribute prefix from html/ to html/0/ This means that <p data-foo="bar"> will now be converted to a paragraph with attributes {"html/0/data-foo":"bar"} rather than {"html/foo":"bar"} This paves the way for multi-element node (about group) handling in the node API: nodes representing multiple DOM elements will have html/i/attr to represent an attribute of the i'th DOM element. Change-Id: Iea52bdccd721942ca708c8f9f47e934524809845
2013-02-06 19:47:52 +00:00
{ 'type': 'MWentity', 'attributes': { 'character': '¥', 'html/0/typeof': 'mw:Entity' } },
(bug 42218) Add MWEntityNode <span typeof="mw:Entity"> tags are now correctly represented in the model, and rendered in CE. There are still issues with cursor movement etc. in CE. Because the prioritization mechanism for annotations vs nodes is broken in the current "node API", I had to hack two special cases for mw:Entity into the converter. I also had to change the converter to ignore the children of inline nodes (this was a legitimate bug, but had never come up before). Change-Id: Ib9f70437c58b4ca06aa09f7272bf51d9c41b18f2
2012-11-20 23:37:06 +00:00
{ 'type': '/MWentity' },
'\t',
Change the HTML attribute prefix from html/ to html/0/ This means that <p data-foo="bar"> will now be converted to a paragraph with attributes {"html/0/data-foo":"bar"} rather than {"html/foo":"bar"} This paves the way for multi-element node (about group) handling in the node API: nodes representing multiple DOM elements will have html/i/attr to represent an attribute of the i'th DOM element. Change-Id: Iea52bdccd721942ca708c8f9f47e934524809845
2013-02-06 19:47:52 +00:00
{ 'type': 'MWentity', 'attributes': { 'character': '™', 'html/0/typeof': 'mw:Entity' } },
(bug 42218) Add MWEntityNode <span typeof="mw:Entity"> tags are now correctly represented in the model, and rendered in CE. There are still issues with cursor movement etc. in CE. Because the prioritization mechanism for annotations vs nodes is broken in the current "node API", I had to hack two special cases for mw:Entity into the converter. I also had to change the converter to ignore the children of inline nodes (this was a legitimate bug, but had never come up before). Change-Id: Ib9f70437c58b4ca06aa09f7272bf51d9c41b18f2
2012-11-20 23:37:06 +00:00
{ 'type': '/MWentity' },
{ 'type': '/paragraph' }
]
(bug 42487) Don't crash the converter for "<span>\n<p>Foo</p></span>" The converter was misbehaving when handling <p>s inside <span>s. This can't be expressed in the linmod, but it would try to anyway. <span><p> would result in too many paragraph closing elements, leading to an exception in ve.dm.Document complaining about unbalanced input. <span>\n<p> would result in an exception in the converter itself while trying to perform whitespace preservation on the newline. This change makes the converter detect these scenarios and alienate the offending node. So <span><p>Foo</p></span> converts to a wrapper paragraph containing an alienInline whose HTML is "<p>Foo</p>" and which is annotated with a TextStyleSpanAnnotation. ve.dm.Converter.getDomFromData(): * Change the criteria for alienBlock vs alienInline ** Only infer from the node type if we're in wrapping mode AND we're at the same level where the wrapping started (wrappingIsOurs). If the latter isn't the case, we can't split the wrapper in the block case because we're at the wrong level. ** Use alienInline not only if the branch is a content branch, but also if there are active annotations. This catches e.g. <li><b><p> (and generally <span><p> on the top level). * Before converting a child element, check that the child isn't "bad". Bad children are non-content children in content branches, and non-content children encountered within a wrapper that we can't split. Only good children are converted, and bad children are alienated (cue Santa/Sinterklaas jokes). * Add childIsContent and rename branchIsContent to branchHasContent Change-Id: If420ae80ab0777424a9a5517335ef9d0170e87ae
2012-12-05 22:35:10 +00:00
},
'block node inside annotation node is alienated': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><span>\n<p>Bar</p></span></body>',
(bug 42487) Don't crash the converter for "<span>\n<p>Foo</p></span>" The converter was misbehaving when handling <p>s inside <span>s. This can't be expressed in the linmod, but it would try to anyway. <span><p> would result in too many paragraph closing elements, leading to an exception in ve.dm.Document complaining about unbalanced input. <span>\n<p> would result in an exception in the converter itself while trying to perform whitespace preservation on the newline. This change makes the converter detect these scenarios and alienate the offending node. So <span><p>Foo</p></span> converts to a wrapper paragraph containing an alienInline whose HTML is "<p>Foo</p>" and which is annotated with a TextStyleSpanAnnotation. ve.dm.Converter.getDomFromData(): * Change the criteria for alienBlock vs alienInline ** Only infer from the node type if we're in wrapping mode AND we're at the same level where the wrapping started (wrappingIsOurs). If the latter isn't the case, we can't split the wrapper in the block case because we're at the wrong level. ** Use alienInline not only if the branch is a content branch, but also if there are active annotations. This catches e.g. <li><b><p> (and generally <span><p> on the top level). * Before converting a child element, check that the child isn't "bad". Bad children are non-content children in content branches, and non-content children encountered within a wrapper that we can't split. Only good children are converted, and bad children are alienated (cue Santa/Sinterklaas jokes). * Add childIsContent and rename branchIsContent to branchHasContent Change-Id: If420ae80ab0777424a9a5517335ef9d0170e87ae
2012-12-05 22:35:10 +00:00
'data': [
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
[ '\n', [ ve.dm.example.span ] ],
{
'type': 'alienInline',
'attributes': {
'html': '<p>Bar</p>'
},
'annotations': [ ve.dm.example.span ]
},
{ 'type': '/alienInline' },
{ 'type': '/paragraph' }
]
},
'block node inside annotation node surrounded by tables': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><table></table><span>\n<p>Bar</p></span><table></table></body>',
(bug 42487) Don't crash the converter for "<span>\n<p>Foo</p></span>" The converter was misbehaving when handling <p>s inside <span>s. This can't be expressed in the linmod, but it would try to anyway. <span><p> would result in too many paragraph closing elements, leading to an exception in ve.dm.Document complaining about unbalanced input. <span>\n<p> would result in an exception in the converter itself while trying to perform whitespace preservation on the newline. This change makes the converter detect these scenarios and alienate the offending node. So <span><p>Foo</p></span> converts to a wrapper paragraph containing an alienInline whose HTML is "<p>Foo</p>" and which is annotated with a TextStyleSpanAnnotation. ve.dm.Converter.getDomFromData(): * Change the criteria for alienBlock vs alienInline ** Only infer from the node type if we're in wrapping mode AND we're at the same level where the wrapping started (wrappingIsOurs). If the latter isn't the case, we can't split the wrapper in the block case because we're at the wrong level. ** Use alienInline not only if the branch is a content branch, but also if there are active annotations. This catches e.g. <li><b><p> (and generally <span><p> on the top level). * Before converting a child element, check that the child isn't "bad". Bad children are non-content children in content branches, and non-content children encountered within a wrapper that we can't split. Only good children are converted, and bad children are alienated (cue Santa/Sinterklaas jokes). * Add childIsContent and rename branchIsContent to branchHasContent Change-Id: If420ae80ab0777424a9a5517335ef9d0170e87ae
2012-12-05 22:35:10 +00:00
'data': [
{ 'type': 'table' },
{ 'type': '/table' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
[ '\n', [ ve.dm.example.span ] ],
{
'type': 'alienInline',
'attributes': {
'html': '<p>Bar</p>'
},
'annotations': [ ve.dm.example.span ]
},
{ 'type': '/alienInline' },
{ 'type': '/paragraph' },
{ 'type': 'table' },
{ 'type': '/table' }
]
},
'block node inside annotation node is alienated and continues wrapping': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body>Foo<span>\n<p>Bar</p></span>Baz</body>',
(bug 42487) Don't crash the converter for "<span>\n<p>Foo</p></span>" The converter was misbehaving when handling <p>s inside <span>s. This can't be expressed in the linmod, but it would try to anyway. <span><p> would result in too many paragraph closing elements, leading to an exception in ve.dm.Document complaining about unbalanced input. <span>\n<p> would result in an exception in the converter itself while trying to perform whitespace preservation on the newline. This change makes the converter detect these scenarios and alienate the offending node. So <span><p>Foo</p></span> converts to a wrapper paragraph containing an alienInline whose HTML is "<p>Foo</p>" and which is annotated with a TextStyleSpanAnnotation. ve.dm.Converter.getDomFromData(): * Change the criteria for alienBlock vs alienInline ** Only infer from the node type if we're in wrapping mode AND we're at the same level where the wrapping started (wrappingIsOurs). If the latter isn't the case, we can't split the wrapper in the block case because we're at the wrong level. ** Use alienInline not only if the branch is a content branch, but also if there are active annotations. This catches e.g. <li><b><p> (and generally <span><p> on the top level). * Before converting a child element, check that the child isn't "bad". Bad children are non-content children in content branches, and non-content children encountered within a wrapper that we can't split. Only good children are converted, and bad children are alienated (cue Santa/Sinterklaas jokes). * Add childIsContent and rename branchIsContent to branchHasContent Change-Id: If420ae80ab0777424a9a5517335ef9d0170e87ae
2012-12-05 22:35:10 +00:00
'data': [
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'F',
'o',
'o',
[ '\n', [ ve.dm.example.span ] ],
{
'type': 'alienInline',
'attributes': {
'html': '<p>Bar</p>'
},
'annotations': [ ve.dm.example.span ]
},
{ 'type': '/alienInline' },
'B',
'a',
'z',
{ 'type': '/paragraph' }
]
Fix the "list of US Presidents" bug I noticed this bug on [[List of Presidents of the United States]]. When there's HTML that looks like "<td>Foo\n<meta/></td>", the converter will collect the newline in wrappedWhitespace, then attempt to splice it out and store it in internal data. But instead, it ends up splicing out the /metaBlock element, which causes strange unbalanced input, which causes an empty table in the node tree. Change-Id: I79ed2fa9a834cc42759c7d21250d8842f563d38f
2012-12-11 18:23:33 +00:00
},
'whitespace before meta node in wrapping mode': {
Make the converter work with full HTML documents rather than fragments The Parsoid output will also be expected to be a full HTML document. For backwards compatibility, we allow for the Parsoid output to be a document fragment as well. We don't send a full document back yet, also for b/c -- we'll change this later once Parsoid has been updated in production. ve.dm.Converter.js: * Make getDataFromDom() accept a document rather than a node ** Split off the recursion (which does use nodes) into its own function ** For now we just convert the <body>. In the future, we'll want to do things with the <head> as well * Pass the document around so we can use it when creating elements * Make getDomFromData() return a document rather than a <div> ve.init.mw.Target.js: * Store a document (this.doc) rather than a DOM node (this.dom) * Pass around documents rather than DOM nodes * Detect whether the Parsoid output is an HTML document or a fragment using a hacky regex * When submitting to Parsoid, submit the innerHTML of the <body> ve.init.mw.ViewPageTarget.js: * s/dom/doc/ * Store body.innerHTML in this.originalHtml ve.Surface.js: * s/dom/doc/ demos/ve/index.php: * Don't wrap HTML in <div> * Pass HTML document rather than DOM node to ve.Surface ve.dm.Converter.test.js: * Construct a document from the test HTML, rather than a <div> ve.dm.example.js: * Wrap the HTML in the converter test cases in <body> tags to prevent misinterpretation (HTML fragments starting with comments, <meta>, <link> and whitespace are problematic) Change-Id: I82fdad0a099febc5e658486cbf8becfcdbc85a2d
2013-02-11 19:46:58 +00:00
'html': '<body><table><tbody><tr><td>Foo\n<meta property="mw:foo" content="bar" /></td></tr></tbody></table></body>',
Fix the "list of US Presidents" bug I noticed this bug on [[List of Presidents of the United States]]. When there's HTML that looks like "<td>Foo\n<meta/></td>", the converter will collect the newline in wrappedWhitespace, then attempt to splice it out and store it in internal data. But instead, it ends up splicing out the /metaBlock element, which causes strange unbalanced input, which causes an empty table in the node tree. Change-Id: I79ed2fa9a834cc42759c7d21250d8842f563d38f
2012-12-11 18:23:33 +00:00
'data': [
{ 'type': 'table' },
{ 'type': 'tableSection', 'attributes': { 'style': 'body' } },
{ 'type': 'tableRow' },
{
'type': 'tableCell',
'attributes': { 'style': 'data' },
'internal': { 'whitespace': [ undefined, undefined, '\n' ] }
},
{
'type': 'paragraph',
'internal': {
'generated': 'wrapper',
'whitespace': [ undefined, undefined, undefined, '\n' ]
}
},
'F',
'o',
'o',
{
Introduce context object in getDataFromDom() * Introduce context object as specified for ve.dm.Node.static.toDataElement() * Remove wrapping variable in favor of context.wrapping * Remove wrappingIsOurs in favor of context.canCloseWrapper * Introduce originallyExpectingContent and use it to repopulate context.expectingContent after closing a wrapper * Replace most uses of branchHasContent with context.expectingContent ** Except for two cases where we need originallyExpectingContent These changes fix a case where a metaBlock was generated in an inline position. Updated the tests to reflect this. Change-Id: I6baf6053f8a3a0b7d91487f812b9235a7b2b3db1
2013-01-31 20:07:56 +00:00
'type': 'metaInline',
Fix the "list of US Presidents" bug I noticed this bug on [[List of Presidents of the United States]]. When there's HTML that looks like "<td>Foo\n<meta/></td>", the converter will collect the newline in wrappedWhitespace, then attempt to splice it out and store it in internal data. But instead, it ends up splicing out the /metaBlock element, which causes strange unbalanced input, which causes an empty table in the node tree. Change-Id: I79ed2fa9a834cc42759c7d21250d8842f563d38f
2012-12-11 18:23:33 +00:00
'attributes': {
'style': 'meta',
'key': 'mw:foo',
(bug 45062) Implement the new node API in the converter This changes the node API to work with multiple elements, so we can support about groups. Instead of passing in and returning single DOM elements, we use arrays of DOM elements. ve.dm.Converter: * Pass modelRegistry into the constructor * Remove onNodeRegister handler and its data * Remove getDataElementFromDomElement() and getDataAnnotationFromDomElement(). Most logic moved into getDataFromDom(), some into createDataElement() * Remove createAlien(), replaced with createDataElement( ve.dm.AlienNode, ... ) * Replace doAboutGrouping() (which wrapped about groups) with getAboutGroup() (which returns an array of the nodes in the group) * Put in a hack so <meta>/<link> elements with an mw: property aren't alienated * Remove about group wrapping behavior in favor of just outputting multiple nodes ve.dm.AlienNode.js: * For multi-element aliens, only choose inline if all elements are inline, not just the first one ve.dm.example.js: * Add html/0 stuff for meta nodes * Fix test case to reflect new alien behavior Change-Id: I40dcc27430f778bc00a44b91b7d824bfb2718be6
2013-02-16 02:37:50 +00:00
'value': 'bar',
'html/0/content': 'bar',
'html/0/property': 'mw:foo'
Fix the "list of US Presidents" bug I noticed this bug on [[List of Presidents of the United States]]. When there's HTML that looks like "<td>Foo\n<meta/></td>", the converter will collect the newline in wrappedWhitespace, then attempt to splice it out and store it in internal data. But instead, it ends up splicing out the /metaBlock element, which causes strange unbalanced input, which causes an empty table in the node tree. Change-Id: I79ed2fa9a834cc42759c7d21250d8842f563d38f
2012-12-11 18:23:33 +00:00
}
},
Introduce context object in getDataFromDom() * Introduce context object as specified for ve.dm.Node.static.toDataElement() * Remove wrapping variable in favor of context.wrapping * Remove wrappingIsOurs in favor of context.canCloseWrapper * Introduce originallyExpectingContent and use it to repopulate context.expectingContent after closing a wrapper * Replace most uses of branchHasContent with context.expectingContent ** Except for two cases where we need originallyExpectingContent These changes fix a case where a metaBlock was generated in an inline position. Updated the tests to reflect this. Change-Id: I6baf6053f8a3a0b7d91487f812b9235a7b2b3db1
2013-01-31 20:07:56 +00:00
{ 'type': '/metaInline' },
Fix the "list of US Presidents" bug I noticed this bug on [[List of Presidents of the United States]]. When there's HTML that looks like "<td>Foo\n<meta/></td>", the converter will collect the newline in wrappedWhitespace, then attempt to splice it out and store it in internal data. But instead, it ends up splicing out the /metaBlock element, which causes strange unbalanced input, which causes an empty table in the node tree. Change-Id: I79ed2fa9a834cc42759c7d21250d8842f563d38f
2012-12-11 18:23:33 +00:00
{ 'type': '/paragraph' },
{ 'type': '/tableCell' },
{ 'type': '/tableRow' },
{ 'type': '/tableSection' },
{ 'type': '/table' }
]
Clean up a few commas and some indentation The commas were resulting from converting this: var foo = 3, bar = 5; to this: foo = 3, bar = 5; Change-Id: I0223b34a30d947c6a51f0601727b0c3850239e66
2012-08-10 23:49:14 +00:00
}
Test getDomFromData using getDataFromDom's tests Move the test cases for getDataFromDom out into ve.dm.example and use them to test getDomFromData as well Change-Id: Ib33854a7a1e8cb6a8ebf2c5b88cd5c17e25644b2
2012-06-08 05:00:25 +00:00
};
Create tests for ve.FormatAction.convert These 3 tests convert different selections of list items to headings. Bug: 45216 Change-Id: I6cf042d9d5aa4afb68c0992f444b600ed69f0c04
2013-02-21 01:30:02 +00:00
ve.dm.example.isolationHTML =
'<ul><li>Item 1</li><li>Item 2</li><li>Item 3</li></ul>' +
'Paragraph' +
'<ul><li>Item 4</li><li>Item 5</li><li>Item 6</li></ul>' +
'<table><tbody><tr><td>Cell 1</td><td>Cell 2</td><td>Cell 3</td></tr><tr><td>Cell 4</td></tr></tbody></table>' +
'Not allowed by dm:' +
'<ul><li><h1>Title in list</h1></li><li><pre>Preformatted in list</pre></li></ul>';
ve.dm.example.isolationData = [
{ 'type': 'list', 'attributes': { 'style': 'bullet' } },
{ 'type': 'listItem' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'I', 't', 'e', 'm', ' ', '1',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': 'listItem' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'I', 't', 'e', 'm', ' ', '2',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': 'listItem' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'I', 't', 'e', 'm', ' ', '3',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': '/list' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'P', 'a', 'r', 'a', 'g', 'r', 'a', 'p', 'h',
{ 'type': '/paragraph' },
{ 'type': 'list', 'attributes': { 'style': 'bullet' } },
{ 'type': 'listItem' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'I', 't', 'e', 'm', ' ', '4',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': 'listItem' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'I', 't', 'e', 'm', ' ', '5',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': 'listItem' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'I', 't', 'e', 'm', ' ', '6',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': '/list' },
{ 'type': 'table' },
{ 'type': 'tableSection', 'attributes': { 'style': 'body' } },
{ 'type': 'tableRow' },
{ 'type': 'tableCell', 'attributes': { 'style': 'data' } },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'C', 'e', 'l', 'l', ' ', '1',
{ 'type': '/paragraph' },
{ 'type': '/tableCell' },
{ 'type': 'tableCell', 'attributes': { 'style': 'data' } },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'C', 'e', 'l', 'l', ' ', '2',
{ 'type': '/paragraph' },
{ 'type': '/tableCell' },
{ 'type': 'tableCell', 'attributes': { 'style': 'data' } },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'C', 'e', 'l', 'l', ' ', '3',
{ 'type': '/paragraph' },
{ 'type': '/tableCell' },
{ 'type': '/tableRow' },
{ 'type': 'tableRow' },
{ 'type': 'tableCell', 'attributes': { 'style': 'data' } },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'C', 'e', 'l', 'l', ' ', '4',
{ 'type': '/paragraph' },
{ 'type': '/tableCell' },
{ 'type': '/tableRow' },
{ 'type': '/tableSection' },
{ 'type': '/table' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'N', 'o', 't', ' ', 'a', 'l', 'l', 'o', 'w', 'e', 'd', ' ', 'b', 'y', ' ', 'd', 'm', ': ',
{ 'type': '/paragraph' },
{ 'type': 'list', 'attributes': { 'style': 'bullet' } },
{ 'type': 'listItem' },
{ 'type': 'heading', 'attributes': { 'level': 1 } },
'T', 'i', 't', 'l', 'e', ' ', 'i', 'n', ' ', 'l', 'i', 's', 't',
{ 'type': '/heading' },
{ 'type': '/listItem' },
{ 'type': 'listItem' },
{ 'type': 'preformatted' },
'P', 'r', 'e', 'f', 'o', 'r', 'm', 'a', 't', 't', 'e', 'd', ' ', 'i', 'n', ' ', 'l', 'i', 's', 't',
{ 'type': '/preformatted' },
{ 'type': '/listItem' },
{ 'type': '/list' }
Merge "(bug 45062) Implement the new node API in the converter"
2013-02-22 23:26:18 +00:00
];
Reference in a new issue Copy permalink