Brief   Full   Jump  


High contrast


[CSSWG] Minutes Telecon 2018-06-27 [mediaqueries-5] [css-transforms] [css-syntax] [css-display] [css-sizing] [css-text-3]

1 message.

[CSSWG] Minutes Telecon 2018-06-27 [mediaqueries-5] [css-transforms] [css-syntax] [css-display] [css-sizing] [css-text-3]
Dael Jackson   Wed, 27 Jun 2018 19:42:34 -0400

www-style > June 2018 > 0032.html

Received on Wednesday, 27 June 2018 23:43:32 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to:

========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= Media Queries 5 --------------- - RESOLVED: Add environment-blending to MQ5 (Issue #2723 | PR #2719) CSS Transforms -------------- - There was a desire to make the change in Issue #927 (Smarter interpolation of truncated transform lists) either in level 1 or not at all so that it maintains interoperability. - No implementor on the call showed interest in this change, but two key commenters from the github issue (birtles and TabAtkins) were not on the telecon so the final decision will be deferred to the F2F. CSS Syntax ---------- - After discussion the group came up with five options to address the request in Issue #2757 (Consider disallowing NULL code points in stylesheets) 1) drop entire stylesheet 2) drop stylesheet after NULL 3) drop encompassing selector around NULL 4) drop NULLs during pre-parse 5) no change - Some members of the group were unconvinced of the use case behind the issue and wanted to have someone with security expertise validate the vulnerability. - The group will review again at the F2F and perhaps request review from TAG. CSS Display ----------- - RESOLVED: Compute to none [instead of behaves as none] (Issue #2755: Use "computes to" instead of "behaves as" for display: contents on unusual elements) CSS Sizing ---------- - RESOLVED: Change to "behave as" instead of "compute" (Issue #2708: Incorrect use of the word "compute" in definition of intrinsic keyword values) CSS Text 3 ---------- - RESOLVED: Accept the proposal in (instead of having break-spaces be a || alternative in overflow-wrap, it will be a | alternative in white-space.) ===== FULL MINUTES BELOW ====== Agenda: Present: Rachel Andrew Rossen Atanassov David Baron Garrett Berg Emilio Cobos Álvarez Dave Cramer Alex Critchfield Elika Etemad Tony Graham Wenli He Dael Jackson Peter Linss Thierry Michel Liam Quin Manuel Rego Casasnovas Melanie Richards Florian Rivoal Dirk Schulze Geoffrey Sneddon Alan Stearns Eric Willigers Jeff Xu Regrets: Fergal Daly Simon Fraser Chris Lilley Jen Simmons Lea Verou Scribe: dael Rossen: Let's get going Rossen: As usual I wanted to see if there are any additional items or changes. cabanier: Could we have a moment to talk about environment-blending? Rossen: It's the first topic. cabanier: Oh! Sorry. Media Queries 5 =============== Add 'environment-blending' keyword ---------------------------------- github: cabanier: Hi everyone! I work for Magic Leap and we do an AR headset and we're doing a web browser for that. One of the things in our headset is it's additive. A lot of websites aren't as pleasing to the eye as can be. Bright white background with small text is hard to read. People tend to switch styles. Some people use scripts to change the site and we want them to use MQ to design pages for display technologies. cabanier: Originally we called the property 'reality', but it's for other technologies too so we came up with 'environment-blending name'. I think fantasai had concerns about virtual reality. If she could expand. fantasai: I had a handful of comments on how spec was written, but aside from that...There was a comment on how opaque vs additive. Additive was if you're blending with real world but you could blend the canvas of page with virtual world as well so I was saying description should be adjusted. cabanier: So it doesn't need to be real world...real or your desktop event. fantasai: Yeah cabanier: Okay. I think we can do that. florian: In principle I support. Need to explore details. One thing I was wondering about, if it falls under something described...something like an overhead projector slide with a default transparent background. cabanier: Like an additive display but you could also add darkness. florian: I guess. Opaque but default transparent cabanier: Yes. I think maybe could add later. Webpages are defined opaque by default and you'd have to change that. florian: I didn't want to dive into details, but in wording of options and list of options...we'll need to iterate. MQ5 is fairly speculative so I have no issue adding it there and working with it. cabanier: And as I mentioned on PR is you want to see what we're trying to do we have videos on our home page of the things we want to do. cabanier: I'll update wording to say real or another virtual. Rossen: Sounds good. Sounds like neat feature. Rossen: I'm hearing support to proceeding forward. Rossen: Any other questions/opinions to Rik or should we resolve to continue this in MQ5? RESOLVED: Add environment-blending to MQ5 CSS Transforms ============== Smarter interpolation of truncated transform lists -------------------------------------------------- github: krit: There's one issue on smart interpolation for transform functions. You have to interpolate when there's an animation. Usually they have to have same parameters to map. Every time those functions do not match there is matrix interpolation. krit: Previously we allowed the transforms to be of different size. As long as they map to same size we do the interpolation per transform function. Concern was this wasn't good enough. krit: In this issue request is interpolation per transform function as long as they match with each other. If they do not match we do matrix interpolate but just for the ones that come after the non-matching krit: Support from TabAtkins, request from smfr to defer to L2. I think we keep what we have b/c it's interop. krit: I don't think we can defer because it would change animation in certain situations. Doesn't happen too often that you don't have 2 matching and an animation. krit: So do we agree to this proposal? Or do we keep the current spec text where everything multiplied to a matrix. krit: Complex, but important for animations. krit: Questions on what the request is? fantasai: I agree with making the animations do closer to what authors expect and making them more powerful in terms of accurate representation. In favor of the change. fantasai: Only question I have is we're using the prefix and padding the end with additional ID transforms. Do we want to allow...if the end of the transform list matches rather then the beginning. You don't interpolate ones you don't have, but if one sequence is a subset allow padding on either side? krit: There are requests to make it smarter, but it's complicated. You have to find the pattern and there might be multiple patterns so you have to decide. fantasai: I'm suggesting it has to be exact match. If you have multiple we pick a rule like match against the first one. krit: I'm a bit confused. You want them to match on start or end and only if same length? fantasai: Different, but only if one is an exact subset of the other. krit: List 1 is a subset of list 2 fantasai: Yes. krit: And only beginning or end or also middle? fantasai: Both. Middle or end. dbaron: I worry matching in middle will be harder to understand. We want behavior to be good and understandable and expected. Matching in the middle feels...oh, it'll randomly search, but only if you have an exact match of sequence. I think there's value in doing something simple and explainable. fantasai: Okay. That's fine. I wanted to know if it was thought through. krit: Does the issue in question have support? Everything matches at the beginning but not end so we do matrix for the things that do not match at end? fantasai: Seems fine krit: Looking for browser impl feedback as that's not impl. krit: If people need time it's fine, but input at some point would be great. Rossen: smfr isn't on the call. We are going to make this change as a part of transforms L1, right? krit: Yes, need to for L1 because if we do L2 there will be unexpected repercussions for Animations. Rossen: Do people feel they need more time? Can we resolve now and reopen if needed? Preference? Rossen: Objections to...krit, wording? krit: I'm not proposing. I'm in favor of not changing text Rossen: Proposal: No change to the current specification krit: Only because it's impl currently. Rossen: Objections to stay with current impl behavior and not change transforms L1? fantasai: We've talked about if we make this change it should be L1. krit: Correct Rossen: Yes if we make the change it should be L1. fantasai: So asking to not change ever? Rossen: No, we can defer this to L2 but for L1 we can stay with current impl solution in the spec. fantasai: If you want to eventually make this change, why not put it in L1? krit: Depends on impl interest. If there isn't doesn't make sense to put it in. fantasai: I don't think it makes sense to decide if we're putting in L1. If we do it it should go in L1. We can put it in L1 and mark as at-risk. This is a WD still. fantasai: The longer that we don't impl, content...this is a change in an existing deployed feature. If we want a change we should do it sooner rather than later. Waiting doesn't seem should do. Rossen: But I'm not hearing impl step up. florian: Then we shouldn't have it at all rather than have it in L2. Rossen: And that's the no change resolution. Don't impl it. Rossen: Any interest in working on this feature? If not we can resolve on rejecting it. fantasai: Note that birtles and TabAtkins aren't here. Can anyone represent their positions? Rossen: People from Mozilla or Chrome on? Rossen: None to represent this issue. fantasai: I recommend that given they're not here and critical we resolve on if we do it this is how and then the question of do we do it waits until next week. Rossen: We can try and get to this in F2F. fantasai: You can resolve on how interpolation happens. Rossen: Prefer not to in absence of the people you mentioned. If will discuss at F2F let's do it at that time. CSS Syntax ========== Consider disallowing NULL code points in stylesheets ---------------------------------------------------- github: Rossen: Can anyone handle "Consider disallowing NULL code points in stylesheets"? <fantasai> Tab's position: florian: The issue is that having a null codepoint in the middle of stylesheet is not useful in general, but is a potential security risk. Could single something like a code extract. Therefore we should kill the stylesheet somehow. How and how much should be discussed. Possibly reject entire stylesheet or a milder version florian: Going further I'm not the right person, but that's high level. hober: Is there current interop? florian: I believe not. Current is that browsers discard, but how they recover doesn't seem interoperable. florian: There are mentions of differences in the issue. How different I'm not sure. Rossen: I ran through all of these locally. I was seeing interop between Edge, Chrome, and FF on all the test cases in the issue. Rossen: Curious to hear from dbaron and if he's thought about it. dbaron: Sounds like emilio has but I haven't. bradk: Any idea how often this is in the wild as possibly a mistake? Rossen: Not sure we have such data. Rossen: If you're asking how often people try and spoof browsers it's quite often and this is a potential attach vector, but this is more speculative. florian: Question is how often do we have almost valid style sheets that were meant to be read. Rossen: Don't think we can disambiguate between. bradk: Concern is break working stylesheets. Rossen: My understanding is you could have actual end user effects. bradk: Will this break websites? Rossen: Potentially. plinss: Tooling injecting null bytes is fairly low unless they'll already be present florian: Current possible interop you Rossen observed is it reasonably safe or interoperably unsafe? <Rossen>,output Rossen: I won't make statements in terms of this as an attack vector. From interop, I just re-ran a variation on some test cases I observe differences here ^ Rossen: In this case you join the null character. This invalidates in Chrome the entire selector. In FF and Edge we only invalidate the join part of the last selector and honor the first part. Rossen: Result is after joining selector with null Edge and FF get red and black default in Blink florian: I get black in FF Rossen: Well...I don't know version. florian: 61. Updated today. Rossen: I'm on 60. Let me take the 61 update emilio: Nightly shows red to me Rossen: So there is non-interop Rossen: FF 61 I still see red * liam gets red on ff61 here fremy: I see red in every browser Rossen: Instead of debating this test case. Let's go back to the behavior in issue. florian: Safe proposal is if you see any null discard entire stylesheet fantasai: 3 proposals fremy: I don't see doing that. I don't see why a null byte is a security issue. I don't see why discard an entire stylesheet. * emilio agrees with fremy florian: One null bit not dangerous. There's no known use case but can be sign of attack. fremy: Any JS is sign of potential attack. Rossen: That's not only option. It's *A* option. fantasai: Others were terminate stylesheet at that point. 3rd option was auto invalidate any construct with that null according to normal invalid rules <fantasai> e.g. invalidate declaration, or style rule, or whatever construct we would normally invalidate Rossen: 3rd makes most sense. Finding the closest adjacent or encompassing rule/select/whatever and discard that is most intuitive. <bradk> Option 3 seems most reasonable to me <gsnedders> I agree with fremy, given we don't do the same in HTML. Rossen: 2nd is a variation of that and almost as bad as discard entire stylesheet. plinss: Another option is ignore null and pretend it's not there. Rossen you seem to favor terminate existing construct, but that's most dangerous for security because it means you have to pass it through. If you ignore the null or terminate or discard you can do that at pre-parse and then you're safe. <liam> +1 to plinss fremy: Still don't understand premise null bit is unsafe. florian: It may be a telltale sign something else is being attempted. If someone is dumping content of memory you'll see null bits. plinss: Risk is you have some code that takes entire construct with the null in the middle and others that terminate the string and you're opening to security vulnerabilities. <fantasai> plinss, wouldn't handle Tab's concern in 1st paragraph of Rossen: Thinking a bit more I like the 4th option to ignore null codepoints during pre-parse and curate the stylesheet as if there were no code points. florian: If you dump memory without nulls you can still export that to some server. gsnedders: As precedent html replaces null with +fffd in some cases and that's better then drop. plinss: [missed] florian: Then not dealing with security problem. If you keep null bytes you can keep them on server. fremy: I don't buy it. I think it's pointless. If you're able to dump memory you can literally do a JS script. The whole premise makes no sense. I see no reason to not use syntax. Browsers can impl css syntax and do what it says. I don't see why do something special because then you create edge cases. fremy: I think premise of thread is not based on something real. I haven't seen anyone from security team say it's real. If no one from security says it's a problem we should fix I don't think we should make any change to algo. There's no strong indication of a problem. If we agree to make a change from security we need someone from security. florian: How do we handle this? If we say a browser has a known vulnerability on this how do they discuss it with us? gsnedders: Member only. florian: Is that private enough? liam: There's also a team-only list. Rossen: We can either postpone to F2F and discuss in person to see all the concerns and options. Or at least we can record the preference of the listed options as at least a proposed resolution Rossen: 1 drop entire stylesheet. 2 drop stylesheet after null. 3 drop encompassing selector around null. 4 drop null during pre-parse. Rossen: That's what's on the table. Only remaining question is do we want to resolve on any of those? ??: Also option of no change. Rossen: Yes fantasai: I would say we've had a good discussion. List the options in the issue, request TAG review, give people time to think. Rossen: Exactly. That's why I wanted to repeat the options. Rossen: Doesn't sound like we'll resolve. Discussion worth capturing. Potentially with TAG assistance or at F2F we can resolve. CSS Display =========== Use "computes to" instead of "behaves as" for display: contents on unusual elements ------------------------------------------------------------------ github: fantasai: We had said that display:contents behaves as display:none on certain elements like some SVG. There's an appendix of exactly which ones. emilio filed an issue to just say computes to display:none since that's easier from impl then handling that at used style time. fantasai: TabAtkins and I have not much of an opinion. Up to implementors. emilio: To be clear everyone that impl computes to none? Rossen: Any reason to do anything other than that? Sounds like there's interop. Rossen: Objections to serialize it out as none? RESOLVED: compute to none CSS 2 ===== empty url() behaviour needs errata to match Level 3 --------------------------------------------------- github: gsnedders: Issue is TabAtkins wanted to review resolution given he wasn't on call, but we should wait for TabAtkins to be on a call. CSS Sizing ========== Incorrect use of the word "compute" in definition of intrinsic keyword values ---------------------------------------------------------------------- github: <fantasai> fantasai: Changes are ^ fantasai: The min-content and max-content keywords and that type are currently defined to behave as property initial value if spec in block axis. fantasai: Spec says they compute to property initial value so auto on height or none or max-height. fantasai: Mats would prefer it to say "behaves as" rather then "computes to" fantasai: TabAtkins and I have no strong opinion. Up to impl. fantasai: Example from Mats is if you explicitly inherit height and gave one of these keywords you should get that keyword. Makes sense, but can't imagine anyone inheriting height. dbaron: Issue is impl have to impl what spec says and that can be a pain to do. florian: If no real use case and simpler thing to impl, why not? dbaron: Note one interesting point that request is the opposite of the request a few issues ago. fantasai: Yep dbaron: Maybe figure out underlying principle. Maybe if it's a property that effects type of boxes. Rossen: Any reasons to not word it as "behaves as"? Rossen: I sympathize with Mats and having dependency between properties when computing the value of others is usually a thing to avoid. By not being a strict as current wording it at least doesn't explicitly say this is what it is. Rossen: We're not fixing issue by changing wording. Rossen: For current sizing spec, are we okay make the change to "behave as" instead of "compute". Rossen: Objections? fremy: Wasn't change to revert? Rossen: Revert what? fantasai: Resolution asked is to accept the change florian: Reverse is earlier issue Rossen: I said change to behave as instead of compute. RESOLVED: Change to "behave as" instead of "compute" Rossen: What's 2 minutes? CSS Text 3 ========== Audit details of break-spaces value against use cases ----------------------------------------------------- github: florian: Reopening. florian: We discussed for 3 years having a value called break-space on the overflow. Chrome and Igalia are mid-impl. Current syntax is not ideal. Would like to change it. I'm not enthusiastic, but their proposal is as good as what we've written and it's to implement so I'm in favor fantasai: Proposal came from discussion with me and koji where koji said properties that takes multiple values is harder then one value. Requested long hands so one can take break-word and the other break-space. Reason for separate property is if they need to cascade separately. That does seem to be the case for these values. I can see why break-spaces and break-rule would be different fantasai: Also notices break-spaces is only ever set with pre-wrap on whitespace. You'll never cascade independently. Makes sense to move this from overflow-wrap to whitespace prop and then it would be mutually exclusive keywords fantasai: That's how got to proposal fantasai: Improvement to cascade behavior. We're cascade independently things that can be and not things which can't. I'm in favor of proposal. florian: So am I, koji, and Javier Rossen: Objections? RESOLVED: Accept the proposal in <astearns> dbaron: One thing from astearns in IRC. Apply for an ETAS to Australia if you haven't and need it for immigration. Rossen: Yes, please make sure you can enter Australia. Rossen: See you all in a week.