- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 29 May 2018 16:03:23 -0400
- To: "www-style@w3.org" <www-style@w3.org>
=========================================
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