- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Apr 2021 16:59:11 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-display] Should <display-legacy> values be aliased at parse time?`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-display] Should <display-legacy> values be aliased at parse time?<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5575<br> <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<br> <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<br> <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<br> <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<br> <dael> florian: emilio, does it make it awkward for impl long term complexity or jsut when you write<br> <dael> emilio: Probably fine. once it computes it's okay. oriol your comment is slightly different. inline-math should be jsut math.<br> <dael> fantasai: Agree with emilio that's a different concern<br> <dael> oriol: Then it should be different if eq possibility one is legacy css2 and other is new?<br> <dael> emilio: That's why I prefer just alias at parse time. Each has a serialization and you're done<br> <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<br> <dael> fantasai: I prop we continue to define newer values as computing to legacy keywords but not process any earlier<br> <dael> emilio: That's more complicated. new thing to old thing. ideally want other way around<br> <dael> emilio: So you just worry about inner and outer display value<br> <dael> fantasai: You want to compute to the new ones but resolved is older?<br> <dael> emilio: Serialize as the.<br> <dael> fantasai: Reasonable that resolved value for gCS is legacy. Need that for compat.<br> <dael> emilio: That does change the behavior of the APIs.<br> <dael> emilio: We probably don't mind<br> <fantasai> s/APIs/Houdini APIs/<br> <dael> emilio: If we want computed style map to return the new thing and then resolve into the keyword is the way to go<br> <dael> emilio: Sooner you alias the better<br> <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<br> <fantasai> s/easier/easier to understand/<br> <dael> emilio: Then waht does specified style do? 3 values we expose, spec, computed, resolved<br> <dael> emilio: What Gecko impl is computed and resolved are same, serialize legacy<br> <dael> emilio: Moving the legacy thing to computational stage...that's okay but we also change behavior of houdini API<br> <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<br> <dael> fantasai: TabAtkins or rachelandrew?<br> <dael> emilio: If we can get away with keeping parse time alias. Serialize to legacy. I don't know<br> <dael> emilio: Prefer if each combo had single serialization. Only gCS exposes legacy. But that's breaking change for specified.<br> <dael> emilio: Maybe only Houdini exposes new<br> <dael> TabAtkins: No opinion either way<br> <dael> astearns: Other opinions?<br> <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.<br> <dael> rachelandrew: Prefer we keep the 2 value all the way through if that's possible<br> <dael> emilio: That's another proposal. May be okay. But inline-block and inline-flow-root compute to different thigns but behave same<br> <dael> iank_: I feel like serialization should go to legacy if they can<br> <dael> iank_: Worried about the web compat here<br> <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<br> <dael> fantasai: That's an arguement to not introduce the display types<br> <dael> fantasai: It's a new display type with same behavior. If your scripts break it's a problem with your script<br> <dael> emilio: Perhaps. But you cannot say in our css codebase we'll only use new display types b/c they break stuff.<br> <dael> emilio: I don't have super strong opinion. Can impl whatever. Least complex is parse time<br> <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.<br> <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.<br> <dael> astearns: Resolve these return most backwards compat serialization except houdini and houdini has 2 value?<br> <dael> iank_: You mean typedOM API?<br> <dael> astearns: Yep<br> <dael> emilio: Should be fine<br> <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<br> <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<br> <dael> jensimmons: I think new display values with 2 parts are so eleigant, don't want the old to stick around<br> <dael> astearns: Which is why I want new to return the 2 value. But we serialize to least backwards compat for a reason<br> <astearns> ack jensimmons<br> <astearns> ack fantasai<br> <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<br> <dael> fantasai: 1) alias at parse time.<br> <dael> fantasai: 2) 2 independant values with same behavior<br> <dael> fantasai: 3) do inbetween where some apis return old and some return new if you spec new<br> <dael> fantasai: Seems first 2 are most elegant. For sake of authors I vote 1 with jensimmons and rachelandrew<br> <miriam> +1<br> <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<br> <dael> iank_: With emilio. I don't htink this is great to go down for script dev that queries style<br> <dael> astearns: Yeah, if we go with independant values it could slow adoption because not compat<br> <dael> fantasai: I'm n ot convinced it would be compat problem<br> <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<br> <bradk> I’m also leaning towards option 3<br> <dael> astearns: Option 3 would not be alias at parse time b/c need to preserve values for TypedOM?<br> <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.<br> <dael> astearns: Do people have objections to the version 3?<br> <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.<br> <dael> fremy: I have one serialization for gCS. You always have 2 value in Houdini. Never get 2<br> <dael> emilio: That how we impl it probably. Have same value but serialize differently for TYpedOM<br> <dael> fantasai: If you put something in specified style do you get 2 value or 1?<br> <dael> emilio: Legacy serialiation<br> <dael> fantasai: .style.display do I get inline-block?<br> <dael> emilio: You would get inline-block<br> <dael> fantasai: What's point of having weird in typed OM?<br> <dael> emilio: It's the one place where we can not go to legacy<br> <dael> emilio: You have issue of script athors having to care about both values if you don't<br> <dael> fantasai: But if you do inline-list-item they need to handle. We keep adding display values<br> <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<br> <dael> emilio: There's a lot of code that won't update<br> <dael> fantasai: Sure, and when using don't use new things<br> <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<br> <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<br> <chris> q+<br> <dael> emilio: Take all hsl and serialize as rgb for that reason<br> <chris> q-<br> <astearns> ack chris<br> <chris> yup. can't unmute<br> <dael> astearns: Not hearing consensus<br> <dael> astearns: Does anyone want to try coming up with something we agree on?<br> <dael> emilio: Won't object if we serialize the new thing, but I don't htink it's best<br> <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.<br> <dael> astearns: iank_ you had concerns?<br> <dael> iank_: I don't think it's the way we should go<br> <dael> astearns: And others don't think we should be cutting off new display types at serialization time<br> <dael> astearns: Any way we can get evidence of compat problem?<br> <dael> fantasai: TabAtkins points out [reads IRC] so to bring florian question back, why do you think this applies to display and not color<br> <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.<br> <dael> emilio: I have same concern. It's common for script to just parse rgba output<br> <chris> q+<br> <dael> iank_: With color example there are scripts that will add a11y dynamically and insert a color. I had similar concerns there<br> <leaverou_> q+<br> <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<br> <dael> fremy: Talking about inline-style or gCS? I think gCS everything is rgb serialization<br> <astearns> ack chris<br> <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<br> <astearns> acl ;ea<br> <dael> chris: Clarifying<br> <astearns> ack lea<br> <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<br> <chris> Serialization of rgb() or rgba() only reports non-unity alpha<br> <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.<br> <chris> Sure, people seemed to be arguing by analogy though so I wanted to be sure the analogy was accurate<br> <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?<br> <dael> fremy: We have rule of if can serialize to old we do<br> <dael> florian: At computed time, yes. Not at specified<br> <dael> emilio: Isn't that general serialization rule?<br> <TabAtkins> I suggest this be taken back to the issue for a bit to stew over the options and arguments.<br> <dael> florian: I don't think so. Am I wrong?<br> <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.<br> <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<br> <dael> iank_: Quick search, jwuery uses this. Likely some cases will break<br> <dael> astearns: Can you put references in issue iank_ ?<br> <dael> iank_: Not exaustive. Just a litmus test<br> <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<br> <dael> astearns: Sound alright?<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5575#issuecomment-819671726 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 14 April 2021 16:59:14 UTC