-
Notifications
You must be signed in to change notification settings - Fork 184
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Distinguish between simple and complex initial values in data/css/properties.json #61
Comments
Agreed, I was relying on the previous behaviour of wrapping the https://github.com/ben-eb/postcss-reduce-initial/blob/master/src/acquire.js#L20-L21 |
Thanks for filing this John! We need a design decision here. I'm leaning towards option two "Prefix for prose value", but I have no strong feeling. Any other opinions? |
I think I prefer option 2 as well, as it seems like the least amount of effort to maintain and update, and cognitive overhead to understand. There is little in it between 2 and 3, but the syntax of 2 is shorter and easier. I think 1 risks being a bit more confusing than necessary - needing to get the right key as well as the right value. |
Two votes for using a prefix, so let's go down that path. The goal is:
The implementer would write something like:
I'm not sure
Any favorites? Other ideas? |
(I'm thinking of |
When choosing a solution, it's worth considering that the solution must be scalable. The problem described also applies to other fields. For example, So my choice is using an object definition for special cases and left others as is. It's better over solution with prefixes for some reasons. One of them, we can define a JSON schema to validate it (I think it would be great to have a schema anyway). PS While writing the comment, I found some |
I think we all agree that additional keys is not the solution, no need for further beating of that straw man. I prefer
I don't like optional objects because I don't like having two ways to say the same thing. It makes parsing more complex and can lead to ambiguities. However, it would be an acceptable compromise for readability, since we're hoping for manual contributions. I agree that the short version should imply literal values. JSON Schema is good for structural validation, but I don't think it is sufficient for validation of these keys into the string structure. For example, I think JSON Schema would be OK with That's a long way of saying my preference is still a prefix of |
Add a prefix of '__l10nkey' to values that are look-ups in the l10n/css.json file. See issue mdn#61.
See #67 for what the css/properties.json would look like with the prefixes applied everywhere. Some notable things:
|
My thoughts about changes in #67:
|
Thanks for your feedback. I think some of it would be clearer on #67, where you can add your comments to specific lines of the changed JSON, and I can refine the PR to be more correct. There's some issues that you have identified that need fixed. |
After thinking about it for a while, I'm 👎 on using the prefix, and I like the idea of a different key for prose descriptions more, such as: "align-self": {
"initial": "auto"
},
"all": {
"initialText": "There is no practical initial value for it."
},
"animation": {
"initial": [
"animation-name",
"animation-duration",
"animation-timing-function",
"animation-delay",
"animation-iteration-count",
"animation-direction",
"animation-fill-mode",
"animation-play-state"
]
} So the default of |
@jwhitlock How does the connection to our localization then look like? Sebastian |
I was thinking something like this:
My plan may change as I implement localization in the KumaScript macros. I plan to get this working for |
In data/css/properties.json, the
initial
value can be:0
,0% 0%
,none
, orauto
. This used to be wrapped like<code>0</code>
noneButOverriddenInUserAgentCSS
ornoPracticalInitialValue
.I've proposed mdn/kumascript#162 to distinguish between cases 1 and 2, but it would be better to have a clearer signal in the data. Some straw man suggestions:
Different Keys for literal vs. prose initial values. Advantage - unambiguous. Disadvantage - users must update.
Prefix for prose value, none for literals. Advantage - same key, quick check for literal vs prose. Disadvantage - pick a universal prefix, users must process to get prose key.
Initial objects instead of strings. Advantage - unambiguous, allows for future expansion, mixing literals and prose. Disadvantage - detect object vs list, overly wordy.
The text was updated successfully, but these errors were encountered: