- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 5 Oct 2016 19:37:19 -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.
=========================================
Consider support for overlay scrollbars
---------------------------------------
- TabAtkins summarized his proposal for creating overflow-gap:
auto | stable | always
- Rossen asked if making these optional values for auto on the
overflow property would make more sense as it would avoid
creating another property.
- This was considered and a few people originally expressed no
preference, but the more it was discussed the more people
felt this was the wrong approach.
- There still wasn't agreement as to if this new property should
be a longhand of the overflow: auto or if it should be
completely separate.
- RESOLVED: We will work on a solution to accommodate issue 92
(https://github.com/w3c/csswg-drafts/issues/92)
Stretching image grid items in both dimensions
----------------------------------------------
- RESOLVED: The normal value of align-self and justify-self
preserves aspect of image but stretch causes it to
stretch to fit containing block. Default value
continues to be normal.
CSS Text DoC issues
-------------------
- RESOLVED: Accept the proposal for issue 96 (for linebreak
transformation rules ambiguous characters are narrow
unless it's Chinese or Japanese or Yi in which case
they are wide)
- RESOLVED: Make tab size animatable
- RESOLVED: Make tab size <<number>>
- RESOLVED: Have tab-size account for letter spacing and word
spacing
- RESOLVED: No change to the spec for issue 110
- RESOLVED: Capitalize only title cases lower case things, not
upper case letters
- RESOLVED: text-align-last: justify will compute to center for
CJK
===== FULL MINUNTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Oct/0053.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Tantek Çelik
Dave Cramer
Elika Etemad
Simon Fraser
Tony Graham
Jihye Hong
Dael Jackson
Brad Kemper
Ian Kilpatrick
Vladimir Levantovsky
Peter Linss
Myles Maxfield
Simon Pieters
Anton Prowse
Liam Quin
Florian Rivoal
Jen Simmons
Geoffrey Sneddon
Alan Stearns
Greg Whitworth
Regrets:
Rachel Andrew
Bert Bos
Daniel Glazman
Chris Lilley
Rossen: Let's get going.
Rossen: First topic is stretching image grid items in both
dimensions.
Rossen: There was chatter during TPAC and a bit more on the queue
but this is flagged as agenda+.
Rossen: So fantasai take it away.
[fantasai isn't on]
Rossen: Or is TabAtkins on?
<TabAtkins> one sec
[trying to find a topic with the right people on the phone]
Rossen: Does anyone have a topic they can do without TabAtkins and/
or fantasai?
<astearns> testing?
TabAtkins: I'm in now.
Rossen: Can you do the grid topic or do we need to wait for
fantasai?
<Florian> This one: https://github.com/w3c/csswg-drafts/issues/523
TabAtkins: [looks] I have not read up on this.
<dbaron> I could probably speak a little about 523, but not
comprehensively
Rossen: Second items requires fantasai as well as koji and others.
Consider support for overlay scrollbars
=======================================
<Florian> https://github.com/w3c/csswg-drafts/issues/92
Florian: We had a fairly long conversation on this. TabAtkins you
had the last proposal.
TabAtkins: This was from a little while ago where we discussed
having table scrollbars issue. Current proposal is
overflow-gap using gap terminology from elsewhere with
auto|stable|always
TabAtkins: Auto is do what the browser currently does. Stable is
always have a gap if you have potential scrollbars.
Always is always have a gap.
TabAtkins: I can go over reasoning if needed. So proposal is
overflow-gap: auto|stable|always. This only has effect
if you're in overflow: auto.
Florian: Only problem left is fantasai didn't like calling it a
gap, she wanted gutter. Else wise I like it.
Rossen: I've been reading through this, did we consider having an
optional value for overflow: auto? Seems to me having this
property is overkill given that it only applies to
overflow: auto
Florian: We partly considered that, though not with the latest
incarnation. It goes down to if they should cascade
separately and you may want to have this on the entire
page except for where you override it.
Florian: If you do that it's good to have them separate.
TabAtkins: Against that is if you always use this when activating
auto you should pick the right value.
Florian: Then you have to set it twice to deal with fallback.
Rossen: Depends on the what defaults are.
TabAtkins: Florian is dealing with fallback for non-supporting
browsers and that's true.
Florian: Yeah. I would prefer separate but I'm fine if we roll it
in.
TabAtkins: I'm fine with it being an extra value.
Florian: overflow: auto and then overflow: auto|stable|always
Florian: Auto is implied.
TabAtkins: Stable is okay, I think we want a different name then
always.
Rossen: Auto always suggests scroll.
TabAtkins: I'm happy to go with that and come up with a better
name. The question is should I do this in an active
draft? There was some interest in Chrome in doing this
and removing some properties of overflow, but it
requires stability.
Florian: It should go in overflow level 4 if we have agreement.
Rossen: I think we should start in level 4 and bikeshed in there.
We can call for consensus now.
Rossen: I see smfr on the queue.
smfr: I think it's bizarre to tack this onto overflow. If I read
overflow: auto always I wouldn't understand what it means.
<jensimmons> I agree.
TabAtkins: Always is no longer good, but stable suggests the
meaning.
smfr: Overflow is how the content behaves. I think a separate
property would be so much clearer.
smfr: I would prefer overflow-gutter.
* fantasai agrees with smfr, this is confusing
TabAtkins: If we make overflow a short hand we could say overflow
auto stable and it would work correctly. I'm with
Florian and don't care either way.
Florian: I hadn't realized you meant as long hand.
TabAtkins: If we add overflow-gap overflow needs to be a shorthand.
* fantasai doesn't think overflow-gap and shorthanding makes that
much sense
<fantasai> having it cascade independently would make sense
<Rossen> overflow-style
<Rossen> overflow-style: stable | auto-hiding | gap
<jensimmons> Yeah I'm not sure what overflow gap is either. So
many times handling overflow doesn't involve
scrollbars. Need a way to let people know, hey this
is about scrollbars and gaps. And whatever.
smfr: Another request we've had is hide scrollbars but allow user
scrolling and we should allow extensibility to allow that
also.
TabAtkins: I talked about that separately, but I think we have
room with overflow-gap. I'm not sure it would make
sense there, but someone in overflow there's room to
accommodate.
fantasai: I think gap control should cascade independently of if
something scrolls.
TabAtkins: We aren't sure why you would want it to cascade
separately. There's no reason to use overflow auto and
depend on it being set to stable elsewhere.
Florian: I kind of disagreed with that logic.
Rossen: Sounds like there's a strong desire to have the property.
We have a spec where we can put it and continue to argue
or agree. So should we get an consensus on adopting this
in overflow 4?
Florian: We have consensus on the function, but we don't have it
on if it's a separate property etc.
fantasai: We shouldn't put it into the draft unless there's a
concrete proposal.
TabAtkins: The proposal as stands is in the issue.
Florian: There's 3 proposals and they're different.
<gregwhitworth> for the cascade scenario, it would be nice for use
cases that authors would want them to cascade
separately
fantasai: If this is issue 92 the last comment is from me.
Rossen: And that was about naming.
Florian: We have 3 concrete proposals, not one.
TabAtkins: Do we have consensus on having this ability so that we
should pursue doing it?
fantasai: We have consensus we want to solve the issue so it stays
open and we try and discuss proposals. Last comment you
have, TabAtkins, is adding overflow-gutter property. Now
we're adding a value into overflow directly.
TabAtkins: We can fill in that detail in writing. This came up
before you joined the call.
fantasai: If I'm the only one disagreeing go ahead, but I hear
reservations from others.
Rossen: That was about using it as a value, not a property.
Rossen: That was provoked by me because I didn't see it and we had
a brief conversation.
Florian: And TabAtkins using overflow implied it's a long hand and
I missed the nuance.
<jensimmons> It sounds like some new ideas just came up, and
further discussion in the issue is the next step. And
that everyone want this feature. Just needs a bit
more baking before getting put into the spec.
Florian: Since there's no concrete proposal I don't know what we
should put in the spec.
TabAtkins: Let's resolve to add something with this pending
agreement with how to do it. I want something on the
record saying we want to do this.
Florian: I'm in favor of saying we want to do this, not having
something in the spec.
Rossen: Objections to having us work on overflow [some name] to
accommodate issue 92?
RESOLVED: We will work on a solution to accommodate issue 92
Stretching image grid items in both dimensions
==============================================
<Rossen> https://github.com/w3c/csswg-drafts/issues/523
Rossen: There was a conversation during TPAC with Manuel and
others. Can you take this one fantasai?
fantasai: The issue was about preserving aspect ratio of grid
items that have one. Current spec says squash the image
if it's a fixed size grid block.
fantasai: You can use object fit properties to contain it or you
can change the width but the argument was we should
preserve the aspect ratio by default. With object-fit
you preserve and clip and if you use auto the image box
has this gap and it becomes obvious.
fantasai: We could change auto to cause it to shrink and preserve
aspect ratio by default.
fantasai: I don't have a strong opinion. I do think how object-fit
works is super messed up.
dbaron: I think Mats feels strongly squashing is wrong by default.
Part of the problem is the initial value of object-fit
doesn't work well for grid which stretches by default.
dbaron: Given that the initial value is stretch, grid does this
other sizing on top that makes the stretch happen in more
cases. It feels object-fit is the wrong default for gird.
If we do the other behavior object-fit becomes slightly
less useful.
fantasai: You can set width and height to 100% and it'll fill the
cell.
fantasai: It would be nice if alignment would work to control
this, but they work on each axis independently. You can
say I want to stretch or do intrinsic sizing in this
axis. You can preserve axis ratio, but you may overflow
if you don't know which is longer.
TabAtkins: I think you're saying that preserving aspect ratio if
you let it stretch and do object-fit: contain
fantasai: But than you don't resize the borders. That's a problem
with object in general.
TabAtkins: It's a problem object doesn't solve, sure.
<smfr> object-fit has only been applied to replaced elements so far
<dbaron> smfr, this is about applying to replaced elements --
images that are grid items
Rossen: Is this something dbaron you're okay with? You expressed
Mats has a strong preference.
Rossen: Having a clear work around for this...
fantasai: Another thing we can do to allow an easy switch is we
have a normal value for alignment. For grid items it's
equivalent to stretch. We could say normal does what
Mats is proposing to make sure the image fits in the
frame and stretch alters the aspect ratio. That gives us
a switch for all common behaviors.
dbaron: Seems like a nice idea to me. I'm curious what Mats thinks.
jensimmons: Feels to me that stretch should stretch it and
something else could be the default. Having stretch
not stretch is disappointing. There's use cases to
have the containing box be controlled by grid and
having the crop to make it fit. Having that be the
default is the awkward part.
fantasai: Other thoughts on this or should we go with that?
fantasai: Summary: The normal value of align-self and justify-self
preserves aspect of image but stretch causes it to
stretch to fit containing block. Default value continues
to be normal.
Rossen: Sounds reasonable.
Rossen: Objections?
<dbaron> This is proposing changing the grid rule in
https://drafts.csswg.org/css-align/#distribution-grid
<dbaron> ... so that it's a different default for (I guess)
replaced elements
RESOLVED: The normal value of align-self and justify-self
preserves aspect of image but stretch causes it to
stretch to fit containing block. Default value continues
to be normal.
CSS Text DoC issues
===================
<Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-96
<Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-102
<Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-108
<Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-110
<Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-111
<Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-114
<Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-117
<Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-123
<Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-122
Use language context for dropping spaces around A (issue 96)
------------------------------------------------------------
fantasai: There is discussion about that the Chinese use same " as
English therefore East Asian treats them as ambiguous.
fantasai: We're using East Asian width to determine if align-break
is just a space of if it disappears as in CJK languages.
fantasai: There's rules that say if you're in CJK turn the line
break into nothing. If you're non-CJK keep the space. We
determine it by looking at East Asian width property of
character before and after line break.
fantasai: Issue that came up is can we make this context dependent
so the " doesn't prevent the line break from collapse.
fantasai: Proposal is use the content language if it is known. If
it's unknown we treat them as narrow.
fantasai: Is this okay for the set-up rule and, if yes, do we
adopt?
Florian: The alternative is be language dependent in the markup or
context dependent in surrounding characters?
fantasai: We're using context now and using wide vs narrow to make
that distinction.
Florian: If it's Kanji " Kanji you're wide?
fantasai: Currently all ambiguous is narrow. If content language
is East Asian treat ambiguous as wide is the proposal.
Florian: That sounds fine.
koji: I'm fine with language, I'm concerned with adjacent(?)
character. We can only see the character next to.
Florian: Adjacent doesn't sound like a good idea. Sorry for
brining it up.
fantasai: Characters immediately after the one that has the line
break?
Florian: That's what I thought of and I don't think it's a good
idea.
fantasai: I think there was easier a rule to walk if there's
punctuation but we simplified to immediately adjacent.
fantasai: This seemed a simpler solution.
Florian: Yeah.
<dbaron> Gecko has some language-dependence in justification code
(currently conditioned on C or J but not K!) but I'm not
sure about how far away the code for this is
<dbaron> My suspicion is that the language dependence probably
isn't a problem
Florian: dbaron says in IRC yes to the on C and J but not K
dbaron: fantasai asked about language dependence. I didn't follow
what this is about. We have language dependence in code
that classifies differently on CJ but not K. I think
language dependence is probably okay. It's worth thinking
if you mean CJK or just CJ.
fantasai: It's Chinese and Japanese, but not K. K has spaces so we
don't want to remove those.
fantasai: This is in the white-space collapsing code.
dbaron: It's hard to know for sure if something is implementable
until you implement it, but barring that it sounds okay to
me.
fantasai: Okay, then I'd say this is a good proposal and we should
accept.
Rossen: Objections?
RESOLVED: Accept the proposal for issue 96 (for linebreak
transformation rules ambiguous characters are narrow
unless it's Chinese or Japanese or Yi in which case they
are wide)
Animating tab-size (issue 102)
------------------------------
<fantasai> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-102
fantasai: Animating tab size. dbaron pointed out it's not
animatable. We need to change the integer to a number to
make this possible. Is that okay and do we want it to be
animatable?
Rossen: Let's start with should it be animatable?
myles: What's the use case?
fantasai: I don't think there is one.
TabAtkins: Consistent platform. You have a number and no reason
you can't have something between the two. This would be
another quirk you have to remember.
myles: If we don't expect anyone to do this is there a point is
spec?
Florian: We have to go one way or another.
myles: It is specced one way.
TabAtkins: By default. Bikeshed by default says not animatable
unless you spec it. Tab size does have a length. It's a
weird inconsistency. Small tiny use case, but an
inconsistency we don't need to have.
Rossen: Sounds like TabAtkins proposes we make it animatable.
* fantasai defers to dbaron on this
<bradk> Animatable +1. Principal of least surprise.
TabAtkins: fantasai proposed it and I support. I don't care if we
change it to a number. That they're an integer isn't
significant. But even if they're pure integers they'll
be animatable.
dbaron: I feel there is a real use case for number over integer.
People would be surprised they can't do 2.5.
Florian: I think we're splitting hairs here. Most likely you're
doing this with monospace and you can use ch unit.
fantasai: There is another issue that makes numbers different than
ch in monospace.
fantasai: This issue is coming up on the list.
Florian: [dramatic oooh]
fantasai: In which case this would be smoothing animatable.
Florian: So if it accounts for letter spacing what would 2.5 mean
fantasai: It would be space+letterspace+wordspacing and multiply.
Florian: Not n-1 on spacing?
fantasai: Nope.
Florian: Then it's fine.
TabAtkins: I don't know if I agree with that proposal, but it
doesn't matter because it interpolates fine.
Rossen: Let's call for consensus. Objections to making tab size
animatable? Objections to be being a number?
RESOLVED: Make tab size animatable
RESOLVED: Make tab size <<number>>
tab-stop should handle word/letter-spacing (issue 114)
------------------------------------------------------
Florian: Letter yes, word I'm not sure.
fantasai: Word increases size of space. Every space character
would get increased.
TabAtkins: Does this have an analog in other environments with
tabs?
fantasai: I don't think so? Maybe word processors?
TabAtkins: The important point is if you have a monospace fonts
and tab size is 8 with this change is it lining up to 8
monospace characters?
fantasai: Yes.
Florian: I'm confused on how we space words, but given that it
works this way that's okay.
Rossen: Is this Issue #114?
fantasai: Yes.
Rossen: Objections to have tab-size account for letter spacing and
word spacing?
RESOLVED: have tab-size account for letter spacing and word spacing
* dbaron notes issue 113 is an issue in a feature that's in CSS1
Capitalizing enclosed alphanumerics (issue #110)
------------------------------------------------
fantasai: There was an issue as to if alphanumeric characters with
a circle should be capitalized. They're symbols in
unicode and the case transforms are only for letters.
Jonathan Kew and someone had an argument to have it
stay. There was another to say change.
<tantek> link to email thread?
<gregwhitworth> I think it's this one:
https://lists.w3.org/Archives/Public/www-style/2015Mar/0144.html
fantasai: My recommendation from all the comments is we should
leave the spec as-is and not case transform symbols.
Rossen: I think your last e-mail was we should go with whatever
unicode case mapping is defined and have CSS match that.
fantasai: Yes. I concluded we should keep the spec what it is. We
say which set of characters are effected by case mapping.
fantasai: So this is a similar restriction where case mapping is
only letter characters and not symbols characters.
Florian: I would tend to agree based on if we add custom text
transforms it will be easier to create a new one that
does general capitalization plus that then make one to
remove it.
<tantek> I think that's wise
Rossen: Let's see if we can conclude to leave spec unchanged.
Rossen: Objections?
RESOLVED: No change to the spec for issue 110
Titlecasing digraphs (issue #111)
---------------------------------
<dbaron> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-111
<gregwhitworth> Email thread:
https://lists.w3.org/Archives/Public/www-style/2015Mar/0242.html
fantasai: There is a difference in unicode between capitalizing
and titlecasing. Most letters it's the same, but in a
digraph the titlecase capitalizes the first but not
second letter. Issue was we shouldn't take that and put
it in title case if it's already in upper case.
fantasai: You would get an odd effect where if you title case the
first letter you have a lower case letter in the middle
somewhere for no reason. I agree with that.
Rossen: Is this an addition?
fantasai: Yes.
Florian: Where we go from fully lower case digraph for fully upper
seems non-controversial.
fantasai: Text transform uses language dependency.
Florian: That makes sense.
fantasai: If it's not in unicode case mapping file we don't try
and fix it.
<dbaron> IJ, ij, etc.
fantasai: Otherwise Turkish i wouldn't work.
Florian: Give that's covered, I agree
fantasai: Capitalize only title cases lower case things, not upper
case letter.
RESOLVED: Capitalize only title cases lower case things, not upper
case letters
<TabAtkins> Reviewing the effects of spacing on a <pre>, yeah, I
def agree with the resolution from before - literal
spaces definitely take letter-spacing and word-spacing
into account. I can't tell off-hand whether it's
literally (space width + letter-spacing +
word-spacing) * spaces, or if there's a -1 in there
somewhere, but it looks about right.
Fallback alignment for justified text
-------------------------------------
<dbaron> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-117
<fantasai> https://lists.w3.org/Archives/Public/www-style/2014Oct/0395.html
fantasai: There is several possibilities for when you justify text
and try and space it out to align on both edges. Issue
is what do you do if you have no place to insert a
space. We have text-align-last property that says what
the last line does. There's a justify value. So when you
can't justify a line in the middle of the paragraph we
say do whatever text-align-last is.
fantasai: If it's justify we don't know what to do. We need
another fallback. I propose to just use centering. Use
cases with text-align-last is justify is where they want
centering as the fallback. Classic use case if the dish
name is the column and it's 1-7 characters. If last line
is 1 character is should center.
fantasai: Since there doesn't seem to be a strong case to have the
last line fallback to anything other than centering, I'm
proposing we make it center all the time if you're not
caught by text-align-last.
Florian: When do we do something other than center?
fantasai: You can't justify text in most languages, you just fall
back to start alignment. Those cases are covered by when
you have text-align-last to start.
Rossen: You're argument is for text-align-last it should be always
center.
fantasai: The initial value is start. If you have set
text-align-last to justify, the fallback is center.
Rossen: I'm not 100% sure.
Florian: I concur on the CJK use case. I don't know the other
languages.
Rossen: If you have only one word start makes most sense in
non-CJK.
fantasai: But for that you wouldn't have set text-align-last
koji: I agree with fantasai. text-align-last is set in most CJK
use cases.
Rossen: Objections?
RESOLVED: text-align-last: justify will compute to center for CJK.
Rossen: That's the hour. Thanks to everyone. We made good progress
on text.
Received on Wednesday, 5 October 2016 23:38:19 UTC