[CSSWG] Minutes New York F2F 2015-05-18 Part IV: CSS Zoom, Scroll Snap Point Behaviors

CSS Zoom

  - There was a strong case made for getting rid of CSS Zoom since
      the implementations vary widely and may never be
  - 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

===== 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
  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
  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
  <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
  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
  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
  ratan: I'm not here to praise it, but show what the current system
  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
  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
  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:
  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
  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
  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
  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