<florian> Today (October 9th) is Hangul day. Let us all celebrate this very ingenuous and beautiful writing system.

astearns: For first topic I believe we need emilio or another firefox person on the call

<scribe> scribenick: dael

astearns: I think we have enough to start
... As always, are there any changes to the agenda?

<smfr> present_

astearns: One change, we can't usefully do item 5 unless we get some extra people on the call
... Other changes?

propagation from body to document element is annoying

github: https://github.com/w3c/csswg-drafts/issues/4357

astearns: Who wants to lead?

[discussion about if emilio has audio]

github: none

Should automatic list-item increment adjust for ol[reversed]?

github: https://github.com/w3c/csswg-drafts/issues/4181

<emilio> now does

github: none

propagation from body to document element is annoying

github: https://github.com/w3c/csswg-drafts/issues/4357

emilio: We resolved hesitantly on prop. the used writing mode from body to document element and to viewport I assume
... We have an impl but afaict other engines are not ready to impl since don't store value in layout tree
... Resolution is hacky to impl.
... Should we implement this? Do what other engine impl which is just prop to viewport? And tell people if they want orthogonal set on document element

florian: Discussion on GH is this looks hacky but doable in Blink as well. Given we resolved there is some willingness to do this. If not, I wonder why we resolved. We can reopen but it's unplesent. If can do in blink and FF and we're moving the spec forward and it's nicest for author I would hope keep as is
... If people not going to do it you're right it's not helpful for spec to say one thing and do another

emilio: This is only thing that prop to document element, right?

florian: propagation on other things is a bit complicated but less so. Only thing that propagates in this way

emilio: AS gecko dev I'm not in lovewith hack. Easier to propagate to viewport. Happy to impl if other engines will do it

fantasai: In WM we wanted ot make sure it's prop in same way as direction. Means spec was not quite correct in way direction prop.
... Adding writing modes and direction need to prop together. Iunderstand how hacky it is, Blink solution sounds pretty crazy. I think prop was a mistake, but it happens so have to address. Doens't have to be perfect.

emilio: Direction in gecko does not prop at all, only have hack for scrollbar directionality and that would not be needed if both prop to viewport
... Blink prop to the viewport is to fix the same case and the hack for look up body style from scrollbox is doing.
... Intent is same, behavior is different as is impl complexity

florian: Would like to hear from blink. WE can investigate ideal. It's hacky but doable in gecko. If blink will do we don'th ave to revist. We have discussed preferable behavior.

emilio: But it was on assumption direction was prop somehow. But in blinka nd webkit it is prop with writing mode to viewport. In gecko there'sno prop, just lookup a box for this style

florian: I suspect that's if you fix bugs related to printing you'll have to do it there as well.

emilio: Sure, but scrollbar position....that also works if you prop writing mode to viewport

florian: Direction only not prop to document element is fine. But direction if you don't go through element you create horizontal flow and tha'ts not nice. Ideally for authors we prop the whole thing properly. If can't do that there are intermediate solutions.

fantasai: I think important point that page progression direction and frag direction needs to be consistant with how modify scrollers. That doens't require us to change the root element
... Means content will overflow root, but in a direction we've choosen. Similar to how the root element in the scrolling case doesn't grow to accomodate the content. Solveable but important to solve

florian: If we jsut prop to viewport it's workable but less nice for authors

Rossen_: That solution will be commonly hit by authors bc most tools set direction on body rather than root element
... When orginally disc I was in full support as documented in spec and that's the behavior in Edge where we prop from body to root and all the way to viewport. Allows us to avoid all these corner cases of root element and body element differing by writing mode and causing scrollbars
... Unless explicitly set rules elsewhere that set different writing modes explicitly
... In our impl it wasn't crazy to impl given we're kinda sorta doing it in overflow. I looked at blink and what I desc is impl there. I don't know if we have resources right now, but wouldn't be opposed to giving that a go and having better results for authors as we have desc
... Doens't mean I'm saying I'll def land it in blink, saying not opposed to landing.
... Looking at rune's comments on GH he's not crazy about it but doens't sound against. Don't want to speak for him/chrome, but looking through what's needed and what we spec that matches what as an author I would expect to see happen

emilio: I'm okay closing no change if this is eventually impl interop

astearns: sounds to me that yes impl is hacky but people are willing to change. Given author benefit I think we close no change and wait on impl
... Objections?

RESOLUTION: Close this issue no change

astearns: Thanks emilio for bringing this up

Should automatic list-item increment adjust for ol[reversed]?

github: https://github.com/w3c/csswg-drafts/issues/4181

fantasai: There was a request from someone to discussed resize-observer earlier in the agenda

github: none

[agenda discussing]

device-pixel-border-box size

github: https://github.com/w3c/csswg-drafts/issues/3554#issuecomment-538465771

astearns: Discussed device-pixel-border-box size at TPAC
... I recall we still weren't sure how change will effect Safari. Example have now been provided. Do we have enough information on impact to Safari?

smfr: Saw a couple of examples. I think Chris said he ran the tests on Macbook pro retina with the fixes and it made it look better. Can't say without doing work in webkit, but I think sufficient proof this is useful. On non-apple it's well known it's necessary

astearns: Any other new information?

chrishtr: Nothing new except demos and version of chrome that fixes

smfr: I'm surprised you could get good results. Most macbooks have default scaling. Surprised you got good results on a machine with that behavior

chrishtr: It's not the newest

<drousso> presnet+

[audio problems

chrishtr: Tested on not absolute newest, but a macbook pro retina. I think it does have value and OS scaling if it's outside of control of application those situations can't be fixed

smfr: What I'm interested in understanding is if on hardware with builtin scaling suc htat you never get pixel perfect is there improvement in device-pixel-border-box ? Is there value in making it optional and allow UA to not provide if it thinks it can provide better. Or do we make it required and force UA to do this when it's not going to get better

myles: Easy to test if you change resolution of OS in your macbook pro

astearns: Sounds to me like we don't have an objection to adding device-pixel-border-box size to the API, but may want another issue about behavior of API possibly making it optional?

chrishtr: Would app fallback be multiply css pixel width and height by device-pixel ratio if UA doesn't supply?

smfr: Impl will alreayd have to multiply by device-pixel-ratio. No, does multiply. Okay.

chrishtr: That was the point, rounding or flooring can't get consistent

smfr: Okay, then makes optional thing annoying

chrishtr: I don't know if built in scaling is higher quality but we got really good results on macbook pros even with non-1 to 1 scaling.

smfr: Okay

s/ chrishtr / ken

smfr: Not objecting to adding. Question if needs to be rectangle or just a size since left and top don't mean anything

chrishtr: Use case for canvas sizing top left not nec

smfr: We don't have a dom size object

chrishtr: Yep. More consistent to have a rect, rect does have meaning. Not used in canvas case

myles: Position of rect a little confusing if you consider overflow area

chrishtr: Does mean where it is on device window though
... It's used within the native texture if there's not special scaling smfr referred to. If texture is scrolled it's still...it doesn't take into account transforms and scrolls

myles: Values off the top of the screen?

chrishtr: I think would be fine to have size only for this reason
... top left doesn't seem to mean much, want to know canvas size

astearns: Array of 2 values or are you minting a new size object?

chrishtr: I don't know. Maybe new size object?

smfr: If it always integral?

chrishtr: Yeah

smfr: Maybe you jsut have two long on the entry

chrishtr: THat are just width and height
... As relates to desire to add the eq method to getBoundingClientRect it would change to get device pixel width and height

smfr: If we agree to resizeObserver do we still need?

chrishtr: Don't think so, but Jeff Gilbert from Mozilla thought case was strong so I was okay adding

smfr: Which case was it?

chrishtr: You have a full screen where you don't want resizeObserver and you want a slight jump on resize frames

ken: Jeff also had concerns that it fires late and application would fall behind a frame which is legit concern

myles: You would need to execute heavy calculations every frame with this. resizeObserver means code only called when need to be.

ken: Agree, but in experience from a dev on FF stack we felt it was important to aleviate concern. And FF intends to not recompute if layout isn't dirty

smfr: I don't want every getBoundingClientRect to be more expensive

chrishtr: Adding a new thing

smfr: Okay, okay. Should discuss sep.

chrishtr: Okay with me. Is Jeff Gilbert on? Want ot make sure he's okay to separate.
... If he's not, maybe tentatively do that.

ken: I think Jeff would object. Not to represent his opinion, but I think he would.

chrishtr: Great to resolve device-pixel-border-box size makes sense and then follow-up on the other one
... To make progress.

ken: Want progress too

astearns: smfr you would rather continue new API discussion or resolve to add it and continue discussion?

smfr: Prefer to fork into separate issue

fantasai: Question, says doing device-pixel-border-box size. What if person wants size of padding or content box?

chrishtr: Those other boxes have use cases and tracked via other issues on the spec

florian: But not at device pixel level the others

chrishtr: No. Only use case for device pixels is canvas

fantasai: But why wouldn't people using canvas want to paint inside the border?

<AmeliaBR> Wouldn't it be the content-box that is important for the canvas? Since that's what they're using in their code?

chrishtr: Canvas has a certain size and border is outside of that. Browser does that for you.

fantasai: boder box size includes border so if it's not included it's not a border box

chrishtr: It's the device pixel box size in case of canvas. It's actual size of canvas

fantasai: Then it's the content box and we should call it that and not border box

chrishtr: Right

<Zakim> fantasai, you wanted to ask about padding/content boxes

ken: Sounds good

astearns: Other discussion?

fantasai: Summary of proposal?

astearns: Add an API to get canvas height and width to resizeObserver

chrishtr: Actual device width and height of the canvas. When changes resizeObserver fires.

fantasai: I want to be clear. Adding and API which is only available on canavas element. Reflects pixel size of content box of canvas element
... And it has a name that is not device-pixel-border-box

chrishtr: Yes

smfr: Available for any element you resizeObserve not jsut canvas

fantasai: Have had various discussion on only canvas or all and want to be clear

chrishtr: Only use case I know is canvas. Could do it for all

smfr: I wonder if this should be something the user of the API request.

chrishtr: For any API you ask for what you want and you're saying only available on canvas?

smfr: ONly want browser to do computation if author asks for data

chrishtr: For sure. Part of draft spec to observe multiple types of boxes. You say what to observe. I agree browser should only do this if needed

astearns: Further question of if someone requests this on not canvas what happens

chrishtr: Allow or not allow is both okay. In terms of APIs implicity maybe better on all

smfr: Can imagine on something like video. Better on all

chrishtr: No impl difficulty from allowing it

fantasai: Add API to get content box height and width in device pixel sizes to resize observer. ONly return when requested and applies to all.

chrishtr: Can bikeshed name

florian: Not obj, but want to be cautios on all elements. pixels vs device pixels people can get confused about and I have mild concern making this too easily available people will try and use it.

astearns: A lot of things discussing now should be separate issues once we have draft text in place.
... objections to adding this?

RESOLUTION: Add API to get content box height and width in device pixel sizes to resize observer. Only return when requested and applies to all element.

astearns: Thanks chrishtr

chrishtr: I appriciate all the feedback

ken: Thanks for discussion

fantasai: Want to discuss optionality

astearns: Add an issue for that

Should automatic list-item increment adjust for ol[reversed]?

github: https://github.com/w3c/csswg-drafts/issues/4181

<fantasai> https://github.com/w3c/csswg-drafts/issues/4181#issuecomment-522196318

fantasai: Where we are is in this comment ^
... Given TabAtkins isn't here maybe not now

github: none

Allow breaking anywhere when dictionary is missing for SEA scripts

github: https://github.com/w3c/csswg-drafts/issues/4284

fantasai: Certain lang where breakpoint not obvious from character code. hvae to do analysis. If you do not have the dictionary or rules in the engine you don't break the text and it'll be long and overflow. I suggest saying if you don't know how to break then you should break somewhere. Doesn't matter where but between grapheme clusters. hvae to have break opportunities

myles: Did you mean must?

fantasai: Yeah
... Proposal to add that. Discussion in issue about where to break in languages, but this is about what to happen when UA doens't have rules.

florian: I think saying you must break somewhre and not middle of grapheme cluster. If you can do mid analysis with meaningful unit of breaking do that. But must break and not break grapheme closters

myles: How does browser know which scripts?

fantasai: THere's a classification, let me see.

<fantasai> http://unicode.org/reports/tr14/#SA

fantasai: Class SA is complex context dependant. If you're one of these scripts and don't have a resource to tell you where to break you should break somewhere

myles: As long as spec says that this is fine

fantasai: Okay

astearns: Other concerns?

fantasai: Prop: If there is a language for which you do not know the breaking rules. Rather then treating as unbreakable you treat it as breakable anywhere

astearns: And something about not breaking through grapheme cluster?

fantasai: Yes. If we copy from overflow: anywhere that comes

RESOLUTION: f there is a language for which you do not know the breaking rules. Rather then treating as unbreakable you treat it as breakable anywhere similar to overflow:anywhere

`grid-template-rows/columns` Computed / Resolved Values for 'subgrid' values

<fantasai> https://github.com/w3c/csswg-drafts/issues/4362

github: https://github.com/w3c/csswg-drafts/issues/4362

fantasai: Just accept Mats proposal

astearns: Opinions?

Rossen_: Wish I had time to read it.
... This doesn't sound like something needed right now. Resolve next week?

jensimmons: Can fantasai explain and then Rossen_ you can feel you understand? I don't want to postpone because we're trying to ship subgrid

fantasai: Issues is when getting resolved value, value from gCS, what that value is not well defined. Regular grids resolved value expands all repititions so you have number of tracks/columns. Mats proposal is same for subgrid but don't include length b/c that's not valid value.
... You would say subgrid and then a list of all the line names.
... Example in the bottom makes it clear

Rossen_: In this way it will be...subgrid columns will be serialized as part of grid col?

fantasai: grid-template-columns is property, subgrid keyword. Optional line names which are matched up. Can use repeat notation

Rossen_: Grid-template-columns would resolve to what he suggests in very last sentence?
... Is that the expected behavior?

fantasai: Yeah
... WE do the same thing as for regular grids, but we don't specify sizes in resolved value. Otherwise same rules for expanding repetitions

Rossen_: Going through examples to figure out if it's lossy for what you can reconstruct

fantasai: It is lossy in same way as current without subgrid. We return resolved style, not computed.

Rossen_: I'm trying to figure out if it's more lossy, but seems about same

fantasai: Yeah

Rossen_: Doesn't sound bad

fantasai: Alternatives is to fill in all sizes, but then can't read it back in. Want it to roundtrip

Rossen_: Agree

fantasai: Other is to not unwrap but that's inconsistent with regular grids.

Rossen_: Yeah. That would have been my pref but we are where we are.
... This seems consistent. Not opposed

astearns: Prop: Accept Mats' suggestion which preserves consistency with the rest of grid but allows subgrid values to roundtrip

fantasai: Prop: Accept Mat's proposal which is that resolved value unwraps repeat notations and does not insert track sizes for subgrid

astearns: Objections?

RESOLUTION: Accept Mat's proposal which is that resolved value unwraps repeat notations and does not insert track sizes for subgrid

publication

fantasai: Related topic, this is only issue on subgrid. I suggest we go to CR in the next week or two.

Rossen_: Yay!

astearns: Alright, fair warning.

end

astearns: Thanks everyone for calling in.

<jensimmons> ya subgrid let's ship it!

<jensimmons> anyone else? webkit? chromium??

<jensimmons> ship it!

<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/??/chrishtr/
FAILED: s/ chrishtr / ken/
Succeeded: s/ken/myles/
Succeeded: s/objection/object/
Succeeded: s/??/Jeff Gilbert/
Succeeded: s/executecode/execute heavy calculations/
Present: dauwhe florian dael antonp Rossen_ jensimmons oriol emilio smfr chrishtr myles sanketj drousso
Regrets: tantek
Found ScribeNick: dael
Inferring Scribes: dael

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 09 Oct 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.)