6e68e552011334135fc3741c472a96aeda4f2b64: Bug 1273706 - Part 24: Have nsComputedDOMStyle try to get a computed value first for variables. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Wed, 27 Jul 2016 13:38:47 -0700 - rev 393399
Push 24308 by jchan@mozilla.com at Wed, 27 Jul 2016 20:45:06 +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: A8Lk6eKxC59
540b95c249f5dcd90f523394e9726caa03edd6a0: Bug 1273706 - Part 23: Add support for storing custom properties in nsCSSPropertySet. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Wed, 27 Jul 2016 13:38:47 -0700 - rev 393398
Push 24308 by jchan@mozilla.com at Wed, 27 Jul 2016 20:45:06 +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: AwSru13EgZL
7b42c5fe95ca4be000b671b423d8cc376101944e: Bug 1273706 - Part 22: Add new ComputedVars style struct. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Wed, 27 Jul 2016 13:38:46 -0700 - rev 393397
Push 24308 by jchan@mozilla.com at Wed, 27 Jul 2016 20:45:06 +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: JX2J0RfV3dW
6d09ec2faff8b3b047ba06da4e000a589981f7d5: 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> - Wed, 27 Jul 2016 13:38:46 -0700 - rev 393396
Push 24308 by jchan@mozilla.com at Wed, 27 Jul 2016 20:45:06 +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: AplFq8JRADm
aa4edeac1d702f58515037236b7a0588f14e3db2: Bug 1273706 - Part 20: Implement CSS.registerProperty and CSS.unregisterProperty. r?dbaron draft
Jonathan Chan <jchan@mozilla.com> - Wed, 27 Jul 2016 13:38:46 -0700 - rev 393395
Push 24308 by jchan@mozilla.com at Wed, 27 Jul 2016 20:45:06 +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: 8QlCsZmvQlq
5ebeabf021d1030a486537e27667ad2f2469475a: Bug 1273706 - Part 19: Update CSSVariableResolver for custom properties. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Wed, 27 Jul 2016 13:38:46 -0700 - rev 393394
Push 24308 by jchan@mozilla.com at Wed, 27 Jul 2016 20:45:06 +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: HsJW8G7gTJe
4e5a515f2835f490a1c38bff578ad05a7df06752: Bug 1273706 - Part 18: Add WebIDL bindings for the Properties & Values API. r?dbaron draft
Jonathan Chan <jchan@mozilla.com> - Wed, 27 Jul 2016 13:38:46 -0700 - rev 393393
Push 24308 by jchan@mozilla.com at Wed, 27 Jul 2016 20:45:06 +0000
Bug 1273706 - Part 18: Add WebIDL bindings for the Properties & Values API. r?dbaron MozReview-Commit-ID: 5ybQkqK5kpi
2395d724b17f0072062a73ad8bbe0e0b50ac5e24: Bug 1273706 - Part 17: Have CSSVariableValues store more information. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Wed, 27 Jul 2016 13:38:46 -0700 - rev 393392
Push 24308 by jchan@mozilla.com at Wed, 27 Jul 2016 20:45:06 +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: Cjy19U5m99q
987babdf0b2734dbc86be0107e4b3a004dbf9c21: Bug 1273706 - Part 16: Store important and unimportant declarations in one object. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Wed, 27 Jul 2016 13:38:46 -0700 - rev 393391
Push 24308 by jchan@mozilla.com at Wed, 27 Jul 2016 20:45:06 +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: FJlHoHzDyPG
ae5abcbc5eb856831a25e5534cfe5add4448fbfa: Bug 1273706 - Part 15: Add support for custom properties in supports conditions. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Wed, 27 Jul 2016 13:38:46 -0700 - rev 393390
Push 24308 by jchan@mozilla.com at Wed, 27 Jul 2016 20:45:06 +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: CLN3WbdqW0c
6bdae153a8ca9ddea838ce68e20ef4e9080d6fb1: Bug 1273706 - Part 14: Add the |ParseTypedValue| method for parsing typed CSS values. r?dbaron draft
Jonathan Chan <jchan@mozilla.com> - Wed, 27 Jul 2016 13:38:45 -0700 - rev 393389
Push 24308 by jchan@mozilla.com at Wed, 27 Jul 2016 20:45:06 +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: 1SrmOfIPmxJ
4fa31c60561a6d952eefed64b5a9c5b64bee3716: Bug 1273706 - Part 13: Add an aAllowVariableReferences parameter to ParseVariableDeclaration. r?dbaron draft
Jonathan Chan <jchan@mozilla.com> - Wed, 27 Jul 2016 13:38:45 -0700 - rev 393388
Push 24308 by jchan@mozilla.com at Wed, 27 Jul 2016 20:45:06 +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: H9kvXfqHalB
f40cbe5c44e45ae8a74c6db26deedec544bb57a3: Bug 1273706 - Part 12: Store custom property registrations on nsCSSParser. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Wed, 27 Jul 2016 13:38:45 -0700 - rev 393387
Push 24308 by jchan@mozilla.com at Wed, 27 Jul 2016 20:45:06 +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: 4pCOM8hiL4v
809317c546fb8a0cb3a1f57ffdaf88f32ea4b347: Bug 1273706 - Part 11: Store custom property registrations on the inner window (in nsGlobalWindow). r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Wed, 27 Jul 2016 13:38:45 -0700 - rev 393386
Push 24308 by jchan@mozilla.com at Wed, 27 Jul 2016 20:45:06 +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: 93Fayb4MBXx
eb8746bada2389a94b69308047d091896d7757e4: Bug 1273706 - Part 10: Add CSSVariableSyntax for representing the syntax of a custom property. r?dbaron draft
Jonathan Chan <jchan@mozilla.com> - Wed, 27 Jul 2016 13:38:45 -0700 - rev 393385
Push 24308 by jchan@mozilla.com at Wed, 27 Jul 2016 20:45:06 +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: IMLnnZ96KLl
4439cd976c91b084188eb0dbb972016023fc9b58: Bug 1273706 - Part 9: Add CSSComputedValues, like CSSVariableValues but for computed variable values. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Wed, 27 Jul 2016 13:38:45 -0700 - rev 393384
Push 24308 by jchan@mozilla.com at Wed, 27 Jul 2016 20:45:06 +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: HFiEKP5TjM5
6601206ea84fb676a11c47bee1b7631af6995daa: Bug 1273706 - Part 8: Add a new type for computed CSS values. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Wed, 27 Jul 2016 13:38:45 -0700 - rev 393383
Push 24308 by jchan@mozilla.com at Wed, 27 Jul 2016 20:45:06 +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: F9jn4w1s5J7
abf133270c398cc59424d61e6d42f58fbfb5e555: Bug 1273706 - Part 7: Add support to StyleAnimationValues for storing lists of values. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Wed, 27 Jul 2016 13:38:45 -0700 - rev 393382
Push 24308 by jchan@mozilla.com at Wed, 27 Jul 2016 20:45:06 +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: IkOnjVzUcfF
f930afbac8bed0c2baf270de3667b3860a1fd07b: Bug 1273706 - Part 6: Make nsCSSProperty castable to/from nsIAtom*. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Wed, 27 Jul 2016 13:38:45 -0700 - rev 393381
Push 24308 by jchan@mozilla.com at Wed, 27 Jul 2016 20:45:06 +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: 6PNwg174Lga
3ae9b97f5463ec1d065cc37e4c4d07cd80fed8e7: Bug 1273706 - Part 5: Factor out code for parsing resolutions in nsCSSParser. r?heycam draft
Jonathan Chan <jchan@mozilla.com> - Wed, 27 Jul 2016 13:38:44 -0700 - rev 393380
Push 24308 by jchan@mozilla.com at Wed, 27 Jul 2016 20:45:06 +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: o0kyeqVjQC
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip