- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 30 Apr 2014 19:59:58 -0400
- To: www-style@w3.org
Charter Update -------------- - Plh plans to send the charter in by the end of the week. CSS Masking LC/Rename mask-box to mask-border --------------------------------------------- - RESOLVED: Change mask-box to mask-border - Krit and fantasai brought the group's attention to the changes made to Masking and asked for review before a decision on going to LC. Proposal to split CSS Text level 3 ----------------------------------- - There was a lot of concern about splitting Text into smaller pieces since they are highly related. -A few potential smaller splits were discussed and a look into what pieces were holding the spec up most was advised. - The details of a potential split was declared to be perfect for a F2F conversation. Calc() in MQ ------------ - RESOLVED: No change to calc() in MQ Box model/Render tree --------------------- - Due to the lack of immediate concern, this was declared another great F2F topic. inline-x auto-sizing -------------------- - There was some concern about it not being easy to standardize atomic inlines. - Fantasai will come up with some proposed text. Changing MediaQueryList to use events ------------------------------------- - Defer to mailing list. Scrollbar Stickiness -------------------- - Also staying on the mailing list. Adding any-pointer and any-hover MQs ------------------------------------ - There was a request for more time to read up about this proposal. - MaRakow and TabAtkins will discuss technical details about the proposal on the mailing list. officially using the behavior of 'animation' wrt parsing <custom-ident>s in properties. ---------------------------------------------------------- - TabAtkins stated that he needs to go back to this text and come up with another draft before consideration. Seoul F2F --------- - WG members were reminded to add discussion topics to the wiki - Anyone that hasn't already reserved their hotel room show do so ASAP. Variables --------- - RESOLVED: New LC for Variables Revisiting calc() and whitespace -------------------------------- - Zcorpan drew attention to his e-mail with the same subject and requested review for discussion on next week's call. ====FULL MINUTES BELOW======= Present: Glenn Adams Rossen Atanassov Tab Atkins David Baron Bert Bos Dave Cramer Elika Etemad Daniel Glazman Koji Ishii Dael Jackson Brian Kardell Philippe Le Hégaret Shinyu Murakami Edward O'Connor Simon Pieters Matt Rakow Florian Rivoal Simon Sapin Dirk Schulze Alan Stearns Greg Whitworth Steve Zilles Regrets: Brad Kemper Peter Linss Michael Miller Anton Prowse Lea Verou (briefly in attendance, but had connection issues) ScribeNick: dael Charter Update -------------- glazou: Let's start glazou: We have a full agenda, but any extra items? glazou: Sorry for that glazou: Any extra items? plh: I can do a short charter update. plh: So I've got all the necessary stuff to send the charter to AC. plh: I expect to send by end of the week at the latest. glazou: Any questions? CSS Masking LC/Rename mask-box to mask-border --------------------------------------------- <krit> http://dev.w3.org/fxtf/css-masking-1/#box-masks glazou: So the first issue is the rename. krit: This was a request from the last call. The reasoning was mask-box is similar to border image so it mostly affects ordering. krit: The request to was rename to mask-border since that describes what it does. krit: The cost for that is that boxes have a border. Also box is a rectangular shape so that might be good for SVG shapes. krit: But I don't have a preference. I like box or border. I'd like to hear concerns about renaming. fantasai: I'd like to note there's other things for masking. One related is there's a fill keyword in mask-slice which is similar to border image. fantasai: Like border image, mask doesn't affect the middle so it is like a border. krit: So that would be a vote for mask border. krit: Any other issues/concerns? rossen: Did any reasons to not rename get raised on the mailing list? krit: Just my pros and cons. rossen: So it sounds like no one else objects to border? krit: No. rossen: So it's fine than. glazou: So is there any objection? rossen: The only one is there's the mask-border...There's left, right, top, and bottom parts and for mask even though it can be just a single border? krit: There's a mask border property in the future that takes four arguments. It's an offset for tiles. There isn't longhand for each side. krit: Does that answer your question? rossen: Yes. It's going to be like borders in that respect? fantasai: Borders can't take image. It doesn't have per-side. There's one setting for the whole box. rossen: Ok. <dbaron> So this is the mask property that's analogous to border- image, and we're now calling it mask-border? krit: So can we get a resolution? rossen: One more. Do you want to change to mask-border to reserve the shorthand or is border-mask another option? rossen: As fantasai pointed out, I'd expect the border-mask so that way it would be clear. fantasai: If it was border-mask, I'd expect only border to be affected but this does the whole element. fantasai: So I think mask-border is correct. If we add border-mask that would just do border. rossen: That would be crazy. fantasai: Yes. My point this the effects the whole thing. rossen: Are we sure we'll never do that? fantasai: I don't think we can ever be sure. rossen: By choosing mask-border we prevent border-mask. fantasai: Well, if we choose that now we can't have border-mask. rossen: So you think that this won't prevent things in the future? fantasai: We can never know for sure about things in the future, but hopefully it'll be fine for now. glazou: dbaron asked in IRC if mask property is analogous to border -image and we're now calling it mask-border fantasai: Yes. glazou: So is there any objections? RESOLVED: Change mask-box to mask-border glazou: So back to item 1 on the agenda. LC for masking? fantasai: There's more issues I think we should discuss. glazou: That's the only one I was told about. fantasai: One was there's mask-type about using alpha or luminance to interpret image, but there wasn't an analog to mask- border so we added that type. krit: Biggest change was that I added layers to mask property similar to background and mask-composite to allow you to composite layers. <krit> http://dev.w3.org/fxtf/css-masking-1/#the-mask-composite krit: That's linked here (above) krit: What I want to do is ask for 1 or 2 weeks review so everyone can look at the changes and then go to LC if there's no objections. glazou: What do people think? fantasai: I'm in favor of review period. Several: yes glazou: Any objections against that? [silence] krit: Do we want to bring it up during the F2F? krit: Or do we just go to LC automatically? fantasai: I think we should talk again. glazou: I agree. I think 2 weeks review and all questions can be addressed in the week before the F2F since that's a bit more than 2 weeks. glazou: So that's a good time to discuss issues. krit: Okay. Action everyone review CSS Masking and send comments <fantasai> lea, can you help get feedback on the spread radius changes from the authoring community? <leaverou> fantasai: yes, but I will need some help on what to ask Proposal to split CSS Text level 3 ----------------------------------- <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2014AprJun/0036.html [Members only list] koji: The idea is the spec has been split several times. In the LC we have more than 70 issues and I think that means that it just keeps getting issues and therefore delayed. fantasai: My concern is with the fact that a lot of these features are interrelated so I'm hesitant to split the spec more than before. fantasai: Maybe if we have a solid base as 3 and do additions as partial modules, but I think I'd prefer to churn through the issues. fantasai: I think the problem is no one looked at the spec until we are in LC koji: Like textbox is interactive so there will be interaction between specs. I don't see... fantasai: The relation between justify and align and spacing is very tight. It's not just vocabulary. If you change the alignment, than justification changes. koji: I agree. <Bert> q+ to ask if we know what part is the slowest and if we can put some effort into solving it. koji: Perhaps it should have spacing in that one spec. koji: Maybe break out white space and text transformation. fantasai: We could, but that's too small. koji: Okay. koji: Um. Bert: I'm still undecided for what's best, but do we know what's the slowest part and can concentrate on that? Bert: If you don't know the slowest, maybe splitting is the only way, but I'd rather keep it together. rossen: Is it possible to focus on the hard problems first and after that reconsider a split? glazou: Unless there's a firm proposal, I suggest we go to e-mail. koji: What to e-mail? glazou: The discussion on how to split. Otherwise we'll spend a lot of telecon time rossen: Is the question how or if? krit: I think the biggest problem is that the spec can grow. In the last TPAC Kenny raised indentation questions and that added to the spec. krit: On the other hand line break and alignment do require discussion. The size and broadness is making progress slow. glazou: Okay. rossen: So back to the list? glazou: That or dedicate F2F time. glazou: We have to have a really complete discussion in the same room. glazou: It's too big for telecon time Calc() in MQ ------------ TabAtkins: This topic was raised by zcorpan. TabAtkins: He thinks calc() is low value in MQ so we should disallow it to simplify MQ. TabAtkins: I disagree and think language consistency is preferable since calc() is just a length and it should be allowed everywhere length is in CSS. TabAtkins: Making arbitrary wording due to implementor concerns makes the language harder to learn. glazou: I don't think he was arguing on implementor constraints, but on use cases. glazou: But I agree that consistency matters and I'm with you on that front. TabAtkins: He did also raise for implementor issues because we're using it in sizes and that does make it more complex. zcorpan: My main reason was lack of use cases, but it seems there's implementor interest so if browsers will implement it I don't object. florian: Implementor interest is there, no one has said it's a bad idea, but no one is rushing to it. zcorpan: I saw Mozilla had interest in implementing as well. zcorpan: I raised this because we're doing authors a disservice if it's not implemented but we pretend it exists. fantasai: To help on that front, maybe add a note on level 3 saying calc() isn't there, and say on level 4 that we are including it, but it's at risk. fantasai: That way it's clear that anyone using MQ3 it doesn't have calc() florian: But why would MQ say anything about that? TabAtkins: It should be where lengths are allowed. hober: I'm fine with fantasai's suggestion, but I think it's easier for us to restrict it now then realize it's a mistake and restrict later. florian: MQ3 is already a rec and I'm not sure we should edit a rec to remove something we're planning to add later. It doesn't mention calc() in the first place and if we want this it feel better to talk about calc() than MQ TabAtkins: And some people are planning on implementing calc() in MQ now. TabAtkins: Since zcorpan drops his objection if there's implementors, I suggest no change. TabAtkins: Any objections to that? <SimonSapin> +1 zcorpan: Works for me glazou: Other opinions? <glenn> +1 SimonSapin: I agree several: I agree glazou: So any objections against no change? RESOLVED: No change to calc() in MQ Box model/Render tree --------------------- TabAtkins: I think this is best addressed at F2F. TabAtkins: It's more blue sky. Something for the future. glazou: Bkardell, does that work for you? bkardell: I won't be at F2F, but it works. glazou: Can you join for one part? bkardell: I think so. TabAtkins: I can try and represent for him too. <SimonSapin> (I unfortunately won't be at the F2F either but I'm interested to call in for this) inline-x auto-sizing -------------------- <glazou> http://lists.w3.org/Archives/Public/www-style/2014Apr/0225.html glazou: fantasai, this is you. fantasai: What was it again? glazou: It was from last week's call, plinss had it on. SimonSapin: It talks about generalizing the width calculation with non replaced atomic inlines. TabAtkins: This is asking for 2.1 errata generalizing something that's for inline-block right now to apply to all atomic inlines glazou: Is there anything to discuss on telecon for now? fantasai: Well, does anyone object to the idea or should I come up with wording to propose an errata? bert: Nothing to object, for CSS2.1 it seems like you might say the same thing. fantasai: We have the flex so if this was changed to all atomic inline, other specs could just say it's atomic inline and than other specs won't have to duplicate and we reduce errors. bert: I'm not sure that helps. For example, baseline alignment various atomic doesn't work the same. fantasai: This is just margin and width bart: But the concept.. fantasai: The concept exists in CSS2.1 already. <SimonSapin> q+ to say that inline-table is an atomic inline but is special sizing behavior, IIRC * florian sorry, got to leave. If we reach topic 10, I defer to Tab SimonSapin: I wanted to mention there are inline-tables that have special sizes so perhaps it won't be that easy to generalize. ??: What did he say? glazou: fantasai, can you repeat what SimonSapin said? fantasai: He said that inline tables have a special sizing so perhaps it won't be that easy to generalize <SimonSapin> I'm not sure, though glazou: It seems this requires more work or at least a text proposal so let's decide that approach and move on. Changing MediaQueryList to use events ------------------------------------- <glazou> http://lists.w3.org/Archives/Public/www-style/2014Mar/0603.html glazou: Do we need to continue the discussion on this? glazou: Anyone willing to continue, or do we move on? TabAtkins: I haven't picked this up on the list so I need to do that. Scrollbar Stickiness -------------------- glazou: Same question here. <glazou> http://lists.w3.org/Archives/Public/www-style/2014Apr/0112.html TabAtkins: This would also benefit from staying on list. Adding any-pointer and any-hover MQs ------------------------------------ TabAtkins: Currently the pointer and hover let you query aspect of the pointing device and is defined as whatever the primary pointing device is. TabAtkins: For example, a touchscreen laptop has the touch screen and the pointer. This becomes hard when you do something like plug in a mouse. TabAtkins: We wanted to know user's probable interaction and what they might be able to do. TabAtkins: We let it determine what's the most likely thing for users to use, on a touchscreen laptop it's the trackpad etc. TabAtkins: Hover does all the values that might be on the screen, it just tells you what the user might be capable of. TabAtkins: I think this addresses a larger issue rather elegantly and I want to add this to MQ, but I'm wondering about other thoughts glazou: Comments? rossen: I'm not caught up on this one, but I'd like to run this by others. Can we wait a week? glazou: Is that okay for you? MaRakow: I was looking at this and I think the challenge is along the lines of... it's look at this a course or fine. MaRakow: This is fine if there's just primary and secondary, but if you end up with more tiers it's limiting. TabAtkins: Do you have examples where primary might be hard? TabAtkins: On my chromebook the touchpad is primary, screen secondary. Every example I can think of one can be reasonably assumed as the primary and I think it's okay to play favorites. MaRakow: My main thought is what you're trying to do is negotiate between what's best for the device and what's best for the author. If I have 3 options you can rank those by what's best MaRakow: And then you can correspond precedence. But when you have multiple tiers and the author has things for 2 and 3, does it use 2 not 3? TabAtkins: So the thing is the pointer can smash all them together? MaRakow: Maybe this is best on the mailing list, but I think that picking an input is more complex here. TabAtkins: Okay. TabAtkins: We can get more detailed with technical details on the list, I'm happy with that. glazou: Anything else on this topic? TabAtkins: No. officially using the behavior of 'animation' wrt parsing <custom-ident>s in properties. ---------------------------------------------------------- glazou: We had a comment on this from Xidorn the public ML. TabAtkins: That comment confuses me because this is what I thought he was asking for which means I misread. TabAtkins: I need to go look into what he wants and withdraw this text. glazou: So nothing to discuss now. Seoul F2F --------- glazou: We have time, anything else to discuss? glazou: One thing before anyone else adds items, I think plinss mentioned this, but we need F2F items. Please place it on the wiki. glazou: If you don't have a hotel room, please book soon. Variables --------- fantasai: Variables hasn't had anything since LC last year. TabAtkins: I've been working on comments. TabAtkins: Last resolution is CR once I finish the DoC. TabAtkins: I've made significant changes so we should republish as LC. TabAtkins: So if we can get that with a 4 or 6 week waiting period I'd be happy. glazou: When were the last significant changes? TabAtkins: A month-ish ago. glazou: Did people review? TabAtkins: The implementor, Cameron, did. fantasai: The major changes were call discussed, right? TabAtkins: Yes. glazou: I wanted to make sure no one would object to LC without review here. glazou: So any support, objection, or whatever to the LC? TabAtkins: I support it glazou: I do to <astearns> support publishing <glenn> +1 fantasai: We need it publish, so I support. glazou: Any objections to new LC of Variables? RESOLVED: New LC for Variables TabAtkins: I can prep today. Can we publish this Thursday or wait for Tuesday? bert: I have holiday tomorrow so won't be available and don't want to risk it tonight. glazou: Most of Europe is on holiday tomorrow. TabAtkins: I'll prep for Tuesday. Bert: Tuesday is fine. glazou: Anything else? fantasai: Anything else to publish? Revisiting calc() and whitespace -------------------------------- <zcorpan> http://lists.w3.org/Archives/Public/www-style/2014Apr/0480.html [css-values] Revisiting calc() and whitespace zcorpan: I have another topic, I just sent an e-mail regarding calc() and whitespace. zcorpan: My proposal is don't be fussy with whitespace. We changed parsing to allow white space around + and - and it seems silly to not support it. dbaron: So just changing parsing means it's required in some place not others which is confusing. fantasai: I think the previous concern is still valid. glazou: In you're e-mail, the 4th calc() example, do you want that valid? fantasai: That's invalid. glazou: It is now, but zcorpan says it's hard to explain zcorpan: I want it valid to 1+ not 2+ <TabAtkins> That is valid in JS: `1 + + 2` == 3 <SimonSapin> calc(10px + -2px) ? fantasai: I'm leaning no change here. zcorpan: We can think over this and discuss in a week. TabAtkins: Yep. glazou: Okay. It'll get discussed on www-style since it was just posted. glazou: Anything else? glazou: Okay. It's a short call. Thanks everyone and we'll talk next week.
Received on Thursday, 1 May 2014 00:00:25 UTC