- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 9 May 2019 07:11:21 -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.
=========================================
Toronto F2F
-----------
- Anyone attending should add their names to the wiki
CSS Size Adjust
---------------
- The spec needs more attention before it's ready for FPWD.
CSS Text
--------
- RESOLVED: Inline box boundaries don't affect line breaking
opportunities (Issue #3886)
- RESOLVED: Fixed width spaces U+2000 and up are treated like U+0020
and U+3000 -- hang / disappear at end of line (Issue
#3879)
- There was disagreement on how tabs should be handled in pre-wrap
(Issue #3869) so Florian will add examples to the github issue
of what tabs are used and what the options are for handling them.
- RESOLVED: out-of-flows don't affect hyphenation (Issue #3862)
CSS Pseudo
----------
- RESOLVED: Add .pseudo() to CSSPseudoElement once some stacked
pseudo combination becomes a valid selector. Adjust
.element return type to match. (Issue #3836)
CSS Lists
---------
- RESOLVED: Don't expand the list of properties that apply to
::marker (Issue #3826)
Scroll Snap
-----------
- RESOLVED: Use the writing mode of the container (Issue #3815:
Clarify which writing-mode is used for
scroll-snap-align, scroll container or snap position
element?)
CSSOM
-----
- RESOLVED: Spec these methods, mark them deprecated, add ADVISEMENT
to authors to not teach or use (Issue #3814: webkit/
blink methods on CSSStyleSheet)
CSS Overflow
------------
- RESOLVED: For flex and grid, margins contribute to overflow (Issue
#3653)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019May/0003.html
Present:
Rachel Andrew
David Baron
Amelia Bellamy-Royds
Christian Biesinger
Oriol Brufau
Emilio Cobos Álvarez
Benjamin De Cock
Elika Etemad
Tony Graham
Peter Linss
Anton Prowse
Melanie Richards
Florian Rivoal
Jen Simmons
Lea Verou
Sean Voisen
Fuqiao Xue
Regrets:
Rossen Atanassov
Daniel Bates
Tantek Çelik
Simon Fraser
Dael Jackson
Brad Kemper
Manuel Rego Casasnovas
Alan Stearns
Greg Whitworth
Scribe: fantasai
Toronto F2F
===========
dbaron: If you're planning to come to Toronto, please add yourself
to the wiki
dbaron: and update whether you're coming to Houdini
dbaron: and also dietary requirements, please email me
<jensimmons> Link: https://wiki.csswg.org/planning/toronto-2019#participants
CSS Size Adjust
===============
plinss: FPWD?
florian: Looking at the spec, seems like there are some issues that
we should handle before FPWD
dbaron: I was hoping to add some more before FPWD
dbaron: Admittedly, it's been a long time and I haven't done that...
xfq: FPWD is usually that the WG has consensus to work on the spec
fantasai: A little more than that: agreement to work on it, but also
that the general direction of the draft is acceptable
myles: This is text-size-adjust, right?
myles: We're interested in working with WG to standardize
myles: can't commit any time in the short term tho
AmeliaBR: Any IP reasons to get the call for exclusions out?
[silence]
florian: Issue 1 in the spec says that the subsection requires
checking whether the section is correct
florian: Giving further status to the spec risks confusing people
rather than helping
florian: Like to get to FPWD, but maybe not there yet. How do we get
there?
dbaron: If Apple folks can help in the medium term, that's helpful
dbaron: What's in the draft is roughly what we had figured out for
Gecko as of awhile ago
dbaron: But Gecko impl may have changed a bit since then
dbaron: I'd be inclined to wait and make some progress in the future
dbaron: Maybe at F2F
myles: I'm happy to talk offline
CSS Text
========
Inline boundaries and wrapping
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3886
florian: out-of-flow elements don't introduce a soft wrap opportunity
florian: But doesn't say about inline boundaries
florian: We have a WPT test for this, but not backed by spec
florian: In the past Chrome had a bug where inline element
boundaries suppressed wrap opportunities
florian: Now sometimes have opposite bug that inline boundary
introduces wrap opportunity
florian: Any push back that putting a span around things doesn't
change where line breaks can happen?
fantasai: No, we should definitely spec this
fantasai: "Inline boundaries don't affect line breaking
opportunities"
RESOLVED: Inline box boundaries don't affect line breaking
opportunities
Hanging/collapsing fixed-width spaces
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3879
florian: Spaces ...
florian: Currently only U+0020 and U+3000 are able to hang
florian: But other fixed-width spaces don't
florian: don't know if there was a specific reason not to include
them, or some kind of oversight
fantasai: I think we knew that nbsp couldn't hang
fantasai: so we only had U+0020 hang
fantasai: Later on added ideographic space in response to feedback
from Japan
fantasai: Didn't re-evaluate other fixed-width space
florian: Compat risk?
fantasai: Probably low, most people don't know they exist
fantasai: I'd be willing to change the spec and see how it goes
fantasai: We'll need to except nbsp
fantasai: Also ogham space mark?
florian: There's about whether spaces can hang at the end of the
line in pre-wrap
florian: Separate question of whether they disappear when wrapping
'white-space: normal'
florian: Not sure how to deal with ogham
fantasai: Will have to as i18n
<fantasai> http://www.fileformat.info/info/unicode/category/Zs/list.htm
RESOLVED: Fixed width spaces U+2000 and up are treated like U+0020
and U+3000 -- hang / disappear at end of line
Pre-wrap and tabs
-----------------
github: https://github.com/w3c/csswg-drafts/issues/3869
florian: Also came up writing tests ...
florian: We say what happens to spaces at the end of the line. We
don't say what happens to tabs.
florian: I suppose the same thing happens, but spec doesn't say
florian: Spec describes tabs rendered as a shift, not a visible thing
fantasai: Certainly if spaces after the tab, should be rendered as a
shift
fantasai: but at the end of the line, wouldn't be surprised if they
disappeared
...
fantasai: Definitely treat the same as spaces for break-spaces
fantasai: not so sure for others
myles: I agree with Florian, treat it like spaces.
myles: It's a Unicode character just like any other
fantasai: Its size changes depending on its position in the line
florian: Spec allows UA to compress their width to zero at the end
of the line, could do that with tabs also
fantasai: That won't be allowed in L4 though
fantasai: ... wrt myles's point about font shaping, characters
change shape depending on context
fantasai: But not depending on their position within the line, which
is what tabs do
...
fantasai: I'm not really sure what should happen, but I lean towards
tabs not being allowed to hang
fantasai: Partly for that, partly because they are quite large = 8
spaces by default
florian: But you want your caret to be visible if you put it after
the tab
AmeliaBR: Tabs at the end of the line are rare. Also if you want to
edit, you want to be able to see them.
myles: Don't want too many special cases
plinss: Tabs are used for delimiting things. Shouldn't disappear.
fantasai: Who's saying anything about disappearing? I'm saying they
shouldn't hang. Doesn't mean they disappear
fantasai: Treat it just like a visible character, it causes text to
wrap to the next line.
fantasai: Hanging allows things to overflow even when there are
sufficient wrapping opportunities in the line to not
overflow
myles: Tabs are more like spaces than visible characters
florian: Like spaces or nbsp?
AmeliaBR: Maybe continue this discussion in the issue, write out the
options and add examples of how that would work for use
cases e.g. editing text, viewing tab-delimited data, etc.
ACTION Florian write up options
<trackbot> Created ACTION-878
Unstyled inlines vs hyphenation
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3862
florian: We resolved that unstyled inlines don't affect how
hyphenation work
florian: But forgot to ask about out-of-flow
florian: For all other places in this spec where we say inlines
don't have an effect, say the same thing about out-of-flow
florian: So consistency seems good
fantasai: I think it shouldn't
myles: Linguistically that's wrong
RESOLVED: out-of-flows don't affect hyphenation
CSS Pseudo
==========
CSSPseudoElement having a pseudo() method
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3836
AmeliaBR: Seems to make sense to me, if a pseudo-element can have a
pseudo-element, then having .pseudo() would make sense
emilio: Have we decided yet how to make those styleable
fantasai: Will be stylable with selectors like ::before::marker
emilio: I would wait to add this method until that is allowed
fantasai: So proposal is to add .pseudo() to CSSPseudoElement once
stacked pseudo becomes a valid selector
plinss: Side issue of whether to rename .element to .parent
fantasai: Not always a parent
TabAtkins: The full term is "originating element" but that was too
long
TabAtkins: So shortened to .element
plinss: Need to reach pseudo-element between you and the element
TabAtkins: Yeah, that's what .element would do
plinss: OK
TabAtkins: When we adopt this, just the return type would be adapted
RESOLVED: Add .pseudo() to CSSPseudoElement once some stacked pseudo
combination becomes a valid selector. Adjust .element
return type to match.
CSS Lists
=========
::marker vs other pseudo-elements
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3826
<fantasai> I agree with
https://github.com/w3c/csswg-drafts/issues/3826#issuecomment-483320040
emilio: I think there was some confusion of whether 'display'
applies to markers
fantasai: Display doesn't currently apply to markers
fantasai: and I don't think it should until marker layout is fully
defined
fantasai: and its interaction with display is also defined
TabAtkins: Mats is arguing for much more than display
TabAtkins: He's arguing for marker to take all properties, like
::before/::after
TabAtkins: Is there a reason to stop at display or re-litigate after?
Scribe: florian
fantasai: The reason we have a limited list of properties is that
because we don't know how marker layout works
fantasai: so allowing these properties without knowing what they do
is bad
fantasai: We also don't know the size of the box, so any property
that makes that visible is a problem
fantasai: We don't know if line-height plays a role... many other
properties have the problem
fantasai: There are implementation specific answers, but so far
they're not exposed
fantasai: so if we expose them, me might accidentally lock compat on
whatever ships first
fantasai: So we should not
emilio: Makes sense to me, will apply that to firefox
fantasai: For now we just allow text related properties
fantasai: eventually we want to relax that, but only after layout is
defined
<florian> https://www.w3.org/TR/css-pseudo-4/#marker-pseudo
<florian> proposed resolution: don't expand the list of props that
apply to ::marker
RESOLVED: Don't expand the list of properties that apply to ::marker
<fantasai> It would probably be OK to add more properties from
css-text/text-decor
<fantasai> those that apply to inlines
Scroll Snap
===========
Clarify which writing-mode is used for scroll-snap-align, scroll
container or snap position element?
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3815
fantasai: The question is which writing-mode is used for
scroll-snap-align:start and the container and the
containee have different writing-modes
fantasai: The proposal is to use the writing-mode of the container
fantasai: because that's what we do for alignment properties
fantasai: We also have the self-start and self-end keywords if you
want that
fantasai: That made more sense to align all things the same side in
a single container
fantasai: This proposal is motivated by consistency with that
jensimmons: Sounds reasonable to me
plinss: Me too. objections?
RESOLVED: Use the writing mode of the container
jensimmons: I wanted to thank the group for the great hard work to
make specs understandable.
<bdc> (fully agree with jen)
jensimmons: I have been at conferences, and after struggling with
other specs, I really want to voice appreciation for
doing it well as this group does.
CSSOM
=====
scribes: fantasai and florian
webkit/blink methods on CSSStyleSheet
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3814
emilio: I got a compat issue report on this
emilio: I'm planning to implement and spec
emilio: It is sad that we need them, but it is also easy, so I'll
just do it
emilio: Anyone has a strong concern about adding this?
plinss: I have been advocating for pushing such things to a side
spec / compat spec
TabAtkins: No, I want the compat spec to go away, it should be in
the main spec
plinss: That encourage new content to use it
fantasai: We can mark them as deprecated, presented as a footnote,
make warnings, etc
fantasai: but still put them in the main spec
<chris> I agree that deprecation is sufficient guidance for new
content
florian: The compat spec tends to have a lot less rigor than the
mainstream specs have
florian: It just documents existence of thing, not how it works
florian: For things that aren't needed, let's not spec them. But
things that are necessary for web-compat, then we need to
spec them.
florian: It's a disservice to implementers to not spec them.
florian: If it wasn't necessary to implement, we wouldn't be
speccing at all
emilio: Regarding fantasai's point, PR just says "legacy features".
Open to better suggestions.
plinss: I'm OK as long as clearly marked as deprecated, as fantasai
described
plinss: Other thoughts?
RESOLVED: Spec these methods, mark them deprecated, add ADVISEMENT
to authors to not teach or use
florian: When you do this, you can put them at the bottom of the
spec, so only ppl who read the whole section notice them
emilio, https://www.w3.org/StyleSheets/TR/2016/readme.html#advisement
CSS Overflow
============
Margins and scrollable overflow
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3653
fantasai: ....
florian: For all things where we don't have a legacy constraint, I'm
in favor of including margins, and this is one of them
fantasai: For blocks we cannot just include the margins, because
compat, but for grid and flex we don't have this problem
fantasai: so when you put overflow on things, and have margins,
authors expect them to show up
[fantasai was explaining why spacing specified by the author should
be included in scrollable overflow -- it's used for spacing, and
needs to provide that spacing between item and bottom/right
edges of scroll container]
[but have compat issues with block containers, would create too many
unexpected scrollbars; so adapting for grid flexbox only]
Proposed resolution: for flex and grid, margins contribute to
overflow
RESOLVED: For flex and grid, margins contribute to overflow
Received on Thursday, 9 May 2019 11:12:15 UTC