- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 10 Sep 2023 11:49:32 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Transitions
---------------
- RESOLVED: Add transition-behavior longhand, list valued part of
transition shorthand, with normal | allow-discrete values
(to start) (Issue #8857: Put discrete transitions behind
new syntax for compatibility)
CSS Animations
--------------
- RESOLVED: Add a new syntax for the animation shorthand where the
animation-name comes first, followed by a slash, so that
the new syntax (but not the old one) can accept
animation-timeline and animation-composition in the
shorthand. Work out further details in issue. (Issue
#6946: Make animation shorthand syntax future-proof)
Revisiting standardization of the `zoom` property
-------------------------------------------------
- RESOLVED: Add "zoom" as a real interoperable thing (Issue #5623)
- RESOLVED: Add the zoom property to the device adaptation / viewport
spec (Issue #5623)
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/38
Scribe: dbaron
CSS Transitions
===============
Put discrete transitions behind new syntax for compatibility
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8857
flackr: We previously discussed that supporting discrete transitions
had compat issues.
flackr: We resolved we need a way to opt in.
flackr: We had the open question of what the properties would be and
how to apply them.
flackr: We now have a proposal
flackr: There's a poll with a decent number of responses
<jarhar> vote with list of names here:
https://github.com/w3c/csswg-drafts/issues/8857#issuecomment-1591335579
flackr: We add a new property: transition-animation-type: normal |
animatable
flackr: normal is the current behavior
flackr: animitable allows transitions on discretely animatable
property
flackr: It's another part of the transition shorthand, auto-extends
jarhar: As Mason ??? we resolved on a longhand that's connected to
the transition shorthand, we just need to choose a name.
fremy: A question: what is the value of the animatable keyword? If
you specify display, obviously you want it to be animated...
fremy: if I understand correctly, maybe I don't ... if you say
'transition: display 2s' it won't work. If so, why?
fremy: If you explicitly say `display` that means you want it?
flackr: That's correct. Reason not to default to that behavior is
there are some properties like left or width where there are
auto values that currently do not create transitions when you
change values between a specified value and auto.
flackr: Making this suddenly start discrete transitions breaks many
existing sites.
flackr: We're trying to avoid this.
flackr: What I'm hearing from your question the animation type should
be smarter and for properties that are *only* discrete, being
specified in transition-property should make them transition.
fremy: I think it's unfortunate that for `display` you have to add
this keyword, but I now understand the need for some other
properties.
fantasai: Sorry for not looking at this earlier... the property name
seem mostly fine.
fantasai: If you just use the longhand the values may also be fine
fantasai: but in the shorthand it's vague what `normal` might be
referring to.
fantasai: Since not that common you'd want to set, maybe make clearer
when it's in the shorthand
flackr: Maybe 'interpolable'... but given that it's the initial value
you don't have to specify it.
fantasai: I might do interpolable | animatable since then the
contrast is clearer. And since you don't have to type it in
the normal case it's fine to be long. Makes it clearer what
we're switching between.
flackr: Makes sense
flackr: One downside I can see of this if if we want to support
transitions to/from 'auto' that are interporable in the
future, this would no longer make sense as a way to opt out
of that new behavior
fantasai: Good point
fremy: This would also be more descriptive, like 'allow-discrete'
dbaron: One argument for normal is that we need the backwards
compatible behavior across multiple changes
dbaron: There is probably going to be more than one change we will
want to do later
chrishtr: Is that predicting, or we know of one?
flackr: Yes, the behavior of to/from auto, we'd like to use this for
a compatibility switch for that behavior in the future as well
flackr: I think in the future 'interopolable' doesn't make sense
for that.
<TabAtkins> I think "normal" is probably okay. "normal color" sounds
weird but there's not really any reason to specify it.
<TabAtkins> and then I really prefer "discrete" for the other value
fantasai: That logic makes sense to me... main concern if there's
another longhand where 'normal' is the desirable initial
value.
<TabAtkins> but I'm gonna hard-veto "interpolable" for spelling
complexity reasons
astearns: Maybe one resolution to have a longhand with an initial
value of 'normal', and then discuss the other value we're
adding today?
SebastianZ: How will we interact with 'auto' when you've been
transitionable in the future? Should that be part of
'normal' later, or a new keyword?
jarhar: The idea of ???. Many pages already have transitions of top,
so animating between auto and 100px is something we want to
not animate by default. We need that to be an opt-in. We
could make it happen when you say animatable, or add a third
thing.
flackr: We could add the interpolable behavior later if we felt need
to distinguish between that behavior and discrete animations.
<TabAtkins> Yeah `transition-allow` sounds reasonable I think
<TabAtkins> it'll work for the next value we want to add too
<TabAtkins> so I support `transition-allow: normal | discrete`
fantasai: We're possibly looking at 4... or 3 (flackr; 3) keyword
values.
fantasai: Current behavior, incorporating discrete animations, and
third is allowing things that are currently discrete and
allowing them to be interpolated continuously.
fantasai: Initial value is... the first one.
fantasai: It would be nice if we picked a set of 3 keywords that are
distinguishable, rather than picking 2 and possibly ending
up with an awkward situation with the third one that we
already know we'd like to add.
fantasai: So 'animatable' wouldn't cover animate keywords as
continuous.
flackr: Right, it covers doing anything you can use in animations
which is discrete and continuous.
fantasai: I don't love 'transition-animation-type' because it's 3
segments but really 2 segments... would 'transition-allow'
be reasonable?
fantasai: Does that give us a different perspective on keywords we
might want?
fremy: I guess since it's not a keyword... I like it being shorter,
but feel like it's misleading. If you write 'discrete color'
you're not going to get a discrete transition, which feels
confusing.
fremy: In the shorthand, which is what people are going use most of
the time, I think people will not get what they expect with
'transition: discrete color'
<fantasai> transition-allow: normal | [ continuous || discrete ||
interpolate-keywords ]
<fantasai> Not exactly but maybe something like that...
TabAtkins: Mainly a response to fremy -- allow makes things clearer
-- we have made adjustments for this context before -- we
have made specialized keywords that are allowed in the
shorthand only.
TabAtkins: shorthand could recognize allow-normal and allow-discrete,
turns into normal and discrete in the longhand.
fremy: The other one is that it sounds to me that it should be
possible to have >1 of these things that you allow, e.g.,
'allow-discrete' combined with new behavior for auto -- in
that case you will have confusing shorthand. In that case it
will lose meaning a bit.
<astearns> transition-capabilities: normal | [ allow-continuous ||
allow-discrete || allow-keywords ]
fremy: in the shorthand difficult to read, esp. with >1 keyword
fremy: Could do a function allow() with list of behaviors
fremy: or whatever Alan is writing
dbaron: I was gonna suggest something like Tab said
dbaron: just make the values allow-discrete, at least, without a
distinction between the shorthand/longhand
dbaron: we can have transition-allow: allow-discrete
dbaron: it's a bit verbose in the longhand but if everyone's using
the shorthand it's okay
dbaron: other thought, the other compat thing we know we want to do
maybe isn't allow-*
dbaron: I think the thing with animating auto values isn't as much
about allowing as about changing what they do
dbaron: so maybe that one shouldn't be allow-*
<flackr> +1 it's about changing the interpolation
dbaron: so maybe name the property something else, but do still call
the value allow-discrete
dbaron: and maybe another two-word name for the "transition from
auto" behavior
<fantasai> transition-ability seems easier than transition-capability
<TabAtkins> (that sounds good)
<TabAtkins> (and yes, transition-ability)
SebastianZ: I want to iterate on what dbaron just said: I like the
idea of putting allow- in values rather than property. We
could have transition-type: allow-* or allow-all
fantasai: Maybe traction on transition-ability
jarhar: future value could be allow-mixed
flackr: I think the point is that it's not about allowing something
but about changing interpolation between auto and specified
values
dbaron: I'd point out that the future thing would also want to do
things like numeric interpolation between auto / min-content
/ fit-content etc., which isn't actually mixed
<fantasai> interpolate-keyword-lengths
<flackr> or interpolate-used-values ?
<TabAtkins> yeah it's final values
<fantasai> transition-ability: allow-discrete
interpolate-keyword-lengths
fremy: A question about that: is it about interpolating keywords or
about interpolating the final value -- you may use the keyword
within complex expressions. Authors want the property to
remember the previous value and interpolate from that... but
maybe not relevant to the discussion.
astearns: Could we resolve on transition-ability with values that
will work in the shorthand?
<fantasai> +1
flackr: You don't need to specify the initial value in the shorthand
because it's the initial value, so we really only need the
value for allow-discrete
<fremy> +1
astearns: Is allow-discrete the first value we would add to this?
<TabAtkins> transition-ability: normal | allow-discrete
astearns: my proposed resolution is: ^
<fantasai> sgtm
dbaron: I'm a little hesitant about transition-ability
astearns: It has the transition- because it's a longhand, but I'm not
sure I have a better idea.
?: -capability
fremy: But people aren't going to type it.
<flackr> transition-interpolation
dbaron: There were some other suggestions in the issue
dbaron: Maybe transition-behavior ?
fantasai: transition-interpolation doesn't work for allow-discrete
because it doesn't change how you interpolate, changes
whether you transition at all
flackr: That's... fine... though not changing how you interpolate.
<chrishtr> transition-behavior: normal | allow-discrete
flackr: I don't think it's necessarily wrong.
flackr: Transitions don't currently allow discrete interpolations.
<chrishtr> transition-allowed: normal | discrete ?
astearns: Trying to be a sober adult... I think I agree with dbaron
that transition-ability has an issue.
<emilio> `transition-tweaks` or so?
TabAtkins: Just don't pay attention to the pun. It works
fantasai: "transition ability" -> "transition-ability
astearns: For the people who think there's an issue with
transition-ability, is there a single alternative that
sounds better?
<flackr> Maybe transition-trigger or transition-change ?
flackr: I put some in the IRC. (^^)
fantasai: Some values are about how it transitions, some are about
whether it transitions. So has to accommodate both.
<fremy> transition-behavior sounds fine, really
dbaron: That's why I liked transition-behavior.
iank: Don't we already have... overscroll-behavior.
chrishtr: poll between those 2 options?
astearns: option 1: transition-ability; option 2: transition-behavior
<emilio> 2
<miriam> 2
<flackr> 2
<SebastianZ> 2
<astearns> 2
<chrishtr> 2
<TabAtkins> 2
<fantasai> 1 !!!!
<jarhar> 2
<dbaron> 2
<fremy> 2, weakly
<ydaniv> 1
<iank> 2
<changseok> 2
<dholbert> 2
<bts> 1
<Rossen> 2
<rachelandrew> 2
<bramus> 2
astearns: Proposed resolution: add transition-behavior longhand with
normal | allow-discrete values to start.
flackr: Specifically with list values that match transition list.
fantasai: I think ability is a better word than behavior.
<chrishtr> resolution as stated sgtm!
<ydaniv> +1 to fantasai on that last note
fantasai: I still disagree, but not objecting.
RESOLVED: Add transition-behavior longhand, list valued part of
transition shorthand, with normal | allow-discrete values
(to start)
CSS Animations
==============
Make animation shorthand syntax future-proof
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6946
SebastianZ: There are multiple additions -- new longhands -- to
animation. Starting to collide because data types are the
same.
SebastianZ: I was proposing to have a new syntax that avoids
collisions.
SebastianZ: collisions between those additions.
SebastianZ: I had different proposals on how to solve that.
SebastianZ: I think we already had a resolution to reset new
properties that are added but if we want to add new ones
to the shorthand we should discuss how to do that.
SebastianZ: One proposal by me was to animation-name
animation-timeline are colliding now.
flackr: Is there a proposal?
SebastianZ: Proposal is to change syntax or use a new syntax that
avoids issues with additions to the shorthand.
SebastianZ: so if we want to include animation-timeline in the
shorthand, we have to find a way to do it so it doesn't
collide with animation-name.
SebastianZ: I don't remember what other longhand was added, but there
was another one that collided with animation-name
SebastianZ: So we have to find a way how to include them without any
ambiguities.
SebastianZ: my proposal was to add slashes between them.
<ydaniv> animation-range, maybe?
flackr: We already have ambiguity with anything that specifies time
values -- they're positional. It's an option but not a great
option. Other option that's come up in the past was having
functional notation like timeline(timeline-name), which I
think makes it clearer what's going on.
<fremy> +1 to what flackr said
<TabAtkins> my earlier proposal was `animation-name / <all other
stuff>`
<TabAtkins> and if you didn't have the slash it reset all the new
properties
astearns: Something we could do in general for shorthands that could
have ambiguities is to decide whether we go with slashes or
with bracketed named sections of the shorthand value.
SebastianZ: Ideally we'd find a solution that's broader than just the
animation shorthand
SebastianZ: It could be something other than slashes like functions
or something else.
dbaron: Two things
dbaron: Generally pretty positive about functions
dbaron: Also, one reason we have difficult here is animation-name
property accepts arbitrary custom-idents, not --prefixed
dbaron: which we now decide is a bad practice
dbaron: if we followed current best practices we'd have required
keyframes to establish --prefix names
SebastianZ: even with -- there would be collisions between name and
timeline both having dashes
TabAtkins: Other mistake with animation -- custom idents should be
positionally unambiguous. Custom ident should have been
required to be first in the shorthand.
TabAtkins: It's usually what authors write anyway. That we have to
serialize the animation name last for these weird parsing
reasons looks weird.
TabAtkins: That's why my suggestion was ...
<TabAtkins> That's why my suggestion was for "name / other stuff",
that way the name comes first, where it belongs
<fantasai> +1 that seems nice
<ydaniv> +1
<flackr> +1 name / other stuff seems good to unblock adding things
astearns: What will we do for adding animation-timeline to the
shorthand?
TabAtkins: We need to decide on one of the ways
SebastianZ: Proposals were (1) adding slashes (2) positional stuff or
(3) adding functions
<fantasai> strongly in favor of (1)
astearns: Given we're already in a bad situation with animation-name
that can be anywhere I think we're limited to functional
TabAtkins: No,... we could have a grammar fork. If you do name/stuff
you can write a timeline name, otherwise you can't express
timeline name in the shorthand. So all of them are
compatible.
<fremy> slash is very unclear
<fantasai> positional is hard
<fantasai> and really dislike introducing functional notations for a
shorthand, we don't do that anywhere else
<TabAtkins> we use / for positional separation in several properties
<TabAtkins> like it's not *great* but
fantasai: I think hard to remember order required for positional
things. We generally try to allow reordering.
fantasai: using functional notation just to work around a shorthand
thing, we don't do anywhere. Not pleasant to type. We use
slashes in a bunch of places for syntactic ambiguity.
fantasai: It's not amazing working with syntax in that way... we have
to serialize the older things as older things for compat,
but you can express any past/future possibilities as input
using the new less confusing syntax.
fremy: I want to disagree that we never use functions for that. We do
quite often. We have counter() that takes a name. If you want
to ??? you can use a counter() function.
fantasai: counter() functions are different, you're processing the
counter name and returning the result. It's actually a
function, not something to disambiguate.
fantasai: ... tagging values with function names is not a CSS pattern.
<fremy> https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Functions#animation_functions
flackr: I'm good with / being used to remove challenges with
animation-name. But this only allows us to add one name
before we can add positional stuff again.
flackr: We'll have the problem that the first dashed-ident after the
slash is the timeline name, and the next thing that needs a
name will be the second one.
SebastianZ: I think there was another longhand discussed to add to
the shorthand as well... I think we're already in that
situation.
SebastianZ: for 'animation'. I think animation-composition.
<TabAtkins> this is true, yeah
<TabAtkins> we could *also* use the "keyword prefix" approach for the
timeline name
<TabAtkins> so you'd say `timeline <name>` in the shorthand
<TabAtkins> then that's extendable for the future
TabAtkins: If we want to future proof against adding more names, we
could use a keyword prefix rather than a function wrapper.
I think we have used this before. `timeline <name>`. That
extends into the future.
TabAtkins: We could add more names in the future with similar
prefixes.
TabAtkins: We still have to solve the animation-name thing separately.
flackr: I wasn't specific that it should be functions, keyword
prefixes are great too.
astearns: timeline <name> without the slash means you could put the
animation-name anywhere you wanted
dbaron: Unless the animation-name is timeline
TabAtkins: The current prefix tagging is inside functional syntaxes,
not in a top level property value.
fremy: I'm still reading the timeline thing ... the timeline property
already accepts scroll() and view() functions.
fremy: Can we not fixed that one? animation-timeline takes a
timeline() function and then you don't nee a timeline prefix
because the animation-timeline property takes a function all
the time.
fremy: not sure if this is already shipped
flackr: Would be hard to change existing animation-timeline property
to require that, but could make it always show up that way in
the shorthand
fantasai: But do you then put timeline(scroll(...)) in the shorthand?
flackr: I don't think so.
fantasai: It seems like the logical conclusion but it's really awful.
flackr: The idea that if you specify a name in the
animation-timeline, it's implicitly timeline(<name>), the
other values are just scroll() and view() functions.
astearns: You could put a name in the longhand, but if you want to
specify it in the shorthand you'd need to wrap in a
function -- that discontinuity is not great.
SebastianZ: I agree with fantasai that this would be something new.
SebastianZ: we do have the scroll() and view() function but they just
refer to something.
SebastianZ: we still have the timeline name they are referring to.
SebastianZ: Introducing a function that directly reflects the
property would be something new to CSS.
<fantasai> note that the functional keyword disambiguator pattern
tends to use prepositions so it'd be something like "on
<timeline>" if we follow that pattern
SebastianZ: On the other hand, regarding / syntax, we are already
saying this could lead to issues. I was just thinking
about that again.
SebastianZ: what if you want to set one of these longhand properties
but not the other ones?
SebastianZ: that would be a bit hard with the slashes
fantasai: What?
SebastianZ: The animation-composition is the other issue we have
SebastianZ: If you want to set animation-composition but not the
animation-timeline
[some confusion]
<flackr> animation: foo / add; would be valid
fantasai: Going forward the new syntax would require the animation
name first, and have to follow it with a slash, and then
after that there's no animation-name so there's no name
clashes.
fantasai: We just need to avoid conflicts between the keywords going
forward.
fantasai: We try to minimize positional-ness within a shorthand.
fantasai: Positional relationships are hard to remember
fantasai: Going forward, put an effort into choosing keywords that
don't clash, then we don't run into ambiguity.
SebastianZ: animation-timeline only allows dashed idents?
fantasai: dashed idents and none?
fremy: and auto
SebastianZ: There could still be clashes between new keywords that
get added?
TabAtkins: but that's the initial value
SebastianZ: So if we have a new animation-timeline keyword, and have
animation-composition as well.
<fremy> `auto` is going to be very popular...
fantasai: We can try to avoid clashes. Making everything positional
all the time, or wrapping everything in functions, is not
friendly to authors.
astearns: I think we need to wrap up.
astearns: Can we resolve on: allow animation-timeline into the
shorthand by adding a / after the animation-name
astearns: if people aren't happy with that today, we could hash out
more in the issues
SebastianZ: animation-timeline plus animation-composition
fantasai: Yeah, all the new stuff
flackr: animation-timeline takes an auto value, conflicts with
duration
flackr: It's already the case that we have some overlapping values
and we choose them positionally.
flackr: auto is going to be ambiguous with duration
fantasai: Could say you can't specify auto in the shorthand, and if
you ??/ drop it
dbaron: other thing we do, but it's slightly more complicated in
parsing
dbaron: you can buffer having an auto value
dbaron: see an auto value, say it can be a value for either of these
two properties and keep looking
dbaron: assign auto for the one that isn't assigned
dbaron: by another keyword
dbaron: it's done in other places
dbaron: a little bit of a pain for implementers, but not too hard
dbaron: and is friendly to authors
<TabAtkins> list-style is the example we do today
(ntim asked about list style)
astearns: Can we add / to shorthand to accommodate new longhands, and
then hammer out details for things we discovered today?
<fantasai> sgtm
flackr: Sounds good to me
RESOLVED: Add a new syntax for the animation shorthand where the
animation-name comes first, followed by a slash, so that
the new syntax (but not the old one) can accept
animation-timeline and animation-composition in the
shorthand. Work out further details in issue.
<fantasai> also +1 to dbaron's solution to 'auto'
Revisiting standardization of the `zoom` property
=================================================
scribe: myles
github: https://github.com/w3c/csswg-drafts/issues/5623
chrishtr: Following the previous resolution to not standardize css
zoom, but instead try to remove it from chrome and webkit,
chrishtr sent the intent to remove, gathered feedback, and
got use-cases. Use-counter, chromestatus...
chrishtr: reaching out to microsoft office and google docs
chrishtr: The results are: it is, in fact, used if you go the menu in
excel, and change the zoom, it uses the zoom css property
on a parent element on all of the things in the
spreadsheet. The equivalent thing in google sheets changes
the inline styles of the elements to make them bigger by a
specified factor
chrishtr: Microsoft says it's possible to migrate away, but it's a
lot of work
<Rossen> One clarification about Microsoft Excel position - besides
the work the main objection and concern is driven by
undesirable performance degradation
chrishtr: Gmail has another case where html emails are not usually
responsive. If an email has a width of x pixels that's
wider than the width of your phone, the options are for the
webview to show horizontal scrollbars, or make content
smaller. The horizontal scrollbars is a bad, so making the
content smaller is better (you can see the whole
conversation in a single vertical swipe)
chrishtr: They render it, measure it, then apply zoom to shrink it
down. Zoom works better than transform. Zoom already has
responsive design concepts - all it's doing is multiplying
CSS numbers by something, and letting the usual block flow
(flexbox, etc.) work. Adjacent elements outside the zoom
but next to it will do the right thing. Inside it, relative
sizing generally works
chrishtr: It just happens as a natural course of things
chrishtr: A third use case on Gmail desktop - you can create
templated emails. There's a wizard that allows you to
choose which template you want. On the right it shows a
preview. The preview has external HTML that displays it,
and they shrink it down to fit on the screen. That probably
could be done with transform, but it's hard to get right.
But it's trivial with CSS zoom because it naturally fits
existing responsive design concepts of the web
chrishtr: The chrome use counter is high in general which is
concerning. In other sites, there aren't many where
removing zoom substantially messes up the site
<fantasai> hack for layout? what does it mean?
chrishtr: There are some that get a little worse, but not that bad.
Gmail and Excel were the ones that were most problematic
chrishtr: I found examples of an a11y widget within the page where
you press a button to make content bigger, and they don't
use iframes, but instead use inline html
chrishtr: For implementation notes, some of the comments earlier in
the issue said that emilio mentioned it would be
complicated. The implementation in chromium isn't very
complicated. I could be wrong though. At the used style
time, it multiplies all the non-percentage lengths by a
number. Also, this is how browser zoom is implemented on
desktop with command-plus and command-minus. That works
well for arbitrary pages which haven't put any thought into
supporting this, because responsive design that exists
already makes that easy to do
chrishtr: as far as I can tell even if you just put it on the root
and it propagates to sub elements (e.g. gmail preview thing)
chrishtr: All the JS APIs is pretty weird. getBoundginClientRects()
is goofy - the values are divided for no good reason. It's
so that there can be a round-trip in/out of the style
sheet. BUT I have no evidence that any sites actually care
about these javascript APIs. Sites really just want the
visual output to be bigger or smaller so people can see it,
rather than running JS to inspect it
chrishtr: We should standardize this feature. It achieves compelling
use cases. A11y of external content that naturally fits
within existing responsive design features of the web. If
you use transform, there are tricks and it's difficult to
get right in non-simple situations
astearns: The fixes you'd apply are just around the JS APIs that give
you layout results?
chrishtr: Exactly. yes
chrishtr: I didn't find anything wrong with the way it works visually
flackr: Multi-layout applications lay out, calculate the zoom, then
apply it. That sounds like overflow. Do we need overflow:zoom
that automatically does this?
flackr: The zoom property doesn't accumulate the ancestor zoom; it
gets clobbered. So how does this interact with browser zoom?
It's supposed to stack
chrishtr: For the first, it could be useful to explore. "Fit this
content within its container, and enforce it by zooming it
so it fits" Gmail probably wants it. This has probably been
considered before
chrishtr: I did verify 2 days ago that it does multiply and does more
zooming on top
Rossen: That is correct. Let's say you have a couple of containers
that are all 100px wide by specified width, and you apply
zoom:2 on both of them. ..... <loses steam> I am with
chrishtr on this - the values should multiply
<astearns> sounds like Rossen is implying that nested zooming uses
'special' math
Rossen: In your example, if the browser sets zoom:200 and there is a
widget that is internally zooming, the contents of the widget
will be 2x what it would be if the browser's zoom didn't exist
flackr: I know I saw a case where this wasn't true, but maybe it was
with frames?
Rossen: Yes, or maybe auto or percentage
chrishtr: I think it makes sense not to multiply percentage widths.
That has better responsive design results.
chrishtr: My evidence: That's what browser zoom does and people seem
to like it
emilio: You mentioned not all engines support browser zoom like this.
In gecko, this is a different CSS to device pixel ratio
emilio: I have a couple questions, but they are more implementation
related
emilio: I'm not sure how you fix the JS APIs. Depending on what you
want, if you want the zoomed or unzoomed value, you want the
stuff to round-trip, so from the point of view of the element
you're querying, you want the zoomed thing, but from the
point of view of stuff outside of that, you want the unzoomed
thing. I don't know how to fix that. I don't see how can you
accumulate those use cases
emilio: I had another question about calc() like if you have mixed
lengths and percentages... my understanding is that zoom
works at computed value time, not used value type. So it
interacts with getComputedStyle().
<TabAtkins> I was also going to ask about calc()
emilio: I think that's weird for inheritance. But I'd need to think
more about it. If you inherit an explicit width, but you also
have zoom:2, do you get 2x the width? Probably "no" but maybe?
iank: For lengths, if you've got a simple calc (Apx + B%) it will
scale A but not B
iank: And it can be more complex too
chrishtr: Right. emilio, you mentioned the gecko implementation is to
make all CSS values bigger...
emilio: Not quite
emilio: The behavior is similar to what the zoom property does, but
basically when you convert CSS pixels to device pixels -
after resolving percentages - that scales different depending
on the browser zoom value
emilio: That's the browser zoom, not the zoom property
iank: In gecko's behavior, it applies to the whole page - it can't
apply to a subtree
emilio: Which makes sense - it doesn't make sense to change the
meaning of a CSS pixel in the middle of an element
chrishtr: As far as I can tell what you just described is equivalent
to having set zoom: on the HTML element
chrishtr: and then changing the width of the viewport to be divided
accordingly
chrishtr: So you get text to flow around
fantasai: Well, gecko's browser zoom won't affect any JS APIs
chrishtr: Browser zoom in chromium also doesn't affect APIs except
the client width of the viewport is reduced by the
appropriate amount. Which is probably the case in gecko
because otherwise text will overflow
emilio: That's not a special case - the viewport is a fixed amount of
device pixels wide. This just picks a different value
chrishtr: The visual behavior users see, and the JS APIs, are exactly
the same for both browsers
emilio: Didn't you mention that the browser internal zoom cannot
behave like CSS zoom exactly. Because if you divide by zoom,
getBoundingClientRect would be affected
iank: I think this is why everything gets unzoomed on the way out.
Using offsets
iank: that makes those cases nonexistent
emilio: That only works if the zoom is applied to the root element
chrishtr: Right. As applied to the root element, I think the behavior
is the same
iank: There are some subtle inconsistencies. Firefox can make up
fractional pixels on the viewport.
emilio: Sure, possibly
fantasai: What's the computed value of zoom if you have nested zooms?
chrishtr: The zoom of yourself (unmultiplied)
<flackr> Yes it was frames where I saw zoom not included:
https://jsbin.com/jibiwev/edit?html,output
florian: It seems all the level of intricate details are very very
specific to zoom only and a while back we had also discussed
having layout-affecting-transforms. If we had those we would
need to solve the same issue in a more generic way. If we
had layout-affecting-transforms we would have zoom-only. Are
we going to work on the more generic issue?
<SebastianZ> Big +1 to florian.
florian: You have similar questions. Transforms give you zooming -
it's the same question but harder
smfr: One difference between layout affecting transforms and zoom is
interactions with minimum font size. chrishtr, what's the
interaction there?
chrishtr: zoom is conditionally applied on top, and will make the
fonts as large or small as the developer wants
fantasai: To zoom out a lot, the original question is "do we want to
standardize this property"
fantasai: If the answer is no, we don't have to worry about of this.
If the answer is yes, we have to have issues for all of
these
hober: To speak directly to what elika said: you said "want"
hober: I don't "want" to but we probably have to for compat reasons.
We probably do have to write something down
astearns: If we have to write something down, is this something that
gecko would be willing to implement?
emilio: If we need to standardize it, then sure... zoom is one of the
biggest compat things, but it's also a compat thing even if
we implemented it. We'd need to think about existing content
that is non-zoomed in firefox but zoomed everywhere else. Not
super convinced that implementing zoom would be a compat win
for us. But who knows
fantasai: Are you saying the compat situation is "if you are chrome
or blink you have to implement zoom and if you are Firefox
you can't"?
emilio: Yes
emilio: There are sites that use prefix transforms for gecko and zoom
for everything else. If gecko were to just implement zoom
then we'd break a bunch of sites. If we implemented zoom and
ship prefixed transforms, we'd break less sites, but probably
not 0 sites
emilio: If you're webkit and ship zoom, then you'll break sites... if
you are webkit and ship zoom and ship prefixed transforms
then you'll break websites too... its a bad situation
dbaron: If you're gecko and you implement zoom you'll probably fix
some sites and break other sites
chrishtr: I sympathize with the "what to do" and the work to fix this
problem. Make the web more interoperable in this way
chrishtr: On behalf of chromium we can do whatever we can to help as
much as we can. If we standardize this, then I think first
we should make the thing that has the .... define what we
think the JS APIs should be, chrome can make the change,
demonstrate that it's not going to break sites (which I
don't think it will) and that at least that aspect is
de-risked
chrishtr: I have a suggestion in the issue but I'm certain I didn't
get it all right
chrishtr: If you think I'm wrong, please tell me
chrishtr: I found that sites that were originally broken in Firefox
on the web compat website were fixed over time. But in
Excel, I know the zooming feature just isn't supported on
Firefox.
florian: Re "want" vs "need"... it does make a difference. If "need"
then that affects the answers to the detailed questions ...
if it's just for compat then we don't need really good
solutions, we just need compat solutions
florian: If we decide layout-affecting-transforms are the way
forward, we can spend more time on that
chrishtr: Some developers think zoom is super useful. The developers
I spoke to from Microsoft and Google thought that zoom did
exactly what they wanted with 1 line of code, which was
great from their perspective
fantasai: If we expect people to implement it based on our specs,
then we need to do a good job. It will/is a part of the
core web platform. We can't half-ass it.
astearns: <agrees>
fantasai: <agrees again>
fantasai: Another question: it seems like we have 2 implementations
that can't remove it
fantasai: We can shove it in an appendix for compatibility and
deprecate it (and list patent considerations) but it raises
the question about if there's a new layout engine (servo?)
that wants to consume web content. If they need to
implement it, there should be a spec. They shouldn't have
to reverse engineer it from chrome and webkit
chrishtr: I wasn't around for the layout/transforms discussions in
the past, and I don't know what additional use cases there
are. What are the use cases for those that zoom does not
satisfy?
<dbaron> did you want use cases for layout-affecting transforms in
the issue on zoom?
dholbert: It seems webkit and blink can't unship/change zoom. Gecko
may not be able to ship zoom under any situation due to
compat (sites specifying both zoom and -moz-transform)
dholbert: We might want to address the valid use cases for Microsoft
Office with a new property with a new name that won't have
compat fallout. If there's a new great version of zoom that
gecko can't implement, gecko will be stuck (without
breaking web content that depends on us not implementing
anything)
chrishtr: That might work. A new name that does the same thing ... I
bet office and gmail would immediately adopt it
astearns: We could have a new name like zoom-content, and UAs can
alias either zoom: or -moz-transform to it. Then nobody has
to change anything
dholbert: If we consider zoom as a legacy -webkit- prefixed property,
as not truly part of CSS, we could explain it as part of a
new thing. The new thing can be similar without legacy
burdens and implementable everywhere
chrishtr: I don't think that this plan would solve the interop
problem with gecko. As long as you have a thing that's
exposed, people can use it and it will never go away
iank: The idea is sites will slowly move away from zoom over time
iank: Authors would migrate from zoom to content-zoom
<fantasai> +1 iank
<flackr> Crazy thought, can gecko ship zoom and remove -moz-transform
at the same time?
astearns: I like the idea of this escape hatch. Why don't we keep
this as a separate issue until we get data from gecko about
the compat situation they would be in
hober: It would be interesting to have an experiment of disabling
-moz-transform at the same time.
emilio: yeah.
fantasai: you can do that with @supports
emilio: If we implement zoom then we have to disable -moz-transform.
I'm pretty sure of that
emilio: The main issue of zoom is it literally changes the meaning of
a CSS pixel
emilio: The way the JS APIs behave may be the most reasonable, but I
don't think it's reasonable. You have 2 elements and if one
is in zoomed subtree then you cannot reason about its position
emilio: Copying a position from one to the other means you can't just
copy the zoom but the effective zoom. it's not great.
flackr: I was playing with it and in the zoomed space all of the JS
APIs behave as if your pixels are larger. This is similar to
what you get with transform. The main difference is
getBoundingClientRect() would be changed by a transform, but
isn't changed by zoom, which is odd.
flackr: This is part of working it out and figuring out what
standardizing it means
fantasai: Zooming out again, do we need to spec this? We have 2
implementations, they can't remove it. We might need to add
a 3rd, we're not sure. Should we be speccing this? If we
add it to a spec, we can work out all these details. We can
make a new name. Or aliases. But, regardless, we have an
old thing that needs spec. Do we spec it or not?
hober: The additional information I'd love to know, which no one in
this room can provide, is - ultimately the reason we spec
things is it's possible to enter the browser engine market.
I'd love to know from Andreas who is writing a new browser
engine "do you find that you need to do something here?" If
the answer is "yes", then we should spec EVEN IF firefox can
never implement
astearns: If ladybird wants to render gmail and office 365, they have
to do zoom
emilio: If they want zooming on their spreadsheets. A bunch of
websites would be broken if you have either -moz-transform or
zoom. -moz-transform- is a trivial alias so it's trivial to
implement
<fremy> we are not gonna standardize -moz-transform, emilio ;)
emilio: A new browser could, in theory, implement -moz-transform
emilio: What is the objective of this property? to be web compatible?
I dunno
emilio: I wouldn't be opposed to putting the zoom details in a spec
and try to make the behavior be reasonable. At one point when
I was testing stuff there were disagreements about how blink
and webkit did some zoom stuff
astearns: If we're going to take a resolution to specify zoom, then
we need an action too to create lots of issues about what
that specification is going to take
astearns: Proposed resolution: we specify zoom.
fantasai: If we don't like it, we can spec it into an appendix and
say it's deprecated. If we like it, we can un-deprecate it
florian: The future of this property could become an alias of
something we invent in the future. This would encourage
people to use the new thing and decrease compat pressure on
gecko
astearns: I would be opposed to immediately deprecating the thing.
The only path forward is to specify it. If we end up with
engines that are not able to implement, then we go with the
deprecation or replacement strategy
fantasai: Deprecation means it works but authors are encouraged not
to use it
fantasai: We can deprecate things
<flackr> layout affecting scale transform is very similar to zoom -
it's possible they end up being the same
astearns: Any other opinions to specify it as deprecated?
chrishtr: A bunch of developers say they want it. Shouldn't be
deprecated
emilio: Except for use cases where you don't care how it interacts
with other things, then sure. But it has as ton of quirks
hober: "reasonable behavior" is too high a bar to hold the web to
bemathwi: As far as the voting as speccing for deprecated, Microsoft
would like to see it specced, but not as deprecated.
SebastianZ: The use cases are there. We want to specify zoom as
deprecated because there are quirks. Then, follow-on with
layout-affecting transforms which would generally be the
replacement for the zoom property
dholbert: Yes. If we spec'ed it as deprecated, we would do it because
we'd spec a replacement that's better
dholbert: Does that address Microsoft's concerns?
bemathwi: If there is a simple replacement, that would be OK
bemathwi: We'd have to have a sufficient or better replacement for it
astearns: Proposal: Let's specify it as deprecated or replacing
becomes a new issue. We resolve today that we are
specifying zoom and doing our best to remove as many of the
quirky bits as we can as we specify it. All the quirky bits
become issues, all the things about the JS APIs become
issues. We resolve we are specifying zoom as a real part of
the web platform and see how it goes.
astearns: Proposed resolution: Add zoom to a specification
chrishtr: Which one?
astearns: Proposed resolution as a real interoperable thing
RESOLVED: Add "zoom" as a real interoperable thing
fantasai: Tab and I think it should go in the viewport / device
adaptation spec. Not the transforms spec. It's a very
different model than what this is doing. That would be like
gluing 2 different specs that have nothing to do with each
other
florian: Device adaption might be the right place, if it wasn't such
a mess
fantasai: We renamed it to viewport and removed everything that isn't
viewport
fantasai: We haven't published it yet so it technically has both
names right now
florian: OK
dbaron: Another possibility: Zoom has a lot of interactions with
stuff in CSSOM views spec. Though it doesn't have properties
in it right now
<smfr> mild agreement with dbaron
fantasai: Please keep it that way
dbaron: Not a strong opinion
flackr: I'm not super familiar with the layout transform thing people
are talking about. If there was a chance they could be the
same thing, shouldn't they go in the same spec
fantasai: They have to be different anyway. Scale can be similar, but
rotate & others are quite different
fantasai: What zoom is doing now and what actual layout-affecting
transforms do are quite different
florian: Even if we worked on layout-affecting-transforms, we could
move zoom there when we get there.
astearns: It can move later. People don't have opinions about the
viewport spec, so let's propose that for resolution
RESOLVED: Add the zoom property to the device adaptation / viewport
spec
fantasai: Can we add chrishtr as an editor of that spec?
fantasai: You've dug into this issue a lot and would be a good to
have your help on issues a lot
chrishtr: <grimaces> sure, happy to
topic: lunchtime! 🍔🌭🌮
Received on Sunday, 10 September 2023 15:50:09 UTC