Processing the zoom level - MS extensions to window.screen

Regarding:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029557.html

My objections have been noted throughout the threads:

 > It's not possible to discover the scaling of CSS pixels to actual device
 > pixels, with the current standard.

Ian's response:

"This is by design. You shouldn't need to know the actual device pixel
depth, as far as I can tell. What's the use case?"

I've got to say, this horse has been beaten to death.

It's necessary to know CSS pixel scaling to match the backend bitmap 
with the device.
This is common, active practice on mobile devices:
  [canvas width="200" style="width: 100px;"]

This is the current "fix" for Mozilla, as they are unwilling to budge:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029475.html

Robert O'Callahan's proposal would break some existing applications, and 
though it is indeed within the bounds of the existing spec, it would 
lead to slower canvas implementations; it'd also lead to weird 
situations where canvas backing sizes are of different dimensions across 
elements -- this would again, lead to unnecessary computing when using 
resources.  I've forwarded his proposal to the FX group, as I do think 
it has strong merit as part of the SVG/CSS discussions: Canvas has not 

Fwd: RE: Inconsistent behaviour of globalCompositeOperation property

Exposing spelling/grammar suggestions in contentEditable

Regarding:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029559.html

This has (somewhat) been resolved: Benjamin has pointed out that 
aria-invalid = "spelling|grammar"
would work just fine with <mark>. It's simply not implemented by vendors 
at the moment. It is covered
by the WAI ARIA 1.0 LC doc.

somebody [mark aria-invalid="spelling"]mispeld[/mark] this text.

Low Memory Event

Regarding:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029575.html

Web Applications may have wildly different use cases than hypertext 
documents.

The issue at hand is attempting, in some part, to send a signal to the 
DOM that a low
memory condition exists. This may not happen, but it certainly has 
strong use cases in web apps.

This doesn't mean adding any sort of constraint: it's simply a 
suggestion which the listening
application is free to ignore.

Currently, we can fool around with window.onblur, to try and "guess" 
when responsiveness is less important.

Ian's response to Rob demonstrates something that will always exist: 
Sometimes we switch tabs, and the other tab is a lower priority.
Apple's innovations with the iOS demonstrate how useful events can be, 
for eeking out a little extra stability in constrained environments.

Chrome and Firefox will crash / behave funnily when RAM is short. RAM 
gets short on my machine.
Safari also bails out, on the iOS, when RAM runs out. These can't be 
avoided completely, but they can
easily be mitigated by sending out an event, which the author can use to 
slim-down their environment.

A web application I work on uses Canvas bitmaps as buffers, to speed 
things up, like "Undo", when drawing.
It also uses Canvas to keep image sprites available. Many of these 
buffers can be destroyed at any time,
but doing so would mean they need to be recreated, taking up CPU. It's a 
typical CPU vs RAM trade-off.

If I were to receive an event, letting me know a low memory condition 
exists, I'd drop most of my buffers
immediately, allowing for the machine and my application to carry on 
normally, a little while longer.

This little bit of information sharing means a little bit more stability.

So, again: if low memory, then get rid of unneeded data in the scripting 
environment, such as canvas bitmaps, and state arrays.
The upside, is that the browser would run out of ram a little less 
often. The downside is that there'd be another word in the
large vocabulary of HTML/DOM events.

It may not be time to tackle these kind of issues, but I thought I'd 
give it a shot.

The usefulness has already been proven by iOS applications. We can work 
with low memory events there.
I'd like to be able to listen for them on the desktop as well.

-Charles

Re: Processing the zoom level - MS extensions to window.screen

On Fri, Dec 31, 2010 at 8:17 PM, Charles Pritchard <chuck@...> wrote:
> Nor will it be addressed, as Mozilla has given firm notice, they've intentionally obfuscated
> the value (devicePixelRatio), in the scripting environment. I dislike seeing that kind of behavior
> in any software.

It seems like the same old problem: someone's convinced himself that
he's thought of everything, and considers anything he didn't think of,
that doesn't fit the shiny, unbending, academic design in his head, as
invalid.  It's as frustrating to have my software fall victim to this
as it's always been.

Somebody wrote an NES emulator in Javascript, and even now I wouldn't
have believed it if I didn't see it myself.  Anybody saying "you
should never need to do that" today needs to prepare themselves for
plausible counterexamples.

> WebKit is stuck, as Mozilla won't budge. MS has exposed the values in a
> non-standard way.

Why is WebKit stuck because of Mozilla?  Having browser-specific fixes
for IE and for WebKit is much better than not being able to fix it at
all.  Giving a better experience to people using browsers that give me
what I need is better than forcing a broken lowest-common-denominator
on everyone.

--

-- 
Glenn Maynard

Re: Low Memory Event

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

In many cases the only way a browser can determine that such a condition 
exists is by trying to allocate memory and having the allocation fail. 
At which point... it's out of memory.  It doesn't have memory to 
allocate the event object, much less to run your script.

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 
reading the pretty extensive discussions on this topic in Mozilla's 
bugzilla and on the various Mozilla mailing lists over the last several 
years.

> I'd drop most of my buffers
> immediately, allowing for the machine and my application to carry on
> normally, a little while longer.

"drop most of my buffers" means you stop referencing them.  They don't 
get deallocated until garbage collection happens.  Garbage collection 
can require memory to perform.  In the case of Gecko, collecting 
canvases in fact requires a cycle-collection algorithm to run, which has 
to build a graph representing the current reference graph.  It's a 
fairly memory-hungry algorithm.

So by the time you're out of memory, doing this is too late.  It won't work.

 > The downside is that there'd be another word in the
> large vocabulary of HTML/DOM events.

And significantly greater implementation complexity for browsers if they 
try to make it work.  And it still wouldn't work.

> The usefulness has already been proven by iOS applications. We can work
> with low memory events there.

iOS may well provide useful low memory notifications to applications. 
Other OSes do not.  You find out about low memory when your allocation 
fails if you're lucky or when the kernel sends you a SIGKILL (Linux, I'm 
looking at you).

> I'd like to be able to listen for them on the desktop as well.

Then get desktop OS vendors to give applications a way to detect low 
memory reliably.

-Boris

Re: Exposing spelling/grammar suggestions in contentEditable

On Sat, Jan 1, 2011 at 1:23 AM, Charles Pritchard <chuck@...> 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

--
Benjamin Hawkes-Lewis

Re: Submitting form question

On Thu, Dec 30, 2010 at 9:09 PM, Aryeh Gregor
<Simetrical+w3c@...> wrote:
> On Thu, Dec 30, 2010 at 9:06 AM,  <Yael.Aharon@...> wrote:
>> When submitting a form, whose method is "GET" and action is identical to the
>> current location, except for the fragment, should that trigger reloading the
>> page, or simply navigating to the fragment?
>
> As I'm reading the spec, you're doing "Mutate action" in step 19 here:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#form-submission-algorithm
>
> Then in the navigation algorithm, step 7 says you just navigate to the
> new fragment and don't reload the page:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate
>
>> The background for my question is in the analysis done in
>> <          >
>
> Your conclusion appears to match mine, if I'm reading you right.
> HTML5 is confusing sometimes, but it sure is precise.
>

--

-- 
--
Benjamin Hawkes-Lewis

Re: Exposing spelling/grammar suggestions in contentEditable

On Sat, Jan 1, 2011 at 7:12 AM, Benjamin Hawkes-Lewis
<bhawkeslewis@...> wrote:
> On Sat, Jan 1, 2011 at 1:23 AM, Charles Pritchard <chuck@...> 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: 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.   `._.-(,_..'--(,_..'`-.;.'