- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 12 Nov 2015 05:25:40 -0500
- To: www-style@w3.org
New WD for Device Adaptation
----------------------------
- RESOLVED: Publish new WD for Device Adaptation.
CSS Snap Points Path Forward
----------------------------
- MaRakow, TabAtkins, and fantasai got a chance to speak and come
to a consensus on how to fold the change in approach to snap
points into the existing WD.
- This change-over will occur over the next several weeks.
- Once the new version is ready, the group will publish a last
version of the old approach right before publishing the new
approach, both as WDs.
- This allows a good record of how the spec progressed without
sending the wrong signal about the direction of the spec
to implementors.
Round Display
-------------
- There was support for the proposal of 2D rotation transform
function for polar coordinates, though it was thought they
should be named polar-angle and reverse-polar-angle or
polar-reverse-angle to explicitly link them with the polar
properties.
- An additional question was raised about how it would
interact with animation, but it was decided that that
interaction was dependent on if it's a computed value or a
specified value.
- RESOLVED: Accept the proposal for a 2D rotation transform
function for polar coordinates and make it clear if
it's a computed value or a specified value and make a
note on the implication of that decision on animations.
- RESOLVED: Accept the polar-origin changes.
- The polar-origin proposal lead to a conversation about adding a
center value to fixed and absolute positioning.
- The conversation will continue on the mailing list.
- If this change ends up happening, it may negate the need for
polar-origin.
Page Floats
-----------
- There wasn't telecon time for a full conversation, but it was
suggested that the interested parties get on a separate call
to work through the mailing list topics.
- johanneswilm and Florian will work on organizing a call.
Match-Parent and Orthogonal Flows
---------------------------------
- RESOLVED: Line-grid will restart in the case of orthogonal flows
between parent and child.
Additional Page Sizes
---------------------
- RESOLVED: Add JIS-B4 and JIS-B5 to page-floats.
- Florian will summarize other page sizes that could be added to
the spec in an e-mail.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2015Nov/0185.html
Present:
Rossen Atanassov
Dave Cramer
Elika Etemad
Tony Graham
Jihye Hong
Dael Jackson
Brian Kardell
Brad Kemper
Peter Linss
Myles Maxfield
Simon Pieters
Anton Prowse (IRC Only)
Matt Rakow
Florian Rivoal
Simon Sapin
Alan Stearns
Lea Verou
Greg Whitworth
Johannes Wilm
Steve Zilles
Regrets:
David Baron
Bert Bos
Angelo Cano
Adenilson Cavalcanti
Alex Critchfield
Simon Fraser
Daniel Glazman
Michael Miller
Edward O'Connor
Zhong Xu
Scribe: dael
Rossen: First thing, any extra items?
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Nov/0154.html
Florian: I doubt we'll get to it, but it would be good to talk about
this (link above) this time or next.
Rossen: This is the pre-wrap/pre-wrap-auto? We'll add it.
Rossen: Any other topics?
WG Administrative Discussion
============================
[un-minuted]
New WD for Device Adaptation
============================
<astearns> https://drafts.csswg.org/css-device-adapt/#changes
Florian: I've been through the log. It's been a long time and
there are substantive changes. I think we should publish
a new WD. I've made a change section. If anyone wants
issues logged before we publish it would be good, but I'd
rather add issues and publish as-is because it's been a
long time. What do people think?
<astearns> +1 to new WD
MaRakow: We had a side discussion about the two issues I raised.
I'll add those as issues so we can move ahead with
publishing a WD.
Florian: Okay. Anything else people would like marked in the
document?
SteveZ: Good for me.
Rossen: Sounds like everyone is okay with publishing. I'm also in
favor of publishing with the added issues.
RESOLVED: Publish new WD for Device Adaptation.
Rossen: Who will help with the publication?
Rossen: Are ChrisL or Bert on? No. Florian can you ping one of
them to get it published?
ACTION Florian to work with Chris or Bert on publication
<trackbot> Created ACTION-743
CSS Snap Points Path Forward
============================
Rossen: This was worked on extensively with conversations, so we
need a follow-up.
MaRakow: I had a telecon with TabAtkins and fantasai last week.
They gave me a walk through of the technical changes. We
discussed on there some changes and wording. As far as
procedure goes, over the next couple of weeks we'll do a
detailed review of the spec and pull them into the
existing ED so we can isolate and identify items.
MaRakow: There were a couple of issues, I think we were going to
remove edges from snap-align and a couple of others, but
that will happen over the next few weeks and we'll have a
merged draft.
Rossen: So it sounds like in a couple of weeks we can republish
the merged draft?
MaRakow: Sounds right.
Rossen: Do we have anything we want to publish prior to have a
good before/after?
MaRakow: The spec has the Japan changes using the old syntax. We
could publish that as the furthest progression of the old
syntax. So before moving to the new terms this is as far
as the old one went.
Rossen: Is everyone okay with publishing a WD first and publish
the merged draft including the new syntax?
fantasai: Only if we're super clear with a message in the status
with what the changes will be. I don't want implementors
to think we're not going the new way and implement this
other thing.
MaRakow: That makes sense.
<astearns> would rather wait until we have the draft set with
everything we've agreed on.
Florian: I'm okay with preserving a current state, but I'm worried
about the signal. Can we save the draft on the side, work
on the new one, and publish both in a row? That way we
don't have a long piece of time with the old one.
MaRakow: Main problem with delaying publishing updates is what
will be up will be less up to date.
Florian: It's a matter of signaling. If you update with something
we no longer want that could be confusing.
Rossen: What are the types of changes you have?
MaRakow: I don't have full list, but it included removal of repeat
syntax and some text. I can send the full list to the
mailing list if that helps.
Florian: If we do a gigantic warning that's probably fine.
Rossen: So we can wait until the merged draft is ready and publish
both drafts one after another. That would buy you safety
if it takes longer, which I think worries some people. The
other option is if you're committed to the short timeline,
I doubt this will provoke too much implementor confusion.
fantasai: It would be fairly easy to snapshot the draft right now,
save it, and publish later.
MaRakow: I can go with whatever the group recommends. I wanted to
raise the potential of having the midpoint.
Rossen: I think we agree it's important, it's all about timing.
Rossen: We'll take the snapshot for now and then we'll publish the
two specs one after another once you're ready.
MaRakow: Sounds good.
Rossen: Let's go with that. We'll resolve once you're ready with
the new draft.
MaRakow: Procedurally, who takes the snapshot?
fantasai: Easiest way is for you to note the change set that
corresponds to what you want as the snapshot. Then
whoever publishes can pull down that change set and make
it a WD to pass off to the staff.
Rossen: Two topics on page floats are next on the agenda. These
had the highest number of people wanting to talk about,
but they'll take a while. The Round Display was brought by
LG and they're in an awkward time zone. If fantasai and
johanneswilm are okay, I'd rather do round display first.
johanneswilm: Okay.
Round Display
=============
2D rotation transform function for polar coordinates
----------------------------------------------------
<jihye> https://lists.w3.org/Archives/Public/www-style/2015Oct/0177.html
<jihye> https://drafts.csswg.org/css-round-display/#2d-rotation-transform-function
jihye: There was discussion about the polar orientation property
at TPAC. It was decided to achieve the effect by the rotate
function with additional keywords.n
<jihye> rotate() = rotate( <angle> | center | counter-center)
jihye: Therefore I extended 2D rotation transform for polar
coordinates. In most polar positioning cases elements are
rotated on anchor point to origin point. So we need center
and counter-center value.
jihye: Center enables us to achieve the kind of positioning
elements more easily than specifying an exact value. Also
counter-center, which means center value + 180deg for when
elements are positioned downward in the shape of a
containing block.
<jihye> http://anawhj.github.io/jRound/demo/facebook/circle.html
jihye: In this use case [above link] there are several menu icons.
The upper menus are rotated with center and lower are with
counter-center.
<astearns> (demo does not work in FF, but does in Chrome)
<gregwhitworth> @astearns strange, works in edge - makes me think
it's probably webkit related somehow
jihye: Is this extension of rotate reasonable and are our keyword
value names appropriate?
<Florian> rotate() = rotate( <angle> | polar-angle |
reverse-polar-angle )
Florian: I think proposal is reasonable, but maybe change the
names to what I have in IRC?
<astearns> would the keywords also need to be added to
https://drafts.csswg.org/css-transforms-2/#propdef-rotate ?
<fantasai> astearns, no
<fantasai> astearns, e.g. css-ruby extends 'display'
<fantasai> astearns: so not necessary to fold in
Rossen: What do others think? The proposal is add to rotate that
takes polar and reverse-polar.
Rossen: Your current function will take...it could be both
polar-angle and reverse-polar-angle for the given angle?
jihye: No, polar-angle and reverse-polar-angle can be used instead
of angle value.
Rossen: And the little icons like the like button in the demo, is
that the icons you were referring to?
jihye: Yes. Like and share are using counter-center which means
reverse-polar-angle value.
Florian: It does the same thing as typing an angle manually, but
it picks the value from the computed value of the polar
angle property so you don't have to manually sync.
* fantasai would go with polar-angle/polar-reverse so they both
start with polar-
myles: If this is inside an animation, what do you expect to occur?
myles: Is this function animatable and if so what is the behavior?
jihye: When the rotation function has center value, then when the
elements are moving on the edge of the circular shape, then
always elements are rotated toward the center point of the
containing block. So you don't have to manually adjust the
angle of the rotation function.
Rossen: So if you're animating from an angle to another angle...
myles: Like if one side of the keyframe has center and the other
an angle.
Rossen: So since both are computable, you're animating from
degrees to degrees.
myles: The polar-angle value can also be animated. So you animated
between things that can be animated? Or am I
misunderstanding?
Florian: Wouldn't the behavior fall out of our existing rules?
jihye: I didn't consider animating.
myles: Regarding Florian's comment, I'm not sure we have existing
behavior where we're animating between something we're also
animating, so it may be worth considering that case.
Rossen: That's something we should take as an issue if we accept
this.
<astearns> so change to polar-angle | reverse-polar-angle and add
an issue about animating?
Rossen: So, what do people think about the addition of polar-angle
| reverse-polar-angle
BradK: I like it.
<astearns> I like it
<Florian> +1
fantasai: I think it makes sense. I would go with names that start
with polar to make it clear the values come from the
polar properties.
Rossen: That makes sense. It sounds like we'll have to record an
issue about if this is something that will be requiring
special animation handling.
fantasai: If you're animating polar, if it doesn't compute
through, which I don't think it should, as you're
animating polar-angle the transform will change. If it
computes through you will probably...it won't work as
well.
fantasai: Animating between...that would work. If you don't
compute through it will animate just fine. If you're
animating between rotate: polar-angle and rotate: 0
Florian: It doesn't sound unreasonable to animate between
polar-angle and another of the keywords. But when you
combine both, what happens? If you simultaneously
animated the transform property from rotate a keyword to
an angle and animating the polar-angle.
<fantasai> Florian, this is the same problem as border-color.
Rossen: If you're animating something to inherit and the inherited
value is being animated, as long as the computed values
resolve to animate-able it should work. Both center and
counter-center are just two angles. I don't see how this
is bringing something new to the way you would resolve
your animation graph.
Florian: I was hoping it wouldn't, but the previous discussion
suggests that we may need to make it explicit.
fantasai: We need to make it clear if they're computed values on
their own or if they compute through. How they animate
falls out from that. We had a similar issue with
animating border and border-color.
Rossen: Reasonable. How about accept the change to rotate and
record an issue to make the interaction between the
keywords and animations clear.
Rossen: Is that okay?
jihye: Yes.
fantasai: I think the issue is make it clear if it's a computed
value and we can make a note on the implication of that
decision on animations. We need to make sure if they
compute through to the value on the other property or not.
fantasai: We probably want dbaron to look at that decision.
Florian: We can record as an issue and move on.
RESOLVED: Accept the proposal and make it clear if it's a computed
value or a specified value and make a note on the
implication of that decision on animations.
Polar Origin
------------
<Rossen> https://lists.w3.org/Archives/Public/www-style/2015Nov/0155.html
<jihye> https://drafts.csswg.org/css-round-display/#polar-origin-property
jihye: At TPAC it was resolve dot add polar-origin independent of
transform origin. I updated round display.
jihye: There was consideration of positioning elements with polar
positioning and abspos.
jihye: Before adding the polar-origin property the origin of polar
coordinate was always the center point.
jihye: For that reason we can't use...without polar-origin we
can't use abspos with polar positioning. With polar-origin
we can achieve the same effect as abspos. Polar positioning
is then applied based on polar-origin.
jihye: There may be a situation about adjusting the element's
position horizontal or vertical after being positioned in
polar coordinates. Do we need to apply abspos to elements
in polar coordinates?
<Florian> I don't think polar-origin should have any effect unless
polar positioning is turned on. I don't think polar-
origin should turn on polar positioning on its own.
Florian: If I'm understanding correctly, I don't think I agree
that polar-origin should turn polar position on. It
should do nothing unless we're doing polar positioning.
<fantasai> +1
Florian: That seems like a simpler model. I saw the suggestion on
the mailing list, but it confused me more.
BradK: I think some of the thread was in response to my e-mail. I
haven't had a chance to review the e-mail. My idea was
polar would work within abspos or fixedpos. It would be
more similar to top, right, bottom, left. They start as
auto and when you set a value they position themselves.
That's why I suggested one would be auto as a start and
when you give it a value it positions according to polar-
coordinates and you can use top, right, bottom, left.
Florian: If we did that, I think polar-distance should have the
auto.
BradK: It's either polar-distance or polar-origin. One being
non-auto would be the trigger.
Florian: I think we should think on that separately and add
polar-origin non-magic now.
BradK: I don't know if it's magic. It's more in keeping with other
position properties.
Florian: The wording wasn't good. But if we switch away is a
different conversation than if we should have
polar-origin. I think they're both worth discussing.
BradK: Is polar-origin still needed if we have the polar
properties as part of abspos?
Florian: Ah. I see what you mean. Maaaayybe.
Florian: So you're saying if we could use abspos it would be
left/right instead of polar-origin?
BradK: Yeah.
Florian: That sounds confusing because you want polar-origin to
default to the center.
BradK: I think it would be by default horizontal center if you
didn't have left/right. Or you have a center property which
I've been wanting for a long time.
Rossen: Value or property?
BradK: Property. One that works like left and right, one that
works like top and bottom.
BradK: Or, in the example I gave, for horizontal center, you
position the center of the positioned item with whatever
you want in terms of percentage. The center could line up
with the end of a slider.
Rossen: Going back to the issue. Do we feel like we have enough to
resolve now, or does this go back to the mailing list? It
sounds like there's quite a few opinions and it sounds
like a more general change of the actual model. I don't
think we can resolve on a large change with only a subset
of the WG and not much thinking.
Rossen: I'd suggest we take this all back to the mailing list.
Florian: So either we take everything back or resolve to add
polar-origin with the understanding that BradK's
suggestion may change the whole model and make it
unnecessary.
Rossen: That sounds reasonable.
<fantasai> +1 to resolving on polar-origin and also on exploring
Brad's proposal further
Rossen: So accept the current model, resolve on polar-origin and
continue the discussion on changing the model as per
BradK's suggestion.
jihye: Okay, we can discuss at mailing list.
BradK: I'm okay accepting polar-origin for now with the
understanding it might change if we move it into
positioning properties.
Rossen: So BradK's challenge will continue on the mailing list. As
the polar-origin stands in the current model, anyone
opposed to adding?
RESOLVED: Accept the polar-origin changes.
Rossen: We'll continue the other conversation on the mailing list.
Page Floats
===========
Rossen: Which topic do you think we can do in 10 minutes?
fantasai: I don't think we can do either. There's a lot going on
in that thread that's really interesting. I don't think
solving them will work yet.
johanneswilm: If we don't have anything else, I think we could say
something about inline-start.
Rossen: We have enough things on the agenda. Those topics were
brought up by the most people. If you're okay to continue
on the mailing list we can postpone the page floats topics
for a week. It's up to you.
johanneswilm: It's fine to take them up next week if we continue
on the mailing list.
Rossen: Continue on the mailing list for the time being.
Florian: For the page floats. The subject is large enough we may
want a separate call since it could take an entire
conference call.
johanneswilm: Agreed.
Rossen: Agreed. I think a number of people will want to
participate. If johanneswilm and Florian, you can
coordinate, we can get on the phone and get it out of the
way.
johanneswilm: I can try and coordinate with Florian.
<gregwhitworth> Can you include me Johannes as well
Match-Parent and Orthogonal Flows
=================================
Rossen: 3 topics left. line-grid, css-page, and the pre-wrap topic
brought up at the beginning of the call. Florian, which
can we do in 7 minutes?
Florian: line-grid
<Rossen> http://lists.w3.org/Archives/Public/www-style/2015Oct/0233.html
fantasai: I think you're right we create new grid.
<astearns> Makes sense to me.
Rossen: With my implementor hat restarting the grid makes the most
sense. When we do have subgrids in the grid module, if the
subgrids have orthogonal flows I wouldn't want to match.
Rossen: Objections?
RESOLVED: Line-grid will restart in the case of orthogonal flows
between parent and child.
Additional Page Sizes
=====================
<Rossen> http://lists.w3.org/Archives/Public/www-style/2015Oct/0234.html
Florian: We have two values of the size property/descriptor. The
sizes can be B4 or B5. These are ISO sizes which are
different from JIS sizes. Japan uses JIS sizes and they
are one of the few places that use the B sizes frequently.
I don't believe many people use ISO B sizes. Japan uses B
sizes for paper, it would be good to actually use it.
Florian: I propose to add JIS-B4 and JIS-B5. There's a whole bunch
more we could support, such as A6. But since we already
have the B values, adding JIS version would save a lot of
confusion.
Rossen: Sounds reasonable to me.
<dauwhe> Prince has quite a long list of supported sizes:
http://www.princexml.com/doc/page-size/
Rossen: The current spec has B4 and B5. Are you proposing to add
JIS-B4 or also rename the existing?
Florian: Minimum is to add JIS-B4 AND JIS-B5. We could also add
ISO-B4 and ISO-B5 which alias to B4 and B5 since they're
already there. I don't care strongly between those
options. I think the original proposal was to add the ISO
but as long as we have JIS I'm good.
Rossen: I'm in favor of the minimal change of just adding JIS-B4
and JIS-B5 and leaving B4 and B5 as they are. Other
opinions?
dauwhe: That minimal change sounds reasonable to me.
Rossen: Any objections?
RESOLVED: Add JIS-B4 and JIS-B5 to page-floats.
fantasai: I'm happy to add the changes, but Florian can just add
them.
ACTION Florian add JIS-B4 and JIS-B5 values to the page spec.
<trackbot> Created ACTION-744
Rossen: Looking through, are all the listed editors active?
plinss: Melinda isn't active.
<dauwhe> https://drafts.csswg.org/css-page/
Florian: The editor changes are done in the ED.
Rossen: Okay, great.
Florian: In the 12 sec left, in a future version of the spec we
should consider a more robust list. All editors that care
about print have a longer list. More things would make
sense.
Rossen: It would be great if you can summarize those in an e-mail.
Rossen: That's the top of the hour. Thank you everyone.
Received on Thursday, 12 November 2015 10:26:39 UTC