<scribe> ScribeNick: myles
astearns: We'll skip transforms
and the table row issue today.
... Additional changes?
fantasai: The lists-3 issue needs a concrete proposal or set of proposals, so we shouldn't discuss it today
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.
... Anyone have anything to add?
... 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
... objections?
RESOLUTION: accept the change that astearns put into the ED, handling the case where margin = 0 for very small values of shape-margin
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.
... 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?
RESOLUTION: the line ending trailing space is applied after bidi
RESOLUTION: the line ending trailing space is applied after bidi
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?
RESOLUTION: Publish a new WD of text-3
heycam: I recall discussions about automatic allowance for publishing WDs. Discussion maybe a year or so ago. Is that the case?
<ChrisLilley> +1
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 sicne 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
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.
... If i find the minutes I'll stick a link in
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.
... 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
<chris> Amelia, https://wiki.csswg.org/spec/publish
jihye: This issue is about
spatial navigation actions, and CSS properties.
... 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 af ocusable
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 ^^^
... I'd like to ask that 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 teh 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?
<fantasai> no, we resolved to get rid of Media Type
myles: I thoguht we resolved to get rid of all the "applies to" lines
AmeliaBR: There was soem 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 ont he 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
... Any other CSS property that defines whether a scroll is
triggered separate from whether a scrollbar appears on this
element or a parent element
... 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.
... Then it's more obvious what it applies to, because nothing
bubbles up like an event
bkardell_: If you have focusable
items ....
... 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.
... But I think this is a little bit out of the topic that I
wanted to discuss.
... 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.
... 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 argumetn 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 inherite. 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
... 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.
... 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.
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.
... 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.
RESOLUTION: Publish WD of CSS-Nav-1
astearns: Thank you jihye for your work on this.
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
constructorThere'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
... 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.
... 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?
RESOLUTION: To remove the constructor and remove the language about how to populate the object into a different point in the spec
GitHub: https://github.com/w3c/csswg-drafts/issues/3946
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
... 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
... I agree with this suggestion
<fantasai> +1 to proposal
chris: We've already clarified that these names can all point to the same thing
<fantasai> 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 coudl 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 ahve 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 keywrods
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-monospaced. 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.
<fantasai> Note, it's ui-monospace not ui-monospaced now
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
... 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)
... Sounds like we're leaning toward it.
... 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
RESOLUTION: add ui-sans-serif
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
... 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 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
... 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.
astearns: Anyone concerned about defining pointer-events in a CSS spec?
RESOLUTION: 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
... We only have parsing tests in WPT
astearns: Thanks everyone! Next week is a non-APAC time.
<astearns> trackbot, end meeting
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/<missed>/David Bokan/ Succeeded: s/destructor/constructor/ Succeeded: s/didn't implement this destructor. /didn't implement this constructor/ Succeeded: s/astearns: We shouldn't have/plinss: We shouldn't have/ Default Present: ChrisLilley, dbaron, smfr, dlibby, plinss, bkardell_, AmeliaBR, heycam, jensimmons, fantasai, drousso, jihye, sanketj, dholbert Present: ChrisLilley dbaron smfr dlibby plinss bkardell_ AmeliaBR heycam jensimmons fantasai drousso jihye sanketj dholbert Found ScribeNick: myles Inferring Scribes: myles WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 06 Nov 2019 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]