- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 20 Sep 2017 19:49:34 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
User Agent properties and variables
-----------------------------------
- RESOLVED: Rename what was 'constant' variables to 'environment'
variables using env().
- RESOLVED: Add this as an ED of variables L2.
- RESOLVED: Add dino as an editor of variables L2 with TabAtkins.
- RESOLVED: The initial set is safe area top, bottom, left and
right.
Events for stickiness changes
-----------------------------
- RESOLVED: Close issue 1660 no change.
Using non fixed size SVG in the cursor property
-----------------------------------------------
- RESOLVED: SVG without intrinsic dimensions MAY be supported (not
MUST), add a note (to indicate the working group's
original intent to have this a MUST).
Meta bug for line height
------------------------
- Everyone was again reminded to review this issue and provide
feedback - github: https://github.com/w3c/csswg-drafts/issues/1796
fit-content() vs 'stretch' alignment
------------------------------------
- RESOLVED: fit-content does not grow past its argument due to
alignment stretch.
- RESOLVED: Keep fit-content behavior as-is, to not grow past
max-content in presence of stretch.
===== FULL MINUTES BELOW =======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Sep/0037.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Dael Jackson
Brian Kardell
Chris Lilley
Peter Linss
Myles Maxfield
Manuel Rego Casasnovas
Melanie Richards
Florian Rivoal
Jen Simmons
Alan Stearns (IRC Only)
Greg Whitworth
Regrets:
Benjamin De Cock
Tony Graham
Lea Verou
Scribe: dael
Agenda Setting
--------------
Rossen: Let's get started. Good morning/evening/your time. As
usual, first is any additional items?
smfr: Can I request a rearrange? Can we discuss #5 before 2 & 3
because I have to leave early. #6 should be brief.
smfr: I'm fine with proposal for item #6.
Rossen: You want variables first?
smfr: Yes, please.
Rossen: Any other addition?
florian: I just re-opened something. I'm trying to find a link.
<florian> https://github.com/w3c/csswg-drafts/issues/1391
florian: This ^
florian: If there's time. On writing modes.
Rossen: Is this against current version?
florian: Yes. We closed, but I found new information so I wanted
to check if we're still okay.
Rossen: Okay. Any other changes to agenda?
Spec Rec Next Steps
-------------------
Rossen: There has been quite a bit of progress sense last time I
was on a call. There were a few items I wanted to touch
on. Those are the ones that seem to be a bit behind.
Rossen: Background and borders. Besides that we need tests...did
we make any progress? It was supposed to be converted to
bikeshed by eric. Did that happen or can we assign to
someone else? How can we move this spec forward?
[silence]
Rossen: I will take the silence as no one has an opinion. Since
draft conversion is the first thing to do, can we have
someone volunteer?
TabAtkins: I can go through and re-write it.
Rossen: Thank you very much.
Rossen: Transforms 1. There was some work that had to be done a
month or two ago between Simon & Bogdan on transforms &
SVG. That was open for quite a bit of time.
smfr: I haven't had time to make progress.
Rossen: What are we stuck on?
smfr: There's a number of parts of spec that need reading by an
SVG expert. Those parts are listed in issue, I think.
Rossen: Depending on if SVG folks will gather during tpac...
Chris: They won't. The group wasn't chartered at the time so they
didn't request at tpac.
Rossen: Last time I spoke I had the opposite, but if that's a
fact, great.
Rossen: Chris are we done with fonts 3?
Chris: Not yet. I'm still chipping away at parts without tests. I
meant to do a report for this week, I'll send one next
week. We're close.
Rossen: Are the features to move approved?
Chris: That's fine. Just spec work.
Rossen: And on transforms I'll make sure Bogdan reaches out to you
smfr and maybe someone from the newly rechartered SVG
group.
Rossen: Writing modes. What is the deal? Are we ready?
Chris: I was writing a transition to CR. fantasai answered my last
question the day before. Having done that some tests in the
suite have tests for L4 items. We need to fix that before
going to PR.
Rossen: CR period on this?
fantasai: Should be the min possible.
Rossen: 4 weeks?
Chris: Yes.
Rossen: Looks like we might be able to close at TPAC.
Rossen: Bert css 2.1?
Bert: I put back all the text I removed as fantasai suggested. I
added informative links to the css 3. THere were other
sections that could get those links, but all the text is as
it was.
Rossen: Is this waiting on review? Do you need help? Are we done?
Rossen: Bert?
[it appears we lost him]
Rossen: I'll catch up with Bert offline.
<Rossen> Bert: please reply back to this email
(https://lists.w3.org/Archives/Member/w3c-css-wg/2017JulSep/0160.html)
and let us know what help you need from the rest of us
<Bert> to Rossen: will do
User Agent properties and variables
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1693
smfr: Apple is proposing constants which are UA defined variables.
They're supplied by the UA and not assignable in CSS. Work
everywhere variables work. We intend them for metrics that
are of interest to web authors to layout their pages. You
can imagine one for things like scrollbar.
smfr: Ones we're most interested in is iPhone X where it tells
authors how to avoid rounded corners.
smfr: Two aspects to this discussion. Is the constant function the
right name? Second part is should we have a specific set and
list them out?
TabAtkins: Hitting the second one. You cannot have this as a
feature and have a bunch of UA specific values. It
doesn't help authors.
smfr: I agree
TabAtkins: Values need to be in spec. You can have UA ones behind
a flag, but general set of values need to be specified
and interop.
smfr: We agree.
TabAtkins: I love this and this is great. One bit I think I
disagree. This should be usable wider than variables.
You should be able to use a global in a MQ or
something. It shouldn't be limited to use in properties.
smfr: I think that's reasonable.
florian: I'm not sure. 2 reasons. If it's not like variables we
need to decide how it works. We'd have to invent a new
thing. Also, it's not crazy to imagine that this might
have different values per element in the DOM, like what's
the default font and that's language dependent so you
need a DOM. I'd be careful about expanding it.
TabAtkins: That sort of thing would not be super compat with how
we're thinking about this. But if we did something like
that I would be fine to say in that case it's an
invalid reference. Same as using color in a link MQ.
florian: Okay.
smfr: One concern with using this in MQ. We found authors often
want them in conjunction with min and max. So that gives you
feature creep where you want min and max in MQ.
TabAtkins: Calc is allowed per spec, which you and then do min and
max.
smfr: Does any browser implement?
TabAtkins: Dunno.
smfr: If it's in spec, it's reasonable.
TabAtkins: You might as well be able to. It makes sense.
TabAtkins: Regarding names, I'm fine with constant, but thread had
people object to that. They suggested global which was
fine to me too.
TabAtkins: fremy also pointed out this is the use case I was
trying to reserve $ for. So that might work.
smfr: I don't like $ because if someone doesn't know CSS it looks
like magic. You can't google it. I think 'constant' is way
easier.
florian: I think we want the extra param on it so if we have $ and
function.
<tantek> "you can't google it" is an interesting critique of any
new symbol-based syntax
TabAtkins: A function names $ so $(stuff)
fantasai: These are environment variables so you could use the
entity.
<fantasai> env() because these are environment variables
<florian> +1 to env()
myles: Other programming languages let you use $ for things that
do vary.
Chris: I quite like env option. It's an environment variable.
TabAtkins: Except we want people be able to set the custom ones.
Chris: Ah.
TabAtkins: We recognized a lot of variables are a single global
set at the root and the entire inheritance machine for
that is a lot. We're working on if a variable is only
set on the root we pop it in a separate storage area.
This would let authors declare this sort of thing.
TabAtkins: So you set it once and you have a global variable
across the page.
smfr: So you want the same syntax for that and these?
TabAtkins: Names would have to be -- prefix to distinguish name
space.
fantasai: How to declare?
TabAtkins: Options. Suggested JS API so you can monitor in JS and
watch for changes so you can respond to them. If we
have that structure it will give you read only access
to these. We can allow write access too if it's in the
right form. That's the basic.
fantasai: That's not a good answer.
TabAtkins: That's the basic.
fantasai: I don't consider that basic.
TabAtkins: Secondary is an @'function name' rule in your
stylesheet. Give it a name and a value. It looks same
as property, but as an @ rule. Only problem there is if
you want to respond to changes we need to expose it in
some JS API. So you either delve into CSSOM or we have
to do some mapping between a JS object.
TabAtkins: I have suggestions to this in a thread from where dino
is suggesting edits.
TabAtkins: Current idea is the big JS API can also be used from JS
to demote both user and UA defined ones. @global lets
you do it in stylesheets and they grow a similar
map-like object that's a proxy. Therefore if you need
to watch the values you can do so, but if you want to
set up in JS you can do that. Whichever is best for you
you have access to.
smfr: How does that impact the naming?
TabAtkins: Not at all. Whatever the function name is the @rule is
similar.
smfr: Does it promote any of the options?
TabAtkins: I don't think so. Any of the ones we've come up with
are available and reasonable to read.
smfr: Can we try and resolve on a name?
Rossen: I heard env and global in the running
smfr: Let me type them.
<smfr> options: constant(), const(), env(), global()
smfr: Those ^
<fantasai> prefers env() out of that list
<bkardell> I will go against the grain and say I like const()
actually
Rossen: So constant and const() since they do change can we rule
those out?
<florian> prefers env, ok with global
fremy: global is what I prefer. I quite like the $, but of those
global is most clear to authors.
<dauwhe> "env" seems most descriptive
<bkardell> prefers env
Rossen: I see some people saying env, some people global. Which is
easier to understand for non-English native speakers?
??: I voted for env
Chris: The problem with env is it doesn't work for everything that
TabAtkins does.
TabAtkins: It's the same as for what bash uses.
<bkardell> author-env variables like bash
<bkardell> yes, what tab said !
<Chris> I like env
Rossen: Let's try and resolve on env. Let's get this one on the
books for now.
Rossen: Objections to renaming what was constant variables to
environment variables using env()?
smfr: I'm not particularly happy because we have an impl, but I
guess we can change.
TabAtkins: Given there is 0 spec text, I think we'd be angry if
you pull a we can't change due to impl.
RESOLVED: Rename what was constant variables to environment
variables using env()
<hober> much prefers constant() to env()
Rossen: Did we resolve on the list of predefined?
smfr: Well what spec do they go in?
fantasai: variables
Rossen: variables L2?
TabAtkins: Either own or variables. Variables 2 is good.
Rossen: Makes most sense given how far variable spec is.
Rossen: Obj adding this as ED of variable L2?
<tantek> seems reasonable
<fantasai> sgtm
<Chris> +1 to variables-2
<bkardell> +1
RESOLVED: Add this as an ED of variables L2.
Rossen: Editor?
smfr: I think I'd like to say dino will do it.
TabAtkins: He put text together so he sort of self-volunteered.
Rossen: Object?
RESOLVED: Add dino as an editor of variables L2 with TabAtkins.
Rossen: Now that we know what we're calling them and where, what
will be the initial set of predefined values?
Rossen: Should we take this back to github?
florian: I think so.
smfr: We'd at least like safe area top, bottom, left, right.
TabAtkins: Let's get a list in GH.
fantasai: I think we can resolve on those 4 values.
Rossen: Objections to adding the initial set as safe area top,
bottom, left and right?
RESOLVED: The initial set as safe area top, bottom, left and right
<fantasai> Further additions to the list should go into their own
issues.
Events for stickiness changes
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/1660
Rossen: Summary, issue is someone asked if we can have an event to
be able to know when the element goes into a stuck state
and if it transitions to unstuck.
Rossen: There were a few suggestions given, fremy pointed out if
you use intersection observer everything works. After a
little while people confirmed this is the case. They
proposed to close no change.
Rossen: I want to hear if you agree with this.
smfr: I agree
Rossen: Objections to close, no change?
RESOLVED: Close issue 1660 no change.
Using non fixed size SVG in the cursor property
-----------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1813
Rossen: Thanks florian for progress updates. Remaining issue is
non-fixed size SVG as cursor.
<tantek> hmm - I thought we solved that by referencing a profile
<TabAtkins> https://drafts.csswg.org/css-images/#object-sizing-examples
florian: We mandate support for SVG and forgot to say anything
about those without an intrinsic size. For general SVG
there is support, but no one supports it without
intrinsic size. I'm not seeing progress despite having
bugs, so therefore I think we should change the spec,
maybe to a may.
florian: It's defined how you would do it, but nobody is.
Chris: There is clear spec text to say what to do. It's not a case
we can clarify, but no one seems to want to impl.
TabAtkins: Does anybody allow other sizeless types?
florian: Not, but they're a may.
TabAtkins: I'm fine with it in same category as those.
Chris: I am too, but won't be fixed by same method so that's even
more of a may.
dbaron: One comment is that when we change things in order to
weaken requirements to have impl, I'd like to have notes
to say what we intended so that people 5 years from now
know why it's a may.
florian: The behavior is not tied to SVG, it's anything without a
size. So that would stay in and I would add prose to say
if svg doesn't have intrinsic size you may support it.
I'm happy to add spec text saying we wanted it.
tantek: I think I agree with dbaron's point to add a note to give
the intent of the group, but I kinda disagree with leaving
it in as a may for something never implemented. If we had
one implementation I'd be comfortable, but given no one
implements that means it hasn't been incubated.
Chris: In abstract I agree, but on this do you see a specific
issue?
tantek: I don't, but I wouldn't know until we try and impl. It's
unknown unknowns.
Chris: It's the do we add 32 32 problem. This isn't rocket science.
tantek: In this case I'm going to say display density is highly
variable and changing.
Chris: Okay.
TabAtkins: I don't understand why density is relevant. There's a
size the UA uses for the default to render cursor.
<fantasai> tantek, if we don't allow this with a MAY we have to
forbid it, which means any implementation that tries
will be non-conformant
Rossen: Let's step away from process and go back to the issue.
Rossen: I didn't hear anyone disagree that the current lack of
support suggests we might have to weaken current spec text
with a may. Is this something people are objecting to? Or
is this how to do better as spec editors.
tantek: I am.
tantek: I propose we do a note instead of normative text.
florian: We can't do that instead of a may.
florian: If we do a note instead of a may, we fallback to you must
support svg or you must not support. That's not a good
idea.
<tantek> the point was to explicitly *drop* from normative text
what has not been implemented, AND add the NOTE: with
explicit text indicating consensus intent of the WG
<fantasai> tantek, you can't "drop" the text, you can forbid the
implementation of this subset by *adding* text
Rossen: Can I hear from dbaron? I understood it was a may with a
note saying it wanted to be a must.
dbaron: They're different points. I'm saying when we make changes
to enter PR we should say what the old thing way.
florian: And I'm happy to do that.
dbaron: And that's different then tantek's point.
Rossen: And tantek is about process which I don't want to do now.
Rossen: Objections to changing a the must to a may for svg cursor
and add a note explaining the intended must behavior?
tantek: I object because that's not reflecting what florian wants.
florian: It's a specific case.
tantek: The way you phrased it isn't florian's proposal.
florian: Rossen you said svg in general, it's just the
non-intrinsic sized ones.
Rossen: florian can you put the actual text?
Rossen: thanks for the correction tantek
<florian> PROPOSED RESOLUTION: SVG without intrinsic dimensions
MAY be supported (not MUST), add a note
<tantek> alternatively how about restricting the MUST to intrinsic
sized SVG?
<tantek> and then just leave non-intrinsic sized unspecified, and
documented in the NOTE?
<tantek> see alternative
<fantasai> tantek, you'd have to explicitly undefine it to make it
undefined, it's defined in css-images
Rossen: Objections to florian's proposed resolution?
<tantek> -0
fantasai: I agree with that.
Rossen: Anyone favor tantek's?
florian: It's editor wordsmithing.
Rossen: Objections to florian proposed resolution?
RESOLVED: SVG without intrinsic dimensions MAY be supported (not
MUST), add a note.
<tantek> Florian I still think including normative spec text for
something never implemented is a bad (risky) idea in
general, even if in "this instance" it seems likely ok (
per Chris's points). It sets a bad example and precedent,
and I'd prefer if we encouraged trending toward more
conservative normative spec text when attempting to exit
CR.
<tantek> that is, rather than MAY for something unimplemented, we
choose the "explicitly undefined" and NOTE with details
we had consensus intent for in the WG.
<TabAtkins> tantek I don't see the meaningful difference in those
two wordings?
<tantek> TabAtkins normative vs. informative text. Keeping it
informative allows for more implementation
experimentation (contradicting any such MAY even) without
being non-conformant
<tantek> MAY allows for non-implementation, but AFAIK does not
allow for contradicting it.
<TabAtkins> So your fear is that implementations might want to
size SVGs for cursors in a totally different way than
they do any other image?
<tantek> in general I'm opposed to aspirational normative text at
this point.
<tantek> TabAtkins yes I'm claiming it is a case of sufficient
possibility of unknown unknowns as to be lower risk to
unspecify than specify as MAY.
<TabAtkins> I disagree that this has any reasonable fear of having
unknown unknowns crop up. It's unimplemented due to
low priority, not due to it being hard or confusing.
Meta bug for line height
------------------------
github: https://github.com/w3c/csswg-drafts/issues/1796
florian: I still want people to review. There hasn't been review
in github. Repeating subject:
florian: I wrote a bunch of test cases to figure out if we're
interop on various aspects of line-height. First, please
confirm tests are right. Area I found we're not interop
is a bit deeper on something discussed where first
available font doesn't include the space character.
florian: That's and the font file for font metrics are only places
with changes. Please, please review my work. This is
intricate.
Rossen: Anyone have reviewed? If not, we can consider this a CTA
to give feedback.
Rossen: Okay. Please give feedback to florian.
fit-content() vs 'stretch' alignment
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1732
Rossen: fantasai can you take this?
fantasai: I haven't looked lately. Looking now.
Rossen: I think you brought this up 3 weeks ago.
fantasai: I think in order to make progress on writing modes we
should do florian's extra.
Rossen: Grid issue you want to discuss on GH?
fantasai: no...it's okay.
fantasai: Issue was we have a stretch value for align and justify
content. These align and justify grid tracks from a high
level. One of the options is stretch, kinda like flex
lines. If you choose stretch we do so by distributing
space to auto-size columns equally. No auto sized
columns, nothing happens.
fantasai: Question is if it should apply to fit-content or not.
Looks like rachelandrew asked a few authors and they
expect it not to go past argument of fit-content, but
there was a question of should we apply the extra space
at all.
fantasai: For sure I think we can say fit-content doesn't go past
its argument due to stretching.
<rachelandrew> this was the issue as it came up
https://github.com/rachelandrew/gridbugs/issues/9
Rossen: I'm in favor as an implementor.
Rossen: Objections to resolving that fit-content does not grow
past its argument due to alignment stretch.
RESOLVED: fit-content does not grow past its argument due to
alignment stretch.
fantasai: Second is should fit-content grow past it's max
content...if we're below the argument, the clamping one,
do we grow fit-content it the stretch is set.
fantasai: For that question, I don't know. We don't seem to have
any feedback one way or another of what should happen
there.
jensimmons: Alternately the content would not stretch?
fantasai: If there's auto tracks there, if not start.
jensimmons: And they could adjust by not using stretch?
fantasai: Yes, case where it would make a difference is if there's
fit-content and an auto column. They have very similar
behavior except fit-content has additional clamp.
Rossen: This scenario was a canonical example we had originally
when working on grid. The ability to have a menu system
based on size of items inside and let the extra space go
into the rest of the content area. Using fit-content with
auto columns or fr columns was the way to achieve this.
Rossen: If you take away the guarantee of fit-content that's not
just for grid and we start changing what fit-content means
then this is a pretty, in my opinion, radical change.
Rossen: I haven't seen any really strong cases to change that and
I would prefer if we don't (as an impl).
jensimmons: You want to stretch beyond max-content?
Rossen: I don't.
fantasai: Auto will go beyond max-content, but fit-content won't.
Rossen: fit-content was designed to fit-content
rachelandrew: I'd agree with Rossen I don't think people would
expect it to stretch. I'd prefer fit-content stays
the way it is.
Rossen: We're at top of hour.
fantasai: We should go for resolving
<tantek> +1
Rossen: Objections to keep fit-content behavior as-is, to not grow
past max-content in presence of stretch.
RESOLVED: Keep fit-content behavior as-is, to not grow past
max-content in presence of stretch.
Rossen: florian sorry we didn't get to writing modes, but I urge
everyone to look at this issue and we'll discuss next week.
<tantek> please link issue for writing-modes
<dael> writing modes issue https://github.com/w3c/csswg-drafts/issues/1391
Rossen: Thanks everyone.
<rego> I'm late, but I think that the previous resolution
contradicts the last one somehow :-)
<rego> the first resolution was that "fit-content does not grow
past its argument due to alignment stretch"
<rego> but it's affected by stretch
<rego> in the last comments it seems we want it to fit the content
and not be affected by stretch at all
<fantasai> They're not contradictory, the first resolution
restricts what would be possible if it were affected by
stretch
<fantasai> Then we discussed whether it should be affected by
stretch
<fantasai> Because we knew for sure we didn't want to stretch past
the argument, so we resolved on that first.
<rego> fantasai, ok, I understand it now
Received on Wednesday, 20 September 2017 23:50:30 UTC