W3C home > Mailing lists > Public > public-css-archive@w3.org > December 2018

Re: [csswg-drafts] [css-grid] How to serialize the strings in grid-template-areas? (#3261)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 12 Dec 2018 17:29:44 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-446672986-1544635782-sysbot+gh@w3.org>
The CSS Working Group just discussed `How to serialize the strings in grid-template-areas?`, and agreed to the following:

* `RESOLVED: Use the normalized value to serialize grid-template-areas`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: How to serialize the strings in grid-template-areas?<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/3261#issuecomment-446018130<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/3261#issuecomment-436830050<br>
&lt;dael> fantasai: This is well illustrated by ^ comment<br>
&lt;dael> fantasai: grid-template-areas takes a series of strings and assigns names to different areas. When reserializing that back out do we normalize things that are eq. like compressing whitespace or do we return original string<br>
&lt;dael> TabAtkins: Already not returning originaly, we have compressed whitespace. It's how much compression is okay. Should we do more tracking of original author like keeping number of dots in the slot<br>
&lt;dael> myles: can't imagine an impl that stores original string<br>
&lt;dael> Rossen: Make it available to things like dev tools. It's there. Not sure if it's required and useful. I think that's the discussion<br>
&lt;dael> TabAtkins: 2 comments above linked eric made a table of who returns what.<br>
&lt;fantasai> table https://github.com/w3c/csswg-drafts/issues/3261#issuecomment-435698461<br>
&lt;dael> astearns: One argument to normalize is to make it easier for script to parse. Handling string as spec they have to impl browser's normalization to get useful information<br>
&lt;dael> emilio: Other hand this is only string that would get nromalized. All others we jsut store and return the string. This is special<br>
&lt;dael> Rossen: What's an example of other properties?<br>
&lt;dael> TabAtkins: Every other prop that takes string takes text or a name. This is one place where it's a string for non-string purposes<br>
&lt;dbaron> I think there might have been one other case recently where we did normalization inside a string...<br>
&lt;dbaron> (or maybe it was this one)<br>
&lt;dael> Rossen: That's why asking for example. This is the only snowflake where we're defining behavior and not something simplier<br>
&lt;dael> Rossen: I think current normalized format seems reasonable<br>
&lt;dael> emilio: Arguments for both. Either you make it easier for script to parse it or just reserve right thing useful for editors. Don't have strong preference, but we need interop<br>
&lt;dael> Rossen: Not sure what you mean by editors. WYSIWYG type things are using script APIs so that would be also easier<br>
&lt;dael> myles: Another axis is for an impl [missed]<br>
&lt;dbaron> I think emilio might be on a 10 second plus lag<br>
&lt;tantek> q?<br>
&lt;dael> astearns: Myles first, then emilio. If you're not talking please mute<br>
&lt;emilio> yeah, I think I'm lageged<br>
&lt;emilio> *lagged<br>
&lt;dbaron> I think (a) the echo is emilio and (b) the delay in the echo is showing how much lag emilio is seeing<br>
&lt;dael> myles: THis is speed vs memory trade off. If don't store original you can build it but that's slower<br>
&lt;dael> astearns: emilio go ahead<br>
&lt;dael> emilio: On the dev tools or the CSS editor you can set one thing and after it's applied you get something different. That's an issue reported in chromium. Whne you use repeat we're only returning computed values because we're not storing. That's a similar issue<br>
&lt;dbaron> s/emilio/rego/<br>
&lt;dael> Rossen: Your point is right on. Had this discussion at length with repeaters. I had a similar argument for keeping normalized computed for same purpose so you can represent a repeat. Consensus at that point is if you're building an editor you have enough source information to rebuild that knowledge and use the used values to infer what engine processed.<br>
&lt;dael> Rossen: I think consistency is something we should value between repeat and this one. In which case we'd have to stick with normalized version<br>
&lt;dael> astearns: emilio are you back?<br>
&lt;dael> emilio: Yes, I'm fine with whatever decision we take. Rossen argument is fine<br>
&lt;dael> astearns: Prop: Use the normalized value to serialize grid-template-areas<br>
&lt;dael> astearns: Obj?<br>
&lt;dael> RESOLVED: Use the normalized value to serialize grid-template-areas<br>
&lt;dael> astearns: Was this a grid issue sweep for publishing?<br>
&lt;dael> fantasai: NOt yet, but hoping by next week. If interested in review, these edits need to go in and there's one or two items open with small details<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3261#issuecomment-446672986 using your GitHub account
Received on Wednesday, 12 December 2018 17:29:45 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:41 UTC