- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 14 Mar 2018 19:57:18 -0400
- 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
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.
===== 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 Wednesday, 14 March 2018 23:58:26 UTC