- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 24 Jan 2020 12:54:58 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-text] Atomic inlines being equivalent to ID for line breaking is not web-compatible`, and agreed to the following: * `RESOLVED: Atomic inlines by default always introduce a break opportunity, regardless of context` <details><summary>The full IRC log of that discussion</summary> <emilio> Topic: [css-text] Atomic inlines being equivalent to ID for line breaking is not web-compatible<br> <emilio> github: https://github.com/w3c/csswg-drafts/issues/4576<br> <RossenF2F> github:https://github.com/w3c/csswg-drafts/issues/4576<br> <emilio> florian: it's specified in CSS text that atomic inlines are equivalent to ideograph<br> <emilio> ... but apparently authors expect that there would be a break where breaks would usually be forbidden between a break and an ideograph<br> <emilio> ... (See https://bugs.chromium.org/p/chromium/issues/detail?id=1025715)<br> <emilio> fantasai: I'm sad about this<br> <emilio> ... there's a number of cases where images should behave more like characters<br> <emilio> ... and if we always break stuff like gagii<br> <fantasai> s/gagii/gaiji/<br> <emilio> ... will typeset badly<br> <emilio> hober: if it's possible for authors to write content to do the right thing and we have consistent behavior<br> <emilio> ... then we should put that on the spec and indicate how to tweak it<br> <emilio> fantasai: the current spec behavior doesn't match implementations but it's easy to tweak<br> <emilio> ... into solving all the different use cases<br> <emilio> florian: if we treat images like ID then you can use standard properties to allow it to break<br> <RossenF2F> q?<br> <emilio> ... otherwise we can't<br> <emilio> myles: well I agree we should solve it but we can't solve this this way because it's not web-compatible<br> <fremy> q?<br> <emilio> fantasai: we could reuse the line-break property<br> <emilio> ... and make the strict value make atomic inlines<br> <emilio> faceless: so this seems like the breakness depends on the image<br> <hober> q+<br> <emilio> ... can we set a property on an image?<br> <emilio> florian: line-break on the image would tweak this<br> <koji> q+<br> <florian> q+<br> <emilio> fantasai: The `line-break` property is exactly about the interactions between breaks and punctuation so I think it makes sense to reuse the strict value here.<br> <fantasai> there are wrap-* properties in css-text-4 that allow control over breaking, to forbid or allow unconditionally, but they're not context-dependent on surrounding punctuation, so they're not appropriate for this situation<br> <RossenF2F> ack hober<br> <emilio> hober: I like the shape of fantasai's compromise here... I think there are a couple open questions but I think that's the right direction<br> <emilio> ... I'm still kinda leaning for it to be a different property, but mostly for aesthetic reasons<br> <fremy> q+<br> <emilio> ... I'm concerned with the compat effect of reusing strict<br> <emilio> ... I'd be willing to agree that we should do something like this<br> <emilio> ... but whether it's the strict keyword or a new keyword should probably have some kind of research<br> <emilio> fantasai: I think not a lot of pages use line-break strict<br> <RossenF2F> ack koji<br> <emilio> ... and they're likely CJK which are more likely to use this behavior<br> <emilio> koji: I'd like to combine line-break normal with this behavior<br> <emilio> fantasai: you can have your paragraph with line-break: normal, but the images with line-break: strict<br> <emilio> koji: what about inline-block? Those are a block inside<br> <emilio> fantasai: I suspect those are much less likely to want this behavior<br> <myles> q+<br> <RossenF2F> ack florian<br> <emilio> florian: I think we could make the loosey image breaking behavior if we use `line-break` != `auto`<br> <emilio> ... that way it'd just work... non-default line-break is weird<br> <RossenF2F> ack fremy<br> <emilio> ... widening the scope of the issue a bit, is that there's another issue with breaking around images, which is that `&nbsp;` around it behave like normal spaces<br> <emilio> fremy: when I try to solve this myself is just putting a span on the break elements, but doesn't seem to be interoperable<br> <emilio> RossenF2F: also there's a lot CJK elements<br> <RossenF2F> q?<br> <RossenF2F> ack myles<br> <emilio> myles: I like that you can select the gaiji with a selector<br> <emilio> ... koji makes a really good point<br> <emilio> ... when I think about line-break values I think about text and paragraphs<br> <emilio> ... not images and inline-blocks<br> <emilio> fantasai: I think we can go with florian's proposal<br> <astearns> I'm less enthusiastic about having a text property modify the behavior of images as a side-effect<br> <emilio> myles: some people may want the break on the left of the image<br> <emilio> astearns++<br> <emilio> fantasai: we have controls for that in level 4<br> <emilio> myles: can this use them instead?<br> <emilio> fantasai: no you can't, because those are not contextual<br> <emilio> ... but opting in to treat this as an ideographic character is good<br> <emilio> ... the level 4 properties are unconditional<br> <emilio> ... emojis, small kana and such things these images should be treated like this<br> <emilio> ... which is why it fits with line-break<br> <emilio> myles: I'd like some more time to think about this<br> <emilio> ... maybe a way to tell an image which kind of text it wants to be<br> <emilio> ... I also think it's important to get the default behavior in the spec agreement with implementations<br> <emilio> RESOLVED: Atomic inlines by default always introduce a break opportunity, regardless of context<br> <emilio> ACTION: Investigate using the line-break property to tweak this behavior<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4576#issuecomment-578119202 using your GitHub account
Received on Friday, 24 January 2020 12:55:00 UTC