Re: Objectives?

> On 1Nov 2022, at 2:46, Dave Pawson <dave.pawson@gmail.com> wrote:
> 
> On Mon, 31 Oct 2022 at 15:23, Liam R. E. Quin <liam@fromoldbooks.org> wrote:
>> 
>> On Mon, 2022-10-31 at 13:33 +0000, Dave Pawson wrote:
>>> How much of a moving target is the print element of CSS?
>>> I.e. to use as a target for objectives?
>>> Anyone familiar over time?
>> 
>> It's very incomplete, at best working draft with incomplete proposals
>> partly in the specs, but as far as i can tell it's barely moved forward
>> in the past decade.
>> 
>> It might be that a useful thing a CG could do would be to take some of
>> those proposals and some of the vendor extensions, and get them spec-
>> ready, and show implementations, whether in browsers or elsewhere.
> 
> Positive, tks Liam


My impression is that a lack of specs regarding print&CSS is not what is holding us back.

There have been specs. There have been proposals for extensions or tweaks of the existing ones, and for more specs. But those specs tend to fail to move forward after that, due insufficient (perceived?) interest from implementors and/or users.

Writing some amount of specs ahead of implementations to show the way forward is a good thing. But writing too much when implementations aren’t following is likely to turn from anticipation sci-fi into outright fantasy :)

I don’t know how to break the chicken&egg problem of having not enough users be cause there nothing to be used vs having not enough implementor interest because there’s no user. But having tried to crack it at the spec level before, I now think that this is not where the solution is.

One way or another, we have to make enough people care.

Possibly, Dave’s suggestion of an equivalent of the css zen garden for print may be a good tool in that direction.

Sometimes, I think if we can just “trick” browser into implementing just enough about fragmentation that people start using it on the web, that’ll open the floodgates of requests for more fragmentation related features. I have a could of Trojan horses I keep dreaming about to get there, one of which is to get multicol to be able to fragment into multiple rows of columns when overflowing, so that it’s finally usable on screen for non trivial cases. But that’s another exercise in spec writing ahead of implementor interest, and while as a spec writer that’s tempting, I am not sure that’s actually effective.


>> Getting W3C to accept non-browser implementations has proved
>> problematic in the past, and is one reason why some of the work has
>> stalled.

I am not sure that is true in the case of the CSS-WG. While print implementations aren’t the main focus of interest, we do try to remember them when relevant, and I don’t believe that there’s been push back against getting a CSS spec to REC because the only thing we were missing was implementations, while a non-browser implementation was around.

This may have happened with other WGs. This definitely happens in the WHATWG, but I don’t think it’s a key factor in the CSS-WG.

However, if there’s very little non-browser implementer represented in the room, that does make it hard to make progress. Not because other people refuse to work on it, but because they have their own priorities, and we mainly work on what the people who’re there want to work on.

(I think the number of css-wg members who are personally interested in print and fragmentation exceeds what you’d think based on who their employers are, that does give some air time to print/fragmentation related issue. But there’s a limit to what can be done without more active engagement).

—Florian