W3C home > Mailing lists > Public > www-style@w3.org > November 2015

[CSSWG] Minutes Sapporo F2F 2015-10-27 Part III: All Spec Review

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 23 Nov 2015 20:15:57 -0500
Message-ID: <CADhPm3szi2g4V+9aJnNtB6uAozD3gLyB50iwT_xt4aSQuYvcjw@mail.gmail.com>
To: www-style@w3.org
All Spec Review
---------------

  - RESOLVED: Redirect color-correction to css-color-4, remove draft
  - RESOLVED: Republish speech with updated status
  - RESOLVED: Matt Rakow added as co-editor on device adaptation
  - RESOLVED: WD of GCPM
  - The group went through the specs that haven't been published in
      a while:
      - fantasai will look though Text Decoration to see if there
          are any substantial changes.
      - Masking needs more tests.
      - Exclusions needs working group consensus on the model.
      - Motion Path has 5 issues and will be republished once those
          are handled.
      - Bert will work on gutting Basic Box Model down to the
          description of properties and maybe lots of issues. He'll
          publish in a month.
      - Box Alignment has a few issues, but should be ready for
          publication in November.
      - Mobile Text Size Adjustment may be abandoned, but for now
          needs a note added.
      - CSSOM Values will now redirect to Houdini's Typed OM.
      - The group will review Koji's proposal for simplification
          before a publication.
      - Animations and Scoping are up for discussion during TPAC, so
          publication will wait until those conversations.
      - fantasai will finish her edits for Text Level 3 so it can be
          republished.
      - Fragmentation needs an updated DoC before going to CR.
      - Transitions is close to CR.
      - Transforms has one outstanding issue and some edits in the
          ED that need working group approval.
      - Variables and Will Change have outstanding
          resolutions for CR publication.
      - Florian will review the status of Device Adaptation.
      - The editor for Filter Effects wasn't at the meeting, so the
          status is still unknown.
      - Lists needs dramatic cuts before publication.
      - Regions has a lot of open issues that need review before
          publication.
      - Overflow 3 has a lot of experimental items, but could likely
          be published again.
      - Font Loading 3 only has minor issues before CR.
      - No one knows the status of Non-Element Selectors 1, so
          astearns will investigate.

Scroll Snap
-----------

  - RESOLVED: Drop the box keywords from scroll-snap-area
              (can consider re-adding in the future if needed)
  - MaRakow will review the version of Scroll Snap that TabAtkins
      and fantasai have created in order to resolve which of the two
      versions of Scroll Snap is the main document.

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

Agenda: https://wiki.csswg.org/planning/tpac-2015#agenda
Scribe: fantasai

All Spec Review
===============

  glazou: I took all the documents in our web space, w3.org, and
          look at the last TR publication for that spec and the last
          dev.w3.org publication.
  glazou: Some of our documents are really old, meaning that both
          the official and the ED are old.
  glazou: These ones are endangered.
  glazou: Some have an old pubdate on TR, or the draft is not
          recently updated, and there's some action needed.
  glazou: And some in perfect state.

  SimonSapin: With regards to color correction, we decided to remove
              yesterday the section of css-color-4 that contains the
              exact same content as this draft.
  SimonSapin: Should we just remove this draft?
  SimonSapin: It's just an ED

  RESOLVED: Redirect color-correction to css-color-4, remove draft

  glazou: Basic Box Model
  glazou: These documents give a false image of our WG.
  glazou: Another example is Speech.
  glazou: It was actively maintained by dweck, but he moved to
          something else.
  glazou: We have a CR that is now 3.5 years old.
  glazou: But the last ED is same date.
  fantasai: There's nothing to change, we're waiting for
            implementations.
  fantasai: I think in some cases we just need to wait. In others,
            if we think it's no longer a good idea, remove it.
  glazou: Let's add a note explaining its status then.

  glazou: Orange drafts, just require a new WD.
  glazou: Yellow ones, the list is pretty long.
  glazou: It just needs publication.
  glazou: Font loading L3, almost at the bottom. LC from 2014, but
          we have an ED from this month.
  glazou: So we should republish,
  glazou: to let public know that document is still active, still
          maintaining.
  glazou: Then we have green ones, which are perfectly safe.

  glazou: If someone has no knowledge of our group, goes to that
          document, it seems perfectly normal.
  glazou: This list is too long.
  glazou: We have a commitment problem to republish. We should
          republish more often.
  glazou: Semi-official rules of W3C want us to republish every
          3 months.
  zcorpan: 6 months per spec.

  jdaggett: For specs that are in CR, even though they're in CR, we
            should publish?
  glazou: CR document is a little bit different, need to finish test
          suite and move on.
  glazou: CR that remains 5 years in CR, this is not normal.
  glazou: Conditional Rules is CR since 2013, have ED from 2015
  glazou: We need to do something.
  glazou: Either republish because technical change, or need to
          finish the spec.
  glazou: I'm saying we have too many documents of that kind in this
          WG.
  glazou: We are roughly 30 ppl, 60+ documents on the radar.
  glazou: Our goal is not to submit more and more proposals.
  glazou: Our goal is to submit proposals and make sure they become
          a standard.
  glazou: Shouldn't take 5 years to reach REC.
  jdaggett: Practically speaking, this group has for the most part,
            2 major contributors.

  glazou: If someone looks at our work, what does that person see?
  glazou: Documents that stay out of REC forever.
  glazou: We have to do something,
  glazou: First republish documents that need republication.
  glazou: Too many documents need republishing.

  jdaggett: I'm still confused, e.g. for Fonts, there are some minor
            edits, but what does that mean about this list?
  jdaggett: Are we taking that back to WD?
  fantasai: New process doesn't require that, can just republish CR.

  Florian: We have multiple problems.
  Florian: We have some documents with changes that need
           republication, that we just have to do.
  Florian: But reaching REC, it's not something we can do. We need
           implementations.

  glazou: Let's take 1 concrete example, used worldwide by everyone,
          Transitions and Transforms.
  glazou: These are WDs from 2013.
  glazou: The whole world is relying on theses. We have a problem.
  dbaron: I'm editor of Transitions.
  dbaron: My biggest issue is good issue tracking software,
  dbaron: to create disposition of comments.
  dbaron: I'm not very good at telling people, “you made a comment
          on this spec, I don't think it's actionable therefore I'm
          not acting on it.”
  TabAtkins: We just send such an email. Just do it.
  * liam notes there's issue tracking software (e.g. tracker,
         bugzilla, github) that can produce an automatic disposition
         of comments.

  glazou: Multicol layout is CR since 2011.
  glazou: It's implemented everywhere.
  Florian: It's not implemented everywhere to the point that it can
           go to REC.
  glazou: There's a core featureset that works.
  fantasai: Minus miscellaneous bugs, there's a lot of misc bugs.
  glazou: Implemented, not implemented.
  Florian: Multicol is implemented, but very buggy.
  Florian: Multicol is very different from transitions.

  glazou: I want to have this session where 7 years ago we had
          similar problem.
  glazou: We had some CRs, some WDs, but not publishing RECs.
  glazou: We got signal from staff, this is the wrong way to work.
  glazou: Here we have CRs that remain CRs forever.
  glazou: I suspect we're going to have the same problem.
  glazou: We have a problem with test suites that we are never able
          to complete.
  glazou: We have problems with tools, I can agree with that, but we
          have to do something.

  Florian: Wrt test suites, we have multiple problems on test suites.
  Florian: Not enough people write, not enough people review.
  Florian: I have tests pending review for months.
  Florian: If I can't get tests reviewed, not sure how to move
           forward.
  Florian: There's a problem of tooling, but not only.
  Florian: Should we find a different way to find people to review
           tests?
  Florian: Tests that remain unreviewed for months don't encourage
           writing more tests.

  <tantek> or find a different way to allow *anyone* to review tests
           and approve/comment
  <tantek> and have that logged
  <fantasai> we do
  <tantek> it's a bit opaque
  <fantasai> tantek, anyone can review
  <tantek> fantasai: the word "review" does not exist on this page:
           http://www.w3.org/Style/CSS/Test/
  <tantek> if you have to know where to look, then no, not anyone
           can review. it's not discoverable.
  <fantasai> yeah docs suck, need to fix them

  glazou: Shouldn't work on all tests together. Prioritize, do a few
          specs per quarter or semester.
  glazou: Then it's done.
  fantasai: We should audit specs and republish as necessary yes,
            testing is a bigger topic.
  glazou: Days of 100 tests per spec are over...
  glazou: I'm not sure old way of making tests is going to survive
  fantasai: We have a break-out session on testing tomorrow, with
            gsnedders. I suggest we discuss that then.

  fantasai: What do you want to do now?
  glazou: Update the outdated drafts.
  glazou: That's all for these documents.
  glazou: For list of red documents, if we can move to attic, let's
          do it,
  glazou: If some need strong warning, let's do it.
  glazou: For the others we, make decisions.

  fantasai: Speech I think we just need to leave there, no
            implementations, alternative is to rescind the
            recommendation.
  fantasai: Speech has two options: stay as is, or rescind
  liam: Or republish just to refresh the date.
  Florian: Status saying that no changes, just waiting for
           implementations.

  RESOLVED: Republish speech with updated status

  ACTION Bert: Republish speech
  <trackbot> Created ACTION-733

  [Text Decoration - fantasai to review if any substantive changes]
  [Masking - 1 year old]
  astearns: Getting some implementation
  glazou: Needs work on tests.

  MaRakow: Deal with this by identifying what it needs, different
           for each one, e.g. tests for this, republication for that.
  MaRakow: We can't force implementations, but if need a push, push
           it.
  [Masking needs tests]

  glazou: Exclusions, need a WD update?
  Rossen: Nothing needs to be edited.
  Rossen: One implementation of it.
  Rossen: There are some tests.
  Florian: What's blocking CR?
  fantasai: Consensus that it's a good model?
  fantasai: There were concerns about collisions.

  <skk> Text Decoration is often used in e-book domain (It is
        referenced from EPUB). We thought that this is very stable.
        (I'm not sure but) can it transit to next step? (not enough
        tests?) I heard that we have slight issues not told to WG.
  <dino> skk i think you should propose that as an agenda topic for
         a coming meeting.
  <skk> dino, thanks. I'll hear from my colleagues, and (at first)
        post it to the list. (after, I want to discuss in the coming
        meeting if needed)

  fantasai: Seems to me 6 months is too strict, we have specs not
            changing for a year.
  SteveZ: We just want to update the status, that's the goal.
  Florian: Update the date is fine, thing that's blocking is not the
           same.
  Florian: We're waiting either for everyone to agree to implement,
           or a solution to the problem that's blocking.
  glazou: So let's republish, then decide what to do.
  astearns: I say we keep it as WD and republish
  fantasai: I need to rewrite a section, then publish.
  fantasai: Republishing a spec is an hour's work; consider the
            value of republishing relative to other work.
  glazou: Just republish first.

  glazou: Motion Path, maybe refresh, but not sure, is there any
          progress on motion path?
  dino: 2 implementations
  shane: What it needs is tests.
  glazou: It's an FPWD,
  glazou: but it's almost REC.
  dino: Let's publish a second WD.
  fantasai: This is just busywork. Publish an update with fixes to
            issues.
  shane: 5 issues.
  fantasai: Then solve the issues, and then publish a WD.

  glazou: Basic box model.
  Bert: It's in very bad shape.
  SimonSapin: Before I joined the WG, people said, "Don't look at
              this, it's wrong. Look at CSS2."
  SimonSapin: Maybe we should replace it with a document that says
              "Look at CSS2, we will rewrite it later"
  Florian: The ED has a warning, but not the TR.
  Bert: My preference would be to remove a lot of the content that's
        strange ideas.
  Bert: Cut it down a lot, just keep description of properties and
        maybe lots of issues.
  Florian: If we have time to do that, do that, otherwise delete all
           content. It remains in source control.

  ACTION Bert Publish update WD to Box Model in 4 weeks
  <trackbot> Created ACTION-734

  glazou: Box alignment.
  fantasai: A couple issues to discuss with dbaron, but can publish
            in November.

  dbaron: Color correction was deleted from repo 2 minutes ago.

  glazou: Mobile text size adjustment.
  dbaron: I'm not quite ready to say we should abandon the spec, but
          we might want to.
  glazou: Then maybe add a warning to it

  glazou: OM values,
  zcorpan, TabAtkins: We should drop that.
  TabAtkins: This is an incomplete proposal from Anne, being
             superseded by Houdini work.
  TabAtkins: We should just kill it.

  ACTION plinss Remove cssom-values and redirect to Houdini Typed OM
  <trackbot> Created ACTION-735

  glazou: Line Grid 1
  astearns: Koji had a proposal for simplifying, should look at that
            before updating.

  glazou: Animations needs a republish at least.
  birtles: Can republish, but want to discuss this afternoon first.

  glazou: Text L3?
  fantasai: I have an outstanding action to finish edits and
            republish, have been avoiding the last 2 years.

  glazou: Fragmentation
  fantasai: Need to update DoC and go to CR.

  glazou: Transforms and Transitions are 2 years old.
  glazou: Need to do something about that.
  dbaron: Transitions is close enough to CR that I'd rather just get
          to CR.
  dbaron: I'm not an editor of transforms, I think there are some
          bits that are not ready for CR.
  dbaron: I don't know what's happened since last time.
  dino: We've got one outstanding issue on 3D transforms, waiting
        for feedback from Microsoft.
  MaRakow: Microsoft has given some feedback on 3d transforms but
           still outstanding issues that need resolving. ED has new
           language that needs to be resolved on before republishing.
  fantasai: Then let's solve it, and then publish.
  * fantasai not in favor of publishing fo the sake of publishing
  * fantasai suggests to chairs to put Transforms on the telecon
             agenda in 2 weeks, to pressure ppl to solve the "one
             remaining issue"

  glazou: Variables?
  ACTION ChrisL Publish Variables as CR
  <trackbot> Created ACTION-736
  ACTION ChrisL Publish Will Change as CR
  <trackbot> Created ACTION-737

  glazou: Device Adaptation 4 years old, with edits this September.
  Florian: I'm a co-editor. Not actively working. But in discussions
           with ppk about two things.
  Florian: What spec says is mostly correct, but very hard to
           understand.
  Florian: So there is a need for significant editorial work.
  Florian: It's a major rewrite before anyone can understand the spec.
  Florian: I still think it's a useful concept, but I have no time
           to work on it.
  Florian: Don't think we should drop it.
  fantasai: If there are changes, we should republish and mark an
            issue for editorial update.
  Florian: I can review the content of the changes and see if we
           need to republish.
  jdaggett: Date bump is not actually useful unless someone is
            actually working on it.
  Florian: There are two partial implementations.
  fantasai: Can Microsoft help with editing, given you have an
            implementation?
  Florian: I can take an action to review the changes.

  ACTION Florian Review status of device adaptation
  <trackbot> Created ACTION-738
  <Florian> action Florian to review changes in device-adaptation to
            see if we need a new WD or just a date bump
  <trackbot> Created ACTION-739

  RESOLVED: Matt Rakow added as co-editor on device adaptation

  glazou: Filter effects
  TabAtkins: dirk schulze
  TabAtkins: No issues.
  fantasai: Is it ready for CR?

  glazou: GCPM
  dauwhe: Moving most to generated content, others have
          interoperable implementations.
  Rossen: Republish what you have?
  Florian: What's left?
  dauwhe: Footnotes and running head string-set.
  Florian: WD, yes, CR, less sure.

  RESOLVED: WD of GCPM

  fantasai: Sizing, need to review.

  glazou: Lists?
  TabAtkins: That needs dramatic cuts
  TabAtkins: Need to trim a lot, then republish.

  glazou: Positioned layout?
  Rossen: Ready to republish.

  glazou: Regions?
  astearns: Could republish.
  fantasai: I can review to see if can republish, but has tons of
            issues open.

  glazou: Overflow 3
  Florian: There's a mix of obviously useful things and experimental
           stuff in that draft.
  Rossen: Can we republish?
  Florian: For experimental things... doesn't feel WD-worthy.
  fantasai: It's an early WD, doesn't need to be stable to publish.
  dbaron: Could split stuff into L4.
  Rossen: What's the holdup?
  Florian: Fragmentation, overflow pagination, not quite at the rest
           of the spec.
  fantasai: Unless you're actively pushing for CR, you don't need to
            cut things.

  glazou: Font Loading 3
  jdaggett: A few minor issues
  TabAtkins: Can drive that to CR.

  glazou: Scoping L1
  fantasai: On the agenda today.

  Rossen: zcorpan, CSSOM editor Glenn Adams should be moved to the
          former editors section

  glazou: MQ4?
  Florian: Should republish.
  ACTION Florian republish MQ4
  <trackbot> Created ACTION-740

  glazou: Non-element Selectors 1
  TabAtkins: It's not ours, we were just the appropriate group.
  TabAtkins: I have no idea what implementations are supposed to
             exist for this.

  ACTION astearns figure out status of non-element selectors
  <trackbot> Created ACTION-741

  glazou: Selectors 4
  fantasai: On my to-do list, right under scroll snap.

Scribe: dbaron

Scroll Snap
===========

  TabAtkins: Element-based issues.
  fantasai: Yeah, the change proposal.
  TabAtkins: Did we talk about the one about element-based snapping?
  fantasai: Yeah, accepted. Want overlarge elements and independent
            [?].
  Dino: We are mostly happy with everything.
  Dino: The new spec
  Dino: A little confused about ... maybe like to defer 2d thing to
        next level, struggle to understand it.
  Dino: The 2d snapping.

Independent scroll-snap-type per axis (Issue 45)
and 2D snapping, such as cities on a map (Issue 67)
------------------------------------------------------------------

  <fantasai> https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-45
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Oct/0213.html
  <fantasai> https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-67
  <fantasai> (both issues here are relevant)

  TabAtkins: There's double-1d-snapping and there's 2d-snapping.
             This is 2d snapping.
  fantasai: This is issue 45. You can snap in one axis or both axes.
            If you snap in both axes you might snap independently or
            simultaneously.
  TabAtkins: i.e., in the separate axis thing, 2 different elements
             could be snapped, one in the horizontal and one in the
             vertical.
  TabAtkins: If you want only a single element to be snapped in both
             axes.
  Florian: Cities on a map.
  TabAtkins: Or images in a photo gallery where you want one centered.

  Dino: We want to push 2d to level 2.
  TabAtkins: The photo strip case was one of the original use cases
             from Matt. That needs 2d snapping to do well.
  fantasai: Aren't they all laid out in a line?
  Dino: I thought 2d use cases were flowchart diagram.
  MaRakow: Spreadsheet maybe?
  TabAtkins: No, that's 2x-1d-snapping.
  fantasai: In a strict grid, the 2 types are indistinguishable.

  MaRakow: So you're splitting 2d scrollers into 2 categories?
  TabAtkins: Yes.
  TabAtkins: Once you have 1d snapping, doing it twice is not a
             problem, but actual 2d snapping is a separate use case.
  TabAtkins: I'm curious what was confusing to y'all (Dino) about it.
  Dino: We'll have to give that as feedback.
  Dino: We spent time with people in a room and couldn't work out...
  hober: I think it was editorial in nature.
  hober: The English prose.
  hober: lease use small words.

  TabAtkins: The proposal now, simplified from previous, is just
             'scroll-snap-type' (proximity | mandatory | none) and
             what axis you're snapping to (x-axis, y-axis, point
             (2d))
  TabAtkins: That way no weird confusing about mixing 1d and 2d.
  TabAtkins: Which way you snap is declared on container now
  <fantasai> https://drafts.csswg.org/css-scroll-snap/#snap-type
  <fantasai> scroll-snap-type: none | [ proximity | mandatory |
             trap ] || [ x | y | block | inline | both | point ]

  TabAtkins: scroll-snap-padding is padding on the container to
             limit the area that you're considering for snap stuff.
  <fantasai> https://drafts.csswg.org/css-scroll-snap/#snap-padding
  <fantasai> scroll-snap-padding: [ <length> | <percentage> ]{1,4}
  TabAtkins: Say you're doing a map and want to center cities on
             map, but have sidebar overlaid a bit. So centered on
             screen looks off-center, so set scroll-snap-padding to
             block out part that's sidebar'd.
  Florian: Agree with that, but have issues yet to raise about that;
           will raise shortly.

  fantasai: We agreed to drop scroll-snap-point-x/y

  <fantasai> https://drafts.csswg.org/css-scroll-snap/#scroll-snap-areas
  <fantasai> scroll-snap-area: [ border-box | margin-box ] ||
             <length>{1,4}
  TabAtkins: scroll-snap-areas allows ...... ... , to put a margin
             top or bottom on the scroll snap area, to let you see
             what's past it.
  fantasai: Important thing is this gives you an area that you're
            snapping rather than a point. Advantage is for handling
            overlarge elements. Because UA knows that, when screen
            is smaller than area, it can allow the user to pan
            around that area. When you only have one point you're
            snapping to, you can align that point but can't see rest
            of element with mandatory snapping.
  fantasai: Author hasn't said what stuff is to be visible in
            snapped position.
  fantasai: Thus we went to scroll-snap-area to set area and
            scroll-snap-align to align that area in the viewport.

  MaRakow: The issue about splitting x and y into separate snap
           types?
  fantasai: No, this is a different issue.
  fantasai: Because we're not using position syntax, the position
            syntax requires a position in both axes, but sometimes
            you want to snap only in the vertical axis; this syntax
            allows to specify wanting snapping only on the top edge
            but don't care about left/right sides, per box.
  fantasai: Higher-level switch is scroll-snap-type: specify axis
            scroll container cares about snapping to. But on element
            level, element might not want to define snap position in
            both axes.
  MaRakow: Diagram?
  TabAtkins: I can draw.
  Florian: Is switching to element-based snapping the motivation for
           this entire rewrite?
  TabAtkins: Correct.

  TabAtkins: [Draws]
  TabAtkins: [says he'll put the diagram, or similar, in the spec]
  [dbaron takes photo of diagram]
  [whiteboard drawing:
https://lists.w3.org/Archives/Public/www-archive/2015Oct/att-0062/img_0237-Meeting-Whiteboard-CROPPED-CONTRAST.jpg]
  <fantasai> [TabAtkins explains what all the properties mean]

  TabAtkins: [in response to MaRakow] if you want to center, set
             scroll-snap-align to center center; probably scroll-snap
             -area: border-box (initial value) is fine.
  MaRakow: How different from existing properties?
  TabAtkins: Translating the concepts well; big difference is that
             destination and coordinate are point-based which is
             difficult to talk about well when handling error cases
             (large elements)...
  MaRakow: Splitting X and Y?
  TabAtkins: Yes, splitting apart so only have to worry about one
             side if you want. And it's talking about aligning
             rectangles in other rectangles, and CSS knows how to do
             that well and handle errors well.
  TabAtkins: Aligning rectangles is something easy to handle.
  Florian: Maybe not obvious what to do, but you have the
           information that something is overflow. If you went by
           points, you don't know about overflow so you can't act on
           it.
  TabAtkins: scroll-snap-padding and scroll-snap-area are to modify
             the default boundaries; defaults often good.
  Florian: With nested elements... tops are a identical points, but
           with areas, you can distinguish overflow, you have enough
           information to act on it.

  TabAtkins: An example was blog posts, where you want to show a bit
             of the previous one.
  TabAtkins: Leave scroll-snap-padding: initial value
  TabAtkins: scroll-snap-type: proximity y (or could omit y if only
             scrollable in one axis)
  TabAtkins: scroll-snap-area: border-box 20px 0 0 0
  TabAtkins: scroll-snap-align: start
  MaRakow: scroll-snap-align is what's saying that it's the top edge
           that's snapping.
  TabAtkins: Yes.
  TabAtkins: So you could just say scroll-snap-area: 20px 0 0 0;
  fantasai: Or might want 20px on both edges... if you're only
            snapping to one edge, easier to drop 0s,
            scroll-snap-area: 20px

  TabAtkins: [response to Dino] scroll-snap-area: margin-box 4px
             grows the area by 4px outside the margin.
  Rossen: used margin? collapsed margin?
  TabAtkins: You still have a well-defined margin-box with
             margin-collapsing.
  fantasai: Same as you use for shapes.
  dbaron: Shapes happen on things that don't collapse margins...

  astearns: Can use margin-box on shapes for masking.
  TabAtkins: So maybe we need to define it.
  TabAtkins: border-box is most common; don't recall why we had
             margin-box.
  Rossen: Try to drop it.
  TabAtkins: Drop the box keywords entirely, just use the offsets.
  fantasai: Sounds good.

  RESOLVED: drop the box keywords from scroll-snap-area

Two Spec Versions
-----------------

  Rossen: So... not having 2 competing specs?
  TabAtkins: Yes, getting to that.
  TabAtkins: So we have a spec that we think is ready for WD, we
             even have a DoC for CR.
  fantasai: This in an unofficial draft.
  fantasai: We made the changes to the propdef tables, took all text
            from Matt's spec and incorporated into this spec.
  fantasai: We added all additional things based on issues in issues
            list.
  fantasai: We went and addressed all issues since 2013; have a DoC.
  fantasai: Spec now is different in the ways just discussed, and a
            superset of text in both specs.
  fantasai: This is effectively the merged spec; we'd want to use
            this as the master copy, but want Matt to look in depth
            and make sure it's correct, and keep working together on
            it.
  TabAtkins: roc is fine with doing this, we (Chrome) are fine with
             it; we haven't heard from Apple though previously think
             smfr said fine to switch over, so the issue is
             clarification from Apple, and from IE if this is all
             right.
  MaRakow: It's a lot to take in here.

  TabAtkins: We were told in no uncertain terms that if we wanted to
             change it had to be quick.
  TabAtkins: By Apple and Mozilla.
  TabAtkins: We went through 2 years of mailing list feedback, went
            through and addressed all feedback.
  MaRakow: Other large issues other than large element?
  TabAtkins: Anything that says "Accepted by TF" is stuff that was
             addressed only in our draft and not in yours.
  TabAtkins: MaRakow, we'd be happy to go through them with you.
  fantasai: Many changes were fallout of switching to this model;
            others were editorial or minor fixes.
  fantasai: The major issues were handful accepted by switching to
            this model.
  fantasai: Solves overly large elements, solves issues with syntax,
            issues with bad naming of destination/coordinate,
            axis-specific scrolling.
  TabAtkins: We know 2 browsers are fine with this. Microsoft
             implementation is fine with the spec since we agreed to
             drop x/y and remaining pieces in Microsoft's
             implementation are subset of this.

  TabAtkins: Is the WG fine with this and can we accept this as the
             scroll snap model?
  astearns: How long will it take for you to come up with answer?
  MaRakow: Can talk with TabAtkins and fantasai and find out what's
           changed here.
  Dino: We already gave our feedback.
  hober: If people want this to go to CR soon...

  [meeting is breaking up]
  [fantasai wants to know whether we're switching over,
   pending MaRakow's approval]
  [Rossen is concerned that this is a major change and wants everyone
   to discuss it more]
  [dbaron notes that a lot of feedback wasn't handled previously,
   and implementers, under pressure to implement something,
   implemented something they didn't like that was what was in old
   spec, which was a problem]
  [meeting closed to discuss further, MaRakow to discuss changes with
   Tab and fantasai to understand them better]
  [revisit topic later]
Received on Tuesday, 24 November 2015 01:17:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:58 UTC