- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 21 Feb 2018 19:15:13 -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.
=========================================
TYPO talk
---------
- Anyone interested in coordinating the TYPO talk should reply to
the thread on the member list.
CSS Snapshot 2018
-----------------
- Members were asked to add to the github issue
(https://github.com/w3c/csswg-drafts/issues/2281 ) what items
should be in the 2018 Snapshot.
CSS Sizing
----------
- The group agreed with the spec text for handling placeholder text
as max(placeholder, value). (Issue #2141)
- RESOLVED: Have a UA defined minimum on content based sizes for
these new keywords with suggestions of possible
minimums. (Issue #2141)
- RESOLVED: Single line inputs have no breakpoints for purpose of
calculating min and max. (Issue #2141)
- dbaron and fremy will review the proposal in issue #1132 (
Percentage sizing section is kind of vague) next week before
it's re-raised for resolution.
- RESOLVED: Publish an updated WD of CSS Sizing 3
Typed OM
--------
- RESOLVED: Specify USVString for all new Houdini APIs.
Filter Effects
--------------
- The group agreed to make no change on FXTF Issue #178 (Why can't
opacity() filter function ever increase opacity?)
CSS Grid
--------
- RESOLVED: Have a minimum of 10k tracks in each direction as a
recommendation. (Issue #2261)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Feb/0019.html
Present:
Rachel Andrew
Tab Atkins
David Baron
Amelia Bellamy-Royds
Tantek Çelik
Dave Cramer
Alex Critchfield
Benjamin De Cock
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Brad Kemper
Vladimir Levantovsky
Chris Lilley
Peter Linss
Anton Prowse
Liam Quin
Melanie Richards
Florian Rivoal
Dirk Schulze
Geoffrey Sneddon
Alan Stearns
Regrets:
Michael Miller
Manuel Rego Casasnovas
Lea Verou
Greg Whitworth
Scribe: dael
astearns: Let's get started.
astearns: Does anyone have anything to add to the agenda?
astearns: There are agenda order changes in IRC.
TYPO talk
=========
Vlad: I mentioned everything in my email. I got some desired topics
from the organizers. It's a suggestion, not a requirement.
Theme of conference is variable fonts and responsive web so if
we introduced something from CSS on those subjects that would
be in line.
Vlad: My focus is to make sure we don't leave this to last minute so
we can present the group best possible.
myles: Is this recorded?
Vlad: Yes and mostly video recording too.
Vlad: You can see prior recordings by looking through the speaker
list.
Vlad: All talks are video so I believe CSS will be. It will not be
different.
myles: We should talk after the call.
Vlad: That's why I wanted to make sure we're ready and have time to
finalize the speaker list and items.
astearns: myles and Vlad will talk after call. There's a thread on
the member list and a wiki page someone started to talk
about font metrics issues. Good to add to the thread and
wiki.
Vlad: I think it was fantasai that brought the wiki up and this
would be the right audience for that discussion.
astearns: I think it would be good to have several speakers fill
that with short focused talks.
astearns: I'll ping fantasai about a talk for font metrics. It was
fantasai or dbaron bringing that up. It would be great as
a 10 minute talk.
Chris: I think it was dbaron.
astearns: Please contribute to the thread. I will start wrangling
people with Vlad to get things more set.
Vlad: Thanks.
CSS Snapshot 2018
=================
github: https://github.com/w3c/csswg-drafts/issues/2281
Chris: I listed a few things, florian added more. I'd like more
discussion. Editing work is small. I think we should be able
to do this quickly if we can agree on in and out.
astearns: Shall we have this as a reminder to look at the thread?
Chris: Sure.
astearns: There are suggestions in the thread. If people could add
their opinions perhaps we can resolve on a future call.
florian: Reminder to TabAtkins there is a bug in bikeshed or my
brain and indexes aren't gen properly. Please look at that.
TabAtkins: Cool.
astearns: Hopefully we can get that squared away.
<florian> TabAtkins: direct link to the indexes issue:
https://github.com/w3c/csswg-drafts/issues/1007
CSS Sizing
==========
Please add vertical auto-resize textarea field
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2141
TabAtkins: We've got a few details we weren't sure of. First: right
now we have it specified that the width of something with
a placeholder is the larger of the widths of the
placeholder or contained text. That way you won't get
size jiggle when you click inside.
TabAtkins: Have a comment from fremy it's the right thing to do but
hard to implement in Edge. Any other opinions or stick
with spec?
astearns: Seems like right thing to do to me.
astearns: Other opinions?
astearns: Want a resolution?
TabAtkins: Just a check.
TabAtkins: Next: We could that empty inputs...a 0 size is hard to
click into. There's probably some measure of min size
that should come from UA in width and height. We wrote UA
can enforce the size required to hold a single character
as a minimum size, even if it's empty.
TabAtkins: Sound fine? More specific? Remove text?
bradk: Suggest that could be in UA stylesheet.
TabAtkins: Maybe as a min width or min height. Possibly.
fantasai: fremy sent a comment why we shouldn't do it with min
height in UA stylesheet. Comment here:
https://github.com/w3c/csswg-drafts/issues/2141#issuecomment-365745317
fantasai: Authors might animate height from 0 and if we impose a min
now the animation would clamp at non-0 size. He's got a
form control with a height of less than the min we
recommend.
TabAtkins: And more generally there's no reason to impose a min size
on arbitrary form controls. But when they're being
content sized there's a reasonable minimum. I agree we
shouldn't use min width and height for this.
astearns: Sounds like discussion is landing with not having a
minimum content base size?
TabAtkins: No, we're explaining why not use min-width and height to
impose it. We still think you should impose it.
astearns: I'm wondering since at the moment if you don't specify a
height on one of these you'll get something with 0
height...is imposing min a breaking change?
TabAtkins: That's not what happens right now.
fantasai: Textarea takes its height from the rows.
TabAtkins: This isn't about auto size. This is when you activate
content based sizing which is a new feature.
fantasai: Using min-content keyword. It's a minimum on the used
value of this keyword.
fantasai: [missed]
astearns: We're going to add a minimum height to the behavior of
these new keyword values when there is no content to size
from.
TabAtkins: Height and width.
florian: Is this only inputs and text areas?
TabAtkins: Only these.
fantasai: Not about content editable things.
astearns: Shall we have a resolution on adding a minimum size to
these new keywords?
astearns: Does anyone what to discuss what the size should be?
florian: UA defined.
fantasai: Yes, it's UA defined but there is an example.
astearns: Is that really UA defined?
fantasai: The UA gets to choose what the minimum to be. Our
suggestion is the size for a single 0 width character
because that gets you straightforward behavior when you
focus the item.
astearns: Why do we want to let UA?
fantasai: It's a font control and they have a lot of UA defined
behavior. Some UA might decide if they want the form
control easier and it should be big enough to contain the
letter 'n' for example.
astearns: uuuuu....okay. I prefer spec something so you can get more
interop if there's no pushback.
TabAtkins: I support fantasai in that we should support UAs wanting
to be large enough to be a tap target, for example.
astearns: Can you put that suggestion is as the example? Like you're
free to make it larger, but not suggest 1px in either
direction is useful?
fantasai: It really depends on how they're implement form controls
in terms of UA defined items. There's a reason form
controls are UA defined and this is the category where too
precise definition locks us in. UA should look for best
user experience. If every platform is the same we can
standardize then.
TabAtkins: I don't disagree that we can put in tap target size as
another suggestion.
astearns: Proposal: Have UA minimum on content based sizes for these
new keywords with suggestions of possible minimums.
RESOLVED: Have a UA defined minimum on content based sizes for these
new keywords with suggestions of possible minimums.
TabAtkins: Next is min-content for <input type=text>. There's no
breakpoints there. But right now it's magic only. UA
style sheets don't clarify, they just strip lines and
render as a pre. We probably want additional magic
clarified. If it's intended to be a single line we'll
clarify that the min and max content are the same and the
full size of the stuff inside.
TabAtkins: This might be accomplish-able through a UA important rule.
fantasai: Alternate definition is to have min and max content mean
different things based on where there could be a
breakpoint.
TabAtkins: Doesn't sound useful can't get it to size to that. It
wouldn't do anything useful.
fantasai: Not sure what you mean. If you set input to be min-content
then it's the size of the longest word.
TabAtkins: That has no meaning if content isn't breaking. There
would still be scrolling because you'd have lots of
content on their size of the big word.
fantasai: There's no word that wouldn't fit.
astearns: I think I agree with TabAtkins. I don't see how it's
useful. It would have the weird effect of making input
larger as you add characters.
florian: And i18n problems on what's a word.
TabAtkins: Not in that case because breakpoints.
fantasai: We know where the breakpoints would be.
fantasai: Question is is there a reason for these things to be
different. We as spec writers don't have a reason. If
authors do we can make it different.
fantasai: If there's no compelling use case for different then they
shouldn't be different.
astearns: If we're not going to have min-content on an input be the
longest word are we saying min and max is same result?
TabAtkins: Single line inputs have no breakpoints for purpose of
calculating min and max.
astearns: I'd be fine with that.
<dbaron> +1 to what TabAtkins said
astearns: fantasai okay?
fantasai: Yeah. As long as there's no one with a reason to do
different.
astearns: Objections to resolving?
RESOLVED: Single line inputs have no breakpoints for purpose of
calculating min and max.
astearns: Last item looks to be a review of the new text. There's
quite a bit so a few eyes would be good.
astearns: One question is we want to republish sizing as updated CR.
This is a new feature, is there a reason this is L3 as
opposed to L4?
fantasai: Keywords are introduced in L3 so we need to define their
behavior in L3.
TabAtkins: We could undefine the keywords and move the definition to
L4.
fantasai: That's true.
fantasai: I don't think it's necessary at this point.
florian: Depends on if we prioritize rec faster.
[missed]
Chris: Is it WD or CR?
astearns: It is just a WD. My concern is moot.
gsnedders: There are no tests for sizing so it won't get rec very
fast unless people provide tests.
astearns: Okay. I was wrong on my concern. Anything else on this
issue?
TabAtkins: No.
Percentage sizing section is kind of vague
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1132
fantasai: There's...the last comment is a summary.
<astearns> https://github.com/w3c/csswg-drafts/issues/1132#issuecomment-363623845
fantasai: Proposed edits for the behavior is [reads]
[
If the box is non-replaced, then the value of any sizing property
specified on it as an expression containing a percentage is
treated for the purpose of calculating the box’s intrinsic size
contribution only as that property’s initial value. For example,
given a box with ''width: calc(20px + 50%)'', its max-content
contribution is calculated as if its 'width' were ''width/auto''.
The percentage is honored as usual, however, during the actual
sizing of the box itself.
]
fantasai: Seems to be interoperably implemented.
fantasai: If you have a mix width of calc(20px+50%) we consider it
as [missed] and once containing block resolves we resolve
the percentages. There's a WPT PR and we're asking for WG
review.
astearns: Has anyone reviewed the test PR?
fantasai: There's no spec text. Somebody needs to look at tests and
see if that's what people want to add to the spec. We need
a review of the tests.
dbaron: Proposal is matching the behavior of percentage widths?
fantasai: There may be cases I didn't test correctly.
dbaron: I think it does. But I think if it doesn't it ought to match.
astearns: dbaron could you review?
dbaron: Probably but maybe next week.
astearns: Is that enough for now fantasai?
fantasai: If anybody else wants to review I'd prefer they do it in
parallel with dbaron. This is the last open issue as far
as I'm aware at which point we'd like to republish and
issue LC.
fantasai: It's been on the agenda for 2 weeks. If someone needs to
review and they need time let's assign it to that person.
astearns: Any other engines have a volunteer? fremy can I ask you to
look?
fremy: I guess yes. It may not happen this week, but in theory yes.
astearns: Other volunteers?
fantasai: You can just defer to dbaron. But if you want more time I
need to know how much.
Publication
-----------
astearns: Since this is a WD we can publish what we have and leave
this open.
fantasai: Yes, but I'd like to get to a point where we can ask for
final review. But I am happy to publish a WD.
astearns: Opinions on an interim draft or wait for this to resolve?
astearns: It is a WD so fantasai I can leave it up to you. I'm happy
to call for resolution at any point.
fantasai: Now is fine. It's out of date.
astearns: Objections to publishing an updated WD of CSS Sizing?
RESOLVED: Publish an updated WD of CSS Sizing 3
Chris: That's an update WD so it can auto publish?
fantasai: Yes.
Chris: Thanks.
<fantasai> TabAtkins, can you publish?
Typed OM
========
Should we be using DOMString, USVString, or CSSOMString?
--------------------------------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/687
TabAtkins: Should things be specified as DOMString, USVString, or
CSSOMString. I need guidance. I got that URL should be
USVString, but for the rest I'm not sure what to do. Any
guidance appreciated.
plinss: In general I think we should be doing USVString and only
DOMString where we need it for backwards compat
TabAtkins: And we did CSSOMString to allow that but for engines that
are more efficient on DOM to do that.
plinss: That's why I'm thinking for new APIs let's do USVString and
not propagate more DOMStrings.
florian: Reason for CSSOMString was an implementation difficulty I
thought.
gsnedders: But elsewhere in platform spec have changed DOMString to
USVString. I'm not sure why we have CSSOMString at all
rather then we expect will change.
florian: CSSOMString is for should do USVString but do DOMString if
you have to
plinss: Reality is they will do the DOMString if they can't do
anything else so why give them permission to do it wrong if
they can do it right?
<gsnedders> what plinss said
astearns: Sound to me like general consensus is to use USVstring.
I'm not hearing anyone cheer for CSSOMString.
florian: Then we should move away from CSSOMString everywhere.
astearns: Fair but we can try it with this new API and any in the
future and see how much we can go back as we find out if
this one works.
astearns: Objections to spec USVString for this Houdini API? Is it
just this one or all?
TabAtkins: Might as well be all.
astearns: Objections to spec USVString for all new Houdini APIs?
RESOLVED: Specify USVString for all new Houdini APIs.
Filter Effects
==============
Why can't opacity() filter function ever increase opacity?
----------------------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/178
AmeliaBR: We have an opacity shorthand filter function. It takes any
integer >0 but any >1 is clamped to 1. So opacity filter
reduces but cannot increase opacity. So a number of
features like taking a blur or drop shadow and increasing
opacity of blurred areas is not possible.
AmeliaBR: We're getting late in the process for major changes. All
engines currently implement as specified. Problem is
because the way it's specified it won't be easy to add
this in later. If it was currently written that >1 is
invalid we could add it later without worrying about
breaking.
AmeliaBR: As far as an author prospective I found this to be an
arbitrary restriction so I wanted to change, but I
recognize it's late in the game.
krit: 2 comments. Spec was following implementation already, that
was already implemented. Point 2 that I think TabAtkins
mentioned if you have some areas with a 0 they will not get
opaque again. There might be issues there. Also some browsers
might have optimizations.
krit: Biggest issue is there might be content already that can
increase >1 and this code will result in 2 different results.
TabAtkins: I take back my objection. AmeliaBR pointed out that's
exactly what you do want.
AmeliaBR: It's consistent with behavior of other shorthands like
brightness.
smfr: There are other issues. 1 is that some browsers may rely on
platform graphics libraries that expect 0-1 value. Second is
with premultiplied alpha. Many engines will store in that and
you have very small rgb units and when you multiply that you
get this gray. I think that'll happen with >1 opacity.
krit: For some effects we require to go back to unmodified, yes.
Depending on how impl is done you get very different results.
smfr: You've got data loss with premultiplied alpha.
smfr: I also don't like because it gives us different behavior in
opacity. If we want this we should think about a different
filter - component transfer.
AmeliaBR: Yes, that one lets you modify each channel.
Chris: Agree. Exposing that is the best way forward.
AmeliaBR: That is something that could be added in the future
without web compat. Add a separate function in the future.
smfr: That would be fine.
TabAtkins: sgtm.
AmeliaBR: Sounds like a reasonable way forward. Hoping to get
filters stable so I'll accept.
astearns: So we'll close this issue no change and put in component
transfer as future work.
AmeliaBR: I'll open an issue on filters 2.
CSS Grid
========
"Clamping Overly Large Grids": Perhaps have a minimal required track
count
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2261
TabAtkins: Earlier in the draft we had a minimum required grid size
and it was fairly large. We removed that because it was
too much. Implementations can't actually support a
million cells by a million cells. Still good to have a
min. Firefox has 10,000 in positive and negative
direction. Seems reasonable. Does the WG like that
number? Different number? Don't like having a min?
fantasai: Min should be the lowest possible number that we think is
reasonable to consider. This should be that the author can
count on there being at least this many tracks.
fremy: Can we verify what browsers accept?
fantasai: Report from implementors. Gecko is 10k. Chrome is 9,999.
fantasai: If Edge is lower we can go with that. We don't prefer the
number, just that it's there. And it's a should.
astearns: fremy do you know if Edge has a limit?
fremy: I don't know but we should be fine with 10k in each direction.
astearns: Anyone not okay with the idea of a minimum?
astearns: Proposal: have a minimum of 10k tracks in each direction
as a recommendation. Obj?
RESOLVED: Have a minimum of 10k tracks in each direction as a
recommendation.
astearns: That gets us close to the end and I'm not seeing a 1
minute issue. I think we'll call it a couple minutes
early. Thanks everyone and we'll talk next week.
Received on Thursday, 22 February 2018 00:16:08 UTC