Re: [w3c/webcomponents] observedStyles (#856)

I can provide some examples from our popup generic (used within dropdown menu, select, etc), whose layout logic occurs partly in ES. It supports a number of CSS properties, but four in particular are needed during the ES layout calc.

<details>
  <summary>
    CSS properties used in `<kn-popup>` that we observe from ES. (Snippet from docs.)
  </summary>

  ### --kn-popup-bleed-width

  Syntax: `<length> | <percentage>`
  Initial: `0px`

  This creates a sort of ‘phantom margin’: the layout process, when selecting a
  placement for the popup, will treat the containing boundaries being tested as if
  they were smaller by this amount.

  ### --kn-popup-origin-gap

  Syntax: `conterminous | <length>`
  Initial: `0px`

  As a length value, this specifies the distance between the origin and the popup
  on the vertical axis (which could be above or below).

  The keyword `conterminous` (look, it’s just perfect okay) produces no gap, like
  `0px`, but has additional effects:

  - Any corner of the popover which directly touches the origin box will have its
    border-radius set to zero. Keep in mind, again, that you do not always know
    in advance which corners these will be.
  - The edge of the popover which contacts the origin box will be clipped such
    that box-shadows cannot extend past it.
  - The expansion and collapse animations will scale only on the X axis.

  Note that the shadow clipping behavior may be unsuitable if your usage is one
  that does not guarantee the width of the popover is not wider than the origin
  element. For such cases, you may instead wish to set `--kn-popup-box-shadow` to
  none and place a drop shadow filter on the entire element instead.

  In the future, when `:state` is available, we may eliminate this option and
  instead provide state pseudoclasses to allow the consuming elements to respond
  to the various specific conditions mentioned here directly.

  ### --kn-popup-origin-priority

  Syntax: `[ center | end | left | right | start ] || [ top | bottom ]`
  Initial: `center bottom`

  This sets the preferred origin point from which the popover should seem to open.

  Vertical values are fairly straightforward. The _top_ value asks to prefer using
  the top edge of the origin element as the origin from which the popover expands,
  in this case upwards; _bottom_ is the opposite.

  Horizontal values may require more clarification. As with _top_, _left_ asks to
  prefer using the left edge of the origin element as the origin from which the
  popup expands, but such popup is extending _towards the right._

  ```
    ______
   |______|___  <--origin element
   |          | <--popover is wider than origin. it is using a left origin point.
   |__________|

  ```

  The `start` and `end` values behave the same as `left` and `right` in some order
  which depends on local directionality.

  The `center` option prefers alignment with the middle of the origin element, but
  it cannot ‘swap’ with anything else. With the other four horizontal values,
  their _opposite_ value is considered higher priority than falling back on
  arbitrary shifting. To understand why this should be, consider if the previous
  example’s left preference had been unsatisfiable:

  ```
        ______  |<--edge of screen — doesn’t fit opening from the left
       |______|_|_
       |        | |
       |________|_|
                |
  ```

  If the prioritized value aligned with a side, it is taken to indicate a
  preference not just for that specific side, but also for aligning with _a_ side
  period:

  ```
       SWAP     |    |     SHIFT    |
        ______  |    |      ______  |
    ___|______| |    |   __|______| |
   |          | | VS |  |          ||
   |__________| |    |  |__________||
                |    |              |
  ```

  ### --kn-popup-width-mode

  Syntax: `auto | min-origin | origin`
  Initial: `auto`

  The `origin` value expressly binds the width of the popup to the origin’s width.
  If the popup content actually doesn’t fit, it will overflow with a horizontal
  scrollbar.

  Given that, `min-origin` is what it sounds like: the popup can be larger than
  but not narrower than the origin.

</details>

Again it is not clear to me that this _should_ be part of the element API. I’d rather be realizing this example through the Houdini Layout API, using a registered worklet. But I think it’s a good illustration of a use case in this space.

Note that even if one does not consider it valuable to keep attributes concerned with semantics and css properties concerned with style, attributes would not help for items that require interpretation as CSS values (referencing vars, resolving lengths, etc).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/856#issuecomment-558391075