Memory padding when storing data+flags on `ComputedStyle`

[Koji Ishii]

Hi style experts,

I'm thinking about extending `text-indent` from:

[ <length-percentage> ]

to:

[ <length-percentage> ] && hanging? && each-line?

To do this, I can create:

class TextIndent {

  Length length_;

  bool is_each_line_;

  bool is_hanging_;

};

but this allocates 2 bytes padding for each `ComputedStyle`.

I can think of a few ways to avoid this, such as:

1. Serialize to a bit stream of 10 bits, and declare as `field_size: 10`.
2. Add bits to `computed_style_extra_fields.json5` and somehow combine with the `Length` in getter/setters.

These options look a bit tricky. Is there a best practice to do this?

I checked existing examples. For example, `StyleIntrinsicLength` is 16 bytes. Out of the 16 bytes, 7 bytes are padding (2 in `Length`, 3 in `optional`, 2 in `StyleIntrinsicLength`). Do we prefer readability over reducing these padding?

[Anders Hartvoll Ruud]

On Wed, Nov 19, 2025 at 8:56 AM Koji Ishii <ko...@chromium.org> wrote:

Hi style experts,

I'm thinking about extending `text-indent` from:

[ <length-percentage> ]

to:

[ <length-percentage> ] && hanging? && each-line?

To do this, I can create:

class TextIndent {

  Length length_;

  bool is_each_line_;

  bool is_hanging_;

};

but this allocates 2 bytes padding for each `ComputedStyle`.

So we are talking about this field, right?

    {
      name: "text-indent",
      property_methods: ["ParseSingleValue", "CSSValueFromComputedStyleInternal"],
      interpolable: true,
      inherited: true,
      field_group: "*",
      field_template: "<length>",
      default_value: "Length::Fixed()",
      style_builder_custom_functions: ["value"],
      typedom_types: ["Length", "Percentage"],
      valid_for_page_context: true,
      invalidate: ["layout", "paint"],
      affected_by_zoom: true,
    },

On the top-level of ComputedStyle, there are indeed some cases where we do one of the tricks you're thinking about, e.g. storing a single bit out-of-line to avoid the padding that would be needed for e.g. sizeof(Length + 1 bit). However, we normally don't do that for fields that are buried in rare data (field_group:"*"). I prefer readability/ergonomics here; just create the TextIdent class the "naive" way.

 

I can think of a few ways to avoid this, such as:

1. Serialize to a bit stream of 10 bits, and declare as `field_size: 10`.
2. Add bits to `computed_style_extra_fields.json5` and somehow combine with the `Length` in getter/setters.

These options look a bit tricky. Is there a best practice to do this?

I checked existing examples. For example, `StyleIntrinsicLength` is 16 bytes. Out of the 16 bytes, 7 bytes are padding (2 in `Length`, 3 in `optional`, 2 in `StyleIntrinsicLength`). Do we prefer readability over reducing these padding?

--
You received this message because you are subscribed to the Google Groups "style-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to style-dev+...@chromium.org.
To view this discussion, visit https://groups.google.com/a/chromium.org/d/msgid/style-dev/CAHe_1dK2GUP9y9rQSycQjN6j6xyDdtkpucXFmE%3Dtun8GYtT9Eg%40mail.gmail.com.

[Koji Ishii]

Thank you for the prompt response.

Only top-level properties are worth the complexity, that makes sense.

The `text-indent` is 35% used, so we probably want to keep it at top-level. I'm interested in experimenting with all properties used only in line-breaker and inline-layout into a group, but that's a separate discussion.

Another possible idea is to create internal longhands and make `text-indent` a shorthand of them. But that'd change web-visible things of the property, so it doesn't seem to work.

2025年11月19日(水) 18:55 Anders Hartvoll Ruud <and...@chromium.org>:

[Anders Hartvoll Ruud]

On Wed, Nov 19, 2025 at 11:08 AM Koji Ishii <ko...@chromium.org> wrote:

Thank you for the prompt response.

Only top-level properties are worth the complexity, that makes sense.

The `text-indent` is 35% used, so we probably want to keep it at top-level.

Maybe, but we should not draw that conclusion based on those metrics alone. It just means that 35% of page loads use text-indent at least once, on any element. It does not mean that 35% of ComputedStyle instances have this field set, or change this field vs. the parent style.

 

I'm interested in experimenting with all properties used only in line-breaker and inline-layout into a group, but that's a separate discussion.

If they are likely to be used together, that could make sense.

 

Another possible idea is to create internal longhands and make `text-indent` a shorthand of them. But that'd change web-visible things of the property, so it doesn't seem to work.

Yeah, that's probably more hassle than storing the bits out-of-line.