Re: [webkit-dev] progress/meter/input[type=range] orientation and implications in WebKit

[Dimitri Glazkov]

On Fri, Mar 4, 2011 at 12:16 PM, Ian Hickson  wrote:
> On Fri, 4 Mar 2011, Dimitri Glazkov wrote:
>>
>> Today, we happily use -webkit-appearance to apply platform-specific
>> appearance to the controls. The trouble is, the value of
>> -webkit-appearance is going to be different depending on the value of
>> logical width.
>
> Why not have a value of 'appearance' that automatically uses the right
> orientation, instead of having orientation-specific values?

You are correct, the theme can paint correctly oriented slider
controls in by looking at the box size it's painting. Hyatt pointed
out the same thing on #webkit.

However, the issue still exists in the cases of meter and progress.
They are using plain-old CSS gradient rules, not magic platform
painter (calked RenderTheme in WebKit).

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

Re: [webkit-dev] ANGLE out of date?

[Mo, Zhenyao]

Angle in webkit is only the shader translator, which doesn't change
very often, whereas the main Angle (GLES simulation on top of D3D) is
still under active development.

We should update webkit Angle from time to time, but if it's outdated,
no need to be alarmed.  We definitely don't need to update Angle
whenever there is a new revision.

Mo

On Fri, Mar 4, 2011 at 3:05 PM, Adam Barth  wrote:
> Our version of ANGLE seems to be out of date:
>
> http://trac.webkit.org/browser/trunk/Source/ThirdParty/ANGLE
> http://code.google.com/p/angleproject/source/browse/trunk
>
> Who owns keeping our copy updated?
>
> Adam
> ___
> 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] ANGLE out of date?

[Adam Barth]

Our version of ANGLE seems to be out of date:

http://trac.webkit.org/browser/trunk/Source/ThirdParty/ANGLE
http://code.google.com/p/angleproject/source/browse/trunk

Who owns keeping our copy updated?

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

Re: [webkit-dev] Canvas backing resolution

[Charles Pritchard]

We do receive a resize event when zoom happens. That's what I'm currently 
hooked into.



On Mar 4, 2011, at 12:29 PM, Kenneth Rohde Christiansen 
 wrote:

> I guess that is not even possible, as I would need to subscribe to
> something like "(-min-webkit-device-pixel-ratio: 1.0)" and will only
> be notified in case the evaluation of that exact expression changes.
> Maybe that spec is lacking a way to subscribe to arbitrary changes in
> say device-pixel-ratio.
> 
> It does feel a bit expensive, but then again we are only reevaluation
> after pinch end, so I guess that would be fully OK.
> 
> Kenneth
> 
> On Fri, Mar 4, 2011 at 9:02 PM, Kenneth Rohde Christiansen
>  wrote:
>> Hi Simon,
>> 
>> I guess you could use the media query listener defined in
>> http://dev.w3.org/csswg/cssom-view/#the-mediaquerylist-interface
>> 
>> We support that on trunk now. This of course means that we will need
>> to reevaluate the CSS when a pinch zoom ends, which we might be doing
>> already given media queries such as @media all and (min-width: 200px).
>> 
>> Cheers
>> Kenneth
>> 
>> On Fri, Mar 4, 2011 at 8:47 PM, Simon Fraser  wrote:
>>> On Mar 4, 2011, at 11:24 AM, Kenneth Rohde Christiansen wrote:
>>> 
 Hey Oliver!
 
 If you are saying that device-pixel-ratio should include the user
 scaling, then I can push that for Qt, but I would really like seeing
 it supported by iOS as well for compatibility reasons. If you create a
 bug for that, please cc me.
>>> 
>>> There's a problem with that, which is that the author can assume (possibly 
>>> erroneously) that device-pixel-ratio doesn't change for the life of the 
>>> page. However, the zoom level can change often, and there's no notification 
>>> that the author can register for that will tell them when the zoom level 
>>> changes, and thus when they'll need to redraw their canvas contents.
>>> 
>>> Simon
>>> 
>>> 
>> 
>> 
>> 
>> --
>> Kenneth Rohde Christiansen
>> Senior Engineer
>> Application and Service Frameworks, Nokia Danmark A/S
>> Phone  +45 4093 0598 / E-mail kenneth.christiansen at gmail.com
>> 
>> http://codeposts.blogspot.com ﹆﹆﹆
>> 
> 
> 
> 
> -- 
> Kenneth Rohde Christiansen
> Senior Engineer
> Application and Service Frameworks, Nokia Danmark A/S
> Phone  +45 4093 0598 / E-mail kenneth.christiansen at gmail.com
> 
> http://codeposts.blogspot.com ﹆﹆﹆
> ___
> 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] Canvas backing resolution

[Kenneth Rohde Christiansen]

I guess that is not even possible, as I would need to subscribe to
something like "(-min-webkit-device-pixel-ratio: 1.0)" and will only
be notified in case the evaluation of that exact expression changes.
Maybe that spec is lacking a way to subscribe to arbitrary changes in
say device-pixel-ratio.

It does feel a bit expensive, but then again we are only reevaluation
after pinch end, so I guess that would be fully OK.

Kenneth

On Fri, Mar 4, 2011 at 9:02 PM, Kenneth Rohde Christiansen
 wrote:
> Hi Simon,
>
> I guess you could use the media query listener defined in
> http://dev.w3.org/csswg/cssom-view/#the-mediaquerylist-interface
>
> We support that on trunk now. This of course means that we will need
> to reevaluate the CSS when a pinch zoom ends, which we might be doing
> already given media queries such as @media all and (min-width: 200px).
>
> Cheers
> Kenneth
>
> On Fri, Mar 4, 2011 at 8:47 PM, Simon Fraser  wrote:
>> On Mar 4, 2011, at 11:24 AM, Kenneth Rohde Christiansen wrote:
>>
>>> Hey Oliver!
>>>
>>> If you are saying that device-pixel-ratio should include the user
>>> scaling, then I can push that for Qt, but I would really like seeing
>>> it supported by iOS as well for compatibility reasons. If you create a
>>> bug for that, please cc me.
>>
>> There's a problem with that, which is that the author can assume (possibly 
>> erroneously) that device-pixel-ratio doesn't change for the life of the 
>> page. However, the zoom level can change often, and there's no notification 
>> that the author can register for that will tell them when the zoom level 
>> changes, and thus when they'll need to redraw their canvas contents.
>>
>> Simon
>>
>>
>
>
>
> --
> Kenneth Rohde Christiansen
> Senior Engineer
> Application and Service Frameworks, Nokia Danmark A/S
> Phone  +45 4093 0598 / E-mail kenneth.christiansen at gmail.com
>
> http://codeposts.blogspot.com ﹆﹆﹆
>



-- 
Kenneth Rohde Christiansen
Senior Engineer
Application and Service Frameworks, Nokia Danmark A/S
Phone  +45 4093 0598 / E-mail kenneth.christiansen at gmail.com

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

Re: [webkit-dev] progress/meter/input[type=range] orientation and implications in WebKit

[Ian Hickson]

On Fri, 4 Mar 2011, Dimitri Glazkov wrote:
> 
> Today, we happily use -webkit-appearance to apply platform-specific 
> appearance to the controls. The trouble is, the value of 
> -webkit-appearance is going to be different depending on the value of 
> logical width.

Why not have a value of 'appearance' that automatically uses the right 
orientation, instead of having orientation-specific values?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Canvas backing resolution

[Kenneth Rohde Christiansen]

Hi Simon,

I guess you could use the media query listener defined in
http://dev.w3.org/csswg/cssom-view/#the-mediaquerylist-interface

We support that on trunk now. This of course means that we will need
to reevaluate the CSS when a pinch zoom ends, which we might be doing
already given media queries such as @media all and (min-width: 200px).

Cheers
Kenneth

On Fri, Mar 4, 2011 at 8:47 PM, Simon Fraser  wrote:
> On Mar 4, 2011, at 11:24 AM, Kenneth Rohde Christiansen wrote:
>
>> Hey Oliver!
>>
>> If you are saying that device-pixel-ratio should include the user
>> scaling, then I can push that for Qt, but I would really like seeing
>> it supported by iOS as well for compatibility reasons. If you create a
>> bug for that, please cc me.
>
> There's a problem with that, which is that the author can assume (possibly 
> erroneously) that device-pixel-ratio doesn't change for the life of the page. 
> However, the zoom level can change often, and there's no notification that 
> the author can register for that will tell them when the zoom level changes, 
> and thus when they'll need to redraw their canvas contents.
>
> Simon
>
>



-- 
Kenneth Rohde Christiansen
Senior Engineer
Application and Service Frameworks, Nokia Danmark A/S
Phone  +45 4093 0598 / E-mail kenneth.christiansen at gmail.com

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

Re: [webkit-dev] process for unreviewed commits

[Eric Seidel]

Another angle to attack this problem from is to make our OOPS system
less confusing.  New committers are very often confused as to what
OOPS is or does.  I made an attempt to make our changelog template
more explanatory at one point, but perhaps someone could make a better
one.

In either case, the CQ has trouble differentiating between intentional
omission of reviewed information and mistakes by new committers.  This
was one attempt at a solution, I'm sure we can find better. :)

On Fri, Mar 4, 2011 at 11:50 AM, Eric Seidel  wrote:
> The code is here:
> http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/tool/steps/validatereviewer.py#L38
>
> The original bug is here:
> https://bugs.webkit.org/show_bug.cgi?id=26927
>
> "unreviewed" (or similar text) serves to differentiate between the
> case where someone just mangled the "Reviewed by" line and when there
> actually should be no reviewer.
>
> The commit queue doesn't care if there is a reviewer for changes
> (aside from this check).  It just knows how to commit patches when a
> valid committer tells it to. :)  This enables it to do rollouts and
> land-safely, etc.
>
>
> Examples of cases this check is trying to catch:
> Reviewed by NOBODY.
> Not reviewed yet.
> (no review line at all)
>
> r78566, r72854, r72061, r71706, r65547 are some recent examples of
> strange Reviewed By lines.  (I ignored all the ones with OOPS in them,
> of which there were many).
>
> I'm happy to remove the support for preventing bad Reviewed By lines,
> assuming I'm given full immunity to further complaints. :)
>
> -eric
>
> On Fri, Mar 4, 2011 at 1:27 AM, Ojan Vafai  wrote:
>> Why does the commit-queue need to do more than just looking for OOPS?
>>
>> On Fri, Mar 4, 2011 at 7:37 PM, Eric Seidel  wrote:
>>>
>>> The unreviewed bit is currently used by the scripts (like the
>>> commit-queue) to help them understand that the patch is intentionally
>>> unreviewed.
>>>
>>> I don't know what the "official" process is.  But certainly some
>>> amount of "this is intentionally missing a review" information is
>>> useful for the commit-queue.  Feel free to change how that's conveyed.
>>>
>>> -eric
>>>
>>> On Thu, Mar 3, 2011 at 11:58 PM, Ojan Vafai  wrote:
>>> > This isn't a big deal either way, but I noticed
>>> >
>>> > that http://trac.webkit.org/wiki/CommitterTips#Walkingyouthroughyourfirstcommit
>>> > lists the following as the process for unreviewed commits: "Unreviewed
>>> > commits should include a line saying "Unreviewed." in place of the
>>> > "Reviewed
>>> > By..." line in each ChangeLog entry."
>>> > The "Unreviewed" bit is news to me. I thought it was assumed that if
>>> > there's
>>> > no "Reviewed By..." line then it was committed unreviewed and, in fact,
>>> > that
>>> > was preferred to adding the "Unreviewed" line.
>>> > Ojan
>>> > ___
>>> > 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] process for unreviewed commits

[Eric Seidel]

The code is here:
http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/tool/steps/validatereviewer.py#L38

The original bug is here:
https://bugs.webkit.org/show_bug.cgi?id=26927

"unreviewed" (or similar text) serves to differentiate between the
case where someone just mangled the "Reviewed by" line and when there
actually should be no reviewer.

The commit queue doesn't care if there is a reviewer for changes
(aside from this check).  It just knows how to commit patches when a
valid committer tells it to. :)  This enables it to do rollouts and
land-safely, etc.


Examples of cases this check is trying to catch:
Reviewed by NOBODY.
Not reviewed yet.
(no review line at all)

r78566, r72854, r72061, r71706, r65547 are some recent examples of
strange Reviewed By lines.  (I ignored all the ones with OOPS in them,
of which there were many).

I'm happy to remove the support for preventing bad Reviewed By lines,
assuming I'm given full immunity to further complaints. :)

-eric

On Fri, Mar 4, 2011 at 1:27 AM, Ojan Vafai  wrote:
> Why does the commit-queue need to do more than just looking for OOPS?
>
> On Fri, Mar 4, 2011 at 7:37 PM, Eric Seidel  wrote:
>>
>> The unreviewed bit is currently used by the scripts (like the
>> commit-queue) to help them understand that the patch is intentionally
>> unreviewed.
>>
>> I don't know what the "official" process is.  But certainly some
>> amount of "this is intentionally missing a review" information is
>> useful for the commit-queue.  Feel free to change how that's conveyed.
>>
>> -eric
>>
>> On Thu, Mar 3, 2011 at 11:58 PM, Ojan Vafai  wrote:
>> > This isn't a big deal either way, but I noticed
>> >
>> > that http://trac.webkit.org/wiki/CommitterTips#Walkingyouthroughyourfirstcommit
>> > lists the following as the process for unreviewed commits: "Unreviewed
>> > commits should include a line saying "Unreviewed." in place of the
>> > "Reviewed
>> > By..." line in each ChangeLog entry."
>> > The "Unreviewed" bit is news to me. I thought it was assumed that if
>> > there's
>> > no "Reviewed By..." line then it was committed unreviewed and, in fact,
>> > that
>> > was preferred to adding the "Unreviewed" line.
>> > Ojan
>> > ___
>> > 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] Canvas backing resolution

[Simon Fraser]

On Mar 4, 2011, at 11:24 AM, Kenneth Rohde Christiansen wrote:

> Hey Oliver!
> 
> If you are saying that device-pixel-ratio should include the user
> scaling, then I can push that for Qt, but I would really like seeing
> it supported by iOS as well for compatibility reasons. If you create a
> bug for that, please cc me.

There's a problem with that, which is that the author can assume (possibly 
erroneously) that device-pixel-ratio doesn't change for the life of the page. 
However, the zoom level can change often, and there's no notification that the 
author can register for that will tell them when the zoom level changes, and 
thus when they'll need to redraw their canvas contents.

Simon

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

Re: [webkit-dev] Canvas backing resolution

[Kenneth Rohde Christiansen]

Hey Oliver!

If you are saying that device-pixel-ratio should include the user
scaling, then I can push that for Qt, but I would really like seeing
it supported by iOS as well for compatibility reasons. If you create a
bug for that, please cc me.

Kenneth

On Fri, Mar 4, 2011 at 8:11 PM, Oliver Hunt  wrote:
> WebKit's canvas implementation has always scaled the backing buffer according 
> to actual screen resolution,  i suspect it doesn't pay any attention to zoom 
> however :-/
>
> Arguably that's a bug.
>
> --Oliver
>
> On Mar 4, 2011, at 10:08 AM, Charles Pritchard wrote:
>
>> In the future?
>>
>>
>>
>> On Mar 4, 2011, at 8:51 AM, Oliver Hunt  wrote:
>>
>>> For reference desktop webkit implementations will automatically increase 
>>> the canvas backing store resolution as the device:css pixel ratio increases.
>>>
>>> --Oliver
>>>
>>> On Mar 4, 2011, at 1:44 AM, Charles Pritchard wrote:
>>>
 On 3/4/2011 1:35 AM, Kenneth Rohde Christiansen wrote:
> Hi again,
>
>> I'm trying to keep the canvas bitmap at the same pixel resolution as the
>> device,
>> otherwise it is blurry.
> OK, I see.
>
>> This, for example, works if the pixel ratio is 2.
>> > height="200">
>>
>> Yes, when the user has a zoom level set, I'd like to paint to match the
>> pixel ratio,
>> so that, a zoomed in user still receives crisp output, instead of blurry
>> output.
> -webkit-device-pixel-ratio does not change when the user scaled the
> content; it is a device value.
>
> On old iPhone it is 1.0, on Android it can be 0.5, 1.0 and 1.5
> depending on it being a low, medium (160) or high dpi (240) device. On
> the iPhone 4 and the new iPod Touch it is 2.0.
>
> On Android devices, with for instance, a device-pixel-ratio of 1.5,
> you can disable the upscaling by adding target-densitydpi=device-dpi
> to the viewport meta tag.
>
> What you can do is to disable user scaling (add user-scaling=no to the
> viewport meta tag) and then handle zooming in your app using the touch
> events. This only works on mobile devices though.

 I haven't debugged with enough tablet devices, such as the color kindle, 
 to know how many webkit distros it works with.
 What should I do about user zoom on the desktop (and possibly, the kindle) 
 ?

 Drawing in high res, just-in-case, makes for a poorer experience for users 
 at a 1.0 ratio,
 and asking users to slide a "sharpen" slider is a little awkward.

 Mozilla, in their implementation, has setup device-pixel-ratio to scale 
 when the user scales content;
 they directly expose window css pixel ratio value to trusted scripts, but 
 not to web content; requiring
 web content to use css device-pixel-ratio.

 Microsoft has exposed the values through window.screen.



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



-- 
Kenneth Rohde Christiansen
Senior Engineer
Application and Service Frameworks, Nokia Danmark A/S
Phone  +45 4093 0598 / E-mail kenneth.christiansen at gmail.com

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

Re: [webkit-dev] Canvas backing resolution

[Oliver Hunt]

WebKit's canvas implementation has always scaled the backing buffer according 
to actual screen resolution,  i suspect it doesn't pay any attention to zoom 
however :-/

Arguably that's a bug.

--Oliver

On Mar 4, 2011, at 10:08 AM, Charles Pritchard wrote:

> In the future?
> 
> 
> 
> On Mar 4, 2011, at 8:51 AM, Oliver Hunt  wrote:
> 
>> For reference desktop webkit implementations will automatically increase the 
>> canvas backing store resolution as the device:css pixel ratio increases.
>> 
>> --Oliver
>> 
>> On Mar 4, 2011, at 1:44 AM, Charles Pritchard wrote:
>> 
>>> On 3/4/2011 1:35 AM, Kenneth Rohde Christiansen wrote:
 Hi again,
 
> I'm trying to keep the canvas bitmap at the same pixel resolution as the
> device,
> otherwise it is blurry.
 OK, I see.
 
> This, for example, works if the pixel ratio is 2.
>  height="200">
> 
> Yes, when the user has a zoom level set, I'd like to paint to match the
> pixel ratio,
> so that, a zoomed in user still receives crisp output, instead of blurry
> output.
 -webkit-device-pixel-ratio does not change when the user scaled the
 content; it is a device value.
 
 On old iPhone it is 1.0, on Android it can be 0.5, 1.0 and 1.5
 depending on it being a low, medium (160) or high dpi (240) device. On
 the iPhone 4 and the new iPod Touch it is 2.0.
 
 On Android devices, with for instance, a device-pixel-ratio of 1.5,
 you can disable the upscaling by adding target-densitydpi=device-dpi
 to the viewport meta tag.
 
 What you can do is to disable user scaling (add user-scaling=no to the
 viewport meta tag) and then handle zooming in your app using the touch
 events. This only works on mobile devices though.
>>> 
>>> I haven't debugged with enough tablet devices, such as the color kindle, to 
>>> know how many webkit distros it works with.
>>> What should I do about user zoom on the desktop (and possibly, the kindle) ?
>>> 
>>> Drawing in high res, just-in-case, makes for a poorer experience for users 
>>> at a 1.0 ratio,
>>> and asking users to slide a "sharpen" slider is a little awkward.
>>> 
>>> Mozilla, in their implementation, has setup device-pixel-ratio to scale 
>>> when the user scales content;
>>> they directly expose window css pixel ratio value to trusted scripts, but 
>>> not to web content; requiring
>>> web content to use css device-pixel-ratio.
>>> 
>>> Microsoft has exposed the values through window.screen.
>>> 
>>> 
>>> 
>>> -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] progress/meter/input[type=range] orientation and implications in WebKit

[Dimitri Glazkov]

Dear WebKit,

It seems we have a bit of a conundrum with spec-conforming element
rendering. The 
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-meter-element-0,
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-progress-element-0,
and 
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-input-element-as-a-range-control
all state something along these lines:

"When the control is wider than it is tall (or square), the control is
expected to be a horizontal slider, with the lowest value on the right
if the 'direction' property on this element has a computed value of
'rtl', and on the left otherwise. When the control is taller than it
is wide, it is expected to be a vertical slider, with the lowest value
on the bottom."

How shall we accomplish this?

Today, we happily use -webkit-appearance to apply platform-specific
appearance to the controls. The trouble is, the value of
-webkit-appearance is going to be different depending on the value of
logical width.

For example, consider 

http://jsfiddle.net/dglazkov/qmnKN/1/embedded/result/

If the logical width of the control is over 200px, the property
-webkit-appearance: sliderthumb-horizontal applies to it.

As you size the window down, at the point where the width of the
control is less than 200px, the property -webkit-appearance:
sliderthumb-vertical should start apply to it.

One could imagine something like this for a set of rules to describe this:

input[type=range]:horizontal::-webkit-slider-thumb {
-webkit-appearance: sliderthumb-horizontal;
}

input[type=range]:vertical::-webkit-slider-thumb {
-webkit-appearance: sliderthumb-vertical;
}

where "horizontal" and "vertical" pseudo-classes are applied according
to logical width/height ration of the control box. This seems gross,
since we'll need to create a new rendering primitive
(RenderGrossOrientationAwareBox?), which re-matches style during
layout, as early as the logical width of a box can be determined.

Tab pointed out to me that introducing something like this would also
be a bad idea, since the logical width/height ration may be affected
by the newly-re-matched rules:

foo:vertical {
width: 1px; /* no longer vertical */
}

So it sucks. Please help with better ideas?

Our options:

a) add a gross hack in layout for these elements to re-match style
after calculating logical width
b) do something even grosser.
c) do something more brilliant.
d) not implement this part of the spec.

P.S. This is a continuation of discussion on
https://bugs.webkit.org/show_bug.cgi?id=54440.

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

Re: [webkit-dev] process for unreviewed commits

[Martin Robinson]

On Thu, Mar 3, 2011 at 11:58 PM, Ojan Vafai  wrote:
> This isn't a big deal either way, but I noticed
> that http://trac.webkit.org/wiki/CommitterTips#Walkingyouthroughyourfirstcommit
> lists the following as the process for unreviewed commits: "Unreviewed
> commits should include a line saying "Unreviewed." in place of the "Reviewed
> By..." line in each ChangeLog entry."
> The "Unreviewed" bit is news to me. I thought it was assumed that if there's
> no "Reviewed By..." line then it was committed unreviewed and, in fact, that
> was preferred to adding the "Unreviewed" line.

This was also discussed some months ago, though perhaps things have
changed since then:
https://lists.webkit.org/pipermail/webkit-dev/2010-July/013712.html

It seems that the consensus was that non-bot commits should not
include "Unreviewed" or "Not reviewed." Disclaimer: I have no
preference one way or the other, but thought I should link to the
previous discussion.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Canvas backing resolution

[Charles Pritchard]

In the future?



On Mar 4, 2011, at 8:51 AM, Oliver Hunt  wrote:

> For reference desktop webkit implementations will automatically increase the 
> canvas backing store resolution as the device:css pixel ratio increases.
> 
> --Oliver
> 
> On Mar 4, 2011, at 1:44 AM, Charles Pritchard wrote:
> 
>> On 3/4/2011 1:35 AM, Kenneth Rohde Christiansen wrote:
>>> Hi again,
>>> 
 I'm trying to keep the canvas bitmap at the same pixel resolution as the
 device,
 otherwise it is blurry.
>>> OK, I see.
>>> 
 This, for example, works if the pixel ratio is 2.
 >>> height="200">
 
 Yes, when the user has a zoom level set, I'd like to paint to match the
 pixel ratio,
 so that, a zoomed in user still receives crisp output, instead of blurry
 output.
>>> -webkit-device-pixel-ratio does not change when the user scaled the
>>> content; it is a device value.
>>> 
>>> On old iPhone it is 1.0, on Android it can be 0.5, 1.0 and 1.5
>>> depending on it being a low, medium (160) or high dpi (240) device. On
>>> the iPhone 4 and the new iPod Touch it is 2.0.
>>> 
>>> On Android devices, with for instance, a device-pixel-ratio of 1.5,
>>> you can disable the upscaling by adding target-densitydpi=device-dpi
>>> to the viewport meta tag.
>>> 
>>> What you can do is to disable user scaling (add user-scaling=no to the
>>> viewport meta tag) and then handle zooming in your app using the touch
>>> events. This only works on mobile devices though.
>> 
>> I haven't debugged with enough tablet devices, such as the color kindle, to 
>> know how many webkit distros it works with.
>> What should I do about user zoom on the desktop (and possibly, the kindle) ?
>> 
>> Drawing in high res, just-in-case, makes for a poorer experience for users 
>> at a 1.0 ratio,
>> and asking users to slide a "sharpen" slider is a little awkward.
>> 
>> Mozilla, in their implementation, has setup device-pixel-ratio to scale when 
>> the user scales content;
>> they directly expose window css pixel ratio value to trusted scripts, but 
>> not to web content; requiring
>> web content to use css device-pixel-ratio.
>> 
>> Microsoft has exposed the values through window.screen.
>> 
>> 
>> 
>> -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] process for unreviewed commits

[Darin Adler]

On Mar 3, 2011, at 11:58 PM, Ojan Vafai wrote:

> The "Unreviewed" bit is news to me. I thought it was assumed that if there's 
> no "Reviewed By..." line then it was committed unreviewed and, in fact, that 
> was preferred to adding the "Unreviewed" line.

Yes, this is how I understood it too.

-- Darin

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

Re: [webkit-dev] Canvas backing resolution

[Oliver Hunt]

For reference desktop webkit implementations will automatically increase the 
canvas backing store resolution as the device:css pixel ratio increases.

--Oliver

On Mar 4, 2011, at 1:44 AM, Charles Pritchard wrote:

> On 3/4/2011 1:35 AM, Kenneth Rohde Christiansen wrote:
>> Hi again,
>> 
>>> I'm trying to keep the canvas bitmap at the same pixel resolution as the
>>> device,
>>> otherwise it is blurry.
>> OK, I see.
>> 
>>> This, for example, works if the pixel ratio is 2.
>>> >> height="200">
>>> 
>>> Yes, when the user has a zoom level set, I'd like to paint to match the
>>> pixel ratio,
>>> so that, a zoomed in user still receives crisp output, instead of blurry
>>> output.
>> -webkit-device-pixel-ratio does not change when the user scaled the
>> content; it is a device value.
>> 
>> On old iPhone it is 1.0, on Android it can be 0.5, 1.0 and 1.5
>> depending on it being a low, medium (160) or high dpi (240) device. On
>> the iPhone 4 and the new iPod Touch it is 2.0.
>> 
>> On Android devices, with for instance, a device-pixel-ratio of 1.5,
>> you can disable the upscaling by adding target-densitydpi=device-dpi
>> to the viewport meta tag.
>> 
>> What you can do is to disable user scaling (add user-scaling=no to the
>> viewport meta tag) and then handle zooming in your app using the touch
>> events. This only works on mobile devices though.
> 
> I haven't debugged with enough tablet devices, such as the color kindle, to 
> know how many webkit distros it works with.
> What should I do about user zoom on the desktop (and possibly, the kindle) ?
> 
> Drawing in high res, just-in-case, makes for a poorer experience for users at 
> a 1.0 ratio,
> and asking users to slide a "sharpen" slider is a little awkward.
> 
> Mozilla, in their implementation, has setup device-pixel-ratio to scale when 
> the user scales content;
> they directly expose window css pixel ratio value to trusted scripts, but not 
> to web content; requiring
> web content to use css device-pixel-ratio.
> 
> Microsoft has exposed the values through window.screen.
> 
> 
> 
> -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] Canvas backing resolution

[Kenneth Rohde Christiansen]

> I haven't debugged with enough tablet devices, such as the color kindle, to
> know how many webkit distros it works with.
> What should I do about user zoom on the desktop (and possibly, the kindle) ?

Well the value doesn't change with zooming on neither Safari nor
Chrome. I am not sure about the Kindle either; I'm not even sure what
port it uses.

> Drawing in high res, just-in-case, makes for a poorer experience for users
> at a 1.0 ratio,
> and asking users to slide a "sharpen" slider is a little awkward.
>
> Mozilla, in their implementation, has setup device-pixel-ratio to scale when
> the user scales content;
> they directly expose window css pixel ratio value to trusted scripts, but
> not to web content; requiring
> web content to use css device-pixel-ratio.

This is not now WebKit ports currently work. For me the 'device' part
of the name also makes it feel like a static value. Whether this
should be changed or whether we should add a way to get access to the
user scale (ie something like -webkit-page-scale), I don't know. Maybe
Hyatt has some input on this?

> Microsoft has exposed the values through window.screen.

Do you have a link to some documentation for this?

Cheers,

-- 
Kenneth Rohde Christiansen
Senior Engineer
Application and Service Frameworks, Nokia Danmark A/S
Phone  +45 4093 0598 / E-mail kenneth.christiansen at gmail.com

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

Re: [webkit-dev] Canvas backing resolution

[Charles Pritchard]

On 3/4/2011 1:35 AM, Kenneth Rohde Christiansen wrote:

Hi again,


I'm trying to keep the canvas bitmap at the same pixel resolution as the
device,
otherwise it is blurry.

OK, I see.


This, for example, works if the pixel ratio is 2.


Yes, when the user has a zoom level set, I'd like to paint to match the
pixel ratio,
so that, a zoomed in user still receives crisp output, instead of blurry
output.

-webkit-device-pixel-ratio does not change when the user scaled the
content; it is a device value.

On old iPhone it is 1.0, on Android it can be 0.5, 1.0 and 1.5
depending on it being a low, medium (160) or high dpi (240) device. On
the iPhone 4 and the new iPod Touch it is 2.0.

On Android devices, with for instance, a device-pixel-ratio of 1.5,
you can disable the upscaling by adding target-densitydpi=device-dpi
to the viewport meta tag.

What you can do is to disable user scaling (add user-scaling=no to the
viewport meta tag) and then handle zooming in your app using the touch
events. This only works on mobile devices though.


I haven't debugged with enough tablet devices, such as the color kindle, 
to know how many webkit distros it works with.

What should I do about user zoom on the desktop (and possibly, the kindle) ?

Drawing in high res, just-in-case, makes for a poorer experience for 
users at a 1.0 ratio,

and asking users to slide a "sharpen" slider is a little awkward.

Mozilla, in their implementation, has setup device-pixel-ratio to scale 
when the user scales content;
they directly expose window css pixel ratio value to trusted scripts, 
but not to web content; requiring

web content to use css device-pixel-ratio.

Microsoft has exposed the values through window.screen.



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

Re: [webkit-dev] Canvas backing resolution

[Kenneth Rohde Christiansen]

Hi again,

> I'm trying to keep the canvas bitmap at the same pixel resolution as the
> device,
> otherwise it is blurry.

OK, I see.

> This, for example, works if the pixel ratio is 2.
>  height="200">
>

> Yes, when the user has a zoom level set, I'd like to paint to match the
> pixel ratio,
> so that, a zoomed in user still receives crisp output, instead of blurry
> output.

-webkit-device-pixel-ratio does not change when the user scaled the
content; it is a device value.

On old iPhone it is 1.0, on Android it can be 0.5, 1.0 and 1.5
depending on it being a low, medium (160) or high dpi (240) device. On
the iPhone 4 and the new iPod Touch it is 2.0.

On Android devices, with for instance, a device-pixel-ratio of 1.5,
you can disable the upscaling by adding target-densitydpi=device-dpi
to the viewport meta tag.

What you can do is to disable user scaling (add user-scaling=no to the
viewport meta tag) and then handle zooming in your app using the touch
events. This only works on mobile devices though.

Cheers,

-- 
Kenneth Rohde Christiansen
Senior Engineer
Application and Service Frameworks, Nokia Danmark A/S
Phone  +45 4093 0598 / E-mail kenneth.christiansen at gmail.com

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

Re: [webkit-dev] process for unreviewed commits

[Ojan Vafai]

Why does the commit-queue need to do more than just looking for OOPS?

On Fri, Mar 4, 2011 at 7:37 PM, Eric Seidel  wrote:

> The unreviewed bit is currently used by the scripts (like the
> commit-queue) to help them understand that the patch is intentionally
> unreviewed.
>
> I don't know what the "official" process is.  But certainly some
> amount of "this is intentionally missing a review" information is
> useful for the commit-queue.  Feel free to change how that's conveyed.
>
> -eric
>
> On Thu, Mar 3, 2011 at 11:58 PM, Ojan Vafai  wrote:
> > This isn't a big deal either way, but I noticed
> > that
> http://trac.webkit.org/wiki/CommitterTips#Walkingyouthroughyourfirstcommit
> > lists the following as the process for unreviewed commits: "Unreviewed
> > commits should include a line saying "Unreviewed." in place of the
> "Reviewed
> > By..." line in each ChangeLog entry."
> > The "Unreviewed" bit is news to me. I thought it was assumed that if
> there's
> > no "Reviewed By..." line then it was committed unreviewed and, in fact,
> that
> > was preferred to adding the "Unreviewed" line.
> > Ojan
> > ___
> > 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] process for unreviewed commits

[Eric Seidel]

The unreviewed bit is currently used by the scripts (like the
commit-queue) to help them understand that the patch is intentionally
unreviewed.

I don't know what the "official" process is.  But certainly some
amount of "this is intentionally missing a review" information is
useful for the commit-queue.  Feel free to change how that's conveyed.

-eric

On Thu, Mar 3, 2011 at 11:58 PM, Ojan Vafai  wrote:
> This isn't a big deal either way, but I noticed
> that http://trac.webkit.org/wiki/CommitterTips#Walkingyouthroughyourfirstcommit
> lists the following as the process for unreviewed commits: "Unreviewed
> commits should include a line saying "Unreviewed." in place of the "Reviewed
> By..." line in each ChangeLog entry."
> The "Unreviewed" bit is news to me. I thought it was assumed that if there's
> no "Reviewed By..." line then it was committed unreviewed and, in fact, that
> was preferred to adding the "Unreviewed" line.
> Ojan
> ___
> 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] Canvas backing resolution

[Charles Pritchard]

On 3/4/2011 12:21 AM, Kenneth Rohde Christiansen wrote:

Hi there,

I do not exactly understand what you are trying to do (you want the
canvas to cover the whole view?), but for me
I'm trying to keep the canvas bitmap at the same pixel resolution as the 
device,

otherwise it is blurry.

This, for example, works if the pixel ratio is 2.
height="200">



This returns true, always, on non-mobile platforms, it seems:
window.matchMedia('(-webkit-min-device-pixel-ratio: 1)');

makes perfect sense on the desktop, as the content isn't scaled up in
any way (except user zooming). It means that one css pixel should
correspond to one screen pixel given your current screen resolution.
Yes, when the user has a zoom level set, I'd like to paint to match the 
pixel ratio,
so that, a zoomed in user still receives crisp output, instead of blurry 
output.



On the other hand on many Android devices (most 240 DPI) the web
contents using a viewport meta tag is scaled up with 1.5 due to most
mobile pages being designed for a DPI of 160, and so the
-webkit-device-pixel-ratio reports 1.5. On the iPhone 4, the contents
is scaled up by 2.0 due to the retina display and the
-webkit-device-pixel-ration will report 2.0.

Yes, Android and Mobile Safari distributions work fine.

-Charles



Cheers
Kenneth

On Fri, Mar 4, 2011 at 8:16 AM, Charles Pritchard  wrote:

Is there currently an accepted way within webkit to get the resolution which
should be used for an HTML canvas backing store?

Currently, on Mobile Safari and Android, I can use window.devicePixelRatio,
on the desktop, I use window.outerWidth / window.innerWidth and on FF4, I
use
a big string of CSS min-pixel-device-ratio CSS selectors, as fall through
case statements,
and on IE9, its exposed through window.screen.

I noticed over at the bookstore, as I pawed a color kindle, that I didn't
get the mixture right,
for that device. Time is running out for me on some distros, as Sidebars
come into use,
as they'll break the inner/outerWidth hack.

Anyway, that's the story. Is there a method to get the current, proper pixel
ratio, between CSS and device pixels,
across webkit distributions?

---
FF4 hack, example:
#canvas.CompatibilityMozScreen { width: 1px; }
@media all and (min--moz-device-pixel-ratio: .3) {
  #canvas.CompatibilityMozScreen { width: .3px; }
}
@media all and (min--moz-device-pixel-ratio: .5) {
  #canvas.CompatibilityMozScreen { width: .5px; }
}
... continued many times, based on:
http://kb.mozillazine.org/Toolkit.zoomManager.zoomValues


This trick does not seem to with webkit, or it is otherwise restricted to
mobile devices:

This returns true, always, on non-mobile platforms, it seems:
window.matchMedia('(-webkit-min-device-pixel-ratio: 1)');
---

I'm hoping for a resolution to this issue, as we do use the canvas tag, and
our canvas elements appear a little blurry on some devices:
without a solution, some of our users will have to manually adjust the
"sharpness" of the site... adjusting a website until it
comes into focus seems a bit strange.


-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] Canvas backing resolution

[Kenneth Rohde Christiansen]

Hi there,

I do not exactly understand what you are trying to do (you want the
canvas to cover the whole view?), but for me

> This returns true, always, on non-mobile platforms, it seems:
> window.matchMedia('(-webkit-min-device-pixel-ratio: 1)');

makes perfect sense on the desktop, as the content isn't scaled up in
any way (except user zooming). It means that one css pixel should
correspond to one screen pixel given your current screen resolution.
On the other hand on many Android devices (most 240 DPI) the web
contents using a viewport meta tag is scaled up with 1.5 due to most
mobile pages being designed for a DPI of 160, and so the
-webkit-device-pixel-ratio reports 1.5. On the iPhone 4, the contents
is scaled up by 2.0 due to the retina display and the
-webkit-device-pixel-ration will report 2.0.

Cheers
Kenneth

On Fri, Mar 4, 2011 at 8:16 AM, Charles Pritchard  wrote:
> Is there currently an accepted way within webkit to get the resolution which
> should be used for an HTML canvas backing store?
>
> Currently, on Mobile Safari and Android, I can use window.devicePixelRatio,
> on the desktop, I use window.outerWidth / window.innerWidth and on FF4, I
> use
> a big string of CSS min-pixel-device-ratio CSS selectors, as fall through
> case statements,
> and on IE9, its exposed through window.screen.
>
> I noticed over at the bookstore, as I pawed a color kindle, that I didn't
> get the mixture right,
> for that device. Time is running out for me on some distros, as Sidebars
> come into use,
> as they'll break the inner/outerWidth hack.
>
> Anyway, that's the story. Is there a method to get the current, proper pixel
> ratio, between CSS and device pixels,
> across webkit distributions?
>
> ---
> FF4 hack, example:
> #canvas.CompatibilityMozScreen { width: 1px; }
> @media all and (min--moz-device-pixel-ratio: .3) {
>  #canvas.CompatibilityMozScreen { width: .3px; }
> }
> @media all and (min--moz-device-pixel-ratio: .5) {
>  #canvas.CompatibilityMozScreen { width: .5px; }
> }
> ... continued many times, based on:
> http://kb.mozillazine.org/Toolkit.zoomManager.zoomValues
>
>
> This trick does not seem to with webkit, or it is otherwise restricted to
> mobile devices:
>
> This returns true, always, on non-mobile platforms, it seems:
> window.matchMedia('(-webkit-min-device-pixel-ratio: 1)');
> ---
>
> I'm hoping for a resolution to this issue, as we do use the canvas tag, and
> our canvas elements appear a little blurry on some devices:
> without a solution, some of our users will have to manually adjust the
> "sharpness" of the site... adjusting a website until it
> comes into focus seems a bit strange.
>
>
> -Charles
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



-- 
Kenneth Rohde Christiansen
Senior Engineer
Application and Service Frameworks, Nokia Danmark A/S
Phone  +45 4093 0598 / E-mail kenneth.christiansen at gmail.com

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

Re: [webkit-dev] process for unreviewed commits

[Ojan Vafai]

On Fri, Mar 4, 2011 at 7:03 PM, Mark Rowe  wrote:

> On 2011-03-03, at 23:58, Ojan Vafai wrote:
> It's never been customary to say "Unreviewed." in place of a reviewer.  The
> most common type of change that doesn't require review is a build fix, and
> in those cases it's customary to omit the reviewer line completely.  <
> http://trac.webkit.org/search?q=build+fix> provides plenty of examples of
> this.  The wiki page should be updated to match existing procedures.
>

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

Re: [webkit-dev] process for unreviewed commits

[Dan Bernstein]

On Mar 3, 2011, at 11:58 PM, Ojan Vafai wrote:

> This isn't a big deal either way, but I noticed that 
> http://trac.webkit.org/wiki/CommitterTips#Walkingyouthroughyourfirstcommit 
> lists the following as the process for unreviewed commits: "Unreviewed 
> commits should include a line saying "Unreviewed." in place of the "Reviewed 
> By..." line in each ChangeLog entry."
> 
> The "Unreviewed" bit is news to me. I thought it was assumed that if there's 
> no "Reviewed By..." line then it was committed unreviewed and, in fact, that 
> was preferred to adding the "Unreviewed" line.

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

Re: [webkit-dev] process for unreviewed commits

[Mark Rowe]

On 2011-03-03, at 23:58, Ojan Vafai wrote:

> This isn't a big deal either way, but I noticed that 
> http://trac.webkit.org/wiki/CommitterTips#Walkingyouthroughyourfirstcommit 
> lists the following as the process for unreviewed commits: "Unreviewed 
> commits should include a line saying "Unreviewed." in place of the "Reviewed 
> By..." line in each ChangeLog entry."
> 
> The "Unreviewed" bit is news to me. I thought it was assumed that if there's 
> no "Reviewed By..." line then it was committed unreviewed and, in fact, that 
> was preferred to adding the "Unreviewed" line.

It's never been customary to say "Unreviewed." in place of a reviewer.  The 
most common type of change that doesn't require review is a build fix, and in 
those cases it's customary to omit the reviewer line completely.  
 provides plenty of examples of 
this.  The wiki page should be updated to match existing procedures.

- Mark

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