- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 28 Nov 2011 14:25:48 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Unless you're correcting the minutes,
*Please respond by starting a new thread with an appropriate subject line.*
Testing and CSS2.1
------------------
RESOLVED: Update the site/wiki/etc to publicly prioritize testing css3
modules rather than 2.1 (for those who want WG guidance on what
to work on).
RESOLVED: Have all 2.1 issues filed in bugzilla by the february meeting.
RESOLVED: Every year, evaluate CSS2.1 and republish if necessary to keep
it up-to-date.
RESOLVED: Publish a CSS snapshot annually.
RESOLUTION: All issues with the tests (not the infrastructure) go to Shepherd.
Backgrounds and Borders
-----------------------
Discussed ISSUE-89 definition of color transition center for border corners.
http://www.w3.org/Style/CSS/Tracker/issues/189
http://lists.w3.org/Archives/Public/www-style/2011Nov/0006.html
http://lists.w3.org/Archives/Public/www-archive/2011Jul/0005.html
====== Full minutes below ======
http://www.w3.org/2011/10/31-css-irc#T18-43-31
http://krijnhoetmer.nl/irc-logs/css/20111101#l-1267
Scribe: TabAtkins
florian: Extra agenda item - CSS3 Text, talking about text-transform
sylvaing: Extra agenda item - discuss how to move some of the current specs
with lots of impl xp.
<bradk> xp = experience points?
Testing
-------
JohnJansen: I'm thinking there are N new tests, and I'm wondering when
they're going to be moved into a snapshot.
JohnJansen: And what it means if we don't have two impls passing those
new tests.
fantasai: To the 2nd q, it doesn't mean anything - we're just moving
towards better interop. It doesn't revoke our Rec status.
fantasai: To the 1st q, I think somebody needs to make sure everything's
in order and nothing's been lost (general vetting), and then
we can just create a new snapshot any time.
JohnJansen: Should we have a regular schedule for that, so I can
predictably work on it? Otherwise things tend to sit.
fantasai: Sounds good. What schedule do you want?
JohnJansen: I think it should be in conjunction with publishing errata,
so tests over the new errata show up at the same time.
plinss: I think that makes a lot of sense, it's a no-brainer.
plinss: Gerard's been reviewing a bunch of tests, and have a bunch
flagged now with problems, but no one's working on them.
JohnJansen: I think one of the challenges is prioritization.
JohnJansen: Gerard is making a lot of comments (others too) - some are
corrections, some are improvements.
JohnJansen: But they get the same prioritization. I'd like to prioritize
a correction versus an optional improvement.
JohnJansen: We should jump on errors.
JohnJansen: When I come into work in the morning, though, I dunno if I
should work on 2.1 tests or css3 new tests.
JohnJansen: We've got a lot of specs approaching CR or even Rec that
need tests.
JohnJansen: But I've got a finite amount of time in my day.
JohnJansen: So some help in prioritizing would be helpful.
fantasai: You also wanted a snapshot at the time of errata pub.
fantasai: I'm not sure how long it takes to go from PER to Rec, but we
are *way* behind on tracking 2.1 issues.
JohnJansen: Right. It's never on the agenda.
fantasai: The reason's simple: I stopped tracking them - I switched to other
specs. I was never even an editor, but I was doing most of the
tracking, so when I stopped, the tracking stopped.
fantasai: So we need somebody to track the issues for 2.1. They need to
start now, track into the future, and move backwards to the LC
deadline, which is a lot of stuff.
fantasai: Once we have a list, we can do a few issues each telcon and
make progress.
fantasai: We can make sure that resolutions end up in the errata and the
draft.
fantasai: And I am *not* volunteering to do any of that.
fantasai: We can't have a new errata until someone takes this up.
<fantasai> http://www.w3.org/Style/css2-updates/REC-CSS2-20110607-errata.html
JohnJansen: yesterday we made a decision on margin-collapsing that needs
to go in, for example, and it should be tracked.
fantasai: Theoretically it should be in bugzilla.
Bert: I've been lax about this, but I'm going to go through and extract
things to Bugzilla.
Bert: I'll start when I get back to my office.
fantasai: If you can maintain a date range that you have definitely
covered, that would be very useful.
fantasai: So if somebody decides to help you, they can just start at the
last date you've touched and work backwards.
<dbaron> http://wiki.csswg.org/spec/css2.1 says
"Last mailing list sweep 2011-01-07 -- arronei "
dbaron: I'll edit the 2.1 issues wiki to say that new issues go to Bugzilla.
dbaron: But we can still keep the mailing list sweep dates here in the wiki.
dbaron: And there's a bunch of open issues here in the wiki that need to
migrate.
JohnJansen: Last idea - encourage the focus to fall on CSS3 modules,
from a testing perspective, rather than continuing to
focus exclusively on 2.1.
fantasai: One thing to keep in mind is that all tests in 2.1 are a
subset of the tests we'll need in css3.
fantasai: So for B&B3, we'll just take all the relevant tests from 2.1,
convert to reftest if possible, and then augment with new tests.
fantasai: Because that's easier than just writing entirely new tests.
plinss: In most cases, that's nothing more than adding a new spec link
to the existing test. No moving, no copying, just add a new
link and Shepherd will pick it up and track.
<gsnedders> How does Shepherd cope with tests becoming reftests?
<plinss> not an issue, it just adds the reference
JohnJansen: Even if we moved all the 2.1 tests for B&B to B&B tests,
we're still not complete.
JohnJansen: So should we prioritize writing more css3 tests, or
continue prioritizing 2.1.
fantasai: We need both, but we should prioritize writing new tests for 3.
fantasai: If people outside the WG want to work on 2.1, we should support
them, though.
JohnJansen: Agreed, but I'm not sure that we should *encourage* them to
work on 2.1.
JohnJansen: As a WG, we should give guidance to people who want to
participate, and we should guide them to work on 3.
dbaron: Two types of tests - one is to validate the spec, and one is
to improve interop.
dbaron: For the former, the priority should be writing for css3.
For the latter...
dbaron: I don't want to discourage 2.1 tests. We're still undertesting
parts of the spec.
TabAtkins: So if someone comes up and says "I want to work on tests",
we should encourage specific css3 tests.
TabAtkins: But if they want to work on 2.1 tests specifically, that's cool.
fantasai: We should have a list of specs that need testing help, but
Gerard, for example, really wants to work on 2.1 interop,
and that's fine.
fantasai: We can put a list on the wiki of specs that are in maintenance
and could use tests.
JohnJansen: And additionally, we don't know and can't really track what
parts of 2.1 need tests, we just have sort of a gut feeling.
JohnJansen: We can provide rough guidance there too, though.
JohnJansen: My preferred idea is that we're just done with 2.1, it's Rec,
and we have a regular maintenance schedule, but it's not a
living spec that needs active attention.
RESOLVED: Update the site/wiki/etc to publicly prioritize testing css3
modules rather than 2.1.
arronei: We need a per-spec maintenance schedule.
plinss: Probably in conjunction with the snapshot.
fantasai: We don't have anything new to snapshot yet, but we have a lot
of things to errata.
fantasai: I don't see anything being added to the 2010 snapshot that's
not already in the 2011 snapshot.
arronei: Why not put errata in there?
plinss: We can have a list of "these specs are in Rec, here's their
errata", etc.
fantasai: Right now we just list the stable things and link to the spec.
So that's no change.
arronei: I think it's good to publish an annual snapshot anyway. I want
to see the 2011 snapshot, not the 2010 snapshot.
TabAtkins: It's difficult to tell the difference between "there was no
change, so no updates" and "the spec is dead, and it's
out-of-date".
JohnJansen: And without a deadline to the issue tracking, work will
grow to fill the alloted time.
JohnJansen: With a specific once-per-year date or something, we know
when things are expected and have a push to get the necessary
things done.
arronei: I'm hearing that we want a maintenance schedule. Should we
set one up for 2.1 right now?
arronei: And beyond that, each spec can have its own schedule (or hook
into the existing one, we can evaluate per module).
arronei: But we should at least nail down 2.1's schedule.
fantasai: PLH suggested republishing every year.
fantasai: Should we set a goal to have all issues in the tracker by
the Feb meeting? Bert, is that workable?
Bert: Yes.
RESOLVED: Have all 2.1 issues filed in bugzilla by the february meeting.
dbaron: I think 2.1 issues are best addressed on the mailing list, not
in a f2f.
fantasai: Right, this is just a deadline for getting them in a tracker,
not resolving them.
dbaron: We should at least attempt to deal with them on the mailing list
before bringing them to a f2f meeting.
RESOLVED: Publish an updated version of 2.1 and its testsuite annually.
Bert: Once a year seems quite fast. More like every 5 years seems more
reasonable.
plinss: We should keep the once-a-year as a review cycle. If it turns
out that the issues are tiny, okay, we'll skip publishing this year.
PROPOSED EDITED RESOLUTION: Ensure that 2.1 is up-to-date yearly.
<gsnedders> IMO publishing once a year makes sense if there are non-editorial
issues. Even if the issues are tiny it's probably still worth
publishing if they have normative consequences.
plinss: Should we commit to publishing an annual snapshot?
RESOLVED: Publish a snapshot annually.
fantasai: I think we should try to address 2.1 issues on the telcon each week.
plinss: Once we get some together, yeah.
dbaron: I think we should try to resolve them on the mailing list first.
plinss: Yes. But once a proposal appears on the mailling list, quickly
discuss it for telcons.
JohnJansen: Another thing - I don't yet know how to prioritize the
comments to the list for the current 2.1 testsuite.
fantasai: If it's invalid, fix it immediately.
fantasai: Tests that are imprecise (impls can pass when they actually
fail the spec) should be fixed next.
fantasai: And then issues with metadata or reusability are nice-to-fix,
but not strictly necessary.
fantasai: Every time we snapshot, the first two types should have all
been fixed.
fantasai: The last should be fixed as time allows.
JohnJansen: I agree with that.
JohnJansen: I don't yet know when I should make sure that's done by.
fantasai: The last pub was June 2011, so the next will be June 2012,
since we're doing yearly.
<fantasai> http://test.csswg.org/shepherd/
RESOLUTION: All issues with the tests (not the infrastructure) go to Shepherd.
CSS3 Backgrounds and Borders
----------------------------
<fantasai> ISSUE-89
<fantasai> http://lists.w3.org/Archives/Public/www-style/2011Nov/0006.html
<fantasai> http://www.w3.org/Style/CSS/Tracker/issues/189
<fantasai> http://lists.w3.org/Archives/Public/www-archive/2011Jul/0005.html
fantasai: Look at the pictures!
fantasai: Which of these 4 looks correct?
plinss: #4
fantasai: #1 is what IE implements.
fantasai: #2 seems to be hooking up the half-way points of the arc lengths.
fantasai: #3 is the current spec which is totally crazy.
fantasai: #4 is what I think is correct.
smfr: I think we should look at different border widths.
fantasai: I picked equal widths for a specific reason.
fantasai: The reason I chose equal widths is that we know the angle must
vary to zero when the width of either side is zero, and there
are multiple ways to map the ratio of widths onto angles, but
1:1 is definitely 45deg.
fantasai: The quesiton here is how do you interpret "45deg"
smfr: Should border-radius influence what this corner-join should look like?
smfr: In the absence, it's pretty obvious - you just go corner-to-corner.
<smfr> https://bug-9197-attachments.webkit.org/attachment.cgi?id=30423
smfr: This diagram shows our logical interpretation which is independent
of border-radius.
dbaron: That doesn't work when one of the sides is very narrow or 0.
dbaron: You get a thick border that curves down, and then suddenly changes
color at these two triangles, and that looks really bad.
<smfr> http://jsfiddle.net/jMb8k/
dbaron: Did you consider that the spec is mostly correct, but it should be
looking at the curvature of the padding edge instead of border-edge?
fantasai: What if there's no curvature?
fantasai: The underlying algorithm is to find the point on the border
curve where the tangent's angle equals the ratio of the
border widths.
plinss: So find the angle that you would have without curvature, take
the normal of that, then find the point on the outer curve with
a matching tangent.
fantasai: That *sounds* right, but I'm not certain off the top of my head.
dbaron: Based on the fiddle, if we run the algorithm we're thinking of,
it would produce the funny backwards-facing transition line that
we don't want.
fantasai: I *think* you take the ratio of the two widths and apply that
to 90deg.
dbaron: Right, that's not our interpretation, and our intepretation is
wrong.
<tantek> Frankly, I don't want to resolve this without a designer in the
room.
<tantek> If the goal is some sort of aesthetic ideal, we should base it
on input from visual designer(s). Basing it on convenience of
math or some approximate visual ideal is probably not a good way
to resolve this.
<fantasai> tantek: there's a designer on your left
plinss: I think it's take the line from the inner to outer corner, invert
it over the 45deg line, then take the normal and match the tangent.
<tantek> fantasai - and I observe that he's scratching his head.
dbaron: I think I agree with you on the outside point. I'm not certain
that "closest point on the inside edge" is correct.
[some unminuted discussion about inner point]
<tantek> ok I think we should issue a public call for proposals for how
to resolve this issue (with the visual samples above as an
initial set of possibilities, open to others), and then invite
visual designers to provide input (on www-style)
<tantek> I don't think we should spend further time trying to resolve
this among this group in the f2f - I don't think is either a
good use of our f2f time, nor will it result in a visually
good solution.
<tabatkins> I disagree, tantek. This is productive so far.
plinss: You take the angle you'd have without a curve. Mirror it over 45deg
(so a 45deg line won't change), then take the normal and find the
tangent on the outer curve
plinss says to take the tangent on the inner curve
fantasai says she remembers trying that, and it gives bad results --
you want the shortest distance from the chosen outer point
dbaron: I believe a case something like "border-width: thick thin;
border-radius: thin thick;" can produce bad transitions with
this rule.
plinss: I think that has the right behavior. It's at least the limit
behavior.
dbaron: Actually, this may not be a big deal either. [mutters over details]
ACTION fantasai to detail the algorithm, and produce mockups for lots
of corner cases.
<trackbot> Created ACTION-396
<dbaron> http://www.w3.org/Style/CSS/Tracker/actions/396
Received on Monday, 28 November 2011 22:26:30 UTC