- 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