- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 09 Apr 2018 14:54:27 +0000
- To: public-houdini-archive@w3.org
The Working Group just discussed `Paint API`, and agreed to the following resolutions: * `RESOLVED: Paint function and custom paint function registration does not change.` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Paint API<br> <dael> github: https://github.com/w3c/css-houdini-drafts/issues/751<br> <cbiesinger> s/cbiesinger/??/<br> <dael> leaverou: I was suggesting that since the item with the first param defines what is bieng paited it should be part of the function name. So it should be paint-blah. It reads more clearly and separates it from the arguments. Current situation is very hard to read. It makes the thing being panted the ame level of it's parameters.<br> <dael> leaverou: I think besides the ability issue, it reads much more naturally.<br> <dael> TabAtkins: We decided against the approach back when we were diong var. THe property is --foo and tha var is --foo. This is similar. If you don't have a requirement to regirester your paint functions with the name you have the same problem. If we do require it we can but that feels strange and restricts what we can do later with a sub-version of paint.<br> <dael> leaverou: Variable was defined and references in CSS. Here's it's split between CSS and JS. JS identifier with a CSS function. In var it was both in the same place. THe CSS is consistent with this.<br> <dael> TabAtkins: But one person could have written variables file. The difference of authors applies.<br> <dael> dbaron: Another issue is readability and understanding a new feature you see in code. Witht he combined name you find paint-foo and it sounds like a CSS feature but there's no search results. There's nothing that says the name is part CSS.<br> <dael> leaverou: Because it reads more naturally. YOu're saying make it unnatural so people re confused.<br> <dael> dbaron: Make it two parts so people understand. If you put them together and they look like one thing it's hard for people to recognize it's two pieces.<br> <dael> TabAtkins: When we have custom functions in CSS you can have whatever names you want with a -- at the front.<br> <dael> fremy: I agree with the point it's tricky to parse. One argument I like is auto-completion is getting surpremicy. But I also don't like putting function in.<br> <dael> dbaron: If you want to fix the function you can do a nested function.<br> <dael> leaverou: If your paint takes functions that also have parameters you end up with lists.<br> <dael> astearns: I suggested that earlier in IRC which addresses having the function and it's elements at the same level.<br> <dael> leaverou: What if we came up with a syntax that doesn't have the nested param. What if it's a keyword.<br> <dael> astearns: I'm convinced by dbaron where if you see a function in the value of a css you should be able to search for it to figure out what it is. Having something I can google is easier then knowing some portion would need to be extracted.<br> <ChrisL> good luck searching for 'paint' though<br> <dael> leaverou: Can you imagine this argument in any other language?<br> <dael> TabAtkins: JS swallows the compat issue of user stuff and browser stuff being in the same place. WE stay away from that.<br> <dael> fantasai: None of the param to a function are attached to a name.<br> <dael> leaverou: In JS you can create your own functions.<br> <dael> dbaron: But not that you get an additional name.<br> <dael> leaverou: In CSS you don't have . notation so you can't do what JS does here.<br> <dael> TabAtkins: Exactly<br> <dael> leaverou: Only seperator we have is the hyphen.<br> <dael> TabAtkins: But it's not for separate origins thing.<br> <astearns> (my suggestion for the minutes since I emoted it before) is paint(company-logo()) and paint(chat-bubble(blue)) a terrible idea?<br> <dael> Rossen: Alright. Any more arguments?<br> <dbaron> I wonder if the first could still just be paint(company-logo)<br> <dael> leaverou: What if it remains as an argument but it's separated in another way like a /<br> <dael> TabAtkins: We don't use / unless required by parsing.<br> <dael> astearns: And anything other then nested parans would be confusing.<br> <TabAtkins> It would mean you can't create a function that returns an ident, and use that to select the paint function you want. ^_^<br> <dael> flackr: I also find it confusing because the thing you're defining is a class.<br> <dael> leaverou: That's impl detail to a CSS author.<br> <dael> fremy: I forsee it being used for [missed]. As a css author you only care what you give to the conic gradient.<br> <dael> leaverou: As a polyfill I find it harder to say you do a conic gradient and then the other arguments depend on what your arguments are.<br> <dael> leaverou: The one parans give you more places for people to screw up.<br> <dael> Rossen: There is a couple ways to go forward. Discussion is going in two parallels. We can vote to decide on one or the other or we can stop and discuss in github.<br> <dael> leaverou: might be better for people to think so if we continue in GH issue.<br> <dael> shane: I think same argument applies, this is the space where we come to agree.<br> <dael> TabAtkins: It was just brough today, though.<br> <dael> shane: Fair. But if we resolve it's not the end of the world we can revisit.<br> <dael> Rossen: True. We can look for a resolution.<br> <dael> krit: We have the paint function and a resolution for it.<br> <dael> Rossen: We want a resolution to not change so we can mark it in the issue.<br> <dael> Rossen: Before I call for a straw poll, any other closing arguments?<br> <dael> Rossen: I've heard so far strong reasons against changing and readability and usability PoV a preference toward hypenated.<br> <dael> leaverou: And for documentation. It's easier to explain that this is a new function you can use then if you use paint function the first value is fixed.<br> <dael> Rossen: Let's try to resolve by objection first.<br> <dael> Rossen: Would there be objections to not changing the Paint function and custom paint function registration<br> <dael> shane: Does anybody object to closing this issue no change?<br> <dael> RESOLVED: Paint function and custom paint function registration does not change.<br> <dael> Rossen: I would suggest continuing discussion on this.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/751#issuecomment-379780733 using your GitHub account
Received on Monday, 9 April 2018 14:54:51 UTC