brandonmcconnell has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-values-4] Small/Large/Dynamic Logical CSS Units == ### Abstract This proposal introduces new CSS units that are based on the logical inline and block dimensions of the viewport, rather than the its width and height. This aligns with the growing trend towards logical, layout-agnostic styles in modern web development. ### Motivation Current CSS units like `vw`/`vh`/`lvw`/`lvh`/`dvw`/`dvh` are based on the width and height of the viewport, which can be problematic when dealing with layouts that are not constrained to a single axis (e.g. responsive designs, rotated screens, internationalization, etc.). This proposal aims to provide a more flexible and logical way to size elements based on the inline and block dimensions of the viewport. ### Proposed Units | | block | inline | |:-------|:-------|:-------| | **small** | `svb` | `svi` | | **large** | `lvb` | `lvi` | | **dynamic** | `dvb` | `dvi` | | Unit | Relative to | |:-------|:-------| | `svb`, `svi` | 1% of the small viewport's width and height, respectively. | | `lvb`, `lvi` | 1% of the large viewport's width and height, respectively. | | `dvb`, `dvi` | 1% of the dynamic viewport's width and height, respectively. | ### Use Cases - Sizing elements based on the logical dimensions of the viewport, rather than the viewport's dimensions. - Creating layout-agnostic styles that work well in both landscape and portrait orientations. - Designing responsive components that can adapt to changes in the viewport's logical dimensions. ### Conclusion This proposal aims to introduce a more logical and flexible approach to CSS units, aligning with the growing trend towards layout-agnostic web design. By focusing on the inline and block dimensions of the viewport, rather than the viewport's width and height, developers can create more robust and adaptable styles for a wide range of device and layout scenarios. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10157 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
brandonmcconnell has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-values-4] Small/Large/Dynamic Logical CSS Units == ### Abstract This proposal introduces new CSS units that are based on the logical inline and block dimensions of the viewport, rather than the its width and height. This aligns with the growing trend towards logical, layout-agnostic styles in modern web development. ### Motivation Current CSS units like `vw`/`vh`/`lvw`/`lvh`/`dvw`/`dvh` are based on the width and height of the viewport, which can be problematic when dealing with layouts that are not constrained to a single axis (e.g. responsive designs, rotated screens, internationalization, etc.). This proposal aims to provide a more flexible and logical way to size elements based on the inline and block dimensions of the viewport. ### Proposed Units | | block | inline | |:-------|:-------|:-------| | **small** | `svb` | `svi` | | **large** | `lvb` | `lvi` | | **dynamic** | `dvb` | `dvi` | | Unit | Relative to | |:-------|:-------| | `svb`, `svi` | 1% of the small viewport's width and height, respectively. | | `lvb`, `lvi` | 1% of the large viewport's width and height, respectively. | | `dvb`, `dvi` | 1% of the dynamic viewport's width and height, respectively. | ### Use Cases - Sizing elements based on the logical dimensions of the viewport, rather than the viewport's dimensions. - Creating layout-agnostic styles that work well in both landscape and portrait orientations. - Designing responsive components that can adapt to changes in the viewport's logical dimensions. ### Conclusion This proposal aims to introduce a more logical and flexible approach to CSS units, aligning with the growing trend towards layout-agnostic web design. By focusing on the inline and block dimensions of the viewport, rather than the viewport's width and height, developers can create more robust and adaptable styles for a wide range of device and layout scenarios. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10157 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
brandonmcconnell has just created a new issue for https://github.com/w3c/csswg-drafts: == [mediaqueries-5] Logical Media Queries == ### Abstract This proposal introduces new media queries that are based on the logical inline and block dimensions of the viewport, rather than width and height. This aligns with the growing support for logical styles in modern web development. ### Motivation Current CSS media queries are based on the width and height of the viewport, which can be problematic when dealing with layouts that are not constrained to a single axis (e.g. responsive designs, rotated screens, internationalization, etc.). This proposal aims to provide a more flexible and logical way to target styles based on the inline and block dimensions of the viewport. ### Proposed Media Queries <table> <tr> <th></th> <th>block</th> <th>inline</th> </tr> <tr> <th>range</th> <td><code>(min-block: <size>)</code><br><code>(max-block: <size>)</code></td> <td><code>(min-inline: <size>)</code><br><code>(max-inline: <size>)</code></td> </tr> <tr> <th>operator</th> <td><code>(block > <size>)</code><br><code>(block >= <size>)</code><br><code>(block < <size>)</code><br><code>(block <= <size>)</code></td> <td><code>(inline > <size>)</code><br><code>(inline >= <size>)</code><br><code>(inline < <size>)</code><br><code>(inline <= <size>)</code></td> </tr> </table> ### Use Cases - Targeting styles based on the logical dimensions of the viewport, rather than the static w/h viewport dimensions - Creating layout-agnostic styles that work well in both landscape and portrait orientations - Designing responsive components that can adapt to changes in the viewport's logical dimensions, especially useful in the case of internationalization ### Conclusion This proposal aims to introduce a more logical and flexible approach to media queries in CSS, aligning with the growing trend towards layout-agnostic web design. By focusing on the inline and block dimensions of the viewport, rather than the physical width and height, developers can create more robust and adaptable styles for a wide range of device and layout scenarios. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10156 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
brandonmcconnell has just created a new issue for https://github.com/w3c/csswg-drafts: == [mediaqueries-5] Logical Media Queries == ### Abstract This proposal introduces new media queries that are based on the logical inline and block dimensions of the viewport, rather than width and height. This aligns with the growing support for logical styles in modern web development. ### Motivation Current CSS media queries are based on the width and height of the viewport, which can be problematic when dealing with layouts that are not constrained to a single axis (e.g. responsive designs, rotated screens, internationalization, etc.). This proposal aims to provide a more flexible and logical way to target styles based on the inline and block dimensions of the viewport. ### Proposed Media Queries <table> <tr> <th></th> <th>block</th> <th>inline</th> </tr> <tr> <th>range</th> <td><code>(min-block: <size>)</code><br><code>(max-block: <size>)</code></td> <td><code>(min-inline: <size>)</code><br><code>(max-inline: <size>)</code></td> </tr> <tr> <th>operator</th> <td><code>(block > <size>)</code><br><code>(block >= <size>)</code><br><code>(block < <size>)</code><br><code>(block <= <size>)</code></td> <td><code>(inline > <size>)</code><br><code>(inline >= <size>)</code><br><code>(inline < <size>)</code><br><code>(inline <= <size>)</code></td> </tr> </table> ### Use Cases - Targeting styles based on the logical dimensions of the viewport, rather than the static w/h viewport dimensions - Creating layout-agnostic styles that work well in both landscape and portrait orientations - Designing responsive components that can adapt to changes in the viewport's logical dimensions, especially useful in the case of internationalization ### Conclusion This proposal aims to introduce a more logical and flexible approach to media queries in CSS, aligning with the growing trend towards layout-agnostic web design. By focusing on the inline and block dimensions of the viewport, rather than the physical width and height, developers can create more robust and adaptable styles for a wide range of device and layout scenarios. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10156 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
One note is that the current spec draft just defines `calc-size()` and doesn't say which properties accept it. I think we do need to agree on which properties accept it. I think the list is probably something like this: * `width`, `height`, [`block-size`, `inline-size`](https://drafts.csswg.org/css-logical-1/#dimension-properties) (intrinsic sizing keywords and `auto`) * `min-width`, `min-height`, `min-block-size`, `min-inline-size` (intrinsic sizing keywords and probably `auto`) * `max-width`, `max-height`, `max-block-size` `min-block-size` (intrinsic sizing keywords but *not* `none`) * [`flex-basis`](https://drafts.csswg.org/css-flexbox/#flex-basis-property) (intrinsic sizing keywords and `auto` and `content`??) * the `<track-breadth>` and `<inflexible-breadth>` productions for [`grid-template-rows` and `grid-template-columns`](https://drafts.csswg.org/css-grid-1/#track-sizing) (`min-content` and `max-content` and, for the latter, `auto`) * I don't think there's a need to allow `fr` units in `calc-size()` since they already allow math. (It could be nice for completeness but it also doesn't feel worth it.) (My current prototype has just been for `width`, `height`, `min-width`, `min-height`, `max-width` and `max-height`.) It's not clear to me whether the grid or flex parts have important use cases, though. -- GitHub Notification of comment by dbaron Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/626#issuecomment-2025918637 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Use the right data types for `types` == Based on CSSWG resolution: https://github.com/w3c/csswg-drafts/issues/10114#issuecomment-2023217450 Closes #10114 See https://github.com/w3c/csswg-drafts/pull/10155 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Use the right data types for `types` == Based on CSSWG resolution: https://github.com/w3c/csswg-drafts/issues/10114#issuecomment-2023217450 Closes #10114 See https://github.com/w3c/csswg-drafts/pull/10155 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Use the right data types for `types` == Based on CSSWG resolution: https://github.com/w3c/csswg-drafts/issues/10114#issuecomment-2023217450 Closes #10114 See https://github.com/w3c/csswg-drafts/pull/10155 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Use the right data types for `types` == Based on CSSWG resolution: https://github.com/w3c/csswg-drafts/issues/10114#issuecomment-2023217450 Closes #10114 See https://github.com/w3c/csswg-drafts/pull/10155 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Use the right data types for `types` == Based on CSSWG resolution: https://github.com/w3c/csswg-drafts/issues/10114#issuecomment-2023217450 Closes #10114 See https://github.com/w3c/csswg-drafts/pull/10155 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Use the right data types for `types` == Based on CSSWG resolution: https://github.com/w3c/csswg-drafts/issues/10114#issuecomment-2023217450 Closes #10114 See https://github.com/w3c/csswg-drafts/pull/10155 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Use the right data types for `types` == Based on CSSWG resolution: https://github.com/w3c/csswg-drafts/issues/10114#issuecomment-2023217450 Closes #10114 See https://github.com/w3c/csswg-drafts/pull/10155 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Use the right data types for `types` == Based on CSSWG resolution: https://github.com/w3c/csswg-drafts/issues/10114#issuecomment-2023217450 Closes #10114 See https://github.com/w3c/csswg-drafts/pull/10155 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Use the right data types for `types` == Based on CSSWG resolution: https://github.com/w3c/csswg-drafts/issues/10114#issuecomment-2023217450 Closes #10114 See https://github.com/w3c/csswg-drafts/pull/10155 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Use the right data types for `types` == Based on CSSWG resolution: https://github.com/w3c/csswg-drafts/issues/10114#issuecomment-2023217450 Closes #10114 See https://github.com/w3c/csswg-drafts/pull/10155 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Use the right data types for `types` == Based on CSSWG resolution: https://github.com/w3c/csswg-drafts/issues/10114#issuecomment-2023217450 Closes #10114 See https://github.com/w3c/csswg-drafts/pull/10155 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Use the right data types for `types` == Based on CSSWG resolution: https://github.com/w3c/csswg-drafts/issues/10114#issuecomment-2023217450 Closes #10114 See https://github.com/w3c/csswg-drafts/pull/10155 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-align] Inconsistent fallback alignments for space-between and space-around/evenly == https://drafts.csswg.org/css-align/#distribution-values | Alignment | Fallback | | - | - | | `space-between` | `flex-start` | | `space-around` | `safe center` | | `space-evenly` | `safe center` | As per https://drafts.csswg.org/css-align/#valdef-overflow-position-safe, `safe center` will basically behave as `start`, which differs from the `flex-start` of `space-between`. Blink seems to treat all of them as `flex-start` ```html <!DOCTYPE html> <style> .flex { display: inline-flex; flex-wrap: wrap-reverse; flex-direction: row-reverse; height: 100px; width: 100px; border: solid; margin: 30px; } .flex::before { content: ""; height:125%; width: 125%; flex-shrink: 0; z-index: -1; background: cyan; } </style> <div class="flex" style="place-content: space-between"></div> <div class="flex" style="place-content: space-around"></div> <div class="flex" style="place-content: space-evenly"></div> ``` ![](https://github.com/w3c/csswg-drafts/assets/7477678/d3127907-f117-4e2f-afdd-715199011040) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10154 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-align] Inconsistent fallback alignments for space-between and space-around/evenly == https://drafts.csswg.org/css-align/#distribution-values | Alignment | Fallback | | - | - | | `space-between` | `flex-start` | | `space-around` | `safe center` | | `space-evenly` | `safe center` | As per https://drafts.csswg.org/css-align/#valdef-overflow-position-safe, `safe center` will basically behave as `start`, which differs from the `flex-start` of `space-between`. Blink seems to treat all of them as `flex-start` ```html <!DOCTYPE html> <style> .flex { display: inline-flex; flex-wrap: wrap-reverse; flex-direction: row-reverse; height: 100px; width: 100px; border: solid; margin: 30px; } .flex::before { content: ""; height:125%; width: 125%; flex-shrink: 0; z-index: -1; background: cyan; } </style> <div class="flex" style="place-content: space-between"></div> <div class="flex" style="place-content: space-around"></div> <div class="flex" style="place-content: space-evenly"></div> ``` ![](https://github.com/w3c/csswg-drafts/assets/7477678/d3127907-f117-4e2f-afdd-715199011040) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10154 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-align] Inconsistent fallback alignments for space-between and space-around/evenly == https://drafts.csswg.org/css-align/#distribution-values | Alignment | Fallback | | - | - | | `space-between` | `flex-start` | | `space-around` | `safe center` | | `space-evenly` | `safe center` | As per https://drafts.csswg.org/css-align/#valdef-overflow-position-safe, `safe center` will basically behave as `start`, which differs from the `flex-start` of `space-between`. Blink seems to treat all of them as `flex-start` ```html <!DOCTYPE html> <style> .flex { display: inline-flex; flex-wrap: wrap-reverse; flex-direction: row-reverse; height: 100px; width: 100px; border: solid; margin: 30px; } .flex::before { content: ""; height:125%; width: 125%; flex-shrink: 0; z-index: -1; background: cyan; } </style> <div class="flex" style="place-content: space-between"></div> <div class="flex" style="place-content: space-around"></div> <div class="flex" style="place-content: space-evenly"></div> ``` ![](https://github.com/w3c/csswg-drafts/assets/7477678/d3127907-f117-4e2f-afdd-715199011040) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10154 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr closed this issue. See https://github.com/w3c/csswg-drafts/issues/9874 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Allow pseudo-element with class and no * == Based on resolution: https://github.com/w3c/csswg-drafts/issues/9874#issuecomment-2023235242 Closes #9874 See https://github.com/w3c/csswg-drafts/pull/10153 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
chriskirknielsen has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color] Allow light-dark() to be used for any property, not just color == I am excited to see that [`light-dark()`](https://drafts.csswg.org/css-color-5/#light-dark) is landing in more browsers, as I believe it is a great way to prevent repetition when creating a light/dark theme override toggle, which by default looks at user preferences. The spec only allows it for colour-based properties at this point, which is fair given this is new. I would, however, like to see this expanded to be available for any property. In some cases, light and dark themes are not simply a colour change, but a different look and feel altogether. As such, things like typography (which, at a basic level, could also benefit weight adjustment on light vs dark background!) and other effects could leverage `light-dark()` to make theming easier. A simple example would be the following: in a "light" context, a card component might have a drop shadow, like layers of paper, whereas in a dark context, you might want to have more of a neon glow effect. Currently, you would need to do something like this: (you can simplify this, but I'm being verbose just to drive the point home) ```css :root { color-scheme: light dark; --light-fx: 0 4px 3px #3218; --dark-fx 0 1px 8px #0ff; } /* Defaults */ @media (prefers-color-scheme: light) { html:not([data-theme]) { --fx: var(--light-fx); } } @media (prefers-color-scheme: dark) { html:not([data-theme]) { --fx: var(--dark-fx); } } /* Overrides */ html[data-theme=light] { --fx: var(--light-fx); } html[data-theme=dark] { --fx: var(--dark-fx); } .card { box-shadow: var(--fx); } ``` This would be very easy to implement using `light-dark()`: ```css :root { color-scheme: light dark; --light-fx: 0 4px 3px #3218; --dark-fx 0 1px 8px #0ff; } html[data-theme=light] { color-scheme: light; } html[data-theme=dark] { color-scheme: dark; } .card { box-shadow: light-dark(var(--light-fx), var(--dark-fx)); } ``` If this were possible, it would considerably reduce the amount of code I need to write for theming, as I still need to write some things as either inside a user-preference media query and repeat that in a data-attribute-based selector on the root. If this is already planned, I did not find a reference in the spec or by having a look at recent issues on here. Thank you! Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10152 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
chriskirknielsen has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color] Allow light-dark() to be used for any property, not just color == I am excited to see that [`light-dark()`](https://drafts.csswg.org/css-color-5/#light-dark) is landing in more browsers, as I believe it is a great way to prevent repetition when creating a light/dark theme override toggle, which by default looks at user preferences. The spec only allows it for colour-based properties at this point, which is fair given this is new. I would, however, like to see this expanded to be available for any property. In some cases, light and dark themes are not simply a colour change, but a different look and feel altogether. As such, things like typography (which, at a basic level, could also benefit weight adjustment on light vs dark background!) and other effects could leverage `light-dark()` to make theming easier. A simple example would be the following: in a "light" context, a card component might have a drop shadow, like layers of paper, whereas in a dark context, you might want to have more of a neon glow effect. Currently, you would need to do something like this: (you can simplify this, but I'm being verbose just to drive the point home) ```css :root { color-scheme: light dark; --light-fx: 0 4px 3px #3218; --dark-fx 0 1px 8px #0ff; } /* Defaults */ @media (prefers-color-scheme: light) { html:not([data-theme]) { --fx: var(--light-fx); } } @media (prefers-color-scheme: dark) { html:not([data-theme]) { --fx: var(--dark-fx); } } /* Overrides */ html[data-theme=light] { --fx: var(--light-fx); } html[data-theme=dark] { --fx: var(--dark-fx); } .card { box-shadow: var(--fx); } ``` This would be very easy to implement using `light-dark()`: ```css :root { color-scheme: light dark; --light-fx: 0 4px 3px #3218; --dark-fx 0 1px 8px #0ff; } html[data-theme=light] { color-scheme: light; } html[data-theme=dark] { color-scheme: dark; } .card { box-shadow: light-dark(var(--light-fx), var(--dark-fx)); } ``` If this were possible, it would considerably reduce the amount of code I need to write for theming, as I still need to write some things as either inside a user-preference media query and repeat that in a data-attribute-based selector on the root. If this is already planned, I did not find a reference in the spec or by having a look at recent issues on here. Thank you! Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10152 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
chriskirknielsen has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color] Allow light-dark() to be used for any property, not just color == I am excited to see that [`light-dark()`](https://drafts.csswg.org/css-color-5/#light-dark) is landing in more browsers, as I believe it is a great way to prevent repetition when creating a light/dark theme override toggle, which by default looks at user preferences. The spec only allows it for colour-based properties at this point, which is fair given this is new. I would, however, like to see this expanded to be available for any property. In some cases, light and dark themes are not simply a colour change, but a different look and feel altogether. As such, things like typography (which, at a basic level, could also benefit weight adjustment on light vs dark background!) and other effects could leverage `light-dark()` to make theming easier. A simple example would be the following: in a "light" context, a card component might have a drop shadow, like layers of paper, whereas in a dark context, you might want to have more of a neon glow effect. Currently, you would need to do something like this: (you can simplify this, but I'm being verbose just to drive the point home) ```css :root { color-scheme: light dark; --light-fx: 0 4px 3px #3218; --dark-fx 0 1px 8px #0ff; } /* Defaults */ @media (prefers-color-scheme: light) { html:not([data-theme]) { --fx: var(--light-fx); } } @media (prefers-color-scheme: dark) { html:not([data-theme]) { --fx: var(--dark-fx); } } /* Overrides */ html[data-theme=light] { --fx: var(--light-fx); } html[data-theme=dark] { --fx: var(--dark-fx); } .card { box-shadow: var(--fx); } ``` This would be very easy to implement using `light-dark()`: ```css :root { color-scheme: light dark; --light-fx: 0 4px 3px #3218; --dark-fx 0 1px 8px #0ff; } html[data-theme=light] { color-scheme: light; } html[data-theme=dark] { color-scheme: dark; } .card { box-shadow: light-dark(var(--light-fx), var(--dark-fx)); } ``` If this were possible, it would considerably reduce the amount of code I need to write for theming, as I still need to write some things as either inside a user-preference media query and repeat that in a data-attribute-based selector on the root. If this is already planned, I did not find a reference in the spec or by having a look at recent issues on here. Thank you! Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10152 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
chriskirknielsen has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color] Allow light-dark() to be used for any property, not just color == I am excited to see that [`light-dark()`](https://drafts.csswg.org/css-color-5/#light-dark) is landing in more browsers, as I believe it is a great way to prevent repetition when creating a light/dark theme override toggle, which by default looks at user preferences. The spec only allows it for colour-based properties at this point, which is fair given this is new. I would, however, like to see this expanded to be available for any property. In some cases, light and dark themes are not simply a colour change, but a different look and feel altogether. As such, things like typography (which, at a basic level, could also benefit weight adjustment on light vs dark background!) and other effects could leverage `light-dark()` to make theming easier. A simple example would be the following: in a "light" context, a card component might have a drop shadow, like layers of paper, whereas in a dark context, you might want to have more of a neon glow effect. Currently, you would need to do something like this: (you can simplify this, but I'm being verbose just to drive the point home) ```css :root { color-scheme: light dark; --light-fx: 0 4px 3px #3218; --dark-fx 0 1px 8px #0ff; } /* Defaults */ @media (prefers-color-scheme: light) { html:not([data-theme]) { --fx: var(--light-fx); } } @media (prefers-color-scheme: dark) { html:not([data-theme]) { --fx: var(--dark-fx); } } /* Overrides */ html[data-theme=light] { --fx: var(--light-fx); } html[data-theme=dark] { --fx: var(--dark-fx); } .card { box-shadow: var(--fx); } ``` This would be very easy to implement using `light-dark()`: ```css :root { color-scheme: light dark; --light-fx: 0 4px 3px #3218; --dark-fx 0 1px 8px #0ff; } html[data-theme=light] { color-scheme: light; } html[data-theme=dark] { color-scheme: dark; } .card { box-shadow: light-dark(var(--light-fx), var(--dark-fx)); } ``` If this were possible, it would considerably reduce the amount of code I need to write for theming, as I still need to write some things as either inside a user-preference media query and repeat that in a data-attribute-based selector on the root. If this is already planned, I did not find a reference in the spec or by having a look at recent issues on here. Thank you! Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10152 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
chriskirknielsen has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color] Allow light-dark() to be used for any property, not just color == I am excited to see that [`light-dark()`](https://drafts.csswg.org/css-color-5/#light-dark) is landing in more browsers, as I believe it is a great way to prevent repetition when creating a light/dark theme override toggle, which by default looks at user preferences. The spec only allows it for colour-based properties at this point, which is fair given this is new. I would, however, like to see this expanded to be available for any property. In some cases, light and dark themes are not simply a colour change, but a different look and feel altogether. As such, things like typography (which, at a basic level, could also benefit weight adjustment on light vs dark background!) and other effects could leverage `light-dark()` to make theming easier. A simple example would be the following: in a "light" context, a card component might have a drop shadow, like layers of paper, whereas in a dark context, you might want to have more of a neon glow effect. Currently, you would need to do something like this: (you can simplify this, but I'm being verbose just to drive the point home) ```css :root { color-scheme: light dark; --light-fx: 0 4px 3px #3218; --dark-fx 0 1px 8px #0ff; } /* Defaults */ @media (prefers-color-scheme: light) { html:not([data-theme]) { --fx: var(--light-fx); } } @media (prefers-color-scheme: dark) { html:not([data-theme]) { --fx: var(--dark-fx); } } /* Overrides */ html[data-theme=light] { --fx: var(--light-fx); } html[data-theme=dark] { --fx: var(--dark-fx); } .card { box-shadow: var(--fx); } ``` This would be very easy to implement using `light-dark()`: ```css :root { color-scheme: light dark; --light-fx: 0 4px 3px #3218; --dark-fx 0 1px 8px #0ff; } html[data-theme=light] { color-scheme: light; } html[data-theme=dark] { color-scheme: dark; } .card { box-shadow: light-dark(var(--light-fx), var(--dark-fx)); } ``` If this were possible, it would considerably reduce the amount of code I need to write for theming, as I still need to write some things as either inside a user-preference media query and repeat that in a data-attribute-based selector on the root. If this is already planned, I did not find a reference in the spec or by having a look at recent issues on here. Thank you! Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10152 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
chriskirknielsen has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color] Allow light-dark() to be used for any property, not just color == I am excited to see that [`light-dark()`](https://drafts.csswg.org/css-color-5/#light-dark) is landing in more browsers, as I believe it is a great way to prevent repetition when creating a light/dark theme override toggle, which by default looks at user preferences. The spec only allows it for colour-based properties at this point, which is fair given this is new. I would, however, like to see this expanded to be available for any property. In some cases, light and dark themes are not simply a colour change, but a different look and feel altogether. As such, things like typography (which, at a basic level, could also benefit weight adjustment on light vs dark background!) and other effects could leverage `light-dark()` to make theming easier. A simple example would be the following: in a "light" context, a card component might have a drop shadow, like layers of paper, whereas in a dark context, you might want to have more of a neon glow effect. Currently, you would need to do something like this: (you can simplify this, but I'm being verbose just to drive the point home) ```css :root { color-scheme: light dark; --light-fx: 0 4px 3px #3218; --dark-fx 0 1px 8px #0ff; } /* Defaults */ @media (prefers-color-scheme: light) { html:not([data-theme]) { --fx: var(--light-fx); } } @media (prefers-color-scheme: dark) { html:not([data-theme]) { --fx: var(--dark-fx); } } /* Overrides */ html[data-theme=light] { --fx: var(--light-fx); } html[data-theme=dark] { --fx: var(--dark-fx); } .card { box-shadow: var(--fx); } ``` This would be very easy to implement using `light-dark()`: ```css :root { color-scheme: light dark; --light-fx: 0 4px 3px #3218; --dark-fx 0 1px 8px #0ff; } html[data-theme=light] { color-scheme: light; } html[data-theme=dark] { color-scheme: dark; } .card { box-shadow: light-dark(var(--light-fx), var(--dark-fx)); } ``` If this were possible, it would considerably reduce the amount of code I need to write for theming, as I still need to write some things as either inside a user-preference media query and repeat that in a data-attribute-based selector on the root. If this is already planned, I did not find a reference in the spec or by having a look at recent issues on here. Thank you! Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10152 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
chriskirknielsen has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color] Allow light-dark() to be used for any property, not just color == I am excited to see that [`light-dark()`](https://drafts.csswg.org/css-color-5/#light-dark) is landing in more browsers, as I believe it is a great way to prevent repetition when creating a light/dark theme override toggle, which by default looks at user preferences. The spec only allows it for colour-based properties at this point, which is fair given this is new. I would, however, like to see this expanded to be available for any property. In some cases, light and dark themes are not simply a colour change, but a different look and feel altogether. As such, things like typography (which, at a basic level, could also benefit weight adjustment on light vs dark background!) and other effects could leverage `light-dark()` to make theming easier. A simple example would be the following: in a "light" context, a card component might have a drop shadow, like layers of paper, whereas in a dark context, you might want to have more of a neon glow effect. Currently, you would need to do something like this: (you can simplify this, but I'm being verbose just to drive the point home) ```css :root { color-scheme: light dark; --light-fx: 0 4px 3px #3218; --dark-fx 0 1px 8px #0ff; } /* Defaults */ @media (prefers-color-scheme: light) { html:not([data-theme]) { --fx: var(--light-fx); } } @media (prefers-color-scheme: dark) { html:not([data-theme]) { --fx: var(--dark-fx); } } /* Overrides */ html[data-theme=light] { --fx: var(--light-fx); } html[data-theme=dark] { --fx: var(--dark-fx); } .card { box-shadow: var(--fx); } ``` This would be very easy to implement using `light-dark()`: ```css :root { color-scheme: light dark; --light-fx: 0 4px 3px #3218; --dark-fx 0 1px 8px #0ff; } html[data-theme=light] { color-scheme: light; } html[data-theme=dark] { color-scheme: dark; } .card { box-shadow: light-dark(var(--light-fx), var(--dark-fx)); } ``` If this were possible, it would considerably reduce the amount of code I need to write for theming, as I still need to write some things as either inside a user-preference media query and repeat that in a data-attribute-based selector on the root. If this is already planned, I did not find a reference in the spec or by having a look at recent issues on here. Thank you! Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10152 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-5] Behavior of `none` in relative color syntax == see : https://drafts.csswg.org/css-color-4/#valdef-color-none > For all other purposes, a missing component behaves as a zero value, in the appropriate unit for that component: 0, 0%, or 0deg. This includes rendering the color directly, converting it to another color space, performing computations on the color component values, etc. There is a note still in the WPT tests for relative color about `none` : https://github.com/web-platform-tests/wpt/blob/master/css/css-color/parsing/color-computed-relative-color.html#L336-L340 ``` // FIXME: Clarify with spec editors if 'none' should pass through to the constants. fuzzy_test_computed_color(`lab(from lab(none none none) l a b)`, `lab(0 0 0)`); fuzzy_test_computed_color(`lab(from lab(none none none / none) l a b / alpha)`, `lab(0 0 0 / 0)`); fuzzy_test_computed_color(`lab(from lab(25 none 50) l a b)`, `lab(25 0 50)`); fuzzy_test_computed_color(`lab(from lab(25 20 50 / none) l a b / alpha)`, `lab(25 20 50 / 0)`); ``` As I understand it there are two possible cases: - `none` was used in the **origin** color (e.g. `hsl(from hsl(none 50% 50%) h s l)`) - `none` was used in the **relative** color (e.g. `hsl(from green none s l)`) When `none` was used in the **origin** color then it should be treated as `0` because channel keywords have type `number`. When `none` was used in the **relative** color then it should behave exactly the same as it does in absolute colors. Is this correct? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10151 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-5] Behavior of `none` in relative color syntax == see : https://drafts.csswg.org/css-color-4/#valdef-color-none > For all other purposes, a missing component behaves as a zero value, in the appropriate unit for that component: 0, 0%, or 0deg. This includes rendering the color directly, converting it to another color space, performing computations on the color component values, etc. There is a note still in the WPT tests for relative color about `none` : https://github.com/web-platform-tests/wpt/blob/master/css/css-color/parsing/color-computed-relative-color.html#L336-L340 ``` // FIXME: Clarify with spec editors if 'none' should pass through to the constants. fuzzy_test_computed_color(`lab(from lab(none none none) l a b)`, `lab(0 0 0)`); fuzzy_test_computed_color(`lab(from lab(none none none / none) l a b / alpha)`, `lab(0 0 0 / 0)`); fuzzy_test_computed_color(`lab(from lab(25 none 50) l a b)`, `lab(25 0 50)`); fuzzy_test_computed_color(`lab(from lab(25 20 50 / none) l a b / alpha)`, `lab(25 20 50 / 0)`); ``` As I understand it there are two possible cases: - `none` was used in the **origin** color (e.g. `hsl(from hsl(none 50% 50%) h s l)`) - `none` was used in the **relative** color (e.g. `hsl(from green none s l)`) When `none` was used in the **origin** color then it should be treated as `0` because channel keywords have type `number`. When `none` was used in the **relative** color then it should behave exactly the same as it does in absolute colors. Is this correct? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10151 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-5] Behavior of `none` in relative color syntax == see : https://drafts.csswg.org/css-color-4/#valdef-color-none > For all other purposes, a missing component behaves as a zero value, in the appropriate unit for that component: 0, 0%, or 0deg. This includes rendering the color directly, converting it to another color space, performing computations on the color component values, etc. There is a note still in the WPT tests for relative color about `none` : https://github.com/web-platform-tests/wpt/blob/master/css/css-color/parsing/color-computed-relative-color.html#L336-L340 ``` // FIXME: Clarify with spec editors if 'none' should pass through to the constants. fuzzy_test_computed_color(`lab(from lab(none none none) l a b)`, `lab(0 0 0)`); fuzzy_test_computed_color(`lab(from lab(none none none / none) l a b / alpha)`, `lab(0 0 0 / 0)`); fuzzy_test_computed_color(`lab(from lab(25 none 50) l a b)`, `lab(25 0 50)`); fuzzy_test_computed_color(`lab(from lab(25 20 50 / none) l a b / alpha)`, `lab(25 20 50 / 0)`); ``` As I understand it there are two possible cases: - `none` was used in the **origin** color (e.g. `hsl(from hsl(none 50% 50%) h s l)`) - `none` was used in the **relative** color (e.g. `hsl(from green none s l)`) When `none` was used in the **origin** color then it should be treated as `0` because channel keywords have type `number`. When `none` was used in the **relative** color then it should behave exactly the same as it does in absolute colors. Is this correct? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10151 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-5] Behavior of `none` in relative color syntax == see : https://drafts.csswg.org/css-color-4/#valdef-color-none > For all other purposes, a missing component behaves as a zero value, in the appropriate unit for that component: 0, 0%, or 0deg. This includes rendering the color directly, converting it to another color space, performing computations on the color component values, etc. There is a note still in the WPT tests for relative color about `none` : https://github.com/web-platform-tests/wpt/blob/master/css/css-color/parsing/color-computed-relative-color.html#L336-L340 ``` // FIXME: Clarify with spec editors if 'none' should pass through to the constants. fuzzy_test_computed_color(`lab(from lab(none none none) l a b)`, `lab(0 0 0)`); fuzzy_test_computed_color(`lab(from lab(none none none / none) l a b / alpha)`, `lab(0 0 0 / 0)`); fuzzy_test_computed_color(`lab(from lab(25 none 50) l a b)`, `lab(25 0 50)`); fuzzy_test_computed_color(`lab(from lab(25 20 50 / none) l a b / alpha)`, `lab(25 20 50 / 0)`); ``` As I understand it there are two possible cases: - `none` was used in the **origin** color (e.g. `hsl(from hsl(none 50% 50%) h s l)`) - `none` was used in the **relative** color (e.g. `hsl(from green none s l)`) When `none` was used in the **origin** color then it should be treated as `0` because channel keywords have type `number`. When `none` was used in the **relative** color then it should behave exactly the same as it does in absolute colors. Is this correct? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10151 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-5] Behavior of `none` in relative color syntax == see : https://drafts.csswg.org/css-color-4/#valdef-color-none > For all other purposes, a missing component behaves as a zero value, in the appropriate unit for that component: 0, 0%, or 0deg. This includes rendering the color directly, converting it to another color space, performing computations on the color component values, etc. There is a note still in the WPT tests for relative color about `none` : https://github.com/web-platform-tests/wpt/blob/master/css/css-color/parsing/color-computed-relative-color.html#L336-L340 ``` // FIXME: Clarify with spec editors if 'none' should pass through to the constants. fuzzy_test_computed_color(`lab(from lab(none none none) l a b)`, `lab(0 0 0)`); fuzzy_test_computed_color(`lab(from lab(none none none / none) l a b / alpha)`, `lab(0 0 0 / 0)`); fuzzy_test_computed_color(`lab(from lab(25 none 50) l a b)`, `lab(25 0 50)`); fuzzy_test_computed_color(`lab(from lab(25 20 50 / none) l a b / alpha)`, `lab(25 20 50 / 0)`); ``` As I understand it there are two possible cases: - `none` was used in the **origin** color (e.g. `hsl(from hsl(none 50% 50%) h s l)`) - `none` was used in the **relative** color (e.g. `hsl(from green none s l)`) When `none` was used in the **origin** color then it should be treated as `0` because channel keywords have type `number`. When `none` was used in the **relative** color then it should behave exactly the same as it does in absolute colors. Is this correct? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10151 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-5] Behavior of `none` in relative color syntax == see : https://drafts.csswg.org/css-color-4/#valdef-color-none > For all other purposes, a missing component behaves as a zero value, in the appropriate unit for that component: 0, 0%, or 0deg. This includes rendering the color directly, converting it to another color space, performing computations on the color component values, etc. There is a note still in the WPT tests for relative color about `none` : https://github.com/web-platform-tests/wpt/blob/master/css/css-color/parsing/color-computed-relative-color.html#L336-L340 ``` // FIXME: Clarify with spec editors if 'none' should pass through to the constants. fuzzy_test_computed_color(`lab(from lab(none none none) l a b)`, `lab(0 0 0)`); fuzzy_test_computed_color(`lab(from lab(none none none / none) l a b / alpha)`, `lab(0 0 0 / 0)`); fuzzy_test_computed_color(`lab(from lab(25 none 50) l a b)`, `lab(25 0 50)`); fuzzy_test_computed_color(`lab(from lab(25 20 50 / none) l a b / alpha)`, `lab(25 20 50 / 0)`); ``` As I understand it there are two possible cases: - `none` was used in the **origin** color (e.g. `hsl(from hsl(none 50% 50%) h s l)`) - `none` was used in the **relative** color (e.g. `hsl(from green none s l)`) When `none` was used in the **origin** color then it should be treated as `0` because channel keywords have type `number`. When `none` was used in the **relative** color then it should behave exactly the same as it does in absolute colors. Is this correct? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10151 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-5] Behavior of `none` in relative color syntax == see : https://drafts.csswg.org/css-color-4/#valdef-color-none > For all other purposes, a missing component behaves as a zero value, in the appropriate unit for that component: 0, 0%, or 0deg. This includes rendering the color directly, converting it to another color space, performing computations on the color component values, etc. There is a note still in the WPT tests for relative color about `none` : https://github.com/web-platform-tests/wpt/blob/master/css/css-color/parsing/color-computed-relative-color.html#L336-L340 ``` // FIXME: Clarify with spec editors if 'none' should pass through to the constants. fuzzy_test_computed_color(`lab(from lab(none none none) l a b)`, `lab(0 0 0)`); fuzzy_test_computed_color(`lab(from lab(none none none / none) l a b / alpha)`, `lab(0 0 0 / 0)`); fuzzy_test_computed_color(`lab(from lab(25 none 50) l a b)`, `lab(25 0 50)`); fuzzy_test_computed_color(`lab(from lab(25 20 50 / none) l a b / alpha)`, `lab(25 20 50 / 0)`); ``` As I understand it there are two possible cases: - `none` was used in the **origin** color (e.g. `hsl(from hsl(none 50% 50%) h s l)`) - `none` was used in the **relative** color (e.g. `hsl(from green none s l)`) When `none` was used in the **origin** color then it should be treated as `0` because channel keywords have type `number`. When `none` was used in the **relative** color then it should behave exactly the same as it does in absolute colors. Is this correct? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10151 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-5] Behavior of `none` in relative color syntax == see : https://drafts.csswg.org/css-color-4/#valdef-color-none > For all other purposes, a missing component behaves as a zero value, in the appropriate unit for that component: 0, 0%, or 0deg. This includes rendering the color directly, converting it to another color space, performing computations on the color component values, etc. There is a note still in the WPT tests for relative color about `none` : https://github.com/web-platform-tests/wpt/blob/master/css/css-color/parsing/color-computed-relative-color.html#L336-L340 ``` // FIXME: Clarify with spec editors if 'none' should pass through to the constants. fuzzy_test_computed_color(`lab(from lab(none none none) l a b)`, `lab(0 0 0)`); fuzzy_test_computed_color(`lab(from lab(none none none / none) l a b / alpha)`, `lab(0 0 0 / 0)`); fuzzy_test_computed_color(`lab(from lab(25 none 50) l a b)`, `lab(25 0 50)`); fuzzy_test_computed_color(`lab(from lab(25 20 50 / none) l a b / alpha)`, `lab(25 20 50 / 0)`); ``` As I understand it there are two possible cases: - `none` was used in the **origin** color (e.g. `hsl(from hsl(none 50% 50%) h s l)`) - `none` was used in the **relative** color (e.g. `hsl(from green none s l)`) When `none` was used in the **origin** color then it should be treated as `0` because channel keywords have type `number`. When `none` was used in the **relative** color then it should behave exactly the same as it does in absolute colors. Is this correct? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10151 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-5] Behavior of `none` in relative color syntax == see : https://drafts.csswg.org/css-color-4/#valdef-color-none > For all other purposes, a missing component behaves as a zero value, in the appropriate unit for that component: 0, 0%, or 0deg. This includes rendering the color directly, converting it to another color space, performing computations on the color component values, etc. There is a note still in the WPT tests for relative color about `none` : https://github.com/web-platform-tests/wpt/blob/master/css/css-color/parsing/color-computed-relative-color.html#L336-L340 ``` // FIXME: Clarify with spec editors if 'none' should pass through to the constants. fuzzy_test_computed_color(`lab(from lab(none none none) l a b)`, `lab(0 0 0)`); fuzzy_test_computed_color(`lab(from lab(none none none / none) l a b / alpha)`, `lab(0 0 0 / 0)`); fuzzy_test_computed_color(`lab(from lab(25 none 50) l a b)`, `lab(25 0 50)`); fuzzy_test_computed_color(`lab(from lab(25 20 50 / none) l a b / alpha)`, `lab(25 20 50 / 0)`); ``` As I understand it there are two possible cases: - `none` was used in the **origin** color (e.g. `hsl(from hsl(none 50% 50%) h s l)`) - `none` was used in the **relative** color (e.g. `hsl(from green none s l)`) When `none` was used in the **origin** color then it should be treated as `0` because channel keywords have type `number`. When `none` was used in the **relative** color then it should behave exactly the same as it does in absolute colors. Is this correct? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10151 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
jchv has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-ui] Proposal: new `cursor` value `all-resize` == https://www.w3.org/TR/css-ui-3/#propdef-cursor I am proposing the addition of a new `cursor` value `all-resize`. The CSS `cursor` spec does a good job enumerating a common set of cursors that cover the needs of most software with reasonable names. As such, the CSS `cursor` names have been mostly adopted in the free software desktop world, e.g. in GTK's own cursor names, and in the recent Wayland cursor-shape-v1. However, it appears that there is no specific cursor that covers the use case of a cursor that is for generally moving or resizing in all directions at once. This often looks like a combination of `ns-resize` and `ew-resize`: ![Adwaita "move" cursor](https://github.com/w3c/csswg-drafts/assets/938744/d0bfcc83-6b24-46f7-8c54-95720b977c0b) This cursor is often used by image editing software to represent translation of a compositing layer. This is distinct from `all-scroll`, traditionally called `fleur` in Xcursor themes as far as I can tell, which usually looks something like this: ![Breeze "fleur" cursor](https://github.com/w3c/csswg-drafts/assets/938744/be21863a-16bb-447e-8759-f13f4080c63b) On some platforms, e.g. Apple computers, there appears to be no distinction, and the `all-scroll` cursor and `all-resize` cursor would likely map to the same system cursor. This doesn't seem to be a problem, because there are already cases where browsers map multiple `cursor` values to the same OS cursor. I apologize if I have filed this issue incorrectly, please let me know and I'll do my best to make it correct. Thanks for your consideration. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10150 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
jchv has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-ui] Proposal: new `cursor` value `all-resize` == https://www.w3.org/TR/css-ui-3/#propdef-cursor I am proposing the addition of a new `cursor` value `all-resize`. The CSS `cursor` spec does a good job enumerating a common set of cursors that cover the needs of most software with reasonable names. As such, the CSS `cursor` names have been mostly adopted in the free software desktop world, e.g. in GTK's own cursor names, and in the recent Wayland cursor-shape-v1. However, it appears that there is no specific cursor that covers the use case of a cursor that is for generally moving or resizing in all directions at once. This often looks like a combination of `ns-resize` and `ew-resize`: ![Adwaita "move" cursor](https://github.com/w3c/csswg-drafts/assets/938744/d0bfcc83-6b24-46f7-8c54-95720b977c0b) This cursor is often used by image editing software to represent translation of a compositing layer. This is distinct from `all-scroll`, traditionally called `fleur` in Xcursor themes as far as I can tell, which usually looks something like this: ![Breeze "fleur" cursor](https://github.com/w3c/csswg-drafts/assets/938744/be21863a-16bb-447e-8759-f13f4080c63b) On some platforms, e.g. Apple computers, there appears to be no distinction, and the `all-scroll` cursor and `all-resize` cursor would likely map to the same system cursor. This doesn't seem to be a problem, because there are already cases where browsers map multiple `cursor` values to the same OS cursor. I apologize if I have filed this issue incorrectly, please let me know and I'll do my best to make it correct. Thanks for your consideration. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10150 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
jchv has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-ui] Proposal: new `cursor` value `all-resize` == https://www.w3.org/TR/css-ui-3/#propdef-cursor I am proposing the addition of a new `cursor` value `all-resize`. The CSS `cursor` spec does a good job enumerating a common set of cursors that cover the needs of most software with reasonable names. As such, the CSS `cursor` names have been mostly adopted in the free software desktop world, e.g. in GTK's own cursor names, and in the recent Wayland cursor-shape-v1. However, it appears that there is no specific cursor that covers the use case of a cursor that is for generally moving or resizing in all directions at once. This often looks like a combination of `ns-resize` and `ew-resize`: ![Adwaita "move" cursor](https://github.com/w3c/csswg-drafts/assets/938744/d0bfcc83-6b24-46f7-8c54-95720b977c0b) This cursor is often used by image editing software to represent translation of a compositing layer. This is distinct from `all-scroll`, traditionally called `fleur` in Xcursor themes as far as I can tell, which usually looks something like this: ![Breeze "fleur" cursor](https://github.com/w3c/csswg-drafts/assets/938744/be21863a-16bb-447e-8759-f13f4080c63b) On some platforms, e.g. Apple computers, there appears to be no distinction, and the `all-scroll` cursor and `all-resize` cursor would likely map to the same system cursor. This doesn't seem to be a problem, because there are already cases where browsers map multiple `cursor` values to the same OS cursor. I apologize if I have filed this issue incorrectly, please let me know and I'll do my best to make it correct. Thanks for your consideration. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10150 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
jchv has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-ui] Proposal: new `cursor` value `all-resize` == https://www.w3.org/TR/css-ui-3/#propdef-cursor I am proposing the addition of a new `cursor` value `all-resize`. The CSS `cursor` spec does a good job enumerating a common set of cursors that cover the needs of most software with reasonable names. As such, the CSS `cursor` names have been mostly adopted in the free software desktop world, e.g. in GTK's own cursor names, and in the recent Wayland cursor-shape-v1. However, it appears that there is no specific cursor that covers the use case of a cursor that is for generally moving or resizing in all directions at once. This often looks like a combination of `ns-resize` and `ew-resize`: ![Adwaita "move" cursor](https://github.com/w3c/csswg-drafts/assets/938744/d0bfcc83-6b24-46f7-8c54-95720b977c0b) This cursor is often used by image editing software to represent translation of a compositing layer. This is distinct from `all-scroll`, traditionally called `fleur` in Xcursor themes as far as I can tell, which usually looks something like this: ![Breeze "fleur" cursor](https://github.com/w3c/csswg-drafts/assets/938744/be21863a-16bb-447e-8759-f13f4080c63b) On some platforms, e.g. Apple computers, there appears to be no distinction, and the `all-scroll` cursor and `all-resize` cursor would likely map to the same system cursor. This doesn't seem to be a problem, because there are already cases where browsers map multiple `cursor` values to the same OS cursor. I apologize if I have filed this issue incorrectly, please let me know and I'll do my best to make it correct. Thanks for your consideration. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10150 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Including nesting feature will eliminate the last reason of someone needing to use preprocessor. Lot of things were not possible, but they are today. So if we don’t see the solution for it at this moment, we probably will in future, i see that personal preference impacts the whole web which is not ideal. -- GitHub Notification of comment by djekanovic Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6119#issuecomment-2023810082 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Privacy section in the [explainer](https://github.com/WICG/visual-viewport/blob/gh-pages/segments-explainer/SEGMENTS-EXPLAINER.md) indicates that segments will return null when called from within an iframe and explains how this prevents using the API as a fingerprinting vector from cross origin iframes. A concern I have is accessing the segments through [CSS media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries#targeting_media_features). Having CSS API in iframes might enable this type of fingerprinting. Is disabling CSS media queries for the segments feasible? -- GitHub Notification of comment by aykutbulut Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9285#issuecomment-2023111466 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Privacy section in the [explainer](https://github.com/WICG/visual-viewport/blob/gh-pages/segments-explainer/SEGMENTS-EXPLAINER.md) indicates that segments will return null when called from within an iframe and explains how this prevents using the API as a fingerprinting vector from cross origin iframes. A concern I have is accessing the segments through [CSS media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries#targeting_media_features). Having CSS API in iframes might enable this type of fingerprinting. Is disabling CSS media queries for the segments feasible? -- GitHub Notification of comment by aykutbulut Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9285#issuecomment-2023111466 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Privacy section in the [explainer](https://github.com/WICG/visual-viewport/blob/gh-pages/segments-explainer/SEGMENTS-EXPLAINER.md) indicates that segments will return null when called from within an iframe and explains how this prevents using the API as a fingerprinting vector from cross origin iframes. A concern I have is accessing the segments through [CSS media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries#targeting_media_features). Having CSS API in iframes might enable this type of fingerprinting. Is disabling CSS media queries for the segments feasible? -- GitHub Notification of comment by aykutbulut Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9285#issuecomment-2023111466 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Privacy section in the [explainer](https://github.com/WICG/visual-viewport/blob/gh-pages/segments-explainer/SEGMENTS-EXPLAINER.md) indicates that segments will return null when called from within an iframe and explains how this prevents using the API as a fingerprinting vector from cross origin iframes. A concern I have is accessing the segments through [CSS media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries#targeting_media_features). Having CSS API in iframes might enable this type of fingerprinting. Is disabling CSS media queries for the segments feasible? -- GitHub Notification of comment by aykutbulut Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9285#issuecomment-2023111466 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Privacy section in the [explainer](https://github.com/WICG/visual-viewport/blob/gh-pages/segments-explainer/SEGMENTS-EXPLAINER.md) indicates that segments will return null when called from within an iframe and explains how this prevents using the API as a fingerprinting vector from cross origin iframes. A concern I have is accessing the segments through [CSS media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries#targeting_media_features). Having CSS API in iframes might enable this type of fingerprinting. Is disabling CSS media queries for the segments feasible? -- GitHub Notification of comment by aykutbulut Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9285#issuecomment-2023111466 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Privacy section in the [explainer](https://github.com/WICG/visual-viewport/blob/gh-pages/segments-explainer/SEGMENTS-EXPLAINER.md) indicates that segments will return null when called from within an iframe and explains how this prevents using the API as a fingerprinting vector from cross origin iframes. A concern I have is accessing the segments through [CSS media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries#targeting_media_features). Having CSS API in iframes might enable this type of fingerprinting. Is disabling CSS media queries for the segments feasible? -- GitHub Notification of comment by aykutbulut Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9285#issuecomment-2023111466 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Privacy section in the [explainer](https://github.com/WICG/visual-viewport/blob/gh-pages/segments-explainer/SEGMENTS-EXPLAINER.md) indicates that segments will return null when called from within an iframe and explains how this prevents using the API as a fingerprinting vector from cross origin iframes. A concern I have is accessing the segments through [CSS media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries#targeting_media_features). Having CSS API in iframes might enable this type of fingerprinting. Is disabling CSS media queries for the segments feasible? -- GitHub Notification of comment by aykutbulut Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9285#issuecomment-2023111466 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Privacy section in the [explainer](https://github.com/WICG/visual-viewport/blob/gh-pages/segments-explainer/SEGMENTS-EXPLAINER.md) indicates that segments will return null when called from within an iframe and explains how this prevents using the API as a fingerprinting vector from cross origin iframes. A concern I have is accessing the segments through [CSS media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries#targeting_media_features). Having CSS API in iframes might enable this type of fingerprinting. Is disabling CSS media queries for the segments feasible? -- GitHub Notification of comment by aykutbulut Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9285#issuecomment-2023111466 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Privacy section in the [explainer](https://github.com/WICG/visual-viewport/blob/gh-pages/segments-explainer/SEGMENTS-EXPLAINER.md) indicates that segments will return null when called from within an iframe and explains how this prevents using the API as a fingerprinting vector from cross origin iframes. A concern I have is accessing the segments through [CSS media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries#targeting_media_features). Having CSS API in iframes might enable this type of fingerprinting. Is disabling CSS media queries for the segments feasible? -- GitHub Notification of comment by aykutbulut Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9285#issuecomment-2023111466 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Privacy section in the [explainer](https://github.com/WICG/visual-viewport/blob/gh-pages/segments-explainer/SEGMENTS-EXPLAINER.md) indicates that segments will return null when called from within an iframe and explains how this prevents using the API as a fingerprinting vector from cross origin iframes. A concern I have is accessing the segments through [CSS media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries#targeting_media_features). Having CSS API in iframes might enable this type of fingerprinting. Is disabling CSS media queries for the segments feasible? -- GitHub Notification of comment by aykutbulut Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9285#issuecomment-2023111466 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Privacy section in the [explainer](https://github.com/WICG/visual-viewport/blob/gh-pages/segments-explainer/SEGMENTS-EXPLAINER.md) indicates that segments will return null when called from within an iframe and explains how this prevents using the API as a fingerprinting vector from cross origin iframes. A concern I have is accessing the segments through [CSS media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries#targeting_media_features). Having CSS API in iframes might enable this type of fingerprinting. Is disabling CSS media queries for the segments feasible? -- GitHub Notification of comment by aykutbulut Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9285#issuecomment-2023111466 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Privacy section in the [explainer](https://github.com/WICG/visual-viewport/blob/gh-pages/segments-explainer/SEGMENTS-EXPLAINER.md) indicates that segments will return null when called from within an iframe and explains how this prevents using the API as a fingerprinting vector from cross origin iframes. A concern I have is accessing the segments through [CSS media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries#targeting_media_features). Having CSS API in iframes might enable this type of fingerprinting. Is disabling CSS media queries for the segments feasible? -- GitHub Notification of comment by aykutbulut Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9285#issuecomment-2023111466 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Privacy section in the [explainer](https://github.com/WICG/visual-viewport/blob/gh-pages/segments-explainer/SEGMENTS-EXPLAINER.md) indicates that segments will return null when called from within an iframe and explains how this prevents using the API as a fingerprinting vector from cross origin iframes. A concern I have is accessing the segments through [CSS media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries#targeting_media_features). Having CSS API in iframes might enable this type of fingerprinting. Is disabling CSS media queries for the segments feasible? -- GitHub Notification of comment by aykutbulut Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9285#issuecomment-2023111466 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Privacy section in the [explainer](https://github.com/WICG/visual-viewport/blob/gh-pages/segments-explainer/SEGMENTS-EXPLAINER.md) indicates that segments will return null when called from within an iframe and explains how this prevents using the API as a fingerprinting vector from cross origin iframes. A concern I have is accessing the segments through [CSS media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries#targeting_media_features). Having CSS API in iframes might enable this type of fingerprinting. Is disabling CSS media queries for the segments feasible? -- GitHub Notification of comment by aykutbulut Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9285#issuecomment-2023111466 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Privacy section in the [explainer](https://github.com/WICG/visual-viewport/blob/gh-pages/segments-explainer/SEGMENTS-EXPLAINER.md) indicates that segments will return null when called from within an iframe and explains how this prevents using the API as a fingerprinting vector from cross origin iframes. A concern I have is accessing the segments through [CSS media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries#targeting_media_features). Having CSS API in iframes might enable this type of fingerprinting. Is disabling CSS media queries for the segments feasible? -- GitHub Notification of comment by aykutbulut Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9285#issuecomment-2023111466 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Privacy section in the [explainer](https://github.com/WICG/visual-viewport/blob/gh-pages/segments-explainer/SEGMENTS-EXPLAINER.md) indicates that segments will return null when called from within an iframe and explains how this prevents using the API as a fingerprinting vector from cross origin iframes. A concern I have is accessing the segments through [CSS media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries#targeting_media_features). Having CSS API in iframes might enable this type of fingerprinting. Is disabling CSS media queries for the segments feasible? -- GitHub Notification of comment by aykutbulut Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9285#issuecomment-2023111466 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Privacy section in the [explainer](https://github.com/WICG/visual-viewport/blob/gh-pages/segments-explainer/SEGMENTS-EXPLAINER.md) indicates that segments will return null when called from within an iframe and explains how this prevents using the API as a fingerprinting vector from cross origin iframes. A concern I have is accessing the segments through [CSS media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries#targeting_media_features). Having CSS API in iframes might enable this type of fingerprinting. Is disabling CSS media queries for the segments feasible? -- GitHub Notification of comment by aykutbulut Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9285#issuecomment-2023111466 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Privacy section in the [explainer](https://github.com/WICG/visual-viewport/blob/gh-pages/segments-explainer/SEGMENTS-EXPLAINER.md) indicates that segments will return null when called from within an iframe and explains how this prevents using the API as a fingerprinting vector from cross origin iframes. A concern I have is accessing the segments through [CSS media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries#targeting_media_features). Having CSS API in iframes might enable this type of fingerprinting. Is disabling CSS media queries for the segments feasible? -- GitHub Notification of comment by aykutbulut Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9285#issuecomment-2023111466 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I'm making a simple demo that uses View Transitions to animate enlarging an item that's laid out with CSS Grid, and shifting the other items in the grid around. I was surprised to learn that 1) I have to use JavaScript to use View Transitions, and 2) that I have to give each item in the Grid a unique `view-transition-name`, and there's no mechanism for applying the functionality to all items. This caused me to have to write this code: ``` .card:nth-child(1) { view-transition-name: card-1; } .card:nth-child(2) { view-transition-name: card-2; } .card:nth-child(3) { view-transition-name: card-3; } .card:nth-child(4) { view-transition-name: card-4; } .card:nth-child(5) { view-transition-name: card-5; } .card:nth-child(6) { view-transition-name: card-6; } .card:nth-child(7) { view-transition-name: card-7; } .card:nth-child(8) { view-transition-name: card-8; } .card:nth-child(9) { view-transition-name: card-9; } .card:nth-child(10) { view-transition-name: card-10; } .card:nth-child(11) { view-transition-name: card-11; } .card:nth-child(12) { view-transition-name: card-12; } .card:nth-child(13) { view-transition-name: card-13; } .card:nth-child(14) { view-transition-name: card-14; } .card:nth-child(15) { view-transition-name: card-15; } .card:nth-child(16) { view-transition-name: card-16; } .card:nth-child(17) { view-transition-name: card-17; } .card:nth-child(18) { view-transition-name: card-18; } .card:nth-child(19) { view-transition-name: card-19; } .card:nth-child(20) { view-transition-name: card-20; } .card:nth-child(21) { view-transition-name: card-21; } .card:nth-child(22) { view-transition-name: card-22; } .card:nth-child(23) { view-transition-name: card-23; } .card:nth-child(24) { view-transition-name: card-24; } .card:nth-child(25) { view-transition-name: card-25; } .card:nth-child(26) { view-transition-name: card-26; } .card:nth-child(27) { view-transition-name: card-27; } .card:nth-child(28) { view-transition-name: card-28; } .card:nth-child(29) { view-transition-name: card-29; } .card:nth-child(30) { view-transition-name: card-30; } .card:nth-child(31) { view-transition-name: card-31; } .card:nth-child(32) { view-transition-name: card-32; } .card:nth-child(33) { view-transition-name: card-33; } .card:nth-child(34) { view-transition-name: card-34; } .card:nth-child(35) { view-transition-name: card-35; } .card:nth-child(36) { view-transition-name: card-36; } .card:nth-child(37) { view-transition-name: card-37; } .card:nth-child(38) { view-transition-name: card-38; } .card:nth-child(39) { view-transition-name: card-39; } .card:nth-child(40) { view-transition-name: card-40; } .card:nth-child(41) { view-transition-name: card-41; } .card:nth-child(42) { view-transition-name: card-42; } .card:nth-child(43) { view-transition-name: card-43; } .card:nth-child(44) { view-transition-name: card-44; } .card:nth-child(45) { view-transition-name: card-45; } .card:nth-child(46) { view-transition-name: card-46; } .card:nth-child(47) { view-transition-name: card-47; } .card:nth-child(48) { view-transition-name: card-48; } .card:nth-child(49) { view-transition-name: card-49; } .card:nth-child(50) { view-transition-name: card-50; } ``` Which is not robust — what if there are more than 50 items on the Grid?? The experience will break. It seems View Transitions was designed with the expectation that websites are JavaScript first — that it's fine if every items needs to be uniquely named, a developer can just use JS to create all the HTML, and inline styles with JS-created names. -- GitHub Notification of comment by jensimmons Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8320#issuecomment-2023077559 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I'm making a simple demo that uses View Transitions to animate enlarging an item that's laid out with CSS Grid, and shifting the other items in the grid around. I was surprised to learn that 1) I have to use JavaScript to use View Transitions, and 2) that I have to give each item in the Grid a unique `view-transition-name`, and there's no mechanism for applying the functionality to all items. This caused me to have to write this code: ``` .card:nth-child(1) { view-transition-name: card-1; } .card:nth-child(2) { view-transition-name: card-2; } .card:nth-child(3) { view-transition-name: card-3; } .card:nth-child(4) { view-transition-name: card-4; } .card:nth-child(5) { view-transition-name: card-5; } .card:nth-child(6) { view-transition-name: card-6; } .card:nth-child(7) { view-transition-name: card-7; } .card:nth-child(8) { view-transition-name: card-8; } .card:nth-child(9) { view-transition-name: card-9; } .card:nth-child(10) { view-transition-name: card-10; } .card:nth-child(11) { view-transition-name: card-11; } .card:nth-child(12) { view-transition-name: card-12; } .card:nth-child(13) { view-transition-name: card-13; } .card:nth-child(14) { view-transition-name: card-14; } .card:nth-child(15) { view-transition-name: card-15; } .card:nth-child(16) { view-transition-name: card-16; } .card:nth-child(17) { view-transition-name: card-17; } .card:nth-child(18) { view-transition-name: card-18; } .card:nth-child(19) { view-transition-name: card-19; } .card:nth-child(20) { view-transition-name: card-20; } .card:nth-child(21) { view-transition-name: card-21; } .card:nth-child(22) { view-transition-name: card-22; } .card:nth-child(23) { view-transition-name: card-23; } .card:nth-child(24) { view-transition-name: card-24; } .card:nth-child(25) { view-transition-name: card-25; } .card:nth-child(26) { view-transition-name: card-26; } .card:nth-child(27) { view-transition-name: card-27; } .card:nth-child(28) { view-transition-name: card-28; } .card:nth-child(29) { view-transition-name: card-29; } .card:nth-child(30) { view-transition-name: card-30; } .card:nth-child(31) { view-transition-name: card-31; } .card:nth-child(32) { view-transition-name: card-32; } .card:nth-child(33) { view-transition-name: card-33; } .card:nth-child(34) { view-transition-name: card-34; } .card:nth-child(35) { view-transition-name: card-35; } .card:nth-child(36) { view-transition-name: card-36; } .card:nth-child(37) { view-transition-name: card-37; } .card:nth-child(38) { view-transition-name: card-38; } .card:nth-child(39) { view-transition-name: card-39; } .card:nth-child(40) { view-transition-name: card-40; } .card:nth-child(41) { view-transition-name: card-41; } .card:nth-child(42) { view-transition-name: card-42; } .card:nth-child(43) { view-transition-name: card-43; } .card:nth-child(44) { view-transition-name: card-44; } .card:nth-child(45) { view-transition-name: card-45; } .card:nth-child(46) { view-transition-name: card-46; } .card:nth-child(47) { view-transition-name: card-47; } .card:nth-child(48) { view-transition-name: card-48; } .card:nth-child(49) { view-transition-name: card-49; } .card:nth-child(50) { view-transition-name: card-50; } ``` Which is not robust — what if there are more than 50 items on the Grid?? The experience will break. It seems View Transitions was designed with the expectation that websites are JavaScript first — that it's fine if every items needs to be uniquely named, a developer can just use JS to create all the HTML, and inline styles with JS-created names. -- GitHub Notification of comment by jensimmons Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8320#issuecomment-2023077559 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I'm making a simple demo that uses View Transitions to animate enlarging an item that's laid out with CSS Grid, and shifting the other items in the grid around. I was surprised to learn that 1) I have to use JavaScript to use View Transitions, and 2) that I have to give each item in the Grid a unique `view-transition-name`, and there's no mechanism for applying the functionality to all items. This caused me to have to write this code: ``` .card:nth-child(1) { view-transition-name: card-1; } .card:nth-child(2) { view-transition-name: card-2; } .card:nth-child(3) { view-transition-name: card-3; } .card:nth-child(4) { view-transition-name: card-4; } .card:nth-child(5) { view-transition-name: card-5; } .card:nth-child(6) { view-transition-name: card-6; } .card:nth-child(7) { view-transition-name: card-7; } .card:nth-child(8) { view-transition-name: card-8; } .card:nth-child(9) { view-transition-name: card-9; } .card:nth-child(10) { view-transition-name: card-10; } .card:nth-child(11) { view-transition-name: card-11; } .card:nth-child(12) { view-transition-name: card-12; } .card:nth-child(13) { view-transition-name: card-13; } .card:nth-child(14) { view-transition-name: card-14; } .card:nth-child(15) { view-transition-name: card-15; } .card:nth-child(16) { view-transition-name: card-16; } .card:nth-child(17) { view-transition-name: card-17; } .card:nth-child(18) { view-transition-name: card-18; } .card:nth-child(19) { view-transition-name: card-19; } .card:nth-child(20) { view-transition-name: card-20; } .card:nth-child(21) { view-transition-name: card-21; } .card:nth-child(22) { view-transition-name: card-22; } .card:nth-child(23) { view-transition-name: card-23; } .card:nth-child(24) { view-transition-name: card-24; } .card:nth-child(25) { view-transition-name: card-25; } .card:nth-child(26) { view-transition-name: card-26; } .card:nth-child(27) { view-transition-name: card-27; } .card:nth-child(28) { view-transition-name: card-28; } .card:nth-child(29) { view-transition-name: card-29; } .card:nth-child(30) { view-transition-name: card-30; } .card:nth-child(31) { view-transition-name: card-31; } .card:nth-child(32) { view-transition-name: card-32; } .card:nth-child(33) { view-transition-name: card-33; } .card:nth-child(34) { view-transition-name: card-34; } .card:nth-child(35) { view-transition-name: card-35; } .card:nth-child(36) { view-transition-name: card-36; } .card:nth-child(37) { view-transition-name: card-37; } .card:nth-child(38) { view-transition-name: card-38; } .card:nth-child(39) { view-transition-name: card-39; } .card:nth-child(40) { view-transition-name: card-40; } .card:nth-child(41) { view-transition-name: card-41; } .card:nth-child(42) { view-transition-name: card-42; } .card:nth-child(43) { view-transition-name: card-43; } .card:nth-child(44) { view-transition-name: card-44; } .card:nth-child(45) { view-transition-name: card-45; } .card:nth-child(46) { view-transition-name: card-46; } .card:nth-child(47) { view-transition-name: card-47; } .card:nth-child(48) { view-transition-name: card-48; } .card:nth-child(49) { view-transition-name: card-49; } .card:nth-child(50) { view-transition-name: card-50; } ``` Which is not robust — what if there are more than 50 items on the Grid?? The experience will break. It seems View Transitions was designed with the expectation that websites are JavaScript first — that it's fine if every items needs to be uniquely named, a developer can just use JS to create all the HTML, and inline styles with JS-created names. -- GitHub Notification of comment by jensimmons Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8320#issuecomment-2023077559 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I'm making a simple demo that uses View Transitions to animate enlarging an item that's laid out with CSS Grid, and shifting the other items in the grid around. I was surprised to learn that 1) I have to use JavaScript to use View Transitions, and 2) that I have to give each item in the Grid a unique `view-transition-name`, and there's no mechanism for applying the functionality to all items. This caused me to have to write this code: ``` .card:nth-child(1) { view-transition-name: card-1; } .card:nth-child(2) { view-transition-name: card-2; } .card:nth-child(3) { view-transition-name: card-3; } .card:nth-child(4) { view-transition-name: card-4; } .card:nth-child(5) { view-transition-name: card-5; } .card:nth-child(6) { view-transition-name: card-6; } .card:nth-child(7) { view-transition-name: card-7; } .card:nth-child(8) { view-transition-name: card-8; } .card:nth-child(9) { view-transition-name: card-9; } .card:nth-child(10) { view-transition-name: card-10; } .card:nth-child(11) { view-transition-name: card-11; } .card:nth-child(12) { view-transition-name: card-12; } .card:nth-child(13) { view-transition-name: card-13; } .card:nth-child(14) { view-transition-name: card-14; } .card:nth-child(15) { view-transition-name: card-15; } .card:nth-child(16) { view-transition-name: card-16; } .card:nth-child(17) { view-transition-name: card-17; } .card:nth-child(18) { view-transition-name: card-18; } .card:nth-child(19) { view-transition-name: card-19; } .card:nth-child(20) { view-transition-name: card-20; } .card:nth-child(21) { view-transition-name: card-21; } .card:nth-child(22) { view-transition-name: card-22; } .card:nth-child(23) { view-transition-name: card-23; } .card:nth-child(24) { view-transition-name: card-24; } .card:nth-child(25) { view-transition-name: card-25; } .card:nth-child(26) { view-transition-name: card-26; } .card:nth-child(27) { view-transition-name: card-27; } .card:nth-child(28) { view-transition-name: card-28; } .card:nth-child(29) { view-transition-name: card-29; } .card:nth-child(30) { view-transition-name: card-30; } .card:nth-child(31) { view-transition-name: card-31; } .card:nth-child(32) { view-transition-name: card-32; } .card:nth-child(33) { view-transition-name: card-33; } .card:nth-child(34) { view-transition-name: card-34; } .card:nth-child(35) { view-transition-name: card-35; } .card:nth-child(36) { view-transition-name: card-36; } .card:nth-child(37) { view-transition-name: card-37; } .card:nth-child(38) { view-transition-name: card-38; } .card:nth-child(39) { view-transition-name: card-39; } .card:nth-child(40) { view-transition-name: card-40; } .card:nth-child(41) { view-transition-name: card-41; } .card:nth-child(42) { view-transition-name: card-42; } .card:nth-child(43) { view-transition-name: card-43; } .card:nth-child(44) { view-transition-name: card-44; } .card:nth-child(45) { view-transition-name: card-45; } .card:nth-child(46) { view-transition-name: card-46; } .card:nth-child(47) { view-transition-name: card-47; } .card:nth-child(48) { view-transition-name: card-48; } .card:nth-child(49) { view-transition-name: card-49; } .card:nth-child(50) { view-transition-name: card-50; } ``` Which is not robust — what if there are more than 50 items on the Grid?? The experience will break. It seems View Transitions was designed with the expectation that websites are JavaScript first — that it's fine if every items needs to be uniquely named, a developer can just use JS to create all the HTML, and inline styles with JS-created names. -- GitHub Notification of comment by jensimmons Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8320#issuecomment-2023077559 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I'm making a simple demo that uses View Transitions to animate enlarging an item that's laid out with CSS Grid, and shifting the other items in the grid around. I was surprised to learn that 1) I have to use JavaScript to use View Transitions, and 2) that I have to give each item in the Grid a unique `view-transition-name`, and there's no mechanism for applying the functionality to all items. This caused me to have to write this code: ``` .card:nth-child(1) { view-transition-name: card-1; } .card:nth-child(2) { view-transition-name: card-2; } .card:nth-child(3) { view-transition-name: card-3; } .card:nth-child(4) { view-transition-name: card-4; } .card:nth-child(5) { view-transition-name: card-5; } .card:nth-child(6) { view-transition-name: card-6; } .card:nth-child(7) { view-transition-name: card-7; } .card:nth-child(8) { view-transition-name: card-8; } .card:nth-child(9) { view-transition-name: card-9; } .card:nth-child(10) { view-transition-name: card-10; } .card:nth-child(11) { view-transition-name: card-11; } .card:nth-child(12) { view-transition-name: card-12; } .card:nth-child(13) { view-transition-name: card-13; } .card:nth-child(14) { view-transition-name: card-14; } .card:nth-child(15) { view-transition-name: card-15; } .card:nth-child(16) { view-transition-name: card-16; } .card:nth-child(17) { view-transition-name: card-17; } .card:nth-child(18) { view-transition-name: card-18; } .card:nth-child(19) { view-transition-name: card-19; } .card:nth-child(20) { view-transition-name: card-20; } .card:nth-child(21) { view-transition-name: card-21; } .card:nth-child(22) { view-transition-name: card-22; } .card:nth-child(23) { view-transition-name: card-23; } .card:nth-child(24) { view-transition-name: card-24; } .card:nth-child(25) { view-transition-name: card-25; } .card:nth-child(26) { view-transition-name: card-26; } .card:nth-child(27) { view-transition-name: card-27; } .card:nth-child(28) { view-transition-name: card-28; } .card:nth-child(29) { view-transition-name: card-29; } .card:nth-child(30) { view-transition-name: card-30; } .card:nth-child(31) { view-transition-name: card-31; } .card:nth-child(32) { view-transition-name: card-32; } .card:nth-child(33) { view-transition-name: card-33; } .card:nth-child(34) { view-transition-name: card-34; } .card:nth-child(35) { view-transition-name: card-35; } .card:nth-child(36) { view-transition-name: card-36; } .card:nth-child(37) { view-transition-name: card-37; } .card:nth-child(38) { view-transition-name: card-38; } .card:nth-child(39) { view-transition-name: card-39; } .card:nth-child(40) { view-transition-name: card-40; } .card:nth-child(41) { view-transition-name: card-41; } .card:nth-child(42) { view-transition-name: card-42; } .card:nth-child(43) { view-transition-name: card-43; } .card:nth-child(44) { view-transition-name: card-44; } .card:nth-child(45) { view-transition-name: card-45; } .card:nth-child(46) { view-transition-name: card-46; } .card:nth-child(47) { view-transition-name: card-47; } .card:nth-child(48) { view-transition-name: card-48; } .card:nth-child(49) { view-transition-name: card-49; } .card:nth-child(50) { view-transition-name: card-50; } ``` Which is not robust — what if there are more than 50 items on the Grid?? The experience will break. It seems View Transitions was designed with the expectation that websites are JavaScript first — that it's fine if every items needs to be uniquely named, a developer can just use JS to create all the HTML, and inline styles with JS-created names. -- GitHub Notification of comment by jensimmons Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8320#issuecomment-2023077559 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Just adding my 2️⃣ 🪙 -- for SSR rendering of web components being able to use `::slotted::part` would allow you handle correct styling of nested components from the shadow dom styles of the parent component to have it styled correctly before the web component is hydrated on the front end. Currently any of the existing solutions like passing props or styles down to child components will cause page shift for the component related to the nested rules not being present at load time before JS fires. -- GitHub Notification of comment by jlukic Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3896#issuecomment-2023045819 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
frivoal has just labeled a pull request from birtles for https://github.com/w3c/csswg-drafts as "Commenter Response Pending": == [css-text-4] Add note about deviations from UAX-14 == Fixes #9432 See https://github.com/w3c/csswg-drafts/pull/9997 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
frivoal has just labeled a pull request from birtles for https://github.com/w3c/csswg-drafts as "Commenter Response Pending": == [css-text-4] Add note about deviations from UAX-14 == Fixes #9432 See https://github.com/w3c/csswg-drafts/pull/9997 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
frivoal has just labeled a pull request from birtles for https://github.com/w3c/csswg-drafts as "Commenter Response Pending": == [css-text-4] Add note about deviations from UAX-14 == Fixes #9432 See https://github.com/w3c/csswg-drafts/pull/9997 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
frivoal has just labeled a pull request from birtles for https://github.com/w3c/csswg-drafts as "Commenter Response Pending": == [css-text-4] Add note about deviations from UAX-14 == Fixes #9432 See https://github.com/w3c/csswg-drafts/pull/9997 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
frivoal has just labeled a pull request from birtles for https://github.com/w3c/csswg-drafts as "Commenter Response Pending": == [css-text-4] Add note about deviations from UAX-14 == Fixes #9432 See https://github.com/w3c/csswg-drafts/pull/9997 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
frivoal has just labeled a pull request from birtles for https://github.com/w3c/csswg-drafts as "Commenter Response Pending": == [css-text-4] Add note about deviations from UAX-14 == Fixes #9432 See https://github.com/w3c/csswg-drafts/pull/9997 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
frivoal has just labeled a pull request from birtles for https://github.com/w3c/csswg-drafts as "Commenter Response Pending": == [css-text-4] Add note about deviations from UAX-14 == Fixes #9432 See https://github.com/w3c/csswg-drafts/pull/9997 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@birtles your GitHub account doesn't seem to be associated with your W3C account. At least I think that's why the IPR check fails. Could you double check on that? -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9997#issuecomment-2022281653 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Removed the RESOLVED line from the summary posted by the bot, as it actually belonged to the previous issue on the agenda, https://github.com/w3c/csswg-drafts/issues/9112, and putting back on the Agenda, since that's what we said we'd do -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9310#issuecomment-2022266714 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
hiikezoe has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-viewport] Each property name should be case-ascii-insensitive? == From the spec text; > Set-Property matches the [listed property names](https://drafts.csswg.org/css-viewport/#meta-properties) case-insensitively. The property-value strings are interpreted as follows: It clearly mentions "case-insensitively" but it should be case-ascii-insensitively? Emilio raised this question, and apparently [Chrome handles it case-ascii-insensitively](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/html_meta_element.cc;l=303-343;drc=9a183cad71c06f491775e34da5473e7a19d035f2). CC @bokand Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10146 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
hiikezoe has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-viewport] Each property name should be case-ascii-insensitive? == From the spec text; > Set-Property matches the [listed property names](https://drafts.csswg.org/css-viewport/#meta-properties) case-insensitively. The property-value strings are interpreted as follows: It clearly mentions "case-insensitively" but it should be case-ascii-insensitively? Emilio raised this question, and apparently [Chrome handles it case-ascii-insensitively](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/html_meta_element.cc;l=303-343;drc=9a183cad71c06f491775e34da5473e7a19d035f2). CC @bokand Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10146 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar closed this issue. See https://github.com/w3c/csswg-drafts/issues/10011 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar closed this issue. See https://github.com/w3c/csswg-drafts/issues/10011 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar closed this issue. See https://github.com/w3c/csswg-drafts/issues/10011 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar closed this issue. See https://github.com/w3c/csswg-drafts/issues/10011 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar closed this issue. See https://github.com/w3c/csswg-drafts/issues/10011 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] Should view transition names be tree scoped? == The spec currently traverses all DOM elements to look for view transition names, see text [here](https://drafts.csswg.org/css-view-transitions-1/#capture-old-state-algorithm:~:text=block%20size.-,For%20each%20element%20of%20every%20element%20that%20is%20connected%2C%20and%20has%20a%20node%20document%20equal%20to%20to%20document,-%2C%20in%20paint%20order). This should probably be tree scoped similar to other CSS naming conventions like [scroll timeline](https://github.com/w3c/csswg-drafts/issues/8135) and I'm guessing anchor positioning (@tabatkins ?). @nt1m fyi. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10145 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] Should view transition names be tree scoped? == The spec currently traverses all DOM elements to look for view transition names, see text [here](https://drafts.csswg.org/css-view-transitions-1/#capture-old-state-algorithm:~:text=block%20size.-,For%20each%20element%20of%20every%20element%20that%20is%20connected%2C%20and%20has%20a%20node%20document%20equal%20to%20to%20document,-%2C%20in%20paint%20order). This should probably be tree scoped similar to other CSS naming conventions like [scroll timeline](https://github.com/w3c/csswg-drafts/issues/8135) and I'm guessing anchor positioning (@tabatkins ?). @nt1m fyi. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10145 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] Should view transition names be tree scoped? == The spec currently traverses all DOM elements to look for view transition names, see text [here](https://drafts.csswg.org/css-view-transitions-1/#capture-old-state-algorithm:~:text=block%20size.-,For%20each%20element%20of%20every%20element%20that%20is%20connected%2C%20and%20has%20a%20node%20document%20equal%20to%20to%20document,-%2C%20in%20paint%20order). This should probably be tree scoped similar to other CSS naming conventions like [scroll timeline](https://github.com/w3c/csswg-drafts/issues/8135) and I'm guessing anchor positioning (@tabatkins ?). @nt1m fyi. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10145 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] Should view transition names be tree scoped? == The spec currently traverses all DOM elements to look for view transition names, see text [here](https://drafts.csswg.org/css-view-transitions-1/#capture-old-state-algorithm:~:text=block%20size.-,For%20each%20element%20of%20every%20element%20that%20is%20connected%2C%20and%20has%20a%20node%20document%20equal%20to%20to%20document,-%2C%20in%20paint%20order). This should probably be tree scoped similar to other CSS naming conventions like [scroll timeline](https://github.com/w3c/csswg-drafts/issues/8135) and I'm guessing anchor positioning (@tabatkins ?). @nt1m fyi. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10145 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] Should view transition names be tree scoped? == The spec currently traverses all DOM elements to look for view transition names, see text [here](https://drafts.csswg.org/css-view-transitions-1/#capture-old-state-algorithm:~:text=block%20size.-,For%20each%20element%20of%20every%20element%20that%20is%20connected%2C%20and%20has%20a%20node%20document%20equal%20to%20to%20document,-%2C%20in%20paint%20order). This should probably be tree scoped similar to other CSS naming conventions like [scroll timeline](https://github.com/w3c/csswg-drafts/issues/8135) and I'm guessing anchor positioning (@tabatkins ?). @nt1m fyi. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10145 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] Should view transition names be tree scoped? == The spec currently traverses all DOM elements to look for view transition names, see text [here](https://drafts.csswg.org/css-view-transitions-1/#capture-old-state-algorithm:~:text=block%20size.-,For%20each%20element%20of%20every%20element%20that%20is%20connected%2C%20and%20has%20a%20node%20document%20equal%20to%20to%20document,-%2C%20in%20paint%20order). This should probably be tree scoped similar to other CSS naming conventions like [scroll timeline](https://github.com/w3c/csswg-drafts/issues/8135) and I'm guessing anchor positioning (@tabatkins ?). @nt1m fyi. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10145 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] Should view transition names be tree scoped? == The spec currently traverses all DOM elements to look for view transition names, see text [here](https://drafts.csswg.org/css-view-transitions-1/#capture-old-state-algorithm:~:text=block%20size.-,For%20each%20element%20of%20every%20element%20that%20is%20connected%2C%20and%20has%20a%20node%20document%20equal%20to%20to%20document,-%2C%20in%20paint%20order). This should probably be tree scoped similar to other CSS naming conventions like [scroll timeline](https://github.com/w3c/csswg-drafts/issues/8135) and I'm guessing anchor positioning (@tabatkins ?). @nt1m fyi. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10145 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
MurakamiShinyu has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-text-4] Japanese Paragraph-start Conventions in CSS need to be updated == CSS Text Module Level 4 8.5.3. Japanese Paragraph-start Conventions in CSS https://drafts.csswg.org/css-text-4/#japanese-start-edges > - Brackets flush with indent, flush with other lines (first scheme): > ```css > p { /* Flush alignment */ > margin: 0; > text-indent: 1em; > text-spacing-trim: trim-auto; > } > ``` > - Brackets preserve fullwidth spacing on all lines (second scheme): > ```css > p { /* Fullwidth alignment */ > margin: 0; > text-indent: 1em; > text-spacing-trim: space-all; > } > ``` > - Brackets hang in indent, flush with other lines (third scheme): > ```css > p { /* Hanging alignment */ > margin: 0; > text-indent: 1em; > text-spacing-trim: trim-auto; > hanging-punctuation: first; > } > ``` In the second scheme, `text-spacing-trim: space-all` which is typographically very poor should be changed to `text-spacing-trim: normal`. In the first and third schemes, `text-spacing-trim: trim-auto` is good but `text-spacing-trim: trim-start` would be more appropriate because: - `trim-start` just changes the line start behavior and keeps the line end behavior as `normal`. This is good to show the differences between Japanese paragraph-start conventions. - [JLREQ §3.1.9 Positioning of Closing Brackets, Full Stops, Commas and Middle Dots at Line End](https://www.w3.org/TR/jlreq/#positioning_of_closing_brackets_full_stops_commas_and_middle_dots_at_line_end) says “In principle, closing brackets (cl-02), commas (cl-07) or full stops (cl-06) at the line end have half em spacing after them. This half em spacing can be removed for line adjustment.” This corresponds to `trim-start`'s line end behavior, not `trim-auto`'s. - Chromium supports `trim-start` but not `trim-auto` yet, unfortunately. (https://developer.chrome.com/blog/chrome-123-beta#the_css_text-spacing-trim_property says “The `text-spacing-trim` property accepts one of the following four values: `normal`, `trim-start`, `space-all`, and `space-first`.”) So I suggest changing these examples as follows: - Brackets flush with indent, flush with other lines (first scheme): ```css p { /* Flush alignment */ margin: 0; text-indent: 1em; text-spacing-trim: trim-start; } ``` - Brackets preserve fullwidth spacing on all lines (second scheme): ```css p { /* Fullwidth alignment */ margin: 0; text-indent: 1em; text-spacing-trim: normal; } ``` - Brackets hang in indent, flush with other lines (third scheme): ```css p { /* Hanging alignment */ margin: 0; text-indent: 1em; text-spacing-trim: trim-start; hanging-punctuation: first; } ``` Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10144 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/8472 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Use readonly attributes for `CSSViewTransitionRule` == Closes #10011 See https://github.com/w3c/csswg-drafts/pull/10143 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Use readonly attributes for `CSSViewTransitionRule` == Closes #10011 See https://github.com/w3c/csswg-drafts/pull/10143 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Use readonly attributes for `CSSViewTransitionRule` == Closes #10011 See https://github.com/w3c/csswg-drafts/pull/10143 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Use readonly attributes for `CSSViewTransitionRule` == Closes #10011 See https://github.com/w3c/csswg-drafts/pull/10143 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Use readonly attributes for `CSSViewTransitionRule` == Closes #10011 See https://github.com/w3c/csswg-drafts/pull/10143 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Use readonly attributes for `CSSViewTransitionRule` == Closes #10011 See https://github.com/w3c/csswg-drafts/pull/10143 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Use readonly attributes for `CSSViewTransitionRule` == Closes #10011 See https://github.com/w3c/csswg-drafts/pull/10143 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I would say, that for 95% of the usecases that run into this, they would be fine falling back onto using the window for placement. Perhaps just a "sticky-window" or something like that additional, could solve the issue, but not open the need to select the anhoring ansestor. You would just get your parent, or the window. And if you choose the window, things like overflow and the ancestors scroll position is not longer taken into account, cause it can just be relative to the window. -- GitHub Notification of comment by webark Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/865#issuecomment-2019998573 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I would say, that for 95% of the usecases that run into this, they would be fine falling back onto using the window for placement. Perhaps just a "sticky-window" or something like that additional, could solve the issue, but not open the need to select the anhoring ansestor. You would just get your parent, or the window. And if you choose the window, things like overflow and the ancestors scroll position is not longer taken into account, cause it can just be relative to the window. -- GitHub Notification of comment by webark Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/865#issuecomment-2019998573 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I would say, that for 95% of the usecases that run into this, they would be fine falling back onto using the window for placement. Perhaps just a "sticky-window" or something like that additional, could solve the issue, but not open the need to select the anhoring ansestor. You would just get your parent, or the window. And if you choose the window, things like overflow and the ancestors scroll position is not longer taken into account, cause it can just be relative to the window. -- GitHub Notification of comment by webark Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/865#issuecomment-2019998573 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I would say, that for 95% of the usecases that run into this, they would be fine falling back onto using the window for placement. Perhaps just a "sticky-window" or something like that additional, could solve the issue, but not open the need to select the anhoring ansestor. You would just get your parent, or the window. And if you choose the window, things like overflow and the ancestors scroll position is not longer taken into account, cause it can just be relative to the window. -- GitHub Notification of comment by webark Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/865#issuecomment-2019998573 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I would say, that for 95% of the usecases that run into this, they would be fine falling back onto using the window for placement. Perhaps just a "sticky-window" or something like that additional, could solve the issue, but not open the need to select the anhoring ansestor. You would just get your parent, or the window. And if you choose the window, things like overflow and the ancestors scroll position is not longer taken into account, cause it can just be relative to the window. -- GitHub Notification of comment by webark Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/865#issuecomment-2019998573 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I would say, that for 95% of the usecases that run into this, they would be fine falling back onto using the window for placement. Perhaps just a "sticky-window" or something like that additional, could solve the issue, but not open the need to select the anhoring ansestor. You would just get your parent, or the window. And if you choose the window, things like overflow and the ancestors scroll position is not longer taken into account, cause it can just be relative to the window. -- GitHub Notification of comment by webark Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/865#issuecomment-2019998573 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I would say, that for 95% of the usecases that run into this, they would be fine falling back onto using the window for placement. Perhaps just a "sticky-window" or something like that additional, could solve the issue, but not open the need to select the anhoring ansestor. You would just get your parent, or the window. And if you choose the window, things like overflow and the ancestors scroll position is not longer taken into account, cause it can just be relative to the window. -- GitHub Notification of comment by webark Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/865#issuecomment-2019998573 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I would say, that for 95% of the usecases that run into this, they would be fine falling back onto using the window for placement. Perhaps just a "sticky-window" or something like that additional, could solve the issue, but not open the need to select the anhoring ansestor. You would just get your parent, or the window. And if you choose the window, things like overflow and the ancestors scroll position is not longer taken into account, cause it can just be relative to the window. -- GitHub Notification of comment by webark Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/865#issuecomment-2019998573 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Should `CSSViewTransitionTypeSet` specifically handle `none`? == Since [`@view-transition/types`](https://drafts.csswg.org/css-view-transitions-2/#descdef-view-transition-types) is defined with either `none` or `<custom-ident>+`, should [`CSSViewTransitionTypeSet`](https://drafts.csswg.org/css-view-transitions-2/#cssviewtransitiontypeset) entries be cleared when adding `none`? Note: there is probably no need to check for a valid `<custom-ident>`, assuming the input is [escaped](https://drafts.csswg.org/cssom-1/#dom-css-escape) at parse/serialization time when required (eg. `{}`, `;`, `1`, etc). Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10142 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Should `CSSViewTransitionTypeSet` specifically handle `none`? == Since [`@view-transition/types`](https://drafts.csswg.org/css-view-transitions-2/#descdef-view-transition-types) is defined with either `none` or `<custom-ident>+`, should [`CSSViewTransitionTypeSet`](https://drafts.csswg.org/css-view-transitions-2/#cssviewtransitiontypeset) entries be cleared when adding `none`? Note: there is probably no need to check for a valid `<custom-ident>`, assuming the input is [escaped](https://drafts.csswg.org/cssom-1/#dom-css-escape) at parse/serialization time when required (eg. `{}`, `;`, `1`, etc). Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10142 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Should `CSSViewTransitionTypeSet` specifically handle `none`? == Since [`@view-transition/types`](https://drafts.csswg.org/css-view-transitions-2/#descdef-view-transition-types) is defined with either `none` or `<custom-ident>+`, should [`CSSViewTransitionTypeSet`](https://drafts.csswg.org/css-view-transitions-2/#cssviewtransitiontypeset) entries be cleared when adding `none`? Note: there is probably no need to check for a valid `<custom-ident>`, assuming the input is [escaped](https://drafts.csswg.org/cssom-1/#dom-css-escape) at parse/serialization time when required (eg. `{}`, `;`, `1`, etc). Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10142 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Should `CSSViewTransitionTypeSet` specifically handle `none`? == Since [`@view-transition/types`](https://drafts.csswg.org/css-view-transitions-2/#descdef-view-transition-types) is defined with either `none` or `<custom-ident>+`, should [`CSSViewTransitionTypeSet`](https://drafts.csswg.org/css-view-transitions-2/#cssviewtransitiontypeset) entries be cleared when adding `none`? Note: there is probably no need to check for a valid `<custom-ident>`, assuming the input is [escaped](https://drafts.csswg.org/cssom-1/#dom-css-escape) at parse/serialization time when required (eg. `{}`, `;`, `1`, etc). Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10142 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Should `CSSViewTransitionTypeSet` specifically handle `none`? == Since [`@view-transition/types`](https://drafts.csswg.org/css-view-transitions-2/#descdef-view-transition-types) is defined with either `none` or `<custom-ident>+`, should [`CSSViewTransitionTypeSet`](https://drafts.csswg.org/css-view-transitions-2/#cssviewtransitiontypeset) entries be cleared when adding `none`? Note: there is probably no need to check for a valid `<custom-ident>`, assuming the input is [escaped](https://drafts.csswg.org/cssom-1/#dom-css-escape) at parse/serialization time when required (eg. `{}`, `;`, `1`, etc). Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10142 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Asked opinions from web developer's point of view and got some feedback. Web developer's basic requirement is to be able to get a caret position inside shadow roots. The Firefox approach (piercing through the shadow boundary) is acceptable. In fact, sticking to the already existing behavior would allow web developer to simplify the implementation. Given that, should we specify the already existing Firefox approach and put it in spec? -- GitHub Notification of comment by siliu1 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9932#issuecomment-2019326300 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
macnmm has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-text-4] hanging-punctuation property not language-specific enough == https://drafts.csswg.org/css-text-4/#hanging-punctuation-property The list of hanging characters includes characters that should not hang if processing layout according to Japanese rules. At least there should be modifications to the behavior based on the language conventions being emulated. For example, Latin period characters are used in Japanese layout, but should not hang; but Japanese period and comma should. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10141 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
macnmm has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-text-4] text-transform-property full-size-kana seems out of place == https://www.w3.org/TR/css-text-4/#text-transform-property > Converts all [small Kana](https://www.w3.org/TR/css-text-4/#kana-small) characters to the equivalent [full-size Kana](https://www.w3.org/TR/css-text-4/#kana-full-size). This value is typically used for ruby annotation text, where authors may want all small Kana to be drawn as large Kana to compensate for legibility issues at the small font sizes typically used in ruby. Small kana is not equivalent to large kana -- small kana cannot exist on their own but modify the character before and are always attached to the prior character. They are not simply a small version of the large kana character. In ruby usage, it is true to make it more legible by convention, small kana are written the same size (or very close) to the other kana. Kana OTF feature can perform this using glyph substitution. I believe changing the text itself, in the manner of a case change, is completely a different and unrelated transformation to this ruby usage of a larger glyph to display what is functionally a different character altogether. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10140 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/9598 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/9598 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/9149 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@keithamus I am unclear why the agenda+ tag was added here (and we often miss tagged PRs for the agenda). If there is a question that needs resolving could you open an issue? -- GitHub Notification of comment by astearns Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/8213#issuecomment-2019160468 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@keithamus I am unclear why the agenda+ tag was added here (and we often miss tagged PRs for the agenda). If there is a question that needs resolving could you open an issue? -- GitHub Notification of comment by astearns Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/8213#issuecomment-2019160468 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Yeah, I think there's plenty of reasonable use-cases here. We'll just need to figure out exactly what sort of things to expose; there's potentially a long list of page-related boxes. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8301#issuecomment-2019145063 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Yeah, I think there's plenty of reasonable use-cases here. We'll just need to figure out exactly what sort of things to expose; there's potentially a long list of page-related boxes. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8301#issuecomment-2019145063 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Yeah, I think there's plenty of reasonable use-cases here. We'll just need to figure out exactly what sort of things to expose; there's potentially a long list of page-related boxes. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8301#issuecomment-2019145063 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-align-3][css-overflow-3] Content alignment on scroll containers extends scrollable area #4957 == See #4957. Review questions: * Should we collapse the concepts of "scroll origin position" and "initial scroll position" now that they coincide even in the presence of alignment? If so, which word should we use? * I think we can close the two issues marked in https://drafts.csswg.org/css-overflow-3/#scrolling ? * Having the[ "The scrollable overflow area is the union of:" list](https://drafts.csswg.org/css-overflow-3/#scrollable) before the [definition of key terms like “scroll position”](https://drafts.csswg.org/css-overflow-3/#scrolling) seems wrong. Should I pull it out into its own subsection? Where? See https://github.com/w3c/csswg-drafts/pull/10139 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-align-3][css-overflow-3] Content alignment on scroll containers extends scrollable area #4957 == See #4957. Review questions: * Should we collapse the concepts of "scroll origin position" and "initial scroll position" now that they coincide even in the presence of alignment? If so, which word should we use? * I think we can close the two issues marked in https://drafts.csswg.org/css-overflow-3/#scrolling ? * Having the[ "The scrollable overflow area is the union of:" list](https://drafts.csswg.org/css-overflow-3/#scrollable) before the [definition of key terms like “scroll position”](https://drafts.csswg.org/css-overflow-3/#scrolling) seems wrong. Should I pull it out into its own subsection? Where? See https://github.com/w3c/csswg-drafts/pull/10139 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-align-3][css-overflow-3] Content alignment on scroll containers extends scrollable area #4957 == See #4957. Review questions: * Should we collapse the concepts of "scroll origin position" and "initial scroll position" now that they coincide even in the presence of alignment? If so, which word should we use? * I think we can close the two issues marked in https://drafts.csswg.org/css-overflow-3/#scrolling ? * Having the[ "The scrollable overflow area is the union of:" list](https://drafts.csswg.org/css-overflow-3/#scrollable) before the [definition of key terms like “scroll position”](https://drafts.csswg.org/css-overflow-3/#scrolling) seems wrong. Should I pull it out into its own subsection? Where? See https://github.com/w3c/csswg-drafts/pull/10139 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-align-3][css-overflow-3] Content alignment on scroll containers extends scrollable area #4957 == See #4957. Review questions: * Should we collapse the concepts of "scroll origin position" and "initial scroll position" now that they coincide even in the presence of alignment? If so, which word should we use? * I think we can close the two issues marked in https://drafts.csswg.org/css-overflow-3/#scrolling ? * Having the[ "The scrollable overflow area is the union of:" list](https://drafts.csswg.org/css-overflow-3/#scrollable) before the [definition of key terms like “scroll position”](https://drafts.csswg.org/css-overflow-3/#scrolling) seems wrong. Should I pull it out into its own subsection? Where? See https://github.com/w3c/csswg-drafts/pull/10139 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-align-3][css-overflow-3] Content alignment on scroll containers extends scrollable area #4957 == See #4957. Review questions: * Should we collapse the concepts of "scroll origin position" and "initial scroll position" now that they coincide even in the presence of alignment? If so, which word should we use? * I think we can close the two issues marked in https://drafts.csswg.org/css-overflow-3/#scrolling ? * Having the[ "The scrollable overflow area is the union of:" list](https://drafts.csswg.org/css-overflow-3/#scrollable) before the [definition of key terms like “scroll position”](https://drafts.csswg.org/css-overflow-3/#scrolling) seems wrong. Should I pull it out into its own subsection? Where? See https://github.com/w3c/csswg-drafts/pull/10139 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
We did discuss scroll containers being an exception here in https://github.com/w3c/csswg-drafts/issues/8992 actually; but it wasn't clear in the resolution... -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10008#issuecomment-2019018691 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
We did discuss scroll containers being an exception here in https://github.com/w3c/csswg-drafts/issues/8992 actually; but it wasn't clear in the resolution... -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10008#issuecomment-2019018691 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
We did discuss scroll containers being an exception here in https://github.com/w3c/csswg-drafts/issues/8992 actually; but it wasn't clear in the resolution... -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10008#issuecomment-2019018691 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
We did discuss scroll containers being an exception here in https://github.com/w3c/csswg-drafts/issues/8992 actually; but it wasn't clear in the resolution... -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10008#issuecomment-2019018691 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-align] Empty cells are excluded from baseline alignment == https://drafts.csswg.org/css-align/#baseline-export > If any cells in the row participate in [first baseline](https://drafts.csswg.org/css-align/#valdef-justify-self-first-baseline)/[last baseline](https://drafts.csswg.org/css-align/#valdef-justify-self-last-baseline) alignment along the [inline axis](https://drafts.csswg.org/css-writing-modes-4/#inline-axis), the first/last [baseline set](https://drafts.csswg.org/css-align/#baseline-set) of the row is [generated](https://drafts.csswg.org/css-align/#generate-baselines) from their shared [alignment baseline](https://drafts.csswg.org/css-align/#alignment-baseline) and the row’s [first available font](https://drafts.csswg.org/css-fonts-4/#first-available-font), after alignment has been performed. However, all browsers skip empty cells, even if they have `vertical-align: baseline`: ``` <!DOCTYPE html> a <table style="display: inline-table; border: 10px solid; margin: 10px"> <td style="vertical-align: baseline; width: 50px; height: 50px; border: solid cyan"></td> </table> ``` | Gecko, Blink | WebKit | | - | - | | ![](https://github.com/w3c/csswg-drafts/assets/7477678/1539f91a-07a2-414f-846f-32c2e554e8d9) | ![](https://github.com/w3c/csswg-drafts/assets/7477678/0299c25d-cb50-45d8-bbd5-0125dee11c9b) | However, the definition of "empty" varies. For this purpose, Blink considers that the cell isn't empty if it has any content (in-flow or out-of-flow) other than collapsed whitespace. This is similar to the logic used by `empty-cells`, but counting abspos content as not empty. ``` <!DOCTYPE html> a <table style="display: inline-table; border: 10px solid; margin: 10px"> <td style="vertical-align: baseline; width: 50px; height: 50px; border: solid cyan"> <div style="position:absolute"></div> </td> </table> ``` | Gecko | Blink | WebKit | | - | - | - | | ![](https://github.com/w3c/csswg-drafts/assets/7477678/1539f91a-07a2-414f-846f-32c2e554e8d9) | ![](https://github.com/w3c/csswg-drafts/assets/7477678/fe167656-ab43-4843-a910-9cf3f42f3599) | ![](https://github.com/w3c/csswg-drafts/assets/7477678/0299c25d-cb50-45d8-bbd5-0125dee11c9b) | Gecko and WebKit still consider the cell empty if it contains something like: - `<div class="cell" style="font-size: 0px">X</div>` - `<div style="position: absolute; height: 1px"></div>` - `<div style="float: left"></div>` - `<div></div>` However, Gecko doesn't consider the above as empty if the cell has border or padding. But they don't consider these as empty: - `<div style="float: left; height: 1px"></div>` - `<div style="height: 1px"></div>` - `<span></span>` - `<div style="display: inline-block"></div>` - `<canvas style="height: 0; width: 0"></div>` Another interesting case: Gecko considers this as empty, WebKit doesn't: ```html a <table style="display: inline-table; border: 10px solid; margin: 10px"> <td style="vertical-align: baseline; width: 50px; height: 50px; padding: 0"> <div style="font-size: 0"> <div style="display: inline-block; height: 30px; width: 10px; background: orange; vertical-align: top"></div> </div> </td> </table> ``` | Gecko | Blink | WebKit | | - | - | - | | ![](https://github.com/w3c/csswg-drafts/assets/7477678/99283a20-e0e7-4d8e-a2ac-10202a38b20c) | ![](https://github.com/w3c/csswg-drafts/assets/7477678/95c8cadc-1b6b-46a8-9e28-451e665ec379) | ![imatge](https://github.com/w3c/csswg-drafts/assets/7477678/ffc8072b-164a-41ef-b393-ae4bdfcbdada) | Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10138 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-align] Empty cells are excluded from baseline alignment == https://drafts.csswg.org/css-align/#baseline-export > If any cells in the row participate in [first baseline](https://drafts.csswg.org/css-align/#valdef-justify-self-first-baseline)/[last baseline](https://drafts.csswg.org/css-align/#valdef-justify-self-last-baseline) alignment along the [inline axis](https://drafts.csswg.org/css-writing-modes-4/#inline-axis), the first/last [baseline set](https://drafts.csswg.org/css-align/#baseline-set) of the row is [generated](https://drafts.csswg.org/css-align/#generate-baselines) from their shared [alignment baseline](https://drafts.csswg.org/css-align/#alignment-baseline) and the row’s [first available font](https://drafts.csswg.org/css-fonts-4/#first-available-font), after alignment has been performed. However, all browsers skip empty cells, even if they have `vertical-align: baseline`: ``` <!DOCTYPE html> a <table style="display: inline-table; border: 10px solid; margin: 10px"> <td style="vertical-align: baseline; width: 50px; height: 50px; border: solid cyan"></td> </table> ``` | Gecko, Blink | WebKit | | - | - | | ![](https://github.com/w3c/csswg-drafts/assets/7477678/1539f91a-07a2-414f-846f-32c2e554e8d9) | ![](https://github.com/w3c/csswg-drafts/assets/7477678/0299c25d-cb50-45d8-bbd5-0125dee11c9b) | However, the definition of "empty" varies. For this purpose, Blink considers that the cell isn't empty if it has any content (in-flow or out-of-flow) other than collapsed whitespace. This is similar to the logic used by `empty-cells`, but counting abspos content as not empty. ``` <!DOCTYPE html> a <table style="display: inline-table; border: 10px solid; margin: 10px"> <td style="vertical-align: baseline; width: 50px; height: 50px; border: solid cyan"> <div style="position:absolute"></div> </td> </table> ``` | Gecko | Blink | WebKit | | - | - | - | | ![](https://github.com/w3c/csswg-drafts/assets/7477678/1539f91a-07a2-414f-846f-32c2e554e8d9) | ![](https://github.com/w3c/csswg-drafts/assets/7477678/fe167656-ab43-4843-a910-9cf3f42f3599) | ![](https://github.com/w3c/csswg-drafts/assets/7477678/0299c25d-cb50-45d8-bbd5-0125dee11c9b) | Gecko and WebKit still consider the cell empty if it contains something like: - `<div class="cell" style="font-size: 0px">X</div>` - `<div style="position: absolute; height: 1px"></div>` - `<div style="float: left"></div>` - `<div></div>` However, Gecko doesn't consider the above as empty if the cell has border or padding. But they don't consider these as empty: - `<div style="float: left; height: 1px"></div>` - `<div style="height: 1px"></div>` - `<span></span>` - `<div style="display: inline-block"></div>` - `<canvas style="height: 0; width: 0"></div>` Another interesting case: Gecko considers this as empty, WebKit doesn't: ```html a <table style="display: inline-table; border: 10px solid; margin: 10px"> <td style="vertical-align: baseline; width: 50px; height: 50px; padding: 0"> <div style="font-size: 0"> <div style="display: inline-block; height: 30px; width: 10px; background: orange; vertical-align: top"></div> </div> </td> </table> ``` | Gecko | Blink | WebKit | | - | - | - | | ![](https://github.com/w3c/csswg-drafts/assets/7477678/99283a20-e0e7-4d8e-a2ac-10202a38b20c) | ![](https://github.com/w3c/csswg-drafts/assets/7477678/95c8cadc-1b6b-46a8-9e28-451e665ec379) | ![imatge](https://github.com/w3c/csswg-drafts/assets/7477678/ffc8072b-164a-41ef-b393-ae4bdfcbdada) | Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10138 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai closed this issue. See https://github.com/w3c/csswg-drafts/issues/7775 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai closed this issue. See https://github.com/w3c/csswg-drafts/issues/7775 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai closed this issue. See https://github.com/w3c/csswg-drafts/issues/8992 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-align] Baseline of row with no cells == https://drafts.csswg.org/css-align/#baseline-export > If any cells in the row participate in [first baseline](https://drafts.csswg.org/css-align/#valdef-justify-self-first-baseline)/[last baseline](https://drafts.csswg.org/css-align/#valdef-justify-self-last-baseline) alignment along the [inline axis](https://drafts.csswg.org/css-writing-modes-4/#inline-axis) [...] If there are no cells, the condition is false, so... > Otherwise, the first/last baseline set of the row is [synthesized](https://drafts.csswg.org/css-align/#synthesize-baseline) from the lowest and highest content edges of the cells in the row. What if there are no cells? ```html <!DOCTYPE html> a <table style="display: inline-table; border: 10px solid; margin: 10px; baseline-source: first; width: 60px"> <tr style="height: 20px; outline: solid cyan"></tr> <tr style="height: 20px; outline: solid orange"><td>b</td></tr> <tr style="height: 20px; outline: solid magenta"><td></td></tr> </table> <table style="display: inline-table; border: 10px solid; margin: 10px; baseline-source: last; width: 60px"> <tr style="height: 20px; outline: solid cyan"></tr> <tr style="height: 20px; outline: solid orange"><td>c</td></tr> <tr style="height: 20px; outline: solid magenta"></tr> </table> ``` | Gecko | Blink | WebKit | | - | - | - | | ![](https://github.com/w3c/csswg-drafts/assets/7477678/7b53ab88-97a6-4f4e-a8d1-8d1bb5659aef) | ![](https://github.com/w3c/csswg-drafts/assets/7477678/bf58a5cb-a62b-4db4-9895-cc73fa40fd9f) | ![](https://github.com/w3c/csswg-drafts/assets/7477678/ef974e7d-0d8a-443c-b70c-e4dadc5eb5e3) | - Gecko seems to ignore `baseline-source` on tables. The 1st baseline is placed at the top of the content area of the 1st row. - Blink places the 1st baseline at the top of the content area of the 1st row, and the last baseline at the top of the content area of the last row. - WebKit doesn't set a baseline, so it's synthesized from the bottom of the margin box (as per https://drafts.csswg.org/css-inline-3/#baseline-tables). Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10137 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-align] Baseline of row with no cells == https://drafts.csswg.org/css-align/#baseline-export > If any cells in the row participate in [first baseline](https://drafts.csswg.org/css-align/#valdef-justify-self-first-baseline)/[last baseline](https://drafts.csswg.org/css-align/#valdef-justify-self-last-baseline) alignment along the [inline axis](https://drafts.csswg.org/css-writing-modes-4/#inline-axis) [...] If there are no cells, the condition is false, so... > Otherwise, the first/last baseline set of the row is [synthesized](https://drafts.csswg.org/css-align/#synthesize-baseline) from the lowest and highest content edges of the cells in the row. What if there are no cells? ```html <!DOCTYPE html> a <table style="display: inline-table; border: 10px solid; margin: 10px; baseline-source: first; width: 60px"> <tr style="height: 20px; outline: solid cyan"></tr> <tr style="height: 20px; outline: solid orange"><td>b</td></tr> <tr style="height: 20px; outline: solid magenta"><td></td></tr> </table> <table style="display: inline-table; border: 10px solid; margin: 10px; baseline-source: last; width: 60px"> <tr style="height: 20px; outline: solid cyan"></tr> <tr style="height: 20px; outline: solid orange"><td>c</td></tr> <tr style="height: 20px; outline: solid magenta"></tr> </table> ``` | Gecko | Blink | WebKit | | - | - | - | | ![](https://github.com/w3c/csswg-drafts/assets/7477678/7b53ab88-97a6-4f4e-a8d1-8d1bb5659aef) | ![](https://github.com/w3c/csswg-drafts/assets/7477678/bf58a5cb-a62b-4db4-9895-cc73fa40fd9f) | ![](https://github.com/w3c/csswg-drafts/assets/7477678/ef974e7d-0d8a-443c-b70c-e4dadc5eb5e3) | - Gecko seems to ignore `baseline-source` on tables. The 1st baseline is placed at the top of the content area of the 1st row. - Blink places the 1st baseline at the top of the content area of the 1st row, and the last baseline at the top of the content area of the last row. - WebKit doesn't set a baseline, so it's synthesized from the bottom of the margin box (as per https://drafts.csswg.org/css-inline-3/#baseline-tables). Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10137 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Agenda+ for CSS Box L4 WD, see [issue open for confirmation](https://github.com/w3c/csswg-drafts/issues/5132) and [changes list](https://drafts.csswg.org/css-box-4/#changes); and also CSS Box L3 REC [editorial update](https://drafts.csswg.org/css-box-3/#changes). -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6900#issuecomment-2018953613 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-align] Baseline of table with no rows == https://drafts.csswg.org/css-align/#baseline-export > The first/last [baseline set](https://drafts.csswg.org/css-align/#baseline-set) of a table box is the first/last baseline set of its first/last row. What if the table has no row? Gecko/Blink/WebKit agree that it has no baseline. Therefore it's synthesized from the bottom of the margin box of the table (as per https://drafts.csswg.org/css-inline-3/#baseline-tables). ```html <!DOCTYPE html> a<div style="display: inline-table; border: 10px solid; margin: 10px; width: 50px; height: 50px"></div> ``` ![](https://github.com/w3c/csswg-drafts/assets/7477678/a810e6a2-f34a-4017-b758-77a68a8e033f) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10136 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-align] Baseline of table with no rows == https://drafts.csswg.org/css-align/#baseline-export > The first/last [baseline set](https://drafts.csswg.org/css-align/#baseline-set) of a table box is the first/last baseline set of its first/last row. What if the table has no row? Gecko/Blink/WebKit agree that it has no baseline. Therefore it's synthesized from the bottom of the margin box of the table (as per https://drafts.csswg.org/css-inline-3/#baseline-tables). ```html <!DOCTYPE html> a<div style="display: inline-table; border: 10px solid; margin: 10px; width: 50px; height: 50px"></div> ``` ![](https://github.com/w3c/csswg-drafts/assets/7477678/a810e6a2-f34a-4017-b758-77a68a8e033f) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10136 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> We actually have an explicit paint ordering for the view-transition-names so I think it'd make sense to order ::view-transition-group based on that rather than lexographically. That's how its in the spec today, see the text [here](https://drafts.csswg.org/css-view-transitions-1/#capture-the-old-state:~:text=We%20iterate%20in%20paint%20order%20to%20ensure%20that%20this%20order%20is%20cached%20in%20namedElements.%20This%20defines%20the%20DOM%20order%20for%20%3A%3Aview%2Dtransition%2Dgroup%20pseudo%2Delements%2C%20such%20that%20the%20element%20at%20the%20bottom%20of%20the%20paint%20stack%20generates%20the%20first%20pseudo%20child%20of%20%3A%3Aview%2Dtransition.). We actually rely on the DOM order of the group pseudos to make sure their paint order in the pseudo-DOM matches their paint order in the author DOM. -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9588#issuecomment-2018922346 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color][css-images] Interpolation method / color space that favors chroma over lightness == Current implementations clip out of gamut colors, which happens to produce darker but more vibrant colors in some cases. This can easily be seen as a feature instead of a bug. The current specifications are all clear that clipping should not be applied and that gamut mapping by reducing chrome in oklch is the intended method to make colors displayable. That it is easily doable with clipping does mean that authors are playing around with and are finding a use for the incorrect behavior. ----------- Is there a broad use case for interpolating in such a way that colors are as vibrant as possible between colors? Is this useful for darker and/or less vibrant gradients? I know that @argyleink has played around with this a lot, maybe he can share some more insights? Authors can manually define extra color stops to have the desired effect, but that isn't trivial. ------------ Has there been any research into this? The properties that seem to be favored: - `oklch` has a good distribution of hue's, while `hsl` is a mess. - `hsl` goes all over the place from very dark (blue) to very bright (yellow). It must preserve lightness better than `hsl`. - perceived vibrance should be the same throughout the gradient. ----- Some quick examples that illustrate how interpolating in `oklch` with out of gamut colors can produce visually nice results. https://codepen.io/romainmenke/pen/ExJXoVW?editors=1100 <img width="1470" alt="Screenshot 2024-03-25 at 19 16 27" src="https://github.com/w3c/csswg-drafts/assets/11521496/ca18f65b-4331-4424-aba0-0e879a2c39a2"> Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10135 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color][css-images] Interpolation method / color space that favors chroma over lightness == Current implementations clip out of gamut colors, which happens to produce darker but more vibrant colors in some cases. This can easily be seen as a feature instead of a bug. The current specifications are all clear that clipping should not be applied and that gamut mapping by reducing chrome in oklch is the intended method to make colors displayable. That it is easily doable with clipping does mean that authors are playing around with and are finding a use for the incorrect behavior. ----------- Is there a broad use case for interpolating in such a way that colors are as vibrant as possible between colors? Is this useful for darker and/or less vibrant gradients? I know that @argyleink has played around with this a lot, maybe he can share some more insights? Authors can manually define extra color stops to have the desired effect, but that isn't trivial. ------------ Has there been any research into this? The properties that seem to be favored: - `oklch` has a good distribution of hue's, while `hsl` is a mess. - `hsl` goes all over the place from very dark (blue) to very bright (yellow). It must preserve lightness better than `hsl`. - perceived vibrance should be the same throughout the gradient. ----- Some quick examples that illustrate how interpolating in `oklch` with out of gamut colors can produce visually nice results. https://codepen.io/romainmenke/pen/ExJXoVW?editors=1100 <img width="1470" alt="Screenshot 2024-03-25 at 19 16 27" src="https://github.com/w3c/csswg-drafts/assets/11521496/ca18f65b-4331-4424-aba0-0e879a2c39a2"> Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10135 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color][css-images] Interpolation method / color space that favors chroma over lightness == Current implementations clip out of gamut colors, which happens to produce darker but more vibrant colors in some cases. This can easily be seen as a feature instead of a bug. The current specifications are all clear that clipping should not be applied and that gamut mapping by reducing chrome in oklch is the intended method to make colors displayable. That it is easily doable with clipping does mean that authors are playing around with and are finding a use for the incorrect behavior. ----------- Is there a broad use case for interpolating in such a way that colors are as vibrant as possible between colors? Is this useful for darker and/or less vibrant gradients? I know that @argyleink has played around with this a lot, maybe he can share some more insights? Authors can manually define extra color stops to have the desired effect, but that isn't trivial. ------------ Has there been any research into this? The properties that seem to be favored: - `oklch` has a good distribution of hue's, while `hsl` is a mess. - `hsl` goes all over the place from very dark (blue) to very bright (yellow). It must preserve lightness better than `hsl`. - perceived vibrance should be the same throughout the gradient. ----- Some quick examples that illustrate how interpolating in `oklch` with out of gamut colors can produce visually nice results. https://codepen.io/romainmenke/pen/ExJXoVW?editors=1100 <img width="1470" alt="Screenshot 2024-03-25 at 19 16 27" src="https://github.com/w3c/csswg-drafts/assets/11521496/ca18f65b-4331-4424-aba0-0e879a2c39a2"> Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10135 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color][css-images] Interpolation method / color space that favors chroma over lightness == Current implementations clip out of gamut colors, which happens to produce darker but more vibrant colors in some cases. This can easily be seen as a feature instead of a bug. The current specifications are all clear that clipping should not be applied and that gamut mapping by reducing chrome in oklch is the intended method to make colors displayable. That it is easily doable with clipping does mean that authors are playing around with and are finding a use for the incorrect behavior. ----------- Is there a broad use case for interpolating in such a way that colors are as vibrant as possible between colors? Is this useful for darker and/or less vibrant gradients? I know that @argyleink has played around with this a lot, maybe he can share some more insights? Authors can manually define extra color stops to have the desired effect, but that isn't trivial. ------------ Has there been any research into this? The properties that seem to be favored: - `oklch` has a good distribution of hue's, while `hsl` is a mess. - `hsl` goes all over the place from very dark (blue) to very bright (yellow). It must preserve lightness better than `hsl`. - perceived vibrance should be the same throughout the gradient. ----- Some quick examples that illustrate how interpolating in `oklch` with out of gamut colors can produce visually nice results. https://codepen.io/romainmenke/pen/ExJXoVW?editors=1100 <img width="1470" alt="Screenshot 2024-03-25 at 19 16 27" src="https://github.com/w3c/csswg-drafts/assets/11521496/ca18f65b-4331-4424-aba0-0e879a2c39a2"> Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10135 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color][css-images] Interpolation method / color space that favors chroma over lightness == Current implementations clip out of gamut colors, which happens to produce darker but more vibrant colors in some cases. This can easily be seen as a feature instead of a bug. The current specifications are all clear that clipping should not be applied and that gamut mapping by reducing chrome in oklch is the intended method to make colors displayable. That it is easily doable with clipping does mean that authors are playing around with and are finding a use for the incorrect behavior. ----------- Is there a broad use case for interpolating in such a way that colors are as vibrant as possible between colors? Is this useful for darker and/or less vibrant gradients? I know that @argyleink has played around with this a lot, maybe he can share some more insights? Authors can manually define extra color stops to have the desired effect, but that isn't trivial. ------------ Has there been any research into this? The properties that seem to be favored: - `oklch` has a good distribution of hue's, while `hsl` is a mess. - `hsl` goes all over the place from very dark (blue) to very bright (yellow). It must preserve lightness better than `hsl`. - perceived vibrance should be the same throughout the gradient. ----- Some quick examples that illustrate how interpolating in `oklch` with out of gamut colors can produce visually nice results. https://codepen.io/romainmenke/pen/ExJXoVW?editors=1100 <img width="1470" alt="Screenshot 2024-03-25 at 19 16 27" src="https://github.com/w3c/csswg-drafts/assets/11521496/ca18f65b-4331-4424-aba0-0e879a2c39a2"> Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10135 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [css2][css-tables] border-spacing when there are no tracks == I don't think this is in the specs, but everybody agrees that if a table has no tracks, then no border-spacing is added: ```html <!DOCTYPE html> <table style="border: 20px solid; border-spacing: 10px"></table> <br> <table style="border: 20px solid; border-spacing: 10px"> <td></td> </table> ``` ![imatge](https://github.com/w3c/csswg-drafts/assets/7477678/134d7eb1-147e-4437-ab23-124a65eb3155) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10133 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [css2][css-tables] border-spacing when there are no tracks == I don't think this is in the specs, but everybody agrees that if a table has no tracks, then no border-spacing is added: ```html <!DOCTYPE html> <table style="border: 20px solid; border-spacing: 10px"></table> <br> <table style="border: 20px solid; border-spacing: 10px"> <td></td> </table> ``` ![imatge](https://github.com/w3c/csswg-drafts/assets/7477678/134d7eb1-147e-4437-ab23-124a65eb3155) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10133 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [css2][css-tables] border-spacing when there are no tracks == I don't think this is in the specs, but everybody agrees that if a table has no tracks, then no border-spacing is added: ```html <!DOCTYPE html> <table style="border: 20px solid; border-spacing: 10px"></table> <br> <table style="border: 20px solid; border-spacing: 10px"> <td></td> </table> ``` ![imatge](https://github.com/w3c/csswg-drafts/assets/7477678/134d7eb1-147e-4437-ab23-124a65eb3155) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10133 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [css2][css-tables] Width of row that span 0 columns? == ```html <!DOCTYPE html> <table style="border: 20px solid; width: 170px; height: 170px; border-spacing: 10px"> <tr style="outline: 10px dashed cyan"></tr> <tr style="outline: 10px dotted magenta"></tr> </table> ``` | Gecko | Blink | WebKit | Servo | | - | - | - | - | | ![](https://github.com/w3c/csswg-drafts/assets/7477678/2e69f760-edc4-4d2c-8965-ca90f3aa0786) | ![](https://github.com/w3c/csswg-drafts/assets/7477678/5c634754-199a-43c7-90fc-a99090b86180) | ![](https://github.com/w3c/csswg-drafts/assets/7477678/c830960d-5c63-4850-b83d-cdcb82071fff) | ![](https://github.com/w3c/csswg-drafts/assets/7477678/55ddd13a-5635-493c-bc85-3d6a3b3b2405) | I think the spec doesn't cover this, here is my opinion: - Gecko is broken. Distributing twice the table height among the rows makes no sense at all. - Blink sizes correctly but places at the wrong position - WebKit and Servo are good Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10132 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [mediaqueries] Lift <media-feature> parens to <media-in-parens> (#6806) == This PR applies https://github.com/w3c/csswg-drafts/commit/1af56e0fe072307489875cd6456d3c409953bcb0 to MediaQueries 5. This commit was made 3 years ago, after [initiating](https://github.com/w3c/csswg-drafts/commit/2e34611e661fe3a7cb6ce70491ecf44676c6685e) from MediaQueries 4. Also, the railroad diagram of the updated syntax was not updated accordingly. This PR updates it in both levels of the spec. --- Without this change, a container size query will match `<general-enclosed>` and evaluate to `unknown`, unless it is specified in two `()`-blocks, because `<query-in-parens>` ([CSS Contain](https://drafts.csswg.org/css-contain-3/#typedef-query-in-parens)) produces `( <size-feature> )`, and `<size-feature>` is defined as *"the same as for a media feature: a feature name, a comparator, and a value"*. (*Note that you do not always have a comparator, eg. `orientation: portrait`*.) Besides, I assume that [`media-progress(<media-feature>, ...)`](https://drafts.csswg.org/css-values-5/#typedef-media-progress) and [`container-progress(<size-feature>, ...)`](https://drafts.csswg.org/css-values-5/#typedef-container-progress) are supposed to accept/take a query without using a `()`-block. See https://github.com/w3c/csswg-drafts/pull/10131 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr closed this issue. See https://github.com/w3c/csswg-drafts/issues/10070 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr closed this issue. See https://github.com/w3c/csswg-drafts/issues/10070 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I'd love to see this being picked up again. A `<iframe srcdoc=... fit-contents>` element would be a great way to isolate web components. All the code run in `srcdoc` would point to the right `document`, so I don't have to ask every library/tool I use to "use `element.shadowRoot` instead of `globalThis.document`" -- GitHub Notification of comment by fregante Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1771#issuecomment-2017978351 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I'd love to see this being picked up again. A `<iframe srcdoc=... fit-contents>` element would be a great way to isolate web components. All the code run in `srcdoc` would point to the right `document`, so I don't have to ask every library/tool I use to "use `element.shadowRoot` instead of `globalThis.document`" -- GitHub Notification of comment by fregante Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1771#issuecomment-2017978351 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == Update remaining instances of "type" to "types == Closes #10070 [css-spec-shortname-1] Brief description which should also include the #issuenum-or-URL and/or link to relevant CSSWG minutes. Copy the above line into the Title and replace with the relevant details. Fill in any additional details here. See https://github.com/w3c/csswg-drafts/blob/master/CONTRIBUTING.md for more info. See https://github.com/w3c/csswg-drafts/pull/10129 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == Update remaining instances of "type" to "types == Closes #10070 [css-spec-shortname-1] Brief description which should also include the #issuenum-or-URL and/or link to relevant CSSWG minutes. Copy the above line into the Title and replace with the relevant details. Fill in any additional details here. See https://github.com/w3c/csswg-drafts/blob/master/CONTRIBUTING.md for more info. See https://github.com/w3c/csswg-drafts/pull/10129 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == Update remaining instances of "type" to "types == Closes #10070 [css-spec-shortname-1] Brief description which should also include the #issuenum-or-URL and/or link to relevant CSSWG minutes. Copy the above line into the Title and replace with the relevant details. Fill in any additional details here. See https://github.com/w3c/csswg-drafts/blob/master/CONTRIBUTING.md for more info. See https://github.com/w3c/csswg-drafts/pull/10129 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == Update remaining instances of "type" to "types == Closes #10070 [css-spec-shortname-1] Brief description which should also include the #issuenum-or-URL and/or link to relevant CSSWG minutes. Copy the above line into the Title and replace with the relevant details. Fill in any additional details here. See https://github.com/w3c/csswg-drafts/blob/master/CONTRIBUTING.md for more info. See https://github.com/w3c/csswg-drafts/pull/10129 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == Update remaining instances of "type" to "types == Closes #10070 [css-spec-shortname-1] Brief description which should also include the #issuenum-or-URL and/or link to relevant CSSWG minutes. Copy the above line into the Title and replace with the relevant details. Fill in any additional details here. See https://github.com/w3c/csswg-drafts/blob/master/CONTRIBUTING.md for more info. See https://github.com/w3c/csswg-drafts/pull/10129 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == Update remaining instances of "type" to "types == Closes #10070 [css-spec-shortname-1] Brief description which should also include the #issuenum-or-URL and/or link to relevant CSSWG minutes. Copy the above line into the Title and replace with the relevant details. Fill in any additional details here. See https://github.com/w3c/csswg-drafts/blob/master/CONTRIBUTING.md for more info. See https://github.com/w3c/csswg-drafts/pull/10129 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == Update remaining instances of "type" to "types == Closes #10070 [css-spec-shortname-1] Brief description which should also include the #issuenum-or-URL and/or link to relevant CSSWG minutes. Copy the above line into the Title and replace with the relevant details. Fill in any additional details here. See https://github.com/w3c/csswg-drafts/blob/master/CONTRIBUTING.md for more info. See https://github.com/w3c/csswg-drafts/pull/10129 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == Update remaining instances of "type" to "types == Closes #10070 [css-spec-shortname-1] Brief description which should also include the #issuenum-or-URL and/or link to relevant CSSWG minutes. Copy the above line into the Title and replace with the relevant details. Fill in any additional details here. See https://github.com/w3c/csswg-drafts/blob/master/CONTRIBUTING.md for more info. See https://github.com/w3c/csswg-drafts/pull/10129 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == Update remaining instances of "type" to "types == Closes #10070 [css-spec-shortname-1] Brief description which should also include the #issuenum-or-URL and/or link to relevant CSSWG minutes. Copy the above line into the Title and replace with the relevant details. Fill in any additional details here. See https://github.com/w3c/csswg-drafts/blob/master/CONTRIBUTING.md for more info. See https://github.com/w3c/csswg-drafts/pull/10129 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
ydaniv has just labeled a pull request from ydaniv for https://github.com/w3c/csswg-drafts as "css-animations-2": == [css-animations-2] Specify the animation-trigger property == Adding initial draft for Animation triggers and the `animation-trigger` property as resolved in https://github.com/w3c/csswg-drafts/issues/8942#issuecomment-1854342340. See https://github.com/w3c/csswg-drafts/pull/10128 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
ydaniv has just labeled a pull request from ydaniv for https://github.com/w3c/csswg-drafts as "css-animations-2": == [css-animations-2] Specify the animation-trigger property == Adding initial draft for Animation triggers and the `animation-trigger` property as resolved in https://github.com/w3c/csswg-drafts/issues/8942#issuecomment-1854342340. See https://github.com/w3c/csswg-drafts/pull/10128 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
ydaniv has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-animations-2] Specify the animation-trigger property == Adding initial draft for Animation triggers and the `animation-trigger` property as resolved in https://github.com/w3c/csswg-drafts/issues/8942#issuecomment-1854342340. See https://github.com/w3c/csswg-drafts/pull/10128 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
https://github.com/w3c/csswg-drafts/issues/9325 allows clamping the number of repetitions, but it wouldn't help here since 1fr would still resolve using the entire element. I don't like your proposal because it's grid-specific, but a similar thing could be wanted in e.g. flex or block. Also, the "will be ignored if there's a conflict with the values of grid-template-columns/rows" isn't much well defined, e.g. `grid-template-columns: 1fr` would typically grow to fill the provided `grid-template-width` and avoid conflicts, but there could be an item that forces the track to become bigger. I think the right solution is https://github.com/w3c/csswg-drafts/issues/2406: ```html <style> .grid { background-color: #00BD79; } .grid::contents { max-width: 1400px; margin: auto; display: grid; grid-template-columns: repeat(auto-fit, minmax(400px, 1fr)); gap: 20px; } </style> <div class="grid"> <!-- grid elements here --> </div> ``` -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9182#issuecomment-2017075717 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
https://github.com/w3c/csswg-drafts/issues/9325 allows clamping the number of repetitions, but it wouldn't help here since 1fr would still resolve using the entire element. I don't like your proposal because it's grid-specific, but a similar thing could be wanted in e.g. flex or block. Also, the "will be ignored if there's a conflict with the values of grid-template-columns/rows" isn't much well defined, e.g. `grid-template-columns: 1fr` would typically grow to fill the provided `grid-template-width` and avoid conflicts, but there could be an item that forces the track to become bigger. I think the right solution is https://github.com/w3c/csswg-drafts/issues/2406: ```html <style> .grid { background-color: #00BD79; } .grid::contents { max-width: 1400px; margin: auto; display: grid; grid-template-columns: repeat(auto-fit, minmax(400px, 1fr)); gap: 20px; } </style> <div class="grid"> <!-- grid elements here --> </div> ``` -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9182#issuecomment-2017075717 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
https://github.com/w3c/csswg-drafts/issues/9325 allows clamping the number of repetitions, but it wouldn't help here since 1fr would still resolve using the entire element. I don't like your proposal because it's grid-specific, but a similar thing could be wanted in e.g. flex or block. Also, the "will be ignored if there's a conflict with the values of grid-template-columns/rows" isn't much well defined, e.g. `grid-template-columns: 1fr` would typically grow to fill the provided `grid-template-width` and avoid conflicts, but there could be an item that forces the track to become bigger. I think the right solution is https://github.com/w3c/csswg-drafts/issues/2406: ```html <style> .grid { background-color: #00BD79; } .grid::contents { max-width: 1400px; margin: auto; display: grid; grid-template-columns: repeat(auto-fit, minmax(400px, 1fr)); gap: 20px; } </style> <div class="grid"> <!-- grid elements here --> </div> ``` -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9182#issuecomment-2017075717 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
https://github.com/w3c/csswg-drafts/issues/9325 allows clamping the number of repetitions, but it wouldn't help here since 1fr would still resolve using the entire element. I don't like your proposal because it's grid-specific, but a similar thing could be wanted in e.g. flex or block. Also, the "will be ignored if there's a conflict with the values of grid-template-columns/rows" isn't much well defined, e.g. `grid-template-columns: 1fr` would typically grow to fill the provided `grid-template-width` and avoid conflicts, but there could be an item that forces the track to become bigger. I think the right solution is https://github.com/w3c/csswg-drafts/issues/2406: ```html <style> .grid { background-color: #00BD79; } .grid::contents { max-width: 1400px; margin: auto; display: grid; grid-template-columns: repeat(auto-fit, minmax(400px, 1fr)); gap: 20px; } </style> <div class="grid"> <!-- grid elements here --> </div> ``` -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9182#issuecomment-2017075717 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> Secondly, it would be nice to add `{row,column}-reverse` to `grid-auto-flow`, to match `flex-direction` - where it will fill items in from the end rather than the start Resolved in https://github.com/w3c/csswg-drafts/issues/3622#issuecomment-1789824193 -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7399#issuecomment-2016995173 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
jfkthame has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-fonts] @font-face source: reference to OpenType Collection without a fragment identifier == It's unclear to me from the current text at https://www.w3.org/TR/css-fonts-4/#font-face-src-loading exactly what a UA should do if the source referenced by a `@font-face` rule is a collection, but no fragment identifier is provided to specify which face from the resource is to be used. We're told: > [F]ont container formats that can contain more than one font must load one and only one of the fonts for a given `@font-face` rule. Fragment identifiers are used to indicate which font to load; these use the PostScript name of the font as defined in [[RFC8081]](https://www.w3.org/TR/css-fonts-4/#biblio-rfc8081). We're also told: > Conformant user agents must skip downloading a font resource if the fragment identifier is unknown or unsupported. I think it would be reasonable for this also to apply to the case of a missing fragment identifier, but I don't think the spec makes this clear. Perhaps this sentence should be expanded to say "...if the fragment identifier is absent, unknown, or unsupported"? An alternative might be to say that in the absence of a fragment identifier, the UA loads the first defined font in the collection. This would be similar to the behavior for SVG fonts, mentioned just above: > If the element reference is omitted, a reference to the first defined font is implied. but on the other hand, the WG has in the past specifically opposed selecting fonts by their index in OpenType collections, insisting that names must be used. So it seems hard to justify making an exception whereby a missing fragment identifier equates to selecting the face at index zero. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10127 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
jfkthame has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-fonts] @font-face source: reference to OpenType Collection without a fragment identifier == It's unclear to me from the current text at https://www.w3.org/TR/css-fonts-4/#font-face-src-loading exactly what a UA should do if the source referenced by a `@font-face` rule is a collection, but no fragment identifier is provided to specify which face from the resource is to be used. We're told: > [F]ont container formats that can contain more than one font must load one and only one of the fonts for a given `@font-face` rule. Fragment identifiers are used to indicate which font to load; these use the PostScript name of the font as defined in [[RFC8081]](https://www.w3.org/TR/css-fonts-4/#biblio-rfc8081). We're also told: > Conformant user agents must skip downloading a font resource if the fragment identifier is unknown or unsupported. I think it would be reasonable for this also to apply to the case of a missing fragment identifier, but I don't think the spec makes this clear. Perhaps this sentence should be expanded to say "...if the fragment identifier is absent, unknown, or unsupported"? An alternative might be to say that in the absence of a fragment identifier, the UA loads the first defined font in the collection. This would be similar to the behavior for SVG fonts, mentioned just above: > If the element reference is omitted, a reference to the first defined font is implied. but on the other hand, the WG has in the past specifically opposed selecting fonts by their index in OpenType collections, insisting that names must be used. So it seems hard to justify making an exception whereby a missing fragment identifier equates to selecting the face at index zero. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10127 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
jfkthame has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-fonts] @font-face source: reference to OpenType Collection without a fragment identifier == It's unclear to me from the current text at https://www.w3.org/TR/css-fonts-4/#font-face-src-loading exactly what a UA should do if the source referenced by a `@font-face` rule is a collection, but no fragment identifier is provided to specify which face from the resource is to be used. We're told: > [F]ont container formats that can contain more than one font must load one and only one of the fonts for a given `@font-face` rule. Fragment identifiers are used to indicate which font to load; these use the PostScript name of the font as defined in [[RFC8081]](https://www.w3.org/TR/css-fonts-4/#biblio-rfc8081). We're also told: > Conformant user agents must skip downloading a font resource if the fragment identifier is unknown or unsupported. I think it would be reasonable for this also to apply to the case of a missing fragment identifier, but I don't think the spec makes this clear. Perhaps this sentence should be expanded to say "...if the fragment identifier is absent, unknown, or unsupported"? An alternative might be to say that in the absence of a fragment identifier, the UA loads the first defined font in the collection. This would be similar to the behavior for SVG fonts, mentioned just above: > If the element reference is omitted, a reference to the first defined font is implied. but on the other hand, the WG has in the past specifically opposed selecting fonts by their index in OpenType collections, insisting that names must be used. So it seems hard to justify making an exception whereby a missing fragment identifier equates to selecting the face at index zero. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10127 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
jfkthame has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-fonts] @font-face source: reference to OpenType Collection without a fragment identifier == It's unclear to me from the current text at https://www.w3.org/TR/css-fonts-4/#font-face-src-loading exactly what a UA should do if the source referenced by a `@font-face` rule is a collection, but no fragment identifier is provided to specify which face from the resource is to be used. We're told: > [F]ont container formats that can contain more than one font must load one and only one of the fonts for a given `@font-face` rule. Fragment identifiers are used to indicate which font to load; these use the PostScript name of the font as defined in [[RFC8081]](https://www.w3.org/TR/css-fonts-4/#biblio-rfc8081). We're also told: > Conformant user agents must skip downloading a font resource if the fragment identifier is unknown or unsupported. I think it would be reasonable for this also to apply to the case of a missing fragment identifier, but I don't think the spec makes this clear. Perhaps this sentence should be expanded to say "...if the fragment identifier is absent, unknown, or unsupported"? An alternative might be to say that in the absence of a fragment identifier, the UA loads the first defined font in the collection. This would be similar to the behavior for SVG fonts, mentioned just above: > If the element reference is omitted, a reference to the first defined font is implied. but on the other hand, the WG has in the past specifically opposed selecting fonts by their index in OpenType collections, insisting that names must be used. So it seems hard to justify making an exception whereby a missing fragment identifier equates to selecting the face at index zero. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10127 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
jfkthame has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-fonts] @font-face source: reference to OpenType Collection without a fragment identifier == It's unclear to me from the current text at https://www.w3.org/TR/css-fonts-4/#font-face-src-loading exactly what a UA should do if the source referenced by a `@font-face` rule is a collection, but no fragment identifier is provided to specify which face from the resource is to be used. We're told: > [F]ont container formats that can contain more than one font must load one and only one of the fonts for a given `@font-face` rule. Fragment identifiers are used to indicate which font to load; these use the PostScript name of the font as defined in [[RFC8081]](https://www.w3.org/TR/css-fonts-4/#biblio-rfc8081). We're also told: > Conformant user agents must skip downloading a font resource if the fragment identifier is unknown or unsupported. I think it would be reasonable for this also to apply to the case of a missing fragment identifier, but I don't think the spec makes this clear. Perhaps this sentence should be expanded to say "...if the fragment identifier is absent, unknown, or unsupported"? An alternative might be to say that in the absence of a fragment identifier, the UA loads the first defined font in the collection. This would be similar to the behavior for SVG fonts, mentioned just above: > If the element reference is omitted, a reference to the first defined font is implied. but on the other hand, the WG has in the past specifically opposed selecting fonts by their index in OpenType collections, insisting that names must be used. So it seems hard to justify making an exception whereby a missing fragment identifier equates to selecting the face at index zero. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10127 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Does this feature open up the path to _real_ "CSS modules"? Right now, all CSS imports are side-effectful, but `@sheet` could make it possible to split the "import" vs "apply" parts into two steps. 1. Import: ```css @import "foo.css" sheets(A, B); ``` 2. Apply (in any order desired): ```css @sheet B; @sheet A; ``` Also it would be useful to be able to rename sheets when importing. I think this functionality is essential for any module-like system. ```css @import "foo.css" sheets(A as X, B as Y); @sheet X; @sheet Y; ``` --- Lastly — and this might be far-fetched — maybe there should be some reserved sheet names that have special meaning. For example, `@sheet inherit;` could be used to reference host context stylesheets from within a shadow-root. ```html <head> <style> @sheet A {…} @sheet B {…} </style> </head> <div> <template shadowrootmode="open"> <style type="module"> @sheet inherit.A; @sheet inherit.B; /* or just @sheet inherit; */ </style> </template> </div> ``` --- Regardless of the specific ideas and syntaxes I illustrated, I think we should all be thinking about how to make CSS (and HTML) better and more useful on its own, even when JS is not involved. -- GitHub Notification of comment by mayank99 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5629#issuecomment-2016582527 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Does this feature open up the path to _real_ "CSS modules"? Right now, all CSS imports are side-effectful, but `@sheet` could make it possible to split the "import" vs "apply" parts into two steps. 1. Import: ```css @import "foo.css" sheets(A, B); ``` 2. Apply (in any order desired): ```css @sheet B; @sheet A; ``` Also it would be useful to be able to rename sheets when importing. I think this functionality is essential for any module-like system. ```css @import "foo.css" sheets(A as X, B as Y); @sheet X; @sheet Y; ``` --- Lastly — and this might be far-fetched — maybe there should be some reserved sheet names that have special meaning. For example, `@sheet inherit;` could be used to reference host context stylesheets from within a shadow-root. ```html <head> <style> @sheet A {…} @sheet B {…} </style> </head> <div> <template shadowrootmode="open"> <style type="module"> @sheet inherit.A; @sheet inherit.B; /* or just @sheet inherit; */ </style> </template> </div> ``` --- Regardless of the specific ideas and syntaxes I illustrated, I think we should all be thinking about how to make CSS (and HTML) better and more useful on its own, even when JS is not involved. -- GitHub Notification of comment by mayank99 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5629#issuecomment-2016582527 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Does this feature open up the path to _real_ "CSS modules"? Right now, all CSS imports are side-effectful, but `@sheet` could make it possible to split the "import" vs "apply" parts into two steps. 1. Import: ```css @import "foo.css" sheets(A, B); ``` 2. Apply (in any order desired): ```css @sheet B; @sheet A; ``` Also it would be useful to be able to rename sheets when importing. I think this functionality is essential for any module-like system. ```css @import "foo.css" sheets(A as X, B as Y); @sheet X; @sheet Y; ``` --- Lastly — and this might be far-fetched — maybe there should be some reserved sheet names that have special meaning. For example, `@sheet inherit;` could be used to reference host context stylesheets from within a shadow-root. ```html <head> <style> @sheet A {…} @sheet B {…} </style> </head> <div> <template shadowrootmode="open"> <style type="module"> @sheet inherit.A; @sheet inherit.B; /* or just @sheet inherit; */ </style> </template> </div> ``` --- Regardless of the specific ideas and syntaxes I illustrated, I think we should all be thinking about how to make CSS (and HTML) better and more useful on its own, even when JS is not involved. -- GitHub Notification of comment by mayank99 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5629#issuecomment-2016582527 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Does this feature open up the path to _real_ "CSS modules"? Right now, all CSS imports are side-effectful, but `@sheet` could make it possible to split the "import" vs "apply" parts into two steps. 1. Import: ```css @import "foo.css" sheets(A, B); ``` 2. Apply (in any order desired): ```css @sheet B; @sheet A; ``` Also it would be useful to be able to rename sheets when importing. I think this functionality is essential for any module-like system. ```css @import "foo.css" sheets(A as X, B as Y); @sheet X; @sheet Y; ``` --- Lastly — and this might be far-fetched — maybe there should be some reserved sheet names that have special meaning. For example, `@sheet inherit;` could be used to reference host context stylesheets from within a shadow-root. ```html <head> <style> @sheet A {…} @sheet B {…} </style> </head> <div> <template shadowrootmode="open"> <style type="module"> @sheet inherit.A; @sheet inherit.B; /* or just @sheet inherit; */ </style> </template> </div> ``` --- Regardless of the specific ideas and syntaxes I illustrated, I think we should all be thinking about how to make CSS (and HTML) better and more useful on its own, even when JS is not involved. -- GitHub Notification of comment by mayank99 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5629#issuecomment-2016582527 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Does this feature open up the path to _real_ "CSS modules"? Right now, all CSS imports are side-effectful, but `@sheet` could make it possible to split the "import" vs "apply" parts into two steps. 1. Import: ```css @import "foo.css" sheets(A, B); ``` 2. Apply (in any order desired): ```css @sheet B; @sheet A; ``` Also it would be useful to be able to rename sheets when importing. I think this functionality is essential for any module-like system. ```css @import "foo.css" sheets(A as X, B as Y); @sheet X; @sheet Y; ``` --- Lastly — and this might be far-fetched — maybe there should be some reserved sheet names that have special meaning. For example, `@sheet inherit;` could be used to reference host context stylesheets from within a shadow-root. ```html <head> <style> @sheet A {…} @sheet B {…} </style> </head> <div> <template shadowrootmode="open"> <style type="module"> @sheet inherit.A; @sheet inherit.B; /* or just @sheet inherit; */ </style> </template> </div> ``` --- Regardless of the specific ideas and syntaxes I illustrated, I think we should all be thinking about how to make CSS (and HTML) better and more useful on its own, even when JS is not involved. -- GitHub Notification of comment by mayank99 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5629#issuecomment-2016582527 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I really like the idea of integrating this with link-params, but I'm not totally sure I've followed the mechanism that's proposed here. link-params allow a _source_ document to set a variable in the _target_ document, with the value is passed through to the target document as if the variable were set in a user-agent stylesheet (or any equivalent process resulting in the rules having lower priority than any rules set in the target) ``` Properties in the source document ------------------ link-parameters: param(--foo x); Effective new user-agent stylesheet in the target document ------------------ :root { --foo: x } ``` And if `x` is missing in the `param()`, it defaults to the value the same variable in the source document; so `var(--foo)` If I understand this proposal, the idea is to extend this so if the parameter name is not a custom-ident, it's parsed as a CSS property name and the default value is the source element's computed value of that property. ``` Properties in the source document ------------------ font-family: serif link-parameters: param(font-family); Effective new user-agent stylesheet in the target document ------------------ :root { font-family: serif } ``` Is that correct? I like it if so, easy to use and no harder to implement than regular link-params. Two questions: * wouldn't it be `param(color)` not `param(currentcolor)` in this case? * I presume when passing through a `font-family` that refers to downloaded fonts, the idea is that the target document also inherits any `@font-face` rules that define the family? -- GitHub Notification of comment by faceless2 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9872#issuecomment-2016522754 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I really like the idea of integrating this with link-params, but I'm not totally sure I've followed the mechanism that's proposed here. link-params allow a _source_ document to set a variable in the _target_ document, with the value is passed through to the target document as if the variable were set in a user-agent stylesheet (or any equivalent process resulting in the rules having lower priority than any rules set in the target) ``` Properties in the source document ------------------ link-parameters: param(--foo x); Effective new user-agent stylesheet in the target document ------------------ :root { --foo: x } ``` And if `x` is missing in the `param()`, it defaults to the value the same variable in the source document; so `var(--foo)` If I understand this proposal, the idea is to extend this so if the parameter name is not a custom-ident, it's parsed as a CSS property name and the default value is the source element's computed value of that property. ``` Properties in the source document ------------------ font-family: serif link-parameters: param(font-family); Effective new user-agent stylesheet in the target document ------------------ :root { font-family: serif } ``` Is that correct? I like it if so, easy to use and no harder to implement than regular link-params. Two questions: * wouldn't it be `param(color)` not `param(currentcolor)` in this case? * I presume when passing through a `font-family` that refers to downloaded fonts, the idea is that the target document also inherits any `@font-face` rules that define the family? -- GitHub Notification of comment by faceless2 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9872#issuecomment-2016522754 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I really like the idea of integrating this with link-params, but I'm not totally sure I've followed the mechanism that's proposed here. link-params allow a _source_ document to set a variable in the _target_ document, with the value is passed through to the target document as if the variable were set in a user-agent stylesheet (or any equivalent process resulting in the rules having lower priority than any rules set in the target) ``` Properties in the source document ------------------ link-parameters: param(--foo x); Effective new user-agent stylesheet in the target document ------------------ :root { --foo: x } ``` And if `x` is missing in the `param()`, it defaults to the value the same variable in the source document; so `var(--foo)` If I understand this proposal, the idea is to extend this so if the parameter name is not a custom-ident, it's parsed as a CSS property name and the default value is the source element's computed value of that property. ``` Properties in the source document ------------------ font-family: serif link-parameters: param(font-family); Effective new user-agent stylesheet in the target document ------------------ :root { font-family: serif } ``` Is that correct? I like it if so, easy to use and no harder to implement than regular link-params. Two questions: * wouldn't it be `param(color)` not `param(currentcolor)` in this case? * I presume when passing through a `font-family` that refers to downloaded fonts, the idea is that the target document also inherits any `@font-face` rules that define the family? -- GitHub Notification of comment by faceless2 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9872#issuecomment-2016522754 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I really like the idea of integrating this with link-params, but I'm not totally sure I've followed the mechanism that's proposed here. link-params allow a _source_ document to set a variable in the _target_ document, with the value is passed through to the target document as if the variable were set in a user-agent stylesheet (or any equivalent process resulting in the rules having lower priority than any rules set in the target) ``` Properties in the source document ------------------ link-parameters: param(--foo x); Effective new user-agent stylesheet in the target document ------------------ :root { --foo: x } ``` And if `x` is missing in the `param()`, it defaults to the value the same variable in the source document; so `var(--foo)` If I understand this proposal, the idea is to extend this so if the parameter name is not a custom-ident, it's parsed as a CSS property name and the default value is the source element's computed value of that property. ``` Properties in the source document ------------------ font-family: serif link-parameters: param(font-family); Effective new user-agent stylesheet in the target document ------------------ :root { font-family: serif } ``` Is that correct? I like it if so, easy to use and no harder to implement than regular link-params. Two questions: * wouldn't it be `param(color)` not `param(currentcolor)` in this case? * I presume when passing through a `font-family` that refers to downloaded fonts, the idea is that the target document also inherits any `@font-face` rules that define the family? -- GitHub Notification of comment by faceless2 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9872#issuecomment-2016522754 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I really like the idea of integrating this with link-params, but I'm not totally sure I've followed the mechanism that's proposed here. link-params allow a _source_ document to set a variable in the _target_ document, with the value is passed through to the target document as if the variable were set in a user-agent stylesheet (or any equivalent process resulting in the rules having lower priority than any rules set in the target) ``` Properties in the source document ------------------ link-parameters: param(--foo x); Effective new user-agent stylesheet in the target document ------------------ :root { --foo: x } ``` And if `x` is missing in the `param()`, it defaults to the value the same variable in the source document; so `var(--foo)` If I understand this proposal, the idea is to extend this so if the parameter name is not a custom-ident, it's parsed as a CSS property name and the default value is the source element's computed value of that property. ``` Properties in the source document ------------------ font-family: serif link-parameters: param(font-family); Effective new user-agent stylesheet in the target document ------------------ :root { font-family: serif } ``` Is that correct? I like it if so, easy to use and no harder to implement than regular link-params. Two questions: * wouldn't it be `param(color)` not `param(currentcolor)` in this case? * I presume when passing through a `font-family` that refers to downloaded fonts, the idea is that the target document also inherits any `@font-face` rules that define the family? -- GitHub Notification of comment by faceless2 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9872#issuecomment-2016522754 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I really like the idea of integrating this with link-params, but I'm not totally sure I've followed the mechanism that's proposed here. link-params allow a _source_ document to set a variable in the _target_ document, with the value is passed through to the target document as if the variable were set in a user-agent stylesheet (or any equivalent process resulting in the rules having lower priority than any rules set in the target) ``` Properties in the source document ------------------ link-parameters: param(--foo x); Effective new user-agent stylesheet in the target document ------------------ :root { --foo: x } ``` And if `x` is missing in the `param()`, it defaults to the value the same variable in the source document; so `var(--foo)` If I understand this proposal, the idea is to extend this so if the parameter name is not a custom-ident, it's parsed as a CSS property name and the default value is the source element's computed value of that property. ``` Properties in the source document ------------------ font-family: serif link-parameters: param(font-family); Effective new user-agent stylesheet in the target document ------------------ :root { font-family: serif } ``` Is that correct? I like it if so, easy to use and no harder to implement than regular link-params. Two questions: * wouldn't it be `param(color)` not `param(currentcolor)` in this case? * I presume when passing through a `font-family` that refers to downloaded fonts, the idea is that the target document also inherits any `@font-face` rules that define the family? -- GitHub Notification of comment by faceless2 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9872#issuecomment-2016522754 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
emilio has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-viewport] CSS zoom should affect clip-path: path() strings. == Right now per spec it doesn't, but that doesn't match implementations, and it makes sense for it to affect it. We have tests for this (css/css-masking/clip-path/clip-path-path-with-zoom.html etc), so I think just a tweak to the spec should be enough, wdyt @chrishtr? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10126 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
emilio has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-viewport] CSS zoom should affect clip-path: path() strings. == Right now per spec it doesn't, but that doesn't match implementations, and it makes sense for it to affect it. We have tests for this (css/css-masking/clip-path/clip-path-path-with-zoom.html etc), so I think just a tweak to the spec should be enough, wdyt @chrishtr? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10126 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-syntax-3] `url(` followed by comment(s) == In Chrome and FF (at least), `url(/**/"bg.jpg")` is invalid, and `url(/**/bg.jpg)` serializes as `url("/**/bg.jpg")`. I could not find something equivalent to the following note from [CSS2](https://drafts.csswg.org/css2/#uri) in CSS Syntax 3: > COMMENT tokens do not occur in the grammar (to keep it readable), but any number of these tokens may appear anywhere outside other tokens. Based on this note, I would expect `url(/**/"bg.jpg")` to be valid. However, according to this note (which may be usefull to reproduce in CSS Syntax 3, imo), also from CSS2, `/**/bg.jpg` must be seen as an invalid URL `<ident>`: > Note that COMMENT tokens cannot occur within other tokens: thus, "url(/*x*/pic.png)" denotes the URI "/*x*/pic.png", not "pic.png". So I guess the first note does not apply anymore, ie. comment tokens can *usually* appear anywhere except in some places that you do not want to explicitly list. And I cannot find any corresponding case on WPT. If everything I said above is true and you think there is no need to clarify anything in CSS Syntax, this issue can be closed. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10125 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> pseudo elements are not in the DOM That argument has been brought up a number of times, but one can access pseudo elements via `getComputedStyle`'s second argument, so they are definitely not completely hidden from the DOM APIs. -- GitHub Notification of comment by silverwind Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2894#issuecomment-2016294347 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> pseudo elements are not in the DOM That argument has been brought up a number of times, but one can access pseudo elements via `getComputedStyle`'s second argument, so they are definitely not completely hidden from the DOM APIs. -- GitHub Notification of comment by silverwind Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2894#issuecomment-2016294347 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> pseudo elements are not in the DOM That argument has been brought up a number of times, but one can access pseudo elements via `getComputedStyle`'s second argument, so they are definitely not completely hidden from the DOM APIs. -- GitHub Notification of comment by silverwind Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2894#issuecomment-2016294347 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
autokagami has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Align with Web IDL specification == 🤖 This is an automated pull request to align the spec with the latest Web IDL specification. 🤖 The followings are the Web IDL validation messages, which may help understanding this PR: * ``` Validation error at line 2 in css-view-transitions-2,2, inside `interface ViewTransitionTypeSet`: interface ViewTransitionTypeSet { ^ ``` > Error: Interfaces must have `[Exposed]` extended attribute. To fix, add, for example, `[Exposed=Window]`. Please also consider carefully if your interface should also be exposed in a Worker scope. Refer to the [WebIDL spec section on Exposed](https://heycam.github.io/webidl/#Exposed) for more information. Currently this autofix might introduce awkward code formatting, and feel free to manually fix it whenever it happens. Please file an issue at https://github.com/saschanaz/webidl-updater/issues/new if you think this is invalid or should be enhanced. See https://github.com/w3c/csswg-drafts/pull/10123 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] Apply resolutions for hidden document state == Closes https://github.com/w3c/csswg-drafts/issues/10101. See https://github.com/w3c/csswg-drafts/pull/10122 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] Apply resolutions for hidden document state == Closes https://github.com/w3c/csswg-drafts/issues/10101. See https://github.com/w3c/csswg-drafts/pull/10122 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> The difficulty here is that some of our view transition styles are conditional on the structure of the tree. For example, isolation is only set on the pair if it has two children. The behaviour per spec is such that the static UA CSS rules [here](https://drafts.csswg.org/css-view-transitions-1/#ua-styles) are always in the user agent origin. And the [dynamic style sheet](https://drafts.csswg.org/css-view-transitions-1/#document-dynamic-view-transition-style-sheet) which has the tree structure dependent CSS won't be there if there is no transition. So we could compute the pseudo-element style based on that? -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9880#issuecomment-2016166811 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
[HarijsR](https://github.com/HarijsR) this is an implementation bug in blink. Can you file an issue on https://crbug.com/new with a test case and use the "ViewTransition" component. -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9802#issuecomment-2016151736 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
[HarijsR](https://github.com/HarijsR) this is an implementation bug in blink. Can you file an issue on https://crbug.com/new with a test case and use the "ViewTransition" component. -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9802#issuecomment-2016151736 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
[HarijsR](https://github.com/HarijsR) this is an implementation bug in blink. Can you file an issue on https://crbug.com/new with a test case and use the "ViewTransition" component. -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9802#issuecomment-2016151736 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar closed this issue. See https://github.com/w3c/csswg-drafts/issues/9802 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar closed this issue. See https://github.com/w3c/csswg-drafts/issues/9543 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I went with “shaped edge” and “unshaped edge”. Agenda+ to confirm and republish. -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5132#issuecomment-2016033266 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-box-4] Audit boxes == This spec defines several different sets of boxes, but maybe not all of the necessary ones; e.g. `transform-box` doesn't include `padding-box`. We should check the uses of the various box types to make sure they're subsetting what they want to subset, and that we have the appropriate subsets available. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10121 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
amn has just created a new issue for https://github.com/w3c/csswg-drafts: == Ambiguity or omission in list of steps for "CSS Syntax Level 3", section "4.3.4. Consume an ident-like token"? [css-syntax] == Rading [section 4.34 of "CSS Syntax Level 3"](https://www.w3.org/TR/css-syntax-3/#consume-ident-like-token) I am confused by two sentences, which I am unable to properly understand in order to, say, proceed in implementing a compliant tokenizer. The [adjacent] sentences, quoting: > While the next two input code points are [whitespace](https://www.w3.org/TR/css-syntax-3/#whitespace), consume the next input code point. If the next one or two input code points are U+0022 QUOTATION MARK ("), U+0027 APOSTROPHE ('), or whitespace followed by U+0022 QUOTATION MARK (") or U+0027 APOSTROPHE ('), then create a [<function-token>](https://www.w3.org/TR/css-syntax-3/#typedef-function-token) with its value set to string and return it. It's the second sentence that is of primary concern, really. What condition does it exactly express? Between all the "or" in the sentence, I confess it reads in a manner I can't wrap my head around. First off, if the next two input code points (previous sentence) are (both) whitespace, after consuming the next input code point (which is the first of the whitespace, necessarily), the subsequent code point is assertively whitespace, no? And what condition is exactly being expressed with the second sentence anyway, could someone please clarify? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10120 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
amn has just created a new issue for https://github.com/w3c/csswg-drafts: == Ambiguity or omission in list of steps for "CSS Syntax Level 3", section "4.3.4. Consume an ident-like token"? [css-syntax] == Rading [section 4.34 of "CSS Syntax Level 3"](https://www.w3.org/TR/css-syntax-3/#consume-ident-like-token) I am confused by two sentences, which I am unable to properly understand in order to, say, proceed in implementing a compliant tokenizer. The [adjacent] sentences, quoting: > While the next two input code points are [whitespace](https://www.w3.org/TR/css-syntax-3/#whitespace), consume the next input code point. If the next one or two input code points are U+0022 QUOTATION MARK ("), U+0027 APOSTROPHE ('), or whitespace followed by U+0022 QUOTATION MARK (") or U+0027 APOSTROPHE ('), then create a [<function-token>](https://www.w3.org/TR/css-syntax-3/#typedef-function-token) with its value set to string and return it. It's the second sentence that is of primary concern, really. What condition does it exactly express? Between all the "or" in the sentence, I confess it reads in a manner I can't wrap my head around. First off, if the next two input code points (previous sentence) are (both) whitespace, after consuming the next input code point (which is the first of the whitespace, necessarily), the subsequent code point is assertively whitespace, no? And what condition is exactly being expressed with the second sentence anyway, could someone please clarify? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10120 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
amn has just created a new issue for https://github.com/w3c/csswg-drafts: == "Consume qualified rule" section in the spec. appears to mention consumption of simple block _twice_? [css-syntax] == Reading https://www.w3.org/TR/css-syntax-3/#consume-qualified-rule I am confused as to why there is seemingly more or less identical steps described under "Repeatedly consume next input token", the first step is written thus: > [<{-token>](https://www.w3.org/TR/css-syntax-3/#tokendef-open-curly) [Consume a simple block](https://www.w3.org/TR/css-syntax-3/#consume-a-simple-block) and assign it to the qualified rule’s block. Return the qualified rule. Fair, enough, but then immediately after another is written thus: > [simple block](https://www.w3.org/TR/css-syntax-3/#simple-block) with an associated token of [<{-token>](https://www.w3.org/TR/css-syntax-3/#tokendef-open-curly) Assign the block to the qualified rule’s block. Return the qualified rule. If we disregard the fact that it's not at all clear how the condition related to the sentence "Repeatedly consume next input token" that precedes the steps, the second item above appears to basically express the same procedure as the first. Is this an omission, and at any rate, can someone in the know clarify this issue? If the second parable (step) is removed entirely, then in fact, the list of steps looks entirely comprehensible. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10119 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
amn has just created a new issue for https://github.com/w3c/csswg-drafts: == "Consume qualified rule" section in the spec. appears to mention consumption of simple block _twice_? [css-syntax] == Reading https://www.w3.org/TR/css-syntax-3/#consume-qualified-rule I am confused as to why there is seemingly more or less identical steps described under "Repeatedly consume next input token", the first step is written thus: > [<{-token>](https://www.w3.org/TR/css-syntax-3/#tokendef-open-curly) [Consume a simple block](https://www.w3.org/TR/css-syntax-3/#consume-a-simple-block) and assign it to the qualified rule’s block. Return the qualified rule. Fair, enough, but then immediately after another is written thus: > [simple block](https://www.w3.org/TR/css-syntax-3/#simple-block) with an associated token of [<{-token>](https://www.w3.org/TR/css-syntax-3/#tokendef-open-curly) Assign the block to the qualified rule’s block. Return the qualified rule. If we disregard the fact that it's not at all clear how the condition related to the sentence "Repeatedly consume next input token" that precedes the steps, the second item above appears to basically express the same procedure as the first. Is this an omission, and at any rate, can someone in the know clarify this issue? If the second parable (step) is removed entirely, then in fact, the list of steps looks entirely comprehensible. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10119 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr closed this issue. See https://github.com/w3c/csswg-drafts/issues/10070 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr closed this issue. See https://github.com/w3c/csswg-drafts/issues/10070 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr closed this issue. See https://github.com/w3c/csswg-drafts/issues/10070 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr closed this issue. See https://github.com/w3c/csswg-drafts/issues/10070 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr closed this issue. See https://github.com/w3c/csswg-drafts/issues/10070 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr closed this issue. See https://github.com/w3c/csswg-drafts/issues/10070 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr closed this issue. See https://github.com/w3c/csswg-drafts/issues/10070 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr closed this issue. See https://github.com/w3c/csswg-drafts/issues/10070 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr closed this issue. See https://github.com/w3c/csswg-drafts/issues/10071 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr closed this issue. See https://github.com/w3c/csswg-drafts/issues/10011 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I think this is the correct definition : https://dbaron.org/css/intrinsic/#:~:text=intermediate%20min%2Dcontent%20width%20for%20span%20N%20(N%20%3E%201) -- GitHub Notification of comment by mmghv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9837#issuecomment-2015482838 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
emattias has just created a new issue for https://github.com/w3c/csswg-drafts: == enable touch accelerated scrolling even for mouse pointers == You can disable touch based scrolling (clicking and dragging and releasing and the scrolling continuing depending on the speed of the pointer move at release) with `touch-action:none` but (to my knowledge) you cant enable the touch scrolling if the browser doesnt detect the pointer as being touch. You can enable it in devtools, like in the video below. Would be nice to be able to enable it with css. https://github.com/w3c/csswg-drafts/assets/351537/ed3825ef-361f-4968-b457-4c00c9b0fcab ### Why? Css scroll snap has eliminated the need for part of what js libraries like [swiper](https://swiperjs.com/), [keen-slider](https://keen-slider.io/examples), etc. but to getting accelerated scrolling you still need js to achieve. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10118 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
emattias has just created a new issue for https://github.com/w3c/csswg-drafts: == enable touch accelerated scrolling even for mouse pointers == You can disable touch based scrolling (clicking and dragging and releasing and the scrolling continuing depending on the speed of the pointer move at release) with `touch-action:none` but (to my knowledge) you cant enable the touch scrolling if the browser doesnt detect the pointer as being touch. You can enable it in devtools, like in the video below. Would be nice to be able to enable it with css. https://github.com/w3c/csswg-drafts/assets/351537/ed3825ef-361f-4968-b457-4c00c9b0fcab ### Why? Css scroll snap has eliminated the need for part of what js libraries like [swiper](https://swiperjs.com/), [keen-slider](https://keen-slider.io/examples), etc. but to getting accelerated scrolling you still need js to achieve. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10118 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
emattias has just created a new issue for https://github.com/w3c/csswg-drafts: == enable touch accelerated scrolling even for mouse pointers == You can disable touch based scrolling (clicking and dragging and releasing and the scrolling continuing depending on the speed of the pointer move at release) with `touch-action:none` but (to my knowledge) you cant enable the touch scrolling if the browser doesnt detect the pointer as being touch. You can enable it in devtools, like in the video below. Would be nice to be able to enable it with css. https://github.com/w3c/csswg-drafts/assets/351537/ed3825ef-361f-4968-b457-4c00c9b0fcab ### Why? Css scroll snap has eliminated the need for part of what js libraries like [swiper](https://swiperjs.com/), [keen-slider](https://keen-slider.io/examples), etc. but to getting accelerated scrolling you still need js to achieve. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10118 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
emattias has just created a new issue for https://github.com/w3c/csswg-drafts: == enable touch accelerated scrolling even for mouse pointers == You can disable touch based scrolling (clicking and dragging and releasing and the scrolling continuing depending on the speed of the pointer move at release) with `touch-action:none` but (to my knowledge) you cant enable the touch scrolling if the browser doesnt detect the pointer as being touch. You can enable it in devtools, like in the video below. Would be nice to be able to enable it with css. https://github.com/w3c/csswg-drafts/assets/351537/ed3825ef-361f-4968-b457-4c00c9b0fcab ### Why? Css scroll snap has eliminated the need for part of what js libraries like [swiper](https://swiperjs.com/), [keen-slider](https://keen-slider.io/examples), etc. but to getting accelerated scrolling you still need js to achieve. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10118 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Sorry, I missed this before. Common use cases are designs that want to move content element to an edge or corner of the page. The attached image is from a sample document that moves the "before" content of level 1 headings to a corner of the page. Additionally being able to position against the bleed-box is helpful, so its no longer necessary to manually move boxes into the bleed. In general it allows for some creative designs, especially around forced page breaks. ![ro-position-origin](https://github.com/w3c/csswg-drafts/assets/43403851/e225ef24-faf9-4958-91db-a507e7101ca2) -- GitHub Notification of comment by bernhardf-ro Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8301#issuecomment-2014880321 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Sorry, I missed this before. Common use cases are designs that want to move content element to an edge or corner of the page. The attached image is from a sample document that moves the "before" content of level 1 headings to a corner of the page. Additionally being able to position against the bleed-box is helpful, so its no longer necessary to manually move boxes into the bleed. In general it allows for some creative designs, especially around forced page breaks. ![ro-position-origin](https://github.com/w3c/csswg-drafts/assets/43403851/e225ef24-faf9-4958-91db-a507e7101ca2) -- GitHub Notification of comment by bernhardf-ro Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8301#issuecomment-2014880321 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Sorry, I missed this before. Common use cases are designs that want to move content element to an edge or corner of the page. The attached image is from a sample document that moves the "before" content of level 1 headings to a corner of the page. Additionally being able to position against the bleed-box is helpful, so its no longer necessary to manually move boxes into the bleed. In general it allows for some creative designs, especially around forced page breaks. ![ro-position-origin](https://github.com/w3c/csswg-drafts/assets/43403851/e225ef24-faf9-4958-91db-a507e7101ca2) -- GitHub Notification of comment by bernhardf-ro Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8301#issuecomment-2014880321 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Sorry, I missed this before. Common use cases are designs that want to move content element to an edge or corner of the page. The attached image is from a sample document that moves the "before" content of level 1 headings to a corner of the page. Additionally being able to position against the bleed-box is helpful, so its no longer necessary to manually move boxes into the bleed. In general it allows for some creative designs, especially around forced page breaks. ![ro-position-origin](https://github.com/w3c/csswg-drafts/assets/43403851/e225ef24-faf9-4958-91db-a507e7101ca2) -- GitHub Notification of comment by bernhardf-ro Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8301#issuecomment-2014880321 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Sorry, I missed this before. Common use cases are designs that want to move content element to an edge or corner of the page. The attached image is from a sample document that moves the "before" content of level 1 headings to a corner of the page. Additionally being able to position against the bleed-box is helpful, so its no longer necessary to manually move boxes into the bleed. In general it allows for some creative designs, especially around forced page breaks. ![ro-position-origin](https://github.com/w3c/csswg-drafts/assets/43403851/e225ef24-faf9-4958-91db-a507e7101ca2) -- GitHub Notification of comment by bernhardf-ro Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8301#issuecomment-2014880321 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Sorry, I missed this before. Common use cases are designs that want to move content element to an edge or corner of the page. The attached image is from a sample document that moves the "before" content of level 1 headings to a corner of the page. Additionally being able to position against the bleed-box is helpful, so its no longer necessary to manually move boxes into the bleed. In general it allows for some creative designs, especially around forced page breaks. ![ro-position-origin](https://github.com/w3c/csswg-drafts/assets/43403851/e225ef24-faf9-4958-91db-a507e7101ca2) -- GitHub Notification of comment by bernhardf-ro Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8301#issuecomment-2014880321 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Sorry, I missed this before. Common use cases are designs that want to move content element to an edge or corner of the page. The attached image is from a sample document that moves the "before" content of level 1 headings to a corner of the page. Additionally being able to position against the bleed-box is helpful, so its no longer necessary to manually move boxes into the bleed. In general it allows for some creative designs, especially around forced page breaks. ![ro-position-origin](https://github.com/w3c/csswg-drafts/assets/43403851/e225ef24-faf9-4958-91db-a507e7101ca2) -- GitHub Notification of comment by bernhardf-ro Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8301#issuecomment-2014880321 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Sorry, I missed this before. Common use cases are designs that want to move content element to an edge or corner of the page. The attached image is from a sample document that moves the "before" content of level 1 headings to a corner of the page. Additionally being able to position against the bleed-box is helpful, so its no longer necessary to manually move boxes into the bleed. In general it allows for some creative designs, especially around forced page breaks. ![ro-position-origin](https://github.com/w3c/csswg-drafts/assets/43403851/e225ef24-faf9-4958-91db-a507e7101ca2) -- GitHub Notification of comment by bernhardf-ro Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8301#issuecomment-2014880321 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Sorry, I missed this before. Common use cases are designs that want to move content element to an edge or corner of the page. The attached image is from a sample document that moves the "before" content of level 1 headings to a corner of the page. Additionally being able to position against the bleed-box is helpful, so its no longer necessary to manually move boxes into the bleed. In general it allows for some creative designs, especially around forced page breaks. ![ro-position-origin](https://github.com/w3c/csswg-drafts/assets/43403851/e225ef24-faf9-4958-91db-a507e7101ca2) -- GitHub Notification of comment by bernhardf-ro Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8301#issuecomment-2014880321 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Sorry, I missed this before. Common use cases are designs that want to move content element to an edge or corner of the page. The attached image is from a sample document that moves the "before" content of level 1 headings to a corner of the page. Additionally being able to position against the bleed-box is helpful, so its no longer necessary to manually move boxes into the bleed. In general it allows for some creative designs, especially around forced page breaks. ![ro-position-origin](https://github.com/w3c/csswg-drafts/assets/43403851/e225ef24-faf9-4958-91db-a507e7101ca2) -- GitHub Notification of comment by bernhardf-ro Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8301#issuecomment-2014880321 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Nit: the definition of [`CSSContainerRule.containerQuery`](https://drafts.csswg.org/css-contain-3/#dom-csscontainerrule-containerquery) should return a list. > The `containerQuery` attribute, on getting, must return the `<container-query>` that was specified [...] -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7551#issuecomment-2014543789 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Nit: the definition of [`CSSContainerRule.containerQuery`](https://drafts.csswg.org/css-contain-3/#dom-csscontainerrule-containerquery) should return a list. > The `containerQuery` attribute, on getting, must return the `<container-query>` that was specified [...] -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7551#issuecomment-2014543789 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Nit: the definition of [`CSSContainerRule.containerQuery`](https://drafts.csswg.org/css-contain-3/#dom-csscontainerrule-containerquery) should return a list. > The `containerQuery` attribute, on getting, must return the `<container-query>` that was specified [...] -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7551#issuecomment-2014543789 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Nit: the definition of [`CSSContainerRule.containerQuery`](https://drafts.csswg.org/css-contain-3/#dom-csscontainerrule-containerquery) should return a list. > The `containerQuery` attribute, on getting, must return the `<container-query>` that was specified [...] -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7551#issuecomment-2014543789 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Nit: the definition of [`CSSContainerRule.containerQuery`](https://drafts.csswg.org/css-contain-3/#dom-csscontainerrule-containerquery) should return a list. > The `containerQuery` attribute, on getting, must return the `<container-query>` that was specified [...] -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7551#issuecomment-2014543789 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Nit: the definition of [`CSSContainerRule.containerQuery`](https://drafts.csswg.org/css-contain-3/#dom-csscontainerrule-containerquery) should return a list. > The `containerQuery` attribute, on getting, must return the `<container-query>` that was specified [...] -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7551#issuecomment-2014543789 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Nit: the definition of [`CSSContainerRule.containerQuery`](https://drafts.csswg.org/css-contain-3/#dom-csscontainerrule-containerquery) should return a list. > The `containerQuery` attribute, on getting, must return the `<container-query>` that was specified [...] -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7551#issuecomment-2014543789 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Nit: the definition of [`CSSContainerRule.containerQuery`](https://drafts.csswg.org/css-contain-3/#dom-csscontainerrule-containerquery) should return a list. > The `containerQuery` attribute, on getting, must return the `<container-query>` that was specified [...] -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7551#issuecomment-2014543789 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
adambernath has just created a new issue for https://github.com/w3c/csswg-drafts: == View Transitions MPA click miss == I'm testing out the MPA version, I don't really know how close it is to release, but what I've experienced so far is that it does not register click events (havent tried it with tap) around 20-30% of the time, sometimes even twice on the same element. Is this something you are aware of and working on? Thanks Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10117 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
adambernath has just created a new issue for https://github.com/w3c/csswg-drafts: == View Transitions MPA click miss == I'm testing out the MPA version, I don't really know how close it is to release, but what I've experienced so far is that it does not register click events (havent tried it with tap) around 20-30% of the time, sometimes even twice on the same element. Is this something you are aware of and working on? Thanks Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10117 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
adambernath has just created a new issue for https://github.com/w3c/csswg-drafts: == View Transitions MPA click miss == I'm testing out the MPA version, I don't really know how close it is to release, but what I've experienced so far is that it does not register click events (havent tried it with tap) around 20-30% of the time, sometimes even twice on the same element. Is this something you are aware of and working on? Thanks Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10117 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
adambernath has just created a new issue for https://github.com/w3c/csswg-drafts: == View Transitions MPA click miss == I'm testing out the MPA version, I don't really know how close it is to release, but what I've experienced so far is that it does not register click events (havent tried it with tap) around 20-30% of the time, sometimes even twice on the same element. Is this something you are aware of and working on? Thanks Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10117 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
adambernath has just created a new issue for https://github.com/w3c/csswg-drafts: == View Transitions MPA click miss == I'm testing out the MPA version, I don't really know how close it is to release, but what I've experienced so far is that it does not register click events (havent tried it with tap) around 20-30% of the time, sometimes even twice on the same element. Is this something you are aware of and working on? Thanks Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10117 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
eeeps has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-images-4] Should `contain-intrinsic-size` affect `object-fit`? == [This question came up during `sizes=auto` spec/implementation work](https://github.com/whatwg/html/issues/10079), and I don't know the answer. Here's a test page: https://codepen.io/eeeps/pen/mdgWNJo?editors=1101 [WebKit thinks that it should](https://o.img.rodeo/image/upload/v1711052026/kspptzsafh9kex0rtnf7.png), [Chromium thinks that it should](https://o.img.rodeo/image/upload/v1711052050/eyr42shpztgsxccigtr1.png), and [Firefox refuses to do any kind of object-fitting on size-contained elements](https://o.img.rodeo/image/upload/v1711052061/zfnvwrz2watd9exuah6i.png). Notably, @mirisuzanne [thinks that it shouldn't,](https://github.com/whatwg/html/issues/10079#issuecomment-2010705829) because `contain-intrinsic-size` doesn't actually change the natural dimensions of replaced elements (`Image.naturalWidth`/`naturalHeight` are unaffected), but simply tells the layout algorithm to proceed *as if those were the natural dimensions*. I agree with her, and think UAs should use the actual natural dimensions that you get from `Image.naturalWidth`/`naturalHeight`, and not the `contain-intrinsic-size` dimensions, when painting `object-fit` objects into `contain:size`d elements. I think we need some more spec language somewhere here, although admittedly my understanding of the precise meaning of [concrete object size](https://www.w3.org/TR/css-images-3/#concrete-object-size) is provisional at best. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10116 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
eeeps has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-images-4] Should `contain-intrinsic-size` affect `object-fit`? == [This question came up during `sizes=auto` spec/implementation work](https://github.com/whatwg/html/issues/10079), and I don't know the answer. Here's a test page: https://codepen.io/eeeps/pen/mdgWNJo?editors=1101 [WebKit thinks that it should](https://o.img.rodeo/image/upload/v1711052026/kspptzsafh9kex0rtnf7.png), [Chromium thinks that it should](https://o.img.rodeo/image/upload/v1711052050/eyr42shpztgsxccigtr1.png), and [Firefox refuses to do any kind of object-fitting on size-contained elements](https://o.img.rodeo/image/upload/v1711052061/zfnvwrz2watd9exuah6i.png). Notably, @mirisuzanne [thinks that it shouldn't,](https://github.com/whatwg/html/issues/10079#issuecomment-2010705829) because `contain-intrinsic-size` doesn't actually change the natural dimensions of replaced elements (`Image.naturalWidth`/`naturalHeight` are unaffected), but simply tells the layout algorithm to proceed *as if those were the natural dimensions*. I agree with her, and think UAs should use the actual natural dimensions that you get from `Image.naturalWidth`/`naturalHeight`, and not the `contain-intrinsic-size` dimensions, when painting `object-fit` objects into `contain:size`d elements. I think we need some more spec language somewhere here, although admittedly my understanding of the precise meaning of [concrete object size](https://www.w3.org/TR/css-images-3/#concrete-object-size) is provisional at best. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10116 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
eeeps has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-images-4] Should `contain-intrinsic-size` affect `object-fit`? == [This question came up during `sizes=auto` spec/implementation work](https://github.com/whatwg/html/issues/10079), and I don't know the answer. Here's a test page: https://codepen.io/eeeps/pen/mdgWNJo?editors=1101 [WebKit thinks that it should](https://o.img.rodeo/image/upload/v1711052026/kspptzsafh9kex0rtnf7.png), [Chromium thinks that it should](https://o.img.rodeo/image/upload/v1711052050/eyr42shpztgsxccigtr1.png), and [Firefox refuses to do any kind of object-fitting on size-contained elements](https://o.img.rodeo/image/upload/v1711052061/zfnvwrz2watd9exuah6i.png). Notably, @mirisuzanne [thinks that it shouldn't,](https://github.com/whatwg/html/issues/10079#issuecomment-2010705829) because `contain-intrinsic-size` doesn't actually change the natural dimensions of replaced elements (`Image.naturalWidth`/`naturalHeight` are unaffected), but simply tells the layout algorithm to proceed *as if those were the natural dimensions*. I agree with her, and think UAs should use the actual natural dimensions that you get from `Image.naturalWidth`/`naturalHeight`, and not the `contain-intrinsic-size` dimensions, when painting `object-fit` objects into `contain:size`d elements. I think we need some more spec language somewhere here, although admittedly my understanding of the precise meaning of [concrete object size](https://www.w3.org/TR/css-images-3/#concrete-object-size) is provisional at best. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10116 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
eeeps has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-images-4] Should `contain-intrinsic-size` affect `object-fit`? == [This question came up during `sizes=auto` spec/implementation work](https://github.com/whatwg/html/issues/10079), and I don't know the answer. Here's a test page: https://codepen.io/eeeps/pen/mdgWNJo?editors=1101 [WebKit thinks that it should](https://o.img.rodeo/image/upload/v1711052026/kspptzsafh9kex0rtnf7.png), [Chromium thinks that it should](https://o.img.rodeo/image/upload/v1711052050/eyr42shpztgsxccigtr1.png), and [Firefox refuses to do any kind of object-fitting on size-contained elements](https://o.img.rodeo/image/upload/v1711052061/zfnvwrz2watd9exuah6i.png). Notably, @mirisuzanne [thinks that it shouldn't,](https://github.com/whatwg/html/issues/10079#issuecomment-2010705829) because `contain-intrinsic-size` doesn't actually change the natural dimensions of replaced elements (`Image.naturalWidth`/`naturalHeight` are unaffected), but simply tells the layout algorithm to proceed *as if those were the natural dimensions*. I agree with her, and think UAs should use the actual natural dimensions that you get from `Image.naturalWidth`/`naturalHeight`, and not the `contain-intrinsic-size` dimensions, when painting `object-fit` objects into `contain:size`d elements. I think we need some more spec language somewhere here, although admittedly my understanding of the precise meaning of [concrete object size](https://www.w3.org/TR/css-images-3/#concrete-object-size) is provisional at best. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10116 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
eeeps has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-images-4] Should `contain-intrinsic-size` affect `object-fit`? == [This question came up during `sizes=auto` spec/implementation work](https://github.com/whatwg/html/issues/10079), and I don't know the answer. Here's a test page: https://codepen.io/eeeps/pen/mdgWNJo?editors=1101 [WebKit thinks that it should](https://o.img.rodeo/image/upload/v1711052026/kspptzsafh9kex0rtnf7.png), [Chromium thinks that it should](https://o.img.rodeo/image/upload/v1711052050/eyr42shpztgsxccigtr1.png), and [Firefox refuses to do any kind of object-fitting on size-contained elements](https://o.img.rodeo/image/upload/v1711052061/zfnvwrz2watd9exuah6i.png). Notably, @mirisuzanne [thinks that it shouldn't,](https://github.com/whatwg/html/issues/10079#issuecomment-2010705829) because `contain-intrinsic-size` doesn't actually change the natural dimensions of replaced elements (`Image.naturalWidth`/`naturalHeight` are unaffected), but simply tells the layout algorithm to proceed *as if those were the natural dimensions*. I agree with her, and think UAs should use the actual natural dimensions that you get from `Image.naturalWidth`/`naturalHeight`, and not the `contain-intrinsic-size` dimensions, when painting `object-fit` objects into `contain:size`d elements. I think we need some more spec language somewhere here, although admittedly my understanding of the precise meaning of [concrete object size](https://www.w3.org/TR/css-images-3/#concrete-object-size) is provisional at best. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10116 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
matthiasclasen has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-ui] Issues with the list of standard cursors == The css ui spec has a list of standard [cursors](https://www.w3.org/TR/css-ui-4/#cursor) with intended semantics, grouped by related functionality. These groups need to use compatible visual metaphors for the whole set to work well. The 'drag and drop' group has cursors to indicate the selected drag action during a drag operation: copy, move, alias, no-drop, but their descriptions are not making it very clear that they are meant to be used for this purpose. The 'resizing and scrolling' group has lots of resize cursors (which are commonly used for window resizing), but nothing for moving (which is also a common window management task). As a consequence, everybody is misusing the dnd 'move' cursor for window moving. And that makes it difficult to change the iconography of the dnd cursors - changing move to match the other dnd cursors will make it look foreign when used for window movement. At the same time, the typical 4-legged arrow looks wrong when used for drag status. Suggestions: - Admit that the move cursor is effectively used in a way that makes it belong to the 'resize and scrolling' group, so move it there, and introduce a new name for the drag status cursor that is more explicitly reserved for dnd - Clarify the indended semantics of the dnd cursors to say that they are meant for indicating the action that will be taken when hovering over a drag target during a dnd operation This issue came to light in recent changes in gtk and adwaita-icon-theme, where we tried to narrow the theme down to the css standard cursors, but ran into the problem I described above: https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/issues/286 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10115 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
matthiasclasen has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-ui] Issues with the list of standard cursors == The css ui spec has a list of standard [cursors](https://www.w3.org/TR/css-ui-4/#cursor) with intended semantics, grouped by related functionality. These groups need to use compatible visual metaphors for the whole set to work well. The 'drag and drop' group has cursors to indicate the selected drag action during a drag operation: copy, move, alias, no-drop, but their descriptions are not making it very clear that they are meant to be used for this purpose. The 'resizing and scrolling' group has lots of resize cursors (which are commonly used for window resizing), but nothing for moving (which is also a common window management task). As a consequence, everybody is misusing the dnd 'move' cursor for window moving. And that makes it difficult to change the iconography of the dnd cursors - changing move to match the other dnd cursors will make it look foreign when used for window movement. At the same time, the typical 4-legged arrow looks wrong when used for drag status. Suggestions: - Admit that the move cursor is effectively used in a way that makes it belong to the 'resize and scrolling' group, so move it there, and introduce a new name for the drag status cursor that is more explicitly reserved for dnd - Clarify the indended semantics of the dnd cursors to say that they are meant for indicating the action that will be taken when hovering over a drag target during a dnd operation This issue came to light in recent changes in gtk and adwaita-icon-theme, where we tried to narrow the theme down to the css standard cursors, but ran into the problem I described above: https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/issues/286 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10115 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
matthiasclasen has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-ui] Issues with the list of standard cursors == The css ui spec has a list of standard [cursors](https://www.w3.org/TR/css-ui-4/#cursor) with intended semantics, grouped by related functionality. These groups need to use compatible visual metaphors for the whole set to work well. The 'drag and drop' group has cursors to indicate the selected drag action during a drag operation: copy, move, alias, no-drop, but their descriptions are not making it very clear that they are meant to be used for this purpose. The 'resizing and scrolling' group has lots of resize cursors (which are commonly used for window resizing), but nothing for moving (which is also a common window management task). As a consequence, everybody is misusing the dnd 'move' cursor for window moving. And that makes it difficult to change the iconography of the dnd cursors - changing move to match the other dnd cursors will make it look foreign when used for window movement. At the same time, the typical 4-legged arrow looks wrong when used for drag status. Suggestions: - Admit that the move cursor is effectively used in a way that makes it belong to the 'resize and scrolling' group, so move it there, and introduce a new name for the drag status cursor that is more explicitly reserved for dnd - Clarify the indended semantics of the dnd cursors to say that they are meant for indicating the action that will be taken when hovering over a drag target during a dnd operation This issue came to light in recent changes in gtk and adwaita-icon-theme, where we tried to narrow the theme down to the css standard cursors, but ran into the problem I described above: https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/issues/286 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10115 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
matthiasclasen has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-ui] Issues with the list of standard cursors == The css ui spec has a list of standard [cursors](https://www.w3.org/TR/css-ui-4/#cursor) with intended semantics, grouped by related functionality. These groups need to use compatible visual metaphors for the whole set to work well. The 'drag and drop' group has cursors to indicate the selected drag action during a drag operation: copy, move, alias, no-drop, but their descriptions are not making it very clear that they are meant to be used for this purpose. The 'resizing and scrolling' group has lots of resize cursors (which are commonly used for window resizing), but nothing for moving (which is also a common window management task). As a consequence, everybody is misusing the dnd 'move' cursor for window moving. And that makes it difficult to change the iconography of the dnd cursors - changing move to match the other dnd cursors will make it look foreign when used for window movement. At the same time, the typical 4-legged arrow looks wrong when used for drag status. Suggestions: - Admit that the move cursor is effectively used in a way that makes it belong to the 'resize and scrolling' group, so move it there, and introduce a new name for the drag status cursor that is more explicitly reserved for dnd - Clarify the indended semantics of the dnd cursors to say that they are meant for indicating the action that will be taken when hovering over a drag target during a dnd operation This issue came to light in recent changes in gtk and adwaita-icon-theme, where we tried to narrow the theme down to the css standard cursors, but ran into the problem I described above: https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/issues/286 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10115 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
matthiasclasen has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-ui] Issues with the list of standard cursors == The css ui spec has a list of standard [cursors](https://www.w3.org/TR/css-ui-4/#cursor) with intended semantics, grouped by related functionality. These groups need to use compatible visual metaphors for the whole set to work well. The 'drag and drop' group has cursors to indicate the selected drag action during a drag operation: copy, move, alias, no-drop, but their descriptions are not making it very clear that they are meant to be used for this purpose. The 'resizing and scrolling' group has lots of resize cursors (which are commonly used for window resizing), but nothing for moving (which is also a common window management task). As a consequence, everybody is misusing the dnd 'move' cursor for window moving. And that makes it difficult to change the iconography of the dnd cursors - changing move to match the other dnd cursors will make it look foreign when used for window movement. At the same time, the typical 4-legged arrow looks wrong when used for drag status. Suggestions: - Admit that the move cursor is effectively used in a way that makes it belong to the 'resize and scrolling' group, so move it there, and introduce a new name for the drag status cursor that is more explicitly reserved for dnd - Clarify the indended semantics of the dnd cursors to say that they are meant for indicating the action that will be taken when hovering over a drag target during a dnd operation This issue came to light in recent changes in gtk and adwaita-icon-theme, where we tried to narrow the theme down to the css standard cursors, but ran into the problem I described above: https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/issues/286 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10115 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Data type for types in script APIs == @emilio brought up that because we want types to be readonly on the CSSViewTransitionRule, it shouldn't be a DOMTokenList. Filing this issue to clarify the data type across all script APIs. - `startViewTransition` has a `types` param which is currently sequence<DOMString>. - `CSSViewTransitionRule` has a `types` param which is currently DOMTokenList. - `ViewTransition` has a `types` param which is DOMTokenList. The `ViewTransition` is the only one that needs to me mutable. @noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10114 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@drott said: > I suggest > > * to freeze in the `<font-format>` production to be equal to an explicitly listed limited set of fixed strings (perhaps those at the time of when this was changed to keywords?) and explain how these are supposed to be interpreted (i.e. parse them analogously to the non-string parts of the `<font-format>` production). > > * to specify that for the parsed CSSOM cssText value of the parsed at-rule keyword representations should be returned. > > * to harmonise the examples in the spec to use the keyword syntax, i.e. change example 22 and 23 to use keyword syntax. @astearns said: > The remaining question is whether format() should accept keywords in addition to strings, as WebKit and one of the spec examples does. I am seeing suggestions here to only allow strings. @litherum would WebKit be OK with making this change? to which @litherum responded > I don't see any reason to forbid the idents, and they seem very natural from an authoring point-of-view... > > "format(opentype)" seems natural... So it seems that the current proposal is to allow setting with either a string or a keyword? And then @fantasai said > * If strings are the most backwards-compatible syntax, then we must serialize as strings, not as keywords. Which is also what we [resolved on](https://github.com/w3c/csswg-drafts/issues/6328#issuecomment-971823790) And this implies we need to mint new strings for any formats that don't already have them. Before I go making edits, does that all seem correct? -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6328#issuecomment-2013124814 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@drott said: > I suggest > > * to freeze in the `<font-format>` production to be equal to an explicitly listed limited set of fixed strings (perhaps those at the time of when this was changed to keywords?) and explain how these are supposed to be interpreted (i.e. parse them analogously to the non-string parts of the `<font-format>` production). > > * to specify that for the parsed CSSOM cssText value of the parsed at-rule keyword representations should be returned. > > * to harmonise the examples in the spec to use the keyword syntax, i.e. change example 22 and 23 to use keyword syntax. @astearns said: > The remaining question is whether format() should accept keywords in addition to strings, as WebKit and one of the spec examples does. I am seeing suggestions here to only allow strings. @litherum would WebKit be OK with making this change? to which @litherum responded > I don't see any reason to forbid the idents, and they seem very natural from an authoring point-of-view... > > "format(opentype)" seems natural... So it seems that the current proposal is to allow setting with either a string or a keyword? And then @fantasai said > * If strings are the most backwards-compatible syntax, then we must serialize as strings, not as keywords. Which is also what we [resolved on](https://github.com/w3c/csswg-drafts/issues/6328#issuecomment-971823790) And this implies we need to mint new strings for any formats that don't already have them. Before I go making edits, does that all seem correct? -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6328#issuecomment-2013124814 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@drott said: > I suggest > > * to freeze in the `<font-format>` production to be equal to an explicitly listed limited set of fixed strings (perhaps those at the time of when this was changed to keywords?) and explain how these are supposed to be interpreted (i.e. parse them analogously to the non-string parts of the `<font-format>` production). > > * to specify that for the parsed CSSOM cssText value of the parsed at-rule keyword representations should be returned. > > * to harmonise the examples in the spec to use the keyword syntax, i.e. change example 22 and 23 to use keyword syntax. @astearns said: > The remaining question is whether format() should accept keywords in addition to strings, as WebKit and one of the spec examples does. I am seeing suggestions here to only allow strings. @litherum would WebKit be OK with making this change? to which @litherum responded > I don't see any reason to forbid the idents, and they seem very natural from an authoring point-of-view... > > "format(opentype)" seems natural... So it seems that the current proposal is to allow setting with either a string or a keyword? And then @fantasai said > * If strings are the most backwards-compatible syntax, then we must serialize as strings, not as keywords. Which is also what we [resolved on](https://github.com/w3c/csswg-drafts/issues/6328#issuecomment-971823790) And this implies we need to mint new strings for any formats that don't already have them. Before I go making edits, does that all seem correct? -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6328#issuecomment-2013124814 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@drott said: > I suggest > > * to freeze in the `<font-format>` production to be equal to an explicitly listed limited set of fixed strings (perhaps those at the time of when this was changed to keywords?) and explain how these are supposed to be interpreted (i.e. parse them analogously to the non-string parts of the `<font-format>` production). > > * to specify that for the parsed CSSOM cssText value of the parsed at-rule keyword representations should be returned. > > * to harmonise the examples in the spec to use the keyword syntax, i.e. change example 22 and 23 to use keyword syntax. @astearns said: > The remaining question is whether format() should accept keywords in addition to strings, as WebKit and one of the spec examples does. I am seeing suggestions here to only allow strings. @litherum would WebKit be OK with making this change? to which @litherum responded > I don't see any reason to forbid the idents, and they seem very natural from an authoring point-of-view... > > "format(opentype)" seems natural... So it seems that the current proposal is to allow setting with either a string or a keyword? And then @fantasai said > * If strings are the most backwards-compatible syntax, then we must serialize as strings, not as keywords. Which is also what we [resolved on](https://github.com/w3c/csswg-drafts/issues/6328#issuecomment-971823790) And this implies we need to mint new strings for any formats that don't already have them. Before I go making edits, does that all seem correct? -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6328#issuecomment-2013124814 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@drott said: > I suggest > > * to freeze in the `<font-format>` production to be equal to an explicitly listed limited set of fixed strings (perhaps those at the time of when this was changed to keywords?) and explain how these are supposed to be interpreted (i.e. parse them analogously to the non-string parts of the `<font-format>` production). > > * to specify that for the parsed CSSOM cssText value of the parsed at-rule keyword representations should be returned. > > * to harmonise the examples in the spec to use the keyword syntax, i.e. change example 22 and 23 to use keyword syntax. @astearns said: > The remaining question is whether format() should accept keywords in addition to strings, as WebKit and one of the spec examples does. I am seeing suggestions here to only allow strings. @litherum would WebKit be OK with making this change? to which @litherum responded > I don't see any reason to forbid the idents, and they seem very natural from an authoring point-of-view... > > "format(opentype)" seems natural... So it seems that the current proposal is to allow setting with either a string or a keyword? And then @fantasai said > * If strings are the most backwards-compatible syntax, then we must serialize as strings, not as keywords. Which is also what we [resolved on](https://github.com/w3c/csswg-drafts/issues/6328#issuecomment-971823790) And this implies we need to mint new strings for any formats that don't already have them. Before I go making edits, does that all seem correct? -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6328#issuecomment-2013124814 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@drott said: > I suggest > > * to freeze in the `<font-format>` production to be equal to an explicitly listed limited set of fixed strings (perhaps those at the time of when this was changed to keywords?) and explain how these are supposed to be interpreted (i.e. parse them analogously to the non-string parts of the `<font-format>` production). > > * to specify that for the parsed CSSOM cssText value of the parsed at-rule keyword representations should be returned. > > * to harmonise the examples in the spec to use the keyword syntax, i.e. change example 22 and 23 to use keyword syntax. @astearns said: > The remaining question is whether format() should accept keywords in addition to strings, as WebKit and one of the spec examples does. I am seeing suggestions here to only allow strings. @litherum would WebKit be OK with making this change? to which @litherum responded > I don't see any reason to forbid the idents, and they seem very natural from an authoring point-of-view... > > "format(opentype)" seems natural... So it seems that the current proposal is to allow setting with either a string or a keyword? And then @fantasai said > * If strings are the most backwards-compatible syntax, then we must serialize as strings, not as keywords. Which is also what we [resolved on](https://github.com/w3c/csswg-drafts/issues/6328#issuecomment-971823790) And this implies we need to mint new strings for any formats that don't already have them. Before I go making edits, does that all seem correct? -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6328#issuecomment-2013124814 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@jfkthame @drott are those restrictions in Chrome and FF: 1. we didn't implement that, the spec is fine though 2. we are doing the right thing because (reasons) and the spec should change to reflect that -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9926#issuecomment-2013086918 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
MrHBS has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == chore: typo in css-scrollbars == @frivoal I think you meant to say paint here? See https://github.com/w3c/csswg-drafts/pull/10113 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
MrHBS has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == chore: typo in css-scrollbars == @frivoal I think you meant to say paint here? See https://github.com/w3c/csswg-drafts/pull/10113 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
MrHBS has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == chore: typo in css-scrollbars == @frivoal I think you meant to say paint here? See https://github.com/w3c/csswg-drafts/pull/10113 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@tabatkins I know it's not a pseudo class, but now that container queries are a thing, would it be feasible to have a opt-in wrapped query? -- GitHub Notification of comment by cyraid Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5150#issuecomment-2012164157 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@tabatkins I know it's not a pseudo class, but now that container queries are a thing, would it be feasible to have a opt-in wrapped query? -- GitHub Notification of comment by cyraid Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5150#issuecomment-2012164157 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@tabatkins I know it's not a pseudo class, but now that container queries are a thing, would it be feasible to have a opt-in wrapped query? -- GitHub Notification of comment by cyraid Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5150#issuecomment-2012164157 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@tabatkins I know it's not a pseudo class, but now that container queries are a thing, would it be feasible to have a opt-in wrapped query? -- GitHub Notification of comment by cyraid Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5150#issuecomment-2012164157 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@tabatkins I know it's not a pseudo class, but now that container queries are a thing, would it be feasible to have a opt-in wrapped query? -- GitHub Notification of comment by cyraid Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5150#issuecomment-2012164157 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@tabatkins I know it's not a pseudo class, but now that container queries are a thing, would it be feasible to have a opt-in wrapped query? -- GitHub Notification of comment by cyraid Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5150#issuecomment-2012164157 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@tabatkins I know it's not a pseudo class, but now that container queries are a thing, would it be feasible to have a opt-in wrapped query? -- GitHub Notification of comment by cyraid Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5150#issuecomment-2012164157 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
ccameron-chromium has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-4] Define target for gamut mapping for 2D canvas == When rendering a CSS color such as our friend `oklch(90% 90% 0deg)` to a 2D canvas, what gamut should the color be mapped to? It's not possible to map to the gamut of the display. Two reasons: * The display is not knowable in general. E.g, an offscreen canvas, something being streamed to a video or saved as images, or there could be multiple displays. * If the display is known, mapping to the gamut of the display is a potent fingerprinting vector. It may be that the target of mapping should be the [color space of the canvas](https://html.spec.whatwg.org/multipage/canvas.html#canvasrenderingcontext2dsettings). For the moment this is reasonable. When we start supporting float16 canvases, it could be less obvious. E.g, an sRGB canvas with float16 pixels can express an arbitrarily wide gamut, so gamut mapping to sRGB would impose undesirable restrictions. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10112 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
ccameron-chromium has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-4] Define target for gamut mapping for 2D canvas == When rendering a CSS color such as our friend `oklch(90% 90% 0deg)` to a 2D canvas, what gamut should the color be mapped to? It's not possible to map to the gamut of the display. Two reasons: * The display is not knowable in general. E.g, an offscreen canvas, something being streamed to a video or saved as images, or there could be multiple displays. * If the display is known, mapping to the gamut of the display is a potent fingerprinting vector. It may be that the target of mapping should be the [color space of the canvas](https://html.spec.whatwg.org/multipage/canvas.html#canvasrenderingcontext2dsettings). For the moment this is reasonable. When we start supporting float16 canvases, it could be less obvious. E.g, an sRGB canvas with float16 pixels can express an arbitrarily wide gamut, so gamut mapping to sRGB would impose undesirable restrictions. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10112 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
ccameron-chromium has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-4] Define target for gamut mapping for 2D canvas == When rendering a CSS color such as our friend `oklch(90% 90% 0deg)` to a 2D canvas, what gamut should the color be mapped to? It's not possible to map to the gamut of the display. Two reasons: * The display is not knowable in general. E.g, an offscreen canvas, something being streamed to a video or saved as images, or there could be multiple displays. * If the display is known, mapping to the gamut of the display is a potent fingerprinting vector. It may be that the target of mapping should be the [color space of the canvas](https://html.spec.whatwg.org/multipage/canvas.html#canvasrenderingcontext2dsettings). For the moment this is reasonable. When we start supporting float16 canvases, it could be less obvious. E.g, an sRGB canvas with float16 pixels can express an arbitrarily wide gamut, so gamut mapping to sRGB would impose undesirable restrictions. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10112 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
ccameron-chromium has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-4] Define target for gamut mapping for 2D canvas == When rendering a CSS color such as our friend `oklch(90% 90% 0deg)` to a 2D canvas, what gamut should the color be mapped to? It's not possible to map to the gamut of the display. Two reasons: * The display is not knowable in general. E.g, an offscreen canvas, something being streamed to a video or saved as images, or there could be multiple displays. * If the display is known, mapping to the gamut of the display is a potent fingerprinting vector. It may be that the target of mapping should be the [color space of the canvas](https://html.spec.whatwg.org/multipage/canvas.html#canvasrenderingcontext2dsettings). For the moment this is reasonable. When we start supporting float16 canvases, it could be less obvious. E.g, an sRGB canvas with float16 pixels can express an arbitrarily wide gamut, so gamut mapping to sRGB would impose undesirable restrictions. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10112 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
ccameron-chromium has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-4] Define target for gamut mapping for 2D canvas == When rendering a CSS color such as our friend `oklch(90% 90% 0deg)` to a 2D canvas, what gamut should the color be mapped to? It's not possible to map to the gamut of the display. Two reasons: * The display is not knowable in general. E.g, an offscreen canvas, something being streamed to a video or saved as images, or there could be multiple displays. * If the display is known, mapping to the gamut of the display is a potent fingerprinting vector. It may be that the target of mapping should be the [color space of the canvas](https://html.spec.whatwg.org/multipage/canvas.html#canvasrenderingcontext2dsettings). For the moment this is reasonable. When we start supporting float16 canvases, it could be less obvious. E.g, an sRGB canvas with float16 pixels can express an arbitrarily wide gamut, so gamut mapping to sRGB would impose undesirable restrictions. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10112 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
ccameron-chromium has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-4] Define target for gamut mapping for 2D canvas == When rendering a CSS color such as our friend `oklch(90% 90% 0deg)` to a 2D canvas, what gamut should the color be mapped to? It's not possible to map to the gamut of the display. Two reasons: * The display is not knowable in general. E.g, an offscreen canvas, something being streamed to a video or saved as images, or there could be multiple displays. * If the display is known, mapping to the gamut of the display is a potent fingerprinting vector. It may be that the target of mapping should be the [color space of the canvas](https://html.spec.whatwg.org/multipage/canvas.html#canvasrenderingcontext2dsettings). For the moment this is reasonable. When we start supporting float16 canvases, it could be less obvious. E.g, an sRGB canvas with float16 pixels can express an arbitrarily wide gamut, so gamut mapping to sRGB would impose undesirable restrictions. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10112 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
graouts has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-display-4] [css-animations-2] clarify and test how `display` animations involving `none` interact with pseudo-elements == Chrome has added support for the `display` property and work to add similar support in WebKit is ongoing ([bug 267762](https://bugs.webkit.org/show_bug.cgi?id=267762)). As part of this work, I noticed the Blink test [fast/css-generated-content/pseudo-animation-display.html](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/fast/css-generated-content/pseudo-animation-display.html;l=1?q=pseudo-animation-display&sq=&ss=chromium) was yielding different results in Chrome and WebKit and it was not obvious to me which of the two engines, if any, is correct. Here is the relevant part of this test: ```css #target:after { display: block; content: ""; background-color: blue; } #target.animated:after { animation: anim 1ms forwards; } @keyframes anim { from { left: 0px; display: block; } to { left: 100px; display: none; } } ``` ```javascript const target = document.getElementById('target'); target.addEventListener('animationend', () => { const style = getComputedStyle(target, ':after'); test(style, 'left', '100px'); test(style, 'display', 'block'); }); target.classList.add('animated'); ``` In WebKit, the obtained values will be (once the mentioned feature bug is fixed) `left: 100px; display: none;` matching the `to` keyframe of the forwards-filling animation. In Chrome, the values are `left: auto; display: block;`, indicating that the animation is not applied. It's not immediately obvious to me what the right behavior is here, and additionally I don't think WPT has test coverage that matches this. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10111 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
graouts has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-display-4] [css-animations-2] clarify and test how `display` animations involving `none` interact with pseudo-elements == Chrome has added support for the `display` property and work to add similar support in WebKit is ongoing ([bug 267762](https://bugs.webkit.org/show_bug.cgi?id=267762)). As part of this work, I noticed the Blink test [fast/css-generated-content/pseudo-animation-display.html](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/fast/css-generated-content/pseudo-animation-display.html;l=1?q=pseudo-animation-display&sq=&ss=chromium) was yielding different results in Chrome and WebKit and it was not obvious to me which of the two engines, if any, is correct. Here is the relevant part of this test: ```css #target:after { display: block; content: ""; background-color: blue; } #target.animated:after { animation: anim 1ms forwards; } @keyframes anim { from { left: 0px; display: block; } to { left: 100px; display: none; } } ``` ```javascript const target = document.getElementById('target'); target.addEventListener('animationend', () => { const style = getComputedStyle(target, ':after'); test(style, 'left', '100px'); test(style, 'display', 'block'); }); target.classList.add('animated'); ``` In WebKit, the obtained values will be (once the mentioned feature bug is fixed) `left: 100px; display: none;` matching the `to` keyframe of the forwards-filling animation. In Chrome, the values are `left: auto; display: block;`, indicating that the animation is not applied. It's not immediately obvious to me what the right behavior is here, and additionally I don't think WPT has test coverage that matches this. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10111 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
graouts has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-display-4] [css-animations-2] clarify and test how `display` animations involving `none` interact with pseudo-elements == Chrome has added support for the `display` property and work to add similar support in WebKit is ongoing ([bug 267762](https://bugs.webkit.org/show_bug.cgi?id=267762)). As part of this work, I noticed the Blink test [fast/css-generated-content/pseudo-animation-display.html](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/fast/css-generated-content/pseudo-animation-display.html;l=1?q=pseudo-animation-display&sq=&ss=chromium) was yielding different results in Chrome and WebKit and it was not obvious to me which of the two engines, if any, is correct. Here is the relevant part of this test: ```css #target:after { display: block; content: ""; background-color: blue; } #target.animated:after { animation: anim 1ms forwards; } @keyframes anim { from { left: 0px; display: block; } to { left: 100px; display: none; } } ``` ```javascript const target = document.getElementById('target'); target.addEventListener('animationend', () => { const style = getComputedStyle(target, ':after'); test(style, 'left', '100px'); test(style, 'display', 'block'); }); target.classList.add('animated'); ``` In WebKit, the obtained values will be (once the mentioned feature bug is fixed) `left: 100px; display: none;` matching the `to` keyframe of the forwards-filling animation. In Chrome, the values are `left: auto; display: block;`, indicating that the animation is not applied. It's not immediately obvious to me what the right behavior is here, and additionally I don't think WPT has test coverage that matches this. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10111 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
graouts has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-display-4] [css-animations-2] clarify and test how `display` animations involving `none` interact with pseudo-elements == Chrome has added support for the `display` property and work to add similar support in WebKit is ongoing ([bug 267762](https://bugs.webkit.org/show_bug.cgi?id=267762)). As part of this work, I noticed the Blink test [fast/css-generated-content/pseudo-animation-display.html](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/fast/css-generated-content/pseudo-animation-display.html;l=1?q=pseudo-animation-display&sq=&ss=chromium) was yielding different results in Chrome and WebKit and it was not obvious to me which of the two engines, if any, is correct. Here is the relevant part of this test: ```css #target:after { display: block; content: ""; background-color: blue; } #target.animated:after { animation: anim 1ms forwards; } @keyframes anim { from { left: 0px; display: block; } to { left: 100px; display: none; } } ``` ```javascript const target = document.getElementById('target'); target.addEventListener('animationend', () => { const style = getComputedStyle(target, ':after'); test(style, 'left', '100px'); test(style, 'display', 'block'); }); target.classList.add('animated'); ``` In WebKit, the obtained values will be (once the mentioned feature bug is fixed) `left: 100px; display: none;` matching the `to` keyframe of the forwards-filling animation. In Chrome, the values are `left: auto; display: block;`, indicating that the animation is not applied. It's not immediately obvious to me what the right behavior is here, and additionally I don't think WPT has test coverage that matches this. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10111 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
graouts has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-display-4] [css-animations-2] clarify and test how `display` animations involving `none` interact with pseudo-elements == Chrome has added support for the `display` property and work to add similar support in WebKit is ongoing ([bug 267762](https://bugs.webkit.org/show_bug.cgi?id=267762)). As part of this work, I noticed the Blink test [fast/css-generated-content/pseudo-animation-display.html](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/fast/css-generated-content/pseudo-animation-display.html;l=1?q=pseudo-animation-display&sq=&ss=chromium) was yielding different results in Chrome and WebKit and it was not obvious to me which of the two engines, if any, is correct. Here is the relevant part of this test: ```css #target:after { display: block; content: ""; background-color: blue; } #target.animated:after { animation: anim 1ms forwards; } @keyframes anim { from { left: 0px; display: block; } to { left: 100px; display: none; } } ``` ```javascript const target = document.getElementById('target'); target.addEventListener('animationend', () => { const style = getComputedStyle(target, ':after'); test(style, 'left', '100px'); test(style, 'display', 'block'); }); target.classList.add('animated'); ``` In WebKit, the obtained values will be (once the mentioned feature bug is fixed) `left: 100px; display: none;` matching the `to` keyframe of the forwards-filling animation. In Chrome, the values are `left: auto; display: block;`, indicating that the animation is not applied. It's not immediately obvious to me what the right behavior is here, and additionally I don't think WPT has test coverage that matches this. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10111 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
ccameron-chromium has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-4] Need a future-proof way to adjust lightness of a color == The current relative color syntax offers the promise of being able to adjust properties such as the lightness of a color. When increasing lightness of a color in the `oklch` color space, one very quickly goes far out of the gamut of current displays. This creates a problem wherein the content author is not seeing the color that they specified. In the future, that content will be within the capabilities of display hardware, and the result will not be what the author saw when they created the page (by definition). The request in this issue is to create a mechanism wherein authors can avoid this problem. Here is a worked example. Suppose I like the color `color(srgb 1 0.09 0.54)`. I may be tempted to create a lighter version of this color by doing: ``` oklch(from color(srgb 1 0.09 0.54) 90% c h) ``` The original color, in oklch, is: ``` oklch(65.28% 0.2572 0) ``` And so the resulting color is: ``` oklch(90% 0.2572 0) ``` This color is equivalent to: ``` color(srgb 1.37 0.516 0.843) ``` This color is currently outside of the gamut of almost all displays. On an sRGB display, CSS gamut mapping would display it as: ``` color(srgb 1 0.785 0.862) ``` This is not close to the true meaning of the color. By playing some games with the settings of one’s monitor, some displays are capable of producing the true color. On Chrome, because of some quirky implementation details (which are likely to change), you can see the true color (for a slightly different example value) [here](https://ccameron-chromium.github.io/webgl-examples/oklab.html) on some displays. The following is a photo of the true color (which doesn’t quite do it justice): ![photo](https://github.com/w3c/csswg-drafts/assets/32557109/26a40da2-a55c-470c-860f-d982bd58c0b1) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10110 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
foolip has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-4] Expected behavior around lightness 0 or 100% in Oklab/Oklch/Lab/LCH? == When adjusting lightness in Oklab/Oklch/Lab/LCH, what is expected behavior? This is related to handling out-of-gamut colors, because: - As lightness decreases we reach imaginary colors with no physical meaning. - As lightness increases we reach real colors that cannot be shown on most displays. I'm filing a new issue, because [since Chrome 120](https://chromiumdash.appspot.com/commit/71a936c76e12c63c3a4bee4034b5054151fdc55c), lightness exactly equalling 0 or 100% are mapped to black and white respectively. This led to a [discontinuity](https://issues.chromium.org/issues/329106317) and browsers now handle these cases differently: https://wpt.live/css/css-color/oklab-l-almost-0.html (subtle difference) https://wpt.live/css/css-color/oklab-l-almost-1.html (very apparent difference) See also [results on wpt.fyi](https://wpt.fyi/results/css/css-color?label=master&label=experimental&aligned&q=almost) In https://github.com/web-platform-tests/wpt/pull/45073#issuecomment-2002106428, @svgeesus explained that the spec previously "effectively mandated a discontinuity", but that's no longer the case, so Chrome appropriate fails these tests now. Oklab gradients with endpoints close to 0/100% are also affected. Demo at https://codepen.io/foolip/pen/zYXZPYr, with Chrome rendering inlined here: Lightness 0-100%: <img width="763" alt="zero-to-hundred" src="https://github.com/w3c/csswg-drafts/assets/498917/c4998b9c-170a-4776-95cb-69f6fe4318ef"> Lightness 0-99.9%: <img width="763" alt="zero-to-almost" src="https://github.com/w3c/csswg-drafts/assets/498917/980ba84b-6d3c-438d-b32d-b37a3fd338c5"> Lightness 0.1-100%: <img width="763" alt="almost-to-hundred" src="https://github.com/w3c/csswg-drafts/assets/498917/64d12dd8-f267-4d8a-a603-bc2698eed381"> Lightness 0.1-99.9%: <img width="763" alt="almost-to-almost" src="https://github.com/w3c/csswg-drafts/assets/498917/f0c620fb-7b3f-4a8d-bdbe-071c427cb63c"> In Firefox and Safari, all gradients look like the last case. The fastest way to get back to an interoperable state would be to revert the Chrome change, so that all browsers do [channel clipping](https://github.com/w3c/csswg-drafts/issues/9449), but ideally the behavior would only change once. I'm filing this issue as background reading for the breakout session planned on March 27. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10109 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
foolip has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-4] Expected behavior around lightness 0 or 100% in Oklab/Oklch/Lab/LCH? == When adjusting lightness in Oklab/Oklch/Lab/LCH, what is expected behavior? This is related to handling out-of-gamut colors, because: - As lightness decreases we reach imaginary colors with no physical meaning. - As lightness increases we reach real colors that cannot be shown on most displays. I'm filing a new issue, because [since Chrome 120](https://chromiumdash.appspot.com/commit/71a936c76e12c63c3a4bee4034b5054151fdc55c), lightness exactly equalling 0 or 100% are mapped to black and white respectively. This led to a [discontinuity](https://issues.chromium.org/issues/329106317) and browsers now handle these cases differently: https://wpt.live/css/css-color/oklab-l-almost-0.html (subtle difference) https://wpt.live/css/css-color/oklab-l-almost-1.html (very apparent difference) See also [results on wpt.fyi](https://wpt.fyi/results/css/css-color?label=master&label=experimental&aligned&q=almost) In https://github.com/web-platform-tests/wpt/pull/45073#issuecomment-2002106428, @svgeesus explained that the spec previously "effectively mandated a discontinuity", but that's no longer the case, so Chrome appropriate fails these tests now. Oklab gradients with endpoints close to 0/100% are also affected. Demo at https://codepen.io/foolip/pen/zYXZPYr, with Chrome rendering inlined here: Lightness 0-100%: <img width="763" alt="zero-to-hundred" src="https://github.com/w3c/csswg-drafts/assets/498917/c4998b9c-170a-4776-95cb-69f6fe4318ef"> Lightness 0-99.9%: <img width="763" alt="zero-to-almost" src="https://github.com/w3c/csswg-drafts/assets/498917/980ba84b-6d3c-438d-b32d-b37a3fd338c5"> Lightness 0.1-100%: <img width="763" alt="almost-to-hundred" src="https://github.com/w3c/csswg-drafts/assets/498917/64d12dd8-f267-4d8a-a603-bc2698eed381"> Lightness 0.1-99.9%: <img width="763" alt="almost-to-almost" src="https://github.com/w3c/csswg-drafts/assets/498917/f0c620fb-7b3f-4a8d-bdbe-071c427cb63c"> In Firefox and Safari, all gradients look like the last case. The fastest way to get back to an interoperable state would be to revert the Chrome change, so that all browsers do [channel clipping](https://github.com/w3c/csswg-drafts/issues/9449), but ideally the behavior would only change once. I'm filing this issue as background reading for the breakout session planned on March 27. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10109 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
foolip has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-4] Expected behavior around lightness 0 or 100% in Oklab/Oklch/Lab/LCH? == When adjusting lightness in Oklab/Oklch/Lab/LCH, what is expected behavior? This is related to handling out-of-gamut colors, because: - As lightness decreases we reach imaginary colors with no physical meaning. - As lightness increases we reach real colors that cannot be shown on most displays. I'm filing a new issue, because [since Chrome 120](https://chromiumdash.appspot.com/commit/71a936c76e12c63c3a4bee4034b5054151fdc55c), lightness exactly equalling 0 or 100% are mapped to black and white respectively. This led to a [discontinuity](https://issues.chromium.org/issues/329106317) and browsers now handle these cases differently: https://wpt.live/css/css-color/oklab-l-almost-0.html (subtle difference) https://wpt.live/css/css-color/oklab-l-almost-1.html (very apparent difference) See also [results on wpt.fyi](https://wpt.fyi/results/css/css-color?label=master&label=experimental&aligned&q=almost) In https://github.com/web-platform-tests/wpt/pull/45073#issuecomment-2002106428, @svgeesus explained that the spec previously "effectively mandated a discontinuity", but that's no longer the case, so Chrome appropriate fails these tests now. Oklab gradients with endpoints close to 0/100% are also affected. Demo at https://codepen.io/foolip/pen/zYXZPYr, with Chrome rendering inlined here: Lightness 0-100%: <img width="763" alt="zero-to-hundred" src="https://github.com/w3c/csswg-drafts/assets/498917/c4998b9c-170a-4776-95cb-69f6fe4318ef"> Lightness 0-99.9%: <img width="763" alt="zero-to-almost" src="https://github.com/w3c/csswg-drafts/assets/498917/980ba84b-6d3c-438d-b32d-b37a3fd338c5"> Lightness 0.1-100%: <img width="763" alt="almost-to-hundred" src="https://github.com/w3c/csswg-drafts/assets/498917/64d12dd8-f267-4d8a-a603-bc2698eed381"> Lightness 0.1-99.9%: <img width="763" alt="almost-to-almost" src="https://github.com/w3c/csswg-drafts/assets/498917/f0c620fb-7b3f-4a8d-bdbe-071c427cb63c"> In Firefox and Safari, all gradients look like the last case. The fastest way to get back to an interoperable state would be to revert the Chrome change, so that all browsers do [channel clipping](https://github.com/w3c/csswg-drafts/issues/9449), but ideally the behavior would only change once. I'm filing this issue as background reading for the breakout session planned on March 27. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10109 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
foolip has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-4] Expected behavior around lightness 0 or 100% in Oklab/Oklch/Lab/LCH? == When adjusting lightness in Oklab/Oklch/Lab/LCH, what is expected behavior? This is related to handling out-of-gamut colors, because: - As lightness decreases we reach imaginary colors with no physical meaning. - As lightness increases we reach real colors that cannot be shown on most displays. I'm filing a new issue, because [since Chrome 120](https://chromiumdash.appspot.com/commit/71a936c76e12c63c3a4bee4034b5054151fdc55c), lightness exactly equalling 0 or 100% are mapped to black and white respectively. This led to a [discontinuity](https://issues.chromium.org/issues/329106317) and browsers now handle these cases differently: https://wpt.live/css/css-color/oklab-l-almost-0.html (subtle difference) https://wpt.live/css/css-color/oklab-l-almost-1.html (very apparent difference) See also [results on wpt.fyi](https://wpt.fyi/results/css/css-color?label=master&label=experimental&aligned&q=almost) In https://github.com/web-platform-tests/wpt/pull/45073#issuecomment-2002106428, @svgeesus explained that the spec previously "effectively mandated a discontinuity", but that's no longer the case, so Chrome appropriate fails these tests now. Oklab gradients with endpoints close to 0/100% are also affected. Demo at https://codepen.io/foolip/pen/zYXZPYr, with Chrome rendering inlined here: Lightness 0-100%: <img width="763" alt="zero-to-hundred" src="https://github.com/w3c/csswg-drafts/assets/498917/c4998b9c-170a-4776-95cb-69f6fe4318ef"> Lightness 0-99.9%: <img width="763" alt="zero-to-almost" src="https://github.com/w3c/csswg-drafts/assets/498917/980ba84b-6d3c-438d-b32d-b37a3fd338c5"> Lightness 0.1-100%: <img width="763" alt="almost-to-hundred" src="https://github.com/w3c/csswg-drafts/assets/498917/64d12dd8-f267-4d8a-a603-bc2698eed381"> Lightness 0.1-99.9%: <img width="763" alt="almost-to-almost" src="https://github.com/w3c/csswg-drafts/assets/498917/f0c620fb-7b3f-4a8d-bdbe-071c427cb63c"> In Firefox and Safari, all gradients look like the last case. The fastest way to get back to an interoperable state would be to revert the Chrome change, so that all browsers do [channel clipping](https://github.com/w3c/csswg-drafts/issues/9449), but ideally the behavior would only change once. I'm filing this issue as background reading for the breakout session planned on March 27. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10109 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
foolip has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-4] Expected behavior around lightness 0 or 100% in Oklab/Oklch/Lab/LCH? == When adjusting lightness in Oklab/Oklch/Lab/LCH, what is expected behavior? This is related to handling out-of-gamut colors, because: - As lightness decreases we reach imaginary colors with no physical meaning. - As lightness increases we reach real colors that cannot be shown on most displays. I'm filing a new issue, because [since Chrome 120](https://chromiumdash.appspot.com/commit/71a936c76e12c63c3a4bee4034b5054151fdc55c), lightness exactly equalling 0 or 100% are mapped to black and white respectively. This led to a [discontinuity](https://issues.chromium.org/issues/329106317) and browsers now handle these cases differently: https://wpt.live/css/css-color/oklab-l-almost-0.html (subtle difference) https://wpt.live/css/css-color/oklab-l-almost-1.html (very apparent difference) See also [results on wpt.fyi](https://wpt.fyi/results/css/css-color?label=master&label=experimental&aligned&q=almost) In https://github.com/web-platform-tests/wpt/pull/45073#issuecomment-2002106428, @svgeesus explained that the spec previously "effectively mandated a discontinuity", but that's no longer the case, so Chrome appropriate fails these tests now. Oklab gradients with endpoints close to 0/100% are also affected. Demo at https://codepen.io/foolip/pen/zYXZPYr, with Chrome rendering inlined here: Lightness 0-100%: <img width="763" alt="zero-to-hundred" src="https://github.com/w3c/csswg-drafts/assets/498917/c4998b9c-170a-4776-95cb-69f6fe4318ef"> Lightness 0-99.9%: <img width="763" alt="zero-to-almost" src="https://github.com/w3c/csswg-drafts/assets/498917/980ba84b-6d3c-438d-b32d-b37a3fd338c5"> Lightness 0.1-100%: <img width="763" alt="almost-to-hundred" src="https://github.com/w3c/csswg-drafts/assets/498917/64d12dd8-f267-4d8a-a603-bc2698eed381"> Lightness 0.1-99.9%: <img width="763" alt="almost-to-almost" src="https://github.com/w3c/csswg-drafts/assets/498917/f0c620fb-7b3f-4a8d-bdbe-071c427cb63c"> In Firefox and Safari, all gradients look like the last case. The fastest way to get back to an interoperable state would be to revert the Chrome change, so that all browsers do [channel clipping](https://github.com/w3c/csswg-drafts/issues/9449), but ideally the behavior would only change once. I'm filing this issue as background reading for the breakout session planned on March 27. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10109 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-anchor-position-1] Define `CSSPositionTryRule.style` as `CSSPositionTryDescriptors` == It is currently defined as a `CSSStyleDeclaration`, which seems to cause [problems](https://github.com/w3c/csswg-drafts/issues/9042). Now that `CSS*Properties` and `CSS*Descriptors` interfaces inheriting `CSSStyleDeclaration` have landed in CSSOM and other specs, maybe valid properties could be defined in `CSSPositionTryRuleDescriptors`, either explicitly or with some prose (see #10105)? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10108 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-fonts] `CSSFontFaceDescriptors` is missing descriptor attributes == [`CSSFontFaceDescriptors`](https://drafts.csswg.org/css-fonts-4/#cssfontfacedescriptors) seems to be missing `font-weight` (not `fontWeight`) and [`font-stretch`/`fontStretch`](https://drafts.csswg.org/css-fonts-4/#font-face-font-stretch) (legacy). CSS Fonts 5 may also missing a partial interface definition with [`font-size`/`fontSize`](https://drafts.csswg.org/css-fonts-5/#descdef-font-face-font-size), [`size-adjust`/`sizeAdjust`](https://drafts.csswg.org/css-fonts-5/#size-adjust-desc), and `*-override`/`*Override`. A simpler alternative is proposed in #10105. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10107 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev has just created a new issue for https://github.com/w3c/csswg-drafts: == [cssom-1] `CSSMarginDescriptors` does not have a WebIDL definition == It is all in the title. https://drafts.csswg.org/cssom-1/#cssmarginrule Related: #10105 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10106 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev has just created a new issue for https://github.com/w3c/csswg-drafts: == [cssom-1] `CSSPageDescriptors` is missing descriptor attributes == Only the "standalone" descriptors `bleed`, `marks`, `size`, and the dashed and camel cased "property-like" descriptors `margin-*`, are defined as [`CSSPageDescriptors`](https://drafts.csswg.org/cssom-1/#csspagedescriptors) attributes. [`page-orientation`](https://drafts.csswg.org/css-page-3/#descdef-page-page-orientation) and [page properties](https://drafts.csswg.org/css-page-3/#page-property) are missing. Is there any reason for this? --- [if they are missing] Quote from @gsnedders: > There's a part of me that wonders if we actually what to define this, rather than "all descriptors supported for the `@page` at-rule", similar to what we do with properties? +1. Maybe the definition of a [supported property](https://drafts.csswg.org/cssom-1/#supported-css-property) or descriptor should be narrowed down to a valid property or descriptor in the context. For example: > For each descriptor `descriptor` that is a supported CSS descriptor valid in `@page`, the following interface applies ... > > [definition with dashed, camel-cased, and legacy attribute names] Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10105 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I disagree with not applying auto-spacing between a Japanese character and a Western punctuation mark. I believe it's not a matter of visual "balance" but a matter of consistency. In fact, as far as I remember, for instance, Morisawa-Linotype's CORA5-E text composition language designed for Linotype CRT/laser typesetters used by Japanese professional typographers allowed auto-spacing between a Japanese character and a Western punctuation. I don't mean you "must" always do it, but it is one of widely accepted conventions in Japanese typography. -- GitHub Notification of comment by taroyamamoto-451 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9479#issuecomment-2010932663 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I disagree with not applying auto-spacing between a Japanese character and a Western punctuation mark. I believe it's not a matter of visual "balance" but a matter of consistency. In fact, as far as I remember, for instance, Morisawa-Linotype's CORA5-E text composition language designed for Linotype CRT/laser typesetters used by Japanese professional typographers allowed auto-spacing between a Japanese character and a Western punctuation. I don't mean you "must" always do it, but it is one of widely accepted conventions in Japanese typography. -- GitHub Notification of comment by taroyamamoto-451 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9479#issuecomment-2010932663 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I disagree with not applying auto-spacing between a Japanese character and a Western punctuation mark. I believe it's not a matter of visual "balance" but a matter of consistency. In fact, as far as I remember, for instance, Morisawa-Linotype's CORA5-E text composition language designed for Linotype CRT/laser typesetters used by Japanese professional typographers allowed auto-spacing between a Japanese character and a Western punctuation. I don't mean you "must" always do it, but it is one of widely accepted conventions in Japanese typography. -- GitHub Notification of comment by taroyamamoto-451 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9479#issuecomment-2010932663 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I disagree with not applying auto-spacing between a Japanese character and a Western punctuation mark. I believe it's not a matter of visual "balance" but a matter of consistency. In fact, as far as I remember, for instance, Morisawa-Linotype's CORA5-E text composition language designed for Linotype CRT/laser typesetters used by Japanese professional typographers allowed auto-spacing between a Japanese character and a Western punctuation. I don't mean you "must" always do it, but it is one of widely accepted conventions in Japanese typography. -- GitHub Notification of comment by taroyamamoto-451 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9479#issuecomment-2010932663 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I disagree with not applying auto-spacing between a Japanese character and a Western punctuation mark. I believe it's not a matter of visual "balance" but a matter of consistency. In fact, as far as I remember, for instance, Morisawa-Linotype's CORA5-E text composition language designed for Linotype CRT/laser typesetters used by Japanese professional typographers allowed auto-spacing between a Japanese character and a Western punctuation. I don't mean you "must" always do it, but it is one of widely accepted conventions in Japanese typography. -- GitHub Notification of comment by taroyamamoto-451 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9479#issuecomment-2010932663 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I disagree with not applying auto-spacing between a Japanese character and a Western punctuation mark. I believe it's not a matter of visual "balance" but a matter of consistency. In fact, as far as I remember, for instance, Morisawa-Linotype's CORA5-E text composition language designed for Linotype CRT/laser typesetters used by Japanese professional typographers allowed auto-spacing between a Japanese character and a Western punctuation. I don't mean you "must" always do it, but it is one of widely accepted conventions in Japanese typography. -- GitHub Notification of comment by taroyamamoto-451 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9479#issuecomment-2010932663 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar closed this issue. See https://github.com/w3c/csswg-drafts/issues/9786 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] Clarify SCB for iframe == Closes https://github.com/w3c/csswg-drafts/issues/9786 See https://github.com/w3c/csswg-drafts/pull/10104 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
nt1m has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] What is the "snapshot containing block" for iframes? == @khushalsagar @vmpstr @noamr The main question I have is whether resizing an iframe skips view transitions in that iframe. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10103 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
nt1m has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] What is the "snapshot containing block" for iframes? == @khushalsagar @vmpstr @noamr The main question I have is whether resizing an iframe skips view transitions in that iframe. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10103 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
nt1m has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] What is the "snapshot containing block" for iframes? == @khushalsagar @vmpstr @noamr The main question I have is whether resizing an iframe skips view transitions in that iframe. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10103 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
nt1m has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] What is the "snapshot containing block" for iframes? == @khushalsagar @vmpstr @noamr The main question I have is whether resizing an iframe skips view transitions in that iframe. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10103 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
As a data-point, we a starting to receive some bug reports about out behaviour (specifically for this case: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12476 [1] ) With people expecting WebKit's behaviour. [1] ``` <!DOCTYPE html> Both these should render the same <div style="width: 100px; height: 100px; display: inline-flex; flex-direction: column"> <div style="aspect-ratio: 1; background-color: red;"></div> <div style="min-height: 100px; background-color: blue;"></div> </div> <div style="width: 100px; height: 100px; display: inline-flex; flex-direction: column"> <div style="width: 100%; aspect-ratio: 1; background-color: red;"></div> <div style="min-height: 100px; background-color: blue;"></div> </div> ``` (in the row direction https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12477 which only Blink is consistent). -- GitHub Notification of comment by bfgeek Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-2010318313 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
As a data-point, we a starting to receive some bug reports about out behaviour (specifically for this case: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12476 [1] ) With people expecting WebKit's behaviour. [1] ``` <!DOCTYPE html> Both these should render the same <div style="width: 100px; height: 100px; display: inline-flex; flex-direction: column"> <div style="aspect-ratio: 1; background-color: red;"></div> <div style="min-height: 100px; background-color: blue;"></div> </div> <div style="width: 100px; height: 100px; display: inline-flex; flex-direction: column"> <div style="width: 100%; aspect-ratio: 1; background-color: red;"></div> <div style="min-height: 100px; background-color: blue;"></div> </div> ``` (in the row direction https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12477 which only Blink is consistent). -- GitHub Notification of comment by bfgeek Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-2010318313 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
As a data-point, we a starting to receive some bug reports about out behaviour (specifically for this case: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12476 [1] ) With people expecting WebKit's behaviour. [1] ``` <!DOCTYPE html> Both these should render the same <div style="width: 100px; height: 100px; display: inline-flex; flex-direction: column"> <div style="aspect-ratio: 1; background-color: red;"></div> <div style="min-height: 100px; background-color: blue;"></div> </div> <div style="width: 100px; height: 100px; display: inline-flex; flex-direction: column"> <div style="width: 100%; aspect-ratio: 1; background-color: red;"></div> <div style="min-height: 100px; background-color: blue;"></div> </div> ``` (in the row direction https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12477 which only Blink is consistent). -- GitHub Notification of comment by bfgeek Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-2010318313 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
As a data-point, we a starting to receive some bug reports about out behaviour (specifically for this case: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12476 [1] ) With people expecting WebKit's behaviour. [1] ``` <!DOCTYPE html> Both these should render the same <div style="width: 100px; height: 100px; display: inline-flex; flex-direction: column"> <div style="aspect-ratio: 1; background-color: red;"></div> <div style="min-height: 100px; background-color: blue;"></div> </div> <div style="width: 100px; height: 100px; display: inline-flex; flex-direction: column"> <div style="width: 100%; aspect-ratio: 1; background-color: red;"></div> <div style="min-height: 100px; background-color: blue;"></div> </div> ``` (in the row direction https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12477 which only Blink is consistent). -- GitHub Notification of comment by bfgeek Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-2010318313 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
As a data-point, we a starting to receive some bug reports about out behaviour (specifically for this case: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12476 [1] ) With people expecting WebKit's behaviour. [1] ``` <!DOCTYPE html> Both these should render the same <div style="width: 100px; height: 100px; display: inline-flex; flex-direction: column"> <div style="aspect-ratio: 1; background-color: red;"></div> <div style="min-height: 100px; background-color: blue;"></div> </div> <div style="width: 100px; height: 100px; display: inline-flex; flex-direction: column"> <div style="width: 100%; aspect-ratio: 1; background-color: red;"></div> <div style="min-height: 100px; background-color: blue;"></div> </div> ``` (in the row direction https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12477 which only Blink is consistent). -- GitHub Notification of comment by bfgeek Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-2010318313 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
As a data-point, we a starting to receive some bug reports about out behaviour (specifically for this case: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12476 [1] ) With people expecting WebKit's behaviour. [1] ``` <!DOCTYPE html> Both these should render the same <div style="width: 100px; height: 100px; display: inline-flex; flex-direction: column"> <div style="aspect-ratio: 1; background-color: red;"></div> <div style="min-height: 100px; background-color: blue;"></div> </div> <div style="width: 100px; height: 100px; display: inline-flex; flex-direction: column"> <div style="width: 100%; aspect-ratio: 1; background-color: red;"></div> <div style="min-height: 100px; background-color: blue;"></div> </div> ``` (in the row direction https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12477 which only Blink is consistent). -- GitHub Notification of comment by bfgeek Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-2010318313 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
As a data-point, we a starting to receive some bug reports about out behaviour (specifically for this case: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12476 [1] ) With people expecting WebKit's behaviour. [1] ``` <!DOCTYPE html> Both these should render the same <div style="width: 100px; height: 100px; display: inline-flex; flex-direction: column"> <div style="aspect-ratio: 1; background-color: red;"></div> <div style="min-height: 100px; background-color: blue;"></div> </div> <div style="width: 100px; height: 100px; display: inline-flex; flex-direction: column"> <div style="width: 100%; aspect-ratio: 1; background-color: red;"></div> <div style="min-height: 100px; background-color: blue;"></div> </div> ``` (in the row direction https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12477 which only Blink is consistent). -- GitHub Notification of comment by bfgeek Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-2010318313 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
As a data-point, we a starting to receive some bug reports about out behaviour (specifically for this case: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12476 [1] ) With people expecting WebKit's behaviour. [1] ``` <!DOCTYPE html> Both these should render the same <div style="width: 100px; height: 100px; display: inline-flex; flex-direction: column"> <div style="aspect-ratio: 1; background-color: red;"></div> <div style="min-height: 100px; background-color: blue;"></div> </div> <div style="width: 100px; height: 100px; display: inline-flex; flex-direction: column"> <div style="width: 100%; aspect-ratio: 1; background-color: red;"></div> <div style="min-height: 100px; background-color: blue;"></div> </div> ``` (in the row direction https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12477 which only Blink is consistent). -- GitHub Notification of comment by bfgeek Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-2010318313 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
astearns closed this issue. See https://github.com/w3c/csswg-drafts/issues/9245 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
astearns closed this issue. See https://github.com/w3c/csswg-drafts/issues/9245 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
astearns closed this issue. See https://github.com/w3c/csswg-drafts/issues/9245 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
astearns closed this issue. See https://github.com/w3c/csswg-drafts/issues/9245 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
astearns closed this issue. See https://github.com/w3c/csswg-drafts/issues/9245 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
astearns closed this issue. See https://github.com/w3c/csswg-drafts/issues/9245 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed `[css-scrollbars] What do (semi) transparent colors mean for scrollbar-color`. <details><summary>The full IRC log of that discussion</summary> <fantasai> florian: Spec doesn't say what happens to transparent/semi-transparent colors if you specify them<br> <fantasai> florian: you could ignore the alpha channel<br> <fantasai> florian: or pre-composite against some color, maybe white, maybe white or black depending on 'color-scheme'<br> <fantasai> florian: maybe transparent thumb over track is possible, but track is opaque<br> <fantasai> florian: variety of possible options<br> <fantasai> florian: e.g. emilio just mentioned making thumb and track invisible<br> <fantasai> florian: but what about partially transparent?<br> <fantasai> florian: does the non-colored part of the scrollbar also become invisible?<br> <fantasai> florian: there's no requirement that scrollbar contains only thumb and track<br> <fantasai> florian: but in the past, and in some systems still, scrollbars could have up/down buttons as well<br> <fantasai> florian: do these become invisible as well?<br> <flackr> q+<br> <emilio> q+<br> <fantasai> florian: which options seem reasonable?<br> <fantasai> florian: Lea commented that alpha channel shouldn't be ignored<br> <fantasai> florian: suggested pre-composing against white/black<br> <astearns> ack flackr<br> <fantasai> florian: or 'canvas', is equivalent to lack/white?<br> <fantasai> emilio: not necessarily<br> <fantasai> flackr: Color used for thumb makes sense to apply to other buttons<br> <fantasai> flackr: maybe make that explicit?<br> <fantasai> flackr: for transparency, I can see use-cases for semi-transparent thumbs<br> <fantasai> flackr: maybe make them look frosted or osmething<br> <fantasai> flackr: maybe keeping their transparency to some extent allowed<br> <fantasai> flackr: but I don't think the rest of the scroll controls should be made more transparent<br> <fantasai> flackr: UA should be free to make it clear that the scroll thumb is there<br> <fantasai> flackr: to be interacted with<br> <astearns> ack emilio<br> <florian> q+<br> <fantasai> emilio: I also have a preference to not special-case transparency<br> <fantasai> emilio: let stuff be semi-transparent as much as the UA can deal with it<br> <fantasai> emilio: is there a good reason to not do that?<br> <fantasai> florian: Here, we're charging to supply both the foreground and background, and thereby ensuring good contrast<br> <PaulG> q+<br> <fantasai> florian: They need to know if the alpha channel will be ignored, composed against lack/white, or against content below?<br> <ntim> +1 to "as the UA can deal with it", some system frameworks may not support it<br> <fantasai> florian: whichever one we choose, needs to be consistent so author can choose properly contrasting colors<br> <astearns> ack emilio<br> <astearns> ack florian<br> <TabAtkins> fantasai: I agree withi everythign florian said<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: ADditional point, let's say you decide to honor the color *and* transparency<br> <TabAtkins> fantasai: And on one system they use black scrollbars, just an oval on a rectangle, flat color, no distinguishing features<br> <TabAtkins> fantasai: If you make both thumb and track transparent, it's invisible<br> <TabAtkins> fantasai: But on another system there's an aqua effect, 3d with some shading<br> <TabAtkins> fantasai: That shading will exist on a fully transparent bar<br> <TabAtkins> fantasai: So on that page the scrollbar will still be visible, just "clear"<br> <TabAtkins> fantasai: So I think we need some kidn of consistency so when an author gets one effect vs the other...<br> <TabAtkins> fantasai: So if they dev on Mac OS 2001 it looks good, but Mac 2011 you can't see anything at all...<br> <florian> q?<br> <TabAtkins> fantasai: So whethe rit's visible and has enough contrast varies depending on style, if you honor transparent colors<br> <TabAtkins> fantasai: So we need to make sure an author working on one platform can know whether their styles will make a visible or invisible scrolblar, on all platforms<br> <astearns> ack PaulG<br> <florian> q+<br> <emilio> q+<br> <fantasai> PaulG: I brought up with APA, they offered to help with the language<br> <fantasai> PaulG: and ensuring contrast/affordances etc.<br> <fantasai> PaulG: Consistency helps everyone, but even if not consistent, APA is comfortable going forward as long as articulated<br> <astearns> ack florian<br> <fantasai> florian: Given fantasai's argument, that pushes us towards precomposing, to get you reliable colors<br> <fantasai> florian: you could still end up with white-on-white and black-on-black and have that be visible with shading and invisible otherwise<br> <astearns> ack emilio<br> <fantasai> florian: but if doing foreground and background are the same, you'll have issues on some platforms -- most platforms currently<br> <fantasai> emilio: I think we should at least specify that if you provide 0 alpha channel, then the whole thing is transparent, because that's a reasonable use case<br> <fantasai> florian: why? why not use other ways of making invisible<br> <kizu> q+<br> <fantasai> emilio: same as having any element invisible<br> <fantasai> emilio: use case was showing scrollbar on :hover without layout shift. You can do with scrollbar gutter nowadays but still useful to not have to do any layout to show a scrollbar<br> <fantasai> emilio: I don't think we need to specify semitransparent colors super deeply<br> <fantasai> emilio: forcing you to compose on a flat color, that's a bit weird.<br> <fantasai> emilio: E.g. on linux/firefox you only show thumb. Track is mostly transparent.<br> <florian> q+<br> <fantasai> emilio: I think we should leave the rendering of most of these semitransparent colors up to UA and how they can provide a good scrollbar with what they get<br> <astearns> ack fantasai<br> <fantasai> fantasai: If we want invisible scrollbars, have a keyword for that. Transparent won't guarantee invisible scrollbars<br> <fantasai> emilio: I don't feel super strongly, but fading a scrollbar by animating alpha channel is nice<br> <TabAtkins> fantasai: if scrollbar is shared, it'll aniamte from clear to purple or wahtever, it just won't actuallyb e invisible because the shading will be there<br> <fantasai> emilio: I don't think current platforms do shading<br> <astearns> s/shared/shaded/<br> <fantasai> emilio: if fully transparent is actually invisible, then the animation would work in such a platform<br> <flackr> q+<br> <astearns> ack kizu<br> <fantasai> kizu: Maybe this could be considered alongside another issue, 9855 about the track and overlay scrollbars and setting colors<br> <fantasai> kizu: if we could require UAs to make the thumb and track to always have contrast, we should do it<br> <fantasai> kizu: and then we might make an exception for completely transparent scrollbars for authors that want to make it completely invisible but still take space<br> <fantasai> kizu: I'm not sure if we want to provide this use case, or always want hidden scrollbars [missed]<br> <fantasai> kizu: issue with making this a special case is that it might not work for UAs for transitions, if you want to have scrollbar appear if UA chooses to precompose colors against some other colors<br> <fantasai> kizu: if we precompose completely invisible, at zero it disappears immediately. That's maybe an issue<br> <astearns> ack florian<br> <fantasai> florian: I'm open to a variety of option, but what is not reasonable is to not specify<br> <fantasai> florian: if the author can't know if precomposed over white or black or actual element background, they can't ensure their colors provide contrast<br> <fantasai> florian: because they don't know what their colors mean<br> <fantasai> florian: so we can't allow one or the other, we have to pick one.<br> <fantasai> florian: Emilio is leaning towards "don't precompose"<br> <fantasai> florian: Another question in another issue about whether you're required to paint the track at all in overlay scrollbars, hoping to keep separate<br> <emilio> q+<br> <astearns> ack flackr<br> <fantasai> florian: desire that you see things the same suggests an alternative, require that we use the opacity from the color for the rest of the painting even if it is shaded<br> <ntim> Some system frameworks don't support alpha, so if we specify anything i'd rather have it be simple<br> <fantasai> s/florian/flackr/<br> <fantasai> flackr: unsure if that's ideal, but would allow things to fade consistently<br> <fantasai> flackr: but maybe if fully transparent don't want it to hit test either<br> <fantasai> flackr: so maybe separate property<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: If fading the scrollbar is something people really want, we shoul dhave scrollbar-opacity that controls it all, including the parts the author isn't coloring<br> <TabAtkins> fantasai: Lots of things potentially in a scrollbar that potentially aren't under author control<br> <astearns> ack emilio<br> <TabAtkins> fantasai: But downside of making it transparent when not hovering - if the element has focus but not hovering, and someone assuming it's only scrolalble when there are scrollbars, someone using a differnet mechanism won't know it's scrolalble<br> <florian> qq+<br> <fantasai> emilio: similar thing with accent-color, and e.g. Chromium ignores alpha channel, Firefox tries to deal with it, and unsure about WebKit<br> <ntim> AppKit doesn't support changing scrollbar colors, so neither does WebKit<br> <fantasai> florian: answer might be the same, but for accent-color, it is different because in that case the author is only providing one color -- UA is charged with providing good contrast<br> <emilio> *?<br> <fantasai> florian: but for scrollbars, the author needs to ensure contrast<br> <fantasai> florian: Either UA ensures contrast, or we specify how the colors composite so the author can know whether they get good contrast<br> <astearns> ack florian<br> <Zakim> florian, you wanted to react to emilio<br> <bramus> q?<br> <fantasai> astearns: I think I'm convinced that we should not try to solve the fully-transparent case with scrollbar colors because there are other bits of the scrollbar which may not be under these colors' control<br> <fantasai> astearns: I find that logic compelling<br> <ntim> WebKit does ignore alpha for accent-color<br> <fantasai> florian: if we go that way, then do we specify semi-transparent colors to be pre-composed? I think these two go together...<br> <fantasai> astearns: yes, but less convinced about that<br> <fantasai> astearns: Anyone want to argue for ignoring alpha channels in scrollbar colors entirely?<br> <fantasai> florian: What you propose seems reasonable, may be other options<br> <ntim> pre-composing is hard because we don't know what background to use<br> <fantasai> astearns: 2 options are ignoring or pre-composing<br> <fantasai> fantasai: Lots of points brought up in this discussion, might be good to list the good options and pros/cons, and resolve later<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9853#issuecomment-2010073356 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed `[css-scrollbars-1] How are the specified color used?`, and agreed to the following: * `RESOLVED: no change to spec for non-transparent colors (tests need fixing)` <details><summary>The full IRC log of that discussion</summary> <fantasai> florian: Contradiction between spec and tests<br> <fantasai> florian: tests are being more specific than the specs<br> <fantasai> florian: css-scrollbars allows setting color of thumb and track<br> <fantasai> florian: doesn't say how the color is used<br> <fantasai> florian: my interpretation was similar to accent-color, browser can use in a reasonable way<br> <fantasai> florian: if scrollbar is very plain, then it will be very basic<br> <fantasai> florian: but if has highlights, shadows, shaping, etc. then it would tint appropriately<br> <fantasai> florian: tests assume flat color<br> <fantasai> florian: and e.g. transparent means you can't see the scrollbar at all<br> <fantasai> florian: Either the tests or the spec are wrong, since they don't agree with each other<br> <emilio> q+<br> <fantasai> florian: Lea opined that it should indeed be like accent-color<br> <astearns> ack emilio<br> <fantasai> emilio: Agree in general, if you specify a color you're not forced to use just that color<br> <fantasai> emilio: but if you set both colors to transparent, it should probably require a transparent scrollbar<br> <fantasai> emilio: mostly because that's a useful way to e.g. show the scrollbar on :hover<br> <fantasai> florian: there's a separate issue on transparency<br> <fantasai> florian: could consider it a special case or not<br> <fantasai> florian: if no special case for transparency, then need to figure how how it's special<br> <astearns> ack fantasai<br> <fantasai> emilio: I added some of the transparent tests because someone was trying to go for this effect, and we didn't have it working on linux<br> <TabAtkins> fantasai: I agree with Lea's comment in the issue<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/9851#issuecomment-1994722439<br> <TabAtkins> fantasai: You should use the colro to generate a usable scheme that matches the way the scrollbar is normally styled, and the color itself should be used *somewhere* (rather than just variations of it)<br> <fantasai> florian: Propose resolution that at least if the color isn't transparent, do what Lea said<br> <fantasai> astearns: so for non-transparent colors, current tests are invalid?<br> <fantasai> florian: right<br> <fantasai> florian: means it'll be hard to test, but that's a separate problem<br> <fantasai> astearns: Proposed no change to spec for non-transparent colors, meaning current tests are overprescriptive<br> <fantasai> florian: might add a note to highlight this impact, but no normative change to spec<br> <fantasai> +1<br> <fantasai> RESOLVED: no change to spec for non-transparent colors (tests need fixing)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9851#issuecomment-2010013415 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mirisuzanne has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-contain] Can we allow absolutely positioned elements to escape a container? == I'm splitting this out from #10040, where [we resolved](https://github.com/w3c/csswg-drafts/issues/10040#issuecomment-2009840674) that `anchor-name` is able to escape containment. That helps authors position elements in relation to contained anchors. But it doesn't help with the inverse: absolutely positioned elements inside a container cannot be anchored to anything outside the container. This mirrors a common footgun with container queries. The container (`layout` containment) generates a fixed positioning context, so position-fixed elements are fixed to the container rather than the viewport. If there is any way to loosen that requirement for container queries, it would remove the footgun and also allow more fluid interaction between container queries and anchor positioning. I'm not entirely clear why this fixed-positioning context restriction is useful for container query implementations. I would have expected the (already resolved) counter example to be more problematic - since generally we don't want external layouts relying on container internals. In this case we only want internal layout to rely on external context - which is already the case. But maybe my mental model is wrong here? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10102 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mirisuzanne has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-contain] Can we allow absolutely positioned elements to escape a container? == I'm splitting this out from #10040, where [we resolved](https://github.com/w3c/csswg-drafts/issues/10040#issuecomment-2009840674) that `anchor-name` is able to escape containment. That helps authors position elements in relation to contained anchors. But it doesn't help with the inverse: absolutely positioned elements inside a container cannot be anchored to anything outside the container. This mirrors a common footgun with container queries. The container (`layout` containment) generates a fixed positioning context, so position-fixed elements are fixed to the container rather than the viewport. If there is any way to loosen that requirement for container queries, it would remove the footgun and also allow more fluid interaction between container queries and anchor positioning. I'm not entirely clear why this fixed-positioning context restriction is useful for container query implementations. I would have expected the (already resolved) counter example to be more problematic - since generally we don't want external layouts relying on container internals. In this case we only want internal layout to rely on external context - which is already the case. But maybe my mental model is wrong here? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10102 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mirisuzanne has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-contain] Can we allow absolutely positioned elements to escape a container? == I'm splitting this out from #10040, where [we resolved](https://github.com/w3c/csswg-drafts/issues/10040#issuecomment-2009840674) that `anchor-name` is able to escape containment. That helps authors position elements in relation to contained anchors. But it doesn't help with the inverse: absolutely positioned elements inside a container cannot be anchored to anything outside the container. This mirrors a common footgun with container queries. The container (`layout` containment) generates a fixed positioning context, so position-fixed elements are fixed to the container rather than the viewport. If there is any way to loosen that requirement for container queries, it would remove the footgun and also allow more fluid interaction between container queries and anchor positioning. I'm not entirely clear why this fixed-positioning context restriction is useful for container query implementations. I would have expected the (already resolved) counter example to be more problematic - since generally we don't want external layouts relying on container internals. In this case we only want internal layout to rely on external context - which is already the case. But maybe my mental model is wrong here? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10102 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mirisuzanne has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-contain] Can we allow absolutely positioned elements to escape a container? == I'm splitting this out from #10040, where [we resolved](https://github.com/w3c/csswg-drafts/issues/10040#issuecomment-2009840674) that `anchor-name` is able to escape containment. That helps authors position elements in relation to contained anchors. But it doesn't help with the inverse: absolutely positioned elements inside a container cannot be anchored to anything outside the container. This mirrors a common footgun with container queries. The container (`layout` containment) generates a fixed positioning context, so position-fixed elements are fixed to the container rather than the viewport. If there is any way to loosen that requirement for container queries, it would remove the footgun and also allow more fluid interaction between container queries and anchor positioning. I'm not entirely clear why this fixed-positioning context restriction is useful for container query implementations. I would have expected the (already resolved) counter example to be more problematic - since generally we don't want external layouts relying on container internals. In this case we only want internal layout to rely on external context - which is already the case. But maybe my mental model is wrong here? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10102 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mirisuzanne has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-contain] Can we allow absolutely positioned elements to escape a container? == I'm splitting this out from #10040, where [we resolved](https://github.com/w3c/csswg-drafts/issues/10040#issuecomment-2009840674) that `anchor-name` is able to escape containment. That helps authors position elements in relation to contained anchors. But it doesn't help with the inverse: absolutely positioned elements inside a container cannot be anchored to anything outside the container. This mirrors a common footgun with container queries. The container (`layout` containment) generates a fixed positioning context, so position-fixed elements are fixed to the container rather than the viewport. If there is any way to loosen that requirement for container queries, it would remove the footgun and also allow more fluid interaction between container queries and anchor positioning. I'm not entirely clear why this fixed-positioning context restriction is useful for container query implementations. I would have expected the (already resolved) counter example to be more problematic - since generally we don't want external layouts relying on container internals. In this case we only want internal layout to rely on external context - which is already the case. But maybe my mental model is wrong here? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10102 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed ``[css-anchor-position-1] Define interaction with the cascade in `@position-try` ``, and agreed to the following: * `RESOLVED: fallback styles live in a new "Position Fallback Origin". They revert like Animation styles (back to User origin)` <details><summary>The full IRC log of that discussion</summary> <chrishtr> TabAtkins: we resolved earlier that rules from position fallbacks interact with the cascade in some way<br> <chrishtr> TabAtkins: now we want to define that<br> <chrishtr> TabAtkins: propose that rules applied by a posoition-try have a new origin after author origin and before animation origin<br> <chrishtr> TabAtkins: this lets such rules win over all author rules but lose to animation, important etc<br> <chrishtr> TabAtkins: revert keyword would also revert to user origin, just like animations<br> <emilio> q+<br> <Rossen_> ack emilio<br> <chrishtr> emilio: can can rules in this origin change position?<br> <chrishtr> TabAtkins: yes<br> <chrishtr> emilio: s/position/transition/<br> <chrishtr> TabAtkins: only once all of the cascade has finished is there a transition to start<br> <chrishtr> emilio: details of that seem fiddly. Seems the right behavior but needs edge case testing and spec text to make sure it's clear<br> <chrishtr> TabAtkins: current spec says to go through them in sequence and only declare the element's real style once all have done<br> <chrishtr> emilio: these things used to not be done until after layout?<br> <chrishtr> TabAtkins: these are inputs to layout and so are used styles<br> <chrishtr> emilio: but how does that cause transitions?<br> <chrishtr> TabAtkins: uses the same mechanism we discussed before<br> <TabAtkins> > These modified styles are applied to the element via interleaving, so they affect computed values (and can trigger transitions/etc) even tho they depend on layout and used values.<br> <chrishtr> emilio: that causes interleaving then?<br> <chrishtr> emilio: performance may be an issue, but if that's what we want ok<br> <chrishtr> futhark: it's quite similar to container queries - might need to repeat style multiple times due to interleaved style and layout across containers<br> <dbaron> futhark: ... before starting transitions<br> <chrishtr> chrishtr: emilio was asking about performance concerns also?<br> <chrishtr> emilio: my question was about remembering rules from before and how are we supposed to do that?<br> <chrishtr> futhark: in Chromium that is part of the cascade implementation generally<br> <chrishtr> futhark: we need to handle that regardless for regular animations<br> <chrishtr> futhark: I forget the exact way that important overriddes animations?<br> <chrishtr> emilio: animations override important. but if we're just reusing the regular cascade then it's fine<br> <chrishtr> futhark: what we do is to insert these trys into the cascade as appropriate and re-run it<br> <chrishtr> emilio: still a bit concerned about performance, but it's fine<br> <chrishtr> futhark: some optimizations can be applied since the try blocks are more scoped<br> <chrishtr> emilio: haven't read the exact spec text but seems fine to me<br> <chrishtr> fantasai: wanted to say that this is the most reasonable place in the cascade to put these rules, other than possibly somehow inlining them somewhere, not sure<br> <astearns> let’s try to get as much of these fiddly details into a spec as we can<br> <chrishtr> fantasai: but that possible alternative sounds complicated<br> <chrishtr> fantasai: we should minimize what goes into these try blocks and put other features elsewhere<br> <chrishtr> fantasai: this way we can maximize the % of styles that end up in their regular place in the cascade<br> <chrishtr> fantasai: for inset and margin it's reasonable to put them in position-try, but for more stylistic items they should go in the cascade proper outside of a position-try rule whenever possible<br> <fantasai> s/somewhere/where the position-try declaration that sources them lives/<br> <fantasai> s/other features/other declarations/<br> <TabAtkins> proposed reoslution: fallback styles live in a new "Position Fallback Origin"<br> <TabAtkins> proposed resoultion: They revert like Animation styles (back to User origin)<br> <chrishtr> RESOLVED: fallback styles live in a new "Position Fallback Origin". They revert like Animation styles (back to User origin)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9149#issuecomment-2009875182 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed ``[css-anchor-position-1] Define interaction with the cascade in `@position-try` ``, and agreed to the following: * `RESOLVED: fallback styles live in a new "Position Fallback Origin". They revert like Animation styles (back to User origin)` <details><summary>The full IRC log of that discussion</summary> <chrishtr> TabAtkins: we resolved earlier that rules from position fallbacks interact with the cascade in some way<br> <chrishtr> TabAtkins: now we want to define that<br> <chrishtr> TabAtkins: propose that rules applied by a posoition-try have a new origin after author origin and before animation origin<br> <chrishtr> TabAtkins: this lets such rules win over all author rules but lose to animation, important etc<br> <chrishtr> TabAtkins: revert keyword would also revert to user origin, just like animations<br> <emilio> q+<br> <Rossen_> ack emilio<br> <chrishtr> emilio: can can rules in this origin change position?<br> <chrishtr> TabAtkins: yes<br> <chrishtr> emilio: s/position/transition/<br> <chrishtr> TabAtkins: only once all of the cascade has finished is there a transition to start<br> <chrishtr> emilio: details of that seem fiddly. Seems the right behavior but needs edge case testing and spec text to make sure it's clear<br> <chrishtr> TabAtkins: current spec says to go through them in sequence and only declare the element's real style once all have done<br> <chrishtr> emilio: these things used to not be done until after layout?<br> <chrishtr> TabAtkins: these are inputs to layout and so are used styles<br> <chrishtr> emilio: but how does that cause transitions?<br> <chrishtr> TabAtkins: uses the same mechanism we discussed before<br> <TabAtkins> > These modified styles are applied to the element via interleaving, so they affect computed values (and can trigger transitions/etc) even tho they depend on layout and used values.<br> <chrishtr> emilio: that causes interleaving then?<br> <chrishtr> emilio: performance may be an issue, but if that's what we want ok<br> <chrishtr> futhark: it's quite similar to container queries - might need to repeat style multiple times due to interleaved style and layout across containers<br> <dbaron> futhark: ... before starting transitions<br> <chrishtr> chrishtr: emilio was asking about performance concerns also?<br> <chrishtr> emilio: my question was about remembering rules from before and how are we supposed to do that?<br> <chrishtr> futhark: in Chromium that is part of the cascade implementation generally<br> <chrishtr> futhark: we need to handle that regardless for regular animations<br> <chrishtr> futhark: I forget the exact way that important overriddes animations?<br> <chrishtr> emilio: animations override important. but if we're just reusing the regular cascade then it's fine<br> <chrishtr> futhark: what we do is to insert these trys into the cascade as appropriate and re-run it<br> <chrishtr> emilio: still a bit concerned about performance, but it's fine<br> <chrishtr> futhark: some optimizations can be applied since the try blocks are more scoped<br> <chrishtr> emilio: haven't read the exact spec text but seems fine to me<br> <chrishtr> fantasai: wanted to say that this is the most reasonable place in the cascade to put these rules, other than possibly somehow inlining them somewhere, not sure<br> <astearns> let’s try to get as much of these fiddly details into a spec as we can<br> <chrishtr> fantasai: but that possible alternative sounds complicated<br> <chrishtr> fantasai: we should minimize what goes into these try blocks and put other features elsewhere<br> <chrishtr> fantasai: this way we can maximize the % of styles that end up in their regular place in the cascade<br> <chrishtr> fantasai: for inset and margin it's reasonable to put them in position-try, but for more stylistic items they should go in the cascade proper outside of a position-try rule whenever possible<br> <fantasai> s/somewhere/where the position-try declaration that sources them lives/<br> <fantasai> s/other features/other declarations/<br> <TabAtkins> proposed reoslution: fallback styles live in a new "Position Fallback Origin"<br> <TabAtkins> proposed resoultion: They revert like Animation styles (back to User origin)<br> <chrishtr> RESOLVED: fallback styles live in a new "Position Fallback Origin". They revert like Animation styles (back to User origin)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9149#issuecomment-2009875182 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed ``[css-anchor-position-1] Define interaction with the cascade in `@position-try` ``, and agreed to the following: * `RESOLVED: fallback styles live in a new "Position Fallback Origin". They revert like Animation styles (back to User origin)` <details><summary>The full IRC log of that discussion</summary> <chrishtr> TabAtkins: we resolved earlier that rules from position fallbacks interact with the cascade in some way<br> <chrishtr> TabAtkins: now we want to define that<br> <chrishtr> TabAtkins: propose that rules applied by a posoition-try have a new origin after author origin and before animation origin<br> <chrishtr> TabAtkins: this lets such rules win over all author rules but lose to animation, important etc<br> <chrishtr> TabAtkins: revert keyword would also revert to user origin, just like animations<br> <emilio> q+<br> <Rossen_> ack emilio<br> <chrishtr> emilio: can can rules in this origin change position?<br> <chrishtr> TabAtkins: yes<br> <chrishtr> emilio: s/position/transition/<br> <chrishtr> TabAtkins: only once all of the cascade has finished is there a transition to start<br> <chrishtr> emilio: details of that seem fiddly. Seems the right behavior but needs edge case testing and spec text to make sure it's clear<br> <chrishtr> TabAtkins: current spec says to go through them in sequence and only declare the element's real style once all have done<br> <chrishtr> emilio: these things used to not be done until after layout?<br> <chrishtr> TabAtkins: these are inputs to layout and so are used styles<br> <chrishtr> emilio: but how does that cause transitions?<br> <chrishtr> TabAtkins: uses the same mechanism we discussed before<br> <TabAtkins> > These modified styles are applied to the element via interleaving, so they affect computed values (and can trigger transitions/etc) even tho they depend on layout and used values.<br> <chrishtr> emilio: that causes interleaving then?<br> <chrishtr> emilio: performance may be an issue, but if that's what we want ok<br> <chrishtr> futhark: it's quite similar to container queries - might need to repeat style multiple times due to interleaved style and layout across containers<br> <dbaron> futhark: ... before starting transitions<br> <chrishtr> chrishtr: emilio was asking about performance concerns also?<br> <chrishtr> emilio: my question was about remembering rules from before and how are we supposed to do that?<br> <chrishtr> futhark: in Chromium that is part of the cascade implementation generally<br> <chrishtr> futhark: we need to handle that regardless for regular animations<br> <chrishtr> futhark: I forget the exact way that important overriddes animations?<br> <chrishtr> emilio: animations override important. but if we're just reusing the regular cascade then it's fine<br> <chrishtr> futhark: what we do is to insert these trys into the cascade as appropriate and re-run it<br> <chrishtr> emilio: still a bit concerned about performance, but it's fine<br> <chrishtr> futhark: some optimizations can be applied since the try blocks are more scoped<br> <chrishtr> emilio: haven't read the exact spec text but seems fine to me<br> <chrishtr> fantasai: wanted to say that this is the most reasonable place in the cascade to put these rules, other than possibly somehow inlining them somewhere, not sure<br> <astearns> let’s try to get as much of these fiddly details into a spec as we can<br> <chrishtr> fantasai: but that possible alternative sounds complicated<br> <chrishtr> fantasai: we should minimize what goes into these try blocks and put other features elsewhere<br> <chrishtr> fantasai: this way we can maximize the % of styles that end up in their regular place in the cascade<br> <chrishtr> fantasai: for inset and margin it's reasonable to put them in position-try, but for more stylistic items they should go in the cascade proper outside of a position-try rule whenever possible<br> <fantasai> s/somewhere/where the position-try declaration that sources them lives/<br> <fantasai> s/other features/other declarations/<br> <TabAtkins> proposed reoslution: fallback styles live in a new "Position Fallback Origin"<br> <TabAtkins> proposed resoultion: They revert like Animation styles (back to User origin)<br> <chrishtr> RESOLVED: fallback styles live in a new "Position Fallback Origin". They revert like Animation styles (back to User origin)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9149#issuecomment-2009875182 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Anchor positioning determines the position, which should affect a scroll driven animation on the anchoring element (see blue anchor in demo). A scroll driven animation could be made to affect the position of the anchor (green anchor in demo). These both behave as expected in chrome. I put together a [demo](https://jsbin.com/menefik/edit?html,css,js,output) of both of these cases. I suppose a particular degenerate case would be if the anchoring element defines a timeline based on its position that is used by a scroll driven animation, [example case](https://jsbin.com/jisugub/edit?html,css,js,output) shows this. The anchored element defines a timeline which is used to move the anchor target to which it is anchoring which in turn affects the anchor position. This also seems to work fine in chrome since scroll timelines are only sampled once per frame - though admittedly the sampled position of an anchor position element would be before the current update. -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9379#issuecomment-2009607082 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Anchor positioning determines the position, which should affect a scroll driven animation on the anchoring element (see blue anchor in demo). A scroll driven animation could be made to affect the position of the anchor (green anchor in demo). These both behave as expected in chrome. I put together a [demo](https://jsbin.com/menefik/edit?html,css,js,output) of both of these cases. I suppose a particular degenerate case would be if the anchoring element defines a timeline based on its position that is used by a scroll driven animation, [example case](https://jsbin.com/jisugub/edit?html,css,js,output) shows this. The anchored element defines a timeline which is used to move the anchor target to which it is anchoring which in turn affects the anchor position. This also seems to work fine in chrome since scroll timelines are only sampled once per frame - though admittedly the sampled position of an anchor position element would be before the current update. -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9379#issuecomment-2009607082 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Anchor positioning determines the position, which should affect a scroll driven animation on the anchoring element (see blue anchor in demo). A scroll driven animation could be made to affect the position of the anchor (green anchor in demo). These both behave as expected in chrome. I put together a [demo](https://jsbin.com/menefik/edit?html,css,js,output) of both of these cases. I suppose a particular degenerate case would be if the anchoring element defines a timeline based on its position that is used by a scroll driven animation, [example case](https://jsbin.com/jisugub/edit?html,css,js,output) shows this. The anchored element defines a timeline which is used to move the anchor target to which it is anchoring which in turn affects the anchor position. This also seems to work fine in chrome since scroll timelines are only sampled once per frame - though admittedly the sampled position of an anchor position element would be before the current update. -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9379#issuecomment-2009607082 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Anchor positioning determines the position, which should affect a scroll driven animation on the anchoring element (see blue anchor in demo). A scroll driven animation could be made to affect the position of the anchor (green anchor in demo). These both behave as expected in chrome. I put together a [demo](https://jsbin.com/menefik/edit?html,css,js,output) of both of these cases. I suppose a particular degenerate case would be if the anchoring element defines a timeline based on its position that is used by a scroll driven animation, [example case](https://jsbin.com/jisugub/edit?html,css,js,output) shows this. The anchored element defines a timeline which is used to move the anchor target to which it is anchoring which in turn affects the anchor position. This also seems to work fine in chrome since scroll timelines are only sampled once per frame - though admittedly the sampled position of an anchor position element would be before the current update. -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9379#issuecomment-2009607082 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Anchor positioning determines the position, which should affect a scroll driven animation on the anchoring element (see blue anchor in demo). A scroll driven animation could be made to affect the position of the anchor (green anchor in demo). These both behave as expected in chrome. I put together a [demo](https://jsbin.com/menefik/edit?html,css,js,output) of both of these cases. I suppose a particular degenerate case would be if the anchoring element defines a timeline based on its position that is used by a scroll driven animation, [example case](https://jsbin.com/jisugub/edit?html,css,js,output) shows this. The anchored element defines a timeline which is used to move the anchor target to which it is anchoring which in turn affects the anchor position. This also seems to work fine in chrome since scroll timelines are only sampled once per frame - though admittedly the sampled position of an anchor position element would be before the current update. -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9379#issuecomment-2009607082 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
emilio closed this issue. See https://github.com/w3c/csswg-drafts/issues/9809 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@tabatkins @svgeesus I updated now that the webidl parser is fixed, and it looks good from here. I should look into @gsnedders' suggestion about making descriptors more generically exposed in page and font-face descriptors, but I agree we can probably merge this and iterate on the specific text, because I don't know if legacy descriptors like `-webkit-foo` (is there any at all?) would be exposed using the `WebKitFoo` syntax or something else. Does that sound good? -- GitHub Notification of comment by emilio Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9686#issuecomment-2009232592 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@tabatkins @svgeesus I updated now that the webidl parser is fixed, and it looks good from here. I should look into @gsnedders' suggestion about making descriptors more generically exposed in page and font-face descriptors, but I agree we can probably merge this and iterate on the specific text, because I don't know if legacy descriptors like `-webkit-foo` (is there any at all?) would be exposed using the `WebKitFoo` syntax or something else. Does that sound good? -- GitHub Notification of comment by emilio Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9686#issuecomment-2009232592 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
nt1m has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] Which skipping reason does "View transition page-visibility change steps" use? == https://drafts.csswg.org/css-view-transitions-1/#page-visibility-change-steps > If document’s [active view transition](https://drafts.csswg.org/css-view-transitions-1/#document-active-view-transition) is not null, then [skip](https://drafts.csswg.org/css-view-transitions-1/#skip-the-view-transition) document’s active view transition. I noticed this while implementing in WebKit, the current spec doesn't say which reason / exception to pass to the skip the view transition algorithm. cc @noamr @khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10101 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
nt1m has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] Which skipping reason does "View transition page-visibility change steps" use? == https://drafts.csswg.org/css-view-transitions-1/#page-visibility-change-steps > If document’s [active view transition](https://drafts.csswg.org/css-view-transitions-1/#document-active-view-transition) is not null, then [skip](https://drafts.csswg.org/css-view-transitions-1/#skip-the-view-transition) document’s active view transition. I noticed this while implementing in WebKit, the current spec doesn't say which reason / exception to pass to the skip the view transition algorithm. cc @noamr @khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10101 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
This was merged in https://github.com/w3c/csswg-drafts/pull/7826, though I'm unclear on the process steps here (was there a resolution where this was adopted?) Should this issue be closed? -- GitHub Notification of comment by theres-waldo Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7767#issuecomment-2008334151 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
This was merged in https://github.com/w3c/csswg-drafts/pull/7826, though I'm unclear on the process steps here (was there a resolution where this was adopted?) Should this issue be closed? -- GitHub Notification of comment by theres-waldo Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7767#issuecomment-2008334151 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
This was merged in https://github.com/w3c/csswg-drafts/pull/7826, though I'm unclear on the process steps here (was there a resolution where this was adopted?) Should this issue be closed? -- GitHub Notification of comment by theres-waldo Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7767#issuecomment-2008334151 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
php4fan has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox]: flex-direction: what about "bustrophedon" rows and columns?? == For `flex-direction` we have these possible values: ``` row | row-reverse | column | column-reverse ``` There's an obvious need for "bustrophedon"-like values. I have no idea how they should be called, but there should obviously be four more values. I'll use made-up names: - **row-alternate**: rows, the first row as in `row`, the second as in `row-reverse`, the third again as in `row`, etc. - **row-reverse**: same but starting with as in `row-reverse` - **column-alternate**: columns, the first column as in `column`, the second as in `column-reverse`, etc. - **column-alternate-reverse**: same but starting as in `column-reverse` I can't believe these don't already exist. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10100 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
php4fan has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox]: flex-direction: what about "bustrophedon" rows and columns?? == For `flex-direction` we have these possible values: ``` row | row-reverse | column | column-reverse ``` There's an obvious need for "bustrophedon"-like values. I have no idea how they should be called, but there should obviously be four more values. I'll use made-up names: - **row-alternate**: rows, the first row as in `row`, the second as in `row-reverse`, the third again as in `row`, etc. - **row-reverse**: same but starting with as in `row-reverse` - **column-alternate**: columns, the first column as in `column`, the second as in `column-reverse`, etc. - **column-alternate-reverse**: same but starting as in `column-reverse` I can't believe these don't already exist. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10100 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
php4fan has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox]: flex-direction: what about "bustrophedon" rows and columns?? == For `flex-direction` we have these possible values: ``` row | row-reverse | column | column-reverse ``` There's an obvious need for "bustrophedon"-like values. I have no idea how they should be called, but there should obviously be four more values. I'll use made-up names: - **row-alternate**: rows, the first row as in `row`, the second as in `row-reverse`, the third again as in `row`, etc. - **row-reverse**: same but starting with as in `row-reverse` - **column-alternate**: columns, the first column as in `column`, the second as in `column-reverse`, etc. - **column-alternate-reverse**: same but starting as in `column-reverse` I can't believe these don't already exist. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10100 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
php4fan has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox]: flex-direction: what about "bustrophedon" rows and columns?? == For `flex-direction` we have these possible values: ``` row | row-reverse | column | column-reverse ``` There's an obvious need for "bustrophedon"-like values. I have no idea how they should be called, but there should obviously be four more values. I'll use made-up names: - **row-alternate**: rows, the first row as in `row`, the second as in `row-reverse`, the third again as in `row`, etc. - **row-reverse**: same but starting with as in `row-reverse` - **column-alternate**: columns, the first column as in `column`, the second as in `column-reverse`, etc. - **column-alternate-reverse**: same but starting as in `column-reverse` I can't believe these don't already exist. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10100 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
This is a dupe of #7758 now. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9380#issuecomment-2008145836 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
This is a dupe of #7758 now. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9380#issuecomment-2008145836 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/9380 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/10075 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/8543 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/8433 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/8433 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Most of these had now been fixed; I added the link to `#typedef-supports-selector-fn`. -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8433#issuecomment-2008107201 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/5804 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Promises now links to MDN. Link to task sources added. -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1187#issuecomment-2008076902 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/1187 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3738 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@yisibl Safari hasn't shipped yet, [let's not panic](https://github.com/WebKit/WebKit/pull/24414#issuecomment-1959798312). :) -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9733#issuecomment-2007904753 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@yisibl Safari hasn't shipped yet, [let's not panic](https://github.com/WebKit/WebKit/pull/24414#issuecomment-1959798312). :) -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9733#issuecomment-2007904753 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@yisibl Safari hasn't shipped yet, [let's not panic](https://github.com/WebKit/WebKit/pull/24414#issuecomment-1959798312). :) -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9733#issuecomment-2007904753 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@yisibl Safari hasn't shipped yet, [let's not panic](https://github.com/WebKit/WebKit/pull/24414#issuecomment-1959798312). :) -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9733#issuecomment-2007904753 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@yisibl Safari hasn't shipped yet, [let's not panic](https://github.com/WebKit/WebKit/pull/24414#issuecomment-1959798312). :) -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9733#issuecomment-2007904753 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-anchor-position] When to invalidate "last remembered position-try option"? == Currently, we're just using essentially the same conditions for forgetting "last remembered position-try option" as we do with "last remembered size". But the chosen position-try option depends on more stuff than the size. Notably, what happens if you *change the 'position-try-options' list*? And what happens if the `@position-try` rules are changed? (mutated, or deleted, or we add a new one that was already referred to while not previously existing) And theoretically, other things can change the styles, like, what if the element with a referenced anchor-name changes? Weighing both usability with difficulty, I propose: * We forget the remembered option if the computed value of 'position-try-options' changes * We forget the remembered option if any of the referenced `@position-try` rules are added/removed/mutated. * That's it. (If other things that affect the style change, but they still don't result in having a non-overflowing position, oh well.) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10099 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-anchor-position] When to invalidate "last remembered position-try option"? == Currently, we're just using essentially the same conditions for forgetting "last remembered position-try option" as we do with "last remembered size". But the chosen position-try option depends on more stuff than the size. Notably, what happens if you *change the 'position-try-options' list*? And what happens if the `@position-try` rules are changed? (mutated, or deleted, or we add a new one that was already referred to while not previously existing) And theoretically, other things can change the styles, like, what if the element with a referenced anchor-name changes? Weighing both usability with difficulty, I propose: * We forget the remembered option if the computed value of 'position-try-options' changes * We forget the remembered option if any of the referenced `@position-try` rules are added/removed/mutated. * That's it. (If other things that affect the style change, but they still don't result in having a non-overflowing position, oh well.) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10099 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-anchor-position] When to invalidate "last remembered position-try option"? == Currently, we're just using essentially the same conditions for forgetting "last remembered position-try option" as we do with "last remembered size". But the chosen position-try option depends on more stuff than the size. Notably, what happens if you *change the 'position-try-options' list*? And what happens if the `@position-try` rules are changed? (mutated, or deleted, or we add a new one that was already referred to while not previously existing) And theoretically, other things can change the styles, like, what if the element with a referenced anchor-name changes? Weighing both usability with difficulty, I propose: * We forget the remembered option if the computed value of 'position-try-options' changes * We forget the remembered option if any of the referenced `@position-try` rules are added/removed/mutated. * That's it. (If other things that affect the style change, but they still don't result in having a non-overflowing position, oh well.) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10099 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-anchor-position] When to invalidate "last remembered position-try option"? == Currently, we're just using essentially the same conditions for forgetting "last remembered position-try option" as we do with "last remembered size". But the chosen position-try option depends on more stuff than the size. Notably, what happens if you *change the 'position-try-options' list*? And what happens if the `@position-try` rules are changed? (mutated, or deleted, or we add a new one that was already referred to while not previously existing) And theoretically, other things can change the styles, like, what if the element with a referenced anchor-name changes? Weighing both usability with difficulty, I propose: * We forget the remembered option if the computed value of 'position-try-options' changes * We forget the remembered option if any of the referenced `@position-try` rules are added/removed/mutated. * That's it. (If other things that affect the style change, but they still don't result in having a non-overflowing position, oh well.) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10099 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-anchor-position] When to invalidate "last remembered position-try option"? == Currently, we're just using essentially the same conditions for forgetting "last remembered position-try option" as we do with "last remembered size". But the chosen position-try option depends on more stuff than the size. Notably, what happens if you *change the 'position-try-options' list*? And what happens if the `@position-try` rules are changed? (mutated, or deleted, or we add a new one that was already referred to while not previously existing) And theoretically, other things can change the styles, like, what if the element with a referenced anchor-name changes? Weighing both usability with difficulty, I propose: * We forget the remembered option if the computed value of 'position-try-options' changes * We forget the remembered option if any of the referenced `@position-try` rules are added/removed/mutated. * That's it. (If other things that affect the style change, but they still don't result in having a non-overflowing position, oh well.) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10099 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-anchor-position] When to invalidate "last remembered position-try option"? == Currently, we're just using essentially the same conditions for forgetting "last remembered position-try option" as we do with "last remembered size". But the chosen position-try option depends on more stuff than the size. Notably, what happens if you *change the 'position-try-options' list*? And what happens if the `@position-try` rules are changed? (mutated, or deleted, or we add a new one that was already referred to while not previously existing) And theoretically, other things can change the styles, like, what if the element with a referenced anchor-name changes? Weighing both usability with difficulty, I propose: * We forget the remembered option if the computed value of 'position-try-options' changes * We forget the remembered option if any of the referenced `@position-try` rules are added/removed/mutated. * That's it. (If other things that affect the style change, but they still don't result in having a non-overflowing position, oh well.) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10099 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-anchor-position] When to invalidate "last remembered position-try option"? == Currently, we're just using essentially the same conditions for forgetting "last remembered position-try option" as we do with "last remembered size". But the chosen position-try option depends on more stuff than the size. Notably, what happens if you *change the 'position-try-options' list*? And what happens if the `@position-try` rules are changed? (mutated, or deleted, or we add a new one that was already referred to while not previously existing) And theoretically, other things can change the styles, like, what if the element with a referenced anchor-name changes? Weighing both usability with difficulty, I propose: * We forget the remembered option if the computed value of 'position-try-options' changes * We forget the remembered option if any of the referenced `@position-try` rules are added/removed/mutated. * That's it. (If other things that affect the style change, but they still don't result in having a non-overflowing position, oh well.) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10099 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-anchor-position] When to invalidate "last remembered position-try option"? == Currently, we're just using essentially the same conditions for forgetting "last remembered position-try option" as we do with "last remembered size". But the chosen position-try option depends on more stuff than the size. Notably, what happens if you *change the 'position-try-options' list*? And what happens if the `@position-try` rules are changed? (mutated, or deleted, or we add a new one that was already referred to while not previously existing) And theoretically, other things can change the styles, like, what if the element with a referenced anchor-name changes? Weighing both usability with difficulty, I propose: * We forget the remembered option if the computed value of 'position-try-options' changes * We forget the remembered option if any of the referenced `@position-try` rules are added/removed/mutated. * That's it. (If other things that affect the style change, but they still don't result in having a non-overflowing position, oh well.) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10099 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> Thank you. Then I agree they should not make a space between other ideographs. > > Can they be in a class that does not create space with any characters? If so we can treat them consistently with other symbols in the same way. If not we would need to special case these symbols, but when they are not used as a replacement character the behavior might look odd, i.e. among many similar symbols only these two make space with Latin characters and numbers. In my experience, there is always some pairing that requires some space or requires spacing logic beyond "do nothing". Consider full justification expansion, where your "do nothing" class could get no spacing where all other ideographs get 0-100% spacing before the H&J violation state kicks in. Therefore, I think all glyphs/characters need assignment to a class, and that class should be part of the spacing rules table at all times. -- GitHub Notification of comment by macnmm Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9603#issuecomment-2007478625 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> Thank you. Then I agree they should not make a space between other ideographs. > > Can they be in a class that does not create space with any characters? If so we can treat them consistently with other symbols in the same way. If not we would need to special case these symbols, but when they are not used as a replacement character the behavior might look odd, i.e. among many similar symbols only these two make space with Latin characters and numbers. In my experience, there is always some pairing that requires some space or requires spacing logic beyond "do nothing". Consider full justification expansion, where your "do nothing" class could get no spacing where all other ideographs get 0-100% spacing before the H&J violation state kicks in. Therefore, I think all glyphs/characters need assignment to a class, and that class should be part of the spacing rules table at all times. -- GitHub Notification of comment by macnmm Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9603#issuecomment-2007478625 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == WIP [css-view-transitions-2] A big editorial refactor == Divided the spec to have feature-based sections rather than by type of addition. Added overviews and enhanced intro to introduce all new features. Added mentions for `pageswap`. See https://github.com/w3c/csswg-drafts/pull/10098 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == WIP [css-view-transitions-2] A big editorial refactor == Divided the spec to have feature-based sections rather than by type of addition. Added overviews and enhanced intro to introduce all new features. Added mentions for `pageswap`. See https://github.com/w3c/csswg-drafts/pull/10098 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == WIP [css-view-transitions-2] A big editorial refactor == Divided the spec to have feature-based sections rather than by type of addition. Added overviews and enhanced intro to introduce all new features. Added mentions for `pageswap`. See https://github.com/w3c/csswg-drafts/pull/10098 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == WIP [css-view-transitions-2] A big editorial refactor == Divided the spec to have feature-based sections rather than by type of addition. Added overviews and enhanced intro to introduce all new features. Added mentions for `pageswap`. See https://github.com/w3c/csswg-drafts/pull/10098 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == WIP [css-view-transitions-2] A big editorial refactor == Divided the spec to have feature-based sections rather than by type of addition. Added overviews and enhanced intro to introduce all new features. Added mentions for `pageswap`. See https://github.com/w3c/csswg-drafts/pull/10098 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
As a CSS author, the part of the property name that confused me was the `-items` suffix. `reading-order` is a more understandable alternative. I also vote for `reading-order` over `reading-flow` because we usually discuss "DOM order" (not "DOM flow") versus "Visual display order" (not "visual display flow"), and the visual order is changed using the `order` property, so "reading order" makes sense and is easier to relate back to the former two concepts. -- GitHub Notification of comment by SaraSoueidan Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9921#issuecomment-2006748835 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
As a CSS author, the part of the property name that confused me was the `-items` suffix. `reading-order` is a more understandable alternative. I also vote for `reading-order` over `reading-flow` because we usually discuss "DOM order" (not "DOM flow") versus "Visual display order" (not "visual display flow"), and the visual order is changed using the `order` property, so "reading order" makes sense and is easier to relate back to the former two concepts. -- GitHub Notification of comment by SaraSoueidan Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9921#issuecomment-2006748835 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
As a CSS author, the part of the property name that confused me was the `-items` suffix. `reading-order` is a more understandable alternative. I also vote for `reading-order` over `reading-flow` because we usually discuss "DOM order" (not "DOM flow") versus "Visual display order" (not "visual display flow"), and the visual order is changed using the `order` property, so "reading order" makes sense and is easier to relate back to the former two concepts. -- GitHub Notification of comment by SaraSoueidan Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9921#issuecomment-2006748835 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
As a CSS author, the part of the property name that confused me was the `-items` suffix. `reading-order` is a more understandable alternative. I also vote for `reading-order` over `reading-flow` because we usually discuss "DOM order" (not "DOM flow") versus "Visual display order" (not "visual display flow"), and the visual order is changed using the `order` property, so "reading order" makes sense and is easier to relate back to the former two concepts. -- GitHub Notification of comment by SaraSoueidan Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9921#issuecomment-2006748835 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
wine-fall has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions] Doc: why all source links in the blog can't work ? == The website is: https://developer.chrome.com/docs/web-platform/view-transitions I click this: ![image](https://github.com/w3c/csswg-drafts/assets/62830944/ddb4ae71-8f00-4e59-87f4-b08480cd553e) and with an error: ![image](https://github.com/w3c/csswg-drafts/assets/62830944/a049bd79-65e3-46bf-bb8a-448c32d908a5) All source link in the blog can not work, please check this. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10097 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
astearns closed this issue. See https://github.com/w3c/csswg-drafts/issues/9874 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
astearns closed this issue. See https://github.com/w3c/csswg-drafts/issues/9874 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Right. I believe `:active-view-transition` is meant to cover this case https://github.com/w3c/csswg-drafts/issues/9972#issuecomment-1994889933 (if I am incorrect, please re-open this issue) -- GitHub Notification of comment by astearns Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9874#issuecomment-2005372416 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar has just created a new issue for https://github.com/w3c/csswg-drafts: == FPWD for CSS View Transitions L2 == [CSS View Transitions Module Level 2](https://drafts.csswg.org/css-view-transitions-2/) is ready for FPWD. Filing this issue to do a formal resolution. The level has open issues that still need to be resolved for classes and types but there's no open issues for cross-document transitions. @nt1m @fantasai @emilio any pending cross-document transition issues that you can think of? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10096 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar has just created a new issue for https://github.com/w3c/csswg-drafts: == FPWD for CSS View Transitions L2 == [CSS View Transitions Module Level 2](https://drafts.csswg.org/css-view-transitions-2/) is ready for FPWD. Filing this issue to do a formal resolution. The level has open issues that still need to be resolved for classes and types but there's no open issues for cross-document transitions. @nt1m @fantasai @emilio any pending cross-document transition issues that you can think of? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10096 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I'm ok with making this read only given the recent resolution to add mutable types to the VT object: https://drafts.csswg.org/css-view-transitions-2/#dom-viewtransition-typelist. The recommended pattern if authors need to set type per navigation would be to use this in `pageswap`/`pagereveal`. -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10011#issuecomment-2005075286 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev closed this issue. See https://github.com/w3c/csswg-drafts/issues/6425 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev closed this issue. See https://github.com/w3c/csswg-drafts/issues/6425 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev closed this issue. See https://github.com/w3c/csswg-drafts/issues/6425 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev closed this issue. See https://github.com/w3c/csswg-drafts/issues/6425 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev closed this issue. See https://github.com/w3c/csswg-drafts/issues/6425 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev closed this issue. See https://github.com/w3c/csswg-drafts/issues/6425 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev closed this issue. See https://github.com/w3c/csswg-drafts/issues/6425 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev closed this issue. See https://github.com/w3c/csswg-drafts/issues/6425 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev closed this issue. See https://github.com/w3c/csswg-drafts/issues/6425 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/7338 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I think this can be closed? Spec was editted, tests were added and both Blink and Gecko have already been updated. -- GitHub Notification of comment by romainmenke Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7338#issuecomment-2003766616 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
nicoburns has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-grid] Define item processing order when resolving intrinsic track sizes == This issue pertains to steps 12.5.3 and 12.5.4 from [css-grid-2] specification (11.5.3 and 11.5.4 in [css-grid-1]): - https://www.w3.org/TR/css-grid-2/#algo-spanning-items Step 12.5 imposes some amount of ordering on processing grid items when determining intrinsic track sizes, but some ordering is left undefined. For example, in which order to process items that cross a flexible track. And in which order to to process items that do not cross a flexible track and cross the same number of tracks as each other. The order in which items are processed can / does affect the sizes that the tracks end up (which tracks item sizes are allocated to), so if we wish for css grid to be completely interoperable then the order must be defined. The following is an example I was recently presented with where my implementation in [Taffy](https://github.com/DioxusLabs/taffy) conflicts with that in Chrome and Firefox (which seem to be interoperable with each other in this case): ```html <div style="display: grid; width: 320px; height: 640px; grid-template-columns: auto auto 1fr; grid-template-rows: auto auto auto 1fr; justify-content: start; justify-items: start;"> <div style="background: #59c4f6; width: 100px; height: 50px; grid-row: 1 / span 2; grid-column: 1;"></div> <div style="background: #63c466; width: 40px; height: 30px; grid-row: 1 / span 2; grid-column: 2 / span 2;"></div> <div style="background: #feb43f; width: 120px; height: 20px; grid-row: 3 / span 1; grid-column: 1 / span 2;"></div> </div> ``` When resolving column width, Taffy is processing the 3rd item before the 2nd item on the basis that is further to the left in the grid (which causes column widths of [110px, 10px, 200px]). Based on the column sizes it is producing ([100px, 20px, 200px]), Chrome is presumably processing the 2nd item before the 3rd item. Swapping the items in the source code doesn't change this, so it is not source order that Chrome is processing items. I am guessing that it is may be processing items in [grid order](https://www.w3.org/TR/css-grid-2/#grid-order). As far as I can tell neither implementation violates the spec, but they nevertheless end up with different results. And I am hoping that we can tighten up the spec to prevent this. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10095 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
nicoburns has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-grid] Define item processing order when resolving intrinsic track sizes == This issue pertains to steps 12.5.3 and 12.5.4 from [css-grid-2] specification (11.5.3 and 11.5.4 in [css-grid-1]): - https://www.w3.org/TR/css-grid-2/#algo-spanning-items Step 12.5 imposes some amount of ordering on processing grid items when determining intrinsic track sizes, but some ordering is left undefined. For example, in which order to process items that cross a flexible track. And in which order to to process items that do not cross a flexible track and cross the same number of tracks as each other. The order in which items are processed can / does affect the sizes that the tracks end up (which tracks item sizes are allocated to), so if we wish for css grid to be completely interoperable then the order must be defined. The following is an example I was recently presented with where my implementation in [Taffy](https://github.com/DioxusLabs/taffy) conflicts with that in Chrome and Firefox (which seem to be interoperable with each other in this case): ```html <div style="display: grid; width: 320px; height: 640px; grid-template-columns: auto auto 1fr; grid-template-rows: auto auto auto 1fr; justify-content: start; justify-items: start;"> <div style="background: #59c4f6; width: 100px; height: 50px; grid-row: 1 / span 2; grid-column: 1;"></div> <div style="background: #63c466; width: 40px; height: 30px; grid-row: 1 / span 2; grid-column: 2 / span 2;"></div> <div style="background: #feb43f; width: 120px; height: 20px; grid-row: 3 / span 1; grid-column: 1 / span 2;"></div> </div> ``` When resolving column width, Taffy is processing the 3rd item before the 2nd item on the basis that is further to the left in the grid (which causes column widths of [110px, 10px, 200px]). Based on the column sizes it is producing ([100px, 20px, 200px]), Chrome is presumably processing the 2nd item before the 3rd item. Swapping the items in the source code doesn't change this, so it is not source order that Chrome is processing items. I am guessing that it is may be processing items in [grid order](https://www.w3.org/TR/css-grid-2/#grid-order). As far as I can tell neither implementation violates the spec, but they nevertheless end up with different results. And I am hoping that we can tighten up the spec to prevent this. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10095 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
nicoburns has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-grid] Define item processing order when resolving intrinsic track sizes == This issue pertains to steps 12.5.3 and 12.5.4 from [css-grid-2] specification (11.5.3 and 11.5.4 in [css-grid-1]): - https://www.w3.org/TR/css-grid-2/#algo-spanning-items Step 12.5 imposes some amount of ordering on processing grid items when determining intrinsic track sizes, but some ordering is left undefined. For example, in which order to process items that cross a flexible track. And in which order to to process items that do not cross a flexible track and cross the same number of tracks as each other. The order in which items are processed can / does affect the sizes that the tracks end up (which tracks item sizes are allocated to), so if we wish for css grid to be completely interoperable then the order must be defined. The following is an example I was recently presented with where my implementation in [Taffy](https://github.com/DioxusLabs/taffy) conflicts with that in Chrome and Firefox (which seem to be interoperable with each other in this case): ```html <div style="display: grid; width: 320px; height: 640px; grid-template-columns: auto auto 1fr; grid-template-rows: auto auto auto 1fr; justify-content: start; justify-items: start;"> <div style="background: #59c4f6; width: 100px; height: 50px; grid-row: 1 / span 2; grid-column: 1;"></div> <div style="background: #63c466; width: 40px; height: 30px; grid-row: 1 / span 2; grid-column: 2 / span 2;"></div> <div style="background: #feb43f; width: 120px; height: 20px; grid-row: 3 / span 1; grid-column: 1 / span 2;"></div> </div> ``` When resolving column width, Taffy is processing the 3rd item before the 2nd item on the basis that is further to the left in the grid (which causes column widths of [110px, 10px, 200px]). Based on the column sizes it is producing ([100px, 20px, 200px]), Chrome is presumably processing the 2nd item before the 3rd item. Swapping the items in the source code doesn't change this, so it is not source order that Chrome is processing items. I am guessing that it is may be processing items in [grid order](https://www.w3.org/TR/css-grid-2/#grid-order). As far as I can tell neither implementation violates the spec, but they nevertheless end up with different results. And I am hoping that we can tighten up the spec to prevent this. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10095 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Hello same here when you have an element with `position: fixed` the property `scrollbar-gutter: stable` doesn't work -- GitHub Notification of comment by TheElegantCoding Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5232#issuecomment-2002606332 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Hello same here when you have an element with `position: fixed` the property `scrollbar-gutter: stable` doesn't work -- GitHub Notification of comment by TheElegantCoding Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5232#issuecomment-2002606332 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Hello same here when you have an element with `position: fixed` the property `scrollbar-gutter: stable` doesn't work -- GitHub Notification of comment by TheElegantCoding Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5232#issuecomment-2002606332 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Hello same here when you have an element with `position: fixed` the property `scrollbar-gutter: stable` doesn't work -- GitHub Notification of comment by TheElegantCoding Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5232#issuecomment-2002606332 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Hello same here when you have an element with `position: fixed` the property `scrollbar-gutter: stable` doesn't work -- GitHub Notification of comment by TheElegantCoding Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5232#issuecomment-2002606332 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Hello same here when you have an element with `position: fixed` the property `scrollbar-gutter: stable` doesn't work -- GitHub Notification of comment by TheElegantCoding Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5232#issuecomment-2002606332 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Some assorted thoughts: The primary use case cited is for adopting `document.styleSheets`, but this will also enable adopting stylesheets from a parent shadow-root (which is equally useful!) ```js const parentRoot = el.shadowRoot.host.getRootNode(); el.shadowRoot.adoptedStyleSheets.push( ...parentRoot.styleSheets, ...parentRoot.adoptedStyleSheets, ); ``` --- I think there is (or should be) a difference between "constructed" stylesheets and "adoptable" stylesheets. The `@import` restriction could continue to apply to *constructed* stylesheets, but does not need to apply to other adoptable stylesheets. --- Should there be an easier way to feature detect? Currently I can see a `try`/`catch` way of polyfilling. ```js function requiresConstructing() { try { const doc = document.implementation.createHTMLDocument(); doc.body.appendChild(doc.createElement("style"); doc.adoptedStyleSheets = doc.styleSheets; return false; } catch { return true; } } ``` ```js el.shadowRoot.adoptedStyleSheets.push( ...constructIfNecessary(document.styleSheets), ...document.adoptedStyleSheets, ); function constructIfNecessary(styleSheets) { if (!requiresConstructing()) return styleSheets; return Array.from(styleSheets).map(styleSheet => { const sheet = new CSSStyleSheet(); sheet.replace(stringifyStyleSheet(styleSheet)); return sheet; }); } ``` (using `stringifyStyleSheet` helper from #7171) --- Should there be a way to adopt stylesheets not just once, but "forever"? If I understand correctly, `adoptedStyleSheets.push(...document.styleSheets)` is taking a snapshot of `document.styleSheets` at the time it's called. `styleSheets` could change in the future, and it's probably desirable to propagate those changes into wherever they are adopted. -- GitHub Notification of comment by mayank99 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10013#issuecomment-2002269431 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Some assorted thoughts: The primary use case cited is for adopting `document.styleSheets`, but this will also enable adopting stylesheets from a parent shadow-root (which is equally useful!) ```js const parentRoot = el.shadowRoot.host.getRootNode(); el.shadowRoot.adoptedStyleSheets.push( ...parentRoot.styleSheets, ...parentRoot.adoptedStyleSheets, ); ``` --- I think there is (or should be) a difference between "constructed" stylesheets and "adoptable" stylesheets. The `@import` restriction could continue to apply to *constructed* stylesheets, but does not need to apply to other adoptable stylesheets. --- Should there be an easier way to feature detect? Currently I can see a `try`/`catch` way of polyfilling. ```js function requiresConstructing() { try { const doc = document.implementation.createHTMLDocument(); doc.body.appendChild(doc.createElement("style"); doc.adoptedStyleSheets = doc.styleSheets; return false; } catch { return true; } } ``` ```js el.shadowRoot.adoptedStyleSheets.push( ...constructIfNecessary(document.styleSheets), ...document.adoptedStyleSheets, ); function constructIfNecessary(styleSheets) { if (!requiresConstructing()) return styleSheets; return Array.from(styleSheets).map(styleSheet => { const sheet = new CSSStyleSheet(); sheet.replace(stringifyStyleSheet(styleSheet)); return sheet; }); } ``` (using `stringifyStyleSheet` helper from #7171) --- Should there be a way to adopt stylesheets not just once, but "forever"? If I understand correctly, `adoptedStyleSheets.push(...document.styleSheets)` is taking a snapshot of `document.styleSheets` at the time it's called. `styleSheets` could change in the future, and it's probably desirable to propagate those changes into wherever they are adopted. -- GitHub Notification of comment by mayank99 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10013#issuecomment-2002269431 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Some assorted thoughts: The primary use case cited is for adopting `document.styleSheets`, but this will also enable adopting stylesheets from a parent shadow-root (which is equally useful!) ```js const parentRoot = el.shadowRoot.host.getRootNode(); el.shadowRoot.adoptedStyleSheets.push( ...parentRoot.styleSheets, ...parentRoot.adoptedStyleSheets, ); ``` --- I think there is (or should be) a difference between "constructed" stylesheets and "adoptable" stylesheets. The `@import` restriction could continue to apply to *constructed* stylesheets, but does not need to apply to other adoptable stylesheets. --- Should there be an easier way to feature detect? Currently I can see a `try`/`catch` way of polyfilling. ```js function requiresConstructing() { try { const doc = document.implementation.createHTMLDocument(); doc.body.appendChild(doc.createElement("style"); doc.adoptedStyleSheets = doc.styleSheets; return false; } catch { return true; } } ``` ```js el.shadowRoot.adoptedStyleSheets.push( ...constructIfNecessary(document.styleSheets), ...document.adoptedStyleSheets, ); function constructIfNecessary(styleSheets) { if (!requiresConstructing()) return styleSheets; return Array.from(styleSheets).map(styleSheet => { const sheet = new CSSStyleSheet(); sheet.replace(stringifyStyleSheet(styleSheet)); return sheet; }); } ``` (using `stringifyStyleSheet` helper from #7171) --- Should there be a way to adopt stylesheets not just once, but "forever"? If I understand correctly, `adoptedStyleSheets.push(...document.styleSheets)` is taking a snapshot of `document.styleSheets` at the time it's called. `styleSheets` could change in the future, and it's probably desirable to propagate those changes into wherever they are adopted. -- GitHub Notification of comment by mayank99 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10013#issuecomment-2002269431 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Some assorted thoughts: The primary use case cited is for adopting `document.styleSheets`, but this will also enable adopting stylesheets from a parent shadow-root (which is equally useful!) ```js const parentRoot = el.shadowRoot.host.getRootNode(); el.shadowRoot.adoptedStyleSheets.push( ...parentRoot.styleSheets, ...parentRoot.adoptedStyleSheets, ); ``` --- I think there is (or should be) a difference between "constructed" stylesheets and "adoptable" stylesheets. The `@import` restriction could continue to apply to *constructed* stylesheets, but does not need to apply to other adoptable stylesheets. --- Should there be an easier way to feature detect? Currently I can see a `try`/`catch` way of polyfilling. ```js function requiresConstructing() { try { const doc = document.implementation.createHTMLDocument(); doc.body.appendChild(doc.createElement("style"); doc.adoptedStyleSheets = doc.styleSheets; return false; } catch { return true; } } ``` ```js el.shadowRoot.adoptedStyleSheets.push( ...constructIfNecessary(document.styleSheets), ...document.adoptedStyleSheets, ); function constructIfNecessary(styleSheets) { if (!requiresConstructing()) return styleSheets; return Array.from(styleSheets).map(styleSheet => { const sheet = new CSSStyleSheet(); sheet.replace(stringifyStyleSheet(styleSheet)); return sheet; }); } ``` (using `stringifyStyleSheet` helper from #7171) --- Should there be a way to adopt stylesheets not just once, but "forever"? If I understand correctly, `adoptedStyleSheets.push(...document.styleSheets)` is taking a snapshot of `document.styleSheets` at the time it's called. `styleSheets` could change in the future, and it's probably desirable to propagate those changes into wherever they are adopted. -- GitHub Notification of comment by mayank99 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10013#issuecomment-2002269431 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Some assorted thoughts: The primary use case cited is for adopting `document.styleSheets`, but this will also enable adopting stylesheets from a parent shadow-root (which is equally useful!) ```js const parentRoot = el.shadowRoot.host.getRootNode(); el.shadowRoot.adoptedStyleSheets.push( ...parentRoot.styleSheets, ...parentRoot.adoptedStyleSheets, ); ``` --- I think there is (or should be) a difference between "constructed" stylesheets and "adoptable" stylesheets. The `@import` restriction could continue to apply to *constructed* stylesheets, but does not need to apply to other adoptable stylesheets. --- Should there be an easier way to feature detect? Currently I can see a `try`/`catch` way of polyfilling. ```js function requiresConstructing() { try { const doc = document.implementation.createHTMLDocument(); doc.body.appendChild(doc.createElement("style"); doc.adoptedStyleSheets = doc.styleSheets; return false; } catch { return true; } } ``` ```js el.shadowRoot.adoptedStyleSheets.push( ...constructIfNecessary(document.styleSheets), ...document.adoptedStyleSheets, ); function constructIfNecessary(styleSheets) { if (!requiresConstructing()) return styleSheets; return Array.from(styleSheets).map(styleSheet => { const sheet = new CSSStyleSheet(); sheet.replace(stringifyStyleSheet(styleSheet)); return sheet; }); } ``` (using `stringifyStyleSheet` helper from #7171) --- Should there be a way to adopt stylesheets not just once, but "forever"? If I understand correctly, `adoptedStyleSheets.push(...document.styleSheets)` is taking a snapshot of `document.styleSheets` at the time it's called. `styleSheets` could change in the future, and it's probably desirable to propagate those changes into wherever they are adopted. -- GitHub Notification of comment by mayank99 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10013#issuecomment-2002269431 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mayank99 has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-cascade] Proposal: `@layer initial` always being the first layer == ## Problem Currently, layers all need to be explicitly defined. This means the page author needs to be very disciplined in setting their layer order upfront, before adding any “real” styles. This almost always involves creating a layer named something like “defaults” early on. ```html <head> <style> @layer defaults, components, utilities; </style> <link rel=“stylesheet” href=“styles.css” /> </head> ``` This works, but is problematic for a few reasons: - If this layer order is not set upfront, then any styles that come before `@layer defaults` can potentially declare layers that come first. - It requires everyone to be aware of the name `defaults` if they want to declare low-priority styles later. - It hinders the adoption of libraries that want to use cascade layers, because they need to instruct page authors to set up layer order correctly. - Every shadow-root needs to come up with its own `defaults` layer. - See [default stylesheets proposal](https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Default-Stylesheets-Concept-and-Proposal.md) from almost a decade ago. ## Proposal Allow authors to declare all low-priority styles in a layer named `initial`. ```css @layer initial { *, ::before, ::after { box-sizing: border-box; margin: 0; } } ``` `initial` is one of the layer names that are ["reserved for future use"](https://www.w3.org/TR/css-cascade-5/#layer-names), so this layer can be automatically set up by the browser, such that: 1. It is *always* the first layer that comes before all other . - It is always the first within a context (e.g. shadow context vs host context vs document context). 2. It always exists automatically, i.e. it doesn’t need to be explicitly created. - This means `@layer initial` exists implicitly, regardless of the page’s layer order, similar to the implicit “outer” (unlayered) layer. ```css @layer A, B; @layer initial { /* this will cascade before A and B */ } ``` ### Polyfill In my testing, I found that the three major browsers do not do anything special to the “reserved” layer names, even though the spec says these must be invalid at parse time. I initially thought this was a bug and/or maybe the spec should be changed (see #10067), but then I realized that the current browser behavior makes this feature somewhat easy to polyfill, by setting `@layer initial;` as the very first style. This could even be done automatically by frameworks. ```html <head> <style>@layer initial;</style> … </head> ``` ## Use cases This solves all of the problems described above, and makes cascade layers easier to incorporate into existing workflows. - Page authors and component authors alike can easily add styles to the initial layer, without having to come up with a carefully-coordinated layer setup. - CSS “resets” (such as [“CSS remedy”](https://github.com/jensimmons/cssremedy)) can be distributed with all styles pre-wrapped in `@layer initial`, with a guarantee that they will come first. - Component library authors can use CSS layers more liberally, without having to worry about third-party resets potentially being in higher-priority layer. - Page authors may not even need to care about a component library’s CSS internally using cascade layers. - Outer context styles that are [adopted](https://developer.mozilla.org/en-US/docs/Web/API/Document/adoptedStyleSheets) into an inner context can use `@layer initial` for their default styles, even though `.adoptedStyleSheets` is ordered after the inner context’s own `.styleSheets`. - This is particularly important for [open-styleable shadow roots](https://redirect.github.com/WICG/webcomponents/issues/909), where document stylesheets *may* be ordered after shadow-root’s styles. `@layer initial` will provide a canonical way to deprioritize certain styles without being impacted by order of appearance or existing layer order. ## Open questions Should `initial` also be implicitly set up for nested sub-layers? ```css @layer foo { @layer A, B; @layer initial { /* comes before foo.A and foo.B */ } } ``` Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10094 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@tabatkins @fantasai @LeaVerou -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10075#issuecomment-2002111596 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I think a scope _statement_ would be useful too? It would be similar to a layer statement. Create a named scope using a scope statement: ```css @scope foo (.start) to (.end); ``` Then use it without specifying `<scope-start>`/`<scope-end>`: ```css @scope foo { p { color: red; } } ``` -- GitHub Notification of comment by mayank99 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9742#issuecomment-2002084564 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mayank99 has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-cascade-6] grouping multiple scopes == Currently there is no way to apply a set of rules to multiple scopes without duplication. `<scope-start>` and `<scope-end>` can be forgiving selector lists, but they create a single scope. It would be useful to create multiple scopes at the same time. For example: ```css @scope (.scope1) to (.scope-1-end), (.scope2-start) to (.scope2-end), (.scope3) { p { color: hotpink; } } ``` roughly equivalent to: ```css @scope (.scope1) to (.scope-1-end) { p { color: hotpink; } } @scope (.scope2-start) to (.scope2-end) { p { color: hotpink; } } @scope (.scope3) { p { color: hotpink; } } ``` The main benefit is avoiding duplication (which is tedious and error-prone). There may also be another benefit around avoiding cascade conflicts/ambiguity, which will be resolved solely through scope proximity. I'd imagine there would need to be a concept of "nearest active scope" within a group of scopes. --- This would play nicely with some other existing proposals, namely [named scopes](https://github.com/w3c/csswg-drafts/issues/9742) and [stylesheet conditions](https://github.com/w3c/csswg-drafts/issues/9427). Additionally, if there is ever a way to set scopes when importing stylesheets (in HTML or CSS), this would work there too. For example: ```css @import "foo.css" scope((.scope1) to (.scope-1-end), (.scope2-start) to (.scope2-end), (.scope3)); ``` ```css /* foo.css */ p { color: red; } ``` Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10093 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/646 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/9805 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I think this fairly uncontentious. Proposal: Have both `:active-view-transition` and `:active-view-transition-type(param)` be 1-class like specificity regardless of `param` -- GitHub Notification of comment by vmpstr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10071#issuecomment-2000429663 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I think this fairly uncontentious. Proposal: Have both `:active-view-transition` and `:active-view-transition-type(param)` be 1-class like specificity regardless of `param` -- GitHub Notification of comment by vmpstr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10071#issuecomment-2000429663 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Added in [ed383b5](https://github.com/w3c/csswg-drafts/commit/ed383b552d3c977ad18116d8038c73d2c997f5a3), happy for review. -- GitHub Notification of comment by mirisuzanne Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8088#issuecomment-2000217307 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Added in [ed383b5](https://github.com/w3c/csswg-drafts/commit/ed383b552d3c977ad18116d8038c73d2c997f5a3), happy for review. -- GitHub Notification of comment by mirisuzanne Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8088#issuecomment-2000217307 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Added in [ed383b5](https://github.com/w3c/csswg-drafts/commit/ed383b552d3c977ad18116d8038c73d2c997f5a3), happy for review. -- GitHub Notification of comment by mirisuzanne Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8088#issuecomment-2000217307 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Added in [ed383b5](https://github.com/w3c/csswg-drafts/commit/ed383b552d3c977ad18116d8038c73d2c997f5a3), happy for review. -- GitHub Notification of comment by mirisuzanne Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8088#issuecomment-2000217307 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Added in [ed383b5](https://github.com/w3c/csswg-drafts/commit/ed383b552d3c977ad18116d8038c73d2c997f5a3), happy for review. -- GitHub Notification of comment by mirisuzanne Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8088#issuecomment-2000217307 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Added in [ed383b5](https://github.com/w3c/csswg-drafts/commit/ed383b552d3c977ad18116d8038c73d2c997f5a3), happy for review. -- GitHub Notification of comment by mirisuzanne Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8088#issuecomment-2000217307 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Added in [ed383b5](https://github.com/w3c/csswg-drafts/commit/ed383b552d3c977ad18116d8038c73d2c997f5a3), happy for review. -- GitHub Notification of comment by mirisuzanne Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8088#issuecomment-2000217307 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Added in [ed383b5](https://github.com/w3c/csswg-drafts/commit/ed383b552d3c977ad18116d8038c73d2c997f5a3), happy for review. -- GitHub Notification of comment by mirisuzanne Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8088#issuecomment-2000217307 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mirisuzanne closed this issue. See https://github.com/w3c/csswg-drafts/issues/8088 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
LeaVerou has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-images-4] Allow gradients with a single color stop and 0-1 positions == This came up in https://github.com/w3c/csswg-drafts/pull/10077 but I’m opening a new issue since I proposed a different path but then the change qualifies as substantive. So currently, CSS Images 4 has prose and grammar that disallows single color stop gradients. However, all UAs have implemented a syntax that allows a gradient with a single color stop as long as it has two positions, e.g. `linear-gradient(red 0% 100%)`. What purpose does this restriction serve? You get a single color *anyway* and the positions are meaningless, they could be anything at all and as long as they parse, they produce the same result. E.g. `linear-gradient(red 50% 50%)`, `linear-gradient(red -100% -200%)`, `linear-gradient(red 50% 50%)`, `linear-gradient(red 300% 1000%)` all produce the same result. So what's the harm in simply allowing a single color stop, even if it has one position — or even none? You get a single color anyway! The benefits of that are small, but not inconsequential: - Smoother authoring experience for editors offering realtime updates (earlier visual feedback). - Less verbosity, - Clearer intent (the current syntax is misleading, because the numbers don't actually *do* anything). - It means that color stops can be independently valid or invalid, they don't depend on the presence of other color stops, which means they can be manipulated more easily in script - We don’t have to introduce warts in the grammar like [a special token for color stops with exactly two positions](https://github.com/w3c/csswg-drafts/pull/10077/files#diff-994978825958ad4d2d852734a8d7d222a30c4bb14402ef0bb98905805bd763a3R1841). - While the restriction is implemented, so adopting that would involve less eng effort, dropping the restriction *is* actually easier to implement so it would allow UAs to clean up their implementations. The [only argument against this](https://github.com/w3c/csswg-drafts/pull/10077#issuecomment-1998556669) is that implementations seem to agree on the current state (of requiring two stops) so we may as well adopt that in the spec. However, given the spec *already* differs from implementations, I see no harm in changing it in a way that makes it *more* permissive than implementations. Having it be *less* permissive (the current situation) is a much bigger issue. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10092 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
LeaVerou has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-images-4] Allow gradients with a single color stop and 0-1 positions == This came up in https://github.com/w3c/csswg-drafts/pull/10077 but I’m opening a new issue since I proposed a different path but then the change qualifies as substantive. So currently, CSS Images 4 has prose and grammar that disallows single color stop gradients. However, all UAs have implemented a syntax that allows a gradient with a single color stop as long as it has two positions, e.g. `linear-gradient(red 0% 100%)`. What purpose does this restriction serve? You get a single color *anyway* and the positions are meaningless, they could be anything at all and as long as they parse, they produce the same result. E.g. `linear-gradient(red 50% 50%)`, `linear-gradient(red -100% -200%)`, `linear-gradient(red 50% 50%)`, `linear-gradient(red 300% 1000%)` all produce the same result. So what's the harm in simply allowing a single color stop, even if it has one position — or even none? You get a single color anyway! The benefits of that are small, but not inconsequential: - Smoother authoring experience for editors offering realtime updates (earlier visual feedback). - Less verbosity, - Clearer intent (the current syntax is misleading, because the numbers don't actually *do* anything). - It means that color stops can be independently valid or invalid, they don't depend on the presence of other color stops, which means they can be manipulated more easily in script - We don’t have to introduce warts in the grammar like [a special token for color stops with exactly two positions](https://github.com/w3c/csswg-drafts/pull/10077/files#diff-994978825958ad4d2d852734a8d7d222a30c4bb14402ef0bb98905805bd763a3R1841). - While the restriction is implemented, so adopting that would involve less eng effort, dropping the restriction *is* actually easier to implement so it would allow UAs to clean up their implementations. The [only argument against this](https://github.com/w3c/csswg-drafts/pull/10077#issuecomment-1998556669) is that implementations seem to agree on the current state (of requiring two stops) so we may as well adopt that in the spec. However, given the spec *already* differs from implementations, I see no harm in changing it in a way that makes it *more* permissive than implementations. Having it be *less* permissive (the current situation) is a much bigger issue. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10092 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
LeaVerou has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-images-4] Allow gradients with a single color stop and 0-1 positions == This came up in https://github.com/w3c/csswg-drafts/pull/10077 but I’m opening a new issue since I proposed a different path but then the change qualifies as substantive. So currently, CSS Images 4 has prose and grammar that disallows single color stop gradients. However, all UAs have implemented a syntax that allows a gradient with a single color stop as long as it has two positions, e.g. `linear-gradient(red 0% 100%)`. What purpose does this restriction serve? You get a single color *anyway* and the positions are meaningless, they could be anything at all and as long as they parse, they produce the same result. E.g. `linear-gradient(red 50% 50%)`, `linear-gradient(red -100% -200%)`, `linear-gradient(red 50% 50%)`, `linear-gradient(red 300% 1000%)` all produce the same result. So what's the harm in simply allowing a single color stop, even if it has one position — or even none? You get a single color anyway! The benefits of that are small, but not inconsequential: - Smoother authoring experience for editors offering realtime updates (earlier visual feedback). - Less verbosity, - Clearer intent (the current syntax is misleading, because the numbers don't actually *do* anything). - It means that color stops can be independently valid or invalid, they don't depend on the presence of other color stops, which means they can be manipulated more easily in script - We don’t have to introduce warts in the grammar like [a special token for color stops with exactly two positions](https://github.com/w3c/csswg-drafts/pull/10077/files#diff-994978825958ad4d2d852734a8d7d222a30c4bb14402ef0bb98905805bd763a3R1841). - While the restriction is implemented, so adopting that would involve less eng effort, dropping the restriction *is* actually easier to implement so it would allow UAs to clean up their implementations. The [only argument against this](https://github.com/w3c/csswg-drafts/pull/10077#issuecomment-1998556669) is that implementations seem to agree on the current state (of requiring two stops) so we may as well adopt that in the spec. However, given the spec *already* differs from implementations, I see no harm in changing it in a way that makes it *more* permissive than implementations. Having it be *less* permissive (the current situation) is a much bigger issue. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10092 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
knowler has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-cascade][css-scoping] Allow layers to use different names in different contexts == ## Background There’s some desire to write “isomorphic stylesheets” that would work for both a document and in shadow roots (https://github.com/WICG/webcomponents/issues/909, https://github.com/WICG/webcomponents/issues/986). This can be problematic, especially with layers since they are often context-specific conventions. Requiring a consumer of a web component to use the same layer names is problematic (it makes the component hard to use), just as expecting the author of a web component to know what layers a consumer is using (enforcing a layering convention on consumers seems unreasonable). This proposal isn’t focused on how external styles can _access_ a shadow root, but rather seeks to improve the adaptability of layering when styles are used in different contexts. ## Syntax The proposed syntax would extend the existing layering syntax: ```css /* As a layer statement rule (useful when sharing entire stylesheets) */ @layer defaults as (reset in one-element, base in another-element), components as (elements in one-element, blocks in another-element); /* As a layer block rule (useful when applying a subset of styles to another context) */ @layer defaults as (reset in one-element, base in another-element) { } ``` The syntax structure would be: ```css @layer <layer-name> as (<inner-context-layer-name> in <selector-with-inner-context>) ``` The selector would effectively match with `:host()`, e.g. if `:host(another-element)` use `base` as the layer name. If no layer name for a specific inner context is given, the original layer name would be used. If a context has already established its layering order, when subsequent layer statement rules appear with contextual layer names, those layer names become associated with the corresponding names in the existing order (they do not modify the order). ## Use cases Ideally, this proposal would be complementary to an happy-path way to apply external styles to a shadow root either as a whole or in part. Even without that happy-path, I do believe it can be useful for web component authors who already are supporting ways to inject external styles into their shadow roots. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10091 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
knowler has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-cascade][css-scoping] Allow layers to use different names in different contexts == ## Background There’s some desire to write “isomorphic stylesheets” that would work for both a document and in shadow roots (https://github.com/WICG/webcomponents/issues/909, https://github.com/WICG/webcomponents/issues/986). This can be problematic, especially with layers since they are often context-specific conventions. Requiring a consumer of a web component to use the same layer names is problematic (it makes the component hard to use), just as expecting the author of a web component to know what layers a consumer is using (enforcing a layering convention on consumers seems unreasonable). This proposal isn’t focused on how external styles can _access_ a shadow root, but rather seeks to improve the adaptability of layering when styles are used in different contexts. ## Syntax The proposed syntax would extend the existing layering syntax: ```css /* As a layer statement rule (useful when sharing entire stylesheets) */ @layer defaults as (reset in one-element, base in another-element), components as (elements in one-element, blocks in another-element); /* As a layer block rule (useful when applying a subset of styles to another context) */ @layer defaults as (reset in one-element, base in another-element) { } ``` The syntax structure would be: ```css @layer <layer-name> as (<inner-context-layer-name> in <selector-with-inner-context>) ``` The selector would effectively match with `:host()`, e.g. if `:host(another-element)` use `base` as the layer name. If no layer name for a specific inner context is given, the original layer name would be used. If a context has already established its layering order, when subsequent layer statement rules appear with contextual layer names, those layer names become associated with the corresponding names in the existing order (they do not modify the order). ## Use cases Ideally, this proposal would be complementary to an happy-path way to apply external styles to a shadow root either as a whole or in part. Even without that happy-path, I do believe it can be useful for web component authors who already are supporting ways to inject external styles into their shadow roots. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10091 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mirisuzanne closed this issue. See https://github.com/w3c/csswg-drafts/issues/10082 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> These functions may, in the future, be extended to accept an `of <selector>` argument, similar to `:nth-child()`, to filter on a subset of the children. If I am not mistaken, these functions are currently the only functions that have no argument value definition. From a theoretical point of view, I do not know if an "empty" value definition matches an empty input but from a pratical point of view, an empty value definition is not great, and it seems more appropriate to define these functions as keywords if they are not intented to accept arguments in the future. -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4559#issuecomment-1999825630 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> These functions may, in the future, be extended to accept an `of <selector>` argument, similar to `:nth-child()`, to filter on a subset of the children. If I am not mistaken, these functions are currently the only functions that have no argument value definition. From a theoretical point of view, I do not know if an "empty" value definition matches an empty input but from a pratical point of view, an empty value definition is not great, and it seems more appropriate to define these functions as keywords if they are not intented to accept arguments in the future. -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4559#issuecomment-1999825630 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> These functions may, in the future, be extended to accept an `of <selector>` argument, similar to `:nth-child()`, to filter on a subset of the children. If I am not mistaken, these functions are currently the only functions that have no argument value definition. From a theoretical point of view, I do not know if an "empty" value definition matches an empty input but from a pratical point of view, an empty value definition is not great, and it seems more appropriate to define these functions as keywords if they are not intented to accept arguments in the future. -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4559#issuecomment-1999825630 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> These functions may, in the future, be extended to accept an `of <selector>` argument, similar to `:nth-child()`, to filter on a subset of the children. If I am not mistaken, these functions are currently the only functions that have no argument value definition. From a theoretical point of view, I do not know if an "empty" value definition matches an empty input but from a pratical point of view, an empty value definition is not great, and it seems more appropriate to define these functions as keywords if they are not intented to accept arguments in the future. -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4559#issuecomment-1999825630 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dbaron has just labeled a pull request from tcaptan-cr for https://github.com/w3c/csswg-drafts as "Closed Accepted as Editorial": == [css-overflow-3] Clarify that scripts can also scroll a scroll container == This clarification was precipitated by an [intersection observer issue](https://github.com/w3c/IntersectionObserver/issues/521) in order to avoid confusion over who can scroll the overflow area of a scroll container. See https://github.com/w3c/csswg-drafts/pull/10048 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dbaron has just labeled a pull request from tcaptan-cr for https://github.com/w3c/csswg-drafts as "Closed Accepted as Editorial": == [css-overflow-3] Clarify that scripts can also scroll a scroll container == This clarification was precipitated by an [intersection observer issue](https://github.com/w3c/IntersectionObserver/issues/521) in order to avoid confusion over who can scroll the overflow area of a scroll container. See https://github.com/w3c/csswg-drafts/pull/10048 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dbaron has just labeled a pull request from tcaptan-cr for https://github.com/w3c/csswg-drafts as "Closed Accepted as Editorial": == [css-overflow-3] Clarify that scripts can also scroll a scroll container == This clarification was precipitated by an [intersection observer issue](https://github.com/w3c/IntersectionObserver/issues/521) in order to avoid confusion over who can scroll the overflow area of a scroll container. See https://github.com/w3c/csswg-drafts/pull/10048 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
birtles has just labeled a pull request from JTensai for https://github.com/w3c/csswg-drafts as "Needs Author Feedback": == [web-animations-1] Add hold phase to animation #4325 == [web-animations-1] Add hold phase to animation #4325 Added the concept of `hold phase` to animations. This will allow them to pass the correct phase to associated effects under such conditions as pausing or any other time the existing `hold time` is used. Added conditions to the animation effect phase calculation to account for animation current phase. See https://github.com/w3c/csswg-drafts/pull/5479 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
frivoal closed this issue. See https://github.com/w3c/csswg-drafts/issues/10068 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
frivoal has just labeled a pull request from SpikyC for https://github.com/w3c/csswg-drafts as "css-animations-1": == [web-animations-1] Fix typo `invaid` → `invalid` == Sorry, but I didn’t open an issue for such a small typographic error. See https://github.com/w3c/csswg-drafts/pull/10090 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
frivoal has just labeled a pull request from SpikyC for https://github.com/w3c/csswg-drafts as "css-animations-1": == [web-animations-1] Fix typo `invaid` → `invalid` == Sorry, but I didn’t open an issue for such a small typographic error. See https://github.com/w3c/csswg-drafts/pull/10090 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
frivoal has just labeled a pull request from SpikyC for https://github.com/w3c/csswg-drafts as "css-animations-1": == [web-animations-1] Fix typo `invaid` → `invalid` == Sorry, but I didn’t open an issue for such a small typographic error. See https://github.com/w3c/csswg-drafts/pull/10090 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
frivoal has just labeled a pull request from SpikyC for https://github.com/w3c/csswg-drafts as "css-animations-1": == [web-animations-1] Fix typo `invaid` → `invalid` == Sorry, but I didn’t open an issue for such a small typographic error. See https://github.com/w3c/csswg-drafts/pull/10090 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
frivoal has just labeled a pull request from SpikyC for https://github.com/w3c/csswg-drafts as "css-animations-1": == [web-animations-1] Fix typo `invaid` → `invalid` == Sorry, but I didn’t open an issue for such a small typographic error. See https://github.com/w3c/csswg-drafts/pull/10090 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
SpikyC has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [web-animations-1] Fix typo `invaid` → `invalid` == Sorry, but I didn’t open an issue for such a small typographic error. See https://github.com/w3c/csswg-drafts/pull/10090 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
SpikyC has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [web-animations-1] Fix typo `invaid` → `invalid` == Sorry, but I didn’t open an issue for such a small typographic error. See https://github.com/w3c/csswg-drafts/pull/10090 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> any thoughts on the intersection of your proposal and the need to not use outside-variable-range values? I'd include that in as part of the behavior of the value that turns off the generation of synthetic oblique. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9390#issuecomment-1998696318 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> any thoughts on the intersection of your proposal and the need to not use outside-variable-range values? I'd include that in as part of the behavior of the value that turns off the generation of synthetic oblique. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9390#issuecomment-1998696318 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> any thoughts on the intersection of your proposal and the need to not use outside-variable-range values? I'd include that in as part of the behavior of the value that turns off the generation of synthetic oblique. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9390#issuecomment-1998696318 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> any thoughts on the intersection of your proposal and the need to not use outside-variable-range values? I'd include that in as part of the behavior of the value that turns off the generation of synthetic oblique. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9390#issuecomment-1998696318 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> any thoughts on the intersection of your proposal and the need to not use outside-variable-range values? I'd include that in as part of the behavior of the value that turns off the generation of synthetic oblique. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9390#issuecomment-1998696318 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@tabatkins I don't see what that has to do with dense packing. Filed as https://github.com/w3c/csswg-drafts/issues/10089 -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9326#issuecomment-1998631423 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@tabatkins I don't see what that has to do with dense packing. Filed as https://github.com/w3c/csswg-drafts/issues/10089 -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9326#issuecomment-1998631423 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-grid-3] "Auto-spanning" based on width of an item == Copying @tabatkins [comment](https://github.com/w3c/csswg-drafts/issues/9326#issuecomment-1710848904): > allow "auto-spanning", where an element will get a span based on its width. This might be a good mode to allow, possibly even with some author control - if an image is >X% of the track width, make it span 2 instead of 1 (or a larger span, as appropriate). Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10089 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai closed this issue. See https://github.com/w3c/csswg-drafts/issues/8206 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-grid-3][masonry] Prioritize tracks that don't create overflow == Pulling out @ethanjv's [comment](https://github.com/w3c/csswg-drafts/issues/8206#issuecomment-1817479266): > Btw we might want to consider that, in the current draft of masonry, having definite tracks mixed with intrinsic tracks might result in some items overflowing the spanning tracks in the grid axis. E.g., if we have a `grid-template-columns: 50px auto` definition, if we have two auto placed items, the first one with a min-content size of `100px` and the other with `50px`, the first will be placed in the first column and overflow it, then the second would be placed in the `auto` track. > > Maybe we want to prioritize placing a grid item in a track that won't overflow? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10088 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-grid-3][masonry] Prioritize tracks that don't create overflow == Pulling out @ethanjv's [comment](https://github.com/w3c/csswg-drafts/issues/8206#issuecomment-1817479266): > Btw we might want to consider that, in the current draft of masonry, having definite tracks mixed with intrinsic tracks might result in some items overflowing the spanning tracks in the grid axis. E.g., if we have a `grid-template-columns: 50px auto` definition, if we have two auto placed items, the first one with a min-content size of `100px` and the other with `50px`, the first will be placed in the first column and overflow it, then the second would be placed in the `auto` track. > > Maybe we want to prioritize placing a grid item in a track that won't overflow? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10088 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai closed this issue. See https://github.com/w3c/csswg-drafts/issues/8966 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/10004 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/10004 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/10004 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/10004 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/10004 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/10004 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/10004 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color] How to handle out-of-bounds legacy srgb values? == Consider this testcase: ```html <!DOCTYPE html> <style> #a { width: 200px; height: 200px; animation: a 2s -1s paused linear(0, -1, 1) } #b { width: 100px; height: 100px; animation: b 2s -1s paused linear } #c { width: 100px; height: 100px; animation: c 2s -1s paused linear } @keyframes a { from { background-color: rgb(75, 0, 0) } to { background-color: rgb(0, 255, 0) } } @keyframes b { from { background-color: inherit } to { background-color: rgb(0, 255, 0) } } @keyframes c { from { background-color: black } to { background-color: rgb(0, 255, 0) } } </style> <div id="a"> <div id="b"></div> <div id="c"></div> </div> <pre><script> document.styleSheets[0].cssRules[5].cssRules[0].style.backgroundColor = getComputedStyle(a).backgroundColor; document.writeln(getComputedStyle(a).backgroundColor); document.writeln(getComputedStyle(b).backgroundColor); document.writeln(getComputedStyle(c).backgroundColor); </script> ``` The background of `#a` is the interpolation between `rgb(75, 0, 0)` and `rgb(0, 255, 0)`. The easing function is `linear(0, -1, 1)`, so at 50% the input progress value is -1. Both colors are legacy, so we interpolate in srgb instead of oklab, producing a color as such: - Color space: srgb - Legacy flag: yes - Red: 150 - Green: -255 - Blue: 0 But of course, `G = -255` is out of bounds, so the painted background is `rgb(150, 0, 0)`. However, on Gecko and Blink, the computed value still has this `G = -255`, as we can observe in `#b`. The background color of `#b` is the 50% linear interpolation between the value inherited from `#a` and `rgb(0, 255, 0)`. This serializes as `rgb(75, 0, 0)`, which means that the inherited value has `G = -255`. The problem is, what do we get if we serialize the computed value of `#a`? Since `G = -255` is out-of-bounds, browsers just clamp and serialize as `rgb(150, 0, 0)`. But of course, when `#c` does the same as `#b`, but interpolating from the provided `rgb(150, 0, 0)`, then it produces `rgb(75, 128, 0)`. WebKit seems to adjust the computed value of `#a`, because `#b` produces `rgb(75, 128, 0)` just like `#c`. So, questions: - Why does `color-mix()` prevent me from picking a percentage outside of the 0-100% range, if I can do the mix with arbitrary values via animations/transitions (but it's much less convenient)? - Should Gecko and Blink adjust the computed value to avoid out-of-bounds problems? - If not, should we change the serialization so that it doesn't become a different color? Maybe serialize with `color-mix()`? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10087 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color] How to handle out-of-bounds legacy srgb values? == Consider this testcase: ```html <!DOCTYPE html> <style> #a { width: 200px; height: 200px; animation: a 2s -1s paused linear(0, -1, 1) } #b { width: 100px; height: 100px; animation: b 2s -1s paused linear } #c { width: 100px; height: 100px; animation: c 2s -1s paused linear } @keyframes a { from { background-color: rgb(75, 0, 0) } to { background-color: rgb(0, 255, 0) } } @keyframes b { from { background-color: inherit } to { background-color: rgb(0, 255, 0) } } @keyframes c { from { background-color: black } to { background-color: rgb(0, 255, 0) } } </style> <div id="a"> <div id="b"></div> <div id="c"></div> </div> <pre><script> document.styleSheets[0].cssRules[5].cssRules[0].style.backgroundColor = getComputedStyle(a).backgroundColor; document.writeln(getComputedStyle(a).backgroundColor); document.writeln(getComputedStyle(b).backgroundColor); document.writeln(getComputedStyle(c).backgroundColor); </script> ``` The background of `#a` is the interpolation between `rgb(75, 0, 0)` and `rgb(0, 255, 0)`. The easing function is `linear(0, -1, 1)`, so at 50% the input progress value is -1. Both colors are legacy, so we interpolate in srgb instead of oklab, producing a color as such: - Color space: srgb - Legacy flag: yes - Red: 150 - Green: -255 - Blue: 0 But of course, `G = -255` is out of bounds, so the painted background is `rgb(150, 0, 0)`. However, on Gecko and Blink, the computed value still has this `G = -255`, as we can observe in `#b`. The background color of `#b` is the 50% linear interpolation between the value inherited from `#a` and `rgb(0, 255, 0)`. This serializes as `rgb(75, 0, 0)`, which means that the inherited value has `G = -255`. The problem is, what do we get if we serialize the computed value of `#a`? Since `G = -255` is out-of-bounds, browsers just clamp and serialize as `rgb(150, 0, 0)`. But of course, when `#c` does the same as `#b`, but interpolating from the provided `rgb(150, 0, 0)`, then it produces `rgb(75, 128, 0)`. WebKit seems to adjust the computed value of `#a`, because `#b` produces `rgb(75, 128, 0)` just like `#c`. So, questions: - Why does `color-mix()` prevent me from picking a percentage outside of the 0-100% range, if I can do the mix with arbitrary values via animations/transitions (but it's much less convenient)? - Should Gecko and Blink adjust the computed value to avoid out-of-bounds problems? - If not, should we change the serialization so that it doesn't become a different color? Maybe serialize with `color-mix()`? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10087 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color] How to handle out-of-bounds legacy srgb values? == Consider this testcase: ```html <!DOCTYPE html> <style> #a { width: 200px; height: 200px; animation: a 2s -1s paused linear(0, -1, 1) } #b { width: 100px; height: 100px; animation: b 2s -1s paused linear } #c { width: 100px; height: 100px; animation: c 2s -1s paused linear } @keyframes a { from { background-color: rgb(75, 0, 0) } to { background-color: rgb(0, 255, 0) } } @keyframes b { from { background-color: inherit } to { background-color: rgb(0, 255, 0) } } @keyframes c { from { background-color: black } to { background-color: rgb(0, 255, 0) } } </style> <div id="a"> <div id="b"></div> <div id="c"></div> </div> <pre><script> document.styleSheets[0].cssRules[5].cssRules[0].style.backgroundColor = getComputedStyle(a).backgroundColor; document.writeln(getComputedStyle(a).backgroundColor); document.writeln(getComputedStyle(b).backgroundColor); document.writeln(getComputedStyle(c).backgroundColor); </script> ``` The background of `#a` is the interpolation between `rgb(75, 0, 0)` and `rgb(0, 255, 0)`. The easing function is `linear(0, -1, 1)`, so at 50% the input progress value is -1. Both colors are legacy, so we interpolate in srgb instead of oklab, producing a color as such: - Color space: srgb - Legacy flag: yes - Red: 150 - Green: -255 - Blue: 0 But of course, `G = -255` is out of bounds, so the painted background is `rgb(150, 0, 0)`. However, on Gecko and Blink, the computed value still has this `G = -255`, as we can observe in `#b`. The background color of `#b` is the 50% linear interpolation between the value inherited from `#a` and `rgb(0, 255, 0)`. This serializes as `rgb(75, 0, 0)`, which means that the inherited value has `G = -255`. The problem is, what do we get if we serialize the computed value of `#a`? Since `G = -255` is out-of-bounds, browsers just clamp and serialize as `rgb(150, 0, 0)`. But of course, when `#c` does the same as `#b`, but interpolating from the provided `rgb(150, 0, 0)`, then it produces `rgb(75, 128, 0)`. WebKit seems to adjust the computed value of `#a`, because `#b` produces `rgb(75, 128, 0)` just like `#c`. So, questions: - Why does `color-mix()` prevent me from picking a percentage outside of the 0-100% range, if I can do the mix with arbitrary values via animations/transitions (but it's much less convenient)? - Should Gecko and Blink adjust the computed value to avoid out-of-bounds problems? - If not, should we change the serialization so that it doesn't become a different color? Maybe serialize with `color-mix()`? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10087 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color] How to handle out-of-bounds legacy srgb values? == Consider this testcase: ```html <!DOCTYPE html> <style> #a { width: 200px; height: 200px; animation: a 2s -1s paused linear(0, -1, 1) } #b { width: 100px; height: 100px; animation: b 2s -1s paused linear } #c { width: 100px; height: 100px; animation: c 2s -1s paused linear } @keyframes a { from { background-color: rgb(75, 0, 0) } to { background-color: rgb(0, 255, 0) } } @keyframes b { from { background-color: inherit } to { background-color: rgb(0, 255, 0) } } @keyframes c { from { background-color: black } to { background-color: rgb(0, 255, 0) } } </style> <div id="a"> <div id="b"></div> <div id="c"></div> </div> <pre><script> document.styleSheets[0].cssRules[5].cssRules[0].style.backgroundColor = getComputedStyle(a).backgroundColor; document.writeln(getComputedStyle(a).backgroundColor); document.writeln(getComputedStyle(b).backgroundColor); document.writeln(getComputedStyle(c).backgroundColor); </script> ``` The background of `#a` is the interpolation between `rgb(75, 0, 0)` and `rgb(0, 255, 0)`. The easing function is `linear(0, -1, 1)`, so at 50% the input progress value is -1. Both colors are legacy, so we interpolate in srgb instead of oklab, producing a color as such: - Color space: srgb - Legacy flag: yes - Red: 150 - Green: -255 - Blue: 0 But of course, `G = -255` is out of bounds, so the painted background is `rgb(150, 0, 0)`. However, on Gecko and Blink, the computed value still has this `G = -255`, as we can observe in `#b`. The background color of `#b` is the 50% linear interpolation between the value inherited from `#a` and `rgb(0, 255, 0)`. This serializes as `rgb(75, 0, 0)`, which means that the inherited value has `G = -255`. The problem is, what do we get if we serialize the computed value of `#a`? Since `G = -255` is out-of-bounds, browsers just clamp and serialize as `rgb(150, 0, 0)`. But of course, when `#c` does the same as `#b`, but interpolating from the provided `rgb(150, 0, 0)`, then it produces `rgb(75, 128, 0)`. WebKit seems to adjust the computed value of `#a`, because `#b` produces `rgb(75, 128, 0)` just like `#c`. So, questions: - Why does `color-mix()` prevent me from picking a percentage outside of the 0-100% range, if I can do the mix with arbitrary values via animations/transitions (but it's much less convenient)? - Should Gecko and Blink adjust the computed value to avoid out-of-bounds problems? - If not, should we change the serialization so that it doesn't become a different color? Maybe serialize with `color-mix()`? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10087 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I'm hoping the CSSWG can resolve on whether to land these PR's, which relate to this issue and also #10066: https://github.com/w3c/csswg-drafts/pull/9823 https://github.com/w3c/csswg-drafts/pull/9842 https://github.com/w3c/csswg-drafts/pull/10085 -- GitHub Notification of comment by szager-chromium Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8649#issuecomment-1998341267 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Hey, thanks for working on this! Long overdue! Here are some tests: https://codepen.io/leaverou/pen/eYodMoj (if anyone can port them to WPT after this is merged, that would be great) And yes, the two position syntax works everywhere. Safari as well, just tested. Looking at the change, it's a little unfortunate we have to define new separate tokens just to make sure that if we have a single color stop it has two positions. And it makes me wonder if we really need that. What purpose does it serve? What's the harm in simply allowing a single color stop, even if it has one position — or even none? You get a single color anyway, and allowing these would provide a smoother authoring experience for editors offering realtime updates. Even with the two color stop positions, you can specify both to be equal, so can't we just spec that a single position expands to that, and no position expands to `0% 100%` or something? cc @tabatkins thoughts? -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/10077#issuecomment-1998324780 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Hey, thanks for working on this! Long overdue! Here are some tests: https://codepen.io/leaverou/pen/eYodMoj (if anyone can port them to WPT after this is merged, that would be great) And yes, the two position syntax works everywhere. Safari as well, just tested. Looking at the change, it's a little unfortunate we have to define new separate tokens just to make sure that if we have a single color stop it has two positions. And it makes me wonder if we really need that. What purpose does it serve? What's the harm in simply allowing a single color stop, even if it has one position — or even none? You get a single color anyway, and allowing these would provide a smoother authoring experience for editors offering realtime updates. Even with the two color stop positions, you can specify both to be equal, so can't we just spec that a single position expands to that, and no position expands to `0% 100%` or something? cc @tabatkins thoughts? -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/10077#issuecomment-1998324780 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> > That one is a list of idents though. It's equivalent to class, it's not a JS array. So I think type is fine for the descriptor. > > The `class` vs `classList` is a good counter for why `type` in CSS is reasonable. But it feels like authors will have an easier time if its the same name everywhere: > > 1. [at-rule](https://drafts.csswg.org/css-view-transitions-2/#view-transition-type-descriptor) > 2. [CSSViewTransitionRule](https://drafts.csswg.org/css-view-transitions-2/#navgation-behavior-rule-interface) > 3. [startViewTransition](https://drafts.csswg.org/css-view-transitions-2/#dictdef-startviewtransitionoptions) > 4. ViewTransition object > > 2. and 4) are already using `typeList`. So could startViewTransition and the at-rule use `typeList` as well. We have to do `typeList` for CSSViewTransitionRule because of [[css-view-transitions-2] `CSSViewTransitionRule.type` overrides deprecated `CSSRule.type` #9905](https://github.com/w3c/csswg-drafts/issues/9905). I think if we do away with (3) (https://github.com/w3c/csswg-drafts/issues/10070#issuecomment-1995165143), having it `type` where we can is equivalent with existing things (class, view-transition-class, font-family, part...). We use `typeList` only because the word `type` is overused and sometimes conflicting (e.g. in `CSSViewTransitionRule`). So I think using `type` in CSS but `typeList` in JS when it's a `DOMTokenList` is consistent enough with current things. But I'm happy to resolve on whatever we reach consensus around. -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10070#issuecomment-1998251585 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> > That one is a list of idents though. It's equivalent to class, it's not a JS array. So I think type is fine for the descriptor. > > The `class` vs `classList` is a good counter for why `type` in CSS is reasonable. But it feels like authors will have an easier time if its the same name everywhere: > > 1. [at-rule](https://drafts.csswg.org/css-view-transitions-2/#view-transition-type-descriptor) > 2. [CSSViewTransitionRule](https://drafts.csswg.org/css-view-transitions-2/#navgation-behavior-rule-interface) > 3. [startViewTransition](https://drafts.csswg.org/css-view-transitions-2/#dictdef-startviewtransitionoptions) > 4. ViewTransition object > > 2. and 4) are already using `typeList`. So could startViewTransition and the at-rule use `typeList` as well. We have to do `typeList` for CSSViewTransitionRule because of [[css-view-transitions-2] `CSSViewTransitionRule.type` overrides deprecated `CSSRule.type` #9905](https://github.com/w3c/csswg-drafts/issues/9905). I think if we do away with (3) (https://github.com/w3c/csswg-drafts/issues/10070#issuecomment-1995165143), having it `type` where we can is equivalent with existing things (class, view-transition-class, font-family, part...). We use `typeList` only because the word `type` is overused and sometimes conflicting (e.g. in `CSSViewTransitionRule`). So I think using `type` in CSS but `typeList` in JS when it's a `DOMTokenList` is consistent enough with current things. But I'm happy to resolve on whatever we reach consensus around. -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10070#issuecomment-1998251585 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> > That one is a list of idents though. It's equivalent to class, it's not a JS array. So I think type is fine for the descriptor. > > The `class` vs `classList` is a good counter for why `type` in CSS is reasonable. But it feels like authors will have an easier time if its the same name everywhere: > > 1. [at-rule](https://drafts.csswg.org/css-view-transitions-2/#view-transition-type-descriptor) > 2. [CSSViewTransitionRule](https://drafts.csswg.org/css-view-transitions-2/#navgation-behavior-rule-interface) > 3. [startViewTransition](https://drafts.csswg.org/css-view-transitions-2/#dictdef-startviewtransitionoptions) > 4. ViewTransition object > > 2. and 4) are already using `typeList`. So could startViewTransition and the at-rule use `typeList` as well. We have to do `typeList` for CSSViewTransitionRule because of [[css-view-transitions-2] `CSSViewTransitionRule.type` overrides deprecated `CSSRule.type` #9905](https://github.com/w3c/csswg-drafts/issues/9905). I think if we do away with (3) (https://github.com/w3c/csswg-drafts/issues/10070#issuecomment-1995165143), having it `type` where we can is equivalent with existing things (class, view-transition-class, font-family, part...). We use `typeList` only because the word `type` is overused and sometimes conflicting (e.g. in `CSSViewTransitionRule`). So I think using `type` in CSS but `typeList` in JS when it's a `DOMTokenList` is consistent enough with current things. But I'm happy to resolve on whatever we reach consensus around. -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10070#issuecomment-1998251585 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> > That one is a list of idents though. It's equivalent to class, it's not a JS array. So I think type is fine for the descriptor. > > The `class` vs `classList` is a good counter for why `type` in CSS is reasonable. But it feels like authors will have an easier time if its the same name everywhere: > > 1. [at-rule](https://drafts.csswg.org/css-view-transitions-2/#view-transition-type-descriptor) > 2. [CSSViewTransitionRule](https://drafts.csswg.org/css-view-transitions-2/#navgation-behavior-rule-interface) > 3. [startViewTransition](https://drafts.csswg.org/css-view-transitions-2/#dictdef-startviewtransitionoptions) > 4. ViewTransition object > > 2. and 4) are already using `typeList`. So could startViewTransition and the at-rule use `typeList` as well. We have to do `typeList` for CSSViewTransitionRule because of [[css-view-transitions-2] `CSSViewTransitionRule.type` overrides deprecated `CSSRule.type` #9905](https://github.com/w3c/csswg-drafts/issues/9905). I think if we do away with (3) (https://github.com/w3c/csswg-drafts/issues/10070#issuecomment-1995165143), having it `type` where we can is equivalent with existing things (class, view-transition-class, font-family, part...). We use `typeList` only because the word `type` is overused and sometimes conflicting (e.g. in `CSSViewTransitionRule`). So I think using `type` in CSS but `typeList` in JS when it's a `DOMTokenList` is consistent enough with current things. But I'm happy to resolve on whatever we reach consensus around. -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10070#issuecomment-1998251585 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Sorry, I missed that the first time around. No need for an async resolution on this, let’s just do it. RESOLVED: Add Miriam as a co-editor of css-values-5 (go ahead and add yourself to the editors list) -- GitHub Notification of comment by astearns Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10082#issuecomment-1998249183 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Note that a downside of "you can access it in two different ways" is that we need to define and implement cascading the two things together. (I don't think defining it is hard since I don't think they differ in [context](https://drafts.csswg.org/css-cascade-5/#cascade-context), and I think any [specificity](https://drafts.csswg.org/css-cascade-5/#cascade-specificity) differences are well defined. Implementing it might be trickier.) -- GitHub Notification of comment by dbaron Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10083#issuecomment-1998240833 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
[astearns](https://github.com/astearns) marked as non substantive for IPR from ash-nazg. -- GitHub Notification of comment by w3cbot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9896#issuecomment-1998229562 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
[astearns](https://github.com/astearns) marked as non substantive for IPR from ash-nazg. -- GitHub Notification of comment by w3cbot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9896#issuecomment-1998229562 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Thank you for the speedy edits @svgeesus, Text is clear to me. The examples had [two typo's](https://github.com/w3c/csswg-drafts/pull/10086) but were otherwise good representations of the behavior. -- GitHub Notification of comment by romainmenke Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9805#issuecomment-1998226011 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-color-5] fix typo == [css-color-5] : some fixes after: https://github.com/w3c/csswg-drafts/commit/4429f5f511be30214d2202670f927aeaea264cea See https://github.com/w3c/csswg-drafts/pull/10086 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
CSS Values 4 [only supports closed ranges](https://drafts.csswg.org/css-values-4/#numeric-ranges) and thus we have to write tah values in the range 90deg to -90deg inclusive are allowed. The OpenType spec gives [the same range, but exclusive](https://learn.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_slnt): > _Valid numeric range:_ Values must be greater than -90 and less than +90. You are correct that implementations may struggle with, say, a perfectly legal 89.999deg slope angle and the end result is unlikely to by typographically satisfying. But just because a thing is possible does not mean it should be done; I don't see us declaring that slope angles greater than 60 degrees are silly in the same way that we don't prevent setting the width of `<body>` to 2px. -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10084#issuecomment-1998171342 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
CSS Values 4 [only supports closed ranges](https://drafts.csswg.org/css-values-4/#numeric-ranges) and thus we have to write tah values in the range 90deg to -90deg inclusive are allowed. The OpenType spec gives [the same range, but exclusive](https://learn.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_slnt): > _Valid numeric range:_ Values must be greater than -90 and less than +90. You are correct that implementations may struggle with, say, a perfectly legal 89.999deg slope angle and the end result is unlikely to by typographically satisfying. But just because a thing is possible does not mean it should be done; I don't see us declaring that slope angles greater than 60 degrees are silly in the same way that we don't prevent setting the width of `<body>` to 2px. -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10084#issuecomment-1998171342 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mayank99 has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-cascade-5] browsers do not disallow CSS-wide keywords in layer names == The spec clearly notes the following: > The CSS-wide keywords are reserved for future use, and cause the rule to be invalid at parse time if used as an <ident> in the <layer-name> I found some existing discussion in #6323, which is where the spec decision was made [originally](https://github.com/w3c/csswg-drafts/issues/6323#issuecomment-887663782). However, it seems like browsers do not currently respect it. This is a problem because it defeats the purpose of reserving keywords for future use. - In #6323, there was some discussion around using the CSS-wide keywords to reference unlayered styles. - In https://github.com/WICG/webcomponents/issues/909#issuecomment-1993388146, there's a proposal around using the CSS-wide keywords to place document styles inside shadow DOM. Maybe this is really a WPT issue, but I think it warrants some discussion here? My main concern is that any websites outside there depending on current browser behavior could break if we start using these "reserved" keywords for new features. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10067 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mayank99 has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-cascade-5] browsers do not disallow CSS-wide keywords in layer names == The spec clearly notes the following: > The CSS-wide keywords are reserved for future use, and cause the rule to be invalid at parse time if used as an <ident> in the <layer-name> I found some existing discussion in #6323, which is where the spec decision was made [originally](https://github.com/w3c/csswg-drafts/issues/6323#issuecomment-887663782). However, it seems like browsers do not currently respect it. This is a problem because it defeats the purpose of reserving keywords for future use. - In #6323, there was some discussion around using the CSS-wide keywords to reference unlayered styles. - In https://github.com/WICG/webcomponents/issues/909#issuecomment-1993388146, there's a proposal around using the CSS-wide keywords to place document styles inside shadow DOM. Maybe this is really a WPT issue, but I think it warrants some discussion here? My main concern is that any websites outside there depending on current browser behavior could break if we start using these "reserved" keywords for new features. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10067 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> I don't think the advice provided by this PR is entirely accurate though, and some of the claims it makes lack evidence (might be true, but not obviously so). For instance: > > > Because [=hanging glyphs=] are considered [=ink overflow=], and hence are not included in [=inline box=] geometry, there is no straightforward way to measure their extent > > This doesn't follow from that. Being defined as ink overflow does not make it easier or harder for the UA to measure there extent. There are things that are included within the definition of ink overflow for which determining the extent is hard (as the extend may theoretically be infinite), but this doesn't seem to be one of them, and anyway, which type of overflow it gets included in makes no difference to that problem. > > Or maybe you meant not easy for an author to measure the extent? Not sure that's true either. modulo the subtleties of sub-pixel rendering, glyphs have sharp edges. They're not like blurs or gradients, where there can considerable uncertainty as to where they end. As you point out in a subsequent paragraph, authors can visually measure the extent of the overflow. Sure, they cannot simply auto-size a box to contain the ink-overflow, and ask an API for the size of that box, but doesn't mean the answer to the question is elusive. Would you be OK with rephrasing it as "no straightforward way for authors to programmatically measure their extent"? That is what I meant to convey. > > However, any two conforming browser implementations, when rendering a given piece of text content using a given font in a supported format […] will produce identically-sized [=ink overflow rectangles=], within a 2-pixel margin of error. > > * [citation needed] :) This is based on conversations with @kojiishi and @drott. > * even if it is true, authors cannot generally rely on the same font being used, so there can be more than 2px of difference This is perhaps an argument in favor of web fonts. > * user styles or zoom can affect the font size, so there can be more than 2px of difference I'm not sure that's true, based on my conversations with @kojiishi and @drott. > * at the moment, hanging glyphs are limited to... This PR gives an example of glyph overhang from an italicized 'f': <div class="figure" style="margin:0; font-size:10rem; font-family:garamond; font-style:italic"> <span style="display:inline-block; width:1ch; height:1lh; background:green; opacity:0.5"></span><span style="vertical-align: top;">f</span><span style="display:inline-block; width:1ch; height:1lh; background:green; opacity:0.5"></span> </div> Regarding CJK typography: I would like to avoid including these kinds of specifics because it's impossible to create an authoritative list. I mean for the takeaway to be: text can result in ink overflow, the extent of which is not directly measurable via web platform API's; but there *is* a practical way to achieve de facto interoperability of ink overflow extents from text. > Whether we should add advice at all to the spec, and what that advice should be, is something that should be discussed as a separate issue from #8649, and get WG consensus before we dive into a specific pull request. I opened #10066 to discuss. -- GitHub Notification of comment by szager-chromium Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9842#issuecomment-1992749312 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> I don't think the advice provided by this PR is entirely accurate though, and some of the claims it makes lack evidence (might be true, but not obviously so). For instance: > > > Because [=hanging glyphs=] are considered [=ink overflow=], and hence are not included in [=inline box=] geometry, there is no straightforward way to measure their extent > > This doesn't follow from that. Being defined as ink overflow does not make it easier or harder for the UA to measure there extent. There are things that are included within the definition of ink overflow for which determining the extent is hard (as the extend may theoretically be infinite), but this doesn't seem to be one of them, and anyway, which type of overflow it gets included in makes no difference to that problem. > > Or maybe you meant not easy for an author to measure the extent? Not sure that's true either. modulo the subtleties of sub-pixel rendering, glyphs have sharp edges. They're not like blurs or gradients, where there can considerable uncertainty as to where they end. As you point out in a subsequent paragraph, authors can visually measure the extent of the overflow. Sure, they cannot simply auto-size a box to contain the ink-overflow, and ask an API for the size of that box, but doesn't mean the answer to the question is elusive. Would you be OK with rephrasing it as "no straightforward way for authors to programmatically measure their extent"? That is what I meant to convey. > > However, any two conforming browser implementations, when rendering a given piece of text content using a given font in a supported format […] will produce identically-sized [=ink overflow rectangles=], within a 2-pixel margin of error. > > * [citation needed] :) This is based on conversations with @kojiishi and @drott. > * even if it is true, authors cannot generally rely on the same font being used, so there can be more than 2px of difference This is perhaps an argument in favor of web fonts. > * user styles or zoom can affect the font size, so there can be more than 2px of difference I'm not sure that's true, based on my conversations with @kojiishi and @drott. > * at the moment, hanging glyphs are limited to... This PR gives an example of glyph overhang from an italicized 'f': <div class="figure" style="margin:0; font-size:10rem; font-family:garamond; font-style:italic"> <span style="display:inline-block; width:1ch; height:1lh; background:green; opacity:0.5"></span><span style="vertical-align: top;">f</span><span style="display:inline-block; width:1ch; height:1lh; background:green; opacity:0.5"></span> </div> Regarding CJK typography: I would like to avoid including these kinds of specifics because it's impossible to create an authoritative list. I mean for the takeaway to be: text can result in ink overflow, the extent of which is not directly measurable via web platform API's; but there *is* a practical way to achieve de facto interoperability of ink overflow extents from text. > Whether we should add advice at all to the spec, and what that advice should be, is something that should be discussed as a separate issue from #8649, and get WG consensus before we dive into a specific pull request. I opened #10066 to discuss. -- GitHub Notification of comment by szager-chromium Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9842#issuecomment-1992749312 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> I don't think the advice provided by this PR is entirely accurate though, and some of the claims it makes lack evidence (might be true, but not obviously so). For instance: > > > Because [=hanging glyphs=] are considered [=ink overflow=], and hence are not included in [=inline box=] geometry, there is no straightforward way to measure their extent > > This doesn't follow from that. Being defined as ink overflow does not make it easier or harder for the UA to measure there extent. There are things that are included within the definition of ink overflow for which determining the extent is hard (as the extend may theoretically be infinite), but this doesn't seem to be one of them, and anyway, which type of overflow it gets included in makes no difference to that problem. > > Or maybe you meant not easy for an author to measure the extent? Not sure that's true either. modulo the subtleties of sub-pixel rendering, glyphs have sharp edges. They're not like blurs or gradients, where there can considerable uncertainty as to where they end. As you point out in a subsequent paragraph, authors can visually measure the extent of the overflow. Sure, they cannot simply auto-size a box to contain the ink-overflow, and ask an API for the size of that box, but doesn't mean the answer to the question is elusive. Would you be OK with rephrasing it as "no straightforward way for authors to programmatically measure their extent"? That is what I meant to convey. > > However, any two conforming browser implementations, when rendering a given piece of text content using a given font in a supported format […] will produce identically-sized [=ink overflow rectangles=], within a 2-pixel margin of error. > > * [citation needed] :) This is based on conversations with @kojiishi and @drott. > * even if it is true, authors cannot generally rely on the same font being used, so there can be more than 2px of difference This is perhaps an argument in favor of web fonts. > * user styles or zoom can affect the font size, so there can be more than 2px of difference I'm not sure that's true, based on my conversations with @kojiishi and @drott. > * at the moment, hanging glyphs are limited to... This PR gives an example of glyph overhang from an italicized 'f': <div class="figure" style="margin:0; font-size:10rem; font-family:garamond; font-style:italic"> <span style="display:inline-block; width:1ch; height:1lh; background:green; opacity:0.5"></span><span style="vertical-align: top;">f</span><span style="display:inline-block; width:1ch; height:1lh; background:green; opacity:0.5"></span> </div> Regarding CJK typography: I would like to avoid including these kinds of specifics because it's impossible to create an authoritative list. I mean for the takeaway to be: text can result in ink overflow, the extent of which is not directly measurable via web platform API's; but there *is* a practical way to achieve de facto interoperability of ink overflow extents from text. > Whether we should add advice at all to the spec, and what that advice should be, is something that should be discussed as a separate issue from #8649, and get WG consensus before we dive into a specific pull request. I opened #10066 to discuss. -- GitHub Notification of comment by szager-chromium Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9842#issuecomment-1992749312 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> I don't think the advice provided by this PR is entirely accurate though, and some of the claims it makes lack evidence (might be true, but not obviously so). For instance: > > > Because [=hanging glyphs=] are considered [=ink overflow=], and hence are not included in [=inline box=] geometry, there is no straightforward way to measure their extent > > This doesn't follow from that. Being defined as ink overflow does not make it easier or harder for the UA to measure there extent. There are things that are included within the definition of ink overflow for which determining the extent is hard (as the extend may theoretically be infinite), but this doesn't seem to be one of them, and anyway, which type of overflow it gets included in makes no difference to that problem. > > Or maybe you meant not easy for an author to measure the extent? Not sure that's true either. modulo the subtleties of sub-pixel rendering, glyphs have sharp edges. They're not like blurs or gradients, where there can considerable uncertainty as to where they end. As you point out in a subsequent paragraph, authors can visually measure the extent of the overflow. Sure, they cannot simply auto-size a box to contain the ink-overflow, and ask an API for the size of that box, but doesn't mean the answer to the question is elusive. Would you be OK with rephrasing it as "no straightforward way for authors to programmatically measure their extent"? That is what I meant to convey. > > However, any two conforming browser implementations, when rendering a given piece of text content using a given font in a supported format […] will produce identically-sized [=ink overflow rectangles=], within a 2-pixel margin of error. > > * [citation needed] :) This is based on conversations with @kojiishi and @drott. > * even if it is true, authors cannot generally rely on the same font being used, so there can be more than 2px of difference This is perhaps an argument in favor of web fonts. > * user styles or zoom can affect the font size, so there can be more than 2px of difference I'm not sure that's true, based on my conversations with @kojiishi and @drott. > * at the moment, hanging glyphs are limited to... This PR gives an example of glyph overhang from an italicized 'f': <div class="figure" style="margin:0; font-size:10rem; font-family:garamond; font-style:italic"> <span style="display:inline-block; width:1ch; height:1lh; background:green; opacity:0.5"></span><span style="vertical-align: top;">f</span><span style="display:inline-block; width:1ch; height:1lh; background:green; opacity:0.5"></span> </div> Regarding CJK typography: I would like to avoid including these kinds of specifics because it's impossible to create an authoritative list. I mean for the takeaway to be: text can result in ink overflow, the extent of which is not directly measurable via web platform API's; but there *is* a practical way to achieve de facto interoperability of ink overflow extents from text. > Whether we should add advice at all to the spec, and what that advice should be, is something that should be discussed as a separate issue from #8649, and get WG consensus before we dive into a specific pull request. I opened #10066 to discuss. -- GitHub Notification of comment by szager-chromium Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9842#issuecomment-1992749312 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
szager-chromium has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-text-3] The spec should provide guidance about interop issues related to ink overflow from text == This is an offshoot from #8649. In cases where the extent of ink overflow can't be pre-determined or programmatically measured (primarily text and text decorations), we should offer non-conforming guidance to authors about interoperability issues and provide best practices for minimizing them. This would be generally useful information, and would be specifically relevant to the same issues mentioned in #8649. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10066 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
A few updates: - The draft spec is now here: https://drafts.csswg.org/css-anchor-position-1 - The rename to "Popover" is roughly complete there. - The spec doesn't seem to need to link to the Popover spec any longer, so that's "complete" also. - The only remaining thing is point number 3 above about the `anchor` attribute. The spec now defines an ["implicit anchor element"](https://drafts.csswg.org/css-anchor-position-1/#implicit-anchor-element), and [this HTML spec PR](https://github.com/whatwg/html/pull/9144) makes the link between `anchor` and "implicit anchor reference". So perhaps nothing more needed for the CSS spec either. I suppose given the above, this issue reduces to adding an example (using the `anchor` attribute) in place of this existing TODO: > TODO fill in new popover-related details. This makes the declared element the [implicit anchor element](https://drafts.csswg.org/css-anchor-position-1/#implicit-anchor-element) for the element with the attribute. -- GitHub Notification of comment by mfreed7 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8191#issuecomment-1992687596 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
A few updates: - The draft spec is now here: https://drafts.csswg.org/css-anchor-position-1 - The rename to "Popover" is roughly complete there. - The spec doesn't seem to need to link to the Popover spec any longer, so that's "complete" also. - The only remaining thing is point number 3 above about the `anchor` attribute. The spec now defines an ["implicit anchor element"](https://drafts.csswg.org/css-anchor-position-1/#implicit-anchor-element), and [this HTML spec PR](https://github.com/whatwg/html/pull/9144) makes the link between `anchor` and "implicit anchor reference". So perhaps nothing more needed for the CSS spec either. I suppose given the above, this issue reduces to adding an example (using the `anchor` attribute) in place of this existing TODO: > TODO fill in new popover-related details. This makes the declared element the [implicit anchor element](https://drafts.csswg.org/css-anchor-position-1/#implicit-anchor-element) for the element with the attribute. -- GitHub Notification of comment by mfreed7 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8191#issuecomment-1992687596 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
A few updates: - The draft spec is now here: https://drafts.csswg.org/css-anchor-position-1 - The rename to "Popover" is roughly complete there. - The spec doesn't seem to need to link to the Popover spec any longer, so that's "complete" also. - The only remaining thing is point number 3 above about the `anchor` attribute. The spec now defines an ["implicit anchor element"](https://drafts.csswg.org/css-anchor-position-1/#implicit-anchor-element), and [this HTML spec PR](https://github.com/whatwg/html/pull/9144) makes the link between `anchor` and "implicit anchor reference". So perhaps nothing more needed for the CSS spec either. I suppose given the above, this issue reduces to adding an example (using the `anchor` attribute) in place of this existing TODO: > TODO fill in new popover-related details. This makes the declared element the [implicit anchor element](https://drafts.csswg.org/css-anchor-position-1/#implicit-anchor-element) for the element with the attribute. -- GitHub Notification of comment by mfreed7 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8191#issuecomment-1992687596 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
A few updates: - The draft spec is now here: https://drafts.csswg.org/css-anchor-position-1 - The rename to "Popover" is roughly complete there. - The spec doesn't seem to need to link to the Popover spec any longer, so that's "complete" also. - The only remaining thing is point number 3 above about the `anchor` attribute. The spec now defines an ["implicit anchor element"](https://drafts.csswg.org/css-anchor-position-1/#implicit-anchor-element), and [this HTML spec PR](https://github.com/whatwg/html/pull/9144) makes the link between `anchor` and "implicit anchor reference". So perhaps nothing more needed for the CSS spec either. I suppose given the above, this issue reduces to adding an example (using the `anchor` attribute) in place of this existing TODO: > TODO fill in new popover-related details. This makes the declared element the [implicit anchor element](https://drafts.csswg.org/css-anchor-position-1/#implicit-anchor-element) for the element with the attribute. -- GitHub Notification of comment by mfreed7 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8191#issuecomment-1992687596 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/9045 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I don't think I've ever personally run into this sort of situation. But more importantly, if you *do* need this sort of thing, there's no way for us to infer what your minimum step is, such that the value range can be shifted over by it. For now, just writing it out (`calc(mod(val - step, max) + step)`) seems sufficient to address this case. If it can be shown there's substantial authoring usage of this sort of pattern, we can reconsider it. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9693#issuecomment-1992675976 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/9693 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
xgebi has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-ruby-1] Obsolete HTML elements in examples == I have a question about obsolete HTML tags in the specification. Ruby annotation has `rb` and `rtc` which in HTML are marked as [obsolete](https://html.spec.whatwg.org/multipage/obsolete.html#rtc). Is there a plan to update current spec or will that happen in Level 2? These two are in [the specification](https://drafts.csswg.org/css-ruby/). `rtc` is in about 30 places and `rb` is referenced in about 60. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10065 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
xgebi has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-ruby-1] Obsolete HTML elements in examples == I have a question about obsolete HTML tags in the specification. Ruby annotation has `rb` and `rtc` which in HTML are marked as [obsolete](https://html.spec.whatwg.org/multipage/obsolete.html#rtc). Is there a plan to update current spec or will that happen in Level 2? These two are in [the specification](https://drafts.csswg.org/css-ruby/). `rtc` is in about 30 places and `rb` is referenced in about 60. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10065 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
xgebi has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-ruby-1] Obsolete HTML elements in examples == I have a question about obsolete HTML tags in the specification. Ruby annotation has `rb` and `rtc` which in HTML are marked as [obsolete](https://html.spec.whatwg.org/multipage/obsolete.html#rtc). Is there a plan to update current spec or will that happen in Level 2? These two are in [the specification](https://drafts.csswg.org/css-ruby/). `rtc` is in about 30 places and `rb` is referenced in about 60. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10065 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
xgebi has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-ruby-1] Obsolete HTML elements in examples == I have a question about obsolete HTML tags in the specification. Ruby annotation has `rb` and `rtc` which in HTML are marked as [obsolete](https://html.spec.whatwg.org/multipage/obsolete.html#rtc). Is there a plan to update current spec or will that happen in Level 2? These two are in [the specification](https://drafts.csswg.org/css-ruby/). `rtc` is in about 30 places and `rb` is referenced in about 60. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10065 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai closed this issue. See https://github.com/w3c/csswg-drafts/issues/6423 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai closed this issue. See https://github.com/w3c/csswg-drafts/issues/6423 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai closed this issue. See https://github.com/w3c/csswg-drafts/issues/5993 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai closed this issue. See https://github.com/w3c/csswg-drafts/issues/5993 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Looks like this was fixed in https://github.com/w3c/csswg-drafts/commit/518226b2be7eb640e8b4b07ab12ef8f70951eaf4 -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5993#issuecomment-1992561756 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Hi @lilychen1388; @SebastianZ outlined in https://github.com/w3c/csswg-drafts/pull/7488#issuecomment-1184321585 that the proposed change makes it a bit less clear, since the `border-color` property only specifies the foreground color of a border specified via `border-style` (and not one specified via e.g. `border-image`). Does that make sense to you? I think I agree that the current wording is more precise. -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7365#issuecomment-1992554922 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr closed this issue. See https://github.com/w3c/csswg-drafts/issues/7514 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
noamr closed this issue. See https://github.com/w3c/csswg-drafts/issues/7514 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@noamr Can you explain what's unclear? Afaict the sizing requirements are normatively specified in https://www.w3.org/TR/css-backgrounds-3/#background-size -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7514#issuecomment-1992517081 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSSWG recently resolved to add `background-clip: border-area`, see https://github.com/w3c/csswg-drafts/issues/9456 ; would this address the use cases here? -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7550#issuecomment-1992514056 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
This was edited in https://github.com/w3c/csswg-drafts/commit/0742ad6e372782b46cca9708fa293e2b5abab219 -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6586#issuecomment-1992505356 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai closed this issue. See https://github.com/w3c/csswg-drafts/issues/6586 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Sorry to bump this old issue with a question, but I'm wondering if browsers currently behave like the conclusion that was reached here. Maybe this is unrelated to the issue, but I am trying to use `min-height: min-content` (or even `max-content` or `fit-content`) and it's not working as expected. Here's a simple reproduction: https://codepen.io/benface/pen/ZEZOXre -- GitHub Notification of comment by benface Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6457#issuecomment-1992500598 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
LeaVerou has just created a new issue for https://github.com/w3c/csswg-drafts: == What is the MVP for inline conditionals on custom properties? == There are several issues across this repo proposing some kind of inline conditional function. Here is a sample: - https://github.com/w3c/csswg-drafts/issues/5624 - https://github.com/w3c/csswg-drafts/issues/5009 - https://github.com/w3c/csswg-drafts/issues/6638 - https://github.com/w3c/csswg-drafts/issues/4731 Yet, this is another case where progress has stalled because we’re trying to flesh out a much more general and powerful feature, which involves a significant amount of design & implementation effort. Meanwhile, this major author pain point remains unsolved, and authors have to resort to HTML attributes instead (as explained in #5624). The current workarounds are: - Using a 0/1 switch and linear interpolation: `calc(var(--test) * var(--if-true) + (1 - var(--test)) * var(--if-false))` - "Space toggle": Using presence/absence and `var(--test, var(--if-false))` - Style container queries: these are great, but only work on descendants. However, there is **no workaround for transforming arbitrary keywords to arbitrary values**, even simple values. E.g. custom properties like these are impossible to implement (examples from Shoelace, one of the most popular web component libraries, but similar use cases can be found in almost any design system and/or WC library): - [`--variant: auto | primary | success | neutral | warning | danger`](https://shoelace.style/components/alert#variants) - [`--effect: none | pulse`](https://shoelace.style/components/badge#pulsating-badges) - [`--button-style: fill | outline`](https://shoelace.style/components/button#pill-buttons) - [`--shape: rect | pill`](https://shoelace.style/components/input#pill) - [`--avatar-shape: square | rounded | circle`](https://shoelace.style/components/avatar#shapes) - [`--size: small | medium | large`](https://shoelace.style/components/radio-button#sizes) - [`--suffix: none | caret`](https://shoelace.style/components/button#caret)` What if we could come up with an MVP that could be implemented fast and extended later? We could scope it down quite a lot and still have something that addresses the most pressing author pain points. Some example restrictions we could start with: - Only [`style( <style-query> )`](https://drafts.csswg.org/css-contain-3/#typedef-style-feature) conditionals - Only custom properties - If it helps, the value space could be restricted too, even as much as single tokens - If it helps, it could even be something that’s only allowed in custom property values Syntax could be either functional (probably easier): ``` <if()> = if (style( <style-query> ), <true-value>, <false-value>? ) ``` or keyword-based (fewer parens, no conflict with preprocessors): ``` <if-inline> = if style( <style-query> ) then <true-value> [ else <false-value> ] ``` Implementors, would this make it tractable? If not, what would? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10064 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@svgeesus What about this question from earlier, though? > Relatedly, for the from-font keyword, should we be picking from the first available font that is able to provide the desired metric? -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6384#issuecomment-1992162218 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@svgeesus What about this question from earlier, though? > Relatedly, for the from-font keyword, should we be picking from the first available font that is able to provide the desired metric? -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6384#issuecomment-1992162218 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
foolip has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-color-4] Update ΔEOK to be even more perceptually uniform == In a discussion with @bottosson, I learned that he considers the scale of the _a_ and _b_ coordinates a mistake in the design of Oklab. Orthogonality between _L_, _a_, and _b_ was a design goal, but the scale of the coordinates was not carefully chosen. They should be roughly doubled to make a change in _a_ or _b_ as noticeable as the same change in _L_. I don't think this is documented anywhere, so I'm hoping for confirmation here. Perhaps I've also misunderstood. If correct, then it's too late to change the coordinates, but ΔEOK should probably take this into account. An update to the [preceding prose](https://drafts.csswg.org/css-color-4/#color-difference-OK) would also be needed, but I'm leaving that until the math itself is confirmed to be correct, in case it's not. See https://github.com/w3c/csswg-drafts/pull/10063 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
foolip has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-color-4] Update ΔEOK to be even more perceptually uniform == In a discussion with @bottosson, I learned that he considers the scale of the _a_ and _b_ coordinates a mistake in the design of Oklab. Orthogonality between _L_, _a_, and _b_ was a design goal, but the scale of the coordinates was not carefully chosen. They should be roughly doubled to make a change in _a_ or _b_ as noticeable as the same change in _L_. I don't think this is documented anywhere, so I'm hoping for confirmation here. Perhaps I've also misunderstood. If correct, then it's too late to change the coordinates, but ΔEOK should probably take this into account. An update to the [preceding prose](https://drafts.csswg.org/css-color-4/#color-difference-OK) would also be needed, but I'm leaving that until the math itself is confirmed to be correct, in case it's not. See https://github.com/w3c/csswg-drafts/pull/10063 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
foolip has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-color-4] Update ΔEOK to be even more perceptually uniform == In a discussion with @bottosson, I learned that he considers the scale of the _a_ and _b_ coordinates a mistake in the design of Oklab. Orthogonality between _L_, _a_, and _b_ was a design goal, but the scale of the coordinates was not carefully chosen. They should be roughly doubled to make a change in _a_ or _b_ as noticeable as the same change in _L_. I don't think this is documented anywhere, so I'm hoping for confirmation here. Perhaps I've also misunderstood. If correct, then it's too late to change the coordinates, but ΔEOK should probably take this into account. An update to the [preceding prose](https://drafts.csswg.org/css-color-4/#color-difference-OK) would also be needed, but I'm leaving that until the math itself is confirmed to be correct, in case it's not. See https://github.com/w3c/csswg-drafts/pull/10063 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
foolip has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-color-4] Update ΔEOK to be even more perceptually uniform == In a discussion with @bottosson, I learned that he considers the scale of the _a_ and _b_ coordinates a mistake in the design of Oklab. Orthogonality between _L_, _a_, and _b_ was a design goal, but the scale of the coordinates was not carefully chosen. They should be roughly doubled to make a change in _a_ or _b_ as noticeable as the same change in _L_. I don't think this is documented anywhere, so I'm hoping for confirmation here. Perhaps I've also misunderstood. If correct, then it's too late to change the coordinates, but ΔEOK should probably take this into account. An update to the [preceding prose](https://drafts.csswg.org/css-color-4/#color-difference-OK) would also be needed, but I'm leaving that until the math itself is confirmed to be correct, in case it's not. See https://github.com/w3c/csswg-drafts/pull/10063 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
foolip has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-color-4] Update ΔEOK to be even more perceptually uniform == In a discussion with @bottosson, I learned that he considers the scale of the _a_ and _b_ coordinates a mistake in the design of Oklab. Orthogonality between _L_, _a_, and _b_ was a design goal, but the scale of the coordinates was not carefully chosen. They should be roughly doubled to make a change in _a_ or _b_ as noticeable as the same change in _L_. I don't think this is documented anywhere, so I'm hoping for confirmation here. Perhaps I've also misunderstood. If correct, then it's too late to change the coordinates, but ΔEOK should probably take this into account. An update to the [preceding prose](https://drafts.csswg.org/css-color-4/#color-difference-OK) would also be needed, but I'm leaving that until the math itself is confirmed to be correct, in case it's not. See https://github.com/w3c/csswg-drafts/pull/10063 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
foolip has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-color-4] Update ΔEOK to be even more perceptually uniform == In a discussion with @bottosson, I learned that he considers the scale of the _a_ and _b_ coordinates a mistake in the design of Oklab. Orthogonality between _L_, _a_, and _b_ was a design goal, but the scale of the coordinates was not carefully chosen. They should be roughly doubled to make a change in _a_ or _b_ as noticeable as the same change in _L_. I don't think this is documented anywhere, so I'm hoping for confirmation here. Perhaps I've also misunderstood. If correct, then it's too late to change the coordinates, but ΔEOK should probably take this into account. An update to the [preceding prose](https://drafts.csswg.org/css-color-4/#color-difference-OK) would also be needed, but I'm leaving that until the math itself is confirmed to be correct, in case it's not. See https://github.com/w3c/csswg-drafts/pull/10063 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
An example of a `scoop` with a partial border not an `angle` but still seems like it might be useful. ![discount-cupon](https://github.com/w3c/csswg-drafts/assets/1286791/35ed5315-ed13-4a45-abde-66f527f43dd4) -- GitHub Notification of comment by jsnkuhn Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9072#issuecomment-1991588830 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
j9t has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-text] Add missing article == None See https://github.com/w3c/csswg-drafts/pull/10062 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
j9t has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-text] Add missing article == None See https://github.com/w3c/csswg-drafts/pull/10062 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
j9t has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-text] Add missing space == Minor change. (Would be open to prepare additional corrections, e.g., to ensure consistency in headings case and some such.) See https://github.com/w3c/csswg-drafts/pull/10061 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The PR got accidentally merged, but we didn't have a resolution on this. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4154#issuecomment-1990964172 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The PR got accidentally merged, but we didn't have a resolution on this. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4154#issuecomment-1990964172 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The PR got accidentally merged, but we didn't have a resolution on this. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4154#issuecomment-1990964172 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Zhang-Junzhi has just created a new issue for https://github.com/w3c/csswg-drafts: == Setting the primary scrolling direction for an scrollable element == Currently, almost all UAs assume the vertical direction is the first-class scrolling direction, so that UAs make vertical scroll as the _pure_ wheel event's default action, while making horizontal scroll as the wheel event's default action with an additional key(typically Shift Key). That's a reasonable assumption for a page in horizontal writing page. A page in vertical writing mode, however, is another story, which is much more likely to overflow horizontally. If we can set an element's primary scrolling direction, then the UAs know that it can make horizontal scroll as the _pure_ wheel event's default action. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10060 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Zhang-Junzhi has just created a new issue for https://github.com/w3c/csswg-drafts: == Setting the primary scrolling direction for an scrollable element == Currently, almost all UAs assume the vertical direction is the first-class scrolling direction, so that UAs make vertical scroll as the _pure_ wheel event's default action, while making horizontal scroll as the wheel event's default action with an additional key(typically Shift Key). That's a reasonable assumption for a page in horizontal writing page. A page in vertical writing mode, however, is another story, which is much more likely to overflow horizontally. If we can set an element's primary scrolling direction, then the UAs know that it can make horizontal scroll as the _pure_ wheel event's default action. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10060 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Zhang-Junzhi has just created a new issue for https://github.com/w3c/csswg-drafts: == Setting the primary scrolling direction for an scrollable element == Currently, almost all UAs assume the vertical direction is the first-class scrolling direction, so that UAs make vertical scroll as the _pure_ wheel event's default action, while making horizontal scroll as the wheel event's default action with an additional key(typically Shift Key). That's a reasonable assumption for a page in horizontal writing page. A page in vertical writing mode, however, is another story, which is much more likely to overflow horizontally. If we can set an element's primary scrolling direction, then the UAs know that it can make horizontal scroll as the _pure_ wheel event's default action. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10060 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Zhang-Junzhi has just created a new issue for https://github.com/w3c/csswg-drafts: == Setting the primary scrolling direction for an scrollable element == Currently, almost all UAs assume the vertical direction is the first-class scrolling direction, so that UAs make vertical scroll as the _pure_ wheel event's default action, while making horizontal scroll as the wheel event's default action with an additional key(typically Shift Key). That's a reasonable assumption for a page in horizontal writing page. A page in vertical writing mode, however, is another story, which is much more likely to overflow horizontally. If we can set an element's primary scrolling direction, then the UAs know that it can make horizontal scroll as the _pure_ wheel event's default action. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10060 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Zhang-Junzhi has just created a new issue for https://github.com/w3c/csswg-drafts: == Setting the primary scrolling direction for an scrollable element == Currently, almost all UAs assume the vertical direction is the first-class scrolling direction, so that UAs make vertical scroll as the _pure_ wheel event's default action, while making horizontal scroll as the wheel event's default action with an additional key(typically Shift Key). That's a reasonable assumption for a page in horizontal writing page. A page in vertical writing mode, however, is another story, which is much more likely to overflow horizontally. If we can set an element's primary scrolling direction, then the UAs know that it can make horizontal scroll as the _pure_ wheel event's default action. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10060 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Zhang-Junzhi has just created a new issue for https://github.com/w3c/csswg-drafts: == Setting the primary scrolling direction for an scrollable element == Currently, almost all UAs assume the vertical direction is the first-class scrolling direction, so that UAs make vertical scroll as the _pure_ wheel event's default action, while making horizontal scroll as the wheel event's default action with an additional key(typically Shift Key). That's a reasonable assumption for a page in horizontal writing page. A page in vertical writing mode, however, is another story, which is much more likely to overflow horizontally. If we can set an element's primary scrolling direction, then the UAs know that it can make horizontal scroll as the _pure_ wheel event's default action. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10060 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Zhang-Junzhi has just created a new issue for https://github.com/w3c/csswg-drafts: == Setting the primary scrolling direction for an scrollable element == Currently, almost all UAs assume the vertical direction is the first-class scrolling direction, so that UAs make vertical scroll as the _pure_ wheel event's default action, while making horizontal scroll as the wheel event's default action with an additional key(typically Shift Key). That's a reasonable assumption for a page in horizontal writing page. A page in vertical writing mode, however, is another story, which is much more likely to overflow horizontally. If we can set an element's primary scrolling direction, then the UAs know that it can make horizontal scroll as the _pure_ wheel event's default action. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10060 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai closed this issue. See https://github.com/w3c/csswg-drafts/issues/6026 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai closed this issue. See https://github.com/w3c/csswg-drafts/issues/6026 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai closed this issue. See https://github.com/w3c/csswg-drafts/issues/6026 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/9668 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai closed this issue. See https://github.com/w3c/csswg-drafts/issues/9691 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai closed this issue. See https://github.com/w3c/csswg-drafts/issues/9691 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai closed this issue. See https://github.com/w3c/csswg-drafts/issues/9691 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I'm not sure this is worth doing, because it's not particularly common and adding rarely-used multipliers makes it harder for people reading our syntax, since it's unavoidably unfamiliar. -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9691#issuecomment-1989546544 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I'm not sure this is worth doing, because it's not particularly common and adding rarely-used multipliers makes it harder for people reading our syntax, since it's unavoidably unfamiliar. -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9691#issuecomment-1989546544 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-values-4] Should `dv*` account for `overflow: auto` scrollbars dynamically? == In https://github.com/w3c/csswg-drafts/issues/6026 we resolved to restore the rule that made viewport units account for `overflow: scroll`. But this is only part of the equation: it doesn't handle `overflow: auto`. The restriction was put in originally because cycling computed style after layout was complicated. But since the `dv*` units are already dynamic, and are relatively new so have fewer compat restrictions, should they be made to dynamically account for scrollbars? If so, should we adjust the `sv*` units also? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10059 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-values-4] Should `dv*` account for `overflow: auto` scrollbars dynamically? == In https://github.com/w3c/csswg-drafts/issues/6026 we resolved to restore the rule that made viewport units account for `overflow: scroll`. But this is only part of the equation: it doesn't handle `overflow: auto`. The restriction was put in originally because cycling computed style after layout was complicated. But since the `dv*` units are already dynamic, and are relatively new so have fewer compat restrictions, should they be made to dynamically account for scrollbars? If so, should we adjust the `sv*` units also? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10059 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-values-4] Should `dv*` account for `overflow: auto` scrollbars dynamically? == In https://github.com/w3c/csswg-drafts/issues/6026 we resolved to restore the rule that made viewport units account for `overflow: scroll`. But this is only part of the equation: it doesn't handle `overflow: auto`. The restriction was put in originally because cycling computed style after layout was complicated. But since the `dv*` units are already dynamic, and are relatively new so have fewer compat restrictions, should they be made to dynamically account for scrollbars? If so, should we adjust the `sv*` units also? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10059 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I think that the default behavior definitely needs to not change the tab ordering at all; the tooltip use-case probably wants it, but other use-cases (even using anchor-default) don't necessarily. For example, if you're just anchoring to some container, you probably don't want to be right after that container in the tab order (or at least, there's definitely enough doubt about your intent that we shouldn't change things by default). There's also other focus-management work being done in HTML that I'd want to at least be consistent with (tho I'm not sure what the status of that work is now). As such, I'd like to defer this to level 2. It would be great to have this work as easily as possible, but there's enough questions to answer that I don't want to make level 1 depend on it, and it will be safe to add in the future. (Once Bikeshed switches to using anchor positioning for its link/dfn popups rather than JS-computed positions, it'll still need to keep its tabindex shenanigans, so it would be great if anchor positioning could somehow solve this!) -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9356#issuecomment-1989459633 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-anchor-position] is !important allowed in @position-try == Should we allow `!important` decls in `@position-try`? I'm inclined to say no - we're already having to do some slightly odd things with the cascade to make things work reasonably well and in a well-defined way (particularly with `flip-*` keywords), so having some parts of the rule also apply in a separate `!important` location would make it a lot *more* complicated for little, if any, benefit to authors. (And, like, where *exactly* would they go anyway? We resolved that normal decls here go at "the end of the author origin", and I'm inclined to actually specify that as a separate origin placed right after Author. Whether an "important position-try decl" should follow normal origin-reversing order (being *weaker* than author !important rules) or violate that to still go after the author !important rules would be an important decision, and both options are fairly bad, I think.) So, propose to disallow !important. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10058 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-anchor-position] is !important allowed in @position-try == Should we allow `!important` decls in `@position-try`? I'm inclined to say no - we're already having to do some slightly odd things with the cascade to make things work reasonably well and in a well-defined way (particularly with `flip-*` keywords), so having some parts of the rule also apply in a separate `!important` location would make it a lot *more* complicated for little, if any, benefit to authors. (And, like, where *exactly* would they go anyway? We resolved that normal decls here go at "the end of the author origin", and I'm inclined to actually specify that as a separate origin placed right after Author. Whether an "important position-try decl" should follow normal origin-reversing order (being *weaker* than author !important rules) or violate that to still go after the author !important rules would be an important decision, and both options are fairly bad, I think.) So, propose to disallow !important. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10058 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/9713 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/9713 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/9713 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/9713 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/251 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/251 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/251 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/251 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/251 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/251 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
flackr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-scroll-snap-1] Define selected snap area amongst multiple aligned candidates == Implements the algorithm agreed upon in https://github.com/w3c/csswg-drafts/issues/9622#issuecomment-1843949800 to select a particular snap area in each axis. Fixes #9622. See https://github.com/w3c/csswg-drafts/pull/10057 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
flackr has just labeled a pull request from flackr for https://github.com/w3c/csswg-drafts as "css-scroll-snap-1": == [css-scroll-snap-1] Define selected snap area amongst multiple aligned candidates == Implements the algorithm agreed upon in https://github.com/w3c/csswg-drafts/issues/9622#issuecomment-1843949800 to select a particular snap area in each axis. Fixes #9622. See https://github.com/w3c/csswg-drafts/pull/10057 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
1. Does "truncate" without a target mean "truncate to zero"? This probably depends on the context of the sentence, the one I see is referencing truncation to zero in the previous sentence. 2. Does "truncate to X" mean "set value to X" or "set value to X if it is larger than X" (so "truncate to zero" would not change negative values)? The latter, per English definition. You can't increase the size of something by truncating it. 3. Same as 1. and 2. but for "trim" Same. 4. Does "discard" mean "set value to zero" (in contrast to things like "skip any processing that requires the value and do some special alternative steps...")? Yes. 5. If those change the value, can we assume it is the used value (e.g. of margin-top) that is changed, not affecting inheriting children but the resolved style for getComputedStyle? Yes. -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3443#issuecomment-1989125535 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai closed this issue. See https://github.com/w3c/csswg-drafts/issues/3443 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I'm not sure this is actually useful, and it certainly makes the grammar more convoluted, but the effect of it is fairly straightforward. Agenda+ to ask the WG what it thinks. -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7884#issuecomment-1989072430 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I'm not sure this is actually useful, and it certainly makes the grammar more convoluted, but the effect of it is fairly straightforward. Agenda+ to ask the WG what it thinks. -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7884#issuecomment-1989072430 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I'm not sure this is actually useful, and it certainly makes the grammar more convoluted, but the effect of it is fairly straightforward. Agenda+ to ask the WG what it thinks. -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7884#issuecomment-1989072430 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Agenda+ to double-check with the WG that including all the shaping properties (`border-radius`, `corner-shape`, etc.) would make sense here. -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9245#issuecomment-1989064175 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Would this need a separate property, or could we fold this into `box-sizing` as like a `border-in-padding` keyword or something like that? (Preferably with a less awkward name, though.) -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7770#issuecomment-1989053309 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@bakura10 Not sure exactly what you're trying to do, but maybe a combination of `display: block; width: fit-content` would get you what you want here? -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6922#issuecomment-1989045200 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
That was subsequently rename to `text-box-trim`; so closing as no longer relevant. :) (Also, it's nice to keep all the margin-related properties sorting together.) -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5750#issuecomment-1989040828 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai closed this issue. See https://github.com/w3c/csswg-drafts/issues/5750 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Retargetting for Level 5; note that the effect on floats has been completely removed, see https://github.com/w3c/csswg-drafts/issues/8547 -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3256#issuecomment-1989038132 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai closed this issue. See https://github.com/w3c/csswg-drafts/issues/8547 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai closed this issue. See https://github.com/w3c/csswg-drafts/issues/8547 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Edits committed, retargetting at Level 5 for reconsideration. -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8547#issuecomment-1989034445 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
emilio closed this issue. See https://github.com/w3c/csswg-drafts/issues/8970 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
emilio closed this issue. See https://github.com/w3c/csswg-drafts/issues/8970 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
emilio closed this issue. See https://github.com/w3c/csswg-drafts/issues/8970 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
emilio closed this issue. See https://github.com/w3c/csswg-drafts/issues/8970 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
nt1m has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] Is `::view-transition:only-child` supported? == Right now WebKit makes it unparsable, but I think Blink has an implementation returning false (which doesn't really make sense honestly, if there's one, it should probably return `true`). @noamr @khushalsagar @vmpstr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10056 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
nt1m has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] Is `::view-transition:only-child` supported? == Right now WebKit makes it unparsable, but I think Blink has an implementation returning false (which doesn't really make sense honestly, if there's one, it should probably return `true`). @noamr @khushalsagar @vmpstr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10056 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
nt1m has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] Is `::view-transition:only-child` supported? == Right now WebKit makes it unparsable, but I think Blink has an implementation returning false (which doesn't really make sense honestly, if there's one, it should probably return `true`). @noamr @khushalsagar @vmpstr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10056 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
nt1m has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] Is `::view-transition:only-child` supported? == Right now WebKit makes it unparsable, but I think Blink has an implementation returning false (which doesn't really make sense honestly, if there's one, it should probably return `true`). @noamr @khushalsagar @vmpstr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10056 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
nt1m has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] Is `::view-transition:only-child` supported? == Right now WebKit makes it unparsable, but I think Blink has an implementation returning false (which doesn't really make sense honestly, if there's one, it should probably return `true`). @noamr @khushalsagar @vmpstr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10056 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
nt1m closed this issue. See https://github.com/w3c/csswg-drafts/issues/9996 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-4] matching displayed colors between CSS colors and images when those colors are outside the displayable gamut == see : https://github.com/w3c/csswg-drafts/issues/9449 @ccameron-chromium said: > This https://github.com/w3c/csswg-drafts/issues/7610#issuecomment-1216700728 the ability to color match between CSS colors and images. Why is it okay to break this functionality? Is there a way that we can avoid breaking this? I think there is a lot of nuance missing from this statement. In particular that all colors inside the displayable gamut would still match between CSS and images. But I agree that having the ability to color match between various features is important to at least some users. -------- Do users have the needed knobs and dials today to effectively color match between images and CSS colors? I think they actually already do with the `color-gamut` media query: - can be used to pick specific CSS colors - can be used to load specific images It is an involved process, not something that falls out naturally. But it is possible. ------- An even smaller group of users might want to match colors that are outside the displayable gamut. (e.g. matching midpoints of interpolations in `oklch` to an image) Maybe there should be an opt-out for gamut mapping in CSS? This could be a keyword on a property that limits overal gamut mapping, see : https://github.com/w3c/csswg-drafts/issues/10038 The resulting colors would be clipped values and would be objectively bad, but might be what the other wants. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10055 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I gave the matter some thought, and in the mdn says "inline-size containment is applied to the element in both the inline and block directions, the size of the element **can** be computed in isolation, ignoring the child elements", so the isolation avoid circular references. I dont figure how the min-size can be calculated ignoring the child elements, in isolation. Think in some like this to prevent circular references and use child elements: ```js var a_size = computed_with_child_elements_in_isolation( node, general_rules ), container_what_match = get_container_what_match( node, a_size ), general_rules_and_container_rules = general_rules + container_what_match.rules, b_size = computed_with_child_elements_in_isolation( node, general_rules_and_container_rules ), containers = [ ]; while ( a_size != b_size && containers.indexOf(container_what_match.id) == -1 ) { containers.push(container_what_match.id); container_what_match = get_container_what_match( node, b_size ); general_rules_and_container_rules = general_rules + container_what_match.rules; a_size = b_size; b_size = computed_with_child_elements_in_isolation( node, general_rules_and_container_rules ); } // now container_what_match === FINAL_CONTAINER_RULES_TO_APPLY b_size === FINAL_SIZE ``` some approach when every @container rule is only applied one time per element dont be a problem with recursion. for example if this rule is the last in css, the element is computed with a width of 0 ```css @container (width < min-width) { #content { width: 0 } } ``` for example if this rule is the last in css, the element is computed with a width of calc(100% of_container_width + 100px) only one time, if width is 1000 and min-width is 950 and max-width is 1020 #content width is 950 the result is a container of 1020px and content width of 1050 with 30 of content overflow ```css @container (width >= min-width) { #content { width: calc(100% + 100px) } } ``` if width is 1000 and min-width is 950 and max-width is 1500 content width is 950 the result is a container of 1050px and content width of 1050 with 0 of content overflow ```css @container (width >= min-width) { #content { width: calc(100% + 100px) } } @container (width >= min-width) { #content { width: calc(100% + 100px) } } ``` if width is 1000 and min-width is 950 and max-width is 1500 content width is 950 the result is a container of 1150px and content width of 1150 with 0 of content overflow uhmm i dont know what i want in the last case, what is better, the proposal or what the last rule override the first? i dont know how this things are computed internally, where i can learn more about the tecnical current implementation for get a better understanding of this topic? -- GitHub Notification of comment by codermapuche Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9978#issuecomment-1987015872 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
If `style` currently only includes counters and quotes, how about adding a new value for that, like `text-formatting`, and then we can keep `style` as "includes all" while allowing other values to escape that containment? -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8915#issuecomment-1986900069 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
If `style` currently only includes counters and quotes, how about adding a new value for that, like `text-formatting`, and then we can keep `style` as "includes all" while allowing other values to escape that containment? -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8915#issuecomment-1986900069 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
If `style` currently only includes counters and quotes, how about adding a new value for that, like `text-formatting`, and then we can keep `style` as "includes all" while allowing other values to escape that containment? -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8915#issuecomment-1986900069 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
chrishtr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == Add clarification that viewport properties are not divided by CSS zoom == Resolves #9911 9911 See https://github.com/w3c/csswg-drafts/pull/10054 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
chrishtr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == Add clarification that viewport properties are not divided by CSS zoom == Resolves #9911 9911 See https://github.com/w3c/csswg-drafts/pull/10054 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
chrishtr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == Add clarification that viewport properties are not divided by CSS zoom == Resolves #9911 9911 See https://github.com/w3c/csswg-drafts/pull/10054 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
chrishtr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == Add clarification that viewport properties are not divided by CSS zoom == Resolves #9911 9911 See https://github.com/w3c/csswg-drafts/pull/10054 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
chrishtr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == Add clarification that viewport properties are not divided by CSS zoom == Resolves #9911 9911 See https://github.com/w3c/csswg-drafts/pull/10054 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3355 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3355 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3355 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3355 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3355 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3355 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3355 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3355 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3355 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3355 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3355 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3355 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3355 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3355 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3355 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3355 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3355 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3355 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3355 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> The image in example 17 doesn't match the CSS used to create it. This is now [example 25](https://drafts.csswg.org/css-images-4/#example-9b0946eb), further demonstration that examples should have meaningful IDs. > So yeah, the spec example is wrong and needs to specify closest-side I can do that trivial edit -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3355#issuecomment-1986160914 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/9349 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
bfgeek has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-grid-3] Current track sizing algorithm can go exponential in complexity. == https://drafts.csswg.org/css-grid-3/#track-sizing Currently you need to place everything in every possible position. With subgrid this means that the complexity can go ~exponential (or sub-exponential). ``` <div style="grid-template: masonry / repeat(10, auto);"> <div style="grid-template: subgrid / subgrid; grid-column: auto / span 6;"> <!-- 5 positions --> <div style="grid-template: subgrid / subgrid; grid-column: auto / span 3;"> <!-- 4 positions --> <div></div> <!-- 3 positions --> </div> </div> </div> ``` In the above example there are 60 positions you need to test (each subgrid level might have different margin/border/padding which needs to be taken into account for the items contribution in a particular position along with many other factors). In Blink we've spent most of our performance work in layout fixing exponential time bugs - developers really care about layout time performance. While these issues were quality of implementation bugs (and not a core problem with a particular spec), having exponential time complexity in a spec seems bad[1]. [1] - Exponential time complexity doesn't care how powerful your CPU is - it'll always win. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10053 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus has just created a new issue for https://github.com/w3c/csswg-drafts: == Selectors 4: test suite and implementation report == The [/TR of Selectors 4](https://www.w3.org/TR/selectors-4/) is currently a [WD published 11 Nov 2022](https://www.w3.org/TR/2022/WD-selectors-4-20221111/). It has the old test results widget, which proudly declares **133** tests. ![image](https://github.com/w3c/csswg-drafts/assets/2506926/7d96ed41-0f75-4123-bfcb-ef8256ba446f) That link is to the old, non-maintained, manual test suite. Looking now at WPT, there are [**5436** tests](https://wpt.fyi/results/css/selectors?label=experimental&label=master&aligned) across all levels, which are well maintained and run every day. ![image](https://github.com/w3c/csswg-drafts/assets/2506926/3fa15a00-44d5-47f2-8c24-8ec1c20d3086) Thus, it would be valuable to add the [Bikeshed WPT annotations](https://speced.github.io/bikeshed/#testing) to that spec, indicating which spec sections are tested by which tests. Clearly that is a lot of work, but it would make the spec significantly more useful and help with advancement to CR. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10052 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus has just created a new issue for https://github.com/w3c/csswg-drafts: == Selectors 4: test suite and implementation report == The [/TR of Selectors 4](https://www.w3.org/TR/selectors-4/) is currently a [WD published 11 Nov 2022](https://www.w3.org/TR/2022/WD-selectors-4-20221111/). It has the old test results widget, which proudly declares **133** tests. ![image](https://github.com/w3c/csswg-drafts/assets/2506926/7d96ed41-0f75-4123-bfcb-ef8256ba446f) That link is to the old, non-maintained, manual test suite. Looking now at WPT, there are [**5436** tests](https://wpt.fyi/results/css/selectors?label=experimental&label=master&aligned) across all levels, which are well maintained and run every day. ![image](https://github.com/w3c/csswg-drafts/assets/2506926/3fa15a00-44d5-47f2-8c24-8ec1c20d3086) Thus, it would be valuable to add the [Bikeshed WPT annotations](https://speced.github.io/bikeshed/#testing) to that spec, indicating which spec sections are tested by which tests. Clearly that is a lot of work, but it would make the spec significantly more useful and help with advancement to CR. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10052 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Similarly for the [Selectors 3 Rec from 2018](https://www.w3.org/TR/selectors-3/) then rather than adding errata to that or publishing an update with a bikeshed conversion, effort should focus on [Selectors 4](https://drafts.csswg.org/selectors/) which is still a WD and last published to /TR on [11 Nov 2022](https://www.w3.org/TR/2022/WD-selectors-4-20221111/) -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/251#issuecomment-1986079391 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Similarly for the [Selectors 3 Rec from 2018](https://www.w3.org/TR/selectors-3/) then rather than adding errata to that or publishing an update with a bikeshed conversion, effort should focus on [Selectors 4](https://drafts.csswg.org/selectors/) which is still a WD and last published to /TR on [11 Nov 2022](https://www.w3.org/TR/2022/WD-selectors-4-20221111/) -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/251#issuecomment-1986079391 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus has just created a new issue for https://github.com/w3c/csswg-drafts: == [none] Testing 123 == Sacrificial dummy issue filed on the [fxtf repo](https://github.com/w3c/fxtf-drafts/) to test migrating issues over to CSSWG as required by - https://github.com/w3c/fxtf-drafts/issues/509 Here is a dummy spec link https://drafts.fxtf.org/compositing-1/#canvascompositingandblending and a reference to a csswh issue - https://github.com/w3c/csswg-drafts/issues/9416 and an fxtf issue https://github.com/w3c/fxtf-drafts/issues/541 I'm also adding labels, some of which also exist in csswg repo, and some of which do not. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10051 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus has just created a new issue for https://github.com/w3c/csswg-drafts: == [none] Testing 123 == Sacrificial dummy issue filed on the [fxtf repo](https://github.com/w3c/fxtf-drafts/) to test migrating issues over to CSSWG as required by - https://github.com/w3c/fxtf-drafts/issues/509 Here is a dummy spec link https://drafts.fxtf.org/compositing-1/#canvascompositingandblending and a reference to a csswh issue - https://github.com/w3c/csswg-drafts/issues/9416 and an fxtf issue https://github.com/w3c/fxtf-drafts/issues/541 I'm also adding labels, some of which also exist in csswg repo, and some of which do not. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10051 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@fantasai said > Adding new features (or substantially changing existing ones) requires CSSWG approval, not just editor approval... it doesn't seem like https://github.com/w3c/csswg-drafts/issues/9237 has that? How do I request CSSWG approval on the added property? -- GitHub Notification of comment by darktears Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9237#issuecomment-1985793250 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@fantasai said > Adding new features (or substantially changing existing ones) requires CSSWG approval, not just editor approval... it doesn't seem like https://github.com/w3c/csswg-drafts/issues/9237 has that? How do I request CSSWG approval on the added property? -- GitHub Notification of comment by darktears Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9237#issuecomment-1985793250 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@fantasai said > Adding new features (or substantially changing existing ones) requires CSSWG approval, not just editor approval... it doesn't seem like https://github.com/w3c/csswg-drafts/issues/9237 has that? How do I request CSSWG approval on the added property? -- GitHub Notification of comment by darktears Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9237#issuecomment-1985793250 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Hello! Front-end developer here who actively builds websites and works with CSS every day. I also published a book on advanced "CSS3" via Wiley in 2013. I think the general concept here is absolutely a winning one. People will be falling over themselves to make CSS4 courses, publishers will be clamouring to release CSS4 books, and it will create a buzz that makes developers feel a sense of needing to get across it all. And the end result will be greater coverage, greater visibility and greater uptake for new CSS features. We've literally already seen this pattern with CSS3, and I've no reason to think it would be different now. As many have mentioned already, naming matters and branding matters. Even if it's not "real", the impact in community uptake will be very real. I echo the sentiments from others who have said that there's a general perception that CSS these days isn't something that needs to be kept on top of. People won't invest the time to look into a new pseudo-class, but if recruiters are listing CSS4 as a requirement, they will get that base covered. As someone who covered CSS3 extensively at the time, I don't think 'production-readiness' needs to be a major consideration with CSS4. While I understand Rachel Andrew's points, the various modules under the CSS3 umbrella had very varying degrees of support at the time, and it seemed to be generally understood that some features had good support and some didn't yet. My main concern at the moment is I think you'll need to be careful about what goes into the CSS4 bucket. Looking at [this list](https://github.com/orgs/CSS-Next/projects/1/views/2), much of the proposed CSS4 features were, in my experience, covered back when CSS3 was the catch-all term. As I mentioned, I think CSS4 has the potential to hit the web dev scene quite hard, and if people then realise it's just Flexbox, Grid and other already mainstream features, it may be somewhat underwhelming and also a bit confusing. I may be wrong on this but this is my gut feeling. To conclude, I personally think this is most definitely the way forward for CSS and am very excited about seeing this come to fruition! 😄 -- GitHub Notification of comment by SteGreig Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4770#issuecomment-1985746266 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Hello! Front-end developer here who actively builds websites and works with CSS every day. I also published a book on advanced "CSS3" via Wiley in 2013. I think the general concept here is absolutely a winning one. People will be falling over themselves to make CSS4 courses, publishers will be clamouring to release CSS4 books, and it will create a buzz that makes developers feel a sense of needing to get across it all. And the end result will be greater coverage, greater visibility and greater uptake for new CSS features. We've literally already seen this pattern with CSS3, and I've no reason to think it would be different now. As many have mentioned already, naming matters and branding matters. Even if it's not "real", the impact in community uptake will be very real. I echo the sentiments from others who have said that there's a general perception that CSS these days isn't something that needs to be kept on top of. People won't invest the time to look into a new pseudo-class, but if recruiters are listing CSS4 as a requirement, they will get that base covered. As someone who covered CSS3 extensively at the time, I don't think 'production-readiness' needs to be a major consideration with CSS4. While I understand Rachel Andrew's points, the various modules under the CSS3 umbrella had very varying degrees of support at the time, and it seemed to be generally understood that some features had good support and some didn't yet. My main concern at the moment is I think you'll need to be careful about what goes into the CSS4 bucket. Looking at [this list](https://github.com/orgs/CSS-Next/projects/1/views/2), much of the proposed CSS4 features were, in my experience, covered back when CSS3 was the catch-all term. As I mentioned, I think CSS4 has the potential to hit the web dev scene quite hard, and if people then realise it's just Flexbox, Grid and other already mainstream features, it may be somewhat underwhelming and also a bit confusing. I may be wrong on this but this is my gut feeling. To conclude, I personally think this is most definitely the way forward for CSS and am very excited about seeing this come to fruition! 😄 -- GitHub Notification of comment by SteGreig Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4770#issuecomment-1985746266 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-text-decor] Propdef table for text-decoration-thickness shouldn't say "Percentages: N/A" == https://drafts.csswg.org/css-text-decor-4/#text-decoration-thickness-property > Percentages: N/A But it does accept percentages, so I guess it should say the same as `line-height`: https://drafts.csswg.org/css-inline/#line-height-property > Percentages: computed relative to 1em Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10050 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-text-decor] Propdef table for text-decoration-thickness shouldn't say "Percentages: N/A" == https://drafts.csswg.org/css-text-decor-4/#text-decoration-thickness-property > Percentages: N/A But it does accept percentages, so I guess it should say the same as `line-height`: https://drafts.csswg.org/css-inline/#line-height-property > Percentages: computed relative to 1em Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10050 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-text-decor] Propdef table for text-decoration-thickness shouldn't say "Percentages: N/A" == https://drafts.csswg.org/css-text-decor-4/#text-decoration-thickness-property > Percentages: N/A But it does accept percentages, so I guess it should say the same as `line-height`: https://drafts.csswg.org/css-inline/#line-height-property > Percentages: computed relative to 1em Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10050 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Are there any plans for this? We need this too. Still can be reliably detected in 2024... -- GitHub Notification of comment by Somnium7 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/809#issuecomment-1985484665 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Are there any plans for this? We need this too. Still can be reliably detected in 2024... -- GitHub Notification of comment by Somnium7 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/809#issuecomment-1985484665 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Are there any plans for this? We need this too. Still can be reliably detected in 2024... -- GitHub Notification of comment by Somnium7 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/809#issuecomment-1985484665 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Are there any plans for this? We need this too. Still can be reliably detected in 2024... -- GitHub Notification of comment by Somnium7 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/809#issuecomment-1985484665 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
As a data point, Microsoft Word also has this function. If there are manually added spaces, they will be copied. If there are no manually added spaces, the extra spacing will not become U+0020 on the clipboard. Users can add the spaces themselves if they want to. -- GitHub Notification of comment by xfq Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8511#issuecomment-1985255127 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
As a data point, Microsoft Word also has this function. If there are manually added spaces, they will be copied. If there are no manually added spaces, the extra spacing will not become U+0020 on the clipboard. Users can add the spaces themselves if they want to. -- GitHub Notification of comment by xfq Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8511#issuecomment-1985255127 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
As a data point, Microsoft Word also has this function. If there are manually added spaces, they will be copied. If there are no manually added spaces, the extra spacing will not become U+0020 on the clipboard. Users can add the spaces themselves if they want to. -- GitHub Notification of comment by xfq Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8511#issuecomment-1985255127 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I don't think we should be using `::part` syntax for `details`. The whole point of `::part` syntax was to namespace shadow DOM / custom elements so that they won't conflict with builtin pseudo elements. I'm immensely annoyed that this topic is getting re-litigated again. -- GitHub Notification of comment by rniwa Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9951#issuecomment-1984811081 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I don't think we should be using `::part` syntax for `details`. The whole point of `::part` syntax was to namespace shadow DOM / custom elements so that they won't conflict with builtin pseudo elements. I'm immensely annoyed that this topic is getting re-litigated again. -- GitHub Notification of comment by rniwa Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9951#issuecomment-1984811081 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I don't think we should be using `::part` syntax for `details`. The whole point of `::part` syntax was to namespace shadow DOM / custom elements so that they won't conflict with builtin pseudo elements. I'm immensely annoyed that this topic is getting re-litigated again. -- GitHub Notification of comment by rniwa Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9951#issuecomment-1984811081 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I don't think we should be using `::part` syntax for `details`. The whole point of `::part` syntax was to namespace shadow DOM / custom elements so that they won't conflict with builtin pseudo elements. I'm immensely annoyed that this topic is getting re-litigated again. -- GitHub Notification of comment by rniwa Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9951#issuecomment-1984811081 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I don't think we should be using `::part` syntax for `details`. The whole point of `::part` syntax was to namespace shadow DOM / custom elements so that they won't conflict with builtin pseudo elements. I'm immensely annoyed that this topic is getting re-litigated again. -- GitHub Notification of comment by rniwa Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9951#issuecomment-1984811081 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I don't think we should be using `::part` syntax for `details`. The whole point of `::part` syntax was to namespace shadow DOM / custom elements so that they won't conflict with builtin pseudo elements. I'm immensely annoyed that this topic is getting re-litigated again. -- GitHub Notification of comment by rniwa Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9951#issuecomment-1984811081 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I don't think we should be using `::part` syntax for `details`. The whole point of `::part` syntax was to namespace shadow DOM / custom elements so that they won't conflict with builtin pseudo elements. I'm immensely annoyed that this topic is getting re-litigated again. -- GitHub Notification of comment by rniwa Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9951#issuecomment-1984811081 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I don't think we should be using `::part` syntax for `details`. The whole point of `::part` syntax was to namespace shadow DOM / custom elements so that they won't conflict with builtin pseudo elements. I'm immensely annoyed that this topic is getting re-litigated again. -- GitHub Notification of comment by rniwa Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9951#issuecomment-1984811081 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-anchor-position] Nailing down the position-try-options "flip" behavior == Currently, the spec says that the `flip-block`/etc values: > Automatically creates a [position option](https://drafts.csswg.org/css-anchor-position/#position-option) from the element’s computed style, by swapping the [margin](https://drafts.csswg.org/css-box-4/#margin-properties), [sizing](https://drafts.csswg.org/css-sizing-3/#sizing-property), [inset](https://drafts.csswg.org/css-logical-1/#inset-properties), and [self-alignment](https://drafts.csswg.org/css-align-3/#self-alignment-properties) property values among the element’s sides, and adds it to the [position options list](https://drafts.csswg.org/css-anchor-position/#position-options-list). This isn't correct (specifically the "computed values" part), for a few reasons: * computed value includes all the origins. Even if we ignore the animation origin, it means that UA !important rules, for example, would contribute their value to the flipped property. (but would still exist as their original form too, since they wouldn't be overrideable by the `@position-try`) * now that we're invoking style/layout interleaving for anchor functions, the "computed value" loses the fact that there was an anchor function at all; it's just a length now. We need something before that point. @andruud worked thru the details of what we'd probably actually want, and after discussing this with him I'm relatively convinced his idea is the right way. I think we need to specify two things: 1. The "virtual" `@position-try` generated by a flip-* keyword contains the properties specified by the `@position-try` being flipped (if there is one), flipped appropriately. It then *also* contains all the *other* position-try allowed properties, with their value being a magic internal value that's like `revert-layer`, but grabs a specified property (the one it's being flipped from). (Per other resolutions, the position-try values are applied as if they're in a final, UA-controlled cascade layer in the author origin, so this would revert to the declared value that otherwise wins the author origin.) Aka, given: ```css @position-try --pos { left: anchor(right); top: anchor(bottom); } /* Regular author styles */ div { position-try-options: --pos flip-inline flip-block; } ``` The "virtual" `@position-try` would look like: ```css @position-try [virtual flipped --pos] { right: anchor(left); top: anchor(top); left: revert-layer-to(right); bottom: revert-layer-to(top); margin-top: revert-layer-to(margin-bottom); ...all the rest of the @position-try allowed properties... } ``` 2. The timing of *precisely* what value we're getting is potentially important here. In particular, if we're flipping the values (`anchor(right)` becoming `anchor(left)`, etc), then we want to ensure we're getting the value *after* variable substitution, but still *before* style/layout interleaving. For example, if the author writes `--foo: anchor(right); right: var(--foo);`, then when we generate the virtual flipped position-try rule, we want to ensure it ends up acting like they'd written `left: anchor(left);`, **not** `left: var(--foo);` (which then var-substitutes to `left: anchor(right);`). But var substitution happens to computed values, and with (1) we're working with cascaded values which precede that, so we'd have to do a special manual variable substitution, and ensure that we similarly manually applied any *other* similar transforms we ever define. Instead of this, Anders suggests leaving the values untransformed, but specifying that the used value of `position-try-options` changes how we *interpret* the values. So in the above variable example, we *would* just flip it to `left: var(--foo);`, which subs to `left: anchor(right);`, but because we're using a flip-inline try option, it would behave as `anchor(left)`; an `align-self: start` would behave as `end`; etc. APIs that observe the computed value won't see the position-try results; APIs that observe the the used value will see the final result after substitution, so the anchor() function itself disappears. We don't expose the used value of properties like `align-self`, so the fact that it's technically still `start` even tho it's behaving as `end` won't be visible. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10049 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tcaptan-cr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-overflow-3] Clarify that scripts can also scroll a scroll container == This clarification was precipitated by an [intersection observer issue](https://github.com/w3c/IntersectionObserver/issues/521) in order to avoid confusion over who can scroll the overflow area of a scroll container. See https://github.com/w3c/csswg-drafts/pull/10048 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tcaptan-cr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-overflow-3] Clarify that scripts can also scroll a scroll container == This clarification was precipitated by an [intersection observer issue](https://github.com/w3c/IntersectionObserver/issues/521) in order to avoid confusion over who can scroll the overflow area of a scroll container. See https://github.com/w3c/csswg-drafts/pull/10048 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tcaptan-cr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-overflow-3] Clarify that scripts can also scroll a scroll container == This clarification was precipitated by an [intersection observer issue](https://github.com/w3c/IntersectionObserver/issues/521) in order to avoid confusion over who can scroll the overflow area of a scroll container. See https://github.com/w3c/csswg-drafts/pull/10048 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tcaptan-cr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-overflow-3] Clarify that scripts can also scroll a scroll container == This clarification was precipitated by an [intersection observer issue](https://github.com/w3c/IntersectionObserver/issues/521) in order to avoid confusion over who can scroll the overflow area of a scroll container. See https://github.com/w3c/csswg-drafts/pull/10048 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
After discussing with Tab, I think it's just an editorial issue. Using the term 'output' in both contexts is maybe a bit confusing. The result of the cascade is a sorted list of declared values based on precedence. If not empty, the top of that list is the single cascaded value. -- GitHub Notification of comment by mirisuzanne Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9998#issuecomment-1984565209 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
For consistency with `background-origin` I would say no, it doesn't apply... but I guess it could be useful? (See https://fantasai.inkedblade.net/style/discuss/table-backgrounds/ for some of the discussion leading up to this painting model, btw.) -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9916#issuecomment-1984469333 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
For consistency with `background-origin` I would say no, it doesn't apply... but I guess it could be useful? (See https://fantasai.inkedblade.net/style/discuss/table-backgrounds/ for some of the discussion leading up to this painting model, btw.) -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9916#issuecomment-1984469333 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dshin-moz has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-cascade-6] Absolutize Relative Selector Syntax within `@scope`? == [CSS Nesting](https://drafts.csswg.org/css-nesting/#cssom) spec explicitly absolutizes any use of relative selector syntax by inserting `&`. Seems consistent, then, to absolutize relative selector uses in `@scope` by inserting `:scope`. By extension (Since we're [treating it like](https://drafts.csswg.org/css-cascade-6/#scope-limits) scoped style rules), `<scope-end>` should do the same, if the relative selector syntax is used. (Aside - `<scope-end>` is [solely defined](https://drafts.csswg.org/css-cascade-6/#typedef-scope-end) as `<forgiving-selector-list>`) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10047 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == Revert "[css-backgrounds-3] #8649 Specify ink overflow extent for box-shadow" == Reverts w3c/csswg-drafts#9823 which afaict isn't an editorial clarification, wasn't approved by an editor, and doesn't have a WG resolution... See https://github.com/w3c/csswg-drafts/pull/10046 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
nt1m has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] Simplify definition of "rendering suppression for view transitions" == > rendering suppression for view transitions a boolean. Initially false. > While a [Document](https://dom.spec.whatwg.org/#document)’s [rendering suppression for view transitions](https://www.w3.org/TR/css-view-transitions-1/#document-rendering-suppression-for-view-transitions) is true, all pointer hit testing must target its [document element](https://dom.spec.whatwg.org/#document-element), ignoring all other [elements](https://drafts.csswg.org/css2/#element). Would it be possible to define this in terms of pre-existing primitives? Something like "the document acts as if `pointer-events: none` was set on the document element". This way this can just be implemented using a simple style adjustment. cc @khushalsagar @vmpstr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10045 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
nt1m has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-1] Simplify definition of "rendering suppression for view transitions" == > rendering suppression for view transitions a boolean. Initially false. > While a [Document](https://dom.spec.whatwg.org/#document)’s [rendering suppression for view transitions](https://www.w3.org/TR/css-view-transitions-1/#document-rendering-suppression-for-view-transitions) is true, all pointer hit testing must target its [document element](https://dom.spec.whatwg.org/#document-element), ignoring all other [elements](https://drafts.csswg.org/css2/#element). Would it be possible to define this in terms of pre-existing primitives? Something like "the document acts as if `pointer-events: none` was set on the document element". This way this can just be implemented using a simple style adjustment. cc @khushalsagar @vmpstr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10045 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
jfkthame has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-text-decor-4] Computed value of text-decoration-thickness == According to the current draft, the computed value of `text-decoration-thickness` is "specified keyword or absolute length", which implies that percentages must be resolved to lengths in the computed value. This seems to be at odds with the note just below, which says that > A percentage will inherit as a relative value, and will therefore scale with changes in the font as it inherits. If percentages were retained in the computed value, this would occur naturally, but with the computed value being an absolute length, inheritance seems to be a special case. So was the definition of the computed value just overlooked when adding percentage support? AFAICS the current WPT test at https://wpt.live/css/css-text-decor/text-decoration-thickness-computed.html expects to see percentages retained. On the other hand, there's an animation test at https://wpt.live/css/css-text-decor/animations/text-decoration-thickness-interpolation.html that expects to see percentages resolved to absolute px lengths. If the computed-value test is correct and percentages should be retained, then shouldn't they also be interpolated as such? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10044 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
jfkthame has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-text-decor-4] Computed value of text-decoration-thickness == According to the current draft, the computed value of `text-decoration-thickness` is "specified keyword or absolute length", which implies that percentages must be resolved to lengths in the computed value. This seems to be at odds with the note just below, which says that > A percentage will inherit as a relative value, and will therefore scale with changes in the font as it inherits. If percentages were retained in the computed value, this would occur naturally, but with the computed value being an absolute length, inheritance seems to be a special case. So was the definition of the computed value just overlooked when adding percentage support? AFAICS the current WPT test at https://wpt.live/css/css-text-decor/text-decoration-thickness-computed.html expects to see percentages retained. On the other hand, there's an animation test at https://wpt.live/css/css-text-decor/animations/text-decoration-thickness-interpolation.html that expects to see percentages resolved to absolute px lengths. If the computed-value test is correct and percentages should be retained, then shouldn't they also be interpolated as such? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10044 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
jfkthame has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-text-decor-4] Computed value of text-decoration-thickness == According to the current draft, the computed value of `text-decoration-thickness` is "specified keyword or absolute length", which implies that percentages must be resolved to lengths in the computed value. This seems to be at odds with the note just below, which says that > A percentage will inherit as a relative value, and will therefore scale with changes in the font as it inherits. If percentages were retained in the computed value, this would occur naturally, but with the computed value being an absolute length, inheritance seems to be a special case. So was the definition of the computed value just overlooked when adding percentage support? AFAICS the current WPT test at https://wpt.live/css/css-text-decor/text-decoration-thickness-computed.html expects to see percentages retained. On the other hand, there's an animation test at https://wpt.live/css/css-text-decor/animations/text-decoration-thickness-interpolation.html that expects to see percentages resolved to absolute px lengths. If the computed-value test is correct and percentages should be retained, then shouldn't they also be interpolated as such? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10044 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
jfkthame has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-text-decor-4] Computed value of text-decoration-thickness == According to the current draft, the computed value of `text-decoration-thickness` is "specified keyword or absolute length", which implies that percentages must be resolved to lengths in the computed value. This seems to be at odds with the note just below, which says that > A percentage will inherit as a relative value, and will therefore scale with changes in the font as it inherits. If percentages were retained in the computed value, this would occur naturally, but with the computed value being an absolute length, inheritance seems to be a special case. So was the definition of the computed value just overlooked when adding percentage support? AFAICS the current WPT test at https://wpt.live/css/css-text-decor/text-decoration-thickness-computed.html expects to see percentages retained. On the other hand, there's an animation test at https://wpt.live/css/css-text-decor/animations/text-decoration-thickness-interpolation.html that expects to see percentages resolved to absolute px lengths. If the computed-value test is correct and percentages should be retained, then shouldn't they also be interpolated as such? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10044 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
jfkthame has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-text-decor-4] Computed value of text-decoration-thickness == According to the current draft, the computed value of `text-decoration-thickness` is "specified keyword or absolute length", which implies that percentages must be resolved to lengths in the computed value. This seems to be at odds with the note just below, which says that > A percentage will inherit as a relative value, and will therefore scale with changes in the font as it inherits. If percentages were retained in the computed value, this would occur naturally, but with the computed value being an absolute length, inheritance seems to be a special case. So was the definition of the computed value just overlooked when adding percentage support? AFAICS the current WPT test at https://wpt.live/css/css-text-decor/text-decoration-thickness-computed.html expects to see percentages retained. On the other hand, there's an animation test at https://wpt.live/css/css-text-decor/animations/text-decoration-thickness-interpolation.html that expects to see percentages resolved to absolute px lengths. If the computed-value test is correct and percentages should be retained, then shouldn't they also be interpolated as such? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10044 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
jfkthame has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-text-decor-4] Computed value of text-decoration-thickness == According to the current draft, the computed value of `text-decoration-thickness` is "specified keyword or absolute length", which implies that percentages must be resolved to lengths in the computed value. This seems to be at odds with the note just below, which says that > A percentage will inherit as a relative value, and will therefore scale with changes in the font as it inherits. If percentages were retained in the computed value, this would occur naturally, but with the computed value being an absolute length, inheritance seems to be a special case. So was the definition of the computed value just overlooked when adding percentage support? AFAICS the current WPT test at https://wpt.live/css/css-text-decor/text-decoration-thickness-computed.html expects to see percentages retained. On the other hand, there's an animation test at https://wpt.live/css/css-text-decor/animations/text-decoration-thickness-interpolation.html that expects to see percentages resolved to absolute px lengths. If the computed-value test is correct and percentages should be retained, then shouldn't they also be interpolated as such? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10044 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
jfkthame has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-text-decor-4] Computed value of text-decoration-thickness == According to the current draft, the computed value of `text-decoration-thickness` is "specified keyword or absolute length", which implies that percentages must be resolved to lengths in the computed value. This seems to be at odds with the note just below, which says that > A percentage will inherit as a relative value, and will therefore scale with changes in the font as it inherits. If percentages were retained in the computed value, this would occur naturally, but with the computed value being an absolute length, inheritance seems to be a special case. So was the definition of the computed value just overlooked when adding percentage support? AFAICS the current WPT test at https://wpt.live/css/css-text-decor/text-decoration-thickness-computed.html expects to see percentages retained. On the other hand, there's an animation test at https://wpt.live/css/css-text-decor/animations/text-decoration-thickness-interpolation.html that expects to see percentages resolved to absolute px lengths. If the computed-value test is correct and percentages should be retained, then shouldn't they also be interpolated as such? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10044 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/9759 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mirisuzanne has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-values][css-contain] Can we account for scrollbars on containers when sizing 100cq*? == In #6026 we resolved to have viewport units account for scrollbars, when `overflow:scroll` or `scrollbar-gutters:stable` is set on the root (propagating directly to viewport, not from `body`). This will also work for `cq*` units that are relative to the root (no container defined), since they default to the equivalent `sv*` units. However, authors are likely to have the same issue on non-root containers. Demo: https://codepen.io/miriamsuzanne/pen/poBjQxm?editors=1100 Would it make sense to apply our above resolution to `cq*` units anywhere that the container in question has either `overflow:scroll` or `scrollbar-gutters:stable` set? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10043 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dshin-moz has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-cascade-6] Should `@scope`'s `<scope-start>` & `<scope-end>` be unforgiving? == As per the discussion log in [making has unforgiving](https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1341347244) in issue #7676, it seemed like the forgiving behaviour was to be restricted to `:is`/`:where`. This is reflected [in the spec's note](https://drafts.csswg.org/selectors-4/#forgiving-selector). On the other hand, `<scope-start>` and `<scope-end>` currently are specified as `<forgiving-selector-list>`. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10042 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dshin-moz has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-cascade-6] Should `@scope`'s `<scope-start>` & `<scope-end>` be unforgiving? == As per the discussion log in [making has unforgiving](https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1341347244) in issue #7676, it seemed like the forgiving behaviour was to be restricted to `:is`/`:where`. This is reflected [in the spec's note](https://drafts.csswg.org/selectors-4/#forgiving-selector). On the other hand, `<scope-start>` and `<scope-end>` currently are specified as `<forgiving-selector-list>`. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10042 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dshin-moz has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-cascade-6] Should `@scope`'s `<scope-start>` & `<scope-end>` be unforgiving? == As per the discussion log in [making has unforgiving](https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1341347244) in issue #7676, it seemed like the forgiving behaviour was to be restricted to `:is`/`:where`. This is reflected [in the spec's note](https://drafts.csswg.org/selectors-4/#forgiving-selector). On the other hand, `<scope-start>` and `<scope-end>` currently are specified as `<forgiving-selector-list>`. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10042 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dshin-moz has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-cascade-6] Should `@scope`'s `<scope-start>` & `<scope-end>` be unforgiving? == As per the discussion log in [making has unforgiving](https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1341347244) in issue #7676, it seemed like the forgiving behaviour was to be restricted to `:is`/`:where`. This is reflected [in the spec's note](https://drafts.csswg.org/selectors-4/#forgiving-selector). On the other hand, `<scope-start>` and `<scope-end>` currently are specified as `<forgiving-selector-list>`. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10042 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dshin-moz has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-cascade-6] Should `@scope`'s `<scope-start>` & `<scope-end>` be unforgiving? == As per the discussion log in [making has unforgiving](https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1341347244) in issue #7676, it seemed like the forgiving behaviour was to be restricted to `:is`/`:where`. This is reflected [in the spec's note](https://drafts.csswg.org/selectors-4/#forgiving-selector). On the other hand, `<scope-start>` and `<scope-end>` currently are specified as `<forgiving-selector-list>`. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10042 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dshin-moz has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-cascade-6] Should `@scope`'s `<scope-start>` & `<scope-end>` be unforgiving? == As per the discussion log in [making has unforgiving](https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1341347244) in issue #7676, it seemed like the forgiving behaviour was to be restricted to `:is`/`:where`. This is reflected [in the spec's note](https://drafts.csswg.org/selectors-4/#forgiving-selector). On the other hand, `<scope-start>` and `<scope-end>` currently are specified as `<forgiving-selector-list>`. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10042 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dshin-moz has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-cascade-6] Should `@scope`'s `<scope-start>` & `<scope-end>` be unforgiving? == As per the discussion log in [making has unforgiving](https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1341347244) in issue #7676, it seemed like the forgiving behaviour was to be restricted to `:is`/`:where`. This is reflected [in the spec's note](https://drafts.csswg.org/selectors-4/#forgiving-selector). On the other hand, `<scope-start>` and `<scope-end>` currently are specified as `<forgiving-selector-list>`. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10042 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dshin-moz has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-cascade-6] Should `@scope`'s `<scope-start>` & `<scope-end>` be unforgiving? == As per the discussion log in [making has unforgiving](https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1341347244) in issue #7676, it seemed like the forgiving behaviour was to be restricted to `:is`/`:where`. This is reflected [in the spec's note](https://drafts.csswg.org/selectors-4/#forgiving-selector). On the other hand, `<scope-start>` and `<scope-end>` currently are specified as `<forgiving-selector-list>`. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10042 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dshin-moz has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-cascade-6] Should `@scope`'s `<scope-start>` & `<scope-end>` be unforgiving? == As per the discussion log in [making has unforgiving](https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1341347244) in issue #7676, it seemed like the forgiving behaviour was to be restricted to `:is`/`:where`. This is reflected [in the spec's note](https://drafts.csswg.org/selectors-4/#forgiving-selector). On the other hand, `<scope-start>` and `<scope-end>` currently are specified as `<forgiving-selector-list>`. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10042 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dshin-moz has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-cascade-6] Should `@scope`'s `<scope-start>` & `<scope-end>` be unforgiving? == As per the discussion log in [making has unforgiving](https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1341347244) in issue #7676, it seemed like the forgiving behaviour was to be restricted to `:is`/`:where`. This is reflected [in the spec's note](https://drafts.csswg.org/selectors-4/#forgiving-selector). On the other hand, `<scope-start>` and `<scope-end>` currently are specified as `<forgiving-selector-list>`. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10042 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
So from a spec perspective, it seems there is nothing further to do here. WPT have been added or corrected. Chrome has changed their implementation. @danburzo @mysteryDate close? -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9759#issuecomment-1983656303 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
So from a spec perspective, it seems there is nothing further to do here. WPT have been added or corrected. Chrome has changed their implementation. @danburzo @mysteryDate close? -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9759#issuecomment-1983656303 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-5] Relative color syntax channel keyword multiplication with percentages == `<number> * <percentage>` works in Chrome: ```css oklch(from red calc(1 * 50%) c h) ``` `l * <percentage>` doesn't work in Chrome. ```css oklch(from red calc(l * 50%) c h) ``` https://codepen.io/romainmenke/pen/PogPgmV @svgeesus This is mostly just a sanity check. As far as I know there isn't anything special here and multiplying channel keywords by percentages should just work. If so, I will file the needed bugs and add more WPT tests. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10041 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-5] Relative color syntax channel keyword multiplication with percentages == `<number> * <percentage>` works in Chrome: ```css oklch(from red calc(1 * 50%) c h) ``` `l * <percentage>` doesn't work in Chrome. ```css oklch(from red calc(l * 50%) c h) ``` https://codepen.io/romainmenke/pen/PogPgmV @svgeesus This is mostly just a sanity check. As far as I know there isn't anything special here and multiplying channel keywords by percentages should just work. If so, I will file the needed bugs and add more WPT tests. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10041 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-5] Relative color syntax channel keyword multiplication with percentages == `<number> * <percentage>` works in Chrome: ```css oklch(from red calc(1 * 50%) c h) ``` `l * <percentage>` doesn't work in Chrome. ```css oklch(from red calc(l * 50%) c h) ``` https://codepen.io/romainmenke/pen/PogPgmV @svgeesus This is mostly just a sanity check. As far as I know there isn't anything special here and multiplying channel keywords by percentages should just work. If so, I will file the needed bugs and add more WPT tests. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10041 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-5] Relative color syntax channel keyword multiplication with percentages == `<number> * <percentage>` works in Chrome: ```css oklch(from red calc(1 * 50%) c h) ``` `l * <percentage>` doesn't work in Chrome. ```css oklch(from red calc(l * 50%) c h) ``` https://codepen.io/romainmenke/pen/PogPgmV @svgeesus This is mostly just a sanity check. As far as I know there isn't anything special here and multiplying channel keywords by percentages should just work. If so, I will file the needed bugs and add more WPT tests. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10041 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-5] Relative color syntax channel keyword multiplication with percentages == `<number> * <percentage>` works in Chrome: ```css oklch(from red calc(1 * 50%) c h) ``` `l * <percentage>` doesn't work in Chrome. ```css oklch(from red calc(l * 50%) c h) ``` https://codepen.io/romainmenke/pen/PogPgmV @svgeesus This is mostly just a sanity check. As far as I know there isn't anything special here and multiplying channel keywords by percentages should just work. If so, I will file the needed bugs and add more WPT tests. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10041 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-5] Relative color syntax channel keyword multiplication with percentages == `<number> * <percentage>` works in Chrome: ```css oklch(from red calc(1 * 50%) c h) ``` `l * <percentage>` doesn't work in Chrome. ```css oklch(from red calc(l * 50%) c h) ``` https://codepen.io/romainmenke/pen/PogPgmV @svgeesus This is mostly just a sanity check. As far as I know there isn't anything special here and multiplying channel keywords by percentages should just work. If so, I will file the needed bugs and add more WPT tests. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10041 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Agreed that value `none` should be animated discretely for syntaxes `none|<transform-list>` or `none|<transform-function>`, but I think `none` should be interpolated for syntaxes `<transform-list>|none` or `<transform-function>|none`. From css-properties-values-api <[https://github.com/w3c/css-houdini-drafts/blob/808c87a30bea/css-properties-values-api/Overview.bs#L306-L308](https://github.com/w3c/css-houdini-drafts/blob/808c87a30bea/css-properties-values-api/Overview.bs#L306-L308)>: > For syntaxes specified with the | combinator, the computed value is given by applying the computed-value rules for the first clause that matches the value. If so, the expectations for WPT <[https://github.com/web-platform-tests/wpt/blob/1a18de6ee35d/css/css-properties-values-api/animation/custom-property-animation-transform-none.tentative.html](https://github.com/web-platform-tests/wpt/blob/1a18de6ee35d/css/css-properties-values-api/animation/custom-property-animation-transform-none.tentative.html)> should be updated, and testcases added for syntaxes `none|<transform-list>` and `none|<transform-function>`. -- GitHub Notification of comment by zrhoffman Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9522#issuecomment-1982821648 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Agreed that value `none` should be animated discretely for syntaxes `none|<transform-list>` or `none|<transform-function>`, but I think `none` should be interpolated for syntaxes `<transform-list>|none` or `<transform-function>|none`. From css-properties-values-api <[https://github.com/w3c/css-houdini-drafts/blob/808c87a30bea/css-properties-values-api/Overview.bs#L306-L308](https://github.com/w3c/css-houdini-drafts/blob/808c87a30bea/css-properties-values-api/Overview.bs#L306-L308)>: > For syntaxes specified with the | combinator, the computed value is given by applying the computed-value rules for the first clause that matches the value. If so, the expectations for WPT <[https://github.com/web-platform-tests/wpt/blob/1a18de6ee35d/css/css-properties-values-api/animation/custom-property-animation-transform-none.tentative.html](https://github.com/web-platform-tests/wpt/blob/1a18de6ee35d/css/css-properties-values-api/animation/custom-property-animation-transform-none.tentative.html)> should be updated, and testcases added for syntaxes `none|<transform-list>` and `none|<transform-function>`. -- GitHub Notification of comment by zrhoffman Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9522#issuecomment-1982821648 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Agreed that value `none` should be animated discretely for syntaxes `none|<transform-list>` or `none|<transform-function>`, but I think `none` should be interpolated for syntaxes `<transform-list>|none` or `<transform-function>|none`. From css-properties-values-api <[https://github.com/w3c/css-houdini-drafts/blob/808c87a30bea/css-properties-values-api/Overview.bs#L306-L308](https://github.com/w3c/css-houdini-drafts/blob/808c87a30bea/css-properties-values-api/Overview.bs#L306-L308)>: > For syntaxes specified with the | combinator, the computed value is given by applying the computed-value rules for the first clause that matches the value. If so, the expectations for WPT <[https://github.com/web-platform-tests/wpt/blob/1a18de6ee35d/css/css-properties-values-api/animation/custom-property-animation-transform-none.tentative.html](https://github.com/web-platform-tests/wpt/blob/1a18de6ee35d/css/css-properties-values-api/animation/custom-property-animation-transform-none.tentative.html)> should be updated, and testcases added for syntaxes `none|<transform-list>` and `none|<transform-function>`. -- GitHub Notification of comment by zrhoffman Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9522#issuecomment-1982821648 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Agreed that value `none` should be animated discretely for syntaxes `none|<transform-list>` or `none|<transform-function>`, but I think `none` should be interpolated for syntaxes `<transform-list>|none` or `<transform-function>|none`. From css-properties-values-api <[https://github.com/w3c/css-houdini-drafts/blob/808c87a30bea/css-properties-values-api/Overview.bs#L306-L308](https://github.com/w3c/css-houdini-drafts/blob/808c87a30bea/css-properties-values-api/Overview.bs#L306-L308)>: > For syntaxes specified with the | combinator, the computed value is given by applying the computed-value rules for the first clause that matches the value. If so, the expectations for WPT <[https://github.com/web-platform-tests/wpt/blob/1a18de6ee35d/css/css-properties-values-api/animation/custom-property-animation-transform-none.tentative.html](https://github.com/web-platform-tests/wpt/blob/1a18de6ee35d/css/css-properties-values-api/animation/custom-property-animation-transform-none.tentative.html)> should be updated, and testcases added for syntaxes `none|<transform-list>` and `none|<transform-function>`. -- GitHub Notification of comment by zrhoffman Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9522#issuecomment-1982821648 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Agreed that value `none` should be animated discretely for syntaxes `none|<transform-list>` or `none|<transform-function>`, but I think `none` should be interpolated for syntaxes `<transform-list>|none` or `<transform-function>|none`. From css-properties-values-api <[https://github.com/w3c/css-houdini-drafts/blob/808c87a30bea/css-properties-values-api/Overview.bs#L306-L308](https://github.com/w3c/css-houdini-drafts/blob/808c87a30bea/css-properties-values-api/Overview.bs#L306-L308)>: > For syntaxes specified with the | combinator, the computed value is given by applying the computed-value rules for the first clause that matches the value. If so, the expectations for WPT <[https://github.com/web-platform-tests/wpt/blob/1a18de6ee35d/css/css-properties-values-api/animation/custom-property-animation-transform-none.tentative.html](https://github.com/web-platform-tests/wpt/blob/1a18de6ee35d/css/css-properties-values-api/animation/custom-property-animation-transform-none.tentative.html)> should be updated, and testcases added for syntaxes `none|<transform-list>` and `none|<transform-function>`. -- GitHub Notification of comment by zrhoffman Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9522#issuecomment-1982821648 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Agreed that value `none` should be animated discretely for syntaxes `none|<transform-list>` or `none|<transform-function>`, but I think `none` should be interpolated for syntaxes `<transform-list>|none` or `<transform-function>|none`. From css-properties-values-api <[https://github.com/w3c/css-houdini-drafts/blob/808c87a30bea/css-properties-values-api/Overview.bs#L306-L308](https://github.com/w3c/css-houdini-drafts/blob/808c87a30bea/css-properties-values-api/Overview.bs#L306-L308)>: > For syntaxes specified with the | combinator, the computed value is given by applying the computed-value rules for the first clause that matches the value. If so, the expectations for WPT <[https://github.com/web-platform-tests/wpt/blob/1a18de6ee35d/css/css-properties-values-api/animation/custom-property-animation-transform-none.tentative.html](https://github.com/web-platform-tests/wpt/blob/1a18de6ee35d/css/css-properties-values-api/animation/custom-property-animation-transform-none.tentative.html)> should be updated, and testcases added for syntaxes `none|<transform-list>` and `none|<transform-function>`. -- GitHub Notification of comment by zrhoffman Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9522#issuecomment-1982821648 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Agreed that value `none` should be animated discretely for syntaxes `none|<transform-list>` or `none|<transform-function>`, but I think `none` should be interpolated for syntaxes `<transform-list>|none` or `<transform-function>|none`. From css-properties-values-api <[https://github.com/w3c/css-houdini-drafts/blob/808c87a30bea/css-properties-values-api/Overview.bs#L306-L308](https://github.com/w3c/css-houdini-drafts/blob/808c87a30bea/css-properties-values-api/Overview.bs#L306-L308)>: > For syntaxes specified with the | combinator, the computed value is given by applying the computed-value rules for the first clause that matches the value. If so, the expectations for WPT <[https://github.com/web-platform-tests/wpt/blob/1a18de6ee35d/css/css-properties-values-api/animation/custom-property-animation-transform-none.tentative.html](https://github.com/web-platform-tests/wpt/blob/1a18de6ee35d/css/css-properties-values-api/animation/custom-property-animation-transform-none.tentative.html)> should be updated, and testcases added for syntaxes `none|<transform-list>` and `none|<transform-function>`. -- GitHub Notification of comment by zrhoffman Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9522#issuecomment-1982821648 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed `[css-writing-modes] spacing within text-combine-upright`, and agreed to the following: * `RESOLVED: All of the text spacing properties don't apply to the squished-together character of t-c-u; text-spacing-trim is treated as trim-all` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> fantasai: there's a feature text-combing-upright which causes glyphs in upright vertical text to combine into a single combined block<br> <TabAtkins> like if you want "23" it'll smush into one block<br> <TabAtkins> fantasai: we specify that letter-spacing doesn't apply inside the smushed box, we treat it like a single character<br> <TabAtkins> fantasai: we didn't specify the other spacing properties, like word-spacing<br> <TabAtkins> fantasai: Proposal is we ignore all of them<br> <TabAtkins> fantasai: and for text-spacing-trim we treat it as trim-all<br> <TabAtkins> fantasai: generally you won't run into these sitautions anyway, but if you do you probably dont' want extra space making it even more squished<br> <TabAtkins> florian: I initially thought we wanted some optoins here, but on further thought i think we don't, and that fantasai is right<br> <TabAtkins> +1<br> <TabAtkins> Rossen_: objections?<br> <fantasai> illustration -> https://www.w3.org/TR/css-writing-modes-4/images/tate-chu-yoko.png<br> <TabAtkins> RESOLVED: All of the text spacing properties don't apply to the squished-together character of t-c-u; text-spacing-trim is treated as trim-all<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9423#issuecomment-1982147003 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed `[css-writing-modes] spacing within text-combine-upright`, and agreed to the following: * `RESOLVED: All of the text spacing properties don't apply to the squished-together character of t-c-u; text-spacing-trim is treated as trim-all` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> fantasai: there's a feature text-combing-upright which causes glyphs in upright vertical text to combine into a single combined block<br> <TabAtkins> like if you want "23" it'll smush into one block<br> <TabAtkins> fantasai: we specify that letter-spacing doesn't apply inside the smushed box, we treat it like a single character<br> <TabAtkins> fantasai: we didn't specify the other spacing properties, like word-spacing<br> <TabAtkins> fantasai: Proposal is we ignore all of them<br> <TabAtkins> fantasai: and for text-spacing-trim we treat it as trim-all<br> <TabAtkins> fantasai: generally you won't run into these sitautions anyway, but if you do you probably dont' want extra space making it even more squished<br> <TabAtkins> florian: I initially thought we wanted some optoins here, but on further thought i think we don't, and that fantasai is right<br> <TabAtkins> +1<br> <TabAtkins> Rossen_: objections?<br> <fantasai> illustration -> https://www.w3.org/TR/css-writing-modes-4/images/tate-chu-yoko.png<br> <TabAtkins> RESOLVED: All of the text spacing properties don't apply to the squished-together character of t-c-u; text-spacing-trim is treated as trim-all<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9423#issuecomment-1982147003 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed `[css-writing-modes] spacing within text-combine-upright`, and agreed to the following: * `RESOLVED: All of the text spacing properties don't apply to the squished-together character of t-c-u; text-spacing-trim is treated as trim-all` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> fantasai: there's a feature text-combing-upright which causes glyphs in upright vertical text to combine into a single combined block<br> <TabAtkins> like if you want "23" it'll smush into one block<br> <TabAtkins> fantasai: we specify that letter-spacing doesn't apply inside the smushed box, we treat it like a single character<br> <TabAtkins> fantasai: we didn't specify the other spacing properties, like word-spacing<br> <TabAtkins> fantasai: Proposal is we ignore all of them<br> <TabAtkins> fantasai: and for text-spacing-trim we treat it as trim-all<br> <TabAtkins> fantasai: generally you won't run into these sitautions anyway, but if you do you probably dont' want extra space making it even more squished<br> <TabAtkins> florian: I initially thought we wanted some optoins here, but on further thought i think we don't, and that fantasai is right<br> <TabAtkins> +1<br> <TabAtkins> Rossen_: objections?<br> <fantasai> illustration -> https://www.w3.org/TR/css-writing-modes-4/images/tate-chu-yoko.png<br> <TabAtkins> RESOLVED: All of the text spacing properties don't apply to the squished-together character of t-c-u; text-spacing-trim is treated as trim-all<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9423#issuecomment-1982147003 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed `[css-writing-modes] spacing within text-combine-upright`, and agreed to the following: * `RESOLVED: All of the text spacing properties don't apply to the squished-together character of t-c-u; text-spacing-trim is treated as trim-all` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> fantasai: there's a feature text-combing-upright which causes glyphs in upright vertical text to combine into a single combined block<br> <TabAtkins> like if you want "23" it'll smush into one block<br> <TabAtkins> fantasai: we specify that letter-spacing doesn't apply inside the smushed box, we treat it like a single character<br> <TabAtkins> fantasai: we didn't specify the other spacing properties, like word-spacing<br> <TabAtkins> fantasai: Proposal is we ignore all of them<br> <TabAtkins> fantasai: and for text-spacing-trim we treat it as trim-all<br> <TabAtkins> fantasai: generally you won't run into these sitautions anyway, but if you do you probably dont' want extra space making it even more squished<br> <TabAtkins> florian: I initially thought we wanted some optoins here, but on further thought i think we don't, and that fantasai is right<br> <TabAtkins> +1<br> <TabAtkins> Rossen_: objections?<br> <fantasai> illustration -> https://www.w3.org/TR/css-writing-modes-4/images/tate-chu-yoko.png<br> <TabAtkins> RESOLVED: All of the text spacing properties don't apply to the squished-together character of t-c-u; text-spacing-trim is treated as trim-all<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9423#issuecomment-1982147003 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed ``[css-contain-2]: Should the first `contentvisibilityautostatechange` event be fired without knowing if the element is close to the viewport``, and agreed to the following: * `RESOLVED: if a c-v:auto element is skipping its contents but has not yet determined its visiblity, don't fire the contentvisibilityautostatechange event until you do know the visibility` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> vmpstr: we have an even tthat fires when content-visibility:auto state changes (form skipped to not skipped, or vice versa)<br> <TabAtkins> vmpstr: question, what to do if we haven't determined visibility for the element yet<br> <TabAtkins> vmpstr: can happen if we add the c-v:auto then force rendering<br> <TabAtkins> vmpstr: visibility is done at IO timing, so not done yet<br> <TabAtkins> vmpstr: naively we'd fire an event that says "it's skipped" then at IO time we fire another saying "it's visible", two events in rapid succession<br> <TabAtkins> vmpstr: filer of the issue suggests we just don't fire the event until we've actually had a chance to determine the visibility<br> <TabAtkins> +1, makes sense to me<br> <TabAtkins> vmpstr: one extra - "unless there's something else making the element relevant to the user", then we already know it's relevant and fire it immeidately<br> <TabAtkins> vmpstr: so if the element is skipping its ocntents but we haven't determined its visibility yet, don't fire the event<br> <chrishtr> +1 to the resolution<br> <TabAtkins> RESOLVED: if a c-v:auto element is skipping its contents but has not yet determined its visiblity, don't fire the contentvisibilityautostatechange event until you do know the visibility<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9803#issuecomment-1982144136 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Given the resolution here https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1982118477 I believe we have opted-in to the tooling pain of using semicolons as delimiters -- GitHub Notification of comment by astearns Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6705#issuecomment-1982144045 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed `[CSS Pseudo] Revisit CSS Custom Properties in highlight pseudos`, and agreed to the following: * `RESOLVED: custom properties don't apply to the highlight pseudos. On highlight pseudos, the var() function takes from the originating element.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> schenney: I filed this base don two things<br> <TabAtkins> schenney: first, one of the ocmments on the bug report when we tried to enable the highlight inheritacne chain<br> <TabAtkins> schenney: someone in a tool was setting ac ustom property on ::selection on every element, expected it to use the custom prop from the element<br> <TabAtkins> schenney: seconds, when I looked at SO about the ::selection pseudo, there was at least one answer that ende dup saying "just use custom props for your selection pseudo"<br> <TabAtkins> schenney: so this appears to already be a big beahvior, custom properties driving selection behavior<br> <TabAtkins> schenney: previous browser behavior, this *was* the correct way to do it - customs would inherit thru the originating element chain<br> <TabAtkins> schenney: So I propose we change the spec to also inherit custom props from originating elements<br> <TabAtkins> schenney: This may be grat for devs, but it poses problems for impl and spec<br> <TabAtkins> schenney: First, at minimum it's a memory hog, you have to copy custom props onto all your selection pseudos.<br> <TabAtkins> schenney: every time the property set changes you have to reallocate a new custom property set for the element<br> <TabAtkins> schenney: second, what do you do when a custom prop is defined in both the highlight inheritance chain *and* the originating element?<br> <TabAtkins> schenney: "correct" answer dpeends on context, hard to spec a reasonable behavior<br> <TabAtkins> schenney: So in hindsight I think we shouldn't make the change. But a lot of webdevs have come in and said we *shoudl* make it.<br> <TabAtkins> schenney: So, is there anything sensible to do about when there's clashing declarations?<br> <Rossen_> ack fantasai<br> <TabAtkins> fantasai: I think one thing suggested in the thread which is fairly simple is to have "normal" properties inherit thru highlihgt chain, but take custom properties from the originating element<br> <TabAtkins> fantasai: and *only* the originating element<br> <TabAtkins> fantasai: so you can't set custom props on an article::selection and have that visible to a span::selection<br> <schenney> q+<br> <TabAtkins> fantasai: but you can set it on `article` and inherit to the span, and then it'll be visible in span::selection<br> <TabAtkins> fantasai: I don't like an interleaved where it's inherited from two places at once, but I think in this limited case it's okay. The entire set of normal and the entire set of custom each have a single place to inherit from<br> <TabAtkins> schenney: I think that's equivalent to saying custom prop defined on highlights are ignored?<br> <TabAtkins> fantasai: No. We *could* define it that way and it probably woulodn't break much. But we could also still allow highlights set on you to win, and just inherit from the element.<br> <TabAtkins> fantasai: but maybe that causes more problems<br> <Rossen_> ack schenney<br> <TabAtkins> schenney: Right, you'd have to say they apply to the element it's set on but not inherited... that causes issues. Simpler to just not allow it<br> <TabAtkins> fantasai: yeah<br> <TabAtkins> schenney: I think this is probably fine.<br> <TabAtkins> schenney: So do we do this for just ::selection or all the highlight pseudos?<br> <TabAtkins> fantasai: all, i think<br> <TabAtkins> schenney: yeah, for consistency<br> <TabAtkins> fantasai: And the same arguments apply for the other highlights too<br> <TabAtkins> schenney: I think there's not enough usage to really draw conclusions from on the other types yet<br> <TabAtkins> fantasai: Lea mentioned wanting to do syntax highlighting with highlight pseudos<br> <TabAtkins> fantasai: being able to use variables with them would be useful<br> <TabAtkins> schenney: syntax highlighting does seem to be the primary usecase for highlights, especially for perf, agreement<br> <TabAtkins> schenney: so proposed resolution: custom properties are disallowed in highlight pseudo-elements. they inherit from the originating element.<br> <dandclark> q+<br> <fantasai> fantasai: would that work for Lea's use case?<br> <fantasai> TabAtkins: yes, because she sets the theme colors on the originating elmeents<br> <TabAtkins> schenney: i think the only difference practically is if you change the custom prop on the originating element chain, in a way that's out-of-sync with how you change the highlight "pseudo-classes" on the chain<br> <TabAtkins> schenney: that's the only way to get into trouble<br> <TabAtkins> dandclark: i was thrown off by Lea's example, it seems you can make it work with either proposal<br> <TabAtkins> dandclark: I think our main concern was not breaking old code relying on the current browser behavior<br> <TabAtkins> schenney: I think that's right<br> <TabAtkins> schenney: My primary motivation is that people currently do a lot of custom properties on the elements and expect it to be visible to the selection. allowing that really increases the likelihood we can actually ship<br> <TabAtkins> dandclark: we are changing long-standing beahvior by changing the selection behavior at all, what's the bar for us to know if it's shippable?<br> <TabAtkins> dandclark: when we switched to inherit custom props from root we got some reports of real breakage, like form github<br> <TabAtkins> dandclark: It sounds like what i'm hearing is that it's not too bad to just inherit the custom props, perfwise<br> <TabAtkins> schenney: from a perf perspective, as long as we don't allow custom props to actually be set on the highlight itself, then from a code compelxity perspective it works fine<br> <TabAtkins> schenney: in trying to launch highlihgts in chromium, we've run into this issue, and people relying on the fact that they could change the selection for just one type of element and explicitly not ahve it inherited<br> <TabAtkins> schenney: But that second one has been fixed in the msot important sites affected by it, so i think with this change we'll have a good chance of shipping the fixes<br> <Rossen_> ack dandclark<br> <TabAtkins> fantasai: So the proposal is custom props don't apply to highlight pseudos. The var() function takes from the originating element<br> <TabAtkins> vmpstr: clarify on var() - that "takes from originating" is just for the highlight pseudos, not in general, right?<br> <TabAtkins> TabAtkins: yes<br> <TabAtkins> RESOLVED: custom properties don't apply to the highlight pseudos. On highlight pseudos, the var() function takes from the originating element.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9909#issuecomment-1982141005 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Just mentioned in the call, but to highlight this, the argument against bare parentheses is in the first comment above: > (I'm rejecting using naked () for the same reason we ended up switching away from them for grid lines - it would mess up Sass syntax, and possibly others, hardcore, since in Sass it indicates math. I'm rejecting {} for "naive userland tools" reasons; again, many just split the text with regexes, and stray {} can screw them up. They're already potentially broken for custom props containing these chars, of course, but that's not an official Part Of CSS like this would be.) -- GitHub Notification of comment by astearns Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1982093669 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Just mentioned in the call, but to highlight this, the argument against bare parentheses is in the first comment above: > (I'm rejecting using naked () for the same reason we ended up switching away from them for grid lines - it would mess up Sass syntax, and possibly others, hardcore, since in Sass it indicates math. I'm rejecting {} for "naive userland tools" reasons; again, many just split the text with regexes, and stray {} can screw them up. They're already potentially broken for custom props containing these chars, of course, but that's not an official Part Of CSS like this would be.) -- GitHub Notification of comment by astearns Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1982093669 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Just mentioned in the call, but to highlight this, the argument against bare parentheses is in the first comment above: > (I'm rejecting using naked () for the same reason we ended up switching away from them for grid lines - it would mess up Sass syntax, and possibly others, hardcore, since in Sass it indicates math. I'm rejecting {} for "naive userland tools" reasons; again, many just split the text with regexes, and stray {} can screw them up. They're already potentially broken for custom props containing these chars, of course, but that's not an official Part Of CSS like this would be.) -- GitHub Notification of comment by astearns Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1982093669 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Just mentioned in the call, but to highlight this, the argument against bare parentheses is in the first comment above: > (I'm rejecting using naked () for the same reason we ended up switching away from them for grid lines - it would mess up Sass syntax, and possibly others, hardcore, since in Sass it indicates math. I'm rejecting {} for "naive userland tools" reasons; again, many just split the text with regexes, and stray {} can screw them up. They're already potentially broken for custom props containing these chars, of course, but that's not an official Part Of CSS like this would be.) -- GitHub Notification of comment by astearns Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1982093669 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed `[css-values] Use of 100vw is causing pointless horizontal scrollbars on some websites`. <details><summary>The full IRC log of that discussion</summary> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6026#issuecomment-1982075435 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
+1 to keeping them - can also use .optional instead of .tentative if needed. -- GitHub Notification of comment by bfgeek Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9856#issuecomment-1981928167 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
+1 to keeping them - can also use .optional instead of .tentative if needed. -- GitHub Notification of comment by bfgeek Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9856#issuecomment-1981928167 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
+1 to keeping them - can also use .optional instead of .tentative if needed. -- GitHub Notification of comment by bfgeek Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9856#issuecomment-1981928167 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
+1 to keeping them - can also use .optional instead of .tentative if needed. -- GitHub Notification of comment by bfgeek Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9856#issuecomment-1981928167 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
+1 to keeping them - can also use .optional instead of .tentative if needed. -- GitHub Notification of comment by bfgeek Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9856#issuecomment-1981928167 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@rachelandrew there are requests for further changes from @fantasai are you able to make those changes? Or (given the long time since this PR was opened, and that other illustrations have been added meanwhile) should this PR be closed? The changes in https://github.com/w3c/csswg-drafts/pull/1066#issuecomment-319973888 look good to me personally, but I am not one of the editors. Also closing/re-opening just to kick the bot into action -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/1066#issuecomment-1981926320 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/4154 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/4154 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/4154 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@tantek thanks for the review! @frivoal This PR from 2019 has of course accumulated merge conflicts in the interim. Could you rebase or otherwise handle these, so it can be merged? -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/4212#issuecomment-1981894124 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@tantek thanks for the review! @frivoal This PR from 2019 has of course accumulated merge conflicts in the interim. Could you rebase or otherwise handle these, so it can be merged? -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/4212#issuecomment-1981894124 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/9862 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/9862 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Has there been any further discussion on the anatomy of a range input given these new ::track and ::thumb (assuming https://github.com/w3c/csswg-drafts/issues/9830) and ::fill (::slider-fill?) pseudos? As far as I understand there's still the issue that WebKit (and blink) differ from Gecko's arrangment of the track, thumb, and fill? -- GitHub Notification of comment by lukewarlow Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4410#issuecomment-1981741415 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Has there been any further discussion on the anatomy of a range input given these new ::track and ::thumb (assuming https://github.com/w3c/csswg-drafts/issues/9830) and ::fill (::slider-fill?) pseudos? As far as I understand there's still the issue that WebKit (and blink) differ from Gecko's arrangment of the track, thumb, and fill? -- GitHub Notification of comment by lukewarlow Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4410#issuecomment-1981741415 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Has there been any further discussion on the anatomy of a range input given these new ::track and ::thumb (assuming https://github.com/w3c/csswg-drafts/issues/9830) and ::fill (::slider-fill?) pseudos? As far as I understand there's still the issue that WebKit (and blink) differ from Gecko's arrangment of the track, thumb, and fill? -- GitHub Notification of comment by lukewarlow Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4410#issuecomment-1981741415 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Has there been any further discussion on the anatomy of a range input given these new ::track and ::thumb (assuming https://github.com/w3c/csswg-drafts/issues/9830) and ::fill (::slider-fill?) pseudos? As far as I understand there's still the issue that WebKit (and blink) differ from Gecko's arrangment of the track, thumb, and fill? -- GitHub Notification of comment by lukewarlow Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4410#issuecomment-1981741415 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mirisuzanne has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-contain-3][css-anchor-position-1] Containment makes it difficult to use anchor positioning with container queries == Currently, container queries rely on several types of containment: `size`, `layout`, and `style`. This already causes some confusion with authors, when fixed-position elements nested in a container are now _fixed to the container_ rather than the viewport (thanks to layout containment). That issue will become much more noticeable when container queries interact with anchor positioning. As currently defined, `layout` and `style` containment will make it impossible for elements to anchor across different containers. I think that will mean: - Positioned elements outside a container cannot see anchors inside a container, since `style` containment scopes the anchor name. - Positioned elements inside a container cannot use an anchor outside the container, since `layout` containment doesn't allow reference to external layout? (I'm less clear on the interaction here) While these decisions all make sense in terms of 'the promise' that each containment makes, it will cause a lot of problems for users who want to use both container queries and anchor positioning. Authors should be able to use these features without one constantly interfering with the other. Since container queries are somewhat abstracted away from containment (we set a `container-type`, and browsers apply containment _as-needed_), I think the only path forward here is defining more subtle and targeted containment rules for container queries. Are there ways that we can relax _how much_ layout and style containment is required to make container size queries work? /cc @tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10040 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mirisuzanne has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-contain-3][css-anchor-position-1] Containment makes it difficult to use anchor positioning with container queries == Currently, container queries rely on several types of containment: `size`, `layout`, and `style`. This already causes some confusion with authors, when fixed-position elements nested in a container are now _fixed to the container_ rather than the viewport (thanks to layout containment). That issue will become much more noticeable when container queries interact with anchor positioning. As currently defined, `layout` and `style` containment will make it impossible for elements to anchor across different containers. I think that will mean: - Positioned elements outside a container cannot see anchors inside a container, since `style` containment scopes the anchor name. - Positioned elements inside a container cannot use an anchor outside the container, since `layout` containment doesn't allow reference to external layout? (I'm less clear on the interaction here) While these decisions all make sense in terms of 'the promise' that each containment makes, it will cause a lot of problems for users who want to use both container queries and anchor positioning. Authors should be able to use these features without one constantly interfering with the other. Since container queries are somewhat abstracted away from containment (we set a `container-type`, and browsers apply containment _as-needed_), I think the only path forward here is defining more subtle and targeted containment rules for container queries. Are there ways that we can relax _how much_ layout and style containment is required to make container size queries work? /cc @tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10040 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mirisuzanne has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-contain-3][css-anchor-position-1] Containment makes it difficult to use anchor positioning with container queries == Currently, container queries rely on several types of containment: `size`, `layout`, and `style`. This already causes some confusion with authors, when fixed-position elements nested in a container are now _fixed to the container_ rather than the viewport (thanks to layout containment). That issue will become much more noticeable when container queries interact with anchor positioning. As currently defined, `layout` and `style` containment will make it impossible for elements to anchor across different containers. I think that will mean: - Positioned elements outside a container cannot see anchors inside a container, since `style` containment scopes the anchor name. - Positioned elements inside a container cannot use an anchor outside the container, since `layout` containment doesn't allow reference to external layout? (I'm less clear on the interaction here) While these decisions all make sense in terms of 'the promise' that each containment makes, it will cause a lot of problems for users who want to use both container queries and anchor positioning. Authors should be able to use these features without one constantly interfering with the other. Since container queries are somewhat abstracted away from containment (we set a `container-type`, and browsers apply containment _as-needed_), I think the only path forward here is defining more subtle and targeted containment rules for container queries. Are there ways that we can relax _how much_ layout and style containment is required to make container size queries work? /cc @tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10040 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mirisuzanne has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-contain-3][css-anchor-position-1] Containment makes it difficult to use anchor positioning with container queries == Currently, container queries rely on several types of containment: `size`, `layout`, and `style`. This already causes some confusion with authors, when fixed-position elements nested in a container are now _fixed to the container_ rather than the viewport (thanks to layout containment). That issue will become much more noticeable when container queries interact with anchor positioning. As currently defined, `layout` and `style` containment will make it impossible for elements to anchor across different containers. I think that will mean: - Positioned elements outside a container cannot see anchors inside a container, since `style` containment scopes the anchor name. - Positioned elements inside a container cannot use an anchor outside the container, since `layout` containment doesn't allow reference to external layout? (I'm less clear on the interaction here) While these decisions all make sense in terms of 'the promise' that each containment makes, it will cause a lot of problems for users who want to use both container queries and anchor positioning. Authors should be able to use these features without one constantly interfering with the other. Since container queries are somewhat abstracted away from containment (we set a `container-type`, and browsers apply containment _as-needed_), I think the only path forward here is defining more subtle and targeted containment rules for container queries. Are there ways that we can relax _how much_ layout and style containment is required to make container size queries work? /cc @tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10040 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mirisuzanne has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-contain-3][css-anchor-position-1] Containment makes it difficult to use anchor positioning with container queries == Currently, container queries rely on several types of containment: `size`, `layout`, and `style`. This already causes some confusion with authors, when fixed-position elements nested in a container are now _fixed to the container_ rather than the viewport (thanks to layout containment). That issue will become much more noticeable when container queries interact with anchor positioning. As currently defined, `layout` and `style` containment will make it impossible for elements to anchor across different containers. I think that will mean: - Positioned elements outside a container cannot see anchors inside a container, since `style` containment scopes the anchor name. - Positioned elements inside a container cannot use an anchor outside the container, since `layout` containment doesn't allow reference to external layout? (I'm less clear on the interaction here) While these decisions all make sense in terms of 'the promise' that each containment makes, it will cause a lot of problems for users who want to use both container queries and anchor positioning. Authors should be able to use these features without one constantly interfering with the other. Since container queries are somewhat abstracted away from containment (we set a `container-type`, and browsers apply containment _as-needed_), I think the only path forward here is defining more subtle and targeted containment rules for container queries. Are there ways that we can relax _how much_ layout and style containment is required to make container size queries work? /cc @tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10040 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mirisuzanne has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-contain-3][css-anchor-position-1] Containment makes it difficult to use anchor positioning with container queries == Currently, container queries rely on several types of containment: `size`, `layout`, and `style`. This already causes some confusion with authors, when fixed-position elements nested in a container are now _fixed to the container_ rather than the viewport (thanks to layout containment). That issue will become much more noticeable when container queries interact with anchor positioning. As currently defined, `layout` and `style` containment will make it impossible for elements to anchor across different containers. I think that will mean: - Positioned elements outside a container cannot see anchors inside a container, since `style` containment scopes the anchor name. - Positioned elements inside a container cannot use an anchor outside the container, since `layout` containment doesn't allow reference to external layout? (I'm less clear on the interaction here) While these decisions all make sense in terms of 'the promise' that each containment makes, it will cause a lot of problems for users who want to use both container queries and anchor positioning. Authors should be able to use these features without one constantly interfering with the other. Since container queries are somewhat abstracted away from containment (we set a `container-type`, and browsers apply containment _as-needed_), I think the only path forward here is defining more subtle and targeted containment rules for container queries. Are there ways that we can relax _how much_ layout and style containment is required to make container size queries work? /cc @tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10040 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mirisuzanne has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-contain-3][css-anchor-position-1] Containment makes it difficult to use anchor positioning with container queries == Currently, container queries rely on several types of containment: `size`, `layout`, and `style`. This already causes some confusion with authors, when fixed-position elements nested in a container are now _fixed to the container_ rather than the viewport (thanks to layout containment). That issue will become much more noticeable when container queries interact with anchor positioning. As currently defined, `layout` and `style` containment will make it impossible for elements to anchor across different containers. I think that will mean: - Positioned elements outside a container cannot see anchors inside a container, since `style` containment scopes the anchor name. - Positioned elements inside a container cannot use an anchor outside the container, since `layout` containment doesn't allow reference to external layout? (I'm less clear on the interaction here) While these decisions all make sense in terms of 'the promise' that each containment makes, it will cause a lot of problems for users who want to use both container queries and anchor positioning. Authors should be able to use these features without one constantly interfering with the other. Since container queries are somewhat abstracted away from containment (we set a `container-type`, and browsers apply containment _as-needed_), I think the only path forward here is defining more subtle and targeted containment rules for container queries. Are there ways that we can relax _how much_ layout and style containment is required to make container size queries work? /cc @tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10040 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed `[css-contain][css-anchor-position-1] Should size/layout containment also contain anchor names?`, and agreed to the following: * `RESOLVED: Layout containment contains anchor names and size containment/paint containment do not` <details><summary>The full IRC log of that discussion</summary> <keithamus> TabAtkins: already in spec that style containment triggers containment of anchor names<br> <keithamus> TabAtkins: should other containments have this? Layout containment should for the same reason that it censors baselines. If it didn't you'd have to do layout in the subtree.<br> <keithamus> TabAtkins: defeats point of containment<br> <keithamus> TabAtkins: size containment should depend on children size and layout children etc. No guarantees are made about being able to defer work on layout containment<br> <keithamus> TabAtkins: size containment should not scope anchor names<br> <emilio> q+<br> <keithamus> TabAtkins: we use size containment as a cycle breaker a lot.<br> <miriam> q+<br> <keithamus> TabAtkins: scoping it means you wouldnt be able to use container queries and anchor names on the same page.<br> <keithamus> TabAtkins: paint containment doesn't for the same reason<br> <astearns> ack emilio<br> <keithamus> emilio: I guess scoping would work both inside and outside right?<br> <keithamus> TabAtkins: no<br> <keithamus> emilio: so some kind of named scoping? I don't see how they change the constraints?<br> <keithamus> emilio: if a name bleeds inside a layout contained thing...<br> <keithamus> emilio: does layout containment also scope counter names and so on?<br> <keithamus> TabAtkins: no and it shouldn't. You dont need to do layout for counter names, just box tree.<br> <keithamus> emilio: I was just confused about what point and where in the dependency tree<br> <astearns> ack miriam<br> <keithamus> miriam: container queries add layout containment as well. Even if we restrict on layout containment we still have problems on how these two interact.<br> <keithamus> miriam: you cant use anchoring across different containers<br> <keithamus> futhark: you can't anchor something inside the size container outside, or vice versa<br> <keithamus> TabAtkins: regardless if we allowed names to leak out of layout containment it defeats the point of layout containment.<br> <keithamus> TabAtkins: I think it's still a requirement that layout containment scopes the values<br> <keithamus> miriam: should we open a new issue to resolve how these two interact?<br> <keithamus> astearns: a developer need to use these across boundaries trumps the need for good optimisations<br> <keithamus> chrishtr: resolve this then raise new issue?<br> <keithamus> astearns: yes resolve this issue and then work out how it interacts, revisit it if it turns out there's a need to anchor across boundaries<br> <keithamus> astearns: did futhark's remarks change your position TabAtkins?<br> <keithamus> TabAtkins: same. It only matters for style queries<br> <keithamus> futhark: no it's also generated compute from... layout on outside<br> <keithamus> TabAtkins: that's not in the spec right now as far as I can tell<br> <keithamus> futhark: yes, container type size also applies layout, size, containment<br> <keithamus> futhark: this is not a problem specific to layout containment, also style containment...<br> <keithamus> TabAtkins: okay. Let's discuss that in the new issue<br> <keithamus> PROPOSED RESOLUTION: Layout containment contains anchor names<br> <keithamus> PROPOSED RESOLUTION: Layout containment contains anchor names and size containment/paint containment do not<br> <keithamus> RESOLVED: Layout containment contains anchor names and size containment/paint containment do not<br> <keithamus> TabAtkins: I have an anchor breakout session in the w3 breakout sessions to resolve the remaining issues. Provisional time slot for now.<br> <keithamus> astearns: we can use that session for a wider audience hopefully<br> <keithamus> fantasai: those breakouts are for across w3. So we want to resolve issues on our own, but discuss stuff with the broader community in the breakout<br> <keithamus> TabAtkins: I thought it was the same as TPAC wednesday.<br> <keithamus> astearns: we'll figure out some extra meeting times.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9349#issuecomment-1981484044 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed `[css-contain][css-anchor-position-1] Should size/layout containment also contain anchor names?`, and agreed to the following: * `RESOLVED: Layout containment contains anchor names and size containment/paint containment do not` <details><summary>The full IRC log of that discussion</summary> <keithamus> TabAtkins: already in spec that style containment triggers containment of anchor names<br> <keithamus> TabAtkins: should other containments have this? Layout containment should for the same reason that it censors baselines. If it didn't you'd have to do layout in the subtree.<br> <keithamus> TabAtkins: defeats point of containment<br> <keithamus> TabAtkins: size containment should depend on children size and layout children etc. No guarantees are made about being able to defer work on layout containment<br> <keithamus> TabAtkins: size containment should not scope anchor names<br> <emilio> q+<br> <keithamus> TabAtkins: we use size containment as a cycle breaker a lot.<br> <miriam> q+<br> <keithamus> TabAtkins: scoping it means you wouldnt be able to use container queries and anchor names on the same page.<br> <keithamus> TabAtkins: paint containment doesn't for the same reason<br> <astearns> ack emilio<br> <keithamus> emilio: I guess scoping would work both inside and outside right?<br> <keithamus> TabAtkins: no<br> <keithamus> emilio: so some kind of named scoping? I don't see how they change the constraints?<br> <keithamus> emilio: if a name bleeds inside a layout contained thing...<br> <keithamus> emilio: does layout containment also scope counter names and so on?<br> <keithamus> TabAtkins: no and it shouldn't. You dont need to do layout for counter names, just box tree.<br> <keithamus> emilio: I was just confused about what point and where in the dependency tree<br> <astearns> ack miriam<br> <keithamus> miriam: container queries add layout containment as well. Even if we restrict on layout containment we still have problems on how these two interact.<br> <keithamus> miriam: you cant use anchoring across different containers<br> <keithamus> futhark: you can't anchor something inside the size container outside, or vice versa<br> <keithamus> TabAtkins: regardless if we allowed names to leak out of layout containment it defeats the point of layout containment.<br> <keithamus> TabAtkins: I think it's still a requirement that layout containment scopes the values<br> <keithamus> miriam: should we open a new issue to resolve how these two interact?<br> <keithamus> astearns: a developer need to use these across boundaries trumps the need for good optimisations<br> <keithamus> chrishtr: resolve this then raise new issue?<br> <keithamus> astearns: yes resolve this issue and then work out how it interacts, revisit it if it turns out there's a need to anchor across boundaries<br> <keithamus> astearns: did futhark's remarks change your position TabAtkins?<br> <keithamus> TabAtkins: same. It only matters for style queries<br> <keithamus> futhark: no it's also generated compute from... layout on outside<br> <keithamus> TabAtkins: that's not in the spec right now as far as I can tell<br> <keithamus> futhark: yes, container type size also applies layout, size, containment<br> <keithamus> futhark: this is not a problem specific to layout containment, also style containment...<br> <keithamus> TabAtkins: okay. Let's discuss that in the new issue<br> <keithamus> PROPOSED RESOLUTION: Layout containment contains anchor names<br> <keithamus> PROPOSED RESOLUTION: Layout containment contains anchor names and size containment/paint containment do not<br> <keithamus> RESOLVED: Layout containment contains anchor names and size containment/paint containment do not<br> <keithamus> TabAtkins: I have an anchor breakout session in the w3 breakout sessions to resolve the remaining issues. Provisional time slot for now.<br> <keithamus> astearns: we can use that session for a wider audience hopefully<br> <keithamus> fantasai: those breakouts are for across w3. So we want to resolve issues on our own, but discuss stuff with the broader community in the breakout<br> <keithamus> TabAtkins: I thought it was the same as TPAC wednesday.<br> <keithamus> astearns: we'll figure out some extra meeting times.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9349#issuecomment-1981484044 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed `[css-contain][css-anchor-position-1] Should size/layout containment also contain anchor names?`, and agreed to the following: * `RESOLVED: Layout containment contains anchor names and size containment/paint containment do not` <details><summary>The full IRC log of that discussion</summary> <keithamus> TabAtkins: already in spec that style containment triggers containment of anchor names<br> <keithamus> TabAtkins: should other containments have this? Layout containment should for the same reason that it censors baselines. If it didn't you'd have to do layout in the subtree.<br> <keithamus> TabAtkins: defeats point of containment<br> <keithamus> TabAtkins: size containment should depend on children size and layout children etc. No guarantees are made about being able to defer work on layout containment<br> <keithamus> TabAtkins: size containment should not scope anchor names<br> <emilio> q+<br> <keithamus> TabAtkins: we use size containment as a cycle breaker a lot.<br> <miriam> q+<br> <keithamus> TabAtkins: scoping it means you wouldnt be able to use container queries and anchor names on the same page.<br> <keithamus> TabAtkins: paint containment doesn't for the same reason<br> <astearns> ack emilio<br> <keithamus> emilio: I guess scoping would work both inside and outside right?<br> <keithamus> TabAtkins: no<br> <keithamus> emilio: so some kind of named scoping? I don't see how they change the constraints?<br> <keithamus> emilio: if a name bleeds inside a layout contained thing...<br> <keithamus> emilio: does layout containment also scope counter names and so on?<br> <keithamus> TabAtkins: no and it shouldn't. You dont need to do layout for counter names, just box tree.<br> <keithamus> emilio: I was just confused about what point and where in the dependency tree<br> <astearns> ack miriam<br> <keithamus> miriam: container queries add layout containment as well. Even if we restrict on layout containment we still have problems on how these two interact.<br> <keithamus> miriam: you cant use anchoring across different containers<br> <keithamus> futhark: you can't anchor something inside the size container outside, or vice versa<br> <keithamus> TabAtkins: regardless if we allowed names to leak out of layout containment it defeats the point of layout containment.<br> <keithamus> TabAtkins: I think it's still a requirement that layout containment scopes the values<br> <keithamus> miriam: should we open a new issue to resolve how these two interact?<br> <keithamus> astearns: a developer need to use these across boundaries trumps the need for good optimisations<br> <keithamus> chrishtr: resolve this then raise new issue?<br> <keithamus> astearns: yes resolve this issue and then work out how it interacts, revisit it if it turns out there's a need to anchor across boundaries<br> <keithamus> astearns: did futhark's remarks change your position TabAtkins?<br> <keithamus> TabAtkins: same. It only matters for style queries<br> <keithamus> futhark: no it's also generated compute from... layout on outside<br> <keithamus> TabAtkins: that's not in the spec right now as far as I can tell<br> <keithamus> futhark: yes, container type size also applies layout, size, containment<br> <keithamus> futhark: this is not a problem specific to layout containment, also style containment...<br> <keithamus> TabAtkins: okay. Let's discuss that in the new issue<br> <keithamus> PROPOSED RESOLUTION: Layout containment contains anchor names<br> <keithamus> PROPOSED RESOLUTION: Layout containment contains anchor names and size containment/paint containment do not<br> <keithamus> RESOLVED: Layout containment contains anchor names and size containment/paint containment do not<br> <keithamus> TabAtkins: I have an anchor breakout session in the w3 breakout sessions to resolve the remaining issues. Provisional time slot for now.<br> <keithamus> astearns: we can use that session for a wider audience hopefully<br> <keithamus> fantasai: those breakouts are for across w3. So we want to resolve issues on our own, but discuss stuff with the broader community in the breakout<br> <keithamus> TabAtkins: I thought it was the same as TPAC wednesday.<br> <keithamus> astearns: we'll figure out some extra meeting times.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9349#issuecomment-1981484044 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed `[css-contain][css-anchor-position-1] Should size/layout containment also contain anchor names?`, and agreed to the following: * `RESOLVED: Layout containment contains anchor names and size containment/paint containment do not` <details><summary>The full IRC log of that discussion</summary> <keithamus> TabAtkins: already in spec that style containment triggers containment of anchor names<br> <keithamus> TabAtkins: should other containments have this? Layout containment should for the same reason that it censors baselines. If it didn't you'd have to do layout in the subtree.<br> <keithamus> TabAtkins: defeats point of containment<br> <keithamus> TabAtkins: size containment should depend on children size and layout children etc. No guarantees are made about being able to defer work on layout containment<br> <keithamus> TabAtkins: size containment should not scope anchor names<br> <emilio> q+<br> <keithamus> TabAtkins: we use size containment as a cycle breaker a lot.<br> <miriam> q+<br> <keithamus> TabAtkins: scoping it means you wouldnt be able to use container queries and anchor names on the same page.<br> <keithamus> TabAtkins: paint containment doesn't for the same reason<br> <astearns> ack emilio<br> <keithamus> emilio: I guess scoping would work both inside and outside right?<br> <keithamus> TabAtkins: no<br> <keithamus> emilio: so some kind of named scoping? I don't see how they change the constraints?<br> <keithamus> emilio: if a name bleeds inside a layout contained thing...<br> <keithamus> emilio: does layout containment also scope counter names and so on?<br> <keithamus> TabAtkins: no and it shouldn't. You dont need to do layout for counter names, just box tree.<br> <keithamus> emilio: I was just confused about what point and where in the dependency tree<br> <astearns> ack miriam<br> <keithamus> miriam: container queries add layout containment as well. Even if we restrict on layout containment we still have problems on how these two interact.<br> <keithamus> miriam: you cant use anchoring across different containers<br> <keithamus> futhark: you can't anchor something inside the size container outside, or vice versa<br> <keithamus> TabAtkins: regardless if we allowed names to leak out of layout containment it defeats the point of layout containment.<br> <keithamus> TabAtkins: I think it's still a requirement that layout containment scopes the values<br> <keithamus> miriam: should we open a new issue to resolve how these two interact?<br> <keithamus> astearns: a developer need to use these across boundaries trumps the need for good optimisations<br> <keithamus> chrishtr: resolve this then raise new issue?<br> <keithamus> astearns: yes resolve this issue and then work out how it interacts, revisit it if it turns out there's a need to anchor across boundaries<br> <keithamus> astearns: did futhark's remarks change your position TabAtkins?<br> <keithamus> TabAtkins: same. It only matters for style queries<br> <keithamus> futhark: no it's also generated compute from... layout on outside<br> <keithamus> TabAtkins: that's not in the spec right now as far as I can tell<br> <keithamus> futhark: yes, container type size also applies layout, size, containment<br> <keithamus> futhark: this is not a problem specific to layout containment, also style containment...<br> <keithamus> TabAtkins: okay. Let's discuss that in the new issue<br> <keithamus> PROPOSED RESOLUTION: Layout containment contains anchor names<br> <keithamus> PROPOSED RESOLUTION: Layout containment contains anchor names and size containment/paint containment do not<br> <keithamus> RESOLVED: Layout containment contains anchor names and size containment/paint containment do not<br> <keithamus> TabAtkins: I have an anchor breakout session in the w3 breakout sessions to resolve the remaining issues. Provisional time slot for now.<br> <keithamus> astearns: we can use that session for a wider audience hopefully<br> <keithamus> fantasai: those breakouts are for across w3. So we want to resolve issues on our own, but discuss stuff with the broader community in the breakout<br> <keithamus> TabAtkins: I thought it was the same as TPAC wednesday.<br> <keithamus> astearns: we'll figure out some extra meeting times.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9349#issuecomment-1981484044 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I think setting the expectation that this works is good. Probably a "SHOULD" as it is UI. But maybe we should fold this into #10039 as there's a number of properties we should clarify for native appearance. -- GitHub Notification of comment by annevk Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9507#issuecomment-1981461785 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I think setting the expectation that this works is good. Probably a "SHOULD" as it is UI. But maybe we should fold this into #10039 as there's a number of properties we should clarify for native appearance. -- GitHub Notification of comment by annevk Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9507#issuecomment-1981461785 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I think setting the expectation that this works is good. Probably a "SHOULD" as it is UI. But maybe we should fold this into #10039 as there's a number of properties we should clarify for native appearance. -- GitHub Notification of comment by annevk Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9507#issuecomment-1981461785 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
annevk has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-ui] Styling of native appearance == HTML has a number of open issues around defining the native appearance of various widget types (as red boxes in the standard). However, it seems to me that HTML's role in this should be relatively small. For the majority of widgets we essentially need a box with an implementation-defined intrinsic width and height (not aspect ratio), to which a number of CSS properties apply and the remainder of CSS properties end up ignored. And as far as the native appearance goes I think generally any pseudo elements ought not to be applicable (this would automatically follow if they are defined as replaced elements as @emilio pointed out to me). --- At the bottom of https://drafts.csswg.org/css-ui/#appearance-switching there is a list of properties that ought to be applicable to widgets with a native appearance. This list seems incomplete. `writing-mode`, `transform`, `filter`, `transition`, `width`, `height`, and likely quite a few other properties need to work as well I think. I'm not entirely sure how we can classify CSS properties such that whenever a new property is added it is clear whether it needs to be honored for widgets with a native appearance, but I think eventually we ought to have such a classification as otherwise this continues to be a game of whack-a-mole. --- I would appreciate feedback as to whether: 1. This generally seems reasonable. 2. What appropriate next steps would be. Thanks! cc @mfreed7 @emilio @fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10039 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed `[css-anchor-position][css-position] Fixing the animation problem`, and agreed to the following: * `RESOLVED: Specify how styles that are conditionally dependant on layout get recomputed` * `RESOLVED: We will use the same sort of recomputed values for animations on anchor & anchor-size functions` * `RESOLVED: Accept that inset area changes the containing block` * `RESOLVED: Defer magic position animations until level 2` <details><summary>The full IRC log of that discussion</summary> <keithamus> TabAtkins: this is two distinct issues. I had an issue in the works to post, but didn't get it finished before the end of the day.<br> <keithamus> TabAtkins: Presently, when we define container queries we implied how anything effected by the query worked but it's not specified.<br> <keithamus> TabAtkins: At the least chrome and webkit act similarly - so there's a throughline.<br> <keithamus> TabAtkins: The existence of container queries is that computed values depend on layout<br> <keithamus> TabAtkins: They must be computed. If a container query matches, changes the value, and the child has a transition on the property it needs to fire the transition<br> <keithamus> TabAtkins: This is a computed value change. We can't know this until layout is already happening and has reached the container.<br> <keithamus> TabAtkins: So we need to somehow figure out what the values were and patch them in.<br> <keithamus> TabAtkins: This needs to be specified.<br> <keithamus> TabAtkins: The rough description is what i just described; part way through layout when we interleave style and layout, and some point (which we'll specify) you realise the computed values need to change as the result of layout, we compute them, teat them as computed values - figure out trasnitions, inheritance, etc - then continue along as if they<br> <keithamus> were alwyas those values<br> <keithamus> TabAtkins: this is also how we make anchoring work well<br> <keithamus> TabAtkins: With the interleaving - does that sound reasonable to eveyrone? Chrome already does this. WebKit is similar but its not as scoped, they do more work but the end result is the same<br> <keithamus> TabAtkins: I do not know what Firefox does. How it handles these.<br> <keithamus> emilio: we do something very similar to WebKit here.<br> <keithamus> TabAtkins: impl details determine exactly what happens, but does this description work?<br> <emilio> q<br> <emilio> q+<br> <astearns> ack emilio<br> <keithamus> emilio: for webkit and gecko (may have some issues with transitions). Is sort of what you describe but it's not... you update the page layout, then recompute the styles for things that change. I'm not sure specifying it that way... like the interleaving blink has...<br> <keithamus> emilio: if you do the extra work of if something changes then recompute it... I mean it generally sounds the right direction but I'd like to have a read of it before.<br> <keithamus> TabAtkins: yes I'm interested in if this is the right direction<br> <keithamus> emilio: the difference between blink and webkit/gecko, AFAIK, style the page as if no container queries match, then do layout, then for things where container queries change, recompute style, then loop until you get to a stable state. Blink does something more subtle.<br> <iank_> q+<br> <keithamus> futhark: in optimal cases we can pause layout and style the subtree, then continue. In several cases we do also need to do multiple passes. Layout depends on auto widths for eg we may not correctly detect this then have something more similar to gecko/webkit<br> <keithamus> iank_: not exactly the same...<br> <astearns> ack iank_<br> <keithamus> iank_: webkit/gecko are failing tests for behavioural difference. Some subtle differences, because they're revisiting prior states.<br> <keithamus> astearns: are tests written down based on spec or impl?<br> <keithamus> iank_: written in spec.<br> <TabAtkins> (there is no spec to be followed right now)<br> <keithamus> astearns: observability... is this a design decision for how we visit this? Recomputation being observable?<br> <emilio> q+<br> <keithamus> chrishtr: right. Not observable.<br> <keithamus> chrishtr: difference in blink and other two engines, it's a bit more optimised to avoid recomputing.<br> <keithamus> iank_: it's quite a bit faster for degenerate cases, and bugs in other engines. Theoretically could be fixed.<br> <keithamus> chrishtr: just a matter of quality of impl difference?<br> <astearns> ack emilio<br> <keithamus> emilio: main difference is how to prevent cycles, things depending on siblings, ancestors, scrollbars, and so on<br> <keithamus> iank_: not cyclical but previous states.<br> <keithamus> astearns: Do we want a resolution? Computed values getting recomputed?<br> <keithamus> PROPOSED RESOLUTION: Specify how styles that are conditionally dependant on layout get recomputed<br> <keithamus> RESOLVED: Specify how styles that are conditionally dependant on layout get recomputed<br> <keithamus> Zakim, next item<br> <Zakim> I see nothing on the agenda<br> <keithamus> TabAtkins: next up. Anchor and anchor size functions should be dependent on this concept.<br> <keithamus> TabAtkins: right now... the anchor function needs to turn into a length, we're not sure exactly when, but at some point it needs to turn into a length to position your element. You need to layout your anchor first then figure out what the length is. It should be transitionable.<br> <keithamus> TabAtkins: if your anchor moves, you should be able to smoothly transition things. If the element you're referring to, e.g. changing anchor name values, you should smoothly transition to them.<br> <keithamus> TabAtkins: So this is dependent on that too.<br> <keithamus> TabAtkins: Larger bit on animation too, but the interleaving is important<br> <keithamus> emilio: other than animation why do we need it to turn into a length?<br> <keithamus> TabAtkins: it is for animation<br> <keithamus> TabAtkins: for all other purposes it's fine<br> <keithamus> emilio: it feels unfortunate that for all other cases it needs to do the extra work to compute<br> <keithamus> emilio: making it a computed value requires some amount of extra work. Unfortunate to require this. If we need it to be computed, then it makes sense, but ordering & dependencies get very tricky.<br> <keithamus> TabAtkins: It's a more complex relationship than container queries. At the moment it means we don't do as-smart trimming for interleaving because the relationship is more complex.<br> <keithamus> astearns: if we want these things to animate then we have to do something? These things animate descretely... we don't want that. Stuffing these changes into computed values, beause that's how animations work, but I suppose we could say computed values that depend on layout use used values instead? That seems worse<br> <keithamus> TabAtkins: I don't know if that seems worse. We're doing all this for the purpose of animations. If there's a simpler solution I'm happy to explore it.<br> <chrishtr> q+<br> <keithamus> iank_: can't use used values... they're at the wrong phase for animations. To do that would be a big and complicated lift.<br> <keithamus> astearns: we're kind of doing that, not used but recomputed which are closer to computed.<br> <keithamus> iank_: I don't think it's comparable.<br> <astearns> ack chrishtr<br> <keithamus> chrishtr: second what iank_ says. emilio is right in difficulty of interleaving but the coherence and overall complexity is less than creating a new way of doing animations. This is just scoped to doing the interelaving, already had to be done for container queries, animations just fall out of that. Confirmed in prototype in blink. Clean solution.<br> <keithamus> q?<br> <astearns> ack dbaron<br> <keithamus> dbaron: the other scary thing is used values - we don't fully formally defined them vs earlier stages<br> <keithamus> PROPOSED RESOLUTION: We will use the same sort of recomputed values for animations on anchor & anchor-size functions<br> <keithamus> emilio: do we need to define what they resolve to when the anchor is not there?<br> <keithamus> TabAtkins: already in the spec. It's the fallback value, which is zero if not specified.<br> <keithamus> emilio: if your anchor has been laid out... I guess I'm wary of the outcomes that happen when you incrementally do this. An anchor function...<br> <keithamus> emilio: I think container queries have the same issues but this can be sorted in the spec.<br> <keithamus> emilio: when you have a style change and the anchor has been laid out before. That can be dealt with the same way as container queries. Probably fine.<br> <keithamus> TabAtkins: Curious about exactly the case. We can discuss in the issue if you'd like<br> <keithamus> astearns: is there a need to specify how animation from anchor size from initial to actual recomputed value? Or does that fall out<br> <keithamus> TabAtkins: initial value?<br> <keithamus> astearns: if anchor isnt there it falls back to initial value. Something changes such that there is an anchor - is it possible to animate from that to a place in layout?<br> <keithamus> TabAtkins: that behavior should fall out<br> <keithamus> RESOLVED: We will use the same sort of recomputed values for animations on anchor & anchor-size functions<br> <chrishtr> +1 to deferring to level 2<br> <keithamus> TabAtkins: one final bit. Do we want to defer fancy animation stuff? emilio proposed that there are enough holes in the idea of position animation animating the rectangle idea I discussed in the f2f. We want to spend more time thinking about it? I'm okay with this based on above resolutions. Most cases will animate reasonably.<br> <keithamus> TabAtkins: Edge cases should be safe to upgrade to via some kind of opt in.<br> <keithamus> TabAtkins: I propose we kick animation idea to level 2 and work on it later.<br> <astearns> ack fantasai<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/9598#issuecomment-1836854109<br> <keithamus> fantasai: I dont mind if we want to push animatability questions to level 2, but there was a number of follow up changes we were planning to make to inset area, alignment, and other things listed, I don't want to defer. As long as making those changes depend on animation, I'd like us to figure out animation<br> <keithamus> TabAtkins: what might we change on inset area?<br> <keithamus> fantasai: containing block vs only causing auto values to compute<br> <keithamus> TabAtkins: already in the spec<br> <keithamus> fantasai: when? That was in this issue?<br> <keithamus> TabAtkins: it's been in for a while<br> <keithamus> TabAtkins: previously we had inset area work by adjusting auto values of inset properties, causing inset properties to match up. This would allow you to animate between inset areas, to some extent. The Apple proposal instead proposed the inset area changed the containing block, which I pushed back on as it was less animatable.<br> <keithamus> TabAtkins: it's a better behaviour to do the container block change and solve animations some other way. If we're deferring the animations stuff to level 2 it means we're potentially regressing inset area animations. I'm okay with that... if we set inset area back to how... resolves, we don't have a good path to a better future world.<br> <keithamus> TabAtkins: I'm okay with it being less animatable now since we have an idea of how we're going to fix in the future.<br> <keithamus> PROPOSED RESOLUTION: Accept that inset area changes the containing block<br> <keithamus> RESOLVED: Accept that inset area changes the containing block<br> <flackr> q+<br> <keithamus> fantasai: that was my main concern, if we need more time and nothing is blocking then that's fine<br> <astearns> ack flackr<br> <keithamus> flackr: we won't be able to automatically enable these animations right?<br> <keithamus> TabAtkins: current proposal is a position-animation property to trigger the good behaviour.<br> <keithamus> TabAtkins: cannot do it by default as it'd be incompatible with todays behaviour<br> <keithamus> flackr: can change it so certain position types are animatable and others aren't?<br> <keithamus> TabAtkins: yes, this is an argument to defer it so it isn't just focused on anchor<br> <keithamus> flackr: I just want to make sure the upgrade path isn't too difficult<br> <keithamus> astearns: what will be animatable in level 1 vs 2?<br> <keithamus> TabAtkins: level 1- properties animating as normal to the extent of positioning insets, e.g. top and left. but if you switch from top to using bottom that won't smoothly interpolate.<br> <keithamus> TabAtkins: or if you change inset area, or self alignment from align self to justify self. Properties will animate it won;t be descrete, but it wont be smooth<br> <keithamus> flackr: usually authors will rely on transitions so there'd be no animation, change from auto to non auto would be descrete<br> <keithamus> astearns: any concerns with level 1?<br> <keithamus> PROPOSED RESOLUTION: Defer magic position animations until level 2<br> <keithamus> RESOLVED: Defer magic position animations until level 2<br> <keithamus> astearns: Next Clarifying inset area syntax.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9598#issuecomment-1981443500 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed `[css-anchor-position][css-position] Fixing the animation problem`, and agreed to the following: * `RESOLVED: Specify how styles that are conditionally dependant on layout get recomputed` * `RESOLVED: We will use the same sort of recomputed values for animations on anchor & anchor-size functions` * `RESOLVED: Accept that inset area changes the containing block` * `RESOLVED: Defer magic position animations until level 2` <details><summary>The full IRC log of that discussion</summary> <keithamus> TabAtkins: this is two distinct issues. I had an issue in the works to post, but didn't get it finished before the end of the day.<br> <keithamus> TabAtkins: Presently, when we define container queries we implied how anything effected by the query worked but it's not specified.<br> <keithamus> TabAtkins: At the least chrome and webkit act similarly - so there's a throughline.<br> <keithamus> TabAtkins: The existence of container queries is that computed values depend on layout<br> <keithamus> TabAtkins: They must be computed. If a container query matches, changes the value, and the child has a transition on the property it needs to fire the transition<br> <keithamus> TabAtkins: This is a computed value change. We can't know this until layout is already happening and has reached the container.<br> <keithamus> TabAtkins: So we need to somehow figure out what the values were and patch them in.<br> <keithamus> TabAtkins: This needs to be specified.<br> <keithamus> TabAtkins: The rough description is what i just described; part way through layout when we interleave style and layout, and some point (which we'll specify) you realise the computed values need to change as the result of layout, we compute them, teat them as computed values - figure out trasnitions, inheritance, etc - then continue along as if they<br> <keithamus> were alwyas those values<br> <keithamus> TabAtkins: this is also how we make anchoring work well<br> <keithamus> TabAtkins: With the interleaving - does that sound reasonable to eveyrone? Chrome already does this. WebKit is similar but its not as scoped, they do more work but the end result is the same<br> <keithamus> TabAtkins: I do not know what Firefox does. How it handles these.<br> <keithamus> emilio: we do something very similar to WebKit here.<br> <keithamus> TabAtkins: impl details determine exactly what happens, but does this description work?<br> <emilio> q<br> <emilio> q+<br> <astearns> ack emilio<br> <keithamus> emilio: for webkit and gecko (may have some issues with transitions). Is sort of what you describe but it's not... you update the page layout, then recompute the styles for things that change. I'm not sure specifying it that way... like the interleaving blink has...<br> <keithamus> emilio: if you do the extra work of if something changes then recompute it... I mean it generally sounds the right direction but I'd like to have a read of it before.<br> <keithamus> TabAtkins: yes I'm interested in if this is the right direction<br> <keithamus> emilio: the difference between blink and webkit/gecko, AFAIK, style the page as if no container queries match, then do layout, then for things where container queries change, recompute style, then loop until you get to a stable state. Blink does something more subtle.<br> <iank_> q+<br> <keithamus> futhark: in optimal cases we can pause layout and style the subtree, then continue. In several cases we do also need to do multiple passes. Layout depends on auto widths for eg we may not correctly detect this then have something more similar to gecko/webkit<br> <keithamus> iank_: not exactly the same...<br> <astearns> ack iank_<br> <keithamus> iank_: webkit/gecko are failing tests for behavioural difference. Some subtle differences, because they're revisiting prior states.<br> <keithamus> astearns: are tests written down based on spec or impl?<br> <keithamus> iank_: written in spec.<br> <TabAtkins> (there is no spec to be followed right now)<br> <keithamus> astearns: observability... is this a design decision for how we visit this? Recomputation being observable?<br> <emilio> q+<br> <keithamus> chrishtr: right. Not observable.<br> <keithamus> chrishtr: difference in blink and other two engines, it's a bit more optimised to avoid recomputing.<br> <keithamus> iank_: it's quite a bit faster for degenerate cases, and bugs in other engines. Theoretically could be fixed.<br> <keithamus> chrishtr: just a matter of quality of impl difference?<br> <astearns> ack emilio<br> <keithamus> emilio: main difference is how to prevent cycles, things depending on siblings, ancestors, scrollbars, and so on<br> <keithamus> iank_: not cyclical but previous states.<br> <keithamus> astearns: Do we want a resolution? Computed values getting recomputed?<br> <keithamus> PROPOSED RESOLUTION: Specify how styles that are conditionally dependant on layout get recomputed<br> <keithamus> RESOLVED: Specify how styles that are conditionally dependant on layout get recomputed<br> <keithamus> Zakim, next item<br> <Zakim> I see nothing on the agenda<br> <keithamus> TabAtkins: next up. Anchor and anchor size functions should be dependent on this concept.<br> <keithamus> TabAtkins: right now... the anchor function needs to turn into a length, we're not sure exactly when, but at some point it needs to turn into a length to position your element. You need to layout your anchor first then figure out what the length is. It should be transitionable.<br> <keithamus> TabAtkins: if your anchor moves, you should be able to smoothly transition things. If the element you're referring to, e.g. changing anchor name values, you should smoothly transition to them.<br> <keithamus> TabAtkins: So this is dependent on that too.<br> <keithamus> TabAtkins: Larger bit on animation too, but the interleaving is important<br> <keithamus> emilio: other than animation why do we need it to turn into a length?<br> <keithamus> TabAtkins: it is for animation<br> <keithamus> TabAtkins: for all other purposes it's fine<br> <keithamus> emilio: it feels unfortunate that for all other cases it needs to do the extra work to compute<br> <keithamus> emilio: making it a computed value requires some amount of extra work. Unfortunate to require this. If we need it to be computed, then it makes sense, but ordering & dependencies get very tricky.<br> <keithamus> TabAtkins: It's a more complex relationship than container queries. At the moment it means we don't do as-smart trimming for interleaving because the relationship is more complex.<br> <keithamus> astearns: if we want these things to animate then we have to do something? These things animate descretely... we don't want that. Stuffing these changes into computed values, beause that's how animations work, but I suppose we could say computed values that depend on layout use used values instead? That seems worse<br> <keithamus> TabAtkins: I don't know if that seems worse. We're doing all this for the purpose of animations. If there's a simpler solution I'm happy to explore it.<br> <chrishtr> q+<br> <keithamus> iank_: can't use used values... they're at the wrong phase for animations. To do that would be a big and complicated lift.<br> <keithamus> astearns: we're kind of doing that, not used but recomputed which are closer to computed.<br> <keithamus> iank_: I don't think it's comparable.<br> <astearns> ack chrishtr<br> <keithamus> chrishtr: second what iank_ says. emilio is right in difficulty of interleaving but the coherence and overall complexity is less than creating a new way of doing animations. This is just scoped to doing the interelaving, already had to be done for container queries, animations just fall out of that. Confirmed in prototype in blink. Clean solution.<br> <keithamus> q?<br> <astearns> ack dbaron<br> <keithamus> dbaron: the other scary thing is used values - we don't fully formally defined them vs earlier stages<br> <keithamus> PROPOSED RESOLUTION: We will use the same sort of recomputed values for animations on anchor & anchor-size functions<br> <keithamus> emilio: do we need to define what they resolve to when the anchor is not there?<br> <keithamus> TabAtkins: already in the spec. It's the fallback value, which is zero if not specified.<br> <keithamus> emilio: if your anchor has been laid out... I guess I'm wary of the outcomes that happen when you incrementally do this. An anchor function...<br> <keithamus> emilio: I think container queries have the same issues but this can be sorted in the spec.<br> <keithamus> emilio: when you have a style change and the anchor has been laid out before. That can be dealt with the same way as container queries. Probably fine.<br> <keithamus> TabAtkins: Curious about exactly the case. We can discuss in the issue if you'd like<br> <keithamus> astearns: is there a need to specify how animation from anchor size from initial to actual recomputed value? Or does that fall out<br> <keithamus> TabAtkins: initial value?<br> <keithamus> astearns: if anchor isnt there it falls back to initial value. Something changes such that there is an anchor - is it possible to animate from that to a place in layout?<br> <keithamus> TabAtkins: that behavior should fall out<br> <keithamus> RESOLVED: We will use the same sort of recomputed values for animations on anchor & anchor-size functions<br> <chrishtr> +1 to deferring to level 2<br> <keithamus> TabAtkins: one final bit. Do we want to defer fancy animation stuff? emilio proposed that there are enough holes in the idea of position animation animating the rectangle idea I discussed in the f2f. We want to spend more time thinking about it? I'm okay with this based on above resolutions. Most cases will animate reasonably.<br> <keithamus> TabAtkins: Edge cases should be safe to upgrade to via some kind of opt in.<br> <keithamus> TabAtkins: I propose we kick animation idea to level 2 and work on it later.<br> <astearns> ack fantasai<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/9598#issuecomment-1836854109<br> <keithamus> fantasai: I dont mind if we want to push animatability questions to level 2, but there was a number of follow up changes we were planning to make to inset area, alignment, and other things listed, I don't want to defer. As long as making those changes depend on animation, I'd like us to figure out animation<br> <keithamus> TabAtkins: what might we change on inset area?<br> <keithamus> fantasai: containing block vs only causing auto values to compute<br> <keithamus> TabAtkins: already in the spec<br> <keithamus> fantasai: when? That was in this issue?<br> <keithamus> TabAtkins: it's been in for a while<br> <keithamus> TabAtkins: previously we had inset area work by adjusting auto values of inset properties, causing inset properties to match up. This would allow you to animate between inset areas, to some extent. The Apple proposal instead proposed the inset area changed the containing block, which I pushed back on as it was less animatable.<br> <keithamus> TabAtkins: it's a better behaviour to do the container block change and solve animations some other way. If we're deferring the animations stuff to level 2 it means we're potentially regressing inset area animations. I'm okay with that... if we set inset area back to how... resolves, we don't have a good path to a better future world.<br> <keithamus> TabAtkins: I'm okay with it being less animatable now since we have an idea of how we're going to fix in the future.<br> <keithamus> PROPOSED RESOLUTION: Accept that inset area changes the containing block<br> <keithamus> RESOLVED: Accept that inset area changes the containing block<br> <flackr> q+<br> <keithamus> fantasai: that was my main concern, if we need more time and nothing is blocking then that's fine<br> <astearns> ack flackr<br> <keithamus> flackr: we won't be able to automatically enable these animations right?<br> <keithamus> TabAtkins: current proposal is a position-animation property to trigger the good behaviour.<br> <keithamus> TabAtkins: cannot do it by default as it'd be incompatible with todays behaviour<br> <keithamus> flackr: can change it so certain position types are animatable and others aren't?<br> <keithamus> TabAtkins: yes, this is an argument to defer it so it isn't just focused on anchor<br> <keithamus> flackr: I just want to make sure the upgrade path isn't too difficult<br> <keithamus> astearns: what will be animatable in level 1 vs 2?<br> <keithamus> TabAtkins: level 1- properties animating as normal to the extent of positioning insets, e.g. top and left. but if you switch from top to using bottom that won't smoothly interpolate.<br> <keithamus> TabAtkins: or if you change inset area, or self alignment from align self to justify self. Properties will animate it won;t be descrete, but it wont be smooth<br> <keithamus> flackr: usually authors will rely on transitions so there'd be no animation, change from auto to non auto would be descrete<br> <keithamus> astearns: any concerns with level 1?<br> <keithamus> PROPOSED RESOLUTION: Defer magic position animations until level 2<br> <keithamus> RESOLVED: Defer magic position animations until level 2<br> <keithamus> astearns: Next Clarifying inset area syntax.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9598#issuecomment-1981443500 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I think we actually want to align on Gecko's behavior as much as possible. If you don't want to have native appearance, you need to explicitly opt out of it using `appearance: none`. And that in turn gives you access to pseudo elements and such. That's a much clearer story than certain properties sometimes influencing this. cc @mfreed7 @emilio -- GitHub Notification of comment by annevk Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9168#issuecomment-1981225500 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I think we actually want to align on Gecko's behavior as much as possible. If you don't want to have native appearance, you need to explicitly opt out of it using `appearance: none`. And that in turn gives you access to pseudo elements and such. That's a much clearer story than certain properties sometimes influencing this. cc @mfreed7 @emilio -- GitHub Notification of comment by annevk Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9168#issuecomment-1981225500 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I think we actually want to align on Gecko's behavior as much as possible. If you don't want to have native appearance, you need to explicitly opt out of it using `appearance: none`. And that in turn gives you access to pseudo elements and such. That's a much clearer story than certain properties sometimes influencing this. cc @mfreed7 @emilio -- GitHub Notification of comment by annevk Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9168#issuecomment-1981225500 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The spec says this at the moment: > These modified styles are applied to the element via interleaving, so they affect computed values (and can trigger transitions/etc) even tho they depend on layout and used values. They are applied as part of the **author origin, as part of a theoretical UA-controlled final cascade layer.** This works, I think, but it would be good to clarify whether it's intended to be weaker or stronger than [element attached styles](https://drafts.csswg.org/css-cascade-5/#style-attr). As written currently, it could be interpreted to mean _weaker_, since it's described as a [layer](https://drafts.csswg.org/css-cascade-5/#cascade-layering). -- GitHub Notification of comment by andruud Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9149#issuecomment-1981212156 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The spec says this at the moment: > These modified styles are applied to the element via interleaving, so they affect computed values (and can trigger transitions/etc) even tho they depend on layout and used values. They are applied as part of the **author origin, as part of a theoretical UA-controlled final cascade layer.** This works, I think, but it would be good to clarify whether it's intended to be weaker or stronger than [element attached styles](https://drafts.csswg.org/css-cascade-5/#style-attr). As written currently, it could be interpreted to mean _weaker_, since it's described as a [layer](https://drafts.csswg.org/css-cascade-5/#cascade-layering). -- GitHub Notification of comment by andruud Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9149#issuecomment-1981212156 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
annevk closed this issue. See https://github.com/w3c/csswg-drafts/issues/3087 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
romainmenke has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color] a new property to limit to a specific color gamut == see : https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1980976323 @ccameron-chromium said : >If an author specifies content that is far outside of what their screen can reproduce, then there is no way to avoid having them be surprised when that content is accurately rendered on a more capable screen. > >This is very much a "the only winning move is not to play" situation. We shouldn't be giving authors tools where it is extremely easy to unintentionally specify such colors. But we did, in the lab, lch, oklab, and oklch spaces. The oklab and oklch spaces are excellent for perceptually uniform interpolation, but they are dangerous for color manipulation, because there are no guardrails for staying in-gamut. The [relative-color syntax](https://www.w3.org/TR/css-color-5/#example-fef81186) exacerbates this. > >The problem that I want for us to focus on solving here is how to avoid having authors specify colors that are far beyond their display's capability to produce. > >If we don't solve that problem then authors will inevitably face the above-described surprise. > >If we don't solve that problem then we also have to solve the problem of assigning meaning to colors that are physically meaningless or far beyond the capabilities of any current display. ------ _This comment was made in the context of gamut mapping for colors when those colors go beyond the device capability._ _While I don't agree with that line of thinking, I do think there is something here and I want to explore it from a different perspective._ ------ There is a disconnect between: - what authors describe - what they can observe today - what their intention was - how values will be displayed in x years on vastly superior hardware. Authors can easily write CSS that produces color values that are outside specific color gamuts. With interpolation, animations, relative color, ... this can often happen without the author noticing at the time of writing that specific code. Should it be possible for authors to force a document to gamut map all colors to a specific gamut? Maybe through a new property : ``` :root { max-color-gamut: display-p3; } ``` Authors would then be able to use things like interpolation in `lch` without having to worry about unexpected outcomes on future hardware. It gives you access to the color models behind `oklch`, `lch`, ... without having to think about extremely out of gamut results. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10038 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Crissov has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-fonts] Add generic font family, Blackletter == https://www.w3.org/TR/css-fonts/#generic-font-families Per #8128 I would like to propose a new generic font family for the **blackletter** font style, which is still sometimes used for headings and other decorative text in German and some other European languages. This style with broken glyph shapes – as if written with a broad quill – is also known by the names of some prominent implementations, _Fraktur_ in particular. Other important variants include _Schwabacher_, _Textura/Textualis_, _Rotunda_, _Gothic_ and more. For many users, the actual typeface used is of secondary importance because they primarily want a distinct look deviating from the now default “grotesque” _Antiqua_ style. Besides evoking associations with traditionalism and conservatism, e.g. in newspaper logos and headlines, it has also been popular in some subcultures, e.g. in the heavy metal music genre and in graffiti / hip-hop culture. Since its look is originally informed by the handwriting medium used, which then had been adopted for printing beginning with Gutenberg, styles with similar characteristics were also developed for other scripts than Latin. However, it is expected that the only ones potentially be also covered by readily available fonts are Cyrillic and, less likely, Greek. ISO 15924 includes the script code `Latf` = `217` _Latin (Fraktur variant)_ and Unicode includes two mathematical alphabets with Fraktur glyphs. Especially in printed German texts before the mid-20th century, intricate typographic conventions were developed that differ from those used with Antiqua texts. These largely still apply when typesetting in this style. For instance, emphasis was preferably expressed by letter-spacing (or perhaps underlining) instead of bold-facing or italics. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10037 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
r12a has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-fonts] Add generic font family, Khmer Mul == https://www.w3.org/TR/css-fonts-5/#generic-font-families https://www.w3.org/TR/css-fonts-4/#generic-font-families Per https://github.com/w3c/csswg-drafts/issues/8128#issuecomment-1962180465 i would like to propose a new generic font label for Khmer âksâr mul (pronounced /ʔɑːksɑː muːl/) font style, which is commonly used for headings and other distinctive text in Khmer. For more information, see https://r12a.github.io/scripts/khmr/km.html#writingstyles 'Mul' is spelled in a variety of ways, including 'mul', 'mool', 'moul', and 'muul'. I'm not sure whether the name for the font family label is sufficient as just 'mul', or whether it should be 'khmer-mul', or perhaps 'askar-mul'. ![km_moul](https://github.com/w3c/csswg-drafts/assets/4839211/908afb04-ee07-44e8-be7b-9acb0a3290f5) Khmer has some other font styles, too, but this seems to be the one you'd most likely want to be able to control fallback behaviour for. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10036 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
r12a has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-fonts] Add generic font family, Khmer Mul == https://www.w3.org/TR/css-fonts-5/#generic-font-families https://www.w3.org/TR/css-fonts-4/#generic-font-families Per https://github.com/w3c/csswg-drafts/issues/8128#issuecomment-1962180465 i would like to propose a new generic font label for Khmer âksâr mul (pronounced /ʔɑːksɑː muːl/) font style, which is commonly used for headings and other distinctive text in Khmer. For more information, see https://r12a.github.io/scripts/khmr/km.html#writingstyles 'Mul' is spelled in a variety of ways, including 'mul', 'mool', 'moul', and 'muul'. I'm not sure whether the name for the font family label is sufficient as just 'mul', or whether it should be 'khmer-mul', or perhaps 'askar-mul'. ![km_moul](https://github.com/w3c/csswg-drafts/assets/4839211/908afb04-ee07-44e8-be7b-9acb0a3290f5) Khmer has some other font styles, too, but this seems to be the one you'd most likely want to be able to control fallback behaviour for. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10036 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
r12a has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-fonts] Add generic font family, Khmer Mul == https://www.w3.org/TR/css-fonts-5/#generic-font-families https://www.w3.org/TR/css-fonts-4/#generic-font-families Per https://github.com/w3c/csswg-drafts/issues/8128#issuecomment-1962180465 i would like to propose a new generic font label for Khmer âksâr mul (pronounced /ʔɑːksɑː muːl/) font style, which is commonly used for headings and other distinctive text in Khmer. For more information, see https://r12a.github.io/scripts/khmr/km.html#writingstyles 'Mul' is spelled in a variety of ways, including 'mul', 'mool', 'moul', and 'muul'. I'm not sure whether the name for the font family label is sufficient as just 'mul', or whether it should be 'khmer-mul', or perhaps 'askar-mul'. ![km_moul](https://github.com/w3c/csswg-drafts/assets/4839211/908afb04-ee07-44e8-be7b-9acb0a3290f5) Khmer has some other font styles, too, but this seems to be the one you'd most likely want to be able to control fallback behaviour for. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10036 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
r12a has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-fonts] Add generic font family, Khmer Mul == https://www.w3.org/TR/css-fonts-5/#generic-font-families https://www.w3.org/TR/css-fonts-4/#generic-font-families Per https://github.com/w3c/csswg-drafts/issues/8128#issuecomment-1962180465 i would like to propose a new generic font label for Khmer âksâr mul (pronounced /ʔɑːksɑː muːl/) font style, which is commonly used for headings and other distinctive text in Khmer. For more information, see https://r12a.github.io/scripts/khmr/km.html#writingstyles 'Mul' is spelled in a variety of ways, including 'mul', 'mool', 'moul', and 'muul'. I'm not sure whether the name for the font family label is sufficient as just 'mul', or whether it should be 'khmer-mul', or perhaps 'askar-mul'. ![km_moul](https://github.com/w3c/csswg-drafts/assets/4839211/908afb04-ee07-44e8-be7b-9acb0a3290f5) Khmer has some other font styles, too, but this seems to be the one you'd most likely want to be able to control fallback behaviour for. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10036 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I agree that we'd want at least “a”: > Add a requirement to the spec that if the user agent ignores one of the provided colors, then the user agent is responsible for providing good contrast, and it may tweak the color of the part that it isn't ignoring in order to achieve that (option 4 above) - - - > For instance, imagine a page with a white background, setting up a white thumb against a brightly colored track. With classic scrollbars, the result works. With overlay scrollbars, the thumb is white-on-white, and is invisible. There was [a recent article](https://frontendmasters.com/blog/how-to-fix-the-invisible-scrollbar-issue-in-ios/) by @simevidas about this issue which I feel needs to be mentioned. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9855#issuecomment-1980580717 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Whatever "scroll into view" solution is adopted, it must support some kind of "scroll-interrupted" event. Since this is an animation-like action that can be interrupted by the user simply by scrolling, the solution must relay that information back to the programmer. This allows the programmer to take action if the intended behavior is not going to happen because the user is not scrolling to the target. Of course, one can create a workaround in the form of a timeout(). I am dropping this note here for the record in case somebody undertakes the task to create a truly universal shim of some sort. -- GitHub Notification of comment by webdevelopers-eu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3744#issuecomment-1980216568 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Whatever "scroll into view" solution is adopted, it must support some kind of "scroll-interrupted" event. Since this is an animation-like action that can be interrupted by the user simply by scrolling, the solution must relay that information back to the programmer. This allows the programmer to take action if the intended behavior is not going to happen because the user is not scrolling to the target. Of course, one can create a workaround in the form of a timeout(). I am dropping this note here for the record in case somebody undertakes the task to create a truly universal shim of some sort. -- GitHub Notification of comment by webdevelopers-eu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3744#issuecomment-1980216568 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Whatever "scroll into view" solution is adopted, it must support some kind of "scroll-interrupted" event. Since this is an animation-like action that can be interrupted by the user simply by scrolling, the solution must relay that information back to the programmer. This allows the programmer to take action if the intended behavior is not going to happen because the user is not scrolling to the target. Of course, one can create a workaround in the form of a timeout(). I am dropping this note here for the record in case somebody undertakes the task to create a truly universal shim of some sort. -- GitHub Notification of comment by webdevelopers-eu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3744#issuecomment-1980216568 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color] limits to specific color spaces and/or color notations == > I would prefer a normative solution to the problem of handling "extreme" colors produced by `oklab` and `oklch` (e.g, the ones from https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1929679581), which gets us to "some very wide gamut". The value as mentioned in that comment can be expressed in many different ways. https://colorjs.io/apps/convert/?color=oklch(90%25%2090%25%200deg)&precision=4 For example with `hwb(329.3 10.37% -52.94%)` or `lab(83.87 115.6 1.847)`. Implementing gamut mapping only for `oklab`, `oklch` would be highly problematic. I immediately think of these : - `oklch(from lab(83.87 115.6 1.847) l c h)` - `lch(from oklch(90% 90% 0deg) l c h)` - `color-mix(in lch, oklch(90% 90% 0deg), oklch(90% 90% 0deg))` - ... How are these affected when gamut mapping is limited to `oklch` and `oklab` notations? ----- Edit: For me personally it is also a bit a side-track :) I keep stumbling over this because I think it is important. But it isn't directly related to this issue. Discussing limits to specific color spaces and/or color notations should be a separate issue. _Originally posted by @romainmenke in https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1978878975_ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10035 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color] limits to specific color spaces and/or color notations == > I would prefer a normative solution to the problem of handling "extreme" colors produced by `oklab` and `oklch` (e.g, the ones from https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1929679581), which gets us to "some very wide gamut". The value as mentioned in that comment can be expressed in many different ways. https://colorjs.io/apps/convert/?color=oklch(90%25%2090%25%200deg)&precision=4 For example with `hwb(329.3 10.37% -52.94%)` or `lab(83.87 115.6 1.847)`. Implementing gamut mapping only for `oklab`, `oklch` would be highly problematic. I immediately think of these : - `oklch(from lab(83.87 115.6 1.847) l c h)` - `lch(from oklch(90% 90% 0deg) l c h)` - `color-mix(in lch, oklch(90% 90% 0deg), oklch(90% 90% 0deg))` - ... How are these affected when gamut mapping is limited to `oklch` and `oklab` notations? ----- Edit: For me personally it is also a bit a side-track :) I keep stumbling over this because I think it is important. But it isn't directly related to this issue. Discussing limits to specific color spaces and/or color notations should be a separate issue. _Originally posted by @romainmenke in https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1978878975_ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10035 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color] limits to specific color spaces and/or color notations == > I would prefer a normative solution to the problem of handling "extreme" colors produced by `oklab` and `oklch` (e.g, the ones from https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1929679581), which gets us to "some very wide gamut". The value as mentioned in that comment can be expressed in many different ways. https://colorjs.io/apps/convert/?color=oklch(90%25%2090%25%200deg)&precision=4 For example with `hwb(329.3 10.37% -52.94%)` or `lab(83.87 115.6 1.847)`. Implementing gamut mapping only for `oklab`, `oklch` would be highly problematic. I immediately think of these : - `oklch(from lab(83.87 115.6 1.847) l c h)` - `lch(from oklch(90% 90% 0deg) l c h)` - `color-mix(in lch, oklch(90% 90% 0deg), oklch(90% 90% 0deg))` - ... How are these affected when gamut mapping is limited to `oklch` and `oklab` notations? ----- Edit: For me personally it is also a bit a side-track :) I keep stumbling over this because I think it is important. But it isn't directly related to this issue. Discussing limits to specific color spaces and/or color notations should be a separate issue. _Originally posted by @romainmenke in https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1978878975_ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10035 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color] limits to specific color spaces and/or color notations == > I would prefer a normative solution to the problem of handling "extreme" colors produced by `oklab` and `oklch` (e.g, the ones from https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1929679581), which gets us to "some very wide gamut". The value as mentioned in that comment can be expressed in many different ways. https://colorjs.io/apps/convert/?color=oklch(90%25%2090%25%200deg)&precision=4 For example with `hwb(329.3 10.37% -52.94%)` or `lab(83.87 115.6 1.847)`. Implementing gamut mapping only for `oklab`, `oklch` would be highly problematic. I immediately think of these : - `oklch(from lab(83.87 115.6 1.847) l c h)` - `lch(from oklch(90% 90% 0deg) l c h)` - `color-mix(in lch, oklch(90% 90% 0deg), oklch(90% 90% 0deg))` - ... How are these affected when gamut mapping is limited to `oklch` and `oklab` notations? ----- Edit: For me personally it is also a bit a side-track :) I keep stumbling over this because I think it is important. But it isn't directly related to this issue. Discussing limits to specific color spaces and/or color notations should be a separate issue. _Originally posted by @romainmenke in https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1978878975_ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10035 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Do you think [`unicode-range`](https://drafts.csswg.org/css-fonts-4/#unicode-range-desc) should keep `<urange>#` as its value definition, and require the `start`/`end` code point to be no greater than `FF0000`, and `start <= end`? WPT does not test these cases, but `U+110000`, `U+11????`, `U+1-0`, are currently invalid `unicode-range` values in Chrome and FF. -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8835#issuecomment-1980056382 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Do you think [`unicode-range`](https://drafts.csswg.org/css-fonts-4/#unicode-range-desc) should keep `<urange>#` as its value definition, and require the `start`/`end` code point to be no greater than `FF0000`, and `start <= end`? WPT does not test these cases, but `U+110000`, `U+11????`, `U+1-0`, are currently invalid `unicode-range` values in Chrome and FF. -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8835#issuecomment-1980056382 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Do you think [`unicode-range`](https://drafts.csswg.org/css-fonts-4/#unicode-range-desc) should keep `<urange>#` as its value definition, and require the `start`/`end` code point to be no greater than `FF0000`, and `start <= end`? WPT does not test these cases, but `U+110000`, `U+11????`, `U+1-0`, are currently invalid `unicode-range` values in Chrome and FF. -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8835#issuecomment-1980056382 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Do you think [`unicode-range`](https://drafts.csswg.org/css-fonts-4/#unicode-range-desc) should keep `<urange>#` as its value definition, and require the `start`/`end` code point to be no greater than `FF0000`, and `start <= end`? WPT does not test these cases, but `U+110000`, `U+11????`, `U+1-0`, are currently invalid `unicode-range` values in Chrome and FF. -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8835#issuecomment-1980056382 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@frivoal could you expand your proposal to take into account the suggestion from @Crissov to allow logical as well as physical directions? -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9392#issuecomment-1980038267 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
LeaVerou has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-5] `color-scale()` for interpolating across multiple colors == During the discussion in #9992 it occurred to me that one of the things that could really help simplify the color-related design systems use cases would be a way to define a gradient line and pick a color on it. ## Why? - As a primary use case, authors often need to define scales of colors with interim colors inserted to adjust the interpolation, and `color-mix()` is not very friendly to that. Super common example: the good-bad scale of red, orange, yellow, green. - Design systems could then define color scales and pass them around in variables, which would make functions a much more appealing solution for actually selecting points on those scales. - It makes interpolation with arbitrary manual interim points much easier, without requiring special overfit syntax in variable groups to cater to this. - The scale specification should be compatible with gradient color stops so that authors can debug them by simply throwing them into a `linear-gradient()`. ## Syntax ### Option 1: Single function for both *defining* the scale, and _selecting_ a color ``` <color-scale()> = color-scale ( <percentage> / <color-interpolation-method>?, <abstract-color-stop-list> ) <abstract-color-stop-list> = <abstract-color-stop> , [ <abstract-color-hint>? , <abstract-color-stop> ]# <abstract-color-stop> = <color> <percentage>? ``` Example usage: ```css --tints-green: white, var(--color-green), black; --color-green-900: color-scale(90% / var(--tint-green)); ``` This is basically modeled after `linear-gradient()` with the non relevant parts removed (lengths, `to <whatever>`, angles). It could also allow `<1d-image>` / `stripes()` to facilitate discrete scales. The reason the percentage is separated from the rest with a `/` is to facilitate storing the actual scale part into variables and passing them around without having to worry about whether you need to specify a comma or not (depending on whether the scale has a `<color-interpolation-method>`). Pros: - By passing a list of arguments around, these can produce *both* a color scale *and* various types of gradients (without gradients having to be extended in any way) - Color stop list could even be extended by adding more stops on either side Cons: - Scale variables don't make sense by themselves, as they're just a comma-separated list of colors. ### Option 2: Separate scale definition and color selection This syntax decouples the scale from the color selection. It seems more conceptually sound, but also too many parens. ``` <color-scale> = color-scale ( <color-interpolation-method>?, <abstract-color-stop-list> ) <abstract-color-stop-list> = <abstract-color-stop> , [ <abstract-color-hint>? , <abstract-color-stop> ]# <abstract-color-stop> = <color> <percentage>? <color-pick()> = color-pick(<percentage> of <color-scale>); ``` Example: ```css --tints-green: color-scale(white, var(--color-green), black); --color-green-900: color-pick(90% of var(--tints-green)); ``` the parens could be reduced if it would be possible to define tokens like: ``` <color-scale-color> = <percentage> of <color-scale> ``` Example: ```css --tints-green: color-scale(white, var(--color-green), black); --color-green-900: 90% of var(--tints-green); ``` but I suspect @tabatkins will have a good reason to rule that out 😁 We could also make it a variant of `color-mix()`: ``` <color-mix> := color-mix(<percentage> of <color-scale>) ``` Example: ```css --tints-green: color-scale(white, var(--color-green), black); --color-green-900: color-mix(90% of var(--tints-green)); ``` Though since conceptually we're not mixing anything, I don't think this is worth it. ## More Examples ### Transparent variations of a base color Option 1: ```css --color-neutral-a: var(--color-neutral), transparent; --color-neutral-a-90: color-scale(90% / var(--color-neutral-a)); ``` Option 2: ```css --color-neutral-a: color-scale(var(--color-neutral), transparent); --color-neutral-a-90: 90% of var(--color-neutral-a)); ``` ### Success/failure scales This is super common to communicate varying levels of success/failure. There are two main forms: red - orange - yellow - green - dark green, or red - white - green. E.g. see screenshot from Coda’s conditional formatting: <img width="329" alt="image" src="https://github.com/w3c/csswg-drafts/assets/175836/9215ca1c-89e2-4d9a-aa2e-04de367afc91"> Especially the red - orange - yellow - green scales almost always require manual correction, and cannot be done with a single 2 color interpolation (yes not even in polar spaces). With `color-scale()` they can be as simple as: ```css :root { --color-scale-bad-good: in oklch, var(--red), var(--orange), var(--yellow) 50%, var(--green) 90%, var(--dark-green); } .badge { background: color-scale(var(--percent-good) of var(--color-scale-bad-good)); .great { --percent-good: 100% } .good { --percent-good: 80% } .ok { --percent-good: 60% } .fair { --percent-good: 40% } .poor { --percent-good: 20% } .terrible { --percent-good: 0% } } ``` Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10034 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Currently the definition is up in the air. I agree we should be consistent with VT (and scroll animations?). -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7758#issuecomment-1979758361 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Currently the definition is up in the air. I agree we should be consistent with VT (and scroll animations?). -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7758#issuecomment-1979758361 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Currently the definition is up in the air. I agree we should be consistent with VT (and scroll animations?). -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7758#issuecomment-1979758361 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@fantasai has said she wants to put more serious thought into this to explore the space before she agrees to anything (and her expressed doubts seem reasonable to me), so I propose we handle this in level 2. The idea presented in this thread, as well as any potential alternate approach I can think of (min/max insets, a more explicit "slide me" value or property) are all compatible with being added in the future. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9960#issuecomment-1979757465 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I liked @mirisuzanne's suggestion to replace "center" with "and", so you'd have e.g. `bottom span-left` instead of `bottom center-left`. -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9862#issuecomment-1979728830 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I think instead of making new function types, it might be better to introduce an additional property e.g. `counter-scope: [ narrow | wide ]#` or something like that? -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9076#issuecomment-1979701666 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I think instead of making new function types, it might be better to introduce an additional property e.g. `counter-scope: [ narrow | wide ]#` or something like that? -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9076#issuecomment-1979701666 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Talking with @bfgeek, we should be able to relax this restriction somewhat, to match the set of properties that are allowed to be used in @position-try. Applying it to a wider set of properties is somewhat problematic, as the properties need to be compatible with "style/layout interleaving". This would rule out usage in clip-path, tho. We'll have to discuss this further. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9827#issuecomment-1979700798 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
BTW, not just the values, the number of declarations is also live (e.g. if you remove the element, `.length` will become 0). -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6144#issuecomment-1979638466 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
BTW, not just the values, the number of declarations is also live (e.g. if you remove the element, `.length` will become 0). -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6144#issuecomment-1979638466 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [cssom] getComputedStyle should sort vendor-prefixed longhands at the end == https://drafts.csswg.org/cssom/#dom-window-getcomputedstyle > set decls to a list of all longhand properties that are [supported CSS properties](https://drafts.csswg.org/cssom/#supported-css-property), in lexicographical order However, all browsers agree that properties starting with `-` should be at the end, even though `'-' < 'a'`. https://wpt.fyi/results/css/cssom/getComputedStyle-property-order.html Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10033 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts: == [cssom] getComputedStyle should sort vendor-prefixed longhands at the end == https://drafts.csswg.org/cssom/#dom-window-getcomputedstyle > set decls to a list of all longhand properties that are [supported CSS properties](https://drafts.csswg.org/cssom/#supported-css-property), in lexicographical order However, all browsers agree that properties starting with `-` should be at the end, even though `'-' < 'a'`. https://wpt.fyi/results/css/cssom/getComputedStyle-property-order.html Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10033 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@ethanjv We currently don't prioritize item placement based on the resolved size of the tracks... if that's something you thin we should add, maybe open a new issue? :) -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8206#issuecomment-1979506451 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Given that https://w3c.github.io/aria/#aria-orientation exists I wonder to what extent we should consider this to be a presentational aspect of the control. Maybe `orient=vertical` is the right approach? -- GitHub Notification of comment by annevk Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9832#issuecomment-1979165914 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Given that https://w3c.github.io/aria/#aria-orientation exists I wonder to what extent we should consider this to be a presentational aspect of the control. Maybe `orient=vertical` is the right approach? -- GitHub Notification of comment by annevk Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9832#issuecomment-1979165914 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Given that https://w3c.github.io/aria/#aria-orientation exists I wonder to what extent we should consider this to be a presentational aspect of the control. Maybe `orient=vertical` is the right approach? -- GitHub Notification of comment by annevk Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9832#issuecomment-1979165914 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Given that https://w3c.github.io/aria/#aria-orientation exists I wonder to what extent we should consider this to be a presentational aspect of the control. Maybe `orient=vertical` is the right approach? -- GitHub Notification of comment by annevk Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9832#issuecomment-1979165914 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Proposed resolution from internal sync: by default types are encapsulated to the document that defined them. We can add semantics for using old-document types in the new one in the future. (In essence, leave the spec as is in this regard, and add an informative note to this effect). -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9526#issuecomment-1978999156 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Proposed resolution from internal sync: by default types are encapsulated to the document that defined them. We can add semantics for using old-document types in the new one in the future. (In essence, leave the spec as is in this regard, and add an informative note to this effect). -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9526#issuecomment-1978999156 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Proposed resolution from internal sync: have a `typeList` attribute in a `ViewTransition` object that can mutate types at any point. -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9542#issuecomment-1978995897 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
wesleyolis has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox] Feature: justify-balance: [top, equal, bottom, 3:6], j*-c*-[start,...,end] + a*-c*-[start,...,end] when more 3 rows/coloums == This is a suggestion not the final spec of properties of mechanics, they may be ways to further simply things, but this control would allow for a lot of things and further improvements call it hacks to another layout can be composed much more easily. 3 new additional properties for flex layout to be able to adjust the layout easier to what is desired for polishing off flex layout, and controlling the behaviour such that perfectly aesthetically pleasing, preventing the need to write JS or programming code external generators of HTML, CSS into the page. These properties will ensure everything is controlled from within the browser CSS specification. They're is better than the item break control mechanism for certain layouts when in the space of a [2-3]X[2-3] layout hacks for forms as well, so there are further added benefits at the low end of these settings as well, which make the combination of both of these even more powerful and simpler: https://github.com/w3c/csswg-drafts/issues/10031 Currently, when there are more than 2,3 rows of items on the main axis or 2,3 columns of items on the cross-sectional axis, there is no way of controlling, how polished off the layout for the 1st row and last row n-1 on the main axis and the cross axis of items, layout when compared to the general section. These properties can still be applied when less the 3, like with a minimum of 2 rows or 2 columns. I may have 10 rows and 4 columns, the first row, which is 40 items, but I only have 34 items. This means the middle section can be full rows of 4 columns of items, but when it comes to the first row and the last row, how should that be displayed the remaining 2 items could be displayed on the top row or the last row, we probably want to be laid out differently, - justify-balance can be set to control the remaining items that wouldn't cause the body/middle of the layout to be fully populated across its cross-sectional axis. These remaining partial items, can either be placed at the top of the bottom of the main section potentially. justify-balance: top, bottom, equal, or a ratio/fraction of the top-to-bottom(leading/trailing) axis of items. Currently justify-balance: top is how flex would currently work as a progressive algorithm, which does not require multiple passes for response rendering. The grid can be full on the main axis rows, and the cross-sectional axis: 4, so any overflow items, which would not form the main body, remaining 33-39 items would be controlled by justify-balance. This together with new properties to control the first and last main/cross-section alignment gives endless possibilities to what can be achieved. - justify-content-start: controls the first main axis row: 1 - justify-content-end: controls the last main axis row: n-1 - align-content-start: controls the first main axis row: 1 - align-content-end: controls the last main axis row: n-1 The following possible values are all possible for the settings above. flex-start, flex-end, flex-center, flex-space-between, space-around, stretch There are going to arise many other simplifications to the existing ways of doing things and hacks as well for these properties, which allows for simplifying HTML layouts in many cases, including form layouts. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10032 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
wesleyolis has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox] Feature: justify-balance: [top, equal, bottom, 3:6], j*-c*-[start,...,end] + a*-c*-[start,...,end] when more 3 rows/coloums == This is a suggestion not the final spec of properties of mechanics, they may be ways to further simply things, but this control would allow for a lot of things and further improvements call it hacks to another layout can be composed much more easily. 3 new additional properties for flex layout to be able to adjust the layout easier to what is desired for polishing off flex layout, and controlling the behaviour such that perfectly aesthetically pleasing, preventing the need to write JS or programming code external generators of HTML, CSS into the page. These properties will ensure everything is controlled from within the browser CSS specification. They're is better than the item break control mechanism for certain layouts when in the space of a [2-3]X[2-3] layout hacks for forms as well, so there are further added benefits at the low end of these settings as well, which make the combination of both of these even more powerful and simpler: https://github.com/w3c/csswg-drafts/issues/10031 Currently, when there are more than 2,3 rows of items on the main axis or 2,3 columns of items on the cross-sectional axis, there is no way of controlling, how polished off the layout for the 1st row and last row n-1 on the main axis and the cross axis of items, layout when compared to the general section. These properties can still be applied when less the 3, like with a minimum of 2 rows or 2 columns. I may have 10 rows and 4 columns, the first row, which is 40 items, but I only have 34 items. This means the middle section can be full rows of 4 columns of items, but when it comes to the first row and the last row, how should that be displayed the remaining 2 items could be displayed on the top row or the last row, we probably want to be laid out differently, - justify-balance can be set to control the remaining items that wouldn't cause the body/middle of the layout to be fully populated across its cross-sectional axis. These remaining partial items, can either be placed at the top of the bottom of the main section potentially. justify-balance: top, bottom, equal, or a ratio/fraction of the top-to-bottom(leading/trailing) axis of items. Currently justify-balance: top is how flex would currently work as a progressive algorithm, which does not require multiple passes for response rendering. The grid can be full on the main axis rows, and the cross-sectional axis: 4, so any overflow items, which would not form the main body, remaining 33-39 items would be controlled by justify-balance. This together with new properties to control the first and last main/cross-section alignment gives endless possibilities to what can be achieved. - justify-content-start: controls the first main axis row: 1 - justify-content-end: controls the last main axis row: n-1 - align-content-start: controls the first main axis row: 1 - align-content-end: controls the last main axis row: n-1 The following possible values are all possible for the settings above. flex-start, flex-end, flex-center, flex-space-between, space-around, stretch There are going to arise many other simplifications to the existing ways of doing things and hacks as well for these properties, which allows for simplifying HTML layouts in many cases, including form layouts. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10032 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
wesleyolis has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox] Feature: justify-balance: [top, equal, bottom, 3:6], j*-c*-[start,...,end] + a*-c*-[start,...,end] when more 3 rows/coloums == This is a suggestion not the final spec of properties of mechanics, they may be ways to further simply things, but this control would allow for a lot of things and further improvements call it hacks to another layout can be composed much more easily. 3 new additional properties for flex layout to be able to adjust the layout easier to what is desired for polishing off flex layout, and controlling the behaviour such that perfectly aesthetically pleasing, preventing the need to write JS or programming code external generators of HTML, CSS into the page. These properties will ensure everything is controlled from within the browser CSS specification. They're is better than the item break control mechanism for certain layouts when in the space of a [2-3]X[2-3] layout hacks for forms as well, so there are further added benefits at the low end of these settings as well, which make the combination of both of these even more powerful and simpler: https://github.com/w3c/csswg-drafts/issues/10031 Currently, when there are more than 2,3 rows of items on the main axis or 2,3 columns of items on the cross-sectional axis, there is no way of controlling, how polished off the layout for the 1st row and last row n-1 on the main axis and the cross axis of items, layout when compared to the general section. These properties can still be applied when less the 3, like with a minimum of 2 rows or 2 columns. I may have 10 rows and 4 columns, the first row, which is 40 items, but I only have 34 items. This means the middle section can be full rows of 4 columns of items, but when it comes to the first row and the last row, how should that be displayed the remaining 2 items could be displayed on the top row or the last row, we probably want to be laid out differently, - justify-balance can be set to control the remaining items that wouldn't cause the body/middle of the layout to be fully populated across its cross-sectional axis. These remaining partial items, can either be placed at the top of the bottom of the main section potentially. justify-balance: top, bottom, equal, or a ratio/fraction of the top-to-bottom(leading/trailing) axis of items. Currently justify-balance: top is how flex would currently work as a progressive algorithm, which does not require multiple passes for response rendering. The grid can be full on the main axis rows, and the cross-sectional axis: 4, so any overflow items, which would not form the main body, remaining 33-39 items would be controlled by justify-balance. This together with new properties to control the first and last main/cross-section alignment gives endless possibilities to what can be achieved. - justify-content-start: controls the first main axis row: 1 - justify-content-end: controls the last main axis row: n-1 - align-content-start: controls the first main axis row: 1 - align-content-end: controls the last main axis row: n-1 The following possible values are all possible for the settings above. flex-start, flex-end, flex-center, flex-space-between, space-around, stretch There are going to arise many other simplifications to the existing ways of doing things and hacks as well for these properties, which allows for simplifying HTML layouts in many cases, including form layouts. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10032 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
wesleyolis has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox] Feature: justify-balance: [top, equal, bottom, 3:6], j*-c*-[start,...,end] + a*-c*-[start,...,end] when more 3 rows/coloums == This is a suggestion not the final spec of properties of mechanics, they may be ways to further simply things, but this control would allow for a lot of things and further improvements call it hacks to another layout can be composed much more easily. 3 new additional properties for flex layout to be able to adjust the layout easier to what is desired for polishing off flex layout, and controlling the behaviour such that perfectly aesthetically pleasing, preventing the need to write JS or programming code external generators of HTML, CSS into the page. These properties will ensure everything is controlled from within the browser CSS specification. They're is better than the item break control mechanism for certain layouts when in the space of a [2-3]X[2-3] layout hacks for forms as well, so there are further added benefits at the low end of these settings as well, which make the combination of both of these even more powerful and simpler: https://github.com/w3c/csswg-drafts/issues/10031 Currently, when there are more than 2,3 rows of items on the main axis or 2,3 columns of items on the cross-sectional axis, there is no way of controlling, how polished off the layout for the 1st row and last row n-1 on the main axis and the cross axis of items, layout when compared to the general section. These properties can still be applied when less the 3, like with a minimum of 2 rows or 2 columns. I may have 10 rows and 4 columns, the first row, which is 40 items, but I only have 34 items. This means the middle section can be full rows of 4 columns of items, but when it comes to the first row and the last row, how should that be displayed the remaining 2 items could be displayed on the top row or the last row, we probably want to be laid out differently, - justify-balance can be set to control the remaining items that wouldn't cause the body/middle of the layout to be fully populated across its cross-sectional axis. These remaining partial items, can either be placed at the top of the bottom of the main section potentially. justify-balance: top, bottom, equal, or a ratio/fraction of the top-to-bottom(leading/trailing) axis of items. Currently justify-balance: top is how flex would currently work as a progressive algorithm, which does not require multiple passes for response rendering. The grid can be full on the main axis rows, and the cross-sectional axis: 4, so any overflow items, which would not form the main body, remaining 33-39 items would be controlled by justify-balance. This together with new properties to control the first and last main/cross-section alignment gives endless possibilities to what can be achieved. - justify-content-start: controls the first main axis row: 1 - justify-content-end: controls the last main axis row: n-1 - align-content-start: controls the first main axis row: 1 - align-content-end: controls the last main axis row: n-1 The following possible values are all possible for the settings above. flex-start, flex-end, flex-center, flex-space-between, space-around, stretch There are going to arise many other simplifications to the existing ways of doing things and hacks as well for these properties, which allows for simplifying HTML layouts in many cases, including form layouts. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10032 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
wesleyolis has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox] Feature: justify-balance: [top, equal, bottom, 3:6], j*-c*-[start,...,end] + a*-c*-[start,...,end] when more 3 rows/coloums == This is a suggestion not the final spec of properties of mechanics, they may be ways to further simply things, but this control would allow for a lot of things and further improvements call it hacks to another layout can be composed much more easily. 3 new additional properties for flex layout to be able to adjust the layout easier to what is desired for polishing off flex layout, and controlling the behaviour such that perfectly aesthetically pleasing, preventing the need to write JS or programming code external generators of HTML, CSS into the page. These properties will ensure everything is controlled from within the browser CSS specification. They're is better than the item break control mechanism for certain layouts when in the space of a [2-3]X[2-3] layout hacks for forms as well, so there are further added benefits at the low end of these settings as well, which make the combination of both of these even more powerful and simpler: https://github.com/w3c/csswg-drafts/issues/10031 Currently, when there are more than 2,3 rows of items on the main axis or 2,3 columns of items on the cross-sectional axis, there is no way of controlling, how polished off the layout for the 1st row and last row n-1 on the main axis and the cross axis of items, layout when compared to the general section. These properties can still be applied when less the 3, like with a minimum of 2 rows or 2 columns. I may have 10 rows and 4 columns, the first row, which is 40 items, but I only have 34 items. This means the middle section can be full rows of 4 columns of items, but when it comes to the first row and the last row, how should that be displayed the remaining 2 items could be displayed on the top row or the last row, we probably want to be laid out differently, - justify-balance can be set to control the remaining items that wouldn't cause the body/middle of the layout to be fully populated across its cross-sectional axis. These remaining partial items, can either be placed at the top of the bottom of the main section potentially. justify-balance: top, bottom, equal, or a ratio/fraction of the top-to-bottom(leading/trailing) axis of items. Currently justify-balance: top is how flex would currently work as a progressive algorithm, which does not require multiple passes for response rendering. The grid can be full on the main axis rows, and the cross-sectional axis: 4, so any overflow items, which would not form the main body, remaining 33-39 items would be controlled by justify-balance. This together with new properties to control the first and last main/cross-section alignment gives endless possibilities to what can be achieved. - justify-content-start: controls the first main axis row: 1 - justify-content-end: controls the last main axis row: n-1 - align-content-start: controls the first main axis row: 1 - align-content-end: controls the last main axis row: n-1 The following possible values are all possible for the settings above. flex-start, flex-end, flex-center, flex-space-between, space-around, stretch There are going to arise many other simplifications to the existing ways of doing things and hacks as well for these properties, which allows for simplifying HTML layouts in many cases, including form layouts. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10032 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
wesleyolis has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox] Feature: justify-balance: [top, equal, bottom, 3:6], j*-c*-[start,...,end] + a*-c*-[start,...,end] when more 3 rows/coloums == This is a suggestion not the final spec of properties of mechanics, they may be ways to further simply things, but this control would allow for a lot of things and further improvements call it hacks to another layout can be composed much more easily. 3 new additional properties for flex layout to be able to adjust the layout easier to what is desired for polishing off flex layout, and controlling the behaviour such that perfectly aesthetically pleasing, preventing the need to write JS or programming code external generators of HTML, CSS into the page. These properties will ensure everything is controlled from within the browser CSS specification. They're is better than the item break control mechanism for certain layouts when in the space of a [2-3]X[2-3] layout hacks for forms as well, so there are further added benefits at the low end of these settings as well, which make the combination of both of these even more powerful and simpler: https://github.com/w3c/csswg-drafts/issues/10031 Currently, when there are more than 2,3 rows of items on the main axis or 2,3 columns of items on the cross-sectional axis, there is no way of controlling, how polished off the layout for the 1st row and last row n-1 on the main axis and the cross axis of items, layout when compared to the general section. These properties can still be applied when less the 3, like with a minimum of 2 rows or 2 columns. I may have 10 rows and 4 columns, the first row, which is 40 items, but I only have 34 items. This means the middle section can be full rows of 4 columns of items, but when it comes to the first row and the last row, how should that be displayed the remaining 2 items could be displayed on the top row or the last row, we probably want to be laid out differently, - justify-balance can be set to control the remaining items that wouldn't cause the body/middle of the layout to be fully populated across its cross-sectional axis. These remaining partial items, can either be placed at the top of the bottom of the main section potentially. justify-balance: top, bottom, equal, or a ratio/fraction of the top-to-bottom(leading/trailing) axis of items. Currently justify-balance: top is how flex would currently work as a progressive algorithm, which does not require multiple passes for response rendering. The grid can be full on the main axis rows, and the cross-sectional axis: 4, so any overflow items, which would not form the main body, remaining 33-39 items would be controlled by justify-balance. This together with new properties to control the first and last main/cross-section alignment gives endless possibilities to what can be achieved. - justify-content-start: controls the first main axis row: 1 - justify-content-end: controls the last main axis row: n-1 - align-content-start: controls the first main axis row: 1 - align-content-end: controls the last main axis row: n-1 The following possible values are all possible for the settings above. flex-start, flex-end, flex-center, flex-space-between, space-around, stretch There are going to arise many other simplifications to the existing ways of doing things and hacks as well for these properties, which allows for simplifying HTML layouts in many cases, including form layouts. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10032 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
wesleyolis has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox] Feature: justify-balance: [top, equal, bottom, 3:6], j*-c*-[start,...,end] + a*-c*-[start,...,end] when more 3 rows/coloums == This is a suggestion not the final spec of properties of mechanics, they may be ways to further simply things, but this control would allow for a lot of things and further improvements call it hacks to another layout can be composed much more easily. 3 new additional properties for flex layout to be able to adjust the layout easier to what is desired for polishing off flex layout, and controlling the behaviour such that perfectly aesthetically pleasing, preventing the need to write JS or programming code external generators of HTML, CSS into the page. These properties will ensure everything is controlled from within the browser CSS specification. They're is better than the item break control mechanism for certain layouts when in the space of a [2-3]X[2-3] layout hacks for forms as well, so there are further added benefits at the low end of these settings as well, which make the combination of both of these even more powerful and simpler: https://github.com/w3c/csswg-drafts/issues/10031 Currently, when there are more than 2,3 rows of items on the main axis or 2,3 columns of items on the cross-sectional axis, there is no way of controlling, how polished off the layout for the 1st row and last row n-1 on the main axis and the cross axis of items, layout when compared to the general section. These properties can still be applied when less the 3, like with a minimum of 2 rows or 2 columns. I may have 10 rows and 4 columns, the first row, which is 40 items, but I only have 34 items. This means the middle section can be full rows of 4 columns of items, but when it comes to the first row and the last row, how should that be displayed the remaining 2 items could be displayed on the top row or the last row, we probably want to be laid out differently, - justify-balance can be set to control the remaining items that wouldn't cause the body/middle of the layout to be fully populated across its cross-sectional axis. These remaining partial items, can either be placed at the top of the bottom of the main section potentially. justify-balance: top, bottom, equal, or a ratio/fraction of the top-to-bottom(leading/trailing) axis of items. Currently justify-balance: top is how flex would currently work as a progressive algorithm, which does not require multiple passes for response rendering. The grid can be full on the main axis rows, and the cross-sectional axis: 4, so any overflow items, which would not form the main body, remaining 33-39 items would be controlled by justify-balance. This together with new properties to control the first and last main/cross-section alignment gives endless possibilities to what can be achieved. - justify-content-start: controls the first main axis row: 1 - justify-content-end: controls the last main axis row: n-1 - align-content-start: controls the first main axis row: 1 - align-content-end: controls the last main axis row: n-1 The following possible values are all possible for the settings above. flex-start, flex-end, flex-center, flex-space-between, space-around, stretch There are going to arise many other simplifications to the existing ways of doing things and hacks as well for these properties, which allows for simplifying HTML layouts in many cases, including form layouts. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10032 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
wesleyolis has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox] Feature: justify-balance: [top, equal, bottom, 3:6], j*-c*-[start,...,end] + a*-c*-[start,...,end] when more 3 rows/coloums == This is a suggestion not the final spec of properties of mechanics, they may be ways to further simply things, but this control would allow for a lot of things and further improvements call it hacks to another layout can be composed much more easily. 3 new additional properties for flex layout to be able to adjust the layout easier to what is desired for polishing off flex layout, and controlling the behaviour such that perfectly aesthetically pleasing, preventing the need to write JS or programming code external generators of HTML, CSS into the page. These properties will ensure everything is controlled from within the browser CSS specification. They're is better than the item break control mechanism for certain layouts when in the space of a [2-3]X[2-3] layout hacks for forms as well, so there are further added benefits at the low end of these settings as well, which make the combination of both of these even more powerful and simpler: https://github.com/w3c/csswg-drafts/issues/10031 Currently, when there are more than 2,3 rows of items on the main axis or 2,3 columns of items on the cross-sectional axis, there is no way of controlling, how polished off the layout for the 1st row and last row n-1 on the main axis and the cross axis of items, layout when compared to the general section. These properties can still be applied when less the 3, like with a minimum of 2 rows or 2 columns. I may have 10 rows and 4 columns, the first row, which is 40 items, but I only have 34 items. This means the middle section can be full rows of 4 columns of items, but when it comes to the first row and the last row, how should that be displayed the remaining 2 items could be displayed on the top row or the last row, we probably want to be laid out differently, - justify-balance can be set to control the remaining items that wouldn't cause the body/middle of the layout to be fully populated across its cross-sectional axis. These remaining partial items, can either be placed at the top of the bottom of the main section potentially. justify-balance: top, bottom, equal, or a ratio/fraction of the top-to-bottom(leading/trailing) axis of items. Currently justify-balance: top is how flex would currently work as a progressive algorithm, which does not require multiple passes for response rendering. The grid can be full on the main axis rows, and the cross-sectional axis: 4, so any overflow items, which would not form the main body, remaining 33-39 items would be controlled by justify-balance. This together with new properties to control the first and last main/cross-section alignment gives endless possibilities to what can be achieved. - justify-content-start: controls the first main axis row: 1 - justify-content-end: controls the last main axis row: n-1 - align-content-start: controls the first main axis row: 1 - align-content-end: controls the last main axis row: n-1 The following possible values are all possible for the settings above. flex-start, flex-end, flex-center, flex-space-between, space-around, stretch There are going to arise many other simplifications to the existing ways of doing things and hacks as well for these properties, which allows for simplifying HTML layouts in many cases, including form layouts. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10032 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
wesleyolis has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox] Feature: justify-balance: [top, equal, bottom, 3:6], j*-c*-[start,...,end] + a*-c*-[start,...,end] when more 3 rows/coloums == This is a suggestion not the final spec of properties of mechanics, they may be ways to further simply things, but this control would allow for a lot of things and further improvements call it hacks to another layout can be composed much more easily. 3 new additional properties for flex layout to be able to adjust the layout easier to what is desired for polishing off flex layout, and controlling the behaviour such that perfectly aesthetically pleasing, preventing the need to write JS or programming code external generators of HTML, CSS into the page. These properties will ensure everything is controlled from within the browser CSS specification. They're is better than the item break control mechanism for certain layouts when in the space of a [2-3]X[2-3] layout hacks for forms as well, so there are further added benefits at the low end of these settings as well, which make the combination of both of these even more powerful and simpler: https://github.com/w3c/csswg-drafts/issues/10031 Currently, when there are more than 2,3 rows of items on the main axis or 2,3 columns of items on the cross-sectional axis, there is no way of controlling, how polished off the layout for the 1st row and last row n-1 on the main axis and the cross axis of items, layout when compared to the general section. These properties can still be applied when less the 3, like with a minimum of 2 rows or 2 columns. I may have 10 rows and 4 columns, the first row, which is 40 items, but I only have 34 items. This means the middle section can be full rows of 4 columns of items, but when it comes to the first row and the last row, how should that be displayed the remaining 2 items could be displayed on the top row or the last row, we probably want to be laid out differently, - justify-balance can be set to control the remaining items that wouldn't cause the body/middle of the layout to be fully populated across its cross-sectional axis. These remaining partial items, can either be placed at the top of the bottom of the main section potentially. justify-balance: top, bottom, equal, or a ratio/fraction of the top-to-bottom(leading/trailing) axis of items. Currently justify-balance: top is how flex would currently work as a progressive algorithm, which does not require multiple passes for response rendering. The grid can be full on the main axis rows, and the cross-sectional axis: 4, so any overflow items, which would not form the main body, remaining 33-39 items would be controlled by justify-balance. This together with new properties to control the first and last main/cross-section alignment gives endless possibilities to what can be achieved. - justify-content-start: controls the first main axis row: 1 - justify-content-end: controls the last main axis row: n-1 - align-content-start: controls the first main axis row: 1 - align-content-end: controls the last main axis row: n-1 The following possible values are all possible for the settings above. flex-start, flex-end, flex-center, flex-space-between, space-around, stretch There are going to arise many other simplifications to the existing ways of doing things and hacks as well for these properties, which allows for simplifying HTML layouts in many cases, including form layouts. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10032 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
wesleyolis has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox] Feature: justify-balance: [top, equal, bottom, 3:6], j*-c*-[start,...,end] + a*-c*-[start,...,end] when more 3 rows/coloums == This is a suggestion not the final spec of properties of mechanics, they may be ways to further simply things, but this control would allow for a lot of things and further improvements call it hacks to another layout can be composed much more easily. 3 new additional properties for flex layout to be able to adjust the layout easier to what is desired for polishing off flex layout, and controlling the behaviour such that perfectly aesthetically pleasing, preventing the need to write JS or programming code external generators of HTML, CSS into the page. These properties will ensure everything is controlled from within the browser CSS specification. They're is better than the item break control mechanism for certain layouts when in the space of a [2-3]X[2-3] layout hacks for forms as well, so there are further added benefits at the low end of these settings as well, which make the combination of both of these even more powerful and simpler: https://github.com/w3c/csswg-drafts/issues/10031 Currently, when there are more than 2,3 rows of items on the main axis or 2,3 columns of items on the cross-sectional axis, there is no way of controlling, how polished off the layout for the 1st row and last row n-1 on the main axis and the cross axis of items, layout when compared to the general section. These properties can still be applied when less the 3, like with a minimum of 2 rows or 2 columns. I may have 10 rows and 4 columns, the first row, which is 40 items, but I only have 34 items. This means the middle section can be full rows of 4 columns of items, but when it comes to the first row and the last row, how should that be displayed the remaining 2 items could be displayed on the top row or the last row, we probably want to be laid out differently, - justify-balance can be set to control the remaining items that wouldn't cause the body/middle of the layout to be fully populated across its cross-sectional axis. These remaining partial items, can either be placed at the top of the bottom of the main section potentially. justify-balance: top, bottom, equal, or a ratio/fraction of the top-to-bottom(leading/trailing) axis of items. Currently justify-balance: top is how flex would currently work as a progressive algorithm, which does not require multiple passes for response rendering. The grid can be full on the main axis rows, and the cross-sectional axis: 4, so any overflow items, which would not form the main body, remaining 33-39 items would be controlled by justify-balance. This together with new properties to control the first and last main/cross-section alignment gives endless possibilities to what can be achieved. - justify-content-start: controls the first main axis row: 1 - justify-content-end: controls the last main axis row: n-1 - align-content-start: controls the first main axis row: 1 - align-content-end: controls the last main axis row: n-1 The following possible values are all possible for the settings above. flex-start, flex-end, flex-center, flex-space-between, space-around, stretch There are going to arise many other simplifications to the existing ways of doing things and hacks as well for these properties, which allows for simplifying HTML layouts in many cases, including form layouts. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10032 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
wesleyolis has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox] Feature: justify-balance: [top, equal, bottom, 3:6], j*-c*-[start,...,end] + a*-c*-[start,...,end] when more 3 rows/coloums == This is a suggestion not the final spec of properties of mechanics, they may be ways to further simply things, but this control would allow for a lot of things and further improvements call it hacks to another layout can be composed much more easily. 3 new additional properties for flex layout to be able to adjust the layout easier to what is desired for polishing off flex layout, and controlling the behaviour such that perfectly aesthetically pleasing, preventing the need to write JS or programming code external generators of HTML, CSS into the page. These properties will ensure everything is controlled from within the browser CSS specification. They're is better than the item break control mechanism for certain layouts when in the space of a [2-3]X[2-3] layout hacks for forms as well, so there are further added benefits at the low end of these settings as well, which make the combination of both of these even more powerful and simpler: https://github.com/w3c/csswg-drafts/issues/10031 Currently, when there are more than 2,3 rows of items on the main axis or 2,3 columns of items on the cross-sectional axis, there is no way of controlling, how polished off the layout for the 1st row and last row n-1 on the main axis and the cross axis of items, layout when compared to the general section. These properties can still be applied when less the 3, like with a minimum of 2 rows or 2 columns. I may have 10 rows and 4 columns, the first row, which is 40 items, but I only have 34 items. This means the middle section can be full rows of 4 columns of items, but when it comes to the first row and the last row, how should that be displayed the remaining 2 items could be displayed on the top row or the last row, we probably want to be laid out differently, - justify-balance can be set to control the remaining items that wouldn't cause the body/middle of the layout to be fully populated across its cross-sectional axis. These remaining partial items, can either be placed at the top of the bottom of the main section potentially. justify-balance: top, bottom, equal, or a ratio/fraction of the top-to-bottom(leading/trailing) axis of items. Currently justify-balance: top is how flex would currently work as a progressive algorithm, which does not require multiple passes for response rendering. The grid can be full on the main axis rows, and the cross-sectional axis: 4, so any overflow items, which would not form the main body, remaining 33-39 items would be controlled by justify-balance. This together with new properties to control the first and last main/cross-section alignment gives endless possibilities to what can be achieved. - justify-content-start: controls the first main axis row: 1 - justify-content-end: controls the last main axis row: n-1 - align-content-start: controls the first main axis row: 1 - align-content-end: controls the last main axis row: n-1 The following possible values are all possible for the settings above. flex-start, flex-end, flex-center, flex-space-between, space-around, stretch There are going to arise many other simplifications to the existing ways of doing things and hacks as well for these properties, which allows for simplifying HTML layouts in many cases, including form layouts. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10032 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
wesleyolis has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox] Feature: Items-Limit-Height - Flex-Line - Main Size Determination == I would like to propose an additional feature for flex, which allows us to abstractly control the Height of the main container which is set to display: flex in which the flex-items would be laided out. Typically one can only limit the height traditional with container style height property. Nowadays we typically design things to be independent of specific measurements of pixels, rem, em if possible, so they work for all devices. The natural design of height property in HTML is to keep expanding to contain its inner contents. I would like to propose that a new property that allows us to control the height for flex items, in which the layout algorithm, would then allow items to be horizontally laid out as the height is softly constrained. This property would take soft precedence over width of a container, basically cause a horizontal/film layout expansion. It must still abide by min-width of items forcing a horizontal expansion of items with min-width property set, would cause the items to no longer shrink and The name of the property is not as important as the functionality, it is just a suggestion. This functionality would allow for a lot of improvements in layout to be made, where by the Items-Limit-height and existing algorithm would cause items to natural be capable of re-laying themselves out as the screen size shrinks for mobile, extra. I have few examples for flex and float I have assembled that cause natural collapsing into mobile layout. Keeping the Title, Error Messages, (spacer) Input Control perfect for both input required display using before or after selectors. This property would just make that and many other things a lot easier to achieve, they also take direction of text into account for languages that are read from left to right and visa versus, where layouts will automatically change. **Examples:** **Naturally bounded by the browse display width and height natural unbounded** .---------------. 1,,,,,,2,,,,,3,,,,,4 5,,,,,,6,,,,,7,,,,,8 9,,,,,10,,11,,,,12, 13,,14,,,15,,,16 .---------------. **With the display:flex;Items-Limit-Height:2** ...............----------------................ 1,,,,,2,,,,|,,3,,,,,4,,,,5,,,,6,,,|,7,,,,,,8 9,,,,10,,,|,11,,12,,13,,14,|,15,,16 ..............-----------------............... **With the display:flex;Items-Limit-Height:2;width:(100%,contain) + Each-Flex-Items:min-width:50% or min-width:contain** In this case, Items-Limit + width, constrain the layout. **_For few items:_** .----------------. ,,,,,,1,,,,+,,,2, ,,,,,,,,,,,,,3, .----------------. **_For few items in which the min-width not set.:_** .----------------. .....1.....2.....3 .....4.....5.....6 .----------------. **_For many items:_** .----------------. .....1.....+.....2, .....3,.....+.....4, .....5.....+.....6, .....7.....+.....8 .....9.....+....10, .....11...+....12, .....13...+....14, .....15...+....16 .----------------. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10031 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
wesleyolis has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox] Feature: Items-Limit-Height - Flex-Line - Main Size Determination == I would like to propose an additional feature for flex, which allows us to abstractly control the Height of the main container which is set to display: flex in which the flex-items would be laided out. Typically one can only limit the height traditional with container style height property. Nowadays we typically design things to be independent of specific measurements of pixels, rem, em if possible, so they work for all devices. The natural design of height property in HTML is to keep expanding to contain its inner contents. I would like to propose that a new property that allows us to control the height for flex items, in which the layout algorithm, would then allow items to be horizontally laid out as the height is softly constrained. This property would take soft precedence over width of a container, basically cause a horizontal/film layout expansion. It must still abide by min-width of items forcing a horizontal expansion of items with min-width property set, would cause the items to no longer shrink and The name of the property is not as important as the functionality, it is just a suggestion. This functionality would allow for a lot of improvements in layout to be made, where by the Items-Limit-height and existing algorithm would cause items to natural be capable of re-laying themselves out as the screen size shrinks for mobile, extra. I have few examples for flex and float I have assembled that cause natural collapsing into mobile layout. Keeping the Title, Error Messages, (spacer) Input Control perfect for both input required display using before or after selectors. This property would just make that and many other things a lot easier to achieve, they also take direction of text into account for languages that are read from left to right and visa versus, where layouts will automatically change. **Examples:** **Naturally bounded by the browse display width and height natural unbounded** .---------------. 1,,,,,,2,,,,,3,,,,,4 5,,,,,,6,,,,,7,,,,,8 9,,,,,10,,11,,,,12, 13,,14,,,15,,,16 .---------------. **With the display:flex;Items-Limit-Height:2** ...............----------------................ 1,,,,,2,,,,|,,3,,,,,4,,,,5,,,,6,,,|,7,,,,,,8 9,,,,10,,,|,11,,12,,13,,14,|,15,,16 ..............-----------------............... **With the display:flex;Items-Limit-Height:2;width:(100%,contain) + Each-Flex-Items:min-width:50% or min-width:contain** In this case, Items-Limit + width, constrain the layout. **_For few items:_** .----------------. ,,,,,,1,,,,+,,,2, ,,,,,,,,,,,,,3, .----------------. **_For few items in which the min-width not set.:_** .----------------. .....1.....2.....3 .....4.....5.....6 .----------------. **_For many items:_** .----------------. .....1.....+.....2, .....3,.....+.....4, .....5.....+.....6, .....7.....+.....8 .....9.....+....10, .....11...+....12, .....13...+....14, .....15...+....16 .----------------. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10031 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
wesleyolis has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox] Feature: Items-Limit-Height - Flex-Line - Main Size Determination == I would like to propose an additional feature for flex, which allows us to abstractly control the Height of the main container which is set to display: flex in which the flex-items would be laided out. Typically one can only limit the height traditional with container style height property. Nowadays we typically design things to be independent of specific measurements of pixels, rem, em if possible, so they work for all devices. The natural design of height property in HTML is to keep expanding to contain its inner contents. I would like to propose that a new property that allows us to control the height for flex items, in which the layout algorithm, would then allow items to be horizontally laid out as the height is softly constrained. This property would take soft precedence over width of a container, basically cause a horizontal/film layout expansion. It must still abide by min-width of items forcing a horizontal expansion of items with min-width property set, would cause the items to no longer shrink and The name of the property is not as important as the functionality, it is just a suggestion. This functionality would allow for a lot of improvements in layout to be made, where by the Items-Limit-height and existing algorithm would cause items to natural be capable of re-laying themselves out as the screen size shrinks for mobile, extra. I have few examples for flex and float I have assembled that cause natural collapsing into mobile layout. Keeping the Title, Error Messages, (spacer) Input Control perfect for both input required display using before or after selectors. This property would just make that and many other things a lot easier to achieve, they also take direction of text into account for languages that are read from left to right and visa versus, where layouts will automatically change. **Examples:** **Naturally bounded by the browse display width and height natural unbounded** .---------------. 1,,,,,,2,,,,,3,,,,,4 5,,,,,,6,,,,,7,,,,,8 9,,,,,10,,11,,,,12, 13,,14,,,15,,,16 .---------------. **With the display:flex;Items-Limit-Height:2** ...............----------------................ 1,,,,,2,,,,|,,3,,,,,4,,,,5,,,,6,,,|,7,,,,,,8 9,,,,10,,,|,11,,12,,13,,14,|,15,,16 ..............-----------------............... **With the display:flex;Items-Limit-Height:2;width:(100%,contain) + Each-Flex-Items:min-width:50% or min-width:contain** In this case, Items-Limit + width, constrain the layout. **_For few items:_** .----------------. ,,,,,,1,,,,+,,,2, ,,,,,,,,,,,,,3, .----------------. **_For few items in which the min-width not set.:_** .----------------. .....1.....2.....3 .....4.....5.....6 .----------------. **_For many items:_** .----------------. .....1.....+.....2, .....3,.....+.....4, .....5.....+.....6, .....7.....+.....8 .....9.....+....10, .....11...+....12, .....13...+....14, .....15...+....16 .----------------. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10031 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
wesleyolis has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox] Feature: Items-Limit-Height - Flex-Line - Main Size Determination == I would like to propose an additional feature for flex, which allows us to abstractly control the Height of the main container which is set to display: flex in which the flex-items would be laided out. Typically one can only limit the height traditional with container style height property. Nowadays we typically design things to be independent of specific measurements of pixels, rem, em if possible, so they work for all devices. The natural design of height property in HTML is to keep expanding to contain its inner contents. I would like to propose that a new property that allows us to control the height for flex items, in which the layout algorithm, would then allow items to be horizontally laid out as the height is softly constrained. This property would take soft precedence over width of a container, basically cause a horizontal/film layout expansion. It must still abide by min-width of items forcing a horizontal expansion of items with min-width property set, would cause the items to no longer shrink and The name of the property is not as important as the functionality, it is just a suggestion. This functionality would allow for a lot of improvements in layout to be made, where by the Items-Limit-height and existing algorithm would cause items to natural be capable of re-laying themselves out as the screen size shrinks for mobile, extra. I have few examples for flex and float I have assembled that cause natural collapsing into mobile layout. Keeping the Title, Error Messages, (spacer) Input Control perfect for both input required display using before or after selectors. This property would just make that and many other things a lot easier to achieve, they also take direction of text into account for languages that are read from left to right and visa versus, where layouts will automatically change. **Examples:** **Naturally bounded by the browse display width and height natural unbounded** .---------------. 1,,,,,,2,,,,,3,,,,,4 5,,,,,,6,,,,,7,,,,,8 9,,,,,10,,11,,,,12, 13,,14,,,15,,,16 .---------------. **With the display:flex;Items-Limit-Height:2** ...............----------------................ 1,,,,,2,,,,|,,3,,,,,4,,,,5,,,,6,,,|,7,,,,,,8 9,,,,10,,,|,11,,12,,13,,14,|,15,,16 ..............-----------------............... **With the display:flex;Items-Limit-Height:2;width:(100%,contain) + Each-Flex-Items:min-width:50% or min-width:contain** In this case, Items-Limit + width, constrain the layout. **_For few items:_** .----------------. ,,,,,,1,,,,+,,,2, ,,,,,,,,,,,,,3, .----------------. **_For few items in which the min-width not set.:_** .----------------. .....1.....2.....3 .....4.....5.....6 .----------------. **_For many items:_** .----------------. .....1.....+.....2, .....3,.....+.....4, .....5.....+.....6, .....7.....+.....8 .....9.....+....10, .....11...+....12, .....13...+....14, .....15...+....16 .----------------. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10031 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
wesleyolis has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox] Feature: Items-Limit-Height - Flex-Line - Main Size Determination == I would like to propose an additional feature for flex, which allows us to abstractly control the Height of the main container which is set to display: flex in which the flex-items would be laided out. Typically one can only limit the height traditional with container style height property. Nowadays we typically design things to be independent of specific measurements of pixels, rem, em if possible, so they work for all devices. The natural design of height property in HTML is to keep expanding to contain its inner contents. I would like to propose that a new property that allows us to control the height for flex items, in which the layout algorithm, would then allow items to be horizontally laid out as the height is softly constrained. This property would take soft precedence over width of a container, basically cause a horizontal/film layout expansion. It must still abide by min-width of items forcing a horizontal expansion of items with min-width property set, would cause the items to no longer shrink and The name of the property is not as important as the functionality, it is just a suggestion. This functionality would allow for a lot of improvements in layout to be made, where by the Items-Limit-height and existing algorithm would cause items to natural be capable of re-laying themselves out as the screen size shrinks for mobile, extra. I have few examples for flex and float I have assembled that cause natural collapsing into mobile layout. Keeping the Title, Error Messages, (spacer) Input Control perfect for both input required display using before or after selectors. This property would just make that and many other things a lot easier to achieve, they also take direction of text into account for languages that are read from left to right and visa versus, where layouts will automatically change. **Examples:** **Naturally bounded by the browse display width and height natural unbounded** .---------------. 1,,,,,,2,,,,,3,,,,,4 5,,,,,,6,,,,,7,,,,,8 9,,,,,10,,11,,,,12, 13,,14,,,15,,,16 .---------------. **With the display:flex;Items-Limit-Height:2** ...............----------------................ 1,,,,,2,,,,|,,3,,,,,4,,,,5,,,,6,,,|,7,,,,,,8 9,,,,10,,,|,11,,12,,13,,14,|,15,,16 ..............-----------------............... **With the display:flex;Items-Limit-Height:2;width:(100%,contain) + Each-Flex-Items:min-width:50% or min-width:contain** In this case, Items-Limit + width, constrain the layout. **_For few items:_** .----------------. ,,,,,,1,,,,+,,,2, ,,,,,,,,,,,,,3, .----------------. **_For few items in which the min-width not set.:_** .----------------. .....1.....2.....3 .....4.....5.....6 .----------------. **_For many items:_** .----------------. .....1.....+.....2, .....3,.....+.....4, .....5.....+.....6, .....7.....+.....8 .....9.....+....10, .....11...+....12, .....13...+....14, .....15...+....16 .----------------. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10031 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/3334 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
So, given that: - the primary source of CSS WG tests is now WPT not the ancient and un-maintained tests in Shepherd - CSS WG specs increasingly use the `<wpt>` annotations to link from specs to individual tests - Bikeshed complains about missing tests (in WPT but not in the bikeshed source) and unfindable tests (in bikeshed but not in WPT I believe this issue is in practice solved for many years now. Closing. -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2438#issuecomment-1978058007 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/2438 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
So, these were all fixed by 2018 yet the issue remains open. -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1230#issuecomment-1978052808 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/1230 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/207 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/207 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Should we just close this issue then? Or is a spec PR needed to clarify? -- GitHub Notification of comment by chrishtr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9911#issuecomment-1977885268 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Should we just close this issue then? Or is a spec PR needed to clarify? -- GitHub Notification of comment by chrishtr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9911#issuecomment-1977885268 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Should we just close this issue then? Or is a spec PR needed to clarify? -- GitHub Notification of comment by chrishtr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9911#issuecomment-1977885268 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Should we just close this issue then? Or is a spec PR needed to clarify? -- GitHub Notification of comment by chrishtr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9911#issuecomment-1977885268 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Should we just close this issue then? Or is a spec PR needed to clarify? -- GitHub Notification of comment by chrishtr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9911#issuecomment-1977885268 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Should we just close this issue then? Or is a spec PR needed to clarify? -- GitHub Notification of comment by chrishtr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9911#issuecomment-1977885268 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Should we just close this issue then? Or is a spec PR needed to clarify? -- GitHub Notification of comment by chrishtr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9911#issuecomment-1977885268 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
chrishtr has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [cssom-viewport] Add specification for `currentCSSZoom` == Resolves #9809 See https://github.com/w3c/csswg-drafts/pull/10030 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
So I fixed 21 of our specs [with this commit](https://github.com/w3c/csswg-drafts/commit/095f2a813c0a9bf2c8bbf259a08e8bd3e7560dbe) and the remaining ones are mostly old specs that still use the .src format; as the preprocessor for that is ancient history and does not generate a publishable spec, the way forward for those is to edit the generated html, sadly. -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/207#issuecomment-1977762090 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
So I fixed 21 of our specs [with this commit](https://github.com/w3c/csswg-drafts/commit/095f2a813c0a9bf2c8bbf259a08e8bd3e7560dbe) and the remaining ones are mostly old specs that still use the .src format; as the preprocessor for that is ancient history and does not generate a publishable spec, the way forward for those is to edit the generated html, sadly. -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/207#issuecomment-1977762090 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
So I fixed 21 of our specs [with this commit](https://github.com/w3c/csswg-drafts/commit/095f2a813c0a9bf2c8bbf259a08e8bd3e7560dbe) and the remaining ones are mostly old specs that still use the .src format; as the preprocessor for that is ancient history and does not generate a publishable spec, the way forward for those is to edit the generated html, sadly. -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/207#issuecomment-1977762090 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment with specific changes you believe should be made to css-scrollbars-1 Proposed Resolution: Close this issue for lack of specific change requests -- GitHub Notification of comment by astearns Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6984#issuecomment-1977731088 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment with specific changes you believe should be made to css-scrollbars-1 Proposed Resolution: Close this issue for lack of specific change requests -- GitHub Notification of comment by astearns Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6984#issuecomment-1977731088 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@yoavweiss @noamr Where would be the right spot to open an issue about breaking change guidelines? I believe it fits under the mission statement for W3C to develop a standard operating procedure. -- GitHub Notification of comment by philcunliffe Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5165#issuecomment-1977654157 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@yoavweiss @noamr Where would be the right spot to open an issue about breaking change guidelines? I believe it fits under the mission statement for W3C to develop a standard operating procedure. -- GitHub Notification of comment by philcunliffe Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5165#issuecomment-1977654157 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@yoavweiss @noamr Where would be the right spot to open an issue about breaking change guidelines? I believe it fits under the mission statement for W3C to develop a standard operating procedure. -- GitHub Notification of comment by philcunliffe Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5165#issuecomment-1977654157 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
argyleink has just created a new issue for https://github.com/w3c/csswg-drafts: == `css-color` unspecified target contrast ratios with `contrast-color()` should use the users preference == https://drafts.csswg.org/css-color-6/ The general goal of `contrast-color()` is to provide legible color pairings for users and make it "easy" for authors. In that ethos, I think the function could use the user's [contrast preference](https://www.w3.org/TR/mediaqueries-5/#prefers-contrast) when resolving a color. This would prevent code duplication if authors were expected to repeat the `contrast-color()` function within media queries, passing explicit target values within the queries. This issue/proposal wants to make the user's contrast preference easier to implement for authors, and also make the default function value the most dynamic and appropriate value for users. tldr; the default for authors would be to let the browser figure it out for each user, not a default of authors needing to know what scores match each user preference. Quick user story: A user prefers contrast `more` in their OS settings, `contrast-color()` defaults to using this preference and resolves a value for them to a contrast target of AAA/7. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10029 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
argyleink has just created a new issue for https://github.com/w3c/csswg-drafts: == `css-color` unspecified target contrast ratios with `contrast-color()` should use the users preference == https://drafts.csswg.org/css-color-6/ The general goal of `contrast-color()` is to provide legible color pairings for users and make it "easy" for authors. In that ethos, I think the function could use the user's [contrast preference](https://www.w3.org/TR/mediaqueries-5/#prefers-contrast) when resolving a color. This would prevent code duplication if authors were expected to repeat the `contrast-color()` function within media queries, passing explicit target values within the queries. This issue/proposal wants to make the user's contrast preference easier to implement for authors, and also make the default function value the most dynamic and appropriate value for users. tldr; the default for authors would be to let the browser figure it out for each user, not a default of authors needing to know what scores match each user preference. Quick user story: A user prefers contrast `more` in their OS settings, `contrast-color()` defaults to using this preference and resolves a value for them to a contrast target of AAA/7. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10029 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
argyleink has just created a new issue for https://github.com/w3c/csswg-drafts: == `css-color` unspecified target contrast ratios with `contrast-color()` should use the users preference == https://drafts.csswg.org/css-color-6/ The general goal of `contrast-color()` is to provide legible color pairings for users and make it "easy" for authors. In that ethos, I think the function could use the user's [contrast preference](https://www.w3.org/TR/mediaqueries-5/#prefers-contrast) when resolving a color. This would prevent code duplication if authors were expected to repeat the `contrast-color()` function within media queries, passing explicit target values within the queries. This issue/proposal wants to make the user's contrast preference easier to implement for authors, and also make the default function value the most dynamic and appropriate value for users. tldr; the default for authors would be to let the browser figure it out for each user, not a default of authors needing to know what scores match each user preference. Quick user story: A user prefers contrast `more` in their OS settings, `contrast-color()` defaults to using this preference and resolves a value for them to a contrast target of AAA/7. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10029 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
argyleink has just created a new issue for https://github.com/w3c/csswg-drafts: == `css-color` unspecified target contrast ratios with `contrast-color()` should use the users preference == https://drafts.csswg.org/css-color-6/ The general goal of `contrast-color()` is to provide legible color pairings for users and make it "easy" for authors. In that ethos, I think the function could use the user's [contrast preference](https://www.w3.org/TR/mediaqueries-5/#prefers-contrast) when resolving a color. This would prevent code duplication if authors were expected to repeat the `contrast-color()` function within media queries, passing explicit target values within the queries. This issue/proposal wants to make the user's contrast preference easier to implement for authors, and also make the default function value the most dynamic and appropriate value for users. tldr; the default for authors would be to let the browser figure it out for each user, not a default of authors needing to know what scores match each user preference. Quick user story: A user prefers contrast `more` in their OS settings, `contrast-color()` defaults to using this preference and resolves a value for them to a contrast target of AAA/7. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10029 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@nex3 I am so sorry. I keep reading over this issue, reading over related issues, and trying to come up with a self-consistent set of principles for when clamping happens and why; but in some cases the "why" is "historical precedent from CSS Color 3" and stuff like that. So I don't form a coherent answer and leave it to come back to. That must be very frustrating, my apologies. The "in practice" is because CSS Color 3 puts two different things into one paragraph: parse-time clamping of HSL input and display-time clamping to the device gamut: > If saturation is less than 0%, implementations must clip it to 0%. If the resulting value is outside the device gamut, implementations must clip it to the device gamut. This clipping should preserve the hue when possible, but is otherwise undefined. (In other words, the clipping is different from applying the rules for clipping of RGB colors after applying the algorithm below for converting HSL to RGB.) Because implementations at that time assumed all screens were sRGB, and also because `hsl()` serializes as `rgb()` with only 8-bit precision, implementations of that time can't be blamed for condensing that into one operation on input. -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9484#issuecomment-1977503873 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@emilio would Gecko have any concerns with specifying that the root can float? -- GitHub Notification of comment by astearns Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8196#issuecomment-1977495836 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
josepharhar has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-ui] Changing UA styles based on the computed value of the appearance property == I'm working on improvements to the `<select>` element ([whatwg thread here](https://github.com/whatwg/html/issues/9799)), and I came across an issue while implementing a prototype of the Apple-supported behavior of switching to a new rendering mode based on the value of the appearance property. The select element has several UA style rules which we don't want in the new rendering mode, such as [white-space:pre](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/resources/html.css;l=919;drc=c96c313ac1e6c9b64abc5ee2d50315995770e2c2), which makes all of the options in the popup have a bunch of line breaks rendered in my examples. I tried adding an internal pseudo-selector which matches when the element has the new appearance value, but I found that it took two style updates to get the final style, which @andruud [described as a "non-starter"](https://chromium-review.googlesource.com/c/chromium/src/+/5315083/comment/ab7d1c7c_dd14d5aa/). @annevk suggested that I should ask here to see if there is a way that we can make this work. Also, if there are any previous discussions about the appearance property that are related to this, I would appreciate links to them. cc @nt1m Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10028 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> `text-orientation` should have an effect on `::marker`, so that, for instance, you can have upright numerals in a numbered list's markers, and otherwise mixed orientation text. > > ```css > ol { > writing-mode: vertical-rl; > text-orientation: mixed; /*the default*/ > } > ol li::marker { > text-orientation: upright; > } > ``` > > Here's a test case: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=12266 > > Currently, all browsers fail it. I _think_ that's a browser bug, as even though `text-orientation` isn't part of the [set of properties that apply directly to the `::marker` pseudo](https://drafts.csswg.org/css-lists-3/#marker-properties), it should inherit into the text inside the marker and apply there. Do we agree, or is there something somewhere in the spec that actually makes it the expected behavior? -- GitHub Notification of comment by Theshrink Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9788#issuecomment-1976958670 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> `text-orientation` should have an effect on `::marker`, so that, for instance, you can have upright numerals in a numbered list's markers, and otherwise mixed orientation text. > > ```css > ol { > writing-mode: vertical-rl; > text-orientation: mixed; /*the default*/ > } > ol li::marker { > text-orientation: upright; > } > ``` > > Here's a test case: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=12266 > > Currently, all browsers fail it. I _think_ that's a browser bug, as even though `text-orientation` isn't part of the [set of properties that apply directly to the `::marker` pseudo](https://drafts.csswg.org/css-lists-3/#marker-properties), it should inherit into the text inside the marker and apply there. Do we agree, or is there something somewhere in the spec that actually makes it the expected behavior? -- GitHub Notification of comment by Theshrink Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9788#issuecomment-1976958670 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Thanks for all the input here! I like bottosson's suggestion of having a mapping to most of the visual spectrum rather than a specific gamut. I definitely would like a normative mapping for `oklab` and `oklch` that gets us to something like that. That would also provide a good delineation of "up to this point you do it this normative way, but after that it's up to you to get to the screen". I might be a bit more iffy about imposing that mapping on the RGB spaces (because they have clearer guardrails, and for their potential use as extended spaces), but I think the impact of how that is resolved is much smaller. -- GitHub Notification of comment by ccameron-chromium Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1976443978 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Thanks for all the input here! I like bottosson's suggestion of having a mapping to most of the visual spectrum rather than a specific gamut. I definitely would like a normative mapping for `oklab` and `oklch` that gets us to something like that. That would also provide a good delineation of "up to this point you do it this normative way, but after that it's up to you to get to the screen". I might be a bit more iffy about imposing that mapping on the RGB spaces (because they have clearer guardrails, and for their potential use as extended spaces), but I think the impact of how that is resolved is much smaller. -- GitHub Notification of comment by ccameron-chromium Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1976443978 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Thanks for all the input here! I like bottosson's suggestion of having a mapping to most of the visual spectrum rather than a specific gamut. I definitely would like a normative mapping for `oklab` and `oklch` that gets us to something like that. That would also provide a good delineation of "up to this point you do it this normative way, but after that it's up to you to get to the screen". I might be a bit more iffy about imposing that mapping on the RGB spaces (because they have clearer guardrails, and for their potential use as extended spaces), but I think the impact of how that is resolved is much smaller. -- GitHub Notification of comment by ccameron-chromium Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1976443978 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Thanks for all the input here! I like bottosson's suggestion of having a mapping to most of the visual spectrum rather than a specific gamut. I definitely would like a normative mapping for `oklab` and `oklch` that gets us to something like that. That would also provide a good delineation of "up to this point you do it this normative way, but after that it's up to you to get to the screen". I might be a bit more iffy about imposing that mapping on the RGB spaces (because they have clearer guardrails, and for their potential use as extended spaces), but I think the impact of how that is resolved is much smaller. -- GitHub Notification of comment by ccameron-chromium Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1976443978 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> having a correctly sized cursor in all browsers seems more important than having it crisp See that's just wrong. Windows would never show a blurry cursor on devicePixelRatio=1.25, people would go mad. So they chose to show a crisp cursor, even if it's slightly smaller. So most browser users with a mouse already see crisps cursors over correctly sized cursors for years now. Lastly, image-set() doesn't solve the problem. I don't want to provide 4-5 images for each cursor and pray that it matches every dpr out there, I just want an option to disable this silly feature. -- GitHub Notification of comment by capr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2480#issuecomment-1976334348 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I plan to align Servo with other browsers. There was already test coverage: - /css/css-position/position-relative-007.html - /css/css-values/calc-offsets-relative-bottom-1.html - /css/css-values/calc-offsets-relative-top-1.html -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9353#issuecomment-1975402522 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I plan to align Servo with other browsers. There was already test coverage: - /css/css-position/position-relative-007.html - /css/css-values/calc-offsets-relative-bottom-1.html - /css/css-values/calc-offsets-relative-top-1.html -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9353#issuecomment-1975402522 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I plan to align Servo with other browsers. There was already test coverage: - /css/css-position/position-relative-007.html - /css/css-values/calc-offsets-relative-bottom-1.html - /css/css-values/calc-offsets-relative-top-1.html -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9353#issuecomment-1975402522 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I plan to align Servo with other browsers. There was already test coverage: - /css/css-position/position-relative-007.html - /css/css-values/calc-offsets-relative-bottom-1.html - /css/css-values/calc-offsets-relative-top-1.html -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9353#issuecomment-1975402522 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I plan to align Servo with other browsers. There was already test coverage: - /css/css-position/position-relative-007.html - /css/css-values/calc-offsets-relative-bottom-1.html - /css/css-values/calc-offsets-relative-top-1.html -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9353#issuecomment-1975402522 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
UA-OS communication is outside of the scope of CSS. Also I wouldn't tie `prefers-color-scheme` to a HTTP header, because the user might change the setting after loading the page. It should be possible to update the media query without requiring a reload with different HTTP headers. -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10015#issuecomment-1975372321 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
UA-OS communication is outside of the scope of CSS. Also I wouldn't tie `prefers-color-scheme` to a HTTP header, because the user might change the setting after loading the page. It should be possible to update the media query without requiring a reload with different HTTP headers. -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10015#issuecomment-1975372321 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Alternatively, a new property could be introduced to specify the “gravitational” center of a box which is used for (`center`) alignment. -- GitHub Notification of comment by Crissov Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1849#issuecomment-1975368583 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Alternatively, a new property could be introduced to specify the “gravitational” center of a box which is used for (`center`) alignment. -- GitHub Notification of comment by Crissov Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1849#issuecomment-1975368583 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Alternatively, a new property could be introduced to specify the “gravitational” center of a box which is used for (`center`) alignment. -- GitHub Notification of comment by Crissov Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1849#issuecomment-1975368583 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Alternatively, a new property could be introduced to specify the “gravitational” center of a box which is used for (`center`) alignment. -- GitHub Notification of comment by Crissov Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1849#issuecomment-1975368583 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Thiago2104 has just created a new issue for https://github.com/w3c/csswg-drafts: == Request for New CSS Property: 'mask-rotation' == ### Summary: I am proposing the addition of a new CSS property, mask-rotation, to provide developers with more control over the orientation and rotation of CSS masks. ### Motivation: Currently, CSS offers properties like `mask-size`, `mask-origin`, and `mask-position` for controlling the size, origin, and position of masks. However, there is no direct property to manage the rotation or orientation of the mask. This feature would be particularly useful for scenarios where precise control over the mask's rotation is required. ### Proposed Solution: Introduce a new property, mask-rotation, that allows developers to specify the rotation angle for CSS masks. The property value could accept degrees (deg) as a unit, similar to how rotate works in transformations. ### Example: ```css .element { mask-image: url('mask.png'); mask-size: cover; mask-origin: center; mask-rotation: 45deg; /* Rotates mask-image 45 degrees clock-wise */ } ``` ### Key Words: The new property could have key words to specify the type of rotation and the axis where it is rotating: - `right`: Rotate the mask 90 degrees - `flip`: Rotate the mask 180 degrees - `left`: Rotate the mask 270 degrees Also, adding the axis to the key words specify the axis where it is rotating: - 'x' (default): Rotates in clock-wise direction - 'y': Rotates mask horizontally - 'z': Rotates mask vertically ### Example: ```css .element { mask-image: url('mask.png'); mask-size: cover; mask-origin: center; mask-rotation: y right, flip; /* Rotates mask-image horizontally 90 degrees, and rotates mask 180 degrees clock-wise */ } ``` ### Benefits: - Enhances flexibility in designing complex visual elements. - Provides a more comprehensive set of tools for controlling mask behavior. - Enables masks complex animations. - Aligns with existing CSS properties, making it intuitive for developers. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10024 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Thiago2104 has just created a new issue for https://github.com/w3c/csswg-drafts: == Request for New CSS Property: 'mask-rotation' == ### Summary: I am proposing the addition of a new CSS property, mask-rotation, to provide developers with more control over the orientation and rotation of CSS masks. ### Motivation: Currently, CSS offers properties like `mask-size`, `mask-origin`, and `mask-position` for controlling the size, origin, and position of masks. However, there is no direct property to manage the rotation or orientation of the mask. This feature would be particularly useful for scenarios where precise control over the mask's rotation is required. ### Proposed Solution: Introduce a new property, mask-rotation, that allows developers to specify the rotation angle for CSS masks. The property value could accept degrees (deg) as a unit, similar to how rotate works in transformations. ### Example: ```css .element { mask-image: url('mask.png'); mask-size: cover; mask-origin: center; mask-rotation: 45deg; /* Rotates mask-image 45 degrees clock-wise */ } ``` ### Key Words: The new property could have key words to specify the type of rotation and the axis where it is rotating: - `right`: Rotate the mask 90 degrees - `flip`: Rotate the mask 180 degrees - `left`: Rotate the mask 270 degrees Also, adding the axis to the key words specify the axis where it is rotating: - 'x' (default): Rotates in clock-wise direction - 'y': Rotates mask horizontally - 'z': Rotates mask vertically ### Example: ```css .element { mask-image: url('mask.png'); mask-size: cover; mask-origin: center; mask-rotation: y right, flip; /* Rotates mask-image horizontally 90 degrees, and rotates mask 180 degrees clock-wise */ } ``` ### Benefits: - Enhances flexibility in designing complex visual elements. - Provides a more comprehensive set of tools for controlling mask behavior. - Enables masks complex animations. - Aligns with existing CSS properties, making it intuitive for developers. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10024 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
abc1000200 has just created a new issue for https://github.com/w3c/csswg-drafts: == ?##### == please tag the issue title with the spec's shortname, like `[css-foo]` (this is the name from the spec URL, without a level number unless the issue is specific to that level). If you're proposing a new feature that doesn't obviously fit in an existing spec, skip this part — don't make something up. * please be specific (in the title and issue) about what you want to change: “make it better” means different things to different people! * please link to the spec section you're talking about, or at least the spec Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10023 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
abc1000200 has just created a new issue for https://github.com/w3c/csswg-drafts: == ?##### == please tag the issue title with the spec's shortname, like `[css-foo]` (this is the name from the spec URL, without a level number unless the issue is specific to that level). If you're proposing a new feature that doesn't obviously fit in an existing spec, skip this part — don't make something up. * please be specific (in the title and issue) about what you want to change: “make it better” means different things to different people! * please link to the spec section you're talking about, or at least the spec Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10023 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
abc1000200 has just created a new issue for https://github.com/w3c/csswg-drafts: == Foo == * please tag the issue title with the spec's shortname, like `[css-foo]` (this is the name from the spec URL, without a level number unless the issue is specific to that level). If you're proposing a new feature that doesn't obviously fit in an existing spec, skip this part — don't make something up. * please be specific (in the title and issue) about what you want to change: “make it better” means different things to different people! * please link to the spec section you're talking about, or at least the spec Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10022 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
abc1000200 has just created a new issue for https://github.com/w3c/csswg-drafts: == Foo == * please tag the issue title with the spec's shortname, like `[css-foo]` (this is the name from the spec URL, without a level number unless the issue is specific to that level). If you're proposing a new feature that doesn't obviously fit in an existing spec, skip this part — don't make something up. * please be specific (in the title and issue) about what you want to change: “make it better” means different things to different people! * please link to the spec section you're talking about, or at least the spec Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10022 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
abc1000200 has just created a new issue for https://github.com/w3c/csswg-drafts: == Foo == * please tag the issue title with the spec's shortname, like `[css-foo]` (this is the name from the spec URL, without a level number unless the issue is specific to that level). If you're proposing a new feature that doesn't obviously fit in an existing spec, skip this part — don't make something up. * please be specific (in the title and issue) about what you want to change: “make it better” means different things to different people! * please link to the spec section you're talking about, or at least the spec Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10022 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
abc1000200 has just created a new issue for https://github.com/w3c/csswg-drafts: == Foo == * please tag the issue title with the spec's shortname, like `[css-foo]` (this is the name from the spec URL, without a level number unless the issue is specific to that level). If you're proposing a new feature that doesn't obviously fit in an existing spec, skip this part — don't make something up. * please be specific (in the title and issue) about what you want to change: “make it better” means different things to different people! * please link to the spec section you're talking about, or at least the spec Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10022 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
abc1000200 has just created a new issue for https://github.com/w3c/csswg-drafts: == Given the implications on screenshot based testing, we should let the WebDriver WG know if we decide to make it web-platform unobservable when all subresources are loaded. (Note `@font-face` is observable through the Font Loading API; the issue here is things like `background-image`.) == Given the implications on screenshot based testing, we should let the WebDriver WG know if we decide to make it web-platform unobservable when all subresources are loaded. (Note `@font-face` is observable through the Font Loading API; the issue here is things like `background-image`.) _Originally posted by @gsnedders in https://github.com/w3c/csswg-drafts/issues/1088#issuecomment-312399699_ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10021 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
abc1000200 has just created a new issue for https://github.com/w3c/csswg-drafts: == Given the implications on screenshot based testing, we should let the WebDriver WG know if we decide to make it web-platform unobservable when all subresources are loaded. (Note `@font-face` is observable through the Font Loading API; the issue here is things like `background-image`.) == Given the implications on screenshot based testing, we should let the WebDriver WG know if we decide to make it web-platform unobservable when all subresources are loaded. (Note `@font-face` is observable through the Font Loading API; the issue here is things like `background-image`.) _Originally posted by @gsnedders in https://github.com/w3c/csswg-drafts/issues/1088#issuecomment-312399699_ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10021 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
abc1000200 has just created a new issue for https://github.com/w3c/csswg-drafts: == Given the implications on screenshot based testing, we should let the WebDriver WG know if we decide to make it web-platform unobservable when all subresources are loaded. (Note `@font-face` is observable through the Font Loading API; the issue here is things like `background-image`.) == Given the implications on screenshot based testing, we should let the WebDriver WG know if we decide to make it web-platform unobservable when all subresources are loaded. (Note `@font-face` is observable through the Font Loading API; the issue here is things like `background-image`.) _Originally posted by @gsnedders in https://github.com/w3c/csswg-drafts/issues/1088#issuecomment-312399699_ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10021 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> Moving this over from https://www.w3.org/Bugs/Public/show_bug.cgi?id=17011, given that's apparently appropriate nowadays. > > CSS should somewhere (hence the lack of any tagged spec!) define which subresources block the load event; at least when that bug was filed IE, Firefox, and Opera blocked the load event on background images and on web fonts loading (which is therefore related to #1082), Safari and Chrome (and this is pre-fork!) didn't, blocking only on `@import`. > > I believe someone claimed recently that Edge matches Safari and Chrome, making Firefox the odd one out. Someone should, however, test that. -- GitHub Notification of comment by abc1000200 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1088#issuecomment-1975247828 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
In a comment on #10001, I suggested that it would be useful for airport to be able to posts an attribute value, `class` in particular, as a space-separated list and randomly access its entries. Would this be in scope of this issue? With explicit type conversion functions, the [current specification of `attr()`](https://drafts.csswg.org/css-values-5/#funcdef-attr) could be simplified a lot because its second parameter [`<attributes-type>`](https://drafts.csswg.org/css-values-5/#attr-types) would not be necessary anymore. -- GitHub Notification of comment by Crissov Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6408#issuecomment-1975079791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
In a comment on #10001, I suggested that it would be useful for airport to be able to posts an attribute value, `class` in particular, as a space-separated list and randomly access its entries. Would this be in scope of this issue? With explicit type conversion functions, the [current specification of `attr()`](https://drafts.csswg.org/css-values-5/#funcdef-attr) could be simplified a lot because its second parameter [`<attributes-type>`](https://drafts.csswg.org/css-values-5/#attr-types) would not be necessary anymore. -- GitHub Notification of comment by Crissov Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6408#issuecomment-1975079791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Fwiw, in #9955: > RESOLVED: % that are resolved against numbers do that at parse time The issue was also about resolving `<percentage>` to `<angle>` at parse time (as noted in the title of the issue but not in the initial comment though). So `opacity: calc(50% + 0.5)` or `background-color: hsl(from blue calc(h + 30deg) calc(s + 25%) calc(l + 5%))` would be valid. That said, I am not fond of resolving values at parse time, whether it is naked or inside a math function. Would you also allow `font-weight: calc(bold + 100)`, since `bold` could be resolved to `<number>` at parse time? -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9955#issuecomment-1974857567 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Fwiw, in #9955: > RESOLVED: % that are resolved against numbers do that at parse time The issue was also about resolving `<percentage>` to `<angle>` at parse time (as noted in the title of the issue but not in the initial comment though). So `opacity: calc(50% + 0.5)` or `background-color: hsl(from blue calc(h + 30deg) calc(s + 25%) calc(l + 5%))` would be valid. That said, I am not fond of resolving values at parse time, whether it is naked or inside a math function. Would you also allow `font-weight: calc(bold + 100)`, since `bold` could be resolved to `<number>` at parse time? -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9955#issuecomment-1974857567 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Fwiw, in #9955: > RESOLVED: % that are resolved against numbers do that at parse time The issue was also about resolving `<percentage>` to `<angle>` at parse time (as noted in the title of the issue but not in the initial comment though). So `opacity: calc(50% + 0.5)` or `background-color: hsl(from blue calc(h + 30deg) calc(s + 25%) calc(l + 5%))` would be valid. That said, I am not fond of resolving values at parse time, whether it is naked or inside a math function. Would you also allow `font-weight: calc(bold + 100)`, since `bold` could be resolved to `<number>` at parse time? -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9955#issuecomment-1974857567 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Fwiw, in #9955: > RESOLVED: % that are resolved against numbers do that at parse time The issue was also about resolving `<percentage>` to `<angle>` at parse time (as noted in the title of the issue but not in the initial comment though). So `opacity: calc(50% + 0.5)` or `background-color: hsl(from blue calc(h + 30deg) calc(s + 25%) calc(l + 5%))` would be valid. That said, I am not fond of resolving values at parse time, whether it is naked or inside a math function. Would you also allow `font-weight: calc(bold + 100)`, since `bold` could be resolved to `<number>` at parse time? -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9955#issuecomment-1974857567 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Fwiw, in #9955: > RESOLVED: % that are resolved against numbers do that at parse time The issue was also about resolving `<percentage>` to `<angle>` at parse time (as noted in the title of the issue but not in the initial comment though). So `opacity: calc(50% + 0.5)` or `background-color: hsl(from blue calc(h + 30deg) calc(s + 25%) calc(l + 5%))` would be valid. That said, I am not fond of resolving values at parse time, whether it is naked or inside a math function. Would you also allow `font-weight: calc(bold + 100)`, since `bold` could be resolved to `<number>` at parse time? -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9955#issuecomment-1974857567 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> I did, however, neglect to handle the case where a font can support both values of the boolean toggle. Is this still the case or has there been any progress on this issue? It's very strange not to be able to use `font-style` as a descriptor for a variable font file that contains both roman and italic glyphs. If all my reading trying to understand this is correct, it sounds like the only way to use the italic glyphs from such a file is to use `font-variation-settings` property when applying the font? But that runs counter to the guidance to "use high level properties" where relevant, and also forces you to re-declare any other font variation settings since resetting the property will overwrite cascaded values for other axes. Am I understanding this correctly? -- GitHub Notification of comment by dev-nicolaos Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3125#issuecomment-1974852307 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I've updated this thread to be specifically about functions. -- GitHub Notification of comment by mirisuzanne Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9938#issuecomment-1974189810 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Sorry for butting in, but I've come here in search of more information about Revision 2 after coming across the warning message that was mentioned up-thread: > Also, there is already such a message at https://www.w3.org/TR/CSS2/, and it already mentions 2.2 as the next revision. When I saw that message, I got confused because I was under the impression that CSS version 3 was what's being worked on at this point in time. I then discovered the W3C's CSS home page [contains a number of tables ](https://www.w3.org/Style/CSS/current-work)which help understand the CSS development process a bit better. Neat! However, Revision 2 is nowhere to be found there... under the name "Revision 2", that is. When Revision 1 is clearly labelled as such. I actually began writing this comment _before_ realising that the [Revision 2 document](https://www.w3.org/TR/CSS22/) document linked to from the warning message _is_ in fact included. Just under a different name, "Preview of CSS Level 2" (in the "Abandoned" table). Which is _not_ what I was looking for, or would have looked for. What I originally was going to say still applies, though: to the casual user it remains a mystery if Revision 2 (or CSS2 overall) is still a thing; if that document is a work in progress or its final form. It says it's from 2016, but the warning message concludes with: "The CSS Working Group _is also developing_ [Revision 2]" (emphasis mine), which suggests it is still under development. But the warning message itself looks, well, let's say a bit "old-schoolish", which doesn't help shed any light on the situation either. -- GitHub Notification of comment by keikoro Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4847#issuecomment-1973881089 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Sorry for butting in, but I've come here in search of more information about Revision 2 after coming across the warning message that was mentioned up-thread: > Also, there is already such a message at https://www.w3.org/TR/CSS2/, and it already mentions 2.2 as the next revision. When I saw that message, I got confused because I was under the impression that CSS version 3 was what's being worked on at this point in time. I then discovered the W3C's CSS home page [contains a number of tables ](https://www.w3.org/Style/CSS/current-work)which help understand the CSS development process a bit better. Neat! However, Revision 2 is nowhere to be found there... under the name "Revision 2", that is. When Revision 1 is clearly labelled as such. I actually began writing this comment _before_ realising that the [Revision 2 document](https://www.w3.org/TR/CSS22/) document linked to from the warning message _is_ in fact included. Just under a different name, "Preview of CSS Level 2" (in the "Abandoned" table). Which is _not_ what I was looking for, or would have looked for. What I originally was going to say still applies, though: to the casual user it remains a mystery if Revision 2 (or CSS2 overall) is still a thing; if that document is a work in progress or its final form. It says it's from 2016, but the warning message concludes with: "The CSS Working Group _is also developing_ [Revision 2]" (emphasis mine), which suggests it is still under development. But the warning message itself looks, well, let's say a bit "old-schoolish", which doesn't help shed any light on the situation either. -- GitHub Notification of comment by keikoro Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4847#issuecomment-1973881089 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Sorry for butting in, but I've come here in search of more information about Revision 2 after coming across the warning message that was mentioned up-thread: > Also, there is already such a message at https://www.w3.org/TR/CSS2/, and it already mentions 2.2 as the next revision. When I saw that message, I got confused because I was under the impression that CSS version 3 was what's being worked on at this point in time. I then discovered the W3C's CSS home page [contains a number of tables ](https://www.w3.org/Style/CSS/current-work)which help understand the CSS development process a bit better. Neat! However, Revision 2 is nowhere to be found there... under the name "Revision 2", that is. When Revision 1 is clearly labelled as such. I actually began writing this comment _before_ realising that the [Revision 2 document](https://www.w3.org/TR/CSS22/) document linked to from the warning message _is_ in fact included. Just under a different name, "Preview of CSS Level 2" (in the "Abandoned" table). Which is _not_ what I was looking for, or would have looked for. What I originally was going to say still applies, though: to the casual user it remains a mystery if Revision 2 (or CSS2 overall) is still a thing; if that document is a work in progress or its final form. It says it's from 2016, but the warning message concludes with: "The CSS Working Group _is also developing_ [Revision 2]" (emphasis mine), which suggests it is still under development. But the warning message itself looks, well, let's say a bit "old-schoolish", which doesn't help shed any light on the situation either. -- GitHub Notification of comment by keikoro Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4847#issuecomment-1973881089 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Sorry for butting in, but I've come here in search of more information about Revision 2 after coming across the warning message that was mentioned up-thread: > Also, there is already such a message at https://www.w3.org/TR/CSS2/, and it already mentions 2.2 as the next revision. When I saw that message, I got confused because I was under the impression that CSS version 3 was what's being worked on at this point in time. I then discovered the W3C's CSS home page [contains a number of tables ](https://www.w3.org/Style/CSS/current-work)which help understand the CSS development process a bit better. Neat! However, Revision 2 is nowhere to be found there... under the name "Revision 2", that is. When Revision 1 is clearly labelled as such. I actually began writing this comment _before_ realising that the [Revision 2 document](https://www.w3.org/TR/CSS22/) document linked to from the warning message _is_ in fact included. Just under a different name, "Preview of CSS Level 2" (in the "Abandoned" table). Which is _not_ what I was looking for, or would have looked for. What I originally was going to say still applies, though: to the casual user it remains a mystery if Revision 2 (or CSS2 overall) is still a thing; if that document is a work in progress or its final form. It says it's from 2016, but the warning message concludes with: "The CSS Working Group _is also developing_ [Revision 2]" (emphasis mine), which suggests it is still under development. But the warning message itself looks, well, let's say a bit "old-schoolish", which doesn't help shed any light on the situation either. -- GitHub Notification of comment by keikoro Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4847#issuecomment-1973881089 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Thanks for the careful look @tabatkins, I’ve been looking forward to your reply! > There's several distinct ideas here: That's a nice overview. I think the decomposed proposal may mesh better with that line of thinking. > We will need some syntax to differentiate it from existing variables, tho. The existing syntax space is wide-open, intentionally, so we can't just infer grouping from the property name, or from the value being a `{}`-block. But something like `--foo-*: {...}` is possible, where the `*` token indicates it's not a standard variable, and has a specific syntax that's a `{}` block. Yeah, I think that makes a lot of sense, and removes a lot of the magic. Though does that mean the wildcard could be preceded by *anything*? Would people be able to do `--foo*: {s: ...}` and reference it as `--foos`? A few thoughts as I read your reply: > I would love to see specific examples of people using design systems and running into these problems, however, to make sure we are indeed solving their problem. This is designing syntax/tooling, and the use-cases are necessarily more abstract, but we still need to be sure we're actually helping people. Did you see the [entire table of popular design systems](https://lea.verou.me/docs/var-groups/#background) that I included in my proposal? > Functions It's not just about verbosity. I have *no* idea how you'd offer something where the design system specifies the ends and the midpoint, and the other tints are automatically computed BUT you can also add hand-tweaked variants to influence how the interpolation works. Though perhaps that is better addressed in `mix()`/`color-mix()`. > As we get further down the list, tho, we're basically just doing functions. (Or array/dict lookups, which can be seen as particularly simple functions; or vice versa, functions are particularly complex array lookups.) We already have a proposal for doing CSS functions, and I don't think we should do functions twice, with different syntaxes, unless there's a really good reason. Groups are analogous to objects/dicts, not functions. Dynamic groups do encroach into function territory, but they are more analogous to JS proxies than functions. You could argue that everything can be implemented via functions (and Lisp even argues that everything can be implemented via lists) but typically languages offer data structures as well, because implementing data structures as functions is painful AF. > You mention having to write a new function as being heavyweight; I acknowledge it's certainly heavier than writing some variant of `--color-primary-*: var(--color-red-*);`, but I don't think this is something you'd do repeatedly. You'll set up your desired variable names at the top of your stylesheet, and then never think about them again. It's not primarily about it being heavyweight (though as an author, looking at your code examples of how it could be done has me going NOPE NOPE NOPE I’d take the repetition over this 😅). That's the least of it. I think possibly the biggest issue is around **encapsulation**. Whether the palette is defined as continuous or not, or somewhere in between *should* be an implementation detail, not drive how you refer to design tokens. The final user of the design system should not have to care about whether `--color-red-200` is specified manually, or the result of interpolation between e.g. `--color-red-100` and `--color-red-400`. And it should be possible to *change* between the two, without uses having to be updated. E.g. you notice that your generated `--color-yellow-800` is crap and want to insert a stop in terms of how the interpolation happens, that should be possible without users of the design system having to update their code (and other shades near it should also benefit from the adjustment). Also, unless we introduce some kind of syntactic convenience, having to use functional syntax is an all-or-nothing preposition which does not play nicely with composition across a distributed ecosystem, while my proposal had paving the cowpaths and requiring as little shared contract between context and components as possible as explicit goals. Meaning that once YOUR design system uses functions, every design system you use needs to use functions, or you're stuck doing manual mappings again. E.g. if a component is expecting `--color-primary`, `--color-primary-100`, etc. and all I have is `--color-red(100)`, there is no way to map the two without a lot of repetitiveness. But even if the component did use functions for its design system, how would you pass these to a component? None of the proposals around functions includes a concept like a function *reference*. If I want to set a component's `--color-primary` (and its tints) to my `--color-magenta` (and its tints), how would that work with functions? -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9992#issuecomment-1973864436 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> you'd need to sort declarations by source order Isn't that already the case due to logical properties? https://drafts.csswg.org/css-logical-1/#box > this requires implementations to maintain relative order of declarations within a CSS declaration block -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8738#issuecomment-1973725807 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
However, if we consider the above use-cases, having enter/exit events on the animations, similar requested by @bramus on #7962 may become quite crucial for easily creating such effects without extra IntersectionObserver or `scroll` handler. Although you can currently get a similar outcome with `start`/`end` events on CSS Animations like here: https://jsbin.com/jizahopixe/edit?css,js,console,output I think it's currently not possible to achieve with WAAPI. -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8799#issuecomment-1973397488 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
However, if we consider the above use-cases, having enter/exit events on the animations, similar requested by @bramus on #7962 may become quite crucial for easily creating such effects without extra IntersectionObserver or `scroll` handler. Although you can currently get a similar outcome with `start`/`end` events on CSS Animations like here: https://jsbin.com/jizahopixe/edit?css,js,console,output I think it's currently not possible to achieve with WAAPI. -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8799#issuecomment-1973397488 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
However, if we consider the above use-cases, having enter/exit events on the animations, similar requested by @bramus on #7962 may become quite crucial for easily creating such effects without extra IntersectionObserver or `scroll` handler. Although you can currently get a similar outcome with `start`/`end` events on CSS Animations like here: https://jsbin.com/jizahopixe/edit?css,js,console,output I think it's currently not possible to achieve with WAAPI. -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8799#issuecomment-1973397488 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
miketaylr has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-adjust-1] -webkit-tap-highlight-color referenced but not defined == AFAICT, `-webkit-tap-highlight-color` is not defined anywhere (here, or the compat standard), but referenced in https://www.w3.org/TR/css-color-adjust-1/#forced-colors-properties. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10020 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
miketaylr has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-adjust-1] -webkit-tap-highlight-color referenced but not defined == AFAICT, `-webkit-tap-highlight-color` is not defined anywhere (here, or the compat standard), but referenced in https://www.w3.org/TR/css-color-adjust-1/#forced-colors-properties. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10020 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@Crissov This looks like custom mixins (#9350) So IIUC wildcard class selectors and custom mixins are basically solving the same problem. I'm also wondering if a selector that targets a group of class names / attribute names will make implementations significantly more complicated. For example, Blink maintains maps keyed by class names for efficient style matching and invalidation, and it will be much more complicated if we have to eg put a trie there for prefix matching. Mixins solve the same use cases without affecting style matching and invalidation. So +1 to mixins over wildcard selectors. -- GitHub Notification of comment by xiaochengh Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10001#issuecomment-1973057268 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Hmm, actually I found a case where layers can't fix (modified from https://esbuild.github.io/content-types/#css-import-order): Say we are using two libraries `a.css` and `b.css`, and in case of conflict, we want `b` to take precedence. So it ends up like: ```css @import url(a.css) layer(a); @import url(b.css) layer(b); ``` However, `a.css` and `b.css` both have a reset: ```css @import url(reset.css) layer(reset); /* real business*/ ``` Then the import order is still `reset, a, reset, b`, causing the double-reset issue as in the original example. `@import-once` will fix this case, but only if `a` and `b` use the same reset. If eg they are from different sources with different reset sheets, then `@import-once` doesn't help, either. I feel like this is a more general issue that we can't arbitrarily re-order imported sheets, and have limited ways to tackle it if these sheets do overlapping things. One way is `@layer`, and the other is `!important`, which is known to be an antipattern if it's used to reorder style rules. I don't have a good idea how this can be fixed from the CSS language side. Maybe it's much simpler if CSS authors make sure one sheet has one unique purpose, for example, a sheet doing actual styling should not perform a reset on its own. In other words, each style sheet should be targetting a particular layer in the overall business -- which perfectly matches the purpose of `@layer`... --- > You can influence which named thing (keyframe animation, custom property,...) is declared last and thus "wins", but you cannot use both side by side. That's unfortunate. But CSS modules can't help here, either. It's a general design issue of CSS that everything is the global namespace (except layers), and the current solution/relief is to scope things by shadow DOM. -- GitHub Notification of comment by xiaochengh Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6130#issuecomment-1972981369 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Hmm, actually I found a case where layers can't fix (modified from https://esbuild.github.io/content-types/#css-import-order): Say we are using two libraries `a.css` and `b.css`, and in case of conflict, we want `b` to take precedence. So it ends up like: ```css @import url(a.css) layer(a); @import url(b.css) layer(b); ``` However, `a.css` and `b.css` both have a reset: ```css @import url(reset.css) layer(reset); /* real business*/ ``` Then the import order is still `reset, a, reset, b`, causing the double-reset issue as in the original example. `@import-once` will fix this case, but only if `a` and `b` use the same reset. If eg they are from different sources with different reset sheets, then `@import-once` doesn't help, either. I feel like this is a more general issue that we can't arbitrarily re-order imported sheets, and have limited ways to tackle it if these sheets do overlapping things. One way is `@layer`, and the other is `!important`, which is known to be an antipattern if it's used to reorder style rules. I don't have a good idea how this can be fixed from the CSS language side. Maybe it's much simpler if CSS authors make sure one sheet has one unique purpose, for example, a sheet doing actual styling should not perform a reset on its own. In other words, each style sheet should be targetting a particular layer in the overall business -- which perfectly matches the purpose of `@layer`... --- > You can influence which named thing (keyframe animation, custom property,...) is declared last and thus "wins", but you cannot use both side by side. That's unfortunate. But CSS modules can't help here, either. It's a general design issue of CSS that everything is the global namespace (except layers), and the current solution/relief is to scope things by shadow DOM. -- GitHub Notification of comment by xiaochengh Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6130#issuecomment-1972981369 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Hmm, actually I found a case where layers can't fix (modified from https://esbuild.github.io/content-types/#css-import-order): Say we are using two libraries `a.css` and `b.css`, and in case of conflict, we want `b` to take precedence. So it ends up like: ```css @import url(a.css) layer(a); @import url(b.css) layer(b); ``` However, `a.css` and `b.css` both have a reset: ```css @import url(reset.css) layer(reset); /* real business*/ ``` Then the import order is still `reset, a, reset, b`, causing the double-reset issue as in the original example. `@import-once` will fix this case, but only if `a` and `b` use the same reset. If eg they are from different sources with different reset sheets, then `@import-once` doesn't help, either. I feel like this is a more general issue that we can't arbitrarily re-order imported sheets, and have limited ways to tackle it if these sheets do overlapping things. One way is `@layer`, and the other is `!important`, which is known to be an antipattern if it's used to reorder style rules. I don't have a good idea how this can be fixed from the CSS language side. Maybe it's much simpler if CSS authors make sure one sheet has one unique purpose, for example, a sheet doing actual styling should not perform a reset on its own. In other words, each style sheet should be targetting a particular layer in the overall business -- which perfectly matches the purpose of `@layer`... --- > You can influence which named thing (keyframe animation, custom property,...) is declared last and thus "wins", but you cannot use both side by side. That's unfortunate. But CSS modules can't help here, either. It's a general design issue of CSS that everything is the global namespace (except layers), and the current solution/relief is to scope things by shadow DOM. -- GitHub Notification of comment by xiaochengh Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6130#issuecomment-1972981369 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Hmm, actually I found a case where layers can't fix (modified from https://esbuild.github.io/content-types/#css-import-order): Say we are using two libraries `a.css` and `b.css`, and in case of conflict, we want `b` to take precedence. So it ends up like: ```css @import url(a.css) layer(a); @import url(b.css) layer(b); ``` However, `a.css` and `b.css` both have a reset: ```css @import url(reset.css) layer(reset); /* real business*/ ``` Then the import order is still `reset, a, reset, b`, causing the double-reset issue as in the original example. `@import-once` will fix this case, but only if `a` and `b` use the same reset. If eg they are from different sources with different reset sheets, then `@import-once` doesn't help, either. I feel like this is a more general issue that we can't arbitrarily re-order imported sheets, and have limited ways to tackle it if these sheets do overlapping things. One way is `@layer`, and the other is `!important`, which is known to be an antipattern if it's used to reorder style rules. I don't have a good idea how this can be fixed from the CSS language side. Maybe it's much simpler if CSS authors make sure one sheet has one unique purpose, for example, a sheet doing actual styling should not perform a reset on its own. In other words, each style sheet should be targetting a particular layer in the overall business -- which perfectly matches the purpose of `@layer`... --- > You can influence which named thing (keyframe animation, custom property,...) is declared last and thus "wins", but you cannot use both side by side. That's unfortunate. But CSS modules can't help here, either. It's a general design issue of CSS that everything is the global namespace (except layers), and the current solution/relief is to scope things by shadow DOM. -- GitHub Notification of comment by xiaochengh Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6130#issuecomment-1972981369 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I think functions and mixins are very different regarding whether/how to access external variables, and should be discussed in separate issues. Speaking of functions only: I strongly agree that external variable access must be lexically scoped. Allowing a function to access something from an unknown caller makes the behavior totally unpredictable. I assume dynamic scoping is just a legacy thing that should be completely avoided today. Tab's `using()` still looks like dynamic scoping to me, as the function still doesn't know where the variables are from. --- Alternative idea: allow nested functions (and make the language more functional) Example: ```css @function --outer(--foo) { /* declares a --foo argument */ @function --inner() { /* captures --foo from the outer scope, same way how capturing works in many other languages */ result: calc(var(--foo) / 2); } result: calc(var(--foo) + --inner()); } @function --outer2() { /* captures --foo from the "global" scope, which is the element's custom properties */ result: calc(var(--foo) / 2); } .foo { --foo: 1; width: calc((--outer(10) + --outer2()) * 1px); /* (15 + 0.5) * 1px */ } ``` And I don't mind having `arg()` if that addes more clarity. -- GitHub Notification of comment by xiaochengh Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9938#issuecomment-1972938887 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Should `sqrt()` and trigonometric functions (excluding `atan2()`) accept `<percentage>`? This does not currently appear to be the case in Chrome and FF. I am asking this because they are defined to take calculation(s) *resolving* either to `<number>` or `<angle>`, and now their return type should either be consistent (the result of adding argument types) or made consistent, which I think is not usefull if they do not accept `<percentage>`. I also note that `log()` and `exp()` only accept calculation(s) *resolving* to `<number>`, but their return type is not defined to be consistent or made consistent. --- [Typo](https://drafts.csswg.org/css-values-4/#css-contain-a-percentage): > A value contains a percentage if its type **is type** is «[ "percent" → 1 ]» -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10017#issuecomment-1972896813 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fregante has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-ui] Single-line `textarea` or auto-wrapping `input` == The correct element to handle single-line text inputs is `<input type="text">`, however its default behavior for overflowing text is to make the field "invisibly scrollable". This has awful usability if the text tends to be longer, because the user cannot see the entire text at once and there's no scrollbar. This leads to authors defaulting to `textarea` even if they want to preserve the the "single-line" input type. A notable example of this is Google Search: <img width="920" alt="Screenshot 8" src="https://github.com/w3c/csswg-drafts/assets/1402241/259c3e7a-a564-42dc-a7c8-9073b5da529d"> You want to allow long input, but also you want to preserve the ability to submit text with <kbd>Enter</kbd>. the [`field-sizing` proposal](https://github.com/w3c/csswg-drafts/issues/7542) is another key of this puzzle, also seen on Google Search. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10019 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> What happens when it's used in a calc, like width: calc(anchor-size(--bad-ref width) + 20px)? I found the answer myself. `calc-size(auto)` works here. (I was away for a few months and missed so much progress...) > More specifically, it should trigger the "behaves as auto" behavior that things like cyclic percentages do. It's a bit different from my mental model that a `calc()` should always keep going (like division-by-zero becomes `infinity`), and invalid values are resolved only at the top level. Or are there existing examples where a `calc()` can be invalidated as long as part of it is invalid, in case I missed something? -- GitHub Notification of comment by xiaochengh Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10005#issuecomment-1972519198 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dbaron has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-typed-om] inverting a type should preserve the percent hint == So after looking at some of the spec rules for #10017, I'm concerned that dividing (in `calc()`) by values with percentages produces inconsistent results. The rules for [invert](https://drafts.css-houdini.org/css-typed-om-1/#cssnumericvalue-invert-a-type) invert (and preserve) `percent` types but erase percent hints. This means when a percentage in the divisor leads to it having a "percent" type it is preserved, but when it leads to a percent hint, it is removed. For example this means that `calc(30px / 20%)` has a type that involves percentages whereas `calc(30px / (20% + 10px))` does not. This seems wrong, and it seems like inverting a type should preserve the percent hint rather than erasing it. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10018 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dbaron has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-typed-om] inverting a type should preserve the percent hint == So after looking at some of the spec rules for #10017, I'm concerned that dividing (in `calc()`) by values with percentages produces inconsistent results. The rules for [invert](https://drafts.css-houdini.org/css-typed-om-1/#cssnumericvalue-invert-a-type) invert (and preserve) `percent` types but erase percent hints. This means when a percentage in the divisor leads to it having a "percent" type it is preserved, but when it leads to a percent hint, it is removed. For example this means that `calc(30px / 20%)` has a type that involves percentages whereas `calc(30px / (20% + 10px))` does not. This seems wrong, and it seems like inverting a type should preserve the percent hint rather than erasing it. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10018 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dbaron has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-typed-om] inverting a type should preserve the percent hint == So after looking at some of the spec rules for #10017, I'm concerned that dividing (in `calc()`) by values with percentages produces inconsistent results. The rules for [invert](https://drafts.css-houdini.org/css-typed-om-1/#cssnumericvalue-invert-a-type) invert (and preserve) `percent` types but erase percent hints. This means when a percentage in the divisor leads to it having a "percent" type it is preserved, but when it leads to a percent hint, it is removed. For example this means that `calc(30px / 20%)` has a type that involves percentages whereas `calc(30px / (20% + 10px))` does not. This seems wrong, and it seems like inverting a type should preserve the percent hint rather than erasing it. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10018 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dbaron has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-typed-om] inverting a type should preserve the percent hint == So after looking at some of the spec rules for #10017, I'm concerned that dividing (in `calc()`) by values with percentages produces inconsistent results. The rules for [invert](https://drafts.css-houdini.org/css-typed-om-1/#cssnumericvalue-invert-a-type) invert (and preserve) `percent` types but erase percent hints. This means when a percentage in the divisor leads to it having a "percent" type it is preserved, but when it leads to a percent hint, it is removed. For example this means that `calc(30px / 20%)` has a type that involves percentages whereas `calc(30px / (20% + 10px))` does not. This seems wrong, and it seems like inverting a type should preserve the percent hint rather than erasing it. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10018 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dbaron has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-typed-om] inverting a type should preserve the percent hint == So after looking at some of the spec rules for #10017, I'm concerned that dividing (in `calc()`) by values with percentages produces inconsistent results. The rules for [invert](https://drafts.css-houdini.org/css-typed-om-1/#cssnumericvalue-invert-a-type) invert (and preserve) `percent` types but erase percent hints. This means when a percentage in the divisor leads to it having a "percent" type it is preserved, but when it leads to a percent hint, it is removed. For example this means that `calc(30px / 20%)` has a type that involves percentages whereas `calc(30px / (20% + 10px))` does not. This seems wrong, and it seems like inverting a type should preserve the percent hint rather than erasing it. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10018 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dbaron has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-typed-om] inverting a type should preserve the percent hint == So after looking at some of the spec rules for #10017, I'm concerned that dividing (in `calc()`) by values with percentages produces inconsistent results. The rules for [invert](https://drafts.css-houdini.org/css-typed-om-1/#cssnumericvalue-invert-a-type) invert (and preserve) `percent` types but erase percent hints. This means when a percentage in the divisor leads to it having a "percent" type it is preserved, but when it leads to a percent hint, it is removed. For example this means that `calc(30px / 20%)` has a type that involves percentages whereas `calc(30px / (20% + 10px))` does not. This seems wrong, and it seems like inverting a type should preserve the percent hint rather than erasing it. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10018 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dbaron has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-typed-om] inverting a type should preserve the percent hint == So after looking at some of the spec rules for #10017, I'm concerned that dividing (in `calc()`) by values with percentages produces inconsistent results. The rules for [invert](https://drafts.css-houdini.org/css-typed-om-1/#cssnumericvalue-invert-a-type) invert (and preserve) `percent` types but erase percent hints. This means when a percentage in the divisor leads to it having a "percent" type it is preserved, but when it leads to a percent hint, it is removed. For example this means that `calc(30px / 20%)` has a type that involves percentages whereas `calc(30px / (20% + 10px))` does not. This seems wrong, and it seems like inverting a type should preserve the percent hint rather than erasing it. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10018 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dbaron has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-typed-om] inverting a type should preserve the percent hint == So after looking at some of the spec rules for #10017, I'm concerned that dividing (in `calc()`) by values with percentages produces inconsistent results. The rules for [invert](https://drafts.css-houdini.org/css-typed-om-1/#cssnumericvalue-invert-a-type) invert (and preserve) `percent` types but erase percent hints. This means when a percentage in the divisor leads to it having a "percent" type it is preserved, but when it leads to a percent hint, it is removed. For example this means that `calc(30px / 20%)` has a type that involves percentages whereas `calc(30px / (20% + 10px))` does not. This seems wrong, and it seems like inverting a type should preserve the percent hint rather than erasing it. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10018 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dbaron has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-typed-om] inverting a type should preserve the percent hint == So after looking at some of the spec rules for #10017, I'm concerned that dividing (in `calc()`) by values with percentages produces inconsistent results. The rules for [invert](https://drafts.css-houdini.org/css-typed-om-1/#cssnumericvalue-invert-a-type) invert (and preserve) `percent` types but erase percent hints. This means when a percentage in the divisor leads to it having a "percent" type it is preserved, but when it leads to a percent hint, it is removed. For example this means that `calc(30px / 20%)` has a type that involves percentages whereas `calc(30px / (20% + 10px))` does not. This seems wrong, and it seems like inverting a type should preserve the percent hint rather than erasing it. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10018 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dbaron has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-typed-om] inverting a type should preserve the percent hint == So after looking at some of the spec rules for #10017, I'm concerned that dividing (in `calc()`) by values with percentages produces inconsistent results. The rules for [invert](https://drafts.css-houdini.org/css-typed-om-1/#cssnumericvalue-invert-a-type) invert (and preserve) `percent` types but erase percent hints. This means when a percentage in the divisor leads to it having a "percent" type it is preserved, but when it leads to a percent hint, it is removed. For example this means that `calc(30px / 20%)` has a type that involves percentages whereas `calc(30px / (20% + 10px))` does not. This seems wrong, and it seems like inverting a type should preserve the percent hint rather than erasing it. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10018 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dbaron has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-typed-om] inverting a type should preserve the percent hint == So after looking at some of the spec rules for #10017, I'm concerned that dividing (in `calc()`) by values with percentages produces inconsistent results. The rules for [invert](https://drafts.css-houdini.org/css-typed-om-1/#cssnumericvalue-invert-a-type) invert (and preserve) `percent` types but erase percent hints. This means when a percentage in the divisor leads to it having a "percent" type it is preserved, but when it leads to a percent hint, it is removed. For example this means that `calc(30px / 20%)` has a type that involves percentages whereas `calc(30px / (20% + 10px))` does not. This seems wrong, and it seems like inverting a type should preserve the percent hint rather than erasing it. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10018 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dbaron has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-typed-om] inverting a type should preserve the percent hint == So after looking at some of the spec rules for #10017, I'm concerned that dividing (in `calc()`) by values with percentages produces inconsistent results. The rules for [invert](https://drafts.css-houdini.org/css-typed-om-1/#cssnumericvalue-invert-a-type) invert (and preserve) `percent` types but erase percent hints. This means when a percentage in the divisor leads to it having a "percent" type it is preserved, but when it leads to a percent hint, it is removed. For example this means that `calc(30px / 20%)` has a type that involves percentages whereas `calc(30px / (20% + 10px))` does not. This seems wrong, and it seems like inverting a type should preserve the percent hint rather than erasing it. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10018 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dbaron has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-typed-om] inverting a type should preserve the percent hint == So after looking at some of the spec rules for #10017, I'm concerned that dividing (in `calc()`) by values with percentages produces inconsistent results. The rules for [invert](https://drafts.css-houdini.org/css-typed-om-1/#cssnumericvalue-invert-a-type) invert (and preserve) `percent` types but erase percent hints. This means when a percentage in the divisor leads to it having a "percent" type it is preserved, but when it leads to a percent hint, it is removed. For example this means that `calc(30px / 20%)` has a type that involves percentages whereas `calc(30px / (20% + 10px))` does not. This seems wrong, and it seems like inverting a type should preserve the percent hint rather than erasing it. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10018 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Chrome CL to support anchor position adjustment with position:sticky has landed: https://chromium-review.googlesource.com/c/chromium/src/+/5297007. There may also be issues with position:sticky under anchor position, but I haven't created a test case broken on Chrome. -- GitHub Notification of comment by wangxianzhu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8448#issuecomment-1971995592 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Chrome CL to support anchor position adjustment with position:sticky has landed: https://chromium-review.googlesource.com/c/chromium/src/+/5297007. There may also be issues with position:sticky under anchor position, but I haven't created a test case broken on Chrome. -- GitHub Notification of comment by wangxianzhu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8448#issuecomment-1971995592 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Chrome CL to support anchor position adjustment with position:sticky has landed: https://chromium-review.googlesource.com/c/chromium/src/+/5297007. There may also be issues with position:sticky under anchor position, but I haven't created a test case broken on Chrome. -- GitHub Notification of comment by wangxianzhu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8448#issuecomment-1971995592 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Chrome CL to support anchor position adjustment with position:sticky has landed: https://chromium-review.googlesource.com/c/chromium/src/+/5297007. There may also be issues with position:sticky under anchor position, but I haven't created a test case broken on Chrome. -- GitHub Notification of comment by wangxianzhu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8448#issuecomment-1971995592 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Chrome CL to support anchor position adjustment with position:sticky has landed: https://chromium-review.googlesource.com/c/chromium/src/+/5297007. There may also be issues with position:sticky under anchor position, but I haven't created a test case broken on Chrome. -- GitHub Notification of comment by wangxianzhu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8448#issuecomment-1971995592 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Chrome CL to support anchor position adjustment with position:sticky has landed: https://chromium-review.googlesource.com/c/chromium/src/+/5297007. There may also be issues with position:sticky under anchor position, but I haven't created a test case broken on Chrome. -- GitHub Notification of comment by wangxianzhu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8448#issuecomment-1971995592 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Chrome CL to support anchor position adjustment with position:sticky has landed: https://chromium-review.googlesource.com/c/chromium/src/+/5297007. There may also be issues with position:sticky under anchor position, but I haven't created a test case broken on Chrome. -- GitHub Notification of comment by wangxianzhu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8448#issuecomment-1971995592 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Chrome CL to support anchor position adjustment with position:sticky has landed: https://chromium-review.googlesource.com/c/chromium/src/+/5297007. There may also be issues with position:sticky under anchor position, but I haven't created a test case broken on Chrome. -- GitHub Notification of comment by wangxianzhu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8448#issuecomment-1971995592 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Chrome CL to support anchor position adjustment with position:sticky has landed: https://chromium-review.googlesource.com/c/chromium/src/+/5297007. There may also be issues with position:sticky under anchor position, but I haven't created a test case broken on Chrome. -- GitHub Notification of comment by wangxianzhu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8448#issuecomment-1971995592 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Chrome CL to support anchor position adjustment with position:sticky has landed: https://chromium-review.googlesource.com/c/chromium/src/+/5297007. There may also be issues with position:sticky under anchor position, but I haven't created a test case broken on Chrome. -- GitHub Notification of comment by wangxianzhu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8448#issuecomment-1971995592 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Chrome change to support chained anchor-position has landed: https://chromium-review.googlesource.com/c/chromium/src/+/5274137. All tests are marked tentative. Is there a plan to update the spec? -- GitHub Notification of comment by wangxianzhu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9071#issuecomment-1971991979 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dbaron has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-values] specification for calc() should be clearer about when the result has a percentage == There are a number of cases where layout algorithms in CSS (and perhaps other things) care about whether a value has a percentage. In particular, values that have a percentage are treated differently when there's nothing for the percentage to resolve against: inside of something with `auto` height a `height: calc(30px)` is a fixed value but a `height: calc(30px + 0%)` is treated as `height: auto`. With `calc()` as it was specified in css-values-3, this could essentially be implemented as part of the type computation; a `calc()` expression could effectively be either a `<length>` or a `<length-percentage>` as its toplevel type, and those that were `<length-percentage>` act as though they have a percent. Newer levels of the specification introduce features that make this approach insufficient: * division by values with units * [`sign()`](https://drafts.csswg.org/css-values-4/#calc-type-checking) * [`progress()` and related functions](https://drafts.csswg.org/css-values-5/#progress) * [`calc-size()`](https://drafts.csswg.org/css-values-5/#calc-size) (I think this is clearly defined for `calc-size()` because it's very important there, but I don't think it's clearly defined for the other cases.) It should be clearer whether these other things "erase" the percentage-ness of their arguments when they erase the types of those arguments, or whether they still produce toplevel values that are treated as having a percentage. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10017 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dbaron has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-values] specification for calc() should be clearer about when the result has a percentage == There are a number of cases where layout algorithms in CSS (and perhaps other things) care about whether a value has a percentage. In particular, values that have a percentage are treated differently when there's nothing for the percentage to resolve against: inside of something with `auto` height a `height: calc(30px)` is a fixed value but a `height: calc(30px + 0%)` is treated as `height: auto`. With `calc()` as it was specified in css-values-3, this could essentially be implemented as part of the type computation; a `calc()` expression could effectively be either a `<length>` or a `<length-percentage>` as its toplevel type, and those that were `<length-percentage>` act as though they have a percent. Newer levels of the specification introduce features that make this approach insufficient: * division by values with units * [`sign()`](https://drafts.csswg.org/css-values-4/#calc-type-checking) * [`progress()` and related functions](https://drafts.csswg.org/css-values-5/#progress) * [`calc-size()`](https://drafts.csswg.org/css-values-5/#calc-size) (I think this is clearly defined for `calc-size()` because it's very important there, but I don't think it's clearly defined for the other cases.) It should be clearer whether these other things "erase" the percentage-ness of their arguments when they erase the types of those arguments, or whether they still produce toplevel values that are treated as having a percentage. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10017 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dbaron has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-values] specification for calc() should be clearer about when the result has a percentage == There are a number of cases where layout algorithms in CSS (and perhaps other things) care about whether a value has a percentage. In particular, values that have a percentage are treated differently when there's nothing for the percentage to resolve against: inside of something with `auto` height a `height: calc(30px)` is a fixed value but a `height: calc(30px + 0%)` is treated as `height: auto`. With `calc()` as it was specified in css-values-3, this could essentially be implemented as part of the type computation; a `calc()` expression could effectively be either a `<length>` or a `<length-percentage>` as its toplevel type, and those that were `<length-percentage>` act as though they have a percent. Newer levels of the specification introduce features that make this approach insufficient: * division by values with units * [`sign()`](https://drafts.csswg.org/css-values-4/#calc-type-checking) * [`progress()` and related functions](https://drafts.csswg.org/css-values-5/#progress) * [`calc-size()`](https://drafts.csswg.org/css-values-5/#calc-size) (I think this is clearly defined for `calc-size()` because it's very important there, but I don't think it's clearly defined for the other cases.) It should be clearer whether these other things "erase" the percentage-ness of their arguments when they erase the types of those arguments, or whether they still produce toplevel values that are treated as having a percentage. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10017 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
dbaron has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-values] specification for calc() should be clearer about when the result has a percentage == There are a number of cases where layout algorithms in CSS (and perhaps other things) care about whether a value has a percentage. In particular, values that have a percentage are treated differently when there's nothing for the percentage to resolve against: inside of something with `auto` height a `height: calc(30px)` is a fixed value but a `height: calc(30px + 0%)` is treated as `height: auto`. With `calc()` as it was specified in css-values-3, this could essentially be implemented as part of the type computation; a `calc()` expression could effectively be either a `<length>` or a `<length-percentage>` as its toplevel type, and those that were `<length-percentage>` act as though they have a percent. Newer levels of the specification introduce features that make this approach insufficient: * division by values with units * [`sign()`](https://drafts.csswg.org/css-values-4/#calc-type-checking) * [`progress()` and related functions](https://drafts.csswg.org/css-values-5/#progress) * [`calc-size()`](https://drafts.csswg.org/css-values-5/#calc-size) (I think this is clearly defined for `calc-size()` because it's very important there, but I don't think it's clearly defined for the other cases.) It should be clearer whether these other things "erase" the percentage-ness of their arguments when they erase the types of those arguments, or whether they still produce toplevel values that are treated as having a percentage. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10017 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
This would be fantastic! -- GitHub Notification of comment by Anoesj Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3070#issuecomment-1971860440 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
This would be fantastic! -- GitHub Notification of comment by Anoesj Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3070#issuecomment-1971860440 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
pyoor has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-selectors-4] Grammar of ns-prefix incorrect? == I'm sorry if I missed this but I couldn't find an explanation of this syntax anywhere. Currently, the syntax for `ns-prefix` is as follows: https://github.com/w3c/csswg-drafts/blob/79819a4e4a523de50d1bcdcc32a99c4fab2da72f/selectors-4/Overview.bs#L3607 Is it intended that `|` is required if no `ident-token` or wildcard is specified? That would mean that selectors such as `|*` are valid. Is that the case? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10016 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
pyoor has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-selectors-4] Grammar of ns-prefix incorrect? == I'm sorry if I missed this but I couldn't find an explanation of this syntax anywhere. Currently, the syntax for `ns-prefix` is as follows: https://github.com/w3c/csswg-drafts/blob/79819a4e4a523de50d1bcdcc32a99c4fab2da72f/selectors-4/Overview.bs#L3607 Is it intended that `|` is required if no `ident-token` or wildcard is specified? That would mean that selectors such as `|*` are valid. Is that the case? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10016 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
pyoor has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-selectors-4] Grammar of ns-prefix incorrect? == I'm sorry if I missed this but I couldn't find an explanation of this syntax anywhere. Currently, the syntax for `ns-prefix` is as follows: https://github.com/w3c/csswg-drafts/blob/79819a4e4a523de50d1bcdcc32a99c4fab2da72f/selectors-4/Overview.bs#L3607 Is it intended that `|` is required if no `ident-token` or wildcard is specified? That would mean that selectors such as `|*` are valid. Is that the case? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10016 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
pyoor has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-selectors-4] Grammar of ns-prefix incorrect? == I'm sorry if I missed this but I couldn't find an explanation of this syntax anywhere. Currently, the syntax for `ns-prefix` is as follows: https://github.com/w3c/csswg-drafts/blob/79819a4e4a523de50d1bcdcc32a99c4fab2da72f/selectors-4/Overview.bs#L3607 Is it intended that `|` is required if no `ident-token` or wildcard is specified? That would mean that selectors such as `|*` are valid. Is that the case? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10016 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
pyoor has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-selectors-4] Grammar of ns-prefix incorrect? == I'm sorry if I missed this but I couldn't find an explanation of this syntax anywhere. Currently, the syntax for `ns-prefix` is as follows: https://github.com/w3c/csswg-drafts/blob/79819a4e4a523de50d1bcdcc32a99c4fab2da72f/selectors-4/Overview.bs#L3607 Is it intended that `|` is required if no `ident-token` or wildcard is specified? That would mean that selectors such as `|*` are valid. Is that the case? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10016 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
On the PR from @DavMila there is one point where we don't have a clear answer. Should the progress be clamped to [0, 1]. For the full discussion you can view the PR review https://github.com/w3c/csswg-drafts/pull/9937#discussion_r1491825782 however I'll do my best to summarize the pros and cons of each. 1. Don't clamp the progress. This makes it similar to the currentTime which progress exists alongside (which also can be negative or greater than end time) and is the natural result of the expressed formula. This could be useful for example to distinguish between being at the start time (progress = 0) where the effect is active and visibly shown, and being before the start time (progress < 0) where the effect is not applied (unless `fill = backwards | both`). However, this also means that to correctly reflect the progress for 0 duration animations we would likely have to return `-Infinity` and `Infinity` when you are before or at/after the start time respectively. 2. Clamp the progress to [0, 1]. A developer won't be able to tell when at 0 progress whether the animation is active or not without also checking whether the currentTime is less than the start time. We could consider adding another member to animation to reflect this in the future. Ultimately, I think either works, but which is better comes back to how authors will use this. @bramus @fantasai @birtles any thoughts? -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8799#issuecomment-1971476352 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
On the PR from @DavMila there is one point where we don't have a clear answer. Should the progress be clamped to [0, 1]. For the full discussion you can view the PR review https://github.com/w3c/csswg-drafts/pull/9937#discussion_r1491825782 however I'll do my best to summarize the pros and cons of each. 1. Don't clamp the progress. This makes it similar to the currentTime which progress exists alongside (which also can be negative or greater than end time) and is the natural result of the expressed formula. This could be useful for example to distinguish between being at the start time (progress = 0) where the effect is active and visibly shown, and being before the start time (progress < 0) where the effect is not applied (unless `fill = backwards | both`). However, this also means that to correctly reflect the progress for 0 duration animations we would likely have to return `-Infinity` and `Infinity` when you are before or at/after the start time respectively. 2. Clamp the progress to [0, 1]. A developer won't be able to tell when at 0 progress whether the animation is active or not without also checking whether the currentTime is less than the start time. We could consider adding another member to animation to reflect this in the future. Ultimately, I think either works, but which is better comes back to how authors will use this. @bramus @fantasai @birtles any thoughts? -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8799#issuecomment-1971476352 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
prarsena has just created a new issue for https://github.com/w3c/csswg-drafts: == [mediaqueries-5] Add language about how the browser obtains prefers-color-scheme from the OS == In [mediaqueries-5/#prefers-color-scheme](https://drafts.csswg.org/mediaqueries-5/#prefers-color-scheme), would it be appropriate to provide details about how the browser obtains information from the device about the user's color preference? For example: > The method by which the user expresses their preference can vary. It might be a system-wide setting exposed by the Operating System, or a setting controlled by the user agent. Could this type of language be added: > Information sent from the operating system or the user agent that contains a `Sec-CH-Prefers-Color-Scheme` Client Hint header (which also supports the "dark" / "light" values) that can be used by the `prefers-color-scheme` media feature to tailor the response to the client’s preferences accordingly. Not to get too into the weeds, but I'm also searching for documentation about how the browser communicates with the OS, if anyone knows of resources for that. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10015 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
cdoublev has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [cssom-1] Simplify setting MediaList.mediaText == This PR removes step 2 for [setting `MediaList.mediaText`](https://drafts.csswg.org/cssom-1/#dom-medialist-mediatext) with empty string since step 3 (parsing) produces the same outcome: > 3. Append all the media queries as a result of [parsing](https://drafts.csswg.org/cssom-1/#parse-a-media-query-list) the given value to the collection of media queries. *Parsing* links to [parse a media query list](https://drafts.csswg.org/cssom-1/#parse-a-media-query-list) which redirects to [`<media-query-list>`](https://drafts.csswg.org/mediaqueries-5/#typedef-media-query-list): > To parse a `<media-query-list>` production, parse a comma-separated list of component values, then parse each entry in the returned list as a `<media-query>`. > > Note: This definition of `<media-query-list>` parsing intentionally accepts an empty list. Alternatively, [parse a comma-separated list according to a CSS grammar](https://drafts.csswg.org/css-syntax-3/#parse-comma-list) could be directly invoked from the setter, but this requires more changes. See https://github.com/w3c/csswg-drafts/pull/10014 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
#7446 fixed this. -- GitHub Notification of comment by zcorpan Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5614#issuecomment-1971140847 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
#7446 fixed this. -- GitHub Notification of comment by zcorpan Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5614#issuecomment-1971140847 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
#7446 fixed this. -- GitHub Notification of comment by zcorpan Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5614#issuecomment-1971140847 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
#7446 fixed this. -- GitHub Notification of comment by zcorpan Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5614#issuecomment-1971140847 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
zcorpan closed this issue. See https://github.com/w3c/csswg-drafts/issues/5614 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
At the risk of resurrecting a lengthy discussion ... I remember skimming over this issue at the time, but have recently been made aware of it again and I'm trying to just check...is this essentially saying: developers want to distinguish between "the viewport is a certain size because the device/browser window/etc is set to a certain size" and "the viewport is a certain size because the user has zoomed"? because if so, I'm really not sure I'm a fan of this idea, because the whole point to me would be that it doesn't matter *why* a viewport is reported as being a particular size, as a developer you should design your content so it works well within your given viewport (regardless of what *actually* caused it to be that way). and yes, I can see how that brings up issues *if* you base your font sizes on viewport units, but that's then effectively the caveat/danger of using those units? and that those units like `vm` by their very nature, if used on their own in particular, are zoom-resistant so will, by their very nature, not lend themselves to allowing authors to meet text resize requirements? -- GitHub Notification of comment by patrickhlauke Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6869#issuecomment-1970828945 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
At the risk of resurrecting a lengthy discussion ... I remember skimming over this issue at the time, but have recently been made aware of it again and I'm trying to just check...is this essentially saying: developers want to distinguish between "the viewport is a certain size because the device/browser window/etc is set to a certain size" and "the viewport is a certain size because the user has zoomed"? because if so, I'm really not sure I'm a fan of this idea, because the whole point to me would be that it doesn't matter *why* a viewport is reported as being a particular size, as a developer you should design your content so it works well within your given viewport (regardless of what *actually* caused it to be that way). and yes, I can see how that brings up issues *if* you base your font sizes on viewport units, but that's then effectively the caveat/danger of using those units? and that those units like `vm` by their very nature, if used on their own in particular, are zoom-resistant so will, by their very nature, not lend themselves to allowing authors to meet text resize requirements? -- GitHub Notification of comment by patrickhlauke Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6869#issuecomment-1970828945 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
At the risk of resurrecting a lengthy discussion ... I remember skimming over this issue at the time, but have recently been made aware of it again and I'm trying to just check...is this essentially saying: developers want to distinguish between "the viewport is a certain size because the device/browser window/etc is set to a certain size" and "the viewport is a certain size because the user has zoomed"? because if so, I'm really not sure I'm a fan of this idea, because the whole point to me would be that it doesn't matter *why* a viewport is reported as being a particular size, as a developer you should design your content so it works well within your given viewport (regardless of what *actually* caused it to be that way). and yes, I can see how that brings up issues *if* you base your font sizes on viewport units, but that's then effectively the caveat/danger of using those units? and that those units like `vm` by their very nature, if used on their own in particular, are zoom-resistant so will, by their very nature, not lend themselves to allowing authors to meet text resize requirements? -- GitHub Notification of comment by patrickhlauke Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6869#issuecomment-1970828945 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
At the risk of resurrecting a lengthy discussion ... I remember skimming over this issue at the time, but have recently been made aware of it again and I'm trying to just check...is this essentially saying: developers want to distinguish between "the viewport is a certain size because the device/browser window/etc is set to a certain size" and "the viewport is a certain size because the user has zoomed"? because if so, I'm really not sure I'm a fan of this idea, because the whole point to me would be that it doesn't matter *why* a viewport is reported as being a particular size, as a developer you should design your content so it works well within your given viewport (regardless of what *actually* caused it to be that way). and yes, I can see how that brings up issues *if* you base your font sizes on viewport units, but that's then effectively the caveat/danger of using those units? and that those units like `vm` by their very nature, if used on their own in particular, are zoom-resistant so will, by their very nature, not lend themselves to allowing authors to meet text resize requirements? -- GitHub Notification of comment by patrickhlauke Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6869#issuecomment-1970828945 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
At the risk of resurrecting a lengthy discussion ... I remember skimming over this issue at the time, but have recently been made aware of it again and I'm trying to just check...is this essentially saying: developers want to distinguish between "the viewport is a certain size because the device/browser window/etc is set to a certain size" and "the viewport is a certain size because the user has zoomed"? because if so, I'm really not sure I'm a fan of this idea, because the whole point to me would be that it doesn't matter *why* a viewport is reported as being a particular size, as a developer you should design your content so it works well within your given viewport (regardless of what *actually* caused it to be that way). and yes, I can see how that brings up issues *if* you base your font sizes on viewport units, but that's then effectively the caveat/danger of using those units? and that those units like `vm` by their very nature, if used on their own in particular, are zoom-resistant so will, by their very nature, not lend themselves to allowing authors to meet text resize requirements? -- GitHub Notification of comment by patrickhlauke Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6869#issuecomment-1970828945 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
At the risk of resurrecting a lengthy discussion ... I remember skimming over this issue at the time, but have recently been made aware of it again and I'm trying to just check...is this essentially saying: developers want to distinguish between "the viewport is a certain size because the device/browser window/etc is set to a certain size" and "the viewport is a certain size because the user has zoomed"? because if so, I'm really not sure I'm a fan of this idea, because the whole point to me would be that it doesn't matter *why* a viewport is reported as being a particular size, as a developer you should design your content so it works well within your given viewport (regardless of what *actually* caused it to be that way). and yes, I can see how that brings up issues *if* you base your font sizes on viewport units, but that's then effectively the caveat/danger of using those units? and that those units like `vm` by their very nature, if used on their own in particular, are zoom-resistant so will, by their very nature, not lend themselves to allowing authors to meet text resize requirements? -- GitHub Notification of comment by patrickhlauke Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6869#issuecomment-1970828945 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Closing as having been rearranged. We might do more rearranging in the future, but the proximate complaint has been addressed. ^_^ -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8869#issuecomment-1970195256 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Closing as having been rearranged. We might do more rearranging in the future, but the proximate complaint has been addressed. ^_^ -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8869#issuecomment-1970195256 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Closing as having been rearranged. We might do more rearranging in the future, but the proximate complaint has been addressed. ^_^ -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8869#issuecomment-1970195256 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Closing as having been rearranged. We might do more rearranging in the future, but the proximate complaint has been addressed. ^_^ -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8869#issuecomment-1970195256 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Closing as having been rearranged. We might do more rearranging in the future, but the proximate complaint has been addressed. ^_^ -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8869#issuecomment-1970195256 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Closing as having been rearranged. We might do more rearranging in the future, but the proximate complaint has been addressed. ^_^ -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8869#issuecomment-1970195256 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Closing as having been rearranged. We might do more rearranging in the future, but the proximate complaint has been addressed. ^_^ -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8869#issuecomment-1970195256 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/8869 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Closing this as part of #9598 now -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8372#issuecomment-1970192509 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/8372 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Even more importantly, resolved by #9598's "interleaving". Closing. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8180#issuecomment-1970177274 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/8180 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Closing as dupe now of #9868 -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8724#issuecomment-1970165117 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/8724 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Closing as #9868 dupe. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9662#issuecomment-1970157801 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/9662 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
tabatkins closed this issue. See https://github.com/w3c/csswg-drafts/issues/9270 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Some experimenting with learning about container-query changes via JS - MutationObserver - Not possible, CSS cannot cause mutations to be observed; Thought perhaps pseudo-elements might work.. they don't. - IntersectionObserver - Viable perhaps by toggling `display: none` on a "dummy" element. Limitations: If the container is outside the viewport - Example: https://codepen.io/robrez/pen/jOROErL - ResizeObserver - Viable by toggling any css property. I'm unsure if the CSS engine will always run prior to the resizeObserver callback - Example: https://codepen.io/robrez/pen/yLrLyKE - Note that many would just use the ResizeObserver w/o any interaction w/ an underlying container query css policy... but the point of this thread is to have something similar to `mediaMatch`. The things you can do in CSS might be tricky to otherwise detect in JS - Note also that `Element.matches` seems like a reasonable _instictive_ "let me try this"... but it will not tolerate any container query -- GitHub Notification of comment by robrez Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6205#issuecomment-1970111751 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
keithamus has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-om] Can we lift the restriction on constructed flag for adoptedStylesheets? == Currently `adoptedStyleSheets` has a restriction on `CSSStyleSheets` that have the `constructed` flag set: > The [set an indexed value](https://webidl.spec.whatwg.org/#observable-array-attribute-set-an-indexed-value) algorithm for adoptedStyleSheets, given value and index, is the following: > > 1. If value’s [constructed flag](https://drafts.csswg.org/cssom/#concept-css-style-sheet-constructed-flag) is not set, or its [constructor document](https://drafts.csswg.org/cssom/#concept-css-style-sheet-constructor-document) is not equal to this [DocumentOrShadowRoot](https://dom.spec.whatwg.org/#documentorshadowroot)'s [node document](https://dom.spec.whatwg.org/#concept-node-document), throw a "[NotAllowedError](https://webidl.spec.whatwg.org/#notallowederror)" [DOMException](https://webidl.spec.whatwg.org/#idl-DOMException). I'm here to rattle this Chesterton's fence. It would be _really_ useful to be able to pluck a documents stylesheets and adopt it into a shadowroots `adoptedStyleSheets`, co-opting the pages styles while applying the shadow's own styles. Currently this is possible with a rather unfortunate amount of JS by duplicating a `<link>` tag and stuffing it in your shadow-dom, but it feels like we can make this easier? (Cue discussion about `@import` and media queries...) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10013 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
keithamus has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-om] Can we lift the restriction on constructed flag for adoptedStylesheets? == Currently `adoptedStyleSheets` has a restriction on `CSSStyleSheets` that have the `constructed` flag set: > The [set an indexed value](https://webidl.spec.whatwg.org/#observable-array-attribute-set-an-indexed-value) algorithm for adoptedStyleSheets, given value and index, is the following: > > 1. If value’s [constructed flag](https://drafts.csswg.org/cssom/#concept-css-style-sheet-constructed-flag) is not set, or its [constructor document](https://drafts.csswg.org/cssom/#concept-css-style-sheet-constructor-document) is not equal to this [DocumentOrShadowRoot](https://dom.spec.whatwg.org/#documentorshadowroot)'s [node document](https://dom.spec.whatwg.org/#concept-node-document), throw a "[NotAllowedError](https://webidl.spec.whatwg.org/#notallowederror)" [DOMException](https://webidl.spec.whatwg.org/#idl-DOMException). I'm here to rattle this Chesterton's fence. It would be _really_ useful to be able to pluck a documents stylesheets and adopt it into a shadowroots `adoptedStyleSheets`, co-opting the pages styles while applying the shadow's own styles. Currently this is possible with a rather unfortunate amount of JS by duplicating a `<link>` tag and stuffing it in your shadow-dom, but it feels like we can make this easier? (Cue discussion about `@import` and media queries...) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10013 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
keithamus has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-om] Can we lift the restriction on constructed flag for adoptedStylesheets? == Currently `adoptedStyleSheets` has a restriction on `CSSStyleSheets` that have the `constructed` flag set: > The [set an indexed value](https://webidl.spec.whatwg.org/#observable-array-attribute-set-an-indexed-value) algorithm for adoptedStyleSheets, given value and index, is the following: > > 1. If value’s [constructed flag](https://drafts.csswg.org/cssom/#concept-css-style-sheet-constructed-flag) is not set, or its [constructor document](https://drafts.csswg.org/cssom/#concept-css-style-sheet-constructor-document) is not equal to this [DocumentOrShadowRoot](https://dom.spec.whatwg.org/#documentorshadowroot)'s [node document](https://dom.spec.whatwg.org/#concept-node-document), throw a "[NotAllowedError](https://webidl.spec.whatwg.org/#notallowederror)" [DOMException](https://webidl.spec.whatwg.org/#idl-DOMException). I'm here to rattle this Chesterton's fence. It would be _really_ useful to be able to pluck a documents stylesheets and adopt it into a shadowroots `adoptedStyleSheets`, co-opting the pages styles while applying the shadow's own styles. Currently this is possible with a rather unfortunate amount of JS by duplicating a `<link>` tag and stuffing it in your shadow-dom, but it feels like we can make this easier? (Cue discussion about `@import` and media queries...) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10013 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
keithamus has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-om] Can we lift the restriction on constructed flag for adoptedStylesheets? == Currently `adoptedStyleSheets` has a restriction on `CSSStyleSheets` that have the `constructed` flag set: > The [set an indexed value](https://webidl.spec.whatwg.org/#observable-array-attribute-set-an-indexed-value) algorithm for adoptedStyleSheets, given value and index, is the following: > > 1. If value’s [constructed flag](https://drafts.csswg.org/cssom/#concept-css-style-sheet-constructed-flag) is not set, or its [constructor document](https://drafts.csswg.org/cssom/#concept-css-style-sheet-constructor-document) is not equal to this [DocumentOrShadowRoot](https://dom.spec.whatwg.org/#documentorshadowroot)'s [node document](https://dom.spec.whatwg.org/#concept-node-document), throw a "[NotAllowedError](https://webidl.spec.whatwg.org/#notallowederror)" [DOMException](https://webidl.spec.whatwg.org/#idl-DOMException). I'm here to rattle this Chesterton's fence. It would be _really_ useful to be able to pluck a documents stylesheets and adopt it into a shadowroots `adoptedStyleSheets`, co-opting the pages styles while applying the shadow's own styles. Currently this is possible with a rather unfortunate amount of JS by duplicating a `<link>` tag and stuffing it in your shadow-dom, but it feels like we can make this easier? (Cue discussion about `@import` and media queries...) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10013 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
keithamus has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-om] Can we lift the restriction on constructed flag for adoptedStylesheets? == Currently `adoptedStyleSheets` has a restriction on `CSSStyleSheets` that have the `constructed` flag set: > The [set an indexed value](https://webidl.spec.whatwg.org/#observable-array-attribute-set-an-indexed-value) algorithm for adoptedStyleSheets, given value and index, is the following: > > 1. If value’s [constructed flag](https://drafts.csswg.org/cssom/#concept-css-style-sheet-constructed-flag) is not set, or its [constructor document](https://drafts.csswg.org/cssom/#concept-css-style-sheet-constructor-document) is not equal to this [DocumentOrShadowRoot](https://dom.spec.whatwg.org/#documentorshadowroot)'s [node document](https://dom.spec.whatwg.org/#concept-node-document), throw a "[NotAllowedError](https://webidl.spec.whatwg.org/#notallowederror)" [DOMException](https://webidl.spec.whatwg.org/#idl-DOMException). I'm here to rattle this Chesterton's fence. It would be _really_ useful to be able to pluck a documents stylesheets and adopt it into a shadowroots `adoptedStyleSheets`, co-opting the pages styles while applying the shadow's own styles. Currently this is possible with a rather unfortunate amount of JS by duplicating a `<link>` tag and stuffing it in your shadow-dom, but it feels like we can make this easier? (Cue discussion about `@import` and media queries...) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10013 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
keithamus has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-om] Can we lift the restriction on constructed flag for adoptedStylesheets? == Currently `adoptedStyleSheets` has a restriction on `CSSStyleSheets` that have the `constructed` flag set: > The [set an indexed value](https://webidl.spec.whatwg.org/#observable-array-attribute-set-an-indexed-value) algorithm for adoptedStyleSheets, given value and index, is the following: > > 1. If value’s [constructed flag](https://drafts.csswg.org/cssom/#concept-css-style-sheet-constructed-flag) is not set, or its [constructor document](https://drafts.csswg.org/cssom/#concept-css-style-sheet-constructor-document) is not equal to this [DocumentOrShadowRoot](https://dom.spec.whatwg.org/#documentorshadowroot)'s [node document](https://dom.spec.whatwg.org/#concept-node-document), throw a "[NotAllowedError](https://webidl.spec.whatwg.org/#notallowederror)" [DOMException](https://webidl.spec.whatwg.org/#idl-DOMException). I'm here to rattle this Chesterton's fence. It would be _really_ useful to be able to pluck a documents stylesheets and adopt it into a shadowroots `adoptedStyleSheets`, co-opting the pages styles while applying the shadow's own styles. Currently this is possible with a rather unfortunate amount of JS by duplicating a `<link>` tag and stuffing it in your shadow-dom, but it feels like we can make this easier? (Cue discussion about `@import` and media queries...) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10013 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
keithamus has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-om] Can we lift the restriction on constructed flag for adoptedStylesheets? == Currently `adoptedStyleSheets` has a restriction on `CSSStyleSheets` that have the `constructed` flag set: > The [set an indexed value](https://webidl.spec.whatwg.org/#observable-array-attribute-set-an-indexed-value) algorithm for adoptedStyleSheets, given value and index, is the following: > > 1. If value’s [constructed flag](https://drafts.csswg.org/cssom/#concept-css-style-sheet-constructed-flag) is not set, or its [constructor document](https://drafts.csswg.org/cssom/#concept-css-style-sheet-constructor-document) is not equal to this [DocumentOrShadowRoot](https://dom.spec.whatwg.org/#documentorshadowroot)'s [node document](https://dom.spec.whatwg.org/#concept-node-document), throw a "[NotAllowedError](https://webidl.spec.whatwg.org/#notallowederror)" [DOMException](https://webidl.spec.whatwg.org/#idl-DOMException). I'm here to rattle this Chesterton's fence. It would be _really_ useful to be able to pluck a documents stylesheets and adopt it into a shadowroots `adoptedStyleSheets`, co-opting the pages styles while applying the shadow's own styles. Currently this is possible with a rather unfortunate amount of JS by duplicating a `<link>` tag and stuffing it in your shadow-dom, but it feels like we can make this easier? (Cue discussion about `@import` and media queries...) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10013 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
keithamus has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-om] Can we lift the restriction on constructed flag for adoptedStylesheets? == Currently `adoptedStyleSheets` has a restriction on `CSSStyleSheets` that have the `constructed` flag set: > The [set an indexed value](https://webidl.spec.whatwg.org/#observable-array-attribute-set-an-indexed-value) algorithm for adoptedStyleSheets, given value and index, is the following: > > 1. If value’s [constructed flag](https://drafts.csswg.org/cssom/#concept-css-style-sheet-constructed-flag) is not set, or its [constructor document](https://drafts.csswg.org/cssom/#concept-css-style-sheet-constructor-document) is not equal to this [DocumentOrShadowRoot](https://dom.spec.whatwg.org/#documentorshadowroot)'s [node document](https://dom.spec.whatwg.org/#concept-node-document), throw a "[NotAllowedError](https://webidl.spec.whatwg.org/#notallowederror)" [DOMException](https://webidl.spec.whatwg.org/#idl-DOMException). I'm here to rattle this Chesterton's fence. It would be _really_ useful to be able to pluck a documents stylesheets and adopt it into a shadowroots `adoptedStyleSheets`, co-opting the pages styles while applying the shadow's own styles. Currently this is possible with a rather unfortunate amount of JS by duplicating a `<link>` tag and stuffing it in your shadow-dom, but it feels like we can make this easier? (Cue discussion about `@import` and media queries...) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10013 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
keithamus has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-om] Can we lift the restriction on constructed flag for adoptedStylesheets? == Currently `adoptedStyleSheets` has a restriction on `CSSStyleSheets` that have the `constructed` flag set: > The [set an indexed value](https://webidl.spec.whatwg.org/#observable-array-attribute-set-an-indexed-value) algorithm for adoptedStyleSheets, given value and index, is the following: > > 1. If value’s [constructed flag](https://drafts.csswg.org/cssom/#concept-css-style-sheet-constructed-flag) is not set, or its [constructor document](https://drafts.csswg.org/cssom/#concept-css-style-sheet-constructor-document) is not equal to this [DocumentOrShadowRoot](https://dom.spec.whatwg.org/#documentorshadowroot)'s [node document](https://dom.spec.whatwg.org/#concept-node-document), throw a "[NotAllowedError](https://webidl.spec.whatwg.org/#notallowederror)" [DOMException](https://webidl.spec.whatwg.org/#idl-DOMException). I'm here to rattle this Chesterton's fence. It would be _really_ useful to be able to pluck a documents stylesheets and adopt it into a shadowroots `adoptedStyleSheets`, co-opting the pages styles while applying the shadow's own styles. Currently this is possible with a rather unfortunate amount of JS by duplicating a `<link>` tag and stuffing it in your shadow-dom, but it feels like we can make this easier? (Cue discussion about `@import` and media queries...) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10013 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
astearns closed this issue. See https://github.com/w3c/csswg-drafts/issues/7947 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
astearns closed this issue. See https://github.com/w3c/csswg-drafts/issues/7947 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
astearns closed this issue. See https://github.com/w3c/csswg-drafts/issues/7947 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
astearns closed this issue. See https://github.com/w3c/csswg-drafts/issues/6739 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
astearns closed this issue. See https://github.com/w3c/csswg-drafts/issues/6739 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Rename type to typeList for CSSViewTransitionRule == Closes https://github.com/w3c/csswg-drafts/issues/9905 See https://github.com/w3c/csswg-drafts/pull/10012 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Rename type to typeList for CSSViewTransitionRule == Closes https://github.com/w3c/csswg-drafts/issues/9905 See https://github.com/w3c/csswg-drafts/pull/10012 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
khushalsagar has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Rename type to typeList for CSSViewTransitionRule == Closes https://github.com/w3c/csswg-drafts/issues/9905 See https://github.com/w3c/csswg-drafts/pull/10012 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
emilio has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions] Make CSSOM interface read-only == I think we have a resolution to make new OM interfaces read-only somewhere, but I couldn't find it. https://github.com/w3c/csswg-drafts/issues/6819 / https://github.com/w3c/csswg-drafts/issues/7033#issuecomment-1046662228 etc are pointers tho... In any case, any strong reason to make https://drafts.csswg.org/css-view-transitions-2/#navgation-behavior-rule-interface writeable? If not, could we just make it read-only? cc @nt1m @noamr @tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10011 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@fantasai looks good to me. -- GitHub Notification of comment by emilio Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4240#issuecomment-1969550160 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@fantasai looks good to me. -- GitHub Notification of comment by emilio Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4240#issuecomment-1969550160 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Reopening as per the discussion in #7947. IMO for style queries it seems you really really want the flat tree. -- GitHub Notification of comment by emilio Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5984#issuecomment-1969538606 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Reopening as per the discussion in #7947. IMO for style queries it seems you really really want the flat tree. -- GitHub Notification of comment by emilio Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5984#issuecomment-1969538606 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Reopening as per the discussion in #7947. IMO for style queries it seems you really really want the flat tree. -- GitHub Notification of comment by emilio Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5984#issuecomment-1969538606 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Reopening as per the discussion in #7947. IMO for style queries it seems you really really want the flat tree. -- GitHub Notification of comment by emilio Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5984#issuecomment-1969538606 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Reopening as per the discussion in #7947. IMO for style queries it seems you really really want the flat tree. -- GitHub Notification of comment by emilio Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5984#issuecomment-1969538606 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed ``[css-borders] accept "px" for pixel values in `border-image-slice` ``, and agreed to the following: * `RESOLVED: Not going to use the pixel unit for the pixel value in border-image-slice` <details><summary>The full IRC log of that discussion</summary> <Frances> Sebastian: Suggested to allow pixel unit for border-image-slice. For authors it is easier to express in pixel values.<br> <emilio> q+<br> <TabAtkins> q+<br> <Frances> Sebastian: Pixel unit is meant for CSS pixels, from an authors perspective it looks weird to have a unitless number for slicing. Would like to possibly introduce a pixel unit.<br> <astearns> ack emilio<br> <Frances> Emilio: Is there a use case for a non pixel length?<br> <Frances> Sebastian: Would just be pixels.<br> <kizu> q+<br> <astearns> ack TabAtkins<br> <Frances> Emilio: Either come up with a different unit and use calc() with it, or treat pixels as arbitrary lengths.<br> <Frances> Emilio: Slightly against<br> <emilio> emilio: it'd be unfortunate if e.g. the zoom property affected this<br> <Frances> Tab: Also slightly against. Pixels to allowed but not others, can put px at the end of a number but nothing else, could end up being confusing.<br> <astearns> ack kizu<br> <SebastianZ> q+<br> <Frances> Roman: For non pixels in any length is if using css gradient and slice using the same thing for the stop of the gradient.<br> <astearns> ack SebastianZ<br> <Frances> Roman: Might not be worth introducing a change.<br> <Frances> Sebastian: Are there other use cases other than border-image-slice? If other use cases for a new pixel unit, could introduce in border-image-slice, until then, we can resolve not to add the px unit.<br> <Frances> Alan: Let's resolve<br> <lea> As Roman said, I do think `border-image` is rotten at the core and needs a complete re-architecting, but no cycles to work on that rn. I would weakly support this change, but it doesn't make much of a difference<br> <Frances> PROPOSAL: Not going to use the pixel unit for the pixel value in border-image-slice<br> <Frances> RESOLVED: Not going to use the pixel unit for the pixel value in border-image-slice<br> <Frances> Alan: If we find other use cases for it, we could consider adding it to border-image-slice. Work on a replacement for border-images.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6739#issuecomment-1969530684 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed ``[css-borders] accept "px" for pixel values in `border-image-slice` ``, and agreed to the following: * `RESOLVED: Not going to use the pixel unit for the pixel value in border-image-slice` <details><summary>The full IRC log of that discussion</summary> <Frances> Sebastian: Suggested to allow pixel unit for border-image-slice. For authors it is easier to express in pixel values.<br> <emilio> q+<br> <TabAtkins> q+<br> <Frances> Sebastian: Pixel unit is meant for CSS pixels, from an authors perspective it looks weird to have a unitless number for slicing. Would like to possibly introduce a pixel unit.<br> <astearns> ack emilio<br> <Frances> Emilio: Is there a use case for a non pixel length?<br> <Frances> Sebastian: Would just be pixels.<br> <kizu> q+<br> <astearns> ack TabAtkins<br> <Frances> Emilio: Either come up with a different unit and use calc() with it, or treat pixels as arbitrary lengths.<br> <Frances> Emilio: Slightly against<br> <emilio> emilio: it'd be unfortunate if e.g. the zoom property affected this<br> <Frances> Tab: Also slightly against. Pixels to allowed but not others, can put px at the end of a number but nothing else, could end up being confusing.<br> <astearns> ack kizu<br> <SebastianZ> q+<br> <Frances> Roman: For non pixels in any length is if using css gradient and slice using the same thing for the stop of the gradient.<br> <astearns> ack SebastianZ<br> <Frances> Roman: Might not be worth introducing a change.<br> <Frances> Sebastian: Are there other use cases other than border-image-slice? If other use cases for a new pixel unit, could introduce in border-image-slice, until then, we can resolve not to add the px unit.<br> <Frances> Alan: Let's resolve<br> <lea> As Roman said, I do think `border-image` is rotten at the core and needs a complete re-architecting, but no cycles to work on that rn. I would weakly support this change, but it doesn't make much of a difference<br> <Frances> PROPOSAL: Not going to use the pixel unit for the pixel value in border-image-slice<br> <Frances> RESOLVED: Not going to use the pixel unit for the pixel value in border-image-slice<br> <Frances> Alan: If we find other use cases for it, we could consider adding it to border-image-slice. Work on a replacement for border-images.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6739#issuecomment-1969530684 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed ``[css-values] Let B default to 1 in `round(<strategy>?, A, B)` ``. <details><summary>The full IRC log of that discussion</summary> <Frances> Alan: Moving onto the next issue, we are limited by compat concerns.<br> <Frances> Tab: Round function takes a rounding strategy, we require the modulus to be rounded. We could omit the modulus.<br> <emilio> q+<br> <lea> q?<br> <astearns> ack emilio<br> <lea> q+<br> <Frances> Emilio: It feels weird to make lengths invalid and not make it optional, such as rounding a pixel value. Default for the length would be nice.<br> <astearns> ack lea<br> <Frances> Tab: Rounding to one pixel as a default is not obvious, people might not care about subpixels, but rather the unit they are using.<br> <bramus> +1 on what tab just said.<br> <emilio> q+<br> <astearns> ack emilio<br> <Frances> Lea: Should not have to specify 1, whereas dimensions such as length, would make more sense on what you are rounding by, pixels might not be used too much today. Would like default for lengths, possibly not pixels.<br> <lea> qq+ to reply to emilio<br> <Frances> Emilio: In length there is a single unit that other lengths end up computing to.<br> <astearns> ack lea<br> <Zakim> lea, you wanted to react to emilio to reply to emilio<br> <Frances> Lea: Sensible defaults are great when centered around user needs or could be confusing.<br> <oriol> q+<br> <Frances> Alan: It is reasonable to have numbers default to 1, but not reasonable for numbers to default to invalid for another type.<br> <Frances> Lea: Which invalid results?<br> <oriol> q-<br> <lea> q?<br> <Frances> Alan: Once taking the pattern of omitting the argument and applying it, it could create invalid creations.<br> <florian> q+<br> <bramus> q+<br> <emilio> q+<br> <Frances> Lea: When rounding numbers will be clear, when rounding lengths will not be clear.<br> <emilio> ack emilio<br> <lea> q+<br> <astearns> ack Frances<br> <astearns> ack florian<br> <Frances> Alan: There could be a reasonable default, omit the parameter in some implications but not others.<br> <oriol> +1 to Florian<br> <Frances> Florian: Figuring out more syntax is necessary, you need to express something. Figuring out which syntax is implied. For rounding things, separate digits after the comma. Does 10 mean 10 digits after the period or before the period? For lengths, have to think about this stuff in what you mean.<br> <astearns> ack bramus<br> <lea> +1 to florian, that's exactly what I was saying too (but always good to have multiple framings)<br> <lea> q?<br> <Frances> Bramus: If the default only cares for one of the cases, then it's not a good default?<br> <Frances> Alan: It could make it difficult for an author to reason whether to use the parameter or not.<br> <astearns> ack lea<br> <Frances> Lea: If it's the concern, round could possibly not have a default. It takes a parameter to round by.<br> <Frances> Alan: We can likely resolve on making the change.<br> <Frances> PROPOSAL: Allow the modulus parameter to be optional in the case of rounding numbers and default to 1<br> <Frances> Alan: Objections? No objections.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9668#issuecomment-1969495056 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed ``[css-values] Let B default to 1 in `round(<strategy>?, A, B)` ``. <details><summary>The full IRC log of that discussion</summary> <Frances> Alan: Moving onto the next issue, we are limited by compat concerns.<br> <Frances> Tab: Round function takes a rounding strategy, we require the modulus to be rounded. We could omit the modulus.<br> <emilio> q+<br> <lea> q?<br> <astearns> ack emilio<br> <lea> q+<br> <Frances> Emilio: It feels weird to make lengths invalid and not make it optional, such as rounding a pixel value. Default for the length would be nice.<br> <astearns> ack lea<br> <Frances> Tab: Rounding to one pixel as a default is not obvious, people might not care about subpixels, but rather the unit they are using.<br> <bramus> +1 on what tab just said.<br> <emilio> q+<br> <astearns> ack emilio<br> <Frances> Lea: Should not have to specify 1, whereas dimensions such as length, would make more sense on what you are rounding by, pixels might not be used too much today. Would like default for lengths, possibly not pixels.<br> <lea> qq+ to reply to emilio<br> <Frances> Emilio: In length there is a single unit that other lengths end up computing to.<br> <astearns> ack lea<br> <Zakim> lea, you wanted to react to emilio to reply to emilio<br> <Frances> Lea: Sensible defaults are great when centered around user needs or could be confusing.<br> <oriol> q+<br> <Frances> Alan: It is reasonable to have numbers default to 1, but not reasonable for numbers to default to invalid for another type.<br> <Frances> Lea: Which invalid results?<br> <oriol> q-<br> <lea> q?<br> <Frances> Alan: Once taking the pattern of omitting the argument and applying it, it could create invalid creations.<br> <florian> q+<br> <bramus> q+<br> <emilio> q+<br> <Frances> Lea: When rounding numbers will be clear, when rounding lengths will not be clear.<br> <emilio> ack emilio<br> <lea> q+<br> <astearns> ack Frances<br> <astearns> ack florian<br> <Frances> Alan: There could be a reasonable default, omit the parameter in some implications but not others.<br> <oriol> +1 to Florian<br> <Frances> Florian: Figuring out more syntax is necessary, you need to express something. Figuring out which syntax is implied. For rounding things, separate digits after the comma. Does 10 mean 10 digits after the period or before the period? For lengths, have to think about this stuff in what you mean.<br> <astearns> ack bramus<br> <lea> +1 to florian, that's exactly what I was saying too (but always good to have multiple framings)<br> <lea> q?<br> <Frances> Bramus: If the default only cares for one of the cases, then it's not a good default?<br> <Frances> Alan: It could make it difficult for an author to reason whether to use the parameter or not.<br> <astearns> ack lea<br> <Frances> Lea: If it's the concern, round could possibly not have a default. It takes a parameter to round by.<br> <Frances> Alan: We can likely resolve on making the change.<br> <Frances> PROPOSAL: Allow the modulus parameter to be optional in the case of rounding numbers and default to 1<br> <Frances> Alan: Objections? No objections.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9668#issuecomment-1969495056 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Both of the mentioned broken links are no longer found in the current draft. -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8075#issuecomment-1969484659 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus closed this issue. See https://github.com/w3c/csswg-drafts/issues/8075 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed `[css-cascade] [css-nesting] Figure out whether we're fine with "shifting up" bare declarations after rules`. <details><summary>The full IRC log of that discussion</summary> <astearns> ack bramus<br> <Frances> Tab: Suggest to wait a little longer for use counters<br> <astearns> ack lea<br> <Frances> Lea: Use counters trade off in waiting, we might not be able to make the change. CSS nesting is established, how could people use it, have anecdotal data. To continue having shifting data, would like to fix it.<br> <Frances> Tab: Need to see if it is possible to fix it, will not change unless we can see that it is compatible, in favor.<br> <Frances> Lea: Don't need to wait for the use counters.<br> <Frances> Alan: Consensus that it is the right thing if possible.<br> <lea> s/Don't need to wait for the use counters./Don't need to wait for the use counters to decide whether it's worth doing, only to determine whether it *can* be done./<br> <Frances> Alan: Would it be possible to make the change, what else do we have to do to see if it will work correctly. Is there a separate issue for SSN?<br> <lea> q+<br> <Frances> Tab: A naked ampersand style rule could be possible.<br> <TabAtkins> The proposal in the issue is to reintroduce @nest without any arguments, which just represents the same elements as the parent. This also avoids problems that would come from a naked `& {...}` rule. Details are in the issue.<br> <Frances> Matthieu: Would like if we could find the solution in parrallel.<br> <astearns> ack lea<br> <Frances> Lea: The author intent is clear, would not like to have another nesting syntax, bad from ui perspective.<br> <TabAtkins> (We already do this "hack" in MQs/etc, fwiw.)<br> <Frances> Tab: CSSOM would reflect after the first rule showed up as @nest rules. Could get grouped up and lose their ordering.<br> <dbaron> s/Could get/Otherwise they would get/<br> <dbaron> s/reflect/reflect declarations/<br> <lea> +1 The design component of this does not need use counters and I'm not sure we have consensus on the design we want<br> <Frances> Alan: It could be useful to continue to work and separate CSSOM into a separate issue.<br> <Frances> Tab: We could create a separate CSSOM issue.<br> <Frances> Alan: We can work through it as soon as we get compat data back.<br> <oriol> Tab's proposal was on another issue, https://github.com/w3c/csswg-drafts/issues/9492#issuecomment-1779739434<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8738#issuecomment-1969468715 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
The CSS Working Group just discussed `[css-cascade] [css-nesting] Figure out whether we're fine with "shifting up" bare declarations after rules`. <details><summary>The full IRC log of that discussion</summary> <astearns> ack bramus<br> <Frances> Tab: Suggest to wait a little longer for use counters<br> <astearns> ack lea<br> <Frances> Lea: Use counters trade off in waiting, we might not be able to make the change. CSS nesting is established, how could people use it, have anecdotal data. To continue having shifting data, would like to fix it.<br> <Frances> Tab: Need to see if it is possible to fix it, will not change unless we can see that it is compatible, in favor.<br> <Frances> Lea: Don't need to wait for the use counters.<br> <Frances> Alan: Consensus that it is the right thing if possible.<br> <lea> s/Don't need to wait for the use counters./Don't need to wait for the use counters to decide whether it's worth doing, only to determine whether it *can* be done./<br> <Frances> Alan: Would it be possible to make the change, what else do we have to do to see if it will work correctly. Is there a separate issue for SSN?<br> <lea> q+<br> <Frances> Tab: A naked ampersand style rule could be possible.<br> <TabAtkins> The proposal in the issue is to reintroduce @nest without any arguments, which just represents the same elements as the parent. This also avoids problems that would come from a naked `& {...}` rule. Details are in the issue.<br> <Frances> Matthieu: Would like if we could find the solution in parrallel.<br> <astearns> ack lea<br> <Frances> Lea: The author intent is clear, would not like to have another nesting syntax, bad from ui perspective.<br> <TabAtkins> (We already do this "hack" in MQs/etc, fwiw.)<br> <Frances> Tab: CSSOM would reflect after the first rule showed up as @nest rules. Could get grouped up and lose their ordering.<br> <dbaron> s/Could get/Otherwise they would get/<br> <dbaron> s/reflect/reflect declarations/<br> <lea> +1 The design component of this does not need use counters and I'm not sure we have consensus on the design we want<br> <Frances> Alan: It could be useful to continue to work and separate CSSOM into a separate issue.<br> <Frances> Tab: We could create a separate CSSOM issue.<br> <Frances> Alan: We can work through it as soon as we get compat data back.<br> <oriol> Tab's proposal was on another issue, https://github.com/w3c/csswg-drafts/issues/9492#issuecomment-1779739434<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8738#issuecomment-1969468715 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
svgeesus has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-backgrounds-3] Steps to Recommendation == (Also css-backgrounds-3 is basically a REC that's just missing an implementation report so definitely anything other than an error correction goes in css-backgrounds-4.) _Originally posted by @fantasai in https://github.com/w3c/csswg-drafts/issues/6739#issuecomment-950031510_ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10010 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I thought that negative zero is always tokenized and parsed as positive zero and that negative zero can only be produced by calculations. So serializing to `-0` wouldn't actually work because it wouldn't round trip. I've actually been using `calc(-1 * 0)` for tooling: - `min(1% / -infinity, 0%)` is converted to `calc(-1 * 0%)` - `max(1% / -infinity, 0%)` is converted to `0%` The context is a bit different for me as the purpose is to calculate what is possible in dev tooling without altering how a browser would parse these. -- GitHub Notification of comment by romainmenke Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9750#issuecomment-1969370921 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
bramus has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [CONTRIBUTING.md] Clarify that PRs should originate from your own fork == Minor update to clarify that PRs should originate from your own fork. This is something I had to find out when filing one of my first PRs – I had created a branch in the `w3c/csswg-drafts` repo, upon which I was told that this isn’t how things are done here. See https://github.com/w3c/csswg-drafts/pull/10009 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
bramus has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [CONTRIBUTING.md] Clarify that PRs should originate from your own fork == Minor update to clarify that PRs should originate from your own fork. This is something I had to find out when filing one of my first PRs – I had created a branch in the `w3c/csswg-drafts` repo, upon which I was told that this isn’t how things are done here. See https://github.com/w3c/csswg-drafts/pull/10009 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
bramus has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [CONTRIBUTING.md] Clarify that PRs should originate from your own fork == Minor update to clarify that PRs should originate from your own fork. This is something I had to find out when filing one of my first PRs – I had created a branch in the `w3c/csswg-drafts` repo, upon which I was told that this isn’t how things are done here. See https://github.com/w3c/csswg-drafts/pull/10009 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
bramus has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [CONTRIBUTING.md] Clarify that PRs should originate from your own fork == Minor update to clarify that PRs should originate from your own fork. This is something I had to find out when filing one of my first PRs – I had created a branch in the `w3c/csswg-drafts` repo, upon which I was told that this isn’t how things are done here. See https://github.com/w3c/csswg-drafts/pull/10009 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
bramus has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [CONTRIBUTING.md] Clarify that PRs should originate from your own fork == Minor update to clarify that PRs should originate from your own fork. This is something I had to find out when filing one of my first PRs – I had created a branch in the `w3c/csswg-drafts` repo, upon which I was told that this isn’t how things are done here. See https://github.com/w3c/csswg-drafts/pull/10009 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
bramus has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [CONTRIBUTING.md] Clarify that PRs should originate from your own fork == Minor update to clarify that PRs should originate from your own fork. This is something I had to find out when filing one of my first PRs – I had created a branch in the `w3c/csswg-drafts` repo, upon which I was told that this isn’t how things are done here. See https://github.com/w3c/csswg-drafts/pull/10009 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
bramus has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [CONTRIBUTING.md] Clarify that PRs should originate from your own fork == Minor update to clarify that PRs should originate from your own fork. This is something I had to find out when filing one of my first PRs – I had created a branch in the `w3c/csswg-drafts` repo, upon which I was told that this isn’t how things are done here. See https://github.com/w3c/csswg-drafts/pull/10009 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
bramus has just submitted a new pull request for https://github.com/w3c/csswg-drafts: == [CONTRIBUTING.md] Clarify that PRs should originate from your own fork == Minor update to clarify that PRs should originate from your own fork. This is something I had to find out when filing one of my first PRs – I had created a branch in the `w3c/csswg-drafts` repo, upon which I was told that this isn’t how things are done here. See https://github.com/w3c/csswg-drafts/pull/10009 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Selecting a different container for cq units than for the querying container does not make sense, right? Then, if this needs to be revisited, wouldn't it be better to re-open issue #5984 ? -- GitHub Notification of comment by lilles Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7947#issuecomment-1968452366 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Selecting a different container for cq units than for the querying container does not make sense, right? Then, if this needs to be revisited, wouldn't it be better to re-open issue #5984 ? -- GitHub Notification of comment by lilles Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7947#issuecomment-1968452366 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Selecting a different container for cq units than for the querying container does not make sense, right? Then, if this needs to be revisited, wouldn't it be better to re-open issue #5984 ? -- GitHub Notification of comment by lilles Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7947#issuecomment-1968452366 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Selecting a different container for cq units than for the querying container does not make sense, right? Then, if this needs to be revisited, wouldn't it be better to re-open issue #5984 ? -- GitHub Notification of comment by lilles Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7947#issuecomment-1968452366 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-align-3] Default safety of scroll containers == In https://github.com/w3c/csswg-drafts/issues/8992 we decided to make the default safety of block containers as `safe`, to help avoid inadvertent clipping. But for scrollable block containers, this isn't a concern since `align-content` also [changes how the scrollable overflow area](https://www.w3.org/TR/css-align-3/#overflow-scroll-position) is clipped. So I'm wondering if we should make the default alignment `unsafe` for scroll containers or not. [demo that doesn't actually work atm...](https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%0A%3Cstyle%3E%0A%20%20body%20%7B%20display%3A%20flex%3B%20height%3A%205em%3B%20%7D%0A%20%20div%20%7B%20margin%3A%200.5em%3B%20border%3A%20solid%3B%20%7D%0A%20%20div%3Ahover%3A%3Abefore%20%7B%0A%20%20%20%20%20position%3A%20absolute%3B%0A%20%20%20%20%20top%3A%200%3B%20left%3A%200%3B%0A%20%20%20%20%20content%3A%20attr(style)%3B%0A%20%20%20%20%20background%3A%20Canvas%3B%0A%20%20%7D%0A%3Cstyle%3E) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10008 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-align-3] Default safety of scroll containers == In https://github.com/w3c/csswg-drafts/issues/8992 we decided to make the default safety of block containers as `safe`, to help avoid inadvertent clipping. But for scrollable block containers, this isn't a concern since `align-content` also [changes how the scrollable overflow area](https://www.w3.org/TR/css-align-3/#overflow-scroll-position) is clipped. So I'm wondering if we should make the default alignment `unsafe` for scroll containers or not. [demo that doesn't actually work atm...](https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%0A%3Cstyle%3E%0A%20%20body%20%7B%20display%3A%20flex%3B%20height%3A%205em%3B%20%7D%0A%20%20div%20%7B%20margin%3A%200.5em%3B%20border%3A%20solid%3B%20%7D%0A%20%20div%3Ahover%3A%3Abefore%20%7B%0A%20%20%20%20%20position%3A%20absolute%3B%0A%20%20%20%20%20top%3A%200%3B%20left%3A%200%3B%0A%20%20%20%20%20content%3A%20attr(style)%3B%0A%20%20%20%20%20background%3A%20Canvas%3B%0A%20%20%7D%0A%3Cstyle%3E) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10008 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-align-3] Default safety of scroll containers == In https://github.com/w3c/csswg-drafts/issues/8992 we decided to make the default safety of block containers as `safe`, to help avoid inadvertent clipping. But for scrollable block containers, this isn't a concern since `align-content` also [changes how the scrollable overflow area](https://www.w3.org/TR/css-align-3/#overflow-scroll-position) is clipped. So I'm wondering if we should make the default alignment `unsafe` for scroll containers or not. [demo that doesn't actually work atm...](https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%0A%3Cstyle%3E%0A%20%20body%20%7B%20display%3A%20flex%3B%20height%3A%205em%3B%20%7D%0A%20%20div%20%7B%20margin%3A%200.5em%3B%20border%3A%20solid%3B%20%7D%0A%20%20div%3Ahover%3A%3Abefore%20%7B%0A%20%20%20%20%20position%3A%20absolute%3B%0A%20%20%20%20%20top%3A%200%3B%20left%3A%200%3B%0A%20%20%20%20%20content%3A%20attr(style)%3B%0A%20%20%20%20%20background%3A%20Canvas%3B%0A%20%20%7D%0A%3Cstyle%3E) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10008 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-align-3] Default safety of scroll containers == In https://github.com/w3c/csswg-drafts/issues/8992 we decided to make the default safety of block containers as `safe`, to help avoid inadvertent clipping. But for scrollable block containers, this isn't a concern since `align-content` also [changes how the scrollable overflow area](https://www.w3.org/TR/css-align-3/#overflow-scroll-position) is clipped. So I'm wondering if we should make the default alignment `unsafe` for scroll containers or not. [demo that doesn't actually work atm...](https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%0A%3Cstyle%3E%0A%20%20body%20%7B%20display%3A%20flex%3B%20height%3A%205em%3B%20%7D%0A%20%20div%20%7B%20margin%3A%200.5em%3B%20border%3A%20solid%3B%20%7D%0A%20%20div%3Ahover%3A%3Abefore%20%7B%0A%20%20%20%20%20position%3A%20absolute%3B%0A%20%20%20%20%20top%3A%200%3B%20left%3A%200%3B%0A%20%20%20%20%20content%3A%20attr(style)%3B%0A%20%20%20%20%20background%3A%20Canvas%3B%0A%20%20%7D%0A%3Cstyle%3E) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10008 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-align-3] Default safety of scroll containers == In https://github.com/w3c/csswg-drafts/issues/8992 we decided to make the default safety of block containers as `safe`, to help avoid inadvertent clipping. But for scrollable block containers, this isn't a concern since `align-content` also [changes how the scrollable overflow area](https://www.w3.org/TR/css-align-3/#overflow-scroll-position) is clipped. So I'm wondering if we should make the default alignment `unsafe` for scroll containers or not. [demo that doesn't actually work atm...](https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%0A%3Cstyle%3E%0A%20%20body%20%7B%20display%3A%20flex%3B%20height%3A%205em%3B%20%7D%0A%20%20div%20%7B%20margin%3A%200.5em%3B%20border%3A%20solid%3B%20%7D%0A%20%20div%3Ahover%3A%3Abefore%20%7B%0A%20%20%20%20%20position%3A%20absolute%3B%0A%20%20%20%20%20top%3A%200%3B%20left%3A%200%3B%0A%20%20%20%20%20content%3A%20attr(style)%3B%0A%20%20%20%20%20background%3A%20Canvas%3B%0A%20%20%7D%0A%3Cstyle%3E) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10008 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-align-3] Default safety of scroll containers == In https://github.com/w3c/csswg-drafts/issues/8992 we decided to make the default safety of block containers as `safe`, to help avoid inadvertent clipping. But for scrollable block containers, this isn't a concern since `align-content` also [changes how the scrollable overflow area](https://www.w3.org/TR/css-align-3/#overflow-scroll-position) is clipped. So I'm wondering if we should make the default alignment `unsafe` for scroll containers or not. [demo that doesn't actually work atm...](https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%0A%3Cstyle%3E%0A%20%20body%20%7B%20display%3A%20flex%3B%20height%3A%205em%3B%20%7D%0A%20%20div%20%7B%20margin%3A%200.5em%3B%20border%3A%20solid%3B%20%7D%0A%20%20div%3Ahover%3A%3Abefore%20%7B%0A%20%20%20%20%20position%3A%20absolute%3B%0A%20%20%20%20%20top%3A%200%3B%20left%3A%200%3B%0A%20%20%20%20%20content%3A%20attr(style)%3B%0A%20%20%20%20%20background%3A%20Canvas%3B%0A%20%20%7D%0A%3Cstyle%3E) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10008 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-align-3] Default safety of scroll containers == In https://github.com/w3c/csswg-drafts/issues/8992 we decided to make the default safety of block containers as `safe`, to help avoid inadvertent clipping. But for scrollable block containers, this isn't a concern since `align-content` also [changes how the scrollable overflow area](https://www.w3.org/TR/css-align-3/#overflow-scroll-position) is clipped. So I'm wondering if we should make the default alignment `unsafe` for scroll containers or not. [demo that doesn't actually work atm...](https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%0A%3Cstyle%3E%0A%20%20body%20%7B%20display%3A%20flex%3B%20height%3A%205em%3B%20%7D%0A%20%20div%20%7B%20margin%3A%200.5em%3B%20border%3A%20solid%3B%20%7D%0A%20%20div%3Ahover%3A%3Abefore%20%7B%0A%20%20%20%20%20position%3A%20absolute%3B%0A%20%20%20%20%20top%3A%200%3B%20left%3A%200%3B%0A%20%20%20%20%20content%3A%20attr(style)%3B%0A%20%20%20%20%20background%3A%20Canvas%3B%0A%20%20%7D%0A%3Cstyle%3E) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10008 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-align-3] Default safety of scroll containers == In https://github.com/w3c/csswg-drafts/issues/8992 we decided to make the default safety of block containers as `safe`, to help avoid inadvertent clipping. But for scrollable block containers, this isn't a concern since `align-content` also [changes how the scrollable overflow area](https://www.w3.org/TR/css-align-3/#overflow-scroll-position) is clipped. So I'm wondering if we should make the default alignment `unsafe` for scroll containers or not. [demo that doesn't actually work atm...](https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%0A%3Cstyle%3E%0A%20%20body%20%7B%20display%3A%20flex%3B%20height%3A%205em%3B%20%7D%0A%20%20div%20%7B%20margin%3A%200.5em%3B%20border%3A%20solid%3B%20%7D%0A%20%20div%3Ahover%3A%3Abefore%20%7B%0A%20%20%20%20%20position%3A%20absolute%3B%0A%20%20%20%20%20top%3A%200%3B%20left%3A%200%3B%0A%20%20%20%20%20content%3A%20attr(style)%3B%0A%20%20%20%20%20background%3A%20Canvas%3B%0A%20%20%7D%0A%3Cstyle%3E) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10008 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-align-3] Default safety of scroll containers == In https://github.com/w3c/csswg-drafts/issues/8992 we decided to make the default safety of block containers as `safe`, to help avoid inadvertent clipping. But for scrollable block containers, this isn't a concern since `align-content` also [changes how the scrollable overflow area](https://www.w3.org/TR/css-align-3/#overflow-scroll-position) is clipped. So I'm wondering if we should make the default alignment `unsafe` for scroll containers or not. [demo that doesn't actually work atm...](https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%0A%3Cstyle%3E%0A%20%20body%20%7B%20display%3A%20flex%3B%20height%3A%205em%3B%20%7D%0A%20%20div%20%7B%20margin%3A%200.5em%3B%20border%3A%20solid%3B%20%7D%0A%20%20div%3Ahover%3A%3Abefore%20%7B%0A%20%20%20%20%20position%3A%20absolute%3B%0A%20%20%20%20%20top%3A%200%3B%20left%3A%200%3B%0A%20%20%20%20%20content%3A%20attr(style)%3B%0A%20%20%20%20%20background%3A%20Canvas%3B%0A%20%20%7D%0A%3Cstyle%3E) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10008 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-align-3] Default safety of scroll containers == In https://github.com/w3c/csswg-drafts/issues/8992 we decided to make the default safety of block containers as `safe`, to help avoid inadvertent clipping. But for scrollable block containers, this isn't a concern since `align-content` also [changes how the scrollable overflow area](https://www.w3.org/TR/css-align-3/#overflow-scroll-position) is clipped. So I'm wondering if we should make the default alignment `unsafe` for scroll containers or not. [demo that doesn't actually work atm...](https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%0A%3Cstyle%3E%0A%20%20body%20%7B%20display%3A%20flex%3B%20height%3A%205em%3B%20%7D%0A%20%20div%20%7B%20margin%3A%200.5em%3B%20border%3A%20solid%3B%20%7D%0A%20%20div%3Ahover%3A%3Abefore%20%7B%0A%20%20%20%20%20position%3A%20absolute%3B%0A%20%20%20%20%20top%3A%200%3B%20left%3A%200%3B%0A%20%20%20%20%20content%3A%20attr(style)%3B%0A%20%20%20%20%20background%3A%20Canvas%3B%0A%20%20%7D%0A%3Cstyle%3E) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10008 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
fantasai has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-align-3] Default safety of scroll containers == In https://github.com/w3c/csswg-drafts/issues/8992 we decided to make the default safety of block containers as `safe`, to help avoid inadvertent clipping. But for scrollable block containers, this isn't a concern since `align-content` also [changes how the scrollable overflow area](https://www.w3.org/TR/css-align-3/#overflow-scroll-position) is clipped. So I'm wondering if we should make the default alignment `unsafe` for scroll containers or not. [demo that doesn't actually work atm...](https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%0A%3Cstyle%3E%0A%20%20body%20%7B%20display%3A%20flex%3B%20height%3A%205em%3B%20%7D%0A%20%20div%20%7B%20margin%3A%200.5em%3B%20border%3A%20solid%3B%20%7D%0A%20%20div%3Ahover%3A%3Abefore%20%7B%0A%20%20%20%20%20position%3A%20absolute%3B%0A%20%20%20%20%20top%3A%200%3B%20left%3A%200%3B%0A%20%20%20%20%20content%3A%20attr(style)%3B%0A%20%20%20%20%20background%3A%20Canvas%3B%0A%20%20%7D%0A%3Cstyle%3E) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10008 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mirisuzanne closed this issue. See https://github.com/w3c/csswg-drafts/issues/9741 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mirisuzanne closed this issue. See https://github.com/w3c/csswg-drafts/issues/9741 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
mirisuzanne closed this issue. See https://github.com/w3c/csswg-drafts/issues/9741 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I noticed in the agenda that this issue is mentioned alongside https://github.com/w3c/csswg-drafts/issues/6705, but neither issue contains an explicit link to another, so I feel it is worth it to mention it explicitly here, as they essentially talk about the same thing. Regarding the potential solution, I would prefer the `value()` or `item()` (or any other function) to any syntax-only way. Most of my arguments for this were already mentioned above, but to re-iterate: 1. I don't like the modality of the `;` vs `,`. It might really be confusing for authors, and it won't be trivial to search for “what is this syntax?”. 2. I don't like the `[]`, `{}` etc, for similar reason, plus I don't like the confusion with the `[]` from the grid syntax. 3. Given this new language feature is required only for edge-cases, I am fine with the syntax being more verbose like with `value()`: if we can keep most of the use cases clear and simple, then it is ok to have the edge-case more verbose. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1966858791 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
We talked about this during the JLReq TF meeting on 2024-2-27. We didn't reach a clear agreement on what should be copied; there were opinions from both sides. One concern brought up was that adding or removing spaces could change the meaning of the text. For instance, if a word contains both Kana/Kanji and Latin/Numbers, like 'Tシャツ,' inserting a space between 'T' and 'シャツ' would make the morphological analyzer see them as two separate words, changing the text's meaning. This could also affect how Text-to-Speech reads the text. Conversely, there might be cases where removing an intentional space could alter the text's semantics. -- GitHub Notification of comment by kidayasuo Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8511#issuecomment-1965844643 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
We talked about this during the JLReq TF meeting on 2024-2-27. We didn't reach a clear agreement on what should be copied; there were opinions from both sides. One concern brought up was that adding or removing spaces could change the meaning of the text. For instance, if a word contains both Kana/Kanji and Latin/Numbers, like 'Tシャツ,' inserting a space between 'T' and 'シャツ' would make the morphological analyzer see them as two separate words, changing the text's meaning. This could also affect how Text-to-Speech reads the text. Conversely, there might be cases where removing an intentional space could alter the text's semantics. -- GitHub Notification of comment by kidayasuo Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8511#issuecomment-1965844643 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
We talked about this during the JLReq TF meeting on 2024-2-27. We didn't reach a clear agreement on what should be copied; there were opinions from both sides. One concern brought up was that adding or removing spaces could change the meaning of the text. For instance, if a word contains both Kana/Kanji and Latin/Numbers, like 'Tシャツ,' inserting a space between 'T' and 'シャツ' would make the morphological analyzer see them as two separate words, changing the text's meaning. This could also affect how Text-to-Speech reads the text. Conversely, there might be cases where removing an intentional space could alter the text's semantics. -- GitHub Notification of comment by kidayasuo Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8511#issuecomment-1965844643 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
We talked about this during the JLReq TF meeting on 2024-2-27. We didn't reach a clear agreement on what should be copied; there were opinions from both sides. One concern brought up was that adding or removing spaces could change the meaning of the text. For instance, if a word contains both Kana/Kanji and Latin/Numbers, like 'Tシャツ,' inserting a space between 'T' and 'シャツ' would make the morphological analyzer see them as two separate words, changing the text's meaning. This could also affect how Text-to-Speech reads the text. Conversely, there might be cases where removing an intentional space could alter the text's semantics. -- GitHub Notification of comment by kidayasuo Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8511#issuecomment-1965844643 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
We talked about this during the JLReq TF meeting on 2024-2-27. We didn't reach a clear agreement on what should be copied; there were opinions from both sides. One concern brought up was that adding or removing spaces could change the meaning of the text. For instance, if a word contains both Kana/Kanji and Latin/Numbers, like 'Tシャツ,' inserting a space between 'T' and 'シャツ' would make the morphological analyzer see them as two separate words, changing the text's meaning. This could also affect how Text-to-Speech reads the text. Conversely, there might be cases where removing an intentional space could alter the text's semantics. -- GitHub Notification of comment by kidayasuo Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8511#issuecomment-1965844643 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
We talked about this during the JLReq TF meeting on 2024-2-27. We didn't reach a clear agreement on what should be copied; there were opinions from both sides. One concern brought up was that adding or removing spaces could change the meaning of the text. For instance, if a word contains both Kana/Kanji and Latin/Numbers, like 'Tシャツ,' inserting a space between 'T' and 'シャツ' would make the morphological analyzer see them as two separate words, changing the text's meaning. This could also affect how Text-to-Speech reads the text. Conversely, there might be cases where removing an intentional space could alter the text's semantics. -- GitHub Notification of comment by kidayasuo Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8511#issuecomment-1965844643 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
We talked about this during the JLReq TF meeting on 2024-2-27. We didn't reach a clear agreement on what should be copied; there were opinions from both sides. One concern brought up was that adding or removing spaces could change the meaning of the text. For instance, if a word contains both Kana/Kanji and Latin/Numbers, like 'Tシャツ,' inserting a space between 'T' and 'シャツ' would make the morphological analyzer see them as two separate words, changing the text's meaning. This could also affect how Text-to-Speech reads the text. Conversely, there might be cases where removing an intentional space could alter the text's semantics. -- GitHub Notification of comment by kidayasuo Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8511#issuecomment-1965844643 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
We talked about this during the JLReq TF meeting on 2024-2-27. We didn't reach a clear agreement on what should be copied; there were opinions from both sides. One concern brought up was that adding or removing spaces could change the meaning of the text. For instance, if a word contains both Kana/Kanji and Latin/Numbers, like 'Tシャツ,' inserting a space between 'T' and 'シャツ' would make the morphological analyzer see them as two separate words, changing the text's meaning. This could also affect how Text-to-Speech reads the text. Conversely, there might be cases where removing an intentional space could alter the text's semantics. -- GitHub Notification of comment by kidayasuo Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8511#issuecomment-1965844643 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
We talked about this during the JLReq TF meeting on 2024-2-27. We didn't reach a clear agreement on what should be copied; there were opinions from both sides. One concern brought up was that adding or removing spaces could change the meaning of the text. For instance, if a word contains both Kana/Kanji and Latin/Numbers, like 'Tシャツ,' inserting a space between 'T' and 'シャツ' would make the morphological analyzer see them as two separate words, changing the text's meaning. This could also affect how Text-to-Speech reads the text. Conversely, there might be cases where removing an intentional space could alter the text's semantics. -- GitHub Notification of comment by kidayasuo Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8511#issuecomment-1965844643 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> Can you give more detailed examples where vanilla CSS could have been more re-usable and modular but that this was prevented by this specific aspect of `@import`? > > I feel like there is some step or aspect that I am missing. > I don't think we can say : "tools do this, so it's needed". > I think it needs to be demonstrated on it's own why it would be useful. It is no accident! To reproduce the main problem with today's `@import`, try making `a.css`, `b.css`, and `c.css` where `b.css` depends on features (overrides things, or uses variables (in the future uses mixins and functions)) from `a.css`, and where `c.css` depends on `b.css`. Pretend these files are in a library call `css-lib` they installed locally. Now, user needs features from `b.css`, so they *should* be able to write this: ```css /*my-feature-1.css*/ @import '/node_modules/css-lib/b.css' /* override things from b, use variables from b or a */ ``` ```css /*some-page.css*/ @import './my-feature-1.css' ``` For now, it works fine. There's no problem yet. Later, the user learns that they want to use feature `c` from `css-lib`, and they try to do that in another file: ```css /*my-feature-1.css*/ @import '/node_modules/css-lib/b.css' /* override or use things from b */ ``` ```css /*my-feature-2.css*/ @import '/node_modules/css-lib/c.css' /* override or use things from c */ ``` ```css /*other-page.css*/ @import './my-feature-1.css' @import './my-feature-2.css' ``` Now what the user did not realize while trying to modularize their code is that `b.css` is loaded _twice_ due to how `@import` currently works. This causes at least one problem: If they try to use `my-feature-1.css` and `my-feature-2.css` on the same page, they'll get differing and potentially unexpected results depending on the order in which they imported `my-feature-1.css` and `my-feature-2.css`. The import of `c.css` in `my-feature-2.css` will undesirably _reset_ the overrides for `b.css` that the user defined in `my-feature-1.css`. Essentially, by writing two features, one that depended on `b`, and one that depended on `c`, and then trying to use both feaatures on the same page, the last feature *undid* the first feature! Another problem is, in order to solve the above issue, `@import` statements have to be hoisted out of the files that depend on the things they depend on. Instead, the app author has to carefully `@import` all things separately, before running `my-feature-1` and `my-feature-2`. Essentially, there's no such thing as a module *graph* that will automatically resolve dependencies and run them in order. Today's `@import` is more like a pre-processor that _includes_ the imported content inline (that's the behavior, at least, although technically at runtime there are separate sheets, but it is the behavior we're referring to). Imagine if with JavaScript modules that multiple imports of the same `b.js` file resulted in multiple executions of `b.js`. Imagine if with JS we did not get modules, but instead got `#include` which would simply include other files inline, and we'd still have to include all main scripts as non-module script tags. We'd be back in the C/C++ caves holding wooden clubs and trying to invent `#ifndef` again. Basically the ask here is to have something more aligned with modern *modules* concepts and automatic dependency graph resolution, making it possible to easily modularize code and share libraries. ----- Perhaps what we need is to start aligning with ES Modules. We already have CSS Modules. Maybe we could expand on that by adding new a new `import` feature behaves more like modules? -- GitHub Notification of comment by trusktr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6130#issuecomment-1965827281 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> Can you give more detailed examples where vanilla CSS could have been more re-usable and modular but that this was prevented by this specific aspect of `@import`? > > I feel like there is some step or aspect that I am missing. > I don't think we can say : "tools do this, so it's needed". > I think it needs to be demonstrated on it's own why it would be useful. It is no accident! To reproduce the main problem with today's `@import`, try making `a.css`, `b.css`, and `c.css` where `b.css` depends on features (overrides things, or uses variables (in the future uses mixins and functions)) from `a.css`, and where `c.css` depends on `b.css`. Pretend these files are in a library call `css-lib` they installed locally. Now, user needs features from `b.css`, so they *should* be able to write this: ```css /*my-feature-1.css*/ @import '/node_modules/css-lib/b.css' /* override things from b, use variables from b or a */ ``` ```css /*some-page.css*/ @import './my-feature-1.css' ``` For now, it works fine. There's no problem yet. Later, the user learns that they want to use feature `c` from `css-lib`, and they try to do that in another file: ```css /*my-feature-1.css*/ @import '/node_modules/css-lib/b.css' /* override or use things from b */ ``` ```css /*my-feature-2.css*/ @import '/node_modules/css-lib/c.css' /* override or use things from c */ ``` ```css /*other-page.css*/ @import './my-feature-1.css' @import './my-feature-2.css' ``` Now what the user did not realize while trying to modularize their code is that `b.css` is loaded _twice_ due to how `@import` currently works. This causes at least one problem: If they try to use `my-feature-1.css` and `my-feature-2.css` on the same page, they'll get differing and potentially unexpected results depending on the order in which they imported `my-feature-1.css` and `my-feature-2.css`. The import of `c.css` in `my-feature-2.css` will undesirably _reset_ the overrides for `b.css` that the user defined in `my-feature-1.css`. Essentially, by writing two features, one that depended on `b`, and one that depended on `c`, and then trying to use both feaatures on the same page, the last feature *undid* the first feature! Another problem is, in order to solve the above issue, `@import` statements have to be hoisted out of the files that depend on the things they depend on. Instead, the app author has to carefully `@import` all things separately, before running `my-feature-1` and `my-feature-2`. Essentially, there's no such thing as a module *graph* that will automatically resolve dependencies and run them in order. Today's `@import` is more like a pre-processor that _includes_ the imported content inline (that's the behavior, at least, although technically at runtime there are separate sheets, but it is the behavior we're referring to). Imagine if with JavaScript modules that multiple imports of the same `b.js` file resulted in multiple executions of `b.js`. Imagine if with JS we did not get modules, but instead got `#include` which would simply include other files inline, and we'd still have to include all main scripts as non-module script tags. We'd be back in the C/C++ caves holding wooden clubs and trying to invent `#ifndef` again. Basically the ask here is to have something more aligned with modern *modules* concepts and automatic dependency graph resolution, making it possible to easily modularize code and share libraries. ----- Perhaps what we need is to start aligning with ES Modules. We already have CSS Modules. Maybe we could expand on that by adding new a new `import` feature behaves more like modules? -- GitHub Notification of comment by trusktr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6130#issuecomment-1965827281 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> Can you give more detailed examples where vanilla CSS could have been more re-usable and modular but that this was prevented by this specific aspect of `@import`? > > I feel like there is some step or aspect that I am missing. > I don't think we can say : "tools do this, so it's needed". > I think it needs to be demonstrated on it's own why it would be useful. It is no accident! To reproduce the main problem with today's `@import`, try making `a.css`, `b.css`, and `c.css` where `b.css` depends on features (overrides things, or uses variables (in the future uses mixins and functions)) from `a.css`, and where `c.css` depends on `b.css`. Pretend these files are in a library call `css-lib` they installed locally. Now, user needs features from `b.css`, so they *should* be able to write this: ```css /*my-feature-1.css*/ @import '/node_modules/css-lib/b.css' /* override things from b, use variables from b or a */ ``` ```css /*some-page.css*/ @import './my-feature-1.css' ``` For now, it works fine. There's no problem yet. Later, the user learns that they want to use feature `c` from `css-lib`, and they try to do that in another file: ```css /*my-feature-1.css*/ @import '/node_modules/css-lib/b.css' /* override or use things from b */ ``` ```css /*my-feature-2.css*/ @import '/node_modules/css-lib/c.css' /* override or use things from c */ ``` ```css /*other-page.css*/ @import './my-feature-1.css' @import './my-feature-2.css' ``` Now what the user did not realize while trying to modularize their code is that `b.css` is loaded _twice_ due to how `@import` currently works. This causes at least one problem: If they try to use `my-feature-1.css` and `my-feature-2.css` on the same page, they'll get differing and potentially unexpected results depending on the order in which they imported `my-feature-1.css` and `my-feature-2.css`. The import of `c.css` in `my-feature-2.css` will undesirably _reset_ the overrides for `b.css` that the user defined in `my-feature-1.css`. Essentially, by writing two features, one that depended on `b`, and one that depended on `c`, and then trying to use both feaatures on the same page, the last feature *undid* the first feature! Another problem is, in order to solve the above issue, `@import` statements have to be hoisted out of the files that depend on the things they depend on. Instead, the app author has to carefully `@import` all things separately, before running `my-feature-1` and `my-feature-2`. Essentially, there's no such thing as a module *graph* that will automatically resolve dependencies and run them in order. Today's `@import` is more like a pre-processor that _includes_ the imported content inline (that's the behavior, at least, although technically at runtime there are separate sheets, but it is the behavior we're referring to). Imagine if with JavaScript modules that multiple imports of the same `b.js` file resulted in multiple executions of `b.js`. Imagine if with JS we did not get modules, but instead got `#include` which would simply include other files inline, and we'd still have to include all main scripts as non-module script tags. We'd be back in the C/C++ caves holding wooden clubs and trying to invent `#ifndef` again. Basically the ask here is to have something more aligned with modern *modules* concepts and automatic dependency graph resolution, making it possible to easily modularize code and share libraries. ----- Perhaps what we need is to start aligning with ES Modules. We already have CSS Modules. Maybe we could expand on that by adding new a new `import` feature behaves more like modules? -- GitHub Notification of comment by trusktr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6130#issuecomment-1965827281 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
> Can you give more detailed examples where vanilla CSS could have been more re-usable and modular but that this was prevented by this specific aspect of `@import`? > > I feel like there is some step or aspect that I am missing. > I don't think we can say : "tools do this, so it's needed". > I think it needs to be demonstrated on it's own why it would be useful. It is no accident! To reproduce the main problem with today's `@import`, try making `a.css`, `b.css`, and `c.css` where `b.css` depends on features (overrides things, or uses variables (in the future uses mixins and functions)) from `a.css`, and where `c.css` depends on `b.css`. Pretend these files are in a library call `css-lib` they installed locally. Now, user needs features from `b.css`, so they *should* be able to write this: ```css /*my-feature-1.css*/ @import '/node_modules/css-lib/b.css' /* override things from b, use variables from b or a */ ``` ```css /*some-page.css*/ @import './my-feature-1.css' ``` For now, it works fine. There's no problem yet. Later, the user learns that they want to use feature `c` from `css-lib`, and they try to do that in another file: ```css /*my-feature-1.css*/ @import '/node_modules/css-lib/b.css' /* override or use things from b */ ``` ```css /*my-feature-2.css*/ @import '/node_modules/css-lib/c.css' /* override or use things from c */ ``` ```css /*other-page.css*/ @import './my-feature-1.css' @import './my-feature-2.css' ``` Now what the user did not realize while trying to modularize their code is that `b.css` is loaded _twice_ due to how `@import` currently works. This causes at least one problem: If they try to use `my-feature-1.css` and `my-feature-2.css` on the same page, they'll get differing and potentially unexpected results depending on the order in which they imported `my-feature-1.css` and `my-feature-2.css`. The import of `c.css` in `my-feature-2.css` will undesirably _reset_ the overrides for `b.css` that the user defined in `my-feature-1.css`. Essentially, by writing two features, one that depended on `b`, and one that depended on `c`, and then trying to use both feaatures on the same page, the last feature *undid* the first feature! Another problem is, in order to solve the above issue, `@import` statements have to be hoisted out of the files that depend on the things they depend on. Instead, the app author has to carefully `@import` all things separately, before running `my-feature-1` and `my-feature-2`. Essentially, there's no such thing as a module *graph* that will automatically resolve dependencies and run them in order. Today's `@import` is more like a pre-processor that _includes_ the imported content inline (that's the behavior, at least, although technically at runtime there are separate sheets, but it is the behavior we're referring to). Imagine if with JavaScript modules that multiple imports of the same `b.js` file resulted in multiple executions of `b.js`. Imagine if with JS we did not get modules, but instead got `#include` which would simply include other files inline, and we'd still have to include all main scripts as non-module script tags. We'd be back in the C/C++ caves holding wooden clubs and trying to invent `#ifndef` again. Basically the ask here is to have something more aligned with modern *modules* concepts and automatic dependency graph resolution, making it possible to easily modularize code and share libraries. ----- Perhaps what we need is to start aligning with ES Modules. We already have CSS Modules. Maybe we could expand on that by adding new a new `import` feature behaves more like modules? -- GitHub Notification of comment by trusktr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6130#issuecomment-1965827281 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Clqsin45 has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-inline-3] Question about the relationship among `text-box-trim`, `text-box-edge` and `text-line-edge`. == Hi CSS specification authors! I'm trying to implemente these properties. Reading https://github.com/w3c/csswg-drafts/issues/8829#issuecomment-1699500216, I have this question in my mind. Since the specification is not updated yet, may I ask some quick questions to unblock my implementation work? My question might be: In the case below, how should I trim the box? ``` <div style=”text-box-trim: ? text-box-edge: leading”> <span>TEXT</span> </div> ``` The div tag wants to trim the half leading, while the span does not do so. In this case, should the box of <div> be trimmed to respect text-box-trim/text-box-edge’s value (like A)? Or should it not be trimmed to respect its inline text’s style( as B)? ![Capture](https://github.com/w3c/csswg-drafts/assets/13186278/16cea43c-3251-47b0-9899-6e1735631637) (Sorry I'm very new to this world. if I asked an unclear question, please let me know!) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10007 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Clqsin45 has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-inline-3] Question about the relationship among `text-box-trim`, `text-box-edge` and `text-line-edge`. == Hi CSS specification authors! I'm trying to implemente these properties. Reading https://github.com/w3c/csswg-drafts/issues/8829#issuecomment-1699500216, I have this question in my mind. Since the specification is not updated yet, may I ask some quick questions to unblock my implementation work? My question might be: In the case below, how should I trim the box? ``` <div style=”text-box-trim: ? text-box-edge: leading”> <span>TEXT</span> </div> ``` The div tag wants to trim the half leading, while the span does not do so. In this case, should the box of <div> be trimmed to respect text-box-trim/text-box-edge’s value (like A)? Or should it not be trimmed to respect its inline text’s style( as B)? ![Capture](https://github.com/w3c/csswg-drafts/assets/13186278/16cea43c-3251-47b0-9899-6e1735631637) (Sorry I'm very new to this world. if I asked an unclear question, please let me know!) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10007 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Clqsin45 has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-inline-3] Question about the relationship among `text-box-trim`, `text-box-edge` and `text-line-edge`. == Hi CSS specification authors! I'm trying to implemente these properties. Reading https://github.com/w3c/csswg-drafts/issues/8829#issuecomment-1699500216, I have this question in my mind. Since the specification is not updated yet, may I ask some quick questions to unblock my implementation work? My question might be: In the case below, how should I trim the box? ``` <div style=”text-box-trim: ? text-box-edge: leading”> <span>TEXT</span> </div> ``` The div tag wants to trim the half leading, while the span does not do so. In this case, should the box of <div> be trimmed to respect text-box-trim/text-box-edge’s value (like A)? Or should it not be trimmed to respect its inline text’s style( as B)? ![Capture](https://github.com/w3c/csswg-drafts/assets/13186278/16cea43c-3251-47b0-9899-6e1735631637) (Sorry I'm very new to this world. if I asked an unclear question, please let me know!) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10007 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Clqsin45 has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-inline-3] Question about the relationship among `text-box-trim`, `text-box-edge` and `text-line-edge`. == Hi CSS specification authors! I'm trying to implemente these properties. Reading https://github.com/w3c/csswg-drafts/issues/8829#issuecomment-1699500216, I have this question in my mind. Since the specification is not updated yet, may I ask some quick questions to unblock my implementation work? My question might be: In the case below, how should I trim the box? ``` <div style=”text-box-trim: ? text-box-edge: leading”> <span>TEXT</span> </div> ``` The div tag wants to trim the half leading, while the span does not do so. In this case, should the box of <div> be trimmed to respect text-box-trim/text-box-edge’s value (like A)? Or should it not be trimmed to respect its inline text’s style( as B)? ![Capture](https://github.com/w3c/csswg-drafts/assets/13186278/16cea43c-3251-47b0-9899-6e1735631637) (Sorry I'm very new to this world. if I asked an unclear question, please let me know!) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10007 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
sorvell has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-mixins] Allow mixins/functions to be called via custom properties == Allow functions and mixins to be called via custom properties to support some additional interesting use cases. The syntax in the [current proposal](https://github.com/w3c/csswg-drafts/issues/9350) seems like it might need a little tweaking to support this. Here's a rough sketch that needs a lot more fleshing out if this idea doesn't have some obvious fatal flaw. **Basic Idea** Introduce a way to "call" mixins/functions, say, using a built-in function called `call` that accepts `var`: ```css @mixin --hover-focus(--hover; --focus;) { &:hover { @apply call(var(--hover), 2); } &:focus { @apply call(var(--focus), 4; } } @function --shadow(--x: 0; --y: 0; --color: black; --calc-blur;) { @return var(--x) var(--y) call(var(--calc-blur, --x, --y)) var(--color); } ``` **Use Cases** * more robust composition of effects (the contrived examples above hint at this). * passing nested content to mixins as [noted in the explainer](https://css.oddbird.net/sasslike/mixins-functions/#passing-nested-content-to-mixins). * as custom properties, mixins and functions could inherit down the tree to be applied elsewhere in the DOM, even cross-scope in Shadow DOM. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10006 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config