We intend to enable the following feature in m-c soon, and ship it in Gecko
85.
Summary:
Support for the "pinch-zoom" keyword value for the touch-action CSS
property
Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1329241
Standard:
https://compat.spec.whatwg.org/#touch-action
Op zondag 29 maart 2020 08:24:06 UTC+2 schreef Emilio Cobos Álvarez:
> Hey, a quick web-observable change that may deserve a bit more
> visibility / an intent.
>
> I'd welcome some feedback, specially from the fingerprinting / privacy
> angle (where I'm clearly not an expert).
>
> Summary: A
On 3/30/20 8:02 PM, Bobby Holley wrote:
Reading the post a few times, I'm still unclear on a few things, so would
appreciate clarification. Here's what I understand from the post:
On the user's machine, there is some entropy, i.e. the set of schemes for
which an external protocol handler is
Reading the post a few times, I'm still unclear on a few things, so would
appreciate clarification. Here's what I understand from the post:
On the user's machine, there is some entropy, i.e. the set of schemes for
which an external protocol handler is registered. This entropy is currently
On 3/29/20 9:11 AM, Emilio Cobos Álvarez wrote:
Doing a bit of digging,
https://bugzilla.mozilla.org/show_bug.cgi?id=680300 contains some more
interesting context...
We apparently used to sync-throw when assigning location.href to an
unknown protocol URI in the past, there we changed it to
Doing a bit of digging,
https://bugzilla.mozilla.org/show_bug.cgi?id=680300 contains some more
interesting context...
We apparently used to sync-throw when assigning location.href to an
unknown protocol URI in the past, there we changed it to silently fail,
and now it is navigating to an
Hey, a quick web-observable change that may deserve a bit more
visibility / an intent.
I'd welcome some feedback, specially from the fingerprinting / privacy
angle (where I'm clearly not an expert).
Summary: A page redirecting / navigating to an unknown protocol will be
silently ignored
Firefox currently has no support for RTCRtpReceiver.getParameters().
Bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1618999
Standard: https://w3c.github.io/webrtc-pc/
Testing:
testing/web-platform/tests/webrtc/RTCRtpReceiver-getParameters.html
Cross-browser support: Chrome (and Edge)
Firefox currently supports an old version of RTCRtpSender.getParameters()
and RTCRtpSender.setParameters(), which has changed significantly in more
recent versions of the webrtc-pc spec. The most important change is the
introduction of a transaction model, wherein setParameters() can only be
There have been some recent changes to the CSS spec for the
text-decoration-thickness, text-underline-offset, and
text-underline-position: support for percentage values (based on the
font-size) is added to the -thickness and -offset properties, as an
alternative to using absolute lengths; and
Summary: The overscroll-behavior-{block,inline} CSS properties are
flow-relative versions of the already-supported overscroll-behavior-{x,y}
longhand properties.
Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1453472
Standard:
This landed in https://hg.mozilla.org/mozilla-central/rev/724d7b936078
To replicate the prior output, use MOZ_LOG="DocShellAndDOMWindowLeak:3"
Because it now includes the MOZ_LOG prefix, any custom scripts you had to
parse the output will need to be updated.
-tom
On Fri, Nov 8, 2019 at 2:44 PM
vid
> >
> > --
> > 턞 L. David Baron http://dbaron.org/ 턂
> > 턢 Mozilla https://www.mozilla.org/ 턂
> > Before I built a wall I'd ask to know
> > What I was walling in or walling out,
We intend to implement and ship Promise.any, a proposed way to `await`
several promises and continue as soon as any of them becomes
fulfilled. André Bargull [:anba] has contributed patches implementing
this feature. It will land in Nightly soon.
We'll ship it once we're confident the
This sounds great. Is there a reason we can't just use MOZ_LOG for the
docshell/domwindow logging?
-e
On Fri, Nov 8, 2019 at 2:44 PM Tom Ritter wrote:
> In https://bugzilla.mozilla.org/show_bug.cgi?id=1592297 I plan/hope to
> remove MOZ_QUIET and turn off the DOCSHELL/DOMWINDOW logging by
Thank you for doing this.
On Fri, Nov 8, 2019 at 2:44 PM Tom Ritter wrote:
> In https://bugzilla.mozilla.org/show_bug.cgi?id=1592297 I plan/hope to
> remove MOZ_QUIET and turn off the DOCSHELL/DOMWINDOW logging by default.
> It will automatically be enabled in browser-chrome tests where it is
>
In https://bugzilla.mozilla.org/show_bug.cgi?id=1592297 I plan/hope to
remove MOZ_QUIET and turn off the DOCSHELL/DOMWINDOW logging by default.
It will automatically be enabled in browser-chrome tests where it is
needed. (It actually will no longer be possible to disable it when running
those
Thanks, that's a good point indeed. I prefer adding a console warning in
this case.
On Tue, Jul 2, 2019 at 9:23 PM Panos Astithas wrote:
> On Tue, Jul 2, 2019 at 6:16 AM Thomas Nguyen wrote:
>
>> DevTools bug: No
>>
>
> Wouldn't it be helpful to indicate such truncation in the console (as a
>
On Tue, Jul 2, 2019 at 6:16 AM Thomas Nguyen wrote:
> DevTools bug: No
>
Wouldn't it be helpful to indicate such truncation in the console (as a
warning) or network panel (with a request badge)? I can imagine developers
being confused about why the referrer header is not what they expect it to
Summary:
Servers often reject requests entailing an overly long `Referer` header.
Additionally, attackers can retain control over the header on `no-cors`
requests and force an error when fetching a subresource which allows them
to perform cache probing attacks by looking at the error event of the
On Fri, Jun 14, 2019 at 3:25 AM violet wrote:
> Preference behind which this will be implemented:
> layout.css.overflow-logical.enabled
>
> Enabled by default.
>
Enabled by default sounds fine to me in this case.
Thanks for doing this,
Sean
___
Summary: webkitURL will be implemented as a legacy compatibility alias of URL.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1366738
Link to standard: https://url.spec.whatwg.org/#url-class
Platform coverage: All
Estimated or target release: 69
Preference behind which this will be
On 3/27/19 5:19 AM, L. David Baron wrote:
On Wednesday 2019-03-27 01:42 +0100, Mats Palmgren wrote:
FYI, the CSS Lists spec isn't very well maintained, sadly,
so it's not up-to-date with recent resolutions. So, some
of the finer details in there might be wrong, but I think
most of it regarding
Summary: Implement StaticRange and makes it and Range inherits AbstractRange
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1444847
Link to Standards: https://dom.spec.whatwg.org/#abstractrange
https://dom.spec.whatwg.org/#staticrange
Platform coverage: all
Estimated or
On 6/17/19 11:02 AM, saschan...@gmail.com wrote:
Summary: Expose DOMMatrix/DOMPoint/DOMQuad/DOMRect to workers and enable
structured cloning for them.
Note that this also allows storing these objects in IndexedDB, via
implementing the equivalent of
Summary: Expose DOMMatrix/DOMPoint/DOMQuad/DOMRect to workers and enable
structured cloning for them.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1420580
Link to standard: https://drafts.fxtf.org/geometry/
Platform coverage: all
Estimated or target release: 69
Preference behind which this
On 6/14/19 6:23 AM, violet wrote:
Preference behind which this will be implemented:
layout.css.overflow-logical.enabled
Thank you.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Preference behind which this will be implemented:
layout.css.overflow-logical.enabled
Enabled by default.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
> Chrome has shipped these properties in latest Canary, commit:
> https://chromium.googlesource.com/chromium/src/+/985a82ce4c869aca8e33dc213293a37b2764d69c
To clarify, Chrome has just implemented a few days ago, it's not "shipped" yet.
The status can be found here:
On 6/13/19 4:15 AM, violet wrote:
Preference behind which this will be implemented: none.
It's probably a good idea to have a pref controlling whether these get
parsed, so we can disable if needed if there's an issue, given that no
one has shipped these yet in a final release. Or are there
Summary: implement overflow-block and overflow-inline CSS properties
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1470695
Link to standard: https://drafts.csswg.org/css-overflow-3/#logical
Platform coverage: all.
Estimated or target release: 69
Preference behind which this will be
Hi,
*Summary*:
We had landed this feature behind a preference last month, and we are
planning to ship this on Firefox 69. The ResizeObserver API is an interface
for observing changes to the element’s size (based on its content-box or
border-box, for now). Each time when the element's size
Summary: implement and ship value "break-spaces" of "white-space" CSS property
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1351432
Link to standard:
https://drafts.csswg.org/css-text-3/#valdef-white-space-break-spaces
Platform coverage: all.
Estimated or target release: 69
Preference
On 6/7/19 8:47 AM, Andrea Marchesini wrote:
Summary: implement and ship 3 new methods to read Blob contents:
blob.text(), blob.arrayBuffer() and blob.stream().
Looks good to me.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
Summary: implement and ship 3 new methods to read Blob contents:
blob.text(), blob.arrayBuffer() and blob.stream().
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1557121
Link to standard: https://w3c.github.io/FileAPI
https://github.com/w3c/FileAPI/pull/117
Platform coverage: all.
Just as a PSA, I did a bunch of work a while ago to align better with
other UAs, and the Gecko-specific values are gone as a result of that work.
The CSSWG resolved in our behavior regarding `auto` in:
https://github.com/w3c/csswg-drafts/issues/3344
So I plan to land the changes in 69 now
On Friday, August 21, 2015 at 11:04:00 PM UTC-4, Birunthan Mohanathas wrote:
> Hi,
>
> navigator.permissions.query has been Nightly-only for a few weeks. We
> are going to let it ride the trains. Other parts of the spec (such as
> Permissions.request) will be implemented when the spec is
Summary: Implement and spec some non-standard CSSOM APIs to converge
with every other browser, since they're unlikely to ever remove their
implementations and the lack of them causes compat issues for us, see
the bug, the CSSWG issue [1] and everything cross-linked from there.
Bug:
*Summary*: This feature adds a token to the window.open() feature argument
to allow callers to specify that the window should be opened without a
referrer (and an opener).
*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1527287
*Link to standard*: https://github.com/whatwg/html/pull/4331
Summary: Make the disabled attribute on link elements do something
useful, and the disabled IDL attribute reflect this attribute instead of
forwarding to the style sheet object (if present). This is mostly compat
work, but should also do less work in pages that use it already. See
below for the
On Monday, April 15, 2019 at 9:21:57 AM UTC+2, Makoto Kato wrote:
> Hi, Mirko. (I mistake email address. sorry)
>
> Does this work on GeckoView/Android too? When showing software keyboard,
> web page may be scrolled without focus manager.
For the record: GeckoView will need to be adapted
Hi, Mirko. (I mistake email address. sorry)
Does this work on GeckoView/Android too? When showing software keyboard,
web page may be scrolled without focus manager.
-- Makoto
On Thu, Apr 11, 2019 at 11:35 PM Mirko Brodesser
wrote:
> *Summary*: this allows web-developers to focus an element
The multiplage version of the spec (for folks with slower machines):
https://html.spec.whatwg.org/multipage/interaction.html#dom-focusoptions-preventscroll
___
dev-platform mailing list
dev-platform@lists.mozilla.org
*Summary*: this allows web-developers to focus an element without scrolling
to it.
*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1374045
*Link to standard*:
https://html.spec.whatwg.org/#dom-focusoptions-preventscroll
*Platform coverage*: all platforms.
*Estimated or target release*:
Are there also plans to revisit our longstanding
foreground/background/link/visited-link colouring prefs (as well as
their companion use_system_colors pref) in light of this set of changes?
They've never really worked very well, nobody has really taken on fixing
their UX, and it would be nice
On Wed, Mar 20, 2019 at 8:45 AM Hiroyuki Ikezoe wrote:
> The Android backend for prefers-color-scheme didn't get on Firefox 67,
> it's just landed on mozilla-central, will be shipped in Firefox 68.
>
The backend was uplifted into Firefox 67 beta yesterday. So
prefers-color-scheme will be
On Wednesday 2019-03-27 01:42 +0100, Mats Palmgren wrote:
> FYI, the CSS Lists spec isn't very well maintained, sadly,
> so it's not up-to-date with recent resolutions. So, some
> of the finer details in there might be wrong, but I think
> most of it regarding counters is correct.
If you've been
On 3/27/19 12:30 AM, Domenic Denicola wrote:
(On-list this time)
However, the actual semantics for how list items work are exclusively
defined by CSS ([css-lists], [css-pseudo]). The above mentioned HTML
elements/attributes simply maps to the relevant CSS properties, using
a built-in
(On-list this time)
> However, the actual semantics for how list items work are exclusively defined
> by CSS ([css-lists], [css-pseudo]).
> The above mentioned HTML elements/attributes simply maps to the relevant CSS
> properties, using a built-in 'list-item' counter.
Where does [css-lists]
On 3/25/19 6:21 AM, Domenic Denicola wrote:
> The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item
> seems to contradict that hard-fought consensus. It seems like a
> regression to implement list item numbering according to that spec,
> instead of according to HTML.
As others
Note that the spec does not yet reflect the decisions made at the last F2F, or
the subsequent decisions from Issues.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Tuesday 2019-03-26 14:25 -0700, Domenic Denicola wrote:
> It's great to hear that this isn't a regression in the way I expected. I
> think I was thrown off by the phrasing of the OP, which implied to me a
> switch from following the HTML spec to following the CSS lists spec. As I
> noted,
It's great to hear that this isn't a regression in the way I expected. I think
I was thrown off by the phrasing of the OP, which implied to me a switch from
following the HTML spec to following the CSS lists spec. As I noted, the CSS
lists spec contradicts the HTML spec, e.g. disallowing
On Sunday 2019-03-24 22:21 -0700, Domenic Denicola wrote:
> Some time ago we spent some effort documenting a cross-browser
> mostly-interoperable behavior for list-item-like behaviors, in
> https://github.com/whatwg/html/pull/2002 and linked threads. The result is
> the spec at
>
On Mon, Mar 25, 2019 at 10:05 PM wrote:
> > As far as separating the value; it kind of depends on how you
> > implement it; but let's say you were going to use a static uint64_t or
> > something like that. Instead of heaving a static uint64_t, create a
> > Dictionary and look up the uint64_t
On 25/03/2019 06:21, Domenic Denicola wrote:
> Some time ago we spent some effort documenting a cross-browser
> mostly-interoperable behavior for list-item-like behaviors, in
> https://github.com/whatwg/html/pull/2002 and linked threads. The result is
> the spec at
>
On Friday, March 22, 2019 at 9:56:20 AM UTC-7, Martin Thomson wrote:
> On Thu, Mar 21, 2019 at 1:11 PM Tom Ritter wrote:
>
> > Okay, good, not making this data available until the user activity
> > engages with the gamepad/VR controller (mostly) assuages my concerns
> > on this component. My
On Wednesday, March 20, 2019 at 7:10:54 PM UTC-7, Tom Ritter wrote:
> > > > Example 1: Let’s say touchId is currently set to 0 and no fingers are
> > > > touching the touchpad. When a finger touches the touchpad, touchId of
> > > > this event would be 1. As that finger moves around the
On Sunday, March 24, 2019 at 10:21:10 PM UTC-7, Domenic Denicola wrote:
> the tests at
> https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-ol-element
correction,
Some time ago we spent some effort documenting a cross-browser
mostly-interoperable behavior for list-item-like behaviors, in
https://github.com/whatwg/html/pull/2002 and linked threads. The result is the
spec at https://html.spec.whatwg.org/multipage/grouping-content.html#list-owner
and the
Summary:
The ::marker pseudo-element represents the automatically generated
marker box of a list item. It allows authors to style the marker
and generate content for it through its 'content' property (like
::before/::after).
Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=205202
Animation
Summary:
The built-in 'list-item' counter is used to implement HTML /
(and other elements with display:list-item) using CSS.
I'm also removing our old (frame-based) code for list item counters,
which had a number of decades-old bugs (bug 4522 et al), was rather
slow (bug 3246) and crashy (bug
Summary:
The counter-set CSS property assigns an absolute value to a CSS counter.
(It behaves the same as counter-increment but assigns instead of
increments.)
It will be used internally to map to set the value of
the built-in 'list-item' counter (see separate announcement following
this).
On Thu, Mar 21, 2019 at 1:11 PM Tom Ritter wrote:
> Okay, good, not making this data available until the user activity
> engages with the gamepad/VR controller (mostly) assuages my concerns
> on this component. My remaining concern is around the sensitivity of
> axis movement. If I have my
> > > Example 1: Let’s say touchId is currently set to 0 and no fingers are
> > > touching the touchpad. When a finger touches the touchpad, touchId of
> > > this event would be 1. As that finger moves around the touchpad, new
> > > touch events are added with updated coordinates, however,
On Friday, March 15, 2019 at 8:35:41 AM UTC-7, Tom Ritter wrote:
> Thanks for more details on the use case.
>
> On Wed, Mar 6, 2019 at 1:35 AM wrote:
> >
> > On Monday, February 25, 2019 at 4:17:29 PM UTC-8, Martin Thomson wrote:
> > > To add to Dan's comments here...
> > >
> > > Assuming that
It's https://bugzilla.mozilla.org/show_bug.cgi?id=1532850, it was at a
deeper level of blockers of bug 1494034, now I added bug 1532850 in the
dependency list of bug 1494034.
Thanks,
hiro
On Wed, Mar 20, 2019 at 9:42 AM Eric Shepherd (Sheppy) <
esheph...@mozilla.com> wrote:
> Presumably that’s
Presumably that’s noted appropriately in some manner in Bugzilla?
On March 19, 2019 at 7:45:53 PM, Hiroyuki Ikezoe (hike...@mozilla.com)
wrote:
The Android backend for prefers-color-scheme didn't get on Firefox 67, it's
just landed on mozilla-central, will be shipped in Firefox 68.
Eric
The Android backend for prefers-color-scheme didn't get on Firefox 67, it's
just landed on mozilla-central, will be shipped in Firefox 68.
Thanks,
hiro
On Sat, Feb 16, 2019 at 5:38 AM Mats Palmgren wrote:
> Summary:
> The 'prefers-color-scheme' media feature is way for pages to detect
> if the
On Fri, Mar 15, 2019 at 11:35 AM Tom Ritter wrote:
> Thanks for more details on the use case.
>
> On Wed, Mar 6, 2019 at 1:35 AM wrote:
> >
> > On Monday, February 25, 2019 at 4:17:29 PM UTC-8, Martin Thomson wrote:
> > > To add to Dan's comments here...
> > >
> > > Assuming that I'm reading
Thanks for more details on the use case.
On Wed, Mar 6, 2019 at 1:35 AM wrote:
>
> On Monday, February 25, 2019 at 4:17:29 PM UTC-8, Martin Thomson wrote:
> > To add to Dan's comments here...
> >
> > Assuming that I'm reading this correctly [1], the fingerprinting risks are
> > pretty extreme
Hello, fantasai!
On Sun, Mar 10, 2019 at 6:14 AM fantasai
wrote:
> 1. Handling overlarge snap areas per
> https://www.w3.org/TR/css-scroll-snap-1/#snap-overflow
> This is important to make content accessible on smaller-than-expected
> screens.
>
I think I've finished this properly, but..
All of this sounds great to me, and I'm pretty excited that Mozilla will
be updating to the latest spec. Most of the changes were in response to
roc's feedback on the spec, and make it a much more robust system for the
variable environment of the Web.
There's a couple things I want to make sure
Summary:
The scroll snap specification has been significantly changed since we
implemented. scroll-snap-coordinate, scroll-snap-destination and
scroll-snap-points-{x,y} were dropped, instead, scroll-snap-align,
scroll-snap-margin and scroll-snap-padding were added in the spec. Also,
On Monday, February 25, 2019 at 4:17:29 PM UTC-8, Martin Thomson wrote:
> To add to Dan's comments here...
>
> Assuming that I'm reading this correctly [1], the fingerprinting risks are
> pretty extreme here. In the touch spec, we have a monotonically increasing
> counter that doesn't appear to
Summary: The CSS `revert` wide-keyword allows authors to ignore all CSS
rules in a given cascade origin[1], while applying rules from other
cascade origins. Trivial example would be:
div {
display: inline;
}
// somewhere further down...
div {
display: revert; /* Goes back to display: block
On Wed, Feb 27, 2019, at 6:43 AM, James Graham wrote:
> The current thinking is that hardware interaction APIs which rely on
> mocks to test should specify the API for testing as part of the
> specification (e.g. [1]). So it seems like the same approach could be
> used here.
>
> [1]
On 26/02/2019 22:49, d...@mozilla.com wrote:
On Tuesday, February 26, 2019 at 2:15:57 AM UTC-8, James Graham wrote:
On 25/02/2019 19:44, Daosheng Mu wrote:
web-platform-tests: none exist (and I don't plan to write WPTs but we do
have gamepad mochitest, I will add new tests to cover these
On Tuesday, February 26, 2019 at 2:15:57 AM UTC-8, James Graham wrote:
> On 25/02/2019 19:44, Daosheng Mu wrote:
>
> > web-platform-tests: none exist (and I don't plan to write WPTs but we do
> > have gamepad mochitest, I will add new tests to cover these two new APIs.)
>
> Why do you plan to
--
Daosheng Mu
Software Engineer | Mozilla
d...@mozilla.com
On Tue, Feb 26, 2019 at 1:14 AM Julien Cristau wrote:
> On Mon, Feb 25, 2019 at 8:45 PM Daosheng Mu wrote:
>
>> Is this feature restricted to secure contexts? Nope
>>
>
> Why not?
>
> I agree. I will make it be restricted to secure
On 25/02/2019 19:44, Daosheng Mu wrote:
web-platform-tests: none exist (and I don't plan to write WPTs but we do
have gamepad mochitest, I will add new tests to cover these two new APIs.)
Why do you plan to not write web-platform-tests? I imagine there may be
technical challenges, but we
On Mon, Feb 25, 2019 at 8:45 PM Daosheng Mu wrote:
> Is this feature restricted to secure contexts? Nope
>
Why not?
Cheers,
Julien
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
To add to Dan's comments here...
Assuming that I'm reading this correctly [1], the fingerprinting risks are
pretty extreme here. In the touch spec, we have a monotonically increasing
counter that doesn't appear to be origin-bound in any way. What is the
purpose of this identifier? In the light
Hi Daniel,
We didn't have a chance to discuss privacy issues in Gamepad Extension or
Gamepad API. We were trying to get responses for the Privacy review [1] but
without any updates yet.
Cheers,
[1] https://lists.w3.org/Archives/Public/public-privacy/2018AprJun/0030.html
--
Daosheng Mu
Software
Neither of the words "security" or "privacy" appear in this spec (most w3
web specs have at least a token attempt at a "Privacy and Security
Considerations" section). At a surface glance this appears to add
additional fingerprinting exposure. Have you talked to the privacy team
about ways to
Summary:
In order to support controllers which have multi touch and light bar
features like Sony DualShock 4. The `*multi touch*` and `*light indicator*`
APIs for gamepad extensions are the things we must have. In `*GamepadTouch*`
API, it would make us know touch surface's dimension and its unique
Summary:
The 'prefers-color-scheme' media feature is way for pages to detect
if the user prefers a light or dark color theme. The values are
'light', 'dark', and 'no-preference'. If the "resist fingerprinting"
feature is active we always match 'light'. If the media type is
'print' we always
We need to implement InputEvent.data and InputEvent.dataTransfer because
they are important information for web apps especially for "beforeinput"
event listeners. So, we need to implement these attributes before
implementing "beforeinput" event. The bug is here:
On Fri, Jan 18, 2019, at 7:46 AM, Mats Palmgren wrote:
> Summary:
> The border-{start,end}-{start,end}-radius CSS properties are flow-relative
> versions of their corresponding physical property, border-top-left-radius etc
>
> Bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1520684
>
> Link
> Do other browser engines implement this?
> I don't know, there was no WPT for these.
I didn't implement them in Blink because they were added into the spec after I
sent the intent to implement. So I should send a new one for them.
Also, the mapping is not clear in the spec
Summary:
The border-{start,end}-{start,end}-radius CSS properties are flow-relative
versions of their corresponding physical property, border-top-left-radius etc
Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1520684
Link to standard:
Summary:
The border-{block,inline}-{color,style,width} CSS properties are shorthand
for their respective -start/-end properties.
The border-{block,inline} are shorthand for their respective -start/-end
shorthands, though you can only specify one value (which is used on both
the -start/-end
Summary:
The inset-block CSS property is a shorthand for the inset-block-start/end
properties (ditto -inline).
The 'inset' CSS property is a shorthand for the top, right, bottom, and
left properties.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1520229
Link to standard:
On 1/14/19 9:09 PM, fantasai wrote:
I have no idea why I did that. Fixed.
Thank you!
Yes, the spec reflects general consensus, and has been explicitly cleared
for shipping by the CSSWG (as of several years). See issue at the bottom
of the intro:
https://www.w3.org/TR/css-logical-1/#intro
On 12/11/18 6:34 AM, Boris Zbarsky wrote:
>
> Spec stability: Not 100% clear, but I expect it's pretty stable; on the spec level this is a tiny
change and there's not much controversy about which letter to use for the flag, I would think.
As the editor of the spec, I second this assessment.
On 12/23/18 2:59 AM, Emilio Cobos Álvarez wrote:
Summary: More explicitly expose the kind of handling for overflowing content in media queries. Using
a media expression instead of the print media type allows for more flexibility, see the bug
description.
Implementation wise, we already expose
On 1/14/19 10:23 AM, Boris Zbarsky wrote:
On 1/14/19 12:58 PM, Mats Palmgren wrote:
Link to standard: https://drafts.csswg.org/css-logical/#propdef-padding-inline
Two quick questions on the spec:
1) 'padding-block-start' is defined as:
Value: <‘padding-top’>
while 'padding-block' is
Summary: The margin-block CSS property is a shorthand for the
margin-block-start/end properties (ditto -inline)
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1519944
Link to standard: https://drafts.csswg.org/css-logical/#propdef-margin-inline
Platform coverage: All platforms
Estimated
On 1/14/19 7:23 PM, Boris Zbarsky wrote:
Do you know whether this is purposeful or just a typo?
Dunno. It seems like a typo to me.
2) We are just implementing the padding shorthands for now, not the margin
ones?
Yes, but I should probably just add margin-block/inline while I'm at it...
On 1/14/19 7:23 PM, Boris Zbarsky wrote:
> On 1/14/19 12:58 PM, Mats Palmgren wrote:
>> Do other browser engines implement this? No,
>> https://wpt.fyi/results/css/css-logical/logical-box-padding.html
>
> Do they plan to? That is, is the spec reflecting some sort of general
> consensus?
1 - 100 of 676 matches
Mail list logo
