W3C home > Mailing lists > Public > www-style@w3.org > June 2018

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

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 27 Jun 2018 19:42:34 -0400
Message-ID: <CADhPm3u5=ng+7ZDvG_h5TbkNsuCOgfh1wG8Pw-EYvuLYTpZR6g@mail.gmail.com>
To: www-style@w3.org
  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


Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jun/0030.html

  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

  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: https://github.com/w3c/csswg-drafts/pull/2719

  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
  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
            virtual...like 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: https://github.com/w3c/csswg-drafts/issues/927

  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

  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: https://github.com/w3c/csswg-drafts/issues/2757

  Rossen: Can anyone handle "Consider disallowing NULL code points in
  <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

  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
  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> http://jsbin.com/vozudorilu/edit?html,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
  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
  <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
  Rossen: 1 drop entire stylesheet. 2 drop stylesheet after null. 3
          drop encompassing selector around null. 4 drop null during
  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
  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

CSS Display

Use "computes to" instead of "behaves as" for display: contents on
    unusual elements
  github: https://github.com/w3c/csswg-drafts/issues/2755

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


empty url() behaviour needs errata to match Level 3
  github: https://github.com/w3c/csswg-drafts/issues/2211

  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
  github: https://github.com/w3c/csswg-drafts/issues/2708

  <fantasai> https://github.com/w3c/csswg-drafts/commit/b603bfb33da70080b83f78e74f41c8af89b9b88b
  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: https://github.com/w3c/csswg-drafts/issues/2465#issuecomment-400171764

  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> https://www.eta.immi.gov.au/ETAS3/etas
  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.
Received on Wednesday, 27 June 2018 23:43:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 27 June 2018 23:43:32 UTC