Meeting minutes
astearns: Thanks to you all for coming in on time. We'll wait a few more minutes
astearns: We're a little light but should start
astearns: Welcome felipeerias, thanks for joinnig
astearns: One change to the agenda, scrollbar topics, 6 & 7, will postpone to next week
astearns: Any other changes people would like to suggest?
astearns: Housekeeping- miriam reminded me we had resolved to start work on the scoping proposal and to write spec text
astearns: Didn't decide where it should go. New draft? In a present draft? ThoughtS?
fantasai: @scope?
TabAtkins: Yeah. I think in scoping spec
fantasai: Or cascade 6. Might fit better there
TabAtkins: I don't think I agree. It's not directly about casade
fantasai: About specificity and which elements something applies to. People think in context of cascade and not in terms...scoping is all about shadow dom
TabAtkins: Didn't used to be. I think confusing if scope rule not in scoping specf
fantasai: fair. Then scoping next level
TabAtkins: Fine with it in current. Nothing pressing to scoping pass cr
fantasai: I'm not. I think what's in scoping is a lot more solid. Want a line between super experimental
astearns: scoping need update anyway?
fantasai: Yep. And it's mainly shadow dom which should be in cr
astearns: Argument to put in current so we have better chance to publish
fantasai: @scope rule should be newer draft. Current level should go to CR soon, and if there's anything blocking that we should be working on it. We can always pub a FPWD of anything we want
astearns: Prop: Add miriam as editor to next level of CSS Scoping and have them work up spec text in an ED which will become FPWD
astearns: Sound good?
miriam: Sounds great
[css-display] math/inline-math (whether display:math on a non-MathML context should be more inline or block)
github: https://
astearns: Has been waiting on math people to weigh in. afaict all we need to deal with is display:math on non-MathML
fantasai: Decided it should be inline
fantasai: Issue from mozilla is having it behave different if in MathML context or not is not great. Not difficult to impl but more tricky b/c context sensitive. Not necessary for any reason.
fantasai: Mats asked for it to behave like mrow regardless of if on math element or not
emilio: and discussion of if need >1. Supposed to be magic depending on element. If not might need more than one
florian: Assume behavior of making it an em which doesn't contain math is well defined?
iank_: Yeah, triggers mrow layout algo
iank_: In simple terms layout things on a row and I think baseline align all
iank_: I think mathml defines internal types fine. Sometimes mrow if it has more children than expected.
iank_: I think not having talked to the MathML people I htink I am supportive of adding each display type as FF folks suggest. Seems consistent with everything else. Would like to hear other thoughts.
iank_: Also works with polyfill story
fantasai: Two issue. One is display:math outside mathML is mrow behavior. Second is add more display types per mathML element
plinss: I think have precedent to jsut rely on display property. I would like to see all math in layout not rely on semantics
plinss: Have it default style
iank_: If you put display:grid on mrow it has an internal layout type of grid algo. Have consistency there
florian: Do we need to check with a11y people, a11y tree, to see if the way the build right now will break? My understanding is for some things they build from box rather than element tree. We should check. I don' tknow
florian: We've been accused of being careless about this in the past
florian: I hope it doesn't. In theory I support plinss
plinss: Agree worth investigating. Might justify a bug on AT. We can evaluate when we find out answers
astearns: Sounding like consensus to have display:math always behave as mrow
fantasai: Outside MathML context and unless otherwise specified
astearns: Prop: have display:math behave as mrow and ping a11y to see if that's an issue
Resolution: have display:math behave as mrow and ping a11y to see if that's an issue
astearns: Separate issue for other math display types?
fantasai: I believe there is
astearns: Is there consensus to resolve that now or postpone to future meeting?
MathML individual display types
<fantasai> github: https://
iank_: I would like to ask people more familiat with MathML
<fantasai> earlier discussion in https://
iank_: Does seem like consensus in this group
astearns: Dim recolection is mathML asked for the display types and Igalia folks thought it too many
iank_: My recollection too.
astearns: Math WG just spun up. Maybe we can ping them on this
astearns: I'll take an action to send this along
plinss: I'm in favor of more display types. Maybe not 100, but 2 or 3 with other properties to control sub-behaviors. Early disgn philosophy in Gecko. I don't want layout and design tied to semantics. I want it all in css
iank_: Quite probably quite a few, 5 or 6. Makes sense b/c distinct layout algos.
florian: Are these things only useful in context of math? Or are they potentially useful in general? In favor either
<bradk> These would be display-inside?
plinss: If we give tools people will have create ways to use them. People will find fun ways to display content we didn't dream of
iank_: mtable has display:table and display:tablecell so this normalizes to that behavior.
<fantasai> bradk, some of them might be more like internal table display types, have to check
iank_: display:mrow there might be. We should give that power
<florian> +1
emilio: Agree. If we want to style math with css using display ew have to do all or none. SVG does no such thing, it's its own box type. I like the direction of exposing all mathml display types
astearns: This will go into issue. I'll ping the new math WG and come back
<bradk> @fantasai I see. Thanks
fantasai: I'd like to propse we take a resolution. csswg believes this is the right direction to go and we prop that to math wg. Useful to capture we're on the same page
astearns: Unless anybody has reservations?
astearns: Prop: We are interested in defining all the math display types necessary for mathml layout
astearns: as individual display types or separate properties in css that let us control the variations
Resolution: We are interested in defining all the math display types necessary for mathml layout to not be element-dependent
Discussion about the block cross-folding screen
github: https://
fantasai: I had brought this up. It looks like need discussion. I don't have a proposal. I think I proposed for F2F
astearns: Yeah, even for virtual F2F we need something to go on
astearns: By my reading this is about what to do with text elements since we do have split and mask capabilities for images
fantasai: No, screen folding. Different ways to handle the effect. One is where you move the boxes apart. Another is mask so stuff apeears. Need to expose to author so they don't put content inside the fold
fantasai: If impl creates a gap and cutting content, need no content in gap. When there's masking there is and author needs to know. need to make adaptable so author can layout. Means conveying information.
astearns: I don't see MS people on call who are working on this stuff
astearns: Maybe we kick back to issue
fantasai: Yeah, needs a proposal
[css-display] Should <display-legacy> values be aliased at parse time?
github: https://
fantasai: Question of if new display types, we have things line inline-block. Now that we have separate keywords we have inline-display-flow-root is same as inline-block. Defined as same. When you do gCS wanted to return inline-block b/c shortest serialization
fantasai: Should this be handled at parse time. I think no, author should get what they spec. I think rachelandrew and others have had value in talking as outer and inner display type. If we merge in APIs harder to conceptulaize
emilio: Much easier to do at parse time for impl. Don't feel super strong. Seems unfortunate display won't compute as specified, but I guess okay
oriol: While FF does at spec value time, chromium does this for combinations and they are considered to be different. It preserves spec keywords
florian: emilio, does it make it awkward for impl long term complexity or jsut when you write
emilio: Probably fine. once it computes it's okay. oriol your comment is slightly different. inline-math should be jsut math.
fantasai: Agree with emilio that's a different concern
oriol: Then it should be different if eq possibility one is legacy css2 and other is new?
emilio: That's why I prefer just alias at parse time. Each has a serialization and you're done
emilio: A bit unfortunate that you say inline-flow-root and get back inline-block. But that's what you get in the computed styles
fantasai: I prop we continue to define newer values as computing to legacy keywords but not process any earlier
emilio: That's more complicated. new thing to old thing. ideally want other way around
emilio: So you just worry about inner and outer display value
fantasai: You want to compute to the new ones but resolved is older?
emilio: Serialize as the.
fantasai: Reasonable that resolved value for gCS is legacy. Need that for compat.
emilio: That does change the behavior of the Houdini APIs.
emilio: We probably don't mind
emilio: If we want computed style map to return the new thing and then resolve into the keyword is the way to go
emilio: Sooner you alias the better
fantasai: From author PoV system is easier to understand with 2 value keyword. If it's jsut a parse time alias that's helpful but could get a bit confusing. If we can get away with it being 2 keyword values in Houdini gude that's reasonable
emilio: Then waht does specified style do? 3 values we expose, spec, computed, resolved
emilio: What Gecko impl is computed and resolved are same, serialize legacy
emilio: Moving the legacy thing to computational stage...that's okay but we also change behavior of houdini API
emilio: More work to basically keep the new values in the specified style, return old in computed, return new in Houdini. You're uncomputing what you computed. Fine. A bit more annoying
fantasai: TabAtkins or rachelandrew?
emilio: If we can get away with keeping parse time alias. Serialize to legacy. I don't know
emilio: Prefer if each combo had single serialization. Only gCS exposes legacy. But that's breaking change for specified.
emilio: Maybe only Houdini exposes new
TabAtkins: No opinion either way
astearns: Other opinions?
rachelandrew: I think as fantasai said from author PoV the two values are understandable and confusing if you get back something other than expected.
rachelandrew: Prefer we keep the 2 value all the way through if that's possible
emilio: That's another proposal. May be okay. But inline-block and inline-flow-root compute to different thigns but behave same
iank_: I feel like serialization should go to legacy if they can
iank_: Worried about the web compat here
emilio: Right. If you keep as spec it's nice if you're in control. But you prevent adoption. If you use jquery and it expects a return of inline-block and it starts returning inline-flow-root b/c you used it in your style sheet, you can't use it b/c scripts break
fantasai: That's an arguement to not introduce the display types
fantasai: It's a new display type with same behavior. If your scripts break it's a problem with your script
emilio: Perhaps. But you cannot say in our css codebase we'll only use new display types b/c they break stuff.
emilio: I don't have super strong opinion. Can impl whatever. Least complex is parse time
<jensimmons> I'm a bit lost. I'd love for us to compute to the new syntax. Get the world of Authors to move on.
iank_: I think I'm with emilio. From maintenance PoV and being a previous webdev this would be somewhat concerning. You don't always controls what people are setting display types to.
astearns: Resolve these return most backwards compat serialization except houdini and houdini has 2 value?
iank_: You mean typedOM API?
astearns: Yep
emilio: Should be fine
emilio: Should also be fine to match computed style either way. As long as same value serializes to the same thing it's fine. backwards compat trips. Up to chrome if they want exisintg users of inline-grid to have breaking change
jensimmons: I understand if there's a compat problem, but I would love to see us for sake of authors compute and return new syntax. I'd love to be able to teach new syntax. Thinking about where will we be 5 years from now. Hvaing to continually teach the old syntax and why? Always a fan of clear the decks and move forward
jensimmons: I think new display values with 2 parts are so eleigant, don't want the old to stick around
astearns: Which is why I want new to return the 2 value. But we serialize to least backwards compat for a reason
fantasai: Could decide this is new independent value. Has same behavior but don't compute to each other. We've got 3 possible options
fantasai: 1) alias at parse time.
fantasai: 2) 2 independant values with same behavior
fantasai: 3) do inbetween where some apis return old and some return new if you spec new
fantasai: Seems first 2 are most elegant. For sake of authors I vote 1 with jensimmons and rachelandrew
<miriam> +1
emilio: I'm okay with saying that.Basically quesiton is how much work does adopting this become. Script authors need to care about both values. That's great for authors of css but not great for authors of script
iank_: With emilio. I don't htink this is great to go down for script dev that queries style
astearns: Yeah, if we go with independant values it could slow adoption because not compat
fantasai: I'm n ot convinced it would be compat problem
iank_: From what I've seen on gCS and display I think there's a significant chance of people accidentally breaking and not realizing it
<bradk> I’m also leaning towards option 3
astearns: Option 3 would not be alias at parse time b/c need to preserve values for TypedOM?
fantasai: Can't do it at parse. Variations on option 3. One would be 2 independent values but have gCS do an extra computation to return old version. We do all kinds of extra lift for gCS.
astearns: Do people have objections to the version 3?
fremy: Small question based on minutes. Why can't we do option 3 at parse time? I don't understand. They're exactly the same. inline-block will always be same 2 values in Houdini.
fremy: I have one serialization for gCS. You always have 2 value in Houdini. Never get 2
emilio: That how we impl it probably. Have same value but serialize differently for TYpedOM
fantasai: If you put something in specified style do you get 2 value or 1?
emilio: Legacy serialiation
fantasai: .style.display do I get inline-block?
emilio: You would get inline-block
fantasai: What's point of having weird in typed OM?
emilio: It's the one place where we can not go to legacy
emilio: You have issue of script athors having to care about both values if you don't
fantasai: But if you do inline-list-item they need to handle. We keep adding display values
fantasai: We add them al the time. If script doesn't handle new you have to tell the person that my script only handles the old ones. If you're putting limits on script you have to negotiate with user. I don't see why this is a particular problem
emilio: There's a lot of code that won't update
fantasai: Sure, and when using don't use new things
emilio: Problem is, people are not going to be able to use new display values. Moving backwards compat from browser to author. That's fine
florian: Seems we have same problem in many areas. Script for colors there's may ways to spec red. They all look the same. But we don't serialize LAB space back
emilio: Take all hsl and serialize as rgb for that reason
<chris> yup. can't unmute
astearns: Not hearing consensus
astearns: Does anyone want to try coming up with something we agree on?
emilio: Won't object if we serialize the new thing, but I don't htink it's best
<TabAtkins> Note that we *only* serialize the older color forms to rgb(). Newer forms, even ones that are absolutely equivalent to rgb(), stay as they are.
astearns: iank_ you had concerns?
iank_: I don't think it's the way we should go
astearns: And others don't think we should be cutting off new display types at serialization time
astearns: Any way we can get evidence of compat problem?
fantasai: TabAtkins points out [reads IRC] so to bring florian question back, why do you think this applies to display and not color
TabAtkins: We have new color forms that are eq. to rgb but don't serialize. We color turn color into rgb but want to keep in same form. Only older turn into rgb.
emilio: I have same concern. It's common for script to just parse rgba output
iank_: With color example there are scripts that will add a11y dynamically and insert a color. I had similar concerns there
iank_: I think less bad b/c breakage is more minor in that case. There's a lot of script htat will check if display is inline-block do something
fremy: Talking about inline-style or gCS? I think gCS everything is rgb serialization
chris: Thing about rgba is the spec says regardless of how you spec, rgb or rgba, rgb can get an alpha, but if it's 1 it's thrown out. Only reported if not 1
<astearns> acl ;ea
chris: Clarifying
leaverou_: Comment about scripts that parse rgba, that ship sailed. Not every color can be rgba so scripts need to support other forms. Shouldn't be a concern. With typed OM hopefully devs wouldn't parse colors manually anymore
<chris> Serialization of rgb() or rgba() only reports non-unity alpha
astearns: I think color discussion is a little far afield. Scripts dealing with display values. I would hope scripts with display values would have an i don't know what this is default.
<chris> Sure, people seemed to be arguing by analogy though so I wanted to be sure the analogy was accurate
florian: I think we need data for compat argument. If we show up we can say doing serialization might break things. In theory all sorts of things could break. Do they?
fremy: We have rule of if can serialize to old we do
florian: At computed time, yes. Not at specified
emilio: Isn't that general serialization rule?
<TabAtkins> I suggest this be taken back to the issue for a bit to stew over the options and arguments.
florian: I don't think so. Am I wrong?
fantasai: When defined to be equal, we do. If defined to eq. it will serialize to shortest. Debate is do we define to be same at computed or specified value time.
fantasai: One proposal is they're distinct and different. We do that in other places. We have places in css with same behavior but serialize independent
iank_: Quick search, jwuery uses this. Likely some cases will break
astearns: Can you put references in issue iank_ ?
iank_: Not exaustive. Just a litmus test
astearns: Nearly out of time. I suggest iank_ puts his in the issue. Others search and add to the issue. We can see what would break and come back at a later date
astearns: Sound alright?
end
astearns: Thanks everyone for calling in and we'll talk next week