- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 19 Sep 2018 20:38: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.
=========================================
Scrollbars
----------
- RESOLVED: Request publication of FPWD of scrollbars
CSS Fonts 4
-----------
- RESOLVED: Higher level properties a positive angle will be a
forward leaning slant, lower level properties will be
what is written by the author (Issue #3091)
- RESOLVED: Publish fonts L4
CSS Break & CSS Display
-----------------------
- RESOLVED: Use 'should' in the patch (Issue #1746)
CSS Text
--------
- RESOLVED: Add florian as an editor to Text 3
- RESOLVED: Revert the previous resolution [break-word will no
longer affect intrinsic sizing] (Issue #2951)
- RESOLVED: Make the normative change [to apply a min width to
rendered tabs] (Issue #2883)
- RESOLVED: Publish a new working draft as text-3
- RESOLVED: Publish a new WD for text-4
CSS Overflow
------------
- RESOLVED: text-overflow affects non-breakable portions of the
block-overflow string (Issue #2882)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Sep/0015.html
Present:
David Baron
Tantek Çelik
Emilio Cobos Álvarez
Benjamin De Cock
Tony Graham
Dean Jackson
Brad Kemper
Chris Lilley
Peter Linss
Nigel Megitt
Thierry Michel
Michael Miller
Melanie Richards
Florian Rivoal
Jen Simmons
Alan Stearns
Lea Verou
Greg Whitworth
Regrets:
Rossen Atanassov
Chris Harrelson
Dael Jackson
Stephen McGruer
Manuel Rego Casasnovas
Sean Voisen
Jeff Xu
Scribe: gregwhitworth
astearns: anyone have any extra agenda items?
astearns: one change, we're going to skip item 8
Scrollbars
==========
Publishing FPWD of scrollbars
-----------------------------
github: https://github.com/w3c/csswg-drafts/labels/css-scrollbars-1
astearns: We discussed this at the f2f, but didn't get there - quite
a few issues have been worked on since then.
astearns: fantasai - you wanted some things working on, are you ok
with it going to fpwd?
fantasai: It looks like there is an outstanding pr that should be
merged first, but probably it's fine
astearns: Any other concerns?
<chris> please let me know when that merge has happened
chris: I'll put in the transition request now and wait until that PR
is merged
astearns: That sounds fine
Proposed Resolution: FPWD of scrollbars
RESOLVED: Request publication of FPWD of scrollbars
CSS Fonts 4
===========
Angle direction of font-style
-----------------------------
https://github.com/w3c/csswg-drafts/issues/3091
chris: It's about the slant axis and the range of values that are
supported
chris: The opentype spec takes negative values that it slants in an
odd direction
chris: Every single example I've seen uses a positive angle
chris: When you're using high level things, like font-style you need
to use positive integers
chris: but we also need to take into account the lower level things
and you have to pass in specifically what the font is asking
for
chris: For font-style a positive angle will make a forward slant and
under the hood it will map to what the font needs
<fantasai> wfm
astearns: The lower level will just pass through what is written by
the author
<bradk> +1
fantasai: It makes sense to me. It is what we would do if OpenType
was only one of multiple font formats, and the others
matched expectations and OpenType didn't. Of course we
translate from CSS syntax to the correct font settings,
and values in font-variation-settings of course get passed
directly to the font.
<florian> Sounds good to me. Let's make things sane for people
myles: This is similar to how we handled optical sizing
Proposed Resolution: Higher level properties a positive angle will
be a forward leaning slant, lower level properties will be what
is written by the author
RESOLVED: Higher level properties a positive angle will be a forward
leaning slant, lower level properties will be what is
written by the author
Publication
-----------
astearns: Fonts level 4
astearns: We had an update to l3 this week, does anyone have an
objection to updating a regular WD for L4
<fantasai> +1 to publishing
astearns: Hearing none
RESOLVED: Publish fonts L4
<fantasai> \^_^/
CSS Break & CSS Display
=======================
box-decoration-break and multi-box inline elements
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1706#issuecomment-420474809
astearns: [describes what is in the issue]
fantasai: Do we want to allow box-decoration-break to close the
fragments similar to what would occur when there is a
forced line break?
astearns: It describes non-contiguous fragments
fantasai: I could possibly make that a little bit clearer with
regards to bidi
fantasai: The two fragments may end up adjacent to each other, the
way the inline happens to break
fantasai: The rule for bidi, on an infinitely long line you end up
with something in the middle of the inline box to split
into two. The intruder are meant to be two separate
fragments even though they end up next to each other it
provides us with the information we need
fantasai: In that case if you did, box-decoration: clone you would
end up with text in between them because the bidi algorithm
fantasai: I think I can try to make it slightly clearer
fantasai: The part about non-contiguous is an example - it's not
exhaustive
astearns: That's fair
fantasai: I think the wording is ok
dbaron: One comment about the bidi thing
dbaron: Where implementations would create a separate fragment
logically but they can never be separate
fantasai: Or if you have an inline which has English text, a little
bit, there is nothing that lets the user know there are
multiple fragments
dbaron: What you're saying is that it's on a visual perspective of
whether it has the capability of breaking
dbaron: That seems complicated to implement
fantasai: This is about where it's defined to have a fragmentation
break
fantasai: from a rendering perspective, the user can't tell that
it's doing that
fantasai: The only case this should be known, is where there is text
outside of the inline is intruding on the inline
dbaron: I'm a little worried about.... <garbled>
dbaron: This section has a lot of mays in it, we should have an
issue for better definition
fantasai: For sure
dbaron: Please open an issue
fantasai: I can open one
astearns: Just open an issue for defining it better and leave the
may out of this draft
fantasai: We don't have any implementations so the may is there
dbaron: If it's actually what you want implementations to do - then
I would say that whether it's a should, with a may it's not
clear it's what you want an implementor to do
fantasai: ok, that's fair
fantasai: How would the WG prefer, a may with a note - or a must
astearns: I'm thinking a note that states that a future level will
completely specify what occurs in this situation
florian: I think that's what should is for
florian: 'should' implies the note that astearns described
dbaron: I support 'should' as well
Proposed Resolution: Take the patch substituting should for may
astearns: Objections?
RESOLVED: Use 'should' in the patch
CSS Text
========
editor for text
---------------
<fantasai> https://drafts.csswg.org/css-break-3/issues-cr-2016
astearns: add florian as an editor to text L 3?
RESOLVED: Add florian as an editor
Reverting resolution about overflow wrap break word
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2951#issuecomment-421705003
florian: We tried to have break-word affect intrinsic sizing
florian: We had some hope that changes in the UA stylesheet would be
sufficient, but it is not true unfortunately
florian: So the only option it seems is to revert the previous
resolution where it does not affect intrinsic sizing
astearns: Is that separate issue somewhere?
fantasai: Yeah we re-opened the issue
astearns: Objections?
RESOLVED: Revert the previous resolution
Applying a min width to rendered tabs
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2883#issuecomment-421733978
florian: When you have tab stops, if you have a tab - you're
supposed to go forward in the line
florian: If your text is coming extremely close to the next tab
stop, should there be a minimum size?
florian: Chrome, it jumps to the next one at a specific size and it
seems reasonable in a monospaced font
florian: I was thinking about going with 1 space, but maybe we
should go smaller than a space
florian: In a proportional font, spaces are already really small -
0.5ch
florian: I'm wanting to take this normative as makes sense
Scribe: emilio
astearns: Any comments from the non-chrome team?
<fantasai> +1 from me anyway
astearns: Proposal is minimum spacing is 0.5ch
astearns: Objections?
RESOLVED: Make the normative change
myles: Should link to the primary font concept
<fantasai> https://www.w3.org/TR/css-values-3/#ch
fantasai: It already does via the ch value, though it's not actually
the primary font
fantasai: It's ch, it's not ambiguous
emilio: Is it what Blink implements?
myles: If the code is the same as WK it's not exactly the same, but
we can say ch on the spec
astearns: The test for this is not going to test this exactly
fantasai: Why not?
astearns: Flaky tests / pixel differences
fantasai: Fine
Publication of text 3/4
-----------------------
astearns: Both text-3 and text-4 are working drafts, proposal is
publishing a new WD as text-3
astearns: No objections?
RESOLVED: Publish a new working draft as text-3
astearns: Any objections for text-4?
RESOLVED: Publish a new WD for text-4
CSS Overflow
============
block-overflow and text-overflow
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2882
florian: So the issue is about whether their interaction is
well-defined. There's only one case where it's not defined.
florian: If you have a break opportunity during the line we'll
insert the ellipsis after that break opportunity and
block-overflow doesn't have the chance to apply
florian: The only case where it's not defined is where the ellipsis
is longer than the whole line, right now the spec doesn't
define it
florian: Seems like we don't want the ellipsis to climb the line
back up, so for now I think we should go for 'when the
ellipsis is longer than the line then it does overflow, and
text-overflow must apply'
tantek: I think we need an example that we could look up
florian: It's something like a very narrow paragraph with a very
long block-overflow ellipsis
florian: The spec says that if block-overflow ellipsis overflows
then it may overflow to the next line, but it's undefined
tantek: Any implementation experience?
tantek: We should construct some examples and experiment, keeping
the issue open for now
tantek: Rather than spec something that is not easy to implement
<dbaron> It seems like "use multiple lines for the block-overflow
indicator" is probably the better behavior from a user
perspective, but it does seem hard to implement.
fantasai: Seems fine to leave it open as people implement it
florian: So I'd expand on the proposal with examples in the issue
florian: I'm ok with that
dbaron: [what he wrote above]
dbaron: Saying that it needs to fit on one line definitely makes
implementation easier, but it's not clear how much
tantek: I'd prefer to specify the better behavior for the user, and
we don't know how much harder it is
fantasai: So what we're hearing is that we should the issue open to
wait for block ellipsis breaking across multiple lines,
but we probably should say that if the block-overflow
string still doesn't fit withing the block then
text-overflow applies in that case as it would to any
other text
astearns: I like the idea of working out concrete examples so that
people get better idea, but also so that we can put them
in the spec
florian: Does it sound reasonable to resolve on what fantasai said
and add examples for the block-ellipsis on multiple lines?
fantasai: I think we should resolve that text-overflow applies to
the overflow string if there's an unbreakable string on it
like it does to the rest
fantasai: Also that we should put some example in the spec about
this interaction, and also on the issue about what happens
if the block-overflow string can break
fantasai: We could narrow down the behavior as 'either you treat is
as unbreakable' or 'treat it as breakable and grab space
from previous lines'
astearns: So the first bit is to resolve that text-overflow affects
overflowing, unbreakable portions of the block-overflow
string. Objections?
RESOLVED: text-overflow affects non-breakable portions of the
block-overflow string
astearns: Probably the examples doesn't need a resolution
astearns: We're going to work on those to put them on the spec
florian: I'm going to put examples in the spec on what we just
resolved, and then in the issue about the wrapping
astearns: Should that be a different issue?
florian: Maybe, sounds reasonable
astearns: We'll leave it to your discretion
florian: Should we resolve on the breaking to narrow it down to the
two discussed options?
astearns: Don't care
florian: I think I prefer to leave as-is for now
florian: Then we can narrow if we don't resolve soon
astearns: I think that's reasonable, I prefer to resolve soon, the
examples would be really helpful
Received on Thursday, 20 September 2018 00:39:38 UTC