- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 28 Jun 2017 20:25:33 -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.
=========================================
Spec Rec next steps
-------------------
- Rossen will confirm if Writing Modes needs a CR publication
before the PR request.
- Variables needs to republished after the tests are approved.
Propose to make "disc" not overridable
--------------------------------------
- RESOLVED: make "disc" not overridable.
Naming of inset-* properties prefix
-----------------------------------
- RESOLVED: adopt inset as the new positioning property name
that's used for shorthand.
- fremy will create a poll with a description and diagrams to
evaluate if this name is preferable over some of the other top
options.
Should 'place-items' accept 'legacy' values?
--------------------------------------------
- RESOLVED: leave behavior as-is and not accept 'legacy' values
for 'place-items'.
Are there compatibility issues with replacing overconstraint rules
from CSS2
------------------------------------------------------------------
- RESOLVED: Accept the proposal that margin and position
properties will return the specified values.
Don't introduce baseline alignment to table columns
---------------------------------------------------
- RESOLVED: The baseline alignment in block direction of tables is
not defined. Also add a note prompting implementors to
bring back ideas if they have any.
Should 'left' and 'right' really both fall back to 'start?
----------------------------------------------------------
- RESOLVED: Leave the left and right values to fallback to start.
- RESOLVED: Remove 'left' and 'right' from align-self and
align-content in align L3.
Reconsider name of frames() timing function
-------------------------------------------
- birtles gave a brief introduction to the topic in hopes of
getting more discussion in the github issue
(https://github.com/w3c/csswg-drafts/issues/1301) before next
week's call.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Jun/0034.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Brian Birtles
Tantek Çelik
Dave Cramer
Alex Critchfield
Benjamin De Cock
Elika Etemad
Tony Graham
Dael Jackson
Brian Kardell
Brad Kemper
Chris Lilley
Peter Linss
Myles Maxfield
Rachel Nabors
François Remy
Melanie Richards
Alan Stearns
Lea Verou
Greg Whitworth
Regrets:
Bert Bos
Emil Eklund
Simon Fraser
Vlad Levantovsky
Anton Prowse
Florian Rivoal
Jen Simmons
Scribe: dael
Spec Rec next steps
-------------------
Rossen: Hello everyone! Any extra agenda items?
[silence]
Rossen: There were a few actions since last time. I was curious if
they materialized.
Rossen: fantasai, I was wondering if we made progress on Writing
Modes, Values & Units or UI.
fantasai: Values & Units has a DoC and I need to next fix the
changes list.
fantasai: Writing modes nothing this week.
Rossen: I see last week we had a question on CR or PR. I looked at
minutes and I believe we agreed PR.
fantasai: It was if process requires CR first because there were
substantive changes.
Rossen: Okay. I'll reconfirm with Chris or Bert. I recall it was
PR.
* fantasai wonders if tantek knows the answer to that question?
<tantek> fantasai just missed it
<fantasai> see above
<fantasai> writing modes to PR
<tantek> IIRC you can go direclty to PR (and request PR
transition) IF you have satisfied all the CR exit
criteria. I believe you still have to have the minimum CR
period during PR
<tantek> hopes that helps
<tantek> In fact I say go ahead and do that (if those conditions
are satisfied), and if you get push back from anyone, I
want to hear about it
<fantasai> tantek, ok, thanks!
<tantek> I prefer to push the limits of being efficient with the
Process, and find out where it breaks or blocks
<tantek> and then I can escalate to the AB
<tantek> (or anyone can escalate to the Process IG)
<tantek> (or both)
Rossen: And V&U was waiting on DoC.
Rossen: And the reviews to UI tests haven't been done, right?
Rossen: I'll take that as a yes
Rossen: gregwhitworth, Variables. Did we get progress on the tests
you needed reviewed?
gregwhitworth: Yeah, they're checked in.
Rossen: Is the next step republish?
gregwhitworth: I'm assuming that's a q for the editors.
Rossen: I think it's only TabAtkins.
TabAtkins: I'm happy to republish.
Rossen: I wonder...how many tests to we have for the ones you
submitted gregwhitworth.
gregwhitworth: I have to pull it up.
Rossen: Okay, we can move on. But it would be good to know so we
can move toward PR.
Rossen: Last was flexbox. Did you hear anything back from anyone
in regards to test coverage?
gregwhitworth: I sent last night the pulls outstanding. There's
one more outstanding. I haven't heard back and
since I didn't now how the process went I sent my
summary as to what I saw. Implementations are
interop in my opinion.
gregwhitworth: There will be 3 PRs and hopefully the editors can
look and pull those in. Christian B has been
waiting a month on intrinsic sizing.
Rossen: So TabAtkins myself and fantasai is who that's on. It
feels this spec should be close to done.
gregwhitworth: I have one more PR to do this week but once they're
accepted we're done.
Rossen: I'll resend the doc on spec updates and to dos. A few are
behind, but a lot are waiting on tests to be provided.
<fantasai> was that for flexbox? There are still bugs in flexbox
<gsnedders> yes
<fantasai> There's a lot of non-interop on auto-sized images in
Flexbox....
Rossen: We'll move on for now, please reply to the next email.
Propose to make "disc" not overridable
--------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1521
TabAtkins: It would be easier if disc was not overwritable so they
didn't have to load the counter styles. I don't see
anything wrong with this. I only have one
non-overwritable which is decimal. I need WG approval.
fantasai: Are we switching non overwritable from decimal to disc
or making both non-overwritable?
TabAtkins: Both
Rossen: Proposal is make both non overwritable?
TabAtkins: Make disc non-overwritable.
Rossen: Any other opinions?
fantasai: Now that disc is non-overwrite do we need decimal too?
TabAtkins: We do. Decimal being the ultimate fallback it's better
to see what you started with when you screw everything
up.
Rossen: fantasai is that good?
fantasai: I don't have an objection, I just wanted there to be a
reason.
Rossen: Objections to make "disc" not overridable?
RESOLVED: make "disc" not overridable
Rossen: TabAtkins please make the change
Naming of inset-* properties prefix
-----------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1519
fantasai: We needed to rename the logical equivalent of the
top/left/bottom/right properties and the shorthand for
them. We wanted that to be the prefix for the logical
properties. We were using offset as the word here.
fantasai: That conflicts with motion so proposal was rename the
offset properties. Top option is inset, but there's
other suggestions in the issue.
Rossen: I was just looking at the list and ~20 days ago was when
Sebastian posted results and then position-offset had the
most votes. You said that would collide with motion path?
fantasai: Offset would. Position-offset wouldn't, but
position-offset isn't a shorthand. It would be
position-offset-inline-start
fantasai: I think it's in author interest to stick to a shorter
prefix.
Rossen: inset is not supposed to be position-inset
fantasai: Yeah. inset: [value for top/left/bottom/right]. You'd
also have inset:inline-block. It would be like the
margin [missed] We also have inset:block
<astearns> might be better to type the syntax
Rossen: Any opinions?
<AmeliaBR> inset isn't great for relative position
<astearns> I like inset
fremy: I think inset is strange. For position relative there's
nothing to do with inset.
bradk: I like it because positive numbers go inwards from
reference box
Rossen: Not when you factor in logical
TabAtkins: Yes still. They always go inward.
fremy: It's not inset to anything for position: relative
fantasai: It's inset from its original position. Agree it is a
nice term because it reflects we're going inwards in a
positive direction.
fremy: I'm not convinced. If you look at the proposal list inset
isn't in it. I don't think it's clear to authors. I'm
surprised we asked for opinions on twitter and picking
something not offered.
fantasai: If we want to do this on twitter we need to put the
whole list and randomize. A lot of people took what came
to their head and posted it. If you want data we can do
that.
fremy: None of the proposals are inset. It wasn't included as an
option to think of. To me it's not intuitive. I wouldn't
think it has anything to do with top left bottom right. I
won't object, but we did a pole and no one came up with
inset.
fantasai: It is in the list. Several people in the WG
independently came up with that term: at the F2F
astearns did, bradk on a list, and me another time. In
twitter we can't give all the information for the
decision and people use this in a way that doesn't
reflect how it's going to be used in all the alignment
systems.
fantasai: People think about it how they position the top left
corner and that's not really the case, especially in
other writing modes. There's a lot going on that's not
just how I position this absolutely. There's a lot of
suggestions that are based on 2 axis abspos. We have to
consider all the layout modes.
fantasai: Blindly taking info from twitter isn't the right way. If
you want data we can post a poll so people can read and
understand what's going on.
fremy: My concern is that inset suggests that you can inset from a
place. If you're position relative I'm pretty sure you
can't take the four of them. If position relative doesn't
have a starting box I don't know how you use inset.
fremy: I don't understand how position relative is inset from
anything. The name doesn't seem intuitive to me.
bradk: For position relative you can set just right and bottom and
positive numbers are inwards from the bottom and right edge
Rossen: They're offset of the initial position.
bradk: Your bottom will move inwards from where the bottom was.
fremy: It's only changing position not size and inset suggests you
could do size.
TabAtkins: What are y'all talking about? Abspos is inward from the
containing block, relpos is inward from the element's
own bounds.
TabAtkins: It's not a point.
<AmeliaBR> The idea is that in position:relative, it would "Inset"
relative to the normal position of the box. But you
can't inset on opposite sides, because you're not
changing size of the box.
<AmeliaBR> ...but, that's confusing. "offset" was better for that
purpose, but that's unavailable now.
* TabAtkins suspects that either some people have forgotten how
relpos works, or are interpreting it in a way that's
functionally identical to what we're saying, but
phrasing it in a totally different way.
Rossen: There's a couple ways forward. If a WG member that is an
avid CSS user is confused chances are he's not alone. We
can adopt the inset as the current name and continue the
discussion. If there's enough people who would like more
votes on a short list we can limit the choices to the top
10 votes, include inset, randomize order, and in that way
we'll see if inset makes it.
Rossen: Given those choices, preference?
fremy: I'm fine inset for now and then make a poll.
Rossen: You wouldn't object to accept inset and continue the
discussion?
fremy: No.
Rossen: Any others that would object to adopting inset as the new
positioning property name that's used for shorthand?
RESOLVED: adopt inset as the new positioning property name that's
used for shorthand
ACTION fremy to create a poll to get more data on the inset name
fantasai: If we're positing a poll can it have all the relevant
background and diagrams.
fremy: Yes. I won't do this on my own.
Should 'place-items' accept 'legacy' values?
--------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1449
fantasai: I don't have an opinion, it's question of so we have the
shorthand for various legacy items of justify:items. It
takes 'legacy' as a keyword alone or in combo of other
values. Do we want it in the shorthand.
TabAtkins: I'm on the side of no. There's no real reason for
authors to specify that for themselves.
Rossen: The legacy one should be left for legacy.
dbaron: One of the tradeoffs is that it becomes harder to
serialize to the shorthand. You end up with cases where
you can't serialize the shorthand.
TabAtkins: I'm not sure. But only if you have the place-items
shorthand on a center element, I think. So...ehh.
<fantasai> Don't we already have other cases where there are
values that aren't possible to express in the shorthand?
Rossen: dbaron would you object if we didn't?
dbaron: I'm okay, I just wanted to bring that up
Rossen: I heard fantasai and dbaron being okay with...fantasai was
fine with either, dbaron would be okay if we stayed with
current version. 2 others voted stay with current. Other
opinions?
<fantasai> what's current?
Rossen: Objections to leaving behavior as-is and not accept legacy
values for place-items.
RESOLVED: leave behavior as-is and not accept 'legacy' values for
'place-items'.
Are there compatibility issues with replacing overconstraint rules
from CSS2
------------------------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1428
fantasai: What's going on is in the alignment spec we're saying we
no longer do the overconstraint rules in CSS 2. Those
are if you spec margin and padding and border and width
on both sides. It's specified in CSS2.1 that margin box
must fill containing block. If you specify all these
properties it won't fit likely. 2.1 says you take end
side margin and treat it as auto.
fantasai: In alignment we're saying don't do that. When the margin
box doesn't match the alignment dictates layout.
Observably there's no difference. We spec the initial to
be start alignment. dbaron pointed out we need to
investigate situation with object model. Do you get the
result of what was spec or what was used?
fantasai: TabAtkins ran tests, it's mostly like the align spec,
but there's no compat. We wanted to verify the group is
okay with this override.
<gregwhitworth> fantasai: I just added that Edge matches Chrome
TabAtkins: Chrome always returns specified value for margin right,
right or bottom. FF returns margin-right specified
value, but fixed for right and bottom. I couldn't test
other browsers at the time, but they're in the issue.
gregwhitworth: I added, we match Chrome.
TabAtkins: Great. Sounds like there was little matching 2.1. Let's
resolve to let align overrule.
Rossen: Okay, so let's match the spec to impl. Other opinions?
Rossen: Objections to proposal?
RESOLVED: Accept the proposal that margin and position properties
will return the specified values.
<TabAtkins> (Rather, not specified values, just *not* the result
of the overconstrained-equation.)
Don't introduce baseline alignment to table columns
---------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1422
Rossen: I think there was less compat on this.
fremy: dbaron mentioned in alignment spec there's a line that says
cell in a table sharing a column are in same alignment
group if there's in the alternate writing mode of the
table. Basically dbaron said it seemed difficult to impl
and I agree so he proposed to remove this from align spec.
fremy: It seems difficult to me to get the result, what dbaron
said seemed right to me. At this point there's no browser
that can handle vertical left right cells properly anyway
so I think we can go ahead and baseline align.
fremy: I agree with dbaron.
dbaron: I think one other analogy is the complexity is similar to
impl character alignment in tables. It's in substantially
higher demand and also not implemented. Seems like the
complexity is similar, but it would complicate things to
do both. I'd rather character alignment happens first
* tantek perks up and agrees with dbaron re: the complexity of
character alignment (and non-implementation thereof)
fantasai: I understand the priorities here. What if the spec said
MAY so if an impl wants to do this they can.
<dauwhe> +1 on priorities :)
Rossen: One thing to point out is we had a similar discussion when
working on grid for alignment of grid items and there we
had a strong vote to not baseline align on the minor/block
direction.
Rossen: Since baseline align is an inline concept trying to align
to those is fairly tricky. When you throw this into the
mix of all the sizing dependency I'd have to agree with
dbaron that making this work and work interop will be a
tall order.
Rossen: I would side on not requiring this as an impl.
myles: Everything you said is correct Rossen.
Rossen: fantasai you seem to have been the one wanting to try and
make this work. How strongly do you feel?
fantasai: If the main concern is impl complexity I think it makes
sense not to require. If there was an impl that decided
it was important for their use case like if they have a
lot of mixed writing modes then that impl should be
allowed to do that without violating spec. I want to
make this optional and we can make it clear we're not
expecting impl but they're allowed to
dbaron: You're saying make it optional but don't spec how it works
since how it works changes the table algorithm pretty
deeply.
Rossen: I was also going to ask about making it explicitly
non-defined rather than not allowing it would let the impl
come back to the table. Could we make a way for this to
work in all our frameworks. If we make it stronger it will
give impetus to those impl that are violating to come back
and say this is important and here is how it should work.
Rossen: fantasai would you agree or prefer it to be in spec and a
may?
fantasai: I suppose that's fine.
<fantasai> would put a note, then
<fantasai> "This may be added in a future level if there is
sufficient demand and implementer interest" ?
Rossen: Other opinions?
Rossen: Proposal: The baseline alignment in block direction of
tables is not defined.
RESOLVED: The baseline alignment in block direction of tables is
not defined. Also add a note prompting implementors to
bring back ideas if they have any.
Should 'left' and 'right' really both fall back to 'start?
----------------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1403
fantasai: dbaron pointed out that left and right fallback to start
if inline axis is not in the axis we're aligning in. The
spec could have been smarter on this, we have physical
and line-relative left and right. Between the 2 there's
an answer to what's left and what's right. There is a
case of a completely horizontal document and align-self
or align-content says left or right we don't have a way
of saying if top or bottom is left or right. Spec says
do start.
fantasai: dbaron says left for top and right for bottom. I'm of
the opinion this is error case and both should fall back
to start. It's fairly arbitrary.
fantasai: ?? commented that they would like to have no mapping.
That's more or less equivalent to start. There's some
differences.
<fantasai> e.g. whether or not to form a BFC
Rossen: Proposal is fall back to start. fantasai explained why she
believes this should be the case. Other opinions?
dbaron: My general concern was it seems strange to have things
called left and right that can end up on the same side.
dbaron: It seemed like the case where you're likely to hit this is
cjk where you author for vertical or horizontal and then
decide to change it.
Rossen: For floats left and right do we have similar?
fantasai: No because we use the line-relative left and right.
TabAtkins: I'll add that although you can come up with uses for
left and right they were impl for being able to do
legacy things. So it's okay for me if they're not great
in some corner cases.
<AmeliaBR> To be clear, we'd never have left falling back to right
and vice-versa. It is about left and right both falling
back to "top", correct?
<fantasai> yes
Rossen: True. Although all existing content is legacy
TabAtkins: No, I mean the legacy keyword.
Rossen: Got you
fantasai: It's more. There are occasions where you want the
physical direction.
TabAtkins: We added it to support legacy keywords. You can use it
other ways, but that was the original reason. We
wouldn't have had left and right if we weren't trying
to do legacy
Rossen: dbaron would you be okay if we resolved to fall back to
start?
fantasai: We also could remove the keywords from align-self and
align-content.
dbaron: I'm okay with it.
Rossen: What I hear is that we have generally seemed to be okay
with falling back to start which doesn't mean it's great
because you could have left and right map to the same
thing. fantasai points out we make be able to revisit
having these values.
fantasai: We needed them for justify-content and -self. They were
added...there were some cases where they would have
meaning in align, but they're not critical.
Rossen: I also think there are impl that are exposing those. Those
are being used...removing left and right would be harder
then fallack to start.
fantasai: I don't think so. Majority of people aren't using left
and right in a vertical axis. Unless you're using
vertical writing modes there is no left and right on
align-self and align-content because there is no left
and right.
Rossen: Perhaps.
Rossen: What if we try to resolve on the fallback and then
separately decide on keeping them. I'm not just trying to
kick that down the road, but I want to see usage.
Rossen: objections to: leave the left and right values to fallback
to start.
RESOLVED: Leave the left and right values to fallback to start.
<tantek> I thought dbaron's point was an obj
<tantek> no?
<dbaron> I'm not objecting... I just thought it should be the
other way.
fantasai: Would it make sense to resolve to drop them? We can add
them later.
fantasai: I can't imagine a case where this is a compat problem.
<tantek> fantasai: has a good point
<tantek> wiser to drop now, reconsider adding in the future
TabAtkins: Should be safe to re-add.
<tantek> +1 fantasai proposal
Rossen: I wouldn't be opposed. Let's make it a forcing function to
those that have impl.
Rossen: Obj to removing left and right from align tree?
<fantasai> This would be to drop left/right from align-self and
align-content
<fantasai> They would remain as part of justify-self and
justify-content
RESOLVED: Remove left and right from align-self and align-content
in align L3.
Reconsider name of frames() timing function
-------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1301
birtles: We introduced a new timing function where the difference
is it includes both endpoints. It has a different name
and different action so it counts number of steps. That
made sense from usability point of view though it's
different than step timing.
birtles: There's two complexities. The timing functions in other
content and other gradients which may need further
variations. I'm wondering if we should extend steps or
have something more familiar.
TabAtkins: We should continue this on issue.
Rossen: Thank you Brian for the introduction to it.
Rossen: Please jump to the GH issue and give your feedback there.
Rossen: Next Wednesday we'll resume with this.
Rossen: Thanks Brian and please everyone give your opinion on the
issue.
Rossen: That's it for today. Thanks for joining.
<astearns> for those who missed the aside - next week's call is at
the APAC-friendly time.
Received on Thursday, 29 June 2017 00:26:38 UTC