Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable
On Sat, Jan 1, 2011 at 7:12 AM, Benjamin Hawkes-Lewis bhawkesle...@googlemail.com wrote: On Sat, Jan 1, 2011 at 1:23 AM, Charles Pritchard ch...@jumis.com wrote: It is covered by the WAI ARIA 1.0 LC doc. Note this usage is waiting on a putative change to WAI-ARIA to define its meaning when used with roles other than gridcell/option/row/tab. http://www.w3.org/WAI/PF/aria/states_and_properties#aria-selected Sorry for the noise - as was pointed out to me off-list, OP was referring to aria-invalid which doesn't have this problem. -- Benjamin Hawkes-Lewis
Re: [whatwg] window.open question...
On Mon, 27 Sep 2010, Biju wrote: Question, whether html5 spec is specific about behavior for steps at... https://bugzilla.mozilla.org/show_bug.cgi?id=197709#c0 See also https://bugzilla.mozilla.org/show_bug.cgi?id=197709#c3 I dont see HTML5 is specific about it at http://www.w3.org/TR/html5/browsers.html#dom-open http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-open So I think that Firefox bug report is invalid, but want to confirm As far as I can tell the HTML spec defines all this. See the navigate algorithm for details on what happens when a page loads, including when a new Window object is created: http://www.whatwg.org/specs/web-apps/current-work/complete.html#navigate Note in particular the exception listed under creating a new Document object, which may be relevant here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Low Memory Event
On 1/1/2011 12:08 PM, whatwg-requ...@lists.whatwg.org wrote: Date: Fri, 31 Dec 2010 22:01:42 -0600 From: Boris Zbarsky bzbar...@mit.edu On 12/31/10 7:35 PM, Charles Pritchard wrote: If I were to receive an event, letting me know a low memory condition exists There are various ways to try to work around this by trying to pre-reserve a memory pool, but they're not very reliable. I suggest ... get deallocated until garbage collection happens. Garbage collection can require memory to perform. In the case of Gecko, collecting ... So by the time you're out of memory, doing this is too late. It won't work. ... And significantly greater implementation complexity for browsers if they try to make it work. And it still wouldn't work. ... Then get desktop OS vendors to give applications a way to detect low memory reliably. Implementation details would not be defined by the spec. Implementation fo the event type would be low-cost, backward compatible, and a simple entry to existing spec docs. lowmemory does not need to mean that the OS is experiencing a low memory condition. Here are some example implementations; it's up to the vendor, not the spec. Tabbed browsing implementation: Send a lowmemory event to hidden tabs listening (for lowmemory), that have not been visible for more than 60 seconds. (This is a partial example, as it doesn't detail when the tabs would be checked for visibility. ) The example requires no OS mem-warnings and would allow use cases such as mine, to clean up a little, when lowmemory is fired. Mobile implementation: Mobile operating systems have lowmemory warnings, they are important for the durability of web apps running in mobile browsers. Expensive implementation: My mail client and web clients often compete with each other for memory: Mozilla apps drop image icons, WebKit crashes tabs. After a few tabs are crashed, or a few icons are dropped, they could certainly send a lowmemory event to remaining listeners. -Charles
Re: [whatwg] Low Memory Event
On 12/31/10, Ian Hickson i...@hixie.ch wrote: Please don't use all my memory for your Web-based game. :-) I may just be running it in the background while finding a video to watch, for example, in which case I really don't want the game using all my resources. Why would you want to run a game in the background? Is it an aural game?
Re: [whatwg] Low Memory Event
I'd like to be able to listen for them on the desktop as well. You need to know a lot about the host system to know what low memory even means. Does it mean allocations may start failing soon? Does it mean we're deep into swap, causing serious performance issues but not failed allocations? Even that's hard to define; you can be using a lot of swap, but it may be for entirely unused, idle background applications and not indicate memory pressure at all. This definitely seems useful on mobile platforms, where memory is much more limited, memory management is much less complex, and being able to deal reliably with memory limitations is a much more pressing issue. But on desktop platforms, even native applications written for a specific platform run into trouble when they try to respond intelligently to memory pressure, and the vast majority don't try. On Sat, Jan 1, 2011 at 3:39 PM, Charles Pritchard ch...@jumis.com wrote: Here are some example implementations; it's up to the vendor, not the spec. Tabbed browsing implementation: Send a lowmemory event to hidden tabs listening (for lowmemory), that have not been visible for more than 60 seconds. (This is a partial example, as it doesn't detail when the tabs would be checked for visibility. ) An event like this needs to have a consistent meaning to allow applications to respond meaningfully. If it has varied meanings--or if it has attributes to indicate each meaning, but they don't get implemented in practice, or are too generic and don't accurately describe the situation on each platform and configuration--then applications can't respond correctly. For example, responding to being an idle tab by releasing resources is the wrong thing to do if there's plenty of memory available. I have 8 GB of memory and Firefox rarely uses more than 512 MB. Don't make me wait for resources to be reloaded (or re-cached, or whatever the resource is) because they were released just in case. I have lots of memory precisely because I don't want to wait; I want applications to cache as much as possible. (The tab visibility proposal seems more appropriate for this particular example, anyway.) I'm not saying this is impossible, but memory management is exceptionally complex, varies wildly across platforms, varies wildly depending on how much memory and swap a system has, and on the behavior of other applications on the system. I'd be concerned about a generic, loosely-defined lowmemory event with entirely unrelated meanings encouraging developers to respond to it in ways that only happen to make sense on the platform they're testing on. -- Glenn Maynard
Re: [whatwg] Low Memory Event
On 1/1/2011 1:43 PM, Glenn Maynard wrote: You need to know a lot about the host system to know what low memory even means. Does it mean allocations may start failing soon? Does it ... This definitely seems useful on mobile platforms, where memory is much more limited, memory management is much less complex, and being able to deal reliably with memory limitations is a much more pressing issue. But on desktop platforms, even native applications written for a specific platform run into trouble when they try to respond intelligently to memory pressure, and the vast majority don't try. I realize it's an exotic feature. The separation of Mobile and Desktop seems arbitrary, in terms of specs: if it's useful on the mobile, why would it not be useful on the desktop? It's the same concept, a memory warning. On Sat, Jan 1, 2011 at 3:39 PM, Charles Pritchardch...@jumis.com wrote: Here are some example implementations; it's up to the vendor, not the spec. Tabbed browsing implementation: Send a lowmemory event to hidden tabs listening (for lowmemory), that have not been visible for more than 60 seconds. (This is a partial example, as it doesn't detail when the tabs would be checked for visibility. ) An event like this needs to have a consistent meaning to allow applications to respond meaningfully. If it has varied meanings--or if it has attributes to indicate each meaning, but they don't get implemented in practice, or are too generic and don't accurately describe the situation on each platform and configuration--then applications can't respond correctly. It has a consistent meaning, again, though, we're talking about whether it's a semantic meaning or a technical one. The technical meaning, we can't allocate memory isn't something that can be used on every platform, per Boris' comments. The semantic meaning is pretty straightforward: low memory warning. It's really up to the author to decide what they want to do with a low memory warning, and up to the vendor to decide if they want to send one out. Anything else seems to be impractical. For example, responding to being an idle tab by releasing resources is the wrong thing to do if there's plenty of memory available. I have 8 GB of memory and Firefox rarely uses more than 512 MB. Don't make me I stated, in the example, that it would need more logic to function appropriately. It was just a simple example to demonstrate that memory can be released without OS support, and that applications could use that information. I'm not saying this is impossible, but memory management is exceptionally complex, varies wildly across platforms, varies wildly depending on how much memory and swap a system has, and on the behavior of other applications on the system. I'd be concerned about a generic, loosely-defined lowmemory event with entirely unrelated meanings encouraging developers to respond to it in ways that only happen to make sense on the platform they're testing on. They all have the same related meaning: get rid of unnecessary buffers, serialize and save to disk, if appropriate. If I had a lowmemory event on the desktop, I'd run it through the exact same logic I would on mobile. Without the generic lowmemory, we're just going to go on without the event (except in extensions), with visibility/focus the only tool to test with. -Charles
Re: [whatwg] Low Memory Event
On Sat, Jan 1, 2011 at 5:04 PM, Charles Pritchard ch...@jumis.com wrote: The separation of Mobile and Desktop seems arbitrary, in terms of specs: if it's useful on the mobile, why would it not be useful on the desktop? It's the same concept, a memory warning. I fully agree that no HTML spec should make a distinction in any way between mobile and desktop. It's an impossible distinction to maintain from a spec perspective, as it's hopelessly blurry--mobile phones having higher and higher specs, iPads straddling the line in the middle, netbooks pushing in from the other direction, and the whole industry being a rapidly moving target that no spec will keep up with. I believe there are differences in practice that make low memory events not very useful on desktops, but that decision should be left to browsers. For example, responding to being an idle tab by releasing resources is the wrong thing to do if there's plenty of memory available. I have 8 GB of memory and Firefox rarely uses more than 512 MB. Don't make me I stated, in the example, that it would need more logic to function appropriately. My point was that the event needs to give enough information to *allow* the application's logic to do this correctly. They all have the same related meaning: get rid of unnecessary buffers, serialize and save to disk, if appropriate. If I had a lowmemory event on the desktop, I'd run it through the exact same logic I would on mobile. It just seems easy for this to go badly wrong. For example, suppose an implementation sends lowmemory when the system is low on swap; that is, it's actually running out of virtual memory entirely, and allocations are about to start failing or applications OOM-killed. So, I'm in Photoshop using a lot of memory, stuff gets swapped out, and then when it's nearly out of memory, Firefox notices and broadcasts lowmemory. What happens then? Your application decides to serialize its data and write it to disk, like you say. But your application is already swapped to disk. By accessing all of that data (there must be a lot of it, for it to be worth serializing to disk), you've just forced the OS to swap it all back into memory. It also forced it to swap something else out (probably Photoshop, which I'm trying to use) to make space for it. Serializing the data may use even more memory. This has all just seriously aggrevated the memory condition. Yet, doing that might be a perfectly valid response on a mobile system, where no swap is involved in a low memory condition. (Not entirely accurate--some Android systems compress memory as a swap mechanism.) If applications aren't given enough information to reasonably decide what to do, they'll have a single, universal response which will be correct in some cases and probably incorrect in many others. (Or, they'll have to try to infer what it means based on the browser and platform, which seems to defeat the purpose of speccing it.) -- Glenn Maynard
Re: [whatwg] Low Memory Event
On Sat, Jan 1, 2011 at 2:04 PM, Charles Pritchard ch...@jumis.com wrote: It's the same concept, a memory warning. On Sat, Jan 1, 2011 at 3:39 PM, Charles Pritchardch...@jumis.com wrote: Here are some example implementations; it's up to the vendor, not the spec. Tabbed browsing implementation: Send a lowmemory event to hidden tabs listening (for lowmemory), that have not been visible for more than 60 seconds. (This is a partial example, as it doesn't detail when the tabs would be checked for visibility. ) An event like this needs to have a consistent meaning to allow applications to respond meaningfully. If it has varied meanings--or if it has attributes to indicate each meaning, but they don't get implemented in practice, or are too generic and don't accurately describe the situation on each platform and configuration--then applications can't respond correctly. It has a consistent meaning, again, though, we're talking about whether it's a semantic meaning or a technical one. The technical meaning, we can't allocate memory isn't something that can be used on every platform, per Boris' comments. The semantic meaning is pretty straightforward: low memory warning. It's really up to the author to decide what they want to do with a low memory warning, and up to the vendor to decide if they want to send one out. Anything else seems to be impractical. What I don't understand about this proposal is how web apps are supposed to free memory. In my understanding, ES5 doesn't allow you to manually free memory (unlike Objective-C), and it's up to GC implementor to decide how and when (most of) resources are freed. - Ryosuke
Re: [whatwg] Low Memory Event
On 1/1/2011 4:07 PM, Glenn Maynard wrote: For example, responding to being an idle tab by releasing resources is the wrong thing to do if there's plenty of memory available. I have 8 GB of memory and Firefox rarely uses more than 512 MB. Don't make me I stated, in the example, that it would need more logic to function appropriately. My point was that the event needs to give enough information to *allow* the application's logic to do this correctly. They all have the same related meaning: get rid of unnecessary buffers, serialize and save to disk, if appropriate. If I had a lowmemory event on the desktop, I'd run it through the exact same logic I would on mobile. It just seems easy for this to go badly wrong. For example, suppose an implementation sends lowmemory when the system is low on swap; that is, it's actually running out of virtual memory entirely, and allocations are about to start failing or applications OOM-killed. So, I'm in Photoshop using a lot of memory, stuff gets swapped out, and then when it's nearly out of memory, Firefox notices and broadcasts lowmemory. What happens then? Your application decides to serialize its data and write it to disk, like you say. But your application is already Serialization mechanisms have to be pretty quick regardless: otherwise you end up with poor behavior (freezing gui) onunload. You're usually moving less than 5 megs of data, when serializing to local storage, as that's what localStorage is limited to in most environments. Serializing isn't the primary use case: de-referencing unneeded objects is the primary reason for the event. Serializing can help, of course.
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, Dec 31, 2010 at 3:46 PM, Jonas Sicking jo...@sicking.cc wrote:
I like the idea of bolding the matching parts of the suggestions which
match the typed string. Or at least creating a pseudo-element which
selected the matching substrings such that you could get the behavior
you want using:
input::matching-suggest {
font-weight: bold;
}
Would be great if you could file a bug in bugzilla.mozilla.org to
implement such a feature and cc me.
I think that's too narrow to be really useful as a dedicated feature
for authors (although maybe UAs will want to use it in their default
stylesheets). The number of authors who want to highlight the
matching suggestion but don't want any further markup seems like it
would be too small to justify a special-case feature. Especially
since if you get even slightly sophisticated, you might be returning
results that don't have the given string as an exact substring, e.g.,
if you normalize spacing and punctuation before doing matches (let
alone doing typo fixes and synonym substitutions like Google).
That aside, I do in general agree that it would be nice to allow
markup inside options. I do wonder if a lot of pages would break if
parsing was changed in such a way.
That does seem like a very logical way to do this. It would be cool
if this were possible -- it's a pain to get the absolute positioning
and such right as it stands.
Re: [whatwg] Low Memory Event
On Sat, Jan 1, 2011 at 7:35 PM, Ryosuke Niwa rn...@webkit.org wrote: What I don't understand about this proposal is how web apps are supposed to free memory. In my understanding, ES5 doesn't allow you to manually free memory (unlike Objective-C), and it's up to GC implementor to decide how and when (most of) resources are freed. Freeing memory in the context of Javascript means make available to the collector to be freed, eg. drop references. Actually collecting any resulting objects as a result of that is up to the implementation: presumably a thorough GC pass would be forced after sending this message, to actually free memory that the application released. (That seems simple enough on mobile browsers, but on desktop systems doing such a collection pass might force everything to be paged back into memory, and to incorrectly hint the OS that everything is active and shouldn't be paged back out quickly, so it's probably not that simple in practice.) -- Glenn Maynard
Re: [whatwg] Low Memory Event
On 1/1/2011 4:48 PM, Glenn Maynard wrote: On Sat, Jan 1, 2011 at 7:35 PM, Ryosuke Niwarn...@webkit.org wrote: What I don't understand about this proposal is how web apps are supposed to free memory. In my understanding, ES5 doesn't allow you to manually free memory (unlike Objective-C), and it's up to GC implementor to decide how and when (most of) resources are freed. Freeing memory in the context of Javascript means make available to the collector to be freed, eg. drop references. Actually collecting any resulting objects as a result of that is up to the implementation: presumably a thorough GC pass would be forced after sending this message, to actually free memory that the application released. (That seems simple enough on mobile browsers, but on desktop systems doing such a collection pass might force everything to be paged back into memory, and to incorrectly hint the OS that everything is active and shouldn't be paged back out quickly, so it's probably not that simple in practice.) ArrayBuffer and Canvas use contiguous memory segments. You don't need a complex GC pass to let those ones go. For my use cases, those are the two types I'm working with. Keeping them around helps the speed of my app, letting them go cuts down on memory usage.
Re: [whatwg] Low Memory Event
On 1/1/2011 4:07 PM, Glenn Maynard wrote: On Sat, Jan 1, 2011 at 5:04 PM, Charles Pritchardch...@jumis.com wrote: The separation of Mobile and Desktop seems arbitrary, in terms of specs: if it's useful on the mobile, why would it not be useful on the desktop? It's the same concept, a memory warning. I fully agree that no HTML spec should make a distinction in any way between mobile and desktop. It's an impossible distinction to maintain from a spec perspective, as it's hopelessly blurry--mobile phones having higher and higher specs, iPads straddling the line in the middle, netbooks pushing in from the other direction, and the whole industry being a rapidly moving target that no spec will keep up with. I believe there are differences in practice that make low memory events not very useful on desktops, but that decision should be left to browsers. ... My point was that the event needs to give enough information to *allow* the application's logic to do this correctly. ... mechanism.) If applications aren't given enough information to reasonably decide what to do, they'll have a single, universal response which will be correct in some cases and probably incorrect in many others. (Or, they'll have to try to infer what it means based on the browser and platform, which seems to defeat the purpose of speccing it.) I'm perfectly fine if a desktop implementer decides that they are not going to send low memory events. For me, the purpose of getting the event in the specs is to promote its use, and ensure that the HTML spec for mobile and desktop stays in sync. It's clearly a useful event for mobile; even if desktop vendors decide not to fire events, it'd be good to see it in the specs.
Re: [whatwg] Low Memory Event
On Sun, 02 Jan 2011 00:53:48 -, Charles Pritchard ch...@jumis.com wrote: ArrayBuffer and Canvas use contiguous memory segments. You don't need a complex GC pass to let those ones go. For my use cases, those are the two types I'm working with. Keeping them around helps the speed of my app, letting them go cuts down on memory usage. Maybe better solution would be to add purgeable flag to canvas (i.e. allow browser to clear canvas at any time) or some way to create/mark weak references? (i.e. a reference to object that can be changed to null if browser is in low-memory situation). Although, I'm not convinced that handling of low memory in JS is necessary. Browsers already have some ways to free memory, e.g. by freeing all bitmaps for img or simply by unloading whole pages. Amount of available memory, even on mobile devices, increases dramatically each year. It's possible that by the time this feature gets specified, implemented, released and installed on significant number of devices it will be irrelevant. On my desktop computer I often have 100 tabs open and memory is not an issue, and my mobile phone has 1/16th of that RAM already. -- regards, Kornel Lesiński
Re: [whatwg] Low Memory Event
On 2011-01-02 03:27, Kornel Lesiński wrote: On Sun, 02 Jan 2011 00:53:48 -, Charles Pritchard ch...@jumis.com wrote: ArrayBuffer and Canvas use contiguous memory segments. You don't need a complex GC pass to let those ones go. For my use cases, those are the two types I'm working with. Keeping them around helps the speed of my app, letting them go cuts down on memory usage. Maybe better solution would be to add purgeable flag to canvas (i.e. allow browser to clear canvas at any time) or some way to create/mark weak references? (i.e. a reference to object that can be changed to null if browser is in low-memory situation). Although, I'm not convinced that handling of low memory in JS is necessary. Browsers already have some ways to free memory, e.g. by freeing all bitmaps for img or simply by unloading whole pages. Amount of available memory, even on mobile devices, increases dramatically each year. It's possible that by the time this feature gets specified, implemented, released and installed on significant number of devices it will be irrelevant. On my desktop computer I often have 100 tabs open and memory is not an issue, and my mobile phone has 1/16th of that RAM already. I think this is starting to get off topic, as we're now into OS memory allocation territory. If the browser is told by the OS or the browser feels it need to conserve memory it can do whatever it pleases, OS stability trumphs web page/app/script/whatever, and should always do so. Charles, you initially said you where worried about this since you used undo buffers. Why not simply add undo buffers to the Canvas spec? That way the browser can start tossing away the oldest undo buffers automatically when it starts getting memory anorexic. And depending on the browser implementation and the OS and hardware support, on some systems the Canvas undo buffers could even be in graphics memory. It's wrong for Canvas to have undo stuff in active memory, most graphics programs store the undo on disk or it's paged out to a swapfile at the least. So if you have to make your own undo buffers for Canvas, then I'd say that Canvas is lacking and might need undo buffers as part of it's spec. -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] Low Memory Event
On Sat, Jan 1, 2011 at 9:52 PM, Roger Hågensen resca...@emsai.net wrote: Charles, you initially said you where worried about this since you used undo buffers. Why not simply add undo buffers to the Canvas spec? That way the browser can start tossing away the oldest undo buffers automatically when it starts getting memory anorexic. And depending on the browser implementation and the OS and hardware support, on some systems the Canvas undo buffers could even be in graphics memory. It's wrong for Canvas to have undo stuff in active memory, most graphics programs store the undo on disk or it's paged out to a swapfile at the least. So if you have to make your own undo buffers for Canvas, then I'd say that Canvas is lacking and might need undo buffers as part of it's spec. Concepts like undo buffers are high level application behavior--that doesn't belong in Canvas directly. A discardable flag is the right level of abstraction, though. It's definitely not simple. It also would be needed in many separate APIs--Canvas, WebGL, ArrayBuffer, HTMLImageElement, and anything else that can store large blocks of data (directly or indirectly). I started suggesting the same thing, but stopped since I don't see that ever happening. For what it's worth, Windows used to have an API to allocate discardable memory, which could be deallocated under memory pressure; it required locking and unlocking the memory, so when unlocked the memory essentially operated as a weak reference that could be deallocated as needed. I think this was only supported in Win16 (the GMEM_DISCARDABLE flag to GlobalAlloc); I mention it only for reference. -- Glenn Maynard
