- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Dec 2019 20:01:08 -0500
- To: 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. ========================================= Summer 2020 Meeting ------------------- - Dates will be finalized on the private list. CSS UI L4 --------- - RESOLVED: Publish a new WD of CSS UI L4 CSS Fonts --------- - The group discussed limiting the exposed fonts in order to limit fingerprinting vectors (Issue #4497: Limit local fonts to those selected by users in browser settings (or other browser chrome)) and was interested in creating possible spec text. - Even though there are plenty of other vectors to fingerprint users, a majority of the group felt that it was worth the effort to chip away at the problem. - There were different options as to what fonts to use; an intersection of OS fonts, a union of them, or somewhere in the middle where we accept that you'll still be able to know basic information like OS from the font list. - Though the spec shouldn't list exact fonts, there was a desire to have an accompanying note-like document that does say fonts which are known to conform to the spec text. - In the current GitHub there is a proposed way to still allow users to install and allow a font and that use case is important to support as this is a common need for users that consume content in a minority language. - Though there's a desire to ensure this text strongly protects users of browsers it may still need to be a SHOULD level requirement as there are other use cases where fingerprinting isn't a concern such as PDF renderers CSS Lists --------- - RESOLVED: Reverse previous blockification requirement and require generating a block container (Issue #4448: How should spaces be treated in markers?) - RESOLVED: Use white-space:pre as the value in UA stylesheet with text about possibly processing new lines (Issue #4448) ===== FULL MINUTES BELOW ======= Agenda: https://lists.w3.org/Archives/Public/www-style/2019Dec/0014.html Present: Rachel Andrew Rossen Atanassov David Baron Amelia Bellamy-Royds Christian Biesinger Oriol Brufau Dave Cramer Elika Eteman Simon Fraser Dael Jackson Brian Kardell Chris Lilley Peter Linss Stanton Marcum Myles Maxfield Devin Rousso Christopher Schmitt Pete Snyder Jen Simmons Alan Stearns Lea Verou Sean Voisen Regrets: François Remy Scribe: dael Year in Review ============== astearns: I think we have enough to start astearns: Any changes to the agenda? Rossen: I wanted to add an item. Rossen: I wanted to give a summary of the year we had. Rossen: Here's some numbers Rossen: We could resolve 176 items not counting the ones we discussed without resolution Rossen: Published 18 WDs, 9 CRs, 2 RECs. This is really amazing. I'm inspired by everything we've done <florian> yeah us ! Rossen: 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 Rossen: It would be fun to do as a summary of the decade; especially for those of you that have been here for the entire declare 2020 Summer Meeting =================== astearns: Can we lock down dates astearns: Two dates provided. One in July which was better for spacing, June which was better for Mozilla astearns: Does anyone from Google know if both dates are available? astearns: 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 plinss: 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 Mozilla folks? dbaron: Yes but heycam 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 maintenance, 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 florian: Noticed how out of date it is I thought we should publish astearns: Objections to new WD of CSSUI L4? RESOLVED: 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: Right now font fingerprinting by most measurements is highest entropy. Would like to address and solve pes: Needs standards level because will require some degree of PR or author notification or browser changes so everyone moves in tandem. pes: Couple proposals but in general need to limit types of fonts websites can tickle are those that are useful for users pes: Most recent proposal is let's figure out default fonts for 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. Conveying 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 GitHub is moderately expert users and that's something two steps out of the mean pes: 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. myles: 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 proposal but don't ask users 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 myles: 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 myles: Realistically us adding a screen at OS install time is difficult to do and generally not something we're comfortable with astearns: Clarification 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 situation for them to have to use web fonts because it's better to require that then for every user to install a font with a name because less websites then web users jensimmons: I was never aware Safari doesn't allow user installed fonts. And I've never heard a web designer talk about that. I agree it's complicated for users to understand a browser setting. That's the kind of thing a webdev can't count on. It may be something to think about but doesn't seem core to solving jensimmons: Looking at last part of GH issues I see intersection of fonts vs union of fonts. 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 Avenir is only on Mac so not allowed. Intersection would be a massive problem. I don't think it's a problem to limit to what's shipped in OSs jensimmons: 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 Avenir but others Roboto pes: Clarifying the proposal: Union of all fonts shipped by default by all OSs that an be reasonably compiled. And the ones fed to the website are intersection of installed and system fonts. That is one option on Android, another on OSX, etc. pes: 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 because 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 already install extra font so this additional step isn't infeasible chris: I wanted to say contrary to jensimmons not seeing it [user installed fonts for uncommon languages] done, I have seen this on some sites, particularly 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 astearns: Is there a way to survey scripts and say these aren't by default but everybody in that region installs these fonts <jensimmons> +1 chris: It would be a valuable addition 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 <Rossen> I'm not convinced that waiting for exposing such API on the OS platform is worth it <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 florian: 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) 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 <pes> +1000 for what is being said right now. <jensimmons> +1 from me as well 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 myles: I don't doubt we can get there so we have one vote on either side so worth discussing 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 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 fingerprintable 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. 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. <myles> dbaron++ 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: Chipping off entropy bits is valuable. Different fingerprint endpoints yield 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 are 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 maintain 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 an 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 registry that's easily maintained and doesn't need our intervention. fantasai: 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 <jensimmons> +1 to everything fantasai just said. It would be incredibly helpful to Authors to have such a list. astearns: Other points on this topic? 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 astearns: I think being active on GH issues that are open and reviewing spec text is most helpful. Anyone else can chime in? <pes> i can promise to do that :) 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 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 about which you might want to limit or be specific about which fonts are safe? AmeliaBR: Have it defined that if a font meets these criteria the browser should make it available and may block access to all others 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. astearns: 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 <gsnedders> do some OSes still conditionally install fonts based on locale? what should the behaviour be then? myles: One point, I don't think can make a must because involves non-CSS pieces of browser. <fantasai> +1 to myles, this would have to be a SHOULD astearns: Must would be font matching algorithm. Not about browser that might make it less restrictive 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. fantasai: Browsers will probably follow because 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. * fantasai notes that Ahem probably needs to be on the list 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. pes: The case discussed where needs to be a way to opt in is handled in GH issue 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 we don't know all UAs that exist or will exist and we shouldn't make a UA non-conformant just because satisfies a non-browser use case. fantasai: Technical definition of SHOULD is [reads] <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. fantasai: 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 <myles> good idea, dbaron 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. chris: pes you should keep watching issue and we update EDs daily so you can see evolution of text astearns: Anything else on this? astearns: Thanks everyone CSS Lists ========= How should spaces be treated in markers? ---------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/4448 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 <Rossen> we do the same in IE and EdgeHtml oriol: I had been confused by internal terminology 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 blockified. 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. Rossen: 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. fantasai: 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: Firefox 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 <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. Rossen: Going back to the proposed resolution I think the understanding is well defined astearns: Proposal: An outside marker box does not have its display value blockified, it generates a block container astearns: Correct? oriol: Should we cover what Firefox does? oriol: You said it's not blockified, but in FF it is. Maybe should say it may be blockified 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 astearns: Object to reverse previous blockification requirement and require generating a block container RESOLVED: 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 White-space: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 browsers opt into processing new lines? florian: Compat with browsers inside case? Or outside only? oriol: Chromium outside markers get white-space: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 because Firefox and legacy chromium preserve fantasai: We should reduce magic switching and make it a simple control florian: Would not necessarily be magic could have pseudo class, but not convinced we need to fantasai: No, let's keep it simple. fantasai: 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: Objections to use pre as the value in UA stylesheet with text about poss processing new lines? RESOLVED: Use pre as the value in UA stylesheet with text about possibly processing new lines 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
Received on Thursday, 19 December 2019 01:01:41 UTC