W3C home > Mailing lists > Public > www-style@w3.org > February 2017

[CSSWG] Minutes Telecon 2017-02-08 [css-align] [css-2017]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 8 Feb 2017 20:28:48 -0500
Message-ID: <CADhPm3tAraRSfq+aH+m0x3no+KSk-ALPyxZWnersGi8x6BztWQ@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.
=========================================


Expanding our help for SVG
--------------------------

  - Rossen informed the group of the proposal for the CSSWG to take
      over the parts of the SVG2.0 spec that are felt to be stable.
  - ChrisL had edited the proposed scope of work into a draft update
      to the charter for review: https://www.w3.org/Style/2016/css-2016+svg.html
  - The arguments in favor of this approach centered on this group
      having the expertise to do the specification and having a need
      to see interdependencies resolved.
  - Concerns raised include a concern that without a test suite it's
      very hard to know what's stable and that the group won't be
      able to deliver on the spec if those planning to work on it
      are no longer available to work on it.
  - Conversation will continue to answer more questions and come to
      a conclusion as to if the group will take on this work.

CSS Alignment
-------------

  - RESOLVED: Restore the accidentally removed text from css-flexbox
              specifying how flex applies to table wrapper boxes
              (https://drafts.csswg.org/css-flexbox/#change-2015-anonymous-fixup)
  - There were three options to address the disparity between how
      CSS Align and CSS2.1 deal with last baseline alignment of
      scrollable boxes:
      A) if 'overflow' is not visible, use the bottom margin edge,
         ignoring the contents
      B) use the last baseline, but if overflow is not visible, then
         clamp that to bottom margin edge
      C) if overflow is not visible, scroll to the bottom then use
         the actual baseline
      - Conversation will continue on the github issue.
  - RESOLVED: Republish CSS Align CR.

CSS profiles in future snapshots
--------------------------------

  - RESOLVED: Add a warning note to all profile notes (mobile,
              print, tv) saying they are obsolete and if people want
              to see what the WG is doing they can go to the
              snapshot.
  - RESOLVED: Stop linking to obsolete profile notes from the CSS
              snapshot.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2017Feb/0043.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Bert Bos
  Bogdan Brinza
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Dael Jackson
  Brad Kemper
  Chris Lilley
  Myles Maxfield
  Michael Miller
  Anton Prowse
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Greg Whitworth
  Steve Zilles

Regrets:
  Tab Atkins
  David Baron
  Brian Birtles
  Tony Graham
  Vladimir Levantovsky
  Alan Stearns

Expanding our help for SVG
==========================

  Rossen: Hello everyone!
  Rossen: Are there any additional agenda items?

  <ChrisL> https://www.w3.org/Style/2016/css-2016+svg.html
  <ChrisL> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FStyle%2F2016%2Fcss-2016.html&doc2=https%3A%2F%2Fwww.w3.org%2FStyle%2F2016%2Fcss-2016%2Bsvg.html
  Rossen: This was the result of conversations starting in TPAC
          where it became clear the SVGWG was slowing down. Since
          then there have been efforts to keep the WG going, but
          it's pretty much disseminated itself.
  Rossen: There's only a few implementation members and invited
          experts left. The implementation experts are also part of
          CSS.
  Rossen: After discussion with w3c management, plh, and contacts
          -astearns and I were in those discussions- the most
          favored path from w3m and plh is to capture the SVG 2.0
          work under the CSSWG and drive that to completion.
  Rossen: That proposal entitles us to do this. The SVG2.0 was
          declared final.

  Rossen: The parts that are unstable were moved to different
          modules.
  Rossen: Those modules will move to incubation.
  Rossen: The work that happens to fall under our charter will be
          the SVG2.0 core spec, the SVG a11y module (which is
          stable) as well as SVG integration spec which was
          something we agreed to take over in Seattle F2F.
  Rossen: Procedurally the way we will drive this so we're not
          taking time away from WG as much as possible we will have
          BogdanBrinza from Microsoft join the CSS WG and help us
          facilitate a track of parallel work on SVG. Similar how we
          handled graphics and text separation in Seattle.
  Rossen: During the graphics discussion discussing transforms we
          had issues we could have resolved if we could have said
          that it would work for SVG.
  <tantek> I'd like "parts that are unstable" to be clarified
           further, or rather, if it's not prototyped (as of today)
           or at least partially already implemented in a browser (
           i.e. at least shipped behind a flag), it is considered
           "unstable"

  Rossen: I am looking forward to this. I know there's a number of
          you on the queue. I'd be happy to take questions, but I
          want to time box this for 5 minutes because we have a
          large agenda.
  Rossen: I also want to point you to the links from ChrisL above.
          He also agreed to change the charter text. Look at the div
          that captures the deliverable expansion.

  Florian: You said the unstable parts are split off. When was that?
           A few days or longer ago?
  Rossen: This was part of what BogdanBrinza and I did with SVG for
          18 months. TPAC 2014 is when we rejoined and started to
          separate unstable pieces into own modules. That was done.
          I can point you back to our tracking system for that and
          the decision matrix.
  Florian: Based on that, for what's left, is that only what was in
           SVG1.1 with refined wording, or new features?
  ChrisL: New features, yes. Primarily html client integration
          clarity. It has aria but we think that can be tested.
  Florian: Unless there was a recent change, I'm suspicious it's
           stable given it doesn't have a test suite. This is a
           massive spec. From a distance I feel taking this to rec
           would be as much work as 2.1 to rec. This isn't a small
           piece of work.
  <gsnedders> Florian: +1
  <glazou> Florian: +1
  <tantek> I am also suspicious of the claim it's stable
  Florian: Even if the crazy parts are removed what's left is
           enormous. I'm worried.

  Florian: Second point is this discussion of merging SVG hasn't
           happened in the AC forum.
  ChrisL: This is normal. A draft goes to WG first, then we send
          notice to AC, then when charter is ready we send it to
          them for review. This is the normal process.
  <glazou> +1 on what Chris said
  <tantek> Chris +1 makes sense for the WG to review / consider an
           additional draft first, then go to AC to ask permission
           to expand charter if we choose to pursue that path
  Florian: We were ongoing review of SVG charter that didn't say it
           was dead. That charter wasn't accepted or rejected. We
           were in the middle of discussion.
  ChrisL: I think plh sent something out saying charter review has
          failed. Did that not happen?
  ??: It did.
  Florian: Okay. Maybe it did.

  glazou: One comment. ChrisL called me a few days ago to discuss
          this. I think having SVG inside the WG will rely on few
          people for lots of work. I think if we don't have these
          important people we can't do SVG and we should say that.
  glazou: Otherwise some ACs will require deliverables to be
          delivered. If we don't have the right people, the WG will
          fail.
  BogdanBrinza: SVG being too big concern- we're fully committed to
                it.
  BogdanBrinza: glazou's point, we do have the right expertise and
                motivation.
  glazou: You have a full commitment on 8 Feb 2017. We know things
          and companies change strategy. It is good now. I'm not
          sure it's good a year from now.
  glazou: That's why I wanted to say without the right people we
          can't commit.
  <glazou> Rossen corporate strategies can change, besides
           individual commitment
  Rossen: Every time we've made progress on SVG it's when a core set
          of us who sat around a table. That was shans, TabAtkins -
          both CSS. dino was involved. Most things changed and moved
          was those overlap meetings.
  Rossen: In terms of making process I believe we have the core
          expertise and right set of people in the WG.
  Rossen: With the commitment of BogdanBrinza and whoever else
          commits I'm hopeful it will happen quickly.
  <SteveZ> The W3C Process does not say that you MUST deliver, only
           that you SHOULD deliver or declare that no further
           progress is possible and publish a Note to that effect.

  Florian: If we have the motivated set of people, why is that not
           it's own WG? Why is the merge needed? The same people can
           be in multi WG.
  <fantasai> thinks what's needed is someone who is willing to take
             ownership of the issues list and agenda
  <fantasai> we needed that for 2.1
  <fantasai> including testing issues
  Rossen: I'm not sure if plh is on the phone. If this is supposed
          to be its own group isn't something we can decide. We were
          asked to help and I'm relaying it.

  BogdanBrinza: I think the proposal of the plan and timelines are
                something we want to have. I want to approach this
                the way we do software development.

  ChrisL: I had two things to say. We have the a11y TF which I think
          has Rick on it who was part of SVG. During the previous
          review of SVG WG charter which failed there was a comment
          from Mozilla that maybe this should be in the CSSWG.
  <tantek> Thanks ChrisL for passing along the Mozilla comment

  fantasai: Why did charter fail?
  ChrisL: No implementors stepped up to join. I don't have it in
          front of me. It was below critical mass. There needs to be
          at least 24 responses.
  Florian: The other aspect is the proposed charter was a death
           march to ship REC within a year, which killed enthusiasm
           for Invited Experts.
  ChrisL: Yes.
  Rossen: This is one way to put it. The other way to put it is it
          wasn't a march to death. It was to scope down and ship a
          spec that was worked on for 13 years and had no progress
          until a year or two ago.
  Rossen: Proposal was centered on keeping that focus and shipping
          the spec and chipping things away to other groups.

  Rossen: This was just an introduction. I'm sure more discussions
          will happen. THis was a conversation starter.

  <tantek> When no browser implementers support a WG producing
           browser technology, the WG must not be created/renewed to
           avoid the XHTML2 failure mode
  <Florian> The spec is longer that css2.1, does not have a test
            suite, and was chartered to reach REC in Q3 2017. This
            was a death march, I stand by my words.

  <Florian> For the record, in relation to the earlier SVG
            discussion, I've checked my ac-forum mails, and I cannot
            find any announcement of the charter review failing,
            from plh or anyone.

CSS Alignment
=============

  <fantasai> https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-align-3
  fantasai: We can go either way on the open issues. The last
            baseline alignment with scroll boxes need more thinking.

Should `align-self` and `flex` (& its subproperties) be honored on
    table wrapper box?
------------------------------------------------------------------

  <fantasai> https://github.com/w3c/csswg-drafts/issues/547
  fantasai: We had text in the past and lost it during an edit that
            said if you apply flex and align-self property does it
            apply to table wrapper box.
  fantasai: If people are happy we can make changes.

  fremy: I'd prefer this in table spec, not align. I'm fine with the
         idea, but I don't think it goes in here.
  fantasai: This would go into align in terms of what the property
            applies to and also the flex box spec.
  fantasai: It's a bigger topic, but the distinction between if
            things apply to table wrapper box applies across all of
            CSS and we should be careful to note it.
  fantasai: There should be a systematic way to track that and it
            should be noted in that property or else we'll forget
            stuff.
  fremy: My opinion is different that we should have a clear rule in
         the table spec and not decide on each property.
  fremy: I think nearly every property in CSS instead of making a
         list of them, instead create a rule in the table spec.
  fantasai: In terms of flex specifically it requires explaining how
            it applies. Flex applies in that the table wrapper box
            needs to be flexed to match the calc in flex. It's
            complicated in this case.
  fantasai: Since flex is further along and tables is in 2.1 I don't
            think we should leave it out of flexbox until tables is
            in CR.
  fremy: I'm fine. If we want to resolve and no one objects let's do
         it.

  Rossen: Going back. My first question is does anyone do anything
          with tables when they are flex items currently?
  fremy: Nope
  Rossen: We don't. Playing with flexbox I don't believe other
          implementations do. Everyone who has worked on table
          layout knows how "fun" it is to make changes there.
  Rossen: If this is an incubation question would anyone have
          interest in implementing flex on tables? If yes we can
          corner the spec somewhere.
  Rossen: Mostly that's to other implementors of flexbox.
  Rossen: I don't hear any.

  fantasai: You don't have the flex impl on the call. This text was
            in CR. It was lost during a change for anonymous boxes.
  fantasai: It probably shouldn't have been.
  <fantasai> https://drafts.csswg.org/css-flexbox/#change-2015-anonymous-fixup
             lost text during a related change, in CR
  fantasai: If we decide down the line we don't want to impl, but it
            should be in the spec. It's reasonable to want a flex
            item that happens to be a table to flex to take up the
            space and not act fixed.
  Rossen: You want to keep this in flex spec?
  fantasai: I want to restore the text.
  Rossen: I think it's fine. We can discuss actual merit later.
  Rossen: Request is restoring the text in flexbox that spec that
          tables as flex items respect flex.
  Rossen: I encourage those not in favor of the behavior to open an
          issue.

  RESOLVED: Restore the accidentally removed text from css-flexbox
            specifying how flex applies to table wrapper boxes

Last Baseline Alignment of Scrollable Boxes
-------------------------------------------

  Rossen: Next issue is scrollable boxes and last baseline alignment?
  <fantasai> https://github.com/w3c/csswg-drafts/issues/766
  fantasai: CSS align had a sentence that [reads]
  fantasai: CSS2.1 had a different sentence [reads]
  fantasai: There was an issue raised on 2.1 to make overflow have a
            less dramatic effect by honoring baseline of actual text
            unless the actual text overflows.
  fantasai: I looked at the 3 versions and I wasn't sure if the one
            we resolved on was right. The text in CSS Align seemed
            the most useful. I want to hear other thoughts.
  fantasai: We need to move 2.1 into align or vice versa.

  myles: As far as I know there aren't any impl that follow this
         feature of CSS align so I'd be worried about changing
         behavior for every impl.
  myles: Seems that one of the existing behaviors should be
         reflected rather than making every impl change.
  fantasai: Seems reasonable.
  Rossen: I'd be in favor of myles' approach as an impl.

  Rossen: Anyone else? If not we can resolve.
  myles: One other piece. What is the reason that CSS align says
         this?
  fantasai: We had to define differently between how you find the
            baseline of the box...when you take the baseline from
            the text you need a scroll position. The scroll position
            for using first baseline is straight forward. Last
            baseline problem is that you are trying to align to
            something that is overflowing and that's not useful.
  fantasai: For scrollable boxes we defined last baseline you scroll
            to the final position and take that. When you've
            scrolled to the bottom you're in alignment. In 2.1
            there's no way to align to that. That makes a difference
            when trying to align to something scrolled all the way
            to the bottom. There's no way to get that to baseline
            align outside that box.
  fantasai: If we take CSS Align that you scroll to the final
            position and then it'll be in view you can use that
            bottom edge and align that to content. Like if you're
            making a chat app you would care about that as they
            scroll upwards and you tend to hang out at the bottom.
  fantasai: I don't think we thought about that when creating 2.1 I
            think this behavior gives a useful result instead of
            semi-random result.
  myles: Yeah. I'm just worried about every browser breaking web
         pages.
  <tantek> wonders if there is a test we can check for that
  <fantasai> tantek, what do you mean?
  <tantek> for breaking every browser - is there a test?
  <tantek> just wondering if there is an evidence based way to
           resolve this issue, instead of "what should happen" vs
           "worried about every browser breaking web pages"
  <tantek> myles, if you can produce a test that demonstrates the
           "every browser breaking web pages" for this change, then
           I think you'll get more support :)

  Rossen: Anyone else?
  Rossen: Let's try to resolve. Would that mean we remove this from
          CSS align?
  fantasai: It means it changes its text to match 2.1
  fantasai: There's 3 behaviors.
  <fantasai> A) (original) if 'overflow' is not visible, use the
             bottom margin edge, ignoring the contents
  <fantasai> B) use the last baseline, but if overflow is not
             visible, then clamp that to bottom margin edge
  <fantasai> C) if overflow is not visible, scroll to the bottom
             then use the actual baseline
  <fantasai> Note: this is for aligning to the *last* baseline

  Rossen: I would caution here that this may or may not have side
          effects to intrinsic controls. So an input type text in
          our implementation is a div with an overflow: hidden and
          we do align baselines of controls with rest of the lines
          given they're positioned in an inline context.
  Rossen: That definition of being an overflow or not seems a bit
          too restrictive from that POV.
  myles: So form controls are inline blocks?
  Rossen: Yes. They can get any type of display.
  myles: Which of these are you commenting about?
  Rossen: B
  Rossen: [reads]
  Rossen: Again, if I re-iterate the input-type:text is
          overflow:hidden and we can perfectly well align with the
          baseline inside. Some thing goes with text area. We can
          align on the line inside a text area. When people create
          components I would expect the normal pattern to be try and
          encapsulate them as much as possible. If we lose the
          ability to align with the baseline it would be unfortunate.
  fantasai: I think what we're ending up on is that A or B would not
            allow you to create a component that allowed you to
            align with the last line. Here's a test case with a
            select box.
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%3E.A%20%3Cselect%20size%3D2%3E%3Coption%3EA%3Coption%3EB%3Coption%3EC%3C%2Fselect%3E
  <fantasai> with margin:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%3E.A%20%3Cselect%20size%3D2%20style%3D%22margin%3A%201em%22%3E%3Coption%3EA%3Coption%3EB%3Coption%3EC%3C%2Fselect%3E

  fantasai: CSS 2.1 with or w/o myles proposal says if that's a div
            you would align to the bottom margin edge, not the text
            inside. To align to the text inside you have to account
            for it. And the text in the align spec will do that.
  myles: In your form controls if they do overflow do you do the
         scrolling behavior?
  Rossen: None do.
  Rossen: I was just using the example of intrinsic controls because
          it's simple. When we generalize to components I would
          expect them to be more encapsulated then not.
  Rossen: Even though we have full control behind the scenes for
          intrinsic, I don't believe we'll have that for components.
          I want to make sure we're not cornering ourselves for web
          components.
  myles: It sounds like if we're going for most encapsulation it
         should always be the border box and no one wants that.
  Rossen: I agree we don't want that.
  myles: Aiming for more encapsulation is not sufficient to guide
         this decision.
  Rossen: It's sufficient to exemplify why A and B are less then
          ideal.

  fantasai: I'm going to say this needs more discussion and we
            should think on use cases and comment on the thread.
  Rossen: I'm fine with going back to github.

Publication
-----------

  Rossen: Publication. I don't know if this includes that.
  <fantasai> sorry, fell off
  <fantasai> No, just want to update.
  <fantasai> Can update more after we resolve this :)
  <Rossen> so you're OK if we don't pub now?
  [wait for fantasai to type or rejoin]
  fantasai: We want to update the spec. WE can update more after
            issues are resolved. It'll be the first echidna update.
  <tantek> ship it!
  Rossen: Objections to republishing?

  RESOLVED: Republish CSS Align CR.

  Rossen: fantasai please work with the contacts to publish.

CSS profiles in future snapshots
================================

  Florian: There have been a couple of snapshot issues. One I want
           to mention is it refers to CSS profiles even though the
           docs are abandoned. WHat should we do about the profiles
           and about the snapshot?
  Florian: fantasai pointed out others refer to them
  <tantek> We can OBSOLETE them as of March 1 per the new process!
  <fantasai> tantek, they're not obsolete. They're just inert.
  <tantek> uh, inert sounds like obsolete :P
  <fantasai> obsolete is "we don't use this spec anymore, we have a
             better spec here"
  <tantek> fantasai - no, obsolete is - do not implement. nothing
           about "better spec here"

  fantasai: Other standards organizations point at these profiles.
            We froze them as notes and said no further work. They
            have not been rescinded. There's no reason to. So I do
            think they are part of the snapshot because they're work
            we did here. Unlike other work where we've said we won't
            continue.
  Florian: Not taking down the profiles, fair enough.
  Florian: They are wrong, though. The one about TV says you may
           support all media types, but you must support all and TV.
           TV has been deprecated so if you support it you'll do
           something incorrect. We shouldn't point to them because
           they're wrong.
  fantasai: They're still...though TV is deprecated anyone following
            the standard is going to follow it. There's deprecated
            technology, but anyone working with those old tech need
            this. We're not recommending to use them, but we're
            saying if you need them they're here.
  Florian: For example, when we deprecated we didn't say don't use
           it, we changed it to does not work. The spec says it must
           never match anything. The profile says if you're a TV use
           that. Pointing to them ourselves seems like it would lead
           to confusion. From the snapshot it seems odd.

  tantek: These aren't TR?
  Florian: They're notes.
  fantasai: That is TR.
  Florian: TR notes.
  tantek: Notes makes it less of a big deal.
  tantek: If we think they're broken we should mark obsolete.
  Florian: I haven't read them all, but I read the beginning of one
           and found something wrong. It made me concerned.
  tantek: If they're out of date we should mark as do not implement.
  Rossen: We can add the red banner. Are all the profiles wrong?
          Just TV? If we don't know we can go through and decide.
          Not on a call.
  Florian: No one wants to go through. That's why they're out of
           date.
  Rossen: One was published on Oct 2014...mobile.
  Florian: By that measure they're all fairly recent.

  Rossen: We can take the opposite. Let's add the note and if
          someone who does care they can go and read them and
          propose changes.
  Florian: Yeah. I think we need to phrase carefully, but a warning
           is appropriate.
  Rossen: Can't we use the regular warning?
  Florian: How does it read?
  Rossen: [reads]
  fantasai: That's not appropriate,
  fantasai: If you want to mark obsolete you can.
  Rossen: ChrisL? Can notes be obsolete?
  ChrisL: Obsolete is about recs.
  SteveZ: The obsolete thing is for things the AC has approved.
          Notes don't require approval.
  tantek: He's got a good point. We don't need to follow the full
          procedure, we can just do a warning.
  fantasai: "this spec is obsolete and not maintained"
  Florian: And having in that note a link to the snapshot saying
           this is a good place to look makes sense to me. Having
           the snapshot point to them makes little sense.
  tantek: I'm fine with that proposed note.
  Rossen: Let's try and capture this. Objections to adding a warning
          note to all profile notes (mobile print tv) saying they
          are obsolete and if people want to see what the WG is
          doing they can go to the snapshot

  RESOLVED: Add a warning note to all profile notes (mobile, print,
            tv) saying they are obsolete and if people want to see
            what the WG is doing they can go to the snapshot.

  ChrisL: Should we point to snapshot or /TR?
  fantasai: That is the snapshot
  ChrisL: I mean to /TR/CSS/ which points to snapshots
  <tantek> fine
  Rossen: Sure.

  Rossen: Do we need to contract anyone else that has a dependency
          on those notes?
  ChrisL: It was external organizations I think. I don't think
          anyone in AGB did TV. It would surprise me if anyone in TV
          was paying attention to it.
  <tantek> ChrisL it wouldn't surprise me because Mark of Netflix
           was complaining about out of date specs on TR just last
           May
  <tantek> and Netflix does have something to do with TV ;)

  Florian: The resolution I wanted was to stop linking to them from
           the snapshot
  Rossen: objections?
  <ChrisL> +1
  <tantek> no objection

  RESOLVED: Stop linking to obsolete profile notes from the CSS
            snapshot

  Rossen: Thanks everyone.
Received on Thursday, 9 February 2017 01:30:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:06 UTC