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

[CSSWG] Minutes Telecon 2018-03-14 [css-typed-om] [css-multicol] [css-pseudo] [css-text]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 14 Mar 2018 19:57:18 -0400
Message-ID: <CADhPm3uBntnwHNky2edjEANVMu8cffQSHXvqCOhiYuzXF9n8FA@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 Typed OM

  - When TabAtkins tried to implement the previous resolutions on
      Houdini Issue #610 (https://github.com/w3c/css-houdini-drafts/issues/610
      | Does the is2D design allow for inconsistent interpretation of
      CSSTransformComponents?) he realized that it introduced a lot of
      implementation complexity that wasn't expected when the group
  - Several people still wanted to have a better solution, though
      understood that the earlier resolution wouldn't work. The group
      decided to roll back the resolutions and keep working at the F2F
      on a better approach.
  - RESOLVED: Reverse the previous resolutions of this issue and keep
              the spec as it currently is.

CSS MultiCol

  - RESOLVED: We allow 0 for column-width for the purpose of parsing,
              1px is the minimum clamping value used for anything
              after parsing.

CSS Pseudo Elements

  - RESOLVED: Add stroke-color and stroke-width to the list of
              highlight properties.
  - RESOLVED: Clarify stroke properties effect ink overflow and not

CSS Text

  - RESOLVED: bidi resolution will result in splitting an inline
              finite space and always create 2 fragments even if they
              end up adjacent.


Agenda: https://lists.w3.org/Archives/Public/www-style/2018Mar/0032.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Garrett Berg
  Tantek Çelik
  Dave Cramer
  Benjamin De Cock
  Elika Etemad
  Simon Fraser
  Dael Jackson
  Brian Kardell (IRC Only)
  Brad Kemper
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Anton Prowse
  Liam Quin
  Manuel Rego
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Alan Stearns

  Angelo Cano
  Vlad Levantovsky
  Lea Verou
  Greg Whitworth

Scribe: dael


  Rossen: Let's get started
  Rossen: Any extra agenda items or anything that you want to change
          on the current agenda?
  tantek: Yesterday gsnedders and I had a discussion about testing. I
          don't know if that's worth spending time on. We chatted a
          bit on IRC.
  Rossen: Concrete open issues or proposed actions to discuss? Or do
          we open a github issue and involve more people?
  tantek: May be something where if we can open an issue not against a
          specific draft. The issues were across all testing.
  tantek: I wanted to raise it to the folks on the telecon in case
          people don't read all the archives and wanted to contribute
          opinions. It's a high level discussion.

  Rossen: Thanks for bringing it to our attention. This is a super
          important topic, especially as we try and move work forward.
          It would be awesome if you can open a github issue and quote
          the discussion for IRC and go from there.
  <astearns> log from yesterday starts here:
  <tantek> some background, my naive experience:
  tantek: plinss helped guide me on that issue ^
  Rossen: Anything else on the agenda?

CSS Flexbox

Min-content sizing currently too smart to be web compatible?
  github: https://github.com/w3c/csswg-drafts/issues/2353

  Rossen: This was waiting on fantasai and TabAtkins to think about.
  <fantasai> gonna need another week
  <fantasai> Tab and I are meeting up on Monday
  Rossen: So fantasai will need a week. Should we push to F2F?
  <fantasai> should have time to look at it then
  <TabAtkins> trying to call in now
  <TabAtkins> but yeah, we'll look at it on monday
  Rossen: Sounds like we'll push to next week at least.


Border width rounding clarification
  github: https://github.com/w3c/csswg-drafts/issues/2114

  Rossen: The bot didn't remove the agenda+. There seemed to be some
          followup from frremy and verification. Is there anything
          else to bring up on this?
  * dbaron notes that github-bot only removes Agenda+ if there was a
  frremy: We should move on.
  Rossen: Okay.

CSS Typed OM

Does the is2D design allow for inconsistent interpretation of
  github: https://github.com/w3c/css-houdini-drafts/issues/610

  Rossen: This has been brought back week after week.
  Rossen: This is typed OM. It's high on the agenda because it's
          related to transforms and it would be good to make progress.
          Can we discuss?
  TabAtkins: I'm ready. My point is summarized in the thread. When
             trying to impl the resolution I realized it's quite
             problematic. We need something very different or go back
             to the original which was you don't pay attention to the
             3d attributes when you're set to be 2d.
  TabAtkins: Should I go over the core issue?
  Rossen: We had a resolution from last week [reads]
  Rossen: That was from 3 or 4 weeks ago.
  TabAtkins: That's not enough. Idea behind this was making things
             like translate.z attribute throw or ignore would be easy,
             but it's actually not. You have a completely separate
             object stored here that needs to know it's read only.
             Only thing easier then dom matrix is it's my spec so I
             can do the edits. I need a whole hierarchy so when you
             swap to 3d you have a read only 0px not a real 0px.
  TabAtkins: It exposes oddness to the author and isn't particularly
             better then what we have.
  Rossen: Okay.
  TabAtkins: My first post after the minutes outlines the basic issue
             where I'd have to do something really weird to implement.
  Rossen: Do you have any proposal of this weird thing?
  TabAtkins: My preferred resolution would be void the previous and
             return to the 3d are ignored if transform is set to 2d.
  TabAtkins: That's the easiest way without a parallel hierarchy.

  Rossen: To recap: we started with what you described. We resolved
          to, when you set a 3d on a 2d we throw. Then a week after we
          said let's not throw, just ignore it. Now we're saying
          nevermind let's go back to the original. Is that where we
  TabAtkins: Yeah. Note that throw and do nothing distinction is very
             small. The original is a substantial difference. It's
             difficult to impl either resolution.
  Rossen: Since you were furthest in impl I'd like to hear if Moz or
          Apple have any objections.
  TabAtkins: dbaron posted a question and I responded to him. We
             haven't discussed further.

  smfr: What if we back away from maintaining the special translate
        behavior? Anyone using the new typed om is working on new
        content where they can change from the magic 0 to a
        will-change transform which is the better way going forward.
        Then get rid of the is2d attribute.
  TabAtkins: Only works if we get rid of the distinctions between 2d
             and 3d. If we key off of does it look plainer we'll have
             a behavior difference when you animate and happen to pass
             through z=0.
  smfr: Sounds like you're considering the typed om to be the om and
        I'm thinking it's an API.
  TabAtkins: It's an API but we can't ignore 2d and 3d. When you ask
             what the transform is you need to indicate if it's 2d or
             3d because when you set it back you might get a behavior
  smfr: You want roundtripping to not have side effects. If you keep
        it to the attribute and if you set anything 3d-ish you remove
        the 2d does that work?
  TabAtkins: Proposal is we go back to is if 2d attribute is set we
             ignore 3d parts of it. It serializes to translate, not
             translate 3d etc. That's what the spec was and currently
             is since I never committed the change.

  smfr: You're saying 2d values from any attribute you set...why not
        the opposite where if you set something z-ish you set the 3d
  TabAtkins: We could...problem is the object we have to monitor is
             not the transform object, but it's a math value or a dom
  TabAtkins: Wouldn't be reversible
  smfr: Is the is2D independent from the matrix?
  TabAtkins: If you don't say it explicitly it will derive, but you
             can only flip manually.
  smfr: I still don't see the problem with...if you say it's okay to
        raise the 0 thing I don't see the problem in allowing people
        to set a z property on a 2d matrix.
  TabAtkins: You have a translate object that's set to 2d. You can
             poke it to z and set it to 5. What does transform is 2D
  smfr: It would turn into a translate 3D.
  TabAtkins: You're okay with that communication between nested
  smfr: It sounds okay, but there's a tear off issue.

  dbaron: That sort of communication isn't that big of a deal. You
          have to do that for all things in the DOM. If you use a
          setter it needs to reflect back to where it came from. Even
          if the API doesn't let you walk back the internals need to
          allow it.
  * myles was going to make the point dbaron is making right now
  TabAtkins: You can have a multi-parent relationship unlike the dom.
  dbaron: That's an interesting point that should be called out
          explicitly in the spec.
  TabAtkins: We don't have detail on moving things around because
             they're objects.
  myles: What's the use case of multi-parent thing?
  TabAtkins: No particular use case, it's how JS works when you don't
             attach extra magic which the dom does.
  TabAtkins: dom behavior is extra magic. JS is what everyone expects.
             Unless we want to attach the extra dom magic to the
             object we get to the JS behavior by default.
  myles: One possible solution, I'm not suggesting it, but it's an
  TabAtkins: The idea a 5px value is unique and special so you can set
             it in one place and not others seems very weird.
  TabAtkins: Elements in the dom are unique and that makes sense. But
             a 5px value doesn't suggest that sort of identity. It
             should only rely on structural equality. We don't do that
             now in JS but I'd like to keep it open.
  dbaron: The 5px value if you manipulate it via its setters it gets
          reflected where used.
  TabAtkins: Only when you set it at which point you can do a tree
             call. There's no need to monitor all the time because
             it's not live. Style property maps are live as of the
             moment you query, but the object produced are dead and of
             no value until set back into property maps. That's
             intentional so you can use these objects multiple times
             and avoid object construction costs.
  dbaron: But the transform stuff...that's true at the lowest but not
          next up?
  TabAtkins: It is. There's no sense of a knowledge connection. What
             are you thinking is happening?
  dbaron: I'm trying to think through what you said about dom matrix.
  TabAtkins: Upon construction you pass in a dom matrix. We examine if
             it's 2d or 3d and decide. If you query the is2D
             object...there's no cross communication after you set
             these things.

  Rossen: Question to dbaron and smfr. Do you have reservations to
          going back to the original design? Or are you trying to
          further where we are today. What I'm hearing and from
          reading the issue I'm feeling we want to take the time to
          make this thing right without locking ourselves in the
          previous resolution. That's a fine path forward.
  Rossen: My question would be would that have any kind of effect on
          the transform spec? If not is there a reason we shouldn't
          resolve to revert and then move on?
  smfr: I don't think this has baring on the transform spec. Maybe
        something different with dom matrix. But I thought TabAtkins
        wasn't happy with the resolution. Might be easier to talk
        about this in Berlin. I don't have my head wrapped around the
        previous proposal.
  Rossen: Going back to the people in the discussion, do we want to
          revert the current resolutions and continue working either
          in the F2F or in a breakout in Houdini or CSS time and make
          progress that way?
  Rossen: Would that satisfy everyone?
  smfr: Works for me.

  Rossen: Proposal: reverse the previous resolutions of this issue and
          keep the spec as it currently is.
  Rossen: Objections?
  smfr: If this is in flux I don't know if we need to resolve anything.
  Rossen: We have previous resolutions.
  smfr: Rollback I guess is okay.

  RESOLVED: Reverse the previous resolutions of this issue and keep
            the spec as it currently is.

CSS MultiCol

Contradictions about whether zero is allowed for 'column-width'
  github: https://github.com/w3c/csswg-drafts/issues/1741

  rachelandrew: I dug this out of the archives and has various
                comments. Is 0 allowed for column width. dbaron wrote
                some stuff that came out of the email archives. There
                were a few comments on that post.
  rachelandrew: There was a comment that said if column-width and
                column-gap are 0 we'd have an infinite situation. So
                does the range restriction change or do we allow?
  Rossen: dbaron is the point that having 0 width columns that if they
          are 0 width then everything will be fragmented and pushed
          forward? If we...I think we addressed in fragmentation where
          we defined meaningful progress and you always need to make
          progress in direction of consuming content.
  dbaron: I was concerned about the # of columns you get. If you don't
          have column count it comes from column width and in this
          case would be infinite.
  Rossen: I see.

  <TabAtkins> The problem with disallowing 0 *syntactically* is that
              it makes an open range, which we don't allow
  <TabAtkins> Just add a ua-defined minimum

  florian: I believe that's why we at some point said - it's not okay,
           but that makes a difference between 0 and 0.00000001 so we
           said that 0 is allowed but may round to a small value.
  Rossen: I'd hate that magic.
  <TabAtkins> Yeah
  <TabAtkins> We use that "magic" elsewhere
  Rossen: If we have an explicit floor let's have it be 1 or whatever.
          The magic value would only increase interop gaps.
  Rossen: So it better be explicit. Since today is 3.14 let's make it
          3.14 ^-^

  Rossen: What makes sense here? What should we do?
  <TabAtkins> I'm fine with an explicit noon-zero min, it's just
  <florian> I support allowing 0, and requiring any number smaller
            than 1px being rounded to 1px
  Rossen: dbaron or rachelandrew do you have a proposal?
  rachelandrew: For me 0 does make sense to allow but I don't have
                impl experience to know if it causes problems
  florian: I wrote my proposal in IRC.
  Rossen: By allowing 0 we round it to 1px regardless?
  florian: Yes
  <fantasai> I agree with not making this minimum syntactic
  Rossen: So allowing 0 is parsing but clamp to 1px.
  florian: Right. And this is error handling. Really no one creates
           columns of 0.01px

  Rossen: Opinions on this proposal? Allow 0 for parsing but keep
          clamping at 1px
  <astearns> +1
  <dbaron> sounds fine to me
  plinss: Can it be some epsilon value?
  <fantasai> I would go with less than 1px if we can
  <TabAtkins> Thus my "UA-defined minimum" wording previously...
  Rossen: What's wrong with 1px? It's much easier to explain and be
          interop on. If we do epsilon one browser will give you a
          different value then another. I'd rather be interop even in
          this weird edge case.
  <fantasai> 0.5px?
  plinss: Understood. I won't argue too strong. I think 1px might be
          too big in some cases.
  Rossen: Let's cross the bridge when we get there.
  plinss: Author can set smaller.
  fantasai: They can't.
  florian: But columns smaller then 1px isn't text layout. They're
           trying to do canvas so they should use canvas.
  <TabAtkins> Yeah, that's silly. There's zero call for 1px columns,
  plinss: There's situations where 1px isn't what you think a pixel
          is. They're doing microprinting.
  plinss: But I don't think it's that big of a deal.
  <florian> I'm ok with tab's variant (UA defined epsilon) as well,
            but I tend to side with Rossen, and would prefer interop

  jensimmons: Are column widths animatable?
  astearns: In theory they probably are.
  <TabAtkins> Yes, they are.
  dbaron: It is. It doesn't get performance optimizations, but it is
  myles: But doing that isn't a strong argument. It can't be negative.
  <TabAtkins> I don't care. Fine with explicit 1px minimum.
  <TabAtkins> (If it were possible I'd want a syntactic restriction to
              1px, but it's not really.)
  jensimmons: It's an argument to make it not 0.
  Rossen: If you're animating between 0 and 10 I guess, but this would
          happen for any sort of clamping we choose.
  jensimmons: Yes, thinking it through and it makes sense. Animating
              from 1px to 12em is possible, but from infinity is not.

  Rossen: Proposal: We allow 0 for column-width for the purpose of
          parsing, 1px is the minimum clamping value used for anything
          after parsing
  Rossen: Objections?

  RESOLVED: We allow 0 for column-width for the purpose of parsing,
            1px is the minimum clamping value used for anything after

  rachelandrew: I'll make the edit
  florian: Is clamping at used time or contribute value time?
  Rossen: It has to be used value.
  florian: Could be earlier.
  Rossen: Sure. You can do it at parse time if you want to.
  florian: You're going for interop so maybe we can define.
  Rossen: I don't believe it will be observable either way.

CSS Pseudo Elements

Add stroke-color and stroke-width to the list of highlight properties
  github: https://github.com/w3c/csswg-drafts/issues/2362

  Rossen: What do people think?
  ChrisL: I agree they should be added, as I said on the thread.
  <TabAtkins> +1
  Rossen: Other opinions?
  Rossen: Objections to adding stroke-color and stroke-width to the
          list of highlight properties.
  myles: Does stroke-width effect layout advances?
  ChrisL: No, that's what fantasai added for clarification.
  myles: When you highlight some text with super big stroke-width it
         could go outside of the highlight?
  ChrisL: Yes
  fantasai: Yes.
  myles: That's okay. Thumbs up.

  RESOLVED: Add stroke-color and stroke-width to the list of highlight

  fantasai: We should also resolve that strokes add ink overflow not
            scrollable overflow.
  myles: I thought that was the case.
  fantasai: It's a separate resolution that they shouldn't apply.
  myles: So why not put that with the width property and not highlight
  fantasai: Ye, I think it's not clear.
  Rossen: Proposal: clarify stroke properties effect ink overflow and
          not layout.
  <ChrisL> +1

  RESOLVED: Clarify stroke properties effect ink overflow and not

  dbaron: When do the properties effect anything when used on one of
          these highlight pseudo elements?
  dbaron: Most of these pseudo elements style text. Does stroke by
          default apply to text?
  fantasai: Yes.
  <fantasai> https://drafts.fxtf.org/fill-stroke/ applies it to text
  dbaron: Is that impl today or something you're imagining will work?
  myles: Webkit is implementing it.
  Rossen: Edge shipped a long time ago.
  ChrisL: There was a webkit specific property that did that which
          people used before standardization.
  ChrisL: So it derives from earlier experience.
  dbaron: Sure, I was worried pages would do unexpected things, but if
          edge is shipping that's not the case.
  ChrisL: Initial value means you shouldn't get a surprise unless you
          set it.
  Rossen: And I don't believe there's much uptake on the web currently.

  Rossen: Anything else on that topic dbaron or myles?
  myles: Not from me.

CSS Text

  Rossen: Preference on the order for the text items?

Letter spacing is inserted after RTL reordering
  github: https://github.com/w3c/csswg-drafts/issues/1509

  Rossen: koji brought this up, we discussed, and it's back again.
          Proposal is to resolve on #1509
  <fantasai> https://github.com/w3c/csswg-drafts/issues/1509#issuecomment-371384680
  Rossen: This comment from fantasai
  <fantasai> “Proposed that bidi resolution would result in splitting
             an inline in infinite space will always create two
             fragments, even if they end up adjacent due to line
  <fantasai> Behavior for letter-spacing (and other things affected,
             like box-decoration-break), falls out of this definition:
             in this case, if the two letters end up adjacent but are
             part of different fragments, the spacing between them
             will be given by the parent (according to the
             letter-spacing rules that control letter-spacing at
             element boundaries). This avoids the measuring problem.”

  myles: I'm a little confused about what fantasai said.
  fantasai: Issue was that let's say the p has letter spacing of 2em
            and span has 0. As you try and layout the line you try
            to...you stop laying out when you run out of space. If the
            point where you break introduces space as how the bidi
            reordering happens and then you add 2em to what the
            characters take up your line layout is confused. For text
            you want a predictable amount of space.
  fantasai: What happens here is bidi reordering splits the span. You
            have abc and 123 and they'll be 321 in left to right. Last
            2 characters are 3 and 2 and they push to another page. 3
            and 2 were separating the b and c so letter spacing came
            from the <p> When you take out the 2 and 3 you get the c
            and 1 next to.
  fantasai: Now that they're both a part of the span do you take the
            spacing from the span or the p. If you take from the span
            it's unpredictable.
  fantasai: Proposal is when you know the span will split you make
            that be an element boundary always. Even if they end up
            next to each other. Letter spacing between those needs to
            use the nearest common ancestor which is the <p> That's
            consistent with what spacing you would use if you have
            more space on the line.
  fantasai: That's what we're trying to solve. Get a consistent idea
            of how much spacing is used for each letter.

  myles: I think that's what webkit does as I understand. We'll break
         the c and 1 into separate objects. Later realizing they're 2
         objects and apply letter spacing independent. If I understand.
  fantasai: All impl don't handle the boundaries well. We have
            problems with letter spacing at the end of the line which
            makes authors unhappy. Spec is clear about no letter
            spacing at the end of the line or after an element. No one
            has that impl, but if you do letter spacing is tied to a
            pair of letters and needs to be determined by the nearest
            ancestor of those letters. So we need a more sophisticated
  myles: It's coming back to me. I agreed to investigate in Paris and
         I still want to do so. I think I said in Paris I'd do it in a
         year and I'm still in that window ^-^

  fantasai: We never resolved so we do need a resolution to do this.
  Rossen: I was trying to read minutes, sounds like there was
          agreement. myles your investigation, are you okay to resolve
  myles: Oh, yeah, we can resolve now. If I investigate and it's all
         wrong we can change.
  Rossen: Proposal: bidi resolution will result in splitting an inline
          finite space and already create 2 fragments even if they end
          up adjacent.
  <dbaron> yeah, I'm fine with this -- Gecko does this sort of
           splitting already
  Rossen: Objections?

  RESOLVED: bidi resolution will result in splitting an inline finite
            space and already create 2 fragments even if they end up

  Rossen: We're at the top of the hour.
  Rossen: One more time, please sign yourself up on the wiki. If
          you're going to attend the dinner please sign up and add any
          dietary restrictions.
  Rossen: Thanks everyone and bye.
Received on Wednesday, 14 March 2018 23:58:26 UTC

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