- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 29 Aug 2018 15:38:36 -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 Fonts 4
-----------
- RESOLVED: Have computed value always be a percentage and have
serialization always show a percentage [for
font-stretch]. Neither deal with keywords (Issue #1671)
CSS Alignment
-------------
- RESOLVED: Take this approach [github:
https://github.com/w3c/csswg-drafts/issues/1425#issuecomment-413375688
]
and file separate issues for wording issues
- RESOLVED: Static position alignment keys off of justify-self on
the abspos, not justify-content on the static position
CB (Issue #1432)
- RESOLVED: Publish updated WD for CSS Align
CSS Fragmentation
-----------------
- RESOLVED: Have 0 sized fragments pushed to next fragmentainer if
content before has overflows its fragmentainer (Issue
#1529)
CSS Contain
-----------
- RESOLVED: Accept change in
https://github.com/w3c/csswg-drafts/issues/3023#issuecomment-415885325
to clarify ink overflow bit only applies to visible,
clip or a combination
- RESOLVED: Close with an explanation note in the spec and no change
['contain-size' will continue to apply to
display:table-caption] (Issue #2952)
Selectors
---------
- RESOLVED: Accept the proposed change [anything with ::-webkit-*
prefix is valid at parse time] and add a note to the
spec explaining why this was necessary to add for web
compat reasons. (Issue #3051)
===== FULL MINUTES BELOW =======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Aug/0029.html
Present:
Rossen Atanasov
Tab Atkins
David Baron
Garrett Berg
Tantek Çelik
Emilio Cobos Álvarez
Dave Cramer
Alex Critchfield
Benjamin De Cock
Tony Graham
Dael Jackson
Brian Kardell
Brad Kemper
Chris Lilley
Peter Linss
Myles Maxfield
Nigel Megitt
Thierry Michel
Melanie Richards
Florian Rivoal
Alan Stearns
Lea Verou
Sean Voisen
Fuqiao Xue
Regrets:
Rachel Andrew
Jen Simmons
Jeff Xu
Scribe: dael
astearns: Anything extra to add or change?
CSS Fonts 4
===========
Computed value for shorthand font: should describe serialization for
font-variant-css21 and font-stretch-css3
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1671#issuecomment-400863224
myles: There's...the issue here recently has migrated. The thing
discussed now is the font-stretch
myles: In L3 font-stretch took keywords. In L4 they're percent
number so you can animate. That's for variable fonts.
myles: Issue is about how the computed style of this property should
be a number of percent rather then keyword or a number
myles: If you're trying to animated from 'condensed' to 139% if
computed is percent or keyword you can't animate. Solution is
always a number and getComputedStyle() function returns
strings if the computed style is a magic number we define
<florian> the explanation did make sense
astearns: Are magic number specified or implementation dependent?
myles: There's a table
<chris> its the magic numbers that correspond to the keywords
myles: Not much of an issue, it's do you want to animate from
keyword to number. If yes, and I think it's yes, we need
backwards compat
florian: Makes total sense to me
<chris> +1 this seems good to me
astearns: me too
emilio: Serialize as number?
myles: We're discussing now if computed style of font-stretch should
be a number or as specified.
emilio: Gecko and blink ship as number so web compat not problem.
myles: Backwards compat concern is getComputedStyle(). If you set
font-stretch to a value that used to be a keyword do you get
number or keyword
emilio: Number.
chris: It's serialization of getComputedStyle() and I think there's
web compat concern on that.
myles: I guess there isn't much web compat risk if blink and gecko
give number.
florian: We can start with that and if there is web compat revisit.
astearns: Perhaps a note in the draft saying may be web compat with
always serialize as number and may need magic conversion
at some point.
florian: Reasonable.
<fremy> +1
astearns: Anyone with evidence that we need magic number to string
conversion in getComputedStyle()?
astearns: Proposal: Have computed value always be a percentage and
have serialization always show a percentage. Neither deal
with keywords
astearns: Objections?
RESOLVED: Have computed value always be a percentage and have
serialization always show a percentage. Neither deal with
keywords
CSS Alignment
=============
Fully specify the "Overflow and Scroll Positions" section
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1425#issuecomment-413375688
astearns: fantasai and TabAtkins made edits. Are you asking for
dbaron approval?
fantasai: It looks like we discussed but didn't resolve. Need to
resolve and get dbaron review
fantasai: We were trying to spec the behavior of the content
alignment properties on scroll containers. Content
alignment when applied to element it adjusts content
inside it
fantasai: dbaron asked to tighten. We noticed what we were doing
fundamentally for a scroll container instead of align by
layout and then clipping the alignment instead you're
doing safe alignment and then scroll so you get effected
alignment
fantasai: If you said align-content:end and the content overflows we
start align and then scroll container so you get same
effect as if not a scroll container
fantasai: Tricky thing is scrollable overflow doesn't include
padding at bottom. Well, might or might not depending on
UA...open issue on overflow 3. When you scroll to the end
the bottom of the visible content that overflows lines up
with the padding edge of scroll container. Needs to be
content edge for proper behavior.
fantasai: To get that alignment effect we're going for so switch
between scrollable and not alignment is same we had to
spec we extend scrollable overflow area by that amount of
padding. We extend from edge of inflow content
fantasai: Authors have asked us to add this.
fantasai: We have a 'normal' value for alignment that lets us do
whatever weird things needed for compat. We trigger this
extra space for scrollable overflow when you have a not
normal value of align or justify content. That's new in
spec because didn't look at implications of padding
fantasai: Asking WG if this is okay and ask for review
fantasai: Questions or need explanation?
astearns: Little weird we trigger this on non-normal but I see why
it's necessary
astearns: dbaron comments? Want more time?
dbaron: Need more time to review.
astearns: Fair enough.
astearns: Other comments?
fremy: Like the global idea. Haven't checked details.
fantasai: Resolve on global idea and check wording later?
fantasai: Then we have WG resolved this is behavior we want.
Problems with wording can file a specific issue
florian: If we could do away with odd compat it would be great. Not
realistic. This approach does seem to work all but a bit
strangely.
florian: Can't think of anything simpler that works and respects
compat
astearns: Objections to resolve to take this approach and filed
separate issues for wording issues?
RESOLVED: Take this approach and file separate issues for wording
issues
<fantasai> issue about including padding in scrollable overflow area
-- 12 upvotes, more than pretty much any other issue I've
seen, + 18 on a comment further down the line supporting
it https://github.com/w3c/csswg-drafts/issues/129
CSS Fragmentation
=================
Empty fragment at fragmentainer boundary
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1529#issuecomment-415592931
fantasai: I added text to spec but realized we said a 0 size
fragment stays with previous page. Doesn't seem to be
always because if whatever came before overflows
fragmentainer.
fantasai: If I've got an unbreakable box that overflows and a 0
height after it moves to the next column.
fantasai: Wanted to check that's what we want.
fantasai: If anyone wants to look more.
astearns: Makes sense to me. In your note say can be pushed. Perhaps
must be pushed?
fantasai: Makes sense. Change from can to will
astearns: Okay
bradk: Should it still be pushed if not content after 0 height thing?
fantasai: Yeah
bradk: Create a new column with nothing in it
fantasai: Might have something in it.
bradk: That's a useful thing?
fantasai: It is what happens currently. If something is visible
generally don't want it below fragmentainer height.
bradk: Alright, you've convinced me
astearns: Other concerns?
<Rossen> Are we still preserving the model of minimizing the number
of empty boxes due to 0 size fragments
astearns: Rossen on IRC asks [reads]
astearns: I think that's restating bradk concern...
fantasai: We're not. Making sure no element starts below end of
fragmentainer. Which is good because sometimes can't see
below end of fragmentainer it gets clipped
<astearns> Rossen, OK with that?
<fantasai> see also Tab's note about how this is how Flexbox works
already
<Rossen> OK, that's fine. My question was - once an element is to be
positioned (margins are consumed) and is 0 size - it gets
placed on the current fragment right?
<fantasai> If we haven't already overflowed the current
fragmentainer, yes
<fantasai> If we've already overflowed, no, it moves to the next one
<Rossen> OK, that makes more sense, thanks
astearns: Any other questions or concerns?
astearns: Objections to have 0 sized fragments pushed to next
fragmentainer if content before has overflows its
fragmentainer?
RESOLVED: Have 0 sized fragments pushed to next fragmentainer if
content before has overflows its fragmentainer
CSS Contain
===========
Clarify spec text about contain:layout so that its ink-overflow
effect on a scrollable element is clearer
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3023#issuecomment-415885325
florian: I think this is sort of an editorial mistake. Makes a
normative difference.
florian: Layout containment when on spec says overflow is treated as
ink. Meant if overflow is visible it's treated as ink so if
content escapes it doesn't trigger scrollbars on an
ancestor. But if there is scroll we don't have a problem
triggering scroll so if all is ink we never get scrollbars
florian: I think this is clarifying, but it is affectively a
normative change. Are we okay with it?
astearns: Concerns?
dbaron: Think I'm okay. Gecko implemented what it said now so we'd
have to change.
florian: He's [the Gecko implementor] the one that raised it with a
comment that what Chrome does is more useful
florian: Some tests will need fixing too, but I'll do that.
astearns: Objections?
RESOLVED: Accept change in
https://github.com/w3c/csswg-drafts/issues/3023#issuecomment-415885325
to clarify ink overflow bit only applies to visible, clip
or a combination
Maybe 'contain-size' shouldn't apply to display:table-caption?
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2952#issuecomment-415890334
florian: This was raised by dbaron because size containment is
described as not applying to table parts. Table-caption is
not a table part. It is intentional.
florian: Table cells and the like need no size containment because
general table layout you can't make it smaller than inflow
content. Trying to do so through containment wouldn't work
unless we define how it works in terms of layout.
Table-captions do not have that limitation. No strong
reason for it to have size containment not work
florian: Therefore I propose close no change.
astearns: Even if your reasoning is accepted I think there should be
a note.
florian: Perfectly reasonable, yes. Thanks.
astearns: dbaron does it make sense to you?
dbaron: I guess...I'm still not convinced table-captions are that
different in characteristics that matter
florian: If you take a table cell with some content with width:0 it
won't have a 0 width. For a caption it will. That's what
matters here
dbaron: Table cell with div inside div can be 0.
florian: On table cell yes
dbaron: Interesting thing is how sizes interact rather than how
sizes interact with content
florian: Size containment changes how you find the size. How it
influences things around doesn't change.
dbaron: In both cases you compute the size in a larger process.
You're saying contain size means contents don't influence
size.
florian: Yes, you size as if empty, then layout content without
changing that resolved size.
florian: It is an undefined operation on table cells, defined on
table-captions.
dbaron: I'm okay with that.
astearns: Objections to close with an explanation note in the spec
and no change?
RESOLVED: Close with an explanation note in the spec and no change
CSS Alignment
=============
Rules for align/justify-self on static position of
absolutely-positioned boxes need more detail
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-415854208
fantasai: This is a discussion we're hoping to close with 1429
fantasai: We made a mistake when figuring out effect of alignment
property on static position. In css2.1 there are rules in
static position as to which edge you care about. Keys off
direction of static position containing block of abspos
element.
fantasai: Since the point of alignment is to replace this model what
we do for in flow elements we use justify-self to
determine which side to align to rather then direction
property of containing block
fantasai: Initial value being start does do that
fantasai: For abspos elements we presented rules for how to behave
and to key off justify-content. Should have been
justify-self on abspos element
fantasai: Want to resolve to make that clear.
fantasai: Proposal: Static position alignment keys off of
justify-self on the abspos, not justify-content on the
static position CB
astearns: Concerns? Questions?
astearns: Anyone need time or shall we resolve?
astearns: Objections to static position alignment keys off of
justify-self on the abspos, not justify-content on the
static position CB
RESOLVED: Static position alignment keys off of justify-self on the
abspos, not justify-content on the static position CB
astearns: There have been quite a few edits. Good for people to
review.
Publication
-----------
fantasai: We'd like to publish updated WD. I understand some people
want time to review so happy to hold until people review
fantasai: This resolution [of issue #1432] also closes #1429
fantasai: Summary- 1429 is now answered yes. The model is that you
place the element...you take static position offsets and
use the space between static position containing block
edge and abspos containing block edge. Set of edges is
based on justify property
<fantasai> https://drafts.csswg.org/css-align-3/#abspos-sizing
fantasai: That's where you size into. Sizing and alignment match up.
fantasai: Normal WD. Want to publish update. If anyone wants to
review first, fine. Later is also fine.
fantasai: This'll bring TR WD in line with recent resolutions
astearns: Would anyone like time to review before publish?
<dbaron> I'm fine with publishing a new WD and then reviewing later.
astearns: Objections to publish updated WD for CSS Align
RESOLVED: Publish updated WD for CSS Align
Selectors
=========
Specify the "all ::-webkit-* pseudos are valid" behavior
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3051
TabAtkins: For a long time webkit based browsers had a quirk where
they accept any pseudo element with ::-webkit-* at parse
time. Won't match, but it's a valid selector.
TabAtkins: Firefox found this is causing compat problems for them
because people had used webkit pseudos in the past to
select browsers. Firefox realized they had to match the
rules because people doing browser selection.
TabAtkins: Proposed we spec that quirk that anything with
::-webkit-* prefix is valid at parse time
TabAtkins: Put that in an appendix of required but obsolete things.
<TabAtkins> https://drafts.csswg.org/selectors-4/#compat
emilio: For what it's worth I think most of this isn't even
intentional. They do ::-webkit-scrollbar something that they
intend to work and it doesn't in Firefox.
emilio: If someone knows why webkit has this I'd be curious to know
TabAtkins: I suspect it was dumb early parsing code and now we can't
remove. If it looks like one of our pseudos let it be
valid.
florian: Maybe also because there's a bunch of webkit pseudos that
only exist on some elements. Maybe checking if valid
sometimes was too complex.
TabAtkins: No, validity of selector can't depend on anything in DOM
florian: Right, because you can't person didn't want to check
anything because can't check some valid.
dbaron: I think in the past unknown pseudos were just accepted.
Might have been incomplete fix for that.
plinss: True.
plinss: That was why double colon was to allow user defined pseudo
elements for templating system.
TabAtkins: Regardless of history, it's here. Appears to be necessary
for compat. Need to spec.
florian: ::-webkit-*-whatever is an ident or start functional
notation there?
TabAtkins: No idea. I think start functional notation, have to check.
emilio: Doesn't work with functional stuff. In Firefox we only do
identifiers
florian: Okay, good. Less insanity is better.
TabAtkins: Confirmed. Just ident. I'll have to clarify spec text on
that
astearns: Concerns with this change?
astearns: Anyone against it?
tantek: I'm not against doing it.
tantek: In light of unproductive comment on github, might be worth
doing a blog post from chairs about this. Seems like a big
compat thing to put out there.
tantek: I figure it's indicative of emotional output. Rather than
people discover it and think we're doing crazy stuff an
upfront blog post might defuse it. Say this sucks but here's
why we have to do it.
astearns: We can put a post on CSSWG blog.
astearns: I'll wait until TabAtkins does clarification
astearns: Other concerns about this?
<dbaron> It might make more sense to put something clarifying in the
issue itself rather than having it prominently in the blog?
astearns: dbaron you're concerned about a blog post because you'd
rather not call attention?
dbaron: Don't know if it's worth making that big of a deal. Don't
feel strong
fantasai: Agree not make a big deal. If direct concerns we can put
comments in issue or add expository notes in the section.
People don't need to know about this in general and I
don't want to take attention from things that matter. A
blog post might get in front of some people but it's more
likely to make more people mad because they know and a
vast majority of people that don't care just read a blog
post
florian: I suggest FAQ of wiki with an entry of why did you spec
this and web compat with details
tantek: It's perceived differently if we do this. They'll appreciate
if we're up front. Much worse if someone says look at this
crap and puts it on reddit. I agree more people will learn
in passing but seeing it from WG it's just ho-hum as opposed
to a 3rd party in another context with exaggeration.
tantek: Hiding or not bringing something up causes things to blow up
fantasai: With webkit prefix we had a blog post. It blew up before
we could post. Secondly a blog post puts the explanation
in a separate place. If you want in front of people you
put in spec.
tantek: Spec bigger is worse.
<bkardell_> is it not reasonable to do both?
astearns: I'm convinced by argument that explanation will be in
spec. You're concerned people will stumble across this and
make a big deal. People will stumble across spec and blog
is somewhere else.
tantek: I'm okay with the FAQ having a long explanation and link to
that on blog and spec. Don't like polluting spec with
historical drama. Not what they're for
fantasai: Don't think it's complex enough for that much text
fremy: Not sure it's worthy of a blog post. It's minor. I'm pretty
sure Edge has this already and no one said anything. This is
weird and no one should use it. Not worth calling attention.
Few are using.
<fantasai> +1 to fremy
astearns: Concern about spec bigger I don't think is founded. I'm a
fan of bigger specs with reason why decisions get in.
<dauwhe> +1 to astearns
TabAtkins: Also why we have stying support for details class=note so
you can add lots of details without space
<TabAtkins> Spec is updated
<TabAtkins> I also folded in a clarification about how to serialize
them, since annevk brought up that it was technically
undefined.
bradk: Blog would get it in front of eyes to get feedback.
astearns: Don't think we're looking for feedback. There's a known
compat problems. Fixing because we need to do it - not
because it's good.
fremy: It's a terrible idea. I don't want people to know this exists.
bradk: There's probably people using it as a hack. Curious how big
of a problem that will be.
* bkardell_ kind of agrees that proactive seems better.. I'm not
even sure it has to be official csswg, just a member who
writes a post we all share is probably ok?
<TabAtkins> I'm happy to write a quick explanatory note into the
spec.
tantek: astearns I leave it to your judgment. Still think it's a
good idea to put something out. If you don't think necessary
I trust your judgment
astearns: TabAtkins has been mentioning changes. TabAtkins I would
like a note in the spec explaining and apologizing why
it's there.
TabAtkins: Spec is live now, writing explanatory note
astearns: Objections to change?
RESOLVED: Accept the proposed change
astearns: Thanks everyone for calling in. We'll talk next week on
APAC time
Received on Wednesday, 29 August 2018 19:39:30 UTC