- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 26 May 2017 21:01:38 -0400
- To: "www-style@w3.org" <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.
=========================================
F2F scheduling
--------------
- Provisional idea is to coincide with TYPO conference, after the
labs.
Motion Path
-----------
- The group originally resolved that offset-position offsets the
shape when the offset-path is a geometry/shape, but as
discussion continued it was decided that more time was needed
to think about the topic.
- shans wrote a summary of possible solutions:
https://github.com/w3c/fxtf-drafts/issues/78#issuecomment-296360745
- RESOLVED: <size> argument of ray() is required.
- RESOLVED: Name the "cast to the side you're pointing at" value
"sides".
- RESOLVED: Close issue #69 (offset-rotation should only do
path-relative rotation- https://github.com/w3c/fxtf-drafts/issues/69)
no change.
- RESOLVED: #51 (offset-* property names collide with logical
properties- https://github.com/w3c/fxtf-drafts/issues/51)
won't cause motion-path to rename; the offset-*
logical props will change name.
Focus of custom textbox-like elements
-------------------------------------
- RESOLVED: Come up with a property name for this focus-ring
property, ratify in the CSS-a11y TF, put it in css-ui-4
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics
Scribe: fantasai
F2F scheduling
==============
astearns: TYPO usually has Tues-Sunday scheduling.
astearns: I suggest our 4-day meeting starts Monday.
fantasai: Suggest people get a break on Monday.
vlad: First two days are more tech heavy than the rest of the
conference.
vlad: Could start with that, and then co-exist with the conference-
vlad: have parallel events.
astearns: So we could have our meetings Thurs-Sun as well.
astearns: But then we're meeting on a weekend.
vlad: Monday Houdini, break for TYPO labs, follow with CSSmeetings.
iank: Hosting us where?
vlad: Host will be Monotype.
vlad: Traditionally in Berlin.
Florian: I would prefer no gap between Houdini and the rest,
because as Houdini stabilizes, might be possible to do
Houdini as a breakout session in parallel with CSS.
Rossen: That's a valid argument, bigger one for those who travel
and don't plan to attend TYPO but do want to attend
Houdini and CSS you have extra stay in the middle.
Rossen: If you're sponsored, not too terrible, but out of pocket
not so great.
[dino agrees]
Florian: Who has problems with weekends?
[dino waves]
...
vlad: Conference part is typographic, some interest to this group,
but not so much overlap.
vlad: labs part is technology, more of interest to this group.
vlad: labs is Tues-Wed.
Rossen: So we can either set up CSS meetings before that so we
don't overlap
Rossen: but we don't want to do like Friday through next week
through Monday, probably.
Rossen: But then people who want to do labs can stay, others can
go home.
Rossen: Pushing after all of TYPO, if you want to go to labs, what
are you doing.
Rossen: So I think we either schedule right before or right after
labs.
Rossen: Either way would go through weekend.
Rossen: Anyone have problem with weekend? glazou tended to have
hard problem with it.
plinss: It was mainly if we did TPAC plus a weekend, then it gets
really long.
astearns: My preference is after the labs, so we're there
simultaneously in case there's something interesting at
the conference.
astearns: We could even have a joint session with the conference.
vlad: Could have panel session, ppl interested in CSS technology.
vlad: May be someone interested to present in the conference
itself.
fantasai: Or we could have a developer meetup after-hours.
astearns: Provisional idea is to coincide with conference, after
the labs.
astearns: Any concerns, speak up.
[CSSWG has preference for earlier in April than later because of
summer meeting and no winter meeting]
[discussion of summer location]
Motion Path
===========
Scribe: TabAtkins
shane: 4 issues I'd particularly like to discuss today; we can do
the rest of the 16 if we have time.
shane: The four I'd like to discuss are relevant to our impl plans.
No model for interaction of `offset-position` and shapes
--------------------------------------------------------
Github Topic: https://github.com/w3c/fxtf-drafts/issues/78
shane: Interaction between <shape> for path, and offset-position
specified.
shane: One suggestions is when using a <shape>, offset-position is
ignored.
shane: Other is to apply to offset-position as the initial offset.
fantasai: Don't have a strong opinion, but if you can do something
useful with it, that's nice.
Florian: Any difficulty with that?
fantasai: Various shapes have a start position as a possible
param. So what does it mean if you have that?
RESOLVED: offset-position offsets the shape when the offset-path
is a geometry/shape.
[resolution rescinded after further discussion, below]
fantasai: So offset-position isn't an offset, it's a position. How
do you turn it into an offset?
fantasai: [elaboration on this]
fantasai: Positioning syntax is a position wrt four sides of a
box; it's not privileging the top left corner. Don't
want to turn it into a description of an offset from the
top left corner.
fantasai: circle(... at <pos>) describes the center of the
circle. offset-position is also a position. Adding
them together is non-obvious.
astearns: What if we let offset-position *replace* the shape's
position, when defined?
shane: Eh, that doesn't seem desirable.
TabAtkins: So core if points and points don't add together.
Florian: Unless you can turn them into a vector.
Scribe: fantasai
fantasai: What if you don't specify a position in the circle?
TabAtkins: Falls back to center.
fantasai: Why not use the offset-position?
TabAtkins: ...
shane: [revisits Alan's suggestion again]
[mumbly discussion of whether the box keywords are useful here]
fantasai: There's no use case afaict, adding them for completeness
is excess implementation and testing work.
TabAtkins: But consistency!
[back to original topic]
shane: Suggestion to have offset-position overrides position in
the shape.
Rossen: Why use a separate position property?
fantasai: Because it's there.
TabAtkins: What makes it special here, vs any other place that
uses the shape functions?
TabAtkins: If we want to make path() easier to use, should do that
generally.
TabAtkins: It would be great to have coords in path via css box
coordinates generally.
shane: Feels wrong, not sure how to explain why I think this...
TabAtkins: If I use offset-position to set the start coord, why
not use it to set other coords?
shane: I think in general for the use cases here, the path doesn't
need to be shaped wrt the box, but often you want the start
position to be wrt box.
shane: Usually you want the path to be absolutely sized.
TabAtkins: Sure, they're all useful.
TabAtkins: box coords are a superset of abs coords.
<ericwilligers> In Blink's shipped implementation, if people use
position absolute and set left/top, then path('m 0
0 ... ') starts from left/top.
TabAtkins: I think it's just weird that in this one instance of
the path function, doing something special is weird.
TabAtkins: Create a CSS-friendly version of path syntax, that
takes <position> with units and such.
shane: Paths are hard to read and write.
shane: You usually take it out of an authoring tool.
shane: Paste it in... but then want to move the path around.
TabAtkins: You alter the first to digits of the path...
shane: But if you're building a site where you're taking data from
somewhere else, don't want a manual fixup.
fantasai: I think shane's got a good point.
TabAtkins: But if you want to use path elsewhere in CSS, then this
is a problem
shane: What you're suggesting doesn't fix it for path(), but it's
also useful and we should do both.
* fantasai agrees with Shane
TabAtkins: Could say that path() takes an "at <position>" after
the path, just like other shapes do
TabAtkins: Should go back to offset position only offsetting ray.
shane: Then position should go into the ray function.
TabAtkins: Just what I was about to say.
fantasai: That's not the only thing offset-position does.
fantasai: So offset-position is not only for setting the position
of the ray(), it's for positioning a box using <position>
syntax in the manner of background-position
(which you can't do with abspos).
TabAtkins: The purpose of offset-position is to give you a
translate function that acts like a background
position, so that 0% and 100% map to aligning to
opposite edges of the container
TabAtkins: That appears to be only necessary use of it here;
shapes can just take an explicit position
TabAtkins: So maybe have a different feature for this
RESOLVED: Undo previous resolution, we're still thinking about this
<TabAtkins> (In other words, we could just move *all* the
positioning functionality into the offset-path
functions - path("..." at <pos>), ray(... at <pos>).
Then there's nothing left for offset-position to do
*in this module*, so we can address the functionality
it still has elsewhere.
<ericwilligers> So is the view that offset-position is to only be
relevant for ray() and none, and not for path()
and basic-shape?
<astearns> ericwilligers: we're not happy with that
<ericwilligers> See Figure 11 in https://drafts.fxtf.org/motion-1/#offset-anchor-property
where offset-position and offset-anchor are useful
with offset-path none.
<fantasai> ericwilligers, I think the proposal was to move
<position> inside the ray() function and delete
offset-position or add the none-based positioning
feature to something else?
<ericwilligers> Can we make the <size> non-optional?
<astearns> topic: ericwilligers we'd still need to decide the
default
<ericwilligers> No default would be needed for function
ray(<angle> && <size> && contain?)
Should omitted <size> just extend to the containing block edge?
---------------------------------------------------------------
Scribe: TabAtkins
Github Topic: https://github.com/w3c/fxtf-drafts/issues/73
jihye: offset-based positioning properties describe the path the
element is on, various ways.
jihye: ray() defines a line segment starting from the position,
going in the defined direction.
jihye: It has 3 params - angle, size, contain.
jihye: Size is where the path ends.
jihye: When talking about size, have to know the path length
jihye: To resolve %s.
jihye: So most important factor is <angle> in ray(); I want
consistency with %s here, so if all you do is animate the
angle, the % resolves to the same length the whole time.
fantasai: So question is what the behavior is when you *omit* the
size keyword.
fantasai: Earlier you just draw the ray until you hit an edge,
it's that long.
fantasai: Current spec it defaults to closest-side.
fantasai: So my suggestion is adding an option (or defaulting it)
to get back the "cast the ray to the edge of the box"
behavior.
[explicitly unminuted discussion about whether it makes sense to
be the default]
fantasai: It's not clear, if the "measurement angle" is different
from the angle you're actually using, why 100% stops at
the point indicated by closest-side.
shane: I think that's not usually the case - mostly it'll be used
to position things around a circle around the box.
ChrisL: I agree with shane - I think it's usually the case that
you're using this feature for polar-positioning multiple
things.
fantasai: That's *a* use-case yes, maybe the most common one.
ChrisL: Yeah, and why not make the most common use-case be the
easiest thing to do?
Florian: [gives example of putting the start-point in the corner
instead, where closest-side will send all %s to 0.]
shane: I think the default of a polar-positioning feature should
be a circle.
astearns: What about making size always required?
fantasai: [doesn't like requiring it]
TabAtkins: [heh, fantasai wants a default, but prefers a different
default than anyone else]
shane: Straw poll?
fantasai: I'm against making it required, but won't oppose it. I
will oppose defaulting it to closest-side, especially
beause of the behavior Florian mentioned where percentages
resolve to zero if you choose a corner origin (which
seems like a reasonably common use case)
RESOLVED: <size> argument of ray() is required.
[discussion of naming the keyword]
RESOLVED: Name the "cast to the side you're pointing at" value
"sides".
offset-rotation should only do path-relative rotation
-----------------------------------------------------
Github Topic: https://github.com/w3c/fxtf-drafts/issues/69
shane: First, issue was opened because you thought offset-rotation
duplicated 'rotate'. I don't think that's true, and we
should reject it.
shane: Second, this is happening well after we shipped; we'd
prefer to not make non-essential adjustments.
<ericwilligers> https://drafts.csswg.org/css-transforms-2/#ctm
shane: Final output transform comes from several sources.
shane: offset, translate, rotate, scale, transform
shane: The order these happen in is quite integral to the result.
Re-ordering is not generally possible.
shane: So a rotation that happens in offset is different from one
in TSR, which is different from one in transform.
shane: In particular, a rotate in "offset-*" rotates the frame of
reference that the TSR properties work in.
fantasai: Do we *want* to do that?
shane: Yeah, definitely cases where you want to; you might be
doing something independent in TRS.
fantasai: [describes some example she wants help with]
[something about additive properties not being possible yet]
[I believe the point is that the example in question is gonna need
more control, probably in scripting, than we can reasonably
provide in simple CSS anyway]
<fantasai> The use case is that you have the little motion path
plane along its path, and then you want it to have an
:active { /* shift it down/right by 2px to react to
click */ }
<fantasai> This should not require scripting.
RESOLVED: Close issue #69 no change.
offset-* property names collide with logical properties
-------------------------------------------------------
Github topic: https://github.com/w3c/fxtf-drafts/issues/51
shane: Offset property names collide with logical props.
shane: We have offset-path/rotation/etc. Logical props has
offset-block/inline-start/end.
shane: Question is what the 'offset' shorthand do.
TabAtkins: I'm okay with no shorthand for positioning offsets.
fantasai: It's a PITA to have to set tbrl to zero.
fantasai: So we should have a shorthand for them
TabAtkins: If we can agree that the logical props don't need a
shorthand, we can just let the logical props to stay as
they are, and give 'offset' to the motion-path spec.
fantasai: And that shorthand should match the prefixes (although
it doesn't have to but that would be silly)
TabAtkins: If that's the case, then one of the impls has to change.
dbaron: I'm okay with changing logical prop name.
RESOLVED: #51 won't cause motion-path to rename; the offset-*
logical props will change name.
[naming brainstorming:
position-*?
bounds-*?
inset-*?]
leaverou: What were the motion-path ones renamed in the first
place? They're not really about offsets.
Florian: They're not about motion either - you only get that when
you animation offset-distance.
Focus of custom textbox-like elements
=====================================
shane: If you have a button-thing or a text-thing, native focus
behavior differs.
shane: If you focus the text thing, it shows a ring whenever it's
focused, regardless.
shane: But button things don't show a ring unless you focused them
via a non-pointer interaction.
shane: This behavior is hardcoded into our browsers with a list.
shane: So we have the :focus pseudo-class, which you can set an
outline with.
shane: With a rule like ":focus { outline: ...; }", all your
button-things act like text-things.
shane: Alice has proposed :focus-ring, designed to help with
outlines, which matches only when the focus ring would show
on the element.
<dbaron> We've also had :-moz-focusring for a while; see
https://lists.w3.org/Archives/Public/www-style//2013Dec/0286.html
shane: This is all background - we already accepted :focus-ring.
shane: Now at the moment we have weird UA stylesheet focus stuff.
Deep magic, we'd like to switch them to :focus-ring.
shane: So now we have a secondary problem.
shane: Sometimes people make buttony-like or texty-like things.
shane: It would be nice to be able to opt these elements into the
appropriate behavior.
shane: We have two proposals. We probably want to do both.
shane: First is a property on an element that sets it to texty or
buttony behavior.
Florian: Why default to button?
TabAtkins: If you put tabindex on a <div>, clicking that div
doesn't focus-ring.
<aboxhall> focus ring usually applies to everything unless that
changed recently
<aboxhall> http://jsbin.com/bujerufeca/edit?html,css,js,output
<aboxhall> clicking the div shows a focus ring
<aboxhall> yes, texty is the default behaviour
[looks like shane had it backwards]
shane: Okay, so texty is the default behavior.
<aboxhall> oh right, it shouldn't match :focus-ring
<dbaron> I suppose this is important because right now people work
around the undesired focus outlines with things like
:focus { outline: none } ?
<aboxhall> dbaron: yup
dino: Why not just defer to the ARIA role?
<shane> aboxhall: why not trigger different behaviors via aria
role?
dbaron: And general design with ARIA is that it doesn't influence
outside the a11y space
<aboxhall> +1 ARIA shouldn't affect anything other than the a11y
tree
<aboxhall> unless the author decides it should
[general agreement with this policy]
<aboxhall> Wait, earlier were we saying texty *should be* the
default behavior?
<shane> no we were saying it is the default behavior
<TabAtkins> yeah, aboxhall, because it's the default on all
elements today, so it needs to be the initial value of
the new property
<aboxhall> omg no
<aboxhall> then we end up back where we started
<aboxhall> buttony should be the default behaviour
<aboxhall> if you want to always see an outline, use :focus
<TabAktins> How does the "default behavior" send us back to where
we started?
<aboxhall> so you'll need to specify "not texty" on everything
which isn't texty (which is most things)?
shane: So second thing we want is the ability to refer to the
browser's default focus styling.
Florian: outline-style: auto does this
dino: Our focus impl in Safari is slightly wrong - it should be
slightly animated glowy outline.
Florian: With outline-style:auto, it can even change the shape of
the outline.
Florian: Can, but not required to follow the outline-color.
shane: So, Alice, can you explain your preference.
aboxhall: If we default to texty, we end up where we are today -
aboxhall: Most things aren't texty, right?
TabAtkins: Yeah, but also most things aren't buttony?
aboxhall: I think if it's focusable they're more likely to be
buttony.
aboxhall: Today people take the focus ring off things because they
don't want it to act texty.
aboxhall: So the buttony behavior, which people actually want,
should presumably help prevent people from removing
focus outlines from things.
* fremy doubts that statement; devs remove focus rings because the
designer told them he/she don't like it
[convo back and forth a bit over exactly how this would be applied]
* fantasai doesn't think focusability belongs in CSS
* shane thinks that ship has already sunk
TabAtkins: So if this affects :focus-ring, and we re-base our
impls to use :focus-ring in the UA stylesheet, this'll
be a behavior change for all tabindex elements. Is that
ok?
aboxhall: I think it's a positive behavior change, yes.
[a bit of banter over why devs remove focus rings]
TabAtkins: So proposal is that the default of shmocus-mode is
buttony, which has the knock-on effect that arbitrary
tabindex'd elements will change behavior (no longer
focus-ringing on click)
aboxhall: Yes. And remember that this won't affect anything that's
currently outline:none, or using :focus. Just default
elements, and things targeted by :focus-ring.
astearns: So does anyone have an objection to doing this?
<fremy> astearns: I am not convinced at all this is a good thing
<fremy> @astearns: but ok, no strong opinion
<astearns> thanks, fremy
RESOLVED: Come up with a property name for this focus-ring
property, ratify the CSS-a11y TF, put it in css-ui-4
aboxhall: One added thing - the way :focus-ring is specced, it
leaves it open to the browser what heuristic to use to
apply :focus-ring.
aboxhall: Obviously this property can be part of that.
aboxhall: But one feedback from a11y folk is that some people
always want to see the focus ring, others find the focus
ring always confusing. So there could be a user setting,
similar to the Chrome Mobile setting that lets you force
it to always allow resizing.
TabAtkins: Yeah, that's generally allowed. And if the user
stylesheet exists, it can override authors with a
!important rule.
Florian: I just checked out outline-style. By spec you have what
you want, in Safari you have what you want. In Chrome you
get a *different* fancy outline; in Firefox you get a
plain outline; in IE you get nothing.
[discussion of how to test outline-style: auto in a reftest]
<br dur=15min>
Received on Saturday, 27 May 2017 01:02:18 UTC