To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Incidentally, Mozilla appears to be implementing new sync APIs. These seem like better targets for adding a promise-based API. Although, again, it's not clear to me that a promised-based API actually works.
On Fri, Apr 11, 2014 at 3:07 PM, Ojan Vafai <oj...@chromium.org> wrote:
Incidentally, Mozilla appears to be implementing new sync APIs. These seem like better targets for adding a promise-based API. Although, again, it's not clear to me that a promised-based API actually works.Note that these APIs represent a consensus reached on www-style last year. I didn't just make them up :-).
Regarding the original "intent to implement" here, the "offset" properties are a real mess and they're obsoleted by getBoxQuads/convert*FromNode so I wouldn't bother changing their behavior in any way (and plan not to in Firefox). The scroll* and client* properties don't map exactly to anything currently defined in GeometryUtils, so making them subpixel-aware might make sense.
That's fair. I still think it's valuable because of existing content that will work better on hidpi devices. Also because many web developers will continue using the offset* properties for the forseeable future and many of them likely won't notice that their animations are slightly jittery, or even if they do, they won't identify subpixel as the root cause. It's a subtle thing and requires a solid understanding of the platform.
On Sat, Apr 12, 2014 at 5:12 AM, Ojan Vafai <oj...@chromium.org> wrote:That's fair. I still think it's valuable because of existing content that will work better on hidpi devices. Also because many web developers will continue using the offset* properties for the forseeable future and many of them likely won't notice that their animations are slightly jittery, or even if they do, they won't identify subpixel as the root cause. It's a subtle thing and requires a solid understanding of the platform.Do you have a characterization of the sort of content that will get automatically better vs the sort of content that will break?
I'm not sure how clean a characterization it is, but we've recently written a bunch of exploratory code that creates scroll-linked effects like hidey bars by updating the transform on a number of elements to a value computed from the scroll offset. If that code receives a subpixel floating point number, it will do the same math and set the appropriate subpixel transform without any modification.
As for the other half of the question (what will break), we don't know. I have trouble imagining anything too common, but that's what this intent is all about: let's try and see what happens. Of course we'll discuss the risk of breakage here once we find concrete examples.
On Thu, Apr 10, 2014 at 8:59 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
On Fri, Apr 11, 2014 at 3:07 PM, Ojan Vafai <oj...@chromium.org> wrote:
Incidentally, Mozilla appears to be implementing new sync APIs. These seem like better targets for adding a promise-based API. Although, again, it's not clear to me that a promised-based API actually works.Note that these APIs represent a consensus reached on www-style last year. I didn't just make them up :-).Email is hard. I didn't mean to imply that Mozilla's doing anything wrong. Just that, if Anne wants to push for async APIs, getBoxQuads/convert*FromNode might be a better place to focus that attention.
Regarding the original "intent to implement" here, the "offset" properties are a real mess and they're obsoleted by getBoxQuads/convert*FromNode so I wouldn't bother changing their behavior in any way (and plan not to in Firefox). The scroll* and client* properties don't map exactly to anything currently defined in GeometryUtils, so making them subpixel-aware might make sense.
That's fair. I still think it's valuable because of existing content that will work better on hidpi devices. Also because many web developers will continue using the offset* properties for the forseeable future and many of them likely won't notice that their animations are slightly jittery, or even if they do, they won't identify subpixel as the root cause. It's a subtle thing and requires a solid understanding of the platform.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
I'm for that as well. New APIs that return style values should be async.
On Sat, Apr 12, 2014 at 11:00 AM, Adam Barth <aba...@google.com> wrote:On Fri Apr 11 2014 at 3:37:59 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:On Sat, Apr 12, 2014 at 5:12 AM, Ojan Vafai <oj...@chromium.org> wrote:That's fair. I still think it's valuable because of existing content that will work better on hidpi devices. Also because many web developers will continue using the offset* properties for the forseeable future and many of them likely won't notice that their animations are slightly jittery, or even if they do, they won't identify subpixel as the root cause. It's a subtle thing and requires a solid understanding of the platform.Do you have a characterization of the sort of content that will get automatically better vs the sort of content that will break?I'm not sure how clean a characterization it is, but we've recently written a bunch of exploratory code that creates scroll-linked effects like hidey bars by updating the transform on a number of elements to a value computed from the scroll offset. If that code receives a subpixel floating point number, it will do the same math and set the appropriate subpixel transform without any modification.That sounds reasonable. But do such scripts use anything other than scrollLeft/scrollTop?
Primary eng/PM emails
e...@chromium.org
Spec
http://www.w3.org/TR/cssom-view/#scrolloptionsvertical
Summary
The latest draft of the CSS OM spec changed the type for a number of
Element, HTMLElement and textRange properties from long to float.
Specifically the following properties:
Element::clientHeight
Element::clientWidth
Element::clientLeft
Element::clientTop
Element::scrollTop
Element::scrollLeft
Element::scrollWidth
Element::scrollHeight
HTMLElement::offsetWidth
HTMLElement::offsetHeight
HTMLElement::offsetTop
HTMLElement::offsetLeft
Those are now specified to return the full precision value, similarly
to Element::getClientRects and Element::getBoundingClientRect.
Motivation
IE has been supporting this on an opt-in basis since version 10 and
many complex web apps requires higher precision than rounded int
values. For offsetWidth and friends getClientRects is a viable
alternative but for scrollTop/Left/Width/Height no high precision
alternative exists.
Compatibility Risk
Firefox: No public signals
Internet Explorer: No public signals
Safari: No public signals
Web developers: Positive
This could have compatibility issues as we are changing the data
type for existing properties. Some websites may depend on the values
being integers.
Ongoing technical constraints
Cannot be controlled by runtime enabled feature with our existing
implementation as it modifies existing properties.
Will this feature be supported on all five Blink platforms (Windows, Mac, Linux,
Chrome OS, and Android)?
Yes
OWP launch tracking bug
http://www.w3.org/TR/cssom-view/#scrolloptionsvertical
Entry in Chromium Dashboard
http://www.chromestatus.com/admin/features/edit/5497402177880064
Requesting approval to ship?
Yes
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Boris,We should bring this up at the next CSSWG meeting. I agree with you that changing scrollTop/offsetWidth/offsetHeight is not web compatible and we should revert the spec change.
Dave,I would guess that gBRC is just as slow as offsetWidth/offsetTop, no? Both (and really any width measurement) require layout recalcs. Do you have a jsperf or something to show? When I looked into this for jQuery, I found gBRC to do a suitable replacement but didn't have the time to implement.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
Mike Sherov
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
-Boris
On 12/11/14, 1:02 AM, PhistucK wrote:
This seems to only affect zoomed pages, or pages viewed on high device
pixel ratio ('retina' like) screens. Am I correct?
I can't speak for Blink, but in Gecko you would not be correct.
Very sensible, Rick. We rely on jQuery to insulate us as much as possible from ongoing changes in W3C specs and browsers like this, and this issue manifested for us through jQuery's scrollTop() API. I believe your approach is correct for Chromium, and that developers who rely on jQuery for insulation need to make sure we're engaged with jQuery to keep API's compatible as browser functionality improves.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
But why would that happen? offsetWidth and the rest are supposed to give you the actual value, am I right?If so, on a 1 CSS pixel to 1 device pixel configuration, the actual value will not be fractional...
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
-Boris
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.