Re: [webkit-dev] image maps to be focused via tab
On Nov 14, 2008, at 4:01 PM, Maciej Stachowiak wrote: On Nov 14, 2008, at 9:15 AM, Darin Adler wrote: On Nov 14, 2008, at 12:24 AM, browserwk wrote: Before list, i assume html page have only one img and map(also one area) tag, but also they are bounded. In order to focus navigate via tab, i did follow things. 1 to identify img,area tag I can get the img or area node from Document::nextFocusableNode Document::previousFocusableNode. 2 get absolutely position Also, i had got the position of the img and each area node with nonstandard way, in any way. If i use areaNode-renderer(), i will got NULL. I didn't know the reason.If u can, tell me more. 3 to focus area node In this step, i fail to focus the area node, moreover didn't see the focus ring. And i found the area node never pass through the isKeyboardFocusable() function. So, some questions 1 I want to know the factor that a node need be focusable, just like area node. 2 Can i render the focus ring, when i got the area node and it's absolutely postion ? This doesn't sound like the right approach. To make this work the approach would not to be write new code to navigate, but rather to change the existing code so that it will do this when necessary. Assuming the page has only one img, one map, and one area seems completely wrong, and I'm not sure it's helpful to designing a solution. The premises behind your questions 1 and 2 are wrong so I really don't see how I can answer the questions. Sorry, I'd love to help, but I'm stuck here. One particularly wrong aspect of the original assumption is that in practice, a single map and all its areas can be used by multiple img elements. So representing focus of individual image map active areas by making the area node focused won't really work - it doesn't fit into the single focus ring model, since just focus on the area node doesn't tell you which image map is active. Let me add that image maps also apply to input elements of type image and object elements when they embed a still image (content-type image/ *). I don't have the WebKit code handy at the moment, but here's some thoughts on this. I think this should be handled through adding more support for image maps. This could be done by changing the RenderReplaced class and the attach() method to deal with img, object and input elements that have a valid value for the usemap attribute. 1) add a RenderArea subclass of RenderBox (a subclass that allows RenderBox to be not only rectangular, but also circular and a polygon and applying all CSS box rules like any RenderBox, but not necessarily as a rectangle) 2) attach RenderArea boxes for each child of a HTMLMapElement just as one would for other child nodes (these RenderArea objects should be added to the RenderImage objects as child objects of the RenderImage containing block, for each RenderImage using that image map) 3) when rendering the replaced element its corresponding RenderReplaced, also add copies of the RenderArea instances in the appropriate place on the replaced element's RenderBox (the positioning would come from interpreting the image maps's area coordinates as CSS pixels and transforming them into ) 4) then the RenderArea boxes should be added to the FocusController architecture just like any other focusable objects (this likely requires something like a shadow element added to the img, input or object element in the tree) Just some quick thoughts on the topic. I admit the treatment of AREA's as CSS boxes is unorthodox, but it will degrade gracefully in other engines and it will make WebKit even more exceptional. This approach allows image map areas to participate in the render and navigation architecture in the same as other boxes. It also gets us CSS box model on areas as well and even improving title/tooltip support (see e.g., this bug[1]). Take care, Rob [1]: https://bugs.webkit.org/show_bug.cgi?id=15035 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] image maps to be focused via tab
Hi Maciej, On Nov 14, 2008, at 5:07 PM, Maciej Stachowiak wrote: On Nov 14, 2008, at 2:48 PM, Rob Burns wrote: On Nov 14, 2008, at 4:01 PM, Maciej Stachowiak wrote: One particularly wrong aspect of the original assumption is that in practice, a single map and all its areas can be used by multiple img elements. So representing focus of individual image map active areas by making the area node focused won't really work - it doesn't fit into the single focus ring model, since just focus on the area node doesn't tell you which image map is active. Let me add that image maps also apply to input elements of type image and object elements when they embed a still image (content- type image/*). This is a completely unrelated issue, and your claim of what image maps apply to is inconsistent with the current HTML5 draft. I know you have a longstanding disagreement with this aspect of the HTML5 spec, but this is probably not a point where the WebKit project would want to diverge from the spec. I just want to remind you that the HTML5 spec is only a draft. The editor predicts a final version in over a decade. So I don't think we need to treat it as authoritative. Also in the future when citing violations of a spec, it would be best to provide a specific reference so other's can follow your reading of that spec. As for this issue of AREA element's I'm not sure how you're reading what I proposed as a violation of any spec. Take care, Rob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] image maps to be focused via tab
Hi Maciej, On Nov 14, 2008, at 5:07 PM, Maciej Stachowiak wrote: On Nov 14, 2008, at 2:48 PM, Rob Burns wrote: On Nov 14, 2008, at 4:01 PM, Maciej Stachowiak wrote: One particularly wrong aspect of the original assumption is that in practice, a single map and all its areas can be used by multiple img elements. So representing focus of individual image map active areas by making the area node focused won't really work - it doesn't fit into the single focus ring model, since just focus on the area node doesn't tell you which image map is active. Let me add that image maps also apply to input elements of type image and object elements when they embed a still image (content- type image/*). This is a completely unrelated issue, and your claim of what image maps apply to is inconsistent with the current HTML5 draft. I know you have a longstanding disagreement with this aspect of the HTML5 spec, but this is probably not a point where the WebKit project would want to diverge from the spec. Let me make sure I understand what you're saying here. Is it that WebKit does not want to properly render properly authored HTML4 content, but only HTML5 content? If this is the case I think that should be clearly stated on the goals of the project page. If that's not the case, then I see no problem with WebKit supporting an HTML4 construct even if it is eventually removed in ten years by HTML5. Take care, Rob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
Hi Peter, On Oct 2, 2008, at 6:28 PM, Peter Kasting wrote: On Thu, Oct 2, 2008 at 3:23 AM, Rob Burns [EMAIL PROTECTED] wrote: As another drastic anecdotal step, I've turned off javascript on Safari (my main browser) and turn to other browsers when I find a site that requires javascript. If I don't do that, I find my Macbook Air battery eaten away in under an hour just because I left pages open that use setTimeout inappropriately. Safari doesn't have a lower setTimeout() cap than Firefox, so I don't think this data point is meaningful. This wasn't a comparison of the handling of different browsers. I was saying that this is a rather drastic measure that users have to take in order to avoid errant javascripts from eating away battery storage. It might make sense to allow users to disable timers separately from disabling javascript in total. In that way it might also encourage authors to use timers appropriately when they might not be able to count on timers being enabled always (using them only when appropriate then). Take care, Rob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
Hi Darin, On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: (I don't understand your comment about not having to have it on all the time. Surely if a page is asking for a fast setTimeout repeatedly, it would be on all the time.) My understanding is that timeBeinPeriod(1) is currently on all the time in Chrome, even when no short-delay timers are currently pending, thus leading to constant greater power consumption. But there is no need for it to be on when there are not fast timers pending. See WebCore/platform/win/SharedTimerWin.cpp. I think that is a technically better approach than switching based on power management state. Feedback welcome, though, and perhaps you will still come to a different conclusion. I think that is a good idea too, but it doesn't help when a fast setInterval is active. That is true. With the webkit.org version of SharedTimerWin, though, you can at least close the problematic tab when you hear your fan spin up and stop suffering any power drain. It may be that running slower is a better option. Yeah, that's the trade off. Close the offending tab or let it run, but more slowly. Another option, would be to halt timers for all unexposed tabs (i.e., tabs in windows that are not the frontmost tab). Are there use-cases or sites that would break with such behavior? The reason I raise this option is that the loaded page represents important state to the user, but when it is buried on a window, it is probably not necessary for it to be actively responding to timer callbacks. Closing the tab saves battery life, but burying the tab behind another tab would be preferable for the user (a mobile user that may not be online when that important state represented by the page loaded in the tab is sought again). Take care, Rob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
Hi Peter, On Oct 3, 2008, at 12:21 PM, Rob Burns wrote: On Oct 2, 2008, at 6:28 PM, Peter Kasting wrote: On Thu, Oct 2, 2008 at 3:23 AM, Rob Burns [EMAIL PROTECTED] wrote: As another drastic anecdotal step, I've turned off javascript on Safari (my main browser) and turn to other browsers when I find a site that requires javascript. If I don't do that, I find my Macbook Air battery eaten away in under an hour just because I left pages open that use setTimeout inappropriately. Safari doesn't have a lower setTimeout() cap than Firefox, so I don't think this data point is meaningful. This wasn't a comparison of the handling of different browsers. I was saying that this is a rather drastic measure that users have to take in order to avoid errant javascripts from eating away battery storage. It might make sense to allow users to disable timers separately from disabling javascript in total. In that way it might also encourage authors to use timers appropriately when they might not be able to count on timers being enabled always (using them only when appropriate then). Since I fear the logic here has been lost let me try to summarize what I'm trying to say on this topic. • setTimeout gets used in cases where it is not always the best solution for authors: i.e., using for polling when a specified event would be a better way to provide interactivity • setTimeout is probably most often tested on IE with a clamp of 15ms and any author testing elsewhere does not focus on power consumption issues • for these cases where it is not being used correctly, a user of Chrome (with a 1ms clamp) will experience 15X processor use over a user of IE (with 15ms clamp) • the 15x processor utilization will result in an accelerated power drain on mobile devices running Chrome compared to those running IE • most users will not diagnose the issue down to a specific tab or a specific page, but may at times identify the browser or the platform as the problem My approach to dealing with this is to leave any number of pages I desire open in Safari my main browser and avoid flash and javascript entirely there. If a page requires javascript, I fire up Shira or Opera or another browser with javascript and flash enabled and make sure I quit the application before I go on battery or immediately after viewing the page. This gives me immensely more battery life than I would otherwise have given my usage patterns (like having a second or even a third battery). Take care, Rob___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
HI Darin, On Oct 3, 2008, at 1:22 PM, Darin Fisher wrote: On Fri, Oct 3, 2008 at 3:10 AM, Rob Burns [EMAIL PROTECTED] wrote: Hi Darin, On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: (I don't understand your comment about not having to have it on all the time. Surely if a page is asking for a fast setTimeout repeatedly, it would be on all the time.) My understanding is that timeBeinPeriod(1) is currently on all the time in Chrome, even when no short-delay timers are currently pending, thus leading to constant greater power consumption. But there is no need for it to be on when there are not fast timers pending. See WebCore/platform/win/SharedTimerWin.cpp. I think that is a technically better approach than switching based on power management state. Feedback welcome, though, and perhaps you will still come to a different conclusion. I think that is a good idea too, but it doesn't help when a fast setInterval is active. That is true. With the webkit.org version of SharedTimerWin, though, you can at least close the problematic tab when you hear your fan spin up and stop suffering any power drain. It may be that running slower is a better option. Yeah, that's the trade off. Close the offending tab or let it run, but more slowly. Another option, would be to halt timers for all unexposed tabs (i.e., tabs in windows that are not the frontmost tab). Are there use-cases or sites that would break with such behavior? The reason I raise this option is that the loaded page represents important state to the user, but when it is buried on a window, it is probably not necessary for it to be actively responding to timer callbacks. Closing the tab saves battery life, but burying the tab behind another tab would be preferable for the user (a mobile user that may not be online when that important state represented by the page loaded in the tab is sought again). Take care, Rob It's a good question. I suspect though that it could break sites. Imagine a calendar application that wishes to periodically wake up to see if it should put up an alert to notify you of an upcoming event. Such a feature probably requires the ability to run a timer. Yes, understood. But this example also requires javascript enabled. If a user disables javascript this web app will not work either. I'm suggesting WebKit could allow more finegrained control by allowing javascript enabled, but timers disabled. Also this example illustrates how an author of such a calendar web app may use setTimeout as a polling device rather than using an event- based approach where the application simply sets event timers for those alerts. By allowing greater control over disabling setTimeout, the authoring community will be forced to learn about better approaches to authoring such a web app. Obviously this stuff won't happen tomorrow, but we have to take a long view of it from time to time and think about what we can do to get there. Take care, Rob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
HI Maciej, On Oct 3, 2008, at 3:16 PM, Maciej Stachowiak wrote: On Oct 3, 2008, at 3:10 AM, Rob Burns wrote: Hi Darin, On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: (I don't understand your comment about not having to have it on all the time. Surely if a page is asking for a fast setTimeout repeatedly, it would be on all the time.) My understanding is that timeBeinPeriod(1) is currently on all the time in Chrome, even when no short-delay timers are currently pending, thus leading to constant greater power consumption. But there is no need for it to be on when there are not fast timers pending. See WebCore/platform/win/SharedTimerWin.cpp. I think that is a technically better approach than switching based on power management state. Feedback welcome, though, and perhaps you will still come to a different conclusion. I think that is a good idea too, but it doesn't help when a fast setInterval is active. That is true. With the webkit.org version of SharedTimerWin, though, you can at least close the problematic tab when you hear your fan spin up and stop suffering any power drain. It may be that running slower is a better option. Yeah, that's the trade off. Close the offending tab or let it run, but more slowly. Another option, would be to halt timers for all unexposed tabs (i.e., tabs in windows that are not the frontmost tab). Are there use-cases or sites that would break with such behavior? The reason I raise this option is that the loaded page represents important state to the user, but when it is buried on a window, it is probably not necessary for it to be actively responding to timer callbacks. Closing the tab saves battery life, but burying the tab behind another tab would be preferable for the user (a mobile user that may not be online when that important state represented by the page loaded in the tab is sought again). There are web apps that a user may legitimately want to continue to work in the background. One obvious example is a web-based audio player, although in that case it would be a plugin or audio element continuing to do work. Still, if you're going to allow plugins and media elements to continue, you may as well allow timers. Other sites update their title on a timer in a way that is useful for a background tab. For example, GMail updates the unread count, which is quite useful on a background tab label. Given these kinds of examples, I think pausing anything in a background tab would not be a good choice; if that kind of functionality were on offer it should be a more explicit user gesture. I agree with that. To me burying a tab is an explicit and often deliberate user gesture. It would take novice users little time to adjust to the pausing of buried tabs (pausing with respect to all processing: plugins, animated images, and javascript for example). If audio is playing and it pauses because the tab is buried, the user will quickly come to understand that the tab needs to be exposed and to switch to a new window to create the new tab. The audio still plays in a background window, just not in a background tab. Until tab management gets up to speed, that would be a prudent approach anyway. All in all, I think we shouldn't overreact on the timer issue. Sites that consume egregious amounts of computing resources, whether through timers or otherwise, are the minority, and so long as they suck in all browsers and not just some, users will blame the site and it will be pressured to change. So really (in my opinion), matching or beating the CPU consumption of other browsers is the target, and we shouldn't go crazy with novel ways to restrict timers or anything else. Just avoid looking broken on sites that were only tested in IE or Firefox. My experience is that the problem is much more of a problem (but I'm mobile a lot). Adding a new highres timer is a good step, but if that's already available, then providing setTimeout a 15 fold difference in clamps between WebKit and IE (the primary test browser) will really exacerbate the problem (perhaps as much as a significant percentage loss in battery-charge-life). As for trying to avoid restricting timers that merely leads to restricting javascript in total. The only reason I would ever want to turn off javascript is to control poorly authored timers (and similar poorly authored plugins and plugin authoring). So I lose all javascript support simply to avoid timers, where I would prefer to lose the timer capabilities and still have the remaining javascript or maintain all javascript and lose timers for buried tabs. If we assume the new highres API will not be abused the way setTimeout
Re: [webkit-dev] High Resolution Timer API proposal(s)
Hi Geoff, On Oct 3, 2008, at 9:04 PM, Geoffrey Garen wrote: Again, I'm wondering how many legitimate uses are there for short timeouts in background tabs/windows. In a background window: animation video For animation and video, is it necessary even in a completely obscured view? audio I only meant to discuss javascript here. Are authors spinning audio using javascript setTimeout (I ask naïvely)? work queues for database or other background processing I think this is another example where event listeners or another approach entirely would be more legitimate than using timers. Are you talking about using setTimout to repeatedly poll to find out if a worker is finished? If so, this is definitely not the type of use we should facilitate long-term for script timers. Again, exploring these questions may lead us to a need to define other events that can trigger scripts to run (rather than reliance on polling). something interesting the web hasn't invented yet Given the need to reign in the abuses I don't find this too compelling. We wouldn't be preventing innovations, just restricting those innovations to run in unburied web pages. To give you some context, Safari used to throttle plug-in timers for background windows. The result was that users would see randomly choppy content. I'm more referring to pages that are completely buried and obscured so pages with no need not run at all and users would have no way to know they are running choppy. In a background tab: audio Again is this being done with javascript? Anyway, I don't think it is much to ask of users that they keep tabs unburied to enable listening to the embedded audio (or otherwise for browsers to provide an interface to re-enable audio within those buried tabs). So authors and users do not already have any ingrained preconceptions that audio must play even if a tab is buried (and so need to tailor APIs for authors to micro-manage this). work queues for database or other background processing something interesting the web hasn't invented yet See above. Also note that protections for background windows and tabs wouldn't solve the majority of the problem we've seen in the wild, which is the *foreground* window going crazy in a single-tabbed browsing session. I feel completely the opposite about this. If a foreground window is going crazy, that's a problem but a visible problem that even a novice user may know how to correct (if it even needs correcting). However, finding one or a dozen background tabs (amidst tens or hundreds) where those tabs contain needlessly running timers (in both javascript and elsewhere) is a huge power drain and one whose impacts are difficult to access. For mobile users the problem is more obvious, but even for desktops, how much wasted energy goes into these cycles when repeated across millions (billions?) of processors world-wide (and then the air-conditioning that also goes into compensating for that needless heat generation)[1]? Take care, Rob [1]: A bit off-topic: say a processor pegged at 20w churns away at these wasteful web app cycles for 2 hours each day driving the processor from an average of 10% power consumption to 99% power consumption. That's 17.8 power dissipation dedicated just to the needless cycles or 35.6 w-h energy consumption per day. For one billion computers that's 17.8 thousand MW or 35.6 thousand MW-h per day or 9256 thousand MW-h per work year. Avoiding something like 17.8 thousand wasted MW power dissipation (and 9256 thousand MW-hours of energy) eliminates the need for dozens of nuclear / coal power reactors worldwide (or even dirtier peaker power plants). Considering a 1.341 pounds of CO2 per kilowatt-hour (the 1999 estimated rate so over-optimistic for world-wide electricity production) that's 12,412 pounds per year. At 10¢ a kw-h that's $925 million per year in world- wide electricity expenses. And that's without calculating compensating cooling power consumption, both internal and external to the computing device. There's a lot of power (and potential power wasted) in the hands of browser developers. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Oct 2, 2008, at 6:01 AM, Linus Upson wrote: My impression from your remarks was that you thought 1ms is working fine 1ms is definitely not working fine for me. I've started reading the Washington Post since NYT makes my fan whir. As another drastic anecdotal step, I've turned off javascript on Safari (my main browser) and turn to other browsers when I find a site that requires javascript. If I don't do that, I find my Macbook Air battery eaten away in under an hour just because I left pages open that use setTimeout inappropriately. I wonder if in addition to a highres timer, we shouldn't also be considering other event driven APIs that could largely eliminate the use of timers from most sites. Take care, Rob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
Hi Peter, On Sep 30, 2008, at 8:42 PM, Peter Kasting wrote: 2008/9/30 Mike Belshe [EMAIL PROTECTED] As for keeping the fan off - if we could keep the CPU idle a 3ms minimum timeout loop does that resolve your concern? Followup to my earlier post, based on this. I realize that one reason why we (Chromium folks) have not been as concerned about CPU usage is that in a multi-process world, excessive CPU is an annoyance, but doesn't completely break the app. This wouldn't necessarily be the case in a single-process consumer of WebKit, e.g. Safari, where a page in a tight JS loop could make the whole browser less responsive. This seems like a legitimate reason to be concerned about excessive CPU usage. Mike's suggestion that we can find a minimum timeout value (e.g. 3 ms) where the CPU doesn't get pegged seems reasonable if this is the main issue. And a few more thoughts on app compat. Using more CPU is not an app compat concern. The CG GIF decoder that Safari uses burns 10x the CPU that Gecko's does, such that on various animated GIFs I can hit 60% of one of my (very fast!) cores just animating a single image in Safari. But no one has ever presented this as a web app compat issue, even though tons of web pages use animated GIFs; it's just a bug/optimization opportunity. Chromium uses extra CPU due to having plugins out of process. Gecko uses more CPU to relayout than WebKit. None of these are compatibility issues. The comments on bug 6998 imply to me that the 10ms cap was put in because Safari was eating more CPU than other browsers, not because there were animations running at the wrong speed or stylesheet loads not being sensed soon enough. I think if we can agree that not pegging the CPU, rather than precisely matching other browsers (which is impossible due to their 60% variance from each other), is the chief objection to uncapped timers, it will be easier to move forward. The problem is not only confined to single processor systems. As others have mentioned the bigger problem is the waste of resources. The length of the timeout is not the full piece of the puzzle. There's also problems with what the application does at the end of each timeout. This often needless processor use ends up draining batteries, increasing heat and wasting energy (even with a multiprocessor system). 2008/9/30 Alexey Proskuryakov [EMAIL PROTECTED] Sep 30, 2008, в 9:12 PM, Mike Belshe написал(а): As for keeping the fan off - if we could keep the CPU idle a 3ms minimum timeout loop does that resolve your concern? Maybe, partially. As mentioned in bug 6998, even 10 ms timers incur non-trivial processor usage. Your comment in that bug was that it was 3.7% of CPU on your machine. 3.7% for as fast as possible doesn't seem like a huge burden. That suggests authors could write tight loops at 3ms delays and still only burn 10% of the CPU. I think that's a reasonable proposal. Again, the length of the timeout is not the only thing determining CPU usage. The response to the timeout also influences CPU usage. If the timeout is clamped at 3ms instead of 12ms, then it is using the processor 4X as much (assuming that it doesn't also introduce synchronization problems the author didn't anticipate). That is quite significant. Given the growing importance in mobile processing it seems rather irresponsible to promote this waste of processor resources. Take care, Rob___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] API in webkit to convert Unicode -- HTML named entities?
On Jul 22, 2008, at 10:26 AM, Benjamin Hawkes-Lewis wrote: Dan Wood wrote: Yeah, that's one approach but it is way overkill for many needs, and invokes threads that aren't what you want for a simple function, and also only go from named entity into rendered Unicode character, and not the opposite (as you mention). I want the named entities rather than numbered for human-coder-readability Note that for the vast majority of characters in Unicode, no named entities exist. I imagine Dan is aware that the named references are a small subset of all Unicode characters. However, I can understand why that tiny subset of Unicode characters might prove useful as character references, making the generated source more human readable (especially for those characters that are part of the Unicode 'common' script). Having said that, It seems to me this sounds like a job for HTMLTidy. It might make sense to approach the HTMLTidy group to implement this. If HTMLTidy already performed this conversion (as an option), WebKit could easily add a method to expose that functionality when serializing the DOMDocument. Considering how ubiquitous HTMLTidy is, that makes it an even better place for code reuse. Take care, Rob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Metric unit measurements and on screen display
Hi Andre, On Jun 24, 2008, at 5:04 PM, Andre-John Mas wrote: Because of the move to resolution independence on the Mac, I decided to see what would happen if I indicated a table using centimeters. What I found is that what was indicated was not what was displayed. The computer being used for this test is MacBook Pro (Core Duo), with the built in screen and using native resolution. A test case is added at the end of the file. In the test case the table is specified to be 6cm wide, but is in reality 5.1cm wide. Is there something I am missing here, or is this something that should be flagged as a bug? What should the expectations be? BTW I decided to compare this with Firefox 3 and Opera 9.5 and the results are not consistent: Opera 9.5 results in 6.9 cm Firefox 3 results in 6.9 cm Some of this discussion has moved to the bugzilla system, but I thought it might be a topic worth discussing here too. Keep in mind that resolution independence is still coming and not yet ready for prime-time. So any tests conducted without specifically enabling resolution independence, will not reflect resolution independence on Mac OS X 10.5.x. Also it is important to understand that even with resolution independence we should not expect users to change their base zoom to 100% just because resolution independence supports that. Certainly some users will want that, but many users have become accustomed to the greater screen real estate afforded to those of us with a base zoom of 70% or even lower. That means that even if WebKit treated 1 point in CSS units as 1 point in NSView units (which it does not currently do), that would not necessarily equal 1 point on a physical ruler for many users. Having said that I do think WebView should be compatible with the resolution independence of the other views on the system and I've outlined a way that it could be made so without breaking compatibility (it is outlined on bugzilla). Basically it involves adding setters and getters to a webview to permit changing its base zoom from the system default. Currently WebView uses 1.33x base zoom from the system default. For Safari and other web browsers this makes sense to do to meet the expectations for users and make type readable. However, I think other applications may want to use a WebView with a standard 1.0x base zoom (compared to the rest of the system). Allowing applications to change the base zoom of a webview can fulfill the needs of both users (perhaps this is a method that belongs in the parent NSView class). Some applications may even want to provide a user default setting to alter the base zoom for webviews to suit the users needs. In this way the user could change either the base zoom of the OS or independently alter the base zoom of an individual WebView using application. Take care, Rob [1]: https://bugs.webkit.org/show_bug.cgi?id=11644 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Keeping track of supported specs on wiki
Hi Alexey,On Nov 10, 2007, at 1:42 AM, Alexey Proskuryakov wrote:on 10.11.2007 01:55, Rob Burns at [EMAIL PROTECTED] wrote:However, I think its better to show all of the standardswhether targeted by Apple or not. There are a lot of specifications out there - how would you decide whetherone is suitable for inclusion on this page? E.g., should we waste bandwidthexplicitly stating that we are not interested in RFC 3251 support?I understand that we could never make the list completely exhaustive. However, the list Phillippe provided is a good starting point. It may be worthwhile to provide links to pages for discussion of the reasons a particular standard is not (or is not yet) supported. After all it is a wiki. Many of the items Maciej removed are not all that helpful. It makes the list very much like the list on the non-wiki part of the website. It might make sense to link to that list as well so that contributors can see this Apple view of things.The Wiki can provide a valuable place to see archive how these discussion may have gone in the past.However, I assume other contributors arefree to bring standard supports to WebKit. I know of two such projectsmyself where contributors are working to bring standards support toWebKit not currently targeted by Apple. If they are working on such support, they can edit the page to mentionthat - it's a wiki.Definitely. However, I think the list Phillippe created was a nice core list to start with. Its worthwhile linking to further explanation for why WebKit has not in the past targeted some of those standards and provide a list of some obvious standards that contributors might pursue.Take care,Rob___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Keeping track of supported specs on wiki
Hi Maciej, On Nov 9, 2007, at 5:07 PM, Maciej Stachowiak wrote: On Nov 9, 2007, at 5:55 PM, Rob Burns wrote: Hello all, I have to say I like Philippe's version of the page better. I think it is more appropriate for an open source project like webkit. I would agree with Maciej that the word stable might be more appropriate than full. However, I think its better to show all of the standards whether targeted by Apple or not. It might make sense to have an asterisk on the no response to indicate that Apple has no plans to target a particular standard. The set of specs that currently have no support isn't necessarily identical to the set we are not targetting, or the set we would categorically rule out default support for. I think there are pretty few in the last category, and a huge number in the first if you take a broad view of what standards count. I would rather list the standards we *do* currently care about (including things like IETF RFCs, ECMA standards, ISO standards, etc) than try to list a complete or partial list of ones we don't care about. However, I assume other contributors are free to bring standard supports to WebKit. I know of two such projects myself where contributors are working to bring standards support to WebKit not currently targeted by Apple. Perhaps the status column should be one of: • No • No* (not targeted by Apple) • Partial • Stable Again, I'm not sure No adds much value relative things not on this list probably are not currently targetted. I certainly do not want to make a commitment on behalf of either Apple or the whole WebKit project that we won't support particular specs. I understand what you're saying. But I think if you step back and think about it logically, you'll see that Phillippe's proposal better fits what you're saying. His list is a list of possible standards that WebKit contributors mights want to consider. The only reason some were removed to create your list is that you personally (or perhaps Apple as an organization) do not foresee targeting those particular standards. However as a place for contributors to b begin it is useful to see what new terrains might be open to them. For example a developer might look at Phillippe's list and decide that standard A is of interest to them and they can then quickly see that its got a No. As an alternative, we could add in a category Intended with an email address or a URI to indicate a contact or contacts interested in pursuing a standard. Take care, Rob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] identifying a unique iPhone?
Hi Mahesh, On Aug 18, 2007, at 3:01 AM, Mark Rowe wrote: On 18/08/2007, at 7:46 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: We can use userAgent string in HTTP request to identify. Thought it might not be there already, but iPhone browser people can think of sending string iPhone and IMEI number in UserAgent string. Not only in scott case, this will be helpful to identify specific iPhone for one time download contents or online gaming in future. Not to mention being a huge invasion of the user's privacy. I'm wondering what problem you're trying to solve that cookies don't solve. Take care, Rob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] identifying a unique iPhone?
Hi Mahesh, I'm wondering what problem you're trying to solve that cookies don't solve. BTW, I added Webkitsdk-dev to this email since I think that's the more appropriate place to discuss this. I'm leaving Webkit-dev@ on here too since I don't know who the original poster was. Replies should probably remove the webkit-dev@ email address. One other thought too. My understanding is that iPhone currently lacks complete support for 509certificates and the like. Once support for that exists (and I'm just assuming it will some day) that would be the other way to uniquely identify a phone that would not involve invading the device user's privacy (since its based on shared trust). Take care, Rob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Accept- Content-Resolution headers proposal
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
Re: [webkit-dev] Your opinion on a CSS proposal
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 [EMAIL PROTECTED] 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Your opinion on a CSS proposal
On Jun 6, 2007, at 12:01 AM, Windy Road wrote:
On 06/06/07, Wesley Moore [EMAIL PROTECTED] 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] HTML4 and CSS2 table column styling
I started to post a reaply on this bug on HTML/CSS column issues,
when it grew to more listserv length post. So here it is.
I'm not totally clear why these table column issues are plaguing so
many browsers. I'm not yet that familiar with the WebKit codebase,
but the problems with implementing this do not seem that severe. This
is one area where IE has been able to get the upper hand (from what I
understand). It’s seems a bit confused too. The HTML4 recommendation
already begins to talk about these presentation properties (align,
width, etc.) being taken over by CSS. However, CSS seems to drop the
ball (by deprecating the string value for text-align for example).
Ideally, I think these features should be implemented through CSS.
Once WebKit was capable of presenting tables in flexible ways, I
imagine the HTML4 attribute behaviors could be implemented through
CSS. The only thing that I think pure CSS 2 could not handle, would
be extracting the character value from the 'char' attribute for use
as the string value in text-align. Regardless, implementing a 2D
table model within (nearly recommendation compliant?) CSS seems
pretty straight forward to me (though it does require a flexible
reading of the W3C recommendations). In doing so, WebKit would
provide features that content-creators want and it would also be
matching features provided by IE. Much of the barriers and objections
I hear raised about fixing these table-column issues stem from
thinking of CSS (which is a presentation layer) as too intricately
linked to the structural tree layer of a document.
Having said that, I think a complete implementation of table columns
requires more than just a consideration of inheritance. There are
three separate issues involved with table columns:
Properties of boxes displayed as table-column and table-column-group
(these are explicitly discussed in CSS recommendation):
border
background
width
visibility
computed values (both HTML attributes and CSS properties) which are
inherited by table-cells from table-columns or table-column-groups
Properties applied through contextual selectors descending from boxes
displayed as table-column and table-column-group (e.g.,
col#mySpecialColumn td {color: blue;} )
We need to think in two dimensions (i.e., a table-cell has two
parents) All that's needed is to think of:
table-cell boxes as descendants of both table-row and table-column boxes
those table-grid (column and row) boxes can descend from their
corresponding table-row-group or table-column-group boxes
finally, those table-grid-group boxes descend from a common table
or inline-table box
All that's needed is to rank the precedence of the two parent
elements, whether considering inheritance on one hand and the
specificity of descendant selectors following the column or row path
on the other hand.
Elaborating on the proposed W3C CSS2.1 recommendation for determining
specificity:
count 1 if the declaration is from a 'style' attribute rather than a
rule with a selector, 0 otherwise (= a) (In HTML, values of an
element's style attribute are style sheet rules. These rules have
no selectors, so a=1, b=0, c=0, and d=0.)
count the number of ID attributes in the selector (= b)
count the number of other attributes and pseudo-classes in the
selector (= c)
count the number of element names and pseudo-elements in the selector
(= d)
count 0 if the rule’s owner declaration’s selector involves a
selector for a box with display table-column or table-column-group
(i.e., it descends from a column). 1 otherwise.
However, when considering certain properties, then reverse this: 1 if
the selector involves a table-column or table-column-group, 0
otherwise. (= e). The reversed properties could be up for debate. Or
they could be listed in another property (e.g.: column-priority-
properties: text-align, font-family, font-size;). Or this reversal
could just be skipped. However, I 'm thinking of the reversals made
in HTML4 with align (horizontal).
[…]
Concatenating the fourfive numbers a-b-c-d-e (in a number system with
a large base) gives the specificity.
This means that within the associated stylesheets, any 'display'
property rules taking a value of 'table-column' or 'table-column-
group' or 'table-cell must be processed (cascaded) before any other
rules. Otherwise this alternate specificity calculation cannot be
performed. Once that has taken place it shouldn't require any
additional ivars (as far as I can tell): just a more elaborate
conditional statement.
Just as in the case of contextual selectors, a parallel issue arises
for inheritance. The inherited value for a table-cell could come from
either a table-row (and its group parent or the table itself) or a
table-column (and ultimately its group-column or group-row parent or
the table itself). However, the only extra conditional processing is
in considering
