- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 17 Jan 2018 20:01:34 -0500
- 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.
=========================================
Move overscroll-behavior spec from WICG to csswg-drafts
-------------------------------------------------------
- RESOLVED: Bring the overscroll-behavior spec to CSSWG drafts as
an ED.
CSS Shapes
----------
- RESOLVED: Leave the spec as is, will not extend the spec to
support the item raised in #2175 (ellipse with single
<shape-radius>)
Values & Units
--------------
- Several implementors stated that they would eventually implement
the previously resolved change to the <position> spec that
3-valued positions would no longer be part of <position> syntax
for any properties other than background-position.
CSS Fonts
---------
- RESOLVED: No change for issue #1531
- Vlad raised a concern that there are some assumptions in the spec
as to how all fonts behave that may need to be re-examined. He
will file a new issue to work through validating any
over-generalized behaviors.
FXTF/Filter Effects
-------------------
- When trying to determine what the correct spec behavior is for
FXTF issue #238 (What should happen if filter and
background-attachment fixed; applied to the same element?) the
group discovered that everyone lacked clarity on the proper
order of operations involved so krit will try and develop the
correct order which should add clarity for the correct solution.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jan/0094.html
Present:
Rachel Andrew
Rossen Atanassov
David Baron
Amelia Bellamy-Royds
Dave Cramer
Alex Critchfield
Benjamin De Cock
Simon Fraser
Tony Graham
Dael Jackson
Brad Kemper
Vladimir Levantovsky
Chris Lilley
Peter Linss
Thierry Michel
Myles Maxfield
Anton Prowse
Liam Quin
Dirk Schulze
Jen Simmons
Alan Stearns
Lea Verou
Greg Whitworth
Eric Willigers
Regrets:
Michael Miller
Melanie Richards
Florian Rivoal
Scribe: dael
Move overscroll-behavior spec from WICG to csswg-drafts
=======================================================
github: https://github.com/w3c/csswg-drafts/issues/2179
Rossen: Since Florian has sent his regrets, is tantek or Chris able
to represent?
Chris: I'm here.
Rossen: Can you present this since you're active on the thread?
Chris: Okay. This is a proposal for the overscroll-behavior. It's
been incubated. There's 2 implementations, 1 shipped one
about to be. A bit late to move it but it should be. I wrote
to the Facebook AC rep asking them to join. This seems a
reasonable spec and reasonable to pick up. tantek was also in
favor.
smfr: I'm in favor for Apple.
Rossen: Okay.
Rossen: Any objections to bringing the overscroll-behavior spec to
CSSWG drafts?
RESOLVED: Bring the overscroll-behavior spec to CSSWG drafts.
Rossen: Chris will this transfer as an ED?
Chris: Yes and then we have to do the FPWD thing. I think
scroll-anchoring was the first we moved.
Rossen: So what we did there we replicate. We bring as ED and then
do first public working draft.
Chris: Exactly.
CSS Shapes
==========
ellipse with single <shape-radius>
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2175
ericwilligers: I want to know, should we adopt what blink and webkit
have shipped or is this a bug? I've only just noticed
so I started a use counter but we won't have data for
months.
Chris: What they have is a bit weird. It's more of an error
correction as far as I can see.
astearns: This is just an error case so I don't mind what we choose
to do. Going with what's impl seems easiest.
ericwilligers: We could easily do what AmeliaBR suggested.
fantasai: Does web content use this format?
ericwilligers: No idea.
Chris: Use counter was just installed.
<smfr> shapes are very little used in the wild
fantasai: As AmeliaBR points out it's very unusual for us to not
double in both axes. If there isn't web content dependency
it makes more sense to do that. There's only one place we
don't do that, background-size, and I consider that a
mistake.
Rossen: ericwilligers when do you expect data? If this is still very
early on and it's a bug level fix to back out by preference
is someone who is going to be impl down the road would be to
go simpler and not have that behavior.
ericwilligers: 12 weeks until data.
Rossen: Okay. Wow.
ericwilligers: Maybe you can collect data server-side. I've never
done that.
<AmeliaBR> Current spec is that single radius value is invalid, so
it would be fine to add support for two values later.
<AmeliaBR> The problem is Blink/WebKit supporting one value, but
with a non-intuitive behavior.
gregwhitworth: Can we resolve one way or another and if the data
comes back and proves us wrong we can revert? I don't
see a ton of use of Shapes in general.
Rossen: We can. We'll have to resolve today for the spec text. In
the presence of more evidence and patterns on the web we can
re-discuss. For now I wanted to hear from blink engineers if
you'd push back in terms of resolution.
smfr: I would be fine to treat this as a bug fix in webkit.
Rossen: Blink?
ericwilligers: I don't see any benefits of the current approach. I
wouldn't be able to change without data.
Rossen: We're talking about changes to spec. Impl changes would
happen when you get the data. I'm asking if you object to
resolve on the contrary to your current behavior. In the
presence of more data we'll review again.
ericwilligers: No objection.
Rossen: Sounds like 2 impl shipping are not objecting to keeping the
spec as-is. Any other opinions/objections?
RESOLVED: Leave the spec as is, will not extend the spec to support
the item raised in #2175
Values & Units
==============
Retiring support for 3-valued positions (excluding background)
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2140
fantasai: There's an issue from ericwilligers with some data about
the incidence of 3 value syntax and checking if we want to
go ahead with that.
ericwilligers: We made a spec change months ago, but I don't think
any impl changed. Do we still support the spec change
and are impl planning to change if so? I don't think
one impl will change if the others aren't good to
change.
Rossen: You're saying based on your data this is a safe change?
ericwilligers: Yes.
Rossen: Current proposal is that for basic shapes, gradient, object
position, and perspective origin to remove support for 3
value positions is safe and we should do it.
ericwilligers: Original motive was so we can have % adjacent to
positions. That's the motivation since it was
ambiguous. If you have a position followed by a
length you wouldn't know what it was.
fantasai: Yes, the issue was we wanted to use position in more
places.
<fantasai> Like transforms
Rossen: What are impl opinions? Sounds like ericwilligers/Blink is
willing to adopt the change. I would have to check what that
means for our (Microsoft) logic and if that would disrupt
some of the uses we have of positions. If this will hurt
more then help. But I don't believe this will be the case so
I don't object to going ahead with this.
Rossen: I'd like to hear from webkit and gecko.
smfr: I don't have a good feel for web compat risk so I won't know.
Rossen: Is this something you can gather that will be more then the
data posted by ericwilligers? Or will you rely on
ericwilligers' data?
smfr: We don't have data gathering as fine-grain as ericwilligers's
data.
smfr: We'd be willing to change as long as we don't find internal
content that would break.
Rossen: Gecko?
dbaron: We'd be fine to change if other engines are willing.
Rossen: So ericwilligers it sounds like more or less everyone is
willing to change. Is this something you're looking for in
terms of time frame? Is it on your schedule?
ericwilligers: This is fine. I consider that intent to change.
Before I put it before the community I wanted to
check position, but everything is fine. I'll send out
intent this week.
Rossen: Anything more on this?
ericwilligers: No.
Rossen: Doesn't sound we need a resolution because we have one to
change. Now it's mostly an agreement of when to roll out the
change. Thanks.
CSS Fonts
=========
Should the OpenType spec dictate the acceptable values for variable
font CSS properties?
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1531
myles: There was an issue that was raised with a bunch of pieces.
All but one were misunderstandings. One has become an issue.
In a variable font there are axes. There's a weight one for
example. The question is should there be limits on the
acceptable values on these axes? If yes, what?
myles: For oblique you may not want >90. Weight no greater then 999.
Etc.
myles: This came up because italic. There's two popular font formats
and they both support variations. Open Type spec says it has
limits on axis values, but true type doesn't have limits.
myles: When I wrote the spec I allowed both to be supported, however
the issue is brought up saying that maybe it should be
limited to the values in open type.
myles: That's problematic because we won't be able to use both types
equally.
<Vlad> I think there is a lot of misunderstanding here, and many
assumptions need to be verified prior to making a final
decision.
<Vlad> For details, one might want to look at
https://www.microsoft.com/typography/otspec/otvaroverview.htm#CSN
Chris: I'm not sure I'd put it the same way. I understand aat does
things differently. It's not just range, but default values.
I remember I fell into this using a non-open type font and
the ranges were something like 0-4 and that was problematic.
Chris: To my mind most of fonts 3 and 4 are based on open type. Then
we said how other formats map to that. I don't mind if it
says for aat fonts there are different things. Where open
type has the same range for everything is more intuitive.
myles: I understand that point. Counter is there are default values
in the true type spec. There is a straightforward mapping to
the scales CSS uses. I don't think...we are making a new
standard so we should make one that both font files apply
equally. It's possible.
Chris: Could you say more about the it's possible? If they're using
different initial values I don't understand how to compat.
myles: The scales can be linearly mapped. For weight CSS says
default is 400, true type is 1.0. 1 maps to 400, 0 to 0.
Chris: Okay, okay. hmm.
Chris: That sounds persuasive.
Chris: I don't want to be reluctant, but seeing spec text would make
me happier. I would like to see specifically what you want to
change.
myles: Proposal in the issue is limit the acceptable range to the
italic variable fonts axis.
myles: Proposal was change the spec. I would argue we shouldn't
change and accept all values because both fonts can work with
that.
Chris: That's for italic where it doesn't mean oblique.
myles: Yes.
Chris: Then I'm a lot happier.
<Vlad> I think we should carefully revisit this topic. I believe
many assumptions about what the variation axis value
represents need to be revisited.
jensimmons: I'm working with a team looking at variable fonts as we
design tooling.
jensimmons: We were thinking of weight with a slider at 0 to 1000
where a font may have juiciness between 200 and 800, but
the slider would show the whole thing. Sounds like
that's what you're talking about where css has an upper
range limit and I would say yes. We could make a better
tool. Elsewise the only numbers are those in the font.
jensimmons: Then the tool would change as people go font to font and
they're trying to set fonts for all of a stack.
Chris: That's what I was trying to set. But people use font stacks
less and they're more setting features on a font and
providing it. The idea that you would set two values I'm
trying to avoid.
myles: I want to also. My position is that for the axes browsers
know there is one scale representable for that axis. CSS desc
that, browsers impl that, then that scale is mapped to the
underlying font tech to make that font have the desired
effect.
Chris: sgtm
Rossen: Sounds like we're coming to a consensus.
Rossen: One person that's IRC only and was active on GH is Vlad. I
want to make sure his point is looked at.
Rossen: Vlad are you on the call?
<Vlad> I am on the call but you don;t seem to be able to hear me
Rossen: We cannot hear you.
<Vlad> Let me try another audio connection
Rossen: While Vlad tries to fix his audio, Chris or myles did you
get to read his IRC comments?
Chris: I read them, but I don't know what he means exactly.
Vlad: Sorry about that. I was trying to say that I'm fine with
leaving as is, but I think we need to revisit carefully in
detail. Assumptions we make in what the font variation axes
are may not hold. Even for weight the assumptions we make that
all fonts can support a particular limit is not true, that's
up to the designer.
Vlad: We can't easily resolve right now so we can leave spec as
written, but we need to make an effort to ensure what we have
will be usable when spec if finalized.
Vlad: Example regular and condensed fonts, the weight axis is not
determined by character stem width. Weight is how heavy the
font is and the condensed will look more heavy with the same
stem size. Weight is somewhat relative. Therefore assuming 900
looks the same is not true, nor is it true 900 is always
supported.
myles: I'm happy to go through this in the future with you.
Vlad: I just wanted to make sure that nothing is set in stone right
this moment.
Chris: Vlad remember the descriptors can say what range, like this
font is 100-350 and if you ask for 500 you get a different
font.
Vlad: Yeah. But some axes, like italic, don't have a particular
range and the variation may change for fonts. Oblique is more
straight forward. The variation for italic isn't as
deterministic as slant, for example.
Rossen: I'm trying to see if we can scope an end. Vlad with the
current proposed resolution it doesn't sound like we will be
constrained with the concerns you have.
Rossen: And reading myles he'd be happy to revisit this when we get
to it.
Vlad: What I'm saying is what's in the spec is based on assumptions
about font behavior where there are variations. We need to
revisit those assumptions before we make a final call.
Rossen: Do you guys want to go back to GH?
myles: I think what Vlad is covering is a secondary issue. If you
have specific places where it may be broken I'd encourage you
to open new issues. On this specific topic I'd hope we can
resolve.
Vlad: My concern is this particular issue where the new name from
it, I don't think that's even possible. Open type spec
couldn't dictate even if you want it too. Variation values are
normalized to what the font designer encoded. The effect of
the variation axis will not be the same for every font. I'm
not sure how to take the issue title.
myles: The way the spec is designed there are 3 axes the browser
understands. For those 3 I think it's reasonable there's a
scale where if an author sets a value in the scale the
browser can do whatever in that scale to represent. If the
axis is something the browser doesn't understand what can it
do?
Vlad: I'm fine with this issue. But I think you're assuming the
browser will know what to do with a value and I don't think
that's always true.
myles: You should open a new issue for that.
Rossen: So for the current, proposed resolution is?
myles: No change.
Rossen: Proposed resolution is no change.
Rossen: Objections?
RESOLVED: No change for issue #1531
<fantasai> myles: Somewhat related question: how do you handle the
different axes of slant?
<fantasai> myles: e.g. in vertical text
Default feature list should not require a list of features to turn on
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1267
myles: I needed to do homework for this topic and I didn't so we
should defer.
FXTF Items
==========
Rossen: There's a number of FXTF items. I don't know who has time to
review what. krit and AmeliaBR are on the phone, I believe.
There's many issues, but if there's 1 or 2 on the top of the
list I'd like to know which.
What should happen if filter and background-attachment fixed; applied
to the same element?
---------------------------------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/238
krit: In certain cases it's possible to fix an object. When you look
at the 2nd link in first comment there's an example. You can
open in any browser except Safari. Element is fixed, has a
filter applied. When you scroll down user expects top line is
blurred as well. You can watch that in FF or Chrome to see
difference.
krit: On the top row there is always some white because something
outside the box is tagged for blur. User expects once you
scroll you don't take white.
<krit> https://jsfiddle.net/3bdv532b/
krit: Safari you can see that or there's an example ^
krit: If you try to get this link open in any browser you'll see the
difference.
krit: If you open it you can scroll down a bit, element is still
fixed, top row doesn't have white. Scroll up and there's
white. That's a very specific issue. User expects there's some
indication on the fixed element.
Rossen: For what it's worth I see Edge has same behavior. We have
some issue with fixed background that I'm hoping we'll fix,
but it seems we're handling the same...uh, sorry. We're same
as Chrome and FF. This isn't what spec defines?
krit: It's what the spec defines. But the author expects what you
see in safari.
krit: You can see that from the jsfiddle, it's an emulation of the
correct behavior using JS.
krit: If you scroll down you don't see white on the top.
krit: I do think that behavior of Edge/Chrome/FF is as spec
intended. But for users it's a better indication if the blue
scrolled with doc as the background stays fixed.
krit: You could argue there's a JS work around. And I'd be in favor
of staying with current.
Rossen: So you propose no change?
krit: Right.
<Chris> No-one can hear me, but for me the fiddle is working very
oddly in firefox
AmeliaBR: I haven't looked carefully, but if Safari is different
it's probably how they handle edge mode of blurs. I'm
pretty sure the other browsers aren't matching spec unless
spec was changed. It's about avoiding edges of elements
getting eroded when you blur the element and that's what
we see. We're first clipping and then blur erodes.
krit: Spec states that what you draw on the screen gets filtered
after. Therefore what you should see is what you get from FF.
There's nothing beyond doc top if you want to put it that way.
smfr: I'm not sure spec says what happens outside doc bounds. For me
Safari makes more sense. Other browsers are pulling in white
from beyond doc bounds which doesn't seem right.
krit: Does background get clipped to viewport? If it's beyond you're
probably right.
smfr: I don't think we ever spec that. Maybe filter should spec what
happens when you can potentially get pixels from outside the
viewport.
Rossen: Is this viewport or any scrollport?
smfr: Anywhere with clipping I guess.
Rossen: From that PoV I wouldn't want special casing for viewport.
Rossen: It's general for all scroll port.
smfr: If this was inside overflow hidden you'd expect pixel from the
outside content maybe? So maybe experiment with blurred things
inside and see what the pixel effects are. That's a more
general.
smfr: This specific problem is pretty irrelevant. I haven't seen a
page to do this, but it would be good to spec carefully.
krit: If an object is clipped with clip path it's clear, but here
clipping is implicit by the browser itself.
smfr: You have to think about order. If there's clipping and
blurring we clip and then blur. If the ancestor clips and blur
is descendant that's more similar.
Rossen: Right.
smfr: I don't know if we have a good desc of the ordering these
effects occur in. I don't think it's written you clip then
filter.
<dbaron> I think there are some open github issues about specifying
the ordering...
AmeliaBR: General is clip after filter. Nobody has written in any
spec how that applies to something like background
attachment, but generally clip after filter.
smfr: Not sure that's what we impl.
fantasai: Clip to a whole element, I think you filter to the whole
element and then clip. Backgrounds are different, you draw
it and then filter then clip it.
fantasai: Background is clipped to the boundaries already because
it's only drawn to the element boundaries. You draw
background into the area and then we filter the whole
thing that results.
AmeliaBR: Good point.
fantasai: We need a background filter property, but we don't have
one.
AmeliaBR: That's different effects. What fantasai is saying is that
the background is acting like a child to the element where
it gets clipper earlier in the rendering. Overflow on the
element is a clip after filter, but background attachment
is at a different place.
Rossen: We're nearing the end of the call. We have some fairly basic
order of operations and based on this discussion we don't
have a clear explanation of what happens when in the combo
of backgrounds, no backgrounds, clip, clip-path etc. I would
be curious to see if we can agree on the order and from that
we should be able to extrapolate what this should do in
terms of clip and blur
Rossen: Would you be interested in putting that inside this issue
krit?
krit: Yes, I think we should.
Rossen: We're at the end of the call. I don't think we can resolve.
I suggest going back to the issue and continuing.
Rossen: I also want to invite anyone in the CSSWG participating in
FXTF to look at all the items in the agenda and participate
before next week. We'll continue discussing open items as
time permits.
Rossen: Thanks for calling and we'll chat next week.
Received on Thursday, 18 January 2018 01:02:30 UTC