<scribe> ScribeNick: dael

astearns: As usual we'll wait for people to join in
... I think we have enough to start
... Any changes to the agenda?

Rossen: I wanted to add an item.
... I wanted to give a summary of the year we had
... Here's some numbers
... We could resolve 176 items not counting the ones we discussed without resolution
... Published 18WD, 9 CRs, 2 RECs. This is really amazing. I'm inspired by everything we've done
... I get praise for the way the WG works and it's amazing. We've done 10 REC this decade and 2 were this year. Inspired by this year and looking forward to 2020

smfr: Do you have a decade summary?

Rossen: I couldn't get the decade for the WD and CR. /tr didn't go back far enough
... It would be fun to do as a summary of the decade; especially for those of you that have been here for the entire decare

2020 Summer Meeting

astearns: Can we lock down dates
... Two dates provided. One in July which was better for spacing, June which was better for Mozilla
... Does anyone from Google know if both dates are available?
... Lacking that, are there Mozilla people that very much prefer June dates?

<dbaron> btw, did Alan's view of the thread include the October messages: https://www.w3.org/mid/c8aababf-85c6-6406-8a32-e5c2a1e77784@inkedblade.net and https://www.w3.org/mid/4e5672f3-475e-42ce-93ed-be4dff028160@www.fastmail.com?

jensimmons: Can you mention the dates again?

astearns: I believe June 22-25 or...not sure July dates

plinss: I have week of 20-24 July
... And the following week of August

dbaron: Thread was 22-24 June or 20-22 July

astearns: Right. And dbaron you thought June was easier for Moz?

dbaron: Yes but heycam|away was okay either way and has longest trip

astearns: Lacking strong opinions on the call let's go to the list

CSS UI L4 WD

florian: Been under low pace mantainence, but we're 2 years from last WD. One section with significant changes is on appearance property. Thanks to zcorpan it's more fleshed out and feels like could be impl
... Noticed how out of date it is I thought we should publish

astearns: Objections to new WD of CSSUI L4?

RESOLUTION: Publish a new WD of CSSUI L4

astearns: Since this is a regular WD and I assume all changes came from resolutions I think you could have published without resolution

florian: I think some changes didn't have a formal resolution

fantasai: You can publish with editorial

astearns: I have not checked the draft but an up to date changes section would be useful

florian: I'll look

[css-fonts] limit local fonts to those selected by users in browser settings (or other browser chrome)

github: https://github.com/w3c/csswg-drafts/issues/4497

<pes> (howdy :) )

pes: Right now font fingerprinting by most measurements is highest entropy. Would like to address and solve
... Needs standards level b/c will require some degree of PR or author notification or browser changes so everyone moves in tandem.
... Couple proposals but in general need to limit types of fonts websites can tickle are those that are useful for users
... Most recent prop is let's figure out default font OSs, union those, websites can access those. If users want to opt in other fonts you should be able to do those with a prompt from the browser

astearns: One things about privacy discussions and opting in to exposing information is the concern about messaging to the user what they are doing. Is there possible a way to opt in to that giving a good story to the user what they're doing?

pes: Two thoughts; if users are doing this they already know somewhat what they want. Convaying some of the functionality without the meaning is easy. If there's the desire to convey why I think that's easy to describe. I could put up text. People usually follow defaults. From examples in GH is moderatly expert users and that's something two steps out of the mean
... I think it falls nicely where browsers are doing things users don't expect and taking it from default path is a win and allowing users intentionally installing fonts is doable

myles: A couple points. 1) Fingerprinting based on set of available fonts is real bad and we philosophically should try to solve.
... 2) there's a problem here issue is trying to address which isn't stated yet. Safari already disallows user installed fonts so we're similar to prop but don't ask user to allow. There's a problem with that where for some lesser used scripts there may be no system font that can support so can have unreadable pages
... This proposal has affordances to solve that where for those scripts users can opt in. That's good. But there's a cost which is throwing additional prompts to user they may not understand and adding friction at OS install time is something the entire company tries to minimize
... Realistically us adding a screen at OS install time is difficult to do and generally not something we're comportable with

astearns: Clearification on scripts not supported- is Safari not rendering some web pages it might otherwise be able to with the script?

myles: Yes. Logic is it's a better situration for them to have to use web fonts b/c it's better to require that then for every user to install a font with a name b/c less websites then web users

jensimmons: I was never aware Safari doesn't allow user installed fonts. And I've never heard a web diesgner talk about that. I agree it's complicated for users to understand a browser setting. That's the kind of thing webdev can't count on. It may be something to think about but doesn't seem core to solving
... Looking at last part of GH issues I see intersection of fonts vs union. Union is when you have all the fonts on both even if they're only on some OS. Some people are saying to do intersection where Arial is on so it's allowed but Aveneer is only on MAc so no allowed. Intersection would be a massive problem. I don't think it's a problem to limit to what's shipped in OSs
... If we try to limit to intersection it will break millions of websites. I don't think people are counting on some people might have fancypants font. But they are counting on some people have Aventeer but others Roboto

pes: Clarifying the proposal: Uniion of all fonts shipped by default by all OSs that an be resonably compliled. And the ones fed to the website are intersection of installed and system fonts. That is one option on Android, another on OSX, etc.
... Proposal isn't to say at install time let these fonts be accessed. Proposal is for small set of users who expect these fonts to be available b/c region of website allow user to go into advanced and have a drop down of additional fonts. Expectation is relatively few people do this, but communities that needs this alreayd install extra font so this additional step isn't infeasible

<Zakim> chris, you wanted to say have seen exactly those notices on web pages

chris: I wanted to say contrary to jensimmons not seeing it done, I have seen this on some sites, particuarly when Indian was worse. South Indian it's common to install locally used fonts. It could be there's a pack that installs a bunch of fonts. I don't want to break web experience for those that have been using it successfully

<jensimmons> +1

astearns: Is there a way to survey scripts and say these aren't by default but everybody in that region installs these fonts

chris: It would be a valuable addition

<Zakim> myles, you wanted to ask browser developers on macOS if they want OS-level support to allow for the behavior that Safari has about user-installed fonts

myles: one other small things. Mechanically ability to discern between fonts is not a public API on OS. I would love to hear if any browser programmers wanted this exposed; I'd love to know that

<pes> https://github.com/Valve/fingerprintjs2/blob/master/fingerprint2.js#L557 <— example of fingerprinting via fonts

florian: I don't see TabAtkins on and I'd like to bring up a point from him. this seems less drastic then others discussed so down side not that bad. If we do the intersection of what's installed it has a fair bit of variability. Besides font fingerprint there are other means. The question to ask is does it actually help. If we don't reduce it enough then we haven't achieved anything even though we decreased it
... Downside isn't that bad if we include the language specific common fonts, but there still is some cost. Are we paying it for something or do we not reduce your uniqueness enough

<jensimmons> There are many other ways of fingerprinting, but many of us out here are knocking them out one by one. I believe we should also do our best to close such security flaws. (in response to florian's comment)

<pes> +1000 for what is being said right now.

<jensimmons> +1 from me as well

plinss: Let's not let hte perfect be the enemy of the good. There's a lot of fingerprinting surface and we need to make small steps in every regard. We have to take small steps where we can and get a cumulative effect where we can

florian: TabAtkins point is he doesn't think we can ever get there

<astearns> yep, if it makes fingerprinting at all harder, it's progress

plinss: If we never try we won't get there

<Zakim> fantasai, you wanted to ask about impact on linguistic minority populations

myles: I don't doubt we can get there so we have one vote on either side so worth discussing

<Zakim> dbaron, you wanted to talk about both exposing Mac OS API and about being willing to expose OS differences rather than intersection or union

dbaron: Two comments. myles asked about the API on Mac. it's not something we planned to work on but if we do get to work on this it would be useful. Lack might cause us to have to do a work around. If it's exposed it would make this sort of thing more practical. But we don't have a concrete plan to use it

<pes> +q

dbaron: Other thing is that there's been a bunch of discussion about intersection and union of fonts across OSs. I'm not convinced we want either. There's an argument that we want to allow vary between OSs. There's a set of fingerpritnable information we can hope to obscure but there's bits of entropy we can be okay giving up on and one of those is if a user is on windows or mac.

<myles> dbaron++

dbaron: Either way of addressing it makes the solution worse. Intersection limits designers, Union is a bunch of fingerprinting exposed if users install fonts that are default on a different OS.

pes: Point about fingerprinting nihilism. Ping and those in privacy community are trying to address it in many ways. You chip away as you can. Nature of problem means different wins benefit different people are different times.

<myles> pes++

pes: Chpping off entropy bits is valuable. Different fingerprint endpoints yeild differently as well. So adding noise is an option in some places, but fonts is not one of those places. Figuring out how to reduce problem to a subset seems valuable here. I think every time we take a slice of the problem we're benefiting some people. We're not throwing coins in a well

<plinss> +1 to pes

fantasai: Two points. 1) If we're going to do this we should document which fonts re allowed on which OSs so all browsers can align with interop. If we're going to do this we should start a registry of allowed fonts so authors and browser vendors can figure it out

astearns: To that I think yes and no. There should be a rule for what's in and maintian it, but have the list generated from rules. If we do a union the set will only ever grow

fantasai: Rule in fonts spec, document of fonts that conform to the rule. In an OS API is nice, but and author won't find it easily

astearns: We aren't saying browsers restricted to this for all time, we're saying here's the set we're aware of and here's the rule to add a new font

myles: There's a bunch of websites that list the fonts. Do we need to maintain if it's out there?

AmeliaBR: Not in reliable up to date fashion

myles: Will ours be?

dbaron: Need something that reflects worldwide usage. Some of that will need to be us.

fantasai: I don't want it in fonts spec. A note or a W3C regitry that's easily maintained and doesn't need our intervention.
... 2) I want to emphasize we need to address impact on minority language population and limiting to default fonts won't cut it. Need to not harm those communities. You can't use web fonts for things like this. Places with minority language are also where downloads are slower and more costly. need to make sure we address that head on

<pes> +q

astearns: Other points on this topic?

<jensimmons> +1 to everything fantasai just said. It would be incredibly helpful to Authors to have such a list.

pes: I'd like to know how Ping or I personally can be most useful to make sure a solution gets into the next part of the spec and get this solved

<pes> i can promise to do that :)

astearns: I think being active on GH issues that are open and reviewing spec text is most helpful. Anyone else can chime in?

fantasai: Are we resolving to do this and if yes exactly what. If not, when do we follow up?

<dbaron> I think we're a decent distance away from converging on a particular thing to add to the spec.

astearns: I was thinking to draft a solution based on GH thread. I'm not hearing objections to trying to solve this. Coming up with something to put into Fonts spec to limit fonts available to web pages

<pes> +q

AmeliaBR: Have text saying browsers may limit what fonts are exposed. Is the agreement at this point to increase the normative standard of that or be more specific abou which you might want to limit or be specific about which fonts are safe?
... Have it defined tht if a font meets these criterias the browser should make it available and may block access to all others

<pes> -q

astearns: It would be yes on your first two. Increase to a must requirements and more concretely define the restriction. But we're not trying to come up with list of web safe fonts, we're defining what browser should make available in terms of locally installed fonts.
... Registry we have won't have all safe, but might be available

AmeliaBR: Using safe from privacy PoV not author guarantee

astearns: Yeah. Like dbaron said in IRC we don't have a thing for the spec yet. Just an intent to solve the problem

myles: One point, I don't think can make a must b/c involves non-CSS pieces of browser.

<fantasai> +1 to myles, this would have to be a SHOULD

<pes> +q

astearns: Must would be font matching algo. Not about browser that might make it less restricitve

<gsnedders> do some OSes still conditionally install fonts based on locale? what should the behaviour be then?

fantasai: Should still be a should. There's CSS UAs that don't want to limited in this way. Like a PDF renderer which is trying to print local documents. This will have to be a should.
... Browsers will probably follow b/c it makes sense to them

chris: Agree it should be a should for that reason. They might have to opt in but we shouldn't block it.

pes: In general a should doesn't mean too much when doing privacy review. We're looking to see if a browser properly implements will they be protected. Point taken where there are places where privacy doesn't apply and those should be carefully detailed out.
... The case discussed where needs to be a way to opt in is handled in GH issue

<fantasai> RFC2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there

<fantasai> may exist valid reasons in particular circumstances to ignore a

<fantasai> particular item, but the full implications must be understood and

<fantasai> carefully weighed before choosing a different course.

pes: I've not written specs but I know in many places functionality is described that hooks into browser chrome so might consider examples like that

fantasai: I want to point out a couple things. One is we as a WG don't know all UAs that exist or will exist and we shouldn't make a UA non-conformant just b/c satisifes a non-browser use case.
... Technical definition of should is [reads]
... I think that's appropriate in this case

<chris> +1 to the RFC2119 definition

astearns: I think we should go back to GH and hammer out exact proposal and level of requirements. I think there's quite a bit of work before there's something to put in spec, but we should get to that. Maybe checkpoint in a month

<dbaron> "a month" is the face-to-face, btw

AmeliaBR: Sample spec text drafts would be helpful so we can start comparing

astearns: dbaron reminds me we have the F2F to hammer out the last details and get it into spec

chris: Sounds good way forward.

<pes> (terrific :) )

chris: pes you should keep watching issue and we update EDs daily so you can see evolution of text

astearns: Anything else on this?
... Thanks everyone

[css-lists] How should spaces be treated in markers?

github: https://github.com/w3c/csswg-drafts/issues/4448

<pes> (im going to jump off the call, thank you for the time, very encouraged by the conversation. I’m looking forwarwd to working with you all to solve the problem!)

oriol: Revisiting a resolution we had. I said that browsers seemingly do when you have an outside marker that's blockified and we made it explicit in the resolution so that if they don't have whitespace then trailing spaces are reserved
... I had been confused by internal termonology and in Chromium they are inline blocks. Outside markers generate a block container and that's what matters. If we want to reflect reality maybe should weaken resolution. Say they should generate block containers and then leave it to impl if it's block or inline level

Rossen_: This is same behavior we have in EdgeHTML so I support your proposal

<fantasai> wfm

astearns: Proposal is modify previous resolution? I see point 3 in previous resolution that outside marker box has display value blockfied.

oriol: It's generates block container not blockifies. It could be an inline block containers.

fantasai: I think we might clarify outside display type is undefined?

<fantasai> https://drafts.csswg.org/css-text-4/#white-space-trim might also be interesting

Rossen_: Could be inline. Did that when we impl outside markers the first time. In order to achieve good baseline alignment for list items that best way to model this was to wrap the list item markets in anon inline blocks with appropriate offset and deal with them.
... Undefined or inline. Not sure if inline will make a difference

fantasai: Markers have a particular interaction with positioning and line positioned to. When we decide they might have their own display:outside value. I'm happy to have it undefined.
... Haven't figured out the model

Rossen_: I don't want display:undefined

fantasai: We can call it inline-block for now so gCS returns consistently across UAs. Not sure if that matters

oriol: FF does blockify into a block box so it seems behavior is different in impl

dbaron: I don't think difference is a big deal for us but should ask Mats

Rossen_: Going back to the proposed resolution I think the understanding is well defined

<fantasai> I think the two options we have going forward is either an outer display value of 'marker' or an outer display value of 'inline' and a 'position' value of 'marker' ... or something like that.

astearns: Prop: An outside marker box does not have its display value blockified, it generates a block container
... Correct?

oriol: Should we cover what FF does?
... You said it's not blockfied, but in FF it is. Maybe should say it may be blockfied

astearns: Yes, sorry. Previous was it has its display value blockified and we're not going to require that. Will require it generates a block container.

<Rossen_> sgtm

astearns: Then can figure out outside container later
... Object to reverse previous blockification requirement and require generating a block container

RESOLUTION: reverse previous blockification requirement and require generating a block container

oriol: Whitespaces; want to preserve by default and resolved to do this to assign whitespace value in user agent origin. Then how to handle new lines. In SVG there way a value for this- should we add to CSS or use Whitespace:pre

fantasai: We say the value is pre for now and UA may transform to spaces and we can try and figure out what to do in the future

astearns: Reasonable

<Rossen_> wfm

astearns: Concerns about UA stylesheet uses pre as the value and let borwsers opt into processing new lines?

florian: Compat with browsers inside case? Or outside only?

oriol: Chromium outside markers get whitespace:pre but inside inherits. In legacy spaces were preserved. In FF if the content property is normal then spaces are preserved like pre but if you spec something other than normal it uses whitespace inherited from list. It's probably compat b/c FF and legacy chromium preserve

fantasai: We should reduce magic switching and make it a simple control

florian: Would not nec be magic could have pseudo class, but not convinced we need to

fantasai: No, let's keep it simple.
... just make it pre. How many people are doing a custom string? Almost nobody.

astearns: florian do you object?

florian: No, just wanted to get it out there

astearns: Obj to use pre as the value in UA stylesheet with text about poss processing new lines?

RESOLUTION: use pre as the value in UA stylesheet with text about possibly processing new lines

end

astearns: That's it for the year and the decade. Talk to you all next year

fantasai: Can we get some FPWD published next year?

Rossen_: We can and should

astearns: We've got next decade for that

<astearns> trackbot, end meeting

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/I would love it if a browser programmer wanted this exposed/I would love to hear if any browser programmers wanted this exposed/
Succeeded: s/returns/returns consistently across UAs/
Default Present: dael, rachelandrew, oriol, jensimmons, teleject, stantonm, smfr, cbiesinger, plinss, AmeliaBR, dbaron, Pete, Snyder, svoisen, fantasai, myles, Rossen_, leaverou, chris, dauwhe, drousso, bkardell_
Present: dael rachelandrew oriol jensimmons teleject stantonm smfr cbiesinger plinss AmeliaBR dbaron Pete Snyder svoisen fantasai myles Rossen_ leaverou chris dauwhe drousso bkardell_
Found ScribeNick: dael
Inferring Scribes: dael

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 18 Dec 2019
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)