Bugzilla

> Ideally, it would be nice to get those rules directly from Inspector.getCSSStyleRules. Is this something that could be done?

Because it has different meaning.

`Inspector.getCSSStyleRules` returns the rules we are using for primary style. The is the rules we are using for rendering and what the users see on the browser. All rules inside `@starting-style` are not used, per spec.

`Inspector.getCSSStartingStyleRules` returns the rules we are using only for computing transitions. This value is used only for creating transitions and we don't use them in layout. These rules are not from the style we are using for the given element, so I intentionally use a separate logic.

If it is better for devtools to merge them together, e.g. if there are any matched rules inside `@starting-style`, we return the rules just like `Inspector.getCSSStartingStyleRules`; otherwise, we use the original logic from `Inspector.getCSSStyleRules`, I can provide a separate patch for it.

> Ideally, it would be nice to get those rules directly from Inspector.getCSSStyleRules. Is this something that could be done?

Because it has different meaning.

`Inspector.getCSSStyleRules` returns the rules we are using for primary style. The is the rules we are using for rendering and what the users see on the browser. All rules inside `@starting-style` are not used, per spec. This means any rules inside `@starting-style` **do not override** rules outside.

`Inspector.getCSSStartingStyleRules` returns the rules we are using only for computing transitions. This value is used only for creating transitions and we don't use them in layout. These rules are not from the style we are using for the given element, so I intentionally use a separate logic.

If it is better for devtools to merge them together, e.g. if there are any matched rules inside `@starting-style`, we return the rules just like `Inspector.getCSSStartingStyleRules`; otherwise, we use the original logic from `Inspector.getCSSStyleRules`, I can provide a separate patch for it.

> Ideally, it would be nice to get those rules directly from Inspector.getCSSStyleRules. Is this something that could be done?

Because it has different meaning.

`Inspector.getCSSStyleRules` returns the rules we are using for primary style. The is the rules we are using for rendering and what the users see on the browser. All rules inside `@starting-style` are not used, per spec. This means any rules inside `@starting-style` **do not override** rules outside.

`Inspector.getCSSStartingStyleRules` returns the rules we are using only for computing transitions. This value is used only for creating transitions and we don't use them in layout. I intentionally use a separate API because the cascade result may be different because the rules inside `@starting-style` overrides above rules outside.

If it is better for devtools to merge them together, e.g. if there are any matched rules inside `@starting-style`, we return the rules just like `Inspector.getCSSStartingStyleRules`; otherwise, we use the original logic from `Inspector.getCSSStyleRules`, I can provide a separate patch for it.

> Ideally, it would be nice to get those rules directly from Inspector.getCSSStyleRules. Is this something that could be done?

Because it has different meaning.

`Inspector.getCSSStyleRules` returns the rules we are using for primary style. The is the rules we are using for rendering and what the users see on the browser. All rules inside `@starting-style` are not used, per spec. This means any rules inside `@starting-style` **do not override** rules outside.

`Inspector.getCSSStartingStyleRules` returns the rules we are using only for computing transitions. This value is used only for creating transitions and we don't use them in layout. I intentionally use a separate API because the cascade result may be different: the rules inside `@starting-style` overrides above rules outside.

If it is better for devtools to merge them together, e.g. if there are any matched rules inside `@starting-style`, we return the rules just like `Inspector.getCSSStartingStyleRules`; otherwise, we use the original logic from `Inspector.getCSSStyleRules`, I can provide a separate patch for it.

> Ideally, it would be nice to get those rules directly from Inspector.getCSSStyleRules. Is this something that could be done?

Because it has different meaning.

`Inspector.getCSSStyleRules` returns the rules we are using for primary style. The is the rules we are using for rendering and what the users see on the browser. All rules inside `@starting-style` are not used, per spec. This means any rules inside `@starting-style` **do not override** rules outside.

`Inspector.getCSSStartingStyleRules` returns the rules we are using only for computing transitions. This value is used only for creating transitions and we don't use them in layout. I intentionally use a separate API because the cascade result may be different: the rules inside `@starting-style` may overrides rules outside, per cascade order.

If it is better for devtools to merge them together, e.g. if there are any matched rules inside `@starting-style`, we return the rules just like `Inspector.getCSSStartingStyleRules`; otherwise, we use the original logic from `Inspector.getCSSStyleRules`, I can provide a separate patch for it.

> Ideally, it would be nice to get those rules directly from Inspector.getCSSStyleRules. Is this something that could be done?

Because it has different meaning.

`Inspector.getCSSStyleRules` returns the rules we are using for primary style. The is the rules we are using for rendering and what the users see on the browser. All rules inside `@starting-style` are not used, per spec. This means any rules inside `@starting-style` **do not override** rules outside.

`Inspector.getCSSStartingStyleRules` returns the rules we are using only for computing transitions. This value is used only for creating transitions and we don't use them in layout. I intentionally use a separate API because the cascade result may be different: the rules inside `@starting-style` may overrides rules outside, per cascade order.

If it is better for devtools to merge them together, e.g. if there are any matched rules inside `@starting-style`, we return the rules just like `Inspector.getCSSStartingStyleRules`; otherwise, we use the original logic from `Inspector.getCSSStyleRules`, I can provide a separate patch for it.

Updated: Please check the new patch I uploaded. However, it may confuse people because the ignored rules are only ignored in starting style, instead of the computed values of the given element.

> Ideally, it would be nice to get those rules directly from Inspector.getCSSStyleRules. Is this something that could be done?

Because it has different meaning.

`Inspector.getCSSStyleRules` returns the rules we are using for primary style. The is the rules we are using for rendering and what the users see on the browser. All rules inside `@starting-style` are not used, per spec. This means any rules inside `@starting-style` **do not override** rules outside.

`Inspector.getCSSStartingStyleRules` returns the rules we are using only for computing transitions. This value is used only for creating transitions and we don't use them in layout. I intentionally use a separate API because the cascade result may be different: the rules inside `@starting-style` may overrides rules outside, per cascade order.

If it is better for devtools to merge them together, e.g. if there are any matched rules inside `@starting-style`, we return the rules just like `Inspector.getCSSStartingStyleRules`; otherwise, we use the original logic from `Inspector.getCSSStyleRules`, I can provide a separate patch for it.

Updated: Please check the new patch I uploaded. However, it may confuse people because the ignored rule are only ignored in starting style, per the example in comment 13. The computed values of the given element should not ignore this rule.

> Ideally, it would be nice to get those rules directly from Inspector.getCSSStyleRules. Is this something that could be done?

Because it has different meaning.

`Inspector.getCSSStyleRules` returns the rules we are using for primary style. The is the rules we are using for rendering and what the users see on the browser. All rules inside `@starting-style` are not used, per spec. This means any rules inside `@starting-style` **do not override** rules outside.

`Inspector.getCSSStartingStyleRules` returns the rules we are using only for computing transitions. This value is used only for creating transitions and we don't use them in layout. I intentionally use a separate API because the cascade result may be different: the rules inside `@starting-style` may overrides rules outside, per cascade order.

If it is better for devtools to merge them together, e.g. if there are any matched rules inside `@starting-style`, we return the rules just like `Inspector.getCSSStartingStyleRules`; otherwise, we use the original logic from `Inspector.getCSSStyleRules`, I can provide a separate patch for it.

Updated: Please check the new patch I uploaded. However, it may confuse people because the ignored rule is ignored only in starting style, per the example in comment 13. The computed values of the given element should not ignore this rule.

> Ideally, it would be nice to get those rules directly from Inspector.getCSSStyleRules. Is this something that could be done?

Because it has different meaning.

`Inspector.getCSSStyleRules` returns the rules we are using for primary style. The is the rules we are using for rendering and what the users see on the browser. All rules inside `@starting-style` are not used, per spec. This means any rules inside `@starting-style` **do not override** rules outside.

`Inspector.getCSSStartingStyleRules` returns the rules we are using only for computing transitions. This value is used only for creating transitions and we don't use them in layout. I intentionally use a separate API because the cascade result may be different: the rules inside `@starting-style` may overrides rules outside, per cascade order.

If it is better for devtools to merge them together, e.g. if there are any matched rules inside `@starting-style`, we return the rules just like `Inspector.getCSSStartingStyleRules`; otherwise, we use the original logic from `Inspector.getCSSStyleRules`, I can provide a separate patch for it.

Updated: Please check the new patch I uploaded.
```
div {
  transition: all 1s linear;
}

div {
  background-color: transparent; /* This is ignored for starting style, but is not ignored in the computed style. */
}

@starting-style {
  div {
    border-color: cyan;
    background-color: blue;
  }
}
```
However, it may confuse people because the ignored rule is ignored only in starting style, per the example above.

> Ideally, it would be nice to get those rules directly from Inspector.getCSSStyleRules. Is this something that could be done?

Because it has different meaning.

`Inspector.getCSSStyleRules` returns the rules we are using for primary style. The is the rules we are using for rendering and what the users see on the browser. All rules inside `@starting-style` are not used, per spec. This means any rules inside `@starting-style` **do not override** rules outside.

`Inspector.getCSSStartingStyleRules` returns the rules we are using only for computing transitions. This value is used only for creating transitions and we don't use them in layout. I intentionally use a separate API because the cascade result may be different: the rules inside `@starting-style` may overrides rules outside, per cascade order.

If it is better for devtools to merge them together, e.g. if there are any matched rules inside `@starting-style`, we return the rules just like `Inspector.getCSSStartingStyleRules`; otherwise, we use the original logic from `Inspector.getCSSStyleRules`, I can provide a separate patch for it.

Updated: Please check the new patch I uploaded.
Note:
```
div {
  transition: all 1s linear;
}

div {
  background-color: transparent; /* This is ignored for starting style, but is not ignored in the computed style. */
}

@starting-style {
  div {
    border-color: cyan;
    background-color: blue;
  }
}
```
However, it may confuse people because the ignored rule is ignored only in starting style, per the example above.

> Ideally, it would be nice to get those rules directly from Inspector.getCSSStyleRules. Is this something that could be done?

Because it has different meaning.

`Inspector.getCSSStyleRules` returns the rules we are using for primary style. The is the rules we are using for rendering and what the users see on the browser. All rules inside `@starting-style` are not used, per spec. This means any rules inside `@starting-style` **do not override** rules outside.

`Inspector.getCSSStartingStyleRules` returns the rules we are using only for computing transitions. This value is used only for creating transitions and we don't use them in layout. I intentionally use a separate API because the cascade result may be different: the rules inside `@starting-style` may overrides rules outside, per cascade order.

If it is better for devtools to merge them together, e.g. if there are any matched rules inside `@starting-style`, we return the rules just like `Inspector.getCSSStartingStyleRules`; otherwise, we use the original logic from `Inspector.getCSSStyleRules`, I can provide a separate patch for it.

Updated: Please check the new patch I uploaded.
Note:
```
div {
  transition: all 1s linear;
}

div {
  background-color: transparent; /* This is ignored for starting style, but is not ignored in the computed style. */
}

@starting-style {
  div {
    border-color: cyan;
    background-color: blue;
  }
}
```
In this example, it may confuse people because the ignored rule is ignored only in starting style, per the example above.

> Ideally, it would be nice to get those rules directly from Inspector.getCSSStyleRules. Is this something that could be done?

Because it has different meaning.

`Inspector.getCSSStyleRules` returns the rules we are using for primary style. The is the rules we are using for rendering and what the users see on the browser. All rules inside `@starting-style` are not used, per spec. This means any rules inside `@starting-style` **do not override** rules outside.

`Inspector.getCSSStartingStyleRules` returns the rules we are using only for computing transitions. This value is used only for creating transitions and we don't use them in layout. I intentionally use a separate API because the cascade result may be different: the rules inside `@starting-style` may overrides rules outside, per cascade order.

If it is better for devtools to merge them together, e.g. if there are any matched rules inside `@starting-style`, we return the rules just like `Inspector.getCSSStartingStyleRules`; otherwise, we use the original logic from `Inspector.getCSSStyleRules`, I can provide a separate patch for it.

Updated: Please check the new patch I uploaded.
Note:
```
div {
  transition: all 1s linear;
}

div {
  ~background-color: transparent;~ /* This is ignored for starting style, but is not ignored in the computed style. */
}

@starting-style {
  div {
    border-color: cyan;
    background-color: blue;
  }
}
```
In this example, it may confuse people because the ignored rule is ignored only in starting style.

> Ideally, it would be nice to get those rules directly from Inspector.getCSSStyleRules. Is this something that could be done?

Because it has different meaning.

`Inspector.getCSSStyleRules` returns the rules we are using for primary style. The is the rules we are using for rendering and what the users see on the browser. All rules inside `@starting-style` are not used, per spec. This means any rules inside `@starting-style` **do not override** rules outside.

`Inspector.getCSSStartingStyleRules` returns the rules we are using only for computing transitions. This value is used only for creating transitions and we don't use them in layout. I intentionally use a separate API because the cascade result may be different: the rules inside `@starting-style` may overrides rules outside, per cascade order.

If it is better for devtools to merge them together, e.g. if there are any matched rules inside `@starting-style`, we return the rules just like `Inspector.getCSSStartingStyleRules`; otherwise, we use the original logic from `Inspector.getCSSStyleRules`, I can provide a separate patch for it.

Updated: Please check the new patch I uploaded.
Note:
```
div {
  transition: all 1s linear;
}

div {
  ~background-color: transparent;~ /* This is ignored in starting style, but is not ignored in the computed style. */
}

@starting-style {
  div {
    border-color: cyan;
    background-color: blue;
  }
}
```
In this example, it may confuse people because the ignored rule is ignored only in starting style.