- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Thu, 16 Aug 2018 13:39:32 +0000
- To: public-css-archive@w3.org
> On the one day they are supporting word-break: break-word and on the next day There was never a group resolution to add that feature under this syntax. It made it to the drafts by mistake, and was removed as soon as the mistake was noticed. There has always been strong reluctance to adding it, not because it is not useful, but because it makes everything else more complicated. > On the one day they are adding calculating min-content size in overflow-wrap: break-word, on the other day they are revert this. This has not been reverted. This was added to the *draft* with the hope that this addition was possible, and we're in the process of checking whether it is. There's a chance that it is not. If so, that will be reverted. > Is this a description for a standard or a mess? How a web-devs or even browser-devs can take changes for real? The current situation on the web is a mess. The world often is. We are attempting to find a non-messy solution to a messy problem. Maybe compatibility constraints will prove this impossible, and we will need a messy solution (`word-break: break-word` is considered messy). Maybe we will solve it cleanly. Here is what the "Status of the document" says: > This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress. or, if you are reading this on TR/ > Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. > Not webcompatible? Maybe we need to fix it once without compomises? If there was a solution that did not involve any compromise, we would have taken it. Taking `work-break: break-word` as upsides (adds the feature, fixes existing sites), and down-sides (it makes everything harder to understand, maintain, and evolve). Make `overflow-wrap: break-word` affect sizing has upsides (adds the feature, it fixes some existing sites, fits the system better), and downsides (doesn't fix all sites, breaks some). Adding a new value to `overflow-wrap` that behaves like `break-word` but also affects sizing has upsides (it doesn't break anything, adds the feature, fits well into the system), and downsides (sites need to be updated to opt into the fix, two values for almost the same thing seem unfortunate). So we're weighing the pros and cons, and to figure out the full extend of the compatibility problem, the most efficient way is to try to implement in test builds and see what happens. Nobody is happy about this situation. But there isn't an obviously right answer we can all just get behind, so -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2951#issuecomment-413548720 using your GitHub account
Received on Thursday, 16 August 2018 13:39:33 UTC