Re: Intent to implement: Scrollbar color properties
Xidorn Quan writes: >> Would the color for the auto property be derived in such as way as >> to hide the thumb or to make it constrast? > > No, currently we don't derive them from each other. We simply use some > fallback color in that case. How is the fallback color chosen? > It is not impossible to derive them, but I would expect authors to specify > them together. We know from experience that authors will not in general specify complete pairs of colors intended to contrast. We need to ensure that if only one color is specified, then the scrollbar is either consistently usable or consistently not. We shouldn't add a feature that can lead to pages testing as reasonable on some systems, but just causes them to render unusable on others. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Scrollbar color properties
On Thu, Jul 26, 2018, at 7:44 AM, Karl Tomlinson wrote: > Thanks very much for answering some of my questions for me. > > Xidorn Quan writes: > > > On Wed, Jul 25, 2018, at 6:29 PM, Karl Tomlinson wrote: > >> Is there a plan to avoid the contrast problems we have mixing > >> document colors with system colors in other widgets? > >> > >> e.g. If one scrollbar color is specified by the document, then > >> what ensures that other parts of the scrollbar are visually > >> distinct? > >> > >> Does the computed value of the other scrollbar color change so > >> that it contrasts with the specified color? > > > > There are only two scrollbar color properties. If a platform has > > other parts which need different colors, we would derive such > > colors from the given one based on the native scheme and > > constrast. > > Does the second sentence also apply when only one of the two > properties is auto? > > Would the color for the auto property be derived in such as way as > to hide the thumb or to make it constrast? No, currently we don't derive them from each other. We simply use some fallback color in that case. It is not impossible to derive them, but I would expect authors to specify them together. We may add a shorthand property to set them at the same time. The spec currently says track can use face color if that's auto... which I don't think I agree with. But I can consider adding some deriving if it's likely to be useful. - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Fwd: Intent to implement and ship: CSS prefers-reduced-motion media feature for Windows and MacOSX
I just realized that I did send below message only to Tom. :) -- Forwarded message -- From: Hiroyuki Ikezoe Date: Wed, Jul 25, 2018 at 6:59 AM Subject: Re: Intent to implement and ship: CSS prefers-reduced-motion media feature for Windows and MacOSX To: Tom Ritter Thank you, bz and Tom. I just filed bug 1478158 for that. On Wed, Jul 25, 2018 at 1:30 AM, Tom Ritter wrote: > As far as I can tell the specification does not indicate any privacy > concerns; even though this exposes a system preference. > > I'd request that if Resist Fingerprinting is enabled; the browser behaves > as if the user has not set any preference. > > -tom > > On Tue, Jul 24, 2018 at 2:34 AM, Hiroyuki Ikezoe > wrote: > >> Summary: By using CSS prefers-reduced-motion media feature, web developers >> can provide contents depending on a system setting that users want >> *motion-less* content. A WebKit blog post [1] might be useful to know >> this feature in more detail. >> >> Bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=1365045 for Windows >> https://bugzilla.mozilla.org/show_bug.cgi?id=1475462 for Mac OSX >> >> Link to standard: >> https://drafts.csswg.org/mediaqueries-5/#prefers-reduced-motion >> >> Platform coverage: Windows and MacOSX >> Though I don't have a plan for Android at this moment , I maybe do it >> soonish. >> >> Estimated release: For Windows in Firefox 63, for MacOSX it might be >> delayed in Firefox 64 >> >> Preference behind which this will be implemented: None >> >> Is this feature enabled by default in sandboxed iframes? Yes >> >> If allowed, does it preserve the current invariants in terms of what >> sandboxed iframes can do? I believe so >> >> DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1477920 >> >> Do other browser engines implement this? >> >> WebKit already shipped this feature on the last year. >> >> Neither Chrome and Edge hasn't progressed yet. >> https://bugs.chromium.org/p/chromium/issues/detail?id=722548 >> https://developer.microsoft.com/en-us/microsoft-edge/platfor >> m/issues/17506002/ >> >> web-platform-tests: None >> This feature is tied to a system setting, so, as far as I can tell, we >> can't write wpt. >> WebKit has test cases on their tree controlled by something like our >> SpecialPowers. We will have reftests controlled by a UI pref. >> >> Secure contexts: Yes >> >> [1] https://webkit.org/blog/7551/responsive-design-for-motion/ >> ___ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Scrollbar color properties
Thanks very much for answering some of my questions for me. Xidorn Quan writes: > On Wed, Jul 25, 2018, at 6:29 PM, Karl Tomlinson wrote: >> Is there a plan to avoid the contrast problems we have mixing >> document colors with system colors in other widgets? >> >> e.g. If one scrollbar color is specified by the document, then >> what ensures that other parts of the scrollbar are visually >> distinct? >> >> Does the computed value of the other scrollbar color change so >> that it contrasts with the specified color? > > There are only two scrollbar color properties. If a platform has > other parts which need different colors, we would derive such > colors from the given one based on the native scheme and > constrast. Does the second sentence also apply when only one of the two properties is auto? Would the color for the auto property be derived in such as way as to hide the thumb or to make it constrast? >> I see some such code in GetScrollbarArrowColor(), but I haven't >> found something similar for track and thumb. Does something >> ensure the thumb will be visible? > > Both track and thumb are specified by the author, so no, there > is nothing ensures that thumb will be visible if the author > specifically want to hide it. I can understand that if the computed values of track and thumb match and are not auto, then a scrollbar might be hidden. I'm not clear on whether it will actually be hidden because I'm not clear on how much variation (e.g. shading) the implementation is permitted to apply to shape the colors. But my key questions are about the situation where one and only one of the two colors is auto. I'm not entirely clear what "If scrollbar-track-color computes to auto, and scrollbar-face-color is not auto, it is used to color the scrollbar track." means. I guess it means that, if only face is not auto, then the track color is the same as that of face. Is that your understanding? Would it be correct to say that the "used value" for the track property is determined from the computed value for the face property in that situation? Assuming the face and track colors match after applying this rule, then would the scrollbar be hidden, in the same way as it would when face and track colors match but neither computed value is auto. What if only track is not auto? >> What if the user has a high contrast theme for accessibility >> reasons? Does this override document colors? > > It follows the same color overriding settings that if > browser.display.document_color_use is the default value, and the > user is using high contrast theme, those properties would be > ignored during style cascading, and consequently no custom > scrollbar would be used. Sounds good, thanks. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: Change the effect of noopener window feature on other window features in window.open
Relevant bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1419960 As of Firefox 63 I intend to make the noopener window feature not affect whether other window features are enabled. Previously, window.open(url, "_blank", "noopener") would open a new window with other window features, such as tab bar and back buttons, disabled. With this change window.open(url, "_blank", "noopener") and window.open(url, "_blank") act exactly the same - they both open a new tab with all window features *enabled*, except that in first case opener is not set. None of the other browsers have shipped it yet, but there is an existing open bug for Chrome https://bugs.chromium.org/p/chromium/issues/detail?id=596068. - Anny ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Stopgap for Commit Series in Phabricator
While our services team is working on making a reliable & maintained tool for handling commit series with Phabricator, I threw together something small to use as a stop-gap for pushing large commit series to Phabricator and updating them. It currently works as a wrapper around Arcanist, and *only supports git* (as I don't know how hg works enough to get it to work reliably), but should allow pushing a range of commits as revisions without touching the working tree, automatic dependency relationships, bug number filling, and reviewer field population. I called it 'phlay' (splinter => flay; flay + phabricator => phlay). GitHub: https://github.com/mystor/phlay Tweet w/ short demo clip: https://twitter.com/kneecaw/status/1021434807325163523 I've used it to push pretty-much all of my recent patch series to Phabricator, and it's saved me a good amount of time, so I figured I'd let people know. Feel free to poke me on IRC if you have questions. - nika ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Performance Working Group
On Wed, Jul 25, 2018 at 5:42 AM, Panos Astithas wrote: > On Wed, Jul 11, 2018 at 4:52 PM Tom Ritter wrote: > >> Device Memory clearly has made an effort to make it 'less fingerprintable' >> by only reporting possible values of 0.25, 0.5, 1, 2, 4, 8 - but there is >> nothing in the spec about omitting it if desired to reduce fingerprinting. >> This is a spec issue though, and not a rechartering one I don't think. >> > > Would a privacy-conscious user prefer to get the full site experience or a > reduced one? I assume they would rather get the full experience without > divulging any additional information. In that case wouldn't it be better to > just send the maximum allowed value (8) instead of adding another 7th > possible value (like null)? > I would imagine the UA would either send the maximum value or just omit the API entirely -tom ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Scrollbar color properties
On Wed, Jul 25, 2018, at 6:29 PM, Karl Tomlinson wrote: > Is there a plan to avoid the contrast problems we have mixing > document colors with system colors in other widgets? > > e.g. If one scrollbar color is specified by the document, then what ensures > that other parts of the scrollbar are visually distinct? > > Does the computed value of the other scrollbar color change so > that it contrasts with the specified color? There are only two scrollbar color properties. If a platform has other parts which need different colors, we would derive such colors from the given one based on the native scheme and constrast. > I see some such code in GetScrollbarArrowColor(), but I haven't found > something similar for track and thumb. Does something ensure the thumb will > be visible? Both track and thumb are specified by the author, so no, there is nothing ensures that thumb will be visible if the author specifically want to hide it. > What if the user has a high contrast theme for accessibility > reasons? Does this override document colors? It follows the same color overriding settings that if browser.display.document_color_use is the default value, and the user is using high contrast theme, those properties would be ignored during style cascading, and consequently no custom scrollbar would be used. - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Performance Working Group
On Wed, Jul 11, 2018 at 4:52 PM Tom Ritter wrote: > Device Memory clearly has made an effort to make it 'less fingerprintable' > by only reporting possible values of 0.25, 0.5, 1, 2, 4, 8 - but there is > nothing in the spec about omitting it if desired to reduce fingerprinting. > This is a spec issue though, and not a rechartering one I don't think. > Would a privacy-conscious user prefer to get the full site experience or a reduced one? I assume they would rather get the full experience without divulging any additional information. In that case wouldn't it be better to just send the maximum allowed value (8) instead of adding another 7th possible value (like null)? Panos ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Scrollbar color properties
Is there a plan to avoid the contrast problems we have mixing document colors with system colors in other widgets? e.g. If one scrollbar color is specified by the document, then what ensures that other parts of the scrollbar are visually distinct? Does the computed value of the other scrollbar color change so that it contrasts with the specified color? I see some such code in GetScrollbarArrowColor(), but I haven't found something similar for track and thumb. Does something ensure the thumb will be visible? What if the user has a high contrast theme for accessibility reasons? Does this override document colors? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
