gecko-dev/dom/webidl/DOMRect.webidl

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

58 строки
2.0 KiB
Plaintext
Исходник Обычный вид История

/* -*- Mode: IDL; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
*
* The origin of this IDL file is
* https://drafts.fxtf.org/geometry/
*
* Copyright © 2012 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C
* liability, trademark and document use rules apply.
*/
[Exposed=(Window,Worker),
Serializable]
interface DOMRect : DOMRectReadOnly {
constructor(optional unrestricted double x = 0,
optional unrestricted double y = 0,
optional unrestricted double width = 0,
optional unrestricted double height = 0);
[NewObject] static DOMRect fromRect(optional DOMRectInit other = {});
inherit attribute unrestricted double x;
inherit attribute unrestricted double y;
inherit attribute unrestricted double width;
inherit attribute unrestricted double height;
};
Bug 1186265 - Partially update DOMPoint, DOMQuad, DOMRect, DOMMatrix. r=bz Some notes: this does not fully bring us to compliance to the current spec. Instead, these are the fixes that I needed to make in order to make css/geometry/interfaces.html pass with the DOMPoint changes in the previous patches. I don't fully understand why that patch caused the test to fail the way it did, but it ended up being easier to fix our code than understand why the harness was falling over. The DOMQuad::QuadBounds class was the source of some confusion for me. Now that DOMRectReadOnly is a concrete class with members, I wanted to avoid wasting them. However, the spec is unclear as to whether a DOMQuad's bound's should be live -- that is because DOMQuad exposes DOMPoint, we can set its points after retrieving a QuadBounds object. Our current code is live, setting the points changes the QuadBounds. Chromium's current behavior is to never update the QuadBounds object. I've left our behavior untouched in this patch (and waste 4 doubles per QuadBounds object), but I am intending to file a bug to understand what the intent of the spec is. I wonder if the author intended the points to be DOMPointReadOnly instead. If so, we could simplify the DOMRectReadOnly code and get rid of the virtual getters, which would be nice. I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly class, but for brevity and simplicity of implementation, I've made them public. I briefly considered making the setters protected on the ReadOnly version of the class, but I'm not convinced that having to explicitly make them public on the derived class is worth the extra copies of the names. MozReview-Commit-ID: CjdW4Nbnc6A --HG-- extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
2018-03-30 02:19:31 +03:00
[ProbablyShortLivingWrapper,
Exposed=(Window,Worker),
Serializable]
interface DOMRectReadOnly {
constructor(optional unrestricted double x = 0,
optional unrestricted double y = 0,
optional unrestricted double width = 0,
optional unrestricted double height = 0);
[NewObject] static DOMRectReadOnly fromRect(optional DOMRectInit other = {});
readonly attribute unrestricted double x;
readonly attribute unrestricted double y;
readonly attribute unrestricted double width;
readonly attribute unrestricted double height;
readonly attribute unrestricted double top;
readonly attribute unrestricted double right;
readonly attribute unrestricted double bottom;
readonly attribute unrestricted double left;
Bug 1186265 - Partially update DOMPoint, DOMQuad, DOMRect, DOMMatrix. r=bz Some notes: this does not fully bring us to compliance to the current spec. Instead, these are the fixes that I needed to make in order to make css/geometry/interfaces.html pass with the DOMPoint changes in the previous patches. I don't fully understand why that patch caused the test to fail the way it did, but it ended up being easier to fix our code than understand why the harness was falling over. The DOMQuad::QuadBounds class was the source of some confusion for me. Now that DOMRectReadOnly is a concrete class with members, I wanted to avoid wasting them. However, the spec is unclear as to whether a DOMQuad's bound's should be live -- that is because DOMQuad exposes DOMPoint, we can set its points after retrieving a QuadBounds object. Our current code is live, setting the points changes the QuadBounds. Chromium's current behavior is to never update the QuadBounds object. I've left our behavior untouched in this patch (and waste 4 doubles per QuadBounds object), but I am intending to file a bug to understand what the intent of the spec is. I wonder if the author intended the points to be DOMPointReadOnly instead. If so, we could simplify the DOMRectReadOnly code and get rid of the virtual getters, which would be nice. I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly class, but for brevity and simplicity of implementation, I've made them public. I briefly considered making the setters protected on the ReadOnly version of the class, but I'm not convinced that having to explicitly make them public on the derived class is worth the extra copies of the names. MozReview-Commit-ID: CjdW4Nbnc6A --HG-- extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
2018-03-30 02:19:31 +03:00
[Default] object toJSON();
};
dictionary DOMRectInit {
unrestricted double x = 0;
unrestricted double y = 0;
unrestricted double width = 0;
unrestricted double height = 0;
};