[CSSWG] Minutes and Resolutions TPAC 2011-11-01 Tuesday Morning II: Testing, CSS2.1, CSS3 Borders

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