6dc3d701c0b00d368109ccff602d4ae69b5512d2: Bug 1273706 - Part 25: Make registered custom properties animatable. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Mon, 04 Jul 2016 23:51:20 -0700 - rev 391180
Push 23827 by jchan@mozilla.com at Fri, 22 Jul 2016 07:03:37 +0000
Bug 1273706 - Part 25: Make registered custom properties animatable. r?heycam MozReview-Commit-ID: 9NgyBxQUPhj
b435cca19872e4590e55f36a597a8e3739a3fbfc: Bug 1273706 - Part 24: Have nsComputedDOMStyle try to get a computed value first for variables. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Thu, 21 Jul 2016 20:56:59 -0700 - rev 391179
Push 23827 by jchan@mozilla.com at Fri, 22 Jul 2016 07:03:37 +0000
Bug 1273706 - Part 24: Have nsComputedDOMStyle try to get a computed value first for variables. r?heycam Now that we can register custom properties that have computed values and are animatable, we should support getting their computed value through getComputedStyle and getPropertyValue the same way we do other properties. Only registered properties have computed values in the ComputedVars style struct, so we try that first. If there is no entry, then either no such variable was declared, or the property is unregistered. In that case we fall back to reading from the Variables style struct as before. MozReview-Commit-ID: 5EVDeQpq8bb
71b98c4e73235b1fe9f1060eedb910c8f2ebee4c: Bug 1273706 - Part 23: Add support for storing custom properties in nsCSSPropertySet. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Thu, 21 Jul 2016 20:55:31 -0700 - rev 391178
Push 23827 by jchan@mozilla.com at Fri, 22 Jul 2016 07:03:37 +0000
Bug 1273706 - Part 23: Add support for storing custom properties in nsCSSPropertySet. r?heycam Needed because animation code uses |nsCSSPropertySet|s to store sets of properties to be animated, and registered custom properties are animatable. MozReview-Commit-ID: 1450ZzAPPt5
2c9de431438ad9ff1fb405d09274339cea99c045: Bug 1273706 - Part 22: Add new ComputedVars style struct. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Thu, 21 Jul 2016 20:55:21 -0700 - rev 391177
Push 23827 by jchan@mozilla.com at Fri, 22 Jul 2016 07:03:37 +0000
Bug 1273706 - Part 22: Add new ComputedVars style struct. r?heycam Custom properties that have been registered using the Properties & Values API with the appropriate types can contain values that need to be computed and/or that can be animated. Because there may be multiple interfaces through which computed CSS custom property values are accessed and in order to make use of the existing infrastructure for sharing, we implement this as a new style struct. The new style struct contains only a hashtable mapping from variable names to |CSSComputedValue|s. MozReview-Commit-ID: 59A1CMPIGAz
fe33f869852a3e4d5c5bfa3be52b81183785f972: Bug 1273706 - Part 21: Make nsRuleNode's mNoneBits and mDependentBits uint64_t's (were uint32_t's). r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Thu, 21 Jul 2016 20:55:21 -0700 - rev 391176
Push 23827 by jchan@mozilla.com at Fri, 22 Jul 2016 07:03:37 +0000
Bug 1273706 - Part 21: Make nsRuleNode's mNoneBits and mDependentBits uint64_t's (were uint32_t's). r?heycam This is in preparation for adding a new ComputedVars style struct, for holding the computed values of CSS custom properties (regular variables are just token streams, but custom properties can have types that need computation. For example, a variable can be set to have syntax <length> and value 5em.) Originally I thought that I could just make them uint32_t's, because other layout people found an unused extra bit. Unfortunately, although there is an unused bit, it turns out that adding an extra bit to NS_STYLE_INHERIT_MASK causes it to overlap with the additional bits for nsStyleContext's mBits, which are pushed as far to the left as they can go. Consequently, we need to make mDependentBits and mNoneBits uint64_t's, shift the bits for nsStyleContext's mBits (which coincidentally is already a uint64_t) four bits to the left, and shift the additional bits for nsRuleNode's mDependentBits one bit to the left. MozReview-Commit-ID: AOpGFGl27Sb
0afe4f05eb70f49026ea7103b73881f1520217f3: Bug 1273706 - Part 20: Implement CSS.registerProperty and CSS.unregisterProperty. r?dbaron draft
Jonathan Chan <jchan@mozilla.com> - Thu, 21 Jul 2016 20:55:21 -0700 - rev 391175
Push 23827 by jchan@mozilla.com at Fri, 22 Jul 2016 07:03:37 +0000
Bug 1273706 - Part 20: Implement CSS.registerProperty and CSS.unregisterProperty. r?dbaron Note that although this patch series modifies a lot of code related to CSS variables in order to support custom properties, behavior if a variable is unregistered is exactly the same as before. This is why merely hiding (un)?registerProperty behind a pref is sufficient to disable the Properties & Values API functionality (hopefully!). MozReview-Commit-ID: CwrprDp41Yv
e5de36687d1e7c20f2f150ac82348bc3764a6933: Bug 1273706 - Part 19: Update CSSVariableResolver for custom properties. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Thu, 21 Jul 2016 20:55:21 -0700 - rev 391174
Push 23827 by jchan@mozilla.com at Fri, 22 Jul 2016 07:03:37 +0000
Bug 1273706 - Part 19: Update CSSVariableResolver for custom properties. r?heycam We also add a new |mHasUninherited| field to the |nsStyleVariables| style struct. Some custom properties are uninherited, but we assume that most will be inherited (all unregistered custom properties). Thus we keep the Variables style struct as an inherited style struct but we set a flag when we set an uninherited variable. The implementation of this is in the next patch in this series. MozReview-Commit-ID: 9bNLGm3OQkj
0a58d7515e86bb585640964b6cc796b9037bd9da: Bug 1273706 - Part 18: Add WebIDL bindings for the Properties & Values API. r?dbaron draft
Jonathan Chan <jchan@mozilla.com> - Thu, 21 Jul 2016 20:55:21 -0700 - rev 391173
Push 23827 by jchan@mozilla.com at Fri, 22 Jul 2016 07:03:37 +0000
Bug 1273706 - Part 18: Add WebIDL bindings for the Properties & Values API. r?dbaron MozReview-Commit-ID: HKUItZc3INd
53d437e3912af33f2d75dea13b436adef201bf22: Bug 1273706 - Part 17: Have CSSVariableValues store more information. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Thu, 21 Jul 2016 20:55:21 -0700 - rev 391172
Push 23827 by jchan@mozilla.com at Fri, 22 Jul 2016 07:03:37 +0000
Bug 1273706 - Part 17: Have CSSVariableValues store more information. r?heycam Namely, the parsed CSS value (for now, a placeholder -- in a later patch in the series, we put all unregistered properties into token stream values and typed properties into specified values of the appropriate type) as well as the type (provided by ParseTypedValue) and the context of the declaration. MozReview-Commit-ID: Fs8BS8HAfyz
f6566fca462ed035b2d0a76d00b45fa932af0221: Bug 1273706 - Part 16: Store important and unimportant declarations in one object. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Thu, 21 Jul 2016 20:55:21 -0700 - rev 391171
Push 23827 by jchan@mozilla.com at Fri, 22 Jul 2016 07:03:37 +0000
Bug 1273706 - Part 16: 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 VariableExprContext, 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: 7PbIuvyIRPV
011e48811cae7c7deab1857d09b3aac964727e68: Bug 1273706 - Part 15: Add support for custom properties in supports conditions. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Thu, 21 Jul 2016 20:55:21 -0700 - rev 391170
Push 23827 by jchan@mozilla.com at Fri, 22 Jul 2016 07:03:37 +0000
Bug 1273706 - Part 15: 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: JpdUujjNBSz
cbc4a4f105310551a51eec8f87f39bde7386edcc: Bug 1273706 - Part 14: Add the |ParseTypedValue| method for parsing typed CSS values. r?dbaron draft
Jonathan Chan <jchan@mozilla.com> - Thu, 21 Jul 2016 20:55:21 -0700 - rev 391169
Push 23827 by jchan@mozilla.com at Fri, 22 Jul 2016 07:03:37 +0000
Bug 1273706 - Part 14: 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: cAJdbbL8Tx
ca1bbff1dfc57df3544735fabbc5c423d31a2570: Bug 1273706 - Part 13: Add an aAllowVariableReferences parameter to ParseVariableDeclaration. r?dbaron draft
Jonathan Chan <jchan@mozilla.com> - Thu, 21 Jul 2016 20:55:20 -0700 - rev 391168
Push 23827 by jchan@mozilla.com at Fri, 22 Jul 2016 07:03:37 +0000
Bug 1273706 - Part 13: 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 (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: Aemi14pKeJU
b092157311864c8d04a16b24fbe248af42db2cb1: Bug 1273706 - Part 12: Store custom property registrations on nsCSSParser. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Thu, 21 Jul 2016 20:55:20 -0700 - rev 391167
Push 23827 by jchan@mozilla.com at Fri, 22 Jul 2016 07:03:37 +0000
Bug 1273706 - Part 12: 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: J0QNSrHfGFU
8f6bfe01e9bcb2803b5c8d54b0a50225832377e3: Bug 1273706 - Part 11: Store custom property registrations on the inner window (in nsGlobalWindow). r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Thu, 21 Jul 2016 20:55:20 -0700 - rev 391166
Push 23827 by jchan@mozilla.com at Fri, 22 Jul 2016 07:03:37 +0000
Bug 1273706 - Part 11: 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 hashtable from available objects (used in nsCSSParser, nsRuleNode, etc.) that are used in future patches in this series. Add a VariableExprContext 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: 6D9Bg9Xex0C
dba6c1293ec48031127d4fa4290e7b4d21416151: Bug 1273706 - Part 10: Add CSSVariableSyntax for representing the syntax of a custom property. r?dbaron draft
Jonathan Chan <jchan@mozilla.com> - Thu, 21 Jul 2016 20:55:20 -0700 - rev 391165
Push 23827 by jchan@mozilla.com at Fri, 22 Jul 2016 07:03:37 +0000
Bug 1273706 - Part 10: 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: 4keHLEGmuwy
a174ee6e45e46da837ce18899e6759a21c233d07: Bug 1273706 - Part 9: Add CSSComputedValues, like CSSVariableValues but for computed variable values. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Thu, 21 Jul 2016 20:55:20 -0700 - rev 391164
Push 23827 by jchan@mozilla.com at Fri, 22 Jul 2016 07:03:37 +0000
Bug 1273706 - Part 9: Add CSSComputedValues, like CSSVariableValues but for computed variable values. r?heycam CSSComputedValues provides a key-value map from custom property names (without the preceding --) to their computed values, like CSSVariableValues. The primary reason we write this small wrapper class instead of using a ns*Hashtable directly is so that we can expose operator== for computing differences. MozReview-Commit-ID: BAS76HAzVhg
fe577f77c69138b5262f9297901d7ee6d48f28e9: Bug 1273706 - Part 8: Add a new type for computed CSS values. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Thu, 21 Jul 2016 20:55:20 -0700 - rev 391163
Push 23827 by jchan@mozilla.com at Fri, 22 Jul 2016 07:03:37 +0000
Bug 1273706 - Part 8: 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. We already have StyleAnimationValues, which represent computed animatable values, and nsCSSValues, which represent specified values. Why do we need a new type? Some custom property types are not animatable, for example, <custom-ident>s. At the same time, its convenient to store computed information, e.g. for <length>s, both so that we can extract computed values for animatable properties and so that we can expose typed values through the future Typed OM API. CSSComputedValues has simple internal representations for types that makes conversion to StyleAnimationValues (and in the future, Typed OM values) straightforward. Computed values are stored in a hashtable on a new ComputedVars style struct that is added in a future patch in this series. MozReview-Commit-ID: FrZxbIhA6qO
7a1540b25e50af578db2c2849bbd5aaae2d679cf: Bug 1273706 - Part 7: Add support to StyleAnimationValues for storing lists of values. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Thu, 21 Jul 2016 20:55:20 -0700 - rev 391162
Push 23827 by jchan@mozilla.com at Fri, 22 Jul 2016 07:03:37 +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. When calculating the distance or interpolating between two lists, the lists are repeated to the length of the result list, whose length is the least common multiple of the lengths of the input lists, as specified in the CSS Transitions spec [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://drafts.csswg.org/css-transitions-1/#animtype-repeatable-list. MozReview-Commit-ID: G2sKSvXLRnM
000c1cb210b562b81da65bed6aa25d64359db068: Bug 1273706 - Part 6: Make nsCSSProperty castable to/from nsIAtom*. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Thu, 21 Jul 2016 19:01:12 -0700 - rev 391161
Push 23827 by jchan@mozilla.com at Fri, 22 Jul 2016 07:03:37 +0000
Bug 1273706 - Part 6: Make nsCSSProperty castable to/from nsIAtom*. r?heycam The current animation code only deals with shorthand properties, who are given values in the nsCSSProperty enum. With the implementation of the Properties & Values API, we need to be able to animate custom properties whose types support it as well. This patch makes the backing type of nsCSSProperty intptr_t, meaning that a variable for holding a nsCSSProperty will have room for holding a nsIAtom*. I also update relevant helper functions (those called by code which will be exposed to nsIAtom* nsCSSProperties in later patches in the series) to recognize a nsCSSProperty argument representing a custom property accordingly. The nsIAtoms are not static atoms, but they aren't deallocated because they are owned by the registrations for their respective custom properties (and atoms are only needed for the custom properties, because they are the only other properties that are animatable). There should not be any collisions between nsCSSProperties representing pointers to atoms and regular nsCSSProperties because modern operating systems mark page zero as inaccessble. To be even more sure, we could make regular properties all have their least-significant bit set (pointers shouldn't collide they will be word aligned, cf tagged integers). I thought that doing this would mean modifying the least code, because these custom properties need to be passed around like this *only* for animations (see later patches in this series). We don't use these for other things, like fetching custom properties from data blocks, because they aren't stored in data blocks. Some alternatives: * making animations store things in another representation * modifying nsCSSProperty to be a struct with a separate tag field MozReview-Commit-ID: 2QQTSS1USm
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip