- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 26 Jun 2014 11:24:04 -0400
- To: www-style@w3.org
Charter Update
--------------
- plh reported that the charter process is going well and nearing
completion.
Upcoming F2F location
---------------------
- As at least one group member has already made reservations for
Sophia/Antipolis, the current focus is to try and have the
meeting there.
- plh will investigate if the W3C is prepared to host.
CSS Masking to CR
-----------------
- RESOLVED: CSS Masking to CR
Explaining <br>
---------------
- The performance implications of creating a special case of
display-box: content or creating a whole new display value
were compared.
- Some members thinking that the special case would potentially
create negative performance implications.
- Others felt that the new display value would create
unnecessary complexity.
- Ultimately it was decided that there still wasn't a good
solution to this problem and it was put back on the shelf
until someone comes up with a better solution.
Flexbox percentage heights in column direction
----------------------------------------------
- The basic issues of this problem were hashed out and clarified.
- Discussion will now move back to the mailing list to try and
find a solution.
background-blend on the root element
------------------------------------
- RESOLVED: Solve as Rik requests in
http://lists.w3.org/Archives/Public/www-style/2014Jun/0280.html
====== FULL MINUTES BELOW ======
Present:
Glenn Adams
Tab Atkins
David Baron
Rik Cabanier
Tantek Çelik
Dave Cramer
Bruno de Oliveira Abinader (IRC Only)
Elika Etemad
Simon Fraser
Koji Ishii
Dael Jackson
Brian Kardell
Philippe Le Hégaret
Chris Lilley
Peter Linss
Edward O'Connor
Matt Rakow
Dirk Schulze
Simon Sapin
Alan Stearns
Greg Whitworth
Steve Zilles
Regrets:
Bert Bos
Sylvain Galineau
Daniel Glazman
Simon Pieters
Lea Verou
Charter Update
--------------
plinss: Let's get started
plinss: Anything to add?
plh: I can do a charter update
plinss: Okay.
plh: I've got all the necessary stuff. I expect the charter to go
to the CRs and approved no later than Friday. We're all good
on that front.
plinss: Cool. It will be nice to be under a charter again.
Upcoming F2F location
---------------------
plinss: TabAtkins was looking in Zurich?
TabAtkins: I'm in a restaurant. Can you hear me?
TabAtkins: I've not yet done so. Sorry.
plinss: What's an ETA?
TabAtkins: Next week if we don't decide to go somewhere else prior.
SteveZ: I assumed that we were set for Sophia/Antipolis so I have
reservations for those dates and would object to changing.
plinss: Is that a non-refundable situation?
SteveZ: It is.
plinss: Any other input, or should we commit to Sophia/Antipolis?
TabAtkins: I have no problem with that.
plh: I don't know if we have approval to host in Antipolis. Is W3C
hosting there?
SteveZ: That was the proposal.
plh: I won't object, but I want people to realize we're not doing
it in Zurich. I hope ChrisL and/or bert made sure we have the
budget.
plinss: ChrisL or bert are you there? [silence] Doesn't look like
it. We need to do research.
action plh to ping bert or ChrisL about budgeting for the Sept F2F
<trackbot> Created ACTION-633 - Ping bert or ChrisL about
budgeting for the sept f2f [on Philippe Le Hégaret -
due 2014-07-02].
plh: FYI for those on the call the next extensible web is in
Berlin on Sept 11.
plinss: There's something else in Berlin too.
plh: On the 12th there's a CSS conference and on the 13th there's
another conference.
SteveZ: If you fly on Luftansa you can get to Berlin easily from
Nice?
plh: Yes.
<dbaron> As I said before, I and other Mozilla folks probably
won't be able to make the week of Sept 8-12
<dbaron> Although I still don't know for sure.
<SimonSapin> (plh, was the September extensible web summit
announced yet? I only find stuff about the one last
April.)
<plh> Simon, not yet, it will be announced before the end of the
week. I'm working with Dan on this.
<SimonSapin> thanks plh
CSS Masking to CR
-----------------
<krit> http://www.w3.org/TR/css-masking-1/
<krit> http://dev.w3.org/fxtf/css-masking-1/issues-lc-2014.html
krit: The LC period is over. I got a lot of positive feedback.
krit: I got one piece of feedback with one issue so there's a typo
with border-box initial value. I changed it to auto.
krit: Other than that there were no change requests, so I'd like
to go to CR.
plinss: Any objections?
TabAtkins: No
fantasai: I didn't review, but I can't object because of that.
RESOLVED: CSS Masking to CR
plinss: How are the test suites? I see 53.
krit: It's particular to SVG, but I'll upload from webkit. For the
new parts we need more tests for coverage since they're not
in browsers yet.
plinss: You'll prepare the draft and ping ChrisL or bert?
krit: Yes.
Explaining <br>
---------------
plinss: TabAtkins?
TabAtkins: At the last F2F we discussed defining the style of <br>
using display-box: content and other properties.
TabAtkins: Since then in the whatwg bug dbaron objected due to
performance implications.
TabAtkins: That's fine, but I want to define it in some way. One
way would be to create a new display value for new
lines.
TabAtkins: Does dbaron think the performance concern is large
enough to pursue a new method?
dbaron: I don't know off the top of my head. Maybe we can special
case the one thing.
dbaron: If something is display-box: content and has this thing
inside we don't take the normal code path, but do this
other thing.
TabAtkins: I would prefer not odd special cases if possible.
<ChrisL> I would prefer not having had a br element, but there we
are.
dbaron: Special is in code.
TabAtkins: If our recommended style for it requires weird special
cases, we should address it more directly.
fantasai: I don't agree. I think if we have a special code path
that constructs a frame with equivalent behavior, but if
other properties are different you use the normal code
path, that's fine.
fantasai: As long as to the author it behaves in a consistent way
that's good. If we create a display value for new lines
that's harder to understand for the author.
fantasai: In addition you have various code paths you have to
write in the engine.
fantasai: If we're doing this for performance improvements,
creating a whole new feature seems like overkill and
extra work for testing and implementation and especially
for authors.
fantasai: I think it's fine.
fantasai: We do something weird and special because this is
common, else wise we do the normal path.
<ChrisL> agree with fantasai. This is a legacy special case that
we can't get rid of
TabAtkins: While I would agree in the past, as I have more
implementor experience, I think having these special
paths slows things down.
fantasai: You'd need one anyway for a new method.
<SteveZ> Is the issue one of code path complexity and therefore
maintenance?
TabAtkins: But specifically if you have this style as this way do
something magic, that's different, from having a
special display value.
TabAtkins: Having the special case path where "if something has
this part treat it different" ends up being annoying
for the code and slows everything down. Removing these
helps performance. I'd prefer if we do a weird special
thing, I'd rather it being it's own case.
TabAtkins: I don't like where if you make a small change it goes
to hell because there's a specific optimized path.
<tantek> yes that ^^^
<tantek> very bad for web authors
<gregwhitworth> Agreed
<ChrisL> /* Don't change this code, it will <br> */
TabAtkins: What we're asking is, if you do this in this particular
way it's fast, but else wise it goes slow.
<SteveZ> How much slower will this BR form be?
fantasai: How many people will style <br>?
fantasai: I don't think it is worth a new feature that we have to
work on and create a generic implementation.
tantek: Lots of style sheets do style with universal selector. I
think there's lots of cases out there and we don't know it.
dbaron: I think that authors not changing it much is an argument
for not worrying about <br>.
TabAtkins: You mean we should make <br> special magic?
dbaron: Yes.
TabAtkins: I don't like it, but I like it better than a weird
special case.
plinss: Sounds like it's a special case one way or the other.
fantasai: Maybe your implementation doesn't need that optimization.
TabAtkins: We almost certainly do. If it's a problem for Mozilla,
it's likely a problem for us.
dbaron: I don't know it is, but I suspect it will be slower.
TabAtkins: That's our expectation for display-box. It'll be useful
but slower.
plinss: Sounds like this goes back on the shelf?
rossen: If we were to implement with display-content it would have
performance implications. For us now <br> is line-layout
without more drama. Anything more will add something to
performance time.
fantasai: Would it be possible to define <br> as rendered
equivalent to this CSS rule, except impl are allowed to
make it non-override-able.
fantasai: Then browsers can keep their current implementations,
but at least the rendering is defined.
rossen: I think people mentioned that they do style <br> a bit and
I've seen evidence of it.
rossen: We'd take a compat hit with breaking <br> styling and I'm
not a fan of that.
rossen: If we end up breaking the content it'll likely be old
legacy content and not likely to change. I'm not sure
that's an odd trade-off.
plinss: My concern is if we explicitly define it, it makes it
harder to come up with a better approach later.
TabAtkins: Another problem is that we're assuming we won't have
anything in the future that would over-ride that style.
I don't think it's a stable solution overall.
plinss: I think we need to let this percolate until we come up
with something better.
* tantek agrees with plinss
fantasai: I thought the conclusion was we can't come up with
something better because it involves making this a style-
able box.
plinss: I'm saying one day someone might come up with another
solution. I'm not willing to declare it forever unsolvable.
<tantek> yes that ^^^
Flexbox percentage heights in column direction
----------------------------------------------
TabAtkins: There is some disagreement between browsers about when
a length is definite or indefinite when it's the size
of a flex-item.
TabAtkins: Chrome says indefinite unless there's a defined
flex-basis
TabAtkins: Other browsers have different rules that I haven't been
able to intuit. I'm not sure when they decide they're
definite for purposes of inheriting to their children.
TabAtkins: The things we defined as definite would say that things
are definite when they have a defined flex-basis, but
I'm not sure.
fantasai: Even with a definite flex-basis, they're flexible so
should we be defining?
TabAtkins: With a definite flex-basis and they're flexible, it's
at least theoretically okay to resolve percentages.
Firefox does. Chrome calls it indefinite.
rossen: Question, what is the test case? You have a flex box with
column direction and a flex item that's auto-size and an
item inside that is percent height?
TabAtkins: There's variations. The flex item is always flexible
but the basis is auto, percentage or fixed size. The
three implementations are different on every one of
those cases.
TabAtkins: I don't know the correct answer.
TabAtkins: The postings from gregwhitworth aren't loading for me.
I'm having trouble giving a sensible answer.
fantasai: If you resolve percentage against any of these things,
you'd resolve against a hypothetical size that may or
may not be the size of the flex item?
TabAtkins: Why?
fantasai: It's flexible.
TabAtkins: When child percentage is resolved against a flex item,
it's after flex sizing.
rossen: That's our code.
TabAtkins: You run flex, lay out children, resolve percentage.
rossen: I think we do the same for grid.
rossen: This is the same argument that was being made where with
components it is nice to resolve at the top and let grid
take care of the inner layers and outer shape.
rossen: I think we resolved on this issue back in Lyon TPAC.
rossen: We discussed allowing percentages inside auto-size.
TabAtkins: You're thinking of the cross dimension where what we
have is a solution that right most of the time and that
solutions is in the spec already. This is the main
dimension.
dbaron: For what it's worth dholbert prefers the Firefox/IE
behavior where we treat it as definite if it's definite at
the time that matters.
TabAtkins: I don't know if that applies to flex items with a auto
base size.
TabAtkins: That should be fine for the other cases when you have a
length, flex, and then lay out your children. In auto
you count your children and then lay out and I'm not
sure if that's definite.
rossen: Did we resolve that flex-basis is a use time value and
defined as used not computed?
rossen: I think about a month ago we decided that flex-basis was a
use value, not computed. It assumes that all the flex
items are already measured to their flexibility and then
we have a use size we can resolve percentage against.
TabAtkins: Hmm.
TabAtkins: You may be right on that.
TabAtkins: Okay. I need to go and research that.
TabAtkins: I've been avoiding the thread, but I think I need to
load flex into my brain.
TabAtkins: Now that I have a grasp on the discussion, let's go
back to the thread and sort out how our previous
resolutions deal with this. I think I can be convinced
Chrome is a bug with some or all of these cases.
rossen: I'm fine with that.
TabAtkins: Cool.
<fantasai> Tab, I don't think used vs. computed value of flex-
basis is a relevant thing here.
background-blend on the root element
------------------------------------
<TabAtkins> http://lists.w3.org/Archives/Public/www-style/2014Jun/0280.html
TabAtkins: Is cabanier around?
cabanier: Yes, sorry. I was on mute.
cabanier: So it looks like there was feedback from Alan this
morning. I'm not sure what's supposed to be happening,
there's different Firefox and WebKit behavior.
cabanier: Firefox pulls up the background layer and draws. Webkit
draws an external layer in white.
cabanier: Now that we expect these layers to be in order, it's
different. It's possible for others to work around it,
but it's a bit weird.
TabAtkins: I completely agree with your question on the thread. We
should say the root element blends and then transposes.
It's odd that the final background is white and that's
an odd detail we shouldn't expose
dbaron: I don't think the final is white in iframes, in some cases.
cabanier: It seems it's only the root elements. There's something
going on.
TabAtkins: It may be an implementation bug.
cabanier: Firefox sometimes draws differently. That's a bug.
Should it be fixed in blending or color?
cabanier: We need to define that the root element is different.
krit: Does it apply to SVG as well?
cabanier: I think it would apply there, I haven't tried it because
there isn't blending in SVG.
TabAtkins: If you're doing background blending in SVG you wouldn't
use white, you'd do transparent.
TabAtkins: Likely we want to do it in colors so that if we want
anything that goes and uses root it blends against the
transparent and untouchable background.
TabAtkins: The backdrop color is untouchable and you can't do
anything with it except map your page.
cabanier: I think that's the behavior most would expect.
plinss: I think that's correct. I don't want to bake an opaque
background into the platform.
plinss: So are we ready to resolve?
cabanier: That CSS Colors needs to define this?
TabAtkins: That whatever browsers do for the backdrop, the page
mattes against that.
TabAtkins: I'll wordsmith it.
RESOLVED: Solve as Rik requests in
http://lists.w3.org/Archives/Public/www-style/2014Jun/0280.html
plinss: I think that's it. We had Animations issues from Sylvain,
but he sent his regrets.
plinss: Anything else?
plinss: Talk to everyone next week.
Received on Thursday, 26 June 2014 15:24:31 UTC