95aa71ec3d8e263c59716dccf7a440d60ef69669: Bug 1273706 - Part 19: Store important and unimportant declarations in one object. r?heycam draft
Jonathan Chan <jyc@eqv.io> - Fri, 12 Aug 2016 13:31:17 -0700 - rev 400279
Push 26115 by jchan@mozilla.com at Fri, 12 Aug 2016 22:08:05 +0000
Bug 1273706 - Part 19: Store important and unimportant declarations in one object. r?heycam Inherited from heycam's patches. This means we have to store more information for variables (in particular, if the variable is important). We now also store the CSSVariableExprContext, which I added in the previous patch, on variable declarations, although in this patch we leave it empty (it's used by a future patch in the series). The eTokenStream, etc. enum values are changed to an enum class, which necessitates some renaming in nsCSSParser. Most importantly, we store invalid variable declarations on a |Declaration|'s |CSSVariableDeclaration|. This allows us to map the declaration that becomes correct after registering properties into the rule data without reparsing everything. We lazily determine which is the correct declaration when someone asks us for information on declarations (e.g. which declaration is at some index in the list of declarations, or when someone asks us to |MapRuleInfoInto|). Because changing registrations might cause which declaration is correct to change, we keep track of which version of the |CSSVariableRegistrations| we last computed the 'used declaration' based on (the 'used declaration' is the most recent declaration with the correct type, considering importance and overriding importance). This necessitates a couple changes: * The constructor for |Declaration| now takes a |RefPtr| to a |CSSVariableRegistrations|, which is used for computing the used declaration. * |Declaration| presents an 'exposed order' that is computed from the actual order. Suppose |--a| is registered with syntax <number>. Then in the declaration: { --a: red; color: black; --a: 50px; display: none; --a: 4.7; } ... the internal order needs to keep track of the positions of *all* of the declarations of |--a|, so that if the registration for |--a| is removed and replaced with a new registration, indexed getters can return |--a| at the correct position, which is expressed in the exposed order. The 'exposed order' system on |Declaration|s comes from heycam's patches. Sorry this is such a long patch. I couldn't find a good way to split it up. MozReview-Commit-ID: 7hegCUosHm1
82310cfdd386e26b2b2e76d82e5621cc1729ae96: Bug 1273706 - Part 18: Add support for custom properties in supports conditions. r?heycam draft
Jonathan Chan <jyc@eqv.io> - Fri, 12 Aug 2016 13:31:17 -0700 - rev 400278
Push 26115 by jchan@mozilla.com at Fri, 12 Aug 2016 22:08:05 +0000
Bug 1273706 - Part 18: Add support for custom properties in supports conditions. r?heycam For conditions like |(--a: 5px)|, when |--a| is a registetred custom property, we verify that the value types correctly. MozReview-Commit-ID: I6PnqbC3Ytp
a42266bb0c5e8dff5eb41d45e72f994590bd3aea: Bug 1273706 - Part 17: Add the |ParseTypedValue| method for parsing typed CSS values. r?dbaron draft
Jonathan Chan <jyc@eqv.io> - Fri, 12 Aug 2016 13:31:17 -0700 - rev 400277
Push 26115 by jchan@mozilla.com at Fri, 12 Aug 2016 22:08:05 +0000
Bug 1273706 - Part 17: Add the |ParseTypedValue| method for parsing typed CSS values. r?dbaron This is what we use for checking the types of custom property values in future patches in this series. MozReview-Commit-ID: 4ZbrcZAr1nR
bd63e8f4b350a4426cf6c3151506a105cd061b80: Bug 1273706 - Part 16: Add an aAllowVariableReferences parameter to ParseVariableDeclaration. r?dbaron draft
Jonathan Chan <jyc@eqv.io> - Fri, 12 Aug 2016 13:31:17 -0700 - rev 400276
Push 26115 by jchan@mozilla.com at Fri, 12 Aug 2016 22:08:05 +0000
Bug 1273706 - Part 16: Add an aAllowVariableReferences parameter to ParseVariableDeclaration. r?dbaron We allow variable references when parsing variable declarations in support conditions or to load into a |Declaration| object. However, we expect resolved variable declarations (that is, declarations with variable values substituted) to not contain variable references, so we disallow variable references there. In particular, a future patch in this series adds a ParseTypedValue method. This expects fully resolved values (otherwise they couldn't be typed), so it disallows variable references. MozReview-Commit-ID: 4lABnRLdHSG
34b85ff70e6050590e6a72adce96635aad0ebd33: Bug 1273706 - Part 15: Store custom property registrations on nsCSSParser. r?heycam draft
Jonathan Chan <jyc@eqv.io> - Fri, 12 Aug 2016 13:31:16 -0700 - rev 400275
Push 26115 by jchan@mozilla.com at Fri, 12 Aug 2016 22:08:05 +0000
Bug 1273706 - Part 15: Store custom property registrations on nsCSSParser. r?heycam When the parser is bound to a sheet, we can get custom property registrations from the sheet's document's inner window. But sometimes we use the parser and need registrations, but are not associated with a sheet. In particular, when we are handling custom property values that come through JS API calls rather than through parsing actual sheets. So we expose a method for setting a custom property registrations object on the parser that overrides getting custom property registrations from the associated sheet. MozReview-Commit-ID: EwnCjOwzCh2
6512f53810384e6d7ca7e8fea9405c49ecf306f7: Bug 1273706 - Part 14: Store custom property registrations on the inner window (in nsGlobalWindow). r?heycam draft
Jonathan Chan <jyc@eqv.io> - Fri, 12 Aug 2016 13:31:16 -0700 - rev 400274
Push 26115 by jchan@mozilla.com at Fri, 12 Aug 2016 22:08:05 +0000
Bug 1273706 - Part 14: Store custom property registrations on the inner window (in nsGlobalWindow). r?heycam Add a CSSVariableRegistration struct to hold registration information. Also add some utility methods for getting access to the registrations mapping from available objects (used in nsCSSParser, nsRuleNode, etc.) that are used in future patches in this series. Add CSSVariableRegistrations, a mapping from registered custom property names to their registrations. Whenever a registration in |mData| is modified, |mVersion| *must* be incremented. (This happens in the bindings for CSS.registerProperty and CSS.unregisterProperty). The reason we need to update |mVersion| is because a Declaration stores a reference to a CSSVariableRegistration that it uses to determine which declaration of a given property is valid. Unlike standard properties, for which we can decide validity at parse time (unless they contain variable references), registered custom property types are not necessarily known at parse time. In particular, CSS.registerProperty, which registers the type of a custom property, can be called in the middle of the life of a Declaration. This means we have to recompute validities every time we try to read from a Declaration and the types of custom properties have changed. We store this monotonically increasing version number so that we only recompute when necessary. This is what is stored on nsGlobalWindow. Add a CSSVariableExprContext for storing the context of a variable expression. This is important for when the computed value of a custom property might depend on the context its declared in -- for example, relative URLs need to be resolved based on the stylesheet they were declared in. Some of these type and function names are absurdly long, though I'm not sure how best to shorten them. MozReview-Commit-ID: J90aiFeF8gW
3826f48200a3193971a91f825eb85bfd683dd46b: Bug 1273706 - Part 13: Add CSSVariableSyntax for representing the syntax of a custom property. r?dbaron draft
Jonathan Chan <jyc@eqv.io> - Fri, 12 Aug 2016 13:31:16 -0700 - rev 400273
Push 26115 by jchan@mozilla.com at Fri, 12 Aug 2016 22:08:05 +0000
Bug 1273706 - Part 13: Add CSSVariableSyntax for representing the syntax of a custom property. r?dbaron A custom property has a syntax that specifies the set of legal values (see the Properties & Values API specification). CSSVariableSyntax::SetSyntax parses a specified syntax string into a CSSVariableSyntax object. A future patch in this series adds functions to nsCSSParser to parse and type check a declaration with a CSSVariableSyntax. heycam wrote this code. I only made small modifications for parsing resolutions and transform-functions and a fix to the syntax parser. MozReview-Commit-ID: 7rZpNJsvVNE
b5e7b08b4ad111dd534eb3f04e43aa7b89417e65: Bug 1273706 - Part 12: Add a new type for computed CSS values. r?heycam draft
Jonathan Chan <jyc@eqv.io> - Fri, 12 Aug 2016 13:31:16 -0700 - rev 400272
Push 26115 by jchan@mozilla.com at Fri, 12 Aug 2016 22:08:05 +0000
Bug 1273706 - Part 12: Add a new type for computed CSS values. r?heycam Previously this was not necessary because computed values for various properties were simply stored with the appropriate type in the corresponding style struct. Now we can have typed custom properties whose names and types are not known until run-time. MozReview-Commit-ID: LQsk6XVbh36
1ee2020ba06afacf4cc1f884306f9176808f9610: Bug 1273706 - Part 11: Have StyleAnimationValue::UncomputeValue(..., nsCSSValue) uncompute UnparsedStrings to token stream nsCSSValues. draft
Jonathan Chan <jyc@eqv.io> - Fri, 12 Aug 2016 13:31:16 -0700 - rev 400271
Push 26115 by jchan@mozilla.com at Fri, 12 Aug 2016 22:08:05 +0000
Bug 1273706 - Part 11: Have StyleAnimationValue::UncomputeValue(..., nsCSSValue) uncompute UnparsedStrings to token stream nsCSSValues. ::UncomputeValue(..., nsAString) already uncomputes these to strings. A later patch in this series uses unparsed strings to represent non-interpolable but animatable custom properties that don't require additional context (URL values require a principal, and StyleAnimationValue provides a URL type). MozReview-Commit-ID: ERHLMPCfFVF
3ceb5c25e3c352c6c79d82e0febb462d99acfda8: Bug 1273706 - Part 10: Expose StyleAnimationValue::StyleCoordToValue and StyleCoordToCSSValue. draft
Jonathan Chan <jyc@eqv.io> - Fri, 12 Aug 2016 13:31:16 -0700 - rev 400270
Push 26115 by jchan@mozilla.com at Fri, 12 Aug 2016 22:08:05 +0000
Bug 1273706 - Part 10: Expose StyleAnimationValue::StyleCoordToValue and StyleCoordToCSSValue. Currently these are used by StyleAnimationValue internally in ExtractComputedValue only. A later patch in this series will use them for converting nsStyleCoords to StyleAnimationValues and for converting nsStyleCoords to strings (by way of nsCSSValue::AppendToString). MozReview-Commit-ID: L1zTPOxq88Z
e60e1256e10c9b8baf14a817aed75de21c61b6e0: Bug 1273706 - Part 9: Expose nsComputedDOMStyle::SetValueToStyleImage as a static method so that we can compute serialized computed values for gradients. draft
Jonathan Chan <jyc@eqv.io> - Fri, 12 Aug 2016 13:31:16 -0700 - rev 400269
Push 26115 by jchan@mozilla.com at Fri, 12 Aug 2016 22:08:05 +0000
Bug 1273706 - Part 9: Expose nsComputedDOMStyle::SetValueToStyleImage as a static method so that we can compute serialized computed values for gradients. SetValueToStyleImage doesn't use any member variables in itself or in the methods it calls, but it used various functions that were also non-static. The reason they were non-static is because in the call chain is a function that takes a member function pointer, which requires an object pointer, SetValueToCoord. The member function pointer argument is nullptr by default and not used by any of the functions used by SetValueToStyleImage. SetValueToCoord is modified to take a class object pointer argument and calls are updated appropriately to pass either nullptr or this. This is a little unpleasant, but its a useful method that a later patch needs to use (CSSComputedValue::AppendToString). MozReview-Commit-ID: Kc6KrZK2Dn5
149cd5855f7db10de92a4534be16f4ffdcf2fb67: [mq]: p10.5-nsStyleImage draft
Jonathan Chan <jyc@eqv.io> - Fri, 12 Aug 2016 13:31:16 -0700 - rev 400268
Push 26115 by jchan@mozilla.com at Fri, 12 Aug 2016 22:08:05 +0000
[mq]: p10.5-nsStyleImage MozReview-Commit-ID: 5roQChonIs0
02bd86f854bdc21ed758119240d836bb7dc78c09: Bug 1273706 - Part 7: Add support to StyleAnimationValues for storing lists of values. r?heycam draft
Jonathan Chan <jyc@eqv.io> - Fri, 12 Aug 2016 13:31:16 -0700 - rev 400267
Push 26115 by jchan@mozilla.com at Fri, 12 Aug 2016 22:08:05 +0000
Bug 1273706 - Part 7: Add support to StyleAnimationValues for storing lists of values. r?heycam The lists are homogeneous lists of style animation values. We also implement computing distances & interpolating between them. The lists are simple lists, not repeatable lists. [1] This is for support of custom properties with syntax like <number>+, which indicates a list of <number>s with length at least one. Currently the syntax only supports homogeneous non-empty list. [1]: https://github.com/w3c/css-houdini-drafts/issues/273 MozReview-Commit-ID: 7AwT2A8W0Hr
870f8b0135148e4f09f4363fb22aaffa714a6c35: Bug 1273706 - Part 6: Add CSSProperty type for custom properties. r?heycam draft
Jonathan Chan <jyc@eqv.io> - Fri, 12 Aug 2016 13:31:15 -0700 - rev 400266
Push 26115 by jchan@mozilla.com at Fri, 12 Aug 2016 22:08:05 +0000
Bug 1273706 - Part 6: Add CSSProperty type for custom properties. r?heycam Add CSSProperty type to replace nsCSSPropertyID in places where we might want to represent custom properties. In particular, a later patch in this series will modify the animation code to use these where appropriate. A CSSProperty is a tagged union containing a nsCSSPropertyID or holding a reference to an nsIAtom corresponding to the custom property name, sans the leading --. MozReview-Commit-ID: 4dSHFsSqLq7
5ec381e89791b8702343b8fc43a4b6a7a4d2587d: Bug 1273706 - Part 5: Factor out code for parsing resolutions in nsCSSParser. r?heycam draft
Jonathan Chan <jyc@eqv.io> - Fri, 12 Aug 2016 13:31:15 -0700 - rev 400265
Push 26115 by jchan@mozilla.com at Fri, 12 Aug 2016 22:08:05 +0000
Bug 1273706 - Part 5: Factor out code for parsing resolutions in nsCSSParser. r?heycam Move it into a new ParseResolution method on CSSParserImpl. This is used by a later patch in this series which parses custom property values. MozReview-Commit-ID: EfVBwtoLAFn
dc5ad028a4b34f7d412f44d2787b67e89df3b8bf: Bug 1273706 - Part 4: Add new nsCSSValue units for resolutions. r?heycam draft
Jonathan Chan <jyc@eqv.io> - Fri, 12 Aug 2016 13:31:15 -0700 - rev 400264
Push 26115 by jchan@mozilla.com at Fri, 12 Aug 2016 22:08:05 +0000
Bug 1273706 - Part 4: Add new nsCSSValue units for resolutions. r?heycam Before, eCSSUnit_Inch, eCSSUnit_Pixel, and eCSSUnit_Centimeter were used for DotsPerInch, DotsPerpixel, and DotsPerCentimeter, respectively. Now custom properties can have type <resolution>, and it'd be nice to associate proper units with the resulting nsCSSValues. The next patch in this series edits nsCSSParser to parse resolutions using the new units. MozReview-Commit-ID: FgirNo4QLJr
d80d4b8a13879ff3b28de8e003892e0a4ac70479: Bug 1273706 - Part 3: Add new pref to enable the Properties & Values API. r?dholbert draft
Jonathan Chan <jyc@eqv.io> - Fri, 12 Aug 2016 13:31:15 -0700 - rev 400263
Push 26115 by jchan@mozilla.com at Fri, 12 Aug 2016 22:08:05 +0000
Bug 1273706 - Part 3: Add new pref to enable the Properties & Values API. r?dholbert This will control whether or not CSS.registerProperty and CSS.unregisterProperty are available. Behavior with existing CSS variables should be the same. MozReview-Commit-ID: GyCMg5bPSyp
c0a7edd8e84b51ed0ef631fc54d4bded3fcfc57c: Bug 1273706 - Part 2: Add missing namespace names that the Windows build complained about. r?dholbert draft
Jonathan Chan <jyc@eqv.io> - Fri, 12 Aug 2016 13:31:15 -0700 - rev 400262
Push 26115 by jchan@mozilla.com at Fri, 12 Aug 2016 22:08:05 +0000
Bug 1273706 - Part 2: Add missing namespace names that the Windows build complained about. r?dholbert MozReview-Commit-ID: Kq5GxJapsqR
e1f5ff24e2a72a763cca298affd39cf8df56ef08: Bug 1273706 - Part 1: Add missing includes exposed by unification. r?dholbert draft
Jonathan Chan <jyc@eqv.io> - Fri, 12 Aug 2016 13:31:15 -0700 - rev 400261
Push 26115 by jchan@mozilla.com at Fri, 12 Aug 2016 22:08:05 +0000
Bug 1273706 - Part 1: Add missing includes exposed by unification. r?dholbert MozReview-Commit-ID: 1azGTgKdFsx
1e6ee4fbdd43d54be4a4bde6d2e1e92fae4ebd5d: Bug 1293743: Add support to ParseVariant for parsing integer calc()s. r?dholbert draft
Jonathan Chan <jyc@eqv.io> - Fri, 12 Aug 2016 13:31:15 -0700 - rev 400260
Push 26115 by jchan@mozilla.com at Fri, 12 Aug 2016 22:08:05 +0000
Bug 1293743: Add support to ParseVariant for parsing integer calc()s. r?dholbert ParseVariant now parses integer calc()s when given VARIANT_INTEGER | VARIANT_CALC. Integer calcs cannot contain any division and must contain only integers. We also move ReduceNumberCalcOps from nsCSSParser to CSSCalc. [1]: https://drafts.csswg.org/css-values-3/#funcdef-calc MozReview-Commit-ID: YYX3k7ONUi
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip