- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 14 Mar 2018 20:12:21 -0400
- To: www-style@w3.org
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