W3C home > Mailing lists > Public > www-style@w3.org > May 2016

[CSSWG] San Francisco F2F 2016-05-10 Part I: Scheduling, Round Display [css-round-display]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 25 May 2016 20:04:13 -0400
Message-ID: <CADhPm3vG2zySwg0QjCcwXfXeVH4kXr1YvHWbAXHnUMF3-ha7Zw@mail.gmail.com>
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.
=========================================


Scheduling
----------

  - Microsoft has offered to host in January/February in Redmond,
      Washington
  - April/May will likely be in Tokyo or Kyoto area; people should
      look for any conflicts in this time period.

Round Display
-------------

  - Florian presented his proposal for a MQ to tell if a device is
      rectangle, round, or unknown.
      - Several people felt that unknown wasn't necessary; if a
          device isn't round it can be assumed to be rectangular.
  - RESOLVED: remove device-radius MQ, add MQ for shape: rect |
              round with traditional boolean semantics
  - There was a split in the group as to if viewport-fit should be
      defined now or if the group should wait for implementation
      experience with a middle ground proposed of giving some
      guidance, but keeping it loose until there's implementations.
  - RESOLVED: 1) Accept viewport-fit with three values: cover,
                 contain, auto.
              2) Initial value is auto. UA can do anything it wants
                 as long as the content not designed for round
                 screens is easily 100% viewable by the reader.
              3) Undefined what is outside the contained viewport
                 for 'contain'. UA can paint anything it wants,
                 chrome, black, canvas background, @page background,
                 photo of SF Bay Bridge, whatever.
  - There were conflicting opinions on if polar origin was necessary
      and how it should interact with other properties (if it exists).
      - The interested parties discussed it over lunch and come up
          with a solution to integrate the desired behavior with the
          motion-path spec, making the motion path spec stronger in
          the process. The proposal is:
          - combine polar-distance and motion-offset -> offset-
              distance
          - polar-angle -> offset path
          - polar-anchor and motion-origin -> offset anchor (initial
              value is auto) which copies the percentages from
              offset-origin so offset-position behaves like
              background position.
  - RESOLVED: Accept current proposal as outlined by fantasai (above)
  - The motion path spec will need to be renamed since it's more
      about path positioning than it is about motion.
  - RESOLVED: jihye added as an editor of Motion Path spec.

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/san-francisco-2016#proposed-agenda-topics

Present:
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  Takao Baba, Beyond Perspective Solutions
  L. David Baron, Mozilla
  Tantek Çelik, Mozilla
  Dave Cramer, Hachette Livre
  Elika Etemad, Invited Expert
  Daniel Glazman, Disruptive Innovations (only IRC)
  Daniel Holbert, Mozilla
  Jihye Hong, LG Electronics (only IRC)
  Joone Hur, Intel Corporation
  Koji Ishii, Google
  Brad Kemper, Invited Expert
  Ian Kilpatrick, Google
  Chris Lilley, W3C
  Peter Linss, HPI
  Myles Maxfield, Apple
  Edward O'Connor, Apple
  Simon Pieters, Opera
  Florian Rivoal, Vivliostyle Inc.
  Andrey Rybka, Bloomberg
  Hiroshi Sakakibara, Beyond Perspective Solutions
  Simon Sapin, Mozilla (only phone)
  Jen Simmons, Mozilla
  Geoffrey Sneddon, Invited Expert
  Alan Stearns, Adobe
  Shane Stephens, Google
  Greg Whitworth, Microsoft

Regrets:
  Dael Jackson, Invited Expert
  Hyojin Song, LG Electronics
  Lea Verou, Invited Expert

Scribe: dbaron

Scheduling
==========

  Rossen: We previously proposed to have January-February-ish F2F in
          Seattle.
  Rossen: We'd be happy to host.
  Rossen: Unless people have a better location to propose.
  Rossen: If we're hosting it, it would be in Redmond rather than
           Seattle.
  Rossen: If we don't have other offers on the table, we can do
          Redmond -- or change later if we have other options.

  Rossen: Still settled for Kyoto for following one?
  Florian: Either Tokyo or Kyoto.
  skk: Want to do Tokyo area.
  Florian: Easier to meet developer communities in Tokyo.
  skk: I'm talking to some Japanese publishers, we could arrange an
       industry meetup.
  Florian: I'll try to organize something in parallel in Kyoto to
           see what we end up with.
  skk: April or May?
  dbaron: Might want to look for dates with conflicts.
  Rossen: If you have conflicts around April/May, please send
          conflicts to mailing list.
  Florian: Are we necessarily CSS and Houdini, or just CSS?
  Rossen: Don't know yet. Will discuss during Houdini meetings.

Round Display
=============

'shape' media feature
---------------------

  <jihye> https://lists.w3.org/Archives/Public/www-style/2016Apr/0273.html
  jihye: First thing is about the 'shape' media query, suggested by
         Florian.
  jihye: The device-radius query in css-round-display detects shape
         of the display.
  jihye: It lets us apply different styles according to display shape
  jihye: but can't cover all shapes since it combines shape with
         roundness of corners
  jihye: so Florian suggested shape media feature.
  Florian: We already talked at previous f2f about this.
  Florian: Two reasons to query for shape: (1) if it's not
           rectangular putting things at some places like corners
           might not work, want to know about this to avoid corners.
  Florian: we'd been discussing visibility(coordinates) query.
  Florian: (2) stylistic reasons -- want round design if screen is
           round
  Florian: this media query is for that.
  Florian: It tests whether the screen is round or not.
  Florian: As of today the only OS that can let the browser know
           about this is Android, and it has a boolean saying
           round-or-not.
  Florian: So it's all we can realistically implement.
  TabAtkins: [joking] so we need to round off to the nearest value?
  Florian: What I propose is rectangle or round media query.

  Florian: We might fall back into yesterday's discussion.
  Florian: This design assumes we have the "unknown" state.
  Florian: If you have the Android API you know -- but otherwise you
           really don't know.
  fantasai: Presumably once you have screens that are really not
            rectangular, you'll have new APIs.
  Florian: This assumes unknown semantics which are close enough to
           false.

  tantek: Is this just for 2 dimensional displays, or 3d as well?
  Florian: This is intentionally fuzzy -- not exact circle or exact
           rectangle.
  Florian: It's about whether round enough that round designs that
           round designs are preferable.
  plinss: ... 2d display wrapped in a 3d space.
  Florian: ...
  tantek: Using a simple term like round will mean different things
          to different people.
  tantek: If you saw the TVs at CES...
  TabAtkins: Round is the correct short and easy-to-type word for
             this.
  plinss: Users perceive those as rectangular.
  plinss: But there are also phones with screens that wrap around
          the edge -- the edge is logically like a different screen,
          but part of the same one.
  Florian: This media query could be extended to a long list of
           shapes, but it's about design trends that exist.

  bradk: What's the chance the OS or browser will be aware of shape
         of screen?
  Florian: Android has a boolean that says round or not.
  Florian: This is about design styles, not exact geometry.
           Star-shaped displays aren't a thing.
  Florian: If want to know what's hidden, need actual geometry of
           screen.
  Rossen: Why is it not rectangular or not in the query?
  Florian: There isn't a design trend of putting circular designs on
           rectangular screens.
  Florian: People want to be round on round screens.
  Florian: If there are star-shaped screens, we can discuss it then.
  Florian: It's intentionally not a boolean query, so we can extend
           the list if we need to.
  Florian: We have 2 shapes for now, but can extend.
  Florian: There's no false-y value in the list, so we can add more
           if we need to.
  Florian: If we give up on unknown semantics,
  Florian: if you're a star-shaped UA and you know it, you can be
           false for both rectangle or round.

  bradk: I would think asking if it's a rectangle or not you might
         want more stuff toward the center of the screen.
  Florian: That's a separate problem about what points are visible.
           This is about qualitative design.

  TabAtkins: The screens that exist are rectangle, rounded-
             rectangle, and round.
  TabAtkins: We should not be in the weeds about all sorts of
             bizarre shapes. MQ aren't the place for fine-grained
             information passing. At some point you want a JS API.
             Let's stop talking about stars.
  <fantasai> +1 to not talking about stars
  Florian: If we end up caring about other shapes, this is
           extensible since it's not a boolean media query.

  jihye: A question about your suggestion: if the UA doesn't knows
         about shape of display, then shape:rectangle and
         shape:round evaluate to unknown.
  Florian: Yes.
  dbaron: On some operating systems it may be reasonable for the UA
          to know that the OS has rectangular displays and that's
          that.
  dbaron: You shouldn't try and say that if there is no API, then
          the UA must not deny that is rectangular.
  Florian: No, not trying to say that. Up to UA to figure out
           whether or not it knows.
  Florian: I'd assume that authors, in this case, knowing vast
           majority of screens are rectangular. Authors likely to
           assume rectangular if the UA doesn't know... but in that
           case we expose full info to author.

  bradk: From a practical viewpoint, wouldn't most authors assume
         that if it's unknown, would assume it's rectangular.
  Florian: I wouldn't have come up with unknown just for this, but
           since we have it...
  TabAtkins: Unknown only happens for unrecognized things -- we
             don't have a semantic for known values being unknown.
  TabAtkins: The assumption that if you don't know, you're
             rectangular, is perfectly valid -- and we should define
             that you're going to be rectangular if you don't know
             that you're not.
  TabAtkins: The thing that we gain is that naive code works just as
             if it were assuming rectangular.
  TabAtkins: We don't have a semantic for defined things returning
             unknown and I don't think we want to add it.
  TabAtkins: Unknown is just a way to not cancel out the entire MQ.
  TabAtkins: We can just assume rectangular unless known otherwise.

  Florian: I think it makes sense for authors to do that, but not UAs.
  TabAtkins: What else would you do other than assuming rectangular?
  Florian: If you're designing widgets for round screens...
  TabAtkins: 99.9% of authors, if they don't know -- probably
             rectangular. If OS isn't giving you information, assume
             rectangular.
  Florian: What do you gain?
  TabAtkins: Simple semantics.
  TabAtkins: If your screen doesn't know, it's rectangular...

  tantek: I tend to agree -- better start with fewer values until
          there's a case for more.
  Florian: Fewer? I have 2.
  TabAtkins: You're defining a third value that's "neither", that's
             confusing.
  TabAtkins: The unknown logical value acts in a counterintuitive
             way if you don't know you're dealing with it.
  jensimmons: I think there's a big difference for authors. We'll
              have screens that know they're rectangles, that know
              they're round, and those that have no idea.
  jensimmons: Can we say that all the screens that don't know what
              they are, definitely know they're rectangular.
  jensimmons: Authors know how to deal with not having media
              queries, e.g., on IE6, not knowing width.
  jensimmons: ..
  bradk: Danger is having code for rectangular screens that gets
         excluded.
  jensimmons: Risk that if every single screen ???

  Scribe: TabAtkins

  dbaron: I don't think this discussion about screens that don't
          know what they are makes sense.
  dbaron: I don't think somebody's gonna ship a browser UI that
          works on a round screen without knowing they're doing so.
  dbaron: So I think the only real risk is that somebody ships an
          engine without updating it, because they updated the
          browser UI and forgot about the engine.
  dbaron: So we should just assume things are rectangular.
  dbaron: Unless somebody knows they're on an OS they can detect
          being round.

  Scribe: dbaron

  ChrisL: Asserting not knowing it's rectangular is ostrich-like --
          we know the shapes of most screens.
  tantek: Before mobile -- having unknown screen wouldn't have
          helped with screen vs. handheld.
  Florian: I think I have 2 counterpoints -- UAs that don't
           implement this media query will behave the same as those
           that implement rectangle as unknown
  Florian: so I'm not sure it's useful to have different behaviors
           between UAs that don't know about screen and those that
           don't know about media query.
  Florian: Having the same information in practice it's the same.
  TabAtkins: I'm not interested in defining backwards-compat of
             media query relative to their non-existence.
  Florian: If you want to write a MQ for round design, query for
           shape:round
  TabAtkins: If we returned unknown, what should an author be doing?
  Florian: In most cases it's useless to query for am-I-rectangle
  Florian: If that's what you want people to query.
  <tantek> this is silly, saying authors may do not(rect) is a
           strawman
  ...
  TabAtkins: What's the benefit of this more complicated unknown
             value?
  TabAtkins: What will authors assume if it's not round?
  Florian: Rectangle.
  Florian: In that case the MQ should be round: yes | no
  TabAtkins: The unknown thing exists so we can do boolean logic
             without breaking the entire media query and repeating
             the selectors mistake.

  Shane: I don't think there will be cases of people building
         browsers for mobile devices without knowing the shape of
         the device.
  zcorpan: The case you're worried about is authors doing not
           (shape:rect) and assuming circle and this will break if
           we add a third shape.
  zcorpan: I don't think we should use unknown value to protect for
           that. We should have tutorials/notes that advocate using
           only round.
  hober: If the only query is rect, then you might ask for
         not(rect), but if you have round, it's the obvious way to
         ask the question of whether it's round.
  hober: I think it's just a non-issue.

  TabAtkins: What is the benefit to authors?
  TabAtkins: Doing what you're suggesting is making it easier to
             write it otherwise.
  TabAtkins: I'll object to making known things unknown values as an
             editor and implementor.
  jensimmons: Useful to target rect.
  Rossen: Anyone other than Florian who wants this?
  Florian: Seems not, and I'm not objecting
  Florian: I think better extensibility my way, but most of time
           won't make a difference.

  jihye: If the rounded rectangle that is not also round -- in this
         case unknown?
  Florian: If you're a rounded corner rectangle, the browser decides
           if you're closer to a rectangle or closer to a circle.
  fantasai: I'm worried about people using to see if it's a circle.
  fantasai: Want to make sure querying what parts of the screen are
            visible is [missed]
  Florian: Browser on egg/ellipse that opt in to roundish designs,
           that browser will want the roundish designs.
  fantasai: We have just this and we don't have ability to query
            what parts of the screen are visible, then authors will
            use this to query what parts of the screen are visible.
  TabAtkins: At first approximation, that's reasonable.
  Florian: Might put things off corners ....
  Florian: We might want MQ for geometry detection, but OSes don't
           want to report that.
  TabAtkins: MQ can't do fine-grained things.
  Florian: We discussed this in Sapporo.
  TabAtkins: I disagree with all that.

  Florian: Back to question -- if neither strictly rectangle or
           strictly a circle, it's a design choice of whether the
           browser prefers round designs.
  jihye: ?? idea of categorize the shape of round and rect only, and
         not unknown?
  fantasai: Should put a note in the spec that if a UA really doesn't
            fit in these categories, should contact the WG so we can
            add a new value
  ??: and should return false for both rect and round.
  TabAtkins: That's what the advisement class is for.
  Tantek & TabAtkins: ...

  hober: The lesson from that is that we shouldn't add MQ without
         having actual implementations.
  tantek: Yes, don't add unless imminent implementation.
  joone: Some round display are not perfect circle, e.g., Moto 360
         has round display but bottom part cut out like flat tire.
  joone: Many smart watch has round display but bottom part are ...
  Florian: Maybe a MQ, maybe a JS API giving details of screen.
  Florian: Also can't be implemented today because OS won't tell you.
  joone: In some cases user cannot see bottom part.
  Florian: I don't think this MQ is appropriate for circle,
           circle-with-10px-cut-off-at-bottom, etc.
  Florian: for that we need another query, as discussed in Sapporo.

  Rossen: Florian, did you want a resolution on that MQ?
  Florian: I think it would be good to resolve if we agree.
  jihye: I would like to change device-radius to shape... is it ok?
  Florian: This is instead of, not in addition, to device-radius.
  Florian: Add this and remove device-radius.
  Florian: Or other thing later.
  TabAtkins: Or do something about that when implementations can do
             something about it.

  RESOLVED: Remove device-radius MQ, add MQ for shape: rect | round
            with traditional boolean semantics.

  jihye: We also need JS api to detect shape of screen.
  jihye: In view of manufacturer, api to directly tell us what shape
         of screen is.
  <jihye> https://developer.tizen.org/dev-guide/2.3.1/org.tizen.web.apireference/html/ui_fw_api/wearable/circular_support/circular_support.htm
  jihye: There are some APIs in Tizen (Samsung) OS.
  jihye: They use these APIs to detect if screen is round or not.
  jihye: Media query with window.matchMedia can know shape of device,
  jihye: but we have to define media query before that to use that
  jihye: so I suggest a new attribute to screen interface to know
         directly
  jihye: ... the shape of the device.
  jihye: Something like round attribute can do that.
  Florian: Why not use the media query we just defined from
           javascript?
  jihye: matchMedia?
  Florian: Yes.
  jihye: We have to define media query always to use that API
  jihye: but when we implement scrolling effect, we mostly implement
         it by javascript.
  florian: But media queries are accessible from javascript.
  fantasai: I think she's trying to say it's harder to polyfill.
  TabAtkins: We're not going to throw in arbitrary new APIs to
             handle all new media queries.
  zcorpan: Authors typically feature test things using something
           like modernizr, which has its own API
  zcorpan: Authors could use modernizr.screenshape.circle -- could
           use matchMedia if supported or fall back to polyfill if
           not supported.
  Florian: jihye, what's the problem for you with using matchMedia?
  jihye: I think matchMedia can do that.
  Florian: The syntax is ugly, but that's not specific to round
           shapes.

  Florian: Side question, is this something typed OM from Houdini
           can fix?
  TabAtkins: We're not currently planning anything for media queries.
  shane: But we'll need to have a typed interface to media queries.
  shane: Won't help with keywords, but will help with lengths.
  Rossen: Next topic, then? More to discuss?

viewport-fit
------------

  <jihye> https://drafts.csswg.org/css-round-display/#extending-viewport-rule
  <astearns> https://drafts.csswg.org/css-round-display/#viewport-fit-descriptor
  jihye: we need to define viewport-fit
  Florian: it's a descriptor in @viewport
  <zcorpan> @viewport { viewport-fit: ... }
  jihye: I wrote spec for this in round display.
  jihye: On rectangular display viewing area is screen rectangle
  jihye: but on rounded display viewing area is not always bounding
         box of screen
  jihye: viewport-fit ...
  jihye: On round display, if viewport-fit is cover, use rectangle
         that covers entire display
  jihye: but if viewport-fit: contain, on round display, viewing
         area is inscribed rectangle.
  jihye: How can we call the viewing area?
  jihye: We can call viewing area as the visual viewport.
  jihye: There is only initial viewport and actual viewport in the
         device adaptation spec.
  jihye: we have to add new term, visual viewport.
  jihye: In this visual viewport, the viewing area [missed]

  Florian: As currently proposed, why do we need this at all?
  Florian: One problem we have with round displays, is that without
           anything, viewport is bigger than screen, and you have
           areas that are not visible.
  Florian: For CSS we've been writing so far, by default things are
           readable and not hidden off screen.
  Florian: If you don't style for specific device, still get
           something usable.
  Florian: So by default should get something readable by default.
  Florian: So by default fit the viewport in the screen, and then
           have a switch if you can deal with the corners being
           hidden -- media queries, shape-inside, etc.
  Florian: If you don't, safe by default.

  Florian: How does this proposed thing work?
  Florian: If you do viewport-fit: contain or cover on a rectangular
           screen, you get the usual results.
  Florian: On a round screen, it influences the initial viewport (as
           defined in device adaptation), should probably talk about
           as initial layout viewport.
  Florian: It's what you have before you apply the constraining
           procedure.
  Florian: Once you're done with that the visual viewport is also
           sized to that size.
  Florian: So you if you have other stylesheet rules that ask for a
           viewport that's 1000px
  Florian: then your layout viewport will be larger and go where
           ever it wants, but your visual viewport will be inscribed
           in the screen.
  Florian: If you do cover then you get the opposite, then layout
           viewport and visual viewport will contain the round screen.

  Florian: There's a third value proposed in the spec which is auto
  Florian: which should be implemented as contain if you don't have
           a better idea, but it allows browsers to say that this is
           a waste of screen real estate, usually nothing in the
           corners anyway.
  Florian: So do something somewhere in between that cuts the
           corners a little and uses much more of the screen and
           only hides a bit of the corners.
  Florian: In addition, if you're in auto mode, you can have an
           extra scrolling mechanism.
  Florian: If the user drags to try to see what's in the corners,
           lets the users drag to see all of the visual viewport
  Florian: but if you don't have anything smart to do, just stick to
           contain.
  Florian: Maybe we need a word for the screen, unless screen works
           fine, or maybe we need a word for the bounding box of the
           screen, or maybe that works.

  bradk: When is the visual viewport not the initial viewport?
  Florian: Initial viewport (should be changed to initial layout
           viewport), in the world where everything is rectangular,
           is the size of the screen.
  Florian: Maybe in the UA style sheet maybe there's a rule forcing
           it to 800 or 900 pixels to deal with mobile devices.
  Florian: After the constraining procedure the actual layout
           viewport is what was in the UA style sheet, unless author
           says to make it fit. That's how it's now described in
           device adaptation.
  Florian: Then you view this through your visual viewport (term not
           actually in spec).
  [bradk asks questions about viewports]
  Rossen: Physical and layout are different if you're pinch-zoomed
          for example.

  Florian: All this terminology is fuzzy; visual viewport not
           discussed anywhere in specs.
  Florian: Most of things in spec that talk about viewport talk
           about actual layout viewport -- but not quite all;
  Florian: some refer to visual one.
  Florian: Maybe in background-attachment???
  Florian: Visual viewport has same dimensions as initial layout
           viewport
  Florian: but easier to think of them as separate things.
  Florian: I'm mostly going by terminology used by ppk on his blog,
           inspired by internal terminology at Opera.

  [ discussion about what goes in the unused space ]
  bradk: Authors will want to put things there.
  Florian: OK for UA to put background color there, but authors
           shouldn't rely on that.
  bradk: If I have control, I'll use cover so I can control what's
         in that space.
  Florian: That's fine. But if you take Web pages designed prior to
           round displays, don't want half the text to be hidden.
  bradk: I want something in between, I can put things there but can
         rely on important being contained.
  plinss: You don't get control if it's outside the viewport.
  bradk: How come I get control over that space if I say cover, but
         not if I say contain?
  TabAtkins: There's nothing underneath there -- since any arbitrary
             webpage *can* draw there.
  Florian: Web page can request full screen.
  TabAtkins: With permissions only.
  TabAtkins: Let's not pretend the whole viewport isn't under their
             control.
  Florian: I'm ok with a MAY that the background extends -- not
           necessarily controllable space.
  dbaron: I think Brad has a good point.
  dbaron: The author is specifically choosing to say "I don't know
          how to fill that space"
  dbaron: So it's not clear why the UA should then say "ok, then
          you're not allowed to touch it at all"
  fantasai: We can reuse similar functionality to @page which lets
            you touch the margin area.
  fantasai: Could use @page.
  bradk: It sounds like the only way to get what I actually want is
         to use cover and do JS math.
  <fantasai> I think this should be under the control of the UA. It
             MAY extend the canvas to bleed outside the viewport
             area, if it wants.

  Florian: How much do we allow to link out?
  TabAtkins: Yes, it's still addressible area
  Florian: Contain is the default value.
  Florian: It's the compatibility mode.

  [discussion of negative positioning just off the edge]
  plinss: People sometimes put things just off the edge so they can
          transition it on-screen.
  Florian: I'm open to leaking canvas color to that area, but not
           any of the other stuff.
  zcorpan: It seems reasonable to me to hide the unscrollable area
           but show the scrollable area part of the screen.
  zcorpan: You have 2 directions that are unscrollable, typically
           above and left
  zcorpan: but you can scroll right and down -- not reason to hide
           these.
  zcorpan: Kinda ugly, but just accessible fallback.
  bradk: But once you scroll...
  zcorpan: Yes, once you scroll down, can render things at the top.
  Florian: This is not dangerous -- but is it ugly?
  TabAtkins: Minus the canvas that escapes the element, root element
             is contain:paint by default.
  TabAtkins: The objection was the elements are outside there --
             they'll look ugly.
  Rossen: For clipping purposes, containing block is still clipping
          in negative scroll direction.
  TabAtkins: ICB clips its contents (elements, etc), but canvas
             background still renders.
  <TabAtkins> that feels like it'll look good

  dbaron: We're doing UX design here, and that's not something we
          should be doing here.
  dbaron: We should have other people design the right thing for
          round displays, and experiment with products, and then
          come back to this group.
  dbaron: It's not clear to me that this is the right thing.

  bradk: so we should just punt on this?
  Florian: I see your concern, but my concern is that if we do that
           we'll end up with Web for Watches and Web for Everyone
           Else.
  TabAtkins: The relevant people implementing things are in this
             room or adjacent to this room.
  TabAtkins: We have examples of this not working well,
             <meta viewport> is a trash fire.
  Florian: With variants discussed today, this is one proposal to
           avoid having at trash fire.
  Florian: Do we want to write it up as a proposal and at risk?
  Rossen: In favor of not influencing it now.

  jihye: We first proposed contain, guarantees element contained in
         screen
  jihye: so you can guarantee that all the elements are in the screen
  jihye: We need that design when we implement scrolling.
  TabAtkins: So have you tried to implement contain yet?
  jihye: Not yet.
  jihye: We do that by javascript translate.
  TabAtkins: So you do show what's in the background of the page in
             the areas that aren't covered.
  jihye: We divided the pages with grid.
  jihye: We don't use that space.
  TabAtkins: What shows in the space?
  jihye: Maybe transparent?

  Florian: One option is don't write anything in the spec; let LG
           figure out
  Florian: or, write something loose in the spec giving some
           guidance and letting implementors figure out details
  Florian: or write exactly what I like.
  plinss: I think middle solution.
  plinss: Write up problem and possible solution and being open to
          improvements.
  plinss: I'd rather give some guidance and leave details up to UX
          experts.
  jensimmons: Seems to me that doing absolute simplest thing
              possible might be good direction -- and contain --
              just make it tiny.
  jensimmons: This isn't at all what I thought it was when I read it.
  jensimmons: If I want to design a layout, and have background
              colors show up in the extra space.
  jensimmons: Smallest thing -- take a website and make it small and
              maybe put black around it
  bradk: Not sure making it small is the best thing, though
  Florian: Contain is meant to be the default.
  bradk: I'd rather see the default be cover.

  Scribe: fantasai

  plinss: Auto can do what cover would do, if you have the ability
          to scroll to see all of it.
  dbaron: I think we need a switch to say whether the page was
          designed with round displays in mind or not.
  dbaron: And I think we should leave it up to people who are trying
          to build a good UX on round display, to figure out what
          the best thing is to do for a Web page designed for not a
          round display.
  plinss: What's the trigger?
  dbaron: Could be something like this.
  fantasai: That's why we have 'auto' as the initial value.
  dbaron: Maybe we should just have 'cover' and 'auto'.
  TabAtkins: That's fine.
  Florian: And some notes that if you have no idea what to do, do
           contain.
  Florian: Should we say, "however you do it, you must show all the
           content".
  dbaron: UA must provide a reasonable way to show content that has
          not been designed for round display.

  Scribe: dbaron

  jensimmons: Another variable here that might or might not matter --
              some sites use and don't use media queries.
  jensimmons: Some pages have made designs that are made to work on
              150px wide screen.
  Florian: Width and height media queries work just fine here.

  Rossen: Where is this going to go into which spec?
  Florian: Round display spec for now, but when both this and the
           natural host are stable enough, can shuffle around.
  Rossen: Action for jihye?
  Rossen: Proposed resolution on having viewport-fit: cover | auto,
          with loose guidance for auto that says the whole Web page
          should be viewable.

  bradk: [question scribe missed ]
  fantasai: proposal is to accept viewport-fit with cover and auto,
            and auto must require that content can be made visible
            and handle pages not designed for round displays.
  fantasai: I agree with this.
  fantasai: One thing w.r.t. contain is some websites where you want
            the whole viewport visible at all times, like a game,
            you don't want the UA to do smart scrolling.
  fantasai: So I think author should be able to opt in to strict
            containment for certain types of things,
  fantasai: pick a rectangle that's inscribed.
  fantasai: What you do with the space outside of that rectangle is
            up to UA.
  fantasai: Can use canvas background, @page background, pick first
            background image, whatever they want.
  fantasai: I think that for certain types of Web pages they might
            want to opt in to having entire viewport always visible,
            in that case contain is your best option.

  bradk: So saying that if there's no scrolling mechanism you should
         always have the entire page visible?
  fantasai: Contain should be about the visual viewport visible
            entirely on screen.
  Florian: I agree with that about making the visual viewport fit in
           the screen; we already have viewport-width:auto to make
           the layout viewport fit in the visual viewport
  <fantasai> 1) Accept viewport-fit with three values: cover,
             contain, auto
  <fantasai> 2) Initial value is auto. UA can do anything it wants
             as long as the content not designed for round screens
             is easily 100% viewable by the reader
  <fantasai> 3) Undefined what is outside the contained viewport for
             'contain'. UA can paint anything it wants, chrome,
             black, canvas background, @page background, photo of SF
             Bay Bridge, whatever.
  Florian: I'd add -- not sure if needs to be part of the resolution
           -- add note that these are early thoughts by the WG.
           Requesting feedback.
  bradk: Note that if you use contain, that most webpages will be
         unreadably small

  RESOLVED: 1) Accept viewport-fit with three values: cover,
               contain, auto.
            2) Initial value is auto. UA can do anything it wants as
               long as the content not designed for round screens is
               easily 100% viewable by the reader.
            3) Undefined what is outside the contained viewport for
               'contain'. UA can paint anything it wants, chrome,
               black, canvas background, @page background, photo of
               SF Bay Bridge, whatever.

  <br duration="calc(15*60s)">

  <MaRakow> Florian, fantasai: noticed before lunch the
            @viewport/@page issue was discussed -- Edge does support
            the mentioned behavior for @viewport but we're not
            entirely satisfied with it -- I think it needs some
            thought on how to make the behavior more understandable
            to authors
Polar coordinates
-----------------
  Scribe: zcorpan

  jihye: So far as we discussed I think there are some ???
  jihye: There is 2 points of disagreements:
  jihye: 1) I think polar-anchor can be used in polar layout
  jihye: 2) the way the polar-origin works
  jihye: Polar-origin can decide the pole of the polar coordinates.
  jihye: The element can be decided by the polar-anchor.

  bradk: Polar-origin you're putting in a value and the end result
         is that the element is shifted over;
  bradk: the current spec it's not shifted over by the amount you
         put in.
  bradk: I'd like that to be more direct, so that if you shift it
         3px to the right, you set the polar origin 3px and 0px (
         rather than -1.5px)
  bradk: I'd also change the name to "nudge."
  bradk: The effect is that you move the element.
  bradk: It's using percentages by itself.
  Florian: So it's anchor?
  Florian: The one that's related to the container is origin,
  Florian: these names are confusing.
  bradk: Yeah.
  bradk: You're right.
  bradk: Origin is relative to CB.
  bradk: Forget what I said earlier.
  Florian: I think what we've said so far, the direction you move
           into is polar angle.
  Florian: The distance and angle work from there.
  Florian: The default is auto.
  Florian: If you set center, the center is of the CB.
  Florian: Polar-anchor lets you use some other point of the element
           to place the element.
  bradk: Percentage resolving is just for the anchor.
  Florian: If we switch to the model you're proposing then it's like
           transforms but in ???
  bradk: You're adding an additional movement to it.
  bradk: The end result is the same, you're just moving it.

  fantasai: Let's say we want to position it ???
  fantasai: The center of the box is 125,125
  fantasai: The positioning scheme that backgrounds use require you
            to ???
  Florian: If you want to be at 25%,25% it would start at 0,0 and to
           do this in polar anchor you do -25%,-25% because you're
           moving the point.
  fantasai: It's what relative positioning does.
  Florian: The difference is whether it's relative to the element
           itself or CB.

  fantasai: I don't like having yet another way to do relative
            positioning.
  fantasai: If we want a generic shift this thing by xxx, we need a
            different way of measuring, not a different way of
            shifting the element.
  Florian: The difference is if we're not doing positioning, we
           already have transforms.
  Florian: The distance that doesn't stick you out of the container,
           not taking transforms into account there is weird.
  Florian: For the sake of polar positioning we need something like
           transforms but happens at layout time.
  bradk: Why do we need it for polar but not in general.
  bradk: We need something that nudges it over...

  fantasai: I want to align this point of the box to another point
            of the container
  fantasai: by default it's the center.
  fantasai: We could say it is like background-position
  fantasai: or we can have a switch between the two.
  fantasai: Yes you can use transforms to get the same effect
  fantasai: but we're not trying to nudge the element.
  fantasai: You only need this if you need the points working
            together.

  Florian: Polar-distance has a switch, which is 100% means don't
           overflow, move as far as you can without overflowing.
  Florian: That operation can't reasonably take transforms into
           account, therefore it can't be using transforms.
  fantasai: Right.
  Florian: Because transforms are out, we need to use polar-anchor.
  bradk: It seems weird that we have this thing that does the same
         thing as transforms but only for this other thing.
  Florian: There are many ways you can move things around the screen.
           This is a different model.

  fantasai: I'd like to drop `??? value and instead have the initial
            value of polar anchor be auto.
  fantasai: So that 50% places it in the center, 100% places it as
            far as it will go without overflow.
  fantasai: If you want to center you say "center"
  fantasai: like backgrounds.
  fantasai: For shifting things around then also allow you to set an
            explicit point.
  Florian: Why doesn't it stick out?
  Florian: For polar-origin: center; polar-distance: 100%
  Florian: That's what contain is for.
  fantasai: ok.
  Florian: There are 2 ways to do that.
  Florian: One can stick out and the other not.
  bradk: I think contain is still weird.
  bradk: What you end up wanting is that the center of the element
         to line up in a circle?
  bradk: Not so much the ends.
  Florian: There are varying behaviors you may want.
  Florian: Sometimes you want it to stick out and sometimes not.

  Florian: I think this is also a tricky discussion
  Florian: If we want an auto value that does some magic but that
           sounds weird to me.
  bradk: Maybe the polar-anchor if it's 100% would be 100% of the
         distance of the polar-distance?
  Florian: ???
  TabAtkins: I'm happy with contain being on polar-distance, seems
             reasonable.
  TabAtkins: Seems like the right place for it.
  Florian: I'm suggesting that when polar-distance is a percentage.
  Florian: We should have a few keywords for what 100% means.
  Florian: Is it against the edge, same distance in all directions
           or follow the edge?
  Florian: Which switches we need can be discussed.
  TabAtkins: Put if far out but make sure you can still see.

  Florian: These switches make sense as keywords.
  Florian: Trying to do that with polar-anchor is wrong.
  Florian: I think using transforms is also wrong.
  Florian: To do nudge instead of anchor, I think that only makes
           sense if there's a usecase outside polar coordinates
           where .... would not work
  bradk: You may want to use it on something else, like animate.
  bradk: That would apply to anything
  bradk: If you need to move it a little bit one way or the other to
         get the position just right, why does it not apply to other
         things?
  bradk: To me it seems if you want to limit it to polar you need to
         justify why it only does that.
  TabAtkins: For round screens you need geometry ????
  bradk: You can use polar-origin to move things around in a box, to
         center it.
  Florian: Polar-distance: 0 puts you in the center.
  bradk: You can use polar-origin and polar-anchor together.
  bradk: People will use them to center or whatever using the
         percentage of the CB.
  Florian: Polar is generic, switching the name makes it more
           general, is your point?
  bradk: Yeah.
  bradk: If you want to move something 3px to the right it shouldn't
         be negative, it should be just 3px.
  Florian: It would be harder to use for the intended use case.

  TabAtkins: Can we move this to hallway conversation? It's just 4
             of you discussing this.
  Rossen: If the conversation has proven to be ineffective for the
          past year we should maybe discuss this.
  shane: Can we give them 2 mins each to present their case. arguing
         like this doesn't help?
  Florian: Should we write or say this?
  shane: Prepare at lunch, present after lunch.
  fantasai: My proposal is what we resolved on in Sydney, it's
            written up.

[Continuation of topic after lunch break]

Scribe: ChrisL

  fantasai: Over lunch, looking at motion-path, open issue for
            motion-origin which pegs a point on an element to the
            path.
  fantasai: Very similar to polar-anchor property.
  fantasai: In fact these are basically the same: polar-angle
            implicitly defines a path
  fantasai: polar-distance is like motion-offset.
  fantasai: So we should combine them, have motion-path accept an
            angle as well, then merge the rest of the properties.
  fantasai: Resolves the issue in the spec.
  fantasai: "and rename all the properties of course" (flames,
            fireworks, kaboom)
  fantasai: (draws on board)
  <dbaron> whiteboard:
https://lists.w3.org/Archives/Public/www-archive/2016May/att-0000/whiteboard.jpg

  fantasai: Also we said, what about making offset-anchor easier so
            make it behave like background-position by making the
            initial value 'auto' instead of center--uses point that
            corresponds to the percentage in offset-origin,
  fantasai: so it takes the same syntax as background-position.
  fantasai: This combines two positioning systems, solves the fact
            that the motion stuff is not actually about motion, and
            we have a combined model
  fantasai: and we can position elements using the background-position
            model which authors are familiar with.

  TabAtkins: You're missing the rotation property.
  fantasai: we can add it
  TabAtkins: We don't need <angle>, SVG has bearing commands now.

  shane: Motion is 0 to 100%, you may need a length value.
  Florian: Keywords like closest side, etc
  bradk: Contain as the default.
  TabAtkins: No contain anymore. And contain in transform space is
             more difficult.
  fantasai: Not sure why.
  Florian: Contain keyword on polar-distance would be on offset-path
           which defines the path.
  fantasai: Origin for path is set by positioning / offset-origin,
            calculate path according to keywords to set the length.
            offset-distance says how far along the path.

  dbaron: Does motion-path have relative vs absolute paths?
  TabAtkins: auto-adds an initial M
  ChrisL: SVG path always defines the starting point of the path.
  ?: motion-path always appends to the transform starting from the
     current position.
  hober: Motion-path is fancy transform, and doesn't affect layout -
         does this?
  TabAtkins: Does not affect layout except for scrollable area.
  hober: ok
  Florian: Other transforms are after motion-path?
  TabAtkins: Yes.

  shane: So we define what a percentage means...
  fantasai: Yes.

  fantasai: polar-distance & motion-offset -> offset-distance
  fantasai: polar-angle -> offset-path
  fantasai: polar-anchor & motion-origin -> offset-anchor
  fantasai: initial value of offset-anchor is auto
  fantasai: which copies the percentages from offset-origin so
            offset-origin behaves like background-position.

  Florian: offset-path newly takes an angle plus a keyword (as yet
           undefined list, including contain).
  bradk: To go out at an angle, the offset-anchor is where?
  Florian: You start where you are.
  bradk: For motion-path it is the center.
  Florian: Same, for straight lines.
  bradk: Not for curved ones.
  jihye: There is also a side.
  Rossen: sounds like a good proposal now.

  RESOLVED: accept current proposal as outlined by fantasai

  shane: names TBD

  <jihye> in current spec of round display, there is <side> value in
          polar-distance
  <jihye> the concept of <side> also can be used in offset-path

  hober: We should tell fxtf that we did this :)

  shane: Apart from naming, this is a functional superset
  shane: The only thing we've changed is (1) addition of angle to
         offset-path and (2) naming.
  Florian: Does offset-origin go into motion path spec?
  fantasai: Spec needs renamed, it is not about motion. It is
            positioning -- path positioning. It can be used to
            build motion if you animate.
  Rossen: Spec to be renamed.
  shane: I can make these changes.
  jihye: Happy with this resolution.
  [and there was much rejoicing]
  fantasai: Add jihye as motion path editor?
  jihye: It would be an honour.

  RESOLVED: jihye added as an editor of Motion Path spec
Received on Thursday, 26 May 2016 00:05:17 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 26 May 2016 00:05:17 UTC