- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 23 Nov 2015 20:15:57 -0500
- 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