Re: BFO Position Paper

Hi,

I won't be in Prague either, but I'd like to make a few comments about this suggested list of action items from Mike.

> On Feb 9, 2020, at 4:39, Mike Bremford <mike@bfo.com> wrote:
> 
> 1. I'd like to propose a "print"  label for issues filed against the CSSWG issue list. This would make it easier for those with a print focus to find issues they're interested in. This is a quick and easy one - if there's general agreement I can try and get this set up, and tag as many as I can find that apply. (should it be "paged"? Something else?)

I support this, but we need to be sure about what we want. "paged" and "print" overlap a lot. Just to take one example, questions about CMYK are "print" but they're not "paged". Since this filter is meant to be of use to people who want to look at only a subset of the activity of the WG, let's not cast it too wide.

Relatedly, there's also quite a few topics which tend to be of interest to this crowd, which are neither really "print" not "paged", but rather around the more general topic of high quality typography. I suspect this is too broad to try and cover with this kind of filter, and that it would dilute the value of a "paged" filter, but this is worth thinking about.

> 2. We've started rolling our in-house tests into a form that makes them suitable for inclusion in the WPT tests, and plan on contributing a lot more over the next few months (Dave, you will be seeing some pull requests coming your way). When we get further down our track we'll publish our results, and get them integrated with the results at tests.csswg.org <http://tests.csswg.org/>. It would be great to see other vendors do the same. Many of the issues we've found with the specifications have come from creating tests in this way.

I strongly support this (especially when combined with the next point). From a spec writer's point of view, it's very useful to be able to tell what implementations are actually doing. Testing manually from browsers is easy, and getting automated results for them from wpt is even easier. For print formatters, less so. But that can often make a difference to how we resolve on specifications. See https://github.com/w3c/csswg-drafts/issues/4036 for an example where knowing what the print formatters do changed the decision the CSSWG made.

> 3. Where issues are filed, we'll test against our software and respond with our results. We have been testing our own software and Prince, which explicitly has an evaluation license for this purpose. I'd be happy to test with Antenna House and RealObjects products too, but I'm not clear their license would allow this given we're developing a product in the same space. So it would be great to see others submitting test results too. Without a consensus from the main print vendors on what is "correct" behaviour, or at least current behaviour, we're not going to move forward.

Yes, a clear testing license would encourage using print formatters when judging the maturity of specifications. See the previous point for why.

> 4. There are some "low hanging fruit" we might look at - for example, Prince, Antenna House, RealObjects and ourselves all have a "text-replace" property, which appear to function identically but all use different prefixes. I'm aware this was dropped from a previous version of css-text - but with three shipping implementations, if it's being used and is considered effective, then should we consider suggesting its return to the spec? I don't know. But if interoperability is the goal, this sort of thing is an easy place to start. Attempting to define large areas of new functionality like page floats without multiple vendor buy in isn't going to work, so testing the collaboration process on smaller features like this one might not be a bad idea.

Yes. Not all things that are acceptable to print formatters will be OK in browsers, due to different performance requirements. But given valid use cases, if some solution is not acceptable to browsers, we should be looking for a different solution that is, so that we can have the same thing across the board. And proposing to standardise things print formatters have is a good way to find out if it is acceptable to browsers or not.

—Florian