- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 26 May 2015 19:19:57 -0400
- To: www-style@w3.org
CSS Zoom
--------
- There was a strong case made for getting rid of CSS Zoom since
the implementations vary widely and may never be
standardize-able.
- Though several people agreed that it should be removed, or at
least deprecated, there were some serious reservations about
this removal having negative consequences, including a
specific concern about accessibility.
- This topic will be revisited on Tuesday once more data about
usage and potential breakage is gathered.
Scroll Snap Point Behaviors
---------------------------
- RESOLVED: Bring back elements for snap points. Once it is
specified, it will be the box that traps all snap
points.
===== FULL MINUTES BELOW =======
Agenda: https://wiki.csswg.org/planning/new-york-2015#agenda
Scribe: gregwhitworth
CSS Zoom
--------
<Rossen> https://cdn.rawgit.com/atanassov/css-zoom/master/Overview.html
<Rossen> http://output.jsbin.com/quwoyovugu/1/
ratan: Anyone not familiar with CSS Zoom?
Florian: Not the details.
ratan: I had to implement this for the third time, and I'm tired
of this.
ratan: We made it closer to webkit's implementation.
ratan: I was able to check the original zoom prop to an IE5.5
checkin.
ratan: The rest is history, so I don't have the background on why
they implemented it.
ratan: All zoom does, is it is a factor that multiplies all of the
length values in your computed style.
ratan: This happens during cascade.
ratan: It is pre-layout.
ratan: The way it affects layout is it becomes an aggregate
multiplier.
ratan: [gives an example]
ratan: The use was to be able to have an element and then zoom it
by %, and all properties would be multiplied by that.
ChrisL: So if it was abspos it would be shifted down?
ratan: Yes.
ChrisL: Do you allow negative values?
ratan: No.
glazou: Is it animatable?
ratan: Haven't tested, but not sure if it is, it should be.
dbaron: What happens with 'em' units?
ratan: Yep.
dbaron: [give a very long nested example]
ratan: [begins building a fiddle to test]
ratan: It is not inherited.
dbaron: Oh.
ratan: It is accumulated.
ratan: What lengths and how do we apply those, obviously auto
doesn't get scaled.
<fantasai> so, computed values are multiplied (i.e. lengths made
absolute are multiplied)
ratan: One new behavior to be more interopable with webkit,
percentages are not affected by zoom.
ratan: Percentages were affected in Trident.
ratan: To get percentages to work right, you need to apply zoom
factor only to the element with 'zoom' on it, not to any
descendants.
<dbaron> I still don't understand what causes the cumulative
effect based on this description.
Florian: A background point, I have a usecase.
Florian: You may think transforms are just fine, the spec doesn't
say what to do with font rendering in a transform, and
while it's getting better using zoom has consistent
results.
smfr: That's a bug though.
ratan: When we were playing with this, we started looking at the
various APIs that should be affected by zoom, what is
returned.
ratan: There are two distinct behaviors.
ratan: They are their used value,
ratan: then there are ones that remove the zoom value as though
you did layout without the zoom.
glazou: I'm a little upset that there are two different things.
ratan: I agree, I don't want to standardize on this nonsense, I
actually want to kill this property.
ratan: I've been asking since IE8 to remove this.
ratan: zoom:1 was used to trigger hasLayout
ratan: This was a leave behind from hasLayout.
ratan: There were a lot of sites that used this so I couldn't
remove it.
ratan: What we have in MS Edge which aligns with Webkit, makes
absolutely no sense.
ratan: We as a group can decide to take this spec on its merits,
and then start active work on it.
ratan: A lot of mobile content that uses zoom:2 or zoom:1.5. It is
kind of now a de-facto standard.
ratan: I propose we either work on this spec and fix these issues,
or kill it all together and get a date to when we remove
this from the web.
ratan: [Explains example http://output.jsbin.com/quwoyovugu/1/ ]
glazou: Looking at that page and the results, you really need a
way to get the original size and the scaled ones from the
OM and not rely on your own computations.
glazou: I want this property.
dbaron: From the way its been described, this property makes no
sense.
ratan: I'm not here to praise it, but show what the current system
is.
smfr: Safari uses zoom for page zoom, zooms the whole page
smfr: We have 5 different ways of zooming, this is one of them
smfr: We scale a certain way that uses zoom so this may be why
you're seeing some of those issues.
ratan: Is this something that we want to see on the standards
track?
glazou: It's used a lot by the web correct, are you going to annoy
them by killing it?
shane: Most people have zoom: 1 for IE8 support and to keep pinch
zoom.
glazou: Are you going to replace it with transforms?
iank: We have data that shows there is only zoom: 1 being used.
shane: They can use scale transform.
smfr: Zoom affects layout though.
Florian: If we are going to recommend people to use transforms
instead of zoom, can we tighten up on font rendering.
smfr: Let's not tangent on that, that's just a bug.
smfr: We could get transforms that focus on affecting layout.
gregwhitworth: To get rid of this, we'd do what we're doing for
visible control codes - set a timetable, implement
behind a flag, and coordinate the release.
plinss: I would like to see this removed from the standards, and
not have it embedded in the web.
plinss: State your case glazou, if you're upset
glazou: Let's take an accessibility aspect, that you want to zoom
in on the content not the nav bar.
plinss: No one is arguing against having transforms that affect
layout. We should evolve that instead of using this
terrible property.
SteveZ: I wrote a spec for it a long time ago, no one wanted it at
the time.
plinss: There are a lot of use cases for this.
ratan: Question again, is this something that we should A) keep
and standardize on the track or B) kill
shane: I'll provide the fire.
smfr: I don't think we feel that people use zoom all that much, so
I don't have a strong desire to see this specified.
ChrisL: Did you like the argument for using transforms?
glazou: I think I can live with it, but don't like the name.
glazou: Do you officially ask us to start working on transforms
that affect layout?
ratan: I believe the use case is strong, I don't have a strong
preference between zoom or transforms.
glazou: I don't disagree with that, but I want to know if we will
be moving forward with layout transforms.
ACTION: glazou to ping Léonie regarding accessibility with the zoom
<trackbot> Created ACTION-686
bcampbell: I would like to see some use cases to make a better
accessibility decision on this.
ratan: [gives example of illustration on random website for Bo]
ratan: [explains how it affects layout on said page]
ratan: It's suggested not to be used here:
https://css-tricks.com/almanac/properties/z/zoom/
bcampbell: Any assistive technology would a need to zoom as well.
bcampbell: Assume someone uses zoom to zoom in on something small,
as long as you can still zoom in the item via the UI.
iank: Having UI hidden for accessibility doesn't help.
ianK: The limited stuff I've done, that stuff needs to be done in
and by the browser, not by the author for discovery reasons.
bcampbell: I agree with that.
ratan: [shows same change using transform]
ratan: Among implementers it does seem there is agreement to hide
it from developers with a decent timeline for them to
update their sites.
Florian: Transforms do a bad job of kerning, etc
ratan: I don't know how bad kerning in transforms affects the
decision on zoom.
Florian: I'm not saying this is blocking, but it would be an
easier transition for authors to solve that use case for
using zoom.
Florian: I'm not an expert on rending of fonts, but would like to
see it addressed.
ratan: Any objections to deprecating zoom?
ChrisL: I object to deprecation, because I think you actually want
to kill it.
<ChrisL> deprecate means new content should not use it, but
implementations must support it. That is not what we want
here.
Florian: We should handle this like control characters.
Florian: only specify or remove -- don't keep without a spec
RESOLVED: Kill CSS Zoom with fire
RESOLVED: Rescind previous resolution
<fantasai> plinss, basically, we don't have a resolution to "kill"
anything unless we have a resolution to remove it from
future releases of a browser. And we don't have that,
because smfr is not convinced.
SteveZ: We need to make this public.
smfr: I don't have much use case on uses other than 1.
smfr: Please provide some more use cases so we can make a better
decision.
ratan: We started down this path, based on our implementation of
webkit's implementation
smfr: I can look at our bug database for why we did this.
ratan: Well now this is becoming a spec.
dbaron: [gives examples as to how standardizing for making better
font rendering is complex]
plinss: I would like to close on this subject.
iank: We can add a use counter into blink that keeps track of what
is used.
ratan: So, Simon, are saying you would like to go the other way
around and standardize it?
smfr: I need data in order to provide whether we're willing to
actually kill it or not.
plinss: Do you think this is data you can have by the F2F
fantasai: I can say that I'm not for there being stuff in multiple
browsers that's not on the standards track.
plinss: We may not be able to standardize everything. [example]
fantasai: That is not stuff that the web depends on.
fantasai: If a new engine needs to implement it, then it needs to
be in a spec.
Florian: Does Servo need to implement this? If so we need to
standardize this.
smfr: I think we should come back to this tomorrow.
ratan: Ok, I'll have more data tomorrow.
Scroll Snap Point Behaviors
---------------------------
smfr: [explains snap points]
smfr: If you set a coordinate, it will start snapping in its
scrollable ancestor, whatever that happens to be.
smfr: I'm arguing for something like the 'elements' keyword to
come back.
smfr: Layout changes can make the element scrollable or not.
smfr: That can make surprising issues for authors when they
thought an element should be snappable but changes cause the
snap ancestor to change.
dbaron: Are you saying that if something has overflow: auto it is
a scrolling container?
smfr: Yes, I think that's undesirable as well.
smfr: I think there needs to be a property on scrollable container
smfr: that would allow it to capture scroll-snap-destination.
smfr: What I'm asking is for the author to be explicit about
what they want to snap to.
ratan: Originally the scroller was the one providing offset
positions in the scrollable area.
ratan: In that case there was no dependency on content.
ratan: Some of the first comments we heard was the argument for
element-based coordnates.
ratan: We didn't make too much of it, there would need to be a
symmetrical handshake between the element and the
scrollable container.
ratan: It's analogous to how breaks work, and why we have
different types of breaks.
ratan: I might have a use case where an element can cross a
scoller and snap to a different scroller.
fantasai: That doesn't make any sense.
smfr: Yeah, I agree.
fantasai: Maybe if you want overflow: hidden you might need to
jump scrollers.
fantasai: But if we had overflow: clip we wouldn't need that.
ratan: The use case Simon presents, and I remove the
overflow: scroll, now I'm screwed.
fantasai: Right.
ratan: There needs to be some type of ident for there to be a
correlation between the scroll container and the element.
<fantasai insert explanation here>
[post-f2f: fantasai doesn't remember what she explained]
ratan: Is this something that you've proposed?
smfr: Possibly bringing elements back.
ratan: What happens when I remove it? It now snaps to ancestor.
smfr: That's fine, that seems like author intent.
fantasai: What is the usecase of repeat with scroll points?
smfr: You have a lot of images that are the same size and you want
it to snap at the same point.
fantasai: I think you're likely to run into issues if you have to
resize the images.
iank: The argument for repeat is if you are lazy loading the
images you can use the repeat for this.
fantasai: Can't you use the border of the box?
iank: Not in all cases, what if still loading?
fantasai: In that case you have nothing to scroll anyway.
dbaron: Maybe scroll-snap-points-{x,y}'s Applies To line could
change to "All Elements", so that the elements value can
be used on things that aren't scroll containers and can
thus capture scroll-snap-destination on descendants.
...
<dbaron> [I think people agreed with my suggestion about the
Applies To.]
smfr: Does anyone object to bringing back elements keyword?
fantasai: I'm becoming less and less convinced of this -- not
snap-points as a concept, I think that's good, but
the design of it...
fantasai: e.g. nobody's given me a good use case for repeat().
ratan: Another use case of this, if you want to read and simulate
reading this, that's possible scroll repeat every 90%.
fantasai: I remember someone raising an issue that scroll-snap-
type should be on each point and not on the container
itself.
fantasai: That seems to make a lot of sense to me.
bcampbell: Is it a mandatory stop?
smfr: Yes, it is a mandatory snap.
smfr: Exact details up to UA, e.g. might want to account for speed
at which you're swiping.
smfr: The spec is vague about the physics when interacting with
the snap point.
bcampbell: I was thinking of this from a an accessible standpoint,
that if your view is very small because you're so
zoomed in that may be painful.
bcampbell: I'm not sure if that will be really bad though.
fantasai: I don't think it does well in a responsive environment.
fantasai: At times the snap points aren't hit because of the
expectation of the size of the screen based on the
content, not all viewports are the same size.
fantasai: I think you should move away from the coordinate system,
you should think about alignment of a box to another
box, so that it won't matter the size of the screens.
fantasai: For example, if I have a photo album, I might think
"of course I want a mandatory stop in the middle of each
photo, you shouldn't land with a photo not centered in
the middle of the screen". And that works great if the
screen is wider than the photos. But if you have a
smaller screen than a photo, it means you can't ever
scroll to the parts of the photo that don't fit when it
is centered.
smfr: That's a fair assessment.
Florian: I think we should try to handle when the screen is
smaller than the author expected.
<leaverou> fantasai++
<leaverou> the way this is proposed makes it exceedingly difficult
to use. Authors want snapping to boxes, they'll just
end up using JS all the time to apply the snap points,
which kinda defeats the purpose a bit.
smfr: Is Microsoft willing to do some spec ediitng?
ratan: Yes.
Bert: If I set them on the outer element with repeat, and use
'break-before: <something>' on a child, will it align to a
set snap point
TabAtkins: You would setup your layout however you want, and then
you would apply the snap point to that box.
?: We had agreement on the trapping behavior at least.
RESOLVED: Bring back elements for snap points. Once it is
specified, it will be the box that traps all snap points.
Meeting adjourned.
Received on Tuesday, 26 May 2015 23:20:25 UTC