I think a good "conservative set" would be:

- left, top, right, bottom
- margin-left, margin-top, margin-right, margin-bottom
- padding-left, padding-top, padding-right, padding-bottom
- border-left-width, border-top-width, border-right-width, border-bottom-width
- width, min-width, max-width, height, min-height, max-height
- display, position, float, clear, overflow, transform
- shorthands for the above

If we're going with the minimal set, we can exclude things that aren't strictly needed for web compat.

I think we don't need the border-*-width, right? Do we need display, float, clear and overflow?

Technically, of the margin/padding ones, we only need margin-top and padding-top, but I think it would be too weird to only include one edge.

So, that would leave us with:
- left, top, right, bottom
- margin-left, margin-top, margin-right, margin-bottom
- padding-left, padding-top, padding-right, padding-bottom
- width, min-width, max-width, height, min-height, max-height
- position, transform
- shorthands for the above

I like that we're ending up with a short list. That makes it very clear that this is a quirk needed for web compatibility. If we were designing the platform from scratch, we would not do SANACLAP at all and would just have you use overflow-anchor appropriately.

SGTM.  I had included display, float, clear, and overflow because they feel conceptually similar to pulling things in/out of flow, but I don't think we saw any sites that need them suppressed.

I think change in the display property should also disable anchoring. Though we haven't found specific examples of breakages, I can see it being a common way to hide headers on scroll down. For e.g if WSJ's code was slightly different, it would be stuck in the js loop if we didn't suppress display changes ( issue 652377 ).

Also, because the list has gone down quite a bit, it would be valuable to get some insights into changes that are causing this suppression. We could change the m_scrollAnchorDisablingPropertyChanged variable to hold bits representing the type of change (roughly 1 bit for each bullet in comment 4). This is obviously not scalable if we add more CSS properties and I don't understand the implications of adding more bits to the every LayoutObject on a webpage, but I see other variables greater than 1 bit. WDYT?  

It actually doesn't make sense to have "display" because changes to "display" will destroy or recreate the LayoutObject.  The same anchor cannot exist both before and after a change to "display" on itself or one of its ancestors.

I think we should try not to add more bits to LayoutObject.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/85861c2144feef2c65bb34f3bcc36e3d57180cb5

commit 85861c2144feef2c65bb34f3bcc36e3d57180cb5
Author: ymalik <ymalik@chromium.org>
Date: Wed Oct 26 04:03:04 2016

Refine the criteria for ScrollAnchor-disabling properties

The change of the following CSS properties on an anchor node's ancestor
causes anchoring suppresion:
- left, top, right, bottom
- margin-left, margin-top, margin-right, margin-bottom
- padding-left, padding-top, padding-right, padding-bottom
- width, min-width, max-width, height, min-height, max-height
- position, transform
- shorthands for the above

BUG= 658834 

Review-Url: https://codereview.chromium.org/2450033002
Cr-Commit-Position: refs/heads/master@{#427584}

[modify] https://crrev.com/85861c2144feef2c65bb34f3bcc36e3d57180cb5/third_party/WebKit/Source/core/style/ComputedStyle.cpp
[modify] https://crrev.com/85861c2144feef2c65bb34f3bcc36e3d57180cb5/third_party/WebKit/Source/core/style/ComputedStyle.h