- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 11 Oct 2017 19:27:41 -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.
=========================================
Reconsider the meaning of 1fr
-----------------------------
- RESOLVED: Close issue #1777 no change
- fantasai will create a separate issue to investigate her proposal
to reduce the confusion that lead to this issue (Her initial
proposal is in this comment:
https://github.com/w3c/csswg-drafts/issues/1777#issuecomment-332683990
)
Clarify definition of widow and orphans
---------------------------------------
- RESOLVED: We want the interpretation to be the first option in
issue 1832
Invalid @counter-style should just not define a counter style, not be
ignored
---------------------------------------------------------------------
- RESOLVED: Treat invalid counter-styles the way we treat invalid
font faces.
What to do with Shepherd test issues?
-------------------------------------
- RESOLVED: Leave shepherd issues in shepherd, make it possible to
mark them closed, file issues per test suite in WPT
pointing at that test suite's issues in shepherd.
Sign up for Houdini at TPAC
---------------------------
- Working group members were reminded to put their name on the wiki
if they plan on attending the Houdini meeting on the Thursday of
TPAC https://github.com/w3c/css-houdini-drafts/wiki/TPAC-F2F-November-2017
Obsoleting CSS1
---------------
- The group will wait for the 'superseded' status that's a part of
the 2018 plan.
Q length unit capitalization
----------------------------
- RESOLVED: Use Q (upper case) in spec but add a note that it's
serialized as lower case.
===== FULL MINUTES BELOW =======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Oct/0022.html
Present:
Tab Atkins
David Baron
Bert Bos
Dave Cramer
Alex Critchfield
Benjamin De Cock
Elika Etemad
Tony Graham
Dael Jackson
Brad Kemper
Chris Lilley
Peter Linss
Thierry Michel
Michael Miller
Theresa O'Connor
Manuel Rego
Melanie Richards
Florian Rivoal
Jen Simmons
Alan Stearns
Sergio Villar Senin
Regrets:
Rachel Andrew
Robert Flack
Vlad Levantovsky
Lea Verou
Greg Whitworth
Scribe: dael
astearns: It's time to start though we're light on numbers. Thanks
for calling.
astearns: Anything extra to add to the agenda? I got Bert's on
obsoleting CSS1.
Spec Rec Next Steps
-------------------
astearns: I want to talk about testing this week.
astearns: We just republished CR of Backgrounds & Borders and it was
missing some tests. That goes against our recent
resolution to require tests, though the resolution to
publish Backgrounds & Borders happened before the
resolution so it was grandfathered. But we need someone to
look through Backgrounds & Borders for tests.
tmichel: I'm on it. The spec isn't published in CR, I'm waiting on
edits from fantasai, but the request was accepted.
astearns: Thanks for signing up. I'll get that added.
astearns: There are other specs that need tests. If you look at the
'needs test case' label in github there are many. I'll
take care of values. Is anyone looking at writing modes?
fantasai: Values test is more about we need information.
astearns: I understand, but there are two issues that got edits in
the draft that need test cases.
florian: I am not signing up for all writing modes, but I have for a
section of them. The one we discussed recently about height
of scrollers I will do.
astearns: I see the orthogonal flow and it is tagged. I've assigned
it to you.
astearns: I do see at least 1 flexbox issue. Can I get a volunteer?
fremy: gregwhitworth was looking into it as far as I know. I think
it's fair to assign to him.
astearns: Okay, I've assigned it since you volunteered him.
astearns: That's what I have for tests.
astearns: To set expectations I don't plan on publishing any more
CRs until their test suites are up to date.
<tantek> +1
astearns: Any other updates for spec progress?
<florian> https://github.com/w3c/csswg-drafts/issues/1598
florian: CSS UI. Last week I mentioned there's one issue left for
not passing tests. fremy thinks it's maybe the spec
instead, so please look at this bug ^
florian: We can add it to agenda next week, but it would be good to
look ahead.
fremy: Feedback on that: we resolved the spec was right, but when we
resolved I based it on the info in the issue which wasn't
completely accurate. What I think spec should say was what's
in the issue from dbaron not what's in the spec. I think it
would be nice to look next week.
florian: Spec text is older then issue. Issue was should we change
and we said no, but issue discussion wasn't entirely
accurate.
astearns: Thanks. Anything else for rec progress?
Chris: I noticed font-stretch didn't have tests so I wrote 18 tests
for that.
astearns: Great, thank you.
astearns: Anything else on rec progress?
Reconsider the meaning of 1fr
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/1777#issuecomment-332683990
astearns: There's a proposal TabAtkins summarized that was from
fantasai apparently...?
fantasai: That's a related issue. There's a problem which is
unintuitive and flexbox has same problem. It's interaction
of implied min size and overflow auto or scroll. What
prompted this bug was running into that combo.
fantasai: Having discussed with jensimmons it seems we don't want to
change meaning of 1fr. I propose we close the 1fr issue no
change and maybe discuss ways to make the behavior of
overflow auto or scroll more intuitive.
fantasai: It's a completely separate framing of problem. I'd suggest
first close reconsidering meaning of fr.
astearns: Is there a separate issue on overflow interp?
fantasai: We'd need to open. We could change/re-title issue, but I'd
like a resolution to not change 1fr.
astearns: Manuel or Sergio have you had a chance to look?
rego: I think that's fine. I didn't check this comment, but I think
it's fine if we don't change. We raised it because people were
confused, but probably not a good idea to change.
astearns: You're fine closing no change?
rego: Yes.
astearns: Other opinions?
jensimmons: I dropped a link at the bottom where Dave Rupert wrote a
good blog post explaining the frustrations. I don't
think changing 1fr is a good way to go. I sat and
thought about this and the way 1fr works now is really
good. I do think we should see what else we can do to
help authors out besides education.
jensimmons: Do something around overflow or add something else to
grid to solve this, but I don't think changing 1fr or
changing behavior between rows and columns is good. Keep
it the same, keep it symmetrical, see what else we can
do for authors.
astearns: Is what fantasai spoke about with overflow does that
address Dave's frustrations?
jensimmons: I don't think he has the best solution, but he's talking
about exactly those problems. He has one way to solve it
and there are other ways to solve it that we list in the
issue like minmax(0px, 1fr) would work. Authors don't
know that because they don't understand what's a
replaced element, but we can teach them that.
astearns: I'm hearing consensus to close no change and then continue
discussion on how to explain how overflow works with grid.
Objections?
RESOLVED: Close issue #1777 no change
fantasai: We'll open a new issue starting with the blog post.
astearns: Is that you fantasai or jensimmons?
fantasai: I can do it.
jensimmons: I'm happy to comment, but fantasai will do a better job
explaining.
Percentages and intrinsic size (decide on indefinitely-sized
containers)
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333236096
astearns: Sounds like we have everything resolved except dealing
with indefinitely sized containers.
astearns: I have not run through the presented options.
fantasai: I haven't either.
fantasai: I can describe, but rego made a lot of comments I haven't
reviewed.
astearns: rego is here anything you can summarize or should we move
this to next week?
rego: I was commenting because some may not be possible, but
realized the previous resolution...the issue was about
percents in gutters or gaps. We resolved for percent tracks
something that changes all impl and I'm not sure we really
want to do that. Probably better to discuss more on github
first and come back
astearns: Sounds good to me. Anyone else have a comment now?
rego: Would be good for other impl to look through the last comments.
astearns: Definitely. Rossen is out this week but might have time
next week. Anyone know what Mats is up to? [silence] Let's
table for now and come back once this has been discussed
more on github.
* tantek reviews 509 discussion
Clarify definition of widow and orphans
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1823
florian: I realized there was ambig. in the definition. [reads from
spec:
The orphans [resp. widow] property specifies the minimum
number of line boxes in a block container that must be
left in a fragment before [resp. after] a fragmentation
break.
[...]
If a block contains fewer lines than the value of widows or
orphans, the rule simply becomes that all lines in the
block must be kept together.
]
florian: The reason I think this is ambiguous is that line boxes in
a block container isn't clear if they must be direct
children or indirect descendants. I don't think it intends
indirect. If it did if you had a div with two paragraphs
with widows and you'd end up gluing them together.
florian: I think we clarify that we only mean direct children.
TabAtkins: The usual intent is to set on a page box, correct?
fantasai: No, this is about paragraphs, not page boxes.
fantasai: The definition is about block containers with line boxes.
You must have a min number of line boxes in each fragment.
I thought that was clear, but if it's not we can clarify.
This is only line boxes. And property inherits. If there's
a block in your block that's a child to which widows can
also apply. But you can break at the boundary.
fantasai: You can always say break after at a block. Usually that's
not an issue because a block inside a block is separate
content.
astearns: Intent is closer to #1 in the example.
dauwhe: #2 in the example would be bad.
dauwhe: Absolutely #1.
florian: I think there are rare cases where you might want #2 but
you should control that separately.
astearns: If there is a case where you want #2 you would structure
html differently.
florian: Probably.
dauwhe: Or the thing you're trying to fix would not be a widow.
florian: I think we can address the rarity of #2 another time if we
can resolve on meaning #1. An editor can change or I send
a PR.
astearns: I'm not certain an edit is required but that may be
because I'm interpreting the language in a particular way.
Bert: If florian finds it's unclear it probably is. I didn't imagine
it in another way, but if florian reads it another way it
needs clarification.
astearns: florian, you'll do a PR to fix the wording?
florian: Yes.
astearns: Okay, we'll then look at wording and decide to take the
change.
florian: Or resolve on intent.
astearns: Resolve that we want the interpretation to be the first
one in your comment and then you write the pull.
Objections?
TabAtkins: Nope.
RESOLVED: We want the interpretation to be the first option in issue
#1832
Invalid @counter-style should just not define a counter style, not be
ignored
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1682
TabAtkins: The problem is what precisely do we do with counter-style
rules that are invalid due to either not having or
missing required descriptors. Is it invalid or does it
not define one?
TabAtkins: Font face has some required descriptors and if you're
missing them it just fails to instantiate a font face. I
propose to mirror font face so they stay in the OM.
florian: Any compat requirements?
TabAtkins: No. FF is only impl and xidorn is okay either way.
dbaron: Sounds good to me.
astearns: Objections to treating invalid counter-styles the way we
treat invalid font faces?
RESOLVED: Treat invalid counter-styles the way we treat invalid font
faces.
What to do with Shepherd test issues?
-------------------------------------
github: https://github.com/w3c/web-platform-tests/issues/5485#issuecomment-335326728
astearns: We had planned to move all shepherd issues to GH but some
people expressed skepticism it will be useful. Proposal is
to keep issues in shepherd so people can work as required
as we have time, but it's fine to store in shepherd
instead of moving them to git.
florian: I support that. Signal to noise ratio is really low.
Hopefully as we get more integrated into CI tests will be
done in a meaningful way and tests will be fixed up as we
go. Elsewise we'll have lots of work for hundreds or bad
tests.
<Chris> agree, best to clear them off as time permits. Probably
duplicates in GH for some of them. And some should have been
closed years ago.
fantasai: Additional consideration is system status is kind broken.
There was auto flipping based on commit and those were
incorrect. So any automated copying would be problematic
<Chris> +1 fantasai that the auto-flipping was problematic
dbaron: Do we discourage new issues in shepherd?
plinss: It's been read only for a while.
florian: Full read only?
plinss: I think so. I can tweak to close only if that's what we want.
florian: If anybody wants to triage I don't think it should be
prevented.
fantasai: Reasonable, yes.
fantasai: We might want a meta issue in the github saying there are
a whole bunch of things filed and point people there.
astearns: Maybe on a suite by suite basis?
fantasai: That's brilliant. Yes.
astearns: As people take on the work and someone plans on going
through shepherd they can track their own work. git issues
where no one is doing something isn't really useful
astearns: Sounds like there's consensus to leave shepherd issues in
shepherd. I like making sheperd issues able to be closed
as people go through. Obj?
RESOLVED: Leave shepherd issues in shepherd, make it possible to
mark them closed, file issues per test suite in WPT
pointing at that test suite's issues in shepherd.
Sign up for Houdini at TPAC
---------------------------
<astearns> https://github.com/w3c/css-houdini-drafts/wiki/TPAC-F2F-November-2017
astearns: There's a section in github for people planning to attend
on Thursday, please add your name.
<Chris> I have two other conflicts Thursday, unfortunately
astearns: There may be some ad hoc earlier discussion for people
leaving earlier.
tantek: I think there's AC meeting Thursday afternoon too. Are we
all day or just morning?
astearns: In the past we haven't secured a room, we just grabbed
tables and had a work session all day. Discussions aren't
terribly formal. I doubt we'll get a room this year.
tantek: Community group rooms are still being allocated so I expect
we might be able to get a room.
Chris: Community groups are in 2 hour blocks, though. It's worth
trying, but don't assume it'll work.
tantek: Preference for morning if there is a conflict.
astearns: Can you add that to the wiki?
tantek: Will do.
<tantek> re: Houdini at TPAC - would prefer remote participation
possibility, at least by phone. we have a dev working on it
in New Zealand (who won't be at TPAC in person)
Obsoleting CSS1
---------------
astearns: There is a new process and it's low effort so he suggested
we do that for CSS1
fantasai: In favor
dbaron: One comment is there was some controversy for doing this for
html things that were superseded and I believe next year
process adds the superseded state.
florian: Obsoleted may be better for something like speech.
dbaron: Basically what happened is there was a ballot to AC for
older HTML things because people were more comfortable
calling those superseded.
astearns: And the HTML spec are waiting for superseded?
dbaron: I think so.
<fantasai> wfm
Chris: Obsolete can be flipped, but it may be better to wait for
superseded.
<dbaron> https://w3c.github.io/w3process/
tantek: fwiw there is a 2018 process document public draft if anyone
is curious to look.
tantek: This is what the difference was intended for. Obsolete is
something that never took off. There are probably CSS specs
that fall there like some of the profiles. It's a good way
to clean up. If there are specs never impl or never tested I
think those are good for obsoleting.
florian: Isn't obsolete or superseded only for REC not just anything
on TR?
tantek: Sure. It is only for REC.
florian: Right, so we turn it into a note and discard if it didn't
make REC.
Bert: I think we made notes for everything. All the other REC are in
use. Profiles never made it.
tantek: TV profile, mobile profile
Bert: They're notes.
astearns: When we have superseded might we use that for lower level
specs with a new module?
tantek: I believe the goal is to include that as a part of the PR
vote. So also say as part of the PR vote that we're
superseding the previous.
astearns: I don't think we have any with a new module that made it
to PR.
astearns: So let's wait for superseded process next year and then
deal with CSS 1 as it's more appropriate.
tantek: A list of specs that qualify would be helpful. I could take
that to the AB.
astearns: Definitely CSS 1.
tantek: CSS 2.0. It's still a rec though it has those warnings.
Bert: It's not superseded yet.
tantek: Well, it is by 2.1
fantasai: That happened because we merged the short name. It's
effectively superseded.
tantek: I recognize we've done good hacks, but there is a dated
permalink that we could mark as superseded.
fantasai: I don't know the permalink. What is that.
tantek: The one with the date.
fantasai: You can't change the dated draft status.
florian: I think there is some plan via JS injection to mark them as
"not the latest draft, look over here".
astearns: Sounds like we've gotten to a stopping point for this
topic.
astearns: That's the end of the agenda. One thing I remembered is if
you haven't signed up for TPAC on the wiki please do. Stat
adding agenda items as well.
<tantek> https://wiki.csswg.org/planning/tpac-2017
astearns: Anything else to talk about?
Q length unit capitalization
----------------------------
ericwilligers: The case in the spec for Q length unit. It used to be
upper and lower, I changed it to lower, then I found
out it's upper in Japan. I then proposed upper and
got comments.
ericwilligers: Chrome is about to ship support of Q and I thought it
would be culturally sensitive for Japan to do upper.
This is just for spec. I think it serializes as pixel.
TabAtkins: You can get it back. I'm fine using upper case in the
spec, I don't care.
fantasai: I agree it serializes the same as other units. But in the
spec using Q in the spec is fine.
astearns: Maybe use it as upper in the spec and add a note it's case
insensitive.
TabAtkins: That's the plan.
astearns: We don't have examples of it as upper though.
TabAtkins: Adding a note saying we're putting it in Q but it's case
insensitive.
florian: Maybe Hz unit too?
TabAtkins: Sure.
fantasai: We can add a note in places with upper saying it's case
insensitive. But it is a capital Q in V&U.
astearns: Thanks ericwilligers.
RESOLVED: Use Q in spec but add a note that it's serialized as lower
case.
astearns: That's it for the call. Thanks everyone.
Received on Wednesday, 11 October 2017 23:28:38 UTC