- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 30 Nov 2016 16:55:37 -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.
=========================================
CSS2.2 plan to CR and test review request
-----------------------------------------
- gsnedders and gregwhitworth offered to review the test suite.
Anyone with interest in a section of CSS 2.2 was also asked to
review at least that section.
- In addition, anyone with interest was asked to review the edits
made to CSS 2.2.
- fantasai will start a thread on the member e-mail list to
discuss how best to keep the CSS 2.X specs updated quickly as
items become interoperability implemented.
- For CSS 2.2 individuals should put issues in where they think
there should be a link to another spec. In CSS 2.3 there will
be work done to integrate all relevant links.
- The group agreed to a goal of getting CSS 2.2 to CR within a
week after the Seattle F2F.
- Review requests will be sent to the appropriate groups
noting that are errata only to help them prioritize.
Remaining Grid Issues
---------------------
- Rossen & TabAtkins agreed to review the conversation on github
around the new definition for 'normal'
https://github.com/w3c/csswg-drafts/issues/523
Need clarification on `auto` margins for abspos flex children
-------------------------------------------------------------
- RESOLVED: For all layout modes when you're figuring out static
position of an abspos child treat auto margins as 0
regardless of normal positioning rules.
Computed value of currentColor
------------------------------
- Everyone agreed that the proposed edits should occur, but
Florian will bring his proposed text to the group as there are
many specs that will need changes.
Should caret-color apply to any element?
----------------------------------------
- RESOLVED: Change the applies to line to all elements
- RESOLVED: Add an informative note as to what is a caret and what
is not.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Nov/0115.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Bo Campbell
Tantek Çelik
Dave Cramer
Elika Etemad
Dael Jackson
Brian Kardell
Peter Linss
Myles Maxfield
Rachel Nabors
Simon Pieters
Anton Prowse
François Remy
Florian Rivoal
Geoffrey Sneddon
Alan Stearns
Greg Whitworth
Steve Zilles
Regrets:
Daniel Glazman
Scribe: dael
Note on the call: Due to problems with the conference bridge, the
meeting began late. All conversation around the conference
bridge has been removed, but specific topic discussion in IRC
before a bridge was established is left as-is below.
CSS2.2 plan to CR and test review request
=========================================
<astearns> SO - the first topic is CSS 2.2
<fantasai> Wrt CSS2.2... I think dbaron said some of the edits are
actually incorrect, so it needs to be verified that
things are correct.
<astearns> who will do that verification?
<Florian> Were the incorrect edits identified?
Bert: 2.2. My goal is to get a plan for getting 2.2 to CR and then
PR.
Bert: It's only FPWD officially but I believe everything is
implemented or close to. To get there I made a number of
items to discuss.
Test Suite
----------
Bert: First is test suite.
Bert: I tried to make tests for all things that are different in
2.2 from 2.1 I submitted and saw gsnedders is reviewing.
Bert: Are my tests correct? Do we need more tests?
Bert: If gsnedders could weigh in on that.
<astearns> gsnedders: have you been able to connect?
[he has not, but is joining]
<dbaron> is there a diff-marked version of the spec relative to
2.1?
<fantasai> dbaron: https://www.w3.org/TR/CSS22/changes.html
Bert: Or can anyone check the test coverage? I think I have at
least one test for everything normative but I may have
missed.
Rossen: Can we turn this into an action for people that want to
review and give them a week or two?
<gregwhitworth> I will review it in the next week or so
fantasai: Bert can you link the tests from the changes page?
fantasai: I think it would help because then this becomes the
implementation report.
Bert: Yes, I linked to the doc section, but I can link to the
changes. That will take a few days.
gsnedders: As far as to the tests they're in the 2.1 test suite
because Sheppard doesn't know about the fragment IDs in
the changes list.
astearns: So are you asking if there should be a 2.2 suite?
gsnedders: Most of our tooling is built around the test suite and
at the moment most of these test wouldn't be put into
any test suite because Sheppard doesn't know the
fragment IDs
plinss: We could have 2.2 but that would only include the 2.2
test. Which may be sufficient.
astearns: It might be preferable.
plinss: That's trivial to spin up. I can do that today
Bert: Do I need to do anything?
plinss: If the tests have links to the 2.2 spec we're fine.
Bert: Okay.
<dbaron> Are the tests visible as files somewhere, or only inside
the pull request in https://github.com/w3c/csswg-test/pull/1139 ?
<gregwhitworth> yes
<gsnedders> dbaron: http://csswg-test.org/submissions/1139/
<gregwhitworth> I would love to look at just the tests for these
changes
<gsnedders> dbaron: though obviously that's the whole testsuite
<gregwhitworth> gsnedders: can you get me the link to the 2.2
tests, I don't run shepherd and there aren't many
here to quickly go through - I'd like to have bugs
filed on Edge for these
<gsnedders> gregwhitworth: there's nothing better than
https://github.com/w3c/csswg-test/pull/1139 and
looking at the list of files there quickly
<gregwhitworth> gsnedders: awesome thanks :)
<gsnedders> gregwhitworth: I can probably create a quick list at
some point later today, if that helps
<gsnedders> gregwhitworth: like, list of links to the new tests
<gsnedders> https://github.com/w3c/csswg-drafts/issues/412
definitely needs edits
Bert: Were the tests correct? gsnedders you were looking. I think
I answered all your comments. Did you look?
gsnedders: Not really. I also haven't looked to see if the tests
matched the changes to the spec. I was doing a quick
high level review.
astearns: Are you planning on looking more detailed, gsnedders?
gsnedders: I can...some of them I'm not competent to review.
astearns: It would be useful if you can and it looks like
gregwhitworth has offered to look.
gregwhitworth: Yes, yes. I'll help as needed.
Rossen: My ask for everyone is given that CSS 2.1 is what everyone
on the web depends on it's in our best interest to make
sure 2.2 is as interop as quickly as possible. Especially
for implementors changing behavior to align better it's my
ask to make sure these are testing what they're supposed
to test.
Rossen: Nothing new in the ask, but more action. I believe this is
the largest impact to interop in the short term.
astearns: Can anyone else commit to taking a look at these tests
and see how well they match?
astearns: If there is a particular errata in 2.2 you were involved
in I'd like you to at least look at those bits.
Process for publication
-----------------------
gsnedders: How many outstanding edits are there on 2.2?
Bert: fantasai pinged me one thing. That's the only one I know of.
fantasai: It was a baseline alignment issue. I don't think it's
interoperability implemented and I just put an issue
against the errata.
fantasai: I'm happy this is happening and I think we need a
process that lets us make edits on 2.2. If we try and
address every thing, though, we'll never get there.
Going forward we need a copy of css 2 that's only the
changes implemented across browsers and a second copy
that's changes decided and not implemented.
<tantek> agreed with fantasai: need CSS2.x that reflects interop
reality, and another CSS2.x that reflects that *plus*
CSSWG consensus decisions on fixes/issues
fantasai: We'll need a multi-stage release process. There's going
to be a lot of issues not addressed in this draft. We do
need to have a way of getting this draft to rec on a
continuous basis. This is a good start to have the
errata that are passed.
<gsnedders> we have git cherry-pick and similar if we want to move
edits, but that doesn't work with stacked edits,
obviously
astearns: I think this is important. I don't want to spend too
much time talking process today. Could we do something
like have these edits not implemented in as at risk and
once they're implemented we take the at risk off. And
once we move forward we move them out to the next level.
<tantek> or go into the next +0.1
Florian: When they're changes to a sentence how do you have a
sentence at risk?
fantasai: For the old process we used to be able to go from WD to
PR if you had fulfilled the requirements. We may want a
WD copy and a PR copy and only include the changes
implemented in the PR and have a trunk branch with all
the decided changes and cherry pick the ones implement.
fantasai: We'll skip the CR cycle
<gsnedders> https://www.w3.org/community/w3process/wiki/Rectracktimeline
implies you need a CR
<tantek> or we use that CR cycle to set expectations of what is
going into the PR, and have a convention of no at-risk
items there
<tantek> CR is only 4 weeks anyway
<tantek> and that's good time to verify tests
<tantek> and get broad review
astearns: Let's start a thread on the member list to decide how to
manage 2 going forward. fantasai can you start that
thread?
fantasai: Sure.
<tantek> fantasai, in general I agree with your approach, see
above for how a minimal CR could be useful
astearns: Any more topic on 2.2 test suite?
Wide Review
-----------
Bert: Two things more. 1 is to go to CR you have to prove wide
review. There hasn't been a lot of comments, but that's not
so strange. So we need some way to prove this has had enough
review. If you have ideas for the arguments let me know and
I'll put those in the transition request.
astearns: Are there other groups we should notify and ask for
review?
tantek: Web platform.
Bert: Yes. a11y normally.
tantek: Yes, but with the note that these are errata only. Same
with i18n.
astearns: We can send out that standard e-mail for review.
tantek: We didn't drop any feature either, right?
Bert: I don't think so.
astearns: Early in the conversation fantasai raised a concern
about incorrect edits. Have we had internal review?
fantasai: I don't remember what it is, I remember that last time
we talked dbaron mentioned there were incorrect edits.
Rossen: So in addition to reviewing tests, please review the
changes.
dbaron: I'll try and look. I may not have time in the next few
weeks.
Linking to other specs
----------------------
Bert: I was hoping that you could be more concise about the links
of other specs requested. It's harder to make links from
chapter definitions. I saw SimonSapin made rough links. How
far do we go in making links to level 3 in the document?
Florian: I think when we have a level 3 entirely replacing a
section it should be linked. When it's a little bit it's
more tricky.
astearns: I wonder if this link replacement could go into 2.3
since 2.2 is close to done. I'm not sure I want to add
this to slow the CR and PR down.
Bert: That's a possibility. Make a copy, call it 2.3 and start
editing there.
tantek: Depends on whether we can get CSS 2.2 into CR by next
Tuesday (week?) right?
fantasai: I think we should go with the edits here and not add
anything. Mainly let's start and get a chunk through.
That way this isn't a big issue and we can push though a
set a year.
gsnedders: We have interop on some of the changes in syntax so we
may want to include them. We don't have interop on the
2.1 and current 2.2 behavior anymore.
fantasai: That's fair. we should fix them.
astearns: Can they be issues?
gsnedders: They are.
gsnedders: Should we add a 2.2 label on github for things that
should go in there?
astearns: Makes sense.
astearns: tantek mentioned postponing the links to 2.3 is
dependent on getting 2.2 to CR on Tuesday. I'm not sure
that's the case. If we don't make the deadline and have
to publish the CR in Jan I think it's useful to get out
as quickly as we can and postpone the link replacement.
tantek: I think that's good in general. I think we should file
issues for each link replacement and we can decide case by
case. I was thinking of the box model width and height
calc are strongly patched in the CSS3 UI box-sizing
section which makes lots of changes and anyone impl should
be reading that.
tantek: I'm just raising that there may be things worth putting in
if we aren't going to make the 2016 deadline.
astearns: So we'll add the 2.2 label on github. I'm pretty sure
we're not going to make the end of the year CR given
that people are still reviewing edits and test suite.
Bert: That's no problem. I didn't ask for CR by the end of the
year, just something soon.
astearns: Anything else on 2.2?
Bert: That's the end of my list.
Timing
------
tantek: Are we trying to CR before Seattle?
astearns: I think that's achievable
tantek: Or is that where we make a final decision on in or out?
fantasai: I think the later is more achievable.
astearns: Let's see what we can do before Seattle and anything
left over we decide in person.
tantek: So we're giving ourselves a deadline of publish CR of 2.2
no later then a week after Seattle F2F?
astearns: Yep.
Florian: How does the asking other people to review work with that?
astearns: We should ask for wide review now; there's enough bulk
in the errata that people will take time. If we wait for
everything is done it add another month to the process.
I'd rather get 2.2 out and start on 2.3.
tantek: Reasonable. Should we resolve to publish a WD that include
the current status of all the edits and send that for
review?
Bert: I don't think I have anything different then current WD.
astearns: So current WD has all the edits.
Bert: Right.
astearns: So that's what we'd send out.
tantek: So no changes in the ED.
Bert: I'll check, but I don't think so. no.
<SteveZ> sending for Wide Review now is what we should do because
the existence of Wide Review is an entry condition for CR
Remaining Grid Issues
=====================
astearns: I'm not sure what's left. fantasai do you have things?
fantasai: There's been discussion. There was a set of edits for
new normal behavior; we resolved that normal preserved
the aspect ratio. It used to be a synonym for stretch.
There's been additional discussion on that. I've made
the edits, I'm looking for review
astearns: Do you have the issue link?
<fantasai> https://github.com/w3c/csswg-drafts/issues/523
fantasai: There's discussion on what if you have normal in one
direction and stretch in the other. Also just the edits
are in and need review. I'm not caught up on the github
conversation.
astearns: Can someone involved in grid look at this?
TabAtkins: Yes.
Rossen: I'll do it on our end.
<fantasai> thanks :)
astearns: What else for grid?
fantasai: I think that's the main thing. Let me flip through and
look for anything else. You can move to the next topic.
astearns: I think we just did the next topic. I'm going to take
the "Grid Layout Issues" topic off the agenda; it had a
lot of things. If we need those discussed let's raise
them separately.
Need clarification on `auto` margins for abspos flex children
=============================================================
<astearns> https://github.com/w3c/csswg-drafts/issues/665
TabAtkins: Mats brought this up a while ago.
TabAtkins: When you have an abspos child you lay it out like the
container. Presumably that means they work like they do
for flexbox. Chrome and Edge don't do that; they do it
as 0. If an abspos child of a block container has auto
margins it also gets treated as 0. This is just to
determine static position.
TabAtkins: Because everyone seems to agree, the proposal is in
position draft or in flexbox we define that when
finding static position the margins are 0.
Rossen: I think I made that change and commented.
TabAtkins: There wasn't anything on the issue.
Rossen: I may be thinking about a different issue. [looks] I was.
Rossen: I can take the action to make the edits if the WG agrees.
fremy: works for me
<tantek> sounds like it makes children that are abspos, their
auto-margins more predictable / consistent, so that seems
reasonable
TabAtkins: prop res: For all layout modes when you're figuring out
static pos of an abspos child treat auto margins as 0
regardless of normal positioning rules
fantasai: This also needs to go in CSS 2.1
Rossen: Sounds like we need this in errata and positioning spec.
TabAtkins: Yes.
astearns: obj?
RESOLVED: For all layout modes when you're figuring out static
position of an abspos child treat auto margins as 0
regardless of normal positioning rules.
ACTION bert make the change to 2.1 for the abspos resolution
<trackbot> Created ACTION-804
Computed value of currentColor
==============================
<astearns> https://github.com/w3c/csswg-drafts/issues/741
Florian: We've defined in css color 4 that currentColor is
supposed to compute to currentColor, but css 3 UI doesn't
invoke that text. It instead says that caret color
resolves to inherit. Are we okay to fix it so that
currentCcolor computes.
<tantek> can we just update to reference css-color-4?
TabAtkins: I agree the wording should be changed, but I don't like
the actual wording. I would prefer we define an
algorithm for doing the color like we do with links
made absolute phrasing and you invoke that.
tantek: I'd agree with TabAtkins.
Florian: We have text in Color 4 that says how currentCcolor
computes in general.
Florian: Should I come back to the call once I have better
phrasing?
fantasai: Whatever you choose we need it to be same for a whole
bunch of other stuff. So please bring it to the group.
Florian: Are all the other specs inherited?
fantasai: Text decoration does. Currently says as spec in computed
value.
Florian: Okay. I'll try and come up with a wording.
fantasai: All the specs need to be updated, so please base it off
of level 3 of color.
Florian: I'll try. Useful wording is in level 4.
TabAtkins: We can pull it back if we need to.
fantasai: we'd resolved to update L3...not sure if it's done yet.
Florian: I'll come back with a suggestion.
astearns: My ask is for Florian and TabAtkins to work on the
wording in the issue and have you both agree.
Florian: yeah.
TabAtkins: Sure.
Should caret-color apply to any element?
========================================
<astearns> https://github.com/w3c/csswg-drafts/issues/725
Florian: Currently the edit talks about caret. There's a bunch of
browsers with a caret navigation mode. The question
raised is if caret color applies to that. Since caret nav
isn't defined we can be explicit and say it's undefined.
TabAtkins: Just doing that doesn't work because the property says
it applied to editable elements.
TabAtkins: I'd prefer adding it to all elements and have a note
that anything caret-like, for example nav caret, should
be effected. Informative note.
Florian: I don't think it can be normative because caret nav isn't
defined.
tantek: Tab are you asking for the normative change to change the
applies to?
TabAtkins: Yeah. Applies to doesn't have any normative meaning.
<fantasai> +1 to fixing applies-to
tantek: I'm just worried if we are in CR does this mean more tests.
TabAtkins: Nope. You can't test an applies to line. It's
impossible.
tantek: I in general agree, but we did have a case in CSS 1 where
that happened.
TabAtkins: It's a behavioral change. The applies to doesn't case
that.
tantek: In CSS 1 it did happen.
<fantasai> +1 to tantek
<fantasai> It does make a difference. In some cases it's not
detectable, and in others it is.
Florian: There is no difference between applies to and applies and
does nothing. If you have a caret for another reason we
make it so it can apply.
tantek: I'm concerned we'll mislead authors. If it applies to all
elements and I see the text selection cursor I'd expect it
to change colors.
TabAtkins: But then that applies to current editable elements. It
doesn't and we don't expect confusion.
tantek: I'd add a normative note that it's only to the actual
caret, not the text cursor.
Florian: People are frequently confused between caret and cursor
so that's not a bad idea.
astearns: I headed three things. 1) normatively change applies to
line 2) add an informative note able nav carets and
caret-like things 3) add a note that says really only
carets, not things like cursor.
Florian: For the 2nd it is this may apply or should?
TabAtkins: It's normative so it's pointing out there are other
things like carets.
tantek: Which is why I pointed out the text cursor.
astearns: I think 2 and 3 should be one note.
TabAtkins: That sounds reasonable.
Florian: sgtm
astearns: Objections to changing the applies to line?
RESOLVED: Change the applies to line to all elements
astearns: Objections to the proposed note?
myles: Can we clarify should or may?
TabAtkins: It's informative so doesn't matter.
RESOLVED: Add an informative note as to what is a caret and what
is not.
astearns: Thanks everyone.
fantasai: We're publishing an update to box alignment soon so if
you're interested please take a look.
Received on Wednesday, 30 November 2016 21:56:43 UTC