W3C home > Mailing lists > Public > www-style@w3.org > October 2016

[CSSWG] Minutes Telecon 2016-10-26 [css-text] [css-2] [css-position-3] [css-box-3] [css-21] [css-align] [css-inline] [css-masking] [css-table]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 26 Oct 2016 21:03:13 -0400
Message-ID: <CADhPm3s+0ro2hyFXT2Uk=1mbA2y5JGNA1SwU=30VAb_5E3qicQ@mail.gmail.com>
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.
=========================================


Define effect of text-transform on copy/paste
---------------------------------------------

  - RESOLVED: Rich text copy/paste is undefined in text level 3.
  - Originally the group resolved that plain text copied to the
      clipboard must (or should) not be affected by text-transform
      in text 3, but there was an objection from koji so the group
      will revisit next week.

Absolutely positioned boxes in inline relatives: not interoperable
------------------------------------------------------------------

  - dbaron requested more time on the topic, so discussion will
      continue on github

Positioning boxes with { float:left; width:0px; }
-------------------------------------------------

  - RESOLVED: 0px width float that is next to a line box does count
              as shortening a line box

Deal with first vs last baseline
--------------------------------

  - RESOLVED: Change "baseline|last-baseline" to "[ first | last ]?
              baseline"

Initial value of mask-repeat and mask-position
----------------------------------------------

  - RESOLVED: Match webkit/blink behavior for initial value of
              mask-repeat and mask-position
  - RESOLVED: ChrisL, TabAtkins, and shane as editors for masking
              spec.

Hoisting things to table wrappers
---------------------------------

  - RESOLVED: Add hoisting of listed properties
              (https://drafts.csswg.org/css-transforms/#grouping-property-values)
              other than overflow.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2016Oct/0126.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Alex Critchfield
  Tantek Çelik
  Dave Cramer
  Elika Etemad (IRC only for part of the call)
  Simon Fraser
  Tony Graham
  Koji Ishii
  Dael Jackson
  Brad Kemper
  Vladimir Levantovsky
  Chris Lilley
  Peter Linss
  Simon Pieters
  Liam Quin
  François Remy
  Florian Rivoal
  Alan Stearns
  Lea Verou
  Johannes Wilm

Regrets:
  Daniel Glazman
  Michael Miller
  Anton Prowse
  Jen Simmons
  Greg Whitworth

Scribe: dael

Define effect of text-transform on copy/paste
---------------------------------------------

  Rossen: Let's get going.
  Rossen: As usual, any additional agenda items?

  <dauwhe> https://github.com/w3c/csswg-drafts/issues/627
  Rossen: There were a couple of topics linked to the same issue
          last week.
  Rossen: I wasn't on the call, but there was a bunch of discussion
          on this already. There were requests for data gathering
          which we did on our end and hopefully others did too.
  Rossen: This idea is to box this discussion to 5 minutes. We could
          stretch to 7 if needed. We want to get to the bottom of
          this. If there's nothing we can get out of this that's a
          strong signal as well.

  Rossen: In my e-mail I asked the people with strong feelings to
          have a quick summary of their proposal
  Rossen: I know fantasai is only on IRC so I'll try and allow her
          to get in her proposed behavior.
  <tantek> I still have the opinion that text-transform should be
           IGNORED for plain text copy/paste.
  Rossen: In the meantime is there anyone with something new or
          concrete?

  <fantasai> I agree with Tantek and Florian, obviously.
  <fantasai> The proposed behavior is that rich text copy/paste is
             not defined
  <fantasai> And in the absence of the user's explicit direction to
             the contrary (through some kind of option or variant
             abilities), text-transform is ignored.

  johanneswilm: I talked to 5 editor projects and they had various
                opinions on plain text. In Chrome text-transform is
                also on HTML version which is highly problematic for
                at least 4 projects because one can't make a
                different plain text version. Otherwise what plain
                text does isn't that important because you can
                create a different plain text version using the html
                version.
  <tantek> the fact that text-transform is applied in Chrome for the
           HTML copy/paste makes it seem like it's a side-effect of
           the code, not a deliberate design, as that seems like an
           obvious bug.
  <tantek> and thus undesirable
  <tantek> I think Chrome is buggy here - is there a bug filed on
           this?
  Rossen: Do you have any proposed behavior to define or is this
          just a summary?
  johanneswilm: Proposed is for the html version to not apply
                text-transform and keep it in a style. It's changing
                the HTML structure and so there's no way you can get
                original text.
  <fantasai> +1 johanneswilm

  Rossen: I'm going to real-time try and rephrase fantasai.
  Rossen: [reads]
  Rossen: So fantasai tantek and Florian propose we leave this
          undefined
  Rossen: I'll also +1 on that.
  tantek: Just one clarification. I'm okay undefined for HTML but
          for plain text we should state text-transform should be
          ignored.

  tantek: Follow-up for johanneswilm: that seems like an obvious
          bug. Is there a bug filed on that and, if not, can you
          file a bug on Chrome? Because that doesn't seem
          deliberate. It seems an error
  johanneswilm: I haven't looked for bugs, but I can file if there
                isn't one.
  * bradk wonders if there is a reason/limitation that causes Chrome
          to do that.
  tantek: I think filing the bug would help.

  Florian: I still agree with the previous, but I want to raise a
           github possibility. The idea would be treating rendering
           into plain text as a separate media and have a MQ for
           that.
  <fantasai> Florian, I think that level of complexity atm is not
             necessary :)
  <tantek> +1 fantasai
  Florian: You would say text-transform is technically applied but
           you could have an @media clipboard that does
           text-transform none but the editors could indicate when
           something is important. I'm not sure I have an opinion.
  Rossen: That's a good discussion for MQ. WE should have the
          conversation there. Having the sync around that may be
          overkill in my opinion.
  <bradk> @media clipboard { body{ display:none; }}
  <fantasai> Florian, It could be interesting, but I think rarely
             used. It won't interact properly with the cascade since
             we want the default behavior to be a set of UA-defined
             behavior.
  <fantasai> Florian, so I'm against going in that direction.
  <fantasai> (the MQ direction)

  Rossen: It sounds like there is growing consensus on undefined
          which makes these conversations moot.
  <tantek> where is the consensus on undefined for plain text?
  Florian: There's not consensus on undefined.
  Rossen: We can ask for consensus.
  Florian: For defining rich text there's consensus for undefined.
           For plain text koji pushed undefined, lots of people not
           caring, and a bunch of us pushing to define it.
  tantek: Yes.
  <tantek> I agree with Florian's summary
  <tantek> that seems like an accurate assessment of the current
           situation
  Rossen: So we have 2 proposed resolutions. 1) leave it undefined.
          2) define plain text unaffected by text-transform. Fair
          summary?
  Florian: What's the 'it' undefined. Rich text?
  Rossen: Correct.
  Rossen: [pauses for fantasai comments]
  <fantasai> Proposal 3: make it SHOULD rather than must ;)
  <tantek> I can live with SHOULD (yuck)
  <astearns> I could live with SHOULD
  <tantek> I would prefer MUST IGNORE
  <tantek> MUST > SHOULD > undefined
  <fantasai> Then people who for some reason think it gives a better
             result can do something "with deliberate consideration
             of the consequences" or whatever it was RFC2119 defined
  <fantasai> But otherwise they have to ignore.
  <fantasai> So any UA that wants to ignore the SHOULD needs to
             submit an essay instead of a passing test result ;)
  Florian: I could live with should but I'm not sure it helps. We're
           trying to go for interop. A should just lets browser do
           what they currently do.
  Rossen: If we can get 2 impl to agree on this we'll be fine.

  <fremy> at Rossen, fantasai: plain text is affected by
          text-transform in Microsoft Word (copy from Word to
          Notepad)
  <johanneswilm> notice that at least word (?) and some of the
                 webbased editors create their own plaintext version
                 based on the html version.

  Rossen: We have proposed resolution: leave rich text undefined and
          define text-transforms should not effect plain text on the
          clipboard
  Florian: There's a bunch of people who can live with should but I
           think they prefer must. Can anyone not live with must?
  <tantek> +1 MUST IGNORE, +0 SHOULD IGNORE, -1 undefined
  <bradk> Must +1
  <Florian> +1 MUST IGNORE, -1 SHOULD IGNORE, -13.5 undefined
  <fremy> -1
  <liam> +1 should, -1 must for text

  Rossen: From reading minutes I think there were people that felt
          stronger...maybe Apple? I want to hear from them.
  smfr: I think that was myles and I disagree so Apple isn't
        cohesive.
  myles: I'll defer to smfr.

  Rossen: So proposed resolution: rich text is undefined in text
          level 3.
  Rossen: Objections?

  RESOLVED: Rich text is undefined in text level 3.

  <fantasai> Rossen, I think johanneswilm's point that HTML paste
             shouldn't transform the text
  <fantasai> is valid
  <fantasai> We shouldn't define how styles are kept or not
  <fantasai> but that's an issue.
  <fantasai> The underlying text shouldn't be converted for HTML
             paste
  Rossen: Proposal: plain text copied to the clipboard must not be
          affected by text-transform in text 3
  <tantek> +1

  RESOLVED: plain text copied to the clipboard must not be affected
            by text-transform in text 3

  Rossen: Is the next topic fantasai's?
  <fantasai> defer pls
  Florian: Didn't we close last time on this with waiting on a
           concrete proposal from fantasai?

  koji: I don't think it's a good idea to define plain text.
  Rossen: koji are you saying you didn't hear proposal about copy/
          paste?
  koji: Yes.
  Rossen: We resolved that the rich text is undefined in text level
          3.
  koji: Fine with me.
  Rossen: Plain text is defined that text-transforms must not effect
          plain text.
  koji: I'd like that undefined.
  Rossen: Are you objecting?
  koji: Yes.
  koji: Last week in straw poll it was half and half.
  Rossen: This week you're the only one not okay with it.
  Rossen: Apple has changed their mind since then.
  koji: I saw myles defer to smfr. smfr said something?
  smfr: I tested and our current behavior is respect text-transform
        when copy/paste plain text. So I'm less convinced.
  <tantek> smfr, we knew that already as legacy behavior in Webkit,
           but as an accident, not deliberate design
  <tantek> smfr, would you consider fixing this?

  <johanneswilm> And apparently we all agree that Chrome changing
                 the html structure and directly applying
                 text-transform is just a bug and doesn't require
                 the decision by us?
  <tantek> johanneswilm, certainly you got consensus on that from
           the editor makers, so mention that in the bug. You can
           cite these logs too.
  <johanneswilm> ok

  Florian: So are we back on should not?
  smfr: I'd prefer not a must.
  Rossen: I can live with should.

  koji: So smfr you said you respect but you'd be okay to change?
  smfr: We respect text-transform now. I don't know if we're okay to
        change I'd have to talk to other people.
  koji: Proposal is must not.
  Rossen: Yes and we're proposing to make it should not.
  Rossen: So koji can you live with that resolution?
  koji: I need to go back to the team and discuss.
  Rossen: Would you object to should not? You can come back next
          week and discuss if you still feel it should be undefined.
  Rossen: Current consensus is around should not which gives you a
          way out of the behavior.
  <tantek> also, would prefer that more discussion require new data
           on this
  <bradk> Should be at least SHOULD
  koji: So apple is going to change?
  Rossen: Nobody is asking you to change anything at the moment.
  koji: hum.

  Rossen: Let's try this one more time. Proposed resolution is text
          level 3 defines that plain text copied to the clipboard
          should not be effected by text-transform
  koji: I object.
  Rossen: Okay.
  Rossen: So let's record the objection and we'll revisit next week.

  <tantek> if koji is objecting to both MUST and SHOULD, then we
           might as well resolve on the MUST
  <tantek> since the consensus is equivalent

  <fantasai> koji, when you go back to talk to your team about
             text-transform and copy/paste, please send them links
             to both
https://lists.w3.org/Archives/Public/public-editing-tf/2016Apr/0005.html
             and
https://lists.w3.org/Archives/Public/www-style/2016Oct/0115.html ?

Make hanging-punctuation scrollable overflow
--------------------------------------------

  Florian: fantasai said on IRC we should defer. And we said last
           time we should defer until she writes a proposal.

Absolutely positioned boxes in inline relatives: not interoperable
------------------------------------------------------------------

  <Rossen> https://github.com/w3c/csswg-drafts/issues/609
  Rossen: fremy could you rejoin the call?
  fremy: Yes, I'm here.

  fremy: The issue is simple. When you have an inline box that
         tracks across 2 lines and you said position: relative it's
         not defined which anchor you should use in CSS 2.
  fremy: This changed in position 3. It's not what Edge and Chrome
         implement. In ltr we match so I was asking if we can change
         the spec and do the same thing in reverse for rtl.
  dbaron: You mentioned Edge and Chrome [missed]
  fremy: I guess Safari is doing same.
  dbaron: Gecko?
  <smfr> github says “ltr: Firefox considers "bottom" and "right" to
         be the bottom/right of the first fragment.”
  ChrisL: Gecko does the right thing.

  fremy: It's not as defined in position 3 either. From my notes
         Firefox considers bottom right to be bottom right of first
         fragment. Spec requires you to have bottom right to be of
         second fragment. Chrome/Edge does right to be left of first
         fragment.
  fremy: I think it's fine to say we have interop and we follow this.
  * bradk thinks gecko behavior sounds much better
  dbaron: So right is based on left edge of first fragment?
  fremy: Yes.
  dbaron: That's strange
  TabAtkins: I agree.

  dbaron: About the test cases you should separately test if the
          right of the last fragment is the right of the left of the
          first fragment or the left of the left of the first
          fragment.
  fremy: Test cases were conclusive. I'm fine leaving spec as-is.
  dbaron: I'd like more time on this.
  fremy: Okay. Let's defer to next week.
  dbaron: I won't be on for next two weeks. Maybe we can continue on
          github.
  Rossen: Let's take it back to github.
  fremy: Yep. Let's do that.

Positioning boxes with { float:left; width:0px; }
-------------------------------------------------

  <Rossen> https://github.com/w3c/csswg-drafts/issues/576
  Rossen: Who added this?
  fremy: Probably me.
  TabAtkins: astearns put it back on.
  Rossen: Is it close? Do we need discussion?

  fremy: We need to resolve. Last time we concluded but people
         wanted more time to review. We said if you have 0px floats
         it's shortening the line so you wrap to the next line.
  fremy: If people are fine we can resolve.
  TabAtkins: This means if you have an inline that exactly fills
             space a 0px float stays. If it's larger the float wraps?
  fremy: Yes.
  TabAtkins: Perfect. I agree.
  Rossen: Which test case in github is an example of what you just
          described?
  fremy: First 2.
  Rossen: Both I see interoperability.
  <tantek> is this bugwards / accidental interop? or deliberate?
  fremy: You must be on a different Edge version..
  Rossen: 0px floats cannot fit in a 0px available width?
  fremy: It's when you have a negative avail width. If your line
         already overflows you're on the next line.
  Rossen: I'm fine with it.

  <dbaron> these testcases are complicated enough that I'm not
           incredibly confident that we're even discussing the right
           issue to cover the testcases
  <tantek> agreed with dbaron

  Rossen: Objections to defining that floats in an over-constrained
          scenario drop to the next line?
  dbaron: That's not really the resolution.
  Rossen: No? That's what I heard.
  dbaron: The issue is about if the inlines are pushed down. It's a
          0 width float constitutes a float that shortens the
          linebox.
  Rossen: I can live with that as well.
  TabAtkins: That's if the float is before. If the float is after
             it's pushed down.
  Rossen: Correct.
  fremy: Yes.
  Rossen: How is the 0px width any significance?
  TabAtkins: Because 0px don't take space. You can always cram them
             onto a line without making it worse.
  dbaron: We should be very careful, but the reason I thought it was
          is because the spec says "if a float shortens the linebox"
          A 0px width float counts as a float shortening the
          linebox. I believe that's the clarification.
  TabAtkins: I think so. I think that's the actual spec change.
  fremy: I think that's it. A 0px float is shortening the line box.
  Rossen: Okay. I can live with this behavior
  <fantasai> Proposal for hanging-punctuation is,
             hanging-punctuation is scrollable overflow. UAs *may*
             trim the blank half of overflowing CJK punctuation that
             takes up 1ic but only has ink on the inner half. (This
             will have no effect on rendering but may affect the
             scrollable area.)
  dbaron: Specifically 0px width. Not height.

  TabAtkins: It's the same as flexbox. If you have a 0px flexbox and
             a really big thing, the really big wraps. If you
             reverse the big stays and the 0 wraps.
  TabAtkins: Flexbox spec is explicit about this. Float is less. It
             gives you constraints. Flexbox should be interoperable
             on that because it has an algorithm that says do this
             thing.
  Rossen: Okay.

  Rossen: dbaron can you summarize proposal one more time?
  dbaron: Proposed resolution: 0px width float that is next to a
          line box does count as shortening a line box
  Rossen: Objections?
  fremy: It's fine.

  RESOLVED: 0px width float that is next to a line box does count as
            shortening a line box

Deal with first vs last baseline
--------------------------------

  <Rossen> https://github.com/w3c/csswg-drafts/issues/210
  TabAtkins: I believe this was raised by fantasai.
  Rossen: Given that she's not on the call...
  Rossen: We can postpone in the call or next week
  Rossen: So she doesn't have to write.
  <fantasai> I can call in 2 min
  Rossen: Are there any issues that aren't fantasai's?

Initial value of mask-repeat and mask-position
----------------------------------------------

  <Rossen> https://github.com/w3c/csswg-drafts/issues/599
  dbaron: At some point we resolved that mask-repeat and
          mask-position have different initial values than
          background. It's not compat with webkit-mask-repeat and
          webkit-mask-position. There's a bunch of web content that
          depends on the values. We've had what the spec says in FF.
  dbaron: We've gotten some of the sites to fix the behavior. We do
          still have compat problems.
  dbaron: Question is; we're close to rolling back and doing same
          initial values as background-position.
  dbaron: In the chromium bug there was a suggestion that we behave
          different for prefix and unprefix though it's not clear to
          me how you do that. If everyone uses shorthand maybe
          webkit-mask shorthand would specify different values. I
          don't have data on shorthand usage.
  dbaron: We're having enough compat problems we're likely to roll
          back.
  Rossen: Any other opinions?

  TabAtkins: We're for keeping spec as-is. Though twitter fixed it
             there's likely other stuff around. no-repeat is a
             better value in isolation in mask, masking for similar
             properties makes sense too. I'm fine changing spec to
             match Chrome behavior.
  Rossen: Any objections to matching webkit/blink behavior and
          record that into the spec?
  fantasai: Do we have a editor?
  TabAtkins: Kinda? krit is technically the editor but shane and I
             will do edits.
  fantasai: There were some other issues with masking that I'm
            guessing isn't edited in. They may be on stats page. We
            need an active editor for masking.
  <ChrisL> agree we need an active editor for masking
  Rossen: That's a great point.

  RESOLVED: match webkit/blink behavior

  Rossen: Next we need official editors. I heard TabAtkins and shane
         stepping in. Yes?
  TabAtkins: Yep.
  <krit> I would welcome another active editor on mask
  Rossen: Anyone else want to be an editor?
  ChrisL: TabAtkins you edit an awful lot of specs.
  ChrisL: Applying TabAtkins doesn't necessarily increase output.
  TabAtkins: Which is why we're adding shane as well.
  ChrisL: This is graphics-y. I'd be interested.
  Rossen: Okay, so ChrisL TabAtkins and shane as editors for masking
          spec?

  RESOLVED: ChrisL, TabAtkins, and shane as editors for masking spec.

  Rossen: That means you guys get to do all the actions and
          resolutions retroactively.

Deal with first vs last baseline
--------------------------------

  fantasai: I don't know if there's been progress.
  fantasai: We discussed a couple of months ago. There's no comments
            on github.
  fantasai: I have a slight preference for separate keywords but I
            haven't thought deeply.
  fantasai: Or if it should be incorporated into which baseline do
            we care about. That's the bigger issue. For inline we
            have several prop for controlling layout. Which baseline
            and how much do you shift. We can incorporate first/last
            into which baseline we use as a spec keyword or it's an
            independent control.
  fantasai: I haven't thought deeply. Another opinion would be
            useful.
  fremy: I like the idea of an independent property. I didn't think
         much further, but I like being able to say I care about the
         first or the last.

  Rossen: Did anyone else look or can add anything to the discussion?
  Rossen: The way I hear it is it's a call for attention and we want
          to make progress?
  fantasai: Given what I've heard I'd propose going forward for
            alignment property in box alignment to take away the
            hyphens so that first vs last baseline is distinguished
            with an keyword. In alignment add new property with
            first|last|auto.
  fantasai: Spec that and review and see if we want that since that
            part of align isn't as close to done.
  fantasai: Does that sound reasonable?

  dbaron: Why do you want to remove the hyphen?
  fantasai: Consistency with vertical align which doesn't have
            hyphens.
  TabAtkins: Note that means replacing with a space, not smuching
             together.
  dbaron: Which seems weird since it's a single value.
  fantasai: Kinda. In most cases you want baseline alignment but you
            can choose first or last. Current is baseline for first
            and last-baseline for last.
  <Rossen> baseline | last-baseline
  <TabAtkins> Current is "baseline | last-baseline". Proposed is
              "[ first | last ]? baseline"
  fantasai: Current baseline|last-baseline. Proposed is [ first |
            last ]? baseline
  fantasai: This is for consistency in terms of hyphenation. Even if
            we choose to incorporate into which baseline do I care
            about there's 5 options there so we wouldn't want a
            hyphen there. In either case in the inline module we
            want to not have a hyphen there.
  fantasai: So for consistency in the box alignment we'd drop the
            hyphen so authors don't have to remember. You can do
            first|last or leave it off which implies first.
  * bradk likes the proposed change
  dbaron: I'm okay if it's first followed by baseline and not
          anything in the middle.
  fantasai: Immediately adjacent would be the requirement.
  Rossen: I see some people like this. I don't hear push back. Do
          you want a resolution?
  fantasai: Let's record one and we can close off box alignment
            issues. We'll revisit is first and last should be
            independent or merge, but we're leaning independent.
  Rossen: Objections?

  RESOLVED: Change to [ first | last ]? baseline

  fantasai: TabAtkins can you make the edits?
  TabAtkins: Yes.

Hoisting things to table wrappers
---------------------------------

  <Rossen> https://github.com/w3c/csswg-drafts/issues/324#issuecomment-235652352
  Rossen: Who wants this?
  astearns: This was left over from TPAC.
  astearns: There were a list of properties Simon thought we should
            add to the list getting hoisted?
  fremy: Yes. I'm fine as the editor with changing this, but I'd
         prefer saying the caption is inside the table box.
  fantasai: It's not. We cannot do that.
  fremy: I can.
  fantasai: Width border and background apply to a box. Caption is
            not inside that.
  fremy: That's a discussion we should have apart.

  fremy: For me this issue doesn't make sense. I have no strong
         opinions. These properties should just work.
  Rossen: What do you mean by "this property"
  fremy: Opacity is resolved. They want to resolve on all the
         transforms properties.
  fremy: The list is overflow, opacity, filter, clip, mask, blend
         modes and transforms.
  fremy: So if you apply on table they effect the caption.
  Rossen: Okay. Is there a problem with that?
  fremy: No. It's just not how it works at this point.
  fantasai: I'm not sure about overflow but others make sense.
  Rossen: Overflow. So if you set overflow scroll on the table it
          should affect the caption?

  fremy: Proposal is to have the property apply on table wrapper
         box. I didn't think much about overflow. Let's say all but
         overflow.
  Rossen: Yes. Overflow on table is all over the place in terms of
          impl.
  fremy: Okay then we can say overflow should apply.
  fantasai: I think I would hesitate to put overflow on the list
  Rossen: Why?
  fantasai: You can't overflow the table wrapper box because it's
            defined to be as big as contents. I guess you could. It
            would be really weird if there were scrollbars not
            connected to an actual box.
  fantasai: It seems a weird case. I don't know if overflow applies
            to tables.
  Rossen: In some implementation it does. There's close to not
          interop.
  fantasai: I'd say no overflow on tables. I think it is currently
            defined as may be for table row groups.
  fantasai: In any case, I would hesitate to hoist the overflow
            property.
  fantasai: Have the scroller inside the table
  Rossen: I wouldn't mind leaving overflow out for now.
  fremy: Let's.
  <Bert> (http://www.w3.org/TR/CSS22/visufx.html#overflow says
         overflow applies to "boxes that establish a formatting
         context" and tables *do* establish a f. context.)

  Rossen: Proposed resolution is accept the list minus the overflow
          property.
  fantasai: The one down side to hoisting these is coordinate system
            is less predictable. Upside is most of the time you'd
            expect it to apply to caption.
  fantasai: I think that's the trade off.
  Rossen: Right.

  Rossen: Do we have any indication of what current impl do?
  fremy: It's not my issue. So unless there's something in the issue
         I don't know.
  dbaron: Gecko hoists transform but I don't think the others.
  dbaron: Rossen you read a list that I don't see
  <Rossen> https://drafts.csswg.org/css-transforms/#grouping-property-values
  [List is:
    overflow: any value other than visible.
    opacity: any value less than 1.
    filter: any value other than none.
    clip: any value other than auto.
    clip-path: any value other than none.
    isolation: used value of isolate.
    mask-image: any value other than none.
    mask-border-source: any value other than none.
    mix-blend-mode: any value other than normal.
  ]
  Rossen: They're out of the spec ^
  dbaron: Ah, okay.
  Rossen: We're out of time.

  Rossen: In terms of table I don't think any implementation is
          trying to change tables. We're looking for interop. We
          shouldn't define new behaviors for spec purity. Going
          back...are we ready to resolve or should we push it off?
  Rossen: Objections?
  Rossen: To adding hoisting of listed properties other than
          overflow?

  RESOLVED: Add hoisting of listed properties
            (https://drafts.csswg.org/css-transforms/#grouping-property-values)
            other than overflow.

  Rossen: hiroshi sent an e-mail about the April F2F dates
  fantasai: Should we buy tickets?
  Rossen: As soon as he says the space is reserved.
  fantasai: Thank you.
  Rossen: Thanks very much!
Received on Thursday, 27 October 2016 01:04:18 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 27 October 2016 01:04:18 UTC