- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 29 Jun 2016 20:19:41 -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.
=========================================
What happens with grid line names when dropping tracks?
-------------------------------------------------------
- RESOLVED: Accept option C: keep the tracks in the track listing,
but force them to be zero-sized and suppress any
gutters between adjacent collapsed tracks.
Removing restrictions on baseline-aligning things that have block-axis
baselines (due to containing orthogonal content)
---------------------------------------------------------------------
- No one has had time to fully think through the best way to
address this problem, but fantasai, TabAtkins, Rossen,
rachelandrew, and Mats are interested in investigating.
- The first step is for fantasai to add more diagrams to the spec
and everyone else to review the baseline-aligning sections of
the spec.
Should we spec required prefixes directly in the relevant spec?
---------------------------------------------------------------
- RESOLVED: Link to the compat spec in the Snapshot and specs with
relevant entires and monitor for problems in the
future.
First and Last Baselines
------------------------
- There were five possible solutions to the combinatorial
explosion
1. Explode alignment-baseline.
2. Use last and baseline as separated keywords in align/
justify-self/content as well as alignment-baseline.
3. Use last-baseline in align/justify-self/content and last
baseline in alignment-baseline.
4. Introduce a new property to choose first vs last for
vertical-align, and have last-baseline decompose to last in
that property plus baseline for alignment-baseline.
5. Introduce first-baseline and last-baseline to
alignment-baseline(to match Align), but also allow first
and last space-separated prefixes for all values of
alignment-baseline(to avoid explosion). (This means that
both first-baseline and first baseline would be valid)
- The group rejected options 1 & 3 and fantasai will add some
examples to clarify the difference between the remaining
options.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Jun/0174.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Tantek Çelik
Dave Cramer
Elika Etemad
Tony Graham
Dael Jackson
Brian Kardell
Brad Kemper
Ian Kilpatrick
Chris Lilley
Peter Linss
Myles Maxfield
Anton Prowse
Liam Quin
Jen Simmons
Geoffrey Sneddon
Alan Stearns
Lea Verou
Greg Whitworth
Regrets:
Angelo Cano
Alex Critchfield
Simon Fraser
Daniel Glazman
Michael Miller
Florian Rivoal
Ian Vollick
Steve Zilles
Scribe: dael
What happens with grid line names when dropping tracks?
-------------------------------------------------------
astearns: Let's start.
astearns: Does anyone have anything aside from the agenda?
<astearns> https://github.com/w3c/csswg-drafts/issues/172
TabAtkins: We did get to that. I noted at the end it was accepted
at telcon.
Rossen: We had said we would discuss this week to give a chance to
review.
astearns: That's what I saw in the minutes.
TabAtkins: Okay.
Rossen: Should I summarize?
fantasai: We did last week, we were waiting on you.
Rossen: There were two options initially...dropping tracks
completely and dropping names as well or B was keeping the
line names though tracks are dropped.
Rossen: With those two options, B is preferable.
Rossen: And you said another option was keep the tracks but
resolve them to 0 width. Basically the empty tracks are
empty by size but there for referential integrity. I find
that weird, keeping all the stuff around having empty
tracks that are there for lines with names.
Rossen: Our preference is B.
fantasai: The reason we went with the 3rd wasn't just named lines.
It was also because when positioning abspos and using
names or numbers you want the references to be the same
column you're referencing if you hadn't dropped tracks.
Otherwise if positioning to 5th track in normal and then
use abspos they won't end up in same tracks.
fantasai: Layout-wise we're collapsing because auto-fit is to get
rid of the extra space, but we want to make sure the
abspos coordinates remain stable and identical. That's
why we're using C and I strongly believe that's the way
to go.
Rossen: I hear you and I see your preference. We would be able to
live with C. I wouldn't object. We'd prefer B. That's our
position.
astearns: So does that mean are going to live with C or is there
possibility other people's preferences can move to B?
* fantasai is not switching preferences, believes the abspos
coordinate thing is more significant than other
concerns mentioned so far
Rossen: Seems like the conversation died off. I don't know if
there's anything else we can add from our side. We can
proceed to unblock the spec with a call for comments or
quick straw poll. I don't mind that.
<rachelandrew> C makes more sense to me, thinking about using it
as an author.
astearns: Okay for fantasai?
fantasai: Yes.
astearns: Let's straw poll in IRC. If you prefer type B or C. No
need to abstain if no preference.
Straw poll results:
<TabAtkins> C
<fantasai> C
<rachelandrew> C
<gregwhitworth> B
<Rossen> B
<gsnedders> C, I think
<plinss> C
astearns: Alright. Smallest straw poll I've seen, but it's
slightly toward C. More commercial entities for C. Let's
go with C.
astearns: If that becomes a problem in the future, Rossen bring it
up again.
Rossen: It'll add implementation complexity, but like I said we
can live with it.
fantasai: Implementation-wise it's easy until gutters and than
it's complicated. You short circuit track sizing and say
it's 0. That's not hard.
Rossen: Let's leave it at that.
RESOLVED: Accept option C: keep the tracks in the track listing,
but force them to be zero-sized and suppress any gutters
between adjacent collapsed tracks.
Removing restrictions on baseline-aligning things that have block-axis
baselines (due to containing orthogonal content).
---------------------------------------------------------------------
fantasai: I'm still trying to wrap my head around this. Is anyone
else interested in looking into this so I know who to
ping?
<TabAtkins> Yeah, this needs fantasai and I to noodle over in a
workday, haven't gotten to it yet.
Rossen: We're interested.
astearns: You and TabAtkins and Mats.
fantasai: K.
<rachelandrew> I'd be happy to be involved
astearns: Is that a I'll look and put it on next week Rossen?
Rossen: I didn't say that. It was who else is interested and we'll
have to see later. I'm not sure why you inferred to next
week.
astearns: If you want to talk now please do.
<astearns> https://github.com/w3c/csswg-drafts/issues/161
<astearns> https://github.com/w3c/csswg-drafts/issues/197
fantasai: Basically what things have baselines and what axes. Are
the baselines synthesized and what's real. I don't have
a clear explanation yet. But if the people interested
want to review baseline alignment sections of align spec
that's great.
Rossen: Would this go into grid or alignment?
fantasai: I'm not 100% sure. Grid has text explaining grid
container baselines. That may or may not need changing
depending on the issues. I don't know because I don't
know what the changes are. Some interesting cases are
there's 3 items on the line 2 with vertical writing mode
and 1 with horizontal writing mode text, who gets
aligned where?
fantasai: What if you put a grid in some inline content, what
happens with the line. I have questions, but no answers.
Rossen: When you have items with mixed writing mode directions I
don't see why it's different than if they're inline
blocks. That's how we treat them.
Rossen: For the next issues where the grid participates in
multiple directions as long as the two main baselines of
the grid are defined I don't anticipate any issues unless
I'm missing something.
<TabAtkins> Yeah, let's discuss this further offline - it's got
some subtleties that aren't easy to see immediately.
fantasai: I think the current Flexbox spec says if You have a flex
line and 2 horizontal text and 1 vertical text the
vertical text is just start aligned. So with your
interpretation we need to change Flexbox. I don't know
if that's a good idea.
Rossen: Riiight...um.
fantasai: That's not a likely case interop-wise so I don't think
there's a compat problem. But if we need to make this
change do we want to.
Rossen: We'll have compat problems soon if we don't define.
fantasai: It's defined, but your expectation and spec don't match.
Rossen: I think what you said which is in the case of having
vertical modes match start for baseline is what would
happen to an inline block anyway.
fantasai: Inline blocks are really weird. It would align with the
first baseline unless it's a table and if it is we
ignore it.
fantasai: And if there's no content, we use the margin edge, which
is weirdly discontinuous.
fantasai: If you're interested in baseline alignment, please
review the sections of the spec. I don't think anyone
has really looked at it besides me and TabAtkins
Rossen: Sure thing.
<tantek> agreed with fantasai, baseline alignment is hard
astearns: Sounds like all of this it would be useful to have test
cases so we can more concretely think about the cases
and not get lost in theory.
<fantasai> +1 astearns, I think that's a very good idea
<TabAtkins> From the agenda: https://github.com/w3c/csswg-drafts/issues/211
is the primary issue. It links to the other two that
are slightly more specific takes.
Rossen: There are multiple issues. I don't think there will be a
blanket solution and it's better to separate them.
astearns: I see fantasai, TabAtkins, Rossen, rachelandrew, and
Mats are interested. Anyone willing to take a task to
write a test case or two?
fantasai: I think my first job is to make illustrations for the
spec.
fantasai: Rossen if you guys could go through the spec and raise
specific issues as you find them that would be great. It
hasn't had detailed review.
Rossen: Yep. We'll definitely do it.
astearns: Anything more on this issue this week?
Should we spec required prefixes directly in the relevant spec?
---------------------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/247
* fantasai agrees with Florian's approach
<BradK> Link to compat spec?
<tantek> yes I'm ok to just link to compat spec
<tantek> I mean, someone else is already doing the work, so why
fight that?
<BradK> What is the url?
<tantek> compat.spec.whatwg.org
TabAtkins: The quick thing is we've got a bunch of the required
-webkit prefixes listed in the WHATWG doc. Given that
we don't like to send people to other documents it's
odd that we're letting other people maintain this. If
we have required prefixes we should do it like other
deprecated features and have it somewhere unobtrusive
like where we do deprecated features.
TabAtkins: We do this in a few spots. UI has prefixed thing for
user-select and it's fine. So when we need to doc a
required prefix we do so in the spec that requires them
is my prop.
<bkardell> this should be a short lived problem right? nobody
should be kicking out more prefixed things?
plinss: I'm opposed to having them in our specs. The list is a
business issue not a technical one. I don't want them
enshrined in our specs because it's dynamic and changing.
I don't care if it's WHATWG or someone else, but not in
our specs. I don't mind a link in the spec or a note.
astearns: I don't care where they go, but the point was made these
should be handled like deprecated property and I don't
think that's correct. Deprecated properties had been
speced in the past, these did not have an actual spec
definition. The set that needs to be handled is fluid,
as plinss said. Having that tracking of what needs to be
implemented for web compat outside our specs and in
something easier to change is good.
tantek: The point about deprecated: there have been numerous
examples where we've deprecated something that hasn't been
speced, like embed element. Those were proprietary before.
That being said this group has a lot to work on and I'm
not sure why we'd want additional workload where another
group is doing it and they're doing a fine job.
<fantasai> tantek++
tantek: I sympathize with the concern, but this seems like
optimizing something that's way down on the list of things
to do. The current system is working fine.
fantasai: We can link to their spec from the snapshot.
tantek: I agree. This is the Web, let's just make it a hyperlink.
astearns: The point about errata is that no one reads them because
they have to go elsewhere is actually what we want.
tantek: That's true. For the web authors that read the specs
there's no need to pollute their minds with prefixed
versions.
astearns: Points or rebuttals?
<bkardell> Just food for thought: if the idea is really that
authors will have a harder time finding it if it is
only a link, very few authors read specs anymore -
they've gotten pretty dense
* BradK agrees with tantek
dbaron: One concern is what happens in the long term? I think it's
just one person maintaining the spec. We may have to deal
with it then.
tantek: We can keep an eye on it. If it gets out of date or causes
problems later let's deal with it later.
<rachelandrew> agree with linking
<bkardell> +1 to linking
<TabAtkins> Yessss, I'm ok with linking in each spec.
astearns: fantasai says we can link to the compat in the snapshot.
I think it also makes sense to link from our specs that
have relevant entires. We can keep track of that on a
spec by spec basis. If something falls out we can handle
the change. If the compat spec doesn't have something
that's something to show we need to re-access what we're
doing.
tantek: astearns: I think that's an excellent suggestion.
RESOLVED: Link to the compat spec in the Snapshot and specs with
relevant entires and monitor for problems in the future.
First and Last Baselines
------------------------
astearns: fantasai you had an extra issue on baselines again? Did
you want to talk about that?
<astearns> https://github.com/w3c/csswg-drafts/issues/210
fantasai: This is syntax.
fantasai: The problem we ran into was the alignment spec has
last-baseline and baseline as a keyword.
<fantasai> <baseline-alignment-keywords> = baseline | last-baseline
fantasai: That's fine for alignment spec, but less fine for inline
layout alignment property which is a shorthand of
alignment-baseline and baseline-shift.
<fantasai> 'vertical-align' = { 'alignment-baseline' |
'baseline-shift' }
fantasai: alignment-baseline lets you choose your alignment
baseline and that gives us a combinatorial problem. It
becomes a lot of keywords that really seems excessive.
Usually we take advantage of allowing multiple keywords.
fantasai: We've got some questions about how do we deal with this.
Do we go to alignment and change 'last-baseline' to be
'last baseline' or do we do something else?
fantasai: There's five options in the issue and I want to know
thoughts.
astearns: I'm in favor of the optional keyword but in the quick
read I'm not seeing the differences in the five options.
fantasai: 1st explodes alignment baseline. 2nd is switch
last-baseline to last baseline
<fantasai> switch baseline | last-baseline to last? baseline
fantasai: 3 is to be inconsistent.
fantasai: 4 was a separate sub-property of vertical-align. It
would have baseline-shift alignment-baseline and a third
to say first or last baseline.
fantasai: That lets you cascade your baseline preferences
independently of first/last preference.
fantasai: 5 is to have both first and last baseline as prefixed
and space separated in the vertical alignment
fantasai: I prefer either 2 or 4.
fantasai: But the main difference between those is if the
first/last preference is an independent property
fantasai: or folded into the ideographic vs. alphabetic property.
fantasai: I can take comments or we can end.
astearns: I would prefer 2, 4, or 5. I don't like 1 or 3.
astearns: Other opinions?
<BradK> 4 sounds good. Set it on the body and let everything
inherit it.
<fantasai> BradK: I don't think it would inherit...
<BradK> Doh!
<fantasai> Bradk: alignment-baseline defaults to using the
'dominant-baseline' of the container, which does inherit
<gsnedders> 4, I think. But my internet connection is dying.
astearns: Is there much use of last-baseline in the wild?
fantasai: No, it's new. It wasn't in Flexbox and we haven't
release grid or alignment yet.
astearns: That's good.
astearns: I could add this to the github issue, but it might be
useful to reject 1 and 3 and have examples of the
differences between 2, 4, and 5.
fantasai: Okay.
<TabAtkins> Yeah, easy to draw up some examples.
<TabAtkins> I or fantasai can do that today, and revisit next week?
astearns: Anything else on this issue?
astearns: I'll take that as a no.
astearns: For other business, you can see on the private list
we're trying to get the charter submitted next time W3C
management meets.
astearns: Hopefully that will go well.
astearns: Anything else?
astearns: Thanks everyone.
Received on Thursday, 30 June 2016 00:20:46 UTC