- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 21 Mar 2018 20:14:33 -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
--------
- Issue #1997: white-space collapse at end of line: test case and
queries
- RESOLVED: Spec Gecko's behavior at the ends of lines in
display text
- Gecko's behavior is summarized as white space trimming at the
start and end of the line operates through any inline box
boundaries.
- Issue #2003: overflow-wrap: break-spaces can effect behavior even
when there are previous breaking opportunities in the line
- RESOLVED: Simplify the definition of break-spaces as in this
commit:
https://github.com/w3c/csswg-drafts/commit/1a6a12db7f8b431fe4646c634aa823105208f1d4
- Issue #1484: letter-spacing computed values don't reflect reality
- Originally the proposal was to have normal compute to normal
but behave as 0 as this was how browsers were believed to
currently behave.
- AmeliaBR created a codepen
(https://codepen.io/AmeliaBR/pen/73997f70e22754a85e0e6f83c5c1daf1?editors=1111
)
which showed getComputedStyle returning normal for 0 with
several browsers, so the spec text would need to accommodate
this behavior since it's already interop.
- RESOLVED: We have the spec say computed value of
letter-spacing is absolute length. There's a quirk
to getComputedStyle where 0 serializes to normal and
that doesn't extend to the computed style map.
- Issue #785: Hyphenation usages in CJK
- RESOLVED: No change on issue #785
- Florian will file bugs on browsers to fix/support the
break-all keyword for the word-break property which
minimizes the issue reported in this bug.
CSS Text Decor
--------------
- Issue #2376: Add use-font keyword for text-decoration-width &
text-decoration-offset
- RESOLVED: Add a use-font (name to be bikesheded) keyword for
these text decoration metrics.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Mar/0038.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Garrett Berg
Tantek Çelik
Benjamin De Cock
Elika Etemad
Dael Jackson
Myles Maxfield
Thierry Michel
Anton Prowse
Liam Quin
Florian Rivoal
Jen Simmons
Alan Stearns
Lea Verou
Regrets:
Dave Cramer
Alex Critchfield
Peter Linss
Melanie Richards
Greg Whitworth
Scribe: dael
astearns: Let's get started.
astearns: Is there anything extra for the agenda today?
astearns: I have one.
astearns: We have a F2F soon. Please add things to the agenda by
tagging them in github or adding them to the wiki.
astearns: As I find things in the issues list and add them to the
wiki I will remove the tag from the issue.
CSS Text
========
white-space collapse at end of line: test case and queries
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1997
florian: I can try and cover for fantasai.
florian: If she's not here.
fantasai: I'm here.
fantasai: There's inline box boundaries that prevent the whitespace
from collapsing at the end of the line for certain impl.
fantasai: You can see from the example in the issue.
fantasai: Question is will we collapse all consecutive spaces and we
have the end of the line and after the space the inline
tag closes. Does the space at the end collapse even though
there's an inline box boundary. I say yes for the reasons
in the comment.
astearns: Looks like we will have interop with Gecko, upcoming
Blink, upcoming Edge.
fantasai: I don't remember the Blink testcase, but we will have some
engines that do that.
fantasai: An important reason to do this is authors will expect
this. When closing tags aren't tight against the last it
just hangs out and it's unexpected. having a space hanging
out inside be different then outside doesn't make a whole
lot of sense.
astearns: Any concerns with trimming the trailing space?
florian: Agree
myles: I don't quite understand the test case. I thought spec was
all trimmed except the first. So the space shown isn't from
inside the span? Maybe I should take this offline.
fantasai: Space is after the first. If you have a series of
collapsible spaces the first is preserved.
myles: It's before the span with the border-left in the firstline.
fantasai: Test cases have checks for before the text and after.
Whitespace does 2 phases, one go down to one space and
then go through the line and any space adjacent to start
or end is trimmed.
myles: Let's take this offline. Resolution is fine.
Rossen: You're okay to resolve on current behavior and continue to
define?
myles: I'm a little confused about the test case, but in the issue
there was a proposed resolution to use the Firefox behavior.
Rossen: I would point out that even though you'll get similar
renderings with at least our current work in progress as
well as what I'm assuming the NG layout is aiming for in
Chrome. I can't speak to webkit, I don't have a device near.
As soon as you start interacting with this particular test
case in contenteditable or you select it, you get very
different behavior.
Rossen: I'm not sure how much this resolution captures this.
florian: I think the problem of having more divergence as to what
happened to spaces when you select them goes way beyond
this test case. We probably should tackle that separately.
Rossen: My point is we should either, ideally have a note for this
or test cases that involve selection. Something that allows
us to proceed forward more interop. I think we've discussed
extensively in the past and made some progress.
Rossen: I want to point out this issue doesn't address any of that.
florian: That's fair and this is something I'm interested in looking
into. I'll try and see what the spec says about when
selecting and editing. It's separate, but I want to look
into it.
astearns: Setting contenteditable and selection aside, it sounds
like we're converging on Gecko's behavior for trimming at
the end of lines for displayed test
astearns: Objections to spec Gecko's behavior at the ends of lines
in display test?
RESOLVED: Spec Gecko's behavior at the ends of lines in display text
CSS Text Decoration
===================
Add use-font keyword for text-decoration-width & text-decoration-offset
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2376#issuecomment-371376593
fantasai: Suggestion to have a keyword to use metrics in font.
Proposals were use-font and from-font. We're open to other
ideas. Resolution I'm looking for is a keyword for this
thing. I vaguely recall another property with a similar
keyword, but I couldn't find it.
astearns: I don't recall.
myles: I think having a new keyword is fine. Point I raised in the
issue is that impl may want UA dependent fixup if font has
ridiculous values.
fantasai: That's fine.
florian: Do you plan that for a known list?
myles: It's done automatically so I can't comment on a specific
algorithm, but it's impl detail on how we perform the fixup.
florian: Okay.
astearns: Spec would say use-font would use metrics from first
available font if they are reasonable?
myles: Or just say it would similar metrics to the font...that's
bad...I'm not sure exact text.
myles: You could have a second sentence saying UA MAY synthesize
values. I'll defer to fantasai. She can do a good job.
astearns: Question is if we add this keyword. Does anyone have
concerns about adding a use font keyword for these text
decoration metrics.
astearns: Objections?
astearns: I'm assuming use-font is what we should use.
fantasai: Use-font and from-font are the top two.
astearns: Use sounds better to me.
<liam> i prefer from-font
<liam> since the font's glyphs aren't used.
fantasai: We're not dead set on this if there's a better idea.
<florian> +1 to from-font, but no objection to the other one
RESOLVED: Add a use-font (name to be bikesheded) keyword for these
text decoration metrics.
CSS Text
========
overflow-wrap: break-spaces can effect behavior even when there are
previous breaking opportunities in the line
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2003#issuecomment-370652901
florian: myles noticed a complication in a corner case of the
handling of break-spaces. Initially intentionally
introduced, but it is a complication. Since
line-break-anywhere exists this brings nothing to the
platform. All variants remain possible.
myles: Background, we are interested in using icu breaking
iterators. There's a bunch of modifiers for breaking
including overflow-wrap which should only kick in if a
breaking opportunity wasn't in the line until the end.
myles: Corner case is where we couldn't look at all properties and
create icu breaking iterator because breaking opportunities
depending on earlier in the line. It would be great if this
corner case could be removed.
myles: I believe the commit fantasai made satisfies that constraint
so it's okay now.
astearns: Concerns with this simplification?
Rossen: Trying to wrap my head around what it means for impl that
impl the corner case.
florian: No one impl yet.
Rossen: I think not in a shipping form.
myles: As I understand if I impl what was in there before I need
special handling and an if statement. I think after there's
no if or special handling. I don't know how the Edge impl
works but I would imagine it would be simpler.
florian: There was also a slight error in the wording for the spec.
[reads] If we remove the normative requirement there's
independence where there was interference before the change.
florian: For the details of what and why we're need a whiteboard.
Rossen: If we can attach the JS to exemplify that would be great.
myles: I couldn't fiddle but I did mockups in pngs inside the thread.
myles: Proposed resolution is to accept fantasai's commit.
Rossen: I did review. I won't object. I'm just trying to work
through ramifications.
astearns: So Rossen are you okay to resolve now or do you want time?
Rossen: We can resolve now. I will play with the behavior and try to
come up with the test cases myles was trying to exemplify. I
don't think it'll be a problem.
astearns: Obj to simplify definition of break spaces?
Rossen: What is the technical version of that resolution?
astearns: We have the commit. Simplify the definition of
break-spaces as in this commit.
<florian> url to the commit:
https://github.com/w3c/csswg-drafts/commit/1a6a12db7f8b431fe4646c634aa823105208f1d4
Rossen: great
RESOLVED: Simplify the definition of break-spaces as in this commit:
https://github.com/w3c/csswg-drafts/commit/1a6a12db7f8b431fe4646c634aa823105208f1d4
* florian intends to write a test case for that
letter-spacing computed values don't reflect reality
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1484
fantasai: Property has a normal keyword that's the initial and takes
length
fantasai: normal is effectively 0 except in 2.1 we said normal you
could adjust inter-letter spacing for justification
purposes. In text L3 I decided that was unnecessary
restriction and we shouldn't distinguish normal and 0.
fantasai: Spec says they're 100% equivalent. Since impl do normal to
normal for computations we can say normal computes to
normal and means 0. I don't see a significant difference.
Reason to compute through it you don't have to set a value
to animate. normal to normal advantage is it's impl.
myles: Making sure I understand. If I animate from -5 to 5 I'll get
visual flash?
fantasai: No, if you animate from initial value to 1em it won't
animate correctly because it's a keyword.
myles: So that's why you unified 0 and normal?
fantasai: I did it because we might as well have computed value
reflect what's in the engine. So at the end when you get
computed you can't tell there's a normal. In terms of
computed value the only observable difference is
animations and transitions.
myles: okay
astearns: It's work for each engine to change from computing to
normal to compute to 0. Seems like we have at least 3
engines computing to normal. I'm not sure there's enough
value to justify the work.
<AmeliaBR> FYI, In Chrome, letter-spacing: 0 computes to "normal".
https://codepen.io/AmeliaBR/pen/73997f70e22754a85e0e6f83c5c1daf1?editors=1111
<fantasai> AmeliaBR: that's a *problem*
<AmeliaBR> (In Edge & Firefox, it computes to 0px)
fantasai: AmeliaBR points out a test case where Blink computes 0 to
normal and that shouldn't happen.
astearns: That's a bug.
dbaron: May be a sign that the animation thing works.
<Rossen> Edge computes to 'normal'
astearns: And if anyone depends on that working in Chrome it might
be worth the effort.
astearns: We'd have to see if any other engine has a bug.
fantasai: So make the spec match impl and if people come back with
use cases we can change back.
astearns: Change spec to say normal computes to normal.
astearns: Obj?
Rossen: We resolved on this 2 weeks ago. I'm fine resolving again.
fantasai: Might have been a different property.
myles: Are we trying to change semantics or computed value?
astearns: Just computed. We're changing the spec for the computed
value to match impl.
Rossen: And what AmeliaBR points out that chrome...edge computes to
normal as well.
florian: Why?
Rossen: The web needs to work.
fantasai: noooooo...that's bad.
astearns: 0 computing to normal seems like you'd lose information.
florian: They do the same thing so not really...
Rossen: I can fix the bug if there's a similar fix in other engines.
Rossen: I'm all for resolving here. I just want to point out what
the irc states about Edge is not correct.
myles: I tested in webkit you set 0 and computed returns normal.
Rossen: There's a codepen from AmeliaBR.
florian: So only FF does normal to normal and 0 to 0?
Rossen: Yes.
florian: Why????
astearns: Probably they matched another engine.
<AmeliaBR> In my testing, Edge v16 is returning 0px. So they must
have changed for v17, if that's what Rossen is seeing.
florian: If we've got 3 engines doing it there might be a reason. A
compat reason.
fantasai: Gecko hasn't changed to do this thing. That's good enough
reason to say the spec doesn't want that.
astearns: Edge made the change recently so Rossen you might be able
to find out why the change was made.
Rossen: I would guess interop issue. I could go through finding the
bug. We're not going to go back to be 0 and break interop to
comply to the spec if the web doesn't do that.
Rossen: You need to lobby with Chrome and Webkit and then we'll fix.
<fantasai> Computing zero to 'normal' makes *no sense*
astearns: The question of what normal computes to I can see the
value of computing to 0 for animations. I don't think it's
worth it. I don't see the value of 0 computing to normal.
That seems like matching for matching.
liam: Is normal required to be 0? You can't do smaller spacing?
florian: That would be a violation.
fantasai: You could change spec to allow that. If normal computes to
itself it can be different then 0. It could do what liam
says and take into account optical sizes and adjust
inter-letter spacing if font says that for example.
fantasai: I don't think we have fonts that do that or impl that do
that so normal and 0 are eq. but could be different.
florian: We've got what does normal compute to and lots of people
compute to normal. 0 computing to normal is a separate
thing.
dbaron: The 0 computing to normal might happen at level of
getComputedStyle.
myles: Exactly. In our impl when we represent letter spacing it's a
float. We don't store extra information to know if it was
normal. It's one float until we produce the getComputedStyle
and if it's 0 we write normal.
Rossen: I think same for us.
<AmeliaBR> So "normal" would be the "used value" for a computed
value of 0?
fantasai: That makes sense. If they want to store as a float that's
fine. Computed value of 0 should be 0 and have normal
compute away. Turning into a keyword in the middle makes
no sense.
florian: Should we say in addition to normal compute to 0 resolved
value may or must be normal?
florian: If everybody does it...
fantasai: Gecko isn't. If this is an impl issue where they're not
storing enough information to know if it's was normal or 0
they should output 0. It just requires no special case in
getComputedStyle.
florian: There may be a set of scripts expecting it.
fantasai: If that script exists we can reconsider. Gecko doesn't do
it.
dbaron: More likely is a script that looks at getComputedStyle to
know if it's the initial value. It looks for normal and says
'oh, that's the initial value'
florian: If Gecko hasn't heard it's not that bad.
dbaron: All browsers agree is if you set nothing getComputedStyle
returns normal.
astearns: This has taken a lot of time.
astearns: I suggest we resolve on computed value of normal, change
the spec to say normal is the computed value of normal.
florian: computed value of normal is 0 [missed] for animation it's 0.
<dbaron> I think the best option may be to leave the spec as it
is... if one of the non-Gecko browsers is willing to change.
astearns: Do we want impl detail of how this is stored?
fantasai: You can tell if you're doing that based on how it
animates. It's about what computed style is. We're down to
the spec if fine to say letter spacing normal computes to
0. Now we need to know if getComputedStyle value of zero
becomes the string normal and that's a web compat question.
<myles> dbaron: what different behavior does gecko have for normal
and 0?
<dbaron> myles, IIRC, none
<dbaron> myles, but letter-spacing and word-spacing represent their
values the same way
<myles> dbaron: so you just have the extra bit just for
getComputedStyle?
<dbaron> myles, I think so
Rossen: Take the two issues separately. First one I think is easier.
getComputedStyle value of letter spacing spec as normal
should be normal. I think that's the original thing we
wanted to resolve.
fantasai: The question was the computed value which isn't the same
thing.
fantasai: All impl currently if you spec letter-spacing:0 they store
computed value of 0. They may or may not return
getComputedValue of 0. It may convert to normal during
that call.
fantasai: Several impl store it as a number. Gecko makes a
distinction between specified as normal and specified as 0.
fantasai: All impl if you spec 0 they store 0. Gecko stores normal
if you spec normal. During getComputedStyle API call there
are several impl that convert 0 to report at normal. Gecko
returns the keyword or 0 depending on what spec.
florian: Ideally what we want is everyone to converge to computing
normal to 0 but there may be web compat issue on that.
Maybe have people that recently changed figure out why and
we can see if the web compat is manageable or not.
myles: If we're going to resolve we should resolve on what 3 or 4
browsers do.
florian: It's insane
myles: But 3 of 4 do it.
florian: But 4th doesn't so it's not required.
Rossen: Are you going to try and spec text that will set right
expectation for authors or write academic papers.
florian: If we have a dependency we write that. We have a browser
that doesn't do it.
Rossen: Let me give an example. If you recall the flexbox percentage
for top and bottom padding it was done only for web compat.
We want the web to work and applications to use the web.
fantasai: No one disagrees.
Rossen: If we spec something not in any browser but FF do you expect
anyone will change?
florian: You're making 2 arguments. The web compat I agree. The fact
that FF doesn't do it we're not locked on. I would prefer
doing the sane thing if we're not locked.
florian: It's not necessarily a web compat problem because not
everyone does the same thing. Given that we may not be
stuck I'd prefer to try and do the sane thing.
<fantasai> Specifying 'letter-spacing: 0', having it behave as zero (
observable from animations), and having getComputedStyle
returning 'normal' is very weird
astearns: I'd like to go back to dbaron on IRC where he thinks best
option is leave spec as is where computed value should be
absolute lengths. I believe that would require Gecko to
change to leave off the normal value, but he mentioned
non-Gecko browsers would need to change.
astearns: I think what florian said is we need to find out if this
is a web compat thing.
florian: Someone will have to change any way.
hober: Absent compat data engines won't change.
hober: Absent compelling data that one is preferable three engines
win. It doesn't matter if it makes sense.
hober: I don't see why we're still arguing.
<tantek> can't even find a bug in bugzilla on this for compat reasons
<tantek> does this affect transitions?
<tantek> tangentially related:
https://bugzilla.mozilla.org/show_bug.cgi?id=694834
astearns: I think we're arguing because it's a hard pill to spec
behavior that we think has no value.
florian: We have to add things to the spec to add the special case.
fantasai: I think it's not a benefit to authors that if they spec
letter spacing 0 and get back normal.
dbaron: I think the other thing that makes sense it spec the
computed value is a number. In getComputedStyle a computed
value of 0 serializes to normal and not extend that to
computed style map.
fantasai: If we spec this that's how we have to spec this. When you
spec 0 computed is 0. It's only the getComputedStyle call
that is normal. This is a resolved value quirk we have to
put in. If it's not required by web compat I'd rather not
do that. If this is just how people just cheated it in I'd
rather not.
dbaron: I think hober is right. It's not worth the energy we'd need
to deal with the compat changes to fix this.
astearns: You're willing the expend the energy to match?
dbaron: Yeah.
astearns: Proposal is we have spec say computed value of
letter-spacing is absolute length. There's a quirk to
getComputedStyle where 0 serializes to normal and that
doesn't extend to the computed style map
astearns: Objections?
RESOLVED: We have the spec say computed value of letter-spacing is
absolute length. There's a quirk to getComputedStyle where
0 serializes to normal and that doesn't extend to the
computed style map.
Hyphenation usages in CJK
-------------------------
github: https://github.com/w3c/csswg-drafts/issues/785
florian: In Japanese it uses mixed writing systems. Just because
there's Latin characters it doesn't mean it's English. It
won't get language tagged as English, but they do expect
hyphenation.
florian: My take is it should just be in the hyphenation dictionary
for Japanese. If people want a hyphen the hyphen property
does that if it's in the dictionary. For the rare word that
isn't in the dictionary it should be language tagged.
myles: Is this just Japanese?
florian: If you're going to use German words, not tag them, and use
them in English I'm going to assume it's common in English
or the author did it wrong. English does not contain all
words of all languages.
<tantek> Schadenfreude for non-English languages?
florian: It is somewhat common in Japanese to have words like that,
but if they're common they should be in the dictionary. I
don't want a property to hyphenate words not in the
language they're in.
florian: tantek's example is good.
florian: Trick with Japanese where you can't tell it by the script
in English and German, you can tell it by the script. But
if a Japanese person wrote schadenfreude you can't tell
it's not English.
florian: If it's common put it in the dictionary. If it's not known
it's not known.
astearns: So florian you suggest don't do anything?
florian: Other then fix bugs in some browsers. In the case where the
author doesn't want hyphens, but just breaks between all
characters, there's word-break:break-all it's only going to
give you places except where there should never be a line
break. 2 browsers break absolutely everywhere.
fantasai: Initial complaint is solved by browsers fixing impl of
break-all keyword to conform to the spec and include words
commonly used in Japanese that use latin characters. For
words that aren't common and won't be in Japanese
dictionary authors will need markup to be appropriate.
fantasai: General conclusion is no change to the spec, but initial
problem is solved by the three things florian outlines.
<fantasai> https://github.com/w3c/csswg-drafts/issues/785#issuecomment-370366049
myles: Spec doesn't say which hyphen opportunities exist. I guess I
agree with florian. Impl have a lot of leeway on how to
hyphenate.
astearns: I'm a little concerned about resolving without koji but
I'm personally convinced about no change.
astearns: Objections to resolving no change on this?
RESOLVED: No change on issues #785
hober: florian do you have links to the bugs?
florian: I have not. I only wrote the test an hour ago. I'll make a
proper test and submit bugs.
<dbaron> I think the relevant Gecko bug is
https://bugzilla.mozilla.org/show_bug.cgi?id=1358019
although I might be wrong
<dbaron> (and that was filed by fantasai)
florian: koji found this and he said he can't do it because it
didn't work in some browsers. dbaron asked if it was some
or all and I wrote this test and it's some. It was an ad
hock test so I'll write a proper one.
Received on Thursday, 22 March 2018 00:15:35 UTC