From mikelima at gmail.com Fri Jun 1 01:19:36 2007 From: mikelima at gmail.com (Luciano Montanaro) Date: Tue Oct 9 17:53:28 2007 Subject: [webkit-dev] Making use of a KJS_EXPORT macro Message-ID: <200706011019.36955.mikelima@gmail.com> Hi all. I'm trying to reconcile the KJS and JSC repositories, and one of the differences I have found is the usage of the KJS_EXPORT macro, which expands to __attribute ((visibility("default"))) on GCC and __declspec(dllexport) or __declspec(dllimport) on Microsoft compilers. I think it's a useful feature, and it offers a way to document which classes are for internal use and which do not without cluttering the source code too much. Would a patch for annotating classes and methods with this macro be welcome? Luciano From ggaren at apple.com Fri Jun 1 09:51:15 2007 From: ggaren at apple.com (Geoffrey Garen) Date: Tue Oct 9 17:53:28 2007 Subject: [webkit-dev] Making use of a KJS_EXPORT macro In-Reply-To: <200706011019.36955.mikelima@gmail.com> References: <200706011019.36955.mikelima@gmail.com> Message-ID: <5734485B-233F-4600-8DEB-8252E1292AAB@apple.com> Hi Luciano. I've found that the required exports from JavaScriptCore change all the time based on new functionality in WebCore or architectural changes in JavaScriptCore. I think that kind of documentation could quickly get out of sync with reality. Geoff On Jun 1, 2007, at 1:19 AM, Luciano Montanaro wrote: > Hi all. > I'm trying to reconcile the KJS and JSC repositories, and one of the > differences I have found is the usage of the KJS_EXPORT macro, which > expands to > __attribute ((visibility("default"))) on GCC and > __declspec(dllexport) or __declspec(dllimport) on Microsoft compilers. > > I think it's a useful feature, and it offers a way to document > which classes > are for internal use and which do not without cluttering the source > code > too much. > > Would a patch for annotating classes and methods with this macro be > welcome? > > Luciano > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev From mjs at apple.com Fri Jun 1 10:30:56 2007 From: mjs at apple.com (Maciej Stachowiak) Date: Tue Oct 9 17:53:28 2007 Subject: [webkit-dev] Making use of a KJS_EXPORT macro In-Reply-To: <5734485B-233F-4600-8DEB-8252E1292AAB@apple.com> References: <200706011019.36955.mikelima@gmail.com> <5734485B-233F-4600-8DEB-8252E1292AAB@apple.com> Message-ID: <2FE2439B-7E80-4C14-834D-B10042A2EB2F@apple.com> Hey Geoff, On Jun 1, 2007, at 9:51 AM, Geoffrey Garen wrote: > Hi Luciano. > > I've found that the required exports from JavaScriptCore change all > the time based on new functionality in WebCore or architectural > changes in JavaScriptCore. I think that kind of documentation could > quickly get out of sync with reality. As I understand it, it's not documentation, but an alternative way of controlling the actual exports. Instead of an export file you can declare symbol visibility at compile time. In theory this could somewhat improve codegen, since the compiler would know some functions are not exported at compile time, not just link time. - Maciej > > Geoff > > On Jun 1, 2007, at 1:19 AM, Luciano Montanaro wrote: > >> Hi all. >> I'm trying to reconcile the KJS and JSC repositories, and one of the >> differences I have found is the usage of the KJS_EXPORT macro, which >> expands to >> __attribute ((visibility("default"))) on GCC and >> __declspec(dllexport) or __declspec(dllimport) on Microsoft >> compilers. >> >> I think it's a useful feature, and it offers a way to document >> which classes >> are for internal use and which do not without cluttering the >> source code >> too much. >> >> Would a patch for annotating classes and methods with this macro >> be welcome? >> >> Luciano >> _______________________________________________ >> 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 From reemyazigi at hotmail.com Fri Jun 1 14:51:43 2007 From: reemyazigi at hotmail.com (Reem Yazigi) Date: Tue Oct 9 17:53:28 2007 Subject: [webkit-dev] Adding New Layout Tests In-Reply-To: <927350.65927.qm@web52401.mail.re2.yahoo.com> Message-ID: An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070601/ff9030c4/attachment.html From ddkilzer at kilzer.net Sat Jun 2 23:28:59 2007 From: ddkilzer at kilzer.net (David D. Kilzer) Date: Tue Oct 9 17:53:28 2007 Subject: [webkit-dev] Adding New Layout Tests In-Reply-To: Message-ID: <524869.6255.qm@web52412.mail.re2.yahoo.com> Reem Yazigi wrote: > Thanks for your helpful answers. I still have some more questions for you guys: > > 1- Dave said "Image test is required to capture expected results that a text > based test can't". Can you please provide me with a path/name of one of these > cases? $ ls LayoutTests/fast/images/*.html > 2- I actually need to know which of the layout test cases I'm adding requires > Image test, so I can generate the PNGs and Checksums for these specific test > cases (through the -p option of the "run-webkit-tests" script)- Or do you > think that it's better to generate the PNGs and checksums for all the test cases > I'm planning to add? If you can write a test (that breaks before fixing the code) by writing a text-only test case (see "layoutTestController.dumpAsText() in LayoutTests/fast/css/computed-style.html), do that. Image tests take a lot longer to run and should be avoided unless the test requires it. Otherwise, new test cases should have both text and pixel results if they're not text-only tests. (If you're porting to a new platform, I'd get the text-only tests working first, then worry about the image tests later.) > 3- How is the PNGs comparison implemented for regression testing? (in the > text based tests it's a string comparison how about the image based tests?) Checksums of the two images are compared. I take it you haven't looked through the source of the run-webkit-tests script yet? > 4- What are the Checksum files used for? See above. > 5- So, please correct me if there's anything missing in the following steps: > In order to test a WebKit based port other than Safari and Qt with WebKit's > Layout tests I need to: > a- update the "run-webkit-tests" Perl script. > b- port the "DumpRenderTree" app. > c- regenerate the expected results for each of the layout tests > (knowing that the render tree dumps are different for each platform) Test results for a new platform should go under the LayoutTestResults directory in a new "platform" directory. Please make sure that the results are repeatable, e.g., running the tests again after generating the results (both individually and as a group) don't generate any differences unless the WebKit code changes as well. Good luck! Dave From jyh.hsc at 163.com Mon Jun 4 00:46:53 2007 From: jyh.hsc at 163.com (Yihua Jin) Date: Tue Oct 9 17:53:28 2007 Subject: [webkit-dev] Building s60webkits consuming a lot of time Message-ID: <6567122.261731180943213701.JavaMail.coremail@bj163app72.163.com> Hi all: I use the build.bat contains in the s60webkit source package tobuild it and it seems re-build all every time any files is modified.Has anyone encouter the same problem and can share us how you deal with it?thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070604/32a039cd/attachment.html From benm at google.com Mon Jun 4 02:01:15 2007 From: benm at google.com (Ben Murdoch) Date: Tue Oct 9 17:53:28 2007 Subject: [webkit-dev] Building s60webkits consuming a lot of time In-Reply-To: <6567122.261731180943213701.JavaMail.coremail@bj163app72.163.com> References: <6567122.261731180943213701.JavaMail.coremail@bj163app72.163.com> Message-ID: <230a220a0706040201v7511f420uead3d95f1ac9ca9d@mail.gmail.com> Hi Yihua, You can use the build -t command to do a target build that will only build the changed files. Regards, Ben Murdoch On 04/06/07, Yihua Jin wrote: > > Hi all: > > I use the build.bat contains in the s60webkit source package to > build it and it seems re-build all every time any files is modified. > Has anyone encouter the same problem and can share us how you deal with > it? > thanks. > > > > > ------------------------------ > 百 万 同 时 在 线，人 山 人 海 同 玩 梦 幻 西 游 > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070604/0234c983/attachment.html From jyh.hsc at 163.com Mon Jun 4 07:18:14 2007 From: jyh.hsc at 163.com (Jin, Yihua) Date: Tue Oct 9 17:53:28 2007 Subject: [webkit-dev] Building s60webkits consuming a lot of time References: <230a220a0706040201v7511f420uead3d95f1ac9ca9d@mail.gmail.com> Message-ID: Thank you Murdoch, it does work! Jin, Yihua，jyh.hsc@163.com 2007-06-04 ----- Original Message ----- From: Ben Murdoch To: Yihua Jin Sent: 2007-06-04, 17:01:15 Subject: Re: [webkit-dev] Building s60webkits consuming a lot of time Hi Yihua, You can use the build -t command to do a target build that will only build the changed files. Regards, Ben Murdoch On 04/06/07, Yihua Jin wrote: Hi all: I use the build.bat contains in the s60webkit source package to build it and it seems re-build all every time any files is modified. Has anyone encouter the same problem and can share us how you deal with it? thanks. 百 万 同 时 在 线，人 山 人 海 同 玩 梦 幻 西 游 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070604/3a2f6fb3/attachment.html From mbritto at pleyo.com Mon Jun 4 08:20:52 2007 From: mbritto at pleyo.com (Maxime Britto) Date: Tue Oct 9 17:53:28 2007 Subject: [webkit-dev] New contributor Message-ID: Hi everyone,my name is Maxime Britto I'm following an internship at Pleyo and I will contribute to debug the WebKit with you for the next 4 months at least. I would like to focus on AJAX issues and I'm available for any unassigned bug. Regards, Maxime. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070604/c54d4e51/attachment.html From mbritto at pleyo.com Mon Jun 4 08:23:37 2007 From: mbritto at pleyo.com (Maxime Britto) Date: Tue Oct 9 17:53:28 2007 Subject: [webkit-dev] New contributor Message-ID: Hi everyone,my name is Maxime Britto I'm following an internship at Pleyo and I will contribute to debug the WebKit with you for the next 4 months at least. I would like to focus on AJAX issues and I'm available for any unassigned bug. Regards, Maxime. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070604/91b19666/attachment.html From adele at apple.com Mon Jun 4 08:29:30 2007 From: adele at apple.com (Adele Peterson) Date: Tue Oct 9 17:53:28 2007 Subject: [webkit-dev] New contributor In-Reply-To: References: Message-ID: Hi Maxime, Welcome! A good place to start is to take a look at our P1 bugs in Bugzilla. Here's a URL for the query: http://tinyurl.com/yxd5wy Hop on the #webkit IRC channel, and get to know the other WebKit developers. - Adele On Jun 4, 2007, at 8:23 AM, Maxime Britto wrote: > Hi everyone, > my name is Maxime Britto I'm following an internship at Pleyo and I > will contribute to debug the WebKit with you for the next 4 months > at least. > > > I would like to focus on AJAX issues and I'm available for any > unassigned bug. > > > Regards, > Maxime. > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev From tom at windyroad.org Tue Jun 5 20:29:55 2007 From: tom at windyroad.org (Windy Road) Date: Tue Oct 9 17:53:28 2007 Subject: [webkit-dev] Your opinion on a CSS proposal Message-ID: <746049190706052029q18643d9boa02ac8adf626d025@mail.gmail.com> Hi, Sorry in advance if this is the wrong place/way to ask this. I recently posted on the www-style list a proposal for allowing the 'font-size' CSS property to have a value of 'auto': http://lists.w3.org/Archives/Public/www-style/2007Jun/0016.html The basic idea is that when font-size: auto is used, the browser would calculate the font-size based on the element's width margins and padding. A javascript mockup is available at: http://windyroad.org/static/resolution-independence/ What I would like to know, if you can spare the time, is what you, the webkit developers, feel about this proposal. I'm not involved in any browser development, so I don't know the implications such a proposal would have if is at all feasible. Thanks for your time, -- Tom Howard http://windyroad.org From hyatt at apple.com Tue Jun 5 20:58:38 2007 From: hyatt at apple.com (David Hyatt) Date: Tue Oct 9 17:53:28 2007 Subject: [webkit-dev] Your opinion on a CSS proposal In-Reply-To: <746049190706052029q18643d9boa02ac8adf626d025@mail.gmail.com> References: <746049190706052029q18643d9boa02ac8adf626d025@mail.gmail.com> Message-ID: <5AC12EC0-CD16-4BDF-876E-392186497E8E@apple.com> I don't quite understand the proposal. width can be defined in terms of font-size.... therefore it's impossible to define font-size in terms of width. For example, width:50em, font-size:auto would be undefined, since each would depend on the other. dave On Jun 5, 2007, at 8:29 PM, Windy Road wrote: > Hi, > > Sorry in advance if this is the wrong place/way to ask this. > > I recently posted on the www-style list a proposal for allowing the > 'font-size' CSS property to have a value of 'auto': > http://lists.w3.org/Archives/Public/www-style/2007Jun/0016.html > > The basic idea is that when font-size: auto is used, the browser would > calculate the font-size based on the element's width margins and > padding. A javascript mockup is available at: > > http://windyroad.org/static/resolution-independence/ > > What I would like to know, if you can spare the time, is what you, the > webkit developers, feel about this proposal. I'm not involved in any > browser development, so I don't know the implications such a proposal > would have if is at all feasible. > > Thanks for your time, > > -- > Tom Howard > http://windyroad.org > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev From ddkilzer at kilzer.net Tue Jun 5 21:12:34 2007 From: ddkilzer at kilzer.net (David D. Kilzer) Date: Tue Oct 9 17:53:28 2007 Subject: [webkit-dev] Your opinion on a CSS proposal In-Reply-To: <746049190706052029q18643d9boa02ac8adf626d025@mail.gmail.com> Message-ID: <665748.56815.qm@web52402.mail.re2.yahoo.com> You may be interested in these blogs as well: http://webkit.org/blog/55/high-dpi-web-sites/ http://webkit.org/blog/56/high-dpi-part-2/ Dave Windy Road wrote: > Hi, > > Sorry in advance if this is the wrong place/way to ask this. > > I recently posted on the www-style list a proposal for allowing the > 'font-size' CSS property to have a value of 'auto': > http://lists.w3.org/Archives/Public/www-style/2007Jun/0016.html > > The basic idea is that when font-size: auto is used, the browser would > calculate the font-size based on the element's width margins and > padding. A javascript mockup is available at: > > http://windyroad.org/static/resolution-independence/ > > What I would like to know, if you can spare the time, is what you, the > webkit developers, feel about this proposal. I'm not involved in any > browser development, so I don't know the implications such a proposal > would have if is at all feasible. > > Thanks for your time, > > -- > Tom Howard > http://windyroad.org > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > From wjmoore at gmail.com Tue Jun 5 21:21:08 2007 From: wjmoore at gmail.com (Wesley Moore) Date: Tue Oct 9 17:53:28 2007 Subject: [webkit-dev] Your opinion on a CSS proposal In-Reply-To: <746049190706052029q18643d9boa02ac8adf626d025@mail.gmail.com> References: <746049190706052029q18643d9boa02ac8adf626d025@mail.gmail.com> Message-ID: <664f64be0706052121l40928c4bgbf9be65d1ce05a82@mail.gmail.com> Tom, Overlooking for the moment the problem Dave H raised, what would the rendering engine be aiming to do with the text when font-size was auto? I assume this is to make the resolution independent example you've made easier to implement, how does it help that? WM On 6/6/07, Windy Road wrote: > Hi, > > Sorry in advance if this is the wrong place/way to ask this. > > I recently posted on the www-style list a proposal for allowing the > 'font-size' CSS property to have a value of 'auto': > http://lists.w3.org/Archives/Public/www-style/2007Jun/0016.html > > The basic idea is that when font-size: auto is used, the browser would > calculate the font-size based on the element's width margins and > padding. A javascript mockup is available at: > > http://windyroad.org/static/resolution-independence/ > > What I would like to know, if you can spare the time, is what you, the > webkit developers, feel about this proposal. I'm not involved in any > browser development, so I don't know the implications such a proposal > would have if is at all feasible. > > Thanks for your time, > > -- > Tom Howard > http://windyroad.org From tom at windyroad.org Tue Jun 5 21:29:48 2007 From: tom at windyroad.org (Windy Road) Date: Tue Oct 9 17:53:28 2007 Subject: [webkit-dev] Your opinion on a CSS proposal In-Reply-To: <5AC12EC0-CD16-4BDF-876E-392186497E8E@apple.com> References: <746049190706052029q18643d9boa02ac8adf626d025@mail.gmail.com> <5AC12EC0-CD16-4BDF-876E-392186497E8E@apple.com> Message-ID: <746049190706052129s12a5fc0dgcad02c0e1dfad336@mail.gmail.com> On 06/06/07, David Hyatt wrote: > I don't quite understand the proposal. width can be defined in terms > of font-size.... therefore it's impossible to define font-size in > terms of width. For example, width:50em, font-size:auto would be > undefined, since each would depend on the other. Take a block element who's width is auto, generally speaking it's width will be determined by the parent, the parent's padding and the element's margins. A block element with a font relative width and a font-size of auto would have it's width calculated in the same way as the block element with a width of auto. Once the width is calculated, the font-size (in px) is determined by the following formula: font-size = calculated_width_in_px / font_relative_width For example, just say we have a block element with a width of 50em, the font-size is auto and the browser calculates it's width as 1024px. In this case the calculated font-size would be font-size = 1024 / 50 = 20.48 If the browser calculates it's width as 640px, then font-size = 640 / 50 = 12.8 Cheers, -- Tom Howard http://windyroad.org From tom at windyroad.org Tue Jun 5 22:01:58 2007 From: tom at windyroad.org (Windy Road) Date: Tue Oct 9 17:53:28 2007 Subject: [webkit-dev] Your opinion on a CSS proposal In-Reply-To: <664f64be0706052121l40928c4bgbf9be65d1ce05a82@mail.gmail.com> References: <746049190706052029q18643d9boa02ac8adf626d025@mail.gmail.com> <664f64be0706052121l40928c4bgbf9be65d1ce05a82@mail.gmail.com> Message-ID: <746049190706052201h6c804ddcuc5aa4254e31ff22f@mail.gmail.com> On 06/06/07, Wesley Moore wrote: > Overlooking for the moment the problem Dave H raised, what would the > rendering engine be aiming to do with the text when font-size was > auto? I assume this is to make the resolution independent example > you've made easier to implement, how does it help that? Just say you wanted a RI (resolution independent) web page with a body width of 62.5em, which comprises of a main column which is takes up 80% and a secondary column which takes up the remaining 20%. The hope is font-size: auto, would allow you to use the following CSS body { width: 62.5em; font-size: auto; } #main-column { width: 80%; } #secondary-column { width: 20%; } Such a page would look identical on a 640px wide browser as a 1900px wide browser in every aspect, except that the font would be much more detailed in the 1900px wide browser. While the demonstration shows this is achievable with Javascript, there is quite a lot of 'scaffolding' to hold it all together. Also, I feel it is something that belongs more in the realms of CSS than Javascript (you know, the whole separation of responsibilities). I'll also admit that font-size auto does not address how to request the server to deliver a correctly scaled version of an image, video or similar. Cheers, -- Tom Howard http://windyroad.org From hyatt at apple.com Tue Jun 5 22:13:25 2007 From: hyatt at apple.com (David Hyatt) Date: Tue Oct 9 17:53:28 2007 Subject: [webkit-dev] Your opinion on a CSS proposal In-Reply-To: <746049190706052129s12a5fc0dgcad02c0e1dfad336@mail.gmail.com> References: <746049190706052029q18643d9boa02ac8adf626d025@mail.gmail.com> <5AC12EC0-CD16-4BDF-876E-392186497E8E@apple.com> <746049190706052129s12a5fc0dgcad02c0e1dfad336@mail.gmail.com> Message-ID: <10586D57-988D-44AB-A0A7-A27E85045DA6@apple.com> On Jun 5, 2007, at 9:29 PM, Windy Road wrote: > On 06/06/07, David Hyatt wrote: >> I don't quite understand the proposal. width can be defined in terms >> of font-size.... therefore it's impossible to define font-size in >> terms of width. For example, width:50em, font-size:auto would be >> undefined, since each would depend on the other. > > Take a block element who's width is auto, generally speaking it's > width will be determined by the parent, the parent's padding and the > element's margins. A block element with a font relative width and a > font-size of auto would have it's width calculated in the same way as > the block element with a width of auto. Once the width is calculated, > the font-size (in px) is determined by the following formula: > > font-size = calculated_width_in_px / font_relative_width > Except that the width of an element can depend on the font size. If you say "width:50em" that means 50ems using *your* calculated font size. In other words, CSS has already created the restriction that font-size must be calculated before width can be calculated. Your idea is interesting, but it can't really be defined using font- size. It's more of an "after-the-fact" adjiustment based off the calculated width of a block. dave From robburns1 at mac.com Tue Jun 5 22:32:51 2007 From: robburns1 at mac.com (Rob Burns) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Your opinion on a CSS proposal In-Reply-To: <746049190706052201h6c804ddcuc5aa4254e31ff22f@mail.gmail.com> References: <746049190706052029q18643d9boa02ac8adf626d025@mail.gmail.com> <664f64be0706052121l40928c4bgbf9be65d1ce05a82@mail.gmail.com> <746049190706052201h6c804ddcuc5aa4254e31ff22f@mail.gmail.com> Message-ID: <3BAE208C-F83E-44E8-B503-B92FF3119CA3@mac.com> On Jun 6, 2007, at 12:01 AM, Windy Road wrote: > On 06/06/07, Wesley Moore wrote: >> Overlooking for the moment the problem Dave H raised, what would the >> rendering engine be aiming to do with the text when font-size was >> auto? I assume this is to make the resolution independent example >> you've made easier to implement, how does it help that? > > Just say you wanted a RI (resolution independent) web page with a body > width of 62.5em, which comprises of a main column which is takes up > 80% and a secondary column which takes up the remaining 20%. The hope > is font-size: auto, would allow you to use the following CSS > > body { > width: 62.5em; > font-size: auto; > } > > #main-column { > width: 80%; > } > > #secondary-column { > width: 20%; > } > > Such a page would look identical on a 640px wide browser as a 1900px > wide browser in every aspect, except that the font would be much more > detailed in the 1900px wide browser. > > While the demonstration shows this is achievable with Javascript, > there is quite a lot of 'scaffolding' to hold it all together. Also, > I feel it is something that belongs more in the realms of CSS than > Javascript (you know, the whole separation of responsibilities). > > I'll also admit that font-size auto does not address how to request > the server to deliver a correctly scaled version of an image, video or > similar. I think its an interesting idea. However, perhaps it would be better to have an additional property that wouldn't conflict with the font- size property. Something like font-size-transform (to avoid conflict with font-size-adjust though this could still cause author confusion). In this way, the width and height in the box model could continue to bet set relative to font-size (an important part of resolution independent CSS). However, there could be a font-size- transform that scaled the font-size relative to the enclosing content box after the other properties are determined. That's just a reaction off the top of my head. Take care, Rob From tom at windyroad.org Tue Jun 5 22:50:52 2007 From: tom at windyroad.org (Windy Road) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Your opinion on a CSS proposal In-Reply-To: <10586D57-988D-44AB-A0A7-A27E85045DA6@apple.com> References: <746049190706052029q18643d9boa02ac8adf626d025@mail.gmail.com> <5AC12EC0-CD16-4BDF-876E-392186497E8E@apple.com> <746049190706052129s12a5fc0dgcad02c0e1dfad336@mail.gmail.com> <10586D57-988D-44AB-A0A7-A27E85045DA6@apple.com> Message-ID: <746049190706052250u6cc2c3c8p157be9f85d67e6b7@mail.gmail.com> On 06/06/07, David Hyatt wrote: > Except that the width of an element can depend on the font size. And in those situations (say a floated element), specifying font-size: auto would be invalid and should be ignored. > Your idea is interesting, but it can't really be defined using font- > size. It's more of an "after-the-fact" adjiustment based off the > calculated width of a block. So let me rephase the question. Do you think the effect I'm trying to achieve should be specified via CSS or Javascript? If the former, do you have any suggestions on how? Cheers, -- Tom Howard http://windyroad.org From tom at windyroad.org Tue Jun 5 23:04:33 2007 From: tom at windyroad.org (Windy Road) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Your opinion on a CSS proposal In-Reply-To: <3BAE208C-F83E-44E8-B503-B92FF3119CA3@mac.com> References: <746049190706052029q18643d9boa02ac8adf626d025@mail.gmail.com> <664f64be0706052121l40928c4bgbf9be65d1ce05a82@mail.gmail.com> <746049190706052201h6c804ddcuc5aa4254e31ff22f@mail.gmail.com> <3BAE208C-F83E-44E8-B503-B92FF3119CA3@mac.com> Message-ID: <746049190706052304r7a7b1b0y7129db69df95ee4b@mail.gmail.com> On 06/06/07, Rob Burns wrote: > I think its an interesting idea. However, perhaps it would be better > to have an additional property that wouldn't conflict with the font- > size property. Something like font-size-transform (to avoid conflict > with font-size-adjust though this could still cause author > confusion). I thought about this as well, but when I was developing the demo I kept thinking "What I really need is a way in CSS to tell the browser that I don't care what the font size is, just make sure the line length is X characters, whatever the width of the column is." This is why I thought of "font-size: auto" hmm... maybe line-length is a better option. e.g. adjusting my previous example body { width: 100%; line-length: 62.5em; } #main-column { width: 80%; } #secondary-column { width: 20%; } Thoughts? Cheers, -- Tom Howard http://windyroad.org From jyh.hsc at 163.com Wed Jun 6 03:49:33 2007 From: jyh.hsc at 163.com (Jin, Yihua) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Where to handle the stick event? Message-ID: Hi all: What is the event handler in S60 webkit that handle the stick event which use to drive the mouse? Thanks. Best Regards, Yihua -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070606/27be795f/attachment.html From Zalan.Bujtas at nokia.com Wed Jun 6 05:41:15 2007 From: Zalan.Bujtas at nokia.com (Zalan.Bujtas@nokia.com) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Where to handle the stick event? In-Reply-To: References: Message-ID: <889E22FD2A94F14DA52BD0DBBC14545702B28699@daebe102.NOE.Nokia.com> In http://trac.webkit.org/projects/webkit/browser/S60/trunk/WebKit/BrowserV iew/src/KeyEventHandler.cpp , CKeyEventHandler::HandleOfferKeyEventL() function manages the key (including the joystick) events. The joystick events get translated to mouse events in CKeyEventHandler::HandleArrowKeysL() -> CKeyEventHandler::NavigateWithCursor(). You should also take a look at the CWebKitCursor::MoveCursorAdjusted() function, where the new mouse position is calculated and the actual mouse move event is sent to the webcore through the bridge. Zalan. ________________________________ From: webkit-dev-bounces@lists.webkit.org [mailto:webkit-dev-bounces@lists.webkit.org] On Behalf Of ext Jin, Yihua Sent: Wednesday, June 06, 2007 6:50 AM To: webkit-dev Cc: shaoliang_1983 Subject: [webkit-dev] Where to handle the stick event? Hi all: What is the event handler in S60 webkit that handle the stick event which use to drive the mouse? Thanks. Best Regards, Yihua From ajmas at sympatico.ca Wed Jun 6 11:09:17 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] WebForms 2.0 and Webkit Message-ID: <5E318A20-9B20-4441-BE9C-7E68ABACEF86@sympatico.ca> Hi, I have heard that the W3C was working on a specification known as 'Web Forms 2.0'. Does anyone know what the status of this is and whether there are any moves to incorporate this into WebKit or any other mainline rendering engine? Andre From ddkilzer at kilzer.net Wed Jun 6 13:42:53 2007 From: ddkilzer at kilzer.net (David D. Kilzer) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] WebForms 2.0 and Webkit In-Reply-To: <5E318A20-9B20-4441-BE9C-7E68ABACEF86@sympatico.ca> Message-ID: <388883.80434.qm@web52402.mail.re2.yahoo.com> Hi Andre, Is Web Forms 2.0 the same thing as XForms? If so (I think it is), you may be interested in these bugs: http://bugs.webkit.org/show_bug.cgi?id=10048 http://bugs.webkit.org/show_bug.cgi?id=13815 Dave Andre-John Mas wrote: > Hi, > > I have heard that the W3C was working on a specification known > as 'Web Forms 2.0'. Does anyone know what the status of this is > and whether there are any moves to incorporate this into > WebKit or any other mainline rendering engine? > > Andre From ajmas at sympatico.ca Wed Jun 6 14:12:39 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] WebForms 2.0 and Webkit In-Reply-To: <388883.80434.qm@web52402.mail.re2.yahoo.com> References: <388883.80434.qm@web52402.mail.re2.yahoo.com> Message-ID: <0570A32F-A1FF-4D1F-AFC3-8679E4CACFA7@sympatico.ca> Hi Dave, Not really sure. I saw it mentioned here amongst other places: http://dev.opera.com/articles/view/making-wii-friendly-pages/ and here: http://www.whatwg.org/specs/web-forms/current-work/ Amongst the additions there seems to be a 'date' input field. Andre On 6-Jun-07, at 16:42 , David D. Kilzer wrote: > Hi Andre, > > Is Web Forms 2.0 the same thing as XForms? If so (I think it is), > you may be > interested in these bugs: > > http://bugs.webkit.org/show_bug.cgi?id=10048 > http://bugs.webkit.org/show_bug.cgi?id=13815 > > Dave > > > Andre-John Mas wrote: > >> Hi, >> >> I have heard that the W3C was working on a specification known >> as 'Web Forms 2.0'. Does anyone know what the status of this is >> and whether there are any moves to incorporate this into >> WebKit or any other mainline rendering engine? >> >> Andre From mjs at apple.com Wed Jun 6 14:15:20 2007 From: mjs at apple.com (Maciej Stachowiak) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] WebForms 2.0 and Webkit In-Reply-To: <5E318A20-9B20-4441-BE9C-7E68ABACEF86@sympatico.ca> References: <5E318A20-9B20-4441-BE9C-7E68ABACEF86@sympatico.ca> Message-ID: <12F6E181-6F2D-424F-8787-A39DE81F4088@apple.com> On Jun 6, 2007, at 11:09 AM, Andre-John Mas wrote: > Hi, > > I have heard that the W3C was working on a specification known > as 'Web Forms 2.0'. Does anyone know what the status of this is > and whether there are any moves to incorporate this into > WebKit or any other mainline rendering engine? The Web Forms 2.0 spec was originally created by the WHAT Working Group . It has been adopted by the W3C as part of HTML5, and we'll likely support some of its features as it gets reviewed and integrated into the main HTML5 spec. (It is not at all the same thing as XForms.) Regards, Maciej From hyatt at apple.com Wed Jun 6 14:15:58 2007 From: hyatt at apple.com (David Hyatt) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] WebForms 2.0 and Webkit In-Reply-To: <388883.80434.qm@web52402.mail.re2.yahoo.com> References: <388883.80434.qm@web52402.mail.re2.yahoo.com> Message-ID: <39D26591-41CC-409F-A4ED-ABD64369222D@apple.com> Web Forms 2 is a subset of HTML5. It is not XForms. Speaking for Apple, we do plan to work on Web Forms 2 support eventually. We have no plans to work on XForms, but contributions/patches are always welcome. dave On Jun 6, 2007, at 1:42 PM, David D. Kilzer wrote: > Hi Andre, > > Is Web Forms 2.0 the same thing as XForms? If so (I think it is), > you may be > interested in these bugs: > > http://bugs.webkit.org/show_bug.cgi?id=10048 > http://bugs.webkit.org/show_bug.cgi?id=13815 > > Dave > > > Andre-John Mas wrote: > >> Hi, >> >> I have heard that the W3C was working on a specification known >> as 'Web Forms 2.0'. Does anyone know what the status of this is >> and whether there are any moves to incorporate this into >> WebKit or any other mainline rendering engine? >> >> Andre > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev From tom at windyroad.org Wed Jun 6 22:35:19 2007 From: tom at windyroad.org (Windy Road) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Your opinion on a CSS proposal In-Reply-To: <665748.56815.qm@web52402.mail.re2.yahoo.com> References: <746049190706052029q18643d9boa02ac8adf626d025@mail.gmail.com> <665748.56815.qm@web52402.mail.re2.yahoo.com> Message-ID: <746049190706062235qe172d40y9a92d5b2a9d4439c@mail.gmail.com> On 06/06/07, David D. Kilzer wrote: > You may be interested in these blogs as well: > > http://webkit.org/blog/55/high-dpi-web-sites/ > http://webkit.org/blog/56/high-dpi-part-2/ Thanks for the heads up. I did find them interesting. Anyone got any thoughts on how to deliver high resolution images to high DPI screens and low resolution images to low DPI screens. Cheers, -- Tom Howard http://windyroad.org From robburns1 at mac.com Wed Jun 6 22:59:31 2007 From: robburns1 at mac.com (Rob Burns) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Your opinion on a CSS proposal In-Reply-To: <746049190706062235qe172d40y9a92d5b2a9d4439c@mail.gmail.com> References: <746049190706052029q18643d9boa02ac8adf626d025@mail.gmail.com> <665748.56815.qm@web52402.mail.re2.yahoo.com> <746049190706062235qe172d40y9a92d5b2a9d4439c@mail.gmail.com> Message-ID: <0ECE0DB0-1D34-4CB7-81AF-CC3067AC288F@mac.com> Its not easy to do these days. In my opinion, this is one of the key features needed for an HTTP 1.2 (along with event/change notifications and a few other things). Apache can probably be configured to do this, but I'm not sure that there's a way to easily get the HTTP clients to request a particular resolution. Take care, Rob On Jun 7, 2007, at 12:35 AM, Windy Road wrote: > On 06/06/07, David D. Kilzer wrote: >> You may be interested in these blogs as well: >> >> http://webkit.org/blog/55/high-dpi-web-sites/ >> http://webkit.org/blog/56/high-dpi-part-2/ > > Thanks for the heads up. I did find them interesting. > > Anyone got any thoughts on how to deliver high resolution images to > high DPI screens and low resolution images to low DPI screens. > > Cheers, > > -- > Tom Howard > http://windyroad.org > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev From bdash at webkit.org Wed Jun 6 23:11:22 2007 From: bdash at webkit.org (Mark Rowe) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Your opinion on a CSS proposal In-Reply-To: <746049190706062235qe172d40y9a92d5b2a9d4439c@mail.gmail.com> References: <746049190706052029q18643d9boa02ac8adf626d025@mail.gmail.com> <665748.56815.qm@web52402.mail.re2.yahoo.com> <746049190706062235qe172d40y9a92d5b2a9d4439c@mail.gmail.com> Message-ID: <38A8CF8F-697E-478B-92AA-69BA43623AEA@webkit.org> On 07/06/2007, at 3:35 PM, Windy Road wrote: > On 06/06/07, David D. Kilzer wrote: >> You may be interested in these blogs as well: >> >> http://webkit.org/blog/55/high-dpi-web-sites/ >> http://webkit.org/blog/56/high-dpi-part-2/ > > Thanks for the heads up. I did find them interesting. > > Anyone got any thoughts on how to deliver high resolution images to > high DPI screens and low resolution images to low DPI screens. mentions using CSS 3's media queries to target a portion of a stylesheet based on the devices DPI. See for more information. - Mark From ddkilzer at kilzer.net Wed Jun 6 23:11:54 2007 From: ddkilzer at kilzer.net (David D. Kilzer) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Your opinion on a CSS proposal In-Reply-To: <0ECE0DB0-1D34-4CB7-81AF-CC3067AC288F@mac.com> Message-ID: <20070607061154.99105.qmail@web52411.mail.re2.yahoo.com> Wasn't one of Hyatt's suggestions that the author of the web page provide references to both a low-res and a high-res image so that the client (which knows most about which one to use) may chose the correct one? Dave Rob Burns wrote: > Its not easy to do these days. In my opinion, this is one of the key > features needed for an HTTP 1.2 (along with event/change > notifications and a few other things). Apache can probably be > configured to do this, but I'm not sure that there's a way to easily > get the HTTP clients to request a particular resolution. > > Take care, > Rob > > > On Jun 7, 2007, at 12:35 AM, Windy Road wrote: > > > On 06/06/07, David D. Kilzer wrote: > >> You may be interested in these blogs as well: > >> > >> http://webkit.org/blog/55/high-dpi-web-sites/ > >> http://webkit.org/blog/56/high-dpi-part-2/ > > > > Thanks for the heads up. I did find them interesting. > > > > Anyone got any thoughts on how to deliver high resolution images to > > high DPI screens and low resolution images to low DPI screens. > > > > Cheers, > > > > -- > > Tom Howard > > http://windyroad.org > From robburns1 at mac.com Thu Jun 7 01:22:06 2007 From: robburns1 at mac.com (Rob Burns) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Your opinion on a CSS proposal In-Reply-To: <20070607061154.99105.qmail@web52411.mail.re2.yahoo.com> References: <20070607061154.99105.qmail@web52411.mail.re2.yahoo.com> Message-ID: On Jun 7, 2007, at 1:11 AM, David D. Kilzer wrote: > Wasn't one of Hyatt's suggestions that the author of the web page > provide > references to both a low-res and a high-res image so that the > client (which > knows most about which one to use) may chose the correct one? > > Dave That sounds familiar. However, resolution specific content negotiation would be better supported through a rev to the http protocol. It could be done now with some javascripting or CSS media queries (for CSS urls anyway), but by adding it to http, it could just work with little effort on the author's or server admin's part. Rob > > Rob Burns wrote: > >> Its not easy to do these days. In my opinion, this is one of the key >> features needed for an HTTP 1.2 (along with event/change >> notifications and a few other things). Apache can probably be >> configured to do this, but I'm not sure that there's a way to easily >> get the HTTP clients to request a particular resolution. >> >> Take care, >> Rob >> >> >> On Jun 7, 2007, at 12:35 AM, Windy Road wrote: >> >>> On 06/06/07, David D. Kilzer wrote: >>>> You may be interested in these blogs as well: >>>> >>>> http://webkit.org/blog/55/high-dpi-web-sites/ >>>> http://webkit.org/blog/56/high-dpi-part-2/ >>> >>> Thanks for the heads up. I did find them interesting. >>> >>> Anyone got any thoughts on how to deliver high resolution images to >>> high DPI screens and low resolution images to low DPI screens. >>> >>> Cheers, >>> >>> -- >>> Tom Howard >>> http://windyroad.org >> > From ajmas at sympatico.ca Thu Jun 7 06:24:57 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Your opinion on a CSS proposal In-Reply-To: <746049190706062235qe172d40y9a92d5b2a9d4439c@mail.gmail.com> References: <746049190706052029q18643d9boa02ac8adf626d025@mail.gmail.com> <665748.56815.qm@web52402.mail.re2.yahoo.com> <746049190706062235qe172d40y9a92d5b2a9d4439c@mail.gmail.com> Message-ID: <06A90CBF-0F49-46E8-BCFF-FEFFDE0E7DEF@sympatico.ca> Hi, Is the idea to ensure that the image is displayed at about the same size on both screens, or that less data is sent in the low-res scenario? One thing that should be noted is that the 'IMG' HTML tag has a 'LOWSRC' attribute, which is intended for a low resolution version of the image, but I don't think that ever made it into CSS. If a low-res device happens to be a TV, then there is a media type 'tv' which can be specified so the right CSS is used. Just a quick look at CSS and I see that 'absolute' units are available for specifying size, such as in, cm and mm. See: http://htmlhelp.com/reference/css/units.html Andre On 7-Jun-07, at 01:35 , Windy Road wrote: > On 06/06/07, David D. Kilzer wrote: >> You may be interested in these blogs as well: >> >> http://webkit.org/blog/55/high-dpi-web-sites/ >> http://webkit.org/blog/56/high-dpi-part-2/ > > Thanks for the heads up. I did find them interesting. > > Anyone got any thoughts on how to deliver high resolution images to > high DPI screens and low resolution images to low DPI screens. > > Cheers, > > -- > Tom Howard > http://windyroad.org > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev From contact at nickshanks.com Thu Jun 7 06:27:20 2007 From: contact at nickshanks.com (Nicholas Shanks) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070607/81949527/smime.bin From tom at windyroad.org Thu Jun 7 06:39:28 2007 From: tom at windyroad.org (Windy Road) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Your opinion on a CSS proposal In-Reply-To: <20070607061154.99105.qmail@web52411.mail.re2.yahoo.com> References: <0ECE0DB0-1D34-4CB7-81AF-CC3067AC288F@mac.com> <20070607061154.99105.qmail@web52411.mail.re2.yahoo.com> Message-ID: <746049190706070639s42cb9230s707e132a625ee594@mail.gmail.com> On 07/06/07, Mark Rowe wrote: > > Anyone got any thoughts on how to deliver high resolution images to > > high DPI screens and low resolution images to low DPI screens. > > -dpi-web-sites/> mentions using CSS 3's > media queries to target a portion of a stylesheet based on the devices > DPI. See for more > information. On 07/06/07, David D. Kilzer wrote: > Wasn't one of Hyatt's suggestions that the author of the web page provide > references to both a low-res and a high-res image so that the client (which > knows most about which one to use) may chose the correct one? Sorry guys, I should have been more specific. David's reference to media queried applies to background images, border images and the like (i.e design constructs). My question was in regards to img elements (jpgs, pngs, etc, not svgs) and other types of non-textual content (movies, etc). Cheers, -- Tom Howard http://windyroad.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070607/bb9b2bcb/attachment.html From speck at vitality.dk Thu Jun 7 08:28:54 2007 From: speck at vitality.dk (Peter Speck) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal In-Reply-To: References: Message-ID: Hi, > Accept-Resolution: 116.66 dpi > ... > In this instance, the 144 DPI stylesheet would be returned, because > it is the next size up, with a header: > > Content-Resolution: 144 dpi > > The client would thus know there was a resolution mis-match and > (optionally) perform a correction on the CSS values. > (the mechanism assumes higher is better, and scaling down is > preferable to scaling up from 72 dpi. Apple's iPhone has a screen > resolution of 160dpi, and so would get the 288dpi stylesheet, even > though the 144 is a closer match, and the laptop with a web page > zoom of 200% would request 233.33 dpi) Why force a "next size up" if most UAs prefer a dpi which is "close enough"? All the other Accept-XXX headers (except Accept-Ranges) uses a wildcard if other values are accepted, e.g. (RFC 2616) section 14.2: Accept-Charset: iso-8859-5, * section 14.3: Accept-Encoding: gzip, * section 14.4: Accept-Language: da, en, * All 3 supports adding a "quality value which represents the user's preference for that charset/...". Could this be used to allow the UA to tell the server if it wants a "higher up" or "closest"? I assume this would be used too when printing a web-page, so the printed output can use high-resultion images. (I've implemented a page which uses high-resolution GIFs for icons, and it is a pita to maintain). But how are the browser going to know which files it should re- request when printing the page? All, or only those with a "Content- Resolution"? > ? A "dpcm" (dots per centimetre) parameter could also be understood > by both ends and converted as necessary. As a web-server implementor, I would prefer keeping the standard as simple as possible (i.e. KISS), especially with options almost no browsers are going to use. Your scheme for selecting the proper css file works spendid with dpcm values converted to dpi. If a webserver wants to support .css files named using dpcm, e.g. "default. 30dpcm.css", that's fine, but don't make the protocol more complex. Continuing with this, I would remove "dpi" from the header value, and simply define both headers value to be dpi. ---- - Peter Speck From robburns1 at mac.com Thu Jun 7 08:29:02 2007 From: robburns1 at mac.com (Rob Burns) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal In-Reply-To: References: Message-ID: <4C71D60E-8E8D-44AE-B65D-0DB87F268DF3@mac.com> On Jun 7, 2007, at 8:27 AM, Nicholas Shanks wrote: > It has been mentioned on the Safari WebKit development mailing list > that a HTTP header which specified a document's target resolution > would be useful to allow clients to negotiate for high-res or low- > res artwork and CSS referring to such (background-image, and the > like), depending on their screen pixels, printer resolution, etc. > I would like to propose this to the Working Group. > My ideas are as follows: > > > The client (a laptop, say) requests - > > GET /style/default HTTP/1.2 > Host: example.com > Accept-Content: text/css, text/dsssl, text/xsl > Accept-Resolution: 116.66 dpi > > > The server has the following to choose from: > > default.72dpi.css > default.144dpi.css > default.288dpi.css > default.2400dpi.css > > > In this instance, the 144 DPI stylesheet would be returned, because > it is the next size up, with a header: > > Content-Resolution: 144 dpi > > The client would thus know there was a resolution mis-match and > (optionally) perform a correction on the CSS values. > (the mechanism assumes higher is better, and scaling down is > preferable to scaling up from 72 dpi. Apple's iPhone has a screen > resolution of 160dpi, and so would get the 288dpi stylesheet, even > though the 144 is a closer match, and the laptop with a web page > zoom of 200% would request 233.33 dpi) > > > Furthermore: > > ? Images served with a Content-Resolution header could have their > resolution trusted (most web browsers today display one pixel on > screen per pixel in the bitmap, and ignore the image's internal > resolution parameter, if one exists). If they don't match, probably > best to use the image's internal one. There could also be a special > "Content-Resolution: auto-adjust" header meaning that the server > doesn't know the resolution at content-negotiation time, but wants > the client to scale it according to the image's internal value > anyway, and not do a pixel-to-pixel mapping. > > ? A "dpcm" (dots per centimetre) parameter could also be understood > by both ends and converted as necessary. > > > What do people think? I've only spent an hour or so pondering this, > so it won't be bulletproof yet. > That's a responsive proposal process. Thanks for picking up on that. Let me just add a few of my own thoughts on how I think this should work. Imagine three different clients all loading the same document over http. Also imagine that all dimensions are specified in physical dimensions (pixels complicate things and they're a moving target in terms of software interpretation).. * The document includes an image with dimensions 6 inches by 4 inches. * The clients are - 1200 DPI printer printing via url request at 100% zoom - Firefox on a 96dpi display at 67% zoom - Safari on an iPhone with 160dpi display at 50% zoom Each cleint calculates the resolution based on its current zoom (in other words base magnification) level (clients could get more sophisticated and request based on expected zoom level if it expects to change while displaying the image; but that should probably be left out of the spec). Following your suggestion, each client always rounds up to the next integer value and returns the pixel dimensions (both width and height). So for each client - 4 inches at 100% on a 1200 dpi display equates to 4800 pixels - 6 inches at 100% on a 1200 dpi display equates to 7200 pixels - 4 inches at 67% on a 96 dpi display equates to 258 pixels - 6 inches at 67% on a 96 dpi display equates to 386 pixels - 4 inches at 50% on a 160 dpi display equates to 320 pixels - 6 inches at 50% on a 160 dpi display equates to 480 pixels Basically each client multiplies its device resolution by its base zoom level and returns its effective ppi resolution. So I think the content negotiation should look more like (for the iPhone for example): GET /style/default HTTP/1.2 Host: example.com Accept-Content: text/css, text/dsssl, text/xsl Accept-Resolution: 80 ppi So for resolution independence we want authors to specify dimensions in absolute (physical) units. However content negotiation of bitmap related content should be based on ppi. If the display is stretched in any way perhaps the protocol should allow for two ppi dimensions to reflect the different horizontal and vertical ppi resolutions. Hope this is clear. Take care, Rob From contact at nickshanks.com Thu Jun 7 09:00:50 2007 From: contact at nickshanks.com (Nicholas Shanks) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal In-Reply-To: References: Message-ID: <67665842-FF4E-4557-A8DE-CFFE0A452B8F@nickshanks.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070607/dcb70e71/smime.bin From mjs at apple.com Thu Jun 7 12:58:32 2007 From: mjs at apple.com (Maciej Stachowiak) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal In-Reply-To: References: Message-ID: <906EE7AC-BBFC-4671-86C0-D33A19C59765@apple.com> On Jun 7, 2007, at 6:27 AM, Nicholas Shanks wrote: > It has been mentioned on the Safari WebKit development mailing list > that a HTTP header which specified a document's target resolution > would be useful to allow clients to negotiate for high-res or low- > res artwork and CSS referring to such (background-image, and the > like), depending on their screen pixels, printer resolution, etc. I don't think it's a good idea to handle this at the HTTP level, because that requires server-side changes and approaches are possible which handle things purely on the client side. > I would like to propose this to the Working Group. > My ideas are as follows: > > > The client (a laptop, say) requests - > > GET /style/default HTTP/1.2 > Host: example.com > Accept-Content: text/css, text/dsssl, text/xsl > Accept-Resolution: 116.66 dpi This is a bad idea for a number of reasons: 1) CSS already has media queries to select from multiple stylesheets in HTML/XML, or to select from multiple blocks in a single stylesheet. 2) DPI is not really the relevant factor to make the decision, what's important is the UI scale factor. If I'm running at 144 DPI but at 1x scale, I want the same images as at 72 dpi 1x scale. 3) Passing the resolution to the server forces the selection logic to be on the server side, not the client. But that's not really sensible - if the server has multiple resolution versions of a resource, such as an image, it should advertise them to the client and let the client choose. For example, at 1.5 UI scale factor, if the server has 3x and 2x images available the client could reasonably choose 2x (the next scale up) or 3x (since it is an integer multiple of the scale factor). > > > The server has the following to choose from: > > default.72dpi.css > default.144dpi.css > default.288dpi.css > default.2400dpi.css > > > In this instance, the 144 DPI stylesheet would be returned, because > it is the next size up, with a header: > > Content-Resolution: 144 dpi > > The client would thus know there was a resolution mis-match and > (optionally) perform a correction on the CSS values. > (the mechanism assumes higher is better, and scaling down is > preferable to scaling up from 72 dpi. Apple's iPhone has a screen > resolution of 160dpi, and so would get the 288dpi stylesheet, even > though the 144 is a closer match, and the laptop with a web page > zoom of 200% would request 233.33 dpi) This doesn't make sense with the way clients actually work. What you care about with images embedded in web content is the relative scale of CSS pixels relative to device pixels, which does not have any necessary direct relation to the physical DPI. You don't actually want to serve different images to different DPI screens if they are both running at the same scale factor. > > > Furthermore: > > ? Images served with a Content-Resolution header could have their > resolution trusted (most web browsers today display one pixel on > screen per pixel in the bitmap, and ignore the image's internal > resolution parameter, if one exists). If they don't match, probably > best to use the image's internal one. There could also be a special > "Content-Resolution: auto-adjust" header meaning that the server > doesn't know the resolution at content-negotiation time, but wants > the client to scale it according to the image's internal value > anyway, and not do a pixel-to-pixel mapping. > > ? A "dpcm" (dots per centimetre) parameter could also be understood > by both ends and converted as necessary. > > > What do people think? I've only spent an hour or so pondering this, > so it won't be bulletproof yet. I think the whole design of it is wrong. It's based on DPI instead of scale factor, it pushes the decision to the server when it should be made on the client side, and it handles things at the HTTP level that should be (and indeed are) handled by CSS media queries. Regards, Maciej From mjs at apple.com Thu Jun 7 13:00:39 2007 From: mjs at apple.com (Maciej Stachowiak) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal In-Reply-To: <67665842-FF4E-4557-A8DE-CFFE0A452B8F@nickshanks.com> References: <67665842-FF4E-4557-A8DE-CFFE0A452B8F@nickshanks.com> Message-ID: On Jun 7, 2007, at 9:00 AM, Nicholas Shanks wrote: > Sorry, > >> Accept-Content: text/css, text/dsssl, text/xsl > > should of course have referred to "Accept-Type" :-) Actually it should have been "Accept:". There is no Accept-Type header. - Maciej From robburns1 at mac.com Thu Jun 7 13:26:01 2007 From: robburns1 at mac.com (Rob Burns) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal In-Reply-To: <906EE7AC-BBFC-4671-86C0-D33A19C59765@apple.com> References: <906EE7AC-BBFC-4671-86C0-D33A19C59765@apple.com> Message-ID: Macej, I think you misunderstand the proposal. It does take scale factor into account. It also is meant to handle other cases (not just CSS). I do think you're right about the server advertising the possibilities, but that would probably complicate things a lot. In any case its better than simply getting a one-size-fits all bitmap image. Take care, Rob On Jun 7, 2007, at 2:58 PM, Maciej Stachowiak wrote: > > On Jun 7, 2007, at 6:27 AM, Nicholas Shanks wrote: > >> It has been mentioned on the Safari WebKit development mailing >> list that a HTTP header which specified a document's target >> resolution would be useful to allow clients to negotiate for high- >> res or low-res artwork and CSS referring to such (background- >> image, and the like), depending on their screen pixels, printer >> resolution, etc. > > I don't think it's a good idea to handle this at the HTTP level, > because that requires server-side changes and approaches are > possible which handle things purely on the client side. > >> I would like to propose this to the Working Group. >> My ideas are as follows: >> >> >> The client (a laptop, say) requests - >> >> GET /style/default HTTP/1.2 >> Host: example.com >> Accept-Content: text/css, text/dsssl, text/xsl >> Accept-Resolution: 116.66 dpi > > This is a bad idea for a number of reasons: > > 1) CSS already has media queries to select from multiple > stylesheets in HTML/XML, or to select from multiple blocks in a > single stylesheet. This is meant for a more flexible approach that also works outside CSS. > > 2) DPI is not really the relevant factor to make the decision, > what's important is the UI scale factor. If I'm running at 144 DPI > but at 1x scale, I want the same images as at 72 dpi 1x scale. > Don't you mean 0.5x scale? > 3) Passing the resolution to the server forces the selection logic > to be on the server side, not the client. But that's not really > sensible - if the server has multiple resolution versions of a > resource, such as an image, it should advertise them to the client > and let the client choose. For example, at 1.5 UI scale factor, if > the server has 3x and 2x images available the client could > reasonably choose 2x (the next scale up) or 3x (since it is an > integer multiple of the scale factor). > This is a valid issue, but perhaps it could be addressed in the proposal. Its better than the alternative of no non-css approach. However, keep in mind that In a purse CSS environment, the author doesn't take into consideration the processing needs off the client anymore than the server does. The CSS (written by the author) will determine which pixel dimension image the client gets). > This doesn't make sense with the way clients actually work. What > you care about with images embedded in web content is the relative > scale of CSS pixels relative to device pixels, which does not have > any necessary direct relation to the physical DPI. You don't > actually want to serve different images to different DPI screens if > they are both running at the same scale factor. I think you're saying the same thing in different language. Both Mac OS X and CSS were designed with resolution independence in mind. The distinction over devise pixels and CSS pixels merely muddies the issue. An image that's specified to be 4 inches square on a 96dpi display at 50% zoom is 192 pixels square (however you want to say it). Getting that pixel dimension image delivered form the server is what we're looking for (or perhaps a different pixel dimension if the client expects a resizing or immediate printing). > I think the whole design of it is wrong. It's based on DPI instead > of scale factor, it pushes the decision to the server when it > should be made on the client side, and it handles things at the > HTTP level that should be (and indeed are) handled by CSS media > queries. I think you should take another look at it. Your objections don't really address the proposal. Take care, Rob From mjs at apple.com Thu Jun 7 13:38:46 2007 From: mjs at apple.com (Maciej Stachowiak) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal In-Reply-To: References: <906EE7AC-BBFC-4671-86C0-D33A19C59765@apple.com> Message-ID: <964E7DB7-E35F-4D48-952A-227B7E600375@apple.com> On Jun 7, 2007, at 1:26 PM, Rob Burns wrote: > Macej, > > I think you misunderstand the proposal. It does take scale factor > into account. It also is meant to handle other cases (not just CSS). > I do think you're right about the server advertising the > possibilities, but that would probably complicate things a lot. It can be done in the CSS file for CSS backgrounds using media queries, this allows things to work without any server-side changes. The only case that needs to be addressed better IMO is foreground images via . And that should probably be handled at the HTML or CSS level, not the HTTP level. > In any case its better than simply getting a one-size-fits all > bitmap image. The scale factor is the only thing that *actually* matters. The DPI is irrelevant. (And as Hyatt pointed out, the actual scaling an image gets might depend on the specific context in the page.) - Maciej > > > Take care, > Rob > > On Jun 7, 2007, at 2:58 PM, Maciej Stachowiak wrote: > >> >> On Jun 7, 2007, at 6:27 AM, Nicholas Shanks wrote: >> >>> It has been mentioned on the Safari WebKit development mailing >>> list that a HTTP header which specified a document's target >>> resolution would be useful to allow clients to negotiate for high- >>> res or low-res artwork and CSS referring to such (background- >>> image, and the like), depending on their screen pixels, printer >>> resolution, etc. >> >> I don't think it's a good idea to handle this at the HTTP level, >> because that requires server-side changes and approaches are >> possible which handle things purely on the client side. >> >>> I would like to propose this to the Working Group. >>> My ideas are as follows: >>> >>> >>> The client (a laptop, say) requests - >>> >>> GET /style/default HTTP/1.2 >>> Host: example.com >>> Accept-Content: text/css, text/dsssl, text/xsl >>> Accept-Resolution: 116.66 dpi >> >> This is a bad idea for a number of reasons: >> >> 1) CSS already has media queries to select from multiple >> stylesheets in HTML/XML, or to select from multiple blocks in a >> single stylesheet. > > This is meant for a more flexible approach that also works outside > CSS. > >> >> 2) DPI is not really the relevant factor to make the decision, >> what's important is the UI scale factor. If I'm running at 144 DPI >> but at 1x scale, I want the same images as at 72 dpi 1x scale. >> > > Don't you mean 0.5x scale? > >> 3) Passing the resolution to the server forces the selection logic >> to be on the server side, not the client. But that's not really >> sensible - if the server has multiple resolution versions of a >> resource, such as an image, it should advertise them to the client >> and let the client choose. For example, at 1.5 UI scale factor, if >> the server has 3x and 2x images available the client could >> reasonably choose 2x (the next scale up) or 3x (since it is an >> integer multiple of the scale factor). >> > > This is a valid issue, but perhaps it could be addressed in the > proposal. Its better than the alternative of no non-css approach. > However, keep in mind that In a purse CSS environment, the author > doesn't take into consideration the processing needs off the client > anymore than the server does. The CSS (written by the author) will > determine which pixel dimension image the client gets). > >> This doesn't make sense with the way clients actually work. What >> you care about with images embedded in web content is the relative >> scale of CSS pixels relative to device pixels, which does not have >> any necessary direct relation to the physical DPI. You don't >> actually want to serve different images to different DPI screens if >> they are both running at the same scale factor. > > I think you're saying the same thing in different language. Both Mac > OS X and CSS were designed with resolution independence in mind. The > distinction over devise pixels and CSS pixels merely muddies the > issue. An image that's specified to be 4 inches square on a 96dpi > display at 50% zoom is 192 pixels square (however you want to say > it). Getting that pixel dimension image delivered form the server is > what we're looking for (or perhaps a different pixel dimension if > the client expects a resizing or immediate printing). > > >> I think the whole design of it is wrong. It's based on DPI instead >> of scale factor, it pushes the decision to the server when it >> should be made on the client side, and it handles things at the >> HTTP level that should be (and indeed are) handled by CSS media >> queries. > > I think you should take another look at it. Your objections don't > really address the proposal. > > Take care, > Rob From contact at nickshanks.com Thu Jun 7 13:53:29 2007 From: contact at nickshanks.com (Nicholas Shanks) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal In-Reply-To: <906EE7AC-BBFC-4671-86C0-D33A19C59765@apple.com> References: <906EE7AC-BBFC-4671-86C0-D33A19C59765@apple.com> Message-ID: On 7 Jun 2007, at 20:58, Maciej Stachowiak wrote: > 2) DPI is not really the relevant factor to make the decision, > what's important is the UI scale factor. If I'm running at 144 DPI > but at 1x scale, I want the same images as at 72 dpi 1x scale. I presume you meant "72 dpi 2x scale" there. In that case just ask for 144 in the request. The server doesn't need to know whether it's a high res screen or a low res one zoomed in, only how many pixels you've got to fill so it can pick the 2 MB photo or the 30 MB photo. > I think the whole design of it is wrong. It's based on DPI instead > of scale factor, It is based on both, the client apply the scale to the output dpi before making the request, so it doesn't ignore scale factor, it's pre-multiplied beforehand. > it pushes the decision to the server when it should be made on the > client side This is a good example and something that cannot easily be done at present - client-side selection. The only way i see to do that would be to preflight each request with a GET with "Accept: *;q=0" header, wait for the 406 response, and make a second request by selecting from the list given. The server would also need to provide the DPI of the images. The problem here is for most resources there is only one choice, but you have to make two trips to the server for it. I know of no means for a client to say "I want this resource, send me a list of choices if there are any, or the resource otherwise". Perhaps there ought to be a CHOICES method that either returns a 406 list if there are choices, or returns the 200 result like GET would have done if and only if there was one choice. CHOICES would never do server-side content selection. Then you would only have one request for most resources, and two for the negotiable ones, yet do the selection on the client side. The problem with GET is it might succeed in selecting a resource that you didn't want, and when it does, the Vary header isn't detailed enough to tell you what else might be more appropriate. Also bear in mind it's infinitely easier for an administrator wanting to deploy high-res images to update his server software than to persuade all his users to upgrade theirs! Whilst I can't see a way of getting the result without updating both, further refinements on the server can improve all clients that send the new header, without them needing to update too. > and it handles things at the HTTP level that should be (and indeed > are) handled by CSS media queries. What about when CSS is not available? What about when you don't control either the CSS or the image resource? (e.g. adverts on a 3rd party server) What about when you don't know what variants of a resource there may be now or in the future? > What you care about with images embedded in web content And what about images not in web content? I agree, use media queries where HTML+CSS is available and you can control both the CSS and the images, but you need to fall back to content negotiation otherwise. - Nicholas. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070607/b7200c84/smime.bin From ajmas at sympatico.ca Thu Jun 7 13:52:10 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal In-Reply-To: <964E7DB7-E35F-4D48-952A-227B7E600375@apple.com> References: <906EE7AC-BBFC-4671-86C0-D33A19C59765@apple.com> <964E7DB7-E35F-4D48-952A-227B7E600375@apple.com> Message-ID: <959F3F28-68A4-428E-8719-D1BCC76293F2@sympatico.ca> Surely all of this becomes moot if we specify objects in terms of inches, cm or mm, all of which are already supported by css? A browser that interprets these 'absolute' units properly should already know what DPI the current environment is in, or have access to the necessary API to display correctly. The problem that we have today is that some environments don't tell the application the real DPI, so the application is left guessing and mis-rendering things on screen. The other thing that must be taken account is that on a multi-headed computer you may have two screens each with different DPIs. If you were to send DPIs to a server, which one would you use? It is for reasons such as this, that I believe, that it is important that it the responsibility of the local system to work this out, with the appropriates hints from the web page. Andre On 7-Jun-07, at 16:38 , Maciej Stachowiak wrote: > > On Jun 7, 2007, at 1:26 PM, Rob Burns wrote: > >> Macej, >> >> I think you misunderstand the proposal. It does take scale factor >> into account. It also is meant to handle other cases (not just >> CSS). I do think you're right about the server advertising the >> possibilities, but that would probably complicate things a lot. > > It can be done in the CSS file for CSS backgrounds using media > queries, this allows things to work without any server-side > changes. The only case that needs to be addressed better IMO is > foreground images via . And that should probably be handled at > the HTML or CSS level, not the HTTP level. > >> In any case its better than simply getting a one-size-fits all >> bitmap image. > > The scale factor is the only thing that *actually* matters. The DPI > is irrelevant. (And as Hyatt pointed out, the actual scaling an > image gets might depend on the specific context in the page.) > > - Maciej > From contact at nickshanks.com Thu Jun 7 14:55:59 2007 From: contact at nickshanks.com (Nicholas Shanks) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal In-Reply-To: <959F3F28-68A4-428E-8719-D1BCC76293F2@sympatico.ca> References: <906EE7AC-BBFC-4671-86C0-D33A19C59765@apple.com> <964E7DB7-E35F-4D48-952A-227B7E600375@apple.com> <959F3F28-68A4-428E-8719-D1BCC76293F2@sympatico.ca> Message-ID: <4C2CC9B7-574D-4A44-AC92-640C98A41CBB@nickshanks.com> On 7 Jun 2007, at 21:52, Andre-John Mas wrote: > Surely all of this becomes moot if we specify objects in terms of > inches, cm or mm, all of which are already supported by css? Yes, but we want a solution that works where CSS is unavailable, the target destination may not be an HTML page either. An example could be an application that displays arbitrary images from file: and http: URLs. With file: we have metadata available, with http it has to be provided along with the image. > A browser that interprets these 'absolute' units properly should > already know what DPI the current environment is in, or have access > to the necessary API to display correctly. Also, some, but by no means all images have pixel dimensions and DPI encoded into them, rather than how wide they are in cms. Either set of values will do the job though. > The problem that we have today is that some environments don't tell > the application the real DPI, so the application is left guessing > and mis-rendering things on screen. I wrote a webkit patch for that, which has a lot of comments on the issue: http://bugs.webkit.org/show_bug.cgi?id=11644 There was a request for make it conditional on a user preference, but the tree got locked down, then I got a job and didn't have time to update the patch. > The other thing that must be taken account is that on a multi- > headed computer you may have two screens each with different DPIs. > If you were to send DPIs to a server, which one would you use? It > is for reasons such as this, that I believe, that it is important > that it the responsibility of the local system to work this out, > with the appropriates hints from the web page. I suggest sending the highest DPI and then scale back slightly for the lower res screen when windows are dragged across (they won't be too different I'd imagine). The patch took the DPI from the main display, which is probably the next best thing. - Nicholas. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070607/c5b9a8b5/smime.bin From robburns1 at mac.com Thu Jun 7 15:07:52 2007 From: robburns1 at mac.com (Rob Burns) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal In-Reply-To: <959F3F28-68A4-428E-8719-D1BCC76293F2@sympatico.ca> References: <906EE7AC-BBFC-4671-86C0-D33A19C59765@apple.com> <964E7DB7-E35F-4D48-952A-227B7E600375@apple.com> <959F3F28-68A4-428E-8719-D1BCC76293F2@sympatico.ca> Message-ID: On Jun 7, 2007, at 3:52 PM, Andre-John Mas wrote: > Surely all of this becomes moot if we specify objects in terms of > inches, cm or mm, all of which are already supported by css? A > browser that interprets these 'absolute' units properly should > already know what DPI the current environment is in, or have access > to the necessary API to display correctly. > > The problem that we have today is that some environments don't tell > the application the real DPI, so the application is left guessing > and mis-rendering things on screen. > > The other thing that must be taken account is that on a multi- > headed computer you may have two screens each with different DPIs. > If you were to send DPIs to a server, which one would you use? It > is for reasons such as this, that I believe, that it is important > that it the responsibility of the local system to work this out, > with the appropriates hints from the web page. > It seems that you're not reading the proposal. This does call for the client to use whatever algorithm it deems appropriate to request an image of a certain pixel dimension (though I think my copy of Nicholas example may have read ppi, I meant to list pixel dimension). In any event, the server works to accommodate the client. This isn't meant to help the client determine the absolute dimensions its meant to deliver efficiently sized content. If its too large, it waists bandwidth (at a UI responsiveness degrading moment) and then gets down-sampled by the client anyway. If its too small, it may look poor. CSS will not solve this (except for CSS related images). It needs content negotiation. And even for CSS with media queries, this is even more flexible. Also, as I said before media queries do not accomplish what you're saying they accomplish. They don't leave things in the hands of the client, they're in the hands of the author. So if the author (maybe years before), decides to deliver an image of a certain size to the client, that's what the client gets. WebKit isn't going to be able to request a different size. Presumably the authro will make it appropriate for the client (based on the media query), but the author does no necessarily know anymore about WebKit's image processing capabilities (whether it prefers an image twice the size to one a little smaller than the requested size). So the solution proposed here actually puts more control in the clien't's hands than CSS media queries (unless the client starts lying about its meda environment, but I don't think that would be good practice). Take care, Rob. PS, again my suggestion is for the client to request specific pixel dimensions for the media not the ppi/dpi/cmpi) If the the UA is in an environment with multiple displays or multiple resolution output of any kind it can use that in determining the pixel dimensions to request. Otherwise, it can re-request the image for the new output device.. From contact at nickshanks.com Thu Jun 7 16:08:29 2007 From: contact at nickshanks.com (Nicholas Shanks) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal In-Reply-To: References: <906EE7AC-BBFC-4671-86C0-D33A19C59765@apple.com> <964E7DB7-E35F-4D48-952A-227B7E600375@apple.com> <959F3F28-68A4-428E-8719-D1BCC76293F2@sympatico.ca> Message-ID: <298C083B-4009-4C5B-B157-D47F015E53D5@nickshanks.com> On 7 Jun 2007, at 23:07, Rob Burns wrote: > PS, again my suggestion is for the client to request specific pixel > dimensions for the media not the ppi/dpi/cmpi) If the the UA is in > an environment with multiple displays or multiple resolution output > of any kind it can use that in determining the pixel dimensions to > request. Otherwise, it can re-request the image for the new output > device.. Yeah, your earlier example used ppi, not dimensions. Could you please provide a new example of what you envisage, with all the relevant back-and-forth headers enumerated, although I think what I suggest below is better than sending any pixel data to the server. Let me know what you think on this, Rob: On my previous CHOICES suggestion: Thinking further about caching, creating a new request type that was a hybrid of GET and HEAD was a bad idea. A better way would be to use GET but supply a new header that disables content negotiation (which is what I was really trying to do, though I didn't quite realise it), forcing a 406 if any content negotiation would otherwise have been performed. The 406 would then be automatically handled (not presented to the user). It puts all choice in the hands of the client/user and not the server/author. I expect it would go something like: "Negotiation: disable" So what happens now still works: Old client requests image /foo and provides no disabling header Server sends back 'optimum' resource foo, as best it can determine, taking into account quality-of-source and file length Object is cached by proxy Client uses result returned New behaviour also works: New client requests /foo and asks for content negotiation to not occur by including a new header. Server responds without negotiation because there's only one choice. Response is cached as normal by proxy. Result is used by client. -or- New client requests /foo and asks for content negotiation to not occur by including a new header. Server detects multiple resources to choose from, sends back a 406 immediately Result is not cached by intermediate proxies. (A smart proxy could even clear it's cache whenever it sees a URI return a 406, as it now knows that there are multiple representations for that resource and that it's previous cached object would not be valid for all clients!) Client parses (scrapes) the 406 response body (which will have to be more clearly spec'ed) Client issues a new request for the choice it wants, using exact URI, can omit new header this time Server responds without negotiation because there's only one choice. Response is cached as normal by proxy. Result is used by client. The cost is one round-tip to the server per negotiable URI + one header on all initial resource requests. The saving is no need to send any Accept-* headers anymore. So basically: ? Content negotiation is a good thing for users ? Server-side negotiation defeats caching and gets so long-winded that usually a wildcard is sent anyway (e.g. Accept-Encoding) ? Client-side negotiation allows caching of the final URI, as long as the negotiable URI is not cached and a bad choice returned by the proxy. ? Client-side negotiation can be transparent to the user, a 406 response doesn't need to be presented ? This can all be implemented as an extension to HTTP 1.1, and in a future version of HTTP, the new header can be made implicit. ? Whilst there could also be a "Negotiation: enable" for HTTP 1.2 or 2.0, simply sending the Accept-* headers would be enough to indicate that you wanted server-side negotiation. ? The response could also include a Suggest-Location: header for clients that aren't able to/don't want to parse the choices and select one. This would probably be what the server would have picked if it had done negotiation anyway. ? Also, a new response code (418 Client Selection Required) could be used instead of a 406, with an XML body that the client is not allowed to show to the user. This would be much better than scraping a 406, more extensible in future etc etc. Clients without an XML parser just use the server's suggestion. - Nicholas. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070608/905ce899/smime.bin From contact at nickshanks.com Thu Jun 7 17:28:34 2007 From: contact at nickshanks.com (Nicholas Shanks) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal In-Reply-To: <0B5C4BEF-94A2-4D99-85E9-57AB70BC503A@mac.com> References: <906EE7AC-BBFC-4671-86C0-D33A19C59765@apple.com> <964E7DB7-E35F-4D48-952A-227B7E600375@apple.com> <959F3F28-68A4-428E-8719-D1BCC76293F2@sympatico.ca> <298C083B-4009-4C5B-B157-D47F015E53D5@nickshanks.com> <0B5C4BEF-94A2-4D99-85E9-57AB70BC503A@mac.com> Message-ID: <7E522AC1-D72A-4683-930D-9438ED12DE7B@nickshanks.com> sorry for more spam people :-) a couple of things i don't have time to write about before i go to bed (tis gone 1am here) http code 300 is what i was wanting, not 406 or making up a new one http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1 the "Suggest-Location" param already exists, and is just called "Location" (same url) agent-driven negotiation is already suggested by HTTP 1.1: http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html except that: 1) the format of a 300 response is not defined and in fact doesn't make it clear whether UAs should look in the headers or body for the list of choices 2) there seems to be no way to make apache (v1.3) generate a 300 response, it does server-side negotiation with all the things i tried (which is where my new header would apply - make it generate a 300!). 3) i've never seen a 300 response from any web server in the wild. if it's not even implemented, i'm not surprised no client apps do their own negotiation. I am intrigued by what larry just write, and will look at it either tomorrow or in 10 days, as am away next week. i'm sure all the HTTP boffins already knew this and are lookin skyward right now. sorry folks! - Nicholas. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070608/f387f58e/smime.bin From speck at vitality.dk Fri Jun 8 01:02:16 2007 From: speck at vitality.dk (Peter Speck) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal In-Reply-To: <40C11BC1-D5E1-47A8-9438-E4BC49F81807@nickshanks.com> References: <40C11BC1-D5E1-47A8-9438-E4BC49F81807@nickshanks.com> Message-ID: <71C7CBC7-496E-4658-8BE8-36D3929FCF39@vitality.dk> Hi, (sorry for the spam if it's duplicate - it seemed like the server discarded the email) More systematic description of idea with using ranges: The Accept-Resolution header has the same overall syntax as the other accept headers to simplify parsing (and reduce bugs in web-servers). Each item-value is a range of non-negative integer dpi values. The range includes both values and the two values are separated by a dash. A range with the first number larger than the second is empty/ invalid and is ignored. If multiple medias match a range, the media closest to the range's midpoint is selected. If the header is not specified, it is equvalent to: Accept-Resolution: 70-80;q=3, 50-150;q=2, *;q=1 so the server defaults to send media fitted for most computer displays. If the header is specified, no default value/asterix is assumed. If no range match the available media, a 406 error is returned. To get normal usage for a desktop browser: Accept-Resolution: 70-80;q=3, 50-150;q=2, *;q=1 A high-resolution for printing would use e.g.: Accept-Resolution: 250-400;q=3, 150-600;q=2, *;q=1 A phone could use: Accept-Resolution: 70-80;q=3, 10-120;q=2 as the phone doesn't specify the asterix, no media of dpi=200 is allowed to be sent to it. The phone UA might ask the user if it should retry and allow higher-resolution. If the server response does not include a "Content-Resolution" header, it is assumed that only one version of the media is available. So only for reponses including the header should the browser try to obtain high-resolution media for printouts. ---- - Peter Speck From speck at vitality.dk Fri Jun 8 01:09:52 2007 From: speck at vitality.dk (Peter Speck) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal In-Reply-To: <964E7DB7-E35F-4D48-952A-227B7E600375@apple.com> References: <906EE7AC-BBFC-4671-86C0-D33A19C59765@apple.com> <964E7DB7-E35F-4D48-952A-227B7E600375@apple.com> Message-ID: On 07/06/2007, at 22:38, Maciej Stachowiak wrote: > The only case that needs to be addressed better IMO is foreground > images via . And that should probably be handled at the HTML > or CSS level, not the HTTP level. But the html doesn't know (today) which dpi the display is using. When the server generates the html file to the client, it doesn't know the resolution either. So do you imaging adding Javascript properties to dynamically update or do you want to add new attributes to the tag? Or should we replace all of them with
's using backgrounds? Rather than hacking with special attributes for resolution, I consider "Accept-Resolution" a generalized solution rather than using one method for css backgrounds, another for , and then another for including images that Flash movies might fetch. ---- - Peter Speck From contact at nickshanks.com Fri Jun 8 04:07:33 2007 From: contact at nickshanks.com (Nicholas Shanks) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal In-Reply-To: <71C7CBC7-496E-4658-8BE8-36D3929FCF39@vitality.dk> References: <40C11BC1-D5E1-47A8-9438-E4BC49F81807@nickshanks.com> <71C7CBC7-496E-4658-8BE8-36D3929FCF39@vitality.dk> Message-ID: <0265F824-0618-4883-A7B1-418413D01CDB@nickshanks.com> Hi Peter. I recommend you take a look at what Larry Masinter pointed out. It becomes clear that all of this has already been solved 9 years ago, but because it (apparently) isn't enabled in Apache by default, I and many others never even realised it existed: > Content negotiation for HTTP based on parameters beyond MIME types > was the focus of a significant amount of IETF work, including > RFC 2295 ("Transparent Content Negotiation in HTTP") > RFC 2296 ("HTTP Remote Variant Selection Algorithm -- RVSA/1.0") > and a set of 'media features' (including resolution, screen > size, pixel depth, etc.) in a Media Feature registry > (RFC 2506, BCP 31). http://www.ietf.org/rfc/rfc2295 Basically the client adds a "Negotiate: trans" header to the GET request, and initiates transparent (to the user) content negotiation (TCN). The server sends back a 300 response with a list of choices in an Alternates header, the format of which is defined in the RFC. The client then issues a new GET request for the one it wants, without having to send any environment information (dpi, &c.) to the server. Clients can also send a few (small) Accept-* headers and ask the server to take an educated guess, but still return the list of Alternates along with it's guess, which could save round trips if the client decides that the server's guess was good enough ("the 150dpi would have been best for me, but I'll just use this here 200dpi image you've already sent"). If the resource is non-negotiable, the Negotiate header is ignored by the server and nothing changes. In light of this, I suggest that WebKit developers (including me if I get the time) look into implementing this set of RFCs, and ignore all previous suggestions. It seems we've been in the classic chicken-and-egg situation since 1998, where clients don't implement it because servers don't have it turned on by default, and servers don't have it enabled because there are no client implementations to test against. Website owners are left none the wiser, and while a few server-side negotiation, most don't find it reliable enough to use, and have things like flag icons on their home page to choose your language. Apple members should discuss with the IETF the addition of device- pixel-ratio to the Media Feature registry. This will allow TCN for and elements containing visual media, and anywhere else where CSS does not apply. I also suggest a "High-Res: Part III" blog post on webkit.org to draw attention to this feature and get more web developers aware of and using TCN, which I think is the biggest hurdle (implementing it won't be as hard). - Nicholas. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070608/23c81121/smime.bin From speck at vitality.dk Fri Jun 8 04:53:21 2007 From: speck at vitality.dk (Peter Speck) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal In-Reply-To: <0265F824-0618-4883-A7B1-418413D01CDB@nickshanks.com> References: <40C11BC1-D5E1-47A8-9438-E4BC49F81807@nickshanks.com> <71C7CBC7-496E-4658-8BE8-36D3929FCF39@vitality.dk> <0265F824-0618-4883-A7B1-418413D01CDB@nickshanks.com> Message-ID: <85810038-EFC5-492D-95C1-C0FE4979E812@vitality.dk> On 08/06/2007, at 13:07, Nicholas Shanks wrote: > http://www.ietf.org/rfc/rfc2295 > [...] > In light of this, I suggest that WebKit developers (including me if > I get the time) look into implementing this set of RFCs, and ignore > all previous suggestions. > It seems we've been in the classic chicken-and-egg situation since > 1998, where clients don't implement it because servers don't have > it turned on by default, and servers don't have it enabled because > there are no client implementations to test against. > [...] > > Apple members should discuss with the IETF the addition of device- > pixel-ratio to the Media Feature registry. This will allow TCN for > and elements containing visual media, and anywhere > else where CSS does not apply. This sounds good. I've read the RFC and cannot find any problems, so I dully agree to drop prior proposals. What's the ETA for WebKit implementation? ---- - Peter Speck From salil.khanwalkar at gmail.com Fri Jun 8 05:35:19 2007 From: salil.khanwalkar at gmail.com (Salil) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] S60WebKit's rendering engine. Message-ID: <11025650.post@talk.nabble.com> Hi, Our application uses the Browser Control (CBrCtlInterface) to render HTML pages. The control does not render tables correctly and does not support some HTML tags like superscript and subscript. I want to extract code of the rendering engine from WebKit. I guess that would be KHTML. What other components from webkit will KHTML need and is it possible to use only KHTML as the rendering engine with CBrCtlInterface? Regards, Salil. -- View this message in context: http://www.nabble.com/S60WebKit%27s-rendering-engine.-tf3889516.html#a11025650 Sent from the Webkit mailing list archive at Nabble.com. From Zalan.Bujtas at nokia.com Fri Jun 8 06:16:01 2007 From: Zalan.Bujtas at nokia.com (Zalan.Bujtas@nokia.com) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] S60WebKit's rendering engine. In-Reply-To: <11025650.post@talk.nabble.com> References: <11025650.post@talk.nabble.com> Message-ID: <889E22FD2A94F14DA52BD0DBBC14545702B5F93B@daebe102.NOE.Nokia.com> Could you first make sure that you are using the Webkit engine? S60 3rd edition SDK is shipped with both the Webkit and the old WAP/XHTML/HTML engine and if you link against browserEngine.lib, you definitely use the old engine. Visit this page (http://tinyurl.com/okeux) and check if the user-agent string has the Webkit text in it. Zalan. -----Original Message----- From: webkit-dev-bounces@lists.webkit.org [mailto:webkit-dev-bounces@lists.webkit.org] On Behalf Of ext Salil Sent: Friday, June 08, 2007 8:35 AM To: webkit-dev@lists.webkit.org Subject: [webkit-dev] S60WebKit's rendering engine. Hi, Our application uses the Browser Control (CBrCtlInterface) to render HTML pages. The control does not render tables correctly and does not support some HTML tags like superscript and subscript. I want to extract code of the rendering engine from WebKit. I guess that would be KHTML. What other components from webkit will KHTML need and is it possible to use only KHTML as the rendering engine with CBrCtlInterface? Regards, Salil. -- View this message in context: http://www.nabble.com/S60WebKit%27s-rendering-engine.-tf3889516.html#a11 025650 Sent from the Webkit mailing list archive at Nabble.com. _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev From robburns1 at mac.com Fri Jun 8 10:07:04 2007 From: robburns1 at mac.com (Rob Burns) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal In-Reply-To: <0265F824-0618-4883-A7B1-418413D01CDB@nickshanks.com> References: <40C11BC1-D5E1-47A8-9438-E4BC49F81807@nickshanks.com> <71C7CBC7-496E-4658-8BE8-36D3929FCF39@vitality.dk> <0265F824-0618-4883-A7B1-418413D01CDB@nickshanks.com> Message-ID: Hi Nicholas and Peter, That is great (though ironic) to hear that this feature's been there all along (at least in the spec and in the server). I wonder if you (Nicholas) could write up or point to some instructions on configuring that in Apache (ideally the exact lines to add to the config filie). This would help implementors and just help raise awareness for server admins (as the word spreads). I think the device-pixel-ratio is not really needed in the registry. Its a bit of a sidetrack issue.. If design is done through resolution- independent units (everything but pixels) and only bitmaps are measured in pixels, the difference between device pixels and CSS pixels disappears. In other words, the work of some of the proposals in CSS 2.1 and the Acid2 tests basically turns pixel into 1/96th of an inch (with complicating caveats about much higher resolution output devices and viewing angle). All of this means that pixels should just not be used except to describe the resolution or dimensions of a bitmap image. The units in an NSView are typically understood as points. In WebKit they're understood as pixels instead (which probably became necessary to match the scale of page designs to other competing browsers). Until resolution independence is finally introduced into Mac OS X the two are equivalent so there's no disjoint. As display resolution's have increased, the base zoom of displays has decreased. This means that with a 96dpi display, the base zoom is at 75% (72/96 =0.75). When resolution independence is introduced, the base zoom can be whatever the user wants. NSView units will be points in other applications, but NSView units will be CSS2.1 pixels (1/96 of an inch) in WebKit (which is why one has to scale down by 75% to turn units that are 1-1/3 of a point back into 1 point when printing because then the base zoom is expected to be 100% ). Anyway, as I said, this was probably necessary just to keep the scale similar to other browsers. Otherwise everyone would be asking why pages were so much smaller in WebKit than in every other browser (plus, I'm not so sure the road to resolution independence was clearly paved when WebKit was brought to Mac OS X). So perhaps some of this could be illustrated on the blog. * The different treatment of resolution independence in WebKit compared with other Mac OS X apps (NSView units are 1/96 of an inch and not 1/72) * The importance of using resolution independent units (not pixels) is important. Pixels were bad to use before for CSS. The treatment by IE and Acid2 as a fixed 1/96 of an inch (and therefore an absolute unit) renders pixels as quasi resolution independent. But that just creates confusion (hence the difference between the terms "CSS pixel" and "device pixel"). If we really need a term for 1/96 of an inch perhaps someone could coin an neologism for it (I'm not even going to try :-) ). * Finally, including the Apache configuration to make that convenient for server admins and browser developers for testing (after all, as Nicholas said the reason we thought we had to reinvent the wheel is that Apache didn't include this in the standard configuration). Getting Apple and other Apache distributors to add this to the config file (even if commented out) would be a good approach. Take care, Rob On Jun 8, 2007, at 6:07 AM, Nicholas Shanks wrote: > Hi Peter. > > I recommend you take a look at what Larry Masinter pointed out. It > becomes clear that all of this has already been solved 9 years ago, > but because it (apparently) isn't enabled in Apache by default, I > and many others never even realised it existed: > >> Content negotiation for HTTP based on parameters beyond MIME types >> was the focus of a significant amount of IETF work, including >> RFC 2295 ("Transparent Content Negotiation in HTTP") >> RFC 2296 ("HTTP Remote Variant Selection Algorithm -- RVSA/1.0") >> and a set of 'media features' (including resolution, screen >> size, pixel depth, etc.) in a Media Feature registry >> (RFC 2506, BCP 31). > > http://www.ietf.org/rfc/rfc2295 > > Basically the client adds a "Negotiate: trans" header to the GET > request, and initiates transparent (to the user) content > negotiation (TCN). The server sends back a 300 response with a list > of choices in an Alternates header, the format of which is defined > in the RFC. The client then issues a new GET request for the one it > wants, without having to send any environment information (dpi, > &c.) to the server. > > Clients can also send a few (small) Accept-* headers and ask the > server to take an educated guess, but still return the list of > Alternates along with it's guess, which could save round trips if > the client decides that the server's guess was good enough ("the > 150dpi would have been best for me, but I'll just use this here > 200dpi image you've already sent"). If the resource is non- > negotiable, the Negotiate header is ignored by the server and > nothing changes. > > > In light of this, I suggest that WebKit developers (including me if > I get the time) look into implementing this set of RFCs, and ignore > all previous suggestions. > It seems we've been in the classic chicken-and-egg situation since > 1998, where clients don't implement it because servers don't have > it turned on by default, and servers don't have it enabled because > there are no client implementations to test against. Website owners > are left none the wiser, and while a few server-side negotiation, > most don't find it reliable enough to use, and have things like > flag icons on their home page to choose your language. > > Apple members should discuss with the IETF the addition of device- > pixel-ratio to the Media Feature registry. This will allow TCN for > and elements containing visual media, and anywhere > else where CSS does not apply. > I also suggest a "High-Res: Part III" blog post on webkit.org to > draw attention to this feature and get more web developers aware of > and using TCN, which I think is the biggest hurdle (implementing it > won't be as hard). > > - Nicholas._______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev From salil.khanwalkar at gmail.com Fri Jun 8 10:33:08 2007 From: salil.khanwalkar at gmail.com (Salil Khanwalkar) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] S60WebKit's rendering engine. In-Reply-To: <889E22FD2A94F14DA52BD0DBBC14545702B5F93B@daebe102.NOE.Nokia.com> References: <11025650.post@talk.nabble.com> <889E22FD2A94F14DA52BD0DBBC14545702B5F93B@daebe102.NOE.Nokia.com> Message-ID: <298fdc20706081033p22f947f5o2ead4ac04eecf8bd@mail.gmail.com> Hi Zalan, > Could you first make sure that you are using the Webkit engine? S60 3rd > edition SDK is shipped with both the Webkit and the old WAP/XHTML/HTML > engine and if you link against browserEngine.lib, you definitely use the > old engine. Yes, we link with the browserengine.lib. The SDK help says CBrCtlInterface should be linked with the browserengine.lib or the webkit.lib. The webkit.lib is not present in the SDK so only option is browserengine.lib , please correct me if I am wrong. We are using S60 3rd edition MR SDK. How do we link with WebKit engine ? > Visit this page (http://tinyurl.com/okeux) and check if the user-agent > string has the Webkit text in it. To fetch the HTML content we do not use HTTP. The content is available on the device stored in files ( proprietary file formats ). While displaying, the data is fetched from the file in a buffer and passed to the browser using LoadDataL() . I was able to run Reindeer on the emulator. It also generated the browserengine_sdk.lib and other lib files, but not the webkit.lib. Regards, Salil. On 6/8/07, Zalan.Bujtas@nokia.com wrote: > > Could you first make sure that you are using the Webkit engine? S60 3rd > edition SDK is shipped with both the Webkit and the old WAP/XHTML/HTML > engine and if you link against browserEngine.lib, you definitely use the > old engine. > Visit this page (http://tinyurl.com/okeux) and check if the user-agent > string has the Webkit text in it. > > Zalan. > > > -----Original Message----- > From: webkit-dev-bounces@lists.webkit.org > [mailto:webkit-dev-bounces@lists.webkit.org] On Behalf Of ext Salil > Sent: Friday, June 08, 2007 8:35 AM > To: webkit-dev@lists.webkit.org > Subject: [webkit-dev] S60WebKit's rendering engine. > > > Hi, > > Our application uses the Browser Control (CBrCtlInterface) to render > HTML pages. > The control does not render tables correctly and does not support some > HTML tags like superscript and subscript. > > I want to extract code of the rendering engine from WebKit. I guess that > would be KHTML. > > What other components from webkit will KHTML need and is it possible to > use only KHTML as the rendering engine with CBrCtlInterface? > > Regards, > Salil. > -- > View this message in context: > http://www.nabble.com/S60WebKit%27s-rendering-engine.-tf3889516.html#a11 > 025650 > Sent from the Webkit mailing list archive at Nabble.com. > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070608/b7e065c9/attachment.html From jyh.hsc at 163.com Sat Jun 9 06:09:23 2007 From: jyh.hsc at 163.com (Jin, Yihua) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] s60 debug Message-ID: Hi all: I found it is difficult to debug on S60 with emulator, can the App output something to IDE console? or else, what's the way to do "printf" like in PC? Best Regards, Yihua -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070609/e119327f/attachment.html From marcus.groeber.at.nuance at bugcom.de Mon Jun 11 00:47:25 2007 From: marcus.groeber.at.nuance at bugcom.de (Marcus Groeber) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] s60 debug In-Reply-To: References: Message-ID: <466CFE0D.6000905@bugcom.de> Jin, Yihua schrieb: > I found it is difficult to debug on S60 with emulator, can the App > output something > to IDE console? or else, what's the way to do "printf" like in PC? Have a look at RDebug::Print() - that is almost exactly like printf(), but outputs to the "Debug messages" console on the emulator. ciao marcus From tom at windyroad.org Mon Jun 11 03:45:22 2007 From: tom at windyroad.org (Windy Road) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Your opinion on a CSS proposal In-Reply-To: <06A90CBF-0F49-46E8-BCFF-FEFFDE0E7DEF@sympatico.ca> References: <746049190706052029q18643d9boa02ac8adf626d025@mail.gmail.com> <665748.56815.qm@web52402.mail.re2.yahoo.com> <746049190706062235qe172d40y9a92d5b2a9d4439c@mail.gmail.com> <06A90CBF-0F49-46E8-BCFF-FEFFDE0E7DEF@sympatico.ca> Message-ID: <746049190706110345i449619e3v4da99b93d4253bd1@mail.gmail.com> On 07/06/07, Andre-John Mas wrote: > > Is the idea to ensure that the image is displayed at about the same > size on both screens, or that less data is sent in the low-res > scenario? Both. One thing that should be noted is that the 'IMG' HTML tag has a 'LOWSRC' > attribute, which is intended for a low resolution version of the image, > but I don't think that ever made it into CSS. My understanding of the LOWSRC tag is it allows for a smaller version of the image to be downloaded and displayed while the full size image is being loaded. I don't see how it will help in this situation. If a low-res device happens to be a TV, then there is a media type 'tv' > which can be specified so the right CSS is used. But CSS doesn't apply to the src of the img element. Just a quick look at CSS and I see that 'absolute' units are available > for specifying size, such as in, cm and mm. See: > > http://htmlhelp.com/reference/css/units.html Adjusting the displayed size of the image is not an issue. The issue is how to deliver a high res / low res images depending on the resolution/screen size of the browser. Cheers, -- Tom Howard http://windyroad.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070611/d7dcd56e/attachment.html From webkit at svolli.dynxs.de Mon Jun 11 05:05:50 2007 From: webkit at svolli.dynxs.de (SvOlli) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Building Spinneret Message-ID: Hello! I'm trying to build the Spinneret application for Windows. So far, I've managed to put together a build environment that compiles the code, including a pthread port. Right now I'm confronted with problems that can be related to the changes that came with changelist 20837: the splitting up of the code in WebKit and WebCore. During this change PageState.cpp was removed, but is still referenced in the .sln project-file. As a workaround I tried to go back to 20836, but there I get compile errors in three of the seven components. So since as a first step I just want to get an impression of WebKit, what can I do to get a working binary? Is there something like a "last known changelist" that worked with building on Windows? The final goal is to get a port of WebKit that is embedded running in a propietary framework running on a QNX target system. Development is usually done in a Windows Simulation, so a Windows port is needed as well, which is the second step, after getting some kind of demo application on Windows. Greetings from Germany, SvOlli -- | _______ | | ( /\ | [After taking NyQuil] I'm high as a kite and |__)v\/lli a.k.a.| my teeth are green. Merry fucking Christmas! |Sven Oliver Moll| -- Denis Leary From slefaou at wimba.com Mon Jun 11 08:00:41 2007 From: slefaou at wimba.com (Sebastien Le Faou) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] WebKitQt development Message-ID: <466D6399.9020909@wimba.com> Hi everybody, I have work a bit on WebKitQt and created some new functions or had new functionnalities which could be useful. I posted new bugs on webkit bugzilla and I put forward my patches to solve this bugs. I had feedbacks with my patches and they suggest me that one of the WebKitQt developers should review the API. So, I would like to be in touch with WebKitQt developers. Thank you. Have a nice day Sebastien. From sergtrejo at gmail.com Mon Jun 11 12:55:52 2007 From: sergtrejo at gmail.com (Sergio Trejo) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] SVG in WebKit for Safari 3 for Windows and Mac and iPhone? Message-ID: <7c3d69360706111255g7cd84142y9e459dc8eef3b782@mail.gmail.com> Hello, Does anyone know if SVG has been integrated into the build of WebKit that is being used for Safari 3 Beta which Steve Jobs announced a few hours ago will be available for Windows XP and Vista as well as Mac OS X and iPhone? The Holy Grail of building consistent SVG user experiences might just have arrived with the bomb that Steve Jobs dropped today! I truly hope and pray that SVG can now have a true shot at taking off without anyone (e.g., Microsoft and its control freak attitude) getting in the way. Here's to WebKit, the jolly good fellow! -Serg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070611/d2ea9196/attachment.html From neumann at karto.baug.ethz.ch Mon Jun 11 13:43:07 2007 From: neumann at karto.baug.ethz.ch (Andreas Neumann) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] SVG in WebKit for Safari 3 for Windows and Mac and iPhone? In-Reply-To: <7c3d69360706111255g7cd84142y9e459dc8eef3b782@mail.gmail.com> References: <7c3d69360706111255g7cd84142y9e459dc8eef3b782@mail.gmail.com> Message-ID: <466DB3DB.9040001@karto.baug.ethz.ch> SVG seems to be enabled. However, I seem to have problems. While local file seem to work fine (similar to the mac version), Safari on Windows crashes when loading files from my own webserver, e.g. from http://www.carto.net/papers/svg/samples/ - do others have the same problem or is it specific to my install or webserver? Maybe it is related to my webserver (gzip compression?) - other files seem from other webserver seem to work fine. Files from my webserver work fine in the Mac version of the Safari beta 3 ... strange Andreas Sergio Trejo wrote: > Hello, > > Does anyone know if SVG has been integrated into the build of WebKit > that is being used for Safari 3 Beta which Steve Jobs announced a few > hours ago will be available for Windows XP and Vista as well as Mac OS > X and iPhone? > > The Holy Grail of building consistent SVG user experiences might just > have arrived with the bomb that Steve Jobs dropped today! I truly hope > and pray that SVG can now have a true shot at taking off without > anyone ( e.g., Microsoft and its control freak attitude) getting in > the way. > > Here's to WebKit, the jolly good fellow! > > -Serg > > > ------------------------------------------------------------------------ > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > -- -- ---------------------------------------------- Andreas Neumann Institute of Cartography ETH Zurich Wolfgang-Paulistrasse 15 CH-8093 Zurich, Switzerland Phone: ++41-44-633 3031, Fax: ++41-44-633 1153 e-mail: neumann@karto.baug.ethz.ch www: http://www.carto.net/neumann/ SVG.Open: http://www.svgopen.org/ Carto.net: http://www.carto.net/ From lambda at mac.com Mon Jun 11 13:45:57 2007 From: lambda at mac.com (Brian Campbell) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] SVG in WebKit for Safari 3 for Windows and Mac and iPhone? In-Reply-To: <7c3d69360706111255g7cd84142y9e459dc8eef3b782@mail.gmail.com> References: <7c3d69360706111255g7cd84142y9e459dc8eef3b782@mail.gmail.com> Message-ID: <710E5BD0-8207-4B97-9D13-F63386CB4702@mac.com> On Jun 11, 2007, at 3:55 PM, Sergio Trejo wrote: > Hello, > > Does anyone know if SVG has been integrated into the build of > WebKit that is being used for Safari 3 Beta which Steve Jobs > announced a few hours ago will be available for Windows XP and > Vista as well as Mac OS X and iPhone? Yes, it has. Download the beta from and go to to check for yourself. SVG support is incomplete in this version of WebKit (no filters, for example), but a pretty sizeable subset of SVG works. From neumann at karto.baug.ethz.ch Mon Jun 11 13:56:34 2007 From: neumann at karto.baug.ethz.ch (Andreas Neumann) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] SVG in WebKit for Safari 3 for Windows and Mac and iPhone? In-Reply-To: <710E5BD0-8207-4B97-9D13-F63386CB4702@mac.com> References: <7c3d69360706111255g7cd84142y9e459dc8eef3b782@mail.gmail.com> <710E5BD0-8207-4B97-9D13-F63386CB4702@mac.com> Message-ID: <466DB702.508@karto.baug.ethz.ch> The beta seems to be several weeks old if compared with the latest nightlies. Several SVG bugfixes that had been made in the trunk (nightlies) hadn't been incorporated into the beta. I hope that these fixes will be included in the final version. Andreas Brian Campbell wrote: > On Jun 11, 2007, at 3:55 PM, Sergio Trejo wrote: > >> Hello, >> >> Does anyone know if SVG has been integrated into the build of WebKit >> that is being used for Safari 3 Beta which Steve Jobs announced a few >> hours ago will be available for Windows XP and Vista as well as Mac >> OS X and iPhone? > > Yes, it has. Download the beta from and > go to to check for yourself. > > SVG support is incomplete in this version of WebKit (no filters, for > example), but a pretty sizeable subset of SVG works. > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev -- -- ---------------------------------------------- Andreas Neumann Institute of Cartography ETH Zurich Wolfgang-Paulistrasse 15 CH-8093 Zurich, Switzerland Phone: ++41-44-633 3031, Fax: ++41-44-633 1153 e-mail: neumann@karto.baug.ethz.ch www: http://www.carto.net/neumann/ SVG.Open: http://www.svgopen.org/ Carto.net: http://www.carto.net/ From tom at windyroad.org Mon Jun 11 15:55:41 2007 From: tom at windyroad.org (Windy Road) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Your opinion on a CSS proposal In-Reply-To: <746049190706110345i449619e3v4da99b93d4253bd1@mail.gmail.com> References: <746049190706052029q18643d9boa02ac8adf626d025@mail.gmail.com> <665748.56815.qm@web52402.mail.re2.yahoo.com> <746049190706062235qe172d40y9a92d5b2a9d4439c@mail.gmail.com> <06A90CBF-0F49-46E8-BCFF-FEFFDE0E7DEF@sympatico.ca> <746049190706110345i449619e3v4da99b93d4253bd1@mail.gmail.com> Message-ID: <746049190706111555h70cf3648i62b5b1f9bef34783@mail.gmail.com> Hi, Regarding my font-size: auto / line-length proposal. It turns out that a new unit (vw) has been proposed for CSS3 which achieves this result. http://www.w3.org/TR/css3-values/#relative0 Anyone know if this currently supported by webkit and if not if there is an ETA on supporting this? Cheers, -- Tom Howard http://windyroad.org From tom at windyroad.org Mon Jun 11 16:47:50 2007 From: tom at windyroad.org (Windy Road) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal In-Reply-To: References: <40C11BC1-D5E1-47A8-9438-E4BC49F81807@nickshanks.com> <71C7CBC7-496E-4658-8BE8-36D3929FCF39@vitality.dk> <0265F824-0618-4883-A7B1-418413D01CDB@nickshanks.com> Message-ID: <746049190706111647x72c953bdt1865e58d7660bc8@mail.gmail.com> On 09/06/07, Rob Burns wrote: > That is great (though ironic) to hear that this feature's been there > all along (at least in the spec and in the server). I wonder if you > (Nicholas) could write up or point to some instructions on > configuring that in Apache (ideally the exact lines to add to the > config filie). This would help implementors and just help raise > awareness for server admins (as the word spreads). I've had a quick look at the Apache docs and I was able to create a very quick demo using Apaches type-maps by uncommenting the line: AddHandler type-map .var in the httpd.conf I then created a file called image.var as follows: URI: image URI: image-1200x1000.jpg Content-type: image/jpeg; qs=0.9 URI: image-600x500.jpg Content-type: image/jpeg; qs=0.5 URI: image-300x250.jpg Content-type: image/jpeg; qs=0.25 URI: image-150x125.jpg Content-type: image/jpeg; qs=0.1 Testing this in Firefox (sorry I don't have my iBook handy at the moment) results in Apache selecting the content with the highest qs. However, from what I can see, Apache does not support the "feature negotiation" portion of the RFC, so there is no way to specify in the type-map anything other than: URI: uri of the file containing the variant (of the given media type, encoded with the given content encoding). These are interpreted as URLs relative to the map file; they must be on the same server (!), and they must refer to files to which the client would be granted access if they were to be requested directly. Content-Type: media type --- charset, level and "qs" parameters may be given. These are often referred to as MIME types; typical media types are image/gif, text/plain, or text/html; level=3. Content-Language: The languages of the variant, specified as an Internet standard language tag from RFC 1766 (e.g., en for English, kr for Korean, etc.). Content-Encoding: If the file is compressed, or otherwise encoded, rather than containing the actual raw data, this says how that was done. Apache only recognizes encodings that are defined by an AddEncoding directive. This normally includes the encodings x-compress for compress'd files, and x-gzip for gzip'd files. The x- prefix is ignored for encoding comparisons. Content-Length: The size of the file. Specifying content lengths in the type-map allows the server to compare file sizes without checking the actual files. Description: A human-readable textual description of the variant. If Apache cannot find any appropriate variant to return, it will return an error response which lists all available variants instead. Such a variant list will include the human-readable variant descriptions. And currently, only the following dimensions of negotiation are supported: Media Type Browser indicates preferences with the Accept header field. Each item can have an associated quality factor. Variant description can also have a quality factor (the "qs" parameter). Language Browser indicates preferences with the Accept-Language header field. Each item can have a quality factor. Variants can be associated with none, one or more than one language. Encoding Browser indicates preference with the Accept-Encoding header field. Each item can have a quality factor. Charset Browser indicates preference with the Accept-Charset header field. Each item can have a quality factor. Variants can indicate a charset as a parameter of the media type. So it looks like even if support for this is added to webkit, we will still need to wait for it to be implemented in Apache or another browser before we can test it. Has anyone else found anything that suggests otherwise? Cheers, -- Tom Howard http://windyroad.org From tom at windyroad.org Mon Jun 11 17:38:05 2007 From: tom at windyroad.org (Windy Road) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Accept- & Content-Resolution headers proposal In-Reply-To: <746049190706111647x72c953bdt1865e58d7660bc8@mail.gmail.com> References: <40C11BC1-D5E1-47A8-9438-E4BC49F81807@nickshanks.com> <71C7CBC7-496E-4658-8BE8-36D3929FCF39@vitality.dk> <0265F824-0618-4883-A7B1-418413D01CDB@nickshanks.com> <746049190706111647x72c953bdt1865e58d7660bc8@mail.gmail.com> Message-ID: <746049190706111738o23e737b8m9343e47f62d07ff9@mail.gmail.com> Hi, Does Apache support "Feature negotiation" as specified in RFC 2295 (see http://www.ietf.org/rfc/rfc2295 )? If so, is there any documentation related to this (I couldn't find any)? If not, are there any plans to support this portion of the RFC? FYI the back story to this request is from a discussion regarding having images served to a client dependant on its resolution and/or viewport width. Normal browsers may get an the image as 600px across, small screen devices may get an image that is 150px across and browser requesting the image for printing purposed may get an image that is 1200px across. I was able to create a type-map file for the images as follows: URI: image URI: image-1200x1000.jpg Content-type: image/jpeg; qs=0.9 URI: image-600x500.jpg Content-type: image/jpeg; qs=0.5 URI: image-300x250.jpg Content-type: image/jpeg; qs=0.25 URI: image-150x125.jpg Content-type: image/jpeg; qs=0.1 Apache would (correctly) perform server side selection to pick the variant with the highest qs, however I could not find any way of specifying features (such as DPI) for each variant, that would allow a lower qs variant to be selected based on a appropriate request with "Accept-Features" (e.g. "Accept-Features: dpi=[70-100]"). Cheers, -- Tom Howard http://windyroad.org From sudarshan at dgbmicro.com Mon Jun 11 22:29:56 2007 From: sudarshan at dgbmicro.com (Sudarshan Parthasarathy) Date: Tue Oct 9 17:53:29 2007 Subject: [webkit-dev] Building WebKitQt on Fedora 5 In-Reply-To: <50284.59.92.156.103.1181589577.squirrel@blr.dgbmicro.com> Message-ID: Hi, I have been trying to build WebKit with Qt 4.3 on Fedora but with no success. I get the following errors when I try to compile. In file included from ../../../WebCore/platform/qt/MimeTypeRegistryQt.cpp:32: ../..