- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 5 Apr 2017 19:13:10 -0400
- 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.
=========================================
Telecon for Transforms & fill-stroke
------------------------------------
- The inaugural call between the CSSWG and those interested in SVG
will be 6 April at 9pm UTC.
REC Steps
---------
- Fonts 3: Myles was actioned to make the changes to the test
font requested by ChrisL and Rossen.
- Cascade: The edits to drop scoped styles were made.
- Values & Units: smfr was actioned to review the <position>
edits.
- RESOLVED: Update motion draft on TR
2017 Paris f2f dates - can we decide exactly?
---------------------------------------------
- RESOLVED: Meeting Houdini Aug 1, CSS Aug 2-4 in Paris
Move underimplemented features to Images 4
------------------------------------------
- RESOLVED: Move everything with no impl to next level and mark
everything with 1 impl as at risk.
Grammar of grid-row-start and friends is ugly and harms value space
for line names
-------------------------------------------------------------------
- Everyone agreed that limiting the name space was bad and should
be avoided in the future. Unfortunately, it is too late to fix
this issue.
- RESOLVED: No change on issue 1137
(https://github.com/w3c/csswg-drafts/issues/1137)
Definition of `column-span` should say what happens without an
ancestor multicol
---------------------------------------------------------------------
- RESOLVED: Have column-span elements create a bfc even if not in
a multi-col container.
- Florian will clarify the spec in the form of a note.
New feature - scroll-boundary-behavior (an extension of
-ms-scroll-chaining)
--------------------------------------------------------
- RESOLVED: Create a WICG repo for this new feature and work there
for now.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Apr/0014.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Tantek Çelik
Dave Cramer
Benjamin De Cock
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Dael Jackson
Brad Kemper
Peter Linss
Thierry Michel
Michael Miller
Simon Pieters
Anton Prowse
Melanie Richards
Florian Rivoal
Geoffrey Sneddon
Alan Stearns
Lea Verou
Greg Whitworth
Steve Zilles
Regrets:
Rachel Andrew
Scribe: dael
Telecon for Transforms & fill-stroke
------------------------------------
astearns: Let's start. Any extra items?
fantasai: Yes.
fantasai: There was a suggestion to have a separate SVG call for
transforms & fill-stroke. I sent an email about that
yesterday.
fantasai: Current proposed time slot is tomorrow during SVG time
slot. That depends on who is interested in making it.
I'd be interested to take a quick IRC survey.
dbaron: What time is that in clock time?
fantasai: Let me grab the link
<fantasai> https://www.timeanddate.com/worldclock/fixedtime.html?month=04&day=06&year=2017&hour=21&min=00&sec=0&p1=0
fantasai: 9pm UTC, 5pm East US, 11pm Paris, 7am Sydney, 6am Tokyo
astearns: So could people interested in meeting at that time
tomorrow put in IRC if they can make it?
fantasai: Topic for tomorrow is transforms.
fantasai: I want to know if you care about transforms,
fill-stroke, or both. And then I want to know if you can
make it.
<dbaron> I'm somewhat interested in transforms, but can't make
that time tomorrow
fantasai: If you're interested in one of those, please type T, F,
or Both in IRC.
<Rossen> T
<dbaron> T
<TabAtkins> Both
<ChrisL> both
<gregwhitworth> T
<smfr> Both
<fantasai> T if you're interested in Transforms, F, if you're
interested in Fill-Stroke, Y if you can make it N if
you can't make it tomorrow
astearns: Please now type if you can make it tomorrow.
<Rossen> interested<T> Sure();
<bradk> Interested, but can't make it
<ChrisL> Both Y
<TabAtkins> Y
<smfr> Y
<dbaron> N
<tantek> cannot make it to the telcon
<tantek> N
<gregwhitworth> N
astearns: I expect some of these issues should be on the F2F
agenda.
astearns: So we'll also have F2F discussion and we can meet after
the F2F.
fantasai: dbaron and gregwhitworth would a different week work?
dbaron: For me a different week would work...but let me think
between now and f2f.
fantasai: smfr is out next week.
<gregwhitworth> I'm just pretty booked at the moment, I can make
tomorrow work if necessary.
dbaron: For time tomorrow I'm on plane to Asia and will be there
through the F2F.
Rossen: Can we keep it tomorrow? Go with the time. A number of
people can join. If we have pending decisions for FF and
there's no rep we can make those resolutions pending
review. But it would be good to get on the phone and make
progress.
<gregwhitworth> that sounds fine
<fantasai> birtles, Can you make it tomorrow?
Rossen: dbaron is that okay with you? And whoever else can't make
it?
dbaron: That's okay.
fantasai: I'll take minutes.
Rossen: Thanks for organizing fantasai.
astearns: This will be the inaugural and we'll continue these to
get transforms done.
REC steps
---------
astearns: That's was the item for transforms. There's a bit on
fonts 3 and Rossen was to investigate a font issue in
Edge?
Rossen: I did look yesterday. The font that was prepared wasn't
prepared in a way that works with dwrite.
Rossen: I did send a message to those on the original email.
Rossen: Summary was if you're asking for zero horizontal progress
we'll make 0.
ChrisL: Well, the CSS font has it's own duplicate set of metrics.
Some browsers will respect that and some won't.
Rossen: It depends on if you're calling back on dwrite or not.
Rossen: But I believe what's in the email was actionable.
ChrisL: Yes. I can patch the font to do that. myles could do it
better.
Rossen: Okay.
smfr: I think myles is out this week.
ACTION myles to respond to the dwrite issue and ChrisL's asks for
font edits.
<trackbot> Created ACTION-838
astearns: Cascade. There's an item to drop scoped styles. Did that
edit get made fantasai?
fantasai: I think TabAtkins and I did that two weeks ago, yes.
astearns: V&U
astearns: It has <position> edits.
<astearns> https://lists.w3.org/Archives/Public/www-style/2017Mar/0054.html
fantasai: They're done. We're waiting on review by somebody.
astearns: Is there a person you'd like to action to review?
fantasai: I have no idea. Does anyone care? Maybe smfr since he
has to integrate into transforms?
smfr: I missed that.
fantasai: We made edits to <position> for transform-origin.
smfr: Sure, I can do that.
ACTION smfr look at <position> edits
<trackbot> Created ACTION-839
fantasai: Are there plans to update motion draft on CR?
<tantek> +1 fantasai update it please
astearns: Good question.
TabAtkins: Yeah, sure. It wasn't on my immediate to do list, but
it should be done.
ACTION TabAtkins update motion draft
<trackbot> Created ACTION-840
fantasai: We'll need to update backgrounds & borders once the
<position> edits are published and that will need a
resolution.
astearns: Right. There was another item on backgrounds & borders
about fixing test. That was on tmichel.
tmichel: I haven't made progress. I have to investigate how to
change those tests.
astearns: That's fair.
astearns: Last thing is changes to tests for UI. They were
reviewed and Florian was going to update the tests.
Florian: I'm waiting for a review from fantasai on an update I did.
astearns: So, fantasai, will you have time soon to look?
fantasai: Probably not, but I can try.
Florian: Should be quick since I think I did everything you asked
for.
fantasai: I think there was one that was a long thing.
Florian: Is gsnedders on?
gsnedders: Yes.
Florian: I think there's one PR that has been migrated, but one
hasn't. What's the status there?
gsnedders: There's three left on the old repo that have comments
which are hard to move over. So yeah, I should be able
to do that soon.
Florian: Yeah, one PR is in the new, one will go soon.
gsnedders: Yes, there's 3 still on the old platform total.
astearns: And fantasai mentions we need a resolution to publish
motion. This is just an update, it's not in CR?
fantasai: Correct. This is merging in round display and other
changes.
ChrisL: It's an auto publish?
fantasai: The old one was on the old system but yes.
astearns: Objections to updating Motion draft?
RESOLVED: Update motion draft on TR
2017 Paris f2f dates - can we decide exactly?
---------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/1165
astearns: I thought dates were exact, Aug 1-4 where one is a
Houdini.
tantek: Which one?
astearns: We usually do Houdini first. Aug 1 houdini, 2-4 is CSS.
tantek: Can we get a resolution on the record?
* fantasai couldn't find it either
astearns: I think we were waiting on confirmation from Mozilla
they can host.
tantek: We can confirm we have the space.
Rossen: We don't tend to have formal resolutions on F2F days.
fantasai: We do usually.
Rossen: I don't recall, but sure.
gsnedders: There were two lines in the minutes on the F2F.
astearns: Yeah, the discussion was longer than the minutes.
<fantasai> It appears there was no minute-taker for that discussion
astearns: Obj to resolving to meeting Aug 1-4 in Paris?
<fantasai> rossen, resolution on dates =
https://lists.w3.org/Archives/Public/www-style/2017Mar/0021.html
RESOLVED: Meeting Houdini Aug 1, CSS Aug 2-4 in Paris
tantek: astearns can you make the page?
astearns: I will set up a page stub for you to fill in details.
I'll copy what I can.
tantek: dbaron myself and Jet will work on that.
Move underimplemented features to Images 4
------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/1148
leaverou: I was looking at the last CR. There are many features
that have wide impl, but there are some that are none
or 1.
leaverou: First is image(). Unless someone plans to implement I
would suggest deferring.
TabAtkins: I agree.
leaverou: Another feature without impl is image-resolution. Is
anyone planning on impl?
TabAtkins: I thought we had an impl of that. I could be wrong.
<leaverou> http://dabblet.com/gist/33ac15e3d6372b2d97b17061783eb40f
leaverou: Since we don't have tests I had to make a quick one.
This is what I used ^
<smfr> webkit does not have image-resolution
<dbaron> Gecko does not have image-resolution
leaverou: It just tests parsing so if the browser doesn't
recognize I assume it's not impl.
TabAtkins: Ah, I was thinking image-rendering.
Florian: image-resolution has partial implementation in
Viviostyle. I'm not sure we fully comply.
TabAtkins: That's still compatible with going to level 4.
leaverou: Do we agree with deferring? Yeah.
leaverou: Image-orientation is only Gecko.
leaverou: Any plans to impl?
<tantek> there's web author demand for image-orientation
<tantek> especially in the IndieWeb community
TabAtkins: I could have sworn safari had something.
smfr: On iOS we respect it and on mac we don't and this is
terrible. We need to pick one. If we had this the author
could force, but we don't have an impl yet.
TabAtkins: We also have an issue that we want to kill everything
except from image and initial because the rest aren't
really CSS appropriate.
<zcorpan> https://bugs.chromium.org/p/chromium/issues/detail?id=158753
fantasai: The other values were added for printer impl. That's why
it's in a spec.
ChrisL: If you only have those two values it's a true/false with
lengths.
TabAtkins: Nothing wrong with a property only having two
reasonable values.
ChrisL: It does mean if you want 270deg rotate you have to edit
the image.
TabAtkins: Or you use a transform.
Florian: Or a writing mode
<zcorpan> writing-mode doesn't affect images?
<fantasai> writing-mode doesn't affect images
ChrisL: Yeah, okay.
astearns: Given there's only on impl and there's question on
values it seems it could move.
leaverou: I agree.
<leaverou> http://dabblet.com/gist/d2c5b3d1beba1dd514f505ab8e3ad219
leaverou: There's gradient interpolation. I did a test ^
leaverou: None of the UAs seem to support. I heard Edge 15 might
have, but I don't have one here to test.
<MaRakow> yes, edge supports gradient interpolation for some time
now
fantasai: Back to image-orientation I'd prefer to keep it in. It's
referenced from other specs. If it keeps us from PR we
can drop at that point.
TabAtkins: Mark as at risk
<ChrisL> mark it as at-risk, then
TabAtkins: And MaRakow says Edge does support [gradient
interpolation].
leaverou: We have 1.
Florian: It's a good feature, but depends on how fast people will
get to it.
fantasai: I think we need to clean up what's clearly not going to
get impl. We can mark the others as at-risk.
leaverou: It's been there over 5 years though.
TabAtkins: Let's punt the things with 0, things with 1 get an
at-risk.
<tantek> +1 tabatkins. drop 0 impls feats. at risk 1 impl feats.
leaverou: I think we can get a resolution. The rest have 2
depending on if you consider blink and webkit different.
TabAtkins: In this case I think those are pre-fork..
astearns: So they're at risk.
<fantasai> either way, using just those two as implementations is
questionable, because they share architecture and code
astearns: Move everything with no impl to next level and mark
everything with 1 impl as at risk.
<glazou> +1 to what astearns said
leaverou: Yes, and can we then resolve on an updated CR?
Florian: You need a DoC.
ChrisL: Could we only resolve once the supporting documents are
done?
fantasai: Yes, I agree with that.
astearns: Objections to the resolution on edits?
astearns: proposal: Move everything with no impl to next level and
mark everything with 1 impl as at risk.
tantek: Can we ask for that to be in a changes section?
TabAtkins: Of course.
fantasai: Changes and DoC haven't been compiled.
RESOLVED: Move everything with no impl to next level and mark
everything with 1 impl as at risk.
astearns: We'll make the edits and then update the draft once it's
all in place.
astearns: Anything more on images 3?
leaverou: Nope.
Grammar of grid-row-start and friends is ugly and harms value space
for line names
-------------------------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/1137
glazou: I made that comment because I found the issue when I
started impl the properties. I understand this is too
late, but I wanted to highlight it. We narrowed the value
space for no reason.
glazou: It's something we should not do again and it's unfortunate
that I couldn't see it before.
TabAtkins: I agree in general that having custom idents live in an
overlapping value space with specified idents is often
clumsy. I thought it was reasonable at the time, it's
probably too bad we cut out values. I agree in the
future we should minimize situations where this happens.
glazou: It's not minimizing. I really think we should get rid of
this kind of issue. If we keep this kind of thing we're
only thinking about engines. Editors will have to provide
UI mechanism to disable for these values. It's bad design.
We're responsible for the whole system. We should not do
it again.
TabAtkins: Yeah, sure.
<fremy> +1
TabAtkins: I won't say we'll never do it again because we may have
to deal with it for compat, but I want to avoid it.
astearns: And we're talking about combining keywords and custom
idents.
glazou: Yeah.
astearns: I'll put it on our list of css mistakes page.
astearns: Just to be clear, you're okay closing no change glazou?
glazou: Yeah.
astearns: Since this is on CR we need a resolution. Objections?
RESOLVED: No change on issue 1137
Definition of `column-span` should say what happens without an
ancestor multicol
---------------------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/1074
Florian: If I remember we reached where if column-span should do
anything not in the multi-col. Both sides were hanging in
terms of author friendliness.
Florian: One set of people said if you're not in multi-col you
don't expect it to do anything so it shouldn't. The other
side is that the content of the multi-col is usually
styled the same as other block layout and if you do
remove the multi-col you're likely to forget to remove it
and you'd want the rest of the style to stay.
Florian: So are we looking for predictable and consistent model or
one that does things the way you want if you forget to
remove something.
Rossen: To confirm you're calling predictable and consistent where
when you have remaining values in a layout system that no
longer matches, that's what you mean?
Florian: If you're not in a multi-col, multi-col properties don't
apply.
Rossen: I'm in favor of that one.
<bdc> FWIW as an author, the typical thing I'd do is to use
multicol for wide viewports and just kill it in a media
query for mobile/etc.
<bdc> would be very unexpected/annoying to revert multiple props
TabAtkins: We took as a general principle that a one col or one
row grid should act the same as a flexbox, basically.
Similarly a single column multi-col is basically
identical to a flow-root container so having the
differences minimize would be good. So having this
property that has the sole effect of making a child a
block container is fine with me.
Florian: You disagree with Rossen?
TabAtkins: Yes. Let's make col-span continue being a block
container.
Florian: Interesting thing is you're both arguing against what
your browsers are doing.
Florian: Edge does what TabAtkins wants and Chrome does what
Rossen wants.
astearns: Chrome is the odd one out?
<Rossen> https://jsfiddle.net/Ld86cuwk/
<Florian> https://github.com/w3c/csswg-drafts/issues/1074#issuecomment-289172502
Florian: Safari and Edge create a bfc.
Rossen: Is that the right link?
Florian: Yeah.
fantasai: I'd like to point out the irc comment from bdc [reads]
Rossen: What we're currently doing seems like a bug, even though
it matches what you're saying. That's an easy bug to fix.
astearns: But if you fix it and it breaks the author
expectations...
Rossen: Can we rename this property to please make me a bfc?
Because this will go into css tricks as the main way to
make a bfc.
<dbaron> We did add display:flow-root!
Florian: You can use flow-root for that.
astearns: This behavior has worked this way in several browsers
for years and that hasn't happened.
Florian: And I think the MQ argument strengthens the argument.
Switching multi-col on or off is a very reasonable use
case. Having a single thing to switch is much more author
friendly.
Florian: I was neutral but am starting to join TabAtkins and
fantasai.
<bradk> So to make a flow root, { column-count:1; } on parent and
{ column-span: all } on child.
astearns: Another thing to note is we have a browser with a
different behavior that is willing the change.
Florian: I think currently the spec isn't very explicit. But it
does correspond to making a bfc if you read it carefully.
Rossen: I don't formally object, but I'm not going to agree.
astearns: Would anyone else object to having column-span elements
create a bfc even if not in a multi-col container?
RESOLVED: Have column-span elements create a bfc even if not in a
multi-col container.
Florian: The spec needs to be clear that this is intentional, so
I'll add a note.
New feature - scroll-boundary-behavior (an extension of
-ms-scroll-chaining)
--------------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/769
fantasai: This was requested by someone...
TabAtkins: Majid, he's one of our implementors.
fantasai: And someone from Facebook.
TabAtkins: Microsoft has a feature already where you can dictate
what happens when you're scrolling inside a scroller
and you hit the end. Do you capture or do you move the
rest of the scroll action upwards in the page.
<tantek> what about the scroll-bounce?
TabAtkins: They have an explicit control. It's ms prefix. We'd
like to standardize this idea, we like it. THere's a
lot of discussion of what to capture and how to do so.
That's cool. Basic ask is does the WG feel this is
worth doing a spec? Should we do this in WICG?
fantasai: I think it's already in WICG. Question is do we add it
to a draft and which?
fantasai: There's a lot of question so we're in a place where we
want to be able to have individual issues on each
question.
TabAtkins: Yeah. Do we believe this is mature enough to bring into
the group or leave in WICG and make sure it has a repo
there.
Rossen: I didn't read the whole WICG topic, but I remember there
being breakouts on this. I would be in favor of moving it
in, especially if there's interest from others.
Rossen: Maybe Overflow? Something along those lines.
fantasai: Makes sense to me.
TabAtkins: Or we can support it getting a WICG repo. Then when we
do get agreement there we can pull into overflow.
fantasai: Open discussion on syntax has not stopped us from
putting things into a draft before. If there wasn't
feature clarity I would say more discussion, but this
seems as well defined as a lot of stuff in drafts
already.
astearns: I'm interested to experiment with WICG process. I'd be
interested to have an official repo and go through that
process.
astearns: So why don't we try the official WICG incubation process
and move it in once it's in a good state?
Florian: One problem is define a good state
TabAtkins: There's success criteria in WICG. They've worked for
webapps. If there are issues we will be in there and we
can provide feedback on how to improve for csswg. It
seems valuable to experiment and this seems like a good
thing to do it with.
Rossen: There has been quite a bit of discussion on this and on
our side the people most involved on initial
implementation have had discussion with Majid. Most
technical discussion is closed. If we're only talking
syntax I think we're ready to move.
Rossen: Although, as I said, if others want to continue in WICG
and you believe you have strong technical additions or
objections to what is done so far I'm fine continuing
there.
ChrisL: I'm hearing 3 or so viewpoints. I heard astearns say he
wants to experiment with WICG. I hear Rossen say it's
mature enough and let's move now. I hear TabAtkins say
that there is a process to move and we haven't made that.
Is that correct?
TabAtkins: I'm in astearns' camp.
astearns: I think that is true, though, that there is a process
that says you set up a repo and work there until it's
ready for standards. If this is mature enough it can
skip repo, maybe that's feedback for WICG when working
with us.
Florian: The point where a spec is ready to graduate if we work
together cannot be dictated from one side. They can say
we're only comfortable working until as late as something
and we can say we won't work until a point. But we need
to agree on a certain point in between.
TabAtkins: We don't have to send signals, we're the ones that lead
the WICG CSS forums.
Florian: It's overlapping with us, but it's not us.
TabAtkins: I don't want to get into a WICG discussion with one
minute left.
astearns: I'd like to continue experimenting with WICG, get a
repo, and see if that was a useless step so we can
figure out what to do in the future given this
experiment.
astearns: Are there objections to creating a WICG repo for this
near feature and working there for now.
<ChrisL> no objection
<leaverou> no objection
<dbaron> needs to leave for another meeting, and is fine with
experimenting with this in WICG for a bit
Florian: I'm not super enthusiastic about the whole thing, but if
we're going to experiment this is a good thing to do it
on.
RESOLVED: Create a WICG repo for this new feature and work there
for now.
Rossen: We're less that 2 weeks from F2F and there's nothing on
the agenda. Please add topics.
astearns: Yes, please do. Thanks everyone for calling in.
<fantasai> astearns, so do we close the issue in our repo and ask
ppl to re-open when they're ready to move over or what?
<astearns> fantasai: I think we leave the issue open, and add a
link to the WICG repo
<astearns> once everything in that issue is addressed, or added to
WICG issues, we can close it
<fantasai> doesn't like having untagged issues in the repo, they
tend to get lost
<fantasai> can we assign it to a module at least?
<astearns> it's tagged with overflow and cssom-view now
<fantasai> ok
Received on Wednesday, 5 April 2017 23:14:17 UTC