Adjusts the lengths of lines in a paragraph balanced, for better readability and to prevent typographic widows. This feature is often used in headlines.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No.
113
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
he CSS spec is still in early stage, it may be renamed, or the value may be moved to other properties, in that case, we may want to keep the current syntax for a while.--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1d%2B-YUM4_3ceOMkajB6BNK3WtkYhv3b3wOxQHrciTtWbqg%40mail.gmail.com.
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAWBYDAmKU3T-M-yyM5SywbSVj2iTUcdqWXCNSdSV6Xco3TGdw%40mail.gmail.com.
> This intent to ship just says that you will ship 'text-wrap'. It doesn't say
> that you will also implement 'white-space-collapse' (the other longhand of
> 'white-space') or the shorthanding relationship between 'text-wrap' and
> 'white-space'. I therefore assume you're shipping 'text-wrap' as an
> independent property, and this is not going to be spec-compatible.
Koji will need to speak to this.
Looks like the tests are in https://wpt.fyi/results/css/css-text/white-space?label=master&label=experimental&aligned&view=subtest&q=balance. There's one failing test there, do you know why that is?
And overall, are you happy with the test coverage here, does it cover most important corner cases?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdZTqRA5x2qpsBZq00Dzvv%3DW-y9cGT4UKxVZXKExfs0HA%40mail.gmail.com.
Looks like the tests are in https://wpt.fyi/results/css/css-text/white-space?label=master&label=experimental&aligned&view=subtest&q=balance. There's one failing test there, do you know why that is?Thanks for pointing this out. The test passes in Chromium repo, I'll investigate why it fails in wpt.
And overall, are you happy with the test coverage here, does it cover most important corner cases?I'm keeping eyes on incoming issues and feedback. It's a pleasant surprise that more web devs than expected are excited with this feature, and gave us great feedback such as this test results. Paragraph-level line breaking is a new area for browsers, there should be more rooms to improve further and I'm looking into them, but I think it's at a good quality to ship, and we can expect more feedback for the next stage.
On Mon, Mar 13, 2023 at 9:02 AM Koji Ishii <ko...@chromium.org> wrote:Looks like the tests are in https://wpt.fyi/results/css/css-text/white-space?label=master&label=experimental&aligned&view=subtest&q=balance. There's one failing test there, do you know why that is?Thanks for pointing this out. The test passes in Chromium repo, I'll investigate why it fails in wpt.Thank you!
And overall, are you happy with the test coverage here, does it cover most important corner cases?I'm keeping eyes on incoming issues and feedback. It's a pleasant surprise that more web devs than expected are excited with this feature, and gave us great feedback such as this test results. Paragraph-level line breaking is a new area for browsers, there should be more rooms to improve further and I'm looking into them, but I think it's at a good quality to ship, and we can expect more feedback for the next stage.Yeah there seems to be a lot of excitement for this feature, which is great! I think you're saying that the test coverage in WPT is good, and there aren't any known missing areas that you're aware of, is that right?
On Thu, Mar 16, 2023 at 12:51 AM Philip Jägenstedt <foo...@chromium.org> wrote:On Mon, Mar 13, 2023 at 9:02 AM Koji Ishii <ko...@chromium.org> wrote:Looks like the tests are in https://wpt.fyi/results/css/css-text/white-space?label=master&label=experimental&aligned&view=subtest&q=balance. There's one failing test there, do you know why that is?Thanks for pointing this out. The test passes in Chromium repo, I'll investigate why it fails in wpt.Thank you!It turned out that the build in the wpt is DEV, not Canary, so it should turn to green soon.
> This intent to ship just says that you will ship 'text-wrap'. It doesn't say
> that you will also implement 'white-space-collapse' (the other longhand of
> 'white-space') or the shorthanding relationship between 'text-wrap' and
> 'white-space'. I therefore assume you're shipping 'text-wrap' as an
> independent property, and this is not going to be spec-compatible.
Koji will need to speak to this.We have implemented a similar approach as the vertical-align/baseline-source case so that setting the `white-space` resets the `text-wrap: wrap`. The current impl passes this cascading test.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dJ8QeZFYbCQHUNdpPFZG2Sx1%3DmTLco-CABCV6u1ogF%3D6A%40mail.gmail.com.
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'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'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
and it raises questions about sizing and floats, among other things.
See also questions in the 2nd paragraph of
https://groups.google.com/a/chromium.org/g/blink-dev/c/f5eLz6PIXaI/m/a9OGhvaNAAAJ
which seem to have been mostly ignored...
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dLOsjmKLjH4t1qVJAtTD0zfUKQpLd%2BfYrgtCcNRu5ijhA%40mail.gmail.com.
--
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+...@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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1d%2B-YUM4_3ceOMkajB6BNK3WtkYhv3b3wOxQHrciTtWbqg%40mail.gmail.com.
On 3/17/23 02:02, Koji Ishii wrote:
> On Fri, Mar 17, 2023 at 4:40 AM fantasai <fantasa...@inkedblade.net
> <mailto:fantasa...@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.
>
> 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.
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.
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?
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.
> 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?
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)
* Interaction with `initial-letter` (no tests in WPT)
* 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?
> 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
--
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+...@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.
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 (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.