[CSSWG] Minutes Telecon 2016-09-14 [css-text] [css-align] [css2] [css-syntax] [css-inline]

  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.


Agenda: https://lists.w3.org/Archives/Public/www-style/2016Sep/0038.html

  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

  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
  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
  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
  fantasai: So we'll go with don't have the computed value
  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
  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
  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
  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:
  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

  <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
  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

Received on Thursday, 15 September 2016 00:11:15 UTC