- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Apr 2025 16:37:17 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[cssom-view] No event to track window position`, and agreed to the following: * `RESOLVED: remove the event` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> q+<br> <JoshT> fantasai: Our team has reviewed this and is opposed to new APIs relying on window position. privacy problems<br> <JoshT> ... we don't want to add to API surface<br> <Rossen5> q?<br> <JoshT> florian: This doesn't expose anything new. Just adds a convienience, so you don't need to actively pull it.<br> <emilio> q+<br> <JoshT> ... if you don't expose anything, it doesn't affect you. but for people using it, they can be more efficient.<br> <JoshT> ... there are projects to see about doing it declaritively, which would be better, but this has been talked about for a while.<br> <JoshT> ... there is an opt-out so I don't understand concerns<br> <JoshT> TabAtkins: I agree generally. this is no new surface, a small easy change that makes a known use case from Bloomburg more efficient.<br> <emilio> s/Bloomburg/Bloomberg<br> <JoshT> ... I agree we shouldn't go to large expense supporting, but in this case synchronising API wise with event for window.size, this does not seem worth objecting to<br> <JoshT> ... I support keeping the resolution as it is<br> <Rossen5> ack TabAtkins<br> <Rossen5> ack emilio<br> <JoshT> emilio: did we define what happens with iframes? they do change screenX, screenY as well<br> <JoshT> ... but they could have cross-origin behaviour<br> <JoshT> florian: there are some cases where it is not useful. to make it useful, you are in breach of privacy<br> <JoshT> TabAtkins: I saw comment on issue that it should be OK to make it fine for iframes<br> <TabAtkins> s/make it fine/make it not work/<br> <JoshT> emilio: I'm curious about particular use case. popups?<br> <PaulG> q+<br> <JoshT> florian: Yes I think it was primerily for popups. And moving windows that are side-by-side together to remain together.<br> <JoshT> emilio: implications for popups are trickier. let's say you don't move the window but user adds a toolbar or menu bar<br> <JoshT> ... that moves the page down and you should get... screenX exposes the top window, so is it useful?<br> <JoshT> florian: if we had a declarative API to make the browser deal with it, that would be great. but we don't have that.<br> <JoshT> ... we have an non-great API that could be made more convienient. not a huge win to do this, but it's a small improvement.<br> <JoshT> emilio: if it's easier to make something work on windows but macOS and linux get screwed...?<br> <JoshT> florian: but how?<br> <JoshT> emilio: it makes something that's not platform independent easier to use<br> <JoshT> ... can we make--<br> <JoshT> PaulG: I work for a competitor to Bloomberg. we break up the app into a PWA and you could have the app tile maybe up to five monitors. get things to respond to size, shape and placement.<br> <JoshT> ... simulates a console app environment<br> <JoshT> ... PWA speeds up development, so I can see how this would be helpful<br> <JoshT> emilio: but how will screenX on monitor a be compatible with monitor b?<br> <smfr> q+<br> <JoshT> ... I'm not sure if we expose stuff like the size of the window borders?<br> <schenney> q+<br> <PaulG> q-<br> <dholbert> s/monitor b/monitor b particularly if they have different devicePixelRatio/<br> <TabAtkins> Remember: this information already exists and is actively used by these tools. Any complexities or issues are things they're already dealing with. This whole API suggestion was solely to let them stop using *polling* and start using an async event instead, so it's a little more efficient.<br> <JoshT> ... but the details of these APIs are not a great fit for the use case. only works if there's no sidebar, for example.<br> <JoshT> ... I'm concerned about making it easier to use<br> <JoshT> florian: we have exposed the info everywhere but we want to make it easier to pull<br> <JoshT> emilio: the common case of a full width window is easy to handle, but if you add stuff on top. the Firefox UI has complex calculations to see where the windows go, and I've seen many bugs<br> <JoshT> ... can people see all the edge cases?<br> <JoshT> Rossen: I think your point is well understood about making the ease of it increasing the badness of it<br> <Rossen5> ack smfr<br> <JoshT> smfr: this also requires leaking the origin of the screen. very fingerprintable<br> <TabAtkins> Again, this information is already "leaked", and to wahtever extent you censor or reduce it, it'll apply to this as well.<br> <JoshT> ... we want to actually lie about this to treduce fingerprinting<br> <JoshT> ... we want to discourage new use of these values<br> <flackr> q+<br> <Rossen5> ack schenney<br> <JoshT> schenney: if they want a popup window outside of the browser chrome, and it contains info relative to the main window, and they want to move with the main window, then the multi-screen thing is still a concern?<br> <Rossen5> ack flackr<br> <JoshT> flackr: I want to respond to smfr. Why not just lie with 0?<br> <JoshT> smfr: It might be 0, but they may not be accurate<br> <keithamus> q+<br> <JoshT> jensimmons: if you say 0 to everyone, it may not be an ideal solution<br> <TabAtkins> randomly fluctuating position would be just as noticeable as constant-0, fwiw.<br> <keithamus> q-<br> <JoshT> emilio: 0 seems non-fingerprintable to me. but sites depend on these, so do you increase the web compat impact on this?<br> <JoshT> flackr: if you do moves consistent with the lie then it should be fine<br> <emilio> q+<br> <JoshT> florian: the spec does already call out you can lie about this<br> <JoshT> ... if you do want to lie with randomisation and jumping around, then that may be a problem<br> <JoshT> ... I understand why browsers would not want to ship this, but the web platform is used as a runtime for a bunch of things<br> <JoshT> ... if you can detect you are on one environment, it is useful to achieve these things<br> <Rossen5> ack emilio<br> <JoshT> emilio: with web compat, let's say we do get them to react to screen pos values, on some platforms, we do lie because we can't do anything better<br> <JoshT> ... on Wayland, screenX is always 0<br> <JoshT> ... if you ???? then sites will break<br> <JoshT> TabAtkins: but this is not a commentary on the existing screenX and Y things<br> <JoshT> ... the polling is easy but it's not efficient for users computers<br> <fantasai> +1 emilio<br> <JoshT> emilio: but maybe instead of the polling, I just don't use them because polling is inefficient<br> <JoshT> IanK: but you do have a lot of large websites doing the polling, so I don't think it discourages anyone<br> <JoshT> Rossen: what if we did a poll here (pun, haha) and see what the group thinks. Is it half and half about whether to add it?<br> <JoshT> TabAtkins: we already have a resolution to do it<br> <JoshT> florian: we need to change both HTML and CSS specs to do it and HTML won't merge if one browser objects<br> <JoshT> ... Safari objects<br> <smfr> Anne points to https://w3ctag.github.io/design-principles/#leave-the-web-better: "The existence of a defect in one part of the platform must not be used to excuse an addition or extension to the defect"<br> <JoshT> Rossen: so the question here is: do we remove it or not?<br> <schenney> q+<br> <JoshT> ... emilio and WebKit folks say we should remove it. chrome folks mostly saying keep it.<br> <JoshT> ... the poll will show the same thing, so we could try to force resolution in a different way<br> <JoshT> schenney: Bloomberg are not so interested in this any more.<br> <JoshT> ... so between those two points, I would say we should remove it<br> <JoshT> Rossen: I could poll or call for a resolution right now<br> <JoshT> ... let's call for a resolution for objections without poll<br> <JoshT> ... does anyone object on removing this event?<br> <JoshT> florian: Unfortunate but I don't object<br> <JoshT> RESOLVED: remove the event<br> <JoshT> Rossen: As editor, you will have to remove it. I am sorry.<br> <JoshT> florian: it's not a huge thing<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7693#issuecomment-2842594228 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 30 April 2025 16:37:18 UTC