[CSSWG] Minutes Telecon 2017-09-20 [css-variables] [css-position] [css-ui-3] [css21] [css-inline] [css-grid]

# Dael Jackson (2 days ago)

========================================= 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

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

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: 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> w3c/csswg-drafts#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 (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: w3c/csswg-drafts#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: w3c/csswg-drafts#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: w3c/csswg-drafts#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> 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: w3c/csswg-drafts#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: w3c/csswg-drafts#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 rachelandrew/gridbugs#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 w3c/csswg-drafts#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

Contact us to advertise here

Want more features?

Request early access to our private beta of readable email premium.