IRC log of css on 2021-04-14
Timestamps are in UTC.
- 15:53:45 [RRSAgent]
- RRSAgent has joined #css
- 15:53:45 [RRSAgent]
- logging to https://www.w3.org/2021/04/14-css-irc
- 15:53:47 [Zakim]
- RRSAgent, make logs Public
- 15:53:48 [Zakim]
- Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
- 15:57:19 [jfkthame]
- jfkthame has joined #css
- 15:58:20 [oriol]
- oriol has joined #css
- 15:58:29 [dael]
- dael has joined #css
- 15:59:35 [dael]
- present+
- 15:59:41 [dael]
- ScribeNick: dael
- 16:00:06 [rachelandrew]
- present+
- 16:00:17 [miriam]
- present+
- 16:00:44 [bradk]
- bradk has joined #css
- 16:00:45 [dael]
- astearns: Thanks to you all for coming in on time. We'll wait a few more minutes
- 16:01:14 [Gottfried]
- Gottfried has joined #css
- 16:01:20 [alisonmaher]
- alisonmaher has joined #css
- 16:01:24 [oriol]
- present+
- 16:01:32 [alisonmaher]
- present+
- 16:01:36 [bradk]
- present+
- 16:02:36 [emilio]
- present+
- 16:02:50 [plinss]
- present+
- 16:03:15 [dbaron]
- present+
- 16:03:15 [dael]
- astearns: We're a little light but should start
- 16:03:19 [jfkthame]
- present+
- 16:03:21 [Morgan]
- Morgan has joined #css
- 16:03:26 [dael]
- astearns: Welcome felipeerias, thanks for joinnig
- 16:03:41 [Morgan]
- present+
- 16:03:41 [dael]
- astearns: One change to the agenda, scrollbar topics, 6 & 7, will postpone to next week
- 16:03:49 [dael]
- astearns: Any other changes people would like to suggest?
- 16:04:08 [smfr]
- smfr has joined #css
- 16:04:13 [dael]
- astearns: Housekeeping- miriam reminded me we had resolved to start work on the scoping proposal and to write spec text
- 16:04:17 [smfr]
- present+
- 16:04:26 [dael]
- astearns: Didn't decide where it should go. New draft? In a present draft? ThoughtS?
- 16:04:41 [dael]
- fantasai: @scope?
- 16:04:47 [dael]
- TabAtkins: Yeah. I think in scoping spec
- 16:04:55 [dael]
- fantasai: Or cascade 6. Might fit better there
- 16:05:11 [dael]
- TabAtkins: I don't think I agree. It's not directly about casade
- 16:05:14 [sanketj]
- sanketj has joined #css
- 16:05:26 [sanketj]
- present+
- 16:05:38 [dael]
- 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
- 16:05:51 [dael]
- TabAtkins: Didn't used to be. I think confusing if scope rule not in scoping specf
- 16:05:58 [dael]
- fantasai: fair. Then scoping next level
- 16:06:11 [dael]
- TabAtkins: Fine with it in current. Nothing pressing to scoping pass cr
- 16:06:29 [dael]
- fantasai: I'm not. I think what's in scoping is a lot more solid. Want a line between super experimental
- 16:06:31 [argyle]
- present+
- 16:06:35 [dael]
- astearns: scoping need update anyway?
- 16:06:44 [dael]
- fantasai: Yep. And it's mainly shadow dom which should be in cr
- 16:06:55 [dael]
- astearns: Argument to put in current so we have better chance to publish
- 16:07:17 [dael]
- fantasai: @scope rule should be newer draft. Current level should go to CR soon. We can always pub a FPWD of anything we want
- 16:07:36 [fantasai]
- s/soon/soon, and if there's anything blocking that we should be working on it/
- 16:07:40 [dael]
- 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
- 16:07:43 [dael]
- astearns: Sound good?
- 16:07:50 [dael]
- miriam: Sounds great
- 16:07:57 [dael]
- Topic: [css-display] math/inline-math (whether display:math on a non-MathML context should be more inline or block)
- 16:08:07 [dael]
- github: https://github.com/w3c/csswg-drafts/issues/5385
- 16:08:32 [dael]
- astearns: Has been waiting on math people to weigh in. afaict all we need to deal with is display:math on non-MathML
- 16:08:32 [faceless]
- present+
- 16:08:36 [dael]
- fantasai: Decided it should be inline
- 16:08:53 [dholbert]
- dholbert has joined #css
- 16:08:59 [dholbert]
- present+
- 16:09:05 [dael]
- 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.
- 16:09:21 [dael]
- fantasai: Mats asked for it to behave like em row regardless of if on math element or not
- 16:09:28 [fantasai]
- s/em row/mrow/
- 16:09:41 [dael]
- emilio: and discussion of if need >1. Supposed to be magic depending on valid. If not might need more than one
- 16:09:52 [fantasai]
- s/valid/element/
- 16:09:56 [dael]
- florian: Assume behavior of making it an em which doesn't contain math is well defined?
- 16:10:04 [dael]
- iank_: Yeah, triggers em row layout algo
- 16:10:08 [fantasai]
- s/em row/mrow/
- 16:10:14 [dael]
- iank_: In simple terms layout things on a row and I think baseline align all
- 16:10:24 [Gottfried]
- Gottfried has joined #css
- 16:10:43 [dael]
- iank_: I think mathml defines internal types fine. Sometimes mrow if it has more children than expected.
- 16:11:03 [gregwhitworth]
- present+
- 16:11:21 [dael]
- 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.
- 16:11:29 [dael]
- iank_: Also works with polyfill story
- 16:11:47 [dael]
- fantasai: Two issue. One is display:math outside mathML is mrow behavior. Second is add more display types per mathML element
- 16:12:17 [dael]
- plinss: I think have precedent to jsut rely on display property. I would like to see all math in layout not rely on semantics
- 16:12:24 [dael]
- plinss: Have it default style
- 16:12:38 [dael]
- iank_: If you put display:grid on mrow it has an internal layout type of grid algo. Have consistency there
- 16:13:03 [chris]
- chris has joined #css
- 16:13:18 [dael]
- 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
- 16:13:27 [dael]
- florian: We've been accused of being careless about this in the past
- 16:13:36 [dael]
- florian: I hope it doesn't. In theory I support plinss
- 16:13:55 [dael]
- plinss: Agree worth investigating. Might justify a bug on AT. We can evaluate when we find out answers
- 16:14:02 [jensimmons]
- present+
- 16:14:08 [dael]
- astearns: Sounding like consensus to have display:math always behave as mrow
- 16:14:19 [dael]
- fantasai: Outside MathML context and unless otherwise specified
- 16:14:27 [castastrophe]
- castastrophe has joined #css
- 16:14:36 [castastrophe]
- present+
- 16:14:36 [dael]
- astearns: Prop: have display:math behave as mrow and ping a11y to see if that's an issue
- 16:14:42 [dael]
- RESOLVED: have display:math behave as mrow and ping a11y to see if that's an issue
- 16:14:51 [dael]
- astearns: Separate issue for other math display types?
- 16:14:58 [dael]
- fantasai: I believe there is
- 16:15:11 [dael]
- astearns: Is there consensus to resolve that now or postpone to future meeting?
- 16:15:14 [fantasai]
- Topic: MathML individual display types
- 16:15:17 [fantasai]
- github: https://github.com/w3c/csswg-drafts/issues/5866
- 16:15:28 [dael]
- iank_: I would like to ask people more familiat with MathML
- 16:15:38 [fantasai]
- earlier discussion in https://www.w3.org/2021/04/14-css-irc
- 16:15:39 [dael]
- iank_: Does seem like consensus in this group
- 16:15:54 [dael]
- astearns: Dim recolection is mathML asked for the display types and we thought it too many
- 16:15:59 [dael]
- iank_: My recolection too.
- 16:16:02 [fantasai]
- s/we/Igalia folks/
- 16:16:12 [dael]
- astearns: Math WG just spun up. Maybe we can ping them on this
- 16:16:15 [fantasai]
- s/recolection/recollection/
- 16:16:23 [dael]
- astearns: I'll take an action to send this along
- 16:16:33 [jensimmo_]
- jensimmo_ has joined #css
- 16:17:03 [dael]
- 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
- 16:17:25 [dael]
- iank_: Quite probably quite a few, 5 or 6. Makes sense b/c distinct layout algos.
- 16:17:45 [dael]
- florian: Are these things only useful in context of math? Or are they potentially useful in general? In favor either
- 16:17:48 [bradk]
- These would be display-inside?
- 16:18:05 [dael]
- 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
- 16:18:21 [dael]
- iank_: mtable has display:table and display:tablecell so this normalizes to that behavior.
- 16:18:28 [fantasai]
- bradk, some of them might be more like internal table display types, have to check
- 16:18:31 [dael]
- iank_: display:mrow there might be. We should give that power
- 16:19:04 [florian]
- +1
- 16:19:05 [dael]
- 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
- 16:19:19 [dael]
- astearns: This will go into issue. I'll ping the new math WG and come back
- 16:19:44 [bradk]
- @fantasai I see. Thanks
- 16:19:47 [dael]
- 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
- 16:19:54 [dael]
- astearns: Unless anybody has reservations?
- 16:20:17 [dael]
- astearns: Prop: We are interested in defining all the math display types necessary for mathml layout
- 16:20:32 [dael]
- astearns: as individual display types or separate properties in css that let us control the variations
- 16:20:44 [dael]
- RESOLVED: We are interested in defining all the math display types necessary for mathml layout
- 16:20:47 [chris]
- present+
- 16:20:52 [dael]
- Topic: Discussion about the block cross-folding screen
- 16:20:54 [fantasai]
- s/layout/layout to not be element-dependent/
- 16:21:01 [dael]
- github: https://github.com/w3c/csswg-drafts/issues/5882
- 16:21:39 [dael]
- fantasai: I had brought this up. It looks like need discussion. I don't have a proposal. I think I proposed for F2F
- 16:21:49 [fremy]
- fremy has joined #css
- 16:22:04 [dael]
- astearns: Yeah, even for virtual F2F we need something to go on
- 16:22:21 [dael]
- astearns: By my reading this is about what to do with text elements since we do have split and mask capabilities for images
- 16:22:52 [dael]
- 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
- 16:23:32 [dael]
- 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.
- 16:23:46 [dael]
- astearns: I don't see MS people on call who are working on this stuff
- 16:23:55 [dael]
- astearns: Maybe we kick back to issue
- 16:23:59 [dael]
- fantasai: Yeah, needs a proposal
- 16:24:08 [dael]
- Topic: [css-display] Should <display-legacy> values be aliased at parse time?
- 16:24:14 [dael]
- github: https://github.com/w3c/csswg-drafts/issues/5575
- 16:25:05 [dael]
- 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
- 16:25:23 [leaverou_]
- leaverou_ has joined #css
- 16:25:26 [leaverou_]
- present+
- 16:25:40 [dael]
- 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
- 16:26:06 [dael]
- 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
- 16:26:35 [dael]
- oriol: While FF does at spec value time, chromium does this for combinations and they are considered to be different. It preserves spec keywords
- 16:26:49 [dael]
- florian: emilio, does it make it awkward for impl long term complexity or jsut when you write
- 16:26:51 [hober]
- hober has joined #css
- 16:27:13 [dael]
- emilio: Probably fine. once it computes it's okay. oriol your comment is slightly different. inline-math should be jsut math.
- 16:27:20 [dael]
- fantasai: Agree with emilio that's a different concern
- 16:27:41 [dael]
- oriol: Then it should be different if eq possibility one is legacy css2 and other is new?
- 16:28:01 [dael]
- emilio: That's why I prefer just alias at parse time. Each has a serialization and you're done
- 16:28:05 [hober]
- present+
- 16:28:22 [dael]
- 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
- 16:28:40 [dael]
- fantasai: I prop we continue to define newer values as computing to legacy keywords but not process any earlier
- 16:28:54 [dael]
- emilio: That's more complicated. new thing to old thing. ideally want other way around
- 16:29:06 [dael]
- emilio: So you just worry about inner and outer display value
- 16:29:15 [dael]
- fantasai: You want to compute to the new ones but resolved is older?
- 16:29:21 [dael]
- emilio: Serialize as the.
- 16:29:34 [dael]
- fantasai: Reasonable that resolved value for gCS is legacy. Need that for compat.
- 16:29:45 [dael]
- emilio: That does change the behavior of the APIs.
- 16:29:49 [dael]
- emilio: We probably don't mind
- 16:29:53 [fantasai]
- s/APIs/Houdini APIs/
- 16:30:13 [dael]
- emilio: If we want computed style map to return the new thing and then resolve into the keyword is the way to go
- 16:30:18 [dael]
- emilio: Sooner you alias the better
- 16:31:03 [dael]
- fantasai: From author PoV system is easier 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
- 16:31:14 [fantasai]
- s/easier/easier to understand/
- 16:31:20 [dael]
- emilio: Then waht does specified style do? 3 values we expose, spec, computed, resolved
- 16:31:34 [dael]
- emilio: What Gecko impl is computed and resolved are same, serialize legacy
- 16:31:56 [dael]
- emilio: Moving the legacy thing to computational stage...that's okay but we also change behavior of houdini API
- 16:32:36 [dael]
- 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
- 16:32:41 [dael]
- fantasai: TabAtkins or rachelandrew?
- 16:32:57 [dael]
- emilio: If we can get away with keeping parse time alias. Serialize to legacy. I don't know
- 16:33:20 [dael]
- emilio: Prefer if each combo had single serialization. Only gCS exposes legacy. But that's breaking change for specified.
- 16:33:27 [dael]
- emilio: Maybe only Houdini exposes new
- 16:33:35 [dael]
- TabAtkins: No opinion either way
- 16:33:44 [dael]
- astearns: Other opinions?
- 16:34:07 [dael]
- rachelandrew: I think as fantasai said from author PoV the two values are understandable and confusing if you get back something other than expected.
- 16:34:18 [dael]
- rachelandrew: Prefer we keep the 2 value all the way through if that's possible
- 16:34:42 [dael]
- emilio: That's another proposal. May be okay. But inline-block and inline-flow-root compute to different thigns but behave same
- 16:34:54 [dael]
- iank_: I feel like serialization should go to legacy if they can
- 16:35:00 [dael]
- iank_: Worried about the web compat here
- 16:35:04 [tantek]
- tantek has joined #css
- 16:35:46 [dael]
- 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
- 16:35:58 [dael]
- fantasai: That's an arguement to not introduce the display types
- 16:36:13 [dael]
- fantasai: It's a new display type with same behavior. If your scripts break it's a problem with your script
- 16:36:31 [dael]
- emilio: Perhaps. But you cannot say in our css codebase we'll only use new display types b/c they break stuff.
- 16:36:46 [dael]
- emilio: I don't have super strong opinion. Can impl whatever. Least complex is parse time
- 16:37:30 [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.
- 16:37:30 [dael]
- 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.
- 16:37:50 [dael]
- astearns: Resolve these return most backwards compat serialization except houdini and houdini has 2 value?
- 16:37:55 [dael]
- iank_: You mean typedOM API?
- 16:37:57 [dael]
- astearns: Yep
- 16:38:03 [dael]
- emilio: Should be fine
- 16:38:50 [dael]
- 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
- 16:39:25 [cbiesinger]
- present+
- 16:39:46 [dael]
- 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
- 16:40:03 [dael]
- jensimmons: I think new display values with 2 parts are so eleigant, don't want the old to stick around
- 16:40:23 [dael]
- astearns: Which is why I want new to return the 2 value. But we serialize to least backwards compat for a reason
- 16:40:35 [astearns]
- ack jensimmons
- 16:40:41 [astearns]
- ack fantasai
- 16:40:44 [dael]
- fantasai: Could decide this is new independent value. Has same behavior but don't compute to each other. We've got 3 possible options
- 16:40:54 [dael]
- fantasai: 1) alias at parse time.
- 16:41:04 [dael]
- fantasai: 2) 2 independant values with same behavior
- 16:41:18 [dael]
- fantasai: 3) do inbetween where some apis return old and some return new if you spec new
- 16:41:42 [dael]
- fantasai: Seems first 2 are most elegant. For sake of authors I vote 1 with jensimmons and rachelandrew
- 16:41:43 [miriam]
- +1
- 16:42:21 [dael]
- 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
- 16:42:36 [dael]
- iank_: With emilio. I don't htink this is great to go down for script dev that queries style
- 16:42:57 [dael]
- astearns: Yeah, if we go with independant values it could slow adoption because not compat
- 16:43:05 [dael]
- fantasai: I'm n ot convinced it would be compat problem
- 16:43:27 [dael]
- 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
- 16:43:38 [bradk]
- I’m also leaning towards option 3
- 16:43:53 [dael]
- astearns: Option 3 would not be alias at parse time b/c need to preserve values for TypedOM?
- 16:44:35 [dael]
- 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.
- 16:44:49 [dael]
- astearns: Do people have objections to the version 3?
- 16:45:08 [tantek]
- present+
- 16:45:19 [dael]
- 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.
- 16:45:35 [dael]
- fremy: I have one serialization for gCS. You always have 2 value in Houdini. Never get 2
- 16:45:55 [dael]
- emilio: That how we impl it probably. Have same value but serialize differently for TYpedOM
- 16:46:05 [dael]
- fantasai: If you put something in specified style do you get 2 value or 1?
- 16:46:10 [dael]
- emilio: Legacy serialiation
- 16:46:19 [dael]
- fantasai: .style.display do I get inline-block?
- 16:46:26 [dael]
- emilio: You would get inline-block
- 16:46:33 [dael]
- fantasai: What's point of having weird in typed OM?
- 16:46:43 [dael]
- emilio: It's the one place where we can not go to legacy
- 16:46:59 [dael]
- emilio: You have issue of script athors having to care about both values if you don't
- 16:47:16 [dael]
- fantasai: But if you do inline-list-item they need to handle. We keep adding display values
- 16:47:49 [GameMaker]
- GameMaker has joined #css
- 16:47:55 [GameMaker]
- present+
- 16:48:01 [dael]
- 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
- 16:48:08 [dael]
- emilio: There's a lot of code that won't update
- 16:48:16 [dael]
- fantasai: Sure, and when using don't use new things
- 16:48:38 [dael]
- 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
- 16:49:05 [dael]
- 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
- 16:49:12 [chris]
- q+
- 16:49:14 [dael]
- emilio: Take all hsl and serialize as rgb for that reason
- 16:49:36 [chris]
- q-
- 16:49:39 [astearns]
- ack chris
- 16:49:55 [chris]
- yup. can't unmute
- 16:50:22 [dael]
- astearns: Not hearing consensus
- 16:50:33 [dael]
- astearns: Does anyone want to try coming up with something we agree on?
- 16:50:46 [dael]
- emilio: Won't object if we serialize the new thing, but I don't htink it's best
- 16:50:57 [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.
- 16:50:58 [dael]
- astearns: iank_ you had concerns?
- 16:51:08 [dael]
- iank_: I don't think it's the way we should go
- 16:51:31 [dael]
- astearns: And others don't think we should be cutting off new display types at serialization time
- 16:51:39 [dael]
- astearns: Any way we can get evidence of compat problem?
- 16:52:03 [dael]
- fantasai: TabAtkins points out [reads IRC] so to bring florian question back, why do you think this applies to display and not color
- 16:52:37 [dael]
- 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.
- 16:52:45 [aja]
- aja has joined #css
- 16:52:50 [dael]
- emilio: I have same concern. It's common for script to just parse rgba output
- 16:52:53 [chris]
- q+
- 16:53:13 [dael]
- iank_: With color example there are scripts that will add a11y dynamically and insert a color. I had similar concerns there
- 16:53:20 [leaverou_]
- q+
- 16:53:34 [dael]
- 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
- 16:53:48 [dael]
- fremy: Talking about inline-style or gCS? I think gCS everything is rgb serialization
- 16:53:54 [astearns]
- ack chris
- 16:54:18 [dael]
- 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
- 16:54:33 [astearns]
- acl ;ea
- 16:54:33 [dael]
- chris: Clarifying
- 16:54:36 [astearns]
- ack lea
- 16:55:10 [dael]
- 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
- 16:55:17 [chris]
- Serialization of rgb() or rgba() only reports non-unity alpha
- 16:55:42 [dael]
- 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.
- 16:55:46 [chris]
- Sure, people seemed to be arguing by analogy though so I wanted to be sure the analogy was accurate
- 16:56:08 [dael]
- 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?
- 16:56:18 [dael]
- fremy: We have rule of if can serialize to old we do
- 16:56:28 [dael]
- florian: At computed time, yes. Not at specified
- 16:56:34 [dael]
- emilio: Isn't that general serialization rule?
- 16:56:36 [TabAtkins]
- I suggest this be taken back to the issue for a bit to stew over the options and arguments.
- 16:56:40 [dael]
- florian: I don't think so. Am I wrong?
- 16:57:09 [dael]
- 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.
- 16:57:46 [dael]
- 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
- 16:58:08 [dael]
- iank_: Quick search, jwuery uses this. Likely some cases will break
- 16:58:16 [dael]
- astearns: Can you put references in issue iank_ ?
- 16:58:26 [dael]
- iank_: Not exaustive. Just a litmus test
- 16:58:57 [dael]
- 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
- 16:59:01 [dael]
- astearns: Sound alright?
- 16:59:09 [dael]
- Topic: end
- 16:59:19 [dael]
- astearns: Thanks everyone for calling in and we'll talk next week
- 16:59:33 [astearns]
- zakim, end meeting
- 16:59:33 [Zakim]
- As of this point the attendees have been dael, rachelandrew, miriam, oriol, alisonmaher, bradk, emilio, plinss, dbaron, jfkthame, Morgan, smfr, sanketj, argyle, faceless, dholbert,
- 16:59:36 [Zakim]
- ... gregwhitworth, jensimmons, castastrophe, chris, leaverou_, hober, cbiesinger, tantek, GameMaker
- 16:59:36 [Zakim]
- RRSAgent, please draft minutes v2
- 16:59:36 [RRSAgent]
- I have made the request to generate https://www.w3.org/2021/04/14-css-minutes.html Zakim
- 16:59:38 [Zakim]
- I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye
- 16:59:43 [Zakim]
- Zakim has left #css
- 17:05:52 [jfkthame]
- jfkthame has left #css
- 17:07:27 [jensimm__]
- jensimm__ has joined #css
- 17:13:18 [jensimmo_]
- jensimmo_ has joined #css
- 17:20:16 [emilio]
- fantasai: sorry again for speaking over you btw, I didn't notice but Alan was right in pointing it out
- 17:21:57 [emilio]
- fantasai: I commented on the issue with a sample of code from jquery, and again I'm not opposed on changing Gecko here, but I _think_ it's a bit of the kind of change which is harder for both implementors and script writers.
- 17:25:05 [TabAtkins]
- Random question: it turns out the "recommended" is a 2119 keyword, and Bikeshed is complaining about its use in an example. I'm feeling like it's a rare enough word that I can safely remove it from the validation. Sound reasonable?
- 18:28:03 [astearns]
- I see 172 instances in the repo
- 18:29:16 [astearns]
- Is the check that we do not use 2119 keywords in non-normative text? I think I see several instances of that
- 19:50:40 [projector]
- projector has joined #css
- 19:51:11 [leaverou]
- leaverou has joined #css
- 19:51:41 [Rossen]
- Rossen has joined #css
- 19:52:11 [shans]
- shans has joined #css
- 19:52:41 [sylvaing]
- sylvaing has joined #css
- 20:17:43 [zcorpan]
- zcorpan has joined #css
- 20:18:42 [zcorpan_]
- zcorpan_ has joined #css
- 20:20:33 [zcorpan]
- zcorpan has joined #css
- 20:22:22 [zcorpan_]
- zcorpan_ has joined #css
- 20:23:30 [zcorpan]
- zcorpan has joined #css
- 20:25:52 [zcorpan_]
- zcorpan_ has joined #css
- 20:26:30 [zcorpan]
- zcorpan has joined #css
- 20:30:41 [zcorpan_]
- zcorpan_ has joined #css
- 20:31:50 [zcorpan]
- zcorpan has joined #css
- 20:33:03 [zcorpan_]
- zcorpan_ has joined #css
- 20:33:39 [zcorpan]
- zcorpan has joined #css
- 20:35:22 [zcorpan_]
- zcorpan_ has joined #css
- 20:37:20 [zcorpan]
- zcorpan has joined #css
- 20:39:22 [zcorpan_]
- zcorpan_ has joined #css
- 20:39:54 [zcorpan]
- zcorpan has joined #css
- 20:42:07 [zcorpan_]
- zcorpan_ has joined #css
- 20:43:40 [zcorpan]
- zcorpan has joined #css
- 20:44:52 [zcorpan_]
- zcorpan_ has joined #css
- 20:47:30 [zcorpan]
- zcorpan has joined #css
- 20:49:07 [zcorpan_]
- zcorpan_ has joined #css
- 20:50:10 [zcorpan]
- zcorpan has joined #css
- 20:52:52 [zcorpan_]
- zcorpan_ has joined #css
- 20:54:15 [zcorpan]
- zcorpan has joined #css
- 20:56:14 [TabAtkins]
- astearns: You have to manually turn on that `Complain About` option; this just happens to be turned on for Color 4.
- 20:56:19 [zcorpan]
- zcorpan has joined #css
- 20:57:02 [zcorpan_]
- zcorpan_ has joined #css
- 20:57:35 [zcorpan]
- zcorpan has joined #css
- 21:00:38 [zcorpan_]
- zcorpan_ has joined #css
- 21:05:28 [astearns]
- So maybe just fix that instance so that people can run the full check elsewhere if they want?
- 22:09:43 [TabAtkins]
- Where I fix it isn't an issue, I'm just wondering if it's even a word *worth* checking for, since I definitely didn't remember it was even a 2119 word.