[webkit-dev] Exposing CSS pixel metrics to the scripting environment

[Charles Pritchard]

Recently I brought this issue up to the WHATWG mailing list, without 
much luck.


Currently, mobile devices are given access to window.devicePixelRatio, 
used for managing what are essentially higher resolution displays. See 
the iPhone, Android, etc. Within the desktop environment, 
devicePixelRatio is not updated on zoom events. I don't think it should 
be, but it's something to consider. Such information is critical to 
adjusting the resolution of bitmaps, be they from an image source or a 
canvas source, to be as crisp as can be.


Microsoft has gone ahead in IE9 and just exposed a collection of metrics 
data:

deviceXDPI, logicalXDPI, systemXDPI and "Y" counterparts.

Source:
http://msdn.microsoft.com/en-us/library/ms535868(VS.85).aspx 



The task at hand is deciding whether or not to expose this information, 
and where. Technically, it's quite simple, as it's only a few floating 
point values which are already available to the WebKit environment. Zoom 
events always trigger a 'resize' event for window, as they alter the 
innerWidth and innerHeight of the layout. That resize event is the point 
in which the scripting environment would check to see if CSS pixel 
metrics have changed, and adjust the page accordingly. I want to note, 
that I am not speaking at all about changing how zoom works, or in any 
way suggesting that zoom be controlled by the scripting environment / 
web authors.


I am recommending that we take a look at Microsoft's  .screen 
extensions, and decide whether they hold merit, and may be included in 
WebKit. Doing so would mean that an independent implementation has 
picked up the extension, and it may be on the fast track for 
standardization.


I had a rough time bringing this up with Mozilla. I'm hoping for a 
little more focus here, on this mailing list. Again, I'm merely looking 
to have CSS pixel metrics exposed, and I'm suggesting the MS proposal as 
it's certain to exist in their upcoming IE9 release. Their proposal 
exposes six floating point variables in the window.screen object, and is 
sufficient for current needs.


Please let me know thoughts on the matter, and try to keep focused on 
the fact that we're just looking to expose a few floating points to the 
scripting environment, we're not looking to change any existing 
behaviors in any existing elements.


-Charles
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Exposing CSS pixel metrics to the scripting environment

[James Robinson]

Are you posting here because there is something specific to WebKit in
your query or because you dislike the outcome of the WHATWG thread?
Most of us follow the WHATWG closely and generally prefer to discuss
standardization issues such as this in that forum to get a broader
feedback base.

- James

On Friday, November 26, 2010, Charles Pritchard  wrote:
> Recently I brought this issue up to the WHATWG mailing list, without much 
> luck.
>
> Currently, mobile devices are given access to window.devicePixelRatio, used 
> for managing what are essentially higher resolution displays. See the iPhone, 
> Android, etc. Within the desktop environment, devicePixelRatio is not updated 
> on zoom events. I don't think it should be, but it's something to consider. 
> Such information is critical to adjusting the resolution of bitmaps, be they 
> from an image source or a canvas source, to be as crisp as can be.
>
> Microsoft has gone ahead in IE9 and just exposed a collection of metrics data:
> deviceXDPI, logicalXDPI, systemXDPI and "Y" counterparts.
>
> Source:
> http://msdn.microsoft.com/en-us/library/ms535868(VS.85).aspx 
> 
>
> The task at hand is deciding whether or not to expose this information, and 
> where. Technically, it's quite simple, as it's only a few floating point 
> values which are already available to the WebKit environment. Zoom events 
> always trigger a 'resize' event for window, as they alter the innerWidth and 
> innerHeight of the layout. That resize event is the point in which the 
> scripting environment would check to see if CSS pixel metrics have changed, 
> and adjust the page accordingly. I want to note, that I am not speaking at 
> all about changing how zoom works, or in any way suggesting that zoom be 
> controlled by the scripting environment / web authors.
>
> I am recommending that we take a look at Microsoft's  .screen extensions, and 
> decide whether they hold merit, and may be included in WebKit. Doing so would 
> mean that an independent implementation has picked up the extension, and it 
> may be on the fast track for standardization.
>
> I had a rough time bringing this up with Mozilla. I'm hoping for a little 
> more focus here, on this mailing list. Again, I'm merely looking to have CSS 
> pixel metrics exposed, and I'm suggesting the MS proposal as it's certain to 
> exist in their upcoming IE9 release. Their proposal exposes six floating 
> point variables in the window.screen object, and is sufficient for current 
> needs.
>
> Please let me know thoughts on the matter, and try to keep focused on the 
> fact that we're just looking to expose a few floating points to the scripting 
> environment, we're not looking to change any existing behaviors in any 
> existing elements.
>
> -Charles
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Exposing CSS pixel metrics to the scripting environment

[Charles Pritchard]

The whatwg thread had no outcome other than the response of Mozilla reiterating 
their prior conclusion. I've posted to WebKit for further feedback.

I don't see what broad base might develop within whatwg. In all pragmatic 
aspects, webkit-dev seems to me the appropriate forum.

Moz has stated clearly, repeatedly, that they do not wish to make the 
information easily accessible. This conclusion was made prior to my defect 
report and was unaltered by it. As of this date, I do not believe any webkit 
contributors have voiced their opinion. I'd prefer to focus on the technical 
aspects and likelihood of adoption. I'm posting to webkit, as I like to see 
this issue resolved within the webkit code base.

-Charles


On Nov 26, 2010, at 10:13 PM, James Robinson  wrote:

> Are you posting here because there is something specific to WebKit in
> your query or because you dislike the outcome of the WHATWG thread?
> Most of us follow the WHATWG closely and generally prefer to discuss
> standardization issues such as this in that forum to get a broader
> feedback base.
> 
> - James
> 
> On Friday, November 26, 2010, Charles Pritchard  wrote:
>> Recently I brought this issue up to the WHATWG mailing list, without much 
>> luck.
>> 
>> Currently, mobile devices are given access to window.devicePixelRatio, used 
>> for managing what are essentially higher resolution displays. See the 
>> iPhone, Android, etc. Within the desktop environment, devicePixelRatio is 
>> not updated on zoom events. I don't think it should be, but it's something 
>> to consider. Such information is critical to adjusting the resolution of 
>> bitmaps, be they from an image source or a canvas source, to be as crisp as 
>> can be.
>> 
>> Microsoft has gone ahead in IE9 and just exposed a collection of metrics 
>> data:
>> deviceXDPI, logicalXDPI, systemXDPI and "Y" counterparts.
>> 
>> Source:
>> http://msdn.microsoft.com/en-us/library/ms535868(VS.85).aspx 
>> 
>> 
>> The task at hand is deciding whether or not to expose this information, and 
>> where. Technically, it's quite simple, as it's only a few floating point 
>> values which are already available to the WebKit environment. Zoom events 
>> always trigger a 'resize' event for window, as they alter the innerWidth and 
>> innerHeight of the layout. That resize event is the point in which the 
>> scripting environment would check to see if CSS pixel metrics have changed, 
>> and adjust the page accordingly. I want to note, that I am not speaking at 
>> all about changing how zoom works, or in any way suggesting that zoom be 
>> controlled by the scripting environment / web authors.
>> 
>> I am recommending that we take a look at Microsoft's  .screen extensions, 
>> and decide whether they hold merit, and may be included in WebKit. Doing so 
>> would mean that an independent implementation has picked up the extension, 
>> and it may be on the fast track for standardization.
>> 
>> I had a rough time bringing this up with Mozilla. I'm hoping for a little 
>> more focus here, on this mailing list. Again, I'm merely looking to have CSS 
>> pixel metrics exposed, and I'm suggesting the MS proposal as it's certain to 
>> exist in their upcoming IE9 release. Their proposal exposes six floating 
>> point variables in the window.screen object, and is sufficient for current 
>> needs.
>> 
>> Please let me know thoughts on the matter, and try to keep focused on the 
>> fact that we're just looking to expose a few floating points to the 
>> scripting environment, we're not looking to change any existing behaviors in 
>> any existing elements.
>> 
>> -Charles
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Exposing CSS pixel metrics to the scripting environment

[Adam Barth]

As a general rule, if Mozilla refuses to implement a feature, we're
unlikely to implement the feature unless there is a very compelling
reason to do so.  Proprietary features are harmful to the web, which
is why we prefer to discuss new features in standards bodies.

Adam


On Sat, Nov 27, 2010 at 3:08 AM, Charles Pritchard  wrote:
> The whatwg thread had no outcome other than the response of Mozilla 
> reiterating their prior conclusion. I've posted to WebKit for further 
> feedback.
>
> I don't see what broad base might develop within whatwg. In all pragmatic 
> aspects, webkit-dev seems to me the appropriate forum.
>
> Moz has stated clearly, repeatedly, that they do not wish to make the 
> information easily accessible. This conclusion was made prior to my defect 
> report and was unaltered by it. As of this date, I do not believe any webkit 
> contributors have voiced their opinion. I'd prefer to focus on the technical 
> aspects and likelihood of adoption. I'm posting to webkit, as I like to see 
> this issue resolved within the webkit code base.
>
> -Charles
>
>
> On Nov 26, 2010, at 10:13 PM, James Robinson  wrote:
>
>> Are you posting here because there is something specific to WebKit in
>> your query or because you dislike the outcome of the WHATWG thread?
>> Most of us follow the WHATWG closely and generally prefer to discuss
>> standardization issues such as this in that forum to get a broader
>> feedback base.
>>
>> - James
>>
>> On Friday, November 26, 2010, Charles Pritchard  wrote:
>>> Recently I brought this issue up to the WHATWG mailing list, without much 
>>> luck.
>>>
>>> Currently, mobile devices are given access to window.devicePixelRatio, used 
>>> for managing what are essentially higher resolution displays. See the 
>>> iPhone, Android, etc. Within the desktop environment, devicePixelRatio is 
>>> not updated on zoom events. I don't think it should be, but it's something 
>>> to consider. Such information is critical to adjusting the resolution of 
>>> bitmaps, be they from an image source or a canvas source, to be as crisp as 
>>> can be.
>>>
>>> Microsoft has gone ahead in IE9 and just exposed a collection of metrics 
>>> data:
>>> deviceXDPI, logicalXDPI, systemXDPI and "Y" counterparts.
>>>
>>> Source:
>>> http://msdn.microsoft.com/en-us/library/ms535868(VS.85).aspx 
>>> 
>>>
>>> The task at hand is deciding whether or not to expose this information, and 
>>> where. Technically, it's quite simple, as it's only a few floating point 
>>> values which are already available to the WebKit environment. Zoom events 
>>> always trigger a 'resize' event for window, as they alter the innerWidth 
>>> and innerHeight of the layout. That resize event is the point in which the 
>>> scripting environment would check to see if CSS pixel metrics have changed, 
>>> and adjust the page accordingly. I want to note, that I am not speaking at 
>>> all about changing how zoom works, or in any way suggesting that zoom be 
>>> controlled by the scripting environment / web authors.
>>>
>>> I am recommending that we take a look at Microsoft's  .screen extensions, 
>>> and decide whether they hold merit, and may be included in WebKit. Doing so 
>>> would mean that an independent implementation has picked up the extension, 
>>> and it may be on the fast track for standardization.
>>>
>>> I had a rough time bringing this up with Mozilla. I'm hoping for a little 
>>> more focus here, on this mailing list. Again, I'm merely looking to have 
>>> CSS pixel metrics exposed, and I'm suggesting the MS proposal as it's 
>>> certain to exist in their upcoming IE9 release. Their proposal exposes six 
>>> floating point variables in the window.screen object, and is sufficient for 
>>> current needs.
>>>
>>> Please let me know thoughts on the matter, and try to keep focused on the 
>>> fact that we're just looking to expose a few floating points to the 
>>> scripting environment, we're not looking to change any existing behaviors 
>>> in any existing elements.
>>>
>>> -Charles
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Exposing CSS pixel metrics to the scripting environment

[Charles Pritchard]

Yes, I certainly understand that.

Still hoping its something we could talk about here, and that Mozilla 
may have a change of mind.


Currently, within WebKit Chromium, there's a very hackish way of 
calculating the zoom ratio, by comparing innerWidth and outerWidth . 
This only works when there is no side bar present. The innerWidth is 
returned in CSS pixels, the outerWidth in device pixels. I don't know if 
that's a bug or not. I've not been able to bring any discussion about 
unity in window.*Width implementations, as we're still stuck on CSS 
metrics.


Here's the reasoning Mozilla has behind disallowing this information:
https://bugzilla.mozilla.org/show_bug.cgi?id=486200

Their refusal is not about the feature itself, but about whether that 
feature would be exposed to untrusted scripts outside of an extension 
context.


" I don't want Web authors to have easy access to information about 
screen pixels. They'll try to defeat our zooming or size things to 
screen pixels, which we don't want." ( Robert O'Callahan ).


The accessibility costs of withholding this information are very real. 
Mozilla's plan is to limit such information to media queries in CSS: the 
very hackish result of this would mean a dozen or so css declarations, 
calibrated for the Mozilla browser environment, then some JS to pull 
through and see which media queries were active. A proprietary, ugly, 
approach in itself.


I find it hard to accept that one man's decision to intentionally make 
things difficult would have such reaching and lasting consequences.




On 11/27/2010 8:15 AM, Adam Barth wrote:

As a general rule, if Mozilla refuses to implement a feature, we're
unlikely to implement the feature unless there is a very compelling
reason to do so.  Proprietary features are harmful to the web, which
is why we prefer to discuss new features in standards bodies.

Adam


On Sat, Nov 27, 2010 at 3:08 AM, Charles Pritchard  wrote:

The whatwg thread had no outcome other than the response of Mozilla reiterating 
their prior conclusion. I've posted to WebKit for further feedback.

I don't see what broad base might develop within whatwg. In all pragmatic 
aspects, webkit-dev seems to me the appropriate forum.

Moz has stated clearly, repeatedly, that they do not wish to make the 
information easily accessible. This conclusion was made prior to my defect 
report and was unaltered by it. As of this date, I do not believe any webkit 
contributors have voiced their opinion. I'd prefer to focus on the technical 
aspects and likelihood of adoption. I'm posting to webkit, as I like to see 
this issue resolved within the webkit code base.

-Charles


On Nov 26, 2010, at 10:13 PM, James Robinson  wrote:


Are you posting here because there is something specific to WebKit in
your query or because you dislike the outcome of the WHATWG thread?
Most of us follow the WHATWG closely and generally prefer to discuss
standardization issues such as this in that forum to get a broader
feedback base.

- James

On Friday, November 26, 2010, Charles Pritchard  wrote:

Recently I brought this issue up to the WHATWG mailing list, without much luck.

Currently, mobile devices are given access to window.devicePixelRatio, used for 
managing what are essentially higher resolution displays. See the iPhone, 
Android, etc. Within the desktop environment, devicePixelRatio is not updated 
on zoom events. I don't think it should be, but it's something to consider. 
Such information is critical to adjusting the resolution of bitmaps, be they 
from an image source or a canvas source, to be as crisp as can be.

Microsoft has gone ahead in IE9 and just exposed a collection of metrics data:
deviceXDPI, logicalXDPI, systemXDPI and "Y" counterparts.

Source:
http://msdn.microsoft.com/en-us/library/ms535868(VS.85).aspx

The task at hand is deciding whether or not to expose this information, and 
where. Technically, it's quite simple, as it's only a few floating point values 
which are already available to the WebKit environment. Zoom events always 
trigger a 'resize' event for window, as they alter the innerWidth and 
innerHeight of the layout. That resize event is the point in which the 
scripting environment would check to see if CSS pixel metrics have changed, and 
adjust the page accordingly. I want to note, that I am not speaking at all 
about changing how zoom works, or in any way suggesting that zoom be controlled 
by the scripting environment / web authors.

I am recommending that we take a look at Microsoft's  .screen extensions, and 
decide whether they hold merit, and may be included in WebKit. Doing so would 
mean that an independent implementation has picked up the extension, and it may 
be on the fast track for standardization.

I had a rough time bringing this up with Mozilla. I'm hoping for a little more 
focus here, on this mailing list. Again, I'm merely looking to have CSS pixel 
metri

Re: [webkit-dev] Exposing CSS pixel metrics to the scripting environment

[Adam Barth]

I usually avoid issues related to rendering, but this discussion
sounds more like a power struggle than a technical issue.  Roc's
comments sound like he doesn't think web sites should have
zoom-specific behaviors, whereas you seem interested in implementing
zoom-specific behavior.  One of the benefits of the standards process
is that they sort out these kinds of arm-wrestling matches.

This list is more focused on the nuts and bolts of WebKit development.
 For example, the recent thread about how, architecturally, we should
use mock objects for testing is more on-topic than a thread about a
specific feature request.

I don't mean to be off-putting.  I'm glad that you share our
enthusiasm for WebKit specifically and the web more generally.  If
you're interested in contributing to WebKit, a good place to start is
by fixing bugs.  If you're interested in shaping the direction of the
web platform, I'd encourage you to do that by participating in
standards bodies.

Adam


On Sat, Nov 27, 2010 at 10:19 AM, Charles Pritchard  wrote:
> Yes, I certainly understand that.
>
> Still hoping its something we could talk about here, and that Mozilla may
> have a change of mind.
>
> Currently, within WebKit Chromium, there's a very hackish way of calculating
> the zoom ratio, by comparing innerWidth and outerWidth . This only works
> when there is no side bar present. The innerWidth is returned in CSS pixels,
> the outerWidth in device pixels. I don't know if that's a bug or not. I've
> not been able to bring any discussion about unity in window.*Width
> implementations, as we're still stuck on CSS metrics.
>
> Here's the reasoning Mozilla has behind disallowing this information:
> https://bugzilla.mozilla.org/show_bug.cgi?id=486200
>
> Their refusal is not about the feature itself, but about whether that
> feature would be exposed to untrusted scripts outside of an extension
> context.
>
> " I don't want Web authors to have easy access to information about
> screen pixels. They'll try to defeat our zooming or size things to screen
> pixels, which we don't want." ( Robert O'Callahan ).
>
> The accessibility costs of withholding this information are very real.
> Mozilla's plan is to limit such information to media queries in CSS: the
> very hackish result of this would mean a dozen or so css declarations,
> calibrated for the Mozilla browser environment, then some JS to pull through
> and see which media queries were active. A proprietary, ugly, approach in
> itself.
>
> I find it hard to accept that one man's decision to intentionally make
> things difficult would have such reaching and lasting consequences.
>
>
>
> On 11/27/2010 8:15 AM, Adam Barth wrote:
>>
>> As a general rule, if Mozilla refuses to implement a feature, we're
>> unlikely to implement the feature unless there is a very compelling
>> reason to do so.  Proprietary features are harmful to the web, which
>> is why we prefer to discuss new features in standards bodies.
>>
>> Adam
>>
>>
>> On Sat, Nov 27, 2010 at 3:08 AM, Charles Pritchard
>>  wrote:
>>>
>>> The whatwg thread had no outcome other than the response of Mozilla
>>> reiterating their prior conclusion. I've posted to WebKit for further
>>> feedback.
>>>
>>> I don't see what broad base might develop within whatwg. In all pragmatic
>>> aspects, webkit-dev seems to me the appropriate forum.
>>>
>>> Moz has stated clearly, repeatedly, that they do not wish to make the
>>> information easily accessible. This conclusion was made prior to my defect
>>> report and was unaltered by it. As of this date, I do not believe any webkit
>>> contributors have voiced their opinion. I'd prefer to focus on the technical
>>> aspects and likelihood of adoption. I'm posting to webkit, as I like to see
>>> this issue resolved within the webkit code base.
>>>
>>> -Charles
>>>
>>>
>>> On Nov 26, 2010, at 10:13 PM, James Robinson  wrote:
>>>
 Are you posting here because there is something specific to WebKit in
 your query or because you dislike the outcome of the WHATWG thread?
 Most of us follow the WHATWG closely and generally prefer to discuss
 standardization issues such as this in that forum to get a broader
 feedback base.

 - James

 On Friday, November 26, 2010, Charles Pritchard  wrote:
>
> Recently I brought this issue up to the WHATWG mailing list, without
> much luck.
>
> Currently, mobile devices are given access to window.devicePixelRatio,
> used for managing what are essentially higher resolution displays. See the
> iPhone, Android, etc. Within the desktop environment, devicePixelRatio is
> not updated on zoom events. I don't think it should be, but it's something
> to consider. Such information is critical to adjusting the resolution of
> bitmaps, be they from an image source or a canvas source, to be as crisp 
> as
> can be.
>
> Microsoft has gone ahead in IE9 and just exposed a collection of
> metrics data:

Re: [webkit-dev] Exposing CSS pixel metrics to the scripting environment

[Charles Pritchard]

I agree, it's a power struggle, not a technical issue, at this point. 
The use cases/defect

is technical, but the solution is stuck entirely on politics.

Circling back to rendering... Roc's suggestion of altering the standard 
behavior of the Canvas element
is on topic: he'd like to resize the canvas backing store to match css 
pixels when a
canvas element is reinitialized. I believe this would be a non-standard 
behavior, one which

would change how ImageData works.

I'm certainly participating in the standard bodies. I'll keep pushing 
the issue there.


I am trying to develop some consensus between vendors to unify some 
existing API behaviors.


At this point, I don't have the bandwidth to directly fix bugs, but I've 
been doing
my best to file them and draw developers attention to them. It's been 
working very well,

which has led me to greater enthusiasm toward WebKit.

-Charles

On 11/27/2010 10:34 AM, Adam Barth wrote:

I usually avoid issues related to rendering, but this discussion
sounds more like a power struggle than a technical issue.  Roc's
comments sound like he doesn't think web sites should have
zoom-specific behaviors, whereas you seem interested in implementing
zoom-specific behavior.  One of the benefits of the standards process
is that they sort out these kinds of arm-wrestling matches.

This list is more focused on the nuts and bolts of WebKit development.
  For example, the recent thread about how, architecturally, we should
use mock objects for testing is more on-topic than a thread about a
specific feature request.

I don't mean to be off-putting.  I'm glad that you share our
enthusiasm for WebKit specifically and the web more generally.  If
you're interested in contributing to WebKit, a good place to start is
by fixing bugs.  If you're interested in shaping the direction of the
web platform, I'd encourage you to do that by participating in
standards bodies.

Adam


On Sat, Nov 27, 2010 at 10:19 AM, Charles Pritchard  wrote:

Yes, I certainly understand that.

Still hoping its something we could talk about here, and that Mozilla may
have a change of mind.

Currently, within WebKit Chromium, there's a very hackish way of calculating
the zoom ratio, by comparing innerWidth and outerWidth . This only works
when there is no side bar present. The innerWidth is returned in CSS pixels,
the outerWidth in device pixels. I don't know if that's a bug or not. I've
not been able to bring any discussion about unity in window.*Width
implementations, as we're still stuck on CSS metrics.

Here's the reasoning Mozilla has behind disallowing this information:
https://bugzilla.mozilla.org/show_bug.cgi?id=486200

Their refusal is not about the feature itself, but about whether that
feature would be exposed to untrusted scripts outside of an extension
context.

" I don't want Web authors to have easy access to information about
screen pixels. They'll try to defeat our zooming or size things to screen
pixels, which we don't want." ( Robert O'Callahan ).

The accessibility costs of withholding this information are very real.
Mozilla's plan is to limit such information to media queries in CSS: the
very hackish result of this would mean a dozen or so css declarations,
calibrated for the Mozilla browser environment, then some JS to pull through
and see which media queries were active. A proprietary, ugly, approach in
itself.

I find it hard to accept that one man's decision to intentionally make
things difficult would have such reaching and lasting consequences.



On 11/27/2010 8:15 AM, Adam Barth wrote:

As a general rule, if Mozilla refuses to implement a feature, we're
unlikely to implement the feature unless there is a very compelling
reason to do so.  Proprietary features are harmful to the web, which
is why we prefer to discuss new features in standards bodies.

Adam


On Sat, Nov 27, 2010 at 3:08 AM, Charles Pritchard
  wrote:

The whatwg thread had no outcome other than the response of Mozilla
reiterating their prior conclusion. I've posted to WebKit for further
feedback.

I don't see what broad base might develop within whatwg. In all pragmatic
aspects, webkit-dev seems to me the appropriate forum.

Moz has stated clearly, repeatedly, that they do not wish to make the
information easily accessible. This conclusion was made prior to my defect
report and was unaltered by it. As of this date, I do not believe any webkit
contributors have voiced their opinion. I'd prefer to focus on the technical
aspects and likelihood of adoption. I'm posting to webkit, as I like to see
this issue resolved within the webkit code base.

-Charles


On Nov 26, 2010, at 10:13 PM, James Robinsonwrote:


Are you posting here because there is something specific to WebKit in
your query or because you dislike the outcome of the WHATWG thread?
Most of us follow the WHATWG closely and generally prefer to discuss
standardization issues such as this in that forum to get a broader
feedback base.

- James

On Friday, Nove

Re: [webkit-dev] Exposing CSS pixel metrics to the scripting environment

[Charles Pritchard]

Looks like I'm digging myself deeper into a hole here.

I'm running this issue through the W3C per your suggestions.

I'll open up an item in the bug tracker if / when there's movement in 
the specs.


Thanks all.

-Charles

On 11/27/2010 10:46 AM, Julian Reschke wrote:

Charles,

I recommend that you follow up in a W3C mailing list/issue tracker.

Best regards, Julian


On 27.11.2010 02:16, Charles Pritchard wrote:

Recently I brought this issue up to the WHATWG mailing list, without
much luck.

Currently, mobile devices are given access to window.devicePixelRatio,
used for managing what are essentially higher resolution displays. See
the iPhone, Android, etc. Within the desktop environment,
devicePixelRatio is not updated on zoom events. I don't think it should
be, but it's something to consider. Such information is critical to
adjusting the resolution of bitmaps, be they from an image source or a
canvas source, to be as crisp as can be.


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev