- From: Sebastian Zartner via GitHub <sysbot+gh@w3.org>
- Date: Sat, 24 Jun 2017 23:49:29 +0000
- To: public-css-archive@w3.org
> 1. Would adding a keyword safe for serialization? If not, are you happy to have another property to control the behavior? My earlier statement about `normal inside inline-end` being the default value was wrong. `normal` would stay the default, of course. And serialization wouldn't be a problem, because both `normal` and `<length>` values (without the new keywords) would still be serialized the same way like now. > 2. #1517 indicates a) existing behavior is not interoperable and b) no browsers do inline-end. Would you be ok with like `auto` for compat, or do we want to align the behavior first in #1517? I just realized that my proposed syntax is web-incompatible. It should have been: letter-spacing: normal | <length> [ inside || [ outside | inline-start | inline-end ] ]? Where `<length>` values without keywords are interpreted as `<length> inside inline-end`, for compatibility. Regarding your question, I'd say the behavior should be aligned first, so it's easier to add the new values. Also, I assume there may be no use case for having `inside` as separate value. I just added it for completeness. And `outside` could also be expressed by allowing both `inline-start` and `inline-end` to be specified at the same time. So, the syntax could be simplified to: letter-spacing: normal | <length> [ inline-start || inline-end ]? Btw. my [use case](https://bugzilla.mozilla.org/show_bug.cgi?id=125390#c38) (having number input where each digit is displayed in its own "block" [copying the layout of a printed form]) would already be covered if browsers implemented the spec. as it's currently specified, i.e. if the spacing weren't applied at the end edge. Though because that's not the case, I came up with this new syntax. Sebastian -- GitHub Notification of comment by SebastianZ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1518#issuecomment-310872706 using your GitHub account
Received on Saturday, 24 June 2017 23:49:35 UTC