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

2820 lines
78 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
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
* annotation objects, and wraps the result in a ve.dm.ElementLinearData object.
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
*
* Shorthand notation for annotations is:
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
* [ 'a', [ { 'type': 'link', 'attributes': { 'href': '...' } ] ]
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
*
* The actual storage format has an instance of ve.dm.LinkAnnotation instead of the plain object,
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
* and an instance of ve.dm.AnnotationSet instead of the array.
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +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
* @method
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
* @param {Array} data Linear model data
* @param {ve.dm.IndexValueStore} [store] Index-value store to use, creates one if undefined
* @returns {ve.dm.ElementLinearData} Element linear data store
* @throws {Error} Example data passed to preprocessAnnotations by reference
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
*/
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
ve.dm.example.preprocessAnnotations = function ( data, store ) {
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
var i, key;
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
// Sanity check to make sure ve.dm.example data has not been passed in
// by reference. Always use ve.copyArray.
for ( i in ve.dm.example ) {
if ( data === ve.dm.example[i] ) {
throw new Error( 'Example data passed to preprocessAnnotations by reference' );
}
}
store = store || new ve.dm.IndexValueStore();
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
for ( i = 0; i < data.length; i++ ) {
key = data[i].annotations ? 'annotations' : 1;
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
// check for shorthand annotation objects in array
if ( ve.isArray( data[i][key] ) && data[i][key][0].type ) {
data[i][key] = ve.dm.example.createAnnotationSet( store, data[i][key] ).getIndexes();
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
}
}
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
return new ve.dm.ElementLinearData( store, data );
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
};
/**
* 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
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
* @param {Object} annotation Plain object with type and attributes properties
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
* @return {ve.dm.Annotation} Instance of the right ve.dm.Annotation subclass
*/
ve.dm.example.createAnnotation = function ( annotation ) {
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
return ve.dm.annotationFactory.create( annotation.type, annotation );
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
};
/**
* 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
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
* @return {ve.dm.AnnotationSet}
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
*/
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
ve.dm.example.createAnnotationSet = function ( store, annotations ) {
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
var i;
for ( i = 0; i < annotations.length; i++ ) {
annotations[i] = ve.dm.example.createAnnotation( annotations[i] );
}
Make the AnnotationSet constructor take an array of indexes Before, it took an array of objects and translated those to indexes using the store. Literally every caller outside of the test suite got an array of indexes from the linear model, translated those to objects, then passed them into the AnnotationSet constructor which translated them right back to indexes. The previous behavior was kind of ridiculous on its face, but the reason we found it is because Inez was investigating the performance degradation when bolding a line and found that half of it was due to the hundreds of ve.getHash() calls caused by this behavior. Change-Id: I38df8ae9f6392849dacf477ea2f804283c964417
2013-04-18 17:56:03 +00:00
return new ve.dm.AnnotationSet( store, store.indexes( 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 */
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
ve.dm.example.bold = { 'type': 'textStyle/bold' };
ve.dm.example.italic = { 'type': 'textStyle/italic' };
ve.dm.example.underline = { 'type': 'textStyle/underline' };
ve.dm.example.span = { 'type': 'textStyle/span' };
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
/**
* Creates a document from example data.
*
* Defaults to ve.dm.example.data if no name is supplied.
*
* @param {string} [name='data'] Named element of ve.dm.example
* @param {ve.dm.IndexValueStore} [store] A specific index-value store to use, optionally.
* @returns {ve.dm.Document} Document
* @throws {Error} Example data not found
*/
Code style fixes * "function(" -> "function (" * "{String}" -> "{string}" * collapse unintentional double spaces Change-Id: I3ce3f02d1e31d4797b44e04d28457dec363be296
2013-05-06 11:34:32 +00:00
ve.dm.example.createExampleDocument = function ( name, store ) {
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
name = name || 'data';
store = store || new ve.dm.IndexValueStore();
if ( ve.dm.example[name] === undefined ) {
throw new Error( 'Example data \'' + name + '\' not found' );
}
return new ve.dm.Document(
ve.dm.example.preprocessAnnotations( ve.copyArray( ve.dm.example[name] ), store )
);
};
Test: Fix 404 errors in example images. Consistently refer to example.png for <img> tests. And "Wiki.png" for MediaWiki image tests. Change-Id: I799654b66bb586338e807a84bb84f7ec0b486728
2013-04-02 21:40:07 +00:00
ve.dm.example.testDir = window.mw ?
( window.mw.config.get( 'wgExtensionAssetsPath' ) + '/VisualEditor/modules/ve/test' ) :
'.';
ve.dm.example.imgSrc = ve.dm.example.testDir + '/example.png';
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>' +
Test: Fix 404 errors in example images. Consistently refer to example.png for <img> tests. And "Wiki.png" for MediaWiki image tests. Change-Id: I799654b66bb586338e807a84bb84f7ec0b486728
2013-04-02 21:40:07 +00:00
'<pre>h<img src="' + ve.dm.example.imgSrc + '">i</pre>'+
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
'<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' },
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
// 32 - End of lis t
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
Image node refactor ve.ce.ImageNode.js * Moved in generic stuff from MWImageNode * Added drag end handler (empty, will be used soon) ve.ce.MWImageNode.js * Changed to inherit ImageNode * Moved generic stuff out ve.dm.ImageNode.js * Added attribute extraction/preservation for src, width and height ve.dm.MWImageNode.js * Changed to inherit ImageNode * Re-using ImageNode's attribute handling to extract/preserve attributes on both the image and wrapper level Change-Id: Ied4e1ece24e6804220eac35330790f7084df55de
2013-04-10 19:56:20 +00:00
{ 'type': 'image', 'attributes': {
'html/0/src': ve.dm.example.imgSrc,
'src': ve.dm.example.imgSrc,
'width': null,
'height': null
} },
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
];
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
];
Add data model support for MediaWiki references So far just read-only. Bug: 39599 Change-Id: I6daff5c5969e5fdc871f8f346cf790b4302ae080
2013-04-17 17:53:26 +00:00
ve.dm.example.internalData = [
{ 'type': 'paragraph' },
'F', 'o', 'o',
{ 'type': '/paragraph' },
{ 'type': 'internalList' },
{ 'type': 'internalItem' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'B', 'a', 'r',
{ 'type': '/paragraph' },
{ 'type': '/internalItem' },
{ 'type': 'internalItem' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'B', 'a', 'z',
{ 'type': '/paragraph' },
{ 'type': '/internalItem' },
{ 'type': '/internalList' },
{ 'type': 'paragraph' },
'Q', 'u', 'u', 'x',
{ 'type': '/paragraph' }
];
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
{
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
'type': 'alienMeta',
(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
'attributes': {
'style': 'comment',
'text': ' No content conversion '
}
},
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
{ 'type': '/alienMeta' },
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
{
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
'type': 'alienMeta',
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
'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
}
},
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
{ 'type': '/alienMeta' },
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': 'paragraph' },
'F',
'o',
'o',
{
Add MW-specific meta items for categories and language links Also rename MWMetaItem to MWAlienMetaItem, because that's what it really is. Change-Id: I70695bfa3b8449c936a63f7b2a248b90c49dcea1
2013-03-21 19:18:52 +00:00
'type': 'MWcategory',
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
'attributes': {
Add MW-specific meta items for categories and language links Also rename MWMetaItem to MWAlienMetaItem, because that's what it really is. Change-Id: I70695bfa3b8449c936a63f7b2a248b90c49dcea1
2013-03-21 19:18:52 +00:00
'hrefPrefix': './',
'category': 'Category:Bar',
'origCategory': 'Category:Bar',
'sortkey': '',
'origSortkey': '',
'html/0/rel': 'mw:WikiLink/Category',
'html/0/href': './Category: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
}
},
Add MW-specific meta items for categories and language links Also rename MWMetaItem to MWAlienMetaItem, because that's what it really is. Change-Id: I70695bfa3b8449c936a63f7b2a248b90c49dcea1
2013-03-21 19:18:52 +00:00
{ 'type': '/MWcategory' },
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
'B',
'a',
'r',
{
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
'type': 'alienMeta',
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
'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
}
},
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
{ 'type': '/alienMeta' },
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
'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
{
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
'type': 'alienMeta',
(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
'attributes': {
'style': 'comment',
'text': ' inline '
}
},
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
{ 'type': '/alienMeta' },
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' },
{
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
'type': 'alienMeta',
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
'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
}
},
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
{ 'type': '/alienMeta' },
(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
{
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
'type': 'alienMeta',
(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
'attributes': {
'style': 'comment',
'text': 'barbaz'
}
},
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
{ 'type': '/alienMeta' },
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
{
Add MW-specific meta items for categories and language links Also rename MWMetaItem to MWAlienMetaItem, because that's what it really is. Change-Id: I70695bfa3b8449c936a63f7b2a248b90c49dcea1
2013-03-21 19:18:52 +00:00
'type': 'MWcategory',
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
'attributes': {
Add MW-specific meta items for categories and language links Also rename MWMetaItem to MWAlienMetaItem, because that's what it really is. Change-Id: I70695bfa3b8449c936a63f7b2a248b90c49dcea1
2013-03-21 19:18:52 +00:00
'hrefPrefix': './',
'category': 'Category:Foo foo',
'origCategory': 'Category:Foo_foo',
'sortkey': 'Bar baz#quux',
'origSortkey': 'Bar baz%23quux',
'html/0/href': './Category:Foo_foo#Bar baz%23quux',
(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/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
}
},
Add MW-specific meta items for categories and language links Also rename MWMetaItem to MWAlienMetaItem, because that's what it really is. Change-Id: I70695bfa3b8449c936a63f7b2a248b90c49dcea1
2013-03-21 19:18:52 +00:00
{ 'type': '/MWcategory' },
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
{
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
'type': 'alienMeta',
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
'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
}
},
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
{ 'type': '/alienMeta' }
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.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
{
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
'type': 'alienMeta',
(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
'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
{
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
'type': 'alienMeta',
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
'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,
[
{
Add MW-specific meta items for categories and language links Also rename MWMetaItem to MWAlienMetaItem, because that's what it really is. Change-Id: I70695bfa3b8449c936a63f7b2a248b90c49dcea1
2013-03-21 19:18:52 +00:00
'type': 'MWcategory',
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
'attributes': {
Add MW-specific meta items for categories and language links Also rename MWMetaItem to MWAlienMetaItem, because that's what it really is. Change-Id: I70695bfa3b8449c936a63f7b2a248b90c49dcea1
2013-03-21 19:18:52 +00:00
'hrefPrefix': './',
'category': 'Category:Bar',
'origCategory': 'Category:Bar',
'sortkey': '',
'origSortkey': '',
'html/0/rel': 'mw:WikiLink/Category',
'html/0/href': './Category: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
}
}
],
undefined,
undefined,
[
{
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
'type': 'alienMeta',
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
'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
[
{
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
'type': 'alienMeta',
(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
'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,
[
{
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
'type': 'alienMeta',
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
'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
{
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
'type': 'alienMeta',
(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
'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
{
Add MW-specific meta items for categories and language links Also rename MWMetaItem to MWAlienMetaItem, because that's what it really is. Change-Id: I70695bfa3b8449c936a63f7b2a248b90c49dcea1
2013-03-21 19:18:52 +00:00
'type': 'MWcategory',
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
'attributes': {
Add MW-specific meta items for categories and language links Also rename MWMetaItem to MWAlienMetaItem, because that's what it really is. Change-Id: I70695bfa3b8449c936a63f7b2a248b90c49dcea1
2013-03-21 19:18:52 +00:00
'hrefPrefix': './',
'category': 'Category:Foo foo',
'origCategory': 'Category:Foo_foo',
'sortkey': 'Bar baz#quux',
'origSortkey': 'Bar baz%23quux',
'html/0/href': './Category:Foo_foo#Bar baz%23quux',
(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/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
}
},
{
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
'type': 'alienMeta',
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
'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
}
}
]
];
Add TableCaptionNode Because we have a node for <table>, we also need one for <caption>, otherwise we'll try to alienate it and fail. Added the test case as a separate example document so Ed can use it for his tests. Removed test case asserting <caption> is alienated. Change-Id: I3a917db58e6c0eb97899b214b07d01fc8d86b56d
2013-04-25 22:24:37 +00:00
ve.dm.example.complexTableHtml = '<table><caption>Foo</caption><thead><tr><th>Bar</th></tr></thead>' +
'<tfoot><tr><td>Baz</td></tr></tfoot><tbody><tr><td>Quux</td><td>Whee</td></tr></tbody></table>';
ve.dm.example.complexTable = [
{ 'type': 'table' },
{ 'type': 'tableCaption' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'F',
'o',
'o',
{ 'type': '/paragraph' },
{ 'type': '/tableCaption' },
{ 'type': 'tableSection', 'attributes': { 'style': 'header' } },
{ 'type': 'tableRow' },
{ 'type': 'tableCell', 'attributes': { 'style': 'header' } },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'B',
'a',
'r',
{ 'type': '/paragraph' },
{ 'type': '/tableCell' },
{ 'type': '/tableRow' },
{ 'type': '/tableSection' },
{ 'type': 'tableSection', 'attributes': { 'style': 'footer' } },
{ 'type': 'tableRow' },
{ 'type': 'tableCell', 'attributes': { 'style': 'data' } },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'B',
'a',
'z',
{ 'type': '/paragraph' },
{ 'type': '/tableCell' },
{ 'type': '/tableRow' },
{ 'type': '/tableSection' },
{ 'type': 'tableSection', 'attributes': { 'style': 'body' } },
{ 'type': 'tableRow' },
{ 'type': 'tableCell', 'attributes': { 'style': 'data' } },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'Q',
'u',
'u',
'x',
{ 'type': '/paragraph' },
{ 'type': '/tableCell' },
{ 'type': 'tableCell', 'attributes': { 'style': 'data' } },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'W',
'h',
'e',
'e',
{ 'type': '/paragraph' },
{ 'type': '/tableCell' },
{ 'type': '/tableRow' },
{ 'type': '/tableSection' },
{ 'type': '/table' }
];
Paragraph->heading conversion was broken when cursor next to an inline node In this case, selectNodes() returns the paragraph, which is not a content node, and so newFromContentBranchConversion() decides to do nothing at all. This change makes newFromContentBranchConversion() more intelligent about finding the content branch to operate on, fixing cases such as these where selectNodes() returns the content branch itself rather than one of its children. Bug: 41203 Change-Id: I710fbf184ef5ef84d9c2f5bca2b115e0660f5b8f
2013-04-26 23:49:43 +00:00
ve.dm.example.inlineAtEdges = [
{ 'type': 'paragraph' },
{ 'type': 'image', 'attributes': {
'html/0/src': ve.dm.example.imgSrc,
'src': ve.dm.example.imgSrc,
'width': null,
'height': null
} },
{ 'type': '/image' },
'F',
'o',
'o',
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
{ 'type': 'alienInline', 'attributes': { 'domElements': $( '<foobar />' ).get() } },
Paragraph->heading conversion was broken when cursor next to an inline node In this case, selectNodes() returns the paragraph, which is not a content node, and so newFromContentBranchConversion() decides to do nothing at all. This change makes newFromContentBranchConversion() more intelligent about finding the content branch to operate on, fixing cases such as these where selectNodes() returns the content branch itself rather than one of its children. Bug: 41203 Change-Id: I710fbf184ef5ef84d9c2f5bca2b115e0660f5b8f
2013-04-26 23:49:43 +00:00
{ 'type': '/alienInline' },
{ 'type': '/paragraph' }
];
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] ),
Test: Fix 404 errors in example images. Consistently refer to example.png for <img> tests. And "Wiki.png" for MediaWiki image tests. Change-Id: I799654b66bb586338e807a84bb84f7ec0b486728
2013-04-02 21:40:07 +00:00
// Preformatted with "h[example.png]i"
Added test data and fixed test suite links Change-Id: Idb5de70b58c525a67f16b21f7adc53214af9b486
2012-04-27 21:59:52 +00:00
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
Rename MWImageNode to MWInlineImageNode (get ready for adding MWBlockImageNode soon) Change-Id: I617e2a17cb6fbd11e486c2981e361ae931ac1870
2013-04-24 23:46:34 +00:00
ve.dm.example.MWInlineImageHtml = '<a rel="mw:Image" href="./File:Wiki.png" data-parsoid="{&quot;tsr&quot;:[158,216],&quot;src&quot;:&quot;[[Image:Wiki.png|500px|thumb|center|Example wiki file]]&quot;,&quot;optNames&quot;:{&quot;width&quot;:&quot;$1px&quot;},&quot;dsr&quot;:[158,216,null,null]}"><img height="" width="500" src="/index.php?title=Special:FilePath/Wiki.png&amp;width=500" alt="Wiki.png"></a>';
MWTemplateNode should serialise original HTML if unchanged To help the selective serialiser we can return the original HTML for generated content if it is unmodified. As the output of toDomElements now depends on changes to the dataElement we now have a 'modify' function in the some test cases. We also now have 'storeItems' to assert that the index-value store is correctly populated and for loading values back into the store for toDomElements tests. Also make 'mw' an attribute and remove 'about' property. Bug: 47394 Change-Id: I2bbb5d2d6a90c4eb87fa129671112c92a9b931e7
2013-04-20 16:08:23 +00:00
ve.dm.example.MWTemplate = {
'blockSpan': '<span about="#mwt1" typeof="mw:Object/Template" data-mw="{&quot;id&quot;:&quot;mwt1&quot;,&quot;target&quot;:{&quot;wt&quot;:&quot;Test&quot;},&quot;params&quot;:{&quot;1&quot;:{&quot;wt&quot;:&quot;Hello, world!&quot;}}}" data-parsoid="{&quot;tsr&quot;:[18,40],&quot;src&quot;:&quot;{{Test|Hello, world!}}&quot;,&quot;dsr&quot;:[18,40,null,null]}"></span>',
'blockSpanModified': '<span about="#mwt1" typeof="mw:Object/Template" data-mw="{&quot;id&quot;:&quot;mwt1&quot;,&quot;target&quot;:{&quot;wt&quot;:&quot;Test&quot;},&quot;params&quot;:{&quot;1&quot;:{&quot;wt&quot;:&quot;Hello, globe!&quot;}}}" data-parsoid="{&quot;tsr&quot;:[18,40],&quot;src&quot;:&quot;{{Test|Hello, world!}}&quot;,&quot;dsr&quot;:[18,40,null,null]}"></span>',
'blockContent': '<p about="#mwt1" data-parsoid="{}">Hello, world!</p>',
'blockData': {
'type': 'MWtemplateBlock',
'attributes': {
'mw': {
'id': 'mwt1',
'target': { 'wt' : 'Test' },
'params': {
'1': { 'wt': 'Hello, world!' }
}
},
'mwOriginal': {
'id': 'mwt1',
'target': { 'wt' : 'Test' },
'params': {
'1': { 'wt': 'Hello, world!' }
}
},
'html/0/about': '#mwt1',
'html/0/data-mw': '{\"id\":\"mwt1\",\"target\":{\"wt\":\"Test\"},\"params\":{\"1\":{\"wt\":\"Hello, world!\"}}}',
'html/0/data-parsoid': '{\"tsr\":[18,40],\"src\":\"{{Test|Hello, world!}}\",\"dsr\":[18,40,null,null]}',
'html/0/typeof': 'mw:Object/Template',
'html/1/about': '#mwt1',
'html/1/data-parsoid': '{}'
},
},
'inlineOpen': '<span about="#mwt1" typeof="mw:Object/Template" data-mw="{&quot;id&quot;:&quot;mwt1&quot;,&quot;target&quot;:{&quot;wt&quot;:&quot;Inline&quot;},&quot;params&quot;:{&quot;1&quot;:{&quot;wt&quot;:&quot;1,234&quot;}}}" data-parsoid="{&quot;tsr&quot;:[18,34],&quot;src&quot;:&quot;{{Inline|1,234}}&quot;,&quot;dsr&quot;:[18,34,null,null]}">',
'inlineOpenModified': '<span about="#mwt1" typeof="mw:Object/Template" data-mw="{&quot;id&quot;:&quot;mwt1&quot;,&quot;target&quot;:{&quot;wt&quot;:&quot;Inline&quot;},&quot;params&quot;:{&quot;1&quot;:{&quot;wt&quot;:&quot;5,678&quot;}}}" data-parsoid="{&quot;tsr&quot;:[18,34],&quot;src&quot;:&quot;{{Inline|1,234}}&quot;,&quot;dsr&quot;:[18,34,null,null]}">',
'inlineContent': '$1,234.00',
'inlineClose': '</span>',
'inlineData': {
'type': 'MWtemplateInline',
'attributes': {
'mw': {
'id': 'mwt1',
'target': { 'wt' : 'Inline' },
'params': {
'1': { 'wt': '1,234' }
}
},
'mwOriginal': {
'id': 'mwt1',
'target': { 'wt' : 'Inline' },
'params': {
'1': { 'wt': '1,234' }
}
},
'html/0/about': '#mwt1',
'html/0/data-mw': '{\"id\":\"mwt1\",\"target\":{\"wt\":\"Inline\"},\"params\":{\"1\":{\"wt\":\"1,234\"}}}',
'html/0/data-parsoid': '{\"tsr\":[18,34],\"src\":\"{{Inline|1,234}}\",\"dsr\":[18,34,null,null]}',
'html/0/typeof': 'mw:Object/Template'
},
Hack MWTemplate so it also does partial type matches For extension-specific types such as mw: , we require that all types be matched. But we want MWTemplateNode to match anything with an mw:Object/Template type, even if it also has other types (like mw:WikiLink/Category in our test case). Hack this into MWTemplate by matching on /^mw:/ then using a matchFunction to assert that mw:Object/Template is in the typeof attribute. Update the test case. Because it's now a template, there's a bunch of store stuff involved. Remove the other test case for about group forcing because it's now a duplicate of this one. Change-Id: Iacbe952a66d610c19b46bd76b84c50488857ac29
2013-05-03 23:34:01 +00:00
},
'mixed': '<link about="#mwt1" rel="mw:WikiLink/Category" typeof="mw:Object/Template" data-mw="{&quot;id&quot;:&quot;mwt1&quot;,&quot;target&quot;:{&quot;wt&quot;:&quot;Inline&quot;},&quot;params&quot;:{&quot;1&quot;:{&quot;wt&quot;:&quot;5,678&quot;}}}"><span about="#mwt1">Foo</span>',
'mixedDataOpen': {
'type': 'MWtemplateInline',
'attributes': {
'mw': {
'id': 'mwt1',
'target': { 'wt': 'Inline' },
'params': {
'1': { 'wt': '5,678' }
}
},
'mwOriginal': {
'id': 'mwt1',
'target': { 'wt': 'Inline' },
'params': {
'1': { 'wt': '5,678' }
}
},
'html/0/about': '#mwt1',
'html/0/rel': 'mw:WikiLink/Category',
'html/0/typeof': 'mw:Object/Template',
'html/0/data-mw': '{\"id\":\"mwt1\",\"target\":{\"wt\":\"Inline\"},\"params\":{\"1\":{\"wt\":\"5,678\"}}}',
'html/1/about': '#mwt1'
}
},
'mixedDataClose' : { 'type': '/MWtemplateInline' }
MWTemplateNode should serialise original HTML if unchanged To help the selective serialiser we can return the original HTML for generated content if it is unmodified. As the output of toDomElements now depends on changes to the dataElement we now have a 'modify' function in the some test cases. We also now have 'storeItems' to assert that the index-value store is correctly populated and for loading values back into the store for toDomElements tests. Also make 'mw' an attribute and remove 'about' property. Bug: 47394 Change-Id: I2bbb5d2d6a90c4eb87fa129671112c92a9b931e7
2013-04-20 16:08:23 +00:00
};
ve.dm.example.MWTemplate.blockParamsHash = ve.getHash( ve.dm.MWTemplateNode.static.getHashObject( ve.dm.example.MWTemplate.blockData ) );
ve.dm.example.MWTemplate.blockStoreItems = {
'hash': ve.dm.example.MWTemplate.blockParamsHash,
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'value': $( ve.dm.example.MWTemplate.blockSpan + ve.dm.example.MWTemplate.blockContent ).get()
MWTemplateNode should serialise original HTML if unchanged To help the selective serialiser we can return the original HTML for generated content if it is unmodified. As the output of toDomElements now depends on changes to the dataElement we now have a 'modify' function in the some test cases. We also now have 'storeItems' to assert that the index-value store is correctly populated and for loading values back into the store for toDomElements tests. Also make 'mw' an attribute and remove 'about' property. Bug: 47394 Change-Id: I2bbb5d2d6a90c4eb87fa129671112c92a9b931e7
2013-04-20 16:08:23 +00:00
};
ve.dm.example.MWTemplate.inlineParamsHash = ve.getHash( ve.dm.MWTemplateNode.static.getHashObject( ve.dm.example.MWTemplate.inlineData ) );
ve.dm.example.MWTemplate.inlineStoreItems = {
'hash': ve.dm.example.MWTemplate.inlineParamsHash,
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'value': $( ve.dm.example.MWTemplate.inlineOpen + ve.dm.example.MWTemplate.inlineContent + ve.dm.example.MWTemplate.inlineClose ).get()
MWTemplateNode should serialise original HTML if unchanged To help the selective serialiser we can return the original HTML for generated content if it is unmodified. As the output of toDomElements now depends on changes to the dataElement we now have a 'modify' function in the some test cases. We also now have 'storeItems' to assert that the index-value store is correctly populated and for loading values back into the store for toDomElements tests. Also make 'mw' an attribute and remove 'about' property. Bug: 47394 Change-Id: I2bbb5d2d6a90c4eb87fa129671112c92a9b931e7
2013-04-20 16:08:23 +00:00
};
Fix MWImageNode dimensions and implement toDomElements Using element.height was returning 0 if the attribute was empty when in fact what we mean to store is null (i.e. auto height). This takes care of the writing of attributes in CE as jQuery ignores an attribute-set command if the value is null. Also in this commit I've implemented a basic toDomElements that outputs the original HTML (code copied from AlienNode). This stops the code from throwing an exception but will eventually need to be rewritten to rebuild the HTML from the attributes stored in the DM. Bug: 56336 Change-Id: I297a1d0a07e9ebf9d0110fb1cdf266f8415f25b7
2013-03-29 11:57:42 +00:00
Hack MWTemplate so it also does partial type matches For extension-specific types such as mw: , we require that all types be matched. But we want MWTemplateNode to match anything with an mw:Object/Template type, even if it also has other types (like mw:WikiLink/Category in our test case). Hack this into MWTemplate by matching on /^mw:/ then using a matchFunction to assert that mw:Object/Template is in the typeof attribute. Update the test case. Because it's now a template, there's a bunch of store stuff involved. Remove the other test case for about group forcing because it's now a duplicate of this one. Change-Id: Iacbe952a66d610c19b46bd76b84c50488857ac29
2013-05-03 23:34:01 +00:00
ve.dm.example.MWTemplate.mixedParamsHash = ve.getHash( ve.dm.MWTemplateNode.static.getHashObject( ve.dm.example.MWTemplate.mixedDataOpen ) );
ve.dm.example.MWTemplate.mixedStoreItems = {
'hash': ve.dm.example.MWTemplate.mixedParamsHash,
'value': $( ve.dm.example.MWTemplate.mixed ).get()
};
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': {
Test: Fix 404 errors in example images. Consistently refer to example.png for <img> tests. And "Wiki.png" for MediaWiki image tests. Change-Id: I799654b66bb586338e807a84bb84f7ec0b486728
2013-04-02 21:40:07 +00:00
'html': '<body><img src="' + ve.dm.example.imgSrc + '"></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' } },
Image node refactor ve.ce.ImageNode.js * Moved in generic stuff from MWImageNode * Added drag end handler (empty, will be used soon) ve.ce.MWImageNode.js * Changed to inherit ImageNode * Moved generic stuff out ve.dm.ImageNode.js * Added attribute extraction/preservation for src, width and height ve.dm.MWImageNode.js * Changed to inherit ImageNode * Re-using ImageNode's attribute handling to extract/preserve attributes on both the image and wrapper level Change-Id: Ied4e1ece24e6804220eac35330790f7084df55de
2013-04-10 19:56:20 +00:00
{ 'type': 'image', 'attributes' : {
'html/0/src' : ve.dm.example.imgSrc,
'width': null,
'height': null,
'src': ve.dm.example.imgSrc
} },
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
]
},
Fix MWImageNode dimensions and implement toDomElements Using element.height was returning 0 if the attribute was empty when in fact what we mean to store is null (i.e. auto height). This takes care of the writing of attributes in CE as jQuery ignores an attribute-set command if the value is null. Also in this commit I've implemented a basic toDomElements that outputs the original HTML (code copied from AlienNode). This stops the code from throwing an exception but will eventually need to be rewritten to rebuild the HTML from the attributes stored in the DM. Bug: 56336 Change-Id: I297a1d0a07e9ebf9d0110fb1cdf266f8415f25b7
2013-03-29 11:57:42 +00:00
'mw:Image': {
Rename MWImageNode to MWInlineImageNode (get ready for adding MWBlockImageNode soon) Change-Id: I617e2a17cb6fbd11e486c2981e361ae931ac1870
2013-04-24 23:46:34 +00:00
'html': '<body><p>' + ve.dm.example.MWInlineImageHtml + '</p></body>',
Fix MWImageNode dimensions and implement toDomElements Using element.height was returning 0 if the attribute was empty when in fact what we mean to store is null (i.e. auto height). This takes care of the writing of attributes in CE as jQuery ignores an attribute-set command if the value is null. Also in this commit I've implemented a basic toDomElements that outputs the original HTML (code copied from AlienNode). This stops the code from throwing an exception but will eventually need to be rewritten to rebuild the HTML from the attributes stored in the DM. Bug: 56336 Change-Id: I297a1d0a07e9ebf9d0110fb1cdf266f8415f25b7
2013-03-29 11:57:42 +00:00
'data': [
{ 'type': 'paragraph' },
{
Rename MWImageNode to MWInlineImageNode (get ready for adding MWBlockImageNode soon) Change-Id: I617e2a17cb6fbd11e486c2981e361ae931ac1870
2013-04-24 23:46:34 +00:00
'type': 'MWinlineimage',
Fix MWImageNode dimensions and implement toDomElements Using element.height was returning 0 if the attribute was empty when in fact what we mean to store is null (i.e. auto height). This takes care of the writing of attributes in CE as jQuery ignores an attribute-set command if the value is null. Also in this commit I've implemented a basic toDomElements that outputs the original HTML (code copied from AlienNode). This stops the code from throwing an exception but will eventually need to be rewritten to rebuild the HTML from the attributes stored in the DM. Bug: 56336 Change-Id: I297a1d0a07e9ebf9d0110fb1cdf266f8415f25b7
2013-03-29 11:57:42 +00:00
'attributes': {
Image node refactor ve.ce.ImageNode.js * Moved in generic stuff from MWImageNode * Added drag end handler (empty, will be used soon) ve.ce.MWImageNode.js * Changed to inherit ImageNode * Moved generic stuff out ve.dm.ImageNode.js * Added attribute extraction/preservation for src, width and height ve.dm.MWImageNode.js * Changed to inherit ImageNode * Re-using ImageNode's attribute handling to extract/preserve attributes on both the image and wrapper level Change-Id: Ied4e1ece24e6804220eac35330790f7084df55de
2013-04-10 19:56:20 +00:00
'html/0-0/alt': 'Wiki.png',
'html/0-0/height': '',
'html/0-0/src': '/index.php?title=Special:FilePath/Wiki.png&width=500',
'html/0-0/width': '500',
'html/0/data-parsoid': '{"tsr":[158,216],"src":"[[Image:Wiki.png|500px|thumb|center|Example wiki file]]","optNames":{"width":"$1px"},"dsr":[158,216,null,null]}',
'html/0/href': './File:Wiki.png',
'html/0/rel': 'mw:Image',
Test: Fix 404 errors in example images. Consistently refer to example.png for <img> tests. And "Wiki.png" for MediaWiki image tests. Change-Id: I799654b66bb586338e807a84bb84f7ec0b486728
2013-04-02 21:40:07 +00:00
'src': '/index.php?title=Special:FilePath/Wiki.png&width=500',
Fix MWImageNode dimensions and implement toDomElements Using element.height was returning 0 if the attribute was empty when in fact what we mean to store is null (i.e. auto height). This takes care of the writing of attributes in CE as jQuery ignores an attribute-set command if the value is null. Also in this commit I've implemented a basic toDomElements that outputs the original HTML (code copied from AlienNode). This stops the code from throwing an exception but will eventually need to be rewritten to rebuild the HTML from the attributes stored in the DM. Bug: 56336 Change-Id: I297a1d0a07e9ebf9d0110fb1cdf266f8415f25b7
2013-03-29 11:57:42 +00:00
'width': 500,
'height': null,
Image node refactor ve.ce.ImageNode.js * Moved in generic stuff from MWImageNode * Added drag end handler (empty, will be used soon) ve.ce.MWImageNode.js * Changed to inherit ImageNode * Moved generic stuff out ve.dm.ImageNode.js * Added attribute extraction/preservation for src, width and height ve.dm.MWImageNode.js * Changed to inherit ImageNode * Re-using ImageNode's attribute handling to extract/preserve attributes on both the image and wrapper level Change-Id: Ied4e1ece24e6804220eac35330790f7084df55de
2013-04-10 19:56:20 +00:00
'isLinked': true
Fix MWImageNode dimensions and implement toDomElements Using element.height was returning 0 if the attribute was empty when in fact what we mean to store is null (i.e. auto height). This takes care of the writing of attributes in CE as jQuery ignores an attribute-set command if the value is null. Also in this commit I've implemented a basic toDomElements that outputs the original HTML (code copied from AlienNode). This stops the code from throwing an exception but will eventually need to be rewritten to rebuild the HTML from the attributes stored in the DM. Bug: 56336 Change-Id: I297a1d0a07e9ebf9d0110fb1cdf266f8415f25b7
2013-03-29 11:57:42 +00:00
}
},
Rename MWImageNode to MWInlineImageNode (get ready for adding MWBlockImageNode soon) Change-Id: I617e2a17cb6fbd11e486c2981e361ae931ac1870
2013-04-24 23:46:34 +00:00
{ 'type': '/MWinlineimage' },
Fix MWImageNode dimensions and implement toDomElements Using element.height was returning 0 if the attribute was empty when in fact what we mean to store is null (i.e. auto height). This takes care of the writing of attributes in CE as jQuery ignores an attribute-set command if the value is null. Also in this commit I've implemented a basic toDomElements that outputs the original HTML (code copied from AlienNode). This stops the code from throwing an exception but will eventually need to be rewritten to rebuild the HTML from the attributes stored in the DM. Bug: 56336 Change-Id: I297a1d0a07e9ebf9d0110fb1cdf266f8415f25b7
2013-03-29 11:57:42 +00:00
{ 'type': '/paragraph' }
]
},
Hybridise MWTemplateNode * Create MWTemplateBlockNode & MWTemplateInlineNode (in ce and dm) * Move Alien's 'isInline' code to ve.dm.Node.static.isHybridInline * Move definition of ce.AlienBlock/InlineNode inside ce.Aline.js file to match dm.AlienBlock/InlineNode and MWTemplate * Duplicate AlienBlock/Inline styles for templates * Create test case for inline templates * Count test cases in ve.dm.Converter.test.js automatically Change-Id: Id9bc7f049ea974dd5e7f8b7a66080939e0948bbd
2013-04-13 21:22:26 +00:00
'mw:Template (block level)': {
MWTemplateNode should serialise original HTML if unchanged To help the selective serialiser we can return the original HTML for generated content if it is unmodified. As the output of toDomElements now depends on changes to the dataElement we now have a 'modify' function in the some test cases. We also now have 'storeItems' to assert that the index-value store is correctly populated and for loading values back into the store for toDomElements tests. Also make 'mw' an attribute and remove 'about' property. Bug: 47394 Change-Id: I2bbb5d2d6a90c4eb87fa129671112c92a9b931e7
2013-04-20 16:08:23 +00:00
'html': '<body>' + ve.dm.example.MWTemplate.blockSpan + ve.dm.example.MWTemplate.blockContent + '</body>',
Create MWTemplateNode This node stores the rendered in the index-value store, hashed on a custom hash of the dm (type + mw) which makes it unique it its parameters. Bug: 46571 Change-Id: I0ab4c9f7bca207121d5b42e83c821771b6139da8
2013-04-10 18:15:15 +00:00
'data': [
MWTemplateNode should serialise original HTML if unchanged To help the selective serialiser we can return the original HTML for generated content if it is unmodified. As the output of toDomElements now depends on changes to the dataElement we now have a 'modify' function in the some test cases. We also now have 'storeItems' to assert that the index-value store is correctly populated and for loading values back into the store for toDomElements tests. Also make 'mw' an attribute and remove 'about' property. Bug: 47394 Change-Id: I2bbb5d2d6a90c4eb87fa129671112c92a9b931e7
2013-04-20 16:08:23 +00:00
ve.dm.example.MWTemplate.blockData,
{ 'type': '/MWtemplateBlock' },
],
'storeItems': [
ve.dm.example.MWTemplate.blockStoreItems
],
'normalizedHtml': ve.dm.example.MWTemplate.blockSpan + ve.dm.example.MWTemplate.blockContent
},
'mw:Template (block level - modified)': {
'html': '<body>' + ve.dm.example.MWTemplate.blockSpan + ve.dm.example.MWTemplate.blockContent + '</body>',
'data': [
ve.dm.example.MWTemplate.blockData,
Hybridise MWTemplateNode * Create MWTemplateBlockNode & MWTemplateInlineNode (in ce and dm) * Move Alien's 'isInline' code to ve.dm.Node.static.isHybridInline * Move definition of ce.AlienBlock/InlineNode inside ce.Aline.js file to match dm.AlienBlock/InlineNode and MWTemplate * Duplicate AlienBlock/Inline styles for templates * Create test case for inline templates * Count test cases in ve.dm.Converter.test.js automatically Change-Id: Id9bc7f049ea974dd5e7f8b7a66080939e0948bbd
2013-04-13 21:22:26 +00:00
{ 'type': '/MWtemplateBlock' },
Create MWTemplateNode This node stores the rendered in the index-value store, hashed on a custom hash of the dm (type + mw) which makes it unique it its parameters. Bug: 46571 Change-Id: I0ab4c9f7bca207121d5b42e83c821771b6139da8
2013-04-10 18:15:15 +00:00
],
MWTemplateNode should serialise original HTML if unchanged To help the selective serialiser we can return the original HTML for generated content if it is unmodified. As the output of toDomElements now depends on changes to the dataElement we now have a 'modify' function in the some test cases. We also now have 'storeItems' to assert that the index-value store is correctly populated and for loading values back into the store for toDomElements tests. Also make 'mw' an attribute and remove 'about' property. Bug: 47394 Change-Id: I2bbb5d2d6a90c4eb87fa129671112c92a9b931e7
2013-04-20 16:08:23 +00:00
'storeItems': [
ve.dm.example.MWTemplate.blockStoreItems
],
Code style fixes * "function(" -> "function (" * "{String}" -> "{string}" * collapse unintentional double spaces Change-Id: I3ce3f02d1e31d4797b44e04d28457dec363be296
2013-05-06 11:34:32 +00:00
'modify': function ( data ) {
MWTemplateNode should serialise original HTML if unchanged To help the selective serialiser we can return the original HTML for generated content if it is unmodified. As the output of toDomElements now depends on changes to the dataElement we now have a 'modify' function in the some test cases. We also now have 'storeItems' to assert that the index-value store is correctly populated and for loading values back into the store for toDomElements tests. Also make 'mw' an attribute and remove 'about' property. Bug: 47394 Change-Id: I2bbb5d2d6a90c4eb87fa129671112c92a9b931e7
2013-04-20 16:08:23 +00:00
data[0].attributes.mw.params['1'].wt = 'Hello, globe!';
},
'normalizedHtml': ve.dm.example.MWTemplate.blockSpanModified
Hybridise MWTemplateNode * Create MWTemplateBlockNode & MWTemplateInlineNode (in ce and dm) * Move Alien's 'isInline' code to ve.dm.Node.static.isHybridInline * Move definition of ce.AlienBlock/InlineNode inside ce.Aline.js file to match dm.AlienBlock/InlineNode and MWTemplate * Duplicate AlienBlock/Inline styles for templates * Create test case for inline templates * Count test cases in ve.dm.Converter.test.js automatically Change-Id: Id9bc7f049ea974dd5e7f8b7a66080939e0948bbd
2013-04-13 21:22:26 +00:00
},
'mw:Template (inline)': {
MWTemplateNode should serialise original HTML if unchanged To help the selective serialiser we can return the original HTML for generated content if it is unmodified. As the output of toDomElements now depends on changes to the dataElement we now have a 'modify' function in the some test cases. We also now have 'storeItems' to assert that the index-value store is correctly populated and for loading values back into the store for toDomElements tests. Also make 'mw' an attribute and remove 'about' property. Bug: 47394 Change-Id: I2bbb5d2d6a90c4eb87fa129671112c92a9b931e7
2013-04-20 16:08:23 +00:00
'html': '<body>' + ve.dm.example.MWTemplate.inlineOpen + ve.dm.example.MWTemplate.inlineContent + ve.dm.example.MWTemplate.inlineClose + '</body>',
Hybridise MWTemplateNode * Create MWTemplateBlockNode & MWTemplateInlineNode (in ce and dm) * Move Alien's 'isInline' code to ve.dm.Node.static.isHybridInline * Move definition of ce.AlienBlock/InlineNode inside ce.Aline.js file to match dm.AlienBlock/InlineNode and MWTemplate * Duplicate AlienBlock/Inline styles for templates * Create test case for inline templates * Count test cases in ve.dm.Converter.test.js automatically Change-Id: Id9bc7f049ea974dd5e7f8b7a66080939e0948bbd
2013-04-13 21:22:26 +00:00
'data': [
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
MWTemplateNode should serialise original HTML if unchanged To help the selective serialiser we can return the original HTML for generated content if it is unmodified. As the output of toDomElements now depends on changes to the dataElement we now have a 'modify' function in the some test cases. We also now have 'storeItems' to assert that the index-value store is correctly populated and for loading values back into the store for toDomElements tests. Also make 'mw' an attribute and remove 'about' property. Bug: 47394 Change-Id: I2bbb5d2d6a90c4eb87fa129671112c92a9b931e7
2013-04-20 16:08:23 +00:00
ve.dm.example.MWTemplate.inlineData,
{ 'type': '/MWtemplateInline' },
{ 'type': '/paragraph' }
],
'storeItems': [
ve.dm.example.MWTemplate.inlineStoreItems
],
'normalizedHtml': ve.dm.example.MWTemplate.inlineOpen + ve.dm.example.MWTemplate.inlineContent + ve.dm.example.MWTemplate.inlineClose
},
'mw:Template (inline - modified)': {
'html': '<body>' + ve.dm.example.MWTemplate.inlineOpen + ve.dm.example.MWTemplate.inlineContent + ve.dm.example.MWTemplate.inlineClose + '</body>',
'data': [
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
ve.dm.example.MWTemplate.inlineData,
Hybridise MWTemplateNode * Create MWTemplateBlockNode & MWTemplateInlineNode (in ce and dm) * Move Alien's 'isInline' code to ve.dm.Node.static.isHybridInline * Move definition of ce.AlienBlock/InlineNode inside ce.Aline.js file to match dm.AlienBlock/InlineNode and MWTemplate * Duplicate AlienBlock/Inline styles for templates * Create test case for inline templates * Count test cases in ve.dm.Converter.test.js automatically Change-Id: Id9bc7f049ea974dd5e7f8b7a66080939e0948bbd
2013-04-13 21:22:26 +00:00
{ 'type': '/MWtemplateInline' },
{ 'type': '/paragraph' }
],
MWTemplateNode should serialise original HTML if unchanged To help the selective serialiser we can return the original HTML for generated content if it is unmodified. As the output of toDomElements now depends on changes to the dataElement we now have a 'modify' function in the some test cases. We also now have 'storeItems' to assert that the index-value store is correctly populated and for loading values back into the store for toDomElements tests. Also make 'mw' an attribute and remove 'about' property. Bug: 47394 Change-Id: I2bbb5d2d6a90c4eb87fa129671112c92a9b931e7
2013-04-20 16:08:23 +00:00
'storeItems': [
ve.dm.example.MWTemplate.inlineStoreItems
],
Code style fixes * "function(" -> "function (" * "{String}" -> "{string}" * collapse unintentional double spaces Change-Id: I3ce3f02d1e31d4797b44e04d28457dec363be296
2013-05-06 11:34:32 +00:00
'modify': function ( data ) {
MWTemplateNode should serialise original HTML if unchanged To help the selective serialiser we can return the original HTML for generated content if it is unmodified. As the output of toDomElements now depends on changes to the dataElement we now have a 'modify' function in the some test cases. We also now have 'storeItems' to assert that the index-value store is correctly populated and for loading values back into the store for toDomElements tests. Also make 'mw' an attribute and remove 'about' property. Bug: 47394 Change-Id: I2bbb5d2d6a90c4eb87fa129671112c92a9b931e7
2013-04-20 16:08:23 +00:00
data[1].attributes.mw.params['1'].wt = '5,678';
},
'normalizedHtml': ve.dm.example.MWTemplate.inlineOpenModified + ve.dm.example.MWTemplate.inlineClose
Create MWTemplateNode This node stores the rendered in the index-value store, hashed on a custom hash of the dm (type + mw) which makes it unique it its parameters. Bug: 46571 Change-Id: I0ab4c9f7bca207121d5b42e83c821771b6139da8
2013-04-10 18:15:15 +00:00
},
Add data model support for MediaWiki references So far just read-only. Bug: 39599 Change-Id: I6daff5c5969e5fdc871f8f346cf790b4302ae080
2013-04-17 17:53:26 +00:00
'mw:Reference': {
'html':
'<body>' +
'<p>Foo' +
'<span id="cite_ref-bar-1-0" class="reference" about="#mwt5" typeof="mw:Object/Ext/Ref" ' +
'data-parsoid="{&quot;src&quot:&quot;<ref name=\\&quot;bar\\&quot;>Bar</ref>&quot;}">'+
'<a href="#cite_note-bar-1" data-parsoid="{}">[1]</a>' +
'</span>' +
' Baz' +
'<span id="cite_ref-quux-2-0" class="reference" about="#mwt6" typeof="mw:Object/Ext/Ref" ' +
'data-parsoid="{&quot;src&quot;:&quot;<ref name=\\&quot;quux\\&quot;>Quux</ref>&quot;}">' +
'<a href="#cite_note-quux-2" data-parsoid="{}">[2]</a>' +
'</span>' +
' Whee' +
'<span id="cite_ref-bar-1-1" class="reference" about="#mwt7" typeof="mw:Object/Ext/Ref" ' +
'data-parsoid="{&quot;src&quot;:&quot;<ref name=\\&quot;bar\\&quot; />&quot;}">' +
'<a href="#cite_note-bar-1" data-parsoid="{}">[1]</a>' +
'</span>' +
' Yay' +
'<span id="cite_ref-3-0" class="reference" about="#mwt8" typeof="mw:Object/Ext/Ref" ' +
'data-parsoid="{&quot;src&quot;:&quot;<ref>No name</ref>&quot;}">' +
'<a href="#cite_note-3" data-parsoid="{}">[3]</a>' +
'</span>' +
'</p>' +
'<ol class="references" typeof="mw:Object/References">' +
'<li li="cite_note-quux-2"><a href="#cite_ref-quux-2-0">u2191</a>Quux</li>' +
'</ol>' +
'</body>',
'data': [
{ 'type': 'paragraph' },
'F', 'o', 'o',
{
'type': 'MWreference',
'attributes': {
'about': '#mwt5',
'listIndex': 0,
'mw': {},
'html/0/about': '#mwt5',
'html/0/class': 'reference',
'html/0/data-parsoid': '{"src":"<ref name=\\"bar\\">Bar</ref>"}',
'html/0/id': 'cite_ref-bar-1-0',
'html/0/typeof': 'mw:Object/Ext/Ref'
}
},
{ 'type': '/MWreference' },
' ', 'B', 'a', 'z',
{
'type': 'MWreference',
'attributes': {
'about': '#mwt6',
'listIndex': 1,
'mw': {},
'html/0/about': '#mwt6',
'html/0/class': 'reference',
'html/0/data-parsoid': '{"src":"<ref name=\\"quux\\">Quux</ref>"}',
'html/0/id': 'cite_ref-quux-2-0',
'html/0/typeof': 'mw:Object/Ext/Ref'
}
},
{ 'type': '/MWreference' },
' ', 'W', 'h', 'e', 'e',
{
'type': 'MWreference',
'attributes': {
'about': '#mwt7',
'listIndex': 0,
'mw': {},
'html/0/about': '#mwt7',
'html/0/class': 'reference',
'html/0/data-parsoid': '{"src":"<ref name=\\"bar\\" />"}',
'html/0/id': 'cite_ref-bar-1-1',
'html/0/typeof': 'mw:Object/Ext/Ref'
}
},
{ 'type': '/MWreference' },
' ', 'Y', 'a', 'y',
{
'type': 'MWreference',
'attributes': {
'about': '#mwt8',
'listIndex': 2,
'mw': {},
'html/0/about': '#mwt8',
'html/0/class': 'reference',
'html/0/data-parsoid': '{"src":"<ref>No name</ref>"}',
'html/0/id': 'cite_ref-3-0',
'html/0/typeof': 'mw:Object/Ext/Ref'
}
},
{ 'type': '/MWreference' },
{ 'type': '/paragraph' },
{
'type': 'MWreferenceList',
'attributes': {
'html': '<ol class="references" typeof="mw:Object/References"><li li="cite_note-quux-2"><a href="#cite_ref-quux-2-0">u2191</a>Quux</li></ol>',
'html/0/class': 'references',
'html/0/typeof': 'mw:Object/References'
}
},
{ 'type': '/MWreferenceList' },
{ 'type': 'internalList' },
{ 'type': 'internalItem' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'B', 'a', 'r',
{ 'type': '/paragraph' },
{ 'type': '/internalItem' },
{ 'type': 'internalItem' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'Q', 'u', 'u', 'x',
{ 'type': '/paragraph' },
{ 'type': '/internalItem' },
{ 'type': 'internalItem' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'N', 'o', ' ', 'n', 'a', 'm', 'e',
{ 'type': '/paragraph' },
{ 'type': '/internalItem' },
{ 'type': '/internalList' }
],
'normalizedHtml':
'<p>Foo' +
'<span id="cite_ref-bar-1-0" class="reference" about="#mwt5" typeof="mw:Object/Ext/Ref" ' +
'data-parsoid="{&quot;src&quot:&quot;<ref name=\\&quot;bar\\&quot;>Bar</ref>&quot;}">'+
'</span>' +
' Baz' +
'<span id="cite_ref-quux-2-0" class="reference" about="#mwt6" typeof="mw:Object/Ext/Ref" ' +
'data-parsoid="{&quot;src&quot;:&quot;<ref name=\\&quot;quux\\&quot;>Quux</ref>&quot;}">' +
'</span>' +
' Whee' +
'<span id="cite_ref-bar-1-1" class="reference" about="#mwt7" typeof="mw:Object/Ext/Ref" ' +
'data-parsoid="{&quot;src&quot;:&quot;<ref name=\\&quot;bar\\&quot; />&quot;}">' +
'</span>' +
' Yay' +
'<span id="cite_ref-3-0" class="reference" about="#mwt8" typeof="mw:Object/Ext/Ref" ' +
'data-parsoid="{&quot;src&quot;:&quot;<ref>No name</ref>&quot;}">' +
'</span>' +
'</p>' +
'<ol class="references" typeof="mw:Object/References"></ol>'
},
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',
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'attributes': { 'domElements': $( '<tt class="foo">b</tt>' ).get() }
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' },
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
{ 'type': 'alienBlock', 'attributes': { 'domElements': $( '<figure>abc</figure>' ).get() } },
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',
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'attributes': { 'domElements': $( '<tt class="foo">b</tt>' ).get() },
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 ]
},
{ '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': {
Test: Fix 404 errors in example images. Consistently refer to example.png for <img> tests. And "Wiki.png" for MediaWiki image tests. Change-Id: I799654b66bb586338e807a84bb84f7ec0b486728
2013-04-02 21:40:07 +00:00
'html': '<body><img src="' + ve.dm.example.imgSrc + '">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' } },
Image node refactor ve.ce.ImageNode.js * Moved in generic stuff from MWImageNode * Added drag end handler (empty, will be used soon) ve.ce.MWImageNode.js * Changed to inherit ImageNode * Moved generic stuff out ve.dm.ImageNode.js * Added attribute extraction/preservation for src, width and height ve.dm.MWImageNode.js * Changed to inherit ImageNode * Re-using ImageNode's attribute handling to extract/preserve attributes on both the image and wrapper level Change-Id: Ied4e1ece24e6804220eac35330790f7084df55de
2013-04-10 19:56:20 +00:00
{ 'type': 'image', 'attributes': {
'html/0/src': ve.dm.example.imgSrc,
'src': ve.dm.example.imgSrc,
'width': null,
'height': null
} },
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',
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'attributes': { 'domElements': $( '<tt class="bar">baz</tt>' ).get() }
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
},
{ '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',
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'attributes': { 'domElements': $( '<figure class="bar">baz</figure>' ).get() }
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
},
{ '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',
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'attributes': { 'domElements': $( '<span typeof="mw:Placeholder">baz</span>' ).get() }
(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
},
{ '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',
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'attributes': { 'domElements': $( '<div typeof="mw:Placeholder">baz</div>' ).get() }
(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
},
{ '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',
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'attributes': { 'domElements': $( '<span typeof="mw:Placeholder">Foo</span>' ).get() }
(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' },
'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',
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'attributes': { 'domElements': $( '<span typeof="mw:Placeholder">Bar</span>' ).get() }
(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' }
]
},
(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',
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'attributes': { 'domElements': $( '<tt about="#mwt1">foo</tt><tt about="#mwt1">bar</tt>' ).get() }
(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
},
(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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'attributes': {
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
'title': 'Foo bar',
Fix tests for fda2e6c1b54a0139a3123de413f672e895ff3352 Change-Id: I2725f3f775e092bafe7aa9dca71d2a9022f16db8
2012-11-23 18:56:00 +00:00
'origTitle': 'Foo_bar',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'hrefPrefix': '',
'html/0/data-rt': '{"sHref":"foo bar"}',
'html/0/href': 'Foo_bar',
'html/0/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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'attributes': {
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
'title': 'Foo bar',
Fix tests for fda2e6c1b54a0139a3123de413f672e895ff3352 Change-Id: I2725f3f775e092bafe7aa9dca71d2a9022f16db8
2012-11-23 18:56:00 +00:00
'origTitle': 'Foo_bar',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'hrefPrefix': '',
'html/0/data-rt': '{"sHref":"foo bar"}',
'html/0/href': 'Foo_bar',
'html/0/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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'attributes': {
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
'title': 'Foo bar',
Fix tests for fda2e6c1b54a0139a3123de413f672e895ff3352 Change-Id: I2725f3f775e092bafe7aa9dca71d2a9022f16db8
2012-11-23 18:56:00 +00:00
'origTitle': 'Foo_bar',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'hrefPrefix': '',
'html/0/data-rt': '{"sHref":"foo bar"}',
'html/0/href': 'Foo_bar',
'html/0/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>',
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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'attributes': {
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
'title': 'Foo/Bar',
Fix tests for fda2e6c1b54a0139a3123de413f672e895ff3352 Change-Id: I2725f3f775e092bafe7aa9dca71d2a9022f16db8
2012-11-23 18:56:00 +00:00
'origTitle': 'Foo/Bar',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'hrefPrefix': './../../../',
'html/0/href': './../../../Foo/Bar',
'html/0/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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'attributes': {
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
'title': 'Foo/Bar',
Fix tests for fda2e6c1b54a0139a3123de413f672e895ff3352 Change-Id: I2725f3f775e092bafe7aa9dca71d2a9022f16db8
2012-11-23 18:56:00 +00:00
'origTitle': 'Foo/Bar',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'hrefPrefix': './../../../',
'html/0/href': './../../../Foo/Bar',
'html/0/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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'attributes': {
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
'title': 'Foo/Bar',
Fix tests for fda2e6c1b54a0139a3123de413f672e895ff3352 Change-Id: I2725f3f775e092bafe7aa9dca71d2a9022f16db8
2012-11-23 18:56:00 +00:00
'origTitle': 'Foo/Bar',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'hrefPrefix': './../../../',
'html/0/href': './../../../Foo/Bar',
'html/0/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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'attributes': {
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'href': 'http://www.mediawiki.org/',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'rel': 'mw:ExtLink/Numbered',
'html/0/href': 'http://www.mediawiki.org/',
'html/0/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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'attributes': {
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'href': 'http://www.mediawiki.org/',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'rel': 'mw:ExtLink/Numbered',
'html/0/href': 'http://www.mediawiki.org/',
'html/0/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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'attributes': {
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'href': 'http://www.mediawiki.org/',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'rel': 'mw:ExtLink/Numbered',
'html/0/href': 'http://www.mediawiki.org/',
'html/0/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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'attributes': {
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'href': 'http://www.mediawiki.org/',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'rel': 'mw:ExtLink/URL',
'html/0/href': 'http://www.mediawiki.org/',
'html/0/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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'attributes': {
New annotation API: update tests Change-Id: I301a1d89c33dd68197d629d187a9a5be8cbf3852
2012-10-06 00:34:12 +00:00
'href': 'http://www.mediawiki.org/',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'rel': 'mw:ExtLink/URL',
'html/0/href': 'http://www.mediawiki.org/',
'html/0/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': {
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'domElements': $( '<p typeof="mw:Placeholder"> <br> </p>' ).get()
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
},
'internal': {
'whitespace': [ ' ', undefined, undefined, ' ' ]
}
},
{ 'type': '/alienBlock' },
{ 'type': 'paragraph', 'internal': { 'whitespace': [ ' ', '\t', ' \n', '\t\n' ] } },
'F',
'o',
'o',
'\t',
'\t',
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
{ 'type': 'alienInline', 'attributes': { 'domElements': $( '<tt>\t\t\tBar\t\t\t\t</tt>' ).get() } },
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
{ 'type': '/alienInline' },
'\n',
'B',
'a',
'z',
'\n',
'\n',
{
'type': 'alienInline',
'attributes': {
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'domElements': $( '<span typeof="mw:Placeholder">\n\n\nQuux\n\n\n\n</span>' ).get()
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
}
},
{ 'type': '/alienInline' },
' ',
'\t',
'W',
'h',
'e',
'e',
{ 'type': '/paragraph' },
{
'type': 'alienBlock',
'attributes': {
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'domElements': $( '<figure>\n\tYay \t </figure>' ).get()
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
},
'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' }
Factor the <pre> newline hack out of the converter into ve.properInnerHTML() Also add detection for whether the browser is actually broken (most are, but some, like Opera, aren't), treat <textarea> and <listing> in addition to <pre>, and fix a bug where the function would crash if the <pre> was empty (because .firstChild was undefined/null). Change-Id: I541b57e9fd5c9c42d19d0a59f6e29fb43d35c9b6
2013-04-18 01:46:50 +00:00
]
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
},
Fix a weird whitespace stripping bug In HTML like <td>Foo <b>Bar</b></td>, the space would be stripped and registered as trailing whitespace in the <td>, so it wouldn't be visible in the editor and would be inserted after the </b> on the way out. Thanks to Subbu for reporting this. This case was kind of ridiculous and we're lucky the JRuby article contained it. To trigger the bug, you had to have: * a table cell * containing unwrapped content * consisting of ** some text ** whitespace ** open annotation (bold in my example, link in Subbu's case) ** text ** close annotation ** and nothing else Change-Id: I2b83f02764b311a32a50956d4c8930a9394e91a4
2013-04-18 00:08:47 +00:00
'whitespace preservation in table cell starting with text and ending with annotation': {
'html': '<body><table><tbody><tr><td>Foo <b>Bar</b></td></tr></tbody></table></body>',
'data': [
{ 'type': 'table' },
{ 'type': 'tableSection', 'attributes': { 'style': 'body' } },
{ 'type': 'tableRow' },
{ 'type': 'tableCell', 'attributes': { 'style': 'data' } },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'F',
'o',
'o',
' ',
[ 'B', [ ve.dm.example.bold ] ],
[ 'a', [ ve.dm.example.bold ] ],
[ 'r', [ ve.dm.example.bold ] ],
{ 'type': '/paragraph' },
{ 'type': '/tableCell' },
{ 'type': '/tableRow' },
{ 'type': '/tableSection' },
{ 'type': '/table' }
]
},
Fix whitespace preservation around meta items This was broken, especially in wrappers. Changed the wrapping algorithm so that meta items are placed outside wrappers if possible. On the left-hand side, this is already the case: we don't open wrappers for meta items. On the right-hand side, this is accomplished by buffering the meta items and only inserting them when we encounter either real text (not whitespace) or the end of the wrapper. If we're interrupted by real text, we insert the meta items with the unmodified whitespace. If we're interrupted by the end of the wrapper, we insert the meta items outside of the wrapper with whitespace stripped. Internally, this is done by stripping the whitespace into the whitespace[0] of the meta item to its right. Then when we output the meta items, we either decide to 'restore' the whitespace, or to 'fixup' by also setting whitespace[3] on the element before the whitespace. Change-Id: Ibeea2a9906c4aae9fe6d284613edd6ec853ca5e7
2013-04-18 23:06:58 +00:00
'whitespace preservation with wrapped text, comments and language links': {
'html': '<body><!-- Foo --> <!-- Bar -->\nFoo\n' +
'<link rel="mw:WikiLink/Language" href="http://de.wikipedia.org/wiki/Foo">\n' +
'<link rel="mw:WikiLink/Language" href="http://fr.wikipedia.org/wiki/Foo"></body>',
'data': [
{
'type': 'alienMeta',
'internal': { 'whitespace': [ undefined, undefined, undefined, ' ' ] },
'attributes': {
'style': 'comment',
'text': ' Foo '
}
},
{ 'type': '/alienMeta' },
{
'type': 'alienMeta',
'internal': { 'whitespace': [ ' ', undefined, undefined, '\n' ] },
'attributes': {
'style': 'comment',
'text': ' Bar '
}
},
{ 'type': '/alienMeta' },
{
'type': 'paragraph',
'internal': {
'generated': 'wrapper',
'whitespace': [ '\n', undefined, undefined, '\n' ]
}
},
'F',
'o',
'o',
{ 'type': '/paragraph' },
{
'type': 'MWlanguage',
'attributes': {
'href': 'http://de.wikipedia.org/wiki/Foo',
'html/0/href': 'http://de.wikipedia.org/wiki/Foo',
'html/0/rel': 'mw:WikiLink/Language'
},
'internal': { 'whitespace': [ '\n', undefined, undefined, '\n' ] }
},
{ 'type': '/MWlanguage' },
{
'type': 'MWlanguage',
'attributes': {
'href': 'http://fr.wikipedia.org/wiki/Foo',
'html/0/href': 'http://fr.wikipedia.org/wiki/Foo',
'html/0/rel': 'mw:WikiLink/Language'
},
'internal': { 'whitespace': [ '\n' ] }
},
{ 'type': '/MWlanguage' }
]
},
Fix placement of whitespace when element ends in meta This was broken for both normal elements, where the meta item is inside the element, and wrapper paragraphs, where the meta item gets moved outside the wrapper. Bug: 47712 Change-Id: I42daaf142e548e5b221ff0a52df0ad24ec6a4fd0
2013-05-01 23:00:33 +00:00
'whitespace preservation with comments at end of wrapper paragraph': {
'html': '<body><ul><li> bar<!-- baz -->quux </li></ul></body>',
'data': [
{ 'type': 'list', 'attributes': { 'style': 'bullet' } },
{
'type': 'listItem',
'internal': {
'whitespace': [
undefined,
' ',
' '
]
}
},
{
'type': 'paragraph',
'internal': {
'generated': 'wrapper',
'whitespace': [
' ',
undefined,
undefined,
' '
]
}
},
'b', 'a', 'r',
{
'type': 'alienMeta',
'attributes': {
'style': 'comment',
'text': ' baz '
}
},
{ 'type': '/alienMeta' },
'q', 'u', 'u', 'x',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': '/list' }
]
},
'whitespace preservation with comment at end of wrapper paragraph': {
'html': '<body><ul><li> bar<!-- baz --> </li></ul></body>',
'data': [
{ 'type': 'list', 'attributes': { 'style': 'bullet' } },
{
'type': 'listItem',
'internal': {
'whitespace': [
undefined,
' ',
' '
]
}
},
{
'type': 'paragraph',
'internal': {
'generated': 'wrapper',
'whitespace': [
' '
]
}
},
'b', 'a', 'r',
{ 'type': '/paragraph' },
{
'type': 'alienMeta',
'attributes': {
'style': 'comment',
'text': ' baz '
},
'internal': {
'whitespace': [
undefined,
undefined,
undefined,
' '
]
}
},
{ 'type': '/alienMeta' },
{ 'type': '/listItem' },
{ 'type': '/list' }
]
},
'whitespace preservation with multiple comments at end of wrapper paragraph': {
'html': '<body><ul><li> foo <!-- bar --> <!-- baz --> </li></ul></body>',
'data': [
{ 'type': 'list', 'attributes': { 'style': 'bullet' } },
{
'type': 'listItem',
'internal': {
'whitespace': [
undefined,
' ',
' '
]
}
},
{
'type': 'paragraph',
'internal': {
'generated': 'wrapper',
'whitespace': [
' ',
undefined,
undefined,
' '
]
}
},
'f', 'o', 'o',
{ 'type': '/paragraph' },
{
'type': 'alienMeta',
'attributes': {
'style': 'comment',
'text': ' bar '
},
'internal': {
'whitespace': [
' ',
undefined,
undefined,
' '
]
}
},
{ 'type': '/alienMeta' },
{
'type': 'alienMeta',
'attributes': {
'style': 'comment',
'text': ' baz '
},
'internal': {
'whitespace': [
' ',
undefined,
undefined,
' '
]
}
},
{ 'type': '/alienMeta' },
{ 'type': '/listItem' },
{ 'type': '/list' }
]
},
'whitespace preservation with comment at start or end of element': {
'html': '<body><p> <!-- foo -->bar<!-- baz --> </p></body>',
'data': [
{
'type': 'paragraph',
'internal': {
'whitespace': [
undefined,
' ',
' '
]
}
},
{
'type': 'alienMeta',
'attributes': {
'style': 'comment',
'text': ' foo '
}
},
{ 'type': '/alienMeta' },
'b', 'a', 'r',
{
'type': 'alienMeta',
'attributes': {
'style': 'comment',
'text': ' baz '
}
},
{ 'type': '/alienMeta' },
{ '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
'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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'attributes': {
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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'title': 'Foo',
'html/0/href': 'Foo',
'html/0/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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'attributes': {
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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'title': 'Foo',
'html/0/href': 'Foo',
'html/0/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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'attributes': {
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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'title': 'Foo',
'html/0/href': 'Foo',
'html/0/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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'attributes': {
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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'title': 'Foo',
'html/0/href': 'Foo',
'html/0/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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'attributes': {
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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'title': 'Foo',
'html/0/href': 'Foo',
'html/0/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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'attributes': {
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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'title': 'Foo',
'html/0/href': 'Foo',
'html/0/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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'attributes': {
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',
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
'title': 'Foo',
'html/0/href': 'Foo',
'html/0/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 MW-specific meta items for categories and language links Also rename MWMetaItem to MWAlienMetaItem, because that's what it really is. Change-Id: I70695bfa3b8449c936a63f7b2a248b90c49dcea1
2013-03-21 19:18:52 +00:00
'<link rel="mw:WikiLink/Category" href="./Category:Foo_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
},
Hack MWTemplate so it also does partial type matches For extension-specific types such as mw: , we require that all types be matched. But we want MWTemplateNode to match anything with an mw:Object/Template type, even if it also has other types (like mw:WikiLink/Category in our test case). Hack this into MWTemplate by matching on /^mw:/ then using a matchFunction to assert that mw:Object/Template is in the typeof attribute. Update the test case. Because it's now a template, there's a bunch of store stuff involved. Remove the other test case for about group forcing because it's now a duplicate of this one. Change-Id: Iacbe952a66d610c19b46bd76b84c50488857ac29
2013-05-03 23:34:01 +00:00
'RDFa types spread across two attributes, about grouping is forced': {
'html': '<body>' + ve.dm.example.MWTemplate.mixed + '</body>',
Fix ModelRegistry bugs * In matchTypeRegExps(), skip string types ** Didn't break because we currently have mixes of strings and regexes * Combine types from rel, typeof and property rather than picking one ** Added test case in ve.dm.example that resembles actual Parsoid output * If the element has extension-specific types, not only restrict type matching to extension-specific types, but also require that *all* types present on the element be matched Change-Id: Iacf3851a0ca9081d2c813b42435484a47cec6230
2013-04-09 00:59:15 +00:00
'data': [
Hack MWTemplate so it also does partial type matches For extension-specific types such as mw: , we require that all types be matched. But we want MWTemplateNode to match anything with an mw:Object/Template type, even if it also has other types (like mw:WikiLink/Category in our test case). Hack this into MWTemplate by matching on /^mw:/ then using a matchFunction to assert that mw:Object/Template is in the typeof attribute. Update the test case. Because it's now a template, there's a bunch of store stuff involved. Remove the other test case for about group forcing because it's now a duplicate of this one. Change-Id: Iacbe952a66d610c19b46bd76b84c50488857ac29
2013-05-03 23:34:01 +00:00
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
ve.dm.example.MWTemplate.mixedDataOpen,
ve.dm.example.MWTemplate.mixedDataClose,
{ 'type': '/paragraph' }
],
'storeItems': [
ve.dm.example.MWTemplate.mixedStoreItems
Fix ModelRegistry bugs * In matchTypeRegExps(), skip string types ** Didn't break because we currently have mixes of strings and regexes * Combine types from rel, typeof and property rather than picking one ** Added test case in ve.dm.example that resembles actual Parsoid output * If the element has extension-specific types, not only restrict type matching to extension-specific types, but also require that *all* types present on the element be matched Change-Id: Iacf3851a0ca9081d2c813b42435484a47cec6230
2013-04-09 00:59:15 +00:00
]
},
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': {
Per Timo's comment, change $.makeArray( foo ) to foo.toArray() Change-Id: Ideee46640bc82f979578d5cc467c9c79d9806ae0
2013-04-30 01:08:04 +00:00
'domElements': $( '<div typeof="mw:Placeholder" about="#mwt1">Foo</div>' +
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'<figure typeof="mw:Placeholder" about="#mwt1">Bar</figure>' ).get()
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
}
},
{ 'type': '/alienBlock' },
{
'type': 'alienBlock',
'attributes': {
Per Timo's comment, change $.makeArray( foo ) to foo.toArray() Change-Id: Ideee46640bc82f979578d5cc467c9c79d9806ae0
2013-04-30 01:08:04 +00:00
'domElements': $( '<figure typeof="mw:Placeholder" about="#mwt2">Baz</figure>' +
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'<span typeof="mw:Placeholder" about="#mwt2">Quux</span>' ).get()
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
}
},
{ 'type': '/alienBlock' },
{ 'type': 'paragraph' },
'W',
'h',
'e',
'e',
{ 'type': '/paragraph' },
{
'type': 'alienBlock',
'attributes': {
Per Timo's comment, change $.makeArray( foo ) to foo.toArray() Change-Id: Ideee46640bc82f979578d5cc467c9c79d9806ae0
2013-04-30 01:08:04 +00:00
'domElements': $( '<span typeof="mw:Placeholder" about="#mwt2">Yay</span>' +
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'<div typeof="mw:Placeholder" about="#mwt2">Blah</div>' ).get()
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
}
},
{ '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': {
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'domElements': $( '<span typeof="mw:Placeholder" about="#mwt3">Meh</span>' ).get()
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' },
{ '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': {
Per Timo's comment, change $.makeArray( foo ) to foo.toArray() Change-Id: Ideee46640bc82f979578d5cc467c9c79d9806ae0
2013-04-30 01:08:04 +00:00
'domElements': $( '<div typeof="mw:Placeholder" about="#mwt1">\tFoo\t\t</div>\t\t\t' +
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'<div typeof="mw:Placeholder" about="#mwt1"> Bar </div>' ).get()
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
},
'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': {
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'domElements': $( '<p>Bar</p>' ).get()
(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
},
'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': {
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'domElements': $( '<p>Bar</p>' ).get()
(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
},
'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': {
GeneratedContentNodes store DOM elements, not HTML (like aliens) To avoid serialisation bugs, and for consistency. Change-Id: I02e202a2ab52c88da039349ec079bea55e000665
2013-05-02 17:22:56 +00:00
'domElements': $( '<p>Bar</p>' ).get()
(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
},
'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',
Fix whitespace preservation around meta items This was broken, especially in wrappers. Changed the wrapping algorithm so that meta items are placed outside wrappers if possible. On the left-hand side, this is already the case: we don't open wrappers for meta items. On the right-hand side, this is accomplished by buffering the meta items and only inserting them when we encounter either real text (not whitespace) or the end of the wrapper. If we're interrupted by real text, we insert the meta items with the unmodified whitespace. If we're interrupted by the end of the wrapper, we insert the meta items outside of the wrapper with whitespace stripped. Internally, this is done by stripping the whitespace into the whitespace[0] of the meta item to its right. Then when we output the meta items, we either decide to 'restore' the whitespace, or to 'fixup' by also setting whitespace[3] on the element before the whitespace. Change-Id: Ibeea2a9906c4aae9fe6d284613edd6ec853ca5e7
2013-04-18 23:06:58 +00:00
{ '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
{
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
'type': 'alienMeta',
Fix whitespace preservation around meta items This was broken, especially in wrappers. Changed the wrapping algorithm so that meta items are placed outside wrappers if possible. On the left-hand side, this is already the case: we don't open wrappers for meta items. On the right-hand side, this is accomplished by buffering the meta items and only inserting them when we encounter either real text (not whitespace) or the end of the wrapper. If we're interrupted by real text, we insert the meta items with the unmodified whitespace. If we're interrupted by the end of the wrapper, we insert the meta items outside of the wrapper with whitespace stripped. Internally, this is done by stripping the whitespace into the whitespace[0] of the meta item to its right. Then when we output the meta items, we either decide to 'restore' the whitespace, or to 'fixup' by also setting whitespace[3] on the element before the whitespace. Change-Id: Ibeea2a9906c4aae9fe6d284613edd6ec853ca5e7
2013-04-18 23:06:58 +00:00
'internal': { 'whitespace': [ '\n' ] },
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
}
},
Change MetaNodes to MetaItems Rather than meta-things being special kinds of nodes, they are now a separate class of things (MetaItems) along with Nodes and Annotations. * Created a generic ve.dm.MetaItem that meta items inherit from. There will be actual instances of this class as well in the upcoming meta group code. * Renamed MetaNode to AlienMetaItem, MWMetaNode to MWMetaItem, 'metaBlock'/'metaInline' to 'alienMeta' * Created a MetaItemFactory, handle meta items in the ModelRegistry * Kill ve.dm.Node.static.isMeta, now obsolete ve.dm.Converter: * Pass in the MetaItemFactory * Look up data element types in the ModelRegistry rather than the NodeFactory, because they can be either nodes or meta items * Document createDataElement() and make explicit that modelClass can be either a node or a meta item * Handle meta items in getDataFromDom() * In getDomFromData(), check the MetaItemFactory as well as the NodeFactory Change-Id: I893709c6f3aa00f85c1b905b70f9f4e597bdeada
2013-02-21 23:01:04 +00:00
{ 'type': '/alienMeta' },
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': '/tableCell' },
{ 'type': '/tableRow' },
{ 'type': '/tableSection' },
{ 'type': '/table' }
]
Add TableCaptionNode Because we have a node for <table>, we also need one for <caption>, otherwise we'll try to alienate it and fail. Added the test case as a separate example document so Ed can use it for his tests. Removed test case asserting <caption> is alienated. Change-Id: I3a917db58e6c0eb97899b214b07d01fc8d86b56d
2013-04-25 22:24:37 +00:00
},
'table with caption, head, foot and body': {
'html': ve.dm.example.complexTableHtml,
'data': ve.dm.example.complexTable
Create meta item for defaultsort Bug: 46465 Change-Id: I604a79c25e5b0315f7e6437da657977b0efa77db
2013-04-29 14:33:37 +00:00
},
'category default sort key': {
'html': '<body><meta property="mw:PageProp/categorydefaultsort" content="foo"></body>',
'data': [
{
'type': 'MWdefaultSort',
'attributes': {
'content': 'foo',
'html/0/content': 'foo',
'html/0/property': 'mw:PageProp/categorydefaultsort'
}
},
{ 'type': '/MWdefaultSort' }
]
Add support for <div>s as user-editable blocks Bug: 47907 Change-Id: I794927a881082e0113c0ce8ee8f1d908b0960899
2013-05-01 01:32:06 +00:00
},
'div set to RTL with paragraph inside': {
'html': '<body><div style="direction: rtl;"><p>a<b>b</b>c<i>d</i>e</p></body>',
'data': [
{ 'type': 'div', 'attributes': { 'html/0/style': 'direction: rtl;' } },
{ 'type': 'paragraph' },
'a',
['b', [ ve.dm.example.bold ]],
'c',
['d', [ ve.dm.example.italic ]],
'e',
{ 'type': '/paragraph' },
{ 'type': '/div' }
]
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:' +
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
'<ul><li><h1>Title in list</h1></li><li><pre>Preformatted in list</pre></li></ul>' +
'<ul><li><ol><li>Nested 1</li><li>Nested 2</li><li>Nested 3</li></ol></li></ul>' +
'<ul><li><p>P1</p><p>P2</p><p>P3</p></li></ul>';
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.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' } },
The resurrection By removing the transaction listeners from surface fragments we no longer have to make sure they are always manually destroyed. In order to retain the functionality of having fragments update with transactions elsewhere we keep a pointer to a place in the new complete history stack in the surface. The complete history stack records all transactions, even undone ones. Whenever getRange is called we replay all transactions in the complete history (in the correct order) since the fragment was last updated. Also in this commit: * Updated Format/IndentationAction to test undo(). This increases coverage of surface fragment behaviour. * .range is always accessed by .getRange now, although as an optimisation we can use the noCopy mode when we a sure the returned range will not be modified. * Added undo test to .update (previously .onTransact) Bug: 47343 Change-Id: I9e9818da1baa8319a3002f6d74fd1aad6732a8f5
2013-04-22 11:20:26 +00:00
'N', 'o', 't', ' ', 'a', 'l', 'l', 'o', 'w', 'e', 'd', ' ', 'b', 'y', ' ', 'd', 'm', ':',
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
{ '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' },
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
{ 'type': '/list' },
{ 'type': 'list', 'attributes': { 'style': 'bullet' } },
{ 'type': 'listItem' },
{ 'type': 'list', 'attributes': { 'style': 'number' } },
{ 'type': 'listItem' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'N', 'e', 's', 't', 'e', 'd', ' ', '1',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': 'listItem' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'N', 'e', 's', 't', 'e', 'd', ' ', '2',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': 'listItem' },
{ 'type': 'paragraph', 'internal': { 'generated': 'wrapper' } },
'N', 'e', 's', 't', 'e', 'd', ' ', '3',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': '/list' },
{ 'type': '/listItem' },
{ 'type': '/list' },
{ 'type': 'list', 'attributes': { 'style': 'bullet' } },
{ 'type': 'listItem' },
{ 'type': 'paragraph' },
'P', '1',
{ 'type': '/paragraph' },
{ 'type': 'paragraph' },
'P', '2',
{ 'type': '/paragraph' },
{ 'type': 'paragraph' },
'P', '3',
{ 'type': '/paragraph' },
{ '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