[CSSWG] Minutes Santa Clara F2F 2014-10-28 Part I: Zoom Effects, Flexbox, :role()

Zoom Effects

  - maRakow presented his research and thoughts on splitting the
      layout and visual viewports. His slides are available here:
  - There was support for his thoughts about clarifying the meaning
      of "viewport" when a spec isn't specific, especially for the
      older specs. maRakow will make a list of references that need
      clarifying and send it to the mailing list.
  - Though people didn't want to define zoom behavior in such a way
      that it limits smart design, they were very much in favor of
      giving authors more controls to create those smart designs.
  - Discussion about all these issues will continue on the mailing


  - RESOLVED: alignment in Flexbox should depend on the value of
    flex-wrap (wrap or nowrap), not the number of lines that result.
  - Most of the other issues will be addressed by the authors


  - RESOLVED: add :role() to selectors


  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Richard Byers
  Dave Cramer
  John Daggett (on phone)
  Elika Etemad
  Simon Fraser
  Sylvain Galineau (on phone)
  Daniel Glazman
  Dael Jackson
  Dean Jackson
  Brian Kardell
  Brad Kemper
  Ian Kilpatrick
  Peter Linss
  Michael Miller
  Shinyu Murakami
  Edward O'Connor
  Simon Pieters
  Matt Rakow
  Florian Rivoal
  Andrey Rybka
  Hiroshi Sakakibara
  Simon Sapin
  Dirk Schulze
  Alan Stearns
  Shane Stephens
  Bobby Tung
  Alan Turransky
  Lea Verou
  Ian Vollick
  Kazutaka Yamamoto
  Steve Zilles

  Scribe: dael

  glazou: Welcome to the second day of the CSS meeting.
  glazou: We have a few things for today. The wiki says animation
          behavior, but that's this afternoon. We have flexbox
          issues, layout.
  glazou: There's the AC meeting from 11-3, I will be there, plinss
          will chair until 2. Bert will chair for the 2-3 hour,
          thank you, Bert.
  glazou: So we have flexbox issues?

Viewports and Zoom

  [maRakow's presentation available here: http://1drv.ms/1xAK9Hd]
  maRakow: I want to talk about what's missing from specs as they
  maRakow: The behaviors are for zooming in various ways and how we
           think about the viewport in various situations.
  maRakow: There's a couple current descriptions that we have. In
           CSS OM we have page and pinch zoom.
  maRakow: And in device adaptation the actual viewport is the
           viewport used.

  maRakow: First thing is why don't we have one zoom type. I'll go
           through this fast to ensure we're on the same page.
  maRakow: If we have a page content and we want to zoom there's two
           ways. Layout zoom where we increase the size of the
           content and everything re-wraps within the viewport.
  maRakow: We do this for consistent zooms. This is something the
           user doesn't have negative issues of zoom in.
  maRakow: The intention of the second type is less about re-flowing
           the content and more about keeping it consistent.
  maRakow: If it's more of a temporary zoom you may just want a
           piece of content.
  maRakow: In this situation we call the area you can see as the
           visual viewport which is distinct from layout viewport.
  maRakow: This isn't reflected in spec text. They're talking about
           initial viewport and that's important to the layout, but
           there's no text about the visual viewport.

  maRakow: One reason it's important is pinched zoom and fixed
           elements. Fixed is description as attached to a single
  maRakow: Do you attach fixed to visual, layout, both?
  maRakow: [shows an example on the screen]
  <MaRakow> https://www.flickr.com/photos/34654941@N02/8560297430/in/photolist-8MXZUM-2nF5aq-baAvmM-fTMsFJ-e3rLc1-hVcTTe-ncLVr5-egjd34-mJuvoW-dDwovw-4aeSwh-6mC7FC-48nagT-bRgbVB-azj7AV-e1Ci8t-9bLLEJ-69489U-dk6EgQ-bXqvdN/lightbox/
  maRakow: The two top fixed elements are meant to travel with you
           on the page. Side navigation is supposed to align nicely
           with the right content. That's a problem where fixed are
           immune to scrolling, but when the document only expects
           one direction of scroll they align to one side. When you
           zoom, it starts to overlap the content.
  maRakow: When the non-fixed content is zoomed it will overlap.
  maRakow: [shows and example on Gizmodo] On this page there's a
           side navigation aligned on the left side.
  <MaRakow> http://gizmodo.com/
  maRakow: What we do instead is fix to the layout viewport so it
           stays to the side when you pinch zoom because the layout
           viewport is stationary.
  maRakow: If you attach instead to the visual, the content starts
           to crossover.
  maRakow: There's a couple way you can do this.
  maRakow: Other scenarios are bars at the top and bottom, content
           scrolling on left/right side of content (ie ads) and also
           full page overlays.
  maRakow: If you pinch zoom and attached to upper left corner, it's
           hard to pinch zoom in.
  maRakow: A page we use a lot is Atlantis World Fair.
  <MaRakow> http://www.lostworldsfairs.com/atlantis/
  maRakow: It's an example of fixed content that expects to align
           with non-fixed content.

  maRakow: Chrome has been doing a lot of work on this. It's similar
           to what we're doing, they keep content aligned left/right
           with fixed and not fixed.
  maRakow: This is a sort of thing we'd like to see described in
           some specs in terms of how the viewports interact, how do
           the types of zoom interact, and defining the types of
  maRakow: There's a lot of words that get thrown around. base-zoom,
           layout-zoom, and base-zoom are used interchangeably for
           things that change inside initial containing.
  maRakow: There's also visual-zoom and pinch-zoom. The ones we
           favor are base and visual zoom since the terms often
           don't describe all the ways the zoom can occur.
  maRakow: My thoughts are we need to put through the existing spec
           and spec what each spec is referring to as well as
           getting good definitions.

  dino: Do you expose any of these as APIs?
  maRakow: In part that's where some of the proposals for the client
           with client height are defined, They refer to a viewport.
           Mostly we spec the property hanging off the document
           layout with the client height viewport.
  dino: So the user can know they're pinched in two times?
  maRakow: We have a property that reveals that.
  maRakow: We've talked about wanting a more explicit API.
  dino: Do you ever expect the user or allow layout to happen as the
        pinch zoom changes? Someone wants a legend on the map and
        remain 1 to 1
  maRakow: We don't. We have a few other things like touch keyboard
           where when we resize we allow scrolling to the bottom
           with the keyboard up. We have a positioning type where
           you fix an item to the visual viewport, but that's the
           only case.

  dbaron: My assumption is every spec is referring to a layout
          viewport because I think most were written before visual
          viewport existed.
  dbaron: I think...there was talk about the lack of
          interoperability of all this that's interesting. I know of
          one place where the video is online.
  dbaron: I'm inclined to think that it ought not be necessary to go
          through every last spec, though it would be nice as we
          revise for clarity.
  maRakow: I spent some time making a list and for the most part
           it's swapping a word, but there were places where
           clarifying text would be helpful. As I finish the list I
           can send it to the ML.

  <dino> http://lanyrd.com/profile/ppk/
  <dino> http://www.youtube.com/watch?v=TF9ID1xwxno
  <dino> Presentation on Mobile Viewports
  <astearns> also:
  <bradk> http://www.quirksmode.org/mobile/viewports2.html

  smfr: When I was talking to Rossen he described the model where
        when you're panning the layout the viewport isn't moving,
        but when you hit the edge you start scrolling. Can you
        clarify when the scroll events fire?
  maRakow: We do fire scroll events. the model we have to interact
           two viewports, one requirement is that if you pinch zoom
           in, scroll down, pinch out and scroll up you should be in
           the same place, so we need to make sure the viewports
           travel together. They're a box within a box.
  maRakow: So as you go down you drag both viewports with you.
  maRakow: So if I pinch zoom in and pan up/down the fixed element
           is aligned to the fixed element. When you hit the edge of
           the layout port, that's when you start to drag the other
  maRakow: All the fixed elements are where you expect.
  smfr: And if you zoom and scroll sideways...?
  maRakow: It'll stay constant here since this page doesn't have
           scroll available, but it should.

  smfr: One issue I have is the position of fixed objects depends on
        how you got to that state. We don't have that in iOS model.
  maRakow: You mean like state pool?
  smfr: You're dragging the layout viewport around. If you came back
        to that same page, but arrive through different scrolling
        action, you could end up in a different place.
  dbaron: What does iOS model do different?
  smfr: Can I project?
  smfr: This is a page with four fixed elements, bars across the top
        and bottom.
  smfr: This is zoomed out. When I zoom in we keep fixed things
        relative to the physical viewport so bars at 100% width
        layout to a narrow width. If you follow that model and zoom
        in enough fixed things crowd so we start pushing off screen
        by interpolating between the two viewports so you scroll
        around and see the edge of the fixed things.
  smfr: That gives weird drifting behavior, but ameliorates the
        problem where things get in your way. The layout of fixed
        position doesn't have any difference.
  BenPoulain: The iOS mobile website when you're targeting, it
              wasn't defined for that.
  krit: Would the elevator model work on yours?
  smfr: No.

  smfr: One thing I'd like to see is web authors express how fixed
        should zoom. People layout fixed and leave the left or top
        auto. I'd like them to be able to express that they always
        want it at the top but it's okay to move it.
  smfr: I've tried keying it off and it doesn't always work.
  maRakow: We're trying to find compatible for desktop. We handle
           fixed so at any point in pinch zoom you see everything
           when you scroll. We tackled keeping content on screen at
           all times with a new property which is device-fixed which
           attaches to visual viewport.
  maRakow: It's opt-in, but it seemed dangerous to do that by
  smfr: And that gives you different zooming? Doesn't it scale with
        the page?
  maRakow: Correct. If an author uses it they should already think
           of it.
  florian: Both behaviors make sense. Seems we need an author level
           way of picking which they want.

  dbaron: Some of this is more about adopting desktop to mobile, not
          really about content made for smaller screens.
  ???: Not quite. I have a touch screen, but sometimes I want to
       zoom. I'm not trying to pidgin-hole
  dbaron: Keying off auto seems like the wrong thing to me.
  maRakow: It works well with content aligned with non-fixed content.
           If you leave the top/left on auto you don't have to do
           resizing logic, it's always just aligned since it's
           positioned as absolute.
  maRakow: In the Gizmodo case, if you have a two column layout and
           then position the fixed as top/bottom/left/right auto as
           you resize you don't have to say change the left to make
           it stay aligned.
  dbaron: As the user resizes?
  maRakow: Correct.
  maRakow: Just resizing. As the margin is reduced by shrinking the
           window, this pages will have a resize handler that
           changes left if they're spec finding left. If it's auto
           that'll auto be reposition along the content.
  smfr: Auto changes the fixed element relative to the right place.
  dbaron: Based on the assumption it's scrolled to the initial
          scrolling positioning.
  smfr: I think it's independent.
  dbaron: It matches the original position.
  smfr: It's kinda like using auto, you use it where it is. Anyway,
        authors do this.

  maRakow: I don't expect a conclusion today, I wanted to socialize
           the problem. We can continue on the mailing list.
  smfr: I'm hesitant to say...to spec the zooming viewport behavior
        in such a way that all UAs need to conform and can't
        innovate, but I'd like to see ways for authors to express
        what they want and we can converge on behavior.
  BenPoulain: And think about when you layout in the port.
  maRakow: I think this is a good start.
  glazou: Okay, so, nothing else on this?
  glazou: Thank you very much.

Flexbox issues

  <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Oct/0489.html
  fantasai: I think we've got basically 3 issues.
  fantasai: One of them, well 4.
  fantasai: One was something TabAtkins and I have to work out and
            might not be quite ready.

  fantasai: Second was alignment difference should depend on if the
            flexbox wraps, not the number of lines it happens to
            wrap to.
  fantasai: The spec says that if there is one line of flex content
            then the align-content property is not used. If there's
            more than one we use align-content to figure out how it
  fantasai: The problem is in a flex container that has wrapping,
            the alignment depends on number of lines. So if my
            screen is wider than the author expects, they'll get
            unexpected behavior.
  fantasai: This should depend on if the flexbox is wrap-able, not
            on if it has more than one line.
  TabAtkins: The spec originally behaved like this and Alex
             Mogilevski requested the change.
  fantasai: I think the current behavior is more likely to give
            unexpected behavior.
  fantasai: Say I want to baseline-align items and center lines in
            the box and you don't get that because it falls on one
  fantasai: So I think we should change it to just depend on
            flex-wrap property. People responded it makes sense.
  TabAtkins: He did respond and say it was fine.
  fantasai: Other comments?
  TabAtkins: I think we need a Rossen okay and we're fine.
  plinss: So we're waiting for a call?
  fantasai: He (dholbert) says he'll call in a minute.
  [connecting phone antics]
  TabAtkins: Did fantasai give you context?
  dholbert: I was following in IRC.
  TabAtkins: Comments? Yea/Nay?
  dholbert: Yes. The align-content change makes sense to me.

  fantasai: There's one more issue Rossen was going to talk about.
  TabAtkins: He's not here.
  fantasai: Okay. In that case maybe we can ask dholbert to call
            back when he's here.
  dholbert: Bye, talk to you soon.
  dbaron: If there were enough to justify it dholbert could drive
  fantasai: I think we have 3 issues total, so I think TabAtkins and
            I should work on one over the break, but I don't think
            it's a WG issue. I think we'll all get confused.
  fantasai: That's all for now, we can come back with rossen.
  glazou: I suggest a 15 minute coffee break and that will allow
          rossen to arrive.

  glazou: Let's restart
  glazou: Since everyone is in the room and we have rossen, let's do
  fantasai: He's waiting on feedback, so we only have one issue. The
            total DoC will be 3 comments and we'll have to go
            through the last one, maybe later.
  rossen: If we get news, they should have had numbers by now. If I
          get it we'll maybe take 15 minutes.


  TabAtkins: jcraig suggested a :role pseudo
  hober: There's a few problems. One is the impl RA roles on the
         elements. When you have multiple roles on one element, you
         get all of them.
  hober: For styling you may want to style that as a switch or a
         checkbox. Right now that's difficult in CSS.
  hober: There's also the case of wanting to simply style all the
         buttons on the page.
  hober: You want to be able to say :role(button) and be done.

  TabAtkins: That's convincing. Is there anything outside that?
  hober: We can always add more.

  glazou: You mentioned implied role. So some won't need an assigned
          role. We'll need to refer to HTML.
  hober: In CSS we say the host language has that.

  dbaron: It's :: or : ?
  TabAtkins: It's a functional class. It should be an ident.
  glazou: Can you have multiple roles?
  hober: Syntactically you can,
  hober: But only one is active.
  glazou: So if you have multiple roles on one element, it's
          whitespace broken?
  dino: So if you do :role...
  hober: You can do role=button and role="super button". Or we
         separate in the list itself.
  glazou: So the role attr is multiple but the :role() pseudo is only
  hober: Yeah.

  dauwhe: dpub is working on adding things for role attr.
  TabAtkins: Do you know if it will be consistent with this?
  dauwhe: They haven't said. I'll raise that with them.

  TabAtkins: So I guess that's simple. Objections to adding :role()
             to selectors?
  TabAtkins: So :role(button) would target anything that has a
             button according to aria rules.
  hober: It wouldn't match button role = checkbox or something crazy

  dbaron: So people are okay with agreeing CSS won't do future
          things to influence what the aria role is.
  hober: It should be defined by pointing over there [to markup layer].
  fantasai: We need to have another language that has CSS syntax for
            that kind of stuff. Our stuff should be about styling.
  fantasai: People keep asking us to put things in CSS that belong
            in the DOM, because they want to use CSS selectors and
            cascading to attach it to the tree.
  TabAtkins: If someone would like to implement cascading attr
             selectors in a browser *shrug*
  dbaron: Having CSS do this side makes sense, but we can't do both.
  hober: Should we have a note in the spec saying "you may be
  glazou: When we had selectors we didn't have a note. I'm not sure
          we need a note.
  hober: Okay.

  glazou: So no objections?

  RESOLVED: add :role() to selectors

  glazou: Who is going to write the prose?
  TabAtkins: I will.

Received on Friday, 2 January 2015 14:51:55 UTC