- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 7 Nov 2019 18:54:50 +0300
- 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.
=========================================
CSS Shapes
----------
- RESOLVED: Accept the change that astearns put into the ED,
handling the case where margin = 0 for very small values
of shape-margin (Issue #675: Calculation of corner radii
by margin-box and border-radius)
CSS Text 3
----------
- RESOLVED: The line ending trailing space is applied after bidi
(Issue #4422: Bidi and pre-wrap end of line spaces)
- RESOLVED: Publish a new WD of text-3
CSS Nav
-------
- It was agreed that the spatial-navigation-action property will
continue to behave as defined and does not inherit (Issue #4449:
Proper definition of 'spatial-navigation-action' property). If
there are use cases for the inheritance the group will re-look
at this issue.
- RESOLVED: Publish WD of CSS-Nav-1
Resize Observer
---------------
- RESOLVED: To remove the constructor and remove the language about
how to populate the object into a different point in the
spec (Issue #3946: ResizeObserverEntry either needs to
have its JS constructor removed, or define how its
members are initialized when constructed)
CSS Fonts
---------
- RESOLVED: Add ui-sans-serif (Issue #4468: Add a ui-sans-serif
keyword to go with ui-serif)
CSS UI
------
- RESOLVED: Add pointer-events to css-ui level 4 (Issue #4438: Spec
the pointer-events property for non-SVG elements)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Nov/0000.html
Present:
David Baron
Amelia Bellamy-Royds
Elika Etemad
Simon Fraser
Daniel Holbert
Jihye Hong
Sanket Joshi
Brian Kardell
Daniel Libby
Chris Lilley
Peter Linss
Myles Maxfield
Cameron McCormack
Devin Russo
Jen Simmons
Regrets:
Christian Biesinger
Oriol Brufau
Emilio Cobos Álvarez
Syed Idris Shah
Dael Jackson
Manuel Rego Casasnovas
Florian Rivoal
Christopher Schmitt
Scribe: myles
astearns: We'll skip transforms and the table row issue today.
astearns: Additional changes?
fantasai: The lists-3 issue needs a concrete proposal or set of
proposals, so we shouldn't discuss it today
CSS Shapes
==========
Calculation of corner radii by margin-box and border-radius
------------------------------------------------------------
GitHub: https://github.com/w3c/csswg-drafts/issues/675
astearns: This is a small change to existing change dealing with an
edge case when margins hit 0. There was some discussion.
The person who raised the issue seems okay with the
change, as does dbaron. I wanted to have a WG resolution.
astearns: Anyone have anything to add?
astearns: The proposed resolution is we accept the change that I put
into the ED, handling the case where margin = 0 for very
small values of shape-margin
astearns: objections?
RESOLVED: Accept the change that astearns put into the ED, handling
the case where margin = 0 for very small values of
shape-margin
CSS Text 3
==========
Bidi and pre-wrap end of line spaces
------------------------------------
GitHub: https://github.com/w3c/csswg-drafts/issues/4422
astearns: Suggestion is to resolve to accept the PR
fantasai: The PR says that we do the hanging after bidi. The
implications of exactly what that results in in the test
cases in the issue depends on implementations fixing their
bidi implementation to add a rule that Safari implements
correctly. As far as the spec is concerned, we need a
clarification that the line ending trailing space is
applied after bidi.
fantasai: There are some bugs in implementation but those are out of
scope for this issue.
<AmeliaBR> The one-line PR, for reference:
https://github.com/w3c/csswg-drafts/pull/4429/files
myles: +1
astearns: This is just fine to resolve to accept the PR. Objections?
RESOLVED: The line ending trailing space is applied after bidi
Publish WD of CSS-Text-3
------------------------
fantasai: We should publish a WD. There are other issues but they
aren't about to close
astearns: This is a standard WD?
fantasai: Yes
astearns: Objections?
RESOLVED: Publish a new WD of text-3
<ChrisLilley> +1
heycam: I recall discussions about automatic allowance for
publishing WDs. Discussion maybe a year or so ago. Is that
the case?
astearns: There is the tooling in place for editors to just update
working drafts continuously. I don't recall where we as a
WG settled when we last discussed this.
<ChrisLilley> yes, you can
fantasai: I can find it if you give me a few minutes. The policy is:
If the differences since the last WD are purely in tone or
if there are specific things that the WG resolved in
(wording) then you can just publish it because it's
reasonable that the WG has consensus on it. If there are
issues that may or may not have come before the WG, or the
resolution was a general statement that had to be
translated, then we're still going to request a WG
approval for the WD publication
<heycam> thanks
astearns: For text-3, I expect there are only resolutions.
fantasai: Nope. There are minor fixes, and some general resolutions
rather than specific resolutions. It's not as clear cut.
Not everyone has had a chance to review everything.
astearns: For css-shapes, it would not have been okay to publish a
new WD until just now when I got a resolution for the
latest change that I made. Everything else I added to the
draft has a resolution
fantasai: Yes. Shapes is CR also.
AmeliaBR: If you want to review this heycam, it was a TPAC we made
these resolutions about publishing rules.
AmeliaBR: If I find the minutes I'll stick a link in
<chris> Amelia, https://wiki.csswg.org/spec/publish
<AmeliaBR> thanks Chris (probably a better reference than the
minutes, anyway!)
CSS Nav
=======
Proper definition of 'spatial-navigation-action' property
---------------------------------------------------------
GitHub: https://github.com/w3c/csswg-drafts/issues/4449
astearns: In the issue, you asked florian for an opinion. We don't
have his opinion, and he's not here.
astearns: Should we discuss this now?
jihye: I also asked another member of CSSWG about this issue. This
is general CSS questions. I think we can proceed
astearns: OK
jihye: This issue is about spatial navigation actions, and CSS
properties.
jihye: Before going into the detailed discussions, I'd like to
introduce spatial navigation actions. They are a CSS
property, which can define the behavior for a scrollable
element. The spatial navigation behavior is when a scrollable
element has focus, and the user triggers spatnav, if there is
a focusable element in the scrollable element, the focus goes
to the focusable element. Otherwise, scrolling happens.
<jihye> https://wicg.github.io/spatial-navigation/demo/sample/api_spatial_navigation_action.html
jihye: If the focus value is given to this property, spatnav on the
scrollable element only works to move. If the scroll value is
given, spatnav only works for scrolling the scrollable
element. You can see how it works with this link ^^^
jihye: I'd like to ask that if the definition of this property is
proper. Currently, the spec describes this property as "which
is applied to scroll element, and not inherited" but the
point that I'm confused about is the attempted behavior of
this property is it also affects the spatnav behavior for
children element of the scrollable element. The description
says it is only applied to the scrolled element, not all
elements. So it sounds like the property will not affect the
children element of the scrollable element, which the spatial
navigation action property is specified.
jihye: It seems like the intended behavior and the description in
the spec don't match. Is this proper or not?
myles: I thought we resolved to get rid of all the "applies to" lines
<fantasai> no, we resolved to get rid of Media Type
AmeliaBR: There was some discussion about whether it was normative
or informative. The question here is you want to change it
so the property both affects the scrollable container
directly and the children of the scrollable container as
far as how it affects whether they trigger scrolling on
the parent
jihye: I researched another CSS property which can affect its
children elements. From my understanding, that property
creates a stacking context, but that property is about
layout. But this spatnav property isn't about layout, so it
doesn't seem like a match
AmeliaBR: We don't have anything equivalent
AmeliaBR: Any other CSS property that defines whether a scroll is
triggered separate from whether a scrollbar appears on
this element or a parent element
AmeliaBR: It seems to me perfectly natural to say that this also can
work on a property on a child element and it affects the
scrollers going up. The concern then is what happens if
you have nested scrolling containers. Is there a way to
control where that scrolling affect stops? Vs if you
specifically set the property on the scroll container
itself.
AmeliaBR: Then it's more obvious what it applies to, because nothing
bubbles up like an event
bkardell: If you have focusable items ....
bkardell: As I understand it, the reason this is desirable is
because you have potentially a limited number of controls.
You don't have tab buttons and shift-tab and things like
that, so we want to define how that works with a d-pad
controller. "spatially" navigate. So you want to move
focus with those sorts of mechanisms. But in this example,
you have a scroll container that contains focusable items.
But if you use scroll, does it make it effectively not
focusable anymore?
bkardell : How would someone focus the child?
jihye: If the value is "scroll" of this property, then the focus
will not move inside or move between the child elements in
the scrollable element. But pressing down or up arrow key
will only scroll the scrollable element. If the focus or auto
value is given to this property, the child element inside the
focusable element will be focused and the focus will move
between them.
bkardell: right.
AmeliaBR: The issue isn't that you can't focus elements when you're
using the scroller thing, it's that you don't jump to the
next focusable element, you jump to the next element
whether its focusable or not, and in that way you end up
scrolling the scroll container. Otherwise, it skips the
next items and jumps to the next focusable one
jihye: Yes, that's right
bkardell: "auto" makes sense to me, "focus" makes sense to me. They
are a different experience of the same thing. But "scroll"
... do we have other CSS properties that prevent your
normal focusability?
myles: we have display:none...
bkardell: but it's not on the screen
jihye: The "scroll" value is at risk. It can be useful when there is
an iframe which can scroll but the user doesn't want to move
inside it.
jihye: But I think this is a little bit out of the topic that I
wanted to discuss.
jihye: I wanted to discuss - this property can apply to child
elements of scrollable elements. Is this proper or not?
heycam: Generally, the "applies to" line is informative and not
normative (as AmeliaBR was saying). It's just a general
description of where you expect the property to have an
effect. The behavior of scrolling will depend on the child
elements and their focusability. It makes sense to say it
applies to the scrollable element. The rest of the
definition can say what it wants about the child elements
and how they are focused.
<fantasai> yes, it's about on what elements can you set the property
to have an effect
AmeliaBR: You mentioned in the issue, if we switch to that model
where its a property of the individual elements rather
than a property of the scroller, it needs to be inherited.
AmeliaBR: It would be a normative change
myles: Can we make this match how scroll snapping works?
AmeliaBR: How does scroll snapping work?
<silence>
fantasai: scroll-snap sets something on the scroll container to
define how snapping happens, and there are additional
properties on child elements about whether that child
should be paying attention to it. <provides an example>
myles: Sounds to me that this should go on the scroller for spatnav
astearns: Another argument for putting it on the scroll container
and having it not inherit, is we might get an incoherent
set of things to do if the some subset of elements
disagree about which value is specified. Inheriting to the
children means the children can override what's on the
container.
jihye: If we match the spatnav action navigation property with
scroll snap, then we'll change the definition to say it
applies to all elements and its inherited?
astearns: I'm arguing for it to stay the way it is. Where it applies
to scroll containers and does not inherit. You can define
how the children behave as saying "look at your nearest
ancestor that its a scroll container and see what its
spatnav action is"
jihye: It means that the current definition of the spec is
reasonable and doesn't have to change.
astearns: Yes
AmeliaBR: Yes, unless you can come up with a specific example where
you'd want the behavior to change partway through a
scrollable container. I don't know what that might look
like. Where you actually want different children to have
different behaviors.
astearns: Can you think of a case where you'd have a scroll
container where some of its children would want to focus
and others would want to scroll?
<silence>
astearns: Why don't we resolve on this issue, saying we are not
going to change the definition of how
spatial-navigation-action at this point, but if come up
with a use case for making the property inherit, we can
change it at that point.
jihye: Okay
jihye: The spatial-navigation-action property behaves as defined,
and does not inherit.
astearns: Is there an issue for the scroll value? Is that why it's
at risk?
jihye: It seems like the scroll value is less important than other
values such as "auto" or "focus". This is the main reason.
astearns: bkardell could I have you take a longer look at this, and
if you have concerns about the "scroll" value changing the
focus behavior, have you raise an issue on it?
bkardell: Yes. It's been a while since I looked at this.
bkardell: In Toronto, we had David Bokan from google present an
interesting related thing. jihye, have you worked with him?
jihye: Yes, I talk with him regularly. We are investigating about
that concept. I think this concept is not mature enough. We
have to think about more details about that. We are working
on that.
bkardell: He would be good to review the question I raised. I can
talk to him
jihye: Thank you.
Publish WD of CSS-Nav-1
-----------------------
jihye: I'd like to publish a WD of spatnav. It's FPWD. There have
been changes in the spec such as adding a new API for spatnav
functions, and modifying the processing model which is the
default behavior of spatnav.
jihye: I think the spec is stabilized. It has been implemented in
blink. Also there won't be the significant change in the spec
for a while. It would be nice to publish the new WD.
<chris> +1 to publish
astearns: I think we should update the draft. Also, I do see that
there is not a "changes" section. We don't really require
a changes section on normal WDs, but it's a nice thing to
have for people who have not been keeping up.
jihye: I will add it.
astearns: Any other concerns?
chris: This will be a FPWD?
astearns: No. Regular WD.
RESOLVED: Publish WD of CSS-Nav-1
astearns: Thank you jihye for your work on this.
Resize Observer
===============
ResizeObserverEntry either needs to have its JS constructor removed,
or define how its members are initialized when constructed
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3946
dlibby: This issue is a historical oddity. WICG spec language made
it into an ED, despite it not being implemented in blink.
Gecko realized this discrepancy, and after some debate,
didn't implement this constructor. There's some conversation
about what the constructor should be because it doesn't fit
into JS. The point of resize observer is to give
asynchronous notifications when layout changes to the size
of elements
dlibby: So given that this doesn't exist in either current
implementation, it seems worth removing from the spec and
updating the language in a different section about
implementation details of how a browser would populate a
resize observer entry at runtime
bkardell: There's an implementation in webkit as well.
dlibby: I'll check it
smfr: Is there a WPT test?
dlibby: No.
AmeliaBR: Seems easy to remove this from the spec. If there is
desire for it later, add it back in.
AmeliaBR: But it doesn't seem like we're blocking anything for the
future to remove it for now
astearns: Anyone want to argue for keeping it in?
RESOLVED: To remove the constructor and remove the language about
how to populate the object into a different point in the
spec
CSS Fonts
=========
Add a ui-sans-serif keyword to go with ui-serif
-----------------------------------------------
GitHub: https://github.com/w3c/csswg-drafts/issues/4468
AmeliaBR: With the new ui- font family keywords. Based on the
resolution, we had ui-serif, ui-monospace, and ui-rounded
keywords. ui-sans-serif wasn't initially added because the
system ui fonts of current systems are all sans-serif, so
we didn't need a new keyword
AmeliaBR: Logically there's nothing in system-ui that says it must
be sans-serif, and in the future, system-ui might be
serif. A more logical system would have ui-sans-serif
keyword, so if you care about it, you can specify it
explicitly, vs system-ui gives you the default system font
regardless of its styling. In most systems these would map
to the same font
chris: I agree it's currently not like that, but it could change in
the future
chris: I agree with this suggestion
<fantasai> +1 to proposal
chris: We've already clarified that these names can all point to the
same thing
myles: Mildly against this just because it's building infrastructure
for a computer that doesn't exist
astearns: I can see the future possibility, we could add the
additional keyword when it becomes necessary.
chris: But people will use it in the interim to mean sans-serif will
be surprised.
astearns: I'm not sure people aren't already going to make that
assumption regardless of another keyword
fantasai: But this means they have to make that assumption
chris: It lets authors be more precise
fantasai: If we don't add this, then they have to make the
assumption. If we add this keyword, they don't have to
astearns: I'm not strongly opposed to adding it
plinss: I have slippery slope concerns here. It sounds like we're
re-inventing things we had in the 90s. <lists many system-
prefixed font names like dingbats and swashes>
AmeliaBR: We've already made the agreement on adding a set of
stylistic system fonts. Do we acknowledge that system-ui
is by default a sans-serif, or do we include a sans-serif
in a stylistic set of keywords
chris: The people arguing against this are arguing against the
keywords in the first place
plinss: I don't think it should be serif or sans-serif
chris: Yes, system-ui shouldn't include that. But we've already got
ui-serif and ui-monospace. Those are 2 of the generic font
families. I don't think anyone is asking for more
plinss: People will ask for stylistic, semantic implications, one
being used for body text or headings ... again, it seems
like it's going to get out of hand. Not a strong objection,
I'm just concerned
chris: I can understand that.
astearns: I'm not a big fan of ui-serif and ui-monospace, but we
have decided to add them, and I'm somewhat convinced by
the argument that, since we have ui-serif, we should also
have ui-sans-serif to future-proof
plinss: We shouldn't have ui-serif in the first place. The
connotations of what it means will change over time. I don't
see how that's getting you anything
plinss: ui-monospace has a functional difference.
astearns: Does anyone want to really object? Or shall we put it in
for now?
<silence>
<fantasai> I think given we have ui-serif/ui-rounded/ui-monospace, I
think it's important to have ui-sans-serif
astearns: The proposal is to add ui-sans-serif (as a sibling to
ui-serif)
astearns: Sounds like we're leaning toward it.
astearns: Objections?
plinss: I'd like to reconsider ui-serif
astearns: Oh, certainly, we can re-litigate adding the pair of them,
but if we have one, the proposal is we should have the
other.
plinss: I agree.
chris: Do these set size and style as well?
AmeliaBR and myles: no
RESOLVED: Add ui-sans-serif
CSS UI
======
Spec the pointer-events property for non-SVG elements
-----------------------------------------------------
GitHub: https://github.com/w3c/csswg-drafts/issues/4438
AmeliaBR: The pointer-events property defines whether an element is
clickable or not. If something has pointer-events: none,
it's treated as transparent for clicks and you can click
through it for whatever's underneath. It's not defined in
any CSS spec. It's defined in SVG, which also has lots of
extra values that relate to fill areas or stroke areas are
clickable and other variations
AmeliaBR: The reason to discuss this is we got a bug report on SVG
complaining that a particular behavior wasn't defined, and
that behavior wasn't SVG-related. It was about CSS boxes
and stuff that wasn't SVG related. So, what about writing
up a spec for pointer-specs?
chris: SVG would be happy to see it turn up in another spec, so they
can delete it from theirs
AmeliaBR: One thing that chris did discover when we were discussing
it, there was a spec text in CSS-UI that got pulled when
trying to stabilize that spec because speccing out the
actual details turned out to be complex. It seemed to have
been pulled and never reappeared in a later draft.
Speccing it won't be nice and easy because we have lots of
legacy behavior
chris: This is widely implemented
AmeliaBR: We have lots of implementations of a property without a
spec. But we should still do it, difficult or no
<heycam> +1 to moving pointer-events to css-ui
chris: This is valuable by itself to define what pointer event
handling is for CSS
astearns: Since the editor of css-ui is not on the call, we can pile
it on him
astearns: But, chris, you mentioned SVG would like to delete it ...
you'd only be deleting a tiny part of it, because all of
those other values would still be an add on for SVG
chris: They would until css-fill-n-stroke. So those parts would move
there
astearns: I would expect that the current work that we are proposing
for css-ui would only be the currently supported values.
AmeliaBR: That sounds like a good strategy. The SVG spec would
continue to be a partial definition adding in the extra
values.
chris: Yes. which is fine.
fantasai I do what I can
astearns: Anyone concerned about defining pointer-events in a CSS
spec?
RESOLVED: Add pointer-events to css-ui level 4
AmeliaBR: One final note: The first step is going to be putting
together some tests to understand existing behavior and
compatibility issues. If anyone wants to take the
initiative to look at their implementation, that would
be great
AmeliaBR: We only have parsing tests in WPT
astearns: Thanks everyone! Next week is a non-APAC time.
Received on Thursday, 7 November 2019 15:55:21 UTC