W3C home > Mailing lists > Public > www-style@w3.org > May 2018

Minutes Berlin F2F 2018-04-12 Thu Part V: Contain, CSS2, Testing Infra [css-contain][css2]

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 29 May 2018 16:03:23 -0400
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <30bd6e56-15c1-d5b1-778d-bbd21616e40f@inkedblade.net>
=========================================
   These are the official CSSWG minutes.
   Unless you're correcting the minutes,
  Please respond by starting a new thread
    with an appropriate subject line.
=========================================


CSS Contain
-----------

   - RESOLVED: You're allowed to have forced breaks inside a layout
               contained thing but you can't propagate the break to the
               parent. (Issue #2527)
   - RESOLVED: Elements with size containment are monolithic for the
               purpose of fragmentation. (Issue #2527)
   - After the resolutions from the F2F are edited in the authors will
       request an updated CR publication.

CSS 2.x
-------

   - RESOLVED: Accept this new editing process (documented here:
               https://gist.github.com/gsnedders/e0aab5ca6a8c06cee3bae4afcfd664ce )
   - RESOLVED: Use the naming scheme proposed at bottom of
               https://github.com/w3c/csswg-drafts/issues/2008#issuecomment-380828317
   - RESOLVED: Ask the team to make https://www.w3.org/TR/REC-CSS2
               redirect to https://www.w3.org/TR/CSS2

Testing
-------

   - The group discussed what it would take to move to WPT tests and,
       though there were plenty of pain points listed, the only
       commitment was from TabAtkins to continue improving bikeshed
       integration.
       - Some of the pain points mentioned:
           - Lack of manual test harness puts a lot of pain on the tester
           - Ahem font not installed for Edge invalidates most of those results
           - Lack of controls over shared files to prevent breakage
               when changes are made
           - Not exporting tests in a way the test harness can import
           - Needs fuzzy matching for ref tests
           - No good way to flag/differentiate 'may' and 'should' tests
               from 'must'

   - Documentation for testing was also discussed (Issue #2438) and the
       group come up with several recommendations:
       - Use the testing wiki to guide new testers and browser vendors
           since the WPT documentation is too high level for that
           audience
       - Don't re-write documentation that exists on WPT but instead
           link to it
       - Add search to the WPT documentation

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

Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule

Scribe: dael

CSS Contain
===========

How do layout and size containment interact with column/page
     fragmentation?
------------------------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/2527

   florian: We noticed containment was underdefined relating to
            fragmentation. Discussion conclusion is that elements with
            size containment should be monolithic for fragmentation.
   TabAtkins: Size yourself like you're empty.
   florian: Then layout yourself as if you have no content. That's size
            containment. That used to be an effect of layout
            containment.
   florian: There are cases where it's useful to do it without size.
   TabAtkins: Layout containment is whatever happens inside of you it
              doesn't effect the rest of the page.
   dbaron: Doesn't this need to apply to that?

   fantasai: I think if you have layout containment you need to trap
             all forced breaks.
   TabAtkins: Which I believe it does already.
   dbaron: If you're moving things around inside the layout containment
           it can effect the breaks.
   astearns: Elements with size or layout containment should be in the
             resolution.
   fantasai: But layout containment can grow and shrink so it should be
             allowed to fragment like a normal container.
   astearns: If we allow a layout contained thing to fragment it means
             it has layout effects outside the boundary it's supposed
             to contain.
   fantasai: But it's only changing size of container which is
             allowed already.
   TabAtkins: Yes, spec says it's except for size is not trapped.

   fantasai: Layout containment should trap forced breaks. Size
             containment can fragment normally, all that content
             overflows and it doesn't grow in size. When we fragment we
             put it back together like it's exactly the same height as
             a monolith.
   florian: It's possible to impl, but the down side, if you have a
            block tightly sized to contain several lines of text. The
            break would be 3.5 lines in the block. Regulate would be 3
            lines in the first 4 lines in the second and so there would
            be one line overflowing the last box. It seems worse than
            slicing the line. But what you said is possible.
   fremy: If next page is different size you size based on first page?
   florian: It'll work.
   TabAtkins: There are cases you can guarantee that you should have
              these effects and this keeps you honest because if you
              make a mistake you paint badly and it's obvious instead
              of your performance sucks.

   florian: We have one resolution that layout containment traps forced
            breaks. That's missing.
   astearns: If they can fragment why are we trapping them?
   fremy: Size can, layout can't.
   florian: No, relayouts inside a layout contained element shouldn't
            affect parent other then overall size changes. If we don't
            trap forced breaks arbitrary changes will have effects
            outside. Like if you change widows inside you propagate all
            the way up.
   fantasai: astearns has a point because a forced break is relative
             the same. The forced breaks can't propagate out. If you
             say page-break-before:always at the top it takes effect
             before the section and that shouldn't happen if it has
             layout containment.
   astearns: So you're just not allowing forced breaks to propagate to
             parent. I'm good with that.
   fantasai: We should be quite clear on that. It's subtle.
   dbaron: Spec may already say this.
   several: I don't think so.
   florian: Bullet 2 is fragmentation is if you have regions or
            overflow fragments.
   florian: I think we should add want you said.
   <TabAtkins> bullet 2 should be rewritten a little to be clearer
   fantasai: You're allowed to have forced breaks inside a layout
             contained thing but you can't propagate the break to the
             parent.
   <TabAtkins> point of it is that if content is flowing between
               multiple elements (regions or continue:fragments), then
               if one of the elements in the chain has layout
               containment, it traps any remaining overflow, so the
               subsequent parts of the chain don't get anything.

   astearns: Proposal: You're allowed to have forced breaks inside a
             layout contained thing but you can't propagate the break
             to the parent.
   astearns: Objections?

   RESOLVED: You're allowed to have forced breaks inside a layout
             contained thing but you can't propagate the break to the
             parent.

   florian: For size containment. Making them monolithic is a thing we
            can do. Non-monolithic can works but can trigger overflow.
            Do we prefer slicing sometimes or arbitrary overflow
            sometimes? I prefer slice.
   astearns: If we preserve the size by disassociating the fragments
             past the first one with the layout thy should contain I
             prefer the first.
   florian: Right. From end user reason PoV slicing seems better.
   astearns: fantasai to you object?
   fantasai: [missed]

   RESOLVED: Elements with size containment are monolithic for the
             purpose of fragmentation.

   astearns: Anything for layout contained items?
   TabAtkins: Aside from the trapping fragmentation can change size and
              that's allowed to happen.
   TabAtkins: None of the containments prevent outside information to
              come in.
   astearns: It's communications both ways. This outside says you need
             to fragment and the thing inside says here's how I'll do
             it. It's 2 way.
   TabAtkins: But the communication out is only about size.
   astearns: Anything else on this issue?

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

   florian: Could resolve to update CR.
   astearns: Need DoC and test cases.
   fantasai: And edits.
   florian: There's a DoC with everything before the F2F and I have a
            tag to track the missing tests.
   astearns: Let's see edits and tests and then we'll resolve.

CSS 2.x
=======

Proposed CSS 2.x editing & publishing workflow
----------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/2553
   proposal: https://gist.github.com/gsnedders/e0aab5ca6a8c06cee3bae4afcfd664ce

   tantek: I made a diagram based on discussion with gsnedders at
           dinner.
   tantek: We want to switch to 1 copy of css2. We want to make 2 kinds
           of changes, one is editorial and the substantive we want
           them to be informative delta notes.
   gsnedders: Notes we can publish them without implementations.
   tantek: And putting notes where people find them. When we go to CR
           those delta notes we ID as normative at risk unless they're
           interop and then we merge them in. CR to PR we look at the
           at-risk delta paragraphs. If they're impl we merge and if
           they're not merge to notes.
   tantek: Given that we think we can publish semi-regularly. Perhaps
           at F2Fs.

   tantek: [shows diagram on description]
   <gsnedders> https://gist.github.com/gsnedders/e0aab5ca6a8c06cee3bae4afcfd664ce#file-flow-png
   tantek: Any substantive changes where there's interop and if we
           don't have it there's not interop we'll go to CR. Once CR
           period is done we issue the PR. We ID at-risk and they're
           merged in or they become notes again. When PR closes we do
           ED.
   gsnedders: If there's no substantive changes we go straight to ED.
   florian: So if no change since last time to impl we can cycle ED?
   tantek: Yes. Only if there are type 1 changes do we seasonally do an
           ER. If there are type 2 we do a CR.

   fantasai: I think that's a lot of extra work for no benefit. Our
             goal is minimize process. If we don't have impl of
             anything yet and everything is we're hoping for impl
             there's no reason for CR.
   tantek: Type 2 edits are agreement from implementors to implement.
   fantasai: But if there's no... if none of the edits can fold into
             main line text there's no reason to go to CR with at risk
             notes. They may as well stay as notes.
   florian: I think that tweak reduces process churn and increases time
            spec is in ER.
   tantek: Okay with that. gsnedders?
   [gsnedders' shrugs]

   fantasai: This whole churn is a lot of work for Chris to set up.
   tantek: Reduce number of transition requests makes sense.
   astearns: So only got to CR once there is at least 1 interoperable
             type 2 change.
   tantek: Reasonable.

   tantek: So there's a number of steps to start, which gsnedders has
           started.
   tantek: gsnedders committed us down to one version. It reflects the
           2011 REC. It's a pull request right now.
   tantek: [reviews the need to do list]
   tantek: Assuming WG accepts this we'll drop this and build
           instructions into the read me.
   florian: The CSS2.1 PR is in the 2011 state?
   gsnedders: 2016 state. The 2011REC edited in place 2016 state.
   florian: Are edits between 2011 and 2016 correct?
   gsnedders: There's a diff. Except the anchors changing it's fine.
              There's some changes for publication rules and adding
              warning boxes.

   florian: Do you want to merge this and then work through things
            resolved?
   gsnedders: Yes.
   florian: So a temporary set back to the most up to date ER?
   ChrisL: It's a stabilization phase.
   florian: Current draft contains mix of correct and mix of not
            correct.
   gsnedders: We merge now and work our way through.
   tantek: And going forward all changes will be PR that require at
           least two positive reviews so there's a trail.
   ChrisL: Including tests for each change?
   tantek: Test requirement is when want to change delta notes to
           normative notes.
   ChrisL: But collecting tests is useful.
   tantek: Don't need to block edits on it.
   ChrisL: No, not block but collect them.
   tantek: When implementors implement the tests will be there.
   ChrisL: I suggest you use wpt 'tests needed' tag
   fantasai: And delta notes should contain links to tests.

   florian: Are you going from 2016 to corrected 2018 state quickly? If
            it will take a long time I want to wonder...I don't want to
            lose good edits for too long.
   ChrisL: Good edits should be in errata.
   tantek: We'll continue to link to errata doc, but the goal is to
           deprecate it.
   florian: I'm not an editor for CSS2.anything and I made a PR to
            merge in line-height. That's not in errata. I'm okay with
            that being pulled back but not if it's 5 years.
   gsnedders: I have a list of things that weren't made. Things that
              went through PR should be relatively easy to land if
              they've been reviewed.
   tantek: We've IDed open questions that are a minimum to do another
           CR. Those are listed on the agenda, but it can be done on
           telecon on github.
   florian: Yes, think it's fine. If it takes longer than expected that
            wouldn't be great, but hopefully it won't happen.

   astearns: Other comments on this process?
   fantasai: I think it's great.
   tantek: Which is good because you're starting as a co-editor.
   fantasai: I should be a former editor. That would be an accurate
             representation.
   tantek: Need a second editor. gsnedders isn't paid for it so he's
           mostly doing tests and build system.
   fantasai: I'd propose to have it be gsnedders and have me as a
             former editor and say former editors can review changes
             at same level as current editors.
   astearns: We've had resolution on different process, we need a
             resolution to say we're adopting.
   ChrisL: Can gsnedders' document be added to the readme to our own
           repo?
   astearns: That is part of the plan.

   RESOLVED: Accept this new editing process

   astearns: I can decree this. I decree fantasai as a former editor.
   <fantasai> DECREED: fantasai to be listed as former editor of CSS2.1
   <fantasai> :)

Testing
=======

WPT - Extra CSS testsuite requirements
--------------------------------------
   Github: https://github.com/w3c/web-platform-tests/issues/10053

   gsnedders: There's a lot in here. I won't cover all of it.
   gsnedders: Big pain points are mostly caused by CSS test rebuild
              system. The current one we have because the CSS test
              harness relies on it.
   gsnedders: We've had agreement before to make CSS test harness not
              rely on build system. Afaict the WG believes we need test
              harness for sake of impl reports.
   ChrisL: Correct
   gsnedders: But no one in this room will pay anyone to work on test
              harness.
   ChrisL: Pretty much.
   gsnedders: This is unfortunate. If we care as much as we say we do
              it shouldn't be hard to find someone to pay to fix the
              major issues that we know it has.

   florian: Who can estimate how much work that would be?
   plinss: I'm probably the only one still around.
   gsnedders: I can talk build system, not test harness.
   florian: We either fix test harness or improve build system.
   ChrisL: But they have different goals. One is a getting out of CR
           system and the other is regression system.
   gsnedders: There is a JS program that creates an impl report from
              automated test run data.
   ChrisL: And that's very partial for CSS
   gsnedders: Depends on the spec.
   ChrisL: Those are API specs.
   gsnedders: Even those that aren't we have very few manual tests.
              Majority of modules don't have manual.
   ChrisL: ref tests are non manual and they fail because the reference
           isn't exactly what it says?
   gsnedders: Then it fails. The pass is these two files are pixel to
              pixel.
   fantasai: I think if you generate an impl report that says all these
             test fail but they actually pass and did you check it's
             just the anti-aliasing? For specs with the anti-aliasing
             the pass condition shouldn't be pixel to pixel it should
             be can a human tell the difference. It's not ideal but we
             can't get out of this situation any time soon.

   astearns: 2 things. First we started with the requirements in the
             build system that are at times blindly broken by WPT
             because they don't have those requirements. Second is
             getting WPT to where we can use for impl reports and we
             should table that.
   florian: If second was easy we wouldn't need the first one. It
            probably isn't so we need the first.
   fantasai: I'd also like to assert that in terms of regression
             testing system for things that are manual only WPT ignores
             all those things and there are test suites where we
             haven't figured out how to test these things. Ideally we
             should run these tests every year or so. We did regression
             testing manually in the past and it sucks and we should
             avoid it but there are cases where we must and WPT is
             ignoring that.
   dbaron: There are a bunch of things browsers can automate internally
           so we're not interested in those tests.
   florian: They're necessary to go to REC.
   fantasai: No, this is different.
   fantasai: No one is asking the browsers to do it but it should be
             possible to test the browsers.
   dbaron: We're not interested in running them.
   dbaron: I think their existence is mostly a waste of time.
   florian: But how do we go to REC if we don't have tests for things
            that cannot be automated.
   dbaron: You try and find ways to automate them.
   emilio: There's a lot of work going on to automate previously hard
           to automate things.
   florian: I'd like to not rabbit hole.
   gsnedders: As example you can't automate a test to see if the Media
              Query works for a monitor that has P3 colors.
   gsnedders: You can't automate that.

   astearns: One of the problems of fixing the competing systems is we
             can't find someone to pay to fix our system. Will someone
             pay to make WPT better for our impl reports?
   gsnedders: Yes.
   astearns: Has anyone tried?
   florian: Part of the discussion on github was trying to gather our
            needs and I don't think that's concluded.
   gsnedders: We know there are other WG that have used WPT tools to
              take specs to REC. How much would those tools need to
              improve for CSSWG to be happy using them. There will
              probably be more and less painful cases.
   fantasai: Given current situation we need to be able to deal with a
             set of manual tests. WPT handles ref tests but we can't do
             that for manual tests and we depend on those for a number
             of specs.
   gsnedders: But for doing CR we don't need to run them all the time.

   gsnedders: A proposal was for WPT to stop writing test results but
              it assumes a future build won't be different from a
              previous. Current assumes Chrome 1 will be same as Chrome
              60.
   plinss: It'll store a result from each. If there's a pass in a past
           version and fail on the current you can see that but it will
           still pass
   florian: That's sufficient to show it's implementable.
   fantasai: It's a different analysis because different goal.
   gsnedders: WPT looks for interop
   plinss: They have different goals so do different things in
           different ways. It's a different view of the same data.

   florian: For requirements I think a desirable improvement of what we
            have is that currently the manual tests can be run by
            anybody. Some results are bogus though that's not entirely
            useless. If someone adds a result that is different that's
            worthwhile to look at. Storing the things that are known to
            be correct is valuable.
   gsnedders: What groups have done with manual tests is have someone
              run them in a browser and create a file with the results.
   florian: When I create an impl report I run all the tests. But I
            don't want to have to run all the tests just to check if
            it's time to try again. Having the history of knowing
            something has passed before it saves time for me so
            I can just verify at the end.
   florian: We don't have to have that, we've lived without it, but if
            we're re-implementing it's useful.

   fantasai: 2 things I'd like to see, one is to have the manual test
             harness deprioritize ref tests. It should put them at the
             end of the list. And WPT exporting test results in a way
             that the test harness can import.
   plinss: Test harness already orders in the way for most needed to
           exit CR.
   plinss: If we load in the automated results, they'll get
           automatically deprioritized
   gsnedders: If we get it running every 12 hours that's a lot of data
              going into the system. No reason to import that often.
              But if you go through writing modes there's 200 fails.
   fantasai: I think the writing modes test suite is a case we don't
             need to optimize, we just need to be able to deal with it.
   florian: I think we'll write fewer of these tests. First because we
            know and second because we know these tests have problems
            on high DPI screens.
   gsnedders: Currently WPT assumes you're in low DPI.

   rego: Current problem that it has is you'll have to duplicate
         different things and you don't realize that because you'll
         have something break in the build system when something
         changes. If there's a solution for that it's not good that
         things pass in a browser and then it's bad for CSSWG.
   florian: If we start to share a bunch of files should we forbid
            modifying them?
   florian: Now every test folder has it's own files so you know you're
            the only user. If we centralize there's a lot of test
            suites using them.
   gsnedders: Keep in mind the merging of support directories.
   florian: So you will not have files like that?
   gsnedders: They have to be bit to bit identical.
   florian: So if we put it in one place there's nothing to detect. So
            if one test changes and forgets it's shared....
   dbaron: If you're reviewing a patch that changes a support file you
           have to review all the places it touches. That general
           statement that you must review all places that touch that
           file. It should be possible for reviewers to know that
           easily so reviewers can figure it out.
   ChrisL: Other thing you can do is if you attempt to modify the file,
           don't, fork it. But that gives you lots of extra files.
   fantasai: Yeah, fonts files can just be modified in most cases.
   plinss: Yes, but sometimes you're testing for a glyph and the glyph
           isn't there.
   gsnedders: Potentially easier because hopefully this year we can run
              all of WPT on every pr.
   fremy: Will still work but for wrong reasons.
   gsnedders: Totally. Doesn't solve everything but it will show up.

   astearns: One thing I heard mentioned is that we still lack way to
             take WPT results and importing. Is that more or less
             important then other tasks you outlined?
   gsnedders: That relies on knowing what source file each test in the
              build suite comes from.
   astearns: I don't want details on the how. But I've heard many
             people want it so I'm asking if that's most important or
             are there other possible items you outlined that are more
             important.

   gsnedders: One of the big questions is can we move to WPT report and
              away from test harness.
   fremy: Quick thing. As of today WPT.FYI is still completely useless
          for CSS. They still don't use Ahem font on windows so these
          results are useless.
   fantasai: Sounds like getting Ahem resolved on those machines is #1
             problem.
   fremy: That has been open since last TPAC. As long as it's not fixed
          this is useless for CSS.
   <dbaron> We could use @font-face rules when we use Ahem...
   <cbiesinger> @font-face also requires using document.fonts.ready, fyi
   <cbiesinger> (^dbaron)
   <gsnedders> dbaron: the problem is updating all the tests for that
   <dbaron> Mozilla css testsuite importing code for adding @font-face
            rules on import is 
https://searchfox.org/mozilla-central/source/layout/reftests/w3c-css/import-tests.py#243-256,268-274
   <ChrisL> dbaron, nice. Can we get that added to the wpt.fyi build
            system?
   <gsnedders> dbaron: in general we can't rely on the Ahem flag
   <cbiesinger> dbaron: does gecko block onload on webfont loading?
   <gsnedders> cbiesinger: yes
   <cbiesinger> gsnedders: ok. I don't think blink does
   <gsnedders> cbiesinger: it doesn't
   <gsnedders> cbiesinger: https://github.com/w3c/csswg-drafts/issues/1088
   <cbiesinger> gsnedders: so if want to use this for wpt.fyi it would
                need to be smarter, somehow (re ChrisL suggestion)
   <gsnedders> cbiesinger: wptrunner already waits on font loading, FWIW
   <gsnedders> cbiesinger: because there are plenty of other tests that
               use web fonts
   <cbiesinger> ah ok

   florian: How come harness is so important to us and no one wants to
            care? Answer comes from, how many people have recently tried
            to take a spec out of CR? Not a lot. But everyone who does
            needs it.
   gsnedders: I mean, the implication is how much does this group cares
              about leaving CR.
   fantasai: Then it means how much do we care about patent protections...
             those kick in on REC.
   florian: Those that have tried to exit CR care. That's only a few
            people which is why only a few people feel the pain.

   astearns: What do you want out of this discussion?
   gsnedders: High level questions: We've answered can we have static
              safe results saved somewhere and the answer is you want
              to know if we seemingly have all tests passing
   fantasai: I also want to be able to run a lot of manual tests
             without a lot of pain.
   fantasai: It's much easier to click buttons in the test harness then
             trying to take hours to run the tests and then have to
             generate a report and figure out what needs to be fixed in
             the spec.
   gsnedders: Anything apart from manual tests?
   fantasai: Ahem font needs to be installed.
   gsnedders: Yes.
   astearns: Fuzzy matching for ref tests.

   fantasai: Does WPT handle paginated test?
   gsnedders: No. So, those are all manual as well atm.

   florian: afaict WPT doesn't care much about helping with evaluating
            test coverage.
   ChrisL: That is useful about the current because you can add a link
           at the top of the document to show you your coverage.

   TabAtkins: I'm working on a section in bikeshed to include tests.
              This lets you see what's tested in the source. And
              bikeshed can warn you about tests.
   astearns: And it's bi-directional where as you move you note which
             tests need to be updated.
   fantasai: Goal of this... we have tests linking to sections but it's
             not very granular. For specs with small sections it's good
             enough, but for complex specs you want... to understand
             coverage you need to annotate spec paragraph by paragraph
             and you might need notes and this test is for this section
             and you want to be able to write an annotated spec as a
             test report
   fantasai: To make that possible without having to keep a separate
             spec copy the idea was to include those annotations in
             bikeshed so you can include them for the test coverage
             report and exclude when publishing spec
   florian: I don't have a problem with that, but only if it's not used
            to ignore annotations.
   fantasai: I think this will make it trivial to ensure you have
             annotations.
   TabAtkins: In so far as tests have annotations I want to make sure
              you can include them.
   ChrisL: Will that cope with tests changing?
   TabAtkins: I dunno. I can probably make it re-runnable. We'll see.
   florian: You probably need to.
   TabAtkins: Once you start and you add a new test bikshed will warn
              you hey there's a test not in your spec.
   TabAtkins: Point of this is not to produce a 2-way it's to help with
              import.
   florian: Once you import and someone makes changes what happens.
   TabAtkins: bikeshed will note that there's a bunch of different
              tests.
   florian: In the future bikeshed will have a flag to let you import
            and it will check for differences?
   TabAtkins: Yes general. Check is separate from import.
   florian: Okay. I guess. Yeah. Something similar to what it does for
            can I use.
   TabAtkins: Yeah, something like that.
   florian: That does release some pressure from test harness.
   fantasai: I like that I can search for tests tagged against a
             section, but that's trivial to do with grep if even test
             harness isn't there (if metadata is there)

   fantasai: I think the collation of test results is important.
   <fantasai> and being able to run all the manual tests against a
              particular spec or section of a spec

   rego: Will WPT be open to add support to WPT FYI to run manual tests?
   gsnedders: What someone mentioned, I think Philip J├Ągenstedt, was
              that...It hasn't been discussed. Some people aren't
              opposed to storing the tests in this revision run against
              this browser got this result.
   florian: That's tore but how to enter? I wish this not to be me
            submitting a PR with a JSON file.
   gsnedders: I would expect that not to be a solution.
   astearns: At this point it's just an idea.
   gsnedders: Yeah.
   florian: Seems like this is more likely to materialize then paying
            for the harness work.

   astearns: I'm hearing we have all sorts of ideas, but no commitment
             to work on anything except TabAtkins and bikeshed.
   TabAtkins: Not too slow of work.
   plinss: How are you getting data on tests?
   TabAtkins: Eventually through WPT.FYI's API.

   florian: Another missing thing from WPT is differentiating the tests
            with may and should flag and the rest.
   dbaron: Especially for tests with a may.
   florian: Should are equally important to know.
   dbaron: May are other "you really shouldn't fail this"
   florian: May is sometimes there to allow you to do something bad.
   fantasai: When you write tests you're supposed to pass when you do
             the thing we want to do.
   ChrisL: Or you can write tests that have multiple pass options.
   dbaron: I've seen tests testing against the thing we don't want you
           to do.
   [many unhappy people]
   fantasai: I think submit a PR for removing that test.
   astearns: Can we close this?

CSSWG specs need usable test suite docs
---------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/2438

   fantasai: I 100% agree testing documentation sucks.
   tantek: Problem highlighted is our testing documentation makes it
           very hard for community of people helping us to grow.

   florian: Shouldn't we delete what's in the wiki and point to WPT's
            documentation and if that's insufficient file issues on
            that?
   gsnedders: The build system and test harness should be there.
   fantasai: And meta
   florian: Meta is on WPT.

   florian: I'd like to propose we delete our test documentation and
            any time we need to reference instructions we point to WPT
            and then we file issues if there's a bug.
   tantek: Their docs are completely opaque. I disagree. Here's a
           bunch of links that look identical and if you guess right
           after 3 levels you'll find information.
   florian: The wiki is old information, though.
   tantek: First thing I did is go through the wiki and it has
           rudimentary information on how to do it. If you want to help
           with the problem look at stuff.
   florian: I added a bunch of documentation to WPT.org for stuff we
            had.
   tantek: WPT is opaque.
   florian: The information is mostly complete, discoverability is
            horrendous.

   gsnedders: My objection to putting everything on css wiki... WPT
              documentation is bad and the solution here isn't to write
              new documentation, it's to fix it.
   florian: It's not bad for containing information.
   gsnedders: It's hard to navigate and not at the level for either
              browser vendors or new people. Too verbose for browser
              vendors.
   gsnedders: And again it doesn't start basic enough level for new ppl.
   TabAtkins: florian do you remember how often browser vendors look at
              old WD instead of what's in TR? They'll look at wrong
              things.

   tantek: You start at the spec, it links to the test suite, you try a
           test and it fails. Look at test and it fails. Now you want
           to fix it. Now you're in trouble.
   tantek: If we fix that on csswg wiki that's a huge improvement.
           We're not going to move all documentation here. But we want
           an avg web dev to have a chance.
   gsnedders: Some of the problem may be test harness links to Shepherd
              for bugs. Where should we file bug on the test harness?
   [silence]

   tantek: First scenario is make it easy to report bugs on test.
           Second thing we should make easy is for people to contribute
           tests. Both of those can be incrementally fixed without
           fixing everything.
   fantasai: I've sent probably 7 people a list of links to Moz
             documentation from 2001 which was very straight forward.
             That's the kind documentation we need. It's clear these
             are real people, they need help to make the Web better,
             and here's how.
   tantek: Can you link to those in this issue?
   fantasai: Yeah.

   tantek: We won't solve it here but I'm hoping we can align on
           objectives.
   florian: Rephrasing my position, I don't mean delete everything from
            the wiki. Do not attempt to duplicate what's in WPT in the
            wiki. Additional guidance to help people find the things or
            help people know what to do.
   tantek: Agree with the caveat that undiscoverable or unlinkable is
           the equivalent to not there.
   florian: Yeah.

   florian: WPT.org needs a search button too. That would be useful.
   astearns: File an issue for that?
   florian: Yes.
   florian: WPT.org is done with Jekyll, right?
   gsnedders: Yes.
   florian: There are plug ins for search.
   [talking about how to add search]
   astearns: Anything more?

CSS 2.x
=======

Naming of revision of CSS 2.1
-----------------------------
   github: https://github.com/w3c/csswg-drafts/issues/2008

   tantek: Now that we have an agreed workflow for 2.1, gsnedders
           opened this last Nov as to what do we call it. 2.2 or 2.1
           nth edition. There has been some back and forth. I can argue
           for either. Wrote a summary at the bottom.
   tantek: Based on that my proposal is go with CSS 2.2 nth edition.
   tantek: Major reason is 2.1 has been stable and unchanging for so
           many years that adding editions would not indicate we're
           applying these changes. We've also already published 2.2 WD
           so it'll always be there.

   fantasai: We can make the permalink repoint. We've done that before.
   florian: Not sure we have. I think we have both links serve same
            content.
   tantek: Regardless, we published and it's out there.

   tantek: So 2.2 nth edition. 2.2 2nd edition 2.2 3rd edition etc.
   florian: Point is URL stays the same.
   fantasai: Should always be CSS 2.
   fantasai: I think it's important to make sure it replaces this
   florian: Unless you put in a dated URL any should link you to the
            latest 2.2

   <fantasai> Need to replace https://www.w3.org/TR/CSS21/
   fantasai: A lot of links point into that. Whatever we publish should
             replace that.
   tantek: Agree.
   <dbaron> you mean like https://www.w3.org/TR/REC-CSS2/ gives me the
            1998 REC... ?
   <dbaron> (I thought we fixed that at some point...)

   fantasai: I think having CSS2.1 point to CSS 2.2 is weird but if you
             want to.
   gsnedders: And we need to make sure that whoever approves is okay
              that /css21 points to /css22.
   dbaron: Sounds like the sort of thing we can convince plh to do.

   astearns: Do we change editions for only substantive changes?
   fantasai: Depends on process.
   tantek: Process doesn't say.
   gsnedders: I think every new ER has a new number.
   astearns: Okay.
   tantek: That's what I propose
   florian: Not a new short name
   fantasai: Short name stays CSS2

   astearns: Obj to the naming scheme proposed at bottom of
             https://github.com/w3c/csswg-drafts/issues/2008 ?
   astearns: [reads]
   [
       PROPOSED: Use CSS 2.2 for the next REC track revision of CSS
       2.1, and then append "2nd edition", "3rd edition" etc. for
       subsequent Edited Recommendations.
   ]
   gsnedders: How many people favored 22 over 21 that you spoke to.
   tantek: That was gathering, a lot of people weren't very strong.
   florian: I'm okay with either.
   astearns: Shall we resolve?

   RESOLVED: Use the naming scheme proposed at bottom of
             https://github.com/w3c/csswg-drafts/issues/2008#issuecomment-380828317

Links
-----

   <dbaron> Proposal: Ask the team to make https://www.w3.org/TR/
            REC-CSS2 redirect to https://www.w3.org/TR/CSS2
   dbaron: I'd like the team to accept this ^
   astearns: Proposed is Ask the team to make https://www.w3.org/TR/
             REC-CSS2 redirect to https://www.w3.org/TR/CSS2

   RESOLVED: Ask the team to make https://www.w3.org/TR/REC-CSS2
             redirect to https://www.w3.org/TR/CSS2

   astearns: That's time

Meeting closed.
Received on Tuesday, 29 May 2018 20:04:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 29 May 2018 20:04:11 UTC