- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 14 Sep 2016 20:10:15 -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.
=========================================
Does 'align-self: auto' compute or behave as 'start' for abspos?
----------------------------------------------------------------
- RESOLVED: Don't have the computed value dependency.
url parsing contradiction between 2.1 and Syntax
------------------------------------------------
- This conversation needed TabAtkins, dbaron, and Bert and none of
them were available today so it was postponed.
Bounds of an inline box vs font fallback
----------------------------------------
- There was a strong leaning toward using the metrics of the first
available font.
- Rossen wanted to confirm there was minimal compat implications
so he asked that the formal resolution wait until TPAC.
Can tab-size be zero?
---------------------
- RESOLVED: Don't disallow 0 width tab size.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Sep/0038.html
Present:
Rossen Atanassov
Tantek Çelik
Dave Cramer
Alex Critchfield
Daniel Glazman
Dael Jackson
Brad Kemper
Ian Kilpatrick
Peter Linss
Myles Maxfield
Thierry Michel
Anton Prowse
Liam Quin
Andrey Rybka
Geoffrey Sneddon
Alan Stearns
Greg Whitworth
Steve Zilles
Regrets:
Rachel Andrew
Tab Atkins
Bert Bos
Tony Graham
Chris Lilley
Florian Rivoal
Jen Simmons
Scribe: dael
Rossen: Let's get started.
Rossen: As usual, are there additional agenda topics to discuss
today?
Rossen: I'll take that as a no. Is koji on for the first topic?
Rossen: So fantasai what if we proceed to topic 2 to see if koji
can join us?
fantasai: Give me one second.
Does 'align-self: auto' compute or behave as 'start' for abspos?
----------------------------------------------------------------
<Rossen> https://github.com/w3c/csswg-drafts/issues/440#issuecomment-244791183
fantasai: There's an auto value for the align-self property which
computes to the value of align items on the parent.
Issue here is right now auto is defined to compute to
normal if you have no parent.
fantasai: We also have a situation for abspos elements where it
needs to behave as normal and not take from the parent.
If you're abspos you mostly are positioned to an
ancestor in which case having your parent effect your
position doesn't make a lot of sense and is likely to
create confusion as that's not where you're going to
layout out.
fantasai: And a lot of times you want to set align-items to effect
ink-flow children. We have defined that if you had
abspos you take from the normal. Is that computed value
time or used time calculation?
Rossen: And so, to make sure I get this, I wasn't sure if you're
talking about only alignment or computing the auto
position different
fantasai: This is just the value of align-self on the abspos which
might effect other things, auto position of final
position depending on align-self.
Rossen: align-self should affect auto but it would take it into
account, right? So indirectly the parent's alignment will
affect the alignment of the element as far as the
auto-positioning is concerned. Do you see what I mean?
fantasai: Yeeeah. It's a question is static position effected by
align in parents.
Rossen: I don't see how it wouldn't be. With this the auto
position would be effected. I think the two are coupled,
static and alignment when static is used for computing
size and position. It's tighter than we want.
Rossen: I'm with you, I'd prefer if alignment applies in layout
context where ever that happens to be, but we'd have to
make sure that 80% of that won't happen independent and
20% dependent.
fantasai: Okay. This issue was focused on is this computed or used
value time issue. I didn't have an opinion. That rarely
affects authors. If we're questioning if we should have
this dependency that's a broader question that we could
talk about. That's not this issue.
fantasai: I don't have an opinion on this issue, we need
implementor feedback. Do you want computed value depend
on position or not?
Rossen: On our side I wouldn't like to have property dependency
based on computed value of other properties. I'd vote
independent.
Rossen: Both are implementable, though.
Rossen: I'd be interested to hear from Mozilla and webkit or Blink.
* fantasai dropped off, calling back in
Rossen: It sounds like we don't have enough feedback here. We can
postpone the issue until more implementors look. Or we can
continue talking now.
Rossen: I don't see to topic being engaged too much.
Rossen: Right. While fantasai calls back in...
fantasai: I'm back
Rossen: I was going to propose we push this topic to a later time.
fantasai: Is anyone planning to give feedback?
Rossen: For now it's you and me. We can try and engage more people
through feedback. We can otherwise put and see if it comes
back.
fantasai: So we'll go with don't have the computed value
dependency.
Rossen: Yes.
Rossen: But I would be reluctant to resolve solely on my opinion.
I can call for objections.
Rossen: Does anyone object to resolving on this issue?
<liam> on the phone but no objections :)
RESOLVED: Don't have the computed value dependency
Rossen: People can re-open if they feel strongly otherwise.
url parsing contradiction between 2.1 and Syntax
------------------------------------------------
<Rossen> https://github.com/w3c/csswg-drafts/issues/412
gsnedders: I brought up the issue, but I don't have an opinion. We
should resolve somehow.
Rossen: fantasai added it to the agenda. I'm with you we should
resolve.
Rossen: Did anyone look at this issue?
Rossen: If not, maybe you can summarize.
gsnedders: I think TabAtkins did more analysis. There were changes
of syntax parsing between 2.1 and the syntax module
Rossen: And the specific contradictions are summarized as what?
Rossen: In the issue you say 3, 4, 12, and 14 should fail
according to syntax spec.
<astearns> Tab said the tests were wrong
Rossen: TabAtkins said tests are wrong?
<gregwhitworth> currently Edge/FF render green, Chrome renders
them as red (thus correct I guess)
<gregwhitworth> what was the change & why
gsnedders: gregwhitworth, Firefox has changed and current nightly
matches Chrome.
<gregwhitworth> ahhh
gsnedders: Blink and Gecko do syntax, Edge does 2.1, Webkit does
neither.
gsnedders: My only opinion is not what webkit does.
myles: Webkit is impl new CSS parser so take what we do now with
less of a grain of salt than you would normally.
fantasai: Main issues are string termination causing url to not
match and closing brackets and braces; how that's
handled. I think to have a useful discussion we need
TabAtkins, dbaron, and Bert and I don't know if any of
them are here.
fantasai: If they're not here it's not useful to have this
conversation.
Rossen: So I'm hearing webkit is willing to follow whatever we
decide in the future.
Rossen: But let's move on because we can't resolve.
Bounds of an inline box vs font fallback
----------------------------------------
<Rossen> https://github.com/w3c/csswg-drafts/issues/391
fantasai: There's a contradiction in 2.1 about how the height of
an inline is calculated. One hand is that it's exactly
line height. Other hand it says it depends on the top
and bottom of the glyphs after they're aligned. If the
two baselines aren't identical you'll get shifting with
character. Deciding that it's one line height or the
bounding box is two different things.
fantasai: I did testing and I think the most sense is maintain
it's exactly that height. Else wise you'll get jittering
when there's font fallback and we don't want that. I
think we should resolve line height is from first
available font.
Rossen: Which impl do this?
fantasai: I posted in the issue. Let me see.
Rossen: I only see webkit
<gregwhitworth> Here is the test:
http://jsbin.com/lixoqijadi/edit?html,css,output
fantasai: Blink and Gecko use the metrics of the first available
font. I didn't get results on Edge.
fantasai: There's two advantages. 1 is we have interop. Second is
it reduces line height inconsistencies. So this is the
way to go.
Rossen: Edge and IE have different behavior than Gecko and Blink
from what I can test.
Rossen: Seems like we're closer to Gecko than Blink. I would need
to do a bit more testing before I can agree. I'm not sure
what the compat would be.
Rossen: Have we done any queries as to what the impact on compat
could be?
fantasai: Since we've got two impl that do the same thing and
authors want that I haven't tried to do compat.
<gregwhitworth> on Linux does the border overflow the black box?
<gregwhitworth> sorry - dotted border
Rossen: I don't see the behavior as the same between...let's see
the versions...between FF 48 and Chrome 53
Rossen: I still see some variance. The border calc...the red
dotted border in Gecko exceeds the box.
Rossen: From what I'm hearig they match.
fantasai: That's what I get on Linux.
Rossen: Nope, not the same for me.
<gregwhitworth> anyone on OSX?
<gsnedders> gregwhitworth: yes?
<liam> gregwhitworth - firefox and chrome behave differently here
on Linux, chrome clips the top of the accents at the red
dotted border, outside the black box
fantasai: Basically the red dotted border should be the same...
Rossen: As the black. I get the point but it's not in Gecko. In
Edge it's even larger.
fantasai: Okay.
Rossen: Given the difference and the variance as an implementor
I'm reluctant to go with any of those without knowing what
compat risk is.
iank: I just tried ours on mac and the red border doesn't match
for us.
<gregwhitworth< interesting, so it's OS specific
myles: Did blink change recently? Mine is older.
iank: We match with webkit but not Gecko. Sorry.
<iank> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cmeta%20charset%3Dutf-8%3E%0A%3Cstyle%3E%0Ap%20%7B%20border%3A%20solid%201px%20black%3B%20color%3A%20silver%3B%20font-size%3A%20100px%3B%20line-height%3A%201%3B%20margin%3A%200.1em%3B%7D%0Ap%20%3E%20*%20%7B%20border%3A%201px%20dotted%20red%3B%20%7D%0A%3C%2Fstyle%3E%0A%0A%3Cp%20style%3D%22font-family%3A%20Ahem%2C%20SimSun%22%3E%3Cspan%3E%C3%89p%E4%B8%8D%3C%2Fspan%3E%0A%3Cp%20style%3D%22font-family%3A%20SimSun%2C%20Ahem%22%3E%3Cspan%3E%C3%89p%E4%B8%8D%3C%2Fspan%3E%0A%3Cp%20style%3D%22font-family%3A%20Ahem%2C%20SimSun%22%3E%3Cspan%3E%E4%B8%8D%3C%2Fspan%3E
myles: Can someone post screenshots?
Rossen: I'm trying.
<fantasai> Screenshot of FF on Linux with the named fonts
installed:
https://lists.w3.org/Archives/Public/www-archive/2016Sep/att-0003/ff-linux.png
<liam> [actually i take it back, the difference between chrome &
ff here is just different font choices]
<liam> [here = on Linux ]
myles: In IRC liam said it's just font choices for Chrome and FF
which is what I see.
liam: For me on Linux the difference is font choice. If I change
the font to be the same they'd be identical.
myles: Sounds to be that Chrome, Webkit and FF do the same thing.
Rossen: Potentially.
Rossen: So. I'd like to go back and figure out what this would
mean for us in terms of implementation before I can feel
comfortable not objecting.
Rossen: My suspicion is this shouldn't be too difficult to change
for us. And given that blink and webkit are already in
agreement I don't believe we'll have too much of a compat
issue. I hope. I'd like to take some time.
gregwhitworth: It would also be good...both of you are using the
same font and FF is exceeding the border on
windows. It would be good if someone from FF would
look at why you're exceeding the border on Windows
and not elsewhere.
Rossen: To move this forward; fantasai are you asking for a
resolution today or would everyone be okay postponing this
for a week and we resolve at TPAC.
fantasai: I'm happy to resolve as soon as convenient.
Rossen: Okay. I wanted to make sure you weren't pushing for this
really hard and it doesn't sound like it.
<liam> [ on Linux 64bit - http://jay.w3.org/~liam/dottedborder.png ]
Can tab-size be zero?
---------------------
<Rossen> https://github.com/w3c/csswg-drafts/issues/460
Rossen: Koji isn't on, fantasai can you discuss?
fantasai: I think I can. Let me pull up the issue.
fantasai: The main issue is we said negative values aren't
allowed, but what do you do with 0? Koji is concerned
about impl that. It seems that basically all you have to
do is if 0 is your tab size you have a 0 width tab. I
don't see a problem, if other people are fine with it
I'll define what happens with a 0 width tab character.
Rossen: On our end I don't see a reason why we wouldn't have 0 or
why that would cause any problems.
<astearns> seems least surprising to allow 0-width tabs
myles: Same thing on our side. 0 width tabs should be fine.
Rossen: Do we have anyone from Gecko or Blink that feels otherwise?
Rossen: Okay.
Rossen: Objections to not disallow 0 width tab size?
Rossen: glazou from an editor perspective would this make any
difference?
glazou: I'm not sure.
Rossen: Because all the character advancement happens on the
content side and you will have basically no visual
indication of the caret movement. In terms of OM it's just
a 0 width character and no different from any other one.
But I want to give you a chance to interject.
glazou: I have to think about it.
Rossen: Are you okay with us resolving?
glazou: I'm fine.
RESOLVED: Don't disallow 0 width tab size
Rossen: That's the top of the agenda.
Rossen: I didn't hear additional items, so we'll have a short day.
Rossen: Safe travels to TPAC and I'll see all of you on Monday in
Lisbon.
Received on Thursday, 15 September 2016 00:11:15 UTC