- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Mar 2015 17:47:45 -0400
- 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