- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 1 Oct 2015 06:45:25 -0400
- To: www-style@w3.org
Joint Meeting with WebApps @ TPAC
---------------------------------
- Tuesday afternoon is the best option for a joint meeting.
Sydney Dates
------------
- The Sydney dates are January 30th and 31st for Houdini, February
1st to 3rd for CSS, February 4th to 6th for SVG.
'polar-anchor' Property
-----------------------
- Jihye reviewed her proposal for 'polar-anchor', available here:
https://lists.w3.org/Archives/Public/www-style/2015Sep/0234.html
- Generally there was agreement that this was useful and the right
direction for this property.
- There was concern that the property could still cause overflow
even though this property was designed to prevent it.
- 'auto' seemed like it could be what prevents the overflow, but
was under-specified in this proposal and needed to be fleshed
out more.
- RESOLVED: Add 'polar-anchor' with issues for better specifying
'auto' and percentages.
Reverting 'animation-timing-function' Change
--------------------------------------------
- dbaron has made the edits to Animations to revert the change.
Computed Values of 'translate', 'rotate' and 'scale'
----------------------------------------------------
- TabAtkins will make the proposed changes to the spec.
ruby-merge
----------
- The group will let fantasai and Richard Ishida come to a solution.
:focus-ring
-----------
- The proposal was to add :focus-ring to allow authors to only
style the focus ring when the browser would normally trigger a
focus ring as a way to narrow-down the more generic :focus
pseudo-class
- There were concerns that this would have negative accessibility
implications, but it was argued those implications exist
within :focus and should be addressed there- this makes the
problem no worse than what already exists.
- The name seemed problematic to some people so it may need
bikeshedding later.
- RESOLVED: Add :focus-ring to Selectors 4 or 5
Stacking Context at animation-start
-----------------------------------
- In the following example, the stacking context would happen at
the 49% keyframe:
@keyframes move {
from, 49% { transform: none;}
50% { transform: translateX(10px); }
to { transform: translateX(100px); }
}
<div style="animation: move 10s"></div>
===== FULL MINUTES =======
Agenda: https://lists.w3.org/Archives/Public/www-style/2015Sep/0300.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Adenilson Cavalcanti
Tantek Çelik
Dave Cramer
Alex Critchfield
Greg Davis
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Jihye Hong
Dael Jackson
Brian Kardell
Chris Lilley
Peter Linss
Myles Maxfield
Simon Pieters
Anton Prowse (IRC Only)
Matt Rakow
Florian Rivoal
Simon Sapin
Alan Stearns
Lea Verou
Ian Vollick
Greg Whitworth
scribe: dael
plinss: Let's get started. Anything to add to the agenda?
<Florian> http://www.w3.org/mid/C717D9A5-8A02-4598-935F-EB83E10D5FF0@rivoal.net
plinss: I'll take that as a no.
<Florian> The mail I pasted above is extra agenda items I'd like
to get to, but WebEx isn't working, as you can't seem to
hear me. Rebooting.
Joint Meeting with WebApps @ TPAC
---------------------------------
plinss: This is a joint meeting to discuss ShadowDOM styling.
plinss: They're proposing Monday or Tuesday. Any constraints for
time? jdaggett prefers Tuesday afternoon.
Rossen: Is that a joint meeting discussion?
plinss: Yes, for ShadowDOM. Any preference or constraints between
Monday and Tuesday afternoon?
Rossen: Either works for me.
plinss: Current proposal is Tuesday afternoon from jdaggett. Let's
go with that.
Sydney Dates
------------
plinss: I have on my calendar Jan. 30, 31 Houdini. Feb. 1-3 for
CSS, Feb. 4-6 for SVG. Does that agree with everyone else
and any reason to change it?
Rossen: Is that what's on all the wikis?
plinss: It's what's on the feed. Let me check the wiki.
dbaron: I think it agrees with everything except maybe SVG because
they shifted a few days.
plinss: It agrees with CSS.
Rossen: Then it should be fine. If that's what the wiki says I'm
good.
plinss: Let's consider those dates in stone.
'polar-anchor' Property
-----------------------
Jihye: I'm from LG Electronics, the editor of Round Display. I
wanted to talk about 'polar-anchor', a new property related
to round display.
Jihye: While discussing it at the F2F in Paris there was a concern
about overflowing within a containing block. Using only
polar-angle and -distance to position we have to adjust to
avoid elements coming out of the containing block.
Jihye: To solve this 'polar-anchor' was suggested. It sets the
anchor of the element and specifies a position that is a
representative point of the element aligned with the
containing block.
Jihye: I referred to background position property for this. It
takes value type <position> which is defined in the
background position property. Any point in the content can
be an anchor point.
Jihye: When you can see the polyfill I mentioned in the mailing
list there are 12 elements in circular layout.
Jihye: Please see my message on the mailing list, reference #4. I
implemented 'polar-anchor' as a polyfill so you can see and
example.
<astearns> http://anawhj.github.io/jRound/demo/polar/anchor.html
Jihye: There are 12 elements in a circular layout.
Jihye: First, 4th, 7th, and 10th are set to top, right, bottom,
left.
Jihye: The anchor of 2nd and 3rd are right-top
Jihye: Those of 5th and 6th are right-bottom.
Jihye: 8th and 9th are left-bottom, 11th and 12th are left-top.
They are set according to the value of polar-angle.
Therefore the exact distance value between the center
points and the edge of the containing block become polar-
distance value so you don't need to adjust it to avoid
overflowing.
Jihye: So I want to ask you is this 'polar-anchor' useful enough
to be a new property?
Florian: Yes, I think it's good. You're e-mail included the 'auto'
value and I'm guessing it would mean you wouldn't need to
say top-right on 2 and 3, etc. and it would guess based
on the angle. I think that would be useful and difficult
to specify. Even without that it's useful so I'm in favor.
Jihye: Thank you.
Jihye: And the name of this property is appropriate?
Florian: I think so.
<dbaron> I don't understand how polar-anchor interacts with
polar-angle and polar-distance
Florian: There's a comment on IRC from dbaron saying he doesn't
understand. If I do, the polar-anchor says which point in
the element that you're placing using polar coordinates
is measured from the center of the containing block. If
you do top-left you're positioning the top-left of the
element from the center of the containing block. The
default is center center.
<dbaron> ah, ok.
Jihye: Yes, default is center center
Jihye: What was your question?
Florian: It was dbaron asking how it worked on IRC so I explained.
<astearns> if I understand correctly, if the 7 box is much wider,
it's bottom left and right corners would still overflow
the circle.
<Florian> astearns: I believe so, yes. But presumably not with the
auto value (which is not polyfilled here).
Jihye: When the anchor point is set within a content box of the
element then the represented point of the element, which
point is mapped in the containing block is decided.
Jihye: Anchor point is center center then the center point of the
content area of the element is mapped to the point of the
containing block.
Jihye: When you put the element whose anchor is center center to
the edge of the containing block some part of the element
overflows.
Jihye: Can you understand it?
Florian: I think that's what astearns was saying on IRC.
<fantasai> The 'auto' value basically says "position like bg
position works"
ChrisL: The numbers are irregularly spaced because there isn't a
consistent position and I think the reason for that is
that the demo is trying to make sure it doesn't go over
the edges. [cutting out]
ChrisL: In general this proposal doesn't guarantee you won't go out
...it depends on the shape that uses the alignment point.
<ChrisL> It seems that this would need a clipping behaviour.
Florian: So if I understand this, yes if you're using the explicit
position keywords depending on the shape of the element
and the container you will have a chance of overflow. The
auto should make this magically not overflow. What I'm
less sure about is how auto works when the distance is
not 100%.
Jihye: In the polyfill I didn't consider auto.
plinss: What I'm hearing is people agree it's useful, but there
are questions about how auto works and it doesn't seem to
completely guarantee no overflow so there may be work
there. It's a good start.
Jihye: Thank you.
Jihye: I'm curious, is value type <position> acceptable for
'polar-anchor'?
Florian: I guess so. What I think we should do is resolve to add
this, see how you write it, try to resolve the issues
around auto, and depending on how well it works maybe we
don't need <position>.
Jihye: Okay.
Florian: What do others think?
<TabAtkins> Without a well-behaving (and well-specified) auto
value, I'm not convinced <position> is worthwhile.
<TabAtkins> The trig you need to do to figure out where it should
go can just as easily be used to adjust polar-distance
with a fixed (center) anchor.
dbaron: I feel like <position> is awkward when you're at an angle
that's not a multiple of 45deg. If you look at the clock
example the numbers are a bit uneven.
Jihye: Between 1 & 2 and 2 & 3?
dbaron: Yeah.
Jihye: I will think about that, thank you.
<ChrisL> dbaron, I explained why they are uneven earlier. look at
the css
<ChrisL> #item3 {
<ChrisL> position: polar;
<ChrisL> polar-angle: 60deg;
<ChrisL> polar-distance: 100%;
<ChrisL> polar-anchor: right top;
<ChrisL> }
<ChrisL> #item4 {
<ChrisL> position: polar;
<ChrisL> polar-angle: 90deg;
<ChrisL> polar-distance: 100%;
<ChrisL> polar-anchor: right center;
<ChrisL> }
<ChrisL> different alignment points
dbaron: I wonder...I think having square boxes around the numbers
seems a bit awkward as well so I don't know if that's
messing with my view of the example.
dbaron: The way background position works is if you say 75% 75% it
aligns a point that is 75% 75% in the image to the point
that's 75% 75% in the box. I wonder if something more like
that would be useful here.
Florian: Or...I think now it's positioning the anchor so when
you...I think when you do an angle and a distance it
should still work from the center but use the anchor to
avoid overflow. That doesn't make sense. What we're
trying to do is adjust how far the element is moved out,
not adjust the line of how far it's move. Anchor seems to
be doing both.
Florian: But I still think it's difficult to talk without details.
I'm in favor of writing it and working on issues from
there.
plinss: Agreed.
Florian: Should we resolve?
TabAtkins: I'd rather see a well specified auto value or some
fixes to percentages before we resolve. Without that I
don't think it's useful.
plinss: Let's see it added to the ED so we can work on those.
fantasai: You can add it with those two issues.
plinss: Yeah.
RESOLVED: Add 'polar-anchor' with issues for better specifying
'auto' and percentages
Reverting 'animation-timing-function' Change
--------------------------------------------
dbaron: I don't know if there's anything to discuss. Everyone on
the list agreed. I reverted the one change though there's
a bunch more editing I haven't gotten to.
plinss: Okay.
Computed Values of 'translate', 'rotate' and 'scale'
----------------------------------------------------
TabAtkins: I agree with what dbaron said and I'll make the edits.
plinss: Other opinions?
ruby-merge
----------
plinss: Richard Ishida sent some e-mails on this. Can anyone speak
to it?
Florian: If anyone it would be fantasai.
fantasai: I sent a message to the list yesterday, I don't know if
there's been time for Richard to reply. It was suggested
there should be a value that triggers Jukugo ruby as per
JLREQ and that the rest of it should be dropped. I don't
have a response from Richard.
plinss: Anyone else have comments or are we okay with letting
fantasai and Richard sort this out?
TabAtkins: Yep.
:focus-ring
-----------
TabAtkins: If you remember at the last F2F we had a discussion
with bkardell about input modality. We've been working
through the issues with bkardell and Alice Boxhall to
find the simplest way to solve the use cases.
TabAtkins: We're still working things through, but one thing seems
obvious. Whenever the author wants to style the focus
ring because it doesn't match the website's style: They
can use :focus styling, but they can't style it only
when the browser would have applied focus rings.
<bkardell> ala
https://developer.mozilla.org/en-US/docs/Web/CSS/%3A-moz-focusring
TabAtkins: The idea is to add a pseudo-class that applies only
when the browser would apply a focus ring and we say
the UA is styled with that pseudo-class.
TabAtkins: We thought that was generally useful. Mozilla already
has something that is basically this.
bkardell: I shared it in the IRC.
Florian: I agree this is a nicer way to address it, but we should
wait for the use case hunt to end.
TabAtkins: This seems useful no matter what the other conclusions
are. What other functionalities we might need is what
we're waiting on. This is independently useful
regardless of how we decide on the other pieces of
input modality.
Florian: Depending on what we find if we see the :focus-ring can
solve almost all the use cases we might want to change it
to solve all of them.
TabAtkins: That should only happen if we take two years. If we
find we need to tweak it it would be in the next few
months.
<tantek> I'd like to hear from bkardell
<tantek> rather than speculation
* bradk thinks the name is weird. Should be something like
:browser-chosen-focus
* bradk "ring" is meaningless to indicate that it is a focus that
doesn't apply to everything.
Rossen: One concern I have is focus ring could be viewed as system
specific between different OSs. Different implementations
may want different ways to handle a11y scenarios which the
page author may or may not be handling. With giving
authors the ability to style focus ring they may fight
with a11y primitives.
TabAtkins: They have that ability already. The :focus pseudo-class
lets them do that. This narrows the meaning of focus so
that it doesn't happen when a browser doesn't normally
trigger a focus ring.
bkardell: I see a lot on IRC about name bikeshedding. I agree we
can bikeshed. I think conceptually Alice and I agree
that the crux of the problem as it manifests today is
authors have no way to be privy to the knowledge the
browser has. The :focus pseudo-class is unfortunate in
that your use of it messes with the a11y.
bkardell: :focus-ring is intended to just bubble up whatever the
browser decides will get the focus ring and allow you to
style it better without effecting a11y.
bkardell: As to if we need more properties, this is a useful
exercise to drill down and see. If we need to go further
it lines up with our existing proposal. I don't think
this precludes others.
Rossen: I have my reservations. If we could go back I'd prefer
this to be a global media feature that's set once not per
pseudo-class...
TabAtkins: I'm not sure what you're proposing there.
TabAtkins: Is what you're proposing relevant to the fact that
people can override focus rings today by messing with
the outline property.
Florian: Authors today cannot know if they're overriding or
creating one where it shouldn't be.
TabAtkins: Rossen's reservation was about overriding. We're not
introducing new functionality.
Rossen: Okay. Consider it a rant about past decisions.
bkardell: If you'd like to talk more privately I'd love to hear
what you have to say.
Rossen: Sure.
<bradk> :focus:not(:focus-ring) ?
TabAtkins: So given that :focus-ring is a subset of :focus, any
objections?
plinss: If this pseudo-class is triggered then :focus is triggered?
TabAtkins: Yes.
<tantek> are we talking about just standardizing
https://developer.mozilla.org/en-US/docs/Web/CSS/%3A-moz-focusring ?
Florian: I've considered if a :focus-ring-within thing would be
useful and I think probably not. That extension doesn't
need to be repeated.
TabAtkins: Yes. I think you want to be able to put a focus ring
style in your document and you don't want that to apply
to everything that has a focus ring.
tantek: Are we standardizing what moz-focusring does?
TabAtkins: It's basically moz-focusring.
tantek: Okay. That sounds good to me.
bkardell: Only caveat is we would like a way for custom elements
to define their behavior. Are they more like a button or
text input field.
TabAtkins: And that's where conversations are ongoing, but that
will interact with this pseudo-class.
tantek: I think we should capture that as an open issue rather
than try and solve it.
<bkardell> +1
tantek: We can specify this without solving that.
bkardell: I wouldn't be bowled over if the group was opposed to
that. I don't see a high bar to that.
tantek: Let's capture the custom element part as an issue.
TabAtkins: It should be a part of the custom elements. Now that
we've agreed on level 1 that should arrive shortly.
tantek: Okay. I'm fine with capturing this where ever.
TabAtkins: This would go into selectors 4 or 5. 4 isn't
unreasonable because it has one implementation and
requires no new functionality so it's a pretty minor
feature.
tantek: Is Chrome committing to shipping this soon?
TabAtkins: I can't speak directly to that, but I don't think we'd
have opposition.
plinss: Objections?
smfr: Is the intent that the author would only change the outline
style?
TabAtkins: It's a selector. You can change what you want.
tantek: Yeah, we often have selectors that can limit.
TabAtkins: We have pseudo-elements that have limits, but that's
due to the nature of the elements.
plinss: There's no restrictions on :focus.
bkardell: Someone in the community group raised that they thought
it should be a pseudo-element.
TabAtkins: We're not creating anything new on the tree.
bkardell: I wanted to check for agreement
Florian: I agree.
plinss: I do too. There may be a reason for an pseudo-element
later, but that may be just for a11y reasons.
<bradk> Would :focus-ring override:focus? Or would they both
apply?
<bkardell> a ua default sheet could !important display
smfr: I'm concerned that if this is used incorrectly you could get
a state where it flickers in and out. You could set display:
none and it would shift. I'd rather limit it to something
that only applied to the focus ring.
TabAtkins: I think there's reason to tint the background element
for example. So I think there's reason to not just
focus the ring. If you change the outline it overrides
whatever the browser is doing for the focus ring.
tantek: smfr if you have specific examples that you think are
problems, post them with the moz prefix and we can treat
Firefox as the canary in the coal mine.
Florian: If there's a problem it's bigger than :focus-ring. All
the drag and drop might have a problem. All UI pseudo-
classes have that problem. We should solve this larger
problem.
TabAtkins: This is just a subset :focus to only do items that the
browser would normally create a focus ring on.
tantek: This is a subset of :focus
TabAtkins: Any arguments on this that would also apply to :focus
we should approach, but it's not something against this.
It's valid, but isn't related to this request.
tantek: Yes, anything that demos bad behavior we can demo with
:focus.
smfr: That sounds reasonable.
smfr: I don't like the name. It's also not obvious to me what the
UA would know when to stop stying it's normal focus ring.
TabAtkins: It appears the default is that if you set outline we
turn off the native style. We can capture that as the
default or make something more explicit, such as a
subset of outline that captures if it's being used as a
focus ring. That's a generic focus ring issue.
Florian: I agree that however we address that should go around
outline property, not around the selector.
smfr: I'm fine with that.
RESOLVED: Add :focus-ring to Selectors 4 or 5
* TabAtkins is thinking of "outline-focus: yes | no" (with better
names), set to "yes" by the UA stylesheet and
defaulted to "no" by the 'outline' shorthand.
<Florian> TabAtkins: Maybe. Do you want to make a Pull Request
against CSS-UI, then we discuss, and I merge if we agree?
Stacking Context at animation-start
-----------------------------------
<smfr> https://lists.w3.org/Archives/Public/www-style/2015Sep/0279.html
smfr: Before Paris I investigated a webkit bug. In Paris I spoke
to TabAtkins and dbaron about the scenario where you have a
set of keyframes and not all of them create a stacking
context. So this e-mail has an example where 50% onwards in
stacking. So when do they start the stacking context?
smfr: Originally I thought it was when the animation started, but
it looks like it starts at 49%. That's contrary to the
opinion I got from TabAtkins and dbaron.
TabAtkins: I didn't mean to indicate contrary to that. I assume
animations is applied in the simple way where you only
get stacking when you run into something that requires
it. Anything else would have required extra work. I
think that's correct. We should let animations change
properties. The will-change is appropriate for say you
will change the transform and you can create stacking
earlier.
<MaRakow> +1 to Tab
<vollick> If authors wanted to avoid jank due to stacking contexts
coming and going, they should use will-change as well,
then?
Rossen: I agree. I'd like it to be that values are applied as the
timeline of the animation goes. Any kind of chaining
doesn't need to be analyzed ahead of time which could be
costly. I'm not sure where you're going, but my guess is
with more stacking you get better layering which would
lead to better performance. As a general rule from our
implementation it would be hacky and cumbersome to analyze
ahead of time.
smfr: I bring this up because in webkit we'd prefer to hand off
the animation to an underlying graphics animation. I'd
prefer to not re-evaluate while it's running.
Rossen: I totally sympathize, but I'd rather have a static
decision where ether you let it be as is or you create
stacking at the start of any animation that causes
stacking. Trying to find out ahead means you have to
compute a bunch of styles.
TabAtkins: I think it's worse in the general web animations APIs
where you can have more complexity. I don't want to
limit it to small batches of keyframes when you can
create a large number. We have a property to indicate
that you will create stacking.
Rossen: The animation graph intersecting with the inheritance
isn't something you can find ahead of time.
smfr: I think will-change inside keyframes won't have an effect.
TabAtkins: It should still be respected via the resolution we made
a while ago about having non-animatable ones flip.
smfr: Okay. I'd like to hear from dbaron?
dbaron: I think I agree with TabAtkins and Rossen.
smfr: Okay.
smfr: I guess we don't need new text in animations since this is
the behavior that falls out from doing nothing.
TabAtkins: Yeah.
smfr: Okay.
<bradk> @tabatkins -internal-outline:1px dotted black;gets set to
none by shorthand in shorthand.
plinss: I agree with all that, but one complaint we come up with,
I hate that we have all these behaviors that are side
effects and we can't get at directly, like if it's
stacking context. I think we should have stacking context
always.
fantasai: If you set z-index to 0 it's stacking
TabAtkins: Not quite. You also have to set position: relative
<vollick> plinss: +1
<MaRakow> https://drafts.fxtf.org/compositing-1/#isolation
Rossen: We do have a property that's stacking context. It's a
compound property, but implementing or exposing is
straight forward. I'm not sure about useful. As to
containing blocks I second that.
plinss: It annoys me that there are so many things that say
position:relative just to get the side effects.
<dbaron> We actually changed opacity >= 0.99 to use the cheap
drawing path
TabAtkins: The isolation property from filter has the effect of
making it stacking so it can define your filter groups.
So that's one thing.
TabAtkins: For containing blocks, for block layout the display
spec defines the flow root type. For positioning we
don't have a way to trigger arbitrary position
containing blocking, which we should at some point.
Rossen: We'll have to figure out how that intersects with
positioning, but yes. I think we're taking a ranting
detour from smfr issue.
plinss: And we're over time. To close on smfr's issue, I think
everyone agrees you create stacking context when you
create stacking context, not beforehand.
TabAtkins: Yep.
Florian: I added some agenda+, can we do those next week? I also
wanted an update on the prefixing policy for next time.
plinss: Will do.
Received on Thursday, 1 October 2015 10:46:32 UTC