- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 12 Apr 2017 20:32:32 -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-ing
------------
- There is a goal to take Writing Modes to PR at the F2F next
week, so anyone with interest was asked to review the DoC
(https://drafts.csswg.org/css-writing-modes-3/issues-cr-2015)
& Implementation Report
(https://drafts.csswg.org/css-writing-modes-3/implementation-report.html)
in advance of the meeting.
- Some of the changes were made to the Fonts 3 test font, the rest
will be made soon.
- The SVG breakout call made it through most of the Transforms
topics that needed SVG input.
Partial implementations of space-evenly in grid but not flexbox
---------------------------------------------------------------
- Discussion on what's the right approach and what is too hard for
implementors will happen at the F2F.
How to NOT justify a piece of text inside a justified paragraph?
----------------------------------------------------------------
- RESOLVED: Allow text-justify:none to apply to inlines.
Ambiguities with 0 valid for all dimensions
-------------------------------------------
- RESOLVED: Only spec the unitless 0 quirk for transforms &
gradients.
Define which subresources block the DOM load event
--------------------------------------------------
- RESOLVED: Add proposed DOM load events to Values & Units.
Figure out the interaction between line-height-step and the lh and
rlh units
------------------------------------------------------------------
- The proposed solution is lh includes calculation of
line-height-step and if lh is used in line-height-step
property, it refers to unadjusted line-height property.
- The group will resolve once the formal spec text is available.
Alignment Issues
----------------
- RESOLVED: Push fallback alignments to L4.
- RESOLVED: Safe & unsafe keywords ordered before alignment
keywords.
- RESOLVED: Drop justify-content: baseline.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Apr/0026.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
Tantek Çelik
Benjamin De Cock
Dave Cramer
Alex Critchfield
Elika Etemad
Dael Jackson
Myles Maxfield
Michael Miller
Melanie Richards
Florian Rivoal
Jen Simmons
Alan Stearns
Lea Verou
Steve Zilles
Regrets:
David Baron
Bert Bos
Daniel Glazman
Tony Graham
Anton Prowse
Scribe: dael
Agenda Setting
==============
Rossen: Let's get going!
Rossen: Any additional things to add to the agenda?
fantasai: Probably the alignment issues.
Rossen: What about?
fantasai: I think I sent an email yesterday.
Rossen: [looking]
<fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2017AprJun/0019.html
Rossen: Is that the query at the bottom of the email?
fantasai: There's the 3 need input ones.
<Rossen> https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-align-3
Rossen: The three I pasted ^.
Rossen: That's great. If we're going to start changing tags
anything that needs agenda+ should have that. Needs input
sounds to me like a please respond.
fantasai: Sure. I think at least one was deferred from earlier
discussion.
Rossen: Sure. It's just easier to only track agenda+. Do they need
to be today?
fantasai: Nope.
Rossen: Anything else?
Rossen: Quick reminder, we have F2F next week. Please add agenda
topics. Safe travels.
Spec REC-ing
============
Rossen: Writing modes impl report...Is koji on?
koji: Yes.
Rossen: How are we doing with the impl report?
koji: I think it's done from my POV. I'm wondering if anyone can
give feedback and if there's any other work needed to move
to PR.
koji: astearns sent we need a DoC and I think it's done.
koji: Advice on what to do next is appreciated.
Florian: koji can you send links so I'm reviewing the right thing?
<koji> https://drafts.csswg.org/css-writing-modes-3/implementation-report.html
<koji> https://drafts.csswg.org/css-writing-modes-3/issues-cr-2015
koji: Implementation report & DoC^
Florian: I would like to review, but haven't had time. Should we
resolve to go to PR if everything is good next week?
Rossen: That would be great. Would there be enough people to
review until then?
<astearns> I will review the doc, have already looked at the
implementation report
Florian: We can pre-review until then. Going through this during
the meeting with review ahead if possible.
Rossen: If everyone interested in Writing Modes could take a look
at both docs before the meeting it would be great. We'll
try and go to PR during the meeting. Thanks koji for
taking the time to do these.
Rossen: Fonts L3
Rossen: ChrisL and Myles I believe the font issue is addressed.
myles: There were two issues. One is broken on some platforms, one
is that it didn't support everything Chris wanted to test.
I fixed the first, not the second.
Rossen: So we have a way to do some set of tests and ChrisL is
asking for more features. Are you planning on adding those
soon?
myles: Probably on the plane to Tokyo.
Rossen: Oh, that would be great.
Rossen: Do you know with the fixed font what percentage of the
tests pass?
myles: I don't.
Rossen: Okay, thanks for helping.
Rossen: Cascade L3 we had some test start to be added by
gregwhitworth.
Rossen: We did discuss last week Mozilla will look for somebody to
try and locate tests. Just a ping to Mozilla folks did you
find someone? Or should we postpone until F2F?
<tantek> postpone
Rossen: Okay, waiting. Conditional rules is the same, it's on the
agenda.
Rossen: smfr was supposed to look at V&U edits. I believe that's
wait for F2F.
Rossen: Backgrounds & borders- did we make any progress on further
evaluation on what was failing before?
Rossen: I'll take that as he is not on call.
Rossen: Transforms L1.
Rossen: We did have the SVG call last week and we resolved on a
few issues.
Rossen: fantasai correct me, but I think we made it through almost
all pending transform L1 issues.
fantasai: We focused on the ones impacting SVG.
Rossen: Right, I'm saying the ones that needed their input.
fantasai: Right.
fantasai: Rossen we're at 15 minutes, we're just at status
reporting too. Maybe we should do this by email or at
least figure out who is not here or figure out what's
not done before.
fantasai: If you want every week for me to give you a list of
specs I haven't worked on I can do that every week.
Rossen: Why would that apply to you.
fantasai: Because I don't feel we're making any progress.
Rossen: Let's table this until F2F and have it there. Will that
work for you?
fantasai: Yes.
<tantek> can we timebox status updates to first 5 min of call? and
start at 9:00?
<tantek> (modest proposal :) )
Rossen: Did we republish Flexbox?
fantasai: It has open issues.
fantasai: Grid is waiting for Mats to say if he's okay on an issue
and we're blocked on publication.
Partial implementations of space-evenly in grid but not flexbox
===============================================================
<Rossen> https://github.com/w3c/csswg-drafts/issues/1167
Florian: CSS align adds a bunch of values that apply in multiple
layout modes. The guidelines to impl is the same where we
say don't ship until you impl everything. Because it's in
a bunch of layout modes that didn't happen. Space-evenly
is impl only for Grid in some browsers.
Florian: If you try to use @supports to detect it fails because
it's implemented, but not in flexbox. Do we intend people
should hold off until implementing in all layout modes?
If no, what do we intend? What's happening right now
seems not great. I want to give some advice on what
should be done.
Rossen: I see fantasai did a PR with some edits.
Florian: I had not seen that.
Rossen: I wonder if that's enough to address the issue.
Florian: [reads through github]
Rossen: fantasai is there anything else you want to add?
<fantasai> no
<fantasai> I have nothing to add
Florian: I'm not sure I understand the edit.
Florian: Can you explain the intention, fantasai?
fantasai: Let's discuss during the F2F then.
Florian: Quickly, are current implementations doing the right
thing?
fantasai: Some aren't.
Florian: Sure. We can take it next week.
fantasai: Somebody impl a keyword for align-content in grid that
means nothing in flexbox. If you do align-content in
flexbox you must impl all keywords to claim support. The
keyword has to be impl across all layout modules for
which the impl claims support.
Florian: We'll need impl feedback.
fantasai: I think they're unwilling to do all at once. So not grid
and flexbox and abspos and multicol etc. at the same
time. That's fine. Don't support start and center and
not end on multicol. If you're going to support the
property you don't have to do it on every layout mode,
but you have to support all the keywords.
Florian: I think that's what the Chromium folks were saying was
too hard.
fantasai: I don't see why that would be too much. Once you have it
the keywords are easy.
Florian: So this needs to be between you, me, and someone from
Chrome.
Roosen: Next is "Define interaction of display:contents and
replaced elements"
Rossen: Seems like this is push to F2F.
Rossen: Unless fantasai or anyone wants to add something I suggest
we move on.
Rossen "Should anonymous boxes always inherit through the box
tree?"
fantasai: I think this would benefit from dbaron and boris input.
Rossen: Anyone else want to discuss?
<tantek> I think that's a good one to save for f2f
<tantek> since it usually helps to have diagrams for anything with
anon boxes
How to NOT justify a piece of text inside a justified paragraph?
================================================================
fantasai: That use case is handled by text-justify and using value
none. Currently that's the block containers and
optionally inline. We could solve by applying to inlines
in general, but is that something people can make sense
out of? Would impl be willing to support?
Rossen: So you're saying I could have a span with text-align:
justify and the text in that span will span?
fantasai: text-justify: none to the span and text-align: justify
to the <p>
fantasai: I'm willing to give this a go. If there's a combo of
values that makes no sense that can be undefined.
Rossen: So intended behavior is that the basic layout of the
current segment that sits outside the inline is not
considered for justification for the rest of the segments?
fantasai: You have a line of text with 5 segments, each with a
different justification. Those five segments will behave
differently depending on their justification property.
fantasai: The issue is it's unclear with all these options on one
line, how do you prioritize? That's the reason why I
wasn't sure. Certainly the none is straight forward. The
issue comes up when you have more specific instructions.
Rossen: So from implementor POV it doesn't seem crazy. What are
the use cases for having the behaviors?
fantasai: If you want something to not justify none is useful.
Another is you might want inter-character justification
within a long phrase of quoted English. I don't know.
dauwhe: I want this.
dauwhe: To suppress justification in certain spans this would be
useful.
<jensimmons> +1
fantasai: Then I propose we add it and people can add issues if
necessary.
Rossen: Any objections to allowing text-justify:none to apply to
inlines?
RESOLVED: allow text-justify:none to apply to inlines
Ambiguities with 0 valid for all dimensions
===========================================
Rossen: We don't have TabAtkins.
TabAtkins: I am on.
TabAtkins: A while back in a meeting I missed we decided to allow
unitless 0 for all angles because there were places
where impl allowed it. I don't think we did for all
dimensions.
fantasai: Correct.
TabAtkins: Even just on length vs angle it causes grammar
ambiguity in motion where the shorthand can combine a
length and angle. In general this will become a
problem. Unitless 0 are a legacy mistake. This will
cause footguns in the future. I would like to revisit
the decision and make it unitless 0 angles in the
functions that allow them as a legacy thing and then
restrict to just lengths in grammars.
<fremy> I think that makes sense
Florian: Since you're revisiting, do you recall the arguments for
generalization?
TabAtkins: Basically, the places are the common places where angle
is used. It was a harmonization effort. Reasonable
argument in general, but I believe in this case it's
not worth the effort.
Rossen: I also vaguely remember when we discussed...I can't find
the minutes to recall...
fantasai: It was Sydney I believe.
TabAtkins: In the thread posted on 3/13/16 called minutes...part 1
web compat challenges
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016Mar/0205.html
Rossen: Sooo, okay. I'm assuming you took those...are you now
proposing to change the resolution?
TabAtkins: Yes. Given now that I have evidence it's causing syntax
ambiguous in a spec and will likely continue to do so
in other specs. I would like to avoid this footgun of
ambiguous token types.
Rossen: Other opinions?
TabAtkins: From the summary there were three options. 1) file bugs
to fix the code, 2) spec the quirk for transforms &
gradients, 3) allow for all. I think 2 is the way to go.
<fantasai> would like to hear from implementors, esp dbaron &
smfr, but otherwise has no objection
<Florian> sounds sane to me.
Rossen: Who is editing?
TabAtkins: Me or leaverou
Rossen: Okay.
Rossen: So you're calling to change the resolution to only have
the quirk for transforms & gradients and TabAtkins or
leaverou can make the edits.
Rossen: Objections?
RESOLVED: Only spec the unitless 0 quirk for transforms &
gradients.
<leaverou> is there a Github issue for this?
<fantasai> https://github.com/w3c/csswg-drafts/issues/1162
Define which subresources block the DOM load event
==================================================
<Rossen> https://github.com/w3c/csswg-drafts/issues/1088
TabAtkins: This is a good question.
* fantasai votes for CSSOM :p
TabAtkins: I suspect...probably in the definition of URL in V&U.
It's not great.
gsnedders: That doesn't work for @import.
TabAtkins: That's fine because url type is string or URL function
fantasai: That's not true.
TabAtkins: The generic <url> is not, but it's defined it can be
strings.
fantasai: It's noted that in some places it can be but those
places have to define.
TabAtkins: Which import does.
TabAtkins: So if we'll define it probably V&U. Other choice is
distributing it everywhere, but we would need concepts
to link to. I don't have a strong opinion.
gsnedders: Some will depend on if everything has same behavior.
TabAtkins: It's fine to have a list of different behaviors.
Rossen: Does a separate module make sense?
fantasai: I think I agree with TabAtkins. I think we should define
there for properties and then the @rules should define
for themselves what they do. It would be weird if
backgrounds is different than counter styles.
Rossen: Okay. So let's start in V&U
Florian: I'm wondering about this all properties should behave the
same is a correct assertion.
TabAtkins: We didn't assert that.
Florian: Then it's good.
Rossen: Obj to adding proposed DOM load events to V&U?
RESOLVED: add proposed DOM load events to V&U
Figure out the interaction between line-height-step and the lh and
rlh units
==================================================================
Florian: We have lh and rlh unit and we have line-height-step
property. The later should influence the formers.
Florian: So the lh is eq to the value of line-height property. If
there's line-height-step it steps up the size so lh and
rlh should step up.
fantasai: I think it makes sense. It needs special behavior on
line-height, but we need this. It's fairly
straight-forward and can be computed value
Florian: If the line height in reality is stepped up you want the
lh to be doing the same or otherwise it will not be
matching.
myles: If you make it work like em it's good.
fantasai: It's similar. Slightly more complex, but the same
principle.
Florian: If we do that the only question is how to we break the
cycle when we us lh in line-height-step. You do value on
parent for pre-adjust value
fantasai: Value before adjusting. Parent doesn't make sense. It's
weird.
Florian: I can sort of imagine both, but I prefer the same.
Florian: Other direction is I want my line step height to be 2lh.
That doesn't sound insane.
fantasai: Then why aren't you adjusting the lh property. Your
target line height is 10px, but you're setting
line-height-step to 20px...that's weird.
<tantek> leaning towards what fantasai is saying, I'd need to see
the use-case that would need line-step-height to be 2lh.
Florian: Fair enough. I say same as you.
Florian: Is koji still around?
Florian: Are you okay with this?
koji: I think so. I'm not sure I fully understand.
koji: Do you think that only for line-height and line-height-step...
I guess it's helpful to write a proposal.
<fantasai> proposal is lh includes calculation of line-height-step
<fantasai> and if lh is used in line-height-step property, it
refers to unadjusted line-height property
Florian: All fonts related units need some exceptions. Other then
that there's nothing special.
koji: If it's like em I'm probably fine.
Florian: Concept is the same. Details will need tweaks.
koji: I think it's fine until there's more details to discuss.
Florian: I feel good enough to leave it to editors, but if you
want a PR first that's fine.
koji: Okay. That's good.
Rossen: Who will have the proposed text?
fantasai: TabAtkins or I will fix it.
Florian: Alright. If I find time I can make the PR.
Rossen: Resolve now or after koji reviews?
fantasai: Up to koji.
koji: Whichever is fine.
Rossen: Let's resolve on this one.
Rossen: I mean when we have proposed text.
Rossen: We have the 3 CSS alignment issues fantasai pointed out.
Do you have an order?
CSS Alignment issues
====================
Allowing fallback alignments without breaking shorthands
--------------------------------------------------------
<fantasai> https://github.com/w3c/csswg-drafts/issues/1002
fantasai: First is the issue on allowing fallback alignment.
fantasai: We have several types like space-between which don't
make sense unless you have more than one item.
fantasai: Since they have syntax for fallback it has been
problematic. We've had proposals, but TabAtkins and I
were thinking let's drop for this level and reduce the
number of stuff in the spec. No fallback alignments for
now, we'll add them fairly quickly in L4.
fremy: Did we not resolve on that last time?
fantasai: Let me see.
Rossen: If we did, I don't believe it was under that issue.
[minutes searching]
fremy: I'm fine with re-resolving.
Rossen: Let's assume we didn't.
Rossen: Any other comments?
Rossen: TabAtkins I see you commented where you proposed commas to
separate fallback.
TabAtkins: Yeah, but I'd rather drop for now. We can always
address it in the future.
TabAtkins: Push to level 4. My suggestion was compatible with drop
for now.
Rossen: Let's push it to level 4. Objections?
RESOLVED: Push fallback alignments to L4.
Fix order of `unsafe`/`safe` keyword wrt alignment keyword?
-----------------------------------------------------------
<fantasai> https://github.com/w3c/csswg-drafts/issues/1001
Rossen: Unsafe/safe keywords
fantasai: They can be either order, but introduced an ambiguity
when we did shorthands. To resolve the ambiguity we
propose to fix the order and require safe or unsafe to
be before the alignment it modifies.
fantasai: Alternate proposals are welcome.
Rossen: Any alternate proposals?
Rossen: Proposal doesn't sound crazy. From an implementor PoV it's
straight forward to handle.
Rossen: I don't see a big reason why not to go with the proposed
ordering.
Rossen: Any comments?
RESOLVED: safe & unsafe keywords ordered before alignment keywords.
Rossen: Last is about last baseline alignment for scrollable boxes.
fantasai: This is a longer discussion. We might want that at the
F2F. I'll push this to that agenda.
Rossen: Yeah, this needs a whiteboard.
Drop justify-content: <baseline-position>
-----------------------------------------
<fantasai> https://github.com/w3c/csswg-drafts/issues/1184
fantasai: There's a quick one. I realized we have values that
don't do anything.
fantasai: Assuming that's correct I'd like to drop them.
Rossen: I thought we resolved in the past. We were discussing in
grid and later resolved on conference calls to drop.
fantasai: We dropped the concept. The writing mode will always be
fixed for align and justify content so justify-self will
have baseline, but justify-content will never apply
afaict.
fantasai: I think that's how it works. If anyone has a case I'd be
happy to reconsider, but I just noticed that.
Rossen: Makes sense to me.
<astearns> makes sense to me
<Florian> I cannot think of a case where it would apply
Rossen: I see general consensus around dropping it. Objections to
dropping justify-content: baseline since it only applies
in block axis?
RESOLVED: Drop justify-content: baseline
Rossen: And that's the end of those issue and the top of the hour.
TabAtkins: Can we try and do my topic that fill & stroke should be
L3?
fantasai: We resolved that.
fantasai: I'll get you the minutes.
Rossen: Yeah, and fantasai asked plh for the short name change.
<fantasai> https://lists.w3.org/Archives/Public/www-style/2017Mar/0088.html
<fantasai> minutes^
TabAtkins: Okay. Cool. Alright.
Rossen: Thanks everyone for calling.
Rossen: Safe travels to those flying to Tokyo!
Received on Thursday, 13 April 2017 00:33:38 UTC