- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 19 Dec 2018 20:09:07 -0500
- To: www-style@w3.org
- Cc: www-svg@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.
=========================================
Move SVG text-decoration features to a CSS draft
------------------------------------------------
- RESOLVED: text-decoration-fill and -stroke goes into Fill and
Stroke spec. Shapes properties go into Shapes L2. Both
with notes they're at risk and looking for implementer
interest. (SVG Issue #591)
CSS Grid
--------
- RESOLVED: Close this issue (Issue #3445: Non-existent line names
in abspos grid items) and accept the clarification note.
CSS Text
--------
- RESOLVED: Add a clarifying note to L3 and discuss a potential new
value in L4 (Issue #3434: Prevent line breaking after
explicit hyphens)
- There is disagreement to if the segment break transformation rules
should be defined using East Asian Width or if there's a
different approach available.
- The argument to use East Asian Width is that currently line
breaks are unusable and this moves toward addressing that
even though it requires special casing some characters, like
emoji. Additionally more characters can be added at a later
date if a better system is found.
- The argument against is that since it is currently unused time
should be taken to find the right solution and avoid risk
that we'll end up with a compatibility problem later.
- fantasai stated that there were two principles she's like to
solution to adhere to:
1: We have defined rules all UAs must follow.
2: We're using unicode property of some kind and not having
CSS spec create a custom list
- Discussion will continue on the issue and then on a telecon or
F2F.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Dec/0028.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Tantek Çelik
Dave Cramer
Elika Etemad
Javier Fernandez
Tony Graham
Dael Jackson
Brad Kemper
Peter Linss
Myles Maxfield
Michael Miller
Anton Prowse
Melanie Richards
Florian Rivoal
Jen Simmons
Alan Stearns
Regrets:
Chris Harrelson
Chris Lilley
Nigel Megitt
Manuel Rego Casasnovas
Lea Verou
Greg Whitworth
Scribe: dael
Next F2F
========
Rossen: Let's get going
Rossen: As usual first agenda item is call for any extra items
Rossen: Or any changes you would like to see to the current agenda
florian: One on scheduling, I think. fantasai you wanted to mention
a side meeting on inline?
fantasai: There was a lot of inline topics, wondering if want to
spend extra time around F2F on those issues. Not sure what
would be on the agenda. If anyone is interested we can try
and schedule.
Rossen: Can we try and do this on the private list to see what works
best?
fantasai: mmhmm
Rossen: I think this is a great idea.
Rossen: Anything else?
Move SVG text-decoration features to a CSS draft
-------------------------------------------------
github: https://github.com/w3c/svgwg/issues/591
Rossen: Is krit on?
astearns: I don't think he is, but said it was fine without him.
Rossen: Request is to move text decoration features into CSS WD
Rossen: Sounds like we took all resolutions last week about moving
Rossen: We have resolution for text-decoration-fill and -stroke.
What's asked now?
astearns: Resolutions are from SVG WG
Rossen: You're correct. I was remembering the resolution frenzy a
week or 2 ago
Rossen: So SVG group is more then happy if we can take text decor
related properties back into CSS
Rossen: Since there are already resolutions on this in the issue we
can do one to accept them all
Rossen: Comments or objections?
<tantek> are they implemented outside of SVG?
florian: Would this be text decoration L4?
Rossen: That would be my expectation unless there's a reason to put
anywhere else
AmeliaBR: Fill and stroke module is other logical place. We're
recommending to move to CSS because fill and stroke is
taking basic fill and stroke properties which these line
up with. They're equivalent of text decoration color but
if you're using fill and stroke you need to continue that
AmeliaBR: They're in SVG2 right now, but not stable enough for
implementation to stay there as we go to CR. Fill and
stroke module is also called CSS Paints
AmeliaBR: It's in FXTF repo
<AmeliaBR> https://drafts.fxtf.org/paint/
florian: Is there a resolution to move these to CSS Repo?
AmeliaBR: All FXTF specs are full responsibility of CSS
florian: Yes, but did we resolve to move them?
Rossen: Yes, I'm pretty sure we have resolutions
tantek: Are these implemented yet? Or are they things implementors
said they want to implement?
AmeliaBR: No implementations yet which is why we can't keep in SVG2
tantek: Makes sense for moving them out.
tantek: Do we have any positive noises or statements about intent to
experiment or implement from any implementors?
AmeliaBR: In SVG we've had positive statements of the type where if
anyone else implemented we'll implement too. Nothing
beyond that
Rossen: Shape properties were discussed at length. Only implementor
at time interested was inkscape. Browser implementors
weren't interested at the time
Rossen: I remember a couple years ago consensus was we will move and
use CSS shapes L2 and go from there. See how much
implementor interest that takes
Rossen: text-decoration-fill/-stroke I don't recall. I trust
AmeliaBR.
Rossen: If the leading question is if they should go to WICG instead
that's a good point
fantasai: I think these properties are quite straight forwardly
analogous to what is in fill and stroke already. Question
on if they should exist is more interesting. We can add
and say at risk and point out we're not sure this is high
priority to have fill and stroke separate. I don't think
WICG makes any sense because it's analogous to what we have
TabAtkins: Agree. At bare min we're adopting the definitions as
exist. We can put in an appendix and note they may not
make it.
tantek: I'm okay incubating these in WG because we've shown good
practice in the past. If we don't have implementors with
interest I'd ask we note in the spec we're looking for
implementor interest so we're transparent. Other then that
fine with where group puts this
fantasai: We can put this in an appendix with that note
<myles> I'd like to implement these someday eventually
<tantek> concern with appendix is that indicates informative intent,
whereas I think I am hearing normative intent
<fantasai> tantek, appendices are normative unless otherwise noted
AmeliaBR: There's a placeholder section already in fill and stroke
and it even says they should be at risk, just doesn't have
actual definitions. Can slot in neatly there right now
<astearns> https://drafts.fxtf.org/fill-stroke/#text-decor
Rossen: Sounds like we're taking text-decoration-fill/-stroke into
Fill and Stroke spec and shapes into Shapes L2 with a note
calling for impl interest
Rossen: Reasonable?
<tantek> +1
Rossen: Objections to adopting text decoration fill and stroke into
text decoration with a note calling for impl interest. Same
for shaping into Shape L2?
AmeliaBR: Fill and stroke spec is what we talked about.
Rossen: Sorry, text-decoration-fill and -stroke goes into fill and
stroke. Shapes properties go into Shapes L2
RESOLVED: text-decoration-fill and -stroke goes into Fill and Stroke
spec. Shapes properties go into Shapes L2. Both with notes
they're at risk and looking for implementor interest.
CSS Grid
========
Non-existent line names in abspos grid items
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3445
fantasai: Wanted to confirm everything with WG since it's CR.
Rossen: Can you summarize?
fantasai: Issue was about the reference for line name. Currently
define implicit lines have all the names. Abspos referring
to line name not in explicit grid. Had been a case where
someone referenced a non existent line in inflow grid and
caused a line to be created and now abspos is looking for
a different line name. We defined it's looking for
implicit line. Added a note to clarify, everyone seems in
agreement
florian: Close no change or close with clarification note?
fantasai: Close with clarification note
<lajava> I've been discussing this with rego and we agree that the
note clarifies the issue
Rossen: Objections to close this issue and accept the clarification
note?
RESOLVED: Close this issue and accept the clarification note
CSS Text
========
Prevent line breaking after explicit hyphens
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3434
<fantasai> https://drafts.csswg.org/css-text-3/#hyphenation
florian: Not entirely clear to me at least and at least one other
implementor if hyphens:none is meant for only suppressing
invisible but leave existing hyphens alone or if it's meant
to turn off wrapping opportunity at regular hyphens
florian: koji and, I think, fantasai understood to not doing
anything to normal hyphens. But I read that it's no
breaking at hyphens. Either way we should clarify. If we
clarify to say it's not suppressed maybe explore a control
in the next level
florian: Current spec is not clear so we should clarify
florian: Spec says suppresses hyphenation opportunities. Doesn't
define a hyphenation opportunity.
florian: That's where ambiguous comes from
dbaron: You'd think hyphenation opportunity is different then
breaking opportunity.
florian: Different from wrapping opportunity. Wrapping opportunity
that's right after a hyphen is different. I can see it's
reasonable for the spec to mean it
AmeliaBR: As an author, I've come across places where I want to
suppress break at hyphens. But you can do that by turning
off wrapping
florian: You can do it with extra mark up.
astearns: Need extra to signal intent. It's not breaking at any
breaking opportunity in that string. If you have a regular
hyphen and words on either side with breaking opportunity
you don't want those to break either
<myles> ++astearns
florian: You mean you would allow in other places as well? The
automatic hyphenation. But in this no auto, no wrapping.
astearns: You want markup on the special words where you don't want
entire term to break
florian: Not opposed to saying hyphens:none does not disable
wrapping at regular hyphens. I think we could use a little
clarification
florian: It does seem that's what spec intends, but was not obvious.
AmeliaBR: I like clarifying hyphenation opportunity is opportunity
to insert a hyphen. Breaking opportunity is second to that.
florian: And we can re-open an issue on L4 to explore if we want an
automatic way of doing this.
dauwhe: We have general rule where we don't want to hyphenate
hyphenated phrases and I'd love some css control for that
that doesn't involve preprocessing thousands of words. But
that's L4
dauwhe: We don't want to hyphenate words with intrinsic hyphens
florian: That's dealt with. This is a different case.
dauwhe: I'm phrasing in a different way. But yes we don't want line
breaks anywhere in those phases as astearns said
fantasai: Seems really weird that you'd take hyphenated phrase like
one in issue, forbid breaking in a long term is unusually
strict. I can see not breaking at a point that's not the
hyphen, but breaking at hyphen I don't imagine you'd want
to suppress.
<bradk> “E-Mail” should not wrap
fantasai: Case here is someone that doesn't want hyphenation and is
getting breaks at hyphens. And they thought they turned
off hyphens and think hyphens and breaking is analogous
AmeliaBR: I think there is a Unicode character for hyphen without
break
fantasai: I think it makes sense suppress hyphens at breaks through
hyphens property. Given current state of implementations
hyphens:none does not suppress those breaks. Might mean we
add a value in L4 that means no really don't break at
hyphens or hyphenation points.
myles: What's the example?
florian: bradk's IRC example. You'd never want e-mail to break
<AmeliaBR> @bradk, I think that would also be covered by
hyphenate-limit-chars
https://drafts.csswg.org/css-text-4/#hyphenate-char-limits
myles: This is about things like long-term and t-shirt
<dauwhe> https://www.princexml.com/doc-refs/#prop-prince-hyphenate-before
fantasai: t-shirt could be a case where you don't break if it's less
then 2 char on other side. You can control that for
hyphenation in L4.
fantasai: long-term breaking there is less likely to be because each
half is too short
florian: Seems like stylistic choice in this case
florian: Can we resolve for L3 to clarify as AmeliaBR and I spoke of
and leave it open for L4 and hash it out there? Seem
reasonable?
myles: One more thought, in section it says it affects searching and
copying. I think affecting copying is a feature not a bug.
florian: Possibly. Searching is more annoying
myles: Have to look at searching. Searching is more complex
fantasai: NFK normalization
florian: There was spec by i18n to help browsers figure out what to
do when searching
myles: Like curly quotation marks match straight quotation marks
myles: We use ICU usearch facilities
florian: I think we're a little off topic. L3 hyphens:none doesn't
do what we talked about, open issue in L4?
fantasai: I think we wouldn't change meaning of none in L4.
florian: We might add a value.
fantasai: Fine with me.
<bradk> 👍
Rossen: Any objections to add a clarifying note to L3 and discuss a
potential new value in L4?
RESOLVED: Add a clarifying note to L3 and discuss a potential new
value in L4
Segment Break Transformation Rules for East Asian Width property of A
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/337#issuecomment-446842105
Rossen: Brought back from week before if I recall
Rossen: Additional comments from koji. Wanted to have koji comment.
Rossen: Do we have koji or enough from his feedback that we can
discuss?
myles: I think I understand koji's feedback
Rossen: So we can make progress and see if can resolve
florian: Context is suppressing segment breaks in source code. If
you have word space word space the segment break is
converted to a space, but in languages without spaces we're
having a part of the spec deal with suppressing.
Non-controversial part has been shipped. Characters on both
sides of break are unambiguously CJK
florian: What do we do when one side is ambiguous like ". Initial
proposal was when segment break is language tag as CJ and
one side is ambiguous and the other unambiguous we suppress.
florian: emoji, though, was inconsistent. Some wide, some narrow,
some ambiguous. We proposed in spec to treat all emoji as
ambiguous so if you had unambiguous Asian on the other side
you suppress the break
florian: koji pushed back and myles agrees with pushback
myles: I think we can all agree on goal. If you have Chinese text
line break in the middle shouldn't turn into a space.
myles: When I was reading spec the whole section on how to determine
if suppress space proposal looks at East Asian Width and then
emoji and then elsewhere and it seemed this wouldn't work in
a lot of cases we haven't thought of. The more we try and fix
this section the more complex it gets and the more we'll miss
myles: I think that's similar to koji where if you add a case for
emoji you'll have to add a case to reduce set of emoji
because unicode says more is emoji then people think. Instead
of spec behavior only one browser impl we should let browsers
experiment and try and come up with a better way, perhaps
involving unicode consortium.
florian: Agree with part, but not all. Languages are complicated so
if we want to cover all cases rules will be complicated. If
we are not careful here and we add too many things we later
want to remove that would be problematic.
florian: Being cautious about what to add, I would agree.
florian: On the other hand, letting UA experiment- that's not
reliable for authors so they can't do anything. If both
sides are clearly Asian there's no worry and we should do
it. Ambiguous on one side and break is Asian and other side
is Asian we're safe.
florian: Emoji we went through everything and found that we thought
adding all of it was safe. I'd be okay with you double
checking.
florian: I suspect there will be more areas of inconsistency. We
will at some point say this is rare enough and we're not
handling it. I think we should solve enough that East Asian
languages can have line breaks.
florian: I would say let's be careful with what we add. I think we
have been with emoji. There is a slope here, but we can
decide how far down we go
<fantasai> proposal wrt emoji is in
https://github.com/w3c/csswg-drafts/issues/337#issuecomment-444316214
<fantasai> you can see the entire list of affected characters
myles: Rather then going half way down the slope and saying no more,
we should investigate another approach
florian: Do you have a suggestion on another type of approach? I
feel this will be about subsets of unicode things. How to
do it may have strategies.
myles: I don't have a specific proposal and that's why I think more
room to experiment. I don't think we're at a point where we
can say some should and some should not react this way. I
think we're at an early phase.
fantasai: I don't think that's the case. Spec has used East Asian
Width property and no one has said we shouldn't use that.
The details of how we're using it we're finding in some
cases it needs to be tailored to do it in the same way.
Smiley face is neutral and grinning is wide, but author
won't expect that.
fantasai: I don't think it makes sense for us to have an environment
where they can't know that their space will get eaten by
changing smiley. Rule florian has is there are subsets of
emoji where we don't know why they're wide.
florian: They're mostly classified due to what legacy encoding they
came from
myles: I agree East Asian Width doesn't work well. Possible solution
is don't use East Asian Width and I'd like to pursue that
fantasai: Alternative is script + script extensions property. Other
then that it's creating a custom list which we won't do.
florian: That's because maintenance.
florian: East Asian Width spec says it should be tailored
koji: I agree with myles. East Asian Width is designed to be compat
with encoding. Not designed for this purpose. We'll see lots
of inconsistencies. Options are live with inconsistencies. If
we don't want that, don't use East Asian Width
florian: My feeling is in terms of web compat if we add more cases
to suppress it's safe. Removing is bad. If we find a more
efficient approach later that characterizes more characters
we can move to that. We should be careful to not suppress
spaces that really should be there. Even if way we reach
character set is more complicated then you wish, that's not
a long term problem. If we find a better way in the future
we can do that as long as we didn't include so many
florian: I think marking some of it at risk we can do that. But it's
not going to do wrong behavior in a way that we can't walk
back.
florian: So I propose mark as at risk, but leave it, and welcome
experimentation
koji: If we find myles' point logic on East Asian Width wasn't great
it's not backwards compat
florian: Suggesting there are currently characters classified as
wide that shouldn't suppress spaces? Because if there isn't
any we're safe
myles: One happy medium is to say there are some sets of triggers
that will or won't cause suppression. Other then that it's up
to browser. Kinda like line breaking with some restrictions
fantasai: Where you break the line isn't a big deal. It doesn't look
really wrong with slight differences. But if there is a
space in one impl and not another that's a real problem
for the typesetting. If there isn't interop the user can't
check their text, looks fine, load in another browser and
there's lots of space. We need interop and this isn't a
good place for everyone decides.
<dbaron> I think there are real web compatibility problems as a
result of line breaking differences.
myles: We've go through to today
florian: No author uses line breaks in East Asian. We're trying to
make it better
myles: Why not solve now because they're not using it
florian: Any solution will be a superset of what's specced today so
I don't see why can't spec today. I'm willing to put part
that you think is overkill at-risk
myles: As spec right now there is an algorithm where every string
produces yes or no suppress.
florian: What I mean is if we say yes suppress to more things it
won't cause web compat. If we say yes to fewer things it
will. That's why I'm talking about supersets. If we add
more things authors will be able to add more line breaks.
So we can expand. Reducing is bad. So if there's a
different solution later with a same size or larger set
that's okay.
myles: I'd like to expand that set without going through WG
florian: I don't see how that works. Regardless of how we spec if
browsers aren't interop it's not usable
myles: Already not
florian: Trying to make it usable
myles: So wait
florian: Wait until what? You say don't standardize and I say do.
Rossen: We're getting too argumentative and I'm not sure we're ready
to resolve. Discussion is valuable and brings us closer to
something where we can resolve. Doesn't feel we're there yet.
Rossen: Perhaps we can continue to work on this as part of the text
inline focus group that will be proceeding F2F unless you
feel strongly we can resolve
florian: I don't feel we can. Taking it offline for now and next
time we meet we keep talking sounds...not as good as
resolving, but we can't resolve
Rossen: But this conversation was great and gives room for people to
continue
fantasai: I want to say I insist on 2 things. 1: we have defined
rules all UAs must follow. 2: We're using unicode property
of some kind and not having CSS spec create a custom list
<tantek> +1 to fantasai's two rules
Rossen: We can recommend to people what they can do, we can't
require it
fantasai: Then you'll be non-compat with spec
myles: I'd like to hear what unicode consortium has to say
fantasai: Their feedback is East Asian Width is not something
they're putting effort into maintaining
florian: That conversation goes off topic, it's hard to share it all.
fantasai: And we're explaining what we're doing and they ask if
we're using UAX-14 properties and that's not helpful
Rossen: Your point is valid. This won't bring us closer to
resolution.
Rossen: Let's table this and work more to get to something better
for interop and for the web.
2018 In Review
==============
Rossen: We've got a minute left. I'd like to wrap up 2018 by
thanking everyone for all the hard work. I wanted to share a
quick state. In terms of how productive we were; If a WG is
measured by amount of spec published then 2018 has been
spectacular.
<myles> yaaaaaay!!!
<tantek> Woohoo! 🎉
Rossen: We have published 4 RECs, congrats to everyone that put the
hard work into getting those. 13 CRs including one Houdini.
Rossen: We have published 27 WDs, some of them a few times
Rossen: We have published 44 documents which is unbelievable.
Congratulations. 2017 we had 16, 2016 11, 2015 we had 8.
We're trending quite well. Not sure we'll be able to keep
that curve next year, we'd need over 100.
Rossen: Bottom line, thank you for all of the hard work. I know
editors have been pushing hard, people have been writing
test cases, debating issues, all of this results in an
awesome 2018. I'm looking forward to 2019 being even better.
Rossen: Thank you again for a great 2018. Happy holidays to you and
your family and we will be back on January 9th as our first
2019 call
Rossen: Happy holidays, talk to you in 2019
Received on Thursday, 20 December 2018 01:10:13 UTC