- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 1 May 2019 21:06:04 -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.
=========================================
Color Adjust
------------
- RESOLVED: FPWD for css-color-adjust
Selectors
---------
- RESOLVED: Generic selector grammar allows stacking pseudo elements
and classes. Only certain combos will be made valid, by
default everything is invalid (Issue #3876: Need to
allow stacked pseudo-element selectors in the grammar)
- RESOLVED: Close the issue (Issue #3754: What a whitespace
character is)
CSS Shapes
----------
- It was proposed to remove the padding-box and content-box values
from <shape-box> (Issue #3872) since they have extremely low use
counts and bad behavior with scrollbars.
- There were some use cases for the values, especially
content-box, but many of them relied upon interacting with
properties that haven't been implemented so discussion
mostly changed from removing completely to changing to Level
2 so the issues with scrollbars can be fixed.
- Since these values are already implemented and interoperable
except for scrollbar interaction, the group decided to open
a new issue to fix scrollbar behavior and keep the values.
- RESOLVED: No change on this issue (Issue #3872)
CSS Text
--------
- RESOLVED: Add this to the spec (Issue #3863: Styling of soft
hyphens)
- RESOLVED: Inline boundaries do not effect hyphenation, styled or
unstyled (Issue #3862: Impact of unstyled inlines on
hyphenation)
- Another issue will be opened to discussed if a general note should
be added about unstyled spans having no effect and, if so, where
that note should go and what is the exact text we should use.
- There were contrasting principles about what behavior to align to
when discussing issue #3440 (When to/not to include preserved
trailing spaces) and there wasn't enough time to reach consensus
on the call, so discussion will continue in github
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019May/0000.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Christian Biesinger
Oriol Brufau
Elika Etemad
Dael Jackson
Ian Kilpatrick
Chris Lilley
Peter Linss
Cameron McCormack
Florian Rivoal
Jen Simmons
Regrets:
Rachel Andrew
Daniel Bates
Tantek Çelik
Dave Cramer
Simon Fraser
Myles Maxfield
Melanie Richards
Alan Stearns
Scribe: dael
Color Adjust
============
color-adjust Call for FPWD
--------------------------
<Rossen> https://drafts.csswg.org/css-color-adjust-1/
Rossen: That is something we had resolution to put in a working draft
Rossen: It is now assembled as an ED on the drafts repo
Rossen: It has a shortname of css-color-adjust
<chris> +1 for FPWD
Rossen: Call is to go for a FPWD
<florian> +1 for FPWD
Rossen: Comments or objections?
RESOLVED: FPWD for css-color-adjust
Rossen: We have 4 people currently listed as editors
Rossen: I'll go ahead and prepare the spec for FPWD
Selectors
=========
Need to allow stacked pseudo-element selectors in the grammar
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3876
Rossen: Is TabAtkins on?
<@TabAtkins> Will be in a sec
fantasai: I can take it
<florian> I did not check that TabAtkins did the grammar correctly
(I assume he did), but I support the intent.
fantasai: There were some cases where we had pseudo elements that
are pseudo elements of pseudo elements. One is the marker
of a before pseudo if that's set as display:list-item
fantasai: Selectors grammar only allows one pseudo element in the
grammar. We'll have to relax to allow this. Proposal is do
it same as pseudo classes applied to pseudo elements. It's
generically allow, but disallowed except for certain
allow-listed combinations
fantasai: The generic grammar needs to allow for the stacking.
Proposal here is to do that for pseudo elements so one can
allow another to stack after
amelia: Really a need to make the allow-list or defined at
individual level? It could be a valid that doesn't match
anything. Example is invalid that doesn't match non-form
elements anyway and wouldn't when on a before or after.
fantasai: Reason to do is because at some point in future might
allow some combos, but not sure which will become
reasonable. Better to make them invalid now and only the
ones that make sense now are valid. When another combo is
reasonable in the future we can say it's now valid and
means something.
fantasai: Don't want a selector that's valid now but matches nothing
but 5 years from now it starts matching a bunch of stuff
Rossen: Sounds reasonable
Rossen: Other points?
<dbaron> sounds reasonable to me too, though I'm not sure I could
extract all that from the issue
Rossen: +1 to dbaron comment. Thanks for making it clear fantasai
Rossen: Objections to accepting the issue?
fantasai: Proposal: Generic selector grammar allows stacking pseudo
elements and classes. Only certain combos will be made
valid, by default everything is invalid
Rossen: Objections?
RESOLVED: Generic selector grammar allows stacking pseudo elements
and classes. Only certain combos will be made valid, by
default everything is invalid
CSS Shapes
==========
Remove padding-box, content-box values from <shape-box>
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3872
iank: As I was redoing parts of shapes impl for our layout engine I
noticed something that bugged me. I put in use counters.
Padding-box and content-box as values on shape outside is
weird. If you have scrollable content inside it won't respect
scrollbars. Not a strong use case for these values
iank: Use counter was basically 0.
iank: Given all this, to simplify can we remove?
Rossen: Move to L2 or at all?
iank: Just remove it. I don't know there are strong use cases for
these values. Be interested if there are.
amelia: Mentioned a few use cases in a comment earlier today. It's
matching up shapes with either actual content image of an
element. shape-outside can be defined using an image and you
use it to match actual content image and you need them to
align to correct layout box
amelia: Also aligning...shape-outside shapes with clip-path shapes
functions. One issue there is Chrome and possibly WK don't
support shape boxes on clip-path and default is border-box
so if people are using a combo they're almost automatically
using border box. That might effect use counter more than
anything else.
amelia: Other is matching with background images that can be aligned
to many other boxes. Definitely use cases, but need to deal
with...there's inside boxes and outside boxes when talking
about scroll and that doesn't seem thought of in the spec
amelia: Something needs to change in the spec. I don't think
deleting is best because then have to deal with that that
set of boxes is used in a lot of graphic properties. Also
clip-path and shape-inside in the future.
amelia: Getting rid of it all together will probably cause problems
with consistency to other properties
iank: Doesn't sound like...we haven't shipped padding box for clip
path
amelia: no
iank: My primary issue is no one has thought about scrollable boxes.
It's also weird for engine caching, this reaches inside
internals of the box.
fantasai: I think for dealing with scrollable boxes you would want
to, for clip-path as well, only thing that would make
sense is inset it by border edge by amount of border and
padding width. Can't draw it around scrollable area
amelia: That's one option. Makes perfect sense. Figure out what
padding box would be working from existing box.
amelia: Other option is for scrolling boxes only you make at used
value time these values get re-written but still allow
content-box and border-box to work on non-scrollers. I like
fantasai's suggestion better
fantasai: As we switch to incorporate padding into scrollable [gives
example]
iank: Other thing to keep in mind for boxes with scrollers you've
got to account for where scrollbars are with is a potential
world of pain
iank: I don't care where we fall on this issue. 9 months ago I found
this weird, hence use counters
fantasai: If we hadn't impl it would make sense to drop. Since they
are impl I'm ambivalent
iank: Impl but no usage. I can drop based on that.
amelia: Willing to accept this. Going back to Rossen question is
make them invalid for now and defer to L2 where people can
look more carefully about how should impl. If we've got
something not impl consistently and we don't agree how and
it's not used a lot we should take it out. I don't want to
resolve to never support
jensimmons: Do we know if we have interop and complete impl or a
lack of interop and confusion what it should be
iank: Based on amount of WPT there's good interop. Good between
Blink and WK because of heritage. Good with FF based on WPT.
amelia: On the things you want to remove?
iank: Yes. There's well tested I believe. I can check. But that said
they have 0 usage
amelia: But if we've got clear interop why is issue to get rid of
it? You don't like behavior standardize on?
iank: Yeah. Behavior is weird for scrollers
amelia: Wrapping around area overflowing the box? I don't have any
pictures...
iank: Make simple impl, apply to scroller and that's what you get.
Rossen: Going back to original motivation to add them was
completeness and symmetry with other properties. That's what
motivated us to add them in
Rossen: Given there's no uptake on the values and a reason to remove
from a given impl. In terms of being safe to unship it
sounds okay. Technical PoV sounds like we can unship with no
negative effect on content.
Rossen: Question is are we completely uninterested or are we saying
we don't know enough but might have reasons to work on it
and we push to L2
Rossen: Where on this spectrum are we? Push to L2 and worry later?
Or no use cases and let's move on.
fantasai: amelia's point that some things it would work with aren't
shipped yet means we won't know potential usage accurately
until those are widespread
Rossen: Push to L2
fantasai: If we have interop and spec and impl there's no reason to
move to L2 because it would pass REC. If we didn't have
impl it would make sense to drop
Rossen: Sounds like one impl will unship so we won't reach rec
without having another impl
florian: Don't we have 3?
Rossen: 2 only
amelia: WK and Chromium aren't independent is the issue?
iank: Correct
amelia: Agree playing with the demo what's happening is not good
behavior. If we leave as a valid value we'd want to spec and
define better behavior. Considering status of spec I don't
think that can really happen in timelines we want.
Rossen: Yeah
florian: Suggestion is push to L2 with an issue saying there is
interop but we want to change?
Rossen: If it is unshipped from blink there's no interop
amelia: FF and Chrome aren't identical. Both bad, but not interop
Rossen: Let's see if we can resolve. Objections to move these
properties out of L1 and into L2 and add a note about the
interop problem?
dbaron: What does that imply impl should do?
florian: rediscuss how it should work before usage and then fix it
Rossen: In short term blink is looking into removing their impl. In
long term spend more time thinking about how should work in
conjunction with scrolling, overflow, etc.
amelia: One thing, if we change definition there will be
dependencies beyond this one property.
amelia: Just practical for whoever does edits
amelia: We've got a shape-box type that's equal to set of keywords.
Used in more than this one property
Rossen: Right
jensimmons: For me...I'm not hearing that a browser needs to unship
this in order to get through re-engineering of platform.
Not hearing a compelling reason to remove. As a person
that's taught about this property adjusting the
shape-box property is the last thing people think about
or learn. Switching from border-box to margin-box makes
sense, but makes me nervous to unship.
jensimmons: That people aren't using it doesn't convince me because
I think people have not dug into it. I haven't thought
of use cases, but makes me nervous
TabAtkins: Shouldn't fall pray to status quo fallacy. Since no one
has come up with reasonable reason to have it in, it's
weakly supported at best
dbaron: Sounds like reason to remove isn't that it's complicated,
but it's not useful.
dbaron: Could argue using it on a thing with scrollbars is a bad
idea. Then it's not that bad that it has weird results.
Clipping a scrollbar is probably not what you wanted.
Question is are there use cases for non-scrollbar
amelia: That's what I brought up. There are use cases. Simplest
solution from spec is add a warning that using content-box
or padding-box on an element with scrollbars has undefined
behavior. It's a warning to authors you'll get weird stuff.
In non-scrollbar case we've got clear interop. But for the
intersection of properties adding a warning behavior is
undefined might be quick
TabAtkins: Officially undefined is something we try not to use. All
it means is we hope to revisit once web compat has frozen.
TabAtkins: No one has brought up use cases and I can't think of when
I'd want text outside to flow into a box past a border
fantasai: We see this frequently with first letter shapes. You can
have a light color bg and want text to flow over and wrap
shape of letter. This kind of design does happen
jensimmons: And a lot of ability to overlap with negative margin.
You can't do that here.
fantasai: I don't see use case for padding-box, but for content-box
you have that
iank: In the wild when people want that they reach for insets to
modify
fantasai: If you want to take an image, cut into a circle. You don't
want to have to do an inset of your border and padding
when you can just say make the circle that covers the
content box. Less repeating yourself, less complications.
That's what these keywords are for. If want to cut image
to a circle, then want text wrap in a circle
TabAtkins: And also have the image have a border and have text
overlap that border?
fantasai: Might not be a circle so yeah. I think it's not the common
case, but I don't think it's totally crazy
jensimmons: Interesting question to ask now. If we asked a year ago
when there's one impl and the question at the time is
this is complicated. But we just shipped it all and
we've got interop except the corner case of scrollbars,
why remove it now? Only reason I'm hearing is it would
make things feel better for those reading the code so
you don't have to drag around extra code. I get that as
an engineer, but not compelling to change a spec
TabAtkins: Trying to ignore scrollbar doesn't work, we still need
interop. People will have to add code to handle it. It's
not a matter of leave it alone, someone will have to pay
additional cost to get it right. Then there's the non-0
maintenance for a feature we're not going to use and
doesn't have a realistic use case
fantasai: We've spent a lot of time talking about removing a feature
that's mostly interop. I'm inclined to leave things along
with no change
<dbaron> +1 to spending time on other things
Rossen: Also a valid option
Rossen: iank would you be okay no change for now?
iank: Fine. No work for me now, this is for someone down the line
with scrollers.
Rossen: Objections to no change on this issue?
amelia: Can we leave an issue about scrollbar case?
Rossen: We can
RESOLVED: no change on this issue
CSS Text
========
Styling of soft hyphens
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/3863
florian: Trying to write tests around this. Spec wasn't clear how
the soft hyphens are styled. Does a span change the color
of the hyphen? Spec is silent. Impl are interop where if
line isn't breaking you style span as an empty span. When
line does hyphenate it behaves as if span was around
actual hyphenation character. Makes sense, has interop,
like to spec
fantasai: Happy to add as clarification. I'm pretty sure that
codepoint represents visible glyph. Can't lookup unicode
right now
florian: I think it says you may want to tailor to language. There's
some level of smart to what you insert. Not clear it falls
out. but if we clarify this is what we want doesn't matter
to me
Rossen: Other opinions?
TabAtkins: Agree completely
Rossen: Objections?
RESOLVED: Add this to the spec
Impact of unstyled inlines on hyphenation
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3862
florian: While playing with tests I noticed inconsistency in Chrome
behavior. If you put unstyled spans on parts of the word,
it causes Chrome to suppress hyphen. Have a general
principle unstyled spans don't do anything, but call it out
where it matters.
florian: I don't think it's good a span around part of a word
changes what the word is. We have similar notes for text
transforms what a span doesn't change
iank: Test case?
florian: Yes
iank: Put one in IRC?
<florian> https://github.com/web-platform-tests/wpt/pull/16428
florian: Yes ^
florian: All test cases in the PR are about that. I don't remember
which version does what, but the superset of Chrome breaks
some cases
fantasai: Agree we should spec. Might also be worth putting that
unstyled spans do not effect any stuff in CSS Text into
this spec.
florian: Good too
heycam: What's the definition of style here?
fantasai: Any span that's inline, not inline block, even if styled
has no effect. Principle of unstyled spans if you have 0
properties on a span and just put it in almost no where in
CSS does that cause a difference in rendering. One
exception is text-combine due to impl difficulties.
fantasai: General principle and then once styles on span it depends
on the properties. It can no longer be a blanket rule
fantasai: CSS text it can be a styled span should not effect line
breaking
Rossen: Hearing general consensus
Rossen: Objections?
fantasai: Prop: Inline boundaries do not effect hyphenation, styled
or unstyled
fantasai: Second is do we want to note general principle about
unstyled in this spec or another or just a principle we
don't define. Mostly it's a note for spec authors to write
so unstyled span has no effect on styling
florian: In a display spec?
Rossen: Not sure
florian: It's where we define inline. There we say and if it's not
otherwise styled and no exception it has no effect.
fantasai: Good to put that for inline and blocks too
florian: fantasai I think this is good to nail down. Specific
wording maybe need more thoughts so open a new issue?
fantasai: Let's get a new issue for generic one and close this for
styled and unstyled spans
Rossen: Objections to Inline boundaries do not effect hyphenation,
styled or unstyled?
RESOLVED: Inline boundaries do not effect hyphenation, styled or
unstyled
Rossen: Please open an additional issue
Selectors (continued)
======================
What a whitespace character is
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3754
florian: Filed against text, but it's a selectors issue. But I'm not
editor. I think we can close though. Old definition of
common blank is it contains only whitespace. We no longer
rely on whitespace so I think this is a non-issue.
TabAtkins: Yeah, close
Rossen: Other opinions?
Rossen: Objections to close the issue
RESOLVED: Close the issue
CSS Text (continued)
====================
When to/not to include preserved trailing spaces
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3440
florian: Before concluded whitespaces at the end of a line for
whitespace pre-wrap force hang. But spaces before forced
break wouldn't hang.
florian: Based on issue fantasai proposed in order to make them
count to max content, but definition of hanging doesn't say
if they count or not.
florian: Then again spaces before a forced break also shouldn't
count to min content
florian: If you look at interop browsers don't treat spaces before a
forced break differently
florian: I think we should say they hang regardless of forced or
soft wrap, but say they count toward max-content size.
florian: Also clarify if hanging punctuation counts or not. Implied
maybe, but hanging on intrinsic size isn't explicit
fantasai: [reads spec]
<fantasai> https://www.w3.org/TR/css-text-3/#hang
florian: Doesn't say for intrinsic. For min talked explicitly, but
for max it's fuzzy. In punctuation case...it's saying a
bunch of things and you can figure out what they probably
mean but it doesn't say it explicitly. Especially given
tests aren't clear there's interop so clarifying is good
florian: I proposed we clarify toward don't count regardless of it's
min or max. Space we don't count for min and do for max. I
think that matches rough interop
fantasai: If we include it in max content size but then subsequently
align to the right the max content no longer fits the
content. This is why we want to be consistent if it's
counter for alignment max content and justification. Need
same answer or otherwise weird
florian: Also quite weird with non-intrinsic size. You've got
whitespace at the end of lots of lines. All except last
align to the right. That's also weird.
fantasai: Yeeah. But in other cases you're wrapping. Whitespace at
wrap you expect to disappear. Whitespace before a break
you didn't have to put it there.
fantasai: If behavior makes more or less sense depends on if content
is wrapping or not. Nice if right/left/center align is
consistent and encased in max-content
fantasai: No great answer here. Having max-content and align have
different answers on a single line doesn't make sense
florian: If koji's test is still accurate everyone includes spaces
for max and most but not all include for right align.
Webkit and blink don't include for justification so they do
that differently then alignment
florian: Last time around we resolved to align with WK and Blink for
justification and apply that to right align so never
include the spaces.
florian: It's weird anyway. I have tests to match previous, I just
think it's weird.
Rossen: We're overtime
Rossen: I don't feel we're ready to resolve.
florian: I think we forced last time and that's part of problem
Rossen: Table discussion back to github. For those interested,
continue there and we'll resume next week
florian: Please look, what we have is well defined, but I'm not sure
it's good.
Rossen: Let's wrap up today. Thank you everyone, next week back to
west coast US time. Thank you for calling in.
Received on Thursday, 2 May 2019 01:06:56 UTC