- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 Mar 2016 17:31:51 -0400
- To: www-style@w3.org
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= Behavior of contains:paint and overflow:clip, text-overflow and resize properties --------------------------------------------------------------------- - RESOLVED: Remove any mention of overflow:clip from the containment spec and change section 3.3 to define that clipping happens (just not by affecting value of 'overflow') CSS Text -------- - RESOLVED: In order to prevent overflow or wrapping of invisible white space, spaces at the end of a line must either be visually collapsed to fit within the line or must hang outside the line (as in hanging punctuation) - RESOLVED: Add 'word-break: break-spaces' - RESOLVED: Drop pre-wrap-auto - RESOLVED: text-wrap: balance evaluation works off of remaining space in the line, not average line length. - The changes to text-decoration (in this e-mail: https://lists.w3.org/Archives/Public/www-style/2016Jan/0195.html) need to be explained further before a resolution can be reached. RESOLVED: Add word-break: break-word to spec if Edge/Firefox find it critical enough to Web compat to implement it. Exclusions and bidi ------------------- - RESOLVED: When a line is split by an exclusion, each side is its own line box for the purposes of bidi algorithm (i.e. they are effectively separated by a soft line wrap). Which line box is first depends on the block's directionality. ===== FULL MINUTES BELOW ====== Agenda: https://wiki.csswg.org/planning/sydney-2016 Scribe: fantasai Behavior of contains:paint and overflow:clip, text-overflow and resize properties ===================================================================== leviw: Position that I have is that we do not want to conflate the notion of having a resize handle and text-ellipsis with paint containment, leviw: keep that just a performance thing leviw: Want to support clip as overflow: clip leviw: But not have it as part of paint containment. leviw: Florian has different position. Florian: If we look at how we came to this, the reason clip was introduced and depended on Florian: Was that it wouldn't make sense to have resize handler and text-overflow: ellipsis containment on the other hand Florian: but not be able to have both at the same time, Florian: or the full effect over both at the same time. Florian: By the full effect of both at the same time, I mean, if you wanted both and didn't have 'clip', you'd need to have 'overflow: hidden' which may be less performant because of possibility of scrolling. leviw: We don't allocate the buffer but okay. Florian: If you support overflow: clip and you support containment, and authors can use both they can do everything they want to do. Florian: I would prefer one step less, but preference not a requirement. esprehn: If you trigger too much behavior, you break the multi-actor situation. esprehn: Two libraries: spreadsheet library that turns ellipsizing on/off. esprehn: Separately you have an animation library, which adds 'contains: paint" when it runs animation for performance reasons. esprehn: All of a sudden your ellipsis triggers. esprehn: I like idea that they are separate concepts. fantasai: Historical interesting point here, fantasai: which is that text-overflow:ellipsis should have always triggered, regardless of 'overflow', but for historic reasons due to WebKit's implementation, had to make it depend on overflow; not an intentional design. fantasai: Designing things architecturally around this concept seems awkward. Florian: For other implementers implementing containment, do you either also plan on implementing 'overflow: clip' *or* have an implementation of 'overflow: hidden' that has no performance cost? Florian: If that's the case, I'm okay with the plan. dbaron: We have more-or-less overflow: clip. Trivial to adjust it to current spec. Florian: Do you allocate a buffer for potential scrolling for overflow: hidden? fantasai: There's a different frame tree if it's scrollable. Florian: So there's a performance downside to hidden. dbaron: There is, but not graphics memory. <dbaron> (I don't think) Florian: I'm convinced by the multi-actor story. leviw: The change is that 'contains: paint' doesn't compute 'overflow: visible' to 'overflow: clip' ojan: This is section 3.3., delete item 1 ojan: Remove "must convert to clip" <leviw> https://drafts.csswg.org/css-containment/#containment-paint fantasai: "used value is clip" ? dbaron: Used value is messy <dbaron> (used value isn't really a general concept) <ojan> Proposed resolution: Remove any mention of overflow:clip from the containment spec and change section 3.3 to define that clipping happens (just not via used or computed values) RESOLVED: Remove any mention of overflow:clip from the containment spec and change section 3.3 to define that clipping happens (just not by affecting value of 'overflow') CSS Text ======== white-space: pre-wrap / pre-wrap-auto ------------------------------------- Florian: I want a resolution on this, in my head it's done. Florian: No idea how to get rest of group to agree. Florian: We discussed this in NYC, came to a resolution Florian: Which I'm happy with, but koji isn't. Florian: Being a co-editor of that spec, his point of view is at least somewhat relevant :) Florian: At a very high level my position is simple: Florian: 1. Interoperability is desirable Florian: 2. whitespace: pre-wrap should preserve and wrap. Florian: We don't have these things today. Florian: Browsers all do different things. Florian: Relevant question is what happens to white space at the end of a line. gregwhitworth: What was the resolution in NYC? Florian: Resolution at NYC was that white-space: pre-wrap would preserve white space, and break between spaces. Florian: This is not what is happening today. Florian: In Chrome and webkit, all white space is preserved *if it would not overflow*. Florian: The bit that would overflow is compacted to zero width Florian: which makes it very confusing when you're trying to edit. Florian: The Microsoft behavior does the white space, but the white space at the end of the line is allowed to overflow (like hanging-punctuation). Florian: Firefox behavior, which is what's specced, is preserved white space is non-breaking and break opportunity at the end of the run. Florian: Doesn't overflow, doesn't compact. <gregwhitworth> http://log.csswg.org/irc.w3.org/css/2015-05-18/#e553590 <gregwhitworth> resolution from NYC^. Florian: NYC resolution made the default behavior good for the case I care about. Florian: Koji is right to point out that this behavior is not great for other use cases. Florian: I'm okay to have default behavior that's not that. Florian: Whatever we resolve, the default behavior to be, we also need a mode where: Florian: 1. All white space is actually preserved. Florian: 2. It does not cause overflow, it does wrap. Florian: After that I have preferences on how it should wrap, but these are only preferences. Florian: Prefer that asking white space to wrap should not simultaneously allow arbitrary breakpoints in the middle of words. Florian: Fairly strong preference. SteveZ: Clarification, you have to pick some breakpoint at the end of the line. SteveZ: You're saying that breakpoint is the end of the line whether in a word or not, at least for one option, and you don't like that option. fantasai: I have a proposal. fantasai: My proposal is maybe in level 4 or possibly right now. fantasai: We define Microsoft's behavior as the default behavior fantasai: Because I think that makes the most sense. <tantek> is that Microsoft Word behavior? <koji> tantek, no fantasai: Add value to word-break property "break-spaces" fantasai: which allows breaks between white space characters. fantasai: I think that would be the best end result. koji: First, I'm not sure if we officially revert NYC resolution. Florian: I don't want to revert resolution and then close the discussion. I'm okay with reverting resolution in order to replace with better solution. SteveZ: I think a number of us willing to revert resolution if there is a replacement but not without one. SteveZ: So can't break it down like that. Let's agree on the replacement first. koji: For fantasai's proposal, agree on 2nd point add value to word-break property. koji: For first point, I would prefer of Word behavior over IE behavior. koji: It works better for me if default behavior is IE or Word (same as Chrome/WebKit). Florian: I prefer IE behavior, but okay with allowing both, Florian: On the condition that Chrome will break and wrap the extra spaces, not collapse them at the end of the line Florian: when word-break: break-spaces is specified. * fantasai agrees with Florian SteveZ: I'm getting confused, if the spaces disappear if I don't say "break-spaces", but they're visible if I say "break- spaces" SteveZ: Seems like that would be confusing to a user. Florian: This is why I prefer the IE behavior over the Chrome one. Florian: I think it's weird that in a mode called "white-space: preserve and wrap" it's not preserved. Florian: But given what's out there, I think it makes sense to allow it. [...] <gregwhitworth> http://jsbin.com/zudatozoqi/1/edit?html,output Florian: From 5-sec check, looks like Chrome is doing the IE behavior. ojan: My guess is that this was an accidental change, but maybe we'll keep it ^_^ Florian: In a quick demo, it looks like Chrome does what we've been calling the IE behavior. Florian: So I'm happy. Florian: Safari probably didn't accidentally do the same thing at the same time. Florian: So we probably still need the same exception. Florian: Unless Apple wants to align on the IE behavior for this? [...] fantasai: I think we should just allow both for now. Florian: Agree. ... dbaron: The IE behavior is that you're allowed to have white space hang outside the edge of the line box. Rossen: and it's scrollable space, I know :) :) :) tantek: It's scrollable!? tantek: You can scroll to see nothing? Florian: You should be able to scroll to see your caret when you are editing. tantek: We have so many problems with editing, we shouldn't solve this one either. <fantasai> Proposed resolution: Spaces at the end of a line must be either visually collapsed if they would either overflow or cause wrapping, or they must hang outside the line. <fantasai> In order to prevent overflow or wrapping of invisible white space, spaces at the end of a line must either be visually collapsed to fit within the line or must hang outside the line (as in hanging punctuation) <fantasai> (better wording) <fantasai> In order to prevent overflow or wrapping of invisible white space, spaces at the end of a line must either be visually collapsed to fit within the line or must hang outside the line (as in hanging punctuation) koji: This looks good to me koji: I still don't understand conversation over there (waves at gregwhitworth). koji: Seems there was some miscommunication, I think I'm fine if current Canary behavior is fine. fantasai: Proposed resolution has a second part: adding a break-spaces value to word-break fantasai: ... details to come later. fantasai: Definition is that breaks are allowed between whitespace characters. (to satisfy Florian's concern) SteveZ: Which means white space at the end of the line can wrap to the next line. tantek: You could resolve that independently. Florian: I want to resolve together, because replacing the NYC resolution means we lose what I want, unless we add this behavior. [tantek argues process stuff] <tantek> no I objected to tying too many things together. koji: One issue, NYC allowed breaking before spaces? Florian: Not doing that break is okay with me. [More arguing over process] dbaron: I'm not happy adding more stuff here. astearns: Are you objecting? dbaron: Not really. astearns: What we have sketched out seems like it'll get us better interop today, and will not close off functionality. dbaron: We should talk about functionality that exists today as functionality that we have interop on. tantek: I'm happy with NYC and happy with today's change that gives us more interop. tantek: I'm not okay to committing to new functionality, tantek: okay with leaving the door open. tantek: I'm not okay with committing to it, it's a separate discussion. Florian: If we have identified the way to solve a problem, let's put it in the spec and mark it at-risk. astearns: We've literally spent hours on this. Would you object to resolving to adding the new value to Text Level 4? astearns: Then we are resolving both, because I've heard nobody objecting to both. RESOLVED: In order to prevent overflow or wrapping of invisible white space, spaces at the end of a line must either be visually collapsed to fit within the line or must hang outside the line (as in hanging punctuation) RESOLVED: Add 'word-break: break-spaces' Florian: As part of that discussion, we added pre-wrap-auto, do we need it? fantasai: I'm strongly in favor of dropping it. RESOLVED: Drop pre-wrap-auto text-wrap: balance and fragmentation ------------------------------------ astearns: When you have text-wrap: balance, and the element fragments across fragmentainers, do you continue to try to balance? astearns: I think the answer is yes. Florian: Question is also what does balancing mean? fantasai: The goal is to minimize the sum of the squares of the extra space left in each line in the element across all fragmentainers. astearns: If I have a 2-line heading that fragments, then don't want to have one word on the second line. astearns: Bad enough on one page, it's worse if it's fragmented SteveZ: Balance means that every line in a given fragment has the same ending point, and there are an integral number of lines. SteveZ: If the second fragment is shorter than ... ? [Florian reads from the spec] Florian: You want to minimize the variation overall, but you want to do the averaging over the fragment. Florian: If your first fragment is 10em and the second is 4em don't want to balance at 7.5em. ... SteveZ: fantasai said it correctly. You want to minimize the extra space to the line, it's not the length of the text in the line you care about. SteveZ: If you say it that way, then you don't run into the issues Florian said. astearns: I'm happy to make that change. RESOLVED: text-wrap: balance evaluation works off of remaining space in the line, not average line length text-decoration --------------- koji: Topic is by Masayuki at Mozilla <astearns> https://readable-email.org/list/www-style/topic/css-text-decor-doesn-t-example-3-in-text-underline-position-break-current-ua-behavior koji: There was some conversation with fantasai and me. koji: Current text decoration assumes we have a UA style sheet to determine underline position based on language. koji: What Masayuki and myles and I prefer is that it be more automatic, koji: rather than UA style sheet to define. koji: Second point is that current syntax is extensible but more complicated than necessary today. koji: So prefer simpler syntax, koji: Good enough for now. fantasai: I don't think I understand why we are putting magic into auto instead of relying on UA style sheet. koji: Two value syntax is more complicated than single-value syntax koji: When single value can do the work, prefer single value for now. fantasai: I still don't understand the issue here, really, so I can't comment. dbaron: We didn't do text-emphasis the way the spec said. xidorn: What we did for text-emphasis-position was to implement it as a presentational hint. fantasai: So identically to UA style sheet, but it's at the wrong level of the cascade [which is mostly unnoticeable, unless you're in a user style sheet rather than author sheet] xidorn: ... xidorn: text-underline-position has specific concerns xidorn: text-underline-position is something authors are more likely to change. <koji> https://lists.w3.org/Archives/Public/www-style/2016Jan/0195.html [From the e-mail above: Clarify when "under" alone is used, its position in vertical flow is automatic (the behavior isn't defined today.) The value syntax could be one of: a. No change: auto | [ under || [ left | right ] ] b. Full options: auto | [ under || [ left | right | auto ]] c. Simpler: auto | under | left | right So now my proposal is above 1 and 2, and: 3. Clarify when "under" alone is used, its position in vertical flow is automatic (the behavior isn't defined today.) 4. The value syntax could be one of: a. No change: auto | [ under || [ left | right ] ] b. Full options: auto | [ under || [ left | right | auto ]] c. Simpler: auto | under | left | right ] fantasai: I agree with 4, I don't agree with 3. fantasai: I don't think we should have auto be language dependent, use the UA style sheet for that. fantasai: UA style sheet would assign CJK languages to left or right as appropriate fantasai: and everyone else would get auto. fantasai: left/right implies either auto or under, don't really care. fantasai: I think that auto should never switch the underline to the over side. koji: I don't know how Gecko switches between two underlines, but with this spec if the page has lang=ja, page would use automatic switching. xidorn: I don't think we've implemented that. xidorn: So we haven't supported text-underline-position yet. koji: Gecko changes underline position without property, depends on fonts or whatever. koji: Having this spec will force the underline position to be under. fantasai: Different fonts have different underline positions anyway. koji: Font information has alphabetic position. koji: If Japanese, most ignore that and draw at correct position. koji: When the page has lang=ja, this spec forces that underline- position is under. koji: What gecko does, or what I guess gecko does it regardless of language, using font or whatever information, they would use auto. koji: I actually agree that that's better behavior for CJK. koji: If the page has lang=ja, but still the underlined text is only alphabet, then underline should be drawn at baseline position. fantasai: I still don't understand what you're proposing so I can't comment on it... Scribe: Bert koji: I need to talk to Mozilla people and see if I can better understanding. astearns: Can that be on the www-style list instead? koji: Yes. koji I'll take it back to mailing list. astearns: OK, break now. <break duration=15min> word-break: break-word ---------------------- [This discussion shifted here from the end of the day.] <astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0010.html koji: I replied to mailing list about non-standard property to remove from blink and WebKit. koji: "word-break: break-word" koji: Should we add 'break-word" to the spec? koji: Historical from webkit. koji: It was historically added to WebKit for web compat despite being non-standard. BogdanBrinza: 9 years ago, change in webkit references IE7 BogdanBrinza: The usage is fairly high. BogdanBrinza: Used in yelp, stack overflow, fairly big sites koji: It's very similar to word-wrap: break-word except it doesn't expand the containers. koji: The use case is imagine normal word wrap where the text contains a long URL. koji: word-wrap: break-work expands the container while word-break: break-word will break the word to maintain the container size. <gregwhitworth> they add it to content editable by default, here's a testcase http://jsfiddle.net/pfe9mj4o/10/ koji: fantasai: Is Microsoft implementing this? BogdanBrinza: We are considering it, the web depends on it. BogdanBrinza: We will consider implementing it for web compat. fantasai: The naming is very confusing. Florian: These names are already confusing, adding this makes it worse. astearns: That's a good question, if there's a typo do you standardize it for web compatibility? fantasai: I think the better solution would have been to let the author set the minimum size of the table cell. Florian: Regarding this it sounds like you're considering this for web compat, I don't think the working group is best for this decision. Florian: Decide and if you do send us the spec of what you implement. fantasai: I don't object to adding this if implementers decide it's necessary for compat. RESOLVED: Add word-break: break-word to spec if Edge/Firefox find it critical enough to Web compat to implement it. Exclusions and bidi =================== Scribe: zcorpan koji: The issue is CSS exclusions when exclusions split a line. koji: bidi defines that after linebreak was determined. koji: bidi algorithm is applied to the line koji: so when the line is spread my multiple by css exclusions. koji: Does each part of the line apply to bidi algorithm? astearns: My understanding is that exclusions will fragment the linebox and each line will be individually considered for bidi. koji: That answers my question but it's not in the spec. shane: Is this the easier behavior? koji: Yes. astearns: An exclusion can intrude in the middle of a line box, astearns: when that happens two line boxes are created. astearns: Each is individually considered for bidi. Florian: Need to elaborate on the last part. Florian: Is it just like line breaking? astearns: Everything that would happen with regular line breaking would happen here also. dbaron: I agree this makes sense. dbaron: You need to specify which half of line goes where. dbaron: Depends on block's directionality. <shane> it's the reordering part that would be impacted by the decision of whether there is one line or two lines. Bert: If the exclusion is very small, might look better to do the reordering as if it were a single line. astearns: This is an error case, it's better to make it so lines are not split Bert: [describes edge case] Florian: it's not a problem for LTR-only or RtL-only <zcorpan> Proposed resolution: lines split by exclusions is equivalent to a regular linebreak for the purposes of bidi algorithm <zcorpan> Proposed resolution: lines split by exclusions is equivalent to a regular linebreak for the purposes of bidi algorithm, where which half of the line goes where depends on the block's directionality. RESOLVED: When a line is split by an exclusion, each side is its own line box for the purposes of bidi algorithm (i.e. they are effectively separated by a soft line wrap). Which line box is first depends on the block's directionality.
Received on Wednesday, 23 March 2016 21:32:48 UTC