- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Dec 2018 17:33:58 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Prevent line breaking after explicit hyphens`, and agreed to the following: * `RESOLVED: add a clarifying note to L3 and discuss a potential new value in L4` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Prevent line breaking after explicit hyphens<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/3434<br> <fantasai> tantek, so does D<br> <tantek> fantasai, you're proving my point that appendices are in general informative<br> <fantasai> tantek, E doesn't say anything -- it's normative<br> <fantasai> tantek, F says it's informative explicitly<br> <fantasai> etc.<br> <dael> florian: Not entirely clear to me at least and at least one other impl if hyphens none is meant for only suppressing invisible but leave existing hyphens alone or if it's meant to turn off wrapping opportunity at regular hyphens<br> <dael> florian: koji and I think fantasai understood to not doing anything to normal hyphens. But I read that it's no breaking at hyphens. either way we should clarify. If we clarify to say it's not suppressed maybe explore a control in the next level<br> <dael> florian: Current spec is not clear so we should clarify<br> <dael> florian: Spec says suppresses hyphenation opportunities. Doesn't define a hyphenation opportunity.<br> <dael> florian: That's where ambig comes from<br> <dael> dbaron: You'd think hypenation opp is different then breaking opp.<br> <fantasai> https://drafts.csswg.org/css-text-3/#hyphenation<br> <dael> florian: Different from wrapping opp. Wrapping opp that's right after a hyphen is different. I can see it's reasonable for the spec to mean it<br> <dael> AmeliaBR: As an author, I've come across places where I want to suppress break at hypens. But you can do that by turning off wrapping<br> <dael> florian: You can do it with extra mark up.<br> <dael> astearns: Need extra to signal intent. It's not breaking at any breaking opp. in that string. If you have a reg hyphen and words on either side with breaking opp. you don't want those to break either<br> <myles> ++astearns<br> <dael> florian: You mean you would allow in other places as well? The automatic hypenation. But in this no auto, go wrapping.<br> <dael> astearns: You want markup on the special words where you don't want entire term to break<br> <dael> florian: Not opposed to saying hyphens:none does not disable wrapping at reg hyphens. I think we could use a little clarification<br> <dael> florian: It does seem that's what spec intends, but was no obvious<br> <dael> AmeliaBR: I like clarifying hyphenation opp is opp to insert a hyphen. Breaking opp is second to that.<br> <dael> florian: And we can re-open an issue on L4 to expore if we want an automatic way of doing this.<br> <dael> dauwhe: We have general rule where we don't want to hyphenate hyphenated phrases and I'd love some css control for that that doesn't involve preprocessing thousands of words. But that's L4<br> <dael> dauwhe: We don't want to hyphenate words with intrinsic hypens<br> <dael> florian: That's dealt with. This is a different case.<br> <dael> dauwhe: I'm phrasing in a differnet way. But yes we don't want line breaks anywhere in those phases as astearns said<br> <dael> fantasai: Seems really weird that you'd take hyphenated phrase like one in issue, forbid breaking in a long term is unusually strict. I can see not breaking at a point that's not the hyphen, but breaking at hyphen I don't imagine you'd want to suppress.<br> <bradk> “E-Mail” should not wrap<br> <dael> fantasai: Case here is someone that doesn't want hyphenation and is getting breaks at hyphens. And they thought they turned off hyphens and think hyphens and breaking is analogous<br> <dael> AmeliaBR: I think there is a property for hyphen w/o break<br> <AmeliaBR> s/property/Unicode character/<br> <dael> fantasai: I think it makes sense suppress hyphens at breaks through hypens prop. Given current state of impl none does not suppress those breaks. Might mean we add a value in L4 that means no really don't break at hyphens or hypenation points<br> <dael> myles: What's the exampl?<br> <AmeliaBR> @bradk, I think that would also be covered by hyphenate-limit-chars https://drafts.csswg.org/css-text-4/#hyphenate-char-limits<br> <dael> florian: bradk 's IRC example. You'd never want e-mail to break<br> <dael> myles: This is about things like long-term and t-shirt<br> <dauwhe> https://www.princexml.com/doc-refs/#prop-prince-hyphenate-before<br> <dael> fantasai: t-shirt could be a case where you don't break if it's less then 2 char on other side. You can control that for hyphenation in L4.<br> <dael> fantasai: long-term breaking there is less likely to be because each half is too short<br> <dael> florian: Seems like stylistic choice in this case<br> <dael> florian: Can we resolve for L3 to clarify as AmeliaBR and I spoke of and leave it open for L4 and hash it out there? Seem reasonable?<br> <dael> myles: One more thought, in section it says it affects searching and copying. I think affecting copying is a feature not a bug.<br> <dael> florian: Possibly. Searching is more annoying<br> <dael> myles: Have to look at searching. Searching is more complex<br> <dael> fantasai: [missed]<br> <fantasai> NFK normalization<br> <dael> florian: There was spec by i18n to help browsers figure out what to do when searching<br> <dael> myles: Like curly " match striaght "<br> <dael> myles: We use ICU u search facilities<br> <dael> florian: I think we're a little off topic. L3 hyphens:none doesn't do what we talked about, open issue in L4?<br> <dael> fantasai: I think we wouldn't change meaning of none in L4<br> <dael> florian: We might add a value<br> <dael> fantasai: fine with me<br> <bradk> 👍<br> <dael> Rossen: Any objections to add a clarifying note to L3 and discuss a potential new value in L4?<br> <dael> RESOLVED: add a clarifying note to L3 and discuss a potential new value in L4<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3434#issuecomment-448680240 using your GitHub account
Received on Wednesday, 19 December 2018 17:33:59 UTC