- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 16 Mar 2016 19:45:58 -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.
=========================================
Future F2Fs
-----------
- There will be room for everyone on every day at the May F2F
thanks to the efforts of Ojan and Shane.
- The Houdini group needs to decide if and when they'll need room
at TPAC.
CSS Snap Points
---------------
- RESOLVED: Publish new WD of CSS Snap Points
Snap Size FPWD (short name TBD)
-------------------------------
- Step-sizing received favor as a new name.
- Several implementors hadn't had time to review the spec. Though
they were interested in solving the problem space, they
weren't prepared to affirm that this ED is the direction they
believe the group should go to solve it.
- Implementors were given another week to review the spec in
hopes of being able to resolve.
We have an issue in the 2015 Snapshot for adding Will Change once it
hits CR
---------------------------------------------------------------------
- RESOLVED: Republish 2015 snap shot with Will Change added.
CSS UI Implementor feedback on allowing pseudo-elements on form
controls when appearance:none
---------------------------------------------------------------------
- TabAtkins will write up a proposal for checkbox and radio
buttons for next week detailing his thoughts while everyone
else reviews the e-mails.
CSS Values
----------
- RESOLVED: Allow calc() to be nested.
- RESOLVED: Drop calc() from nested calc() and serialize it as
parentheses.
- calc() simplification for serializing specified values will
continue on the mailing list and be on next week's agenda if
needed.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Mar/0233.html
Present:
Rossen Atanassov
Tab Atkins
Bert Bos
David Baron
Dave Cramer
Elika Etemad
Simon Fraser
Daniel Glazman (IRC only)
Tony Graham
Koji Ishii
Dael Jackson
Brad Kemper
Peter Linss
Anton Prowse
Matt Rakow (IRC only)
François Remy
Florian Rivoal
Alan Stearns
Regrets:
Tantek Çelik
Greg Whitworth
Scribe: dael
Future F2Fs
===========
Rossen: Let's get started
Rossen: Are there any additional agenda items?
Bert: Maybe a reminder that Houdini needs to decide if they are
meeting at TPAC.
Rossen: Thank you Bert. We did discuss and we want to meet. I'll
send a mail to the Houdini list and if everyone is on
board we'll reserve with you. Thank you for the reminder.
Snap Points
===========
fantasai: Can we publish CSS snap points since there isn't hope of
it getting more up to date?
Rossen: Are all editors on the call?
fantasai: I have no idea. Why don't you ask MaRakow if he wants to
publish or not.
Rossen: MaRakow are you on the call?
<MaRakow> Irc only
<fantasai> Question is just, should we publish what we have
<fantasai> or rather, what MaRakow has so far
<fantasai> so at least there's an update from the previous
publication
Rossen: IRC Only. Okay. We'll ask him or IRC and review this at
the end with IRC responses.
Rossen: Anything else that needs to be added?
<MaRakow> It's fine to publish what's there currently, I requested
this previously.
Future F2Fs
===========
Rossen: Quick reminder on May F2F. We'll be hosted at Google.
There will be enough room for everyone on all days,
including Wednesday. Thank you again for pulling this
together on short notice, especially Shane and Ojan.
Rossen: If you haven't booked, I'd recommend doing so. I'm not
sure if there's anything big, but when I was tying to book
there weren't too many options.
Florian: If anyone is interested in AirBnB it's time we coordinate.
I'm interested.
Rossen: Florian, if you could just start a thread on the private
list it would be great.
Snap Points
===========
fantasai: MaRakow says he thinks it's fine to publish. Can we
resolve and someone action to publish?
Rossen: Yes, let's vote. Objections to publishing CSS snap points
as a new WD?
Florian: One question, where are we?
Florian: Along the merging process moving TabAtkins and fantasai
items into MaRakow draft?
* fantasai is guessing we are about 50% there
Rossen: MaRakow is on IRC and is the one in the position to answer
that.
Rossen: As far as I know there's still outstanding merges, but the
spec is in consumable version so there's no reason not to
publish from that PoV.
Rossen: Any objections or questions?
Rossen: I'll take that silence as a no. Is there even interest?
Florian: I'm more interested in where this is, but I'm excited to
work on it.
Rossen: I'm glad there's interest.
<MaRakow> awesome :)
fantasai: There HAS been interest!
<fantasai> If there wasn't any interest in it, Tab and I wouldn't
have dropped everything to work on it between the Paris
and TPAC F2Fs, and there wouldn't be 3 implementations
of varying bits of its functionality!!!!
<Rossen> fantasai: let me reiterate again that what you and Tab
did was great work. The editor of the draft also did a
lot of work for the few years before that but the other
implementers weren't implementing yet.
RESOLVED: Publish new WD of CSS Snap Points
<TabAtkins> I do question why there are any outstanding merges at
this point, months after we were promised a complete
draft and assured there's no need to add fantasai or I
as editors to get it done.
Snap Size FPWD (short name TBD)
===============================
<astearns> https://drafts.csswg.org/css-snap-size/
<astearns> name suggestion: step-sizing
<SteveZ> name suggestion: line-height-adjust
koji: There was a discussion on property names. I think the best
suggestion is step instead of snap.
koji: The spec has the updated language.
koji: The only thing I haven't changed is the short names because
I wanted to get confirmation from the WG if these new names
are okay and if we can publish.
Florian: Last time we discussed there was a request from me for
extra time and I need to apologize because I've been busy
and have not. I do want to review and I haven't. I'm not
sure if the others that wanted to review have had time.
On my part I haven't. I'm really sorry.
* fantasai hasn't had a chance to review, either
astearns: I've reviewed and like the current state. I suggest we
name it step-sizing.
astearns: At the moment the title is CSS step size. We have CSS
sizing in another draft so I was thinking step-sizing
would work.
koji: Can we go for that as both title and short name?
astearns: Right.
astearns: SteveZ mentioned line-height-adjust in IRC. This isn't
just height and I'd hope this wasn't just line boxes, so
I'd rather not restrict.
koji: I'm good with that.
Florian: Though I haven't had time to review, I know I shared
concerns with astearns so that gives me some comfort. I'd
still like to review.
fantasai: I haven't had a chance to review either. My opinions
aside, I'd like the WG to have consensus that this is a
thing we want rather than some people saying it's an
okay idea and others being eh. I think FPWD should be
created when the WG has a positive, not a neutral opinion.
fantasai: If there's only interest from koji and astearns and no
other implementors that's not a good sign. If people
think this is cool, then we should proceed. I want to
hear from more people rather than have silence as a
reason to publish.
Florian: As an implementor I'm interested in the problem space,
but I haven't reviewed the spec enough to meet that bar.
Rossen: That's a fair point. Other implementors? Apple? Mozilla?
Rossen: Can you talk in terms of interest?
smfr: It's worth considering, but not high priority. It seems like
a generally useful thing to implement long term.
Florian: Are you interested in solving the problem, or solving it
in this specific way?
smfr: In the problem space. I'm not familiar enough with other
solutions to be able to judge against those.
dbaron: I'd like a chance to look at the spec. It's hard to
comment now. Based on some discussions there was some
interest, but hard to say amount.
Rossen: For Edge I'll say along the same lines. It's an
interesting problem to solve. The way Koji proposes to
solve is interesting. In terms of priority it won't be
high on the list for us for impl or spec work.
<dbaron> What's the URL for this draft?
<dbaron> (I don't see a URL in the agenda)
<koji> dbaron: https://drafts.csswg.org/css-snap-size/
Rossen: If I have to summarize as a chair, sounds like the
interest is low to moderate.
Rossen: Is it worth waiting a week or two for the rest of the
people to review the spec?
<astearns> the spec is relatively short - it should not take too
much time to review
fantasai: I would really appreciate having Florian and dbaron take
a more detailed look. I'd like to do that myself. I
don't feel we have a very strong sense of this is
definitely the right way to solve this. We have this is
an interesting possible solution. I'd like to get to
where we had something that is how we believe we want to
solve the problem and then go to publish.
fantasai: We have the ED so we can see. Rather than have 5 modules
of 5 proposals, I'd rather we explore as to if this is
the right direction and do WD when we're confident it's
going in the right direction
<dbaron> How does this relate to line-grid proposals?
astearns: In regards to it relating to line-grid proposals, this
is a useful tool for when you are using a line-grid.
astearns: The line-grid will cause things to move and snap into
place depending on the line height and grid spacing
relationship. This is a way to ensure that the ratio is
such that they do not shift. So this is complementary,
particularly when related to block.
Florian: This is part of why I want to review. It would be good
for them to be complementary. I want to see how they work
in the inline direction too.
Rossen: So we'll give it another week or two if someone asks for
two on the ML. When enough people have reviewed we'll
discuss.
CSSOM 4 Selectors Review
========================
<Rossen> https://lists.w3.org/Archives/Public/www-style/2016Mar/0213.html
astearns: This is mainly a reminder that we agreed to look at the
CSSOM one section a month and thi sis this months'
section.
astearns: If people have comments to make now, great. If not take
this as notice you should look at this short section and
help us finish it up.
<glazou> thinks that section is ok
<glazou> has one extra comment though
Rossen: We have glazou at least that thinks it's ok. Anyone else
show is currently ready to comment? Or is this an action
to start review?
fantasai: We should all take it as an action.
ACTION everyone review this section of CSSOM 4 by the end of the
month
CSS UI Implementor feedback on allowing pseudo-elements on form
controls when appearance:none
=====================================================================
<Rossen> https://lists.w3.org/Archives/Public/www-style/2016Mar/0190.html
Florian: This is TabAtkins with me replying.
<TabAtkins> Be in in just a sec.
Florian: Is TabAtkins there? If not let's delay a bit more
Florian: Do we have a short topic?
We have an issue in the 2015 Snapshot for adding Will Change once
it hits CR
=====================================================================
<Rossen> https://www.w3.org/TR/css-2015/#issue-d34d1161
Rossen: We have an issue for adding Will Change once it hits CR. I
believe this is fantasai.
fantasai: So should I create a new draft with that added and
republish as the 2015 snapshot as intended?
Florian: I think so, or is it 2016?
fantasai: I think 2016 we can do later.
Florian: Okay, I don't care strongly.
<Bert> Let's publish a new snapshot, don't care if it is called
2015 or 2016.
Rossen: So objections to republishing 2015 snap show with Will
Change added?
RESOLVED: Republish 2015 snap shot with Will Change added.
* TabAtkins is here now
Rossen: fantasai please do the republishing and thank you.
CSS UI Implementor feedback on allowing pseudo-elements on form
controls when appearance:none
=====================================================================
TabAtkins: The issue is about standardizing the use of
::before/after on form controls. This is possible on
webkit and blink today.
TabAtkins: In general if you do ::before/after you'll get
something useful. Typically you do appearance:none to
wipe out the checkbox and use this to create cool
styles. However these are not interoperable.
TabAtkins: I know in general inputs are semi-replaced. I don't
want to change that in general because figuring out
what's in an input across platform is hard. We think we
could handle just when there's appearance:none which
makes it an empty <div>. We can say ::before/after work
there. If we can spec this we can get interoperability.
dbaron: In Chromium, does saying appearance:none on a check box
makes it an inline block? Because I don't think that's
Gecko, but we could do that.
Florian: I think to the extend we can make appearance:none
non-replaced I'm in favor. I'm not entirely sure we can
make all types of things non-replaced. Do we go through
every form element and decide if it can become a <div>?
TabAtkins: This list isn't very long. I'm happy to go through what
we can do. Checkboxes and radio are on the list. If we
can figure out how to make appearance:none work in a
way that matches what we do we should do that
Rossen: Does making appearance:none take the check box out of the
form control? Like that's not a check box?
TabAtkins: It is still a checkbox for a11y purposes and whatnot.
It removes the appearance.
Rossen: So it's a checkbox but doesn't look like one.
TabAtkins: Yeah.
Florian: It's appearance not behavior.
Florian: The way I specced it everything that only pertains to
appearance has to be removed, but behavior must stay.
That's fairly easy for checkbox because behavior is only
DOM. Something like a dropdown calender still needs to
look special when you interact. It can't be entirely
flattened.
Florian: Out of these, do some need to be replaced? If can say
everything is flatted with appearance:none that's great,
but if there's an exception we need to know.
TabAtkins: I'm saying radio and checkbox now because they're
simple. Look through the rest later.
Rossen: On our end I'd need to take a bit more time to see what it
means.
ACTION Rossen review appearance:none and ::before/after email
Florian: What you suggested sounds great. You wanting to start a
new doc, I'm not sure why you'd need separate section.
TabAtkins: Not a separate spec, just a doc to be able to drop in.
TabAtkins: dbaron did you have implementation concerns?
dbaron: If this is compatible with what Chromium does I'm okay.
There may be some questions on appearance vs. webkit-
appearance.
TabAtkins: So how about I do a proposal for next week. In the mean
time, Rossen explores the basic idea. Then we discuss
next week.
<bradk> How about ::before and ::after on images?
* Bert is with bradk: wants them on images, too. (But realizes
this will be a difficult to define...)
smfr: bradk mentioned something on images. You can use the style
not on broken images. We need a general review on
::before/after on replaced.
TabAtkins: A broken image isn't quite defined if it's replaced or
not.
fantasai: It is defined in HTML spec and it's not replaced.
TabAtkins: Form elements are never strictly defined to be replaced.
We don't define what's inside of them in any meaningful
way.
<astearns> form elements are explicitly defined as non-replaced,
in that they're in the non-replaced elements section in
the html spec
Florian: dbaron while you think on this you may want to ring Boris
because I know he's mentioned this on WHATWG.
TabAtkins: He suggested what I'm suggesting.
Florian: In the discussion about appearance:none
TabAtkins: We looked to see if we could remove our code, the usage
is too high so we can't. He suggested appearance:none
as the key to keep.
<Florian> https://github.com/whatwg/compat/issues/6#issuecomment-188081087
Florian: He suggested that with appearance:none some things will
need to stay.
Florian: Take that as a part of your homework.
Rossen: So TabAtkins will write his explainer document for
checkbox and radio and we'll see if we can generalize more
to other elements.
CSS Values
==========
Nesting calc() and serialization
--------------------------------
<Rossen> https://lists.w3.org/Archives/Public/www-style/2016Mar/0042.html
TabAtkins: This set of topics are in CR so we need approval of
changes.
fantasai: The last one doesn't have clear conclusion.
TabAtkins: This is calc() and nesting. It was always intended that
calc() be nestable. Any items inside a calc(). We
intended the addr function for example. This is
required to make variables work more easily.
TabAtkins: The way I defined calc() technically only allows
literals inside itself. I fixed this up and made sure
calc() was written in generic concepts not literal.
fantasai: I want to double check the edits for unintended effects.
We need the group to agree calc() can be nested and that
the inner calc() serializes out as parentheses. Does
that sound good, bad, need more time?
TabAtkins: Nesting calc() is the same as putting parentheses
around things.
fremy: In 2012 I wrote tests in the values test suite on this.
It's in the test suite so I'm in favor of supporting the
change.
<fantasai> ACTION: fantasai review wording changes for nesting
calc() to avoid unintended changes.
<trackbot> Created ACTION-760
TabAtkins: Objections to making calc() nestable in the spec?
Rossen: Does anyone allow nested calc()?
<bradk> No objection from me.
TabAtkins: I don't remember if we do, but the way implementations
handle calc() is ad hoc. It wouldn't surprise me.
Rossen: I think we don't allow nesting. So this will be at least a
functional change.
Rossen: I'm curious what that means for other implementors.
TabAtkins: It's a functional change in so far as if you accept the
format. It's not new behaviors, just syntax.
Rossen: I'm just curious if someone supports this.
TabAtkins: Don't know. I'm not pegging this on a compat bug.
TabAtkins: You care about compat when it matters for page support,
not for every single detail of an implementation.
Rossen: In the context of calc() as long as it become equivalent
of parentheses we should be fine. We don't support it now,
certainly.
TabAtkins: Do you object to the spec change?
Rossen: No.
<Bert> (I'm fine with nested calc, no opinion on how it
serializes, other than that it does, somehow. :-))
<dbaron> I don't think we should look at introducing new features
as a compatibility issue unless there's an actual
compatibility problem we know about.
TabAtkins: If no one else objects we can resolve.
fantasai: There's 2 points.
TabAtkins: They're independent. Does anyone object to allowing
calc() to be nested?
Rossen: Are there restrictions to level of nesting?
TabAtkins: No. They're just like parentheses.
Rossen: Okay, any objections, time requests?
RESOLVED: Allow calc() to be nested.
Rossen: I'm assuming you'll make the change?
TabAtkins: Yeah.
Clamping calc() values, serialization thereof
---------------------------------------------
<Rossen> https://lists.w3.org/Archives/Public/www-style/2016Feb/0160.html
TabAtkins: So do we need nested calc(), or treat them as
parentheses and serialize as such. I don't care either
way, but we need to decide. If the WG wants to keep the
exact form we can go with that.
Rossen: Feedback? Comments?
Rossen: glazou is up.
Rossen: We have to read IRC as he types.
<glazou> the question is: will web authors understand they have
nested calc() when there's only ()
<glazou> in a serialization
<glazou> and what's impact on OM
TabAtkins: [reads first question] I don't understand.
<glazou> calc(... ())
Rossen: He's asking if you serialize back only parentheses when
calc() was nested, would there be loss where people
wouldn't know if this was calc() or parentheses and would
that matter.
<glazou> what Rossen said
TabAtkins: Doesn't matter anyway because they're equivalent.
<glazou> no that matters in OM
Rossen: They're logically equivalent but for editors they may not
be.
<glazou> you have to know to be able to tweak it programmatically
if you need
fremy: I don't see why someone would write calc() inside calc().
The only reason we allow this is to allow variables in a
calc(). I don't expect impact on authors.
Rossen: This would also impact tools. Tools can add nested calcs
and they may expect it to be serialized back.
<glazou> right
<TabAtkins> Yeah, important case is "--foo: calc(1px + 2em); --
bar: calc(var(--foo) + 10vw);"
<TabAtkins> If calcs cant' be nested, you have to do some clumsy
stuff instead.
Florian: The general tooling argument about preserving more syntax
is better because you get more author intent. In general
I agree. In this case there isn't different author intent.
The only case where you want calc() to nest is when
variables do it for you. It's not something you'd want to
preserve.
* glazou agrees that computations have to be nestable
TabAtkins: I don't see when you would have a compound expression
where you'd put a calc() in purpose. You may have a
compound made of a bunch of calcs and you would
serialize that out.
<glazou> would prefer a model where what's inside calc( and ) can
be more complex than a single operation and still be a
single calc()
<glazou> but of course we had that discussion several times in the
past
<TabAtkins> glazou: Yes, that's already allowed. Again, nesting
calc() offers *no new functionality whatsoever*.
<smfr> do we need () for precedence? calc(A * (B + C))
<TabAtkins> smfr: Yeah, parens already exist, for that purpose
exactly.
Rossen: I would suggest keeping the PoV where an editor has a
button that adds a calc() button and you can do it as many
times as you want. It's a valid test case.
Florian: I think what we're saying is if you're nesting it's
preferable to use parentheses. Writing extra code to
support sub-optimal usage isn't good. If we can come up
with a use case where you're gaining anything, that's
fine. It's worth dropping information to avoid a noisy
stylesheet.
fantasai: This is about as significant as to if you used tab or
spaces for indentation. At some level you'll care, but
for the APIs in the CSSOM it doesn't matter any more.
Florian: Since our OM doesn't fully preserve, we're not at that
level.
<Florian> sorry Daniel, I'm usually on the same side as you on
these questions, but this time it feels the other way is
better.
<glazou> Florian np
<Florian> but I can still see where you're coming from.
<glazou> I am trying to help understanding better the request,
that still seems obscure to me for potential harm for
editors
Rossen: It sounds like there's not a lot of push back on the call.
The person trying to object is glazou. glazou will you
need more time or are you okay resolving to drop calc() on
parentheses.
<glazou> no I am not objecting
Rossen: And while we wait, should we postpone the next topic?
TabAtkins: Next one maybe.
fantasai: When you're serializing the computed value of calc, yeah.
Rossen: So glazou doesn't object to dropping calc() from nested
calc() and leaving it as parentheses. Anyone object?
RESOLVED: Drop calc() from nested calc() and serialize it as
parentheses.
calc() simplification for serializing specified values
------------------------------------------------------
<Rossen> https://lists.w3.org/Archives/Public/www-style/2016Feb/0160.html
fantasai: So it's if we perform clamping because serialization.
<TabAtkins> calc(10px - 1em) <== positive? negative? can't tell at
parse time.
fantasai: So in the past if you have -5 in calc() we'd drop at
parse. We can't do that. So if we're serializing, do we
perform clamping and than serialize it out.
TabAtkins: It's not if we should, it's I spec it and it needs to
be checked for correct. We can't tell if calc() is +
or -. If it resolves outside the range we clamp. But
there's also a rule that we unwrap the calc() if it's a
single value at certain stages. We have to clamp or it
doesn't round trip. I wrote the rules, we need approval
on those changes.
<dbaron> I'd like more than 30 seconds to review this issue...
Florian: And the rest was discussed years ago?
TabAtkins: Yes, the existence of clamping was decided years ago
fantasai: We spec it does, but not what stage.
TabAtkins: And because the unwrapping we have to say how and when
it happens. We clamp as soon as possible at computed
value time. If you unwrap you pop out the clamped value.
<fantasai> https://drafts.csswg.org/css-values-3/#calc-serialize
fantasai: Here's the section. The two things to pay attention to
are clamping and how do we manage the simplification of
calc() for serializing.
fantasai: Those are the issues, they're in the DoC.
<fantasai> clamping issue
https://drafts.csswg.org/css-values-3/issues-cr-2015#issue-11
<fantasai> simplification issue
https://drafts.csswg.org/css-values-3/issues-cr-2015#issue-17
Rossen: In interest of time, let's go to the ML. If we can't
resolve there we will do this next week.
Rossen: Remember next week we'll still be one hour earlier.
Rossen: Thanks and we'll chat next week.
Received on Wednesday, 16 March 2016 23:46:57 UTC