Dael Jackson
2018-06-08 00:13:37 UTC
=========================================
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 UI 4
--------
- RESOLVED: Accept the suggestion in the issue plus a prefix for
unless otherwise specified. Edits to be added UI 4
(Issue #2664)
CSS Align
---------
- RESOLVED: Accept proposal in
https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-392854468
[Proposal text:
- If justify-content on the static position containing block
is start, use the start edge of the static position
containing block and the end edge of the actual containing
block (as CSS2.1 requires).
- If justify-content on the static position containing block
is end, use the start edge of the actual containing block
and the end edge of the static position containing block.
- If justify-content on the static position containing block
is center, use the start edge and end edges of the static
position containing block.
]
Values & Units
--------------
- RESOLVED: Allow calc to handle negative 0s (Issue #545)
CSS Display
-----------
- RESOLVED: Close this issue (Issue #2546) by adding a note
mentioning the difference between line box and other
boxes.
CSS Variables
-------------
- RESOLVED: Reserve "--" for future use and it is not a valid custom
property name. (Issue #2692)
CSS 2.2
-------
- dbaron created a proposal
(https://dbaron.org/css/test/2018/stacking-context-z-order )
for issue #2717 (anything that creates a stacking context should
sort in the positioned descendants z-ordering list ). The
working group needed time to review and will discuss again
during a future meeting (perhaps the next F2F).
CSS Nesting
-----------
- No one was objecting to the purely syntactic nesting proposal
TabAtkins had written (http://tabatkins.github.io/specs/css-nesting/ )
however the call was running out of time so the group will
revisit next week to ensure everyone has time to look. (Issue
#2701)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jun/0000.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Tantek Çelik
Elika Etemad
Javier Fernandez
Dael Jackson
Dean Jackson
Brian Kardell
Chris Lilley
Xidorn Quan
Melanie Richards
Florian Rivoal
Alan Stearns
Lea Verou
Eric Willigers
Regrets:
Angelo Cano
Emilio Cobos Álvarez
Benjamin De Cock
Simon Fraser
Tony Graham
Vlad Levantovsky
Thierry Michel
Manuel Rego Casasnovas
Scribe: dael
CSS Align
=========
astearns: We have enough people
astearns: Any extra items for the call?
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-392854468
astearns: I believe we just need Rossen's take on fantasai's comment.
Rossen: I did review it.
Rossen: It should be fine.
Rossen: Just before I sign off on it...let's get back to this. I
need to sort out a network issue.
CSS UI 4
========
Require link-pointer when pointer is over a link
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2664#issuecomment-388344661
florian: CSS UI defines what a link pointer looks like but doesn't
say it has to apply to links, esp. Chrome noticed they
don't apply in SVG. Chrome fixed itself. I think we have
interop, not 100% sure on Edge. Request is UI spec says
there needs to be something in UA stylesheet instructing
browser to use link in the link format for that style of
document.
florian: Seems reasonable. AmeliaBR approved. What do you all think?
fremy: I would recommend we say we recommend it to be there. I don't
think we can require it. I don't think we should be normative
on other doc formats.
florian: So we can either put it as a note or say unless otherwise
specified.
fremy: Second is good.
florian: Same sentence [UAs must apply cursor: pointer to hyperlinks
for all supported document formats via the UA stylesheet,
using a normal (i.e. not !important) declaration] from the
issue with the prefix.
<tantek> UA stylesheet suggestions in CSS UI are non-normative anyway
astearns: [reads tantek IRC] Is that the case?
<tantek> https://www.w3.org/TR/css-ui-3/#default-style-sheet
<tantek> This appendix is informative.
<tantek> so should it be in css-ui-4
florian: Draft has appendix with non-normative UA stylesheet
suggestions. I'm not suggesting writing a stylesheet, but
creating a requirement for other UA stylesheets.
florian: Yes, level 4 not 3.
<tantek> and keep the UA stylesheet in an informative appendix
astearns: Other opinions?
astearns: fremy you're okay with the wording in the issue plus the
prefix?
fremy: Yeah, why not?
<AmeliaBR> The SVG user-agent stylesheet would be the normative spec
(https://svgwg.org/svg2-draft/styling.html#UAStyleSheet ).
But good to have consistent guidance from CSS.
astearns: Objections to the suggestion in the issue plus a prefix
for unless otherwise specified
RESOLVED: Accept the suggestion in the issue plus a prefix for
unless otherwise specified for UI 4
CSS Align
=========
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-392854468
Rossen: Only thing to ask is...I had to re-read...now is time to
discuss and resolve. The ask was to swap out the direction
and have it overwritten for justify-content so static
position and sizing used for abspos items effected by
justify-content. That's the gist, correct?
TabAtkins: Yes.
Rossen: I was making sure we want to resolve that justify-content
takes precedence when calculating position. So if I have
direction rtl and nothing inside the containing block and I
have a justify-content:end then basically I will have 0 size
for the available width.
fantasai: I'm having trouble with your example. If you have abspos
and a size containing block which is the parent.
Containing block we do calc switched on direction
property. Initial value of justify-content is start,start.
If you did justify-content:end and rtl it would we same as
direction ltr.
Rossen: Not quite.
fantasai: That's the proposal
Rossen: This wasn't clear from the linked comment.
fantasai: Not sure. Point is right now we have different behavior
for ltr and ltl for static pos. Also size of an auto size
abspos depends on direction of static pos containing. We
prop we depend on justify-content which then itself
depends on direction.
Rossen: Okay, that should work out
Rossen: When you have orthogonal changes in direction between parent
and containing block?
TabAtkins: No behavior change. What happens today it's the same
behavior we want with a slight complication since center
is new.
Rossen: Center is the half way between?
TabAtkins: More or less, yes.
Rossen: Then I'm more or less okay with it :)
Rossen: With all the information I've heard and read I'm fine with
it.
astearns: Other opinions on the new center behavior?
astearns: Objections to accepting
https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-392854468
?
RESOLVED: Accept proposal in
https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-392854468
Values & Units
==============
Allow division of same types in calc(): should calc(1 / calc(1/(-1/0)))
produce positive infinity or negative infinity?
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/545#issuecomment-394474713
TabAtkins: In the course of porting typed OM into calc, typed OM
depends on float semantics but in calc CSS values don't
theoretically have a float semantic bound. I have to
define certain cases. Division by 0 produces postive or
negative infinity and it's clamped. I followed ieee754
semantics. ieee754 semantics track positive and negative.
CSS doesn't normally care about it.
TabAtkins: Depending on what you're doing you can construct
something that resolves to positive or negative infinity.
So far for simplicity I've omitted them but it's not hard
to add them back in. I suspect we would want that because
it's simpler for typed OM and calc to match in these
cases. Wanted to verify
<TabAtkins> calc(1 / calc(1/(-1/0)))
TabAtkins: In issue I have an example ^
TabAtkins: Resolves differently. It double inverts a negative
infinity and will be positive or negative depending on if
a negative 0 escapes the inner calc.
TabAtkins: I propose we track 0 signedness to be consistent with
general float semantics.
fremy: No objections. Still wondering why track infinity. We can say
it's not a number so it doesn't matter.
TabAtkins: If you're approaching a 0 in the denominator of something
you don't want to suddenly flip. The infinities have to
be something. If they're all positive if something is
approaching infinity it'll flip to positive and go from
really big to really small.
TabAtkins: Typed OM is just math over JS numbers and they have
infinities.
TabAtkins: We could expose extra semantics but it doesn't buy us
anything.
fremy: If you animate the denominator from -1 to 0 when you get to 0
it's positive. There isn't a browser supporting it so it's
not a huge use case.
TabAtkins: I know it's a new feature. There's no compat to worry
about.
TabAtkins: If all infinities go 0 and you have -1/-1 and then bottom
goes to 0 -1/0 should be negative.
fremy: -1/-1 is positive.
TabAtkins: Sorry, meant the other way. -1/1
fremy: -1/-1 goes to a positive 0. But okay, it's fine. I'm fine
with whatever you want.
TabAtkins: I'm not making up semantics. I'm saying follow ieee as
close as possible.
AmeliaBR: I agree with TabAtkins that it makes sense to be
consistent with standard computer math that's already in
JS. Also important b/c CSS we are animating values and
once we're allowing people to divide different lengths
like font size/viewport width and animate to 0 this could
come up. Continuous animations until something turns
infinite makes sense.
astearns: Other impl opinions?
astearns: dbaron do you have an opinion?
dbaron: No strong opinion.
astearns: Other opinions?
astearns: I'm hearing people call for dealing with negative 0. No
opinions against.
astearns: Objections to allowing calc to handle negative 0s?
RESOLVED: Allow calc to handle negative 0s
Filter Effects
==============
filter should be defined to establish a containing block for fixed and
absolutely positioned elements
----------------------------------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/11#issuecomment-360240933
astearns: We discussed once before.
astearns: Looks like krit and Chris H. have been discussing. Are
either on?
chrisl: I did discuss but not prepared to present.
astearns: krit said he didn't have an opinion either
chris: It was Chris Harleson (sp?) contributing.
TabAtkins: I'll get him on the call next week.
CSS Display
===========
Rename 'line box' to 'flow line'
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2546
fantasai: Loirooriol posted asking if we can change name to flow
line because it's not a box in the box tree sense. We have
flex line why not flow line. No strong opinion on what to
call. We've been using line box term for a long time. We'd
have a lot of specs to change and a disconnect between CSS
1 & 2 and other specs.
fantasai: flow lines sounds more obscure too, people who know text
layout. It's easier to guess what the term means with line
box -- it's a boxy thing which contains a line of [text]
content. Not a strong opinion and if WG wants change I'll
do it.
<dbaron> I would prefer not to change. See also the history of
"simple selector".
<tantek> I am against this change
chris: I agree this term has a long history and it's easier to add a
note saying why it's not behaving like a traditional box
leaverou: I would have no idea what flow line is. Line box makes
more sense.
<tantek> can we time box renaming line box?
florian: If we switch I'd want something like "line fragment" but
there's so much history.
astearns: Anyone argue for changing line box to another name?
astearns: I'm hearing no one. There's enough arguments against.
astearns: Objections to close no change?
florian: I think the suggestion of a note is good.
<TheRealChris> go for it
astearns: Objections to closing this issue by adding a note
mentioning the difference between line-box and other boxes
RESOLVED: Close this issue by adding a note mentioning the
difference between line box and other boxes.
CSS Variables
=============
Should "--" be a valid custom property name?
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2692
TabAtkins: Custom property names is anything starting with --
including -- by itself. I had intended to make a variable
specific version of the all property and to claim the --
name for it.
TabAtkins: Browsers allow -- as a custom property. I expect it's
rare. I propose we officially disallow -- as a custom
property name and add -- as an 'all' eq for variables
TabAtkins: Only compat is if someone is using a plain -- and I
suspect most people don't even know it's valid.
<AmeliaBR> Making `--` an official part of the spec sounds kind of
horrible, so I don't like that reason for disallowing
author use!
<AmeliaBR> (But I'm still happy to disallow it for author use.)
<tantek> +1 on TabAtkins proposal, seems reasonable
astearns: Let's separate proposed future use from the current point
of disallowing.
astearns: You can disagree with using -- with how TabAtkins has
suggested and still be okay to disallow.
<tantek> +1 on reserving it for possible future use that is
TabAtkins: I don't see why disallow if not using it for something in
the future.
tantek: [missed] disallow because it shows up in html with a
meaning. It feels like it is throw away syntax rather then
have meaning. To keep a bit of line noise out of stylesheets
<fantasai> +1 on reserving for possible future use from me as well
fremy: I wanted to say I reviewed and I'm fine with TabAtkins
proposal. My PoV this is a good change
<tantek> Let's resolve on just the first half. We can defer debating
if it means anything in the future
astearns: Objections to reserve -- for future use?
RESOLVED: Reserve "--" for future use and it is not a valid custom
property name.
CSS 2.1
=======
Anything that creates a stacking context should sort in the positioned
descendants z-ordering list
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2717
dbaron: I think at this point it's calling attention to it rather
then resolve.
dbaron: Underlying issue is due to how we structured our specs we
changed things relating to paining order and stacking
context without patching this central stuff.
dbaron: I proposed that everything that creates a stacking context
paints where css 2.1 paints
<fantasai> dbaron++++++++
dbaron: I tried to create test cases. Lots of non-interop.
Underlying principle seems entirely followed by chrome and
webkit. Mostly followed by gecko. Edge might be further, but
might be due to bug. Cases where gecko didn't follow is when
an impl literally followed spec and did nothing else and got
different.
dbaron: Other thing worth discussing is if people agree anything
creates a stacking context should cause something painted as
a descendant.
<fantasai> dbaron, makes sense to me
TabAtkins: I think Chris H. would be in favor of it. I'll ping him
into the thread.
dbaron: Chrome follows the principle exactly I think
dbaron: I wrote a comment in the issue with the exceptions. Chrome
and webkit are eq.
dbaron: When you start looking at which properties are supposed to
create stacking context there's lack of interop.
florian: Suggestion is patch css 2 for more generic worded statement?
dbaron: Part of it is css 2 needs to introduce terms other specs can
add. It says positioned element. We need a term...I thought
it's in the issue...I didn't propose a name. But we need a
term.
florian: Other terms?
dbaron: We need a second that's for elements that create a stacking
context and become a containing block. Since that doesn't
exist in L2 it could be introduced in an L3 spec.
Rossen: I looked briefly a couple weeks ago. Thought at the time
is...we have opacity which is a stacking context but not
containing block. display:fixed which is stacking not
containing. We have transforms that are stacking and
containing blocks including fixed.
Rossen: Is that what you're proposing to add...all of this?
dbaron: There's other pieces
<dbaron> https://dbaron.org/css/test/2018/stacking-context-z-order
dbaron: In the big test case ^ there's a lot of details
dbaron: Things I think are supposed to...everything on the left
except red background should create stacking. Things with
green box I think also create containing block for fixed pos.
dbaron: Based on current spec and current resolutions that aren't
yet edited in.
Rossen: This is a really good summary of all the different
combinations which I had not seen. Sorry. I want to go over
this and make sure we can cross our t's and dot our i's.
dbaron: I think if anything I might want resolution on general
principle we'd like to make them equivalent if we can get
away with it, stacking context and position descendants
layer. fixed pos is only somethings definitely.
dbaron: But totally fine taking time.
dbaron: I tried to make a list of bugs at the bottom.
Rossen: Other thing that I don't see in write up or matrix is there
are...also the discussion about body and html in the root
and filter on html or body would behave.
dbaron: I think we had separate resolution on that
Rossen: filter should effect scrolling for viewport or not for
example?
dbaron: I remember we discussed that for filter or mask. I'd like to
keep root stuff separate.
Rossen: That's fine. When it comes to, especially the fixed
containing box drama would be great. And that's where all
the root and body and filter drama comes into play
Rossen: Without considering the reverse style propagation it's hard.
<dbaron> we had some discussion about filter and body/root in
https://github.com/w3c/fxtf-drafts/issues/11
dbaron: I'll link to another issue where we discussed that, I think
astearns: Sounds like we all need to look more and come back to see
if we can resolve. It'd like to in part to get these tests
into wpt.
Rossen: Want to make sure we'll cast a wide net and put this to rest.
astearns: Right
astearns: Anything more to discuss this week?
dbaron: I'm fine with later.
astearns: Maybe a F2F.
Rossen: One more to add, filter opacity vs. opacity does the right
thing per spec.
dbaron: Yeah. I just picked a random filter for my test, but yes.
Rossen: Reason why is this on we've had confusion where people
expect opacity and filter opacity behave the same and it
doesn't for fixed pos.
CSS Nesting
===========
Request to pick up the css-nesting proposal
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2701
<TabAtkins> Proposal on http://tabatkins.github.io/specs/css-nesting/
TabAtkins: The proposal is relatively simple. Wrote a spec a few
years back. I'm fine but it's a syntax nicety where we
didn't get it past the community. If that's changed we
can move it forward.
fantasai: leaverou's comment talks about wanting different
specificity handling or the cascade. That's not syntactic
only where you can do it with a preprocessor. There was
@scope proposal before. I don't know if that's wanted or
something different. I want to see more of that discussed.
Do we want to effect cascade, if yes how. If we do this we
should find out what's desired.
TabAtkins: I strongly believe nothing new on specificity. Because
nesting is in every preprocessor in existence doing so
would be a major behavior change.
fantasai: No, not with same syntax.
TabAtkins: Second reason is it wouldn't be same as @scoped and it
would produce things that some ways resemble but some way
don't. @scoped wasn't popular and doesn't do what people
want for scoping.
* bkardell agrees
leaverou: I agree with TabAtkins, people are used to using nesting
for preprocessors. I disagree with my earlier comment. I
think scoping is useful, Not sure usability of scoping
proposal. It shouldn't hold nesting back.
TabAtkins: Happy to have that separate.
astearns: Objections to working on a purely syntactic nesting
proposal?
astearns: One concern is if you can do it in a preprocessor why do
it, but even the preprocessor authors are asking us to do
it.
chris: preprocessor expands to a ton of stuff and we don't want that
expansion
<gsnedders> It's one less reason to use a preprocessor, IMO.
<gsnedders> And that's a good thing.
<bkardell> better for authors, better for network, very slightly
worse for processing perf maybe?
astearns: Maybe an issue that we want to avoid the explosion of
combinations that can happen.
florian: For OM representation yes, but effect that's unavoidable.
TabAtkins: CSS style rules gain a child. OM doesn't explode.
chris: That's a big advantage.
leaverou: Huge advantage you can hover or focus styles on a one off.
TabAtkins: Originally a proposal to do rules inside style attribute
and this doesn't have that. You need only one token of
look ahead.
astearns: Objections to resolving we want to move forward with pure
syntactic nesting?
TabAtkins: And I want the impl to say if they actually don't want it.
<tantek> I'm too confused to comment on this last minute on the call
dbaron: If you're discussing changing what's in proposal it would be
good to have that written to share around.
TabAtkins: Entire proposal is linked in the issue to a spec on my
personal github. It's laid out with no odd changes.
TabAtkins: We can go to next week.
astearns: We're over time. I don't hear objections. I think we are
going to move forward, but let's give people time and
we'll come back.
<dbaron> I think for Gecko implementation it's probably worth asking
heycam and emilio rather than me.
astearns: Thanks everyone for calling in.
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 UI 4
--------
- RESOLVED: Accept the suggestion in the issue plus a prefix for
unless otherwise specified. Edits to be added UI 4
(Issue #2664)
CSS Align
---------
- RESOLVED: Accept proposal in
https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-392854468
[Proposal text:
- If justify-content on the static position containing block
is start, use the start edge of the static position
containing block and the end edge of the actual containing
block (as CSS2.1 requires).
- If justify-content on the static position containing block
is end, use the start edge of the actual containing block
and the end edge of the static position containing block.
- If justify-content on the static position containing block
is center, use the start edge and end edges of the static
position containing block.
]
Values & Units
--------------
- RESOLVED: Allow calc to handle negative 0s (Issue #545)
CSS Display
-----------
- RESOLVED: Close this issue (Issue #2546) by adding a note
mentioning the difference between line box and other
boxes.
CSS Variables
-------------
- RESOLVED: Reserve "--" for future use and it is not a valid custom
property name. (Issue #2692)
CSS 2.2
-------
- dbaron created a proposal
(https://dbaron.org/css/test/2018/stacking-context-z-order )
for issue #2717 (anything that creates a stacking context should
sort in the positioned descendants z-ordering list ). The
working group needed time to review and will discuss again
during a future meeting (perhaps the next F2F).
CSS Nesting
-----------
- No one was objecting to the purely syntactic nesting proposal
TabAtkins had written (http://tabatkins.github.io/specs/css-nesting/ )
however the call was running out of time so the group will
revisit next week to ensure everyone has time to look. (Issue
#2701)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jun/0000.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Tantek Çelik
Elika Etemad
Javier Fernandez
Dael Jackson
Dean Jackson
Brian Kardell
Chris Lilley
Xidorn Quan
Melanie Richards
Florian Rivoal
Alan Stearns
Lea Verou
Eric Willigers
Regrets:
Angelo Cano
Emilio Cobos Álvarez
Benjamin De Cock
Simon Fraser
Tony Graham
Vlad Levantovsky
Thierry Michel
Manuel Rego Casasnovas
Scribe: dael
CSS Align
=========
astearns: We have enough people
astearns: Any extra items for the call?
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-392854468
astearns: I believe we just need Rossen's take on fantasai's comment.
Rossen: I did review it.
Rossen: It should be fine.
Rossen: Just before I sign off on it...let's get back to this. I
need to sort out a network issue.
CSS UI 4
========
Require link-pointer when pointer is over a link
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2664#issuecomment-388344661
florian: CSS UI defines what a link pointer looks like but doesn't
say it has to apply to links, esp. Chrome noticed they
don't apply in SVG. Chrome fixed itself. I think we have
interop, not 100% sure on Edge. Request is UI spec says
there needs to be something in UA stylesheet instructing
browser to use link in the link format for that style of
document.
florian: Seems reasonable. AmeliaBR approved. What do you all think?
fremy: I would recommend we say we recommend it to be there. I don't
think we can require it. I don't think we should be normative
on other doc formats.
florian: So we can either put it as a note or say unless otherwise
specified.
fremy: Second is good.
florian: Same sentence [UAs must apply cursor: pointer to hyperlinks
for all supported document formats via the UA stylesheet,
using a normal (i.e. not !important) declaration] from the
issue with the prefix.
<tantek> UA stylesheet suggestions in CSS UI are non-normative anyway
astearns: [reads tantek IRC] Is that the case?
<tantek> https://www.w3.org/TR/css-ui-3/#default-style-sheet
<tantek> This appendix is informative.
<tantek> so should it be in css-ui-4
florian: Draft has appendix with non-normative UA stylesheet
suggestions. I'm not suggesting writing a stylesheet, but
creating a requirement for other UA stylesheets.
florian: Yes, level 4 not 3.
<tantek> and keep the UA stylesheet in an informative appendix
astearns: Other opinions?
astearns: fremy you're okay with the wording in the issue plus the
prefix?
fremy: Yeah, why not?
<AmeliaBR> The SVG user-agent stylesheet would be the normative spec
(https://svgwg.org/svg2-draft/styling.html#UAStyleSheet ).
But good to have consistent guidance from CSS.
astearns: Objections to the suggestion in the issue plus a prefix
for unless otherwise specified
RESOLVED: Accept the suggestion in the issue plus a prefix for
unless otherwise specified for UI 4
CSS Align
=========
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-392854468
Rossen: Only thing to ask is...I had to re-read...now is time to
discuss and resolve. The ask was to swap out the direction
and have it overwritten for justify-content so static
position and sizing used for abspos items effected by
justify-content. That's the gist, correct?
TabAtkins: Yes.
Rossen: I was making sure we want to resolve that justify-content
takes precedence when calculating position. So if I have
direction rtl and nothing inside the containing block and I
have a justify-content:end then basically I will have 0 size
for the available width.
fantasai: I'm having trouble with your example. If you have abspos
and a size containing block which is the parent.
Containing block we do calc switched on direction
property. Initial value of justify-content is start,start.
If you did justify-content:end and rtl it would we same as
direction ltr.
Rossen: Not quite.
fantasai: That's the proposal
Rossen: This wasn't clear from the linked comment.
fantasai: Not sure. Point is right now we have different behavior
for ltr and ltl for static pos. Also size of an auto size
abspos depends on direction of static pos containing. We
prop we depend on justify-content which then itself
depends on direction.
Rossen: Okay, that should work out
Rossen: When you have orthogonal changes in direction between parent
and containing block?
TabAtkins: No behavior change. What happens today it's the same
behavior we want with a slight complication since center
is new.
Rossen: Center is the half way between?
TabAtkins: More or less, yes.
Rossen: Then I'm more or less okay with it :)
Rossen: With all the information I've heard and read I'm fine with
it.
astearns: Other opinions on the new center behavior?
astearns: Objections to accepting
https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-392854468
?
RESOLVED: Accept proposal in
https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-392854468
Values & Units
==============
Allow division of same types in calc(): should calc(1 / calc(1/(-1/0)))
produce positive infinity or negative infinity?
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/545#issuecomment-394474713
TabAtkins: In the course of porting typed OM into calc, typed OM
depends on float semantics but in calc CSS values don't
theoretically have a float semantic bound. I have to
define certain cases. Division by 0 produces postive or
negative infinity and it's clamped. I followed ieee754
semantics. ieee754 semantics track positive and negative.
CSS doesn't normally care about it.
TabAtkins: Depending on what you're doing you can construct
something that resolves to positive or negative infinity.
So far for simplicity I've omitted them but it's not hard
to add them back in. I suspect we would want that because
it's simpler for typed OM and calc to match in these
cases. Wanted to verify
<TabAtkins> calc(1 / calc(1/(-1/0)))
TabAtkins: In issue I have an example ^
TabAtkins: Resolves differently. It double inverts a negative
infinity and will be positive or negative depending on if
a negative 0 escapes the inner calc.
TabAtkins: I propose we track 0 signedness to be consistent with
general float semantics.
fremy: No objections. Still wondering why track infinity. We can say
it's not a number so it doesn't matter.
TabAtkins: If you're approaching a 0 in the denominator of something
you don't want to suddenly flip. The infinities have to
be something. If they're all positive if something is
approaching infinity it'll flip to positive and go from
really big to really small.
TabAtkins: Typed OM is just math over JS numbers and they have
infinities.
TabAtkins: We could expose extra semantics but it doesn't buy us
anything.
fremy: If you animate the denominator from -1 to 0 when you get to 0
it's positive. There isn't a browser supporting it so it's
not a huge use case.
TabAtkins: I know it's a new feature. There's no compat to worry
about.
TabAtkins: If all infinities go 0 and you have -1/-1 and then bottom
goes to 0 -1/0 should be negative.
fremy: -1/-1 is positive.
TabAtkins: Sorry, meant the other way. -1/1
fremy: -1/-1 goes to a positive 0. But okay, it's fine. I'm fine
with whatever you want.
TabAtkins: I'm not making up semantics. I'm saying follow ieee as
close as possible.
AmeliaBR: I agree with TabAtkins that it makes sense to be
consistent with standard computer math that's already in
JS. Also important b/c CSS we are animating values and
once we're allowing people to divide different lengths
like font size/viewport width and animate to 0 this could
come up. Continuous animations until something turns
infinite makes sense.
astearns: Other impl opinions?
astearns: dbaron do you have an opinion?
dbaron: No strong opinion.
astearns: Other opinions?
astearns: I'm hearing people call for dealing with negative 0. No
opinions against.
astearns: Objections to allowing calc to handle negative 0s?
RESOLVED: Allow calc to handle negative 0s
Filter Effects
==============
filter should be defined to establish a containing block for fixed and
absolutely positioned elements
----------------------------------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/11#issuecomment-360240933
astearns: We discussed once before.
astearns: Looks like krit and Chris H. have been discussing. Are
either on?
chrisl: I did discuss but not prepared to present.
astearns: krit said he didn't have an opinion either
chris: It was Chris Harleson (sp?) contributing.
TabAtkins: I'll get him on the call next week.
CSS Display
===========
Rename 'line box' to 'flow line'
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2546
fantasai: Loirooriol posted asking if we can change name to flow
line because it's not a box in the box tree sense. We have
flex line why not flow line. No strong opinion on what to
call. We've been using line box term for a long time. We'd
have a lot of specs to change and a disconnect between CSS
1 & 2 and other specs.
fantasai: flow lines sounds more obscure too, people who know text
layout. It's easier to guess what the term means with line
box -- it's a boxy thing which contains a line of [text]
content. Not a strong opinion and if WG wants change I'll
do it.
<dbaron> I would prefer not to change. See also the history of
"simple selector".
<tantek> I am against this change
chris: I agree this term has a long history and it's easier to add a
note saying why it's not behaving like a traditional box
leaverou: I would have no idea what flow line is. Line box makes
more sense.
<tantek> can we time box renaming line box?
florian: If we switch I'd want something like "line fragment" but
there's so much history.
astearns: Anyone argue for changing line box to another name?
astearns: I'm hearing no one. There's enough arguments against.
astearns: Objections to close no change?
florian: I think the suggestion of a note is good.
<TheRealChris> go for it
astearns: Objections to closing this issue by adding a note
mentioning the difference between line-box and other boxes
RESOLVED: Close this issue by adding a note mentioning the
difference between line box and other boxes.
CSS Variables
=============
Should "--" be a valid custom property name?
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2692
TabAtkins: Custom property names is anything starting with --
including -- by itself. I had intended to make a variable
specific version of the all property and to claim the --
name for it.
TabAtkins: Browsers allow -- as a custom property. I expect it's
rare. I propose we officially disallow -- as a custom
property name and add -- as an 'all' eq for variables
TabAtkins: Only compat is if someone is using a plain -- and I
suspect most people don't even know it's valid.
<AmeliaBR> Making `--` an official part of the spec sounds kind of
horrible, so I don't like that reason for disallowing
author use!
<AmeliaBR> (But I'm still happy to disallow it for author use.)
<tantek> +1 on TabAtkins proposal, seems reasonable
astearns: Let's separate proposed future use from the current point
of disallowing.
astearns: You can disagree with using -- with how TabAtkins has
suggested and still be okay to disallow.
<tantek> +1 on reserving it for possible future use that is
TabAtkins: I don't see why disallow if not using it for something in
the future.
tantek: [missed] disallow because it shows up in html with a
meaning. It feels like it is throw away syntax rather then
have meaning. To keep a bit of line noise out of stylesheets
<fantasai> +1 on reserving for possible future use from me as well
fremy: I wanted to say I reviewed and I'm fine with TabAtkins
proposal. My PoV this is a good change
<tantek> Let's resolve on just the first half. We can defer debating
if it means anything in the future
astearns: Objections to reserve -- for future use?
RESOLVED: Reserve "--" for future use and it is not a valid custom
property name.
CSS 2.1
=======
Anything that creates a stacking context should sort in the positioned
descendants z-ordering list
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2717
dbaron: I think at this point it's calling attention to it rather
then resolve.
dbaron: Underlying issue is due to how we structured our specs we
changed things relating to paining order and stacking
context without patching this central stuff.
dbaron: I proposed that everything that creates a stacking context
paints where css 2.1 paints
<fantasai> dbaron++++++++
dbaron: I tried to create test cases. Lots of non-interop.
Underlying principle seems entirely followed by chrome and
webkit. Mostly followed by gecko. Edge might be further, but
might be due to bug. Cases where gecko didn't follow is when
an impl literally followed spec and did nothing else and got
different.
dbaron: Other thing worth discussing is if people agree anything
creates a stacking context should cause something painted as
a descendant.
<fantasai> dbaron, makes sense to me
TabAtkins: I think Chris H. would be in favor of it. I'll ping him
into the thread.
dbaron: Chrome follows the principle exactly I think
dbaron: I wrote a comment in the issue with the exceptions. Chrome
and webkit are eq.
dbaron: When you start looking at which properties are supposed to
create stacking context there's lack of interop.
florian: Suggestion is patch css 2 for more generic worded statement?
dbaron: Part of it is css 2 needs to introduce terms other specs can
add. It says positioned element. We need a term...I thought
it's in the issue...I didn't propose a name. But we need a
term.
florian: Other terms?
dbaron: We need a second that's for elements that create a stacking
context and become a containing block. Since that doesn't
exist in L2 it could be introduced in an L3 spec.
Rossen: I looked briefly a couple weeks ago. Thought at the time
is...we have opacity which is a stacking context but not
containing block. display:fixed which is stacking not
containing. We have transforms that are stacking and
containing blocks including fixed.
Rossen: Is that what you're proposing to add...all of this?
dbaron: There's other pieces
<dbaron> https://dbaron.org/css/test/2018/stacking-context-z-order
dbaron: In the big test case ^ there's a lot of details
dbaron: Things I think are supposed to...everything on the left
except red background should create stacking. Things with
green box I think also create containing block for fixed pos.
dbaron: Based on current spec and current resolutions that aren't
yet edited in.
Rossen: This is a really good summary of all the different
combinations which I had not seen. Sorry. I want to go over
this and make sure we can cross our t's and dot our i's.
dbaron: I think if anything I might want resolution on general
principle we'd like to make them equivalent if we can get
away with it, stacking context and position descendants
layer. fixed pos is only somethings definitely.
dbaron: But totally fine taking time.
dbaron: I tried to make a list of bugs at the bottom.
Rossen: Other thing that I don't see in write up or matrix is there
are...also the discussion about body and html in the root
and filter on html or body would behave.
dbaron: I think we had separate resolution on that
Rossen: filter should effect scrolling for viewport or not for
example?
dbaron: I remember we discussed that for filter or mask. I'd like to
keep root stuff separate.
Rossen: That's fine. When it comes to, especially the fixed
containing box drama would be great. And that's where all
the root and body and filter drama comes into play
Rossen: Without considering the reverse style propagation it's hard.
<dbaron> we had some discussion about filter and body/root in
https://github.com/w3c/fxtf-drafts/issues/11
dbaron: I'll link to another issue where we discussed that, I think
astearns: Sounds like we all need to look more and come back to see
if we can resolve. It'd like to in part to get these tests
into wpt.
Rossen: Want to make sure we'll cast a wide net and put this to rest.
astearns: Right
astearns: Anything more to discuss this week?
dbaron: I'm fine with later.
astearns: Maybe a F2F.
Rossen: One more to add, filter opacity vs. opacity does the right
thing per spec.
dbaron: Yeah. I just picked a random filter for my test, but yes.
Rossen: Reason why is this on we've had confusion where people
expect opacity and filter opacity behave the same and it
doesn't for fixed pos.
CSS Nesting
===========
Request to pick up the css-nesting proposal
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2701
<TabAtkins> Proposal on http://tabatkins.github.io/specs/css-nesting/
TabAtkins: The proposal is relatively simple. Wrote a spec a few
years back. I'm fine but it's a syntax nicety where we
didn't get it past the community. If that's changed we
can move it forward.
fantasai: leaverou's comment talks about wanting different
specificity handling or the cascade. That's not syntactic
only where you can do it with a preprocessor. There was
@scope proposal before. I don't know if that's wanted or
something different. I want to see more of that discussed.
Do we want to effect cascade, if yes how. If we do this we
should find out what's desired.
TabAtkins: I strongly believe nothing new on specificity. Because
nesting is in every preprocessor in existence doing so
would be a major behavior change.
fantasai: No, not with same syntax.
TabAtkins: Second reason is it wouldn't be same as @scoped and it
would produce things that some ways resemble but some way
don't. @scoped wasn't popular and doesn't do what people
want for scoping.
* bkardell agrees
leaverou: I agree with TabAtkins, people are used to using nesting
for preprocessors. I disagree with my earlier comment. I
think scoping is useful, Not sure usability of scoping
proposal. It shouldn't hold nesting back.
TabAtkins: Happy to have that separate.
astearns: Objections to working on a purely syntactic nesting
proposal?
astearns: One concern is if you can do it in a preprocessor why do
it, but even the preprocessor authors are asking us to do
it.
chris: preprocessor expands to a ton of stuff and we don't want that
expansion
<gsnedders> It's one less reason to use a preprocessor, IMO.
<gsnedders> And that's a good thing.
<bkardell> better for authors, better for network, very slightly
worse for processing perf maybe?
astearns: Maybe an issue that we want to avoid the explosion of
combinations that can happen.
florian: For OM representation yes, but effect that's unavoidable.
TabAtkins: CSS style rules gain a child. OM doesn't explode.
chris: That's a big advantage.
leaverou: Huge advantage you can hover or focus styles on a one off.
TabAtkins: Originally a proposal to do rules inside style attribute
and this doesn't have that. You need only one token of
look ahead.
astearns: Objections to resolving we want to move forward with pure
syntactic nesting?
TabAtkins: And I want the impl to say if they actually don't want it.
<tantek> I'm too confused to comment on this last minute on the call
dbaron: If you're discussing changing what's in proposal it would be
good to have that written to share around.
TabAtkins: Entire proposal is linked in the issue to a spec on my
personal github. It's laid out with no odd changes.
TabAtkins: We can go to next week.
astearns: We're over time. I don't hear objections. I think we are
going to move forward, but let's give people time and
we'll come back.
<dbaron> I think for Gecko implementation it's probably worth asking
heycam and emilio rather than me.
astearns: Thanks everyone for calling in.