[CSSWG] Minutes Telecon 2017-03-01 [css-flexbox] [css-display] [css-sizing] [css-paint]

=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Percentage [max-]width|height and intrinsic sizes
-------------------------------------------------

  - dbaron will review and comment on the issue.

What are "form controls"? / Define interaction of display:contents
    and replaced elements
------------------------------------------------------------------

  - The topic of "what are form controls?" was deemed too large and
      undefined to take up telecon time right now, but the smaller
      issue around display:contents could be addressed.
  - There were three proposed solutions:
      1) Treat all the types as stripping off the one box.
      2) Treat all of the types as doing display:none when you do
         display:contents.
      3) Do display:none on form elements and box stripping on
         others.
  - RESOLVED: Have display:contents treated as display:none for
              replaced elements and form controls.

Use flex-order first or document-order first item's baseline?
-------------------------------------------------------------

  - RESOLVED: Take the visually first line when considering baseline
              alignment in flexboxes.

Percentage [max-]width|height and intrinsic sizes
-------------------------------------------------

  - gregwhitworth was actioned to check web compat on fantasai's
      proposal (captured here: https://github.com/w3c/csswg-drafts/issues/765)

abspos flex/grid item "align-self: auto behaves as start" spec-text
    is too vague
-------------------------------------------------------------------

  - RESOLVED: align-self:auto and justify-self:auto still look at
              parent's align and justify items for abspos when
              calculating static position only.

Renaming stroke-* in paint
--------------------------

  - smfr indicated Apple's intent to implement fill and stroke, so
      TabAtkins and fantasai will put a high priority on making the
      Paint spec ready for a FPWD.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2017Mar/0000.html

Present:
  Rachel Andrew
  David Baron
  Bert Bos
  Bogdan Brinza
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Brad Kemper
  Ian Kilpatrick
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Michael Miller
  Anton Prowse
  Liam Quin
  Melanie Richards
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Lea Verou
  Greg Whitworth
  Steve Zilles

Regrets:
  Vladamir Levantovsky
  Simon Pieters

Scribe: dael

Use flex-order first or document-order first item's baseline?
-------------------------------------------------------------

  astearns: Tab you were looking for interop?
  TabAtkins: I didn't do that yet.
  astearns: Then let's table.
  <fantasai> I think more than interop, need to consider logic
  <fantasai> commented in bug
  <fantasai> Proposal is in the last comment
  <fantasai> need WG approval to try something that's not interop
             but more sane
  <fantasai> astearns, ask if there's any objection to last comment
             in first issue?
  <fantasai> astearns, in which case we can resolve it

Percentage [max-]width|height and intrinsic sizes
-------------------------------------------------

  <astearns> https://github.com/w3c/csswg-drafts/issues/765
  astearns: dbaron, you were volunteered to talk on this.
  dbaron: I'm not sure how ready this is for telecon. I missed the
          proposal on the issue.
  astearns: Can I action you?
  ACTION dbaron comment on the percentage [max-]width|height and
         intrinsic sizes thread
  <trackbot> Created ACTION-833

What are "form controls"? / Define interaction of display:contents
    and replaced elements
------------------------------------------------------------------

  <astearns> https://github.com/w3c/csswg-drafts/issues/1024
  TabAtkins: Still the question on if this is the definition or the
             max-width...which issue?
  dbaron: The display:contents bit I think was a different github
  TabAtkins: 540, yes (https://github.com/w3c/csswg-drafts/issues/540)
  dbaron: Right.

  dbaron: We have this historic problem that CSS meant to treat form
          controls as replaced elements but then we applied a bunch
          of css to form controls so we now have this world where
          each one is half way between replaced and controlled by
          css and each is different.
  * tantek agrees with dbaron's summary
  dbaron: We need to go through list of form controls and say which
          one counts as replaced and which doesn't. There might be a
          good general definition for 80% but I'm skeptical on 100%
          having a good general definition.
  TabAtkins: In general I agree with the outline of the problem.
             Which topic do we want to try and discuss. Sizing in
             certain circumstances? display:contents? other stuff?
  dbaron: I think this is complicated enough it should be offline
          for a bit.
  dbaron: Unless there's a particular topic.
  <fantasai> I don't think defining what a "form control" is is
             something we can resolve atm, but 'display: contents'
             issue is important
  <fantasai> max-width issue is the 2nd issue on the agenda, that
             astearns skipped over. I think it is prepared enough
             for wg discussion right now
  TabAtkins: Percentage max-height|width is more relevant. We should
             be consistent on display:contents soon as browsers are
             intending to ship.

  TabAtkins: display:contents might be easier since you posted a
             detailed comment. You had the 3rd option of run
             display:contents literally for form controls. Remove
             the box and treat children as normal boxes.
  * fantasai I think the 3rd option is totally sensible here
  dbaron: That avoids the problem and seems like a reasonable
          behavior.
  TabAtkins: I don't agree it will be useful as only some form
             controls have children. Having options as you strip
             away doesn't seem all that useful, but I guess it's
             fine. There's a lot of form control behavior that
             becomes unclear.
  astearns: Would you get different boxes for same form control in
            different browsers?
  TabAtkins: No. You would pretend the form control element wasn't
             there and it's children as just present.
  <gregwhitworth> that's not actually true - for example our input
                  will have a clear box - where as Chrome/FF/Safari
                  will not
  <gregwhitworth> select should be pretty uniform
  dbaron: Proposal was that display:contents on a form control is
          that the form control loses it's replaced magic and you
          display children on normal css rules.
  TabAtkins: So stripping a select would be a bunch of option inline
             children.
  <tantek> kind of like how alt text is displayed as normal inline
           when an img fails to load.

  dbaron: However options display not in a select. From CSS it's
          straight forward. It's not well spec what aspects of form
          controls are associated with DOM and which with box.
  <gregwhitworth> 100% what David said
  TabAtkins: Do the options in select...are they still selectable?
  TabAtkins: Is there a behavior distinction between select multiple
             and single? That's the hard part.
  tantek: As soon as it's replaced by plain text or content it loses
          it's special behavior. This happens with images when the
          alt text is rendered. You can't drag and drop, but you can
          select the alt text. It's a simple answer, if not ideal.
  TabAtkins: But then you can't walk the DOM and submit a form. You
             can't walk the DOM and find the select, you have to
             look at the presentation layer.
  <gregwhitworth> this sounds messy IMO
  tantek: Technically that's not the same. We could draw a
          distinction between user interaction behavior and submit
          behavior. It's not ideal.
  TabAtkins: If we strip the select you couldn't click on an option
             to change select index.
  tantek: Yeah. It loses it's UI behavior.
  TabAtkins: Seems not crazy.
  * fantasai just wants a spec that's 100% defined and not a
             side-effect of Gecko's nsCSSFrameConstructor
  tantek: For DOM and form submission it would behave as-is in the
          DOM.
  tantek: It's not ideal, but technically you can separate those two.
  TabAtkins: Okay. I like it better then what I thought you were
             saying. I think we can define that generically in a
             reasonable fashion.

  astearns: Does that mean we define as replaced elements when using
            display:contents lose their replaced behavior?
  <fantasai> "Replaced elements no longer replace their content, but
             instead that content is displayed according to the
             usual CSS rules"
  TabAtkins: If we wanted generic over all replaced we have to
             accept this has consequences with object. Or we can
             acknowledge that the children are css-y and that's why
             it works normally.
  astearns: We'd have to display what form elements are to have an
            order of this.
  TabAtkins: Sure, but CSS wouldn't care directly. It would have an
             extra category that the host link would define. When
             you display:contents if they have a special rendering
             normally their children become normal boxes.
  TabAtkins: We can define that category. THere's still more to
             answer like how they work in layout, but for this
             situation we can do it generically without a lot of
             effort

  <fantasai> Alternate proposal: replaced elements do what was just
             suggested, but form controls (defined as anything that
             could potentially submit in HTML), behave as display:
             none
  fantasai: I'm a little skeptical about how we'd define event
            handling and interaction for form controls. Possibly
            it's straight forward, but I'm not certain. And what
            aspects of styling and interaction are inherent to the
            form element.
  <gregwhitworth> I'm fine with them behaving as display none
  fantasai: I think this makes sense for actual replaced elements.
            Taking away the box and showing contents is fairly
            straight forward. But for form controls I think we can
            say they display as display:none. Saying they all
            disappear entirely is simpler to understand and define.
            And form control is anything capable of submitting html.
  TabAtkins: This seems backwards. The elements more similar should
             be treated odd, but the things further from normal
             would act normally.
  fantasai: I see replaced objects like videos as more normal than
            form controls since the idea was control would define
            how replaced elements work.
  fantasai: They don't have elements that are children that
            themselves have special behavior that only make sense as
            being part of the outer element.
  <rachelandrew> the solution fantasai is suggesting makes sense to
                  me, doesn't seem weird.

  <smfr> what about <input type=“text” style=“display:contents”><div>
         children</div></input>
  smfr: Do we expect orphans will want their own children in form
        controls? Or only content the UA creates will show up?
  TabAtkins: HTML parser doesn't let you put stuff in form controls,
             though DOM APIs do. It's not expected people put things
             there on purpose. It's defining how this error case
             occurs.
  dbaron: You're thinking people might use the dom to do things like
          that.
  dbaron: I think that might be okay too.
  * glazou notes editors like CodeMirror are based on that

  rachelandrew: What fantasai is saying makes sense to me. Authors
                see form controls as weird anyway so saying they
                have the display:none behavior makes sense.
  TabAtkins: They're weird, but they act like they have children.
             Replaced elements have 0 children and are a black box.
             That's why it's weird to me that this thing with no
             children can display children.
  <dbaron> there might be an advantage to making them less weird,
           though...
  fantasai: That's not true. When the image fails to load you
            display the contents of the container.
  rachelandrew: It maps to how authors using this stuff think about
                it.

  tantek: I disagree with fantasai generalization that replaced
          elements act in a consistent way. That's false. Image,
          object, and video behave completely differently in regards
          to their children.
  tantek: Trying to lump those together...they behave differently.
  TabAtkins: Her point is the video element where its children are
             just info sources vs a select where the options have a
             behavior. They interact with user interaction. Her
             point is there's more magic in that options are now
             normal vs tracks are normal.
  <fantasai> thanks, TabAtkins :) That was a clearer explanation
             than I would've managed
  tantek: Object is between those two. It does do special things
          based on if browser supports etc.
  TabAtkins: It does fallback. There's no interaction on the normal
             behavior. You treat it like it's doing fallback. I
             think we should be consistent with replaced where they
             all strip one box or all display:none.
  tantek: I'd like image and object to be treated the same and strip
          away one box.
  <gregwhitworth> And what happens when the children boxes vary
                  browser to browser? That sounds like a testing
                  nightmare.
  <gregwhitworth> should not be - doesn't mean they won't

  TabAtkins: I don't think there's use cases for any of these. We're
             defining least intrusive option. dbaron suggests doing
             it literally is the least intrusive.
  TabAtkins: I'm support it on that frame, not on terms of
             usefulness. People shouldn't display:contents these.
  tantek: For object the use case is to force the fallback to show.
  <fantasai> tantek, that is the effect, yes
  TabAtkins: There is no use case. We're defining based on it needs
             some behavior and we need the easiest. What sounds easy
             isn't easy architecturally. Stripping a level is a
             little easier.
  TabAtkins: If you bring up use case you're arguing wrong. It's a
             corner case.
  fantasai: It has the effect and if it's useful, do that. But we're
            not going from a use case here.
  <tantek> I'm ok with treating things simply (architecturally) as a
           first cut and see what unexpected things happen, and then
           address those as needed

  plinss: Every single time in the past where we define a corner
          case by whatever is easiest it's come back and bitten us
          years later.

  astearns: We have 2 proposals. 1 is treat all these as stripping
            out one box which will cause a bit more spec pain as
            we'll have to define what that means for all of these
            things. Other proposal is treat all of these as doing
            display:none when you do display:contents. It seems
            simpler to spec and communicate.
  <gregwhitworth> It also makes it much more obvious to the author
                  that there's a problem
  astearns: Because it's a corner case we're not looking for utility
            so the display:none might be easier because we don't
            know side effects.
  <dbaron> I think I'm OK with the display:none thing; at the very
           least it (so far) has a lot fewer problems than the
           original display:inline solution.
  fantasai: 3rd was display:none on form and box stripping on others
  TabAtkins: I believe that's the worse
  astearns: I'd rather a consistent story on the edge cases of
            display:contents

  <tantek> I thought I heard that "stripping off the one box" was
           the simpler architectural option?
  <fantasai> tantek, it's tricky to define for form controls I think
  astearns: And tantek mentions that stripping one box was simpler
            architecturally.
  dbaron: It's much simpler then display:inline thing. This started
          as we wanted to make it display like and then compute to
          display:inline
  astearns: And that's off the table.
  <tantek> ok it sounds like convergence is happening, will wait it
           out and see what people say

  <gregwhitworth> We can reference HTML5 for "form controls" right?
                  If you have a new one that is proprietary we don't
                  need to spec that.
  <fantasai> gregwhitworth, technically "form control" isn't dfn'd
             but I think we can define it relatively simply or ask
             HTML to do so
  <gregwhitworth> fantasai: 👍

  astearns: Does anyone disagree we're down to display:none or strip
            one box?
  [silence]
  astearns: Does anyone have a marked preference between them?
  <tantek> I know we're not arguing usefulness/use-cases, BUT I have
           a slight preference for strip one box for that reason
           (e.g. object)
  TabAtkins: I believe FF dev expressed a preference for stripping a
             box because display:none is still not trivial.
  dbaron: Emilio's second comment?
  TabAtkins: Yeah.
  dbaron: I'm not entirely sure what he was thinking about but I'm
          not sure it implies it's easier.
  TabAtkins: Okay.
  <dbaron> (emilio's comment being
https://github.com/w3c/csswg-drafts/issues/540#issuecomment-281875695
)

  astearns: So there's slight preference for strip one box. We could
            try spec this and go through repercussions of that.
  astearns: I have a feeling we will run into similar problems as we
            did for inline.
  dbaron: I'm fine with going with none. I should ping Emilio.
  <tantek> I think fantasai provided the two key examples that help
           make strip one box doable. e.g. img does not display alt,
           but object does display its contents
  <tantek> seems like all form controls fall into one of those two
           categories
  <tantek> empty or not?
  <gregwhitworth> I would prefer none - stated it before but I'll
                  say it again :)
  TabAtkins: Do we tentatively resolve and if there's evidence to
             the contrary we can re-open?

  astearns: Objections to display:none for items with
            display:contents?
  <dbaron> And I'm fine with "treated as display:none" -- "computes
           to display:none" would be problematic.
  fantasai: I'd like to gear from rachelandrew
  <tantek> do we have objections to strip one box?
  rachelandrew: It seems okay. It's a corner case and we need
                something to explain.
  astearns: Proposal: have display:contents treated as display:none
            for replaced elements and form controls.
  astearns: Objections?
  <tantek> no objection, but seems like we're throwing away an
           opportunity oh well

  RESOLVED: Have display:contents treated as display:none for
            replaced elements and form controls.

  ACTION dbaron to ping Emilio about the have display:contents
         treated as display:none for replaced elements and form
         controls resolution
  <trackbot> Created ACTION-834

Use flex-order first or document-order first item's baseline?
-------------------------------------------------------------

  fantasai: I have data that's not compat data, which is about what
            is the point of the feature. I think we need to choose
            visually first.
  fantasai: If you're reverse ordering a column flexbox then you're
            choosing first baseline on an element that's potentially
            in the middle. If the goal is visual alignment of text
            then you need visually first baseline. Regardless of the
            interop I think we need to go with first visual box for
            first-baseline and last for last-baseline.
  astearns: I'm confused about the element in the middle.
  <gregwhitworth> an int is used on ~1.3% of sites crawled:

https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/order/
  <gregwhitworth> granted this doesn't determine if they care about
                  baseline alignment in these cases
  fantasai: Suppose each box has 10 lines of text. We'd be taking
            the 21st line of text as the "first line" to align to.
            This makes no sense.
  TabAtkins: If you do it with order and move things you'd take
             visually the first line. It's taking flex direction
             into account as well.
  astearns: I'm happy going with visually first line.
  astearns: Proposal: take the visually first line when considering
            baseline alignment in flexboxes
  astearns: Objections?

  RESOLVED: Take the visually first line when considering baseline
            alignment in flexboxes

Percentage [max-]width|height and intrinsic sizes
-------------------------------------------------

  <astearns> https://github.com/w3c/csswg-drafts/issues/765
  fantasai: There's an interop case where if you have a replaced
            element with a width or max width in percentage we take
            the intrinsic size contribution to be 0 or as close to 0
            as you can get on form controls.
  dbaron: Not all form controls, just text area and input-type is
          text and only the width thing, not max-width.
  fantasai: To get interop into spec we'd have to say all replaced
            elements get max-squished if the width is % unless it's
            a form control where we only look at width. Max-squashed
            you take whatever the percentage resolves to.
  fantasai: Issue I find is doing this special case for width, but
            not max-width for input when doing both for images seems
            inconsistent.
  dbaron: This is a thing where we imitated this quirk for web
          compat.
  fantasai: I understand we want to be close to what's there, but do
            we have to not do this for max-width on input and
            text-area? If that's not a web compat requirement we can
            do these things but have rules for images and inputs the
            same. I want to put it to the WG, but I don't expect
            answers right now.
  fantasai: Was that clear?
  astearns: I'm not following, but I wouldn't have the data you're
            looking for.
  fantasai: It's summarized with a test case in the last comment.

  astearns: What do we do next?
  fantasai: Impl need to review and see if they find it acceptable
            or if it will result in web compat.
  astearns: Can I get impl besides dbaron to volunteer?
  astearns: gregwhitworth? I'd like you to look from Edge.
  ACTION gregwhitworth to review #765 in github
  <trackbot> Created ACTION-835

abspos flex/grid item "align-self: auto behaves as start" spec-text
    is too vague
-------------------------------------------------------------------

  <astearns> https://github.com/w3c/csswg-drafts/issues/440
  <astearns> https://github.com/w3c/csswg-drafts/issues/440#issuecomment-280459999
  fantasai: There was a comment here.
  fantasai: from TabAtkins.
  fantasai: Issue was Christian raised a concern about the change in
            behavior from when we worked on align. We realized we
            don't have align self to take the align item value of
            the parent because it may have nothing to do with layout.
  TabAtkins: One step back: the behavior before alignment spec when
             you have abspos when you set top right bottom left it
             fills the box. We've now tied that to the stretch
             behavior of align & justify self. If you don't want
             that and want to center the abspos you can set top
             right bottom left to 0. So auto looks at the parent for
             align or justify items.
  TabAtkins: If parent is a flexbox, but the abspos containing block
             is further up the tree and is entirely manually
             positioned you'll get a weird effect where flexbox's
             align items changes how the abspos is rendered. It's
             mysterious and shouldn't have this effect.
  TabAtkins: We tried to break that but we probably go too
             aggressive and made it no longer look at parent for
             static pos.
  TabAtkins: We can probably make this more subtle so abspos with
             align-self:auto doesn't pay attention to parent for
             normal alignment, but will for static pos.
  fantasai: Did anyone follow?

  gregwhitworth: You wont be changing static position again?
  TabAtkins: It wasn't intended to change static position.
  TabAtkins: Goal of the edit was to remove the weird parent. The
             change was more aggressive then intended. I can do a
             carve out that does this properly.
  gregwhitworth: Sounds good.
  fantasai: 3 behaviors: align-self had no effect on abspos unless
            effects static position of an abspos that happened to be
            a child. So it would have a side effect of setting the
            static position of the abspos if it happened to be a
            child. Then we had this super weird thing where it ended
            up doing unexpected alignment. So then we said abspos
            don't look at parents, they're always normal. Then
            Christian said it changes the behavior of the static pos.
  fantasai: So we can say when it's abspos it's just normal, but we
            can fix it so that static isn't changed.
  fantasai: Proposal: Static position of a child abspos of a flex
            container is calculated with align-self looking at align
            items even though the abspos normal alignment
            calculations don't do that.
  TabAtkins: Align-self:auto & justify-self:auto still look at
             parent's align and justify items for abspos when
             calculating static position only.
  astearns: Objections?

  RESOLVED: align-self:auto & justify-self:auto still look at
            parent's align and justify items for abspos when
            calculating static position only.

Renaming stroke-* in paint
--------------------------

  <smfr> https://drafts.fxtf.org/paint/
  <smfr> https://drafts.fxtf.org/paint/#perfect-world
  smfr: I want to note apple has interest in fill and stroke.
  smfr: We need Japanese captions which use stroke on a text and
        we'd like to use these standard properties. We'd like this
        draft to move forward. We want to talk about if we should
        accept the rename in 3.7 which is perfect world syntax. We
        don't want to lock into old names and we want to impl soon.
  TabAtkins: fantasai and I plan to spend our work week in March
             finishing this and making it publication ready, now
             that you have interest
  smfr: We have implemented paint-order so we need to put it here.
        There's a stroke-align property where the request is it goes
        on the outside of the glyph. It's hard in the graphics
        engine. Easier to pop the fill on top of the stroke. So
        we've impl paint order.
  TabAtkins: Only works for opaque text, but that's the common case
  smfr: Absolutely.

  smfr: One other things, I'm not sure it specified if you have
        fill-color and color.
  TabAtkins: Color becomes like svg where it just sends the current
             color. It becomes an information channel.
  smfr: So color: red fill-color: blue
  TabAtkins: You get blue text.
  smfr: So fill-color is more specific and wins?
  TabAtkins: Color...we're filling in a previously unspecified
             property. It was previous un-specifiable so it was
             currentColor. Now we can spec.
  astearns: We're at the hour. Great that we'll get more work on the
            draft. Let's continue these discussion as topics come
            up. Thanks all.
  <fantasai> yeah, finish off this FPWD has been on our to-do list
             for awhile, just finally getting around to it now that
             Grid is mostly stabilized :)<div
id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
 <tr>
        <td style="width: 55px; padding-top: 13px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon"
target="_blank"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
  <td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link"
target="_blank" style="color: #4453ea;">www.avast.com</a>
  </td>
 </tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
height="1"></a></div>

Received on Thursday, 2 March 2017 02:38:42 UTC