- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 4 Jan 2017 20:25:19 -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.
=========================================
F2F Meetings
-------------
- The group was reminded to add topics to the wiki for next week's
F2F.
- The wiki for the Tokyo F2F is up.
Grid
----
- RESOLVED: Accept the proposal explained here:
https://github.com/w3c/csswg-drafts/issues/523#issuecomment-268095890
- The proposal to address implied minimum size for grid items
(https://github.com/w3c/csswg-drafts/issues/283#issuecomment-268125974)
hasn't been reviewed enough yet and will be moved to the F2F
agenda.
Fix errors in examples (scroll snap)
------------------------------------
- RESOLVED: Re-publish Scroll Snap CR with these changes
(https://github.com/w3c/csswg-drafts/commit/7a20d00238aac3ddbdd8d5dd7e74ff81dd29ba76)
css-speech issues
-----------------
- RESOLVED: Make the change to speak value properties (to
auto|always|none) and inform the a11y TF.
- There is a possibility this resolution will need to be
reversed because it was discovered later that webkit does
already implement the speak property.
- Having the auto value of speak also respond to the visibility
property needs feedback from the a11y task force and from more
people in the a11y community to ensure this change would be
beneficial for everyone as there is a wide variety of reasons
for using the speak property.
Proposed process for maintaining CSS2
-------------------------------------
- The group reviewed the two proposed approaches for maintaining
CSS2 (available here:
https://lists.w3.org/Archives/Public/www-style/2016Dec/0015.html)
- A third approach was discovered over the call to have a Note
that contains the items the WG has agreed to, but are not
ready to pass the PR criteria and be in the PR CSS2.1 spec.
- There were still concerns over how comments will be made and
tracked on these two specs that weren't addressed by any of
the proposals.
- The group ran out of time on the call to reach a conclusion so
this topic will be added to the F2F agenda. Also, fantasai
will send a summary to the mailing list.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Jan/0004.html
Present:
Rachel Andrew
Rossen Atanassov
David Baron
Tantek Çelik
Alex Critchfield
Elika Etemad
Daniel Glazman
Tony Graham
Dael Jackson
Brian Kardell
Peter Linss
Myles Maxfield
Rachel Nabors
Anton Prowse
Melanie Richards
Jen Simmons
Geoffrey Sneddon
Alan Stearns
Greg Whitworth
Steve Zilles (IRC Only)
Regrets:
Tab Atkins
Angelo Cano
Brad Kemper
Vladimir Levantovsky
Michael Miller
Florian Rivoal
Jen Simmons
Scribe: dael
F2F Meetings
============
astearns: Let's get started. Does anyone have anything extra to
add?
astearns: Couple F2F things to start.
astearns: On F2F is you're coming to Seattle and haven't added
yourself to the list, please do.
<astearns> https://wiki.csswg.org/planning/tokyo-2017
astearns: Hiroshi put together the Japan meeting page so people
can add to that as well.
astearns: Please update the pages with your plans. If you have
anything to add to the F2F agenda please do. It looks
pretty full, but always glad to have more things.
Rossen: The same applies for the Houdini attendance list.
astearns: Yes, and Houdini topics would be good.
Grid
====
Stretching image grid items in both dimensions
----------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/523
<fantasai> https://github.com/w3c/csswg-drafts/issues/523#issuecomment-268095890
fantasai: I wasn't on the last call, but there's a proposal in the
github issue.
fantasai: I can go over it if there are questions.
astearns: Has anyone reviewed it and has questions or concerns?
astearns: I saw jensimmons was okay with the direction.
<rachelandrew> this makes sense to me
<rachelandrew> I feel like this is a straightforward thing to
explain
astearns: So...what do you think fantasai? Should we resolve on
your proposal since the small amt of feedback has been
positive.
fantasai: That's cool. We can resolve if people object in the next
week we can reopen.
fantasai: I'm happy to resolve and move forward and take our time
in shipping the new spec.
astearns: jensimmons and rachelandrew are okay with this. From
what I've looked over it's good to me.
astearns: Proposed resolution: We accept the proposal in the
linked comment. Objections?
tantek: Can you summarize if there's any minority opinions in the
thread?
astearns: This has been going back and forth a bit. I'm not sure
I'm prepared to summarize. fantasai?
fantasai: Basic issue is that grid spec as was in the summery...if
you put a grid item and assigned auto size in a fixed
size grid cell it would take exactly that size. You
could change behavior using alignment. Made sense for
non-replaced, but things with aspect ratio this wasn't
expected.
fantasai: We came up with using normal as initial value and have
aspect ratio preserved. But that no longer equated to an
alignment keyword. Normal should be the default.
fantasai: Problem with new normal since it didn't map it meant we
now have 3 sizing behavior that you can switch between
and you couldn't get aspect preserving as a default. You
can't get it with center alignment because it would
trigger different behavior. So we couldn't go with the
previous solution.
fantasai: So we came up with this behavior summarized in the
comment I linked to. We took all the constraints,
started over, and had this solution.
tantek: Reasoning makes sense. Were there other opinions remaining
or was this a check for reasoning?
fantasai: It's please check our reasoning and if there's a
different solution let's discuss. This is CR level so
everyone should notice the change before we do it.
tantek: Yes. This is exactly the kind of change to make in CR. It
looks like Mats is okay with it.
fantasai: We haven't heard from the Igalia folks. I'm happy to
re-open if the implementors on the list have additional
concerns.
tantek: I'm fine with that. I like how you took the constraints.
It doesn't sound like there are minority opinions
remaining. You took them all into account.
fantasai: We tried.
astearns: Any other concerns? Objections?
RESOLVED: Accept the proposal explained here:
https://github.com/w3c/csswg-drafts/issues/523#issuecomment-268095890
Implied Minimum Size of Grid Items
----------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/283
<astearns> https://github.com/w3c/csswg-drafts/issues/283#issuecomment-268125974
fantasai: This one has been going back and forth. TabAtkins and I
decided to take a step back and look big picture. We
looked at the original goal which was prevent small
images or items shrinking to nothing in the presence of
larger content.
fantasai: We wanted to avoid overflow that would make things more
difficult to read. Let's not have overlapping content,
let's have overflowing.
fantasai: We said the only kinds of tracks that need to be
influenced are auto-size. If you have fixed size we
don't want to deal with auto min because it will overlap.
fantasai: Fix sized should apply normal rules. We wanted to
influence automatic tracks.
fantasai: Proposed change was clarify that fixed track are clamped
based on maximum size, not layout algorithm. Second is
min-width: auto or min-height: auto only resolve to auto
min size if item span one track with automatic.
astearns: Has there been any response from Igalia?
fantasai: No responses at all.
astearns: Based on issue and comments do you think your proposal
will satisfy their concerns?
fantasai: I think it will because it will have a much simpler
influence. I'd like their feedback before we finalize.
But it would be good to get if anyone else has concerns
or needs more time.
astearns: Has anyone looked?
Rossen: I wasn't able to, but would like to. If we can wait a week
I'll take a look at it.
astearns: We can add it to the F2F and I can ping Manual to come
back to the thread and give comments.
fantasai: Sounds good.
Intrinsic size of replaced elements incorrect
=============================================
fantasai: I think this should push to the F2F.
astearns: Sounds good.
Clarify how letter-spacing and word-spacing should affect tab-size
==================================================================
fantasai: I responded in the message so I'm waiting on dbaron
dbaron: I need to go write a bunch of tests.
Fix errors in examples (scroll snap)
====================================
fantasai: There were errors in examples based on changes we made
when merging.
fantasai: The examples were missing hte required axis element. I
wanted permission to republish with these fixes. No text
changes. Just fixing these.
astearns: So a resolution to republish. Objections?
RESOLVED: Re-publish Scroll Snap CR with these changes.
css-speech issues
=================
<astearns> https://github.com/w3c/csswg-drafts/issues/510
fantasai: Two issues on speak property.
fantasai: First is naming. Does anyone impl the speak property?
fantasai: I'll take the silence as no.
dauwhe: I looked at epub and didn't see any.
<gsnedders> I think Presto may have had one. But that may have
gone by the last release of Presto.
<gsnedders> Though that's mostly a historical note.
fantasai: So the suggestion was the auto|always|none were easier
to understand properties. I think we should take it.
<dauwhe> +1
astearns: Looks good to me.
astearns: Objections?
Rossen: I would remind you that this spec is supposed to be worked
on by the TF. So it would be good to give them a heads up.
astearns: What's the venue for that TF?
Rossen: I can send links.
Rossen: Since we agreed to work together it would be good to let
them know.
astearns: Would it be better to loop them in before we make the
change or make the change and inform them?
fantasai: I would lean to make the change since the a11y suggested
it.
Rossen: I wouldn't hold the resolution. An FYI is nice.
astearns: Proposed resolution: Make the change to speak value
properties and inform the a11y TF.
RESOLVED: Make the change to speak value properties and inform the
a11y TF
<astearns> https://github.com/w3c/csswg-drafts/issues/511
fantasai: Next was that the auto value of speak should also
respond to visibility property.
myles: I'm looking at webkit and we at least parse the property. I
don't know what we do with it.
astearns: The speak property?
myles: Yes.
myles: I can't look at what it does on the call.
fantasai: Okay.
fantasai: So we'll make that tentative.
astearns: So auto value responding to visibility.
astearns: Seems reasonable.
fantasai: We might want to ping the TF and see what they think.
astearns: Seems like something they should weigh in on.
astearns: Though it came from a11y people.
bcampbell: I think it would be good to have other people review.
Different people with different disabilities use these
tools differently. I can show it to some people here.
ACTION Bo to get more feedback on
https://github.com/w3c/csswg-drafts/issues/511
<trackbot> Created ACTION-807
ACTION Rossen to get the a11y TF people to look at the appropriate
issues.
<trackbot> Created ACTION-808
ACTION fantasai create a a11y tag on github.
<trackbot> Created ACTION-809
myles: We implement the property.
astearns: fantasai are you okay with not resolving on the second
issue?
fantasai: Yeah, as long as there an action to get feedback.
<fantasai> created the Needs a11y tag, has follow-up request to WG
Proposed process for maintaining CSS2
=====================================
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Dec/0015.html
astearns: proposal^
astearns: Anyone have comments? Responses?
* tantek reads
gsnedders: Should someone summarize?
astearns: Yes.
gsnedders: I'll try.
<tantek> I'm a fan of semantic versioning
gsnedders: The question is what should we call future revisions of
CSS 2. 2.x? New editions of 2.1?
gsnedders: That's the fundamental question. All other issues come
around that.
gsnedders: What I said and Florian agreed calling it 2.1 versions
makes it clear that no one should look at the old
version. So 2.1 doesn't become referenced by rec, but
no one should look at it. Especially since in principal
we're not introducing anything that would cause
incompatibility issues.
astearns: tantek on IRC likes semantic versioning, but that does
have the problem of linking. If we have 2.X you're
linking to a specific thing, not the latest.
tantek: I thought that's why we redirect CSS 2 links.
fantasai: Yeah.
tantek: If we're just doing bug fixes we can do 2.1.x but if we're
doing a breaking change, which is a judgment call, but
then I think it makes sense to bump the number to make it
clear and put the giant warning at the top that there's a
newer version.
astearns: fantasai?
fantasai: I don't have a strong opinion. I do think we shouldn't
spend that much thought on naming past this discussion.
There should be no more judgment calls. We should pick a
numbering scheme now and then go.
<dbaron> I thought we already picked, but now we're being asked to
reconsider?
<gsnedders> dbaron: AFAIK, 2.2 is currently called 2.2 by default
with no WG input
<dbaron> gsnedders, we did discuss it
<gsnedders> dbaron: oh, okay :)
fantasai: Another relevant question is do we want to used the
proposed edit recommendation or do we want several rec
track documents that replace each other. That's
something to think about.
fantasai: In either case we can go the same way wrt naming.
tantek: On that question, one thing the AB did get done and I
expect it to get published, is the process 2016 which
fixes the bug, or the regression, that required any
editorial change to go to AC. So anything editorial we can
do without an AC vote.
fantasai: But a lot of our changes are substantive. CSS2 isn't
helped by that.
tantek: Right.
tantek: I guess we're always doing substantive changes?
fantasai: I would say the majority are normative. Bug fixes,
things we realize will block something we want to do in
level 3. There's a number of reason we've made changes.
Clarify, fix error, tighten prose. Very few fixes are
purely editorial.
fantasai: The process I propose is 2 ED. One with the PR ready
changes and one that's the trunk that has all the
changes we've decided to make and we'll cherry pick
fixes from one ED to another.
fantasai: The process to do that is either the PR process or
WD|PR|REC and have a note to obsolete.
tantek: Second draft sounds like a CR draft. If the group has
consensus and there's intent to impl it sounds CR ready.
Are there other categories?
fantasai: Those are really the only two.
tantek: Then those labels already communicate the behavior we're
doing.
fantasai: But they need to exist in parallel and cycle.
tantek: Yes. That makes sense. And using the process you suggest
makes sense.
fantasai: We've got two decisions. Which process for updates and
what do we call it.
<gsnedders> Somewhat off the direct topic, but should we have
changes to CSS 2 that don't have tests? Should we
require tests for each change?
gsnedders: My understanding that publish to CR you're meant to
have evidence of wide review. Which I thought meant
outside the group.
tantek: I think the first time you publish to CR it requires wide
review. I'm not sure if the intent is that's required for
subsequent.
gsnedders: My reading is that it is.
astearns: At least of the delta between the CRs.
<glazou> not sure the Process makes any difference between a
"first CR" and a subsequent CR
astearns: And gsnedders you had a question on tests in IRC. I
think the answer is yes where possible.
gsnedders: Yes. Most of the changes we made to CSS2 were fairly
small and changeable.
fantasai: In a lot of cases we'll see it's a problem, we decide to
fix, and someone needs to write a test. I think the
changes section of the CSS2 needs to be an impl report
with links to tests. Then it's clear.
fantasai: That's kind of a record keeping things. Whatever we're
doing we have to update the REC. There's two ways to do
it. Standard procedure to refresh the REC. Other one is
to publish a FPWD and then jump to PR, get and AC review
on that, and go to REC with that, adding a not to the
old REC. In which case you need a new short name. BUt
then you get a WD without AC review
astearns: I haven't thought through this a lot, but I don't want a
proliferation of short names.
<dbaron> I don't feel like we'd have a huge number of shortnames.
<dbaron> We should get all the pieces of 2.1 replaced by modules
after a reasonably small number of these revisions...
<gsnedders> https://www.w3.org/community/w3process/wiki/Rectracktimeline
is kinda relevant here when it comes to going down the
the FPWD route
tantek: I want to understand what in an ideal world the right
thing would look like and then the delta between that and
what you feel compelled to do due to process and I'd like
to take those as feedback on process.
fantasai: I think for us for CSS2 as editors we really need two
copies of the spec; one is REC qualified and one working
toward that that includes all the changes. As soon as
any change hits all the checkboxes it ports into the REC
ready copy.
fantasai: Both of these drafts should be on TR somewhere easy to
update. I think both processes give us what we want. The
PR is clearer I think, but we need a
CSS2-things-working-on that's a perpetual WD.
fantasai: The other one will have to be on a month long minimum
cycle due to AC process. That's fine, though.
tantek: Perpetual WD sounds like living doc.
astearns: It's non-REC since we don't want that doc to go to REC.
fantasai: Maybe it's a note. 2.1.next WG note. We cycle CSS 2.1
into PR and back every month.
astearns: We have a note that's proposed errata and things live
there until edited in.
gsnedders: Should the note be in TR? Normally errata are not.
fantasai: Technically ED are unofficial and we should have
official drafts of things we're working on. Historically
we have a hard time keeping that up to date because the
process to publish, but that's been fixed. We can push a
draft to TR in 5 minutes. With bikeshed you do a command
with the resolution link.
fantasai: So all of our drafts should be 100% up to date and no
one should look at ED unless you're in the middle of a
change and you're discussing it with the person you're
working with. We're not there, but we should get there.
tantek: As soon as you have consensus on something it should go to
TR.
gsnedders: From that PoV we should put in TR a copy of CSS2 with
the errata applied.
fantasai: Yes, it should be a full copy of CSS2 with errata
applied, not a list.
astearns: Note can be a full copy with the errata applied and a
list of the changes so they can be reviewed.
fantasai: And we have the list and it just needs to be cleaned.
astearns: Every time we push something to the PR it gets taken off
the list in the note.
tantek: Once both published.
gsnedders: What's the point of notes instead of drafts.
astearns: A note shows this is not a doc we're planning on taking
to rec. It just gets republished on TR and the process
has notes already in it.
* gsnedders feels like he's missing something here
fantasai: And there's a copy that's going to rec that will cycle
back and forth.
tantek: You can look at the note as where we're incubating the
edits to CSS2.1
fantasai: Yeah
tantek: We're putting there until we get impl.
astearns: And gsnedders, the only reason it's a note is that it's
already in the process as a document that will not go to
REC itself.
tantek: This makes sense to me.
tantek: You've got your ED that's whatever the editor drops in
there. You've got your note that reflects the consensus of
the WG but may not be implemented and you've got your PR
that is tested.
gsnedders: Does it make sense to have an editor draft? I thought
PR was equivalent to PR.
fantasai: But we've taken CSS2.1 to that part of the process. It
doesn't have to go back to WD to edit.
tantek: We're saying that everything in there has two interop so
it has exited CR.
gsnedders: My point is can't we just make it a WD of something
that's gone to REC> IT's a WD that will go to PR.
tantek: You don't need the extra step.
gsnedders: I was just making a point of does it make sense.
<gsnedders> But don't we have a PER and a REC with the same
shortname, in principle, at the same time
fantasai: It makes sense that...the stuff that's not ready needs
to exist on the TR space. WE can't have a single draft
exist in two states at once. ANy spec as a shortname can
exist only in one state. WE need two states to exist so
we're prop to have the one represent impl status be
CSS2.1 and have it go between PR and REC depending on
when AC looks. It will get two impl. Instead of the
other being a WD we'll publish as a note which is the
same, but says by status it's not planning to go on the
rec track.
glazou: I wanted to make one comment on the sentence from tantek.
You said we have an ED and push to a note. I'm concerned
about the comments made on these documents. Where will
they go. How will we handle them. How will we connect them
to the document they're related to. This will be hell.
fantasai: I think this is the clearest path we've found.
glazou: I'm not saying it's not clear. There's one detail [missed]
glazou: I'm concerned about our handling of feedback from readers.
How will we connect feedback to the right version.
fantasai: All feedback will be against CSS2 and filed in github.
It will be processed the same way. If it has 2 impl and
a test it will go into PR & note. If it needs work it
goes into the note.
glazou: That doesn't address the question. The reader can comment
on the ED, the note, and the CR/PR. WHich version will you
consider as input.
<tantek> labels?
astearns: I think we need to have the comment son the PR and we
work on replies through the ED and note.
tantek: Impl will comment on the note.
tantek: So glazou is right.
<glazou> thanks tantek
<dbaron> Implementors aren't likely to look at a document where
the errata aren't incorporated into the document.
astearns: We're out of time. We made progress and should address
next week. fantasai can you reply with the added idea of
the note and summarizing?
astearns: We can finalize next week.
astearns: Thanks everyone for calling in and I'll see you next
week if you make it to Seattle.
Received on Thursday, 5 January 2017 01:26:24 UTC