- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 25 Jul 2018 19:33:34 -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
--------
- fantasai requested assistance from experts for issue #698 (cursive
shaping breaks needs better scoping). myles offered to review
and Rossen will ask a font expert from Microsoft to review.
- RESOLVED: No to renaming hyphenate-character and add normative
text describing how UIs are allowed to truncate
additional characters (Issue #2809)
CSS Inline
----------
- RESOLVED: Change the initial-letter value to initial-letters
(Issue #862)
- A new github issue will be opened (Issue #2950) to try and find a
new name for initial-letters as the current name makes it seem
like a selector.
- RESOLVED: No change is needed (Issue #2703: Initial letter,
sizing, and overflow)
CSS Shapes
----------
- RESOLVED: Accept the changes as stated in the issue (Issue #2375:
Degenerate polygons with positive shape-margin)
- Issue summary:
- Zero-area shapes still have edges and those edges impact
float layout.
- Zero-area shapes can be expanded by shape-margin values.
- Zero-area shapes will not affect floated elements that are
block adjacent -- there is no minimum of 1 pixel area
applied to the shape.
- Limit the inset rectangle to a minimum of zero width/zero
height, using rules similar to how border-radius values
that add to greater than 100% are adjusted.
CSS UI 4
--------
- RESOLVED: Accept florian's proposal (Issue #285: Readonly form
control and user-select)
[Proposal (to be word-smithed into a PR for review): an
editable element is either an editing host or a form
control with normally mutable textual content such as
textarea, even if this form control is in non mutable
state.]
Fonts 4
-------
- RESOLVED: Defer this issue (#528: May want different properties
for font matching and variation value) to next level.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jul/0032.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
Tantek Çelik
Emilio Cobos Álvarez
Dave Cramer
Elika Etemad
Tony Graham
Dael Jackson
Brian Kardell
Brad Kemper
Ian Kilpatrick
Myles Maxfield
Thierry Michel
Liam Quin
Florian Rivoal
Jen Simmons
Alan Stearns
Greg Whitworth
Zheng Xu
Fuqiao Xue
Regrets:
David Baron
Peter Linss
Manuel Rego Casasnovas
François Remy
Melanie Richards
Lea Verou
Scribe: dael
Administration
==============
Rossen: As usual I wanted to check if there are any additional
agenda items anyone wants to add or any changes.
Rossen: We'll remove item #5 as suggested by florian
Rossen: Anything else that we need to change?
myles: Might be valuable to discuss should initial letter be plural
along with should hyphenation-character be -characters?
Rossen: Can you find the issue?
myles: Yeah.
Rossen: Admin items:
Rossen: #1: Reminder to those going to TPAC, prices will go up soon.
Register early, book hotels early. Just a reminder.
Rossen: #2: As many of you have heard liam will be parting ways with
W3C end of the month. We have a new staff contact, Fuqiao Xue
xfq: Hi everyone my name is Fuqiao.
* xfq waves
xfq: I just joined the group and I'm very pleased to join. I've got
a lot to learn and will like to work with you.
<astearns> welcome, xfq
<dauwhe> welcome!
Rossen: Thank you xfq, we're excited to have you
<fantasai> +1
<florian> xfq, welcome! 欢迎!
<xfq> thanks all!
CSS Text
========
cursive shaping breaks needs better scoping
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/698
Rossen: Who wants this? fantasai?
fantasai: This was from F2F. Not sure there's anything to talk
about. Trying to figure out what to put. There was a lot
of pushback when first drew up text to not being specific
enough. There's a lot about shaping like Arabic doesn't
need a lot of assistance like more complex scripts
fantasai: Issues is because there's a certain amount of shaping you
can do across font changes. In terms of what edits need to
be made brings in a question as to how to handle other
aspects of glyph shaping.
fantasai: I don't know enough about this to figure out the issue.
There's a long thread. I'd appreciate help from someone
who knows more about this topic.
myles: I can take a look. I have some opinions but no proposal. I
can come up with something for next call
fantasai: That's all on this one. I need help.
Rossen: I'll get our fonts people to look and comment and ideally we
can resolve on github and put on agenda for resolution.
CSS Inline
==========
should `initial-letter` be plural?
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/862
<myles> https://github.com/w3c/csswg-drafts/issues/2809
Rossen: As myles pointed out there's another related issue ^
Rossen: hyphenated-character
fantasai: Slightly different issues, I think, in sense that
hyphenated-character is one character and if it's more
than one unicode code point it's one thing from user
prospective
<TabAtkins> (the word fantasai is searching for is "grapheme
cluster")
fantasai: From author prospective it's a character from what I've
heard of
Rossen: Let's do initial letter and then hyphen
fantasai: initial-letter was originally plural and we decided to do
that to make it clear that not only can you put multiple
characters but also because it can apply to not just
first-letter pseudo element but also the span which can
have >1 character
fantasai: Intent to plural was to make it more clear you can do that
fantasai: Reason it's an issue is because it's already shipping in
webkit
dauwhe: prefixed
fantasai: It becomes an issue about compat if we're going to change
name
<tantek> yes please keep it singular
dauwhe: This was an editing error in early spec stages. Probably 99%
of use cases will be a single letter so I'm relatively
agnostic.
<tantek> let's not design by edge-case
fantasai: I would change if even for single letter case it's a
property effecting multiple
fantasai: Problem is it's not just webkit shipped, it's that
documentation written uses current name.
<tantek> also consistent with :first-letter
<myles> initial-item?
fantasai: I don't think it's an edge case as that it's not as common
in English. Dutch it's more common to have multiple. We
have had requests for "what about first word" and you can
do that. That it says initial-letter guides people to
assume you can't
dauwhe: You can educate people, though.
florian: From my pov I have slight preference for plural, but given
slight compat issue I don't care strongly. I have another
issue is that it describes what it applies to, not what it
does. People keep thinking of this as a selector. In our
last F2F there were questions making it seem like a
selector. I don't have a good alternative, but I think this
name is a problem because it looks like selector
<tantek> agreed that it does sound like a selector
Rossen: Valid point. Do we have counter proposals? If we don't I
would prefer to take that discussion back to github.
florian: It could be drop-cap but it also does initial. I don't know
if there's a generic term for drop or raised caps
fantasai: There isn't really which is how we ended up with
initial-letter
florian: But I think that's the problem more than pluralization. I
don't think single or plural matters enough
myles: Not sure how much compat is relevant because it's prefixed.
But I think florian's point is right
<myles> dauwhe: will you open up the other issue?
<florian> Would "lettrine" work, or is that too obscure?
Rossen: We have options. Resolve the current issue and it seems most
people lean not plural. Then we continue discussion here or
separate as to if this is proper name.
jensimmons: I like the idea of thinking about another name. If we
can't think of one I do like switching to plural. I
don't think it's clear it would work on multi-letters. I
don't think it's compat issue because not many people
are using it.
fantasai: I don't think we have a web compat issue in terms of
content. Do you think there's a lot of documentation out
there?
jensimmons: No. I've been talking about it more than most in the
industry. I think it would be easy enough when it ships
for real to have a new round of education. The handful
of docs could update or they're ancient.
<gregwhitworth> +1 to what jensimmons - if we update MDN and caniuse
we'll be good
fantasai: Then I lead toward make the change and then look for a
less confusing word.
fantasai: because if even members of WG are confused as to if it's a
selector, we could hopefully do better.
dauwhe: I'm fine resolve for plural and hope for a new word
<tantek> how about take it github as Rossen suggested?
<dauwhe> tantek: I will open new issue for property name
Rossen: Objections to change the initial-letter value to
initial-letters?
RESOLVED: Change the initial-letter value to initial-letters
Rossen: Rest can go to github and if there's a proposal we can go to
the working group
Rossen: myles still do hyphenated character now?
myles: still relevant
CSS Text
========
hyphenate-character doesn't accept just a character
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2809
myles: It allows you to put in a whole string so hyphenate-character
seems disingenuous
fantasai: I think from user view it's a single character that goes
in there. hyphenate-string seems fine
fantasai: But I think we have impl shipping
<tantek> why *-letters vs *-string ?
<fantasai> tantek, because initial-letters doesn't take a string,
but this one does?
myles: We are one of those implementors. I was thinking you could go
other direction and have it accept a string and all grapheme
clusters except first get ignored
fantasai: Happy to have UA truncate appropriately. Not sure first
grapheme cluster is enough. There's CJK punctuation that's
>1 code point. If that's covered seems fine
myles: How about we don't have to specific details and have that as
a separate issue. We can say text is truncated to something
similar to a grapheme cluster
fantasai: At min include 1 grapheme cluster
fantasai: Other comments?
fantasai: Proposal: hyphenate-character keeps name, but UI may/can/
should truncate if it's more than one grapheme cluster
myles: Should be normative
florian: Decide how strict?
florian: If we're not sure may/can/should we should decide.
Rossen: Let's resolve on renaming property. We're saying no and add
normative text describe how UI are allowed to truncate
additional characters
Rossen: Objections?
<florian> I'd go with "required to truncate" rather than "allowed to
truncate"
RESOLVED: no to rename and add normative text desc how UI are
allowed to truncate additional characters
CSS Inline
==========
Initial letter, sizing, and overflow
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2703
fantasai: florian do we need to do anything on this?
florian: I don't think need to discuss now. Probably fine, I'll
re-read
Rossen: Resolve no change?
florian: Yeah and I'll re-open if I find something
RESOLVED: no change is needed
CSS Shapes
==========
Degenerate polygons with positive shape-margin
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2375
TabAtkins: The current shape spec has text about degenerate
polygons. It makes them not create a shape, text can
pierce through.
TabAtkins: It doesn't have a special case for a positive shape
margin where actual exclusion area is non-0. We should
amend the spec so things with positive shape margin are
treated as having a positive area
TabAtkins: Issue goes further that the ruling about degenerate
polygons is wrong and we should remove. SVG has similar
issue where if trying to stroke a path and size of box
for stroking is determined by fill rectangle. Can be 0
area and triggers special cases where it isn't stroked
and causes strange cases.
TabAtkins: Get similar issues where if animating polygon and if all
points line up you temporarily get entire layout to shift
as it no longer excludes. Issue argues we remove special
casing
TabAtkins: I looked at our code with iank and he supports it because
it's removing special case
TabAtkins: Only complication is you can have negative margins and it
can shrink spacing to 0. With degenerate rule you didn't
have to worry about where 0 is. AmeliaBR's suggestion
sounds reasonable at first glance to solve. It's
relatively corner case.
TabAtkins: Larger is should 0 area be an exclusion
TabAtkins: Chrome supports the change.
Rossen: Other perspective?
astearns: I support what's discussed in issue. Question: you can
have polygons with inverted areas, not just a line but
they're crossing and inverted area inside. If you have a
positive shape margin in that case does it have to
overcome the inverted space or do we define inverted space
to un-invert
<myles> what is inverted space
<myles> winding order?
TabAtkins: Good question, don't have best answer. Related to when
you over-deflate. Should a really big negative margin
cause positive shape. Should they
<tantek> there's a similar question / issue with negative outlines
fantasai: They don't. We won't change that.
TabAtkins: Why?
fantasai: Right now if you have a float with negative margin on both
sides that won't turn into a positive shape
TabAtkins: It's a shape-margin not a normal one.
fantasai: shape-margin is positive only?
TabAtkins: Nope
fantasai: I still think same principle should apply. Why can't you
create a rectangle with the same behavior as a float.
TabAtkins: There's a lot of difference with shape and shape-margin
so I don't know yet. I'm happy to figure it out as we go
along. Don't think we need to resolve to resolve this
issue
<tantek> regarding what astearns said about inverted areas, here is
another way we end up with inverted areas (and incompat)
https://github.com/w3c/csswg-drafts/issues/2892
astearns: Clarification: It sounded like polygons with just lines
and a positive shape margin will add their shape to
exclusion area. Also polygons that are just lines will
include line edge even without margins
TabAtkins: Correct
TabAtkins: There's a special case in our shape code and it skips by
it currently. We just remove that check.
astearns: I propose we take what's in the issue, put in spec, and
attempt to spec inverted areas and bring to group
iank: One other thing, I filed an issue, but there will be bugs if
we do just a paragraph. When we do this change I'd prefer we
define how a line-box intrudes into a float with a shape
outside and write out algorithm.
iank: Otherwise someone will do something slightly different and we
get compat bugs
iank: It's issue #2949
iank: I looked at Mozilla code and they have same concept in their
code
astearns: Thanks
Rossen: Going back to this issue
Rossen: Can we take the resolution proposed by TabAtkins?
astearns: I'm fine
TabAtkins: proposal: we take what's in the issue, put in spec, and
attempt to spec inverted areas and bring to group
Rossen: Objections?
astearns: Agree with issue and bring it into the spec to match
Rossen: Accept the changes as stated in the issue. Objections?
RESOLVED: Accept the changes as stated in the issue
CSS UI 4
========
Readonly form control and user-select
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/285
florian: Recap: across all browsers afaict when you have editable
text area regardless if form control or from
contenteditable. When you start selection inside it it
can't extend outside. Selection is trapped within
florian: This behavior is exposed in user-select as contain. Current
spec says on editable elements it always does contain.
Currently spec as editable content is mutable form controls
and contenteditable elements. Mozilla raised that read-only
form controls are not mutable so we should update spec
florian: Second part is once we do it for normally mutable but
currently unmutable switching to user-select: none might be
okay. Not clear how editing would work with selection
disabled and no one wants to do that.
florian: So making contain apply to normally mutable but not
currently mutable and then making contain switch to none
for those.
florian: Should I wordsmith that into spec or do people think I
missed something?
* tantek reviews the issue
Rossen: Opinions?
Rossen: Objections to accepting florian's proposal to the spec?
<tantek> I'd prefer to get Xidorn's opinion
Rossen: I think it's time to force progress since it's gone through
3 F2Fs.
<tantek> can we discuss in APAC call?
<tantek> otherwise I do not object
Rossen: tantek xidorn can add his opinion on github.
florian: We're resolving in favor of his opinion
tantek: I'm asking that...florian if that's true can you put that
into the issue? Just a back and forth to confirm. Why not
make sure. You've got wordsmithing, put it in the issue,
give xidorn a chance to say yes
florian: Can I put in PR and merge when he says okay?
tantek: Sure
RESOLVED: Accept florian's proposal
Rossen: Summary is form controls should be selectable?
florian: More complicated
florian: I'll create a PR with proposal and merge
Rossen: We'll look at your PR
Fonts 4
=======
May want different properties for font matching and variation value
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/528
myles: Right now for font variations the properties are partitioned.
Set A effects font selection and set B doesn't. A is
font-weight, font-style, font-stretch.
myles: You use value of those to find a font and if it has range of
values to which the requested width or slope is applied
myles: For those properties they both are used to choose fonts and
then they select a point in design space. Issue asks how to
separate concepts. I want to select a font-weight but not
have it effect font selected.
myles: There is a way, you can use font-weight properties to do
font-selection and after that you can use font-variation
settings of 'wght' and that separates the values. It's not
very clean, but it will work the way you want. It's just not
as nice
fantasai: If don't do that then...If you had a variable font and you
just want to use for all weights on page and you're using
3 weights then you would have to create a new @font-face
rule for each weight that's pegged to that value and map
that to a value on the variation axis
fantasai: That would work if you had fixed number of weights and you
knew what you would use.
fantasai: If you were animating weight that won't work because you
have no mapping for intermediate values
myles: font-face descriptor allows range
fantasai: Font variations doesn't. So if you have a font-weight
descriptor that's 400-800 and then set font variation
settings as a default of 500 then you've said this font
which is gonna be rendered at 500 always is the 400-800
range. If I ask for the 400 I get the 500 because it wins,
right?
myles: right
fantasai: You can't create the mapping...you can do it for a single
point but not a range
florian: I think a use case would help
florian: I think a typical thing is you're using your main font for
lots of things, but for '&'' you want a different font.
Non-variable you use unicode range to subset and you decide
that it looks good at a different size. With @font-face you
can do that. With variables you try and do the same thing
where the '&'' font is about 200 more weight than main font
you can't do that. You can lock it for specific values, but
not on range
florian: I think we want in the @font-face rule you can map a range
to another range. At font-selection if there's a font
between 500-700 I'm good and it corresponds to 700-900. Or
something along those lines
fantasai: Agree that's what needed to solve. Have a similar issue as
related to size. It's a bit easier because it's constant.
florian: I think the problem isn't too bad because you can slice per
linear range you can do it if you have mapping
fantasai: I think we should solve this, but defer to next level. not
super critical, but we do need to...people are shipping.
We should get set of features to ship and get the spec to
CR. I agree it's a problem and we should look to solve
myles: I'd like to hear from designers about the problems they're
trying to solve
fantasai: And defer would give time for that to happen
Rossen: myles okay to defer or did you want to hear now?
myles: defer is fine
florian: Okay to defer
Rossen: Objections to defer this issue to next level?
RESOLVED: Defer this issue to next level
Admin
=====
Rossen: myles any of the remaining topics we can do?
myles: Don't think we can do any remaining in 2 minutes
Rossen: Anything else that's 2 minutes?
Rossen: If not we can adorn.
Rossen: Then we're adjourned.
* liam waves bye as this is my last css call
Rossen: Next Wednesday is APAC time
Rossen: Thanks xfq for joining
Rossen: We'll chat in a week
Received on Wednesday, 25 July 2018 23:35:11 UTC