W3C home > Mailing lists > Public > www-style@w3.org > March 2015

[CSSWG] Minutes Sydney F2F 2015-02-10 Part I: Rounded Displays

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 18 Mar 2015 17:47:45 -0400
Message-ID: <CADhPm3sNCM_mjAVx-r-Rf5FP8WZDRJUtTJjdAok8EmTaTQZdqA@mail.gmail.com>
To: www-style@w3.org
Rounded Displays
----------------

  - Hyojin Song from LG presented their proposed additions to CSS to
      make it easier to design for rounded displays such as smart
      watches.  The slides he brought to the group are available
      here: http://www.w3.org/wiki/images/8/84/141029_W3C_TPAC_Breakout_Session_Round_Display.pdf
      - Adding a new media query for 'device-radius' was well
          received
      - The new 'border-boundary' property also was well received
          though there was interest and questions about expanding it
          beyond just circular objects.
      - The polar coordinates for layout left many in the group
          uncertain about exactly how effective they'd be and
          several expressed a desire to read the proposed text in
          detail to find out more.
      - There was debate as to if this spec belonged in the working
          group since its properties were meant mostly for
          polyfills, not for browsers, however it was argued the
          expertise is in this working group and that the exit
          criteria can be designed in such a way to allow polyfill
          implementations to count toward achieving REC.
      - Ultimately, the group decided to turn the work that LG has
          already done into an ED and pull properties into other
          spec if necessary as they develop and stabilize.
  - RESOLVED: Add css-round-display as ED

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

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron
  Brian Birtles
  Rick Byers
  Tantek Çelik
  Dave Cramer
  John Daggett (phone)
  Elika Etemad
  Daniel Glazman
  Dean Jackson
  Toru Kawakubo
  Ian Kilpatrick
  Chris Lilley
  Peter Linss
  Cameron McCormack
  Shinyu Murakami
  Robert O'Callahan
  Simon Pieters
  Xidorn Quan
  Liam Quin (phone)
  Florian Rivoal
  Andrey Rybka
  Dirk Schulze
  Alan Stearns
  Jet Villegas
  Greg Whitworth
  Johannes Wilm
  Steve Zilles

Rounded Displays
================
Scribe: TabAtkins

  <glazou> https://www.w3.org/wiki/TPAC2014/SessionIdeas#CSS_Extensions_to_support_a_round_display
  <glazou> http://www.w3.org/2014/10/29-rounddisplay-minutes.html
  <glazou> http://www.w3.org/wiki/images/8/84/141029_W3C_TPAC_Breakout_Session_Round_Display.pdf

  Hyojin: My name is Hyojin Song, working at LG's Software Platforms
          Lab.
  hyojin: This is the first time for LG to present something to the
          CSSWG.
  hyojin: We have WebOS, embedded in TVs and watches.
  hyojin: LG personally released a watch with WebOS last January.
  hyojin: The platform is the web.
  hyojin: Like HTML, CSS.

Scribe: fantasai

  hyojin: HTML and CSS should support some requirements to present
          web content to web-based device.
  hyojin: LG smart watch display is round.
  hyojin: When developing apps, we have some difficulty aligning
          contents in the device this way.
  hyojin: So we would like to propose some ideas for round display.
  hyojin: This is a slide presented last TPAC.
  hyojin: I'm going to briefly show you the concepts of our ideas
          using this slide.

  hyojin: New devices with are round screen are emerging.
  hyojin: Here are 4 devices: ASUS ZenWatch, Moto360, LG G Watch R,
          LG G3 when cover is closed.
  hyojin: Web was designed for a rectangular screen, especially CSS.
  hyojin: Here are some LG watch applications [photographs] compass
          app, weather app, phone dialer, etc.
  hyojin: CSS should make these applications.

Media Queries
-------------

  hyojin: We have 4 ideas.
  hyojin: First is extension of media query.
  hyojin: Detect a round display.
  hyojin: Defined a 'device-radius' property, inspired by
          border-radius.
  hyojin: We made a specification like this. Very immature, but we
          have summarized here
  [projects spec draft]
  <dbaron> is there a URL for that spec?
  hyojin: Takes same syntax as border-radius.
  hyojin: 0% is rectangular display.
  hyojin: Round display.
  hyojin: It can detect the shape of the display.

  Florian: I think the MQ is quite reasonable
  Florian: How complicated or simple do we want to be?
  Florian: There's a clear real use case for rounded display
  Florian: What do we do about e.g. triangle display or whatever?
  fantasai: We have proposals for addressing this for borders,
            triangles for example, changing the shape for the
            corners.
  fantasai: This approach is fine and we can extend as we need.

  glazou: Devices for mobile are changing very rapidly.
  glazou: Change shapes in 2d, but also in 3d, e.g. rounded surface.
          Display is different on the curve.
  glazou: The first bendable screen just appeared.
  glazou: It will reach a completely new set of characteristics of
          screens that we will need to cover in the future.
  Florian: This works for rectangle, rounded rectangle, ellipses,
           but what else?

  roc: Do we have the goal of only detecting what shape it is and
       use MQ to create different layouts for each shape?
  roc: Or create layouts that will adapt to any shape?
  roc: MQ will help with the first, not the second.
  roc: Need to decide on goal, one or other or both.
  hyojin: device-radius is limited in expressiveness.


Rounded Flows
-------------

  hyojin: Next topic is content alignment.
  hyojin: CSS shape-inside.
  hyojin: In rectangle display like this [floats and text in
          rectangle].
  hyojin: If you put it on a round display, the corners cannot be
          shown on the display.
  hyojin: We want the content to flow inside the shape, like this
          [photo].
  hyojin: We extended shape-inside like this: add value 'display'
  [hyojin shows content flowed into a circle]
  [hyojin shows content that starts partway down the screen, wraps
          into the semicircle of the bottom of the screen]
  hyojin: We didn't implement in browsers, we automatically generate
          the shape like this [shows code].

Fitting Boxes to Screen Shape
-----------------------------

  hyojin: Next topic is border.
  hyojin: Borders extend outward from the edge of the screen, want
          it to fit in the screen.
  hyojin: So we defined new 'border-boundary' property, values
          'none' or 'display'.
  Florian: Did you consider keyword to make shape-inside and
           border-boundary to match?
  astearns: I think it's a different problem they're trying to solve.
  astearns: They're trying to get the children's border to match the
            contours of a parent's shape-inside.
  Florian: Exactly. Parent has shape-inside: display.
  Florian: The children match the shape-inside of the parent,

  tantek: This feels like a position: fixed approach.
  tantek: Relative to display
  tantek: vs. position: absolute, where relative to some other block.
  dbaron I think it would also be possible to inset the borders as
         you go down the tree.
  dbaron: Propagating the shape down based on margin/padding/border.
  rossen: You gotta be able to find the shape going down. Display is
          only one of the shapes as you're going down.
  hyojin: Many issues, something to consider, so we wrote the issues
          in the spec.
  hyojin: I will share these materials into the CSS mailing list.
  hyojin: We can discuss topics of round display issues.

  hyojin: Last one is about layout features.

  Rossen: Back on the borders:
  Rossen: This is easy to explain for solid borders.
  Rossen: What do you expect the behavior to be for, e.g.
          border-styles other than solid.
  Rossen: Say I have a dashed border-right and a dotted border-top
          border.
  fantasai: Probably same way as you solve it for border-radius.
  Rossen: If it's round-ish, that works, what if it's a star?
  Florian: It will require wordsmithing, but not an unsolvable issue.
  fantasai: Take 45deg from center, find that point on the shape, or
            some other formula.
  hyojin: Using canvas, I can draw different border shapes.

Polar coordinates
-----------------

  hyojin: Last one is layout
  hyojin: We propose polar coordinates, to position around circle
          like this.
  hyojin: polar-angle and polar-distance properties with position:
          polar e.g. 'polar-angle: 225deg; polar-distance: 100%'
  krit: Positioning only, or other layout?
  hyojin: Just positioning

  * heycam wonders if this could be done as part of transform
  <dbaron> heycam: maybe better as a transform item, an alternate
           way of specifying a translate

  TabAtkins: Other than the fact that 'position: polar' would go on
             the children, not on the container (be just like
             alternate version of abspos), looks good to me.
  dino: Which point is positioned at that point?
  fantasai: polar-origin property to determine it. It should take an
            'auto' value maybe that does automatic anchoring like
            backgrounds do
  glazou: Rounded display on a sphere, turning, ...
  [missed]

  glazou: Why polar coordinates instead of transforms?
  hyojin: We developed this using transforms.
  hyojin: I think the developer can make applications like this
          easily.
  TabAtkins: One nice thing about this is that you can animate this
             very nicely.
  TabAtkins: E.g. spiraling outward much easier.

  tantek: This example makes it looks like the distance: 80% was
          very carefully chosen to make it look like there is
          padding is on the parent that the children bump up against.
  tantek: Feels like a very fragile way of doing it.
  tantek: If you change the font size, or the radius of the
          elements, it will no longer fit nicely.
  tantek: I wonder if percentage-based distance abspos is what you
          want, or some model of polar box model.
  TabAtkins: You can always do calc(100% - half-of radius).
  Florian: Yes if you know your radius.

  fantasai: If you have the ability to set origin the way
            backgrounds do, then you can take the size into account
            as positioning.
  tantek: abspos does a nice job of taking into account
          borders/padding.
  tantek: abspos lets you do positioning from the edge without doing
          calc etc.
  tantek: I would challenge this to be as simple as abspos.
  fantasai: You might want to have border/padding consideration,
            yes, but if you can do positioning like backgrounds then
            you can do offsets and positioning that take into
            account the size of the item.
  fantasai: Abspos doesn't do e.g. centering without knowing the
            size of the box. Background positioning can do offsets,
            but also more than that.
  dbaron: Absolute positioning is pretty fragile in most cases.

  <tantek> The example shown looks like it is pushing the child
           elements to the edge of the padding of the parent -
           automatically - without having to magically pick 80%.
  <tantek> I would like to NOT have to pick 80% based on the radius
           of the child, parent etc.
  <tantek> and rather do it like abspos where you it takes into
           account both the padding of the containing block, and the
           border of the child.
  <tantek> My point was it should be NO WORSE than abspos.
  <tantek> If we can do better, great.

  zcorpan: My point was already said by fantasai:
           background-positioning can do offsets

  dbaron: I would not want to follow abspos as a model
  dbaron: We've done a lot of things with layout systems that do
          more flexible and produce better results.

  roc: Since this is easily polyfillable in its current form,
  roc: Maybe we produce better custom layout and style integration.
  roc: Do this instead of adding it to the CSS core.
  roc: If this has to go into CSS core, then what wouldn't?
  glazou: Even for polyfills, 2 different editors of polyfill for
          this would like to rely on the spec.
  roc: Could have a spec for features that are implemented in
       polyfill rather than in browsers.
  roc: Need to be clear about which it is, makes a big difference to
       constraints around the design.

  SteveZ:...
  SteveZ: If I consider a center an edge and an angle, it has all of
          the properties that you want.
  SteveZ: Could talk about edge shape.
  SteveZ: Adjusting along an angle-line, either toward the center or
          toward the edge, and has exactly the same set of
          properties abspos has today, and you could even use it for
          squares.
  SteveZ: So you could use it for better positioning.
  tantek: Goal is to avoid collisions by default.
  SteveZ: If you want it to touch the outer edge, you say 0 on the
          outer edge, same as you do with picking
          left/right/top/bottom
  SteveZ: Same rules as abspos.
  SteveZ: Center, you may want a different rule, e.g. center me on
          the center.
  SteveZ: TabAtkins's point was that it generalizes the same way.

Editorship
----------

  hyojin: In future, we will need extensions for smart watch.
  hyojin: I think these are reasonable.
  hyojin: Will send this to CSS ML, and will collect problems from
          developers making round display. I will share with CSS WG.
  hyojin: Thank you.
  glazou: Thank you for the presentation.

  glazou: The way you are expecting to contribute to the document,
  glazou: Are you requesting an Editors Draft at this point?
  hyojin: Yes, we'd like to publish this.
  Florian: I'm happy about including these ideas, but many of these
           look like they belong in existing documents.
  Florian: E.g. put rounded display MQ into the MQ spec
  glazou: We could do that, or until things stabilize a bit more,
          keep them in a separate document.

  glazou: A partial solution is not enough for LG.
  glazou: So I think for the time being, keep it all into single
          editors draft, and as soon as they stabilize dispatch them.
  glazou: Proposal is new ED with editor as LG.
  <tantek> agreed with keeping it all together in a first editor's
           draft
  fantasai: Shortname?

  roc: Might be good to have a spec for all of coordinate layout.
  roc: If it's not in a browser, then doesn't need to go through W3C.
  glazou: We have a way to say a spec is not required.
  roc: Could have the polyfillers standardize in a decentralized way.
  roc: CSSWG's expertise is useful, but that is also useful.

  glazou: LG is leading the effort, but it is clear that other
          vendors with rounded display watches will have exactly the
          same issue.
  glazou: Application authors wanting to address these devices will
          want a standardized way to develop apps.
  ChrisL: W3C is about interop and getting people to work together.
          It's not about browsers only.
  ChrisL: It's better that people liaise with us, and it's better
          that we can comment and say in 5 minutes "No, no don't do
          that! Do it this way"
  ChrisL: than they continue down.
  ChrisL: They've the taken initiative to come here, we should
          reciprocate.
  glazou: And the expertise on CSS is here.
  <ChrisL> open source round display watch (failed kickstarter)
           https://www.kickstarter.com/projects/958981650/the-pi-watch-a-programmable-open-source-smartwatch

  SteveZ: First, there is a cost to doing this, which is it takes us
          time to review each of these specs.
  SteveZ: It's not zero cost.
  SteveZ: There is also a benefit, which is people here have
          knowledge about how to put things into CSS in a CSS-like
          way.
  SteveZ: We've had several discussions through the day, where
          people make comments on how ... e.g. dbaron's comment
          about unstyled divs and spans being no-ops.
  SteveZ: It's good to discuss these so that we don't make it
          difficult to extend CSS in the future.
  SteveZ: I'm of the opinion that we should do the spec, and don't
          care how it's implemented.

  Florian: Just as MQ spec editor, I just want to say I'm happy with
           either approach.
  Florian: If you would like in MQ draft, would be happy to help.

  tantek: I would partially agree with SteveZ's observation that our
          review is beneficial.
  tantek: Part of me also wants to see more rapid experimentation,
          even if solutions are imperfect.
  tantek: To use that to learn from the use cases.
  tantek: To experiment e.g. how do we get things to not overlap.
  tantek: Learning how problems occur in this kind of layout is
          itself valuable.
  tantek: I want to avoid discouraging experimentation.
  tantek: Specifically avoid scenario of numerous webkit properties
          being thrown out there
  tantek: without any discussion with WG.

  krit: Do we have a way for extending MQ?
  TabAtkins: Yes.
  ChrisL: You can link things up by having a note in MQ pointing to
          the other draft.

Polyfills as implementations
----------------------------

  glazou: This only raises one question about what we call an
          implementation.
  glazou: We shall now consider a polyfill as an implementation.
  ...
  ChrisL: So you think the wording needs clarification that it
          qualifies.
  dbaron: I think that maybe requires more clarity about which specs
          are expected to be implemented in browsers vs. polyfills.
  dbaron: polyfill should be a valid implementation for the latter
          type of spec.
  fantasai: I don't see why there needs to be a distinction.
  dino: How many browsers does it have to work in?
  roc: Implementation in a browser uncovers more interaction
       problems, that a polyfill might not notice or might not even
       run into.
  Florian: As an answer to this, when we count a browser to continue
           passing previously-passing tests.
  roc: The issue is with interaction of features, e.g. combine
       multicol with X and it explodes.
  roc: Feature A and Feature B both work, but A+B explodes.
  zcorpan: There are also different constraints between browser and
           polyfill.
  zcorpan: A polyfill doesn't have to care about optimizations in
           the browser, like the preloader.
  zcorpan: If it does all of its work after all the document is
           loaded
  zcorpan: A native implementation might want to do the work during
           parsing, when element is inserted into DOM
  glazou: Would it be acceptable to say that for now a document that
          is aimed only at polyfills accept polyfills as a valid
          implementation.
  fantasai: I'm concerned that if we design specs only for
            polyfills, we will end up with specs that *can't* be
            implemented in browsers. What if we decide it ought to
            be folded into the core?
  Florian: ???
  dbaron: If a REC says it's designed for polyfills, then sure, we
          might need to change it in order to produce a REC that can
          be implemented in browsers.

  ChrisL: Sounds like we had weak consensus on allowing polyfills as
          implementations, then discussed having polyfill-specific
          spec,...
  ChrisL: You really don't want to have to move around your code.
  ChrisL: We run into the prefixing issue again.
  TabAtkins: Polyfilled properties are --foo anyway, so you have the
             prefixing built into the polyfilling
  ...
  heycam: Standardized version in a browser isn't triggered by that
          property.

  krit: We do not have custom layout.
  krit: We have to decide on this proposal right now. Very
        interesting discussion, but doesn't help LG right now.
  TabAtkins: Custom layout will be the hardest part of Houdini, so a
             long time from now.
  TabAtkins: If custom layout existed today, maybe there would be a
             different approach, but doesn't exist right now.
  TabAtkins: Let's do this simple stuff.

Editor's draft
--------------

  glazou: Sounds like return to LG, push other stuff to ML.
  Florian: What does LG want wrt splitting?
  krit: I think it should stay in the same document.
  glazou: I'd like to review that document.
  <dbaron> The part of the document I'm most concerned about is the
           polar coordinate layout bits.

  glazou: New editors draft for this?
  fantasai: I'm in favor
  <tantek> +1 new editor's draft
  tantek: me too
  dbaron: I'm in favor, but I'm concerned about polar coordinates.
  fantasai: Yes, I think it needs work.
  * ChrisL looks forward to seeing the polar coordinate stuff
  tantek: Decide on a place for issue to be captured, and ED to link
          to that,
  glazou: In the document.
  tantek: File issues and not block publication.
  Florian: Send mail to www-style.
  ChrisL, glazou: Don't see how this is different from previous docs
  tantek: ...
  ChrisL: So you're encouraging use of that existing rule [ to
          indicate tracker ]
  <tantek> Florian: this has nothing to do with sending email
  <tantek> This has to do with requiring a link from the editor's
           draft to a *specific* place for tracking issues, e.g. W3C
           Bugzilla, Tracker, or a Wiki page

  [bikeshedding shortname]
  [css-round]
  [css-rounded-display]
  Rossen: css-o
  dbaron: It's a focused-enough specification that it should have a
          longer shortname
  <dauwhe> css-round-display
  <fantasai> +1 to css-round-display
  <ChrisL> +1
  <tantek> css-polar?

  RESOLVED: Add css-round-display as ED
Received on Wednesday, 18 March 2015 21:48:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:30 UTC