- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 16 May 2019 18:56:22 -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.
=========================================
CSS Overflow
------------
- heycam gave an update about the work to specify
-webkit-line-clamp. There are a few differences being introduced
intentionally such as skipping newer formatting contexts (such
as flexbox) and having any independent formatting context child
get skipped over.
- iank will try fixing Blink to use the block-end edge of the line
box (per spec, consistent with normal sizing rules) rather than
the block-end edge of the lowest item (current -webkit-
behavior).
CSS Multicol
------------
- RESOLVED: Clarify the spec using the notion that this is an out of
flow that leaves a forced break behind (Issue #1072: How
do elements between column-span and its multicol
ancestor appear around the span)
- RESOLVED: Update the spec to return to the behavior as implemented
in Blink/WebKit/Edge that `column-fill: auto` balances
an unconstrained container, and does not balance a
constrained container (Issue #3224: Improve column-fill
and make it backward-compatible)
- RESOLVED: Include min and max as constraints [in the above
resolution] (Issue #3224: Improve column-fill and make
it backward-compatible)
CSS Fonts
---------
- RESOLVED: Use ascii-case folding (Issue #3675: Font-family name
matching requires full Unicode case comparison)
CSS Lists
---------
- There were three proposals to solve Issue #3686 (Initial value of
counter-increment needs to be something different from none)
which will be discussed in the issue:
(A) fantasai's proposal: if an element has display: list-item,
then the list-item counter is incremented unless the
counter-increment property contains a reference to the
list-item counter. (Authors can override this effect with
counter-increment: list-item 0.)
(B) dbaron's proposal: if an element has display: list-item,
then the list-item counter is incremented. (Authors can
override this effect with counter-increment: list-item -1,
unless the list is reversed, in which case it would be by 1.)
(C) Fremy's proposal: if an element has display: list-item, then
the list-item counter is incremented unless the
counter-reset, counter-set, or counter-increment property
contains a reference to the list-item counter.
CSS Grid
--------
- RESOLVED: When calculating content based base sizes of spanning
items, if extra space needs to be distributed past the
growth limit, and there is a range available in another
column, put it in there (Issue #3648: Distribute extra
space into non-intrinsic tracks instead of going beyond
growth limits)
CSS Text & Sizing
-----------------
- RESOLVED: Preserved spaces from pre-wrap hang when they occur
before a soft wrap, but would not hang when at the end
of block or forced break (Issue #3440: When to/not to
include preserved trailing spaces)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sf-2019
Scribe: iank
CSS Overflow
============
Convert -webkit-line-clamp alias requirement into a spec issue
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2847
heycam: Talked about -webkit-line-clamp, wanted to give an update,
last couple weeks looking at implementing, and looking at
what the actual behavior inside blink/webkit
heycam: At high level, in the spec we talk about it as a
fragmentation, once you reach Nth line, subsequent lines
fragment, and lines disappear.
heycam: In blink/WK the effect is only influencing its size. Like a
max-block-size constraint, element is reflowed, where is
position of last line? This affects intrinsic block-size
heycam: As in blink/WK you'll end up with an element w/ this size,
however the remaining lines will appear as overflow.
heycam: These differences aren't insignificant, I've written patch
for what blink/WK have done. Wanted to do this in a
reasonable time.
TabAtkins: The existing -webkit-line-clamp impls are bad and
horrible.
heycam: Apart from the difference with fragmenting or not, elements
on subsequent lines will actually show, however this
probably isn't a webcompat constraint.
heycam: -webkit-line-clamp only works on -webkit-box, orientation:
vertical. Some risk that if we don't respect that it may
appear on elements that wasn't expected to have that treated.
<fantasai> The differences are largely intentional
https://medium.com/mofed/css-line-clamp-the-good-the-bad-and-the-straight-up-broken-865413f16e5
<fantasai> Main concern is really interaction with -webkit-box
TabAtkins: iank did some looking.
iank: I did some analysis by adding a bunch of usecounters in our
-webkit-box implementation to answer questions like how many
w/ single block-flow child, vs. multiple.
iank: This allowed us to kill percentage -webkit-line-clamp
heycam: yaya
<dholbert> https://www.chromestatus.com/features/5393405823680512
seems to be the query for percentage values of
webkit-line-clamp
<astearns> https://www.chromestatus.com/metrics/feature/timeline/popularity/2139
heycam: One other difference between spec and impl, any independent
formatting context child gets skipped over, that means a
BFC, overflow: scroll, display: flex etc, I think that makes
sense, is nice simple model, however it is a difference.
heycam: Where this difference has more of an effect, as it only
works on a "box-item" that establishes a independent
formatting context.
heycam: If respected that rule, we'd never be able to apply that
line-clamp. Needs to be an exception around this.
fantasai: A couple of options: an exception for -webkit-line-clamp
stuff, e.g. inherit the line clamp behavior into the
flex-item, or automatically apply.
heycam: I think that's a sensible thing to do.
florian: Most differences are intentional
florian: We probably need to do at the syntax level, where you
specifically that you need -webkit-box, etc, to apply the
prefixed version.
florian: We should do these tweaks, need to confess to ulterior
motive, I think feature is good on its own, the way that we
spec'd it is good. But it's also the first step helps us
solves a bigger problem.
florian: This solution is a subset which we need to get to overflow:
fragments.
florian: I think this is a good things.
florian: Wouldn't want to clean the hacks so much that we lose the
nice version.
heycam: What is in the spec at the moment is good, I'll probably
only implement the -webkit-line-clamp for compat reasons,
but want to try and get to the standards based version.
heycam: The aim for the fragmentation based solution is good.
heycam: I don't think making the prefixed -webkit-line-clamp
property an alias of the standards-based thing is possible.
florian: I think there is an issue in the spec, about this.
heycam: Can I ask people if skipping over new formatting contexts is
a good thing?
fantasai: I think that its not clear for many new formatting contexts
(like flex) where it applies.
fantasai: e.g. horizontal flexbox or table, what do you clamp? each
item in the row, first item only...
heycam: I agree.
florian: I would to keep a vertical -webkit-box w/ single item is
simpler, if isn't sufficient for web compat, and need to
handle multiple items, then if we need to handle that, yup
can add to spec.
heycam: Can I also ask if people are against the size calculation
the current implementations have.
florian: Would rather not spec, until we need them.
iank: We might need them.
heycam: I've written a bunch of tests to determine what is happening.
scribe: emilio
heycam: One final difference, is the exact position, in standards
version it is the block-end edge of the line-box, in
implementations its actually block-end edge of the items
within that linebox.
fantasai: The line-box can be taller.
florian: It makes the line shorter, because the line can be taller
due to line-height
TabAtkins: Is that what auto-sizing does?
(somebody): no
TabAtkins: Then that's bad
heycam: I agree that line-box block-end edge makes more sense
iank: I actually got a request a couple days ago about our behavior
being bad, and it's a one-liner, so I may just try to change it
iank: To do the same as auto-height
TabAtkins: Cool
iank: WebKit's behavior is also bad, and it's probably the same
one-liner
heycam: Another difference is that the flex item is inflexible if
you have line-clamp on the flex container
heycam: I suspect this is not a problem in practice since authors
are not using this feature for flexbox sizing anyway
heycam: I think this is all we wanted to get out of this
heycam: I'll change the patch to use the line-box block-end edge as
iank is going to do in Blink and land the weirdo behavior
<iank> Use counters, see
https://www.chromestatus.com/metrics/feature/popularity
and WebkitBox* counters.
<TabAtkins> I propose "boxflex item" and "boxflex container" as
words to refer to the old stuff.
fantasai: For the flex special-case, the simpler thing is that if
you have an anonymous flex item, you inherit line-clamp
from the parent
heycam: Current patch makes it apply to both anon and non-anon flex
containers
heycam: May be more complicated
emilio: No, just inherit from ::-moz-anonymous-* thing
heycam: Ah, ok, maybe not
florian: If we specify that -webkit-line-clamp only applies to
display: -webkit-box, we need to define what that is
iank: Some of it is in the compat spec
florian: Should we pull that in?
florian: Can we rely on the compat spec to do that?
dholbert: Yeah, it's not exactly the WebKit implementation but has
been good enough
<xfq> https://compat.spec.whatwg.org/#css-keyword-mappings
florian: ok, there's no w3c spec that depends on the compat spec, so
may be an issue
fantasai: Isn't it a whatwg spec? we can refer to that
florian: We can pull from compat spec as well
(everyone): Let's not discuss that now
heycam: Is the idea to do that when we have the non-webkit version
as well?
heycam: Or does it makes sense to do it already?
florian: I think we should spec everything we're moderately sure we
won't be able to rip off
dholbert: We can move -webkit-line-clamp to the compat spec too
florian: The way I see it is that things that we need to define
precisely how they work should get on the proper spec
florian: You could see the compat spec as an incubation thing for
these things
TabAtkins: The ideal is that things in compat should effectively
migrate out into real spec
<florian> this is also why it is hard to have normative refs to the
compat spec. Not because it's in whatwg (that's fine), but
because it a fast and loose spec that's not terribly
precise or stable
CSS Multicol
============
multicol descendant ancestors of a column-span
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1072#issuecomment-465362932
rachelandrew: It's a reopened issue that was resolved on but dbaron
reopened requesting some clarification
rachelandrew: The example is figure 21 in the spec
rachelandrew: The initial thing was mentioned was essentially a
clarification. The situation is when margins paddings
and borders are split by the spanner, but an empty
fragment ends up before the spanner
<fantasai> I think this just needs to adopt the same wording as
CSS2.1 block-in-inline splits
dbaron: A bunch of the clarifications was just to say what happens
for elements that are both descendants of the multicol and
ancestors of the spanner when they're split by the spanner
dbaron: A more interesting question is what happens when there's an
explicit height and how's it distributed
fantasai: Simplest is to treat the split as creating a fragmentation
break, but computes padding borders as if the spanner
didn't exist
dbaron: I think everyone pretty much agreed with the outcomes even
if there's disagreement on how to describe them
florian: There are a couple related aspects
florian: <section><div><aside column-span: all> split element
florian: We thought it could be described like the spanner being
out-of-flow
florian: but forces a fragmentation break
florian: so that it doesn't influence min-content and such
florian: The div is not affected by the span itself
florian: I think it's easier to define the span this way
rachelandrew: I think it's one of the cleanest way to describe it
rachelandrew: and easier to understand
fantasai: I think out of flow stuff in CSS is taken out of the flow,
the rest of the stuff is supposed to ignore it. An
out-of-flow span in a paragraph doesn't cause a break on
the parent
emilio: Actually, it leaves behind a break opportunity
florian: It's not quite true that out-of-flow don't affect the float
-> floats
florian: We need to define the specifics, but other than that is out
of flow
emilio: At least in Gecko, Webkit and Blink, out-of-flows do create
break opportunities. I believe it's a bug. Edge does it
right.
florian: In this case it would be a forced break rather than a break
opportunity
Rossen: This is the model we use in Edge. We treat it as out-of-flow
and force a break
Rossen: This is the exact model we use for spanners in edge
AmeliaBR: It is probably worth referencing it as being similar to a
flow wrt. Background painting order and co?
rachelandrew: Yeah I think I should write some spec text
RESOLVED: Clarify the spec using the notion that this is an out of
flow that leaves a forced break behind
Improve column-fill and make it backward-compatible
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3224
rachelandrew: Turns out that a commented out sentence in the spec
which Blink / WebKit and Edge implement
rachelandrew: <reads from issue>
rachelandrew: Firefox does not balance, given that text was
commented out in 2012
rachelandrew: I put together a couple examples
rachelandrew: Proposal is to update the spec to the behavior WebKit
/ Blink / Edge
rachelandrew: Another issue is to include min and max constrains
rachelandrew: And whether we should introduce a "never-balance" mode
florian: I think we almost concluded last time
florian: We should generally follow the behavior of everybody but
Firefox, except with the nuance that if it's not min- and
max- we never go into the fill mode
florian: As for adding a new fill behavior, not opposed but probably
level 2
florian: If we didn't include the min- thing I'd be more reluctant
to follow Chrome / Edge / webKit
rachelandrew: Have looked at Prince and they match FF
florian: I think web compat is the dominant thing here
florian: 1 and 2 solve the problem sufficiently well that you can do
what you want in more cases
rachelandrew: Unless people have objections I think that'd be a good
resolution
emilio: Has FF had compat issues because of that?
florian: No, but others have shipped that behavior for a long time
florian: and if we put 2 together it's not a bad behavior
rachelandrew: Without being able to do the min-size thing it does
get annoying, we use server-side stuff to measure
content and not get the weird columns
florian: Right, without the 2 part I'd prefer FF, but not otherwise
RESOLVED: Update the spec to return to the behavior as implemented
in Blink/WebKit/Edge that `column-fill: auto` balances an
unconstrained container, and does not balance a
constrained container
RESOLVED: Include min and max as constraints
CSS Fonts
=========
Font-family name matching requires full Unicode case comparison
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3675
myles: Spec says that in order to match font-family names full
unicode case folding needs to be performed
myles: so you need to run the names to complicated ICU routines
myles: We just fold ascii chars in WebKit, for performance reasons
myles: We never perform unicode case folding in WebKit
fantasai: When you search on a page?
myles: That particular API is a different one, but we do use unicode
fantasai: It should use compatibility decomposition and caseless
matching
myles: ascii case folding is fast
myles: I haven't done any measurement but if we used the unicode
case comparison it'd likely be a perf regression because font
lookups are not
myles: Wanted to relax this restriction
heycam: Why not require the ascii-case folding?
myles: That's fine too
heycam: I don't think there's many situations when you have
non-ascii names?
myles: Fonts have many names in many languages, in addition to an
ascii name, generally
florian: Isn't common to have a case-mismatched cyrillic name? Is it
not a compat issue?
myles: It's not
myles: Proposed resolution is that font-family lookups should use
ascii-case-insensitive matching
dbaron: What do other implementations do?
myles: Probably matches chrome
eae: It does
fantasai: I'd like to check with jfkthame
emilio: I can check what Firefox does, hang on
emilio: We do whatever nsCaseInsensitiveStringComparator does
dbaron: That's ascii
RESOLVED: Use ascii-case folding
CSS Lists
=========
Scribe: heycam
counter-increment initial value
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3686
fantasai: So there's a plan to use css counters for lists
fantasai: Looks like Gecko is on the process of implementing it
<TabAtkins> Today: <ol><li>one<li style="display:block">two<li>
three</ol> results in "1. one\ntwo\n2. three"
fantasai: They're blocked on an issue about the initial value of
counter-increment
fantasai: Basically by default we need to increment list-item
emilio: The issue is not that we need it to implement this behavior,
but we need it to allow the author to say
counter-increment:none on a list
dbaron: And does that style go on the list item or the marker pseudo?
emilio: The list item
florian: This is not just for markup lists, because if it was we can
do it in the UA sheet, but it's also when you create list
items through the display property
emilio: The computed value of counter-increment needs to depend on
display
emilio: It's not a huge issue
emilio: We have this kind of relationship for fonts and other
properties
emilio: The issue is that the author specified value gets lost
TabAtkins: Sure
dbaron: So auto would mean list item 1 if your display is list-item,
and none for anything else?
emilio: Yes
emilio: and the computed value wouldn't include "auto"
emilio: Otherwise you get into trouble with gCS, checking it against
none or something
fremy: What if on a list item currently you do counter-set:
my-list-item 5
TabAtkins: counter-set or counter-increment?
emilio: If you set counter-increment to something else you will lose
the auto increment
emilio: Edge does something like this
AmeliaBR: You have a todo list, and you're keeping your own track of
how many items in the list are completed or not, don't
want to muck up the existing list counters
fantasai: We discussed something similar to this ~12 years ago
fantasai: From what I recall, the conclusion we ended up with was
that the magic counter would be implied no matter what the
value of the counter property was
fantasai: if you want to override that implied behavior, you could
call it out explicitly
fantasai: 'none' would not turn off increments for list-item
fantasai: Neither would 'foo 0'
fantasai: but 'list-item 0' would
<fremy> +1
emilio: ok
emilio: Then we don't need this, but we should change the spec to
say that the only way you can reset list-item is this way
TabAtkins: Happy with that, then the spec doesn't have to disagree
with implementations as much
Rossen: The issue about the initial value of counter-increment
Rossen: being something different from none
emilio: One annoying thing is that counter-increment is the only
weirdo property that depends on display
emilio: you can explain counter-set for <li value=foo> using
attribute mapping
emilio: If you define that to be magical and non-overridable, then
it becomes more complicated to implement
fantasai: You run into the same issue if people are using counters
already and are clobbered
emilio: For li items inside an ol with the value attribute
emilio: I'm fine restricting this solution to counter-increment
emilio: or maybe counter-reset too?
TabAtkins: We already need magic for these things because of reversed
AmeliaBR: It sounds like in addition to having the list-item is
always auto incremented unless explicitly told, we also
need a way to say increment if displayed versus always
increment
emilio: That is the magic that counter-increment needs for list-item
emilio: We don't need that magic for counter-set or counter-reset
for lists
dbaron: There's one other thing that makes me uncomfortable, but
leads to an alternative
dbaron: Right now if you say counter-increment: foo 1, foo 1; you
increment the counter by 2
fantasai: There's no comma
dbaron: Saying that if you say list-item at all anywhere then it
overrides the implicit "list-item 1" feels weird to me
dbaron: Another way to do it is that display:list-item implicitly
have a "list-item 1" in there. But you can add
"list-item -1" in there to undo that effect
[general groans]
emilio: So you say display: list-item has a magic list-item 1
increment
emilio: and you can specify another one to cancel it
dbaron: You say list-item -1
fantasai: One of authors' goals is to expose counters to do
interesting things with them
fantasai: I think this makes it very confusing
AmeliaBR: If you hide a list item then the next one would jump down
a number
fantasai: I would rather it be an override
dbaron: I don't understand the hiding thing
dbaron: It feels inconsistent that counter:foo 1 doesn't change it,
but if you put list-item into that list that the other one
disappears
fremy: If you do a set and don't do the increment, it's wrong?
fremy: If you have <li value=4> you don't increment
fremy: it sets to that value
dbaron: How you implement <li value> is another question
<AmeliaBR> if you have `counter-increment: list-item -1`, that
wouldn't have the magical dependence on display. So now
hidden elements would reduce your overall counter,
wouldn't they?
emilio: The way the spec defines it is mapping the attribute to
counter-set property
emilio: and then to counter-increment: none too
dbaron: If we change it this way, we have to change the mapping of
the value attribute to counter-increment: list-item 0
dbaron: to explicitly suppress the incrementing
dbaron: and then if the author sets some other counter, it would
break their value attribute
dbaron: If the UA sheet for <li value=5> counter-set: list-item 5;
counter-increment: list-item 0; then the author sets
counter-increment explicitly
dbaron: It would lose the 'list-item 0' counteraction
* TabAtkins did not realize that "counter-increment: foo 1 foo 1;"
was equivalent to "counter-increment: foo 2;"...
fremy: Does anybody use the value attribute?
AmeliaBR: Yes, commonly with pages of lists
AmeliaBR: Has anyone thought for the issue of having the list-item
counter depend on display, is that something we're ok with
exposing to user counters as well?
emilio: No
AmeliaBR: Definitely a no?
AmeliaBR: That only list-item has that?
TabAtkins: We do have the case that counters only increment on
things that generate boxes
TabAtkins: but that's different from what list-item wants to do,
which is depend on display:list-item explicitly
AmeliaBR: So regular counters turn off with display:none, but the
list-item counter turns off for anything other than
display:list-item
TabAtkins: Yes
emilio: So there are 2 proposals
emilio: One is that list-item is magically appended to
counter-increment for list items
fantasai: Unconditionally
fantasai: that's dbaron's proposal
fantasai: The alternative, the earlier discussed one, is that it's
only added if the list-item counter is not mentioned in
the explicit list
fantasai: so the author doesn't have to think about what the UA is
doing
fremy: I was thinking about dbaron's issue -- there is a way of
extending this
fremy: You could stop the magical behavior if list-item appears
explicitly in any of the counter properties
fremy: Then you can map value="" into counter-set without worrying
about counter-increment being clobbered by the author
fantasai: I don't think you want to do that
fantasai: Having property interactions like this makes it more
difficult to implement
fantasai: We want authors to be able to manipulate the list-item
counter in a straightforward manner
fantasai: Looking at other properties is more confusing
fantasai: The author wants to set the counter to something, or
change the increment, or both -- but if mentioning
list-item in one changes how the other behaves, that's
confusing
fremy: <li value="5"> maps to counter-set: list-item 5; and the
counter-increment won't use the implied list-item because it
appears in counter-set
fantasai: Why wouldn't you have this behavior for other counters?
fantasai: If it's useful we can do it for other counters
<dbaron> "Inheriting counters must be done before resetting
counters, which must be done before setting counters, which
must be done before incrementing counters, which must be
done before using counters (for example, in the content
property)."
emilio: Resets are applied before increments
dbaron: Reset, then sets, then increments
emilio: So the increment will always be applied unless you suppress
it
fremy: Either you set the list-item value, and not do the automatic
increment
emilio: If you do what dbaron says, you could map the li value to
counter-set, then counter-increment: list-item -1
fantasai: If we're cringing at this proposal in here, there will be
a lot more cringing out in the world
<fremy> so counter-increment has "listitem 1" implied except if you
"counter-set: listitem 5" or "counter-increment: listitem 0"
TabAtkins: I suggest figuring out the technical issues in the GH
issue itself
dbaron: I think I'm OK with Elika's proposal
dbaron: Mine has the disadvantage [...]
AmeliaBR: I am voting for fremy's proposal
Rossen: It sounds like the leading one for a resolution would be
fantasai's
dbaron: I will write the 3 alternatives in the issue
emilio: We could look at the code to understand the weirdness and
report back
CSS Grid
========
Extra space into non-intrinsic tracks instead exceeding growth limits
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3648
fantasai: Let's say there are two columns
fantasai: one is minmax(0, 100px), the other is minmax(auto, 100px)
fantasai: Normally we do a first pass to figure out the base size
fantasai: min size of each column
fantasai: first is fixed and gets 0
fantasai: The second is roughly the min-content contribution of any
items in that column
fantasai: Let's suppose that item is 150px
fantasai: The max specified here is 100px
fantasai: since the first column says I'm 0px, we put all 100 or
150px into the second column
fantasai: and blow out the maximum
fantasai: in order to fit the content
fantasai: But the author did give us some space, first column has a
range
fantasai: Instead of blowing out the max on the second column, we
could take those 50px and put them into the first column
fantasai: and it wouldn't violate any of the max constraints on the
columns
fantasai: We ran this idea by jensimmons and rachelandrew and they
both said yeah we'd expect that to happen
fantasai: so I'm suggesting adjusting the grid algorithm so that
when computing the min size of a spanning item, if you hit
the growth limit, and have another that is still below
its max, you increase that one
TabAtkins: Sounds reasonable
rachelandrew: I like this because it is more similar to the flex
behavior, which people will expect
rachelandrew: Why overflow the column when there is still space there
rachelandrew: This could happen when you have a single row grid, and
they're using grid for whatever reason, and they'll
expect that space to be used
iank: What happens if the item is 150px in width? are the columns
50px and 100px?
fantasai: Yes
jensimmons: Right now they're 0 and 150 but we're proposing they be
50 and 100
Rossen: Any objections?
RESOLVED: When calculating content based base sizes of spanning
items, if extra space needs to be distributed past the
growth limit, and there is a range available in another
column, put it in there
iank: You'll need to specify which columns take the slack
iank: 2 on the left and 2 on the right
fantasai: All of them
CSS Text & Sizing
=================
When to/not to include preserved trailing spaces
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3440
fantasai: Some discussion back and forth about how to handle
preserved whitespace at the end of a line
fantasai: Most recent resolution is that it hangs if it doesn't fit
in the line box
fantasai: koji came back to say that doesn't make sense if you have
a paragraph that is white-space:pre-wrap
fantasai: since then you will end up not justifying fully with the
last visible letter to the edge of the container
fantasai: because if that white space happened to fit, it would be
within the container, otherwise you wouldn't get a flush
edge
fantasai: The discussion is now: should we say it's force hang
instead?
fantasai: Or do something else?
florian: koji raised this only in the case of justification?
florian: On other alignments browsers were aligned, and you're not
trying to change that?
koji: For justification including trailing spaces it's clearly wrong
koji: For right and center, I'm neutral
koji: In those cases I can see both sides of the argument
<fantasai> I think this is why actually I made the comment in
https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-458783789
florian: I'm trying to understand the use cases better
florian: because I'm a little bit confused about whether it's in
general OK, or already broken, to try to use pre-wrap on
body text, paragraphs
florian: If you have source code that is pre, and you want to switch
to pre-wrap to avoid overflow, that's fine
florian: If you apply pre-wrap to body text, there are some odd
things that happens
florian: Links in the text are underlined, if your linked phrase
have spaces, you'll have a hanging underlined space at the
end
florian: so it's a bit strange, but I'm not sure
florian: Don't know if we should try to support that more, in which
case what you say about justification is right
florian: or decide we don't really care about this, and not optimize
for it
florian: Maybe people want to use double space after a period? that
also feels into the category of not needing to try to
support it
florian: So these are kind of at the edge
florian: of reasonable use of the properties
fantasai: format=flowed plain text email is essentially pre-wrap text
florian: but you don't re-justify it
florian: If you try to preserve the format of the email, you don't
go to justify it, since your alignments made with spaces
will be broken by the justification
fantasai: As far as trailing spaces underlined go, you can use
text-decoration-skip
fantasai: I think it's a bit weird for something to hang for some
operations but not others
fantasai: It might make more sense to say that if there is a soft
break after a space, then that space force hangs
fantasai: for alignment, justification, everything
fantasai: but if there's a hard break, then that space does not hang
fantasai: For the use case of pre-wrap on an entire paragraph,
you're not going to be end it with a period, a space, then
a line break
fantasai: but for a line of text that happens to end with a space,
then that would work
florian: If we do force hang in that situation, what does it do for
the max content size? include the size of not?
fantasai: Max size is always unwrapped, so you include the spaces
florian: What about space at the end of the paragraph?
fantasai: Then there's a force break right after it
florian: ok
fantasai: Let's say you have a word, a space, a word, another space,
end of the block
fantasai: then you wrap in the middle of that
fantasai: so you have word, space, soft-break, word, space, end of
block
fantasai: If you were to right align that text, the space that is at
the end of the block would not hang
fantasai: It's at the end of the block
fantasai: The space that is wrapped does hang
fantasai: When you left align you won't notice
fantasai: when you right align or justify you will see the first
line's space hang
fantasai: Generally you want spaces to disappear when you break the
line on them: we can distinguish between these cases from
other trailing spaces by whether there's a soft wrap there
or not
koji: I think that makes sense
koji: If other browsers are willing to match, I think we can try to
match
koji: Is Gecko happy with it? I think xidorn wanted to include
trailing spaces
koji: for right and center
heycam: We can resolve and ping xidorn to get his opinion
RESOLVED: Preserved spaces from pre-wrap hang when they occur before
a soft wrap, but would not hang when at the end of block
or forced break
florian: Currently we say that spaces hang when they go beyond the
edge of the block, browsers are allowed to discard them
florian: We key that off the fact they hang
florian: Are we still allowed to drop the last spaces before the
forced break, or also not allowed to do that
fantasai: Let's discuss that another day
-- adjourned --
Received on Thursday, 16 May 2019 22:57:46 UTC