- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 8 Jun 2016 22:05:46 +0300
- 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.
=========================================
Charter
-------
- The group is considering switching to the software and document
license (available here:
https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document)
and any working group members representing a company were
asked to review this change with the appropriate parties.
- The new charter will still require deadlines so the group plans
to put items that should be finished soon due in a year and
other items due at the end of the charter.
- Spec authors are asked to please give ChrisL any input on
what specs they plan on working on at what time to help
him determine dates.
Handling combined opacity & preserve-3d
---------------------------------------
- RESOLVED: Any value of opacity less than one forces transform
styles to be flat.
OK to have fragment-only URLs always refer to the host document?
----------------------------------------------------------------
- There were strong objections to this approach so TabAtkins will
re-write with a different approach.
@else rule
----------
- glazou had strong concerns that this rule would be very hard for
editors to implement, but TabAtkins felt that the benefit to
authors was greater than the trouble caused to editors.
- There were concerns that having all @else rues ignored after one
is found as true isn't consistent with other media queries,
however it is consistent with most programming languages so it
was felt it wouldn't give authors too much of a problem.
- RESOLVED: Add @else to the next level of conditionals pending
review by dbaron.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Jun/0022.html
Present:
Rossen Atanassov
Tab Atkins
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Dael Jackson
Brian Kardell
Ian Kilpatrick
Chris Lilley
Peter Linss
Edward O'Connor
Simon Pieters
Florian Rivoal
Alan Stearns
Greg Whitworth
Steve Zilles
Regrets:
Tantek Çelik
Brad Kemper
Anton Prowse
Jen Simmons
Lea Verou
Scribe: dael
Charter
-------
Rossen: Hello everyone. Let's get started.
Rossen: As usual, I'm asking for extra agenda items. I have one I
want to start with, but any extra items?
ChrisL: Is charter on?
Rossen: That's the one I was going to give.
<Rossen> http://www.w3.org/Style/2014/css-charter
Rossen: One thing brought to our attention is that our current
charter as in ^ link expires in 7 days.
<ChrisL> http://w3c.github.io/charter-drafts/css-2016.html
Rossen: So we have a week to renew our charter. ChrisL started a
new draft at this link ^ (from ChrisL)
Rossen: We need to act on this rather rapidly. I'd like to let
ChrisL talk to us about it and come up with some actions
so we can close before it expires.
ChrisL: There's a new template that has to be used which has some
new language. I've kept that. The template is on github
and I've put this on github. Because it's for discussion
I've kept a lot of noisy highlighting. There is some buff
background issues from the charter template itself. On the
greenish I have issues I've raised.
ChrisL: First, when referencing a spec you have to have normative
issues, link, description, state of the draft, and
expected completion. When we rechartered last time we
resolved to get rid of these dates. We presented a charter
with no dates and were told to put them back. So we're
required to have a timeline with all the dates.
ChrisL: If you look in the old charter there's a list of
deliverables.
<astearns> do dates have to be as specific as Q1, etc.? Could we
just have years? 2017-ish?
Florian: Can you roll a die and do random dates? When it's done no
one will look.
glazou: Not quire true. ACs could look and see there's no progress.
Rossen: I agree with glazou. Before we do dates lets have ChrisL
finish.
ChrisL: Main thing I need is peoples thoughts on the old
deliverables. We had high priority list. Selectors was a
really bad one, TR is 3 years old. Basically a bit of help
would be useful because if people think should be bumped
down or active things that should go up.
<fantasai> and Overflow
<fantasai> and Tables is now active :) but that's recent
ChrisL: Once I have a bit more information...I'm going to copy
them to the charter and add descriptions. But if people
chime in on when they'll work on specs it will help me add
dates.
ChrisL: Horizontal review is no longer required, that's different.
The template requires you to say your WG home page has all
deliverables, issues, actions, meetings, and I don't think
that's reasonable. I think most groups have that on
different pages.
ChrisL: There's something about the group conducting work on
public ML and I've been talking with plh about adding
github since we're there. I expect that to self-resolve.
ChrisL: We need to do licensing. It says the group will use one of
the options [reads options]. I suggest we pick software
and document license but I'd like opinions.
glazou: There's one thing, what is the expected end date of the
charter?
ChrisL: Typically we ask for 2, I'm going to try for 3. It's
reasonable and worst is we get 2.
glazou: Then I suggest that for estimated dates the ones we want
published ASAP give them one year. For the other...
<glazou> for the others, duration of the charter
Rossen: I'm sure once we get into dates it'll take a bit. I want
to close on a few other things first and I'll get back to
you on this.
Rossen: First was the license thing. We'll have to take this back
to lawyers and I'm assuming others will too.
ChrisL: So there are two and they're linked. One is document
license which is what we're using. The software and
document is newer. It means examples and the like are
covered by the software license and allows people to copy
them and that's okay.
Florian: IT sounds like if and example is three lines it's fair use.
ChrisL: It does. But people worry about this. It removes the
source of worry.
<ChrisL> https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document
Rossen: So yes. I'll have to follow up on our side. I'd urge
everyone representing a company to take that action and
make sure you're comfortable with the licensing section of
the charter.
Rossen: Another great point glazou brought up offline is the
addendum of the WG may add additional work in the future.
I think that's important for us to keep.
ChrisL: I put it in this one after glazou made that comment.
Rossen: With that we can have a looser wording around dates and
timelines. I think now is a good time to resume the
timeline discussion. But let's cap it at 15 minutes. From
memory that topic can take a long time.
Rossen: So glazou I cut you off. Can your resume?
glazou: I thought since giving estimates for specs is highly on
the guess side, I think giving one year to the specs we
want to publish ASAP and giving the duration of the
charter to others is good to do. We've experienced this in
the past and it's too hard to say.
<fantasai> +1 to glazou's plan
<ChrisL> No-one will complain if we get stuff done early
Rossen: Yes, we've proven time and time again our estimations have
had problems. Sometimes we can surprise people. But I'm
with you on this one.
Rossen: Can we keep it loose in terms of timeline? Can we keep it
before the end of the charter and after expiration of this
charter?
ChrisL: I think that's good.
Florian: By complete we mean?
Rossen: Whatever we put for the timelines is what we'll hold
ourselves to. If we say REC by the end then that's it. If
it's CR than that.
Rossen: We should look for ways to not get bogged down to exact
dates.
Rossen: To use looser language and speak in terms of charter
expiration to guide us.
ChrisL: I'm happy to do that.
Rossen: I wanted to hear from more people in the WG. Any input
into this? Anyone care?
<ChrisL> is the "current work" page still the best one to link to?
https://www.w3.org/Style/CSS/current-work
ChrisL: I have one other question. Currently the charter links to
the current work page. Is that still the best? Is it
maintained?
fantasai: Yes.
fantasai: I'm due for double checking it, but it is being
maintained. Bert and I update.
fantasai: As for the dates I'm happy to give you estimates like
"we might get this to CR, this likely not" but nothing
is getting to REC until we have testers that are as
active as the editors.
fantasai: Except maybe Writing Modes, and that's largely because
Japan is driving progress on that.
Florian: Hasn't that changed because gsnedders is doing stuff?
fantasai: He's going to make it easier to collect tests, but
evaluating it isn't on his list and it's not fair to ask
him to do that on all specs.
Rossen: Even if we want to communicate CR expectations that would
be somewhat conformant?
ChrisL: Sounds right.
Rossen: Great. So let's not get too detail-ly.
ChrisL: Thanks.
Rossen: We'll work with ChrisL and organize all the current work
in terms of expected dates and then circle back with the
WG before we go back to plh. If you have concerns about
licensing and/or dates please look at this charter
template and comment.
<fantasai> The stuff in Stable should be possible to get to REC,
but requires someone to own that process. Until then, I
expect no REC within the next 3 years.
<fantasai> The stuff in Stable I expect to stay there.
<fantasai> The stuff in Refining should get to CR before the end
of the 3-year period, excepting CSS2.2
<fantasai> Wrt Revising, I expect Grid to reach CR in about a
month. Box Alignment, Selectors 4, and Display 3 are
likely to reach CR by the end of 3 years.
<fantasai> Sizing and Overflow 3 were recently trimmed down,
should also reach CR soon.
<fantasai> Media Queries 4 is in the process of being trimmed,
also likely to reach CR
<fantasai> I'm optimistic about Scroll Snap, Pseudo-elements, and
Inline Layout also reaching CR.
<fantasai> I expect nothing else to reach CR.
<fantasai> ChrisL, that's my best guestimate :) Feel free to copy
it over into the charter.
<gsnedders> Florian, fantasai: reviewing tests is on my to-do
list, albeit a touch distance, but I don't have the
competency to review tests for all modules
auto-repeat inside grid-template shorthand
------------------------------------------
Rossen: I think this was fantasai or TabAtkins
TabAtkins: Didn't we talk about this last week?
fantasai: Yeah, we did a tentative resolution pending a week. I
don't think there's anything to discuss.
astearns: This is probably my fault. I thought I had de-labeled
all these.
Rossen: Do we need a resolution or move on?
Handling combined opacity & preserve-3d
---------------------------------------
<Rossen> https://lists.w3.org/Archives/Public/www-style/2016Jun/0013.html
Rossen: Who wants this?
smfr: I responded in the e-mail and I'm not sure we need to talk
much. Implementations were not treating opacity as something
that caused flattening.
smfr: You need to flatten to do correct group opacity so I think
it's correct that it should override.
Rossen: So proposal is change that opacity forces flattening.
smfr: The current ED of transforms says that I believe.
<smfr> here's the text in the draft that describes this:
https://drafts.csswg.org/css-transforms-1/#transform-style-property
<smfr> "opacity: any value less than 1."
Rossen: I think on our side we'd be in favor.
iank: I think there's an e-mail on blink dev saying we will, but
I'm not sure.
smfr: I think I talked to someone at SF F2F and we agreed.
iank: Yeah. We've got intent to implement force flattening of
elements with opacity < 1
Rossen: So you're okay with this iank?
iank: Yes I think so unless I'm misunderstanding.
TabAtkins: I don't think you are. I think we support it.
Rossen: So objections? smfr exact wording?
smfr: Any value of opacity less than one forces transform styles
to be flat.
Rossen: Objections to that?
RESOLVED: Any value of opacity less than one forces transform
styles to be flat
OK to have fragment-only URLs always refer to the host document?
----------------------------------------------------------------
<Rossen> https://github.com/w3c/csswg-drafts/issues/165
TabAtkins: At the F2F after a long talk we did a special thing for
fragment only URLs and I realized as I wrote it we
could do better on a fragment only URL in an external
stylesheet. Right now they're resolved relative to the
stylesheet itself. CSS doesn't have fragment semantics,
though
TabAtkins: It would be useful to be able to refer to local
resources in the page and move the CSS to an external
style sheet. I tentatively added that fragment only
also refer to a local reference in the document.
<fremy> @TabAtkins: lgtm
fantasai: I strongly disagree. We talked in the past about adding
a separate functional notation to let you reference URLs
relative tot he document. I don't think the base url
should change based on if it's a fragment.
<plinss> +100
glazou: I agree with fantasai
TabAtkins: Okay. I'll try and do the local document URL when I try
and write this
Rossen: Okay, thank you TabAtkins
@else rule
----------
<Rossen> https://github.com/w3c/csswg-drafts/issues/112
TabAtkins: This was also from the F2F. In a discussion about the
unknown semantics it's frustrating to write a negated
semantic of a MQ where we don't over-exclude but
exclude enough.
TabAtkins: dbaron mentioned doing @else and I wrote it up. We add
an @else that has to follow a conditional rule. Only
one @else can be true, whichever is true first wins. In
order to handle additional queries I have a combined
syntax that requires everything to be in a function,
not alone.
TabAtkins: Because you have the @else ability I added a
generalized conditional rule to let you start the
chain, @when.
Florian: And @when isn't @if because @if was taken.
TabAtkins: I'd rather not stomp on @if. And also @if can feed
imperative but @when matches the imperative.
TabAtkins: So how serious are people on this? We can put it into
conditional rules.
fantasai: Level 4.
glazou: TabAtkins, I understand where this comes from and in
theory I'm in favor. In practice dealing with MQ is
already hell in my editor. My app was supposed to deal
with arbitrary MQ and adding an @else inside MQ will
complexify that. It will be easier for authors, but more
complex for tools. I want you to understand it's already
hell to manage MQ.
TabAtkins: This is a separate rule following a MQ
glazou: But it's negating the thing. You have to find the host and
if it's an @else you have to climb up the tree and find
the MQ and negate it yourself.
TabAtkins: You look at the previous rule in the OM.
glazou: It's already complicated and this is another level. If we
deal a little with editors in this WG, I'm not sure this
is worth the complexity.
Florian: There's problems with writing not something. It's
repeating yourself, very often people have complex MQ.
glazou: We repeat ourselves all the time in CSS.
<TabAtkins> (Check the example at the end of
<https://tabatkins.github.io/specs/css-when-else/#else-rule>
to see how complex doing three mutually-exclusive
queries can be.)
Florian: negating is not an edge case. Writing a complex MQ and
negation is okay-ish, but maintining it is hell.
<fantasai> florian++
<zcorpan> @else can have a pointer to the object it's else-ing in
the OM
<astearns> +1 to @zcorpan's suggestion
<TabAtkins> Yeah, that sounds good. I haven't specced the
interface yet, but I'd be v happy to do that.
<TabAtkins> (I really need to fix the bugs in the CSS highlighting
code.)
[Missed question about doing an @elseif]
TabAtkins: I thought it didn't make a lot of sense to introduce a
elseif name for the intermediate rules.
TabAtkins: I think it's simple to use @else for all the chaining.
Rossen: And if you have an identical @else?
TabAtkins: It evaluates in order and the first one to be true is
normal and anything following is false.
Rossen: It seems like a safe assertion for now, but it doesn't
seem like it would stick. For the same reasons you gave
for an @else they'll want this evaluated.
Rossen: If you have an @else that's the same people will be
surprised it doesn't evaluate.
TabAtkins: Maybe, but if they do it once and see it's more like
conditional chains in every other programming language.
Rossen: I'm not disagreeing with that.
<ChrisL> Yeah it is an easily transferrable knowledge. if then
elsif
TabAtkins: You can just apply your programming 101 knowledge.
plinss: If the following @else are evaluated independently it's
just a @when and you should use @when. @else means
otherwise.
plinss: I don't see why it would be evaluated.
TabAtkins: I can see the possibility that someone who has never
done programming would be confused for five minutes.
Anyone that has done programming should get this
intuitively.
plinss: Anyone that can parse English should get this.
Rossen: I'm hearing one not strong pushback from glazou and a
bunch of people feeling warm. Do we want more air time?
TabAtkins: I'm happy to ask for it, but I'd like more feedback
from dbaron since he's the editor of conditional rules.
* fantasai would also like to hear from dbaron
Rossen: Since he's not here for the next two weeks we can do a
tentative resolution and let him respond.
Florian: I'm in favor of this, but one thing worth noting I think
this is a good idea but it's going to be a while before
authors can use it because you have to wait until all
browsers support it.
Florian: So it's going to be a while.
TabAtkins: It won't help until 5 years down the line when older
browsers die out.
Rossen: Anything else to add or move to resolution?
TabAtkins: We can move.
Rossen: Objections to add @else to conditionals pending review by
dbaron.
TabAtkins: Next level of conditionals.
RESOLVED: Add @else to the next level of conditionals pending
review by dbaron.
Rossen: We're at the end of our agenda. Unless anyone has
something to bring to the table we can conclude.
fantasai: If anyone plans to review Grid and hasn't, please do
that. We're going to wrap up edits this week and ask for
CR by end of the month.
Rossen: Thanks fantasai.
Rossen: Sounds like everyone gets 12 minutes and we'll chat next
week.
Rossen: Please look at charter licensing and dates.
Received on Wednesday, 8 June 2016 19:06:45 UTC