On Thu, Mar 23, 2023 at 3:41 PM Ian Kilpatrick <ikilpatr...@chromium.org> wrote:
> The reason we opted for the partially-implemented shorthand behaviour > initially was the shorthand aspect of the specification appeared to be in > an incomplete/unstable state. We've heard significant desire for the > text-wrap:balance feature from web developers, and this analysis was based > upon the specification at that stage so that we can meet that developer > need now. > > This behaviour would have mitigated most of the forwards compatibility > risk while this section of the specification matured. > > Since sending this intent the specification for how the new shorthand > works has changed significantly > <https://github.com/w3c/csswg-drafts/commit/4717dbcb83634fb108e36bd5846dd5942cd539a0> > (for the better, thanks!). > > We are happy with these recent changes and in the next week will attempt > the shorthand (without the white-space-trim property, and new values for > the other properties). There are still corner-case compat risks with a > property like this which has been on the web for a significant amount of > time, perhaps mostly in editing use cases, which have a stronger need to > read back serialized style strings. > > We implemented the shorthand changes above and were happy with the result. Ian > Also, note that we have not yet turned the feature on in Chromium, and > won’t do so until the shorthand work mentioned above is done and we’ve > reported the results back to this thread. > > On Mon, Mar 20, 2023 at 10:27 PM fantasai <fantasai.li...@inkedblade.net> > wrote: > >> On 3/17/23 02:02, Koji Ishii wrote: >> > On Fri, Mar 17, 2023 at 4:40 AM fantasai <fantasai.li...@inkedblade.net >> > <mailto:fantasai.li...@inkedblade.net>> wrote: >> > >> > That test doesn't cover the interaction of other values of >> `white-space` with >> > the `nowrap` value of `text-wrap`. It would be incorrect for e.g. >> > `white-space: pre` to return `text-wrap: wrap`. >> > >> > I think it would be better to just implement both longhands of >> `white-space` >> > properly. >> > > I think this is covered by my summary comment above. > > >> > >> > Implementing `nowrap` and other values is easy but it creates other new >> compat >> > risks that are more difficult for authors to handle. >> >> Can you outline these new compat risks that only apply to `nowrap`? Also, >> are >> they filed as an issue against the CSS spec? If there is a real compat >> risk to >> implementing the spec, then the spec needs to be changed. >> > > The compat risk Koji mentioned here would be resolved by the > shorthandifying we’re prototyping now. > > >> >> Note that if the spec changes to not have a shorthanding relationship due >> to >> compat risks, then that means your implementation would need to change to >> stop >> faking a shorthand relationship also. >> >> Going back to that first quoted point: you are currently not testing the >> value >> of `text-wrap` when `white-space: pre` has been declared. If you are >> returning >> `text-wrap: wrap` rather than `text-wrap: nowrap`, then we have a >> problem, >> because that is not compatible with what the spec requires. >> > > This would also be resolved by the current prototyping. > > >> >> Since you think this is the correct thing to do, can you explain why you >> think >> it is better for Blink to ship a behavior change in the future (to match >> the >> spec) vs. shipping the correct behavior initially? >> > > I think this is answered by my summary comment above. > > >> >> Btw, I notice you are only testing the shorthanding side-effects you have >> carefully faked in your code, rather than all of them. I know it's >> natural to >> only write (passing) tests for things you've specifically implemented, >> but it >> is misleading... because if Blink intends to ever follow the spec, there >> are >> property interactions here that will noticeably change. And your >> reviewers >> should be made aware of that. >> >> > With the current impl, authors can detect the situation by >> `supports(‘text-wrap: nowrap’)`. >> >> I don't understand what this suggestion is solving. >> > > Koji is referring here to something developers could potentially use to > work around any corner-case compat issues. > > >> >> > I'm not concerned about the quality of the balancing, as I'm sure >> it's fine, >> > and it will improve over time... my concerns are mainly with >> > a) interaction of the properties >> > b) any layout interactions with e.g. floats, initial-letter, >> positioning, >> > text justification, box sizing, etc. >> > c) whether the CSSWG considers this stable enough to ship, or if >> there are >> > unresolved concerns about the design of the feature >> > >> > I understand that the spec is still in early draft, it’s WD, not CR, >> PR, nor >> > REC. If the spec changes, we can change our implementation accordingly. >> >> As far as I understand, once Blink ships something, whether it is willing >> to >> change its implementation generally depends on the usage rates of the new >> feature. So if Blink ships the feature, and it is widely used, then Blink >> would be unwilling to change or drop the feature. Does that not apply >> here? >> > > It’s true that once shipped we’d have to do a compat analysis in order to > change the implementation. But we don’t think there is a significant compat > risk, even more so if our current prototyping of a shorthand works out. > > >> >> Also, why not ask the CSSWG about (c)? >> >> > I'll note that there was an issue filed in the CSSWG repo recently >> in >> > response >> > to the Blink implementation: >> > https://github.com/w3c/csswg-drafts/issues/8516 >> > <https://github.com/w3c/csswg-drafts/issues/8516> >> > and it raises questions about sizing and floats, among other things. >> > >> > Thank you for citing this, yes, that was great feedback. I fixed bugs >> reported >> > there, Tab and I responded, and the reporter responded “agree that this >> is the >> > best approach >> > < >> https://github.com/w3c/csswg-drafts/issues/8516#issuecomment-1453802827 >> >”. >> >> The reporter was agreeing specifically with adjusting the limit to 4 >> lines >> rather than 10, not with anything else. Some of the other points brought >> up by >> the reporter include: >> >> * Interaction with `text-align` (which you seem to have fixed) >> * Interaction with floats (no tests in WPT) >> > > We believe that this feature is incompatible with complex float > interactions, and as such our initial implementation disables balancing > (similar to if we exceed 4 lines). > > Currently we don't support the combination of initial-letter and some > basic float interactions, but we plan on making improvements soon that we > anticipate are web compatible. There still will be some restrictions, but > we don't believe the spec should restrict usage at this time. > > >> * Interaction with `initial-letter` (no tests in WPT) >> > > See above. > > >> * Interaction with intrinsic sizing (not seriously discussed, but imho >> one of >> the most important questions that would have been worth investigating >> with the >> prototype) >> >> > See also questions in the 2nd paragraph of >> > >> https://groups.google.com/a/chromium.org/g/blink-dev/c/f5eLz6PIXaI/m/a9OGhvaNAAAJ >> < >> https://groups.google.com/a/chromium.org/g/blink-dev/c/f5eLz6PIXaI/m/a9OGhvaNAAAJ >> > >> > which seem to have been mostly ignored... >> > >> > The #8516 you cited above < >> https://github.com/w3c/csswg-drafts/issues/8516> >> > has some initial feedback. >> I also asked some specific questions inline, so let me quote them in list >> form >> since they seem to be repeatedly overlooked: >> >> * Will this be sufficiently useful without any integration into intrinsic >> sizing? >> * Does it actually solve the problems authors want it to solve, or is >> there >> something still unsatisfied here? >> > > I think Adam has addressed these questions. > > >> >> > Also I will share any feedback we get with the WG and I look forward >> to >> discussing them. >> >> I think it would be useful to know if you have positive feedback from web >> developers who have tried to incorporate it into actual designs, or if >> you >> only have feedback that developers are “excited about something like >> this” but >> have not experimented enough to think about important details that might >> matter to them (like the interaction with intrinsic sizing). >> >> > If spec changes from the discussions, as I stated above, we’re willing >> to match the new spec. >> >> You say that, but you're not even willing to match the spec in terms of >> shorthanding... :/ >> >> ~fantasai >> > > Thanks for all the detailed feedback! > > Ian > > >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d66a3d90-f16e-13f2-5ffc-335dda06bd3f%40inkedblade.net >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpQ4ckfy_srSKVrPX-hSdwCpDU7aRAeUScZiJE9W0pN5FA%40mail.gmail.com.
