After many delays, I think this is finally ready for another look.
On Thursday, February 1, 2024 at 4:47:45 PM UTC+11 dom...@chromium.org
wrote:
Very exciting to see this!
On Thu, Feb 1, 2024 at 12:10 AM alice wrote:
Contact emails
al...@igalia.com, mere...@chromium.org
Explainer
https://git
FYI in the spec issue we thought that safe-area-max-inset-* would be better
to ensure that it appears next to the safe-area-inset-* in sorted lists:
https://github.com/w3c/csswg-drafts/issues/11019#issuecomment-2607836504
where the summary in this issue says max-area-safe-inset-*
On Mon, Feb 3, 20
I'm not seeing any privacy information. Does this leak information not
currently available about the hardware running Chrome, or what software is
running on it?
On Monday, February 3, 2025 at 10:49:51 AM UTC-5 Robert Flack wrote:
> FYI in the spec issue we thought that safe-area-max-inset-* wo
On Mon, Feb 3, 2025 at 11:03 AM Matt Menke wrote:
> I'm not seeing any privacy information. Does this leak information not
> currently available about the hardware running Chrome, or what software is
> running on it?
>
The value exposed in safe-area-max-inset-bottom is the same value that
safe-
This is now enabled for OT on Win/Mac. (starting 134) (in addition to
Android which has been already enabled )
Thank you!
On Tuesday, January 14, 2025 at 6:17:04 PM UTC+1 Rick Byers wrote:
> Whoops, I'm very embarrassed to admit that I told Mohamed that he could
> request a renewal for 6 miles
On Mon, Feb 3, 2025 at 1:24 PM Victor Miura wrote:
> Fwiw, I would not say that these values are static. They can change for
> example for an accessibility scale change.
>
> It might be better to say these values are not intended to be animated.
> They provide a "safe max", that can be used for m
Thank you for the quick reply, I've added inline links to artefacts
exemplifying our progress. Let me know if I can further clarify or provide
more information.
- Draft spec (early draft is ok, but must be spec-like and associated
with the appropriate standardization venue, or WICG)
Early
Small correction, viewport-fit=cover is specified in the meta viewport
content string, e.g.
Demo: https://output.jsbin.com/muxotol
On Mon, Feb 3, 2025 at 11:19 AM Robert Flack wrote:
> On Mon, Feb 3, 2025 at 11:03 AM Matt Menke wrote:
>
>> I'm not seeing any privacy information. Does this lea
Thank you Mike, just to confirm this is an extension request to M137
(inclusive). The generated e-mail also included the previous extension's
"Reason this experiment is being extended" section.
Kind Regards,
Andy Paicu
On Mon, Feb 3, 2025 at 5:35 PM Mike Taylor wrote:
> Thanks, LGTM to extend
Oops yes. LGTM to extend from 135 to 137 inclusive.
(thanks)
On 2/3/25 12:20 PM, Andy Paicu wrote:
Thank you Mike, just to confirm this is an extension request to M137
(inclusive). The generated e-mail also included the previous
extension's "Reason this experiment is being extended" section.
Contact emails
nrosent...@chromium.org
Explainer
https://github.com/noamr/explainers/blob/main/corner-shape-explainer.md
Specification
https://drafts.csswg.org/css-borders-4/#corner-shaping
Summary
Enable fine-tuning corners, on top of the existing border-radius, by specifying
the shape/cur
Nan and I had an offline chat about burn-in risk. Given that, LGTM to
extend from 133 to 135 inclusive.
However, I still have some concerns about successfully turning this off
and hope the team can present a timeline or approximate plan for
expiring the experiment, as an artifact of "progress"
Fwiw, I would not say that these values are static. They can change for
example for an accessibility scale change.
It might be better to say these values are not intended to be animated.
They provide a "safe max", that can be used for maximum height or padding,
which will not be changed frequently
Contact emailsvmp...@chromium.org, sko...@chromium.org
ExplainerThis proposal builds upon the safe-area-inset variables specified
here https://drafts.csswg.org/css-env-1/#safe-area-insets. The
safe-area-inset variables can dynamically change based on the device, which
can require relayout or in so
Thanks, LGTM to extend from 132-134 inclusive.
On 2/3/25 5:31 AM, Andy Paicu wrote:
Thank you for the quick reply, I've added inline links to artefacts
exemplifying our progress. Let me know if I can further clarify or
provide more information.
* Draft spec (early draft is ok, but must be s
15 matches
Mail list logo
