Re: [webkit-dev] Christophe Dumez is now a WebKit reviewer

2013-05-10 Thread Kenneth Rohde Christiansen
Congrats! Well deserved!


On Fri, May 10, 2013 at 9:55 AM, Sudarsana Nagineni nagine...@gmail.comwrote:

 Congratulations Chris!


 On Fri, May 10, 2013 at 3:22 AM, Laszlo Gombos laszlo.gom...@gmail.comwrote:

 Hi,

 I'm happy to announce that Christophe Dumez is now a WebKit reviewer.

 Chris has done great work on WebKit2 (test infrastructure, support for
 new device APIs) and one of the driving forces behind the EFL port. Lately
 he has been doing work on the Soup and GStreamer backends and the binding
 generators.

 Please join me in congratulating Chris !

 Thanks,
   Laszlo


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



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




-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4294 9458 / E-mail kenneth at webkit.org

﹆﹆﹆
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Sunsetting committership and reviewership

2013-04-05 Thread Kenneth Rohde Christiansen
I am not sure this is really needed. People sometimes disappear from
working on trunk for extended periods of time due to internal products
and downstream branches. It has happened multiple times to me. That
doesn't mean that I won't come back and start working upstream later.

Also it could be that some people working on Blink would like to
contribute to WebKit in their spare time or in the future again.

Part of being a reviewer is also knowing what and when to review, so I
am not sure there really is an issue here.

Cheers
Kenneth

On Fri, Apr 5, 2013 at 8:19 AM, Ryosuke Niwa rn...@webkit.org wrote:
 Hi,

 This is somewhat related to the bulk move of Chromium-WebKit contributors to
 Blink, but we might want to consider sunsetting/expiring committership and
 reviewership.

 I'm thinking of something like expiring committership/reviwership of a
 person after the person didn't have any SVN activities for 3 or 6 months.

 Any thoughts or opinions?

 - R. Niwa

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




-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4294 9458 / E-mail kenneth at webkit.org

﹆﹆﹆
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Heads-up: C++11 and WebKit2

2013-03-05 Thread Kenneth Rohde Christiansen
Hi there,

I am personally happy that we can make use of C++11 and I don't
suppose it is a problem for the Tizen/EFL port. On the other hand, I
fear that Qt might be targeting some platforms where this could be an
issue. According to http://qt-project.org/wiki/Qt_5.0 they are still
aiming at supporting Windows XP as a Tier 1 platform.

Cheers
Kenneth

On Tue, Mar 5, 2013 at 11:21 PM, Anders Carlsson ander...@apple.com wrote:
 Hello everyone,

 Some time ago we started using C++11 in the Mac port of WebKit2. In the near 
 future we’re going to expand our use of C++11 in the WebKit2 codebase. 
 Specifically, we’d like to make use of rvalue references and move semantics 
 in our IPC code to avoid needlessly copying data and to give some 
 serializable objects (such as Mach ports) better semantics.

 If you’re a port that is building WebKit2, you're probably already building 
 with a compiler that supports rvalue references; according to 
 http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport, support for move 
 semantics exists in Visual Studio 2010 and later, as well as GCC 4.3 and 
 later (and any reasonable modern version of clang).

 - Anders

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



-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4294 9458 / E-mail kenneth at webkit.org

﹆﹆﹆
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Enabling unprefixed CSS Transitions by default.

2013-02-01 Thread Kenneth Rohde Christiansen
Nice work Alexis!

Kenneth

On Fri, Feb 1, 2013 at 1:29 PM, Alexis Menard ale...@webkit.org wrote:
 Hi,

 It's now landed http://trac.webkit.org/changeset/141578

 Please CC me on bugs that could occur and related to it.

 I will move on the CSS Animations now.

 Thanks.

 On Tue, Jan 29, 2013 at 11:22 PM, Eric Seidel e...@webkit.org wrote:
 Thank you for sharing!

 It appears that unless you're logged into WordPress (I had to go dig
 up my credentials) you just get a 404.


 On Tue, Jan 29, 2013 at 6:17 PM, Dean Jackson d...@apple.com wrote:
 Related: when the unprefixed transitions are enabled by default, we plan
 to make a long-overdue blog post on Recent Updates to Transitions and 
 Animations
 where recent means about 2 or 3 years :)

 http://www.webkit.org/blog/?p=2233preview=true

 The idea is that it would cover all the interesting things we've added, 
 even if
 we think most people know about them. Feel free to edit the draft (if 
 that's possible
 - otherwise email me), especially if there are features we've forgotten.

 Dean


 On 30/01/2013, at 8:03 AM, Alexis Menard ale...@webkit.org wrote:

 Hi,

 Last month I started working on supporting unprefixed CSS Transitions
 in WebKit. Today this work is guarded behind
 CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED enabled by default in
 trunk (but disabled in Chrome and probably release branches of other
 ports). After various patches we (Dean Jackson and myself) feel
 confident that the work on the transitions is ready for prime time. We
 still have bugs open in our bug tracker but that doesn't block the
 unprefixed version to go live.

 So the proposal is the following one :
 - Rename CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED to
 CSS_TRANSFORMS_ANIMATIONS_UNPREFIXED to cover the future work for
 unprefixing the animations and the transforms (that I plan to focus
 after this).
 - Ship CSS Transitions unprefixed enabled by default with no feature
 flag to disable it.

 My proposal is tracked here : 
 https://bugs.webkit.org/show_bug.cgi?id=108216

 We can also be proud to say our implementation is maybe the most
 complete one (thanks to the various people involved).

 On a side note the usage of prefixed/unprefixed version is monitored
 through the FeatureObserver so we can later in the future have an idea
 of the usage and maybe remove the prefixed support.

 Thoughts?

 Patched landed :
 http://trac.webkit.org/changeset/141119
 http://trac.webkit.org/changeset/140560
 http://trac.webkit.org/changeset/140448
 http://trac.webkit.org/changeset/140010
 http://trac.webkit.org/changeset/139922
 http://trac.webkit.org/changeset/139762
 http://trac.webkit.org/changeset/139200
 http://trac.webkit.org/changeset/139106
 http://trac.webkit.org/changeset/139070
 http://trac.webkit.org/changeset/138728
 http://trac.webkit.org/changeset/138721
 http://trac.webkit.org/changeset/138184

 Thanks.

 --
 Software Engineer @
 Intel Open Source Technology Center
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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



 --
 Software Engineer @
 Intel Open Source Technology Center
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev



-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4294 9458 / E-mail kenneth at webkit.org

﹆﹆﹆
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Allan Sandfeld Jensen is now a WebKit reviewer!

2012-12-21 Thread Kenneth Rohde Christiansen
Congrats Allan!

On Fri, Dec 21, 2012 at 5:09 PM, Turcotte Jocelyn 
jocelyn.turco...@digia.com wrote:

   Before joining WebKit a year ago, Allan was spending some of his free
 time hacking on KHTML. Since then he has been contributing in various areas
 of the Qt port, WebKit2 and WebCore, including touch adjustment and hit
 testing.

 Please join me in congratulating Allan on his new role as a
 WebKit reviewer!
 - Jocelyn

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




-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4093 0598 / E-mail kenneth at webkit. http://gmail.comorg

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


Re: [webkit-dev] MS Open Tech - Initial Prototype of Pointer Events

2012-12-19 Thread Kenneth Rohde Christiansen
Hi there,

First of all I want to say that it is great that Microsoft are
contributing towards WebKit and I want to congratulating you with the
new MS Open Tech organization.

The best way to provide feedback on a spec like this is through the
W3C, and the best way to provide feedback on the code itself is
through a patch on WebKit bugzilla. Our web site explains very well
how to contribute code to WebKit and you should have a look. When
adding new features we usually announce it on webkit-dev to see if
people are generally interested in the feature. I would say that you
have already done so with this email. Whether people are interested or
not, I would suggest creating a bug and uploading your code so that
anyone interested can give you some initial feedback on your work so
far.

Good luck and welcome

Kenneth

On Wed, Dec 19, 2012 at 2:07 AM, Scott Blomquist (MS OPEN TECH)
sb...@microsoft.com wrote:
 We are part of the engineering team of Microsoft Open Technologies, Inc. (MS 
 Open Tech, a Microsoft subsidiary; see our initial announcement at 
 http://aka.ms/introMSOpenTech). We have developed an initial proof of concept 
 of a WebKit implementation of the Pointer Events W3C Working Draft 
 (http://www.w3.org/TR/pointerevents/). It is based on a proposal that 
 Microsoft initially submitted to the W3C. You can find more details in our 
 blog post at http://aka.ms/PointerEventsWebkitPrototypeBlog.

 Right now, this is only a very early proof of concept that implements 
 selected mouse and touch events. You can find the code as a WebKit patch on 
 our HTML5 Labs website here: http://aka.ms/PointerEventsWebkitPrototype. We 
 would love to have some feedback on the code, work with the WebKit community 
 on a complete implementation of whatever final spec will be defined by the 
 W3C Pointer Events WG and if the community is interested in our contribution 
 get some advice on how/when to submit this patch to the main WebKit trunk.

 (For those wondering why we are doing this, we are obviously interested in 
 moving forward existing and new input types on the open web and, as the spec 
 evolves, maintain interoperability between WebKit and Internet Explorer.)

 --
 Scott Blomquist
 Senior Development Engineer
 Microsoft Open Technologies, Inc.
 A subsidiary of Microsoft Corporation

 Adalberto Foresti
 Principal Program Manager
 Microsoft Open Technologies, Inc.
 A subsidiary of Microsoft Corporation
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev



-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL, Intel Corporation
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

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


Re: [webkit-dev] Unprefixing CSS Animation, Transitions and Transform.

2012-12-12 Thread Kenneth Rohde Christiansen
I believe we also want to keep the unprefixed versions using the
current behavior.

Do you intent to keep these?

Cheers
Kenneth

On Wed, Dec 12, 2012 at 2:49 PM, Alexis Menard ale...@webkit.org wrote:
 Hi all,

 I would like to announce that I will start the work to unprefix CSS
 Animations, Transitions and Transform. It may sounds quick to do but
 it's not, there are few things to do before we can unprefix and
 unleash them to the world (e.g. -webkit-perspective accept valueless
 number but perspective doesn't) and we need to make few fixes to do to
 make sure we are compliant with the spec while keeping the behaviour
 as-is for the current unprefixed version. Also there is few
 unimplemented things.

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

 In the following days I will add new bugs as blocker to this one to
 track the work left to do. If you think of something missing feel free
 to open a new bug and mark is as blocker for 93136. Please put a
 detailed description on the bug.

 I will land the work behind a feature flag
 CSS_TRANSFORM_ANIMATION_TRANSITION_UNPREFIXED (I accept alternatives
 on the name :), I believe three feature flags for that is overkill)
 enabled by default on trunk as it is important for me to get the bots
 running the code. You can turn off the feature in your release
 branches up until the work is done (maybe afterwards we should even
 remove the feature flag).

 Thanks.

 --
 Software Engineer @
 Intel Open Source Technology Center
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev



-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

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


Re: [webkit-dev] Adding Screen orientation API

2012-11-22 Thread Kenneth Rohde Christiansen
Your link links to something entirely different.

Why not wait with implementing this until it is aligned with media queries
and css device adaptation.

Cheers
Kenneth

On Thu, Nov 22, 2012 at 10:34 AM, ryuan Choi ryuan.c...@gmail.com wrote:

 Hello, webkit-dev



 I would like to let you know, I am planning to add Screen Orientation API
 to WebCore.

 This feature will be behind the ENABLE_SCREEN_ORIENTATION. Please see :

 http://www.w3.org/TR/screen-orientation/ http://www.w3.org/TR/proximity/

 https://bugs.webkit.org/show_bug.cgi?id=102869https://bugs.webkit.org/show_bug.cgi?id=92837



 If you have any comments, please let me know.



 BR,
 Ryuan.
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev




-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4093 0598 / E-mail kenneth at webkit. http://gmail.comorg

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


Re: [webkit-dev] x32 support of JavaScriptCore

2012-10-11 Thread Kenneth Rohde Christiansen
OK, I see.

If most of your changes are in JavaScriptCore, it might be possible to
just have a build bot that builds that and runs the unit tests for
now, then later get all of WebKit tested.

Kenneth

On Thu, Oct 11, 2012 at 9:13 AM, Xian, Yuqiang yuqiang.x...@intel.com wrote:
 Thanks for the suggestions, Kenneth.

 I'm refining the code and trying to enable the last major component - the low 
 level interpreter for x32.
 Yes it's ideal if we can upstream the code, and as you mentioned, keep 
 maintaining it. The buildbot is a good idea while we are still way far from 
 it - it requires a mature x32 system which at least supports all of the 
 things that a WebKit port depends on. I know there're efforts porting Gentoo 
 and Fedora to x32 - we may depend on each other.

 Currently I'm testing the JSC shell only. Though I use the EFL port, I 
 eliminated most of the unnecessary dependencies on EFL libraries to run the 
 JSC shell, so that I don't need to put efforts on compiling and enabling 
 those dependencies for x32 at current stage.

 Thanks, -Yuqiang

 -Original Message-
 From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com]
 Sent: 2012年10月11日 5:51
 To: Xian, Yuqiang
 Cc: webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] x32 support of JavaScriptCore

 Hi,

 I don't think another branch on webkit.org will help you much; then
 you can as well have a branch anywhere.

 If you want this code to be well tested and maintained, you need to
 get it upstream (through all the review process) and promise that you
 have resources to keep maintaining it. It will also be an advantage if
 we can get a buildbot running this exact configuration, so that others
 can make sure they don't break your code.

 I think that whether the community will accept it upstream depends
 much about your commitment and the quality of the code, as well as how
 well you interact with the community during the reviews.

 Which port of WebKit is you currently using for testing?

 Cheers
 Kenneth


 On Wed, Oct 10, 2012 at 5:02 PM, Xian, Yuqiang yuqiang.x...@intel.com wrote:
 Hi,



 As you may already know there’s a new x32 ABI – a 32-bit psABI for x86-64
 with 32-bit pointer size. It tries to leverage the advantage of more
 registers and IP relative addressing from x64 and the advantage of smaller
 memory footprint from IA32. You can find more details of the x32 ABI here:
 https://sites.google.com/site/x32abi/.



 The Linux kernel supports x32 since 3.4, and the commonly used development
 tools and libraries are getting in the x32 support. Also more details about
 current status is available in the above link.



 Now back to WebKit. In theory most part of the WebKit code should be fine
 (or require less efforts) to support x32, if they’re pure C++ code and can
 be compiled with the x32 toolchain. The major challenge is the JIT compiler
 in the JavaScript engine (and the low level interpreter) and some
 hand-written assembly code. So I’m currently working on enabling the x32
 support of JavaScriptCore, the WebKit JavaScript engine, to try to remove
 the major obstacle. My current status is that I have enabled the baseline
 JIT, the DFG JIT and the Yarr JIT on x32 – it passes all the JavaScriptCore
 tests and the 3 major benchmarks.



 I’m posting this message in order to seek for some advices on how we should
 have our work shared to more people. I understand that it’s not very
 appropriate to try to get it into current WebKit trunk considering current
 x32 support status in major systems and the lack of maintenance in upstream,
 but we want to keep it synchronized with the newest changes of the WebKit
 code. So is it possible for us to maintain the code in a separate branch
 hosted at the WebKit server?



 Any suggestions are appreciated.



 Thanks, -Yuqiang


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




 --
 Kenneth Rohde Christiansen
 Senior Engineer, WebKit, Qt, EFL
 Phone  +45 4093 0598 / E-mail kenneth at webkit.org

 ﹆﹆﹆



-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

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


Re: [webkit-dev] HbbTV support within Webkit

2012-10-10 Thread Kenneth Rohde Christiansen
 will also
 correctly navigate around the application correctly.



 Regards,



 Mark.



 [1] Hybrid Broadcast Broadband TV - http://www.hbbtv.org/

 [2] Open IPTV Forum - http://www.oipf.tv/

 [3] CEA, CEA-2014-A, Web-based Protocol Framework for Remote User
 Interface
 on UPnP Networks and the Internet (Web4CE)






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


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



-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

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


Re: [webkit-dev] x32 support of JavaScriptCore

2012-10-10 Thread Kenneth Rohde Christiansen
Hi,

I don't think another branch on webkit.org will help you much; then
you can as well have a branch anywhere.

If you want this code to be well tested and maintained, you need to
get it upstream (through all the review process) and promise that you
have resources to keep maintaining it. It will also be an advantage if
we can get a buildbot running this exact configuration, so that others
can make sure they don't break your code.

I think that whether the community will accept it upstream depends
much about your commitment and the quality of the code, as well as how
well you interact with the community during the reviews.

Which port of WebKit is you currently using for testing?

Cheers
Kenneth


On Wed, Oct 10, 2012 at 5:02 PM, Xian, Yuqiang yuqiang.x...@intel.com wrote:
 Hi,



 As you may already know there’s a new x32 ABI – a 32-bit psABI for x86-64
 with 32-bit pointer size. It tries to leverage the advantage of more
 registers and IP relative addressing from x64 and the advantage of smaller
 memory footprint from IA32. You can find more details of the x32 ABI here:
 https://sites.google.com/site/x32abi/.



 The Linux kernel supports x32 since 3.4, and the commonly used development
 tools and libraries are getting in the x32 support. Also more details about
 current status is available in the above link.



 Now back to WebKit. In theory most part of the WebKit code should be fine
 (or require less efforts) to support x32, if they’re pure C++ code and can
 be compiled with the x32 toolchain. The major challenge is the JIT compiler
 in the JavaScript engine (and the low level interpreter) and some
 hand-written assembly code. So I’m currently working on enabling the x32
 support of JavaScriptCore, the WebKit JavaScript engine, to try to remove
 the major obstacle. My current status is that I have enabled the baseline
 JIT, the DFG JIT and the Yarr JIT on x32 – it passes all the JavaScriptCore
 tests and the 3 major benchmarks.



 I’m posting this message in order to seek for some advices on how we should
 have our work shared to more people. I understand that it’s not very
 appropriate to try to get it into current WebKit trunk considering current
 x32 support status in major systems and the lack of maintenance in upstream,
 but we want to keep it synchronized with the newest changes of the WebKit
 code. So is it possible for us to maintain the code in a separate branch
 hosted at the WebKit server?



 Any suggestions are appreciated.



 Thanks, -Yuqiang


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




-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

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


Re: [webkit-dev] New WebKit Reviewer: Caio Marcelo de Oliveira Filho

2012-10-08 Thread Kenneth Rohde Christiansen
Congrats!

On Mon, Oct 8, 2012 at 11:20 PM,  noam.rosent...@nokia.com wrote:
 I am pleased to announce that Caio (@cmarcelo) is now a WebKit reviewer.
 Caio has been working in many areas in the past years, starting with focus on 
 the Qt port with improvements to the Qt/JS bridge, font test results and 
 render-theme.
 More recently has also work on the UndoManager and other aspects of editing 
 code and CSS parsing, his latest contributions being around WTF HashMap 
 iterators.
 Since Caio has been involved in so many parts of WebKit, I'm probably 
 forgetting a few other contributions...

 Please join me in congratulating Caio for his new reviewer status!
 No'am
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev



-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

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


[webkit-dev] unsigned vs unsigned int

2012-09-13 Thread Kenneth Rohde Christiansen
Hi there,

I was telling people to use unsigned instead of unsigned int, as I
have been told that was the preferred style before, but apparently
that is not in the style guide.

The question is, should it be?

A few greps in the code:

unsigned - 18406 occurrences.
unsigned int - 1721
unsigned i = - 1548

It does in fact seem to be the preferred style.

Cheers
Kenneth

-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

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


Re: [webkit-dev] unsigned vs unsigned int

2012-09-13 Thread Kenneth Rohde Christiansen
Filed https://bugs.webkit.org/show_bug.cgi?id=96693

On Thu, Sep 13, 2012 at 10:47 PM, Ryosuke Niwa rn...@webkit.org wrote:
 No. I think we can update webkitpy/style/checkers/cpp.py to do that.
 Unfortunately, I don't understand that code base.

 - Ryosuke


 On Thu, Sep 13, 2012 at 1:34 PM, Oliver Hunt oli...@apple.com wrote:

 Does the style bot pick up unsigned int etc?

 --Oliver

 On Sep 13, 2012, at 1:19 PM, Ryosuke Niwa rn...@webkit.org wrote:

 Landed in http://trac.webkit.org/changeset/128499 (Thanks ggaren!)

 On Thu, Sep 13, 2012 at 12:29 PM, Ryosuke Niwa rn...@webkit.org wrote:

 Uploaded a patch on https://bugs.webkit.org/show_bug.cgi?id=96682.

 - Ryosuke

 On Thu, Sep 13, 2012 at 8:11 AM, Dan Bernstein m...@apple.com wrote:



 On Sep 13, 2012, at 1:29 AM, Kenneth Rohde Christiansen
 kenneth.christian...@gmail.com wrote:

  Hi there,
 
  I was telling people to use unsigned instead of unsigned int, as I
  have been told that was the preferred style before, but apparently
  that is not in the style guide.
 
  The question is, should it be?

 Yes.

 
  A few greps in the code:
 
  unsigned - 18406 occurrences.
  unsigned int - 1721
  unsigned i = - 1548
 
  It does in fact seem to be the preferred style.
 
  Cheers
  Kenneth
 
  --
  Kenneth Rohde Christiansen
  Senior Engineer, WebKit, Qt, EFL
  Phone  +45 4093 0598 / E-mail kenneth at webkit.org
 
  ﹆﹆﹆
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev



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




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




-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

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


[webkit-dev] New WebKit reviewer: Gyuyoung Kim

2012-08-21 Thread Kenneth Rohde Christiansen
I’m pleased to announce that Gyuyoung Kim is now a WebKit reviewer.

Gyuyoung joined the WebKit team as part of an effort to port WebKit to
the EFL platform. Since then he has taken leadership of the Samsung
activities in WebKit trunk and helped integrating his team members in
the community and community practices. Lately, Gyuyoung have been
focused on adding device API's to WebKit, as well as refocusing the
EFL efforts on WebKit2.

Please join me in congratulating him in his new WebKit reviewer role.

-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

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


Re: [webkit-dev] PSA: removing CSS3_FLEXBOX define

2012-08-18 Thread Kenneth Rohde Christiansen
Nice, congratulations on getting this far! A lot of web developers are
going to find flexbox extremely useful, and we should also not forget
that it is even supported by IE10 (though prefixed with -ms-) now, so
it will be good that people can also use it on WebKit based browsers
soon.

Kenneth

On Sat, Aug 18, 2012 at 3:47 AM, Ojan Vafai o...@chromium.org wrote:
 Next week we plan to remove the CSS3_FLEXBOX define again. We had added it
 back in because the spec was about to change a lot (mostly renaming). At
 this point the spec is stable and has been approved to go to CR.

 Also, our implementation has been fuzz-tested for crashes/memory errors.

 I'm fairly confident in the code and API stability at this point. Is there
 any port that doesn't want this enabled? If not, we'll remove the define.

 Sometime in the next couple months we also plan to check our compatibility
 with other implementations (if there are any shipping by that time) and
 remove the vendor prefix.

 Ojan

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




-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

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


Re: [webkit-dev] Chromium for Android builders have been added to the EWS

2012-08-10 Thread Kenneth Rohde Christiansen
Nice to hear and congratulation with getting so far!

I am very happy that you are aiming at having a working mobile port in
trunk; similar goals that we have for the Qt port.

Cheers
Kenneth

On Fri, Aug 10, 2012 at 12:06 PM, Peter Beverloo pe...@chromium.org wrote:

 Hi WebKit,

 Starting yesterday, a queue is now available for the Early Warning System
 (EWS) which will be building --but not testing-- all patches uploaded to
 Bugzilla for the Chromium for Android configuration.

 Compared to Chromium Linux, the main differences are that Android will
 cross-compile the entire project to the ARMv7 architecture (thumb, with
 NEON disabled); the list of enabled features is slightly different[1], and
 some source files have Android-specific implementations. Finally, after
 building the .so libraries is complete, it will create .apk (Android
 Application Package) files for each major target.

 The queue[2] currently still has more than 300 patches pending, which
 seems to include every patch that's still pending review or commit. If you
 get build failure notices on patches that haven't been touched for months,
 please feel free to ignore them.

 We plan to add a tester to the waterfall in the next few weeks, which will
 also be running all unit tests, API tests and Layout Tests on actual
 devices.

 Thanks,
 Peter

 [1]
 http://trac.webkit.org/browser/trunk/Source/WebKit/chromium/features.gypi#L148
 [2] http://webkit-commit-queue.appspot.com/queue-status/cr-android-ews

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




-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4093 0598 / E-mail kenneth at webkit. http://gmail.comorg

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


Re: [webkit-dev] Question related to license in WK2 EFL port

2012-07-25 Thread Kenneth Rohde Christiansen
Hi,

The license is basically up to the contributor, though there might be
a few advantages using the BSD license.

Using BSD licensed code means that the code can be re-factored in the
future and parts can be moved into WebCore or elsewhere. If you use
LGPL you have to make sure to not reuse the code in any file licensed
as BSD.

Having the code licensed as BSD also means that your employer can
reuse code parts in other internal products. That is also possible if
the code is already under your copyright, but when other people start
contributing to it, it becomes less clear.

Cheers
Kenneth

On Wed, Jul 25, 2012 at 8:36 AM, Dumez, Christophe
christophe.du...@intel.com wrote:
 Hi,

 This kind of decision is not easy to take and cannot necessarily be taken by
 us developers (our employers may favor one particular license).

 The WebKit project allows both Apple's new BSD or LGPL as far as I know. So,
 as long as contributors use one of those 2 licenses for WebKit-EFL, I don't
 see any problem with it.

 Kr,


 On Wed, Jul 25, 2012 at 8:50 AM, Gyuyoung Kim gyuyoung@samsung.com
 wrote:

 Hello WebKit folks,

 I'd like to have your opinions on EFL port licensing. Currently it uses
 both LGPL and BSD, and there's no explicit rule in EFL port so far. So the
 license was decided by individual contributor when new file was submitted.
 Nowadays, some EFL contributors are confused which license should be used.

 I would like to know whether EFL folks can continue to choose which
 license to use. Or, is there any rule related to license?

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




 --
 Christophe Dumez
 Linux Software Engineer, PhD
 Intel Finland Oy - Open Source Technology Center


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




-- 
Kenneth Rohde Christiansen
Senior Engineer
Nokia Mobile Phones, Browser / WebKit team
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

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


Re: [webkit-dev] Device and page scaling

2012-05-30 Thread Kenneth Rohde Christiansen
Hi,

I don't think we are doing that much differently.

Desktop Safari is scaling directly in WebCore using the
pageScaleFactor whereas Qt like iOS scales outside of WebCore (using a
tiled backing store), resulting in the FrameView not being in UI
pixels.

devicePixelRatio currently can become 1 on some viewport meta tag
cases in Qt (/Chromium), but I am already convinced that we should
remove the code doing this, which would basically solve most of our
differences in behavior.

Cheers,
Kenneth


On Wed, May 30, 2012 at 8:17 AM, Simon Fraser simon.fra...@apple.com wrote:
 On May 29, 2012, at 7:31 PM, Alexandre Elias wrote:

 Thanks for looking into this, I like this naming scheme and Chrome for 
 Android would be willing to switch to it.

 Another major semantic question is how deviceScaleFactor relates to the 
 FrameView viewport size.  Currently on Chrome for Android and Qt ports, the 
 viewport is just the physical pixel size, whereas on ChromeOS it's 
 pre-divided by deviceScaleFactor (passed in that way by the embedder -- the 
 whole UI is device-scale-independent there).

 I don't know what the Mac Safari port does and would be very interested to 
 hear.  If the Mac port behaves like ChromeOS here and there is no intention 
 to switch to the other approach, we may unfortunately have to introduce yet 
 another variable to represent the split in behaviors; otherwise ChromeOS can 
 adjust its viewport size to converge with all other ports.

 On Mac and iOS, deviceScaleFactor exactly matches window.devicePixelRatio, 
 and is simply a measure of how many physical pixels correspond to each UI 
 pixel on the device: 1 for normal displays, and 2 for Retina displays on 
 relevant iOS devices. Theoretically these could change if a window moves 
 between displays, but are independent of user scaling.

 All FrameView/viewport sizes etc are in UI pixels, and are not affected by 
 deviceScaleFactor. This sounds like the ChromeOS way, which is preferable to 
 the Android/Qt way by the sound of it.

 Gesture zooming on Mac (not to be confused with CSS zoom/text zooming) 
 affects pageScaleFactor, but this is independent of deviceScaleFactor. On 
 Mac, pageScaleFactor is implemented via a RenderStyle transform on the 
 RenderView's RenderLayer. Mac doesn't support the viewport meta tag.

 On iOS, zooming is mostly done outside of WebKit. The viewport tag affects 
 page scale in the same way that user zooming does. iOS has its own zoom 
 factor plumbed into WebCore, but ideally would share pageScaleFactor. On iOS, 
 zooming used to not affect client coordinates (getBoundingClientRects, 
 event clientX/clientY etc), but gradually iOS has migrated to a model were 
 client coords are relative to the porthole viewport (which is not the same 
 as the CSS viewport). Panning on iOS happens outside of WebKit, and is not 
 equivalent to FrameView scrolling, but some notion of the page offset is 
 plumbed through to update scrollTop, and for scroll events etc.

 This is a tricky area to get right, especially since different ports have 
 their own notions of zooming, panning etc. It's going to be a challenge to 
 get all ports sharing code here.

 Simon




-- 
Kenneth Rohde Christiansen
Senior Engineer
Nokia Mobile Phones, Browser / WebKit team
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

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] Default viewport value on WAP DTDs

2012-05-09 Thread Kenneth Rohde Christiansen
Hi there,

Just wanted to say that I sent an email to www-style:
http://lists.w3.org/Archives/Public/www-style/2012May/0371.html

Cheers,
Kenneth

On Tue, May 8, 2012 at 10:07 PM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.com wrote:
 Hi there,

 Now that I have all this info, I will write an email to www-style this
 week (hopefully tomorrow). Thanks John Mellor for clarifying what
 Android does.

 Here is some info about WP7 Internet Explorer which does very similar things:
 http://blogs.msdn.com/b/iemobile/archive/2010/11/22/the-ie-mobile-viewport-on-windows-phone-7.aspx

 Cheers,
 Kenneth

 On Tue, May 8, 2012 at 8:58 PM, Ojan Vafai o...@chromium.org wrote:
 On Tue, May 8, 2012 at 11:32 AM, Hugo Parente Lima hugo.l...@openbossa.org
 wrote:

 On Tuesday, May 08, 2012 07:22:17 PM John Mellor wrote:
  Both Chrome for Android and the legacy Android Browser do what Hugo
  described, i.e. we default to a widthÞvice-width viewport* when an

  XHTML-MP doctype is provided.
 
  And as suggested in wkbug.com/55874, we similarly default to a
  widthÞvice-width viewport if a legacy HandheldFriendly meta tag is
  present, e.g.:
 
  meta nameHandheldFriendly contenttrue

 
  and if a legacy MobileOptimized meta tag is present then we will use a
  viewport with the width provided, e.g. if the following tag is present:
 
  meta nameMobileOptimized content240
 
  we will treat that the same as a width$0 viewport tag (though IIRC the

  legacy Android Browser ignored the provided width and just treated it as
  device-width).
 
  However note that we give these implicit viewport declarations lower
  priority than actual viewport meta tags, so irrespective of the order
  they
  appear in the document, a viewport meta tag will override any behaviour
  we
  infer from the doctype or those legacy meta tags.
 
  We do all this because some number of legacy sites depend on this
  behaviour. I'm afraid we don't know how common these sites still are;
  but
  these heuristics have never seemed to cause us any problems.
 
  It makes sense to propose standardizing the XHTML-MP behaviour on
  www-style
  since I agree with Kenneth that this is something that should be covered
  by
  the http://dev.w3.org/csswg/css-device-adapt/ spec. That would also be a
  good place to try and standardize how we deal with legacy mobile meta
  tags.
  And we'd be happy to see any of these heuristics incorporated into
  WebKit (either before or after they get standardized) so we don't need
  to
  fork them.

 Kenneth pointed that the XHTML-MP behavior is already on the spec, but on
 a
 non normative section, the introduction:

 Certain DOCTYPEs (for instance XHTML Mobile Profile) are used to
 recognize
 mobile documents which are assumed to be designed for handheld devices,
 hence
 using the viewport size as the initial containing block size.

 on http://www.w3.org/TR/css-device-adapt/


 I see. Given this and the fact that Android already does this, I think this
 change is fine. Do any Apple/iOS folk object?

 The Android behavior seems a little more conservative to me, so I'd prefer
 if we did that (e.g. don't mess with zooming). We should make the most
 minimal change we can to optimize compatibility.

 Before making this change, I'd still like to see discussion on www-style for
 this. Specifically, it would be good for this to move to a normative section
 and to be more concretely specified. This open-ended language is not useful
 for actually achieving interoperability across mobile browser vendors. It
 should say specifically which doctypes and how it relates to the viewport
 meta tag. Again, I prefer the Android behavior here of always having the
 viewport meta tag win.

 Speaking of which, given the note in the spec, has there already been
 discussion on www-style about this?

 Ojan




  Cheers,
  John
 
  *: (unlike Hugo's current patch, we don't add initial-scale1.0,
  user-scalableno, just widthÞvice-width, since there doesn't seem to

  be any reason to assume that XHTML-MP sites want to disable zooming, and
  it
  may actually lead to a worse user experience).

 You are right, setting just the width should be enough.

  On Sat, May 5, 2012 at 12:58 PM, Kenneth Rohde Christiansen 
 
  kenneth.christian...@gmail.com wrote:
   Hi there,
  
   On Sat, May 5, 2012 at 7:12 AM, Ojan Vafai o...@chromium.org wrote:
I see. That's unfortunate. I don't really know the best path forward
  
   here.
  
I'm inclined to agree with Alexey that we should at least try to
  
   st
 ndardize
  
this before committing code. It's not clear to me where this should
be
specced. Easiest path forward is to make this proposal to both
wha...@whatwg.org for the HTML spec and www-st...@w3.org for the CSS
  
   Device
  
Adaptation spec.
  
   I will pass it by the CSS Device Adaptation spec first as I really
   think it fits there.
  
We'll see what the response there is and can decide what to do next
based
off

Re: [webkit-dev] Default viewport value on WAP DTDs

2012-05-08 Thread Kenneth Rohde Christiansen
Hi there,

Now that I have all this info, I will write an email to www-style this
week (hopefully tomorrow). Thanks John Mellor for clarifying what
Android does.

Here is some info about WP7 Internet Explorer which does very similar things:
http://blogs.msdn.com/b/iemobile/archive/2010/11/22/the-ie-mobile-viewport-on-windows-phone-7.aspx

Cheers,
Kenneth

On Tue, May 8, 2012 at 8:58 PM, Ojan Vafai o...@chromium.org wrote:
 On Tue, May 8, 2012 at 11:32 AM, Hugo Parente Lima hugo.l...@openbossa.org
 wrote:

 On Tuesday, May 08, 2012 07:22:17 PM John Mellor wrote:
  Both Chrome for Android and the legacy Android Browser do what Hugo
  described, i.e. we default to a widthÞvice-width viewport* when an

  XHTML-MP doctype is provided.
 
  And as suggested in wkbug.com/55874, we similarly default to a
  widthÞvice-width viewport if a legacy HandheldFriendly meta tag is
  present, e.g.:
 
  meta nameHandheldFriendly contenttrue

 
  and if a legacy MobileOptimized meta tag is present then we will use a
  viewport with the width provided, e.g. if the following tag is present:
 
  meta nameMobileOptimized content240
 
  we will treat that the same as a width$0 viewport tag (though IIRC the

  legacy Android Browser ignored the provided width and just treated it as
  device-width).
 
  However note that we give these implicit viewport declarations lower
  priority than actual viewport meta tags, so irrespective of the order
  they
  appear in the document, a viewport meta tag will override any behaviour
  we
  infer from the doctype or those legacy meta tags.
 
  We do all this because some number of legacy sites depend on this
  behaviour. I'm afraid we don't know how common these sites still are;
  but
  these heuristics have never seemed to cause us any problems.
 
  It makes sense to propose standardizing the XHTML-MP behaviour on
  www-style
  since I agree with Kenneth that this is something that should be covered
  by
  the http://dev.w3.org/csswg/css-device-adapt/ spec. That would also be a
  good place to try and standardize how we deal with legacy mobile meta
  tags.
  And we'd be happy to see any of these heuristics incorporated into
  WebKit (either before or after they get standardized) so we don't need
  to
  fork them.

 Kenneth pointed that the XHTML-MP behavior is already on the spec, but on
 a
 non normative section, the introduction:

 Certain DOCTYPEs (for instance XHTML Mobile Profile) are used to
 recognize
 mobile documents which are assumed to be designed for handheld devices,
 hence
 using the viewport size as the initial containing block size.

 on http://www.w3.org/TR/css-device-adapt/


 I see. Given this and the fact that Android already does this, I think this
 change is fine. Do any Apple/iOS folk object?

 The Android behavior seems a little more conservative to me, so I'd prefer
 if we did that (e.g. don't mess with zooming). We should make the most
 minimal change we can to optimize compatibility.

 Before making this change, I'd still like to see discussion on www-style for
 this. Specifically, it would be good for this to move to a normative section
 and to be more concretely specified. This open-ended language is not useful
 for actually achieving interoperability across mobile browser vendors. It
 should say specifically which doctypes and how it relates to the viewport
 meta tag. Again, I prefer the Android behavior here of always having the
 viewport meta tag win.

 Speaking of which, given the note in the spec, has there already been
 discussion on www-style about this?

 Ojan




  Cheers,
  John
 
  *: (unlike Hugo's current patch, we don't add initial-scale1.0,
  user-scalableno, just widthÞvice-width, since there doesn't seem to

  be any reason to assume that XHTML-MP sites want to disable zooming, and
  it
  may actually lead to a worse user experience).

 You are right, setting just the width should be enough.

  On Sat, May 5, 2012 at 12:58 PM, Kenneth Rohde Christiansen 
 
  kenneth.christian...@gmail.com wrote:
   Hi there,
  
   On Sat, May 5, 2012 at 7:12 AM, Ojan Vafai o...@chromium.org wrote:
I see. That's unfortunate. I don't really know the best path forward
  
   here.
  
I'm inclined to agree with Alexey that we should at least try to
  
   st
 ndardize
  
this before committing code. It's not clear to me where this should
be
specced. Easiest path forward is to make this proposal to both
wha...@whatwg.org for the HTML spec and www-st...@w3.org for the CSS
  
   Device
  
Adaptation spec.
  
   I will pass it by the CSS Device Adaptation spec first as I really
   think it fits there.
  
We'll see what the response there is and can decide what to do next
based
off that response. Does that sound OK?
  
   I think we will add a feature flag for now, together with layout tests
   for a document with XHTML-MP doctype using and not using fixed
   layouting.
  
I'm reluctant to make a change like this, but it sounds like

Re: [webkit-dev] the why of viewport tag

2012-05-07 Thread Kenneth Rohde Christiansen
Hi there,

I am pretty sure this is a result of history. Desktop browsers never
had support for the viewport meta tag, which was added initially on
iOS for the sake of giving mobile developers more control on how
contents should be laid out, possible due to vastly different viewport
size, web apps etc. The use case for something like this hasn't really
been big on the desktop, though it could still be useful. As a matter
of fact the Qt port supports this out of the box and we even have a
setting to set the default layout viewport when no viewport meta tag
is present:

Here is our documentation:

\qmlproperty int WebViewExperimental::preferredMinimumContentsWidth
\brief Minimum contents width when not overriden by the page itself.

Unless the page defines how contents should be laid out, using e.g.
the viewport meta tag, it is laid out given the width of the viewport
(in CSS units).

This setting can be used to enforce a minimum width when the page
does not define a width itself. This is useful for laying out pages
designed for big screens, commonly knows as desktop pages, on small
devices.

The default value is 0, but the value of 980 is recommented for small
screens as it provides a good trade off between legitable pages and
non-broken content.

With the default value of 0, desktop pages will lay out as always
(given the current viewport).

Cheers,
Kenneth


On Mon, May 7, 2012 at 4:07 PM, Robert Kroeger rjkro...@chromium.org wrote:
 Hi all,

 Some of the Chromium developers had a discussion recently about whether or
 not it was desirable for Chromium to always support the viewport tag even on
 the desktop. This prompted us to observe that desktop Safari does not
 support the viewport tag while mobile Safari does. Is anybody willing to
 comment on why this choice was made?

 Rob.


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




-- 
Kenneth Rohde Christiansen
Senior Engineer
Nokia Mobile Phones, Browser / WebKit team
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

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] Default viewport value on WAP DTDs

2012-05-05 Thread Kenneth Rohde Christiansen
That won't make a difference, but sure, let's do that. :-) The reason
why it doesn't matter is that the desktop browser are not using fixed
layout and are thus laying our given the actual viewport dimensions.
Even with the flag we should make tests to ensure these two cases.

Cheers,
Kenneth

On Sat, May 5, 2012 at 4:47 AM, Ryosuke Niwa rn...@webkit.org wrote:
 In that case, please add a feature flag that defaults to false since I don't
 think we want to turn this feature on on desktop browsers.

 - Ryosuke

 On Fri, May 4, 2012 at 3:39 PM, Kenneth Rohde Christiansen
 kenneth.christian...@gmail.com wrote:

 Nokia actually looked into this about a year ago and we homogenized
 our UA strings across our different devices, so that we could start to
 tell contents providers to give us the best content supported by our
 browsers. Part of this work was actually simplifying our UA string so
 much as possible and it is actually quite similar to what you are
 using today.

 The user agent for the N9 browser, for instance, is:

 Mozilla/5.0 (MeeGo; NokiaN9) AppleWebKit/534.13 (KHTML, like Gecko)
 NokiaBrowser/8.5.0 Mobile Safari/534.13

 The problem is not just the user agent. For instance the user agent is
 known by your Google, and we did pass validation for Tier 1 YouTube
 content, but the Google search team, as far as I heard, decided that
 we didn't have enough market penetration for them to turn on Tier 1
 content for us, and serves us the XHTML-MP (Tier 3?) content instead.

 As far as I understand, the decision comes from that team not wanting
 to dedicate resources to make sure the Tier 1 content keeps working on
 our device. I totally understand their reasoning and decision, but it
 is a saddens me given the promise of the open web and HTML5. It is
 even more sad that this is not a unique case and it will only be
 solved the day content providers stop looking at the user agent
 strings.

 Kenneth

 On Fri, May 4, 2012 at 11:32 PM, Ojan Vafai o...@chromium.org wrote:
  Instead of UA faking, is it possible for you to pick an actual UA string
  that is more compatible with the web at large? For Chromium we
  experimented
  with making the most minimal UA string possible without a big loss in
  web
  compatibility. To our disappointment, we found we had to match the
  Safari UA
  string almost exactly. Our current UA string is Mozilla/5.0 (X11; Linux
  x86_64) AppleWebKit/536.6 (KHTML, like Gecko) Chrome/20.0.1096.1
  Safari/536.6. The parts that we found to be safe to change are the
  platform
  names in the first sent of parenthesis. The version number after
  AppleWebKit. And the Chrome/versionNumber section. Even getting rid of
  the
  Safari/versionNumber caused us significant web compatibility problems.
 
  That said, we did all this testing in 2008. The web may have changed
  considerably since then. In either case, if your UA string diverges too
  much, I expect this problem will just be the tip of the iceberg of
  compatibility problems you'll encounter. So it might be worth
  considering
  changing your UA string before trying to add new DocType switching
  behavior.
 
  Ojan
 
  On Fri, May 4, 2012 at 10:53 AM, Hugo Parente Lima
  hugo.l...@openbossa.org
  wrote:
 
  On Friday, May 04, 2012 10:11:07 AM
 Ryosuke Niwa
 Software Engineer
 Google Inc.


 wrote:
   On Fri, May 4, 2012 at 9:39 AM, Kenneth Rohde Christiansen 
  
   kenneth.christian...@gmail.com wrote:
This is not supporting XHTML-MP, as we are not implementing
anything
special to support it. We are basically showing the content as it
was
HTML5 and that solves most real use-cases. Injecting a proper
viewport
configuration makes it also layout properly.
  
   Okay. Is this change observable by the page? Or more specifically,
   can a
   web page currently feature-detect whether a given browser support
   XHTML-MP
   by checking the size of the viewport?
 
  The page knows nothing, just as it knows nothing about the ~980 pixels
  used
  for the canvas width, it's a matter of change a magic value to the
  device-
  width to get websites better looking.
 
  I attached screenshots of MiniBrowser runnin with and without the patch
  using:
 
  MiniBrowser --window-size 480x720 http://m.yahoo.com
 
  Without patch (viewport of 980 pixels):
  https://bug-85425-attachments.webkit.org/attachment.cgi?id=140272
  Patched (viewport of 880 pixels)
  https://bug-85425-attachments.webkit.org/attachment.cgi?id=140273
 
 
   If the answer is yes, then we'll be breaking the feature detection.
  
   Unfortunately most unknown mobile browsers tend to get lots of
  
XHTML-MP. Heck, we even get that for google.com on the Nokia N9 :-(
as
well as other high profile sites.
  
   Yeah, it's very unfortunate.
  
   This makes the sites render acceptable, until we can advocate the
  
sites to accept our user agent, something which we haven't always
had
luck with. Google for one didn't want to provide us the Tier 1

Re: [webkit-dev] Default viewport value on WAP DTDs

2012-05-05 Thread Kenneth Rohde Christiansen
Hi there,

On Sat, May 5, 2012 at 7:12 AM, Ojan Vafai o...@chromium.org wrote:
 I see. That's unfortunate. I don't really know the best path forward here.
 I'm inclined to agree with Alexey that we should at least try to standardize
 this before committing code. It's not clear to me where this should be
 specced. Easiest path forward is to make this proposal to both
 wha...@whatwg.org for the HTML spec and www-st...@w3.org for the CSS Device
 Adaptation spec.

I will pass it by the CSS Device Adaptation spec first as I really
think it fits there.

 We'll see what the response there is and can decide what to do next based
 off that response. Does that sound OK?

I think we will add a feature flag for now, together with layout tests
for a document with XHTML-MP doctype using and not using fixed
layouting.

 I'm reluctant to make a change like this, but it sounds like there might not
 be a better choice. One concern I have is how many sites would break due to
 this behavior? For example, will this fix sites on N9, but break them on
 Android/iOS or are these wapforum doctypes never sent to Android/iOS because
 of UA-sniffing?

It can only break browsers respecting the viewport meta and using
fixed layouting in some way, those currently mobile browsers. As far
as I heard Android and iOS are using similar tricks but they seldom
get the pages due to UA sniffing. I already tried contacting the
Android team.

Cheers,
Kenneth
 On Fri, May 4, 2012 at 3:39 PM, Kenneth Rohde Christiansen
 kenneth.christian...@gmail.com wrote:

 Nokia actually looked into this about a year ago and we homogenized
 our UA strings across our different devices, so that we could start to
 tell contents providers to give us the best content supported by our
 browsers. Part of this work was actually simplifying our UA string so
 much as possible and it is actually quite similar to what you are
 using today.

 The user agent for the N9 browser, for instance, is:

 Mozilla/5.0 (MeeGo; NokiaN9) AppleWebKit/534.13 (KHTML, like Gecko)
 NokiaBrowser/8.5.0 Mobile Safari/534.13

 The problem is not just the user agent. For instance the user agent is
 known by your Google, and we did pass validation for Tier 1 YouTube
 content, but the Google search team, as far as I heard, decided that
 we didn't have enough market penetration for them to turn on Tier 1
 content for us, and serves us the XHTML-MP (Tier 3?) content instead.

 As far as I understand, the decision comes from that team not wanting
 to dedicate resources to make sure the Tier 1 content keeps working on
 our device. I totally understand their reasoning and decision, but it
 is a saddens me given the promise of the open web and HTML5. It is
 even more sad that this is not a unique case and it will only be
 solved the day content providers stop looking at the user agent
 strings.

 Kenneth

 On Fri, May 4, 2012 at 11:32 PM, Ojan Vafai o...@chromium.org wrote:
  Instead of UA faking, is it possible for you to pick an actual UA string
  that is more compatible with the web at large? For Chromium we
  experimented
  with making the most minimal UA string possible without a big loss in
  web
  compatibility. To our disappointment, we found we had to match the
  Safari UA
  string almost exactly. Our current UA string is Mozilla/5.0 (X11; Linux
  x86_64) AppleWebKit/536.6 (KHTML, like Gecko) Chrome/20.0.1096.1
  Safari/536.6. The parts that we found to be safe to change are the
  platform
  names in the first sent of parenthesis. The version number after
  AppleWebKit. And the Chrome/versionNumber section. Even getting rid of
  the
  Safari/versionNumber caused us significant web compatibility problems.
 
  That said, we did all this testing in 2008. The web may have changed
  considerably since then. In either case, if your UA string diverges too
  much, I expect this problem will just be the tip of the iceberg of
  compatibility problems you'll encounter. So it might be worth
  considering
  changing your UA string before trying to add new DocType switching
  behavior.
 
  Ojan
 
  On Fri, May 4, 2012 at 10:53 AM, Hugo Parente Lima
  hugo.l...@openbossa.org
  wrote:
 
  On Friday, May 04, 2012 10:11:07 AM Ryosuke Niwa wrote:
   On Fri, May 4, 2012 at 9:39 AM, Kenneth Rohde Christiansen 
  
   kenneth.christian...@gmail.com wrote:
This is not supporting XHTML-MP, as we are not implementing
anything
special to support it. We are basically showing the content as it
was
HTML5 and that solves most real use-cases. Injecting a proper
viewport
configuration makes it also layout properly.
  
   Okay. Is this change observable by the page? Or more specifically,
   can a
   web page currently feature-detect whether a given browser support
   XHTML-MP
   by checking the size of the viewport?
 
  The page knows nothing, just as it knows nothing about the ~980 pixels
  used
  for the canvas width, it's a matter of change a magic value to the
  device-
  width to get websites

Re: [webkit-dev] Default viewport value on WAP DTDs

2012-05-04 Thread Kenneth Rohde Christiansen
I think this relates more to the CSS Device Adaptation spec. Desktop
browser so far ignores the viewport meta tag, where as mobile browsers
do not.

The thing is that a default viewport information is inserted when the
viewport meta tag is missing, which most current mobile browsers then
layouts using a width of around 980 (can differ from browser to
browser). This is done as it handles desktop pages quite well.

Most XHTML-MP pages on the other hand assume that they are being laid
out using the width of the mobile device, which is often far lower
then 980 (especially as high resolution mobile devices adjust the
device-pixel-ratio).

Kenneth

On Fri, May 4, 2012 at 6:01 PM, Alexey Proskuryakov a...@webkit.org wrote:

 03.05.2012, в 13:46, Hugo Parente Lima написал(а):

 !DOCTYPE html PUBLIC -//WAPFORUM//DTD XHTML Mobile 1.0//EN
 http://www.wapforum.org/DTD/xhtml-mobile10.dtd;

 The proposed patch changes the magic value of 980 pixels to device-width
 when this doctype is found causing the website to render nicely if the device
 screen is small, i.e. don't show the website in a 980 pixels canvas zoomed 
 out
 to fit the 980 pixels screen.

 Some webkit browsers already use this hack, like the N9 browser and if I
 understood correctly by the Zalan comments on the bug, the iOS Safari too.

 I think that introduction of new doctype based modes should go through HTML5 
 first - if WebKit needs this, then other browsers need it, too.

 Also, it's not clear what the distinction between mobile and non-mobile is. 
 Is Safari on an 11 MacBook Air a mobile browser?

 - WBR, Alexey Proskuryakov

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



-- 
Kenneth Rohde Christiansen
Senior Engineer
Nokia Mobile Phones, Browser / WebKit team
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

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] Default viewport value on WAP DTDs

2012-05-04 Thread Kenneth Rohde Christiansen
This is not supporting XHTML-MP, as we are not implementing anything
special to support it. We are basically showing the content as it was
HTML5 and that solves most real use-cases. Injecting a proper viewport
configuration makes it also layout properly.

Unfortunately most unknown mobile browsers tend to get lots of
XHTML-MP. Heck, we even get that for google.com on the Nokia N9 :-( as
well as other high profile sites.

This makes the sites render acceptable, until we can advocate the
sites to accept our user agent, something which we haven't always had
luck with. Google for one didn't want to provide us the Tier 1 site of
google.com on the N9, even though it works a lot better than the
XHTML-MP version we are being served. I don't see this situation
change any time soon.

Cheers,
Kenneth

On Fri, May 4, 2012 at 6:31 PM, Ryosuke Niwa rn...@webkit.org wrote:
 I don't think we want to support XHTML-MP. We finally got rid of WML after
 years of discussions and attempts.

 If we were to accept this patch, I'd like to see a broader discussion about
 whether we want to support XHTML-MP or not first.

 - Ryosuke

 On Thu, May 3, 2012 at 1:46 PM, Hugo Parente Lima hugo.l...@openbossa.org
 wrote:

 Hi,

 I was pointed to trigger a discussion here about the patch:

 https://bugs.webkit.org/show_bug.cgi?id=85425

 I'll try to resume to issue:

 If no viewport is specified webkit uses the magic and well know value of
 980
 pixels for the canvas width, this value is very good for most websites
 developed for desktop usage, on the other side there are the websites[1]
 developed for small screen mobile devices. Those websites will look pretty
 ugly on a 980 pixels canvas, many of those websites uses a different DTD
 like:

 !DOCTYPE html PUBLIC -//WAPFORUM//DTD XHTML Mobile 1.0//EN
 http://www.wapforum.org/DTD/xhtml-mobile10.dtd;

 The proposed patch changes the magic value of 980 pixels to device-width
 when this doctype is found causing the website to render nicely if the
 device
 screen is small, i.e. don't show the website in a 980 pixels canvas zoomed
 out
 to fit the 980 pixels screen.

 Some webkit browsers already use this hack, like the N9 browser and if I
 understood correctly by the Zalan comments on the bug, the iOS Safari too.

 Comments about why the viewport width should or shouldn't be changed by
 the
 doc type is appreciated. Thanks!

 Regards
 Hugo Parente Lima

 [1] http://m.yahoo.com; http://www.google.com (using a user agent like:
 Nokia
 7110/1.0)

 ___
 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




-- 
Kenneth Rohde Christiansen
Senior Engineer
Nokia Mobile Phones, Browser / WebKit team
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

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] Default viewport value on WAP DTDs

2012-05-04 Thread Kenneth Rohde Christiansen
Nokia actually looked into this about a year ago and we homogenized
our UA strings across our different devices, so that we could start to
tell contents providers to give us the best content supported by our
browsers. Part of this work was actually simplifying our UA string so
much as possible and it is actually quite similar to what you are
using today.

The user agent for the N9 browser, for instance, is:

Mozilla/5.0 (MeeGo; NokiaN9) AppleWebKit/534.13 (KHTML, like Gecko)
NokiaBrowser/8.5.0 Mobile Safari/534.13

The problem is not just the user agent. For instance the user agent is
known by your Google, and we did pass validation for Tier 1 YouTube
content, but the Google search team, as far as I heard, decided that
we didn't have enough market penetration for them to turn on Tier 1
content for us, and serves us the XHTML-MP (Tier 3?) content instead.

As far as I understand, the decision comes from that team not wanting
to dedicate resources to make sure the Tier 1 content keeps working on
our device. I totally understand their reasoning and decision, but it
is a saddens me given the promise of the open web and HTML5. It is
even more sad that this is not a unique case and it will only be
solved the day content providers stop looking at the user agent
strings.

Kenneth

On Fri, May 4, 2012 at 11:32 PM, Ojan Vafai o...@chromium.org wrote:
 Instead of UA faking, is it possible for you to pick an actual UA string
 that is more compatible with the web at large? For Chromium we experimented
 with making the most minimal UA string possible without a big loss in web
 compatibility. To our disappointment, we found we had to match the Safari UA
 string almost exactly. Our current UA string is Mozilla/5.0 (X11; Linux
 x86_64) AppleWebKit/536.6 (KHTML, like Gecko) Chrome/20.0.1096.1
 Safari/536.6. The parts that we found to be safe to change are the platform
 names in the first sent of parenthesis. The version number after
 AppleWebKit. And the Chrome/versionNumber section. Even getting rid of the
 Safari/versionNumber caused us significant web compatibility problems.

 That said, we did all this testing in 2008. The web may have changed
 considerably since then. In either case, if your UA string diverges too
 much, I expect this problem will just be the tip of the iceberg of
 compatibility problems you'll encounter. So it might be worth considering
 changing your UA string before trying to add new DocType switching behavior.

 Ojan

 On Fri, May 4, 2012 at 10:53 AM, Hugo Parente Lima hugo.l...@openbossa.org
 wrote:

 On Friday, May 04, 2012 10:11:07 AM Ryosuke Niwa wrote:
  On Fri, May 4, 2012 at 9:39 AM, Kenneth Rohde Christiansen 
 
  kenneth.christian...@gmail.com wrote:
   This is not supporting XHTML-MP, as we are not implementing anything
   special to support it. We are basically showing the content as it was
   HTML5 and that solves most real use-cases. Injecting a proper viewport
   configuration makes it also layout properly.
 
  Okay. Is this change observable by the page? Or more specifically, can a
  web page currently feature-detect whether a given browser support
  XHTML-MP
  by checking the size of the viewport?

 The page knows nothing, just as it knows nothing about the ~980 pixels
 used
 for the canvas width, it's a matter of change a magic value to the device-
 width to get websites better looking.

 I attached screenshots of MiniBrowser runnin with and without the patch
 using:

 MiniBrowser --window-size 480x720 http://m.yahoo.com

 Without patch (viewport of 980 pixels):
 https://bug-85425-attachments.webkit.org/attachment.cgi?id=140272
 Patched (viewport of 880 pixels)
 https://bug-85425-attachments.webkit.org/attachment.cgi?id=140273


  If the answer is yes, then we'll be breaking the feature detection.
 
  Unfortunately most unknown mobile browsers tend to get lots of
 
   XHTML-MP. Heck, we even get that for google.com on the Nokia N9 :-( as
   well as other high profile sites.
 
  Yeah, it's very unfortunate.
 
  This makes the sites render acceptable, until we can advocate the
 
   sites to accept our user agent, something which we haven't always had
   luck with. Google for one didn't want to provide us the Tier 1 site of
   google.com on the N9, even though it works a lot better than the
   XHTML-MP version we are being served. I don't see this situation
   change any time soon.
 
  Can we work-around this issue by faking the user agent string?

 If you are working on your own browser you wont be telling every website
 that
 you are a iPhone forever, at least you will not be happy doing that.

 Regards.
 Hugo Parente Lima

 ___
 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




-- 
Kenneth Rohde Christiansen
Senior

Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set

2012-04-25 Thread Kenneth Rohde Christiansen
Hi there,

On Tue, Apr 24, 2012 at 11:48 PM, Edward O'Connor eocon...@apple.com wrote:
 Eric Seidel wrote:

 Assuming I'm understanding Kalle correctly, it seems this could
 already be accomplished with @media resolution?

 http://www.w3.org/TR/css3-mediaqueries/#resolution

 @media screen and (min-resolution: 264dpi) { … }

 Which according to:
 http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density

 Would match both the new iPad and the iPhone 4.

 As far as the resolution media query is concerned, the resolution of the
 new iPad and the iPhone 4 (and anything else with a device-pixel-ratio
 of 2) is exactly 192dpi.

 This is because the CSS 'dpi' unit is defined to mean dots device pixels
 per *CSS inch*, and CSS inches are hardcoded to be 96 CSS pixels.

 This means that—without real physical units—the resolution media query
 is always redundnant with device-pixel-ratio, which a) we already
 implement, and b) is easier to explain to authors than explaining why
 both the new iPad and the iPhone 4 are 192 dpi.

So the original iPhone has a dpi of 163, but it reported a CSS dpi of
96? meaning that in screen width it had around 3,3 CSS inches where as
the physical inches are more close to 1.96.

Why is this? Because the original iPhone reported an unchanged dpi of
96 even though it was in reality 163 and now everyone are depending on
that?

Kenneth

-- 
Kenneth Rohde Christiansen
Senior Engineer
Nokia Mobile Phones, Browser / WebKit team
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

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] Feature announcement: Font Boosting

2012-04-18 Thread Kenneth Rohde Christiansen
I think it would be great to talk about this at the WebKit summit tomorrow,
if you are there.

Cheers
Kenneth

On Tue, Apr 17, 2012 at 10:17 PM, John Mellor joh...@chromium.org wrote:

 Hi webkit-dev,

 You may have heard http://youtu.be/aCdZIHBbRV0?t=1m26s that Chrome for
 Android includes a Font Boosting feature. This is similar in intent to
 the text size 
 adjusthttp://developer.apple.com/library/ios/DOCUMENTATION/AppleApplications/Reference/SafariWebContent/AdjustingtheTextSize/AdjustingtheTextSize.html#//apple_ref/doc/uid/TP40006510-SW16feature
  in Mobile Safari, that the QT port also seems
 interested in http://webkit.org/b/73546. Other mobile browsers have
 corresponding features: Mobile Firefox uses font 
 inflationhttp://dbaron.org/log/2026-font-inflationand IE Mobile applies 
 text
 size 
 adjustmenthttp://msdn.microsoft.com/en-us/library/ff462082(v=vs.92).aspx#sectionToggle2
 .

 Font Boosting increases the font size in wide blocks, so that you can
 easily read the text after double-tapping to fit the block to the screen,
 instead of having to zoom in further then scroll from side to side for each
 line you read.

 The details are subtle (since web text layout is complicated), and there's
 still a lot of tweaking to do. We chose to boost font sizes more than
 Mobile Safari (which has various limits), producing easily legible text,
 more in line with IE Mobile and Firefox Mobile.

 This is core functionality for mobile browsers, so we would like to
 upstream our implementation of Font Boosting to WebCore. We are keen to
 share code with other ports (e.g. QT and Mobile Safari) that are interested
 in this feature, and will be happy to incorporate suggestions on how to
 make this easier.

 I've opened webkit.org/b/84186 to track this effort.

 Best wishes,
 John




-- 
Kenneth Rohde Christiansen
Senior Engineer
Nokia Mobile Phones, Browser / WebKit team
Phone  +45 4093 0598 / E-mail kenneth at webkit. http://gmail.comorg

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] Should we move methods from layoutTestController/etc... to internals?

2012-02-21 Thread Kenneth Rohde Christiansen
Hi,

I think that would be a great idea and the proper thing to do.

Kenneth

On Tue, Feb 21, 2012 at 9:15 PM, Ryosuke Niwa rn...@webkit.org wrote:
 Hi,

 It appears to me window.internals is a superior solution to expose
 cross-platform features to our test harness compared to other interfaces
 implemented in DumpRenderTree and WebKitTestRunner such as
 layoutTestController and friends.

 Should we try to move methods of layoutTestController and friends that
 expose WebCore-level features to internals? Moving methods to internals
 would reduce DRT/WTR's code size, and lower the entry barrier for new ports.

 For example, PlainTextController seems to exist only to expose
 Range::text(). But this function can be exposed via internals for testing
 purposes instead since it doesn't depend on any port-specific code.

 Of course, there will be interfaces that rely on WebKit-layer code (e.g.
 TextInputController) we shouldn't be moving.

 Best,
 Ryosuke Niwa
 Software Engineer
 Google Inc.



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




-- 
Kenneth Rohde Christiansen
Senior Engineer
Nokia Mobile Phones, Browser / WebKit team
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

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] HTML notification usage

2012-01-16 Thread Kenneth Rohde Christiansen
Could anyone brief explain the relation to

http://www.html5rocks.com/en/tutorials/notifications/quick/

and

http://dev.w3.org/2006/webapi/WebNotifications/publish/Notifications.html

?

I haven't followed the work with regard to notifications, so is that
work dead or are we removing legacy code?

Kenneth

On Mon, Jan 16, 2012 at 10:25 PM, Jon Lee jon...@apple.com wrote:
 Hello all,

 I've removed support for HTML notifications on the Mac via 
 http://trac.webkit.org/changeset/105086. Does anyone find much usage for this 
 kind of notification on their respective platforms? Would it be appropriate 
 to remove support for this altogether?

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



-- 
Kenneth Rohde Christiansen
Senior Engineer
Nokia Mobile Phones, Browser / WebKit team
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

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] Cleaning up directories in WebCore

2011-11-18 Thread Kenneth Rohde Christiansen
I also agree with moving Platform out. That would make the
dependencies easier to understand and hopefully avoid more layering
violations.

Kenneth

On Fri, Nov 18, 2011 at 11:06 AM, Ryosuke Niwa rn...@webkit.org wrote:
 What's the benefit of this re-org?
 Is it really worth the trouble to move these files around? This would mean
 that we may need to navigate multiple pages on trac to see revision logs.
 Other tools may suffer from such file moves as well. I remember I had to
 create new git checkout when Source move happened.
 Also, moving inspector, notifications, etc... under Features would mean that
 folks working on those components now need to type at last 2-3 more
 characters even with tab completion to find their files. Isn't that worse
 than the current situation?
 And how would one decide whether a directory belongs to WebCore vs.
 WebCore/Features?
 Though I do agree that moving manual-test out of Source/WebCore seems like a
 good idea. It should probably live at trunk/ManualTests.
 - Ryosuke
 On Fri, Nov 18, 2011 at 1:51 AM, Adam Barth aba...@webkit.org wrote:

 I've been looking for ways to improve the hackability of WebCore, and
 one thing that's been bothering me is the organization of our files.
 It seems like we're due for a bit of fall cleaning for directories.
 We've talked about some of these ideas before, but I wanted to put
 them all in one email so we can see the big picture.

 Below is a concrete proposal for moving some directories around.  In
 this approach, we'll have a Features directory to contain logically
 self-contained features, like WebAudio and MediaStream, that are part
 of the engine but that aren't tightly coupled with the DOM, Layout, or
 Rendering.  We'd also have a new events directory in dom to
 contain the large number of event-related files that we've accreted.
 The history directory would move into page (we could actually
 merge these directories because history is so small).  Finally,
 manual-tests and platform would move out of WebCore entirely.

 Features/  -- New folder for (roughly) self-contained features
  notifications/
  storage/
  fileapi/
  webaudio/
  mediastream/
  workers/
  websockets/
  inspector/
 manual-tests/  -- Move outside of Source
 dom/
  events/  -- New folder for the 106 files that match dom/*Event*
 page/
  history/  -- Moved from top-level
 platform/  -- Move to Source/Platform

 The html and page directories also contain a bunch of unrelated
 files (presumably because they're attractive locations for folks to
 add files).  Once we do the directory moves above, I'll send out
 another proposal for cleaning up those directories a bit.

 Please let me know if you have any thoughts.

 Thanks!
 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





-- 
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] Enable -webkit-tap-highlight-color on all ports which support TOUCH_EVENTS?

2011-09-28 Thread Kenneth Rohde Christiansen
Hi there,

You are right Antonio, the N9 Browser does indeed support
-webkit-tap-highlight-color.

Cheers
Kenneth

On Wed, Sep 28, 2011 at 5:33 PM, Antonio Gomes toniki...@gmail.com wrote:
 What we have to be careful here is to the fact that it is not a standand
 yet.

 I know upcoming versions of the BlackBerry browser will make use of it, and
 that Nokia's N9 likely supports it already (kenneth or qt friends, please
 confirm). Also, iirc I remember Mozilla Mobile (aka Fennec) might have added
 support to this property.

 So what we need to be sure as well is that at some point it will be worked
 on making it a standand. Usually UAs implement specs, but sometimes specs
 write up UA features when it is relevant.

 On Wed, Sep 28, 2011 at 11:22 AM, Johnny Ding j...@chromium.org wrote:

 Hi Folks,
 You may know the css property -webkit-tap-highlight-color which is now
 only supported by Safari on iOS. (Please see here for the details.)
 Now I am working on enabling it for all WebKit ports which support
 TOUCH_EVENTS. This css property (not standard yet) benefits the web
 developers who want to change the tap highlight color to fit their
 websites/webapps.
 Please go to https://bugs.webkit.org/show_bug.cgi?id=48544 for the
 details.  Suggestions and comments are definitely welcome.
 Thanks!
 --
 Best Regards.
 Johnny

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




 --
 --Antonio Gomes

 ___
 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] Do you maintain OS(WINCE)?

2011-09-13 Thread Kenneth Rohde Christiansen
We already have a list of reviewers and committers and it should
mention which port people work on.

Kenneth

On Tue, Sep 13, 2011 at 11:41 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Tue, Sep 13, 2011 at 2:38 PM, Patrick Gansterer par...@paroga.com
 wrote:

 Yes, that's correct.

 How do we measure an active port??? I maintain a buildbot for WinCe and
 usually fix problems with the port within hours. Unfortunately I don't get
 paid to work on WebKit the whole day and so I can't make such big steps
 forward like other ports do.
 Other active ports (e.g. wx) don't even have a buildbot and get maintained
 too.
 Some configuration like BREWMP or HAIKU don't have buildbot and I can't
 see any build fixes or _upstraeming_ activity for them within the last
 months.

 So PLEASE: When do we call a port active? It's not cool to get the
 question about removal every few months!

 Maybe we should have a wiki page with a list of ports and the point of
 contact.
 - Ryosuke

 ___
 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] Who are the EFL reviewers?

2011-04-11 Thread Kenneth Rohde Christiansen
The problem is that as I am not working on the port myself, I find it
quite hard to review their API's without getting input from someone
else working on EFL.

I think Antonio feels likewise.

Kenneth

On Mon, Apr 11, 2011 at 2:13 AM, Antonio Gomes toniki...@gmail.com wrote:
 Mostly myself and Kenneth. We do what we can, but we also to work on our
 stuff (as everybody else :). It really needs other reviewers to help out
 with reviewing, since EFL port guys are working really hard on it.

 On Sun, Apr 10, 2011 at 7:51 PM, Eric Seidel e...@webkit.org wrote:

 We seem to have a zillion EFL patches up for review.
 Who are the EFL reviewers?
 (I think part of the trouble is that it seems the EFL port is trying to do
 too much in WebKit.  I'm not sure where the EFL browser is, but some of the
 patches look like they should be re-directed to that project instead of
 WebKit.)
 -eric
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




 --
 --Antonio Gomes

 ___
 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] Who are the EFL reviewers?

2011-04-11 Thread Kenneth Rohde Christiansen
That sounds like a very good idea and I would be happy to help along
giving the final r+

Kenneth

On Mon, Apr 11, 2011 at 6:08 PM, David Levin le...@chromium.org wrote:


 On Mon, Apr 11, 2011 at 3:40 AM, Tomasz Morawski t.moraw...@samsung.com
 wrote:

 Hi,
 Is it possible to promote some other peoples to reviewers in the EFL
 port?

 A step that I usually suggest to chromium folks before becoming reviewers is
 to actually do reviews on patches.  Do everything except the r+ (with the
 submitter's permission).
 These are helpful to show when the reviewer nomination happens (as
 supporting evidence). If there are folks in the efl community who feel that
 they like to be reviewers, perhaps they can start doing this.  (Then someone
 who is a reviewer can come along and give the final r+. I view it as a kind
 of mentorship thing because the reviewer should do a review as well and then
 the original person can learn from that if there were things that they
 missed.)
 dave

 Tomasz

 The problem is that as I am not working on the port myself, I find it
 quite hard to review their API's without getting input from someone
 else working on EFL.

 I think Antonio feels likewise.

 Kenneth

 On Mon, Apr 11, 2011 at 2:13 AM, Antonio Gomestoniki...@gmail.com
  wrote:

 Mostly myself and Kenneth. We do what we can, but we also to work on our
 stuff (as everybody else :). It really needs other reviewers to help out
 with reviewing, since EFL port guys are working really hard on it.

 On Sun, Apr 10, 2011 at 7:51 PM, Eric Seidele...@webkit.org  wrote:

 We seem to have a zillion EFL patches up for review.
 Who are the EFL reviewers?
 (I think part of the trouble is that it seems the EFL port is trying to
 do
 too much in WebKit.  I'm not sure where the EFL browser is, but some of
 the
 patches look like they should be re-directed to that project instead of
 WebKit.)
 -eric
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




 --
 --Antonio Gomes

 ___
 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





-- 
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

2011-03-04 Thread 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 ch...@jumis.com 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] Canvas backing resolution

2011-03-04 Thread 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.
 canvas style=width: 100px; height: 100px; width=200
 height=200/canvas


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

2011-03-04 Thread 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

2011-03-04 Thread 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 oli...@apple.com 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 oli...@apple.com 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.
 canvas style=width: 100px; height: 100px; width=200
 height=200/canvas

 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

2011-03-04 Thread 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 simon.fra...@apple.com 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] Canvas backing resolution

2011-03-04 Thread 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
kenneth.christian...@gmail.com 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 simon.fra...@apple.com 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] Done moving source files into Source

2011-01-17 Thread Kenneth Rohde Christiansen
Were you going to move wtf out of JavaScriptCore as well?

Kenneth

On Mon, Jan 17, 2011 at 11:12 AM, Adam Barth aba...@webkit.org wrote:
 As of early this morning, I've finished moving all the source files
 around.  I'd like to congratulate myself on painting the bike shed a
 beautiful shade of pink.

 WebKitLibraries probably should be renamed to Libraries, but that's
 blocked on moving LayoutTests to RegressionTests (to free up the L
 tab-completion).  However, I don't think I have the stomach to move
 LayoutTests.  If someone else would like to give that a try, please be
 my guest.

 If you own one of the files below, please consider moving it from the
 root directory to the Source directory:

 Android.mk
 autogen.sh
 cmakeconfig.h.cmake
 CMakeLists.txt
 common.pri
 configure.ac
 DerivedSources.pro
 GNUmakefile.am
 Makefile
 Makefile.shared
 WebKit.pri
 WebKit.pro
 wscript

 I'm happy to move the files myself, but it might be less error prone
 if folks who understand the files best move them.  If the files are
 still in the root in a few weeks, I'll probably try my hand at moving
 them myself.

 Thanks everyone for your patience, and a special thanks to Csaba
 Osztrogonac, Xan Lopez, Mark Rowe, Martin Robinson, Kent Tamura, and
 everyone else who helped me fix broken builds.

 Adam
 ___
 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] WebKit-WinCE finally merged

2011-01-04 Thread Kenneth Rohde Christiansen
Nice! Congratulation!

Keep the patches coming ;-)

Cheers,
Kenneth

On Wed, Jan 5, 2011 at 1:27 AM, Patrick Gansterer par...@paroga.com wrote:
 Hi all,

 I'm glad to say that WebKit-WinCE is finally merged and got a working build 
 slave [1] today.

 Many, many thanks to the people from TorchMobile who did the original WinCE 
 port and all the friends that reviewed my patches to make this possible. 
 Thanks!

 It would be nice if we can try to keep it green when doing changes which 
 affect WinCE ;-).

 [1] http://build.webkit.org/waterfall?show=WinCE%20Release%20(Build)

 - Patrick
 ___
 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] More thoughts on cleaning up the root directory

2010-12-27 Thread Kenneth Rohde Christiansen
So we have PerformanceTests, RegressionTests and manual. Why not
ManualTests?

Is it really a good idea to move platform out of WebCore? Lots of stuff
there seems quite WebCore related.

Cheers
Kenneth

On Mon, Dec 27, 2010 at 9:04 AM, Adam Barth aba...@webkit.org wrote:

 Here's a snapshot of my current thinking on where the files and
 folders currently in the top-level directory might go.

 There are a bunch of build-system related files that are currently in
 the root.  I'm not sure whether we should leave them in there or move
 them into Sources somewhere.  I'm tempted to put them into Sources so
 that Sources is self-contained package of all the stuff you need to
 build WebKit.  That said, having a top-level Makefile that kicks off
 the whole process also seems reasonable.

 Examples/
 PerformanceTests/
  PageLoad/ (was PageLoadTests)
  SunSpider/
  HTMLParser/ (was WebCore/benchmarks/parser)
 RegressionTests/ (was LayoutTests)
  manual/ (was WebCore/manual-tests)
 Sources/
  automake/
  cmake/
  JavaScriptCore/
  JavaScriptGlue/
  Platform/ (was WebCore/platform)
  WebCore/
  WebKit/
  WebKit2/
  WTF/ (was JavaScriptCore/wtf)
  ThirdParty/
ANGLE/
+ Contents WebKitLibraries
 Tools/
 Websites/
 .gitattributes
 .gitignore
 ChangeLog
 Makefile
 Makefile.shared

 == UNSURE ==
 autogen.sh
 Android.mk
 common.pri
 cmakeconfig.h.cmake
 CMakeLists.txt
 configure.ac
 GNUmakefile.am
 wscript
 DerivedSources.pro
 WebKit.pri
 WebKit.pro

 In this layout, I haven't merged PerformanceTests and RegressionTests
 for two reasons.  First, the natural name, Tests, conflicts with
 tab-completing Tools.  Second, folks so commonly access the current
 LayoutTests directory that it seems a bit inefficient to place it
 another level lower in the directory hierarchy.

 Comments welcome, of course.  :)

 Adam
 ___
 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] More thoughts on cleaning up the root directory

2010-12-27 Thread Kenneth Rohde Christiansen
Got it. I didn't notice that manual was a sub directory.

Kenneth

On Mon, Dec 27, 2010 at 8:14 PM, Adam Barth aba...@webkit.org wrote:

 Thanks fora ll your feedback.  Responses inline.

 On Mon, Dec 27, 2010 at 2:06 AM, Kenneth Rohde Christiansen
 kenneth.christian...@gmail.com wrote:
  So we have PerformanceTests, RegressionTests and manual. Why not
  ManualTests?

 My thought process was that these are manual regression tests, just
 like the HTTP tests are HTTP regression tests (and are handled
 specially by run-webkit-tests).
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Have EWS compile patches that are review+ once it is done with the ones that are review?

2010-09-24 Thread Kenneth Rohde Christiansen
If they are r+'ed, there is a big change that they are soon to become
committed, so maybe they should get even more priority?

Kenneth

On Fri, Sep 24, 2010 at 2:25 PM, Darin Adler da...@apple.com wrote:
 It’s not great that if I review a patch that means it won’t get EWS results. 
 Maybe the EWS could be changed to test out “review+” patches once it gets 
 done with all the “review?” patches?

 Is that practical?

    -- Darin

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




-- 
Kenneth Rohde Christiansen
Technical Lead / Senior Software Engineer
Qt Labs Americas, Nokia Technology Institute, INdT
Phone  +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org

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] What is XBL?

2010-08-25 Thread Kenneth Rohde Christiansen
http://en.wikipedia.org/wiki/XBL , I guess?

XBL (XML Binding Language) is an XML-based markup language used to
declare the behavior and look of XUL-widgets and XML elements.

I don't think we need that :-)

Kenneth

On Wed, Aug 25, 2010 at 4:22 AM, Adam Barth aba...@webkit.org wrote:
 What is XBL?  As far as I can tell, there's no way this code can even
 build.  It's incredibly stale.  Can we remove it?

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




-- 
Kenneth Rohde Christiansen
Technical Lead / Senior Software Engineer
Qt Labs Americas, Nokia Technology Institute, INdT
Phone  +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org

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] Bad Qt API?

2010-08-25 Thread Kenneth Rohde Christiansen
Could you file bugs for these?

Also, do you know of any other way of accomplishing the same behaviour
without having security issues/crashes?

Kenneth

On Wed, Aug 25, 2010 at 3:51 PM, Eric Seidel e...@webkit.org wrote:
 Furthermore, any loops like this:

    for (RefPtrNode child = m_element-firstChild(); child;) {

 which allow synchronous javascript execution (i.e. take an
 ExceptionCode parameter) are vulnerable to crashes/security holes. :(

 All of those enclose* functions use such loops. :(

 -eric

 On Wed, Aug 25, 2010 at 11:47 AM, Eric Seidel e...@webkit.org wrote:
 My comments apply to all of the enclose* APIs in that file.

 On Wed, Aug 25, 2010 at 11:46 AM, Eric Seidel e...@webkit.org wrote:
 /*!
    Encloses the contents of this element with the result of parsing \a 
 markup.
    This element becomes the child of the deepest descendant within \a 
 markup.

    \sa encloseWith()
 */
 void QWebElement::encloseContentsWith(const QString markup)


 http://trac.webkit.org/browser/trunk/WebKit/qt/Api/qwebelement.cpp#L1248

 These enclose methods use at least 2 deprecated parts of parser code
 (HTMLElement::endTagRequirement() and
 HTMLElement::deprecatedCreateContextualFragment()).

 They're clear layering violations, and make little sense to me.

 Who wants to call this API?  Can it be removed from Qt?

 -eric


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




-- 
Kenneth Rohde Christiansen
Technical Lead / Senior Software Engineer
Qt Labs Americas, Nokia Technology Institute, INdT
Phone  +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org

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] Bad Qt API?

2010-08-25 Thread Kenneth Rohde Christiansen
They are methods for manipulating the DOM, modelled after jQuery. The
documentation should explain pretty well what they do.

Is it possible to accomplish the same behaviour with the new parser
API? We need to continue supporting this API due to our binary
compatibility, plus because of the fact that it was added due to
customer request.

Cheers,
Kenneth

On Wed, Aug 25, 2010 at 3:46 PM, Eric Seidel e...@webkit.org wrote:
 /*!
    Encloses the contents of this element with the result of parsing \a markup.
    This element becomes the child of the deepest descendant within \a markup.

    \sa encloseWith()
 */
 void QWebElement::encloseContentsWith(const QString markup)


 http://trac.webkit.org/browser/trunk/WebKit/qt/Api/qwebelement.cpp#L1248

 These enclose methods use at least 2 deprecated parts of parser code
 (HTMLElement::endTagRequirement() and
 HTMLElement::deprecatedCreateContextualFragment()).

 They're clear layering violations, and make little sense to me.

 Who wants to call this API?  Can it be removed from Qt?

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




-- 
Kenneth Rohde Christiansen
Technical Lead / Senior Software Engineer
Qt Labs Americas, Nokia Technology Institute, INdT
Phone  +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org

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] Bad Qt API?

2010-08-25 Thread Kenneth Rohde Christiansen
Btw, Eric,

We have unit tests for the QWebElement API in
WebKit/qt/tests/qwebelement/ so you can see the use-cases, if that
helps.

Cheers,
Kenneth

On Wed, Aug 25, 2010 at 3:58 PM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.com wrote:
 They are methods for manipulating the DOM, modelled after jQuery. The
 documentation should explain pretty well what they do.

 Is it possible to accomplish the same behaviour with the new parser
 API? We need to continue supporting this API due to our binary
 compatibility, plus because of the fact that it was added due to
 customer request.

 Cheers,
 Kenneth

 On Wed, Aug 25, 2010 at 3:46 PM, Eric Seidel e...@webkit.org wrote:
 /*!
    Encloses the contents of this element with the result of parsing \a 
 markup.
    This element becomes the child of the deepest descendant within \a markup.

    \sa encloseWith()
 */
 void QWebElement::encloseContentsWith(const QString markup)


 http://trac.webkit.org/browser/trunk/WebKit/qt/Api/qwebelement.cpp#L1248

 These enclose methods use at least 2 deprecated parts of parser code
 (HTMLElement::endTagRequirement() and
 HTMLElement::deprecatedCreateContextualFragment()).

 They're clear layering violations, and make little sense to me.

 Who wants to call this API?  Can it be removed from Qt?

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




 --
 Kenneth Rohde Christiansen
 Technical Lead / Senior Software Engineer
 Qt Labs Americas, Nokia Technology Institute, INdT
 Phone  +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org

 http://codeposts.blogspot.com ﹆﹆﹆




-- 
Kenneth Rohde Christiansen
Technical Lead / Senior Software Engineer
Qt Labs Americas, Nokia Technology Institute, INdT
Phone  +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org

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