Interoperability and Compatibility
The main interoperability risk is if other browsers do not implement the API. However, there should not generally be any impact to sites: the media features won’t parse, and the environment variables will not be set (resolve to author specified default), which is the same state exposed when not in the specific ‘spanning’ mode. Similarly compatibility risk should be low, as new features won’t parse and throw out the entire @media block.
There has been good discussion in CSSWG, with recognition of validity of use cases and positive sentiment towards the initial proposal:
Firefox: No public signals
Safari: No public signals
Web developers: positive
ErgonomicsThere is also a JavaScript API proposal (see the WindowSegments section of the explainer) that will expose similar information. Developers may end up using these in tandem.We will need to investigate and measure the performance of changing CSS environment variables dynamically, based on device posture. Currently these result in fairly large style invalidations.ActivationIt will be relatively easy for developers to extend their existing responsive design by adding a set of grouped rules within a media query, specifically targeting these devices and their fold geometry.A polyfill is available, however it is for specific form factors, and thus not comprehensive.DebuggabilityThis area is still in its early stages, and as such the underlying operating systems’ platforms are still under development, in terms of how this information is exposed (e.g. Android support library is planning on exposing a concept of DisplayFeature). Due to this, we are working with the Microsoft Edge DevTools team to provide an emulation solutionintegrated into the Chromium devtools, in order to initially light up this API for developers
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/77158014-3270-4022-b638-01bce11ed3f3%40chromium.org.
SummaryAdd new CSS media features and environment variables for developers to reason about devices where a fold or hinge semantically splits web content.MotivationIn order to enable web developers to build layouts that are optimized for foldable experiences declaratively using CSS, we consider the fundamental assumptions of CSS (i.e. a single contiguous rectangular space for laying out content) and introduce new primitives that - together with existing layout media queries - allow developers to create layouts that react to states where the root viewport spans across a device's fold or hinge.RisksInteroperability and CompatibilityThe main interoperability risk is if other browsers do not implement the API. However, there should not generally be any impact to sites: the media features won’t parse, and the environment variables will not be set (resolve to author specified default), which is the same state exposed when not in the specific ‘spanning’ mode. Similarly compatibility risk should be low, as new features won’t parse and throw out the entire @media block.There has been good discussion in CSSWG, with recognition of validity of use cases and positive sentiment towards the initial proposal:Firefox: No public signalsSafari: No public signals
Web developers: positiveErgonomicsThere is also a JavaScript API proposal (see the WindowSegments section of the explainer) that will expose similar information. Developers may end up using these in tandem.We will need to investigate and measure the performance of changing CSS environment variables dynamically, based on device posture. Currently these result in fairly large style invalidations.ActivationIt will be relatively easy for developers to extend their existing responsive design by adding a set of grouped rules within a media query, specifically targeting these devices and their fold geometry.A polyfill is available, however it is for specific form factors, and thus not comprehensive.DebuggabilityThis area is still in its early stages, and as such the underlying operating systems’ platforms are still under development, in terms of how this information is exposed (e.g. Android support library is planning on exposing a concept of DisplayFeature). Due to this, we are working with the Microsoft Edge DevTools team to provide an emulation solutionintegrated into the Chromium devtools, in order to initially light up this API for developersWill this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?No, currently with the set of hardware slated for release there will be support on Windows and Android. I would expect this to evolve if the other platforms start supporting devices with a fold/hinge.Is this feature fully tested by web-platform-tests?No, part of prototyping this feature will include coming up with a plan to integrate support for emulation into wpt.Link to entry on the feature dashboard
Foldables are basically a subclass of "multiple screens", as I see it.
Can you generalize this implementation to fit multiple screens as well (and on the way, fix some multiple screen issues Chrome currently has, regarding window.screen.availFoo properties and I am sure there are more - search crbug.com)?
☆PhistucK
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
On Fri, Feb 7, 2020 at 2:23 PM 'Daniel Libby' via blink-dev <blin...@chromium.org> wrote:SummaryAdd new CSS media features and environment variables for developers to reason about devices where a fold or hinge semantically splits web content.MotivationIn order to enable web developers to build layouts that are optimized for foldable experiences declaratively using CSS, we consider the fundamental assumptions of CSS (i.e. a single contiguous rectangular space for laying out content) and introduce new primitives that - together with existing layout media queries - allow developers to create layouts that react to states where the root viewport spans across a device's fold or hinge.RisksInteroperability and CompatibilityThe main interoperability risk is if other browsers do not implement the API. However, there should not generally be any impact to sites: the media features won’t parse, and the environment variables will not be set (resolve to author specified default), which is the same state exposed when not in the specific ‘spanning’ mode. Similarly compatibility risk should be low, as new features won’t parse and throw out the entire @media block.There has been good discussion in CSSWG, with recognition of validity of use cases and positive sentiment towards the initial proposal:Firefox: No public signalsSafari: No public signalsCould you reach out to them?
--Web developers: positiveErgonomicsThere is also a JavaScript API proposal (see the WindowSegments section of the explainer) that will expose similar information. Developers may end up using these in tandem.We will need to investigate and measure the performance of changing CSS environment variables dynamically, based on device posture. Currently these result in fairly large style invalidations.ActivationIt will be relatively easy for developers to extend their existing responsive design by adding a set of grouped rules within a media query, specifically targeting these devices and their fold geometry.A polyfill is available, however it is for specific form factors, and thus not comprehensive.DebuggabilityThis area is still in its early stages, and as such the underlying operating systems’ platforms are still under development, in terms of how this information is exposed (e.g. Android support library is planning on exposing a concept of DisplayFeature). Due to this, we are working with the Microsoft Edge DevTools team to provide an emulation solutionintegrated into the Chromium devtools, in order to initially light up this API for developersWill this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?No, currently with the set of hardware slated for release there will be support on Windows and Android. I would expect this to evolve if the other platforms start supporting devices with a fold/hinge.Is this feature fully tested by web-platform-tests?No, part of prototyping this feature will include coming up with a plan to integrate support for emulation into wpt.Link to entry on the feature dashboard
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
On Friday, February 7, 2020 at 3:24:57 PM UTC-8, Yoav Weiss wrote:On Fri, Feb 7, 2020 at 2:23 PM 'Daniel Libby' via blink-dev <blin...@chromium.org> wrote:SummaryAdd new CSS media features and environment variables for developers to reason about devices where a fold or hinge semantically splits web content.MotivationIn order to enable web developers to build layouts that are optimized for foldable experiences declaratively using CSS, we consider the fundamental assumptions of CSS (i.e. a single contiguous rectangular space for laying out content) and introduce new primitives that - together with existing layout media queries - allow developers to create layouts that react to states where the root viewport spans across a device's fold or hinge.RisksInteroperability and CompatibilityThe main interoperability risk is if other browsers do not implement the API. However, there should not generally be any impact to sites: the media features won’t parse, and the environment variables will not be set (resolve to author specified default), which is the same state exposed when not in the specific ‘spanning’ mode. Similarly compatibility risk should be low, as new features won’t parse and throw out the entire @media block.There has been good discussion in CSSWG, with recognition of validity of use cases and positive sentiment towards the initial proposal:Firefox: No public signalsSafari: No public signalsCould you reach out to them?Engineers from both Safari and Firefox participated in the CSSWG discussion, but I didn't want to represent their initial thoughts as public support (though sentiment was generally positive). We'll continue to work with them as the proposal evolves (both in the github issue and on future conf calls).
----Web developers: positiveErgonomicsThere is also a JavaScript API proposal (see the WindowSegments section of the explainer) that will expose similar information. Developers may end up using these in tandem.We will need to investigate and measure the performance of changing CSS environment variables dynamically, based on device posture. Currently these result in fairly large style invalidations.ActivationIt will be relatively easy for developers to extend their existing responsive design by adding a set of grouped rules within a media query, specifically targeting these devices and their fold geometry.A polyfill is available, however it is for specific form factors, and thus not comprehensive.DebuggabilityThis area is still in its early stages, and as such the underlying operating systems’ platforms are still under development, in terms of how this information is exposed (e.g. Android support library is planning on exposing a concept of DisplayFeature). Due to this, we are working with the Microsoft Edge DevTools team to provide an emulation solutionintegrated into the Chromium devtools, in order to initially light up this API for developersWill this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?No, currently with the set of hardware slated for release there will be support on Windows and Android. I would expect this to evolve if the other platforms start supporting devices with a fold/hinge.Is this feature fully tested by web-platform-tests?No, part of prototyping this feature will include coming up with a plan to integrate support for emulation into wpt.Link to entry on the feature dashboard
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/77158014-3270-4022-b638-01bce11ed3f3%40chromium.org.
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/315a0dda-3b46-4e82-bd66-fd64e6532734%40chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/90b21dc0-830f-4c5a-a38e-caa9924542e0%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_KMZsU-7DyoTi9UD9WYRunw07OY2iXQc6L876%3DwZ7%3DkhQ%40mail.gmail.com.