- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 23 Apr 2015 11:35:51 -0400
- To: www-style@w3.org
Pre-wrap and White Space Processing Followup -------------------------------------------- - Everyone was encouraged to read the email from Florian outlining the different implementations and possible solutions. - Discussion will continue on the mailing list and this will possibly become a F2F topic in May. Which spec for column-span: <integer> -------------------------------------- - RESOLVED: New ED for the next level of multi-col - RESOLVED: Add just Florian as editor for the time being Media Queries ------------- - The grammar for <media-condition> will be changed to avoid requiring looking ahead by an unbounded amount. - TabAtkins and Florian came up with the right behavior set for @media not (unsupported-media-feature) vs @media not (unsupported+syntax), but it's different from previous proposals, so they'll contribute their new idea to the mailing list for further discussion/objections before hopefully getting resolution next week. - TabAtkins and Florian came up with a proposal to address custom MQ before an @import and will write the proposal for the mailing list. Font MIME Types --------------- - RESOLVED: Font MIME type registration is out-of-scope for CSSWG, FontsWG has a (partial) list, forwarding issue to them Allow Extended Hebrew Counters ------------------------------ - RESOLVED: Add that people may support larger Hebrew counters if they want - RESOLVED: Re-publish Counter Styles CR with the above addition Ruby inlinize algorithm ----------------------- - The spec authors need more time to consider this question. Addition of a ::flex-line pseudo-element ---------------------------------------- - This addition might be good for a future level of flexbox, but not for the current level. Naming issue for cursor: default -------------------------------- - Consensus was that renaming the global default was the least-bad option and the name bikeshedding will happen on the mailing list. ===== FULL MINUTES BELOW ====== Present: Tab Atkins David Baron Bert Bos Bo Campbell Dave Cramer Tantek Çelik Elika Etemad Simon Fraser Daniel Glazman Tony Graham Dael Jackson Brad Kemper Chris Lilley Edward O'Connor Simon Pieters Anton Prowse Florian Rivoal Andrey Rybka Simon Sapin Alan Stearns Johannes Wilm Steve Zilles Regrets: Rossen Atanassov Sanja Bonic Adenilson Cavalcanti Alex Critchfield Peter Linss Michael Miller Takayuki Tsukitani Ian Vollick Greg Whitworth Scribe: dael glazou: Let's start. glazou: First thing, anything to add to the agenda? Florian: I was saying I have a few more things, but since the agenda is full I can ping you to add them next week. glazou: If you want to be sure they're added, drop an e-mail to plinss and myself. zcorpan: Starting next week I will be away until mid-Aug. Pre-wrap and White Space Processing Followup ============================================ <Florian> https://lists.w3.org/Archives/Public/www-style/2015Mar/0386.html Florian: Here's the e-mail. We discussed this a while back, but I had one problem because some of what I had was only partly accurate. Florian: Starting again, we have an interop problem with white-space:pre-wrap. There are three behaviors out there and IE, Webkit/Blink, and Firefox all disagree. Florian: In some cases IE disagrees with itself and does different things in textarea vs regular elements. Florian: Overall if you combine the properties you can't really control how things work. I think that's unfortunate. The mail explored who does what. I think there are a few useful behaviors using these properties. It would be nice to be able to switch between those properties, but right now you can't do that with switching. We should aim for more interop. Florian: I'm not sure we can discuss on the phone call because I think we need to look at drawings. I'd like to encourage people to look on the ML and we can have a discussion here on the high level on if interop is a desirable thing. <fantasai> +1 to f2f <andrey-bloomberg> +1 for f2f glazou: It can serve as a reminder for everyone to look at the e-mail and have it at the F2F. tantek: Is this errata? fantasai: CSS3 Text errata and new properties Florian: I'm not sure it needs new properties. We can probably get there with existing properties to describe it, but there's currently a lot of ambiguity. There's also spec violations. If you combine undefined behavior, ambiguous spec prose, and spec violations you get all these behaviors. Florian: Last time there was feedback from MS and Apple saying they didn't want to change, but given that there is no interop I'm not happy with that. I'd like to hear from the rest of the group on if they want progress. <andrey-bloomberg> +1 for interop as well fantasai: I'm happy to work on it but if implementors don't want it they'll ignore it. Florian: I'm a bit uncomfortable with not wanting to change something that isn't interop. But if browser vendors don't want to change that's tricky. fantasai: Given that everyone is silent, we can work on it and people can object. <Bert> (Very good e-mail by florian, by still best to use a white board, I think... I don't like spaces that collapse to zero- width, b.t.w.) <dbaron> I think interop is useful; these issues don't seem like the top priority for authors, but making simple changes seems like it could be valuable. * ChrisL would like to know why the browsers are not interested in interop here Florian: So look on my mail, I think I've worked out what everyone does, and I've proposed alternatives on what we can do. I'd like feedback. I can do it on ML or bore everyone at the F2F. fantasai: I don't have time until then anyway. glazou: So we'll revisit when there's more input or the F2F. Which spec for column-span: <integer> ===================================== <glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0496.html fantasai: Do we have any implementors? Others than Presto? <ChrisL> do we have any *maintained* implementations? Florian: This seems useful to me. Does Bloomberg have an impl of this? andrey-bloomberg: I don't remember. Let me check. fantasai: I think it's great that Presto implements this, but we dropped it from multi-col and it ended in GCPM. If there's no interest in impl we should drop. <Bert> Prince applies column-span: number to floats, I think. Florian: Bloomberg has an implementation. It was in a spec, but dropped because the spec was re-purposed. It's unfortunate to drop when there's two impl, even if they're minor implementations. johanneswilm: This was in page floats. The only reason it was removed is there were many different definitions and this seemed unrelated to page floats. johanneswilm: So the discussion was if it should be in its own spec or if it should sit somewhere. Florian: I can start a multi-col level 4 while we wait for other things. fantasai: The logical place is multi-col. If this was minor feature impl by a few minor things...it's great to document but layout features take a lot of work. If there's interest in impl this going forward we should have this. Florian: Bloomberg has this and would like to contribute, but that's hard without a spec <andrey-bloomberg> just to clarify Bloomberg commits are going to chromium and hopefully upstream fantasai: This goes in multi-col, but that needs a lot of work and so you're volunteering to take on a layout spec. Florian: I'm not volunteering to take on the whole spec. I can create a new level until someone is ready to take it on. I'd be fine with it going at the bottom of page floats. fantasai: If you want progress it needs to be in a multi-col spec and work on the interactions. If you want a place to copy it, there's a copy on TR. If no one is going to work on it we can get it out of the way. If you want to work on it you need to do it with all the layout interactions. Florian: I'm willing to work on it and the interaction with layout, but working on multi-col in the whole is more than I can take on. I can work on this feature, but not the entire module. fantasai: I don't have a problem with you trying, but I want you to keep in mind that it wouldn't fit together unless multi-col has more riggor. Florian: I'm happy to keep it somewhere else, but dropping from all specs is a bad signal. fantasai: I don't want it in page floats because it's not a page float. We drop it or put it in multi-col glazou: That makes sense. <SteveZ> +1 to fantasai's position <tantek> +1 fantasai Florian: Are we comfortable with starting a new level of multi-col and I put that there? <dauwhe> +1 to put in multicol 2 <Bert> +1 fantasai: Start an ED and put it there with an issue where the rest of multi-col has to go there. glazou: Is there agreement on that? <johanneswilm> +1 glazou: Objections? RESOLVED: New ED for the next level of multi-col Florian: Should I add the level 1 editors to level 2? glazou: So editors. Florian you'll be an editor? Florian: I can be for that part, but not the whole spec. I'd like the previous editors to stick. fantasai: That was Hakon. Florian: I think we have a resolution to add Rossen as well. glazou: Since Rossen isn't here, I suggest you start with just yourself and we'll add new editors. Florian: I can respond to comments on multi-col on other topics, but I can't commit at lot of time. RESOLVED: Add just Florian as editor for the time being Media Queries ============= glazou: There's 3 remaining issues for Media Queries. <glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0419.html Florian: Do we have TabAtkins? glazou: He's calling shortly. Florian: Let's wait for him. glazou: jdaggett are you on for your topic? glazou: dbaron you had an issue? <glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0508.html dbaron: Didn't TabAtkins say he fixed it? I don't think it needs telecon time either way. <dbaron> yes, tab said he fixed it in https://lists.w3.org/Archives/Public/www-style/2015Apr/0265.html <glazou> thanks dbaron <media-condition> grammar requires unbounded look ahead ------------------------------------------------------- <Florian> https://lists.w3.org/Archives/Public/www-style/2015Mar/0419.html Florian: The first issue is this, raised by SimonSapin. Florian: The spec is phrased in a way that it requires unbounded look ahead. It can be expressed equivalently. Re- phrasing to make it so would be possible, but would make the spec hard to read. TabAtkins: I'm fine with rephrasing. We have the railroad diagrams to make it easier to read. I'm fine with getting the grammar to point to better impl. Florian: I was worried about the prose afterwards. SimonSapin: We did make a similar change to paged media spec of the same reason, but it's not clear if it's a requirement or a goal of CSS specs to not have look ahead or if that's just impl detail. TabAtkins: I think it is a strong goal. Given we did it with paged media, I'm fine with rephrasing it. It's fine. Florian: Let's give it a shot and if it gets horribly confusing we can back up. TabAtkins: Worst case I put a note with an alternative approach that doesn't have the unbounded look ahead. @media not(unsupported-media-feature) vs @media not(unsupported+syntax) -------------------------------------------- Florian: Next is this: <Florian> https://lists.w3.org/Archives/Public/www-style/2015Mar/0514.html Florian: Currently the <general-enclosed> parts of MQ work the same as @support. That's prob a mistake because @support returns false when it can't parse, which is sensible, since something that cannot be parsed is certainly not supported. But that's a problem for MQ. Just because you can't parse something doesn't mean anything with regards to the environment. It should have the same error handling where it invalidates the entire MQ. SimonSapin: This matters because it adds a not operator that can be used anywhere in MQ. TabAtkins: [pondering noise] Florian: Were you trying to make sure why you disagree? Do you have a reason to think it might be better the other way? TabAtkins: I recall us discussing this specific case where you 'not'ed a thing that was invalid and I don't recall the conclusion. Florian: Back when you could only 'not' the whole thing this wasn't as bad. TabAtkins: I think this was when we added the boolean logic. Florian: I don't recall that discussion, but I think MQ and @supports should be different here. TabAtkins: I'm provisionally okay with this. I'll find the old discussion and re-raise it if I find an issue. Florian: So should we resolve, or wait for you? TabAtkins: Resolve now. The argument is good. If I find a reason why it's this way I'll re-open. fantasai: There is a special case for media type where if you don't recognize the type you're not that type. Florian: Yeah, I'm not changing that. Just the enclosed part of the grammar. SimonSapin: What's is the change? TabAtkins: Change the error handling so general enclosed stays as it is, if it matching the entire thing it invalidated the entire thing. SimonSapin: Isn't that the same as others? Florian: It is. Currently though it works as @supports. SimonSapin: But changing the evaluation would be the same thing as removing entirely I think. Error handling where if you don't match the grammar it's false. TabAtkins: I think you're right. Florian: You're probably right. Florian: So let's just remove it. fantasai: So let's say you have an unknown thing and 'or' and a known thing that's right. You want it to be true. TabAtkins: Yes, I think so. fantasai: That should work. We shouldn't throw out the entire MQ. Florian: With not it's not. TabAtkins: General enclosed can falsify up to the nearest 'or'. Florian: I agree with TabAtkins and fantasai. TabAtkins: I believe that's what I was thinking of to look up. In that case let's talk about having general enclosed falsify to itself. A real syntax error with false the whole thing. <zcorpan> "A media query that does not match the grammar in the previous section must be replaced by not all during parsing." http://dev.w3.org/csswg/mediaqueries/#error-handling <SimonSapin> maybe or X = X; maybe and X = maybe; not maybe = maybe <dbaron> Which of these are incompatible changes to media queries? SimonSapin: What if we have a tri-state logic? TabAtkins: Yeah. There is a bottom value. dbaron: So MQ right now only have 'and'? TabAtkins: Correct. Florian: I think we got the right behavior, but since we hadn't considered this before the call, you or I should propose to the ML and resolve next week. TabAtkins: No resolution for now, we'll discuss, if there's no objections we're good. Allow custom MQ before @import ------------------------------ Florian: Next one is more involved. <Florian> https://lists.w3.org/Archives/Public/www-style/2015Apr/0017.html Florian: TabAtkins do you want this one? Florian: It's if custom MQ can appear before @import and that whole thing. TabAtkins: The definition of custom MQ has no restrictions on where they're placed. Standard behavior. This means standard import rules do restrict them. It might make it difficult to make an import conditional on a custom MQ. TabAtkins: That should still work. Never mind. TabAtkins: You can have an import conditional on a custom MQ, but it might take time to start loading. There's the further question of how to handle loops, part where there's a custom MQ in a MQ block and they're referring to each other. You can't exclude from being inside MQ because at minimum a conditional import applies to this. TabAtkins: So, I believe the rules should be if a cycle is detected in MQ rules, if a custom MQ depends on one it contains then that MQ name gets tainted and all instances are invalid and undefined. TabAtkins: This is similar to the custom property loop handling. If you get a loop in custom property it kills it and you can't recover until the cascade is changed to remove the loop. That's true here. fantasai: What's the case for making these conditional on anything? TabAtkins: Being able to set up a set of variables on arbitrary MQ is good and setting up MQ based on that is good. Like on narrow screens the relevant values are foo and bar, but there are other relevant values on a bigger screen. Florian: Another thing you can do inside a conditional is custom @support. fantasai: Wait...okay... TabAtkins: Producing and arbitrary large condition and wrapping it as an easy MQ name. fantasai: oookay. (doubtfully) Florian: Another thing from the ML is that we may want for preloader reasons to restrict them to only the top of the style sheet. That's not entirely orthogonal. We can just say if they're nested they do nothing, but that's a fast way to preload. TabAtkins: Yoav, who did a lot of work on the preloader for Blink, where it is fine for finding import urls, no one implements viewport parsing in preloader and he thinks that's a bad idea. Custom MQ lie somewhere in the middle of those things for difficulty. It's harder than a URL. My alternate proposal is we define a new meta value for HTML that lets you define a custom MQ up there that can be accessed by preloaders. Ones in style sheets are not. Florian: So you keep the possibility of custom MQs. TabAtkins: Yeah, they're not valid for things that require preloaders. You can still do it, but it'll evaluate to false during the preloading stage. Florian: I'm comfortable with that. I suggest we try and resolve on allowing @import and @custom MQ in the same place. Florian: And we have when you have a loop in custom media you invalidate the entire thing. TabAtkins: I can poke the HTML group for that. Florian: Because we can do that we shouldn't block the rest. TabAtkins: Yeah. fantasai: I'm not 100% sold on all these things. Can we do a simpler set? You can do custom media rules, but if you do them they come before @import. Florian: You still need to define how loops work because you can define media attributes. Since we have do deal with it, I'm not comfortable cutting this off from authors. <tantek> this sounds like it needs more thought <tantek> f2f topic? glazou: We can't resolve on the call. This is complex. Florian: I think TabAtkins and I agree, so we'll make a complete proposal on the ML. Action Florian to write a proposal for the mailing list <trackbot> Created ACTION-681 Action TabAtkins to write a proposal for the mailing list <trackbot> Created ACTION-682 Font MIME types =============== <glazou> https://lists.w3.org/Archives/Public/www-style/2015Apr/0027.html ChrisL: Anne is correct. We do this because when @fontface was first discussed we wanted a new top level media type. Others hated it and we gave up and had this hokey string instead. One one hand I'm concerned about font media types. However, fonts are supposed to be in the registration tree, but they're not and the web ignores this. ChrisL: The font group has put WOFF2 and has defined the whole tree as a new font-* which answers the question of where a definitive list should be. <ChrisL> http://www.w3.org/TR/WOFF2/#IMT <zcorpan> or use text/plain, text/html, application/octet-stream... <tantek> +1 for font/ TabAtkins: She's not wanting all the changes in CSS, they just thought CSS was a place for a definition. ChrisL: Having it in CSS3 Fonts is a place, but I'm pointing out there is a spec where it is. I'm not convinced we need to register these things, but they've decided to do that. glazou: So Anne wanted to know where to put a list of font types. So I guess making that spec the answer is enough? ChrisL: Yes. glazou: Did you contribute to the thread? ChrisL: No, but I can. TabAtkins: Note the font-* types aren't sufficient for the request. The Google analysis has several not listed fonts with decent usage. Where is this going? <TabAtkins> Full list: https://lists.w3.org/Archives/Public/www-style/2015Apr/0224.html ChrisL: It's a WOFF2 appendix. TabAtkins: It doesn't have application-* types. ChrisL: We can add that. TabAtkins: That's what I wanted to check. ChrisL: I just wanted to have discussion here. fantasai: So out of scope, forward to fonts working group ChrisL: Yep. RESOLVED: Font MIME type registration is out-of-scope for CSSWG, FontsWG has a (partial) list, forwarding issue to them Allow Extended Hebrew Counters =============================== glazou: We have 10 minutes and 4 things on the agenda. <glazou> https://lists.w3.org/Archives/Public/www-style/2015Apr/0117.html TabAtkins: Hebrew counts is easy. I'm fine adding that implementors can do larger Hebrew counters if they want to. <Florian> +1 fantasai: I'm fine with that. glazou: So is there objections? <Bert> (no objection) RESOLVED: Add that people may support larger Hebrew counters if they want glazou: Do we have someone from LG on the call? fantasai: We need a resolution to re-publish counter styles CR for this. glazou: Okay, objections? <andrey-bloomberg> +1 <Florian> +1 <astearns> +1 <dauwhe> +1 <zcorpan> +1 Bert: No objection. <tantek> +1 RESOLVED: Re-publish Counter Styles CR with the above addition <fantasai> Tab, don't forget to add to blow away the changes list and replace it with the change above :) Ruby inlinize algorithm ======================= TabAtkins: I was asking fantasai if she had comments. It's relevant to other cases. fantasai: I need to dig deeper into this. Addition of a ::flex-line pseudo-element ======================================== fantasai: We might want to consider it for a future level of flexbox. TabAtkins: I agree. fantasai: Definitely not adding it now. glazou: So that's what we can do without LG. Anything for the remaining minutes? Florian: I have more, but don't remember length. glazou: Okay. Anything else? Naming issue for cursor: default ================================ Florian: Just sent a mail where we have a naming collision about the default value. <tantek> yay. cursor: default; vs. *: default TabAtkins: When was that added to cursor? tantek: CSS2. TabAtkins: Okay. fantasai: And default was reserved in CSS2. TabAtkins: Yeah. Okay. fantasai: It's in the font section. <tantek> time to dig through CSS2 WDs :P Florian: I can think of 3 options. One is you can't use global default on cursor. That would be unfortunate. We can rename the global. Or we can create a horrible special value like 'default-I-mean-it' for the cursor property <ChrisL> I wouldn't worry about using values we haven't reserved TabAtkins: The default isn't arrow for historical reasons, right? Florian: Yeah, but it's too late to rename. Florian: So anyone have a better idea? glazou: I'm sure we're going to hate all the ideas. tantek: Least worst is cursor doesn't get the global default for now. <astearns> +1 to tantek's position Florian: What about later? tantek: You worry when there's demand. Florian: The default isn't supported by anyone now. If we rename now we don't have a problem later. glazou: And not putting a special case in the code. tantek: Sounds like research is needed about applying default to something else. For the global default name. We need to research the bikeshedding. TabAtkins: That's the least unattractive option. We need to see what's been used and what's free on the ML. tantek: Can bikeshed figure that out? TabAtkins: It doesn't know literally all the properties because some specs aren't in bikeshed. glazou: Who will do the research? TabAtkins: Let's suggest things on the ML. Research is pretty easy. Florian: One down side is that default has been reserved for authors as well, but nothing else has so we may conflict with author names. TabAtkins: It's generally unlikely. There's only a few places authors can use custom names so I don't think we'll infringe. Florian: Let's try that on the ML glazou: Let's move it to the ML. glazou: Thank you very much and talk to you next week. <Bert> (Maybe replace by two values: user and ua, to reset to user style and UA style resp.) <TabAtkins> Bert: 'default' currently resets to the user level when used in author sheets, and to the UA level when used in user sheets. <TabAtkins> Bert: I don't think there's any reason to let the author explicitly reset down to UA, skipping the user styles. <Bert> That's my intuition, too, but I'm just brainstorming... <tantek> What TabAtkins and Bert said. <tantek> in addition, *allowing* the author to skip user styles goes against our design principles <zcorpan> 'ua-default' (with same semantics as now; people don't know or care about user styles) * fantasai is now wondering if we need to rename 'default' to 'unset' and 'unset' to 'reset' <SimonSapin> fantasai, isn’t unset shipping? <fantasai> SimonSapin: probably. And probably the people using it don't know the difference :) <TabAtkins> Yeah, and "unset" still works fine for its current name - it unsets *everything*. <TabAtkins> But yeah, I'll bet some people using "unset" are expecting it to give UA defaults. ^_^
Received on Thursday, 23 April 2015 15:36:19 UTC