W3C home > Mailing lists > Public > www-style@w3.org > January 2019

[CSSWG] Minutes Telecon 2019-01-23 [css-syntax] [css-text] [css-inline] [resize-observer] [css-grid] [css-logical]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 23 Jan 2019 20:00:48 -0500
Message-ID: <CADhPm3v7VX0grbCzF-Lfrw384SH6X33yLtjYtJmfEYZ3vapcBg@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.

CSS Syntax

  - RESOLVED: Change syntax to specify behavior implemented in
              majority of browsers (Issue #3182)
  - RESOLVED: Defer the remaining syntax issue with a note we may
              address in future spec (Issue #2757)
  - TabAtkins will compile a disposition of comments and request
      publication on next week's call.

CSS Text

  - Instead of solving for the handful of properties in Issue #3414
      (CSS properties should apply to some SVG elements as well) the
      group will aim for a general solution to update all 'applies to'
      lines to have information about how they interact with SVG
      - In order to do this, interested individuals will work on a new
          language to use for applying to SVG elements as well as to
          make it clearer what the current general text around
          'elements' really means.
      - Once this is agreed to by the group one large PR will be
          drafted to make this change to all specs simultaneously.
      - The goal is to have a first draft of the new language for
          discussion at the next F2F.
  - RESOLVED: Amend the previous resolution to include form feeds so
              they're processed same as lone CRs (Issue #855)

CSS Inline

  - People continue to think on issue #2950 (Better name for
      initial-letters property) so it will be added to the F2F agenda.
      - On the call today one suggestion was line-span, but there were
          concerns that could be misinterpreted.

Resize Observer

  - There was concern that the approach taken to resolve on Issue
      #3329 (Which box information should we pass to the callback) was
      too broad and could be confusing since the data returned here
      would not be returned in other similar calls. Discussion will
      continue at the F2F.

CSS Grid

  - RESOLVED: Define repeat interpolation using the more restrictive
              rule in
              [require that the first arg is a number, and identical
              between start/end; different values, or keyword values,
              both go discrete]

CSS Logical Properties

  - RESOLVED: Do not allow quirks in 'inset' shorthand (Issue #3525)
  - RESOLVED: Close this issue (Issue #3519: border-block/
              border-inline syntax) and add a note to the spec saying
              this is an intentional restriction


Agenda: https://lists.w3.org/Archives/Public/www-style/2019Jan/0009.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  Amelia Bellamy-Royds
  Oriol Brufau
  Emilio Cobos Álvarez
  Dave Cramer
  Benjamin De Cock
  Elika Etemad
  Simon Fraser
  Dael Jackson
  Brad Kemper
  Vladimir Levantovsky
  Chris Lilley
  Peter Linss
  Nigel Megitt
  Michael Miller
  Anton Prowse
  Melanie Richards
  Jen Simmons
  Alan Stearns
  Lea Verou
  Greg Whitworth

  David Baron
  Florian Rivoal

Scribe: dael

CSS Syntax

Correctly handle "escaped EOF"
  github: https://github.com/w3c/csswg-drafts/issues/3182#issuecomment-455376948

  TabAtkins: The spec for syntax- this is a weird corner issue and I'm
             going to match implementation. Turns out the way
             implementations handle an escaped end of file is to omit
             a replacement character
  TabAtkins: Resolved this at one point, but resolutions are
             confusing. Spec doesn't say that right now. A slash at
             the end of the file doesn't create an escape as per spec.
             Firefox, Chrome, and Safari think it counts as an escape
             for replaced character. Want to edit spec to match impl.
  TabAtkins: Edge does extremely wrong things for the slash so I don't
             think we can draw from that.
  <TabAtkins> https://github.com/w3c/csswg-drafts/issues/3182#issuecomment-426019418
  TabAtkins: This is what they do ^
  TabAtkins: I can't tell what they're doing internally, the
             serialized isn't round trip-able
  TabAtkins: Only difference in other browsers is Firefox serializes
             it as an escape for itself which is same result as
             omitting. It's a CSSOM serialization issue.
             syntax-relevant has all browsers behaving the same

  astearns: Concerns?
  Rossen: I haven't had a chance to look. Reading through TabAtkins's
          comments. I won't push back, but I'm curious what we're
          doing. I'll comment if I want to re-open.
  astearns: You're fine resolution now?
  Rossen: Yep. Just like any other issue

  astearns: Objections to changing syntax to spec behavior impl in
            majority of browsers?

  RESOLVED: Change syntax to specify behavior implemented in majority
            of browsers

Publication & Consider disallowing NULL code points in stylesheets
  github: https://github.com/w3c/csswg-drafts/issues/2757

  TabAtkins: Only remaining issue is if we should do something more
             aggressive with a NULL. I'd like to defer to a future
             version. Given that I'd like to request new CR publication
  astearns: Would it make sense to leave something in syntax saying we
            might get tighter in the future?
  TabAtkins: Happy to do so.

  fantasai: I suggest we hold on publication to let you finish DoC and
            let Rossen look at that issue so that we can go next week
  TabAtkins: I want to get it out because it's been 5 years
  fantasai: Yes, definitely let's do next week

  astearns: Do you want resolution on defer?
  TabAtkins: Yes
  astearns: Objections to defer the remaining syntax issue with a note
            we may address in future spec

  RESOLVED: Defer the remaining syntax issue with a note we may
            address in future spec

  <fantasai> \^_^/ Yay for [impending] new publication!
  astearns: Updated publication next week would be great with an
            updated DoC
  TabAtkins: Alright

CSS Text

When to/not to include preserved trailing spaces
  github: https://github.com/w3c/csswg-drafts/issues/3440

  fantasai: Is koji on?
  fantasai: We'll need him.
  astearns: Can you add a comment pinging him so he knows we're
  fantasai: kay

CSS properties should apply to some SVG elements as well
  github: https://github.com/w3c/csswg-drafts/issues/3414

  astearns: Is AmeliaBR on?
  astearns: Looks like krit is asking for some things to apply to SVG

  fantasai: Wanted to ask if we want to deal with them for all our
            specs. Doesn't make sense for a few properties. If we've
            got a case with some but not all we've got a case where if
            you don't specify a property does it apply?
  <Rossen> +1 to what fantasai said
  chris: That's not what we mean. We don't say it applies to HTML
         elements, we just say elements
  AmeliaBR: Reason it came up is...concern if we rely on SVG spec to
            mention which properties apply it will regularly get out
            of date as new properties are introduced. Trying to move
            that into property definitions and make sure it's covered
            by the applies to part of property definition box
  AmeliaBR: As chris said in cases where we have applies to all
            elements it can presume to apply to SVG elements. But then
            there are some places it says applies to but it's CSS box
            type. It's about being consistent and making sure those
            boxes are useful
  fantasai: All elements means all elements formatted with css box
            model. SVG has typically been outside our spec zone.
            Incorporating which applies to what SVG makes sense. But
            if we're going to do it we should do it to all specs.
  fantasai: If we want to do that we should resolve to do that for all
            specs at once so everything is consistent. And it goes in
            at once so there's no point where we've got uncertainly.
  fantasai: That's what I'd like to see us do
  AmeliaBR: Agree with that strategy. I think it should be thought of
            in conjunction with some other open issues about
            redefining how applies to line works. Open issue about if
            pseudo elements are in all elements
  fantasai: They're not except before and after which in their own
            definition says that.
  fantasai: I think if we list every pseudo element we could do that.
            before and after it would be redundant because they say
            they're not a special type.

  <AmeliaBR> https://drafts.csswg.org/css-text-3/#word-spacing-property
  AmeliaBR: Specific properties krit brought up, they say applies to
            inline boxes which is a very CSS term
  AmeliaBR: That's where the issue for those came up. Might come to
            having to sit down and come up with a set of new terms
            that can be used for covering the SVG layout/element types
            as well as the CSS box types
  AmeliaBR: That's probably the first step. A proposal for which
            categories to use for what makes sense to describe the SVG
            properties. Then come back to WG for confirmation and then
            make a giant PR
  fantasai: Makes sense. Don't rely on all elements to help you out,
            though. Border applies to all for SVG. We'll have to
            change things around.
  AmeliaBR: It might change all elements to all css boxes or something
            like that.
  AmeliaBR: Not going to figure it out on the call. If anyone has
            ideas we can brainstorm in the issue. First step is figure
            out what the categories should be that makes sense in both
  AmeliaBR: Once that's decided it's going through every spec and
            making sure it makes sense
  fantasai: Direction sound good to everyone?
  chris: sgtm

  fantasai: I'll tag this issue against all specs
  astearns: I don't know if that'll be that useful. But mentioning in
            a comment this will apply to all specs might be sufficient.

  astearns: How many SVG folks will be at F2F? I'm wondering if this
            is something we can noodle on
  chris: I hope to be
  AmeliaBR: I will be in person
  AmeliaBR: krit, though, won't be around. Not sure about myles or eric
  astearns: Let's see if we can wrap this up by the F2F
  astearns: Anything else on this issue?

Question re white space processing rules for U+000D
  github: https://github.com/w3c/csswg-drafts/issues/855#issuecomment-451191125

  fantasai: We discussed handling lone carriage returns. Last couple
            resolutions talked about carriage, but not form feeds. In
            current spec text form feeds are different than every
            other control character. They are not rendered
  fantasai: Wanted to know what we wanted to do. Treat as 0 width
            space or no?
  <fantasai> https://www.w3.org/TR/css-text-3/#white-space-processing
  fantasai: Spec section ^
  <fantasai> Form feeds (U+000C) (that are not segment breaks) are
             rendered as a zero-width space (U+200B). Control
             characters (Unicode category Cc) other than tab (U+0009),
             line feed (U+000A), and form feed (U+000C), must be
             rendered as a visible glyph which the UA must synthethize
             if the glyphs found in the font are not visible and
             otherwise treated as any other character of the Other
             Symbols (So) general category and
  <fantasai> Common script. The UA may use a glyph provided by a font
             specifically for the control character, substitute the
             glyphs provided for the corresponding symbol in the
             Control Pictures block, generate a visual representation
             of its code point value, or use some other method to
             provide an appropriate visible glyph. As required by
             [UNICODE], unsupported Default_ignorable characters must
             be ignored for rendering.

  astearns: I don't have a strong opinion but makes sense to treat
            form feeds in a consistent way
  astearns: Anyone have a reason to treat form feeds differently?
  astearns: Objections to amend the previous resolution to include
            form feeds so they're processed same as lone CRs?

  RESOLVED: Amend the previous resolution to include form feeds so
            they're processed same as lone CRs

  astearns: That will require test changes an that will get us feedback

  fantasai: I re-tagged the next few for F2F
  astearns: I had asked that.

Better name for initial-letters property
  github: https://github.com/w3c/csswg-drafts/issues/2950#issuecomment-438736819

  jensimmons: As issue says we're debating a name. Kinda hit me is a
              way to approach is describe what this does. I wrote some
              stuff, but I disagree with myself.
  jensimmons: Right now I'm thinking maybe line-span is a possibility.
              I originally rejected because span is in the html, but
              there's em in html and em unit in CSS and that's never
  fantasai: Okay with that
  jensimmons: Made me wonder if you can do more than make a letter
              big. Like if you had an image would it do anything?
  fantasai: Yes, if you apply to an atomic element it will apply.
            There is text on how this works with inline blocks and
  astearns: Definitely intended to work in that case
  fantasai: I think that was my favorite from the list

  astearns: Other opinions?
  dauwhe: Plausible to me
  <AmeliaBR> But to clarify: it still only applies to the first
             element of a block? So that's the bit that isn't conveyed
             by the name.
  bradk: line-span makes it sound like it would be any inline element
         and it would span the line. That was my concern
  jensimmons: Agree we need to think about that
  astearns: Table this for now and get to it at F2F. Let's try and get
            to this on the first day to make sure we give it needed

Should first/last baseline values of `vertical-align` belong to
    `alignment-baseline` or separate longhand?

  astearns: This for F2F?
  fantasai: We have question if first vs last which line we use for
            vertical alignment. Is that a separate property or
            combined with baseline.
  fantasai: I don't have a single good argument in favor of one or the
            other. I'm looking if anyone has an idea or use cases to
  fantasai: Otherwise I don't know how to decide.
  astearns: Anyone on this issue want to register an opinion?
  astearns: We'll put this on F2F agenda. Look to see if anything can
            be clarified.

Resize Observer

Which box information should we pass to the callback
  github: https://github.com/w3c/csswg-drafts/issues/3329#issuecomment-452477429

  gregwhitworth: This comes down to we changed the spec because we
                 resolved we wanted to watch more boxes. Then it was
                 what information should we return? Author wants to
                 observe border box, what do we return? We previously
                 stated all that you could potentially observe so that
                 we answer anything the author wants to watch.
  gregwhitworth: We don't want author putting multiple observers to
                 watch multiple boxes.
  gregwhitworth: What would happen is in the issue. We would return
                 border box, content size box, scroll box, and device
                 pixel border box.

  iank: I'm observing border box size and the content box size
        changes, am I notified?
  gregwhitworth: No. If you want the content box you should observe it
  iank: Worries me webdev will observe border box and then complain
        it's not working as expected. Did you consider getting people
        to list all boxes and nulling things not needed?
  gregwhitworth: Initially we were going to allow them to observe
                 multiple. We can add an option to return us what you
                 want to return. We can add an option that says of the
                 ones we have which do you want options returned.
  gregwhitworth: It's kinda a shot in the dark right now. Even if they
                 have the option they could still have the same
                 problem of observe border and dimensions on content
  iank: Border box size would be null in that call

  Rossen: Verbosity of proposed API. The entity in the platform is the
          css box. All other boxes are properties of that object. My
          worry is if we go down path to expose such models where you
          are creating an identity for a property you're complicating
          lifetime of the API. Sounds a bit odd to me to go down that
  Rossen: Almost equivalent of pretending any other property of box is
          a scriptable object

  smfr: One of the things I find odd is that we don't have any other
        APIs that return content box stuff. It seems odd to get these
        boxes is only resize observer. Why not expose on the things
        that are an imperative to get boxes
  smfr: Also odd API only returns sizes. I'd like rectangles for all
        of these and they should be relative to top left of border box
  smfr: To resolve what changed is you return all rectangles and an
        enum to say which changed
  astearns: Would be which changed, it's which of them changed
  smfr: Yes
  gregwhitworth: Not opposed to having results return in other static
                 areas. This was just an issue for the resize
                 observer. Not sure if you want to expose in CSSOM or
  gregwhitworth: smfr are you saying you want shape is what would be
                 return from getClientRects? I had talked with Aleks
                 that we'd have getBoundingClientRects be what's
                 returned for these boxes. But we said it's about size
                 change not position
  smfr: These rectangles are in local coordinates. Which I think is
        fine. This API shouldn't be able to do abspos or client pos.
        If you're giving size of contents I'd also like offset from
        top left. That seems natural and cheap to compute
  gregwhitworth: Makes sense. I can open that issue. Are we providing
                 for sake or is that a thing authors want commonly?
                 That they want to check the offset
  smfr: I would imagine the users care about fitting things inside. I
        think it's about size and not position
  gregwhitworth: Then why include offsets? Just in case?
  smfr: If you tell me content size I might want to know how much is
        border and how much padding. If I have to call gCS it might
        trigger a layout which is expensive so that should be in
        resize observer

  smfr: One final piece of feedback on algorithm, but we can come back
        to that
  gregwhitworth: That is good F2F item.

  gregwhitworth: Rossen to your point on model, any other
                 recommendations on achieving the end case?
  Rossen: If we're going to discuss at F2F I'd defer to then.
          Providing all the information in a property bag that doesn't
          require additional readbacks would be the preferred model.
  Rossen: The misalignment seems a bit odd here
  gregwhitworth: Okay
  Rossen: Let's table and discuss at length at F2F
  astearns: I'll add F2F tag

CSS Grid

Interpolate repeat()
  Github: https://github.com/w3c/csswg-drafts/issues/3503#issuecomment-453674839

  TabAtkins: Question was raised by Boris. How are repeat functions
             interpolated in grid template rows
  TabAtkins: It's retained in computed values because some can't be
             resolved at computed value time. Computed value animation
             runs on will have repeat functions. How do they
             interpolate. This isn't in spec.
  TabAtkins: They have 2 functions. After some discussion in issue and
             some nice examples there's 2 options that are consistent
             with how we interpolate
  TabAtkins: First is we're very restrictive. To get smooth
             interpolation first argument must be a number and track
             listing must have same number of things. 2, 10px, 10px to
             2, 20px, 20px will be smooth. If you have auto fit no
  TabAtkins: Other poss is we allow any values for first. If same
             transition by doing nothing. If they're numbers and
             different they transition as int. If you try and go into
             to keyword it goes discrete.
  TabAtkins: Still require track listing match with normal
             transitioning rules. You could not go from a repeat 4,
             10px to repeat 2, 10px, 10px. An auto fit and auto fill
             we can't match and I don't like special casing that
  TabAtkins: I propose: We require that either the first argument be
             the same value or both int. Track listings must be
             interpolate-able normally

  fantasai: 2 proposals. Main difference is the first one you can only
            interpolate if it results in same # of tracks. 2nd version
            we try and follow value interpolation patterns we have and
            that allows more possibilities. Disadvantage to that is
            you're not interpolate between # tracks and therefore
            position of elements can change.
  fantasai: Do we want as much smooth in value space but have layout
            discontinuous or do we want to align what's possible to
            interpolate in layout with value space
  TabAtkins: With caveat that discontinuous layout does happen if you
             end up in discrete. We do allow int based on grid
             positions we also can have skipping. This is the whole
             grid, but similar in idea
  astearns: I think I would like to have many example is spec
            whichever we choose
  TabAtkins: Yep

  fantasai: Anyone besides me and TabAtkins have an opinion or want
            more time?
  astearns: fantasai do you have a preference?
  fantasai: From what I know I'd go with first option. More
  fantasai: It seems like interpolating in value space and having
            things jump around, I'm not sure it would be that great. I
            don't feel very strongly because I don't understand
            strongly implementation for layout system. I'd do whatever
            Mats thinks is right
  fantasai: We can poke Mats. Any other opinions?
  astearns: Often we will be more restrictive to begin with and then
            later add smooth interpolation to things that were
            previously discrete. That's an argument to more
            restrictive because we can get to more liberal eventually
  astearns: Other opinions?
  astearns: Am I correct about being able to loosen in the future?
  fantasai: I think you're correct

  astearns: Proposal: Define repeat interpolation using the more
            restrictive rule in
  astearns: Objections?

  RESOLVED: Define repeat interpolation using the more restrictive
            rule in

CSS Logical Properties

Should the `inset` shorthand allow quirks in their lengths like the
    individual properties do?
  github: https://github.com/w3c/csswg-drafts/issues/3525

  fantasai: Top, left, bottom, and right properties in quirks mode
            allow px without px unit. 100=100px. Do we have same quirk
            for logical longhands? Related is what about inset
  <fantasai> (inset shorthand shorthands the physical properties, top/
  TabAtkins: I don't see a reason to allow quirks in new properties.
             Need to not rely on top because that imports quirks
  <bradk> No quirks
  fantasai: We can add a note saying this notation doesn't import
  astearns: I'm agreeing shorthand shouldn't have quirks and deal with
            that in spec definition as well as add test cases
  astearns: Other opinions?
  astearns: Objections to not allowing quirks in 'inset' shorthand?

  RESOLVED: Do not allow quirks in 'inset' shorthand

border-block/border-inline syntax
  github: https://github.com/w3c/csswg-drafts/issues/3519

  fantasai: Mats pointed out they only let you set one value which
            assigns to both sides. Asking if we should allow setting 2
            different values. Short answer is I think no because
            border property includes color, length, and border style.
            Shorthand that deals with that doesn't allow 4 sides. So
            you can only set both sides to same thing.
  fantasai: I think that's fine. I think Oriol thinks it's fine. But
            we could do that.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/3519#issuecomment-454987242
  astearns: Given we have not done it for border property I don't
            think we should do this for border-block and border-inline
  <oriol> I agree with fantasai
  rachelandrew: Agree. It's less confusing if it's the same as 4 value
  TabAtkins: Yeah
  astearns: Proposal: Close this issue and add a note to the spec
            saying this is an intentional restriction
  astearns: Objections?

  RESOLVED: Close this issue and add a note to the spec saying this is
            an intentional restriction

  astearns: Thanks everyone for calling in
Received on Thursday, 24 January 2019 01:01:43 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:09 UTC