Comments (8)
I just responded about the all
option in #626 (comment) ; I don't think that would be sufficient.
I think as far as browser engine developers go, I think I lean towards being willing to try to make changes that might cause small amounts of broken content. However, I think this is way past where I'm willing to go in terms of breaking content, because given the number of problems I saw on top site homepages I suspect there's going to be a large number of sites broken in various ways through the long tail of web content. I think the CSS WG has had extended discussions of compatibility problems whose effects were at least a hundred times smaller than this. I also think parts of a page moving around that the author didn't intend to animate can substantively affect usability and accessibility, and is more significant than "doesn't break actual readability".
from csswg-drafts.
The reason I didn't want to do it this way is described in #10294 (comment) and in #10294 (comment)
from csswg-drafts.
(I'm aware we don't have animation-behavior
but perhaps it's a good time to add one, I believe @LeaVerou suggested it on a different issue)
from csswg-drafts.
This is the current spec for interpolate-size: https://drafts.csswg.org/css-values-5/#interpolate-size
from csswg-drafts.
Hmm, ok. How about size-interpolation
to match color-interpolation
? Just finding ways to make it consistent with the rest of CSS
from csswg-drafts.
There is the open issue of how we set color interpolation space, perhaps we could combine these? E.g. interpolation-settings
or something?
from csswg-drafts.
@nt1m size-interpolation
was one of the two proposals I used to start the discussion of bikeshedding the name -- so I would have been fine with it (particularly if it were the original decision rather than a later revisit), but the discussion at the face-to-face (minutes at #10294 (comment)) moved away from that suggestion.
@LeaVerou I don't want to combine it with something that people actually want to change, because this is designed to be a compatibility opt-in for something that we'd prefer to make the default but can't because of compatibility. It's something you should be able to set once on the root to opt in to the "correct" behavior and then never touch again. If we combine it with something else then people need to remember to re-state that opt-in at each use. See the minutes in #10294 (comment) (and some of the prior comments) for some discussion of this.
from csswg-drafts.
@nt1m
size-interpolation
was one of the two proposals I used to start the discussion of bikeshedding the name -- so I would have been fine with it (particularly if it were the original decision rather than a later revisit), but the discussion at the face-to-face (minutes at #10294 (comment)) moved away from that suggestion.@LeaVerou I don't want to combine it with something that people actually want to change, because this is designed to be a compatibility opt-in for something that we'd prefer to make the default but can't because of compatibility. It's something you should be able to set once on the root to opt in to the "correct" behavior and then never touch again. If we combine it with something else then people need to remember to re-state that opt-in at each use. See the minutes in #10294 (comment) (and some of the prior comments) for some discussion of this.
To re-iterate the feedback we gave in this feature’s TAG review, given that the result of the change is a slight glitch that doesn’t break actual readability, I think we should reconsider simply making the change rather than introducing these awkward opt-ins, or at least digging more into the data to get a fuller picture of the compat implications. We should not be introducing warts into the language simply to avoid examining the compat implications fully or just to be conservative, but when the impact of the wart on authors is genuinely smaller than the impact of the compat implications.
Or perhaps we can introduce certain restrictions that serve use cases while minimizing breakage. E.g. I wonder if it would be more web-compatible to only transition between these values when a width
/height
transition is explicitly requested, rather than when implicitly included via all
(either explicit or omitted).
from csswg-drafts.
Related Issues (20)
- [scroll-animations-1][css-animations-1] A non-animated "Is in viewport" HOT 4
- [css-ui-4] Add `outline-offset-(inline|block)[-(start|end)]`
- [css-view-transitions-2] Capture modes HOT 1
- [css-view-transitions-1] Consider a wider margin from viewport than 0 for offscreen elements
- [css-tables] block size distribution to table sections not interoperable
- [css-tables] Distribution of block size to table sections not interoperable. HOT 4
- [css-scrollbars] Scrollbar Hover/Interaction Colors HOT 3
- [css-values-5] Boolean values in CSS custom properties
- [css-values-5] Proposal for a new `matches()` CSS Function HOT 1
- [css-backgrounds-3] Does `background-attachment: fixed` work with `background-clip: text`? HOT 2
- [css-fonts] Support avar2 within tech() to support using the next generation of variable fonts tech HOT 2
- [css-sizing-3][css-sizing-4] Move `fit-content` keyword to Level 3 and `fit-content()` function to Level 4
- [css-sizing-4]: Minor fix: incorrect wpt.fyi link HOT 1
- [css-sizing] Intrinsic size of <img> / <video> with aspect ratio but no definite size HOT 4
- [css-view-transitions-2] CSSRule interface should not be extended HOT 1
- [css-fonts] Specify `generic()` versions of existing generic font families
- [css-view-transitions] view transitions to customize the appearance of entering/exiting fullscreen? HOT 4
- [css-position] Feature:Stackable Headers/Footers position: [sticky or absolute], stack header items, z-index:(integer), insert prop[top,left, bottom, right]:auto; display:block;
- [css-conditional-3] Stylesheet attached to a document isn't a well-defined concept right now.
- [css-conditional-3] Missing WPT tests
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from csswg-drafts.