- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Tue, 17 Apr 2018 10:04:18 +0000
- To: public-css-archive@w3.org
I agree that the spec's text here is a little loose and with the problems that this causes. I think we should: 1. Change the Computed Value in `text-align-all` propdef's table what it currently says in the propdef table of `text-align`. 2. Change the entries in propdef table of `text-align` to "See individual properties" 3. Move the definition of all values from `text-align` to `text-align-all` (except `justify-all`). The second sentence in the definition of `justify` becomes a note (since the normative behavior is already in `text-align-last`). 4. Change this sentence in the description of of `text-align` >All values except `justify-all` reset `text-align-last` to `auto`. to > All values except `justify-all` are set as-is to `text-align-all` and reset `text-align-last` to `auto`. `justify-all` sets both `text-align-all` and `text-align-last` to `justify`. 5. Add the following sentence to the definition of `match-parent`: > If specified on the root element, `match-parent` behaves identically to `initial`. 6. When `text-align` is`match-parent`, is `text-align-all` really meant to be `auto`, implying start based on the direction of the element itself? The alternative would be match the value of `text-align-last` on the parent, with `start` and `end` resolved to`left` or `right` depending on the direction of that parent. The spec as it is (and the suggested edits above) imply the former, but the later seems more useful. For the later, we can either describe this logic in the shorthand, or add `match-parent` as a value to `text-align-last` as well, and have `text-align: match-parent` pass the value to both long hands. As far as I can tell, browsers are not interoperable, and none of them do either what the spec says or what I suggested we fix it to: * Chrome: - implements `text-align` and `text-align-last` as separate properties, neither of which resets the other. - does not support the `text-align-all` property nor the `match-parent` or `justify-all` values of `text-align`. * Firefox: - implements `text-align` and `text-align-last` as separate properties, neither of which resets the other. - does not support the `text-align-all` property nor the `justify-all` value of `text-align`. - **does support** `text-align:match-parent`. As a consequence of the previous points, when `text-align` is `match-parent` and the parent's `text-align` is `start`, `end`, `left` or `right` but not when it is `justify` (for `center` it is irrelevant), it resolves the direction of `text-align-last:auto` but not `text-align-last:start` and `text-align-last:end` against the direction of the parent. * Edge: - implements `text-align` and `text-align-last` as separate properties, neither of which resets the other. - does not support the `text-align-all` property nor the `match-parent` or `justify-all` values of `text-align`. - does not support the `start` and `end` values, but somehow has an unnamed initial value for the `text-align` property (that the user cannot specify other than by using `initial`) that behaves like `start` (and properly inherits), but shows up as `left` or `right` in getComputedStyle. - the value of the text-align-last property has no effect unless `text-align` is `justify` * Safari does not implement `text-align-last` at all. * I did not test, but judging from documentation, it looks like Prince does the same as Edge, and AntennaHouse does the same as Chrome. Vivliostyle matches the underlying browser. None of these seem more useful than what is specified, and all of them would probably require complicated handling of `match-parent` similar to what Firefox does when support for that value is added. Therefore, I suggest we do not align the spec with implementations, but do fix the spec as suggested above. Alternatively, since nobody supports `justify-all`, we could also change the syntax of the `text-align` shorthand to: '<text-align-all> <text-align-last>?'. If the second one is omitted, it defaults to `auto`. It seems it would be a more conventional syntax. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2577#issuecomment-381931723 using your GitHub account
Received on Tuesday, 17 April 2018 10:04:21 UTC