Re: [PNG] Feb 21, 2022 meeting topics

My regrets for that meeting, sadly; I'm moving house and there were 
limited time slots for when the movers could come.

On TPAC, currently W3C has suspended all travel for technical staff; 
exceptions need to be justified on a case by case basis.

I'm generally comfortable with remote meetings, but could potentially 
attend a face to face one. The worst possible option in my experience is 
the hybrid meeting, where a small group of f2f participants are 
continually asked "please speak into the mic" and "what was that, sorry" 
etc by the remote participants who are missing the visual and non-verbal 
cues from direct participation.

On tRNS, I believe we should continue to follow the Internet principle 
of "be strict in what you send, permissive in what you receive". So an 
encoder SHOULD set these bits to zero and a decoder MUST ignore these 
unused bits.

If the group agrees with that proposal, we wold need to open an issue on 
Firefox to get them to change their behavior.

(Just copied that into https://github.com/w3c/PNG-spec/issues/29 to keep 
the discussion in one place)

On 2022-02-19 06:24, Chris Blume (ProgramMax) wrote:
> Hello everyone,
> For our Feb 21, 2022 meeting let's discuss:
>
>   * TPAC 2022 planning has begun. TPAC is W3C's yearly meetup. The
>     last two years, TPAC has been remote. W3C is considering a hybrid
>     approach this year (in-person with strong support for remote
>     participants).
>
>     TPAC 2022 will be in Vancouver, Sep 12th-16th.
>
>     As part of TPAC 2022 planning, W3C wants Chairs to gather thoughts
>     from their groups:
>       o How likely are you to attend?
>       o What safety concerns should be considered? Already noted are:
>           + new COVID variants
>           + quarantine restrictions
>           + 7-day average COVID trends
>
>   * tRNS ambiguity (GitHub issue #29)
>     <https://github.com/w3c/PNG-spec/issues/29> [1] -- The existing
>     spec says unused bits are 0. I guess this was intended to inform
>     encoders to set them to zero. But for a decoder, any bits being
>     set to 1 means this image does not conform to the spec.
>
>     There is ambiguity in whether the bits MUST be 0 (and what to do
>     if they aren't) or if they can be any value and a decoder should
>     ignore the unused bits.
>
>     Unfortunately, different decoders have taken different
>     interpretations. libpng (and apps that use it, such as
>     Chromium-based browsers) choose to ignore the unused bits. Firefox
>     sees the chunk as being invalid and ignores the whole chunk. So if
>     we choose to clarify the ambiguity, we'll break some wide-spread
>     implementation. Nevertheless, I think it would be good for the PNG
>     spec to be clear instead of ambiguous.
>
> Thank you. See you at the meeting.
> - Chris Blume
>
> [1] https://github.com/w3c/PNG-spec/issues/29

-- 
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media