- From: fantasai <[email protected]>
- Date: Fri, 26 May 2017 22:21:26 -0400
- To: "[email protected]" <[email protected]>
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Geometry API
------------
- RESOLVED: Republish Geomtry API as Working Draft
- RESOLVED: Dirk and Rik to former editors of geometry API
CSS Writing Modes
-----------------
- RESOLVED: shrink-to-fit formula for auto-sized orthogonal flows uses
nearest scrollable ancestor, not necessarily viewport
CSS Values and Units
--------------------
- RESOLVED: Move the close parens to after "including high-resolution devices"
- RESOLVED: Unitless zeros are parsed as numbers if it is ambiguous whether
they are a <length> or a <number>
- Tentative Resolution: Where calc() is resolved at computed value time,
clamp at computed value time; otherwise clamp at used value time
- RESOLVED: Numeric expressions are explicitly allowed in denominators
of calc() expressions
Display
-------
- RESOLVED: display:contents applies to ::after and ::before
Testing
-------
- Normalize spec links to anchors in ToC for now.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017May/0040.html
Present:
Alan Stearns
Alex Critchfield
Anton Prowse
Bert Bos
Brad Kemper
David Baron
Elika Etemad
Greg Whitworth
Jen Simmons
Liam Quin
Melanie Richards
Myles Maxfield
Peter Linss
Rossen Atanassov
Robert Flack
Simon Fraser
Simon Pieters
Tantek Çelik
Tony Graham
Regrets:
Benjamin De Cock
Chris Lilley
Florian Rivoal
Lea Verou
Rachel Andrew
Vladimir Levantovsky
<RRSAgent> logging to http://www.w3.org/2017/05/24-css-irc
Administrivia
=============
Scribe: fantasai
Rossen: Any other agenda items?
Rossen: no?
Rossen: Ok, anyone willing to bikeshedify css-backgrounds?
Rossen: would prefer if fantasai didn't have to do it
fantasai: Shouldn't be too much work: don't need to convert to Markdown,
bikeshed handles HTML just fine. Just need to fix property/value
links and boilerplate
ericwilligers volunteers
Rossen: Is anything else needed here for css-conditional?
<Rossen> this https://github.com/w3c/csswg-drafts/pull/1209
dbaron: Haven't had a chance to look
Rossen: Ok, please have a look then. action item was you and zcorpan to
resolve disrepencies between CSSOM and css-conditional
Rossen: Let us know if this PR is all we need, or we need more.
Rossen: I've been tracking writing-modes issues
Rossen: Anything else besides the issue that's open?
fantasai: I need to respond to ChrisL's transition request questions
Rossen: Fonts L3, are we done moving things to L4?
Rossen: Is ChrisL or Myles here?
Rossen: Thanks to everyone for work on moving these things forward.
Geometry API
============
<Rossen> https://lists.w3.org/Archives/Public/public-fx/2017AprJun/0011.html
zcorpan: It's been a few years
zcorpan: since last publication of this spec
zcorpan: But recent activity on implementations, spec fixes, tests
zcorpan: seems like reasonable time to republish
Rossen: New publication has lots of changes, right? So goes back to WD?
zcorpan: Yes, seems reasonable, since a long time since CR and lots of changes
Rossen: OK
Rossen: Objections to WD of Geometry API?
<tantek> ship it
fantasai: sgtm
RESOLVED: Updated WD of Geometry API
Rossen: Spec currently lists two people who are no longer active
in CSSWG as editors
Rossen: means spec effectively has only one editor, zcorpan
Rossen: Do you need help with the spec?
zcorpan: not atm
Rossen: ok, good, then second request would be to move Dirk and Rik
to former editors
zcorpan: ok
RESOLVED: Dirk and Rik to former editors of geometry API
CSS Writing Modes: Orthogonal Flow Constraints as viewport vs scroller
----------------------------------------------------------------------
Scribe: zcorpan
<Rossen> https://github.com/w3c/csswg-drafts/issues/1391
fantasai: Realized that I hadn't done an action item to update
the spec after some discussions several years ago
fantasai: we have 2 impl and a test that i need to check into WPT
fantasai: the issue is about when you have orthogonal flows and a scroller
fantasai: normally when there's no constraint of the child...
the height is determined by a shink-to-fit formula
fantasai: Spec says to use ICB as the constraint in that formula
fantasai: but better to use the height of the nearest ancestor scrollport
Rossen: I recall discussing this
Rossen: we already agreed to do this for the reasons you outline
Rossen: are there any other opinions or alternative proposals?
Rossen: if not we can just resolve
Rossen: I will take that as a no
RESOLVED: shrink-to-fit formula for auto-sized orthogonal flows uses
nearest scrollable ancestor, not necessarily viewport
Rossen: Does that change go to Level 3?
fantasai: yes
Rossen: any other knobs or switches ?
fantasai: we have the change, the WG resolution, test case and implementations
Rossen: ok great
CSS Values
==========
High-DPI px Anchor
------------------
Github topic: https://github.com/w3c/csswg-drafts/issues/708
fantasai: There was a pull request for this issue that we accepted
to implement the WG resolution.
fantasai: I was reviewing the changes to update V&U spec
fantasai: The edits also switched the anchor category of print media
with unusual viewing distances, which wasn't part of the issue
fantasai: Summary of the issue -
fantasai: 2 categories for anchor units
fantasai: viewing angle unit = px
fantasai: other is physical unit like mm/in
fantasai: css is based on 96 DPI and px is viewing angle
fantasai: used to be independent but had to lock ratio due to web compat
fantasai: On print, we anchor to physical unit
fantasai: so when you print, 12pt is actually 12pt
fantasai: on screen we anchor to viewing angle pixel approximation,
round to actual pixels to make it look nice on the screen
fantasai: print and high-dpi used to be classed together...
fantasai: but the change to move high-dpi screens also moved all
devices with unusual viewing distances
fantasai: so for print with unusual viewing distance, which category?
fantasai: now it's in the physical category
fantasai: do we want to revert the change?
Rossen: So, going to echo florian's point...
Rossen: since this is a SHOULD, do we need to change?
fantasai: if we don't have anything we intentionally want to change,
we shouldn't make a change from the previous CR;
implies some intention behind the difference
<dbaron> seems like if you're taking content written for another device
and print it on a billboard, you want your "12pt" font to be
bigger than 12pt
dbaron: the change seems reasonable to me
dbaron: if you take content designed from a different device and print
to a billboard you may want the viewing distance thing
dbaron: OTOH if you design for the billboard you may want physical units
plinss: seems like this should be a choice when you're printing
plinss: not happy with either change
plinss: it's a print-time choice based on the content, device, etc
plinss: shouldn't mandate from the spec
Rossen: right, that's why it's a should
Rossen: might be enough
plinss: I think that's not what should means
<tantek> where is the change?
<astearns> tantek: https://github.com/w3c/csswg-drafts/pull/713/files
bradk: seems like a viewing angle situation
bradk: language an opt-in, in e-paper(?) you can go either way
fremy: can't you leave it as choice per device?
plinss: need all devices to be consistent
tantek: i'm confused by the example of billboard vs print
fantasai: it's an example of a device with an unusual viewing distance
tantek: looking at the diff in github... billboard can be print or screen
dbaron: the PR changed printed billboard because of the way it worded it
fantasai: [citing spec?]
fantasai: not a subset of screen media
fantasai: 1 category is high-res, second is low-res and unusual viewing
distance
fantasai: before you could interpret print with unusual viewing distance
as either
fantasai: now it can only be that for screen media
<fantasai> Proposal is to move the close parentheses after
"including high-resolution devices"
Rossen: sounds pretty good
<Rossen> For screen media (including high-resolution devices),
lower-resolution devices, and devices with unusual
viewing distances,
tantek: sounds sensible
<bradk> I agree
fantasai: ok, i will make the change
plinss: happy with the change
plinss: maybe provide an opt-in later
<tantek> +1 to proposal
RESOLVED: Move the close parens after "including high-resolution devices"
Ambiguous Unitless Zeroes
-------------------------
Scribe: myles
GitHub: https://github.com/w3c/csswg-drafts/issues/489
fantasai: we have a situation where you can have <interger> or <length>
(or <nubmer> & <length>) & it's not clear what happens with
unitless zero.
fantasai: Situation occurs in, e.g., tab-size & line-height.
<fantasai> cases are property syntaxes like <integer> | <length>
fantasai: which of type does the unitless 0 parse to?
fantasai: currently there is no behavior difference for these properties,
but in the future it might matter
Rossen: so where would it matter?
Rossen: in calc(), parsing would fail if you do it wrong
Rossen: in another expression, in grid gaps, or something else, it will
always be interpreted as a <length>
fantasai: xidorn says that 0 lengths get serialized as "0px"
Rossen: the computed style?
fantasai: I dunno, not an OM person
fantasai: TabAtkins says that the Typed OM might want to make a distinction
fantasai: we could make a rule "if you're in an ambiguous situation,
it parses as a number"
Rossen: yes, and later in the cascade, you could typecast the number to an
internal unit type, imlementation-specific, and the implementation
could handle it
Rossen: the question is: what happens when you serialize it back out?
Do you return the number or a real length?
Rossen: for us, if we have to tag along an additional information about
what I just described, it's going to be difficult
Rossen: not impossible though.
Rossen: doesn't buy authors much.
Rossen: (unless we have a specific example)
fantasai: we could not fix it, or we can say it parses as an integer
fantasai: those are the two options
fantasai: dbaron?
fantasai: <restates the question>
dbaron: i thought it would be a number
fantasai: spec doesn't say that
fantasai: can we resolve?
Rossen: i have no problem keeping it as a number
Rossen: objections?
Rossen: to specify it as a number if it isn't already
RESOLVED: Unitless zeros are parsed as numbers if it is ambiguous whether
they are a <length> or a <number>
Clamping calc()
---------------
GitHub: https://github.com/w3c/csswg-drafts/issues/434
fantasai: this question was about when things get clamped,
if you have a property which doesn't accept negative lengths,
for example, the spec says that the used value is clamped,
but the computed value is not clamped, and there is some
disagreement about whether that is waht is implemented
<fantasai> dbaron's comment from GitHub:
For properties where the computed value is a length (i.e., calc()s
that are computed at computed value time) like font-size, we clamp
to nonnegative values at computed value time. For properties where
the calc() expression is part of the computed value space (like
padding-left) we have clamping at used value time (both in the
GetComputedStyle code and in the code that actually uses the value).
I think the spec is still wrong for properties that accept calc()
but where calc() is not part of the computed value space since it
can be fully computed by computed value time (e.g., font-size).
<fantasai> https://github.com/w3c/csswg-drafts/issues/434#issuecomment-243933445
Rossen: to further TabAtkins's latest point, some or most of this is
referring to getComputedStyle() which returns used values not
computed values
Rossen: it seems like WebKit and blink don't have a separate notion of
computed values, and this is a transient value for them
dbaron: there is some value which gets inherited. If you have "25% - 30px"
and you say this is the computed value and it gets inherited to
something which clamps differently, it should be clamped differently
Rossen: but you don't know that 25% gets resolved to something > 25px
fantasai: but you do know this for some properties
fantasai: for padding-left you don't know this, because percents depend on
layout and are not known at computed value time.
fantasai: but font-size, you do know this: you can resolve this at computed
value time, and you *need* to because the value of font-size needs
to be computed to a length in order to resolve ems.
Rossen: font-size is the only property which resolves percentages outside
of layout
fantasai: dbaron: no
Rossen: ....
Rossen: ok.
fantasai: dbaron, do you have a proposal?
dbaron: not off the top of my head
dbaron: i could write one
fantasai: yes please
dbaron: we need a distinction where calc() is resolved at computed value
time and where calc() is part of a computed value. these needs
separate rules
fantasai: ok.
fantasai: in the first case, we would do the clamping at computed value
time, and the second case, it would be at used value time
dbaron: yes
Rossen: how is this observable?
dbaron: the difference is observable through inheritance. but also, some of
the combinations of ways of specifying it, it doesn't make any sense
fantasai: let's resolve
Rossen: we need a proposal
fantasai: i can write proposed text
fantasai: w/ dbaron's review
Rossen: let's see the prose before we resolve
fantasai: sounds good
Numeric Expression Denominators in calc()
-----------------------------------------
GitHub: https://github.com/w3c/csswg-drafts/issues/1241
fantasai: we originally intended the denominator of calc() to allow a
numeric expression
fantasai: like calc(13 / (5 + 3))
fantasai: we don't like units in the denominator because unit math is hard
fantasai: numeric math is ok though
fantasai: This isn't in the spec but we do have implementations.
So we should add this to level 3
fantasai: Filing against level 4 doesn't make sense because level 4 will
include all the unit math and everything which would be a
superset of this
fantasai: but we need a resolution if we want to add it to level 3
Rossen: yes please
Rossen: <expresses support>
Rossen: any objections?
RESOLVED: Numeric expressions are explicitly allowed in denominators of calc() expressions
Display
=======
'display: contents' vs ::before/::after
---------------------------------------
GitHub: https://github.com/w3c/csswg-drafts/issues/1345
fantasai: <restates the topic>
fantasai: TabAtkins and i are leaning toward "yes" but we aren't
particularly resolute
fantasai: any opinions?
Rossen: it is unclear, if we say "no," what is observable?
fantasai: you can put a border on ::after, and the border will disappear
if you say display:contents, because the box will disappear
Rossen: was this just an oversight?
fantasai: just needed clarification, wanted to check if there were any probs
Rossen: this works for us
Rossen: objections?
RESOLVED: display:contents applies to ::after and ::before
Testing: Normalizing Spec Links
-------------------------------
<Rossen> Github issue: https://github.com/w3c/csswg-drafts/issues/1395
gregwhitworth: a lot of tests are duplicative in the flex tests.
They link to the flex-basis propdef or ... somewhere else
gregwhitworth: i want to make them uniform
gregwhitworth: someone commented
fantasai: we used to have the rule that you would link only to anchors
in the table of contents
fantasai: i'm okay to revise that rule, but that rule was simple
gregwhitworth: that doesn't work because we need deeper links
gregwhitworth: except it's okay for now
fantasai: sections are usually fine-grained enough in L3 specs,
except for flexbox and grid layout algorithms,
each bullet point has an anchor, which allows us to be more
fine-grained, and it makes more sense there to go deeper
gregwhitworth: gsnedders and i were talking about how to understand test
coverage. If anyone has any suggestions, please mention them
dbaron: there are cases where the propdef is more stable across spec versions
fantasai: usually we have one section per property
dbaron: not always, and there are often multiple properties in the same
section. you might want to link to one individually
fantasai: we do that less now.
dbaron: css-align has a lot of these
fantasai: true
Rossen: we are out of time, folks
Rossen: we have a solution which will unblock gregwhitworth and gsnedders
Rossen: need to continue investing in improving
Rossen: please help if you have ideas
Rossen: do we need resolution?
gregwhitworth: no
Rossen: We can just do what fantasai said
gregwhitworth: i'll link to sections for now, and if someone argues,
we can revisit
fantasai: you can also link to both
plinss: let's not make a rule, instead, let's just do this for a single spec
Rossen: ok
plinss: ok
Rossen: please start booking flights to paris
Rossen: byebye
<RRSAgent> http://www.w3.org/2017/05/24-css-minutes.html trackbot
Received on Saturday, 27 May 2017 02:22:28 UTC