<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

[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.
... 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

[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.
... 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

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?

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

[css-nav-1] 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.
... 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.

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.
... 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.

ResizeObserverEntry either needs to have its JS constructor removed, or define how its members are initialized when constructed

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

[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
... 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

[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
... 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.

end of meeting

<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.)