- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 Mar 2016 17:31:36 -0400
- 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.
=========================================
Round Display
-------------
- RESOLVED: Add radial-gradient <side> keywords to polar-distance.
Mark issue for how to get e.g. from top left corner,
100% of shortest side.
- There was some uncertainty about how 'contain' should behave in
relation to the previous resolution and in general. However,
it was decided that decisions on if 'contain' should be a
default behavior should wait on a final definition.
- The existing proposals for addressing polar positioning and
abspos were discussed, but there were still unanswered
questions .
- An outstanding concern that the mental model for this was
the opposite of the mental model for the rest of CSS.
- A proposal developed to drop polar-origin and instead use
alignment to achieve the desired effect.
- RESOLVED: Make the following changes:
1. Remove 'polar' value of 'position'. Polar
positioning applies to absolute/fixed/static/sticky/
relative positioned elements
2. Remove 'auto' value of 'polar-distance'. Initial
value is 0
3. Add 'auto' value to 'polar-origin'. This means find
the origin using normal rules for absolute/fixed/
static/sticky/relative positioning.
4. Make 'auto' initial value of 'polar-origin'
5. Add an open issue as to whether top/right/bottom/
left properties are ignored or interpreted somehow
when 'polar-origin' is not 'auto'.
NOTE: polar-origin doesn't apply to relatively-
positioned elements.
(Or mark an issue for making it apply somehow).
- Joone presented a proposal for supporting 3d transforms in round
display. However, there were two major issues with this
proposal:
1. Transforms aren't a positioning system. This proposal
presumes that they are.
2. Need use cases for what 3D polar coordinates.
- However, there was agreement that it might be interesting to
add functions for using polar-positioning-like syntax as an
alternate way to express existing transforms.
- The ability to support scrolling on a round display would best
come from some of the scrolling work being done in Houdini.
- Since most pages are not designed for round displays,
browsers on such devices simulate a rectangular viewport
by designating a fully-visible area of the display.
For pages that are prepared to handle the constraints of
working with a round display, it was suggested to add
an @viewport switch for authors to opt into the full viewport.
- RESOLVED: Publish new WD of Round Display, with
polar positioning resolution incorporated (@viewport
for next publication okay)
- The discussion from Sapporo about device-radius was revisited;
originally it had been concluded that the query would no
longer return a radius, but instead return if you're visible
or not.
- There was concern from LG about complexity and
implementability
- There was a suggestion that a qualitative query for
"roundish" vs "squarish" would be useful, regardless.
- Florian will write up a proposal for this new media query.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sydney-2016
Scribe: fantasai (with gregwhitworth scribing when fantasai spoke)
Round Display
=============
hyojin: I think if Web support various technology with display
shape, a variety of products will adapt web-based platform
OS in near future.
hyojin: LG webOS is one of the platforms, and CSS Round Display is
starting point in W3C.
hyojin: Some polar issues.
Percentages of 'polar-distance' when origin is not the center of the
containing block
---------------------------------------------------------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Jan/0152.html
jihye: First issue is about percentage of polar distance when
origin is not the center of the containing block.
jihye: This issue was action item at Sapporo meeting.
jihye: We need to define clearly about percentage of polar
distance when origin is not center.
jihye: When origin is not the center, the distance between the
origin of polar coordinates and edge of the containing
block varies according to the value of polar angle.
jihye: With this method we have to assume that the shape of the
containing block is inscribed circle for applying the
method to round display.
jihye: We also have to use polar positioning for rectangular
containing block.
jihye: But aligning elements here seems to be strange.
jihye: Because if there are elements with elements with same
percentage but different polar angle, they create an
alignment in rectangular shape.
jihye: This is not an appropriate polar positioning.
jihye: We discussed about this problem and we got a reference of
radial-gradient().
jihye: So I suggest to specify percentage with extra keywords, e.g.
closest/farthest-side/corner
<jihye> polar-distance : [closet-side | farthest-side |
closest-corner | farthest-corner]? <percentage>
Florian: Looking at various use cases to see which is the correct
definition of percent.
Florian: Different use cases give different answers.
Florian: Sometimes you want to follow the shape around you.
Florian: Sometimes you actually want a circle.
Florian: So having a choice among these four,
Florian: allows different circles.
Florian: And if you omit these keywords, then you do follow the
shape.
Florian: So on each angle, 100% gets you to the edge.
Florian: If you are in a rectangle, you move in a rectangle, get
to the edge.
Florian: Sometimes this is what you want.
Florian: Sometimes this is what you want, but sometimes want to
move in a circle.
Florian: So having theses keywords, plus option to omit keyword,
Florian: We get 5 behaviors instead of 1.
Florian: Because I think one doesn't solve the use case.
Florian: And we reuse familiar syntax.
BradK: I can see how closest-side would be used. When would you
use closest-corner or furthest-side? Seems like you'd get a
lot of clipping.
Florian: Would use if you are in a corner, use closest-side.
fantasai: Seems problematic, because you want the shorter (?) side.
Florian: If you're in a corner and use closest-side, result is the
corner (0), then want farthest side.
BradK: I think closest-side seems useful, unsure about the rest.
Florian: Seems to be most useful, yes, but if borrowing
radial-gradient(), just take the whole thing
<fantasai> polar-distance: <side>? <percentage>
jihye: I think this covers all cases developer would want.
jihye: Can we define polar distance by this method?
fantasai: It's a good direction to go in, I'm a little concerned.
fantasai: If you have a point in the top left corner of a
rectangle, and you want 100% to along the short side, I
don't see how you would do this because closest-side
would give you 0, but farthest-side would get you too far.
Florian: It would take us away from radial-gradients, but maybe it
should be closest non-zero side.
Rossen: Definitely moving in right direction, might be some
additions to it.
Rossen: But mostly okay with this.
Rossen: Any objections?
RESOLVED: Add radial-gradient <side> keywords to polar-distance.
Mark issue top left corner, asking 100% of shortest
side, how to get that.
Revisiting 'contain' keyword in relation to the previous topic
--------------------------------------------------------------
Florian: We currently have a 'contain' keyword adding to
percentages for avoiding overflow,
Florian: Without it, cause overflow.
Florian: The 'contain' keyword modifies this to make 100% the
point where you would just not overflow.
Florian: I have nothing to say behavior difference.
Florian: I have a worry about which is the two is the default.
Florian: I'd rather have no keyword doing the 'contain' behavior,
Florian: and add 'unsafe' to do overflow.
BradK: I think we should revisit 'contain'.
BradK: I don't think it's very effective at placing things where
you want them.
BradK: If you have a clock face with square numbers, the 6 will
be really close to bottom,
BradK: but something like 10, in order to contain the corner,
will throw the center of the 10 closer to center of the
dial than anything else.
BradK: I think you really want the center of the numbers to all
align along a circle, but you don't get that.
Florian: Round the corners.
fantasai: No BradK's right.
BradK: That doesn't sound like a good general solution. Doesn't
make it useful.
BradK: Don't always want squares, either. E.g. a 3 is much
narrower than 12.
BradK: Would be better to have 100% means put center along the
curve, then move in by half the height or something like
that.
[confusion]
BradK: The way it's spec right now, 100% without contain puts the
center of the element along the path of the circular
container, right?
BradK: If you're dealing with numbers on a clock face, all the
same, they're all the same height, so you can take half
that height and move it back by that amount,
BradK: And then it would be contained.
BradK: That would be better than have corners poking in more than
sides do.
Florian: Height doesn't work in [???]
BradK: If it was always half the height, and all the same height,
then they would all move in by that amount.
Florian: But that wouldn't be sufficient to avoid overflow.
Florian: If wider than tall, half the height isn't enough to move
inward.
SteveZ: [mumbles something]
BradK: Don't have a perfect solution, but I think we need to think
some more. Because the one we have right now isn't a great
solution.
* fantasai agrees with BradK
SteveZ: Instead of half the height, could do half the largest
dimension.
SteveZ: Has to be the same for all of them.
Florian: We don't have that, though.
* fantasai thinks shape-outside might be useful here.
BradK: You'd have to have a fixed width, might have overflow
because numbers wider than you anticipated....
Florian: I think there is more work needed on definition of
'contain'.
Florian: Also need to take into account whether or not we care
about rounded corners,
Florian: or shape-outside,
Florian: or shape-inside.
Florian: But assuming we have a 'contain' behavior, would rather
it be the default.
Florian: Regardless of how we define it.
Florian: Maybe reserve judgment of that until we have a precise
definition?
BradK: I don't feel strongly one way or another.
BradK: Sometimes want one or the other.
Florian: My concern is not that, but what happens if the user has
a differently sized screen and author didn't think about
it.
Florian: If author didn't ask for overflow, let's not overflow.
BradK: I think I'll reserve judgment until we had a better
definition of 'contain'
* fantasai agrees with BradK
Florian: Okay, let's work on contain more until deciding whether
it's the default.
polar positioning and abspos
----------------------------
jihye: Next issue is polar positioning and abspos
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Jan/0134.html
<hyojin> Also refer to this written by BradK yesterday:
https://lists.w3.org/Archives/Public/www-style/2016Feb/0002.html
jihye: There was an idea of making polar-distance and polar-angle
with abspos.
jihye: So polar-position properties used with abspos,
jihye: Use of polar positioning is changed.
jihye: If polar-distance isn't auto, then can be polar-positioned.
jihye: If any property among left/top/right/bottom isn't auto
value, any of polar-* property is ignored
Florian: polar positioning is activated if polar-distance
properties are not auto and TLBR are auto.
BradK: I've evolved my position on that based on the alignment spec.
BradK: With alignment spec, you are using the TLBR to create a box
that something can be centered in.
BradK: So needing something to be non-auto doesn't really come in
any more.
BradK: Last email I wrote, detailed how it would work.
BradK: If you start at top and work your way down, top part is
least controversial.
BradK: I think we agree that using position: absolute or
position: fixed or position: relative would be good.
BradK: Instead of having a separate polar positioning spec that's
the same as absolute except that it pays attention to polar.
BradK: The only really other thing different about polar
positioning is that it centers things.
BradK: If box alignment centers things, then we free up polar
positioning to move things at an angle.
BradK: You can decide to center something, move something at an
angle, or not.
Florian: So?
BradK: Covers all the use cases.
* fantasai thinks this makes sense, but isn't 100% clear because
didn't catch up on this email thread.
jihye: I think when we use polar positioning on some elements,
jihye: We have to set origin point to define distance and angle.
Florian: Question is do you do that automatically, or use
alignment first and then?
Florian: Should ?? be magic or manually?
BradK: Manually with existing properties. Otherwise you have 2
properties that by themselves that center.
BradK: If you use position polar, same as using center alignment.
BradK: If we have a way of centering, we have a way to make
off-center with TLBR.
BradK: We don't need a separate thing to make it center.
BradK: To move it at an angle, you don't really need to have a
concept of a center point or polar coordinates.
BradK: You move the whole thing at that angle / distance.
Florian: I'm a bit conflicted.
Florian: On the one hand, I completely see how this works.
Florian: On the other hand, the properties we have for doing the
centering.
Florian: Are in a fairly different mental model than when we're
doing in polar coordinates.
Florian: I'm not sure it makes sense to author to mix these two.
Florian: Alignment isn't something you think about when doing
polar positioning.
Florian: Not sure what I think.
BradK: I think forcing person into different model is polar
coordinates, very different from CSS coordinates in general.
BradK: The effects are centering, and moving at an angle.
BradK: Don't have to change the 0, 0 no longer top left left, now
in the center.
BradK: Don't have to think about that.
BradK: Question is do I want centered or not?
BradK: Independent thought of moving it at an angle.
BradK: Cutting corner across a right angle.
BradK: Could do same thing with TLBR properties.
BradK: Don't have to change my mental model.
BradK: Don't need to use left and top to move at a 45deg angle
anymore, just use polar-angle and polar-distance.
Florian: My assumption here is that even among the people who
write CSS, more people have an intuitive understanding of
polar coordinates that they learned in middle school than
how CSS layout works.
Florian: Not that people have advanced understanding of math, but
that much they do.
plinss: I think you're overestimating people.
plinss: I think more people understand CSS than understand polar
coordinates.
Florian: ...
BradK: We went over this with radial gradients.
BradK: 0deg is at top.
BradK: Not changing the coordinate system,.
BradK: Origin is still top left corner [?]
fantasai: If I understand correctly, let's drop polar-origin and
position things with alignment, then use that as your
origin for moving with polar-distance.
fantasai: I think there are use cases for that, and what happens
if you want your origin to be something other than the
center or the edge, that's really hard without the coords.
fantasai: I think BradK has a great point though, and I think it's
worth separating these things out.
fantasai: I can see also how you would want to have a polar
positioning.
fantasai: You could make the initial value the polar origin be
auto which would mean do your abspos layout like normal,
and use the result as your origin.
fantasai: If you then have polar origin set to a specific
coordinate then that becomes where you start from.
fantasai: You can then share polar-angle and polar-distance among
all of the different layout models.
fantasai: For relpos you would probably ignore the polar-origin
property, but for fixed and abspos you would look at
polar-origin.
BradK: You would have two different ways for centering then.
fantasai: I think there will always be many ways to center
something though.
fantasai: Centering in the future will be possible in many
different ways which is ok.
plinss: I like the proposal but I don't think it should just be
polar-origin.
<franremy> BradK Florian fantasai: Are there written examples of
both proposals, to see which one is more compact? I
fear the normal-css way might be too long to write, but
I am not sure.
BradK: After leaving alignment, I don't see the need for
polar-origin, because you can just adjust the size of the
box you're centering in [by using the offset properties].
plinss: I like the idea fantasai is talking about
plinss: But don't think it should be restricted to polar
plinss: Why not change the origin in any other mode?
fantasai: I don't understand, there is no origin in any other mode.
fantasai: That's defined by the writing mode and the rectangle.
fantasai: There's no numbers, so the align properties don't have
lengths, cords etc - they're just keywords and you're
working off of the rectangle.
fantasai: It's not really an origin system.
BradK: If you want center to be move dot the left, use the right
property.
plinss: Just because we don't have ability to set something.
...
fantasai: I can you give a better example.
plinss: I want to have a box where 1/3 of it is going to align on
this point.
plinss: Can't do that today.
Florian: So you're asking for polar-origin + polar-anchor.
Florian: So you say polar-anchor: 33%; polar-origin: <coordinate> ?
plinss: I don't think we should restrict to polar positioning.
Florian: I don't think I can agree or disagree so long as you're
being this vague.
BradK: That's what I was describing before in earlier emails.
BradK: I did have the idea of polar origin, which I was calling
'center', that could position things based on their center.
BradK: You could' move this center with property, 'centerpoint' or
something.
BradK: Could position item based on any point in the item and any
point in the containing block.
BradK: Would get same effect of putting 1/3 of element to align
with top center of CB, or whatever.
Florian: General idea of what Brad and Peter are describing does
sound reasonable to me.
Florian: But not convinced until more concrete.
Florian: Didn't like the concrete proposal of Brad earlier.
Florian: Maybe a different proposal would be better.
SteveZ: It's very similar to character alignment for images in
inline.
SteveZ: In this case alignment to a baseline, but conceptually the
same kind of idea.
Florian: I think you're generalizing too much here :) But see
where you're coming from.
SteveZ: It's taking what an alignment point would mean in inline
layout vs block layout.
SteveZ: Still the same 1/3 in 2/3 down kind of point.
Florian: I stand by my previous remark :)
Rossen: What is the current favorite proposal?
Florian: I think we have general agreement for making polar
positioning work in absolute/relative/fixed.
Florian: Don't have agreement on how to get to center.
Florian: My favorite concrete proposal so far is fantasai's.
Florian: But interested to see what Brad and plinss have to propose.
jihye: I agree with generalizing polar origin.
fantasai: I think, if we go with the proposal that I had, there is
no new property. It could be renamed.
BradK: Could be renamed. It's not necessarily polar.
BradK: position-origin might be better.
BradK: I was suggesting that this could even be a transform
function.
BradK: It doesn't even really need position, could just transform
something with angle movement.
BradK: Could stop having to change your mindset.
BradK: Different than start point
fantasai: You may want them to cascade separately.
fantasai: If they have hover effects mixed in with layout, that
makes it awkward for the author, transforms should just
be a graphical thing on top.
Florian: My proposal would be, 1. Resolve on what fantasai
proposed earlier, with the understanding that we will
explore generalizing it further.
Florian: I think bradk and peter have some interesting ideas,
Florian: But what fantasai proposed is a clear improvement over
what we have so far,
Florian: So I'd rather have that in the spec,
Florian: and then improve from that.
BradK: Do we have to call it polar-* ?
Florian: I haven't seen an obviously better name proposal, so I
think we should discuss that from a better starting
point, from what fantasai proposed.
Florian: This way reduce the problem space.
Florian: And then make concrete steps from a concrete proposal.
BradK: Sort of agreement on the list to have this be part of
positioning anyway.
Florian: Let's turn this into a concrete set of resolutions.
Florian: I think what fantasai proposes is a clear step up from
what we have so far, so let's take that step and then
move forward from that.
fantasai: To summarize:
fantasai: Add the 'auto' values to polar origin
fantasai: Apply the polar coordinates to all positioning schemes,
not just 'static', and remove 'polar' value.
fantasai: 'auto' on polar-origin, would the be the initial value
and would have them do normal layout.
fantasai: polar-distance initial value becomes 0, remove auto value.
Florian: The definition of "how does polar origin work" in that
model, if you are in anything but position bsolute/fixed,
it does nothing
Florian: If you are in position absolute/fixed, when polar-origin
is non-auto, you do that instead of the traditional way
of finding your position.
Florian: I'm in favor of this proposal.
BradK: What happens when you have align-self: center?
Florian: If you're in abspos, self-align: center; justify-self:
center; and polar-origin: auto
Florian: Then you center through the alignment props
Florian: If polar-origin is non-auto, you ignore align/justify
self and instead do what polar-origin says to do.
Florian: That's the model. And again, we can look into further
generalizations, but the model currently described is this.
jihye: When polar origin is not auto, what happens to the TBLR
properties?
fantasai: We could ignore them, or we could use them to reduce the
size of the box in which you're positioning in.
BradK: Or could just pay attention to top and left.
fantasai: no, no.
fantasai: I don't like using only half of this set of 4 properties.
Florian: So I propose we resolve on the proposal, and then mark an
issue of what happens with top/bottom/left/right
<fantasai> Proposed Resolution:
1. Remove 'polar' value of 'position'. Polar
positioning applies to absolute/fixed/static/sticky/
relative positioned elements
2. Remove 'auto' value of 'polar-distance'. Initial
value is 0
3. Add 'auto' value to 'polar-origin'. This means find
the origin using normal rules for absolute/fixed/
static/sticky/relative positioning.
4. Make 'auto' initial value of 'polar-origin'
5. Add an open issue as to whether top/right/bottom/
left properties are ignored or interpreted somehow
when 'polar-origin' is not 'auto'.
Rossen: So current proposal is resolve on the proposed resolution
above, points 1-5
Rossen: Any objections?
Bert: I'd like to propose a modification.
Bert: I wonder if it isn't more intuitive to put the 'auto' on
'polar-angle' instead of 'polar-origin'.
fantasai: No, the auto value is on the origin because it allows
all of the other layout modes to work.
fantasai: *gives an example*
fantasai: The distance and angle being auto doesn't make sense.
fantasai: Once the origin is set by the default layout modes, then
you can use distance and angle to position it.
fantasai: In that case you can set it to center, or use the
alignment props.
fantasai: But you have to ask for it to be the center, but polar
position will always work generically.
fantasai: So the initial behavior has to be backwards compatible.
fantasai: It's through a switch that makes the polar coordinate
capabilities become possible.
<BradK> Distance and angle can both be 0.
Bert: I think I have a misunderstanding of what fantasai is
proposing, I'll figure it out later.
Rossen: Back to objections on proposed resolution?
BradK: No objection.
RESOLVED: Make the following changes:
1. Remove 'polar' value of 'position'. Polar positioning
applies to absolute/fixed/static/sticky/relative
positioned elements
2. Remove 'auto' value of 'polar-distance'. Initial
value is 0
3. Add 'auto' value to 'polar-origin'. This means find
the origin using normal rules for absolute/fixed/
static/sticky/relative positioning.
4. Make 'auto' initial value of 'polar-origin'
5. Add an open issue as to whether top/right/bottom/left
properties are ignored or interpreted somehow when
'polar-origin' is not 'auto'.
NOTE: polar-origin doesn't apply to relpos. (Or mark an
issue for making it apply somehow).
Polar properties as CSS transforms function
-------------------------------------------
joone: I wanted to extend this idea to 3D transforms
(Joone showing a presentation)
joone: Here is proposal
transform: polar(angle, distance)
transform: polar-origin(percentage|length, oercentage|length)
transform: polar-anchor(percentage|legnth, percentage|legnth)
joone: No changes, just use existing properties as transform
functions.
joone: If you use transform function.
joone: We can move the element in the containing block like this.
joone: If you use polar-origin
joone: you can move the green block like this.
joone: If you use polar-anchor can do this.
joone: If you use polar anchor, use polar origin together.
joone: Could extend this idea to 3D transforms.
joone: Use polar3d function.
* fantasai thinks joone is confused how the cascade works
joone: 3 parameters are polar3d(r, theta, phi)
joone: Place elements in 3d space like this.
joone: Can also use polar-origin3d and polar-anchor3d functions.
joone: polar-origin3d(r,theta,phi)
polar-anchor3d(50%, 50%, alpha, beta)
(joone's diagram has alpha and theta be the angles of the element
with respect to the ray from the origin)
joone: This is the initial idea. Might be some issues with this
idea.
joone: 3D function and transform.
joone: That's it!
<dbaron> Is the idea that these are equivalent to translate/
translate3d transforms?
Florian: I would split my feedback on 2 aspects.
Florian: One being transform and one being 3d.
Florian: Earlier today fantasai explained why doing positioning
with transforms cascades badly, want to do transforms on
top.
Florian: So because of that I don't think we should be doing this
with transforms.
Florian: Whether or not we can do in 3D can discuss separately
Florian: For 3D side of things, I don't think there is any
particular difficulty in understanding how the math works.
Florian: But I want to see use cases before diving into it.
Florian: This is solve-able, but wouldn't work on it without use
cases.
Florian: 2D without transforms is what we resolved on previously.
Florian: 3D maybe, but why?
Florian: Would like more convincing use cases.
Florian: Without that I think it's complication without
justification.
dbaron: I guess I didn't even understand what the proposal was.
dbaron: Are these translations? Are they translate + rotate?
joone: Internally we use translate and rotate functions.
joone: I want web developers to be able to just use polar
properties.
dbaron: I looked at transform polar3d(r, theta, phi). What is that
transformation?
dbaron: Is it a translation? Is there some rotation, too?
joone: No rotation, just move.
dino: If it's a translation, why isn't it a translation?
dbaron: I can understand wanting to express translate as polar
coordinates, but if so, would want translate in the name.
dino: Can you go back to the other slide?
dino: Example in 2d.
dino: The thing I don't understand, maybe it's because I haven't
been listening well enough, but...
dino: We start there, then next slide...
dino: We've changed the positioning completely of the element.
dino: There's this implied translate to the middle of its
containing block.
dino: Which is really confusing, because nothing else does that in
a transform.
dino: Polar angle and polar distance, initial value is located in
the middle of containing block.
dino: Sure, but no other transform needs to know what its
containing block is.
hober: What are the arguments to the function here that would be
the identity transform?
dino: What would you do if you wanted to keep something where it
was?
dino: I think I can see there's a use case for adding polar
transform functions that simplifying the case of moving
something a position rotating it, translating back out, etc.
dino: But don't like that this function completely changes
transforms completely.
dino: If you do translate(0,0) nothing changes. If you do rotate(0)
nothing changes.
dino: But here polar(0,0) completely changes where the element is.
Florian: This is a conversion into transforms from what the polar
positioning model was before we made the resolution 15
minutes ago.
Florian: Polar positioning in the old model had a jump-to-center
effect,
Florian: but we just changed that.
dino: Transforms isn't the way to magically change the positioning
of an element.
<dbaron> I agree with dino.
Florian: Without using transforms.
Florian: What we just discussed dealt with that.
<franremy> The point of having a conversion from polar to
cartesian transforms is useful, if you want to animate
smoothly, like an animation of a satellite around a 3d
globe.
Florian: And as fantasai explained, not good to use transforms for
positioning.
Florian: For 3D polar positioning, we need use cases.
fantasai: So here's the big issues...
fantasai: 2 major confusions here:
fantasai: One of them of which - you don't seem to know how the
cascade works as you're overriding the transforms.
fantasai: The second one is that, transforms are NOT a positioning
system, it's about shifting relative positioning system.
fantasai: That goes back to what Ted was saying, you need an
identity transform - if you 0 out everything it needs to
do nothing.
fantasai: When you add 1 to that it starts to do something - but
we need that identity transform.
fantasai: We can add polar transforms which is basically syntactic
sugar to other transforms.
Florian: If we want to work with transforms, then it needs to work
the way she just said.
Florian: If we want 3D positioning, then I want to see use cases
first.
Florian: And these two things are separate.
dino: Florian made 3 points
dino: and fantasai described them better
dino: The points were
dino: 1. Transforms aren't a positioning system.
dino: 2. It would be interesting to examine functions for doing
polar-like transforms that are shorthands for polar
positioning
dino: 3. and he wants use cases for what you want 3D polar
coordinates for
Florian: If we want to do transforms, as fantasai described, then
we don't need major use cases because it's syntactic
convenience.
Florian: If we need a 3D positioning system, then we need to
understand why are we working on this hard topic.
New type of pseudo-class to support scrolling in rounded viewports
------------------------------------------------------------------
Rossen: Next is pseudo-class issue
jihye: The latest smart phone from LG and Samsung use scrolling
animation like this one.
[jihye shows off an email subject line list, where the middle item
of the 3 visible is larger and shifted left]
jihye: There are several problems here.
jihye: One is that if the list item sizes are the same as the
containing block there is some overflow.
jihye: If the list item size is same as inner circle of containing
block, there can be unused spaces.
jihye: So recent smart phones use scrolling like this.
jihye: Dynamic scrolling and scaling of list items.
jihye: To implement this kind of scrolling animations on the Web,
jihye: This is implemented by JS.
jihye: It takes a lot of calculation, like exact position of
elements while scrolling,
jihye: and doing some scrolling animations.
jihye: So to solve this problem we suggest new pseudo-class.
jihye: We suggest regional pseudo class to handle this problem.
jihye: Can select an element in a specific area.
jihye: When the new type of pseudo-class is :region(
[center|left|top|right|bottom]?)
jihye: When element in the list matches with center point of
containing block, you can select :region(center).
jihye: When element matches with top edge of containing block then
select the element.
jihye: When you specify an element with region(center) that kind
of element scaling bigger than the other elements then
maybe you can deal with the dynamic scrolling I showed you
before.
jihye: But I think this not quite perfect solution for dynamic
scrolling.
jihye: Because layout doesn't change when scrolling animations.
jihye: This is just one idea for dynamic scrolling/aligning of
items.
jihye: What do you think about this idea? Do you have some other
solution for scrolling in round display?
astearns: Is Rick anywhere near?
astearns: The Houdini scrolling stuff might help here.
<dbaron> layout-dependent selectors seem unlikely to work
Florian: I am extremely skeptical that a selector depending on
layout and scrolling can work.
Florian: Since you can do it in JS, doing it in Houdini-powered JS
would make it faster.
Florian: It would be nice to have a declarative way to say that,
but I have no idea.
Florian: Maybe Bert has an idea, he's good at that.
Rossen: First comment, is that "region" in CSS and reusing name is
confusing...
Rossen: But as some experimental work with shape inside.
Rossen: Also kind of suggests that, reinforcing Florian's point
here, automatically scrolling mechanisms is quite
difficult other than approximate rectangles.
Rossen: When the shapes become more exotic this problem becomes
not even solvable.
Rossen: Especially if you have disjoint shapes.
Rossen: Not to say we should stop thinking about this.
Rossen: It is an issue.
Rossen: If the script based solution works, that's already really
good.
Rossen: In Houdini we will try to make that more efficient...
Florian: Houdini is important here, works on desktop, not so much
on watch.
astearns: I suggest taking this specific issue to the github
issues on Houdini as a use case,
astearns: And say that let's try to make our scrolling stuff help
make this more efficient.
Bert: Wrt :current/:past/:future pseudo elements.
Bert: Can see what was coming and what's past.
Bert: That's the first idea I had with this.
Bert: Scrolling also has this. So maybe with pseudo-classes can do
something.
Bert: Just to remind people that we have something in Selectors 4
that might fit this.
<astearns> Perhaps it shouldn't be layout changes based on
position within the round display, but transforms (
scale as you get to the middle...)
<hyojin> I modified that the revision of CSS Round Display as last
item.
Robustness of CSS on non-rectangular displays
---------------------------------------------
Florian: So, next one is robustness of CSS on non-rectangular
displays.
Florian: If you ignore bugs and stuff, if you take an unstyled
document, or to which only the UA stylehseet has been
applied.
Florian: We've never had a situation where doing this would result
in invisible overflowing clipped content.
Florian: With shaped displays, we do, because corners get clipped.
Florian: Starting with invisible content from which the author has
to work from is bad.
Florian: The author cannot be expected to anticipate all the
devices in the world,
Florian: and make their page work in all of them.
Florian: I think we should find a way to have the default
situation for a web page to not clip and hide content on
round displays.
Florian: Should we apply shape-inside by default?
Florian: But that's tough because we don't even know how
shape-inside works precisely enough
Florian: What I think he's suggesting is that by default the
device manufacturer or provider of UA for that device
Florian: Would make a viewport that does not cover the entire
screen, but is either entirely contained or something
that overflows it so little that you don't lose much.
Rossen: So we already have the concept in most implementations of
physical viewport and layout viewport.
Rossen: What I'm hearing is that we should allow sizing of the
layout viewport from the host level.
Florian: ???
Rossen: Currently layout and device viewport is completely
internal,
Rossen: not target-able by content script style anything.
Rossen: This would be the first requirement that allows
programmatic access to the layout viewport.
Florian: Recommendation would be, ask the UA to start with a
layout viewport that is smaller than the screen,
Florian: and sized smartly to not overflow at all or too much,
Florian: and to give either through <meta> or @viewport, allow
author to opt into the full screen.
Florian: If you're asking for it, fair to let you deal with the
situation.
Rossen: If a manufacturer of such a device is using a web view or
any other way to host web platform,
Rossen: How is what you're saying different from resizing overall
host container.
Florian: The difference is matter of initial setting, and allowing
author to opt into the full viewport.
Florian: I'm not strongly defending this solution, just presenting
it.
Florian: People should design for devices everywhere generally,
and then tailor to specific devices.
Florian: Impossible to do this for round displays if we just use
the entire circle as the display for the page.
fantasai: The key thing is being able to opt into the full display.
Rossen: At the app level it's fine.
Florian: I'm not concerned about app level, for content targeted
to the watch. I'm thinking about content not targeted at
anything in particular that needs to work.
Rossen: So you have a round display, and by default you don't want
to clip.
Rossen: As Brad says, putting a square peg in a round hole
Rossen: At some point you want the user...
Florian: Opt-in is for the author, not user.
Florian: If you display any web page not authored for a watch,
should display just fine on the watch.
Rossen: Agree with the general statement.
Rossen: Don't understand the solution.
Florian: If the author does nothing, the UA should provide a
layout viewport smaller than the screen.
Florian: There is no clipping.
Florian: If the author is ready to deal with shaped screen,
Florian: Can ask for viewport that covers the entire screen,
Florian: and be prepared to deal with the clipping.
Rossen: As long as its the on/off switch, it's palatable at least
to me.
Rossen: I'd be more reserved if we go the next stop, which and
through this media feature do a whole bunch of things to
viewport sizing.
Florian: Don't want to do shaping of viewport with this.
Florian: Just opt in/out of the viewport fitting in the circle.
Florian: Would like to tag this into the Device Adaptation spec.
plinss: Why aren't we doing shape-inside by default?
Florian: Well, we don't exactly know what that does.
Florian: Also if you have less content than the screen, fine. What
if you have more content than the screen?
fantasai: We don't have a solution for that.
Florian: In 15 years maybe, you can do that, but need a solution
for now.
Bert: About the smaller viewport, could be maybe a little bit
bigger have margins on the scrolable area.
Florian: I don't think we have to be overly strict, can let device
manufacturer be smart about that.
Rossen: Not necessarily a new problem, at least in Windows Table
mode, number of reasons why you'd want to constrain the
viewport of the browsers for different UIs and impinging
elements that are either part of the browser chrome or
extension of it.
Rossen: This is just the same problem.
Rossen: Impinging items are part of actual display.
Rossen: @viewport works just fine.
Rossen: Anything else on this?
Florian: If we agree that's the way forward, someone needs to take
an action to figure out concrete syntax for this and put
in either round display or device adaptation spec.
Rossen: Start with round display and move to device adaptation?
Florian: With regards to time constraints on my side, would rather
we actioned LG to write it, and I'm happy to review.
ACTION: hyojin add @viewport switch for opting into full round
display size as viewport
<trackbot> Created ACTION-751
Publication
-----------
[discussing new WD publication now]
RESOLVED: Publish new WD of Round Display, with polar positioning
resolution incorporated (@viewport for next publication
okay)
device-radius
-------------
Florian: If you remember in Sapporo we revisited the media query
and sort of concluded on a proposed MQ that no longer
measures roundness of corners,
Florian: but instead queries whether a certain box sized and
position in a certain way would be in the visible area of
the screen or not.
Florian: I don't think the spec has evolved since then.
<hyojin> The summary about it written by David Baron:
https://lists.w3.org/Archives/Public/www-style/2015Oct/0220.html
Florian: I think the spec still has what we had before that.
Florian: I think we need to revisit that entire discussion,
because there are two things that you want to query.
Florian: If you're wondering if something will be visible or not,
that's a good answer.
Florian: But there's a qualitative question as well.
Florian: There's also, am I on a round screen? In that case maybe
I want round buttons and a round layout etc.
Florian: But if I'm on a square display, maybe want more
rectangular look and feel.
Florian: So the question is, do we need to revisit conclusion in
Sapporo?
Florian: Or do we need two media queries, one for whether area is
visible, and whether the shape is roundish or squarish?
Rossen: Wrt resolution from Sapporo, what happened?
hyojin: corner-radius query to check that, also is-visible MQ is
strong, but seems very complex.
hyojin: LG prefers a simpler solution.
hyojin: In consideration of extensibility, we should make this
media query extensible.
hyojin: I would prefer to keep current media query.
hyojin: and rename to corner-radius.
hyojin: Address others in next level.
Florian: I'm sympathetic, but skeptical.
Florian: It doesn't really answer questions for ...
Florian: We have a syntax but don't have a clear idea what it means.
Florian: We discussed and came up with is-visible.
Florian: But that doesn't answer whether it's round or not.
Florian: I'm okay to have "am I round" query in L1 and is-visible
in L2.
[missed last few sentences]
Rossen: You can check is-visible with IntersectionObservers
Rossen: If you have an element and know if it's within the bounds
of a scroller.
Rossen: Similar to a mutation observer.
Rossen: If the thing you're observing intersects a scrolling
viewport, we can ...
dbaron: I'm a little worried about the IntersectionObserver analogy.
dbaron: I don't think it deals with partially-visible in the way
you want.
dbaron: For the use cases of intersection observer, partially
visible is often okay and you want to be notified that
you're visible.
dbaron: But these use cases you care if you're completely visible.
dbaron: But need to check before concluding that intersection
observer is the right thing.
Florian: That leaves us the question of how do we make query of
"am I round"
Florian: I don't think corner-radius is the right MQ.
fantasai: But what does round mean?
fantasai: For answering the qualitative question of screen
round/square is a device MQ possibly.
fantasai: It doesn't answer the question of if my corners are
visible.
fantasai: You can have a watch that has a rounded corners but it's
still a square, so you want to know that it's round but
it's not a circle.
fantasai: Having just "am I round" is not enough.
<franremy> +1
Rossen: What about the negation of that?
Rossen: Am I rectangular?
fantasai: We did discuss a JS API that gives you a path that
allows you to do what you need.
fantasai: Can build whatever logic you need on top of that.
zcorpan: Last time we discussed, a screen shape that's almost
rectangular with corners a bit cut off, should probably
be considered rectangular.
fantasai: What if that cuts off the "close" button, which is
usually in the upper right corner? Need to know that
the corner is clipped.
Florian: Maybe a non-boolean query.
Florian: But if we had a 'device-shape' MQ that has 'curved' and
'square'
Florian: Let the device manufacturer opt in to roundish or
squarish designs.
<BradK> Why not just allow overscrolling the round viewport to see
things that would get clipped by default?
<fantasai> BradK, I think that's an excellent solution to the
previous issue; and I think that's in fact what some of
the watches do.
Rossen: Remind me the use case?
Florian: If you look at the UIs for such watches,
Florian: They look round,
Florian: Not just to avoid corners,
Florian: But everything's round, let's be round, round buttons etc.
Florian: But we can't make an MQ that only answers yes when
perfect circle.
<tantek> I'd like to see photos/screenshots to such "UIs for such
watches"
<fantasai> ask jihye to show you
<tantek> like if you have these readily available and have seen
them, please upload/email to www-style
<tantek> so we can refer to them
<jihye> http://anawhj.github.io/jRound/demo/weather/index.html
<tantek> even better, perhaps we need a "watch-ui-examples" page
on the wiki
joone: I implemented device radius on Android.
joone: Only one API that returns this information,
joone: I think we need first talk to the platform team,
joone: in MS or Apple or Google.
joone: Making the API to return the device shape.
joone: Before can make the media query API.
Florian: The Android API returns "am I a circle or not."
Rossen: Which works perfectly for... circles.
hyojin: We're also positive to specify just rectangle and round as
the values, but I don't know how to define the media
feature syntax in Media Queries.
Florian: Something like @media (shape: rectanglish|circlish)
Florian: I'm not very excited about this, but don't have a better
idea.
Rossen: I think we have two proposals.
Rossen: One is a binary switch.
Rossen: Tells you whether or not rectangular.
Rossen: Other one is actually get a shape.
<heycam> An alternative might be for the author to declare the
unsafe area around the page, and then the device can know
whether any important content would be clipped out. This
could be useful for the "square display with rounded
corners" case.
<joone> Here is the code for getting display shape information
from Android Wear:
https://github.com/joone/crosswalk/commit/4613bf9e2d266fe60a26631e475aaa7392e4c4c5q
fantasai: I think there's three things that would be useful.
fantasai: 1. Have a JS API that provides the screen shape.
fantasai: That will allow you to build any logic for any MQ you
want.
fantasai: The two things that can work together are corner radius
and corner shape, the radius would tell you the smallest
number the cutoff and the shape would say the shape,
square, round or weird.
Rossen: Seem to have nothing approaching consensus.
SteveZ: We need a solution for people to do something different
for the round case.
Florian: Authors are interested in "am I round".
Florian: OS can answer am I a circle.
Florian: So this is implementable and useful.
Florian: We need to make the definition fuzzy enough.
Florian: That when egg-shaped screens start existing.
Florian: and OSes can be asked about it.
Florian: An egg-shaped screen can describe themselves as round.
Florian: But this is implementable, usable, pragmatic, overly
simplistic, but not a terrible starting point.
Florian: Device manufacturers that ship non-circular devices can
adjust their Android...
Rossen: Still no conclusion.
SteveZ: Agree. Need an action to write up a proposal
ACTION Florian: make proposal for round display media query
<trackbot> Created ACTION-752
Received on Wednesday, 23 March 2016 21:32:34 UTC