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

See correction to the CSS Text Resolution below

On Wed, Mar 14, 2018 at 7:57 PM, Dael Jackson <daelcss@gmail.com> wrote:
> =========================================
>   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
>       resolved.
>   - 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
>               layout.
>
> CSS Text
> --------
>
>   - RESOLVED: bidi resolution will result in splitting an inline
>               finite space and always create 2 fragments even if they
>               end up adjacent.

CORRECT RESOLUTION:
  - RESOLVED: If bidi resolution would result in splitting an inline
              in infinite space, it creates 2 fragments even if they
              end up adjacent due to line breaking.

>
> ===== FULL MINUTES BELOW ======
>
> Agenda: https://lists.w3.org/Archives/Public/www-style/2018Mar/0032.html
>
> Present:
>   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
>
> Regrets:
>   Angelo Cano
>   Vlad Levantovsky
>   Lea Verou
>   Greg Whitworth
>
> Scribe: dael
>
> Testing
> =======
>
>   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:
> https://log.csswg.org/irc.w3.org/css/2018-03-13/#e982865
>   <tantek> some background, my naive experience:
> https://github.com/w3c/csswg-drafts/issues/2378
>   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.
>
> CSS 3
> =====
>
> 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
>            resolution
>   frremy: We should move on.
>   Rossen: Okay.
>
> CSS Typed OM
> ============
>
> Does the is2D design allow for inconsistent interpretation of
>     CSSTransformComponents?
> -------------------------------------------------------------
>   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
>           are?
>   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
>              change.
>   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
>         attribute.
>   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
>              matrix.
>   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
>              return?
>   smfr: It would turn into a translate 3D.
>   TabAtkins: You're okay with that communication between nested
>              objects?
>   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
>          option.
>   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
>               arbitrary.
>   <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
>                 elsewhere.
>   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,
>               even.
>   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
>           animatable.
>   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
>             parsing.
>
>   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
>             properties.
>
>   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
>          styling.
>   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
>             layout.
>
>   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
>              breaking.
>   <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
>             letter.
>   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
>           now?
>   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
>             adjacent.
>
>   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 Thursday, 15 March 2018 00:13:31 UTC