Re: [webkit-dev] question about Viewport
http://people.opera.com/rune/TR/css-viewport/ The above link might help you understand how it works Kenneth On Thu, Dec 2, 2010 at 4:28 PM, Eric Zhou wrote: > Could anyone give some help to understand the concept of viewport meta tag? > I got the introduction from apple developer site: > http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safariwebcontent/UsingtheViewport/UsingtheViewport.html > In this introduction, Figure 3-7 makes me confused. The width of viewport > (with scale=0.5) is the same as that of visible area, while width of > viewport with scale = 1.5 is 1.5 times of visible area(shown by Figure 3-6). > In my understanding, scale = [width of viewport]/[width of visible area], > and hence, the width of viewport in Figure 3-7 should be half of width of > visible area. > ___ > 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
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 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
Got it. I didn't notice that manual was a sub directory. Kenneth On Mon, Dec 27, 2010 at 8:14 PM, Adam Barth wrote: > Thanks fora ll your feedback. Responses inline. > > On Mon, Dec 27, 2010 at 2:06 AM, Kenneth Rohde Christiansen > 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] WebKit-WinCE finally merged
Nice! Congratulation! Keep the patches coming ;-) Cheers, Kenneth On Wed, Jan 5, 2011 at 1:27 AM, Patrick Gansterer 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] Done moving source files into Source
Were you going to move wtf out of JavaScriptCore as well? Kenneth On Mon, Jan 17, 2011 at 11:12 AM, Adam Barth 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] Canvas backing resolution
Hi there,
I do not exactly understand what you are trying to do (you want the
canvas to cover the whole view?), but for me
> This returns true, always, on non-mobile platforms, it seems:
> window.matchMedia('(-webkit-min-device-pixel-ratio: 1)');
makes perfect sense on the desktop, as the content isn't scaled up in
any way (except user zooming). It means that one css pixel should
correspond to one screen pixel given your current screen resolution.
On the other hand on many Android devices (most 240 DPI) the web
contents using a viewport meta tag is scaled up with 1.5 due to most
mobile pages being designed for a DPI of 160, and so the
-webkit-device-pixel-ratio reports 1.5. On the iPhone 4, the contents
is scaled up by 2.0 due to the retina display and the
-webkit-device-pixel-ration will report 2.0.
Cheers
Kenneth
On Fri, Mar 4, 2011 at 8:16 AM, Charles Pritchard wrote:
> Is there currently an accepted way within webkit to get the resolution which
> should be used for an HTML canvas backing store?
>
> Currently, on Mobile Safari and Android, I can use window.devicePixelRatio,
> on the desktop, I use window.outerWidth / window.innerWidth and on FF4, I
> use
> a big string of CSS min-pixel-device-ratio CSS selectors, as fall through
> case statements,
> and on IE9, its exposed through window.screen.
>
> I noticed over at the bookstore, as I pawed a color kindle, that I didn't
> get the mixture right,
> for that device. Time is running out for me on some distros, as Sidebars
> come into use,
> as they'll break the inner/outerWidth hack.
>
> Anyway, that's the story. Is there a method to get the current, proper pixel
> ratio, between CSS and device pixels,
> across webkit distributions?
>
> ---
> FF4 hack, example:
> #canvas.CompatibilityMozScreen { width: 1px; }
> @media all and (min--moz-device-pixel-ratio: .3) {
> #canvas.CompatibilityMozScreen { width: .3px; }
> }
> @media all and (min--moz-device-pixel-ratio: .5) {
> #canvas.CompatibilityMozScreen { width: .5px; }
> }
> ... continued many times, based on:
> http://kb.mozillazine.org/Toolkit.zoomManager.zoomValues
>
>
> This trick does not seem to with webkit, or it is otherwise restricted to
> mobile devices:
>
> This returns true, always, on non-mobile platforms, it seems:
> window.matchMedia('(-webkit-min-device-pixel-ratio: 1)');
> ---
>
> I'm hoping for a resolution to this issue, as we do use the canvas tag, and
> our canvas elements appear a little blurry on some devices:
> without a solution, some of our users will have to manually adjust the
> "sharpness" of the site... adjusting a website until it
> comes into focus seems a bit strange.
>
>
> -Charles
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
--
Kenneth Rohde Christiansen
Senior Engineer
Application and Service Frameworks, Nokia Danmark A/S
Phone +45 4093 0598 / E-mail kenneth.christiansen at gmail.com
http://codeposts.blogspot.com ﹆﹆﹆
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas backing resolution
Hi again, > I'm trying to keep the canvas bitmap at the same pixel resolution as the > device, > otherwise it is blurry. OK, I see. > This, for example, works if the pixel ratio is 2. > height="200"> > > Yes, when the user has a zoom level set, I'd like to paint to match the > pixel ratio, > so that, a zoomed in user still receives crisp output, instead of blurry > output. -webkit-device-pixel-ratio does not change when the user scaled the content; it is a device value. On old iPhone it is 1.0, on Android it can be 0.5, 1.0 and 1.5 depending on it being a low, medium (160) or high dpi (240) device. On the iPhone 4 and the new iPod Touch it is 2.0. On Android devices, with for instance, a device-pixel-ratio of 1.5, you can disable the upscaling by adding target-densitydpi=device-dpi to the viewport meta tag. What you can do is to disable user scaling (add user-scaling=no to the viewport meta tag) and then handle zooming in your app using the touch events. This only works on mobile devices though. Cheers, -- Kenneth Rohde Christiansen Senior Engineer Application and Service Frameworks, Nokia Danmark A/S Phone +45 4093 0598 / E-mail kenneth.christiansen at gmail.com http://codeposts.blogspot.com ﹆﹆﹆ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas backing resolution
> 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
Hey Oliver! If you are saying that device-pixel-ratio should include the user scaling, then I can push that for Qt, but I would really like seeing it supported by iOS as well for compatibility reasons. If you create a bug for that, please cc me. Kenneth On Fri, Mar 4, 2011 at 8:11 PM, Oliver Hunt wrote: > WebKit's canvas implementation has always scaled the backing buffer according > to actual screen resolution, i suspect it doesn't pay any attention to zoom > however :-/ > > Arguably that's a bug. > > --Oliver > > On Mar 4, 2011, at 10:08 AM, Charles Pritchard wrote: > >> In the future? >> >> >> >> On Mar 4, 2011, at 8:51 AM, Oliver Hunt wrote: >> >>> For reference desktop webkit implementations will automatically increase >>> the canvas backing store resolution as the device:css pixel ratio increases. >>> >>> --Oliver >>> >>> On Mar 4, 2011, at 1:44 AM, Charles Pritchard wrote: >>> >>>> On 3/4/2011 1:35 AM, Kenneth Rohde Christiansen wrote: >>>>> Hi again, >>>>> >>>>>> I'm trying to keep the canvas bitmap at the same pixel resolution as the >>>>>> device, >>>>>> otherwise it is blurry. >>>>> OK, I see. >>>>> >>>>>> This, for example, works if the pixel ratio is 2. >>>>>> >>>>> height="200"> >>>>>> >>>>>> Yes, when the user has a zoom level set, I'd like to paint to match the >>>>>> pixel ratio, >>>>>> so that, a zoomed in user still receives crisp output, instead of blurry >>>>>> output. >>>>> -webkit-device-pixel-ratio does not change when the user scaled the >>>>> content; it is a device value. >>>>> >>>>> On old iPhone it is 1.0, on Android it can be 0.5, 1.0 and 1.5 >>>>> depending on it being a low, medium (160) or high dpi (240) device. On >>>>> the iPhone 4 and the new iPod Touch it is 2.0. >>>>> >>>>> On Android devices, with for instance, a device-pixel-ratio of 1.5, >>>>> you can disable the upscaling by adding target-densitydpi=device-dpi >>>>> to the viewport meta tag. >>>>> >>>>> What you can do is to disable user scaling (add user-scaling=no to the >>>>> viewport meta tag) and then handle zooming in your app using the touch >>>>> events. This only works on mobile devices though. >>>> >>>> I haven't debugged with enough tablet devices, such as the color kindle, >>>> to know how many webkit distros it works with. >>>> What should I do about user zoom on the desktop (and possibly, the kindle) >>>> ? >>>> >>>> Drawing in high res, just-in-case, makes for a poorer experience for users >>>> at a 1.0 ratio, >>>> and asking users to slide a "sharpen" slider is a little awkward. >>>> >>>> Mozilla, in their implementation, has setup device-pixel-ratio to scale >>>> when the user scales content; >>>> they directly expose window css pixel ratio value to trusted scripts, but >>>> not to web content; requiring >>>> web content to use css device-pixel-ratio. >>>> >>>> Microsoft has exposed the values through window.screen. >>>> >>>> >>>> >>>> -Charles >>>> ___ >>>> webkit-dev mailing list >>>> webkit-dev@lists.webkit.org >>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> > > -- Kenneth Rohde Christiansen Senior Engineer Application and Service Frameworks, Nokia Danmark A/S Phone +45 4093 0598 / E-mail kenneth.christiansen at gmail.com http://codeposts.blogspot.com ﹆﹆﹆ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas backing resolution
Hi Simon, I guess you could use the media query listener defined in http://dev.w3.org/csswg/cssom-view/#the-mediaquerylist-interface We support that on trunk now. This of course means that we will need to reevaluate the CSS when a pinch zoom ends, which we might be doing already given media queries such as @media all and (min-width: 200px). Cheers Kenneth On Fri, Mar 4, 2011 at 8:47 PM, Simon Fraser wrote: > On Mar 4, 2011, at 11:24 AM, Kenneth Rohde Christiansen wrote: > >> Hey Oliver! >> >> If you are saying that device-pixel-ratio should include the user >> scaling, then I can push that for Qt, but I would really like seeing >> it supported by iOS as well for compatibility reasons. If you create a >> bug for that, please cc me. > > There's a problem with that, which is that the author can assume (possibly > erroneously) that device-pixel-ratio doesn't change for the life of the page. > However, the zoom level can change often, and there's no notification that > the author can register for that will tell them when the zoom level changes, > and thus when they'll need to redraw their canvas contents. > > Simon > > -- Kenneth Rohde Christiansen Senior Engineer Application and Service Frameworks, Nokia Danmark A/S Phone +45 4093 0598 / E-mail kenneth.christiansen at gmail.com http://codeposts.blogspot.com ﹆﹆﹆ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas backing resolution
I guess that is not even possible, as I would need to subscribe to something like "(-min-webkit-device-pixel-ratio: 1.0)" and will only be notified in case the evaluation of that exact expression changes. Maybe that spec is lacking a way to subscribe to arbitrary changes in say device-pixel-ratio. It does feel a bit expensive, but then again we are only reevaluation after pinch end, so I guess that would be fully OK. Kenneth On Fri, Mar 4, 2011 at 9:02 PM, Kenneth Rohde Christiansen wrote: > Hi Simon, > > I guess you could use the media query listener defined in > http://dev.w3.org/csswg/cssom-view/#the-mediaquerylist-interface > > We support that on trunk now. This of course means that we will need > to reevaluate the CSS when a pinch zoom ends, which we might be doing > already given media queries such as @media all and (min-width: 200px). > > Cheers > Kenneth > > On Fri, Mar 4, 2011 at 8:47 PM, Simon Fraser wrote: >> On Mar 4, 2011, at 11:24 AM, Kenneth Rohde Christiansen wrote: >> >>> Hey Oliver! >>> >>> If you are saying that device-pixel-ratio should include the user >>> scaling, then I can push that for Qt, but I would really like seeing >>> it supported by iOS as well for compatibility reasons. If you create a >>> bug for that, please cc me. >> >> There's a problem with that, which is that the author can assume (possibly >> erroneously) that device-pixel-ratio doesn't change for the life of the >> page. However, the zoom level can change often, and there's no notification >> that the author can register for that will tell them when the zoom level >> changes, and thus when they'll need to redraw their canvas contents. >> >> Simon >> >> > > > > -- > Kenneth Rohde Christiansen > Senior Engineer > Application and Service Frameworks, Nokia Danmark A/S > Phone +45 4093 0598 / E-mail kenneth.christiansen at gmail.com > > http://codeposts.blogspot.com ﹆﹆﹆ > -- Kenneth Rohde Christiansen Senior Engineer Application and Service Frameworks, Nokia Danmark A/S Phone +45 4093 0598 / E-mail kenneth.christiansen at gmail.com http://codeposts.blogspot.com ﹆﹆﹆ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Who are the EFL reviewers?
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 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 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?
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 wrote: > > > On Mon, Apr 11, 2011 at 3:40 AM, Tomasz Morawski > 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 Gomes >>> 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 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] Do you maintain OS(WINCE)?
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 wrote: > On Tue, Sep 13, 2011 at 2:38 PM, Patrick Gansterer > 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] Enable -webkit-tap-highlight-color on all ports which support TOUCH_EVENTS?
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 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 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] Cleaning up directories in WebCore
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 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 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] Making overflow clipping cheaper
Hi Julien, As you probably are aware, some mobile ports paint their own overlay scroll indicators and do scrolling on the UI side (div overflow using a separate layer) Would it be possible to refactor this code in a way that it would simplify the code paths for these ports? maybe avoiding it altogether. Currently there is a lot of scrolling code in FrameView/ScrollView etc as well which we avoid call when delegatesScrolling() is true. Cheers, Kenneth On Tue, Dec 27, 2011 at 5:50 PM, Julien Chaffraix wrote: > Hi fellow hackers, > > while investigating some slowness related to painting big HTML tables > [1], RenderLayer's painting code path was pointed out as the source of > slowness. The problem stems from RenderLayer not being aware of the > peculiarities of the underlying RenderObject (RenderTableSection > implements painting using a binary search to find out which cells to > paint instead of trying all cells like RenderLayer). > > Looking closely, it seems that the current code path is sub-optimal. > Adding an overflow clip on an element should be a cheap operation but > it ends up not being the case. This is because RenderLayer needs to > handle a lot of different use cases (transforms, opacity, z-index...) > [2]. I have spend some time thinking about how to make clipping a > cheaper operation and it looks like we could factor out most of the > scrolling logic (scroll offset, scrollbars, ScrollableArea) into a > light-weight object. This object would be orthogonal to RenderLayer. > The painting would go through "normal" (ie without layer) code path > that can already handle the clipping. > > As a first step, I took over [3] (splitting ScrollableArea out of > RenderLayer) but would like to get some feedbacks whether this > proposal sounds like something we would like to do or there are some > core issues I missed. > > Any comments welcome! > > Thanks, > Julien > > [1] https://bugs.webkit.org/show_bug.cgi?id=75001 > [2] I would argue that RenderLayer itself is a big memory overhead but > that's another debate. > [3] https://bugs.webkit.org/show_bug.cgi?id=60305 > ___ > 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
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 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] Should we move methods from layoutTestController/etc... to internals?
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 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] Feature announcement: Font Boosting
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 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 > adjust<http://developer.apple.com/library/ios/DOCUMENTATION/AppleApplications/Reference/SafariWebContent/AdjustingtheTextSize/AdjustingtheTextSize.html#//apple_ref/doc/uid/TP40006510-SW16>feature > 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 > inflation<http://dbaron.org/log/2026-font-inflation>and IE Mobile applies > text > size > adjustment<http://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.com>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] Double-Resolution (Retina) Images - Re: -webkit-image-set
Hi there,
On Tue, Apr 24, 2012 at 11:48 PM, Edward O'Connor 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] Default viewport value on WAP DTDs
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 wrote: > > 03.05.2012, в 13:46, Hugo Parente Lima написал(а): > >> > "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
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 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 > 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: >> >> > "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
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 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 > 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 s
Re: [webkit-dev] Default viewport value on WAP DTDs
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 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 > 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 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 >> > >> > 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
Re: [webkit-dev] Default viewport value on WAP DTDs
Hi there, On Sat, May 5, 2012 at 7:12 AM, Ojan Vafai 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 > 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 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 >> > >> > 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 < >> >> > >> >> > kenne
Re: [webkit-dev] the why of viewport tag
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 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
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 wrote: > On Tue, May 8, 2012 at 11:32 AM, Hugo Parente Lima > 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.: >> > >> > >> >> > >> > 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: >> > >> > >> > >> > 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, >> > > >
Re: [webkit-dev] Default viewport value on WAP DTDs
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 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 wrote: >> On Tue, May 8, 2012 at 11:32 AM, Hugo Parente Lima >> 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.: >>> > >>> > >>> >>> > >>> > 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: >>> > >>> > >>> > >>> > 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 >>> > >>> > *: (unli
Re: [webkit-dev] Device and page scaling
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 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] Device and page scaling
On Wed, May 30, 2012 at 10:00 PM, Adam Barth wrote: > On Wed, May 30, 2012 at 12:08 AM, Kenneth Rohde Christiansen > wrote: >> 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. > > This doesn't match what Simon Fraser wrote. He said that all > FrameView sizes on iOS are in "UI" pixels. OK then I got it wrong :-) I thought that was only the case for Desktop Safari. Anyway, the difference shouldn't be that big and I guess we could migrate Qt to do the same (I actually had a proof of concept of that working at some point). Currently we are applying a scale to our GraphicsContext (QPainter), so that everything is drawn with a scale, where as Safari actually adds the scale inside WebCore using the pageScaleFactor. Of course that means that our FrameView has the size as it was at scale 1.0 and we have to do adjustments to innerHeight etc. What are the advantages of the Safari approach? I guess you could make the drawing better in some cases and you avoid external mapping of event positions, but are there additional advantages? Any disadvantages? Kenneth > Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question related to license in WK2 EFL port
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 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 > 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] What is XBL?
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 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?
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 wrote:
> Furthermore, any loops like this:
>
> for (RefPtr 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 wrote:
>> My comments apply to all of the enclose* APIs in that file.
>>
>> On Wed, Aug 25, 2010 at 11:46 AM, Eric Seidel 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?
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 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?
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 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 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
Re: [webkit-dev] Have EWS compile patches that are review+ once it is done with the ones that are review?
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 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] Chromium for Android builders have been added to the EWS
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 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.com>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
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 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
[webkit-dev] New WebKit reviewer: Gyuyoung Kim
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
[webkit-dev] unsigned vs unsigned int
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
Filed https://bugs.webkit.org/show_bug.cgi?id=96693 On Thu, Sep 13, 2012 at 10:47 PM, Ryosuke Niwa 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 wrote: >> >> Does the style bot pick up "unsigned int" etc? >> >> --Oliver >> >> On Sep 13, 2012, at 1:19 PM, Ryosuke Niwa wrote: >> >> Landed in http://trac.webkit.org/changeset/128499 (Thanks ggaren!) >> >> On Thu, Sep 13, 2012 at 12:29 PM, Ryosuke Niwa 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 wrote: >>>> >>>> >>>> >>>> On Sep 13, 2012, at 1:29 AM, Kenneth Rohde Christiansen >>>> 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
Re: [webkit-dev] New WebKit Reviewer: Caio Marcelo de Oliveira Filho
Congrats! On Mon, Oct 8, 2012 at 11:20 PM, 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
Re: [webkit-dev] HbbTV support within Webkit
ore at runtime. >> >> >> >> What I propose is to provide the basic support required within Webkit in >> order to at least load the XHTML portions of HbbTV applications and > provide >> the correct key handling to drive them. In order to provide 'full' HbbTV >> support, implementations would need to provide the plugins and additional >> JavaScript classes to complete the picture. >> >> >> >> For instance, by simply adding support for the document mime type handling >> of application/vnd.hbbtv.xhtml+xml and application/ce-html+xml, many HbbTV >> applications will load and display the main page, and several 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
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 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] x32 support of JavaScriptCore
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 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 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] Adding Screen orientation API
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 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=102869<https://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.com>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.
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 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] MS Open Tech - Initial Prototype of Pointer Events
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) 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] Allan Sandfeld Jensen is now a WebKit reviewer!
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.com>org ﹆﹆﹆ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enabling unprefixed CSS Transitions by default.
Nice work Alexis! Kenneth On Fri, Feb 1, 2013 at 1:29 PM, Alexis Menard 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 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 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=2233&preview=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 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] Opera and WebKit
Welcome! Velkommen! Kenneth On Wed, Feb 13, 2013 at 9:06 AM, Håkon Wium Lie wrote: > Dear WebKit community, > > Many of us have met through various web standards efforts, such as > W3C and WHAT WG. Today I'd like to introduce Opera Software in a new > forum for us: the webkit-dev mailing list. > > We have known WebKit and its KTHML predecessor for some time. Lars > Knoll, who (re)wrote KHTML in 1999, worked for TrollTech for many > years. TrollTech and Opera shared a building in Oslo, a building which > has earned its place in the rendering engine hall of fame. > > Some of our best programmers have been working on the WebKit code for > a while, and today we have announced that we will be using the WebKit > engine in the future [1]. We will also submit our code; switching from > Presto to WebKit frees up resources and allows us to contribute to the > WebKit platform. > > The first contributions from our side will be in multi-column layout > [2]. We have experimented with combining multicol layout with > page floats and column spans [3]; in 10 lines of CSS code one can > create amazingly beautiful, scaleable and responsive paged > presentations [4]. > > We hope to work with you to further strengthen the open web that we > all believe in. > >[1] http://www.opera.com/press/releases/2013/02/13/ >[2] http://www.w3.org/TR/css3-multicol/ >[3] http://dev.w3.org/csswg/css3-gcpm/#page-floats >[4] http://people.opera.com/howcome/2013/02-reader > > Cheers, > > Håkon Wium Lie > CTO Opera Software > http://people.opera.com/howcome > ___ > 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
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 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] Sunsetting committership and reviewership
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 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] Christophe Dumez is now a WebKit reviewer
Congrats! Well deserved! On Fri, May 10, 2013 at 9:55 AM, Sudarsana Nagineni wrote: > Congratulations Chris! > > > On Fri, May 10, 2013 at 3:22 AM, Laszlo Gombos wrote: > >> 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
