- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 17 May 2018 03:32: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 Scroll-Snap
---------------
- The group agreed that the focus should be encouraging users to
reference the new version of Scroll Snap and that writing a
guide to what can be done in both old and new would not move
toward that goes (Issue #2523)
CSS Text 3
----------
- RESOLVED: Defer this (word-break:break-word) to next level. (Issue
#2390)
- RESOLVED: Normatively state that text-transform does not apply to
plaintext paste. (Issue #627)
- RESOLVED: Make text indent percentage relative to the content box
of the element. (Issue #2394)
- RESOLVED: Define hanging punctuation as scrollable overflow in all
cases. (Issue #2398)
- RESOLVED: Requiring language for hyphenation to take effect.
(Issue #869)
- RESOLVED: Treat lone CRs as 0 width spaces. (Issue #855)
- The group needed more time to look at current behavior for Issue
#1597 (intrinsically-sized box with text-indent) so it will be
covered on a telecon.
- RESOLVED: Clarify spec to say control characters should be always
visible even if fonts don't provide a glyph. (Issue
#1990)
- RESOLVED: Defer this (font-relative letter-spacing) to text L4.
(Issue #2165)
- RESOLVED: Keep rule to collapse white spacethrough bidi formatting
chars, don't mark at risk. (Issue #2233)
- RESOLVED: Defer this (hanging-punctuation: last applying to colons
and dashes) to L4. (Issue #2392)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule
Scribe: dael
Schedule Note: During this time block the group split into two
sessions, one for CSS Animations (see Part IV of minutes) and this
session based on Text and Fonts
CSS Scroll-Snap
===============
Path to interop among implementations
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2523
majidvp: Chrome we're impl scroll-snap. We're close to shipping. I
tried to understand what other browsers impl. They're
completely different.
majidvp: In 2016 WG resolved to fundamentally change the spec. Older
spec is mostly coordinate based and new is element based.
New model I think is fundamentally better because it lets
UA make a better decision.
majidvp: At the time I think all impl agreed it's good and spec is
in CR.
majidvp: Only Safari implementation matches spec. Mozilla ships
unprefixed old spec and I see a bug a few years ago for
that. Same with Edge/IE they're an even older version of
the spec.
majidvp: 2 vendors impl old, Safari is close to new, Chrome will
ship close to Safari but probably cover more of the spec.
majidvp: Wanted to see if there's updates from other vendors.
fantasai: I'd like to mention it's important that whoever impl
scroll-padding and ships impl the behavior spec to apply
to containers without snapping turned on. If we want that
to ever work it needs to work when you turn on
scroll-padding so people can detect it exists via
@supports.
astearns: Comment from Edge folks?
Rossen: Looking for current status.
florian: I think it says you plan to do it.
Rossen: We haven't started work. Under considerations.
dbaron: I think updating we looked at doing in the medium term.
Possibly in next year, not next few months.
<tantek> For reference: our (Mozilla) bug to update to the
scroll-snap CR: https://bugzilla.mozilla.org/show_bug.cgi?id=1231777
<tantek> It's also in our 2018 priorities though we're not sure
we'll get to it in 2018: https://wiki.mozilla.org/CSS#2018_Priorities
majidvp: I wouldn't be surprised that since there's an implementor
saying that switching to element based won't be hard to do.
Safari I think managed to switch the model. Seems
reasonably straightforward.
smfr: Impl wasn't too bad. Some compat problems.
majidvp: Seems that for next year the old impl will exist. Next
topic is if we should have explicit comments on how to
migrate from the old snap points syntax to migrate to the
new and if there's a subset of old that can be used.
majidvp: For example, old had scroll-snap-destination and
scroll-snap-coordinates and they would align the two points.
Similar enough to the new spec that if you impl you can use
the old and new models at the same time.
We should have comments that this is safe to do, but don't
use old.
tantek: I'd rather not encourage authors to use any old syntaxes to
reduce compat shadow we create as a whole. I don't think we
should recommend older syntaxes.
florian: I've made demos that work in both old and new and you have
to use both syntaxes but that's all you can do.
tantek: We don't want to support old going forward and if someone
uses it because there's documentation on how to do it, it
increases the risk.
tantek: You increase the risk people create more stuff on the web
with the old stuff .
astearns: That they'll create stuff with old and new so it doesn't
break when you move.
majidvp: But it would be hard to measure they used both. I think I
agree encouraging using both may not be right.
astearns: Anything more?
majidvp: One last thing, spec didn't have tests. As we impl we added
tests, but I wanted to make a suggestion to other impl that
as they impl it would be nice to have more tests.
florian: I'm not impl but considering writing some tests. It's nice
you've got basic and I'll ping you to get a review when I
write for edge cases.
CSS3 Text - All Open Issues
===========================
astearns: I want to timebox this a bit. Let's go to 3:15 and have a
break and we'll switch to fonts. We'll leave the rest for
the afternoon.
<fantasai> https://drafts.csswg.org/css-text-3/issues-lc-2013
word-break: break-word
----------------------
issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-94
github: https://github.com/w3c/csswg-drafts/issues/2390
fantasai: Last time we talked we'd say add only if necessary for
compat reasons. Do we have enough information? Or are we
deferring?
florian: I talked about this with Rossen and they felt comfortable
postponing for now. They're not sure they're doing it yet.
fantasai: So continue to defer. Useful to know.
florian: There is a FF bug about impl because it was in the spec at
some point. We were clear that seeing it in a spec is not
enough justification for impl.
fantasai: And we removed it from the spec.
fantasai: So closed as deferred?
astearns: Objections?
myles: In L4 isn't there another property that does same thing?
fantasai: There's an existing property that's word-wrap: break-word
and that's different behavior.
astearns: And even with identical behavior there may be a web compat
reason to put it in L4.
astearns: Objections?
RESOLVED: Defer this to next level
florian: Follow up question to Blink. Usage is quite high so your
default answer is no.
koji: We contacted some site owners and they said the think the
different behavior is important so they won't change.
koji: About computing [missed] widths. It breaks line only if it
overflows so if an author sets it in the table cell it
expands. The scenario to not extends makes it more difficult
to us.
myles: min-width is different.
florian: But if we implement line-break:anywhere would that work?
fantasai: No because word breaking is normal unless there's overflow;
with line-break:anywhere breaking is anywhere regardless.
astearns: This is now a text L4 issue.
text-transform on copy/paste
----------------------------
issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-108
github: https://github.com/w3c/csswg-drafts/issues/627
myles: I've since flip-flopped. Last time I said text-transform
should apply to copy/paste, but I've changed.
fantasai: Prop: text-transform doesn't apply to plain text copy paste
fremy: There could only be manual tests.
RESOLVED: text-transform doesn't apply to plain text copy/paste.
koji: ...
fantasai: If I say ::first-line text-transform:uppercase if I copy
paste that to a text document, it doesn't make any sense.
koji: I have internal feedback that we have different behavior then
spec.
fantasai: innerText or innerHtml?
koji: Don't remember.
fantasai: I think applying text-transform is seriously problematic.
Because you lose information when you copy out that text.
koji: It's not my opinion. I'm trying to find what they define.
plinss: If they're defining how text-transform works they shouldn't
do that.
florian: They apply to innerText.
koji: It says [reads]
<koji> From the HTML spec: If node is a Text node, then for each CSS
text box produced by node, in content order, compute the text
of the box after application of the CSS 'white-space'
processing rules and 'text-transform' rules
TabAtkins: InnerText is not the same as innerHtml. InnerText
takes weird css already.
tantek: So it's weird legacy and don't build on it.
fantasai: There's many things wrong with that spec text. We
shouldn't build on that.
astearns: Given that innerText isn't a precedent should we resolve?
koji: He wanted to object, JS editors use innerText and want to be
same as copy behavior.
florian: plain text copy?
koji: They're using plain text.
astearns: I am inclined to unless you object have us resolve in this
way and let editors come back with spec bug or objection
in the issue.
astearns: Is that okay?
koji: [nods]
fremy: I don't know what Edge is doing but we won't change for what
the spec says. I think the spec says what Edge is doing. We
try very hard to work. I'm fine resolving because I'm pretty
sure we match.
<rego> it seems Edge is doing what's resolved (not applying
text-transform on copy&paste) :)
fantasai: So, am I putting this in the spec?
astearns: I'm hearing no objections. fremy says he may keep a bug
against the text.
fremy: I don't think copy/paste should be in scope of CSS. If you
want it in CSS that's fine.
astearns: We have 2 options. 1 is state that text-transform doesn't
affect plain copy/paste and other is be silent in spec.
koji: Their opinion is not to define.
astearns: How about a non-normative note that we believe it should
not apply to plain text paste but we're not sure it's web
compat.
fremy: We don't apply.
fantasai: This isn't an issue raised from outside WG and people
posted to www-style unhappy that some browsers have this
behavior, asking us to define it.
koji: For Chrome we have a bug saying don't apply. I believe FF has
bugs saying apply.
myles: Hearing 2 things. Everyone with opinions believe same on
issue. I'm also hearing we don't have jurisdiction to say it.
So we should just say it.
astearns: That's my non-normative note.
florian: Let's say it.
astearns: So we should say it.
tantek: We have interop.
astearns: Objections to normative stating that text-transform does
not apply to plain text paste.
RESOLVED: Normatively state that text-transform does not apply to
plain text paste.
Percentage on text-indent
-------------------------
issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-113
github: https://github.com/w3c/csswg-drafts/issues/2394
fantasai: Issue is percent on text-indent. In CSS 2 it was defined
as relative to containing block and FF interpreted as the
containing block of element it's set. Chrome it's the
containing block of the text being indented. If you
interpret as on the parent the behavior differs on if you
generate anon blocks or not, which is problematic.
fantasai: Proposal is to make the text-indent relative to the
context box width of the element itself.
fantasai: Means you don't expose anon block structure.
florian: I think percent text-indents are relatively rare.
fremy: People use -100% to hide text. Only case I've seen.
astearns: Edge would have to fix?
fantasai: FF
<fantasai> original post from dbaron at
https://lists.w3.org/Archives/Public/www-style/2015Feb/0250.html
<fantasai> Jonathan Kew requesting the spec (and Gecko) to change in
https://lists.w3.org/Archives/Public/www-style/2015Feb/0273.html
<rego> http://jsbin.com/yodarulizi/1/edit?html,css,output
<rego> edge and firefox have the same behavior, which differs from
chromium and webkit
koji: Do we know how often this is used?
florian: I don't have data. We know it exists and it's different in
different browsers. Probably not too much compat constraint.
We're suggesting FF aligns with Chrome which typically
doesn't break web.
koji: Only not compat when anonymous block exists?
koji: I implemented and there was a test case with repeat that all
browsers pass.
florian: If you're not careful in a test case and all boxes are same
size it's all the same.
fantasai: If test case was from hixie it was probably evil.
<fantasai> (as in, doing a very good job of triggering tricky cases)
koji: It has differences.
koji: I'm willing to simplify just wondering how much data we can
discover.
astearns: Any more to discuss?
fantasai: Jonathan Kew (Mozilla) was asking for spec to change.
fantasai: Prop: make it relative to content box of the element.
fantasai: Simple behavior, no weird edge cases.
astearns: Objections to make percentage relative to content box of
element for text indent?
dbaron: Both Edge & Chrome do that?
fantasai: Don't remember.
florian: I believe Edge does.
fremy: Test case?
dbaron: I found a web compat bug on percentage text compat on
overflow:hidden because when there's 2 boxes we do the same
thing as edge and we got a web compat bug. Or had. Probably
fixed.
<dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=1306590
<dbaron> and also https://bugzilla.mozilla.org/show_bug.cgi?id=908706
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5888
fantasai: Test case ^
astearns: rego posted a jsbin that for me shows difference from FF
and Chrome.
rego: My example was from the issue.
fremy: On the fiddle we have same as FF
rego: It's Chrome and Webkit for the other behavior.
fremy: Should the two lines be the same per the spec?
<koji> https://github.com/w3c/web-platform-tests/blob/master/css/css-text/text-indent/text-indent-percentage-001.xht
koji: This is in web platform tests ^ and passes in all browsers.
fantasai: So we want it the be the same for both lines. That makes
more sense.
fantasai: Having text indent reference width of parent doesn't make
sense.
koji: [missed]
fantasai: Depends on what percentage is about. It's specified
against containing block and it's not clear if it's the CB
of element itself or the text inside it.
dbaron: I'm fine changing. I don't understand the deal with the
compat bugs.
<fantasai> http://jsbin.com/yodarulizi/1/edit?html,css,output
rego: This has a paragraph, the other one doesn't.
fremy: Why should the text indent be same if the width inside the
box is smaller?
dbaron: There's a p inside so both the lines are in the inner box.
dbaron: I'm fine changing. If that's what Chrome does it'll be fewer
total compat issues.
<rego> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5888
is interoperable
<rego> but http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5889
is not
astearns: Chrome behavior makes more sense to me.
fantasai: Yes.
astearns: Proposal: Make text-indent percentage relative to the
content box of the element
fantasai: It's possible what was trying to be clarified by css2 is
that if it's a float it's still the same amount.
koji: Are you proposing...?
fantasai: Make everyone match Chrome.
koji: What we do is different...I believe we have code with
containing block and there might be difference in details.
This is probably different then what we do.
fantasai: We're proposing to say FF is wrong. When there's no floats
we should do what Chrome does.
florian: If you can find what's different between what we spec and
what you do let us know.
dbaron: Part of the old problem is people looked at different spec
text and thought different things.
RESOLVED: Make text-indent percentage relative to the content box of
the element.
hanging-punctuation and overflow
--------------------------------
issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-123
github: https://github.com/w3c/csswg-drafts/issues/2398
fantasai: This is about if hanging punctuation is ink or scroll
overflow. Current proposal is that it must be treated as
ink in the general case and scrollable when editable.
astearns: Threading the needle.
fremy: Test case?
fantasai: I'll try to make one.
florian: Overall ink is preferable, especially Japanese punctuation
marks. If you make them scrollable authors are in trouble
because if they have 1/2em overflow you have invisible
text. However when you're editing you want to get to
everything.
myles: Would there be a case for less them 1em?
florian: Yes because it doesn't look 1em. The glyph is 1em and the
ink is not.
myles: If hanging punctuation is 1 character.
florian: Characters that hang don't fill box.
myles: Ink doesn't. I want to look at actual examples because my
intuition is that because a character hangs there would be 1
em of actual space.
florian: The intuition of kobayashi-san is that it would be less. It
is not a full width character and should have the size ink
indicates and the rest is a historical accident back to
typing with blocks. People thinking of it as the space it
consumes. But I don't have data.
florian: Expert opinion. Not data.
koji: Hanging punctuation in CJK looks more natural in ink but David
Hyatt did the scrollable overflow.
florian: I think scrollable will trigger a bunch of scrollbars.
fantasai: When you have a scrollbar you don't want text to run
against the edge of the scrollbar. You want breathing room
which is typically >1/2em. A bunch of text in a scrollable
container would likely have at least an em of padding
florian: A container that's overflow:auto with intent that the
scrollbars will never appear.
myles: If fear is we'll create a bunch of scrollbars let's try and
see.
florian: Another piece of issue is that we're also saying preserved
white space when there's too much it's treated as hanging
and you would also cause scrollbars.
fantasai: Advantage of scrollable overflow is when you're trying to
select them you can see them.
myles: If there's not collapsible spaces you should be able to get
to the spaces.
myles: Having non-collapsed spaces and being editable are separate.
florian: For editing they must be scrollable. If that's true in the
general case I worry about scrollbars allover.
koji: Only webkit impl. If webkit can try it out.
fantasai: You treat it as ink overflow?
myles: I believe so.
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%40supports%20(hanging-punctuation%3A%20last)%20%7B%20html%20%7B%20background%3A%20green%3B%20%7D%20%7D%0A%3C%2Fstyle%3E%0A%3Cdiv%20style%3D%22width%3A%204em%3B%20border%3A%20solid%20silver%3B%20hanging-punctuation%3A%20force-end%22%3E%0A%E4%B8%80%E4%BA%9B%E6%B1%89%E5%AD%97%E3%80%82%20
fantasai: Test case^
fantasai: Add overflow scroll to it.
myles: Not scrollable.
[fiddling with test case]
myles: Inconclusive. I can't get anything to hang over.
florian: From PoV of editing with a single punctuation overflowing
it won't be a big different. It's preferable scrollable.
myles: So it should be scrollable overflow and if it's a problem we
can come back.
astearns: Sounds like we have consensus to define hanging
punctuation as scrollable overflow.
astearns: Do we want a note about concerns?
fantasai: I think people can complain about it.
astearns: Objections to define hanging punctuation as scrollable
overflow in all cases?
RESOLVED: Define hanging punctuation as scrollable overflow in all
cases.
Should 'hyphens: auto' work if lang is not declared?
----------------------------------------------------
issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-133
github: https://github.com/w3c/csswg-drafts/issues/869
myles: Hyphenation requires a dictionary. The dictionary selected
should be informed by lang. Without lang hard to pick
dictionary. In webkit we pick the OS dictionary.
myles: I believe that's right.
myles: We have seen a lot of untagged content.
dbaron: I think this was intentional decision by WG to encourage
content to be written in a way that works worldwide.
dbaron: Gecko impl what the spec says, where we only auto-hyphenate
with a declared language.
astearns: Seemed like terrible things could happen if you use a
dictionary without a lang.
fantasai: Also, if they think their page works, but only on their
computer that's bad.
florian: If hyphens was meant to be applied but doesn't that's not
good but it's readable. Auto hyphens would make text
confusing. It's encouraging authors to not lang tag and you
might hyphen wrong which is worse then no hyphens.
myles: For the first part our thought is about existing content. For
new content we should encourage correct tags. We're worried
about breaking large websites.
florian: You'd have graceful degradation.
fantasai: The pages are broken in browsers that don't have the
behavior you have, so it's already broken. This just makes
it more obvious by being broken in the author's browser
too.
astearns: Aren't you concerned you get German hyphens on English
text? Seems like a reason to change this preference.
richr: If you have a http header with a language?
fantasai: That counts as a language.
myles: I won't object.
<dbaron> https://html.spec.whatwg.org/multipage/dom.html#attr-lang
astearns: Anyone else?
astearns: Objections for requiring language for hyphenation to take
effect?
RESOLVED: Requiring language for hyphenation to take effect.
Lone CRs
--------
issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-138
github: https://github.com/w3c/csswg-drafts/issues/855
fantasai: Jonathan Kew reports, per spec a lone CR is just like a
lone line feed and it's a segment break. But browsers
discard the carriage returns. If you put them in your
source they're transformed. However if you inject it via
JS into the dom text content then it disappears.
fantasai: If they used dhtml and not escape it would happen. We
accepted the change to make them invisible
fantasai: And then when I tried to edit in, I realized that making a
character invisible is under defined.
fantasai: Does it break shaping?
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%D8%B4%D8%AA%0AVA%3Cbr%3E%0A%D8%B4%26%23x000c%3B%D8%AA%0AV%26%23x000c%3BA%3Cbr%3E%0A%D8%B4%26%23x000d%3B%D8%AA%0AV%26%23x000d%3BA%3Cbr%3E%0A%D8%B4%26%23x200b%3B%D8%AA%0AV%26%23x200b%3BA%0A%0A
myles: Can we pretend it never existed?
fantasai: Or treat similar to zwsp.
myles: For kerning you want it not to be similar to zwsp
fantasai: I think this is a weird edge case.
myles: You're saying because it's an edge case we should do the
simple thing.
fantasai: For pages authored with CRs they're taken care of by html
parsing algorithm. This is just people who stick a
CR in the text content via JS.
fantasai: Gecko treats like zwsp and chrome drops. Someone help
me decide between the 2 behaviors.
florian: Dropping seems simpler.
myles: Harder to implement because changes size of data structure.
koji: Difference between drop and zwsp?
fantasai: Shaping between adjacent chars. There's a test case.
myles: In an impl where strings are never copied you'd have to
remove the character and shift the future to pretend it
doesn't happen.
astearns: We have 1 browser with zwsp and another inclined.
fantasai: fremy what does edge do?
fremy: I can't load page.
eae: We wouldn't object.
myles: There are other characters treated as zwsp.
astearns: fremy do you care?
fremy: I don't know what Edge does.
fantasai: There's an IRC test case.
fremy: It's so broken we need to fix it.
astearns: Prop: Treat lone CRs as zero-width spaces.
RESOLVED: Treat lone CRs as zero-width spaces.
intrinsically-sized box with text-indent
----------------------------------------
issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-156
github: https://github.com/w3c/csswg-drafts/issues/1597
fantasai: What impact does percentage text-ident have on intrinsic
sizing?
myles: If there's no web compat risk can we use a model for what
happens in other situations?
fantasai: Treat as 0.
florian: Risk is if you want to treat it as -999% to get it out.
fantasai: You resolve, but for computed size calculation we treat as
0.
[everyone looks at test case: https://wptest.center/#/0jcvq1 ]
fantasai: It treats it as 0.
myles: Everyone does 0?
astearns: No, Chrome and Edge are using parent size according to
fremy comment.
florian: Going to the parent?
myles: Parent can also be shrink wrapped.
fremy: If available is if you're not sizing the parent as
min-content.
myles: Else it's 0?
fremy: Yes.
myles: We should just always 0. This is just a corner case.
fantasai: If we have 2 impl we might as well align. I'm not sure
what this comment means.
fantasai: Chrome and Edge use parent size in min-content if
available.
florian: If parent has definite size work from that if not 0?
fantasai: We're resolving against element itself.
fremy: New version of Edge is completely different. We use 0 all the
time.
fantasai: We'll cover this one on a telecon.
Shipping visible Cc
-------------------
issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-161
github: https://github.com/w3c/csswg-drafts/issues/1990
astearns: This time we'll synchronize.
myles: Didn't have a date and it failed. We shouldn't show them
visibly.
fantasai: We need it all implemented behind a flag first and
*then* all flip on.
myles: That's fair, but has always been true.
fantasai: Didn't some people just release?
florian: They impl something... not what we speced?
fantasai: Comment from xidorn was we wanted to coordinate shipping
this together so that authors know it's an intentional
thing for the platform.
eae: For us it's font dependent. If the font has a glyph it shows.
myles: I think that's what we do too.
astearns: So people sync shipping thiiinnngs...
fantasai: Previous spec said control characters are invisible.
People wanted it visible, I changed the spec, we were
going to coordinate and it shipped.
eae: We had a flag and there was a rough time period.
fremy: We were supposed to do it and we did not.
fantasai: I think goal was ship on a particular day. Anyone who
shipped on proposed schedule had no one with them.
astearns: However this happened. What's before us right now is how
to deal with spec. Do we leave it in that we want control
characters visible? Change spec to match what's interop?
florian: We no longer have full interop. Some browsers are visible
or not depending on font.
astearns: Any browsers always visible?
florian: I think that's behind FF flag.
astearns: Edge has not shipped it. Safari?
myles: [missed]
florian: Blink basic font for windows has control characters so it's
there but on iOS it doesn't so they're not.
Rossen: We shipped when we said it would.
fremy: Did we?
??: We have 2 interop impl on windows.
dbaron: Based on what I'm reading FF nightly has had it on for a
while.
<dbaron> (though I'm less sure than usual that I'm reading correctly
since somebody just rewrote a bunch of pref stuff...)
<xidorn> (dbaron: I just had a look at the code and I don't think we
enable it right now on nightly)
<dbaron> xidorn, layout.css.control-characters.visible seems to be
enabled
<xidorn> (dbaron: on, I see, yes, we enabled that in nightly)
astearns: This being in the spec is not gated on the simultaneous
shipping.
florian: Clarify spec that we mean visible visible.
??: What character do you use
fantasai: Missing glyph replacement.
florian: You put a visible thing so people fix it.
astearns: So this issue is basically close and clarify that it
should be visible. But the coordination conversation is
not relevant
astearns: Objections to clarify spec to say these characters should
be always visible ?
eae: First browser will look broken. It'll be worse if we force to
always. I'm not opposed but a little unpleasant.
astearns: Still better if coordinate.
RESOLVED: Clarify spec to say these characters should be always
visible (regardless of whether any font has assigned a
glyph)
font-relative letter-spacing
----------------------------
issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-167
github: https://github.com/w3c/csswg-drafts/issues/2165
fantasai: This was a feature request. Worth a quick look. Might have
to go in L4 unless someone has a quick solution.
fantasai: We can add unitless values or add percentage or add a
unit'ed value.
florian: TabAtkins doesn't like unitless values
fantasai: Word spacing the percent means that character's own width.
fremy: I understand what we're doing. In previous issue with CR we
render because it's a control character. We render the black
square.
florian: For letter spacing I feel comfortable defer.
astearns: Obj to defer this to text L4?
RESOLVED: Defer this to text L4.
white space collapsing through bidi formatting chars
----------------------------------------------------
issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-172
github: https://github.com/w3c/csswg-drafts/issues/2233
fantasai: We asked for i18n feedback. Wanted to check with WG as
well. You have some text and at the end of the line you
have whitepsace and mixed in there are bidi control
characters. Does the whitespace collapse?
florian: If instead of bidi control characters you have markup with
the equivalent bidi commands we collapse through.
myles: Reason to not collapse is if there's a character user can
see. This is not that. It should collapse.
florian: Spec says that but I don't believe anyone does that.
florian: CSS2 and CSS Text 3 says it must collapse.
fantasai: Keep spec as is and file bugs?
myles: This is a thing we should do.
koji: We make bidi controls follow collapsing.
<eae> (to clarify, in our new layout engine we do collapse through
bidi control characters. the current layout engine does not)
astearns: Text 3 is where in process?
fantasai: LC
astearns: It'll have to be at risk if we still don't have impl.
fantasai: I'm happy for at risk.
fantasai: Mark it as at risk and if no one impl we say we want to do
it this way.
astearns: Close no change?
florian: Mark at risk?
RESOLVED: Keep but mark at risk
fremy: Edge does this
fantasai: koji says Chrome will.
RESOLVED: Just keep, don't mark at risk.
hanging-punctuation: last and colons and dashes
-----------------------------------------------
issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-170
github: https://github.com/w3c/csswg-drafts/issues/2392
fantasai: Brad Kemper asked if we can hang the colon. I thought and
if we wanted to hang colons with the 'end' values that's a
problem but we can do it for the 'last' value and probably
would work. Do we want colons and maybe dashes to be
hangable?
myles: We had a long discussion on this.
fantasai: This is the 'last' line, that was 'end' value. Last line
has different behavior and so we want them to be hangable
there.
myles: Don't want new issues for every new character, there should
be named sets.
fantasai: Dashes are easy as a set in unicode.
myles: I mean, I'm writing an English novel and I want the things in
English novels to hang.
astearns: You would have missed Brad's use case.
fantasai: I think we could do customizable sets some day, not now.
myles: I don't think these sets should be described in CSS
properties. The spec should have a handful of common sets.
fantasai: The default set. Does it include colon? We have a reason
to include. Any reason not to?
myles: The sets of characters are designed for cjk.
fantasai: First and last are all languages. End is CJK. I don't
expect them to use last because they'll use end. Should
that set include colons and dashes?
myles: What's I'm describing is the set has a list of characters.
You want to add to the list. I think instead of one list we
add to we should have general sets.
fantasai: We can do that. But the property defining those sets need
to have values.
myles: The set I see here is designed for one typographic use case.
astearns: Are you asking when we add this new set it's distinct in
the spec? When we add this it'll be in a set.
myles: It can be added both sets.
astearns: You're asking for things to be added in sets based on use
cases?
myles: Yes. I think we should consider this at higher level. For
this use case hang these. And this use case hang these.
astearns: For fantasai we need a default.
myles: Colon doesn't fit in the current set.
fantasai: You're looking at the set for end. The last value hangs
a bunch of large punctuation categories. Do we add more
which is colons and dashes.
koji: I share myles' concerns. The property was defined first for
CJK so there's a lot of CJK. If we want to support Latin
hanging punctuation we should think about a proper set of
hanging punctuation for Latin.
fantasai: We didn't want to do optical margins in L3, but first
and last is in L3.
fantasai: I would ask the question, there's clear use cases for
hanging colons and dashes. Is there a reason why we
shouldn't?
koji: We don't know what the design should be when this property
includes other scripts. Doing that right now may conflict.
astearns: Not sure I agree. I think you have to give evidence that
adding colons and hyphens to the sets would break CJK
layout.
koji: As fantasai said last isn't used in CJK. First is for CJK,
last is for Latin.
fantasai: We're asking to change the set of characters in last to
include more characters.
koji: I think we will have more characters. I wish us to start
thinking about hanging punctuation in a serious way.
florian: Remove last until we know what we'll do with it?
myles: There is an impl, at least one. Proposal is don't touch for
now and have a more elaborate extension in next spec level
astearns: Defer this to text level 4 is proposal.
fantasai: I feel that every time we talk hanging punctuation people
gets confused. I'm trying to distinguish hanging
punctuation at end of every time vs that you do at
beginning of first and end of last line. It's a different
set of characters.
fantasai: You want to pull out the quotation mark from the outside
of the start of the paragraph, but you wouldn't want to do
it anywhere else. It's a different set of characters and a
different feature.
florian: And within that set these characters make sense.
astearns: In the permutations I'm familiar with, optical margin
alignment is the thing in text 4 and hanging punctuation
is what's in L3. But I don't know if my concept of hanging
punctuation in Roman can extend to CJK.
florian: For you would colon and dash be included?
astearns: Yeah.
fantasai: We're solving 2 use cases in L3.
astearns: We don't have to have a complete feature in a module. That
we're close to CR makes me hesitant to add more things.
florian: This new character solves the second feature better. Should
it be incomplete in L3?
astearns: Yes because we have an impl and we can refine in a future
level.
fantasai: But it's a change in behavior, not an addition.
koji: I think colon and dash isn't a significant difference to add
in L4.
florian: We'd have to revise L3.
koji: Future level can change past features.
florian: It means you can't conform to both.
myles: When you impl hanging punctuation there will be tests to say
don't hang anything not in this list?
florian: Yes. You should test these character and only these
characters hang.
astearns: That the spec says UA may include other characters as
appropriate makes me think this is extensible.
astearns: I prefer to defer.
fantasai: It's fine, but we'll discuss in Sydney.
astearns: I'd like to go into more details on the set in L4.
astearns: Objections to defer to L4?
RESOLVED: Defer this to L4.
<br type="15 min">
Received on Thursday, 17 May 2018 07:33:22 UTC