- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 1 Sep 2017 08:50:01 -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 Text 3
----------
- The group agreed that what is in the spec for letter-spacing is
right, but that there hasn't been any move to implement,
partially based on a concern over breakage. There were three
options to get over this barrier:
1) Someone implements & ships
2) Someone does a web crawl to get actual statistics of usage
3) Everyone ships at once
- Myles is going to investigate implementing this part of the
spec to see if it works without breakage and fantasai will
write test cases.
- RESOLVED: No change (on applying line-spacing on a bidi-mixed
string), Blink/Gecko require bugfixes.
https://github.com/w3c/csswg-drafts/issues/1517
- RESOLVED: bidi reordering that would split an inline given
infinite space will always create separate fragments
even if the two fragments end up adjacent due to line
breaking
Note: Behavior for letter-spacing (and other things
affected, like box-decoration-break), falls out of this
definition: in this case, if the two letters end up
adjacent but are part of different fragments, the spacing
between them will be given by the parent (according to
the letter-spacing rules that control letter-spacing at
element boundaries). This avoids the measuring problem.
- RESOLVED: Rename line-break:break-all to line-break:anywhere.
- RESOLVED: After edits from this meeting, publish new WD of
Text 3.
text-spacing fullwidth punctuation collapsing
---------------------------------------------
- RESOLVED: Accept change matching JLReq's punctuation spacing,
put a note into the spec about maybe needing more
complex stuff, follow up with JLReq about the topic.
(Issue #1668)
Orthogonal Flow Constraint: viewport vs scroller
------------------------------------------------
- RESOLVED: Add "size of nearest fixed scrollport" to the list of
things you clamp orthogonal flow inline sizes to,
editing the CR. (Issue #1391)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/paris-2017#topics
Scribe: TabAtkins
CSS Text
========
letter-spacing
--------------
github: https://github.com/w3c/csswg-drafts/issues/1518
koji: Text 3 letter-spacing specifies that the letter-spacing
after the last character of an element should be eliminated.
koji: Concern that, while this is better, it may not be web
compatible.
koji: Our team prefers it be opt-in, so existing pages still work
but authors can choose the better model.
koji: It looks like Sebastian and François agrees.
fantasai: I know it's different, I wanna know if it actually
causes a problem.
fantasai: Adding extra switches is extra cognitive load on the
author; it would be better to just do the right thing.
koji: We have a bug requesting this feature for years.
koji: He wants to stop using negative margin to cancel the space.
koji: If we change things, his pages' compensation will instead
ram the characters together.
fantasai: Right, question is how many people will have that
problem, vs how many will be *fixed* by the change.
fantasai: If you have a large amount of letter-spacing to cancel,
so large negative margin, and there's text after, that's
a problem.
fantasai: But if it's a small letter-spacing, it'll have less than
ideal spacing but still *okay*--and lots of other pages
will have improved letter spacing.
koji: I think it's a little self-contradicting - people that want
this feature care about it, and people who care can apply
negative margin today.
myles: I don't think that's necessarily true
TabAtkins: I've never realized I needed to deal with this case
myles: There's a difference between caring about letter-spacing,
caring and noticing there's a problem, and caring,
noticing, and trying to fix it with this hack.
myles: What's stated in the spec is generally the correct result.
I'd like to implement it, but I share fantasai's hesitation
that we don't know how much will break.
fantasai: I'm not hesitant, I think we should try it.
fremy: letter-spacing is used everywhere on the web, so even if a
tiny fraction care enough to use the hack, it'll still be a
lot of web pages.
fremy: And browsers are mostly interoperable today. I don't think
it's a huge problem to keep current spec, add new
glyph-spacing property that works properly, and tell
authors to use latter.
myles: glyph-spacing is bad name.
fremy: Sure, anything works.
myles: I think making two solutions, one broken and one working,
isn't great. We should investigate fixing the one.
fantasai: Someone has to ship it then.
myles: Or crawl for it.
myles: Look for letter-spacing and negative-margin on the same
element.
Florian: Hard to tell automatically if it's bad.
fantasai: Have to investigate the *inherited* letter-spacing
value, and if negative margin on the element.
fantasai: That's the pages that are trying to work around it.
fantasai: But there's also millions of pages that aren't trying to
fix it, and will look better when we change it.
fantasai: So it's a balance of how much bad it is.
fantasai: Slightly worse appearance, or readability is affected.
fantasai: So you have to actually look at the page.
<fantasai> If it's mostly just slightly worse appearance, we're
winning: there are many many more pages that aren't
trying to compensate.
bdc: Huge letterspacing is bad design by default, while negative
letterspacing is often used for proper kerning.
bdc: So there, we'd have the opposite issue - if we remove the
space after last letter, we'd have bigger space between words
than we currently have.
fantasai: If you apply letter-spacing to whole paragraph, no
impact, since you won't run into this edge case.
dbaron: This isn't the first time it's brought up - maybe web
compat, don't know, a little afraid of it.
dbaron: If it is web-compatible we should stick to the current
design.
dbaron: If we wanna conclude it's not, we need more evidence than
brought so far that it's not.
dbaron: Until we have evidence that it's not, we should stop
trying to discuss it every six months.
<astearns> +1 to dbaron
<myles> I think dbaron made the point I was trying to make, but
much more elegantly than I did
fremy: I've seen a lot of websites using letter-spacing for not
letter-spacing itself; icon fonts and aligning,
letter-spacing of 1px because "it looks better on my
PC", ...
fremy: I'm concerned it'll be a lot of webpages, but I'm not sure
how to figure it out.
TabAtkins: Do a good collection of affected pages via a crawl,
then we can just sample them to whatever accuracy you
want. Basic stats.
<tantek> or at least provide URLs to illustrative examples (didn't
see any in the issue)
<tantek> (illustrative real world examples, not artificial data
URls etc.)
koji: I'm not clear on the next actions.
koji: I think someone has to do a collection and figure out
whether it's problematic or not?
myles: Someone somewhere has to prove that an impl that follows
the spec is not web-compatible.
TabAtkins: WG likes the current spec, and puts burden of proof on
implementations to prove that it's not Web-compatible
TabAtkins: Need to evaluate pages where they have negative right
margin that matches to the letter-spacing
TabAtkins: And then see if they are actually broken.
koji: So who will do this?
myles: Whoever wants to change the spec.
koji: Spec has been there for five years so far...
fantasai: Yeah, nobody has stepped forward to implement this.
fantasai: We want a spec and impls that match.
fantasai: So first option is somebody impls and ships and sees
what trouble they have.
fantasai: Second is somebody does a crawl and checks the stats.
fantasai: Broken vs slightly suboptimal; we don't care about
latter, because we'll fix a bunch more pages.
fantasai: Third is we do what we did with control characters,
where we all ship at same time.
Florian: Option 1 where things just ship, there are release
channels for early info...
bdc: I don't see how the crawl is possible really - the margin
might be a little different than the spacing, they might have
negative spacing and positive margin...
fantasai: positive margin is fine; it doesn't cause overlapping
that hurts readability, just puts in a larger gap.
bdc: So I'm in favor of just keeping the spec as it is.
fantasai: So in favor of moving forward, do impls have a pref on
which strategy to use?
koji: To me this is a nice feature, but not worth spending a week
doing a crawl.
koji: So I'd much rather have another property that does opt-in
and see the usage.
fantasai: That won't give us useful information.
fantasai: Majority of people aren't paying attention to this, or
aren't caring enough to do anything about it.
myles: I think, going along with fantasai, you can track the # of
times you encounter a website that uses it, but that's only
useful as a fraction, and you don't know the denominator.
myles: I can say 1k websites use the property, but we don't know
how many sites considered it and didn't use it because it
was bad for them.
fantasai: [repeats three options]
fantasai: And I think the WG is generally agreeing that changing
the spec isn't a valid fourth option.
Bert: Gradual change; reduce it by half this year, then quarter
next year, eventually it's nothing. :)
Rossen: So I don't think we did very good with the third option.
Rossen: Anyone want to do option #1?
[crickets]
Rossen: Anyone wants to crawl?
[crickets]
Rossen: So we're at same position as before.
fantasai: Question on #1 - we had zero interest in impl and
shipping it.
fantasai: But if someone was to give you a patch, you just had to
ship it, then what?
myles: I'm happy to investigate it, I want to make this work. I'll
impl and see if it doesn't work.
Rossen: Sounds good.
<dbaron> I think Gecko would be happy to try taking a patch.
<dbaron> Probably don't have the resources to do it in the near
future.
ACTION Myles to investigate changing letter-spacing impl to match
spec regarding spacing at start/end of element.
<trackbot> Created ACTION-857
ACTION: fantasai to write test cases
<trackbot> Created ACTION-858
<br dur=15min>
letter-spacing and word-spacing applied to which side
-----------------------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1517
koji: Problem from user perspective is that when letter-spacing is
applied to a bidi-mixed string, Blink and Gecko has
sometimes do l-s, sometimes double l-s, it's hard to predict.
koji: WK and Edge add even letter-spacing.
koji: It's not specced in CSS2, CSS3 defines quite different
algorithm that solves this problem.
koji: But it requires some complex impl.
fantasai: CSS3 just says letter-spacing is applied after bidi
reordering.
myles: If we end up shipping what we resolved in the last topic, I
think that'll mean that the Blink behavior of switching
which direction you add l-s to, you won't need anymore
myles: because then letter-spacing isn't on "left" or "right",
it's on "inside".
fantasai: 2.1 defines it as "between characters" - double or
nothing is just wrong.
<fantasai> https://www.w3.org/TR/CSS21/text.html#spacing-props
<fantasai> CSS2.1 defines letter-spacing as "between" characters
fantasai: CSS3 is more precise "between adjacent typographic
characters, after bidi reordering". No ambiguity.
<fantasai> https://drafts.csswg.org/css-text-3/#letter-spacing-property
myles: So what's the proposal, making it legal to have double/
nothing?
koji: Proposal is to match WK/Edge.
myles: Oh, okay, great.
myles: So that's what the spec already says, right?
koji: If spec says between chars, this might be an impl issue.
koji: Most impls apply it to the left or right of characters.
koji: Edge and WK apply it to the line-right direction, so always
"to the right" regardless of direction.
fantasai: And if we apply the previous topic's resolution, the
user can't tell whether it's line-left/right.
koji: Blink/Gecko apply it to end edge of resolved bidi direction.
Florian: Can't you detect it with backgrounds?
fantasai: No, l-s doesn't occur at a boundary; the l-s at a
boundary is determined by the element containing both of
them.
dbaron: I think the current spec is solid, just a decent bit of
work to implement.
astearns: So reading of issue is just that Blink/Gecko need to
change behavior to match spec?
koji: Yes.
RESOLVED: No change, Blink/Gecko require bugfixes.
Applying letter-spacing after line breaking
-------------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1509
koji: As fantasai just mentioned, difference between CSS2 and CSS3
is that 3 says apply l-s after bidi-reorder.
<fantasai> CSS2.1 implied after bidi-reorder. L3 specifies
explicitly to avoid confusion.
koji: But bidi-reorder applies after line-breaking,
koji: Which can change the number of "between" spaces there is to
add letter-spacing.
koji: So after we add letter-spacing, the line width can change,
shorter or longer.
koji: So I think this is a worse issue than what it's trying to
solve.
fantasai: You have to include the letter-spacing when figuring out
spacing and line-breaking.
fantasai: This is same as kerning.
koji: We don't redo kerning after bidi.
koji: Because changing line widths after break is really bad.
fantasai: Yeah, def don't want to change line-width afterwards,
that's bad.
fantasai: So that means you have to consider letter-spacing before
breaking the line.
fantasai: But since bidi-reordering happens after breaking the
line, you won't know where the letter-spacing goes until
after doing the reordering.
myles: Do you have an example of this breaking?
koji: [looks it up]
koji: Last bit of example 16 in Text.
koji: There's a 2em spacing between the characters in the span,
but reordering separates the letters.
myles: I understand now.
fantasai: If you have that example, bidi-reordering puts two
letters next to each other that weren't next to each
other logically, do you perform shaping and kerning
between them?
myles: Ours won't cross bidi boundaries.
koji: We're trying to do better at shaping across element
boundaries, but only in logical sequences, before bidi
reordering.
koji: I believe we're trying to match Gecko's behavior.
fantasai: Yeah, difficult; we're splitting up letters in an
element, so where does the letter-spacing go?
fantasai: Per spec, you don't put the letter spacing between
letters of the element and letters outside the element.
fantasai: So I see you point that it's hard to measure correctly.
koji: If we follow Edge/WK impl and resolve the previous l-s
topic, there should be 2em space on the right of C.
TabAtkins: line-right edge - in logical order, it separates the
letter from the next logical letter.
fantasai: Example: you have a para with 1em letter spacing. Inside
you have a span with 0 l-s. Between the last letter of
the span and first letter outside the span, there's 1em
letter spacing, where does that attach?
Example: <p>f_o_o_<span>bar</span>_f_o_o</p>
fantasai: Another span with borders and padding. You do
linebreaking calcs.
fantasai: Then you cut the line and do bidi reordering, but it has
b-d-b: clone. Now you have two pieces with padding
around them, where before you had only one. Now what?
koji: I was reading b-d-b for the first time this morning, and
thought of that exact problem.
dbaron: Okay, at bidi *resolution* time, the element would split
into two separate fragments, and thus both get borders.
koji: But you don't know how linebreaking will happen yet.
TabAtkins: If there's only enough room for 4 letters, so the "c"
and the aleph are next to each other, is that still two
independent spans?
dbaron: We don't unclone them - they stay separate fragments.
<dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Aspan%20%7B%20border%3A%20medium%20solid%20blue%3B%20background%3A%20aqua%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cp%3Eab%3Cspan%3Ec%D7%90%3C%2Fspan%3E%D7%91%D7%92%3C%2Fp%3E%0A%3Cp%3Eab%3Cspan%20style%3D%22box-decoration-break%3Aclone%22%3Ec%D7%90%3C%2Fspan%3E%D7%91%D7%92%3C%2Fp%3E%0A%3Cp%3Eab%3Cspan%20style%3D%22box-decoration-break%3Aclone%22%3Ec%D7%90%3C%2Fspan%3E%3Cbr%3E%D7%91%D7%92%3C%2Fp%3E
<dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5292
dbaron: That might not be an intentional decision; they might have
thought about it as normal linebreaking and this behavior
just falls out.
fantasai: I think it's okay to allow impls to do that.
TabAtkins: So the c and aleph would still be considered separate
fragments, even though they are adjacent
TabAtkins: and the letter-spacing between them would be controlled
by the parent.
fantasai: I like this solution.
TabAtkins: Wouldn't be too complicated, and would give sensible
results in most cases and sensible-enough results in
the rest.
TabAtkins: During bidi resolution, you split them into separate
fragments, and behavior falls out from that.
koji: So we'll lose the letter spacing between bidi runs.
TabAtkins: If the bidi runs are in the same element, yes - they'll
use the parent's letter-spacing.
<fantasai> Proposed that bidi resolution would result in splitting
an inline in infinite space will always create two
fragments, even if they end up adjacent due to line
breaking.
RESOLVED: bidi reordering that would split an inline given infinite
space will always create separate fragments even if the
two fragments end up adjacent due to line breaking
line-break: break-all
---------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1561
Florian: line-break:break-all isn't a great name. Should we find a
better name?
Florian: I think all names are bad, but I can't come up with a
good one.
Florian: This value allows line-breaks everywhere.
Florian: word-break:break-all allows for breaks between letters,
but not between punctuations, spaces, etc.
Florian: line-break is terminal wrapping, word-break is just
hyphens-wherever-you-want
Florian: Trying to do better ignoring web constraints is hard,
trying to do better *with* web compat is near impossible.
Florian: line-break:break-all is the newest one, with best chance
of renaming.
Florian: Unfortunately it's got the best name, I think.
koji: I don't mean it's badly named, just that same keyword on
similar property doing differently is confusing.
koji: Particularly if we have a shorthand for both of these.
fantasai: shorthands can do custom syntax; we'll definitely
redesign the whole thing if we do a shorthand
fantasai: Shorthand would be *great*, we can make it all make sense
koji: I understand it's possible, but if we're naming now, why
choose "break-all"?
fantasai: We didn't have a better one.
koji: Line-break:terminal?
Florian: how about line-break: anywhere?
Rossen: anywhere?
Rossen: any?
Rossen: all?
TabAtkins: That would force a break between every character
[a few people like anywhere]
Rossen: anyone care?
[several other ppl care]
TabAtkins: I think re-using the keyword is bad
Rossen: So from the people paying attention, any objections to
renaming break-all to anywhere?
dbaron: How widely implemented?
fantasai: Nowhere, it's new, we added it this year.
RESOLVED: Rename line-break:break-all to line-break:anywhere.
Florian: I have a PR for this change; other than me changing this
keyword, can the editors approve it or tell me what's
wrong?
fantasai: Yeah, at lunch.
RESOLVED: After edits from this meeting, publish new WD of Text 3.
text-spacing fullwidth punctuation collapsing
---------------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1668
Florian: In CJK, full-width punctuation takes a full-width box,
but they visually fill half to fit
Florian: Japanese expects that when they're next to each other (
like two close-parens), there will not be a big space,
they'll be collapsed visually.
Florian: The font contains space, but it needs to be canceled out
in some cases.
Florian: We have a rule in Text 4 that says when to do this.
Florian: One rule is overcomplicated. We did it wrong because
JLReq wasn't specific enough.
Florian: Case is where you have a closing punct followed by an
opening one: `)(`.
Florian: If you did nothing it's 2em long, we want 1.5em long.
Florian: Closing, half-space, opening.
fantasai: Collapse away the adjacent half space.
Florian: We specced that each is .75em long.
Florian: Proper is to keep all space on closing one, remove all
space from opening.
Florian: Difference is barely observable, we should match.
fantasai: Did the people working on those things consider the case
of different-sized fonts?
fantasai: Second paren is half the size of the first one, then
what should happen?
Florian: That's where it becomes observable.
fantasai: I think probably 75% on each side isn't the right
answer, so we should change it, but also not convinced
we should always use the first.
Florian: Unsure. Murakami says to do it the other way, and
InDesign does it the other way, so we should match.
fantasai: One thing we often do is look at print examples, and
find where they're not handling cases.
fantasai: I think we should choose one or the other; we could use
innermost or outermost...
Florian: They're same level.
fantasai: Always use bigger one?
myles: That'll cause space to change when font-size animates?
TabAtkins: It'll do that no matter what.
Florian: I think we should match publishers, with a note about if
someone has cases not considered, let us know.
fantasai: Korean mixes font sizes a lot; rather than ruby they
just reduce font-size for such annotations
Florian: But they use Latin punctuation, not full-width, so this
doesn't apply.
myles: I think it makes the most sense to do what everyone else
does as a first pass.
fantasai: Happy with that if we follow up with JLReq to make sure
they think about this case.
Rossen: Are you current JLReq liaison?
Florian: Not yet, I have something later about that.
koji: I think previous spec is ambiguous, just says "put a half
space between them".
Rossen: So can we resolve to accept change, put a note in, and
follow up with JLReq?
RESOLVED: Accept change matching JLReq's punctuation spacing, put
a note into the spec about maybe needing more complex
stuff, follow up with JLReq about the topic.
Renaming the dynamic and static profiles of selectors
=====================================================
<Rossen> https://lists.w3.org/Archives/Public/www-style/2017Jul/0039.html
<fantasai> https://www.w3.org/TR/selectors4/#profiles
Rossen: Mail sent last Saturday.
TabAtkins: So I've seen enough feedback by now that I agree that
"static/dynamic" is confusing. Dynamic makes people
think of JS. Let's talk about it over lunch and come
back?
Orthogonal Flow Constraint: viewport vs scroller
================================================
github topic: https://github.com/w3c/csswg-drafts/issues/1391
fantasai: We resolved to use the nearest scrollport height for
orthogonal flow fallback height.
fantasai: But that can be auto. ICB is always fixed; we want this
to be fixed as well.
<dbaron> Should it be the nearest scrollport that's non-auto
height?
<astearns> nearest scrollable definite-height ancestor?
<astearns> dang, dbaron beat me to it
Rossen: When I was working on this, the logic I added was to keep
looking for the nearest ancestor that imposes a fixed
height or scroller, and if scroller is height:auto I think
I keep going up.
Rossen: You can go figure out the viewport size, but that doesn't
buy you much.
fantasai: I think you want it to be a size you can calc without
doing layout.
Rossen: Which is doable if you find a fixed ancestor.
fantasai: If you look for fixed size and subtract intervening mbp,
you run into problems we saw before with stretch, where
you get so much accumulated mbp you're zero size.
fantasai: Also, our goal if you're doing autosize is to not make
it larger than what you can see in one screenful; goal
is to fit a line of text they can comfortably read.
Nearest fixed container might be larger than the
viewport.
Rossen: But then you'd have that problem with other things.
TabAtkins: The other things are intended to scroll vertically.
fantasai: It's very important that a line length is less than the
size of the viewport, so you don't scroll back and forth.
fantasai: So nearest fixed container might violate that.
fantasai: This is why we used viewport instead of some random
number.
TabAtkins: If it's as big or smaller than the viewport, then even
if it's not perfectly nice, the user can scroll it into
place and be able to read comfortably
fremy: You're preventing people from using transforms. They might
want large initial size, then scale it down. You'd prevent
that.
TabAtkins: For transforms all bets are off.
TabAtkins: We could clamp to smaller of the scrollport and the
viewport.
Rossen: Using smaller of fixed-height ancestor or viewport sounds
okay.
fantasai: If your parent is fixed size, we already clamp by that.
fantasai: But when we don't have a fixed size, we don't want to
look up thru multiple layers of auto and find a size
bigger than auto.
Proposal: orthogonal flow fallback height is min(100vh, nearest
fixed-size scrollport ancestor's height), no caring
about mbp or anything.
* dbaron notes that this proposed resolution needs to be
logicalized
+ logical swap for other ordering.
+ available size of immediate container, which normally controls
size
<fantasai> min(100vh, nearest fixed-size scrollport, available
size)
fantasai: Looking at spec, you choose smaller of "containing block
size" and "ICB size", and the issue/discussion was about
replacing ICB size.
<fantasai> current CR is min(100vh, available size), previous
resolution was min(available size, nearest scrollport)
TabAtkins: So just adding one more bullet to that list, for
nearest fixed scrollport.
RESOLVED: Add "size of nearest fixed scrollport" to the list of
things you clamp orthogonal flow inline sizes to,
editing the CR.
<br type=lunch dur=1hr>
Received on Friday, 1 September 2017 12:50:56 UTC