Cascading Style Sheets (CSS) Working Group Teleconference -- 18 Mar 2020

<scribe> ScribeNick: dael

astearns: Thanks to everyone who called in on time. We'll wait a bit to get a few more people
... I think we have enough people
... Does anyone have any changes to the agenda?
... One thing I wanted to start with is we'll have a virtual meeting at the end of next month

<jensimmons> good idea astearns

astearns: might be good to have a dry run in the next week or two. Perhaps pick a spec that has issues that need in depth and schedule an hour that works for people involved and try out the technology
... Think about your specs and one that could use the extra hour of focus and I'll start a thread on the private list. Then we can figure out how the virtual meeting will work

[css-align][css-grid] Do grid items that have "no baseline set" participate in baseline alignment?

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

astearns: Is TabAtkins on?

<TabAtkins> ah dang, one sec, totally forgot what day it is because time isn't real any longer

<jensimmons> That will also give us a chance to test our choice of technology. I was just on a Zoom meeting with 600 people, and it held up really well.

<TabAtkins> but also: because of that, i once again forgot to dive into this issue

github: none

[css-color-adjust-1] background-color in forced color modes needs more than a simple unset

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

Rossen_: I think fantasai has this one to resolve on the edits I suppose

astearns: lajava put this on the agenda
... Wait, wrong link

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

astearns: Yes, last comment is fantasai going over actual edits.

fantasai: We were talking about forcing the colors other than alpha channel to be canvas text but we don't use canvas for every item. Example input element.

<fantasai> https://github.com/w3c/csswg-drafts/commit/cffce2008ce030f4b098aece82b95c109485594f

fantasai: I wasn't clear on that case. I spec UA stylesheet has no bg color rule then we force everything to canvas text. If it does have a rule then we revert hte author setting away. Edits here ^
... I wanted to check b/c it's a weird case but I didn't know what else to do that would work

AmeliaBR: There are 2 things we need to factor in
... One is if the custom layout and stylesheet of the website is designed with overlapping content that requires opaque we need to keep that. If transparent keep that
... Other is bg color in forced color have particular pairs. Regular canvas and text for main, buttons and inputs have other pairs
... I'm not sure whether this would fix both those cases. BUt those are the two trying to address

fantasai: If you want to do this 100% right for most elements you force to canvas but elemnts inside button you fore to button bg. But that's really tricky. But because buttons don't have much in them, decided not to worry about that complication

Rossen_: What you desc sounds concerning. We can't be dependant on composition or layout while deciding computed value

fantasai: Right

Rossen_: Which is how I heard you desc

AmeliaBR: I wasn't suggesting browser look at layout. Suggesting browser respect if author styles have opaque background. Important b/c overlapping content

fantasai: What I didn't want to do...what we could do...what is in the rule handles that for everything except things like buttons. Force all channels other than alpha. For buttons and input fields I didn't put that b/c seemed harder to calc what's going one. Easier to revert in those cases. B/c don't have complext things if button is semi-transparent no it's opaque

AmeliaBR: Where rule will fail is element inside a button where for whatever reason it's expected to be opaque but the UA stylehseet won't have a rule for a SVG inside a button, just a rule for the button. As written that case would ge canvas bg which wouldn't be appropriate b/c foreground for the span is the buttons
... Instead of making the switch based on if there's a UA rule could we make this a special bg color being a special keyword that means find opposite of foreground using sytem color pairs? We have defined pairs in system colors, opposite of button-text is button-face. If we could define that tbe bg color in these cases is based on look up current color and calc proper bg from that

fantasai: Only works b/c reverting color right?

AmeliaBR: Right, after revert so color gets forced color for text of that element

Rossen_: Perhaps this is desc different forced color scenario then one for windows? Not sure how foreground color is differnt from text

fantasai: First go through an do revert rules. As result you've reverted color so doc is canvas-text and button is button-text. That's done and colors have inherited through. Span inside a button is also button-text.
... Now try and figure out bg. bg says we'll take colors spec and set all non-alpha channels to be the color that is the bg associated with the current color. If we're in the doc in a span we say what's the color and color says I am canvas-text and so pairing is canvas and we force to canvas color
... Button says it's button-text to background color forces to button-color.

<emilio> (sorry, forgot about timezones)

fantasai: AmeliaBR is doing a interesting cheat b/c color is inherited which color you force to needs to be inherited. b/c color is inherited taking advantage of that.

Rossen_: Thank you for explaining.
... Is this desc a different feature, though? On windows sets both bg and foreground. So can only have colors choosen by user

fantasai: Yes, that's what happens but doing color calc first and then do background based on that

Rossen_: But bg color is also provided why need to compute?

fantasai: Element inside a button. Span in a button what bg do you use?

dbaron: One other concern with what I think prop is is while good practice is to set on same lemenet, might in reality set colors on a decendant of background. Even though color inherits setting the backgorund might not be reliable

AmeliaBR: SHould be effected by general color property reverting rules.
... To address Rossen_ concern is the difference between this and MS browsers is wanting to support the situation of elements in userstylesheet that have opaque but don't have opaque in UA. That's where complication comes from. Pop up that's outside borders of button or custom inputs that do something a little different then UA stylesheet and you need an opaque bg browser needs to know what opaque bg to give that element

fantasai: I think the concerns is elements in author stylesheet with opaque

AmeliaBR: Yes, sorry

fantasai: Back to beginning. Base set of rules is instead of reverting bg we wanted to address elements that have an opaque bg in author and you want to make sure everything is right in forced color. Decided to have all bg match canvas but keep alpha channel. THat doesn't work for things like button or input. So we needed to do something for those since can't force to canvas-text
... One prop is UA needs to know what's not canvas bg and force those to what supposed to be. In button it forces to button bg. Input tp field bg.
... Problem with this is that if you have element inside the button that has a bg that element isn't registered in UA stylehseet as special bg and forced to canvas. Might not be right when it's on a button. B/c it's opaque we change to canvas which is white and then we have a button with a white backgrond so it's white text on white button and unreadable. THat's what AmeliaBR tries to fix

emilio: Looks like FF. For color and bg we have revert and if nothing reverts we set to initial. DOn't preserve alpha but could

fantasai: What I put in spec is assumption that opaque in buttons is not a thing we want to worry about. For elements with bg in UA stylesheet UA knows that and reverts and doens't modify alpha channel. We could decide we don't want to solve the problem or we can use AmeliaBR trick

AmeliaBR: Would people feel better if we wrote text and came back?

astearns: I was about to suggest that. I think it's getting a bit circular. SOunds like not talking about reverting but an additional trick

AmeliaBR: Changing fantasai edits from a week ago

astearns: Modify, not revert

fantasai: Doesn't change behavior of base cases, but changes mechanism to get behavior

astearns: Let's go back to issue. AmeliaBR you can write up your alternative text and we can come back on another call after people can take a look and then we can decide if we want to change

chrishtr: May I ask for examples?

AmeliaBR: Sounds very good

[css-color-adjust-1] User origin !important vs. forced colors mode

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

fantasai: The spec says we add revert !important at user level to wipe out author level. Also reverts entire user level of cascade
... I think intent was leave user styles.
... If we want to do that correctly need origin between user and author. Sort of have this which is non-css presentation layer. It's beginning of author and has no spec

<dbaron> could these rules just be in the author level (at the top)?

fantasai: We could define there's a new UA control layer called presentation-hints and importance is between user and author and then it works as intended. Or we can do something else. Currently spec doesn't work as intended

AmeliaBR: If we can explain behavior using source order; say this is inserted at origin before any other rules at origin; I think that's easier than new cascade origin. If that doesn't work then define it explicitly

fantasai: emilio says they treat all author level as revert so we can spec that way.

astearns: Is this something where we have more tools to solve when we get to custom origins prop?

fantasai: No b/c need to revert...revert in author needs to revert non-css presentaiton hints. So we can create a new origin or do what emilio says FF is doing

astearns: Set of properties?

fantasai: [missed]

emilio: I don't understand why revert !important wouldn't work at end of author. Might be easier to spec that way. In practice I think the obserables are same as FF.

fantasai: I'm happy to put in FF behavior

astearns: Any concerns with specify FF behavior?
... Reading emilio comment: Treat author level declarations with a set of properties as revert

fantasai: 3 solutions. Creat new origin

<fantasai> 1. Create new origin between author / user origins

<fantasai> 2. Insert 'revert !important' rules in author orgin with highest possible specificity

fantasai: I think 3 is what emilio is saying FF does

<fantasai> 3. Rewrite all author rules for affected properties to specify 'revert' instead

fantasai: All of those would work. I don't have an opinion between.

astearns: I think 3 is easiest to explain to authors. Just my personal opinion

fantasai: That's a vote for easy to explain and a vote from FF it's easy to impl

Rossen_: I think #3 makes sense

astearns: AmeliaBR okay to you?

AmeliaBR: Yeah. So long as clearly defined.

astearns: Prop: Option 3- Rewrite all author rules for affected properties to specify 'revert' instead
... Objections?

RESOLUTION: Option 3- Rewrite all author rules for affected properties to specify 'revert' instead

astearns: Thanks emilio for adding FF behavior

[css-inline] initial-letter should allow zero sink?

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

astearns: Are myles and Dave on?

myles: It seems clearly valuable given examples and impl shouldn't be hard. Seems good

astearns: Did you see my last comment on details?

myles: I can do that

astearns: Basically we have rules about where things get pushed below and initial-letter. Just need extra details for this case. Where line is pushed and size of initial letter. I'm asusming size for initial is 15 with a 1 line drop which should be same size as with 0 line drop. Measuring from line below initial instead of next to
... Accomodations for descenders needs an extra bit to avoid colliding

fantasai: Have rules about descenders that would continue to apply

astearns: Need to have rules for this spec text

myles: I think I'm with fantasai that both cases size and descenders are both present when sink is not 0 so we should make the solution general to apply to all sinks

astearns: In agreement. Just in my reading doesn't seem to cover all cases so want to make clear consistent sizing and descendar
... Obj to allow sink of 0 for initial letters

RESOLUTION: allow sink of 0 for initial letters

[css-backgrounds] 'border' shorthand resets 'border-image' but can't set it

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

fantasai: I don't have any idea what we can do about this other then going back in time to change. I think there's logic behind behavior and we dont change it now

TabAtkins: Agree. Change would make shorthand unusable. I think it's won't fix

astearns: I don't think not usable, but not useful addition to the shorthand
... Prop: Close as won't fix for lack of ideas on how to properly fix it. If someone comes up with a workable idea we can re-open
... Concerns about closing won't fix?

RESOLUTION: Close as won't fix for lack of ideas on how to properly fix it. If someone comes up with a workable idea we can re-open

[resize-observer-1] physical, rather than logical, dimensions – for images

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

fantasai: Someone posted a strong use case to return phsyical dimensions. Prop is add phsyical to what resize-observer can return. Use case makes sense and we should do this

iank_: Use case is? How will they use this?

astearns: By my reading the block and inline size in a flow that is orthogonal to an image's useful orientation doesn't really help
... Though in reading htis I'm a little confused as to if you know that's the case why you can't just flip the sizes you get. Are there cases where you don't know if block directio is useful?

myles: Spec that canvas rotated in veritical?

fantasai: NOt rotated. If he wants width of image he has to switch based on writing mode so he needs to switch to decide if he wants inline or block

iank_: No objections to adding but it's not explicitly a use case since it doesn't say how he's going to use information

fantasai: You can ask him for more details

myles: In agreeing with iank_ another solution solved by this would be not return logical and only physical. Need some information to know that both is better than just phsyical

fantasai: We're already returning inline & block size. It's just that on image you then need writing mode

astearns: I don't think we can remove inline and block size and return something else

myles: Not clear to me canavas is used enough that it's a problem to change behavior

fantasai: Shouldn't return different APIs depending on the element.

astearns: Hearing a little concern about adding something that may or may not be useful given data. Do we need to go back with code examples or request more information?

dholbert: Also asking if they want to observe it or have it returned. From sketch is seems logical size isn't changing but physical is

AmeliaBR: Wouldn't they change at same or observing from change of writing mode?

dholbert: When writing mode changes they want notification? Not sure

AmeliaBR: Trickier. Observing size has changed and adding 2 entries to dictionary is straight forward. Changing what triggers observation is more complex

astearns: We have some questions and poster offered a more fleshed out use case so let's ask for more details on these questions.

[cssom-view] Let offsetWidth / offsetHeight report actual size?

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

TabAtkins: I'm confused on this issue. Thanks for digging up issues fantasai . According to the eample script and I verified Chrome. FF it repots offset of A is 40x40 but that's the div child. Chrome doesn't. It has 2 boxes surrounding hte div and b/c whitespace is collapsed the boxes are 0x0.
... Haven't done spec diving to see if it allows A to report div as size. I think Chrome and Wk is correct here and we close no change

AmeliaBR: Do you have link to spec that says block inside inline isn't counted as part of inline dimensions

TabAtkins: Yu return size of first layout box. A element starts with inline that has whtiespace only

AmeliaBR: Entire A includes div but there's a 0 width

TabAtkins: Not quite. In box tree div is not child of A. A produces 2 siblings but they're children of A parent.

<astearns> spec link: https://drafts.csswg.org/cssom-view-1/#extensions-to-the-htmlelement-interface

dbaron: I think there are multi explinations for difference and worth checking which. Possible it's due to FF treating block as inside the inline. Another poss if difference if there's a box generated for that little piece or not

TabAtkins: Yeah, and couldn't tell that without diving more

dbaron: Could check if there's a difference if you put the letter in there

TabAtkins: Yeah.
... Letter in there still considers div part of A but the height is a little higher
... FF makes height a littler higher. In Chrome it's still 0x0. Appears consistent. Chrome generates the empty box, FF considers it a part

dbaron: Not sure how it's higher b/c not sure what box it's dealing with

astearns: Seems like nice to be consistent here

dbaron: Nevermind.

<TabAtkins> With <a>foo<div></div></a>, you get a "foo" with the box below it, so the height grows in Firefox.

dbaron: Code for getOffsetRect does go through all fragments

TabAtkins: Rather then get first?

dbaron: Yeah. At least Geck code goes through all

TabAtkins: Sounds like Chrome doesn't

dbaron: Maybe diff is do you go through all fragments

AmeliaBR: Ran quick test using issue example + character before div and that way we can tell if it's about collapsing whitespace and in that case if there's a character FF gives width of div when giving offset of A element. It's not the first inline, but entire thing. Chrome gives size of first inline

dbaron: Another test is letter before and after div

<TabAtkins> before and after: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7825 Chrome still reports the height of just one line, so it's not iterating all the fragments

florian: Another thing confusing is Chrome behavior which is simple about first. For FF with most all frag are next to in this case. But it's not clear all fragments will be next to each other. If it's multi-col they're not adjacent.

dbaron: I think ti's smallest rect that encloses all

florian: So multi-col you get unrelated stuff, but when printing?

dbaron: API doesn't work in printing. DOn't have access

iank_: I think we had this convo with client height in multi-col. Two things you can do, union of all clients or stack them all. Impl stack. CSS Regions make it funky. Need to be consistent.

emilio: Chrome does take height in getBoundingClientRect

TabAtkins: It should b/c div height influences bounding client rect. But this is just client rect

florian: Not working in printing, saying when we print there is no script so it's not there? B/c that's not true. UAs that renders to PDF runs scripts so you can ask this question in an engine that's fragmenting to multiple pieces not next ot each other. Easy for Chrome example, not sure what it does if try and stick together

astearns: Top of hour. I think way forward is write test cases and then come to agreement what success for those cases should be and get that into spec
... Sound okay to everyone?

florian: I would suggest including something like Prince in test cases to get an engine that prints and runs scripts

<TabAtkins> As far as I can tell, the test cases are all consistently showing that Chrome returns the dimensions of the first fragment, and Firefox gives a bounding rect of all the fragments (including the blocks splitting the inline).

astearns: Fair enough.

end

astearns: Thanks everyone for calling in. Please consider set of spec issues that deserves a trial for the F2F meeting

<dholbert> TabAtkins, RE unioning vs. "first layout box" - note that Chrome does seem to union for a scenario of an inline element that's fragmented via explicit breaks: https://jsfiddle.net/dholbert/hpxo4g2r/

<TabAtkins> dholbert: Yeah, that's all still within one layout box.

<TabAtkins> (we were throwing around "fragment" casually, but the spec doesn't say fragment, it's about layout boxes)

<dholbert> hmm, https://drafts.csswg.org/cssom-view/#css-layout-box Issue 1:"The terms CSS layout box and SVG layout box are not currently defined by CSS or SVG." :D

<dholbert> maybe that's part of the problem

<TabAtkins> lol

<fantasai> "fragment" is a CSS3 term, CSS2 just called them boxes...

<TabAtkins> yeah, css2 mixed "box" and "fragment". But if we read CSSOM-View literally, as referring to boxes, then that a-with-breaks is one box, and the a-with-div is three sibling boxes.

- DRAFT -

Cascading Style Sheets (CSS) Working Group Teleconference

18 Mar 2020

Attendees

Contents