On Thu, Nov 25, 2010 at 6:37 PM, Nils Dagsson Moskopp
nils-dagsson-mosk...@dieweltistgarnichtso.net wrote:
Silvia Pfeiffer silviapfeiff...@gmail.com schrieb am Thu, 25 Nov 2010
14:05:18 +1100:
Can the decision for a file format be taken completely separately from
the codec decision for the
Hi Subscribers,
I am not sure if I am at the right mailing list for this. But I was
wondering if it would be beneficial to have some kind of session
control feature in the Web Applications spec.
Currently the spec defines sessionStorage which I think is a great. It
allows me to stop using
On Thu, Nov 25, 2010 at 3:30 AM, Nils Dagsson Moskopp
1. Can we deprecate alert(), confirm(), prompt() ?
If sites rely on them, it is not possible to deprecate them.
That is why I asked to deprecate, but not obsolete..
However, I melieve browsers are making these dialogs tab-modal.
Yes I
On 11/25/2010 08:30 AM, ext Nils Dagsson Moskopp wrote:
Bijubijumaill...@gmail.com schrieb am Thu, 25 Nov 2010 02:29:31
1. Can we deprecate alert(), confirm(), prompt() ?
At present many web2.0 js libs are providing alternate [and cool
looking] methods to achieve use cases where we need to use
On Thu, Nov 25, 2010 at 8:26 AM, Benjamin Poulain
Although in my opinion, it would not make sense to deprecate without a good
alternative for modal dialogs.
But how many good sites use it.
Only place in GMail is when user try to send mail with no text in
Subject or Body field. Which they will
Am 25.11.2010 13:21 schrieb Biju:
On Thu, Nov 25, 2010 at 3:41 AM, a...@ashleysheridan.co.uk
a...@ashleysheridan.co.uk wrote:
Modal dialogues have a very special purpose, which works consistently across
various browsers in that we can program in with javascript some very
specific responses.
Am 24.11.2010 um 23:59 schrieb Charles Pritchard:
There is evidence that it will enhance usability for programmers who use it
properly.
Focus.
-Charles
Do you mean functionality rather than usability? As I understand this, an
author of a web page has neither control of nor knowledge
On Tue, 16 Nov 2010 02:15:45 +0100, Ian Hickson i...@hixie.ch wrote:
On Wed, 11 Aug 2010, Boris Zbarsky wrote:
For what it's worth, as I see it there are three possible behaviors for
a javascript: URI (whether in an attribute value or elsewhere):
1) Don't run the script.
2) Run the script,
On Thu, Nov 25, 2010 at 1:45 PM, Markus Ernst derer...@gmx.ch wrote:
Maybe, instead of your original suggestion, it might be worth thinking about
making alert()/confirm()/prompt() dialogs styleable via CSS? Then those
fancy JS lib dialogs would get obsolete, and we had the favour of both nice
On Thu, Nov 25, 2010 at 8:45 AM, Markus Ernst
Maybe, instead of your original suggestion, it might be worth thinking about
making alert()/confirm()/prompt() dialogs styleable via CSS? Then those
fancy JS lib dialogs would get obsolete, and we had the favour of both nice
look and support for
On 25.11.2010 15:55, Biju wrote:
The request I put is NOT about whether you can make it PRETTY looking or not.
The question is about why we are allowing website have something which is MODAL
(ie, both window modal and tab modal
https://bugzilla.mozilla.org/show_bug.cgi?id=59314)
In my opinion
On Fri, 12 Nov 2010 23:53:51 +0100, Nicholas Zakas nza...@yahoo-inc.com
wrote:
Just a quick question about the Last-Event-ID header. The spec currently
says:
If the event source's last event ID string is not the empty string,
then a Last-Event-ID HTTP header must be included with the
On 11/25/2010 8:19 AM, whatwg-requ...@lists.whatwg.org wrote:
Message: 3
Date: Thu, 25 Nov 2010 14:18:49 +0100
From: Martin Janeckewhatwg@kaor.in
To: whatwgwhatwg@lists.whatwg.org
Subject: Re: [whatwg] Processing the zoom level - MS extensions to
window.screen
Am 25.11.2010 17:12 schrieb Nikita Popov:
On 25.11.2010 15:55, Biju wrote:
The request I put is NOT about whether you can make it PRETTY looking
or not.
Sorry, that was how I understood point 1 your initial message.
The question is about why we are allowing website have something which
is
On Thu, 14 Oct 2010 14:23:41 +0200, ATSUSHI TAKAYAMA
taka.atsu...@googlemail.com wrote:
On Wed, Oct 13, 2010 at 10:00 AM, Anne van Kesteren ann...@opera.com
wrote:
On Tue, 12 Oct 2010 06:41:59 +0200, ATSUSHI TAKAYAMA
taka.atsu...@googlemail.com wrote:
It's a minor error in the spec in the
On Thu, Nov 25, 2010 at 11:55 AM, Anne van Kesteren ann...@opera.com wrote:
On Thu, 14 Oct 2010 14:23:41 +0200, ATSUSHI TAKAYAMA
taka.atsu...@googlemail.com wrote:
On Wed, Oct 13, 2010 at 10:00 AM, Anne van Kesteren ann...@opera.com
wrote:
On Tue, 12 Oct 2010 06:41:59 +0200, ATSUSHI
On Tue, 23 Nov 2010 23:09:40 +0100, Philip Taylor
excors+wha...@gmail.com wrote:
On Tue, Nov 23, 2010 at 8:43 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
Right now, canvas gradients interpolate their colors in
non-premultiplied space; that is, the raw values of r, g, b, and a are
On Thu, 25 Nov 2010 18:21:35 +0100, ATSUSHI TAKAYAMA
taka.atsu...@googlemail.com wrote:
I would say the simpler the rule is, the better.
So a line without colon should be ignored.
Also for the example in the spec;
-a single data: line followed by an empty line should fire a message
event with
Am 25.11.2010 um 17:41 schrieb Charles Pritchard:
(2) The browsers' build-in zoom function, which web page authors have no
control or information about.
They have information about it, in many browsers, and they receive events
related to window.innerWidth and innerHeight.
Well, an author
On 11/25/10 11:26 AM, Martin Janecke wrote:
Am 25.11.2010 um 17:41 schrieb Charles Pritchard:
(2) The browsers' build-in zoom function, which web page authors have no
control or information about.
They have information about it, in many browsers, and they receive events
related
On Thu, Nov 25, 2010 at 1:29 AM, Biju bijumaill...@gmail.com wrote:
1. Can we deprecate alert(), confirm(), prompt() ?
At present many web2.0 js libs are providing alternate [and cool
looking] methods to achieve use cases where we need to use alert(),
confirm(), prompt(). So do we need those
On 11/25/10 1:59 PM, Anne van Kesteren wrote:
They also pointed out we do support rgba() in SVG.
The point is that the resulting behavior is not defined by the SVG spec.
You could blow up the user's computer when using an rgba() color in
SVG, and that would be as spec-compliant as anything
I'd like to propose reserving two protocols for use with
navigator.registerProtocolHandler: urn and xri (or possibly xriNN
where NN is a version number).
See http://en.wikipedia.org/wiki/Extensible_Resource_Identifier for info
on XRI (basically allows the equivalents of URN but with a
My apologies, I realized that there might be a modification needed to
the HTML5 design of registerProtocolHandler, in that URN and XRI are
better designed to work, in many cases, with registration to a specific
namespace. For example, one application might only wish to handle
urn:earthquakes
24 matches
Mail list logo
