On 08/11/2015 05:08 PM, Majid Valipour wrote:
According to HTML5 spec persisted user state (scroll, scale, form values,
etc)
should be restored before dispatching popstate event. (See steps 9 and 14 in
history traversal algorithm[1]).
Gecko and IE follow the spec order for scroll position but
On 07/09/2015 06:22 PM, Anne van Kesteren wrote:
On Thu, Jul 9, 2015 at 5:15 PM, Rick Byers rby...@chromium.org wrote:
I think there's a big opportunity to substantially improve scroll
performance on the web in the relatively short term by doing something
incremental. I.e. I'm pretty sure I
On 07/08/2015 10:12 PM, Rick Byers wrote:
[Cross-posted to www-...@w3.org - please let me know if there's a better
way to account for the DOM spec duality]
In Chromium we've long worked hard at maximizing scroll performance, with
scroll-blocking DOM events (wheel and touchstart in particular)
On 10/08/2014 08:03 PM, Tab Atkins Jr. wrote:
On Wed, Oct 8, 2014 at 9:16 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
What I find interesting here is the claim that people find try/catch annoying
or
On 08/26/2014 12:53 PM, Jonas Sicking wrote:
On Tue, Aug 26, 2014 at 2:18 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Aug 26, 2014 at 11:06 AM, Jonas Sicking jo...@sicking.cc wrote:
I don't see a problem with firing events on all Notification
instances, and only changing focus if
On 08/24/2014 09:53 AM, Anne van Kesteren wrote:
On Fri, Aug 15, 2014 at 2:38 PM, Olli Pettay o...@pettay.fi wrote:
in order to prevent whatever default action Notification's click event has
(for example focus the tab which initiated the Notification), the click
event
should be cancelable so
On 08/20/2014 11:33 AM, Anne van Kesteren wrote:
On Wed, Aug 20, 2014 at 10:29 AM, Jonas Sicking jo...@sicking.cc wrote:
FWIW, the web platform sorely needs a construct for readonly state
variable + event whenever the state changes. I.e. some form of
observable which remembers the last produced
Hi,
in order to prevent whatever default action Notification's click event has
(for example focus the tab which initiated the Notification), the click event
should be cancelable so that .preventDefault() can be called.
Some background
On 07/24/2014 09:10 AM, Jukka K. Korpela wrote:
2014-07-24 8:34, Boris Zbarsky wrote:
On 7/24/14, 1:29 AM, Jukka K. Korpela wrote:
However, browsers actually impose an upper limit of 32767
In Chrome and Firefox, values larger than this are interpreted as 0.
In the case of Firefox,
On 07/21/2014 12:21 AM, milakam wrote:
Hi everyone,
A BeforeLoad replacement was never discussed as a target use case for
MutationObservers, therefore this message.
I'm currently creating a JS cross-browser user script and noticed that
only Chromium notifies the MutationObserver for an
On 10/01/2013 06:37 PM, Ehsan Akhgari wrote:
Hi everyone,
We're coming across a need to get notified when the other side of a channel
goes away because the user navigates away from the page, or if the page is
killed by the OS, etc. Currently a workaround is for the application to
handle the
On 03/12/2013 12:34 PM, Anne van Kesteren wrote:
On Tue, Mar 12, 2013 at 12:41 AM, Alex Russell slightly...@google.com wrote:
Thoughts?
My main thought is that it's a pita to change the API at this time now
it's unprefixed everywhere and we've been encouraging developers to
use it in favor of
On 01/29/2013 01:35 PM, Richard wrote:
Hi,
In March 2012 there were a number of additions to the canvas 2D
context - including the resetClip() function. However I can't now find
this function mentioned in the spec
(http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas/).
Has it been removed?
On 01/29/2013 12:15 AM, Elliott Sprehn wrote:
The Notification constructor should not have side effects. This is
generally considered bad design, and the rest of the platform doesn't have
this either.
Specifically new Notification() should not show the notification since it
prevents reuse of
On 12/04/2012 09:27 PM, Ian Hickson wrote:
On Thu, 29 Nov 2012, Olli Pettay wrote:
I think we need to keep the contextmenu functionality, and I don't see
reasons to not to do it the way Gecko has it now (using menu
type=context and menuitem).
Do you mean as opposed to allowing menuitem
There are also pageshow and pagehide events,
although the spec for them seems to be wrong.
They are fired always, not only when dealing with session history.
-Olli
On 12/14/2012 08:51 PM, Mike Wilson wrote:
Thanks Ian,
Ian Hickson wrote on 14 december 2012 19:22:
On Fri, 14 Dec 2012, Mike
On 12/15/2012 01:52 AM, Ian Hickson wrote:
On Sat, 15 Dec 2012, Olli Pettay wrote:
There are also pageshow and pagehide events, although the spec for them
seems to be wrong. They are fired always, not only when dealing with
session history.
Do you have a test case that shows when
On 11/12/2012 11:55 AM, Boris Zbarsky wrote:
Consider the attached testcase, which calls setTimeout on a window and passes
in a function from a different window.
When this function is then called, it throws.
Gecko, WebKit, and Presto all seem to trigger the onerror handler of the window
(This all should go to WebApps WG)
In Gecko there is support for moz-chunked-arraybuffer
response type.
On 08/24/2012 03:23 AM, Jussi Kalliokoski wrote:
Hello,
I've got a little proposal to solve a problem we're facing with one of our
codebases ( aurora.js [1], i.e. audio codecs in
On 07/14/2012 12:38 AM, Ojan Vafai wrote:
It's been pointed out to me that what I'm asking for is essentially the
same retargeting as we do for shadow DOMs in web components, where the
iframe is the shadow host and the document is the shadow root. This covers
all the details of what properties
On 06/05/2012 09:31 AM, Jer Noble wrote:
On Jun 4, 2012, at 11:23 PM, Robert O'Callahan rob...@ocallahan.org wrote:
If you implemented that proposal as-is then authors would usually need a
listener on the document as well as the element, and as Chris pointed
out, it's simpler to just always
Few random comments about rniwa's UndoManager
http://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html
Also, any Web app that tries to mix contenteditable region or text
fields with canvas or other non-text editable regions will have to
reimplement undo and redo of contenteditable
On 10/15/2011 07:27 AM, Anne van Kesteren wrote:
I wrote up a draft:
http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
Defining when exactly the fullscreen enabled flag is set for Document
objects I will leave up to HTML. As well as defining the
allowfullscreen attribute. Presumably
On 07/06/2011 07:51 AM, Robert O'Callahan wrote:
I don't think browsers need to prompt for registerProtocolHandler. Instead,
I would simply allow any site to register as a protocol handler for almost
anything, and remember all such registration
So all the ad sites (which are embedded via
On 07/02/2011 12:25 AM, Michael Davidson wrote:
From my perspective on Gmail, I would prefer to know if the user hasn't
registered because they declined previously or haven't been asked. If
they've declined previously, then calling registerProtocolHandler() in
today's UAs will not do anything.
On 06/18/2011 01:31 AM, Ian Hickson wrote:
On Fri, 17 Jun 2011, Jonas Sicking wrote:
On Wed, 1 Jun 2011, Jonas Sicking wrote:
We should probably consider adding the ability to specify if you want
the request to happen with or without credentials (and default to the
safe option which is
On 05/15/2011 01:24 AM, Ojan Vafai wrote:
It's unfortunate that you need to use an inline event handler instead of one
registered via addEventListener to avoid the race condition. Exposing
something to the platform like jquery's live event handlers (
http://api.jquery.com/live/) could mitigate
On 03/18/2011 04:02 PM, Lachlan Hunt wrote:
On Mon, 24 Jan 2011, Anne van Kesteren wrote:
There is a plan of allowing direct assigning to IDL attributes besides
creating URLs.
I.e. being able to do:
audio.src = blob
(The src content attribute would then be something like
about:objecturl.)
On 03/17/2011 06:31 PM, Philip Jägenstedt wrote:
On Thu, 17 Mar 2011 16:48:40 +0100, Olli Pettay
olli.pet...@helsinki.fi wrote:
On 03/17/2011 03:11 PM, Lachlan Hunt wrote:
On 2011-03-16 19:29, Olli Pettay wrote:
Perhaps navigator.getUserMedia(audio,video, success, error);
could return an url
On 03/17/2011 07:41 PM, Lachlan Hunt wrote:
On 2011-03-17 16:48, Olli Pettay wrote:
... src property definition needs to be changed
from DOMString to any.
That would be strange and make API inconsistent with img and iframe
for example.
This is getting a bit off topic, but it would be better
On 03/15/2011 10:58 PM, Robert O'Callahan wrote:
Instead of creating new state signalling and control API for streams, what
about the alternative approach of lettingvideo andaudio use sensors as
sources, and a way to connect the output ofvideo andaudio to encoders?
Then we'd get all the
On 03/16/2011 05:36 PM, Lachlan Hunt wrote:
On 2011-03-15 21:58, Robert O'Callahan wrote:
Instead of creating new state signalling and control API for streams,
what
about the alternative approach of lettingvideo andaudio use
sensors as
sources, and a way to connect the output ofvideo andaudio
On 10/22/2010 10:09 PM, Jonas Sicking wrote:
On Fri, Oct 22, 2010 at 11:15 AM, Erik Arvidssona...@chromium.org wrote:
On Oct 22, 2010 2:00 AM, Anne van Kesterenann...@opera.com wrote:
Yeah, I don't mind moving these features to libraries. Anyone implemented
them apart from Opera?
Neither
On 12/29/2010 09:27 AM, Ian Hickson wrote:
On Mon, 20 Sep 2010, Biju wrote:
We need
HTMLNode.getSupportedEvents() == returns a text array of event names
HTMLNode.isSupportedEvent(eventName) == returns true/false
Many times in particular version of browser we dont know whether an
On 12/02/2010 12:42 AM, Tab Atkins Jr. wrote:
On Wed, Dec 1, 2010 at 2:16 PM, Tab Atkins Jr.jackalm...@gmail.com wrote:
I've gone with using element() for selectors (limited to only ID
selectors, but other valid selectors are accepted, they just don't
currently do anything). Then
On 12/02/2010 01:43 AM, Tab Atkins Jr. wrote:
On Wed, Dec 1, 2010 at 3:38 PM, Olli Pettayolli.pet...@helsinki.fi wrote:
On 12/02/2010 12:42 AM, Tab Atkins Jr. wrote:
On Wed, Dec 1, 2010 at 2:16 PM, Tab Atkins Jr.jackalm...@gmail.com
wrote:
I've gone with using element() for selectors
On 10/20/2010 03:03 PM, Jens Müller wrote:
Hi,
now that device orientation, geolocation, camera etc. have been spec'ed:
Is there any intent to provide an API for pressure sensors?
This might well be the next hip feature in smartphones ...
Oh, and while we are at it: Humidity probably belongs
On 10/15/2010 02:45 PM, Anne van Kesteren wrote:
On Thu, 14 Oct 2010 15:46:30 +0200, Olli Pettay
olli.pet...@helsinki.fi wrote:
may I wonder why on earth any new API, like
link.sizes uses PutForwards?
IMHO, PutForwards should be limited to the
awkward DOM0 APIs like window.location.
What's
Hi,
may I wonder why on earth any new API, like
link.sizes uses PutForwards?
IMHO, PutForwards should be limited to the
awkward DOM0 APIs like window.location.
br,
-Olli
On 09/20/2010 06:42 AM, Shiv Kumar wrote:
Areyah, thanks for your inputs thus far.
At that point, the user is already in the process of navigating
away from the page.
Keep in mind that I'm talking about large file uploads. For the
typically user that takes about 2-6 hours. So they may be in
XMLHttpRequest has progress events and you can send files and form data
using it.
-Olli
On 09/20/2010 12:20 AM, Shiv Kumar wrote:
I’d like to propose that UAs should surface an bytes transferred event
when a form is being submitted. With so many large files being uploaded
using browsers
On 08/24/2010 11:38 PM, Adam Barth wrote:
This seems related to the magic iframe concept that was recently
added in WebKit. Basically, magic iframe lets you move an iframe from
one document to another without blowing away the JavaScript/DOM state
of the iframe.
One thing not too clear in the
Hi all,
I wonder why a element should have .text which
is basically just the same thing as
.textContent.
I'd prefer removing .text.
-Olli
On 6/21/10 9:25 PM, Jonas Sicking wrote:
On Mon, Jun 21, 2010 at 11:09 AM, Olli Pettayolli.pet...@helsinki.fi wrote:
Hi all,
I wonder why a element should have .text which
is basically just the same thing as
.textContent.
I'd prefer removing .text.
It's actually worse, see
On 6/8/10 5:26 PM, Mounir Lamouri wrote:
Hi,
According to the HTML5 specification, an IDL attribute reflecting an
enumerated attribute will have the default reflecting behavior (ie.
return the content attribute on getting and setting it on setting)
except if the attribute is limited to only
On 5/18/10 11:27 AM, Bjorn Bringert wrote:
On Mon, May 17, 2010 at 9:23 PM, Olli Pettayolli.pet...@helsinki.fi wrote:
On 5/17/10 6:55 PM, Bjorn Bringert wrote:
(Looks like half of the first question is missing, so I'm guessing
here) If you are asking about when the web app loses focus (e.g.
On 5/17/10 4:05 PM, Bjorn Bringert wrote:
Back in December there was a discussion about web APIs for speech
recognition and synthesis that saw a decent amount of interest
(http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/thread.html#24281).
Based on that discussion, we would
On 5/17/10 6:55 PM, Bjorn Bringert wrote:
(Looks like half of the first question is missing, so I'm guessing
here) If you are asking about when the web app loses focus (e.g. the
user switches to a different tab or away from the browser), I think
the recognition should be cancelled. I've added
On 5/11/10 11:43 AM, J Ross Nicoll wrote:
Looking at http://www.w3.org/TR/2009/WD-FileAPI-20091117/#dfn-file
Note, discussion about FileAPI should happen in WebApps WG mailing list.
There doesn't appear to be anyway of retrieving creation date,
modification date or size of the file.
You
On 4/5/10 3:21 PM, Mounir Lamouri wrote:
Hi,
I'm wondering why the [PutForwards=value] extended attribute is needed
for the htmlFor output element attribute ?
It is making things pretty ugly for a need I do not really get.
Thanks,
--
Mounir
I agree. In general PutForwards makes APIs
On 3/25/10 12:08 AM, Olli Pettay wrote:
On 3/24/10 11:33 PM, Ian Hickson wrote:
On Sun, 21 Feb 2010, Olli Pettay wrote:
I propose that bufferedAmount doesn't take account the bits added by the
protocol. This way if the protocol is later changed, web developers
don't need to change their code
On 3/25/10 11:11 AM, Anne van Kesteren wrote:
On Wed, 24 Mar 2010 23:08:43 +0100, Olli Pettay
olli.pet...@helsinki.fi wrote:
On 3/24/10 11:33 PM, Ian Hickson wrote:
I guess I'm unclear on whether bufferedAmount should return:
1. the sum of the count of characters sent?
(what would we do when
On 3/25/10 12:08 PM, Niklas Beischer wrote:
On Thu, 25 Mar 2010 10:21:10 +0100, Olli Pettay
olli.pet...@helsinki.fi wrote:
On 3/25/10 12:08 AM, Olli Pettay wrote:
On 3/24/10 11:33 PM, Ian Hickson wrote:
On Sun, 21 Feb 2010, Olli Pettay wrote:
[snip]
I guess I'm unclear on whether
On 3/25/10 4:25 PM, Niklas Beischer wrote:
On Thu, 25 Mar 2010 13:23:57 +0100, Olli Pettay
olli.pet...@helsinki.fi wrote:
On 3/25/10 12:08 PM, Niklas Beischer wrote:
On Thu, 25 Mar 2010 10:21:10 +0100, Olli Pettay
olli.pet...@helsinki.fi wrote:
On 3/25/10 12:08 AM, Olli Pettay wrote:
On 3
On 3/25/10 5:55 PM, Anne van Kesteren wrote:
On Thu, 25 Mar 2010 16:35:19 +0100, Olli Pettay
olli.pet...@helsinki.fi wrote:
On 3/25/10 4:25 PM, Niklas Beischer wrote:
Easy. The bufferedAmount is: The amount of bytes waiting to be
transferred, including protocol overhead.
That doesn't define
On 3/24/10 11:33 PM, Ian Hickson wrote:
On Sun, 21 Feb 2010, Olli Pettay wrote:
I propose that bufferedAmount doesn't take account the bits added by the
protocol. This way if the protocol is later changed, web developers
don't need to change their code because of the way they rely
On 3/18/10 2:15 AM, Alexey Proskuryakov wrote:
On 05.03.2010, at 15:32, Alexey Proskuryakov wrote:
for something no one should care about, as you
implied above.
From API perspective I do care. Web developers shouldn't need to know
about the protocol, yet (s)he should be able to understand
On 3/5/10 7:54 PM, Alexey Proskuryakov wrote:
On 04.03.2010, at 1:52, Olli Pettay wrote:
I noticed that WebSocket spec updated to not inlcude framing overhead in
bufferedAmount.
I asked that since from API point of view it doesn't make
much sense to have the frame bytes to be magically
On 3/5/10 10:39 PM, Alexey Proskuryakov wrote:
On 05.03.2010, at 10:27, Olli Pettay wrote:
I was going to mention this as the primary reason why frame bytes should
be included. JavaScript code needs this information for flow control,
Why?
I assume you are asking why JavaScript code needs
On 3/5/10 11:13 PM, Alexey Proskuryakov wrote:
On 05.03.2010, at 12:56, Olli Pettay wrote:
And you're saying that javascript really needs to know about the
frame boundary bytes to detect if it is streaming too fast.
Doesn't sound likely to me.
OK
That's true, but I don't know how many
On 3/4/10 4:42 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
Hi,
I noticed that WebSocket spec updated to not inlcude framing overhead in
bufferedAmount.
I asked that since from API point of view it doesn't make
much sense to have the frame bytes to be magically included in the
bufferedAmount.
What if we
On 3/4/10 4:11 AM, Ojan Vafai wrote:
WebKit would like to implement this in the (very) near future. Before
proceeding, we'd like to hear from other browser vendors that you're
roughly on board with this direction of adding beforeinput and input events.
Here are the changes I can think of that
On 3/4/10 12:17 PM, Fumitoshi Ukai (鵜飼文敏) wrote:
On Thu, Mar 4, 2010 at 18:52, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
On 3/4/10 4:42 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
Hi,
I noticed that WebSocket spec updated to not inlcude framing
This kind of discussion should happen in W3C WebApps WG, using
DOM mailing list (www-...@w3.org).
There as been some discussion about this subject and I hope
there would be a draft spec somewhat soon.
(This all may depend on patent nonsense.)
-Olli
On 2/26/10 12:37 AM, dpenk...@gmail.com
On 1/31/10 6:38 AM, Tab Atkins Jr. wrote:
This one seems kind of weird. Does the spec currently distinguish
significantly between a user-initiated click and a script-initiated
one?
DOM 3 Events draft does have the concept of trusted events;
UA/user generated events are trusted, script
(where it could e.g. fire twice for the same URL,
because the navigations get processed before it fires).
On Thu, 28 Jan 2010, Olli Pettay wrote:
On 1/28/10 7:15 AM, Darin Fisher wrote:
That said, I think it would be good for location.hash = 'a' to
interrupt the history.back() request. The net
On 1/28/10 7:15 AM, Darin Fisher wrote:
That said, I think it would be good for location.hash = 'a' to interrupt the
history.back() request. The net result being that #a is appended to
session history, and the history.back() request is discarded.
Really? What if iframe has been navigated
On 1/21/10 11:12 AM, Darin Fisher wrote:
In WebKit, history.back() is currently implemented asynchronously.
However, it was not always this way. Previously, if the back navigation
corresponded to a hash change, then the back navigation would complete
synchronously. If the back navigation
On 1/21/10 11:12 AM, Darin Fisher wrote:
From a web compat perspective, it seems wise to match the behavior of
IE.
I'm not sure how important it is to copy IE here, if we aren't going to
copy IE's behavior elsewhere, like about:blank handling.
But anyway, making history.x async sounds good to
And still one thing to test and specify;
if history.back()/forward() is asynchronous,
does that mean that loading start asynchronously,
or that entries are added asynchronously to session history?
What should happen if a page calls:
history.back();
history.forward();
What if the page calls:
On 1/21/10 2:33 PM, Olli Pettay wrote:
or that entries are added asynchronously to session history?
Ok, this is not valid question in this context, since .back()/forward()
use the existing session history entry anyway.
A better question might be that when is the
current entry updated?
-Olli
Hi all,
if I read 6.10 correctly it has a special case for about:blank
documents only when loading a new document to a context which has only
about:blank document. But that isn't quite enough, I think.
Traditionally (IE/Gecko) about:blank documents haven't been put to
session history. Opera
Hi all,
currently
http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#printing
says that window.print() should prompt user to print the page, but that
For instance, a kiosk browser could silently ignore any invocations of
the print() method.
A print button in web pages
On 12/28/09 6:44 PM, João Eiras wrote:
Throwing an error does not seem very compatible either.
Returning a boolean from print() would not be problematic.
Note that desktop UAs support printing most of the time, while handheld
or tv ones don't.
Returning a boolean sounds good to me.
(Sending this 2nd time. Hopefully whatwg list doesn't bounce it back.)
On 12/11/09 6:05 AM, Bjorn Bringert wrote:
Thanks for the discussion - cool to see more interest today also
(http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-December/024453.html)
I've hacked up a proof-of-concept
On 12/10/09 4:54 PM, Weston Ruter wrote:
I've been working on a web app which reads text in a web page,
highlighting each word as it is read. For this to be possible, a
Text-To-Speech API is needed which is able to:
(1) generate the speech audio from some text, and
(2) include the time indicies
Indeed the API should be something significantly simpler than X+V.
Microsoft has (had?) support for SALT. That API is pretty simple and
provides speech recognition and TTS.
The API could be probably even simpler than SALT.
IIRC, there was an extension for Firefox to support SALT (well, there
was
On 11/12/09 10:00 PM, Justin Lebar wrote:
Perhaps a better idea is leaving this whole issue to the UA, which
could collapse all the entries from a single origin in the UI. Then
we wouldn't need either function.
How would UA collapse entries from a single origin?
I agree clearState is a bit
On 10/30/09 7:26 AM, Boris Zbarsky wrote:
On 10/29/09 10:16 PM, Maciej Stachowiak wrote:
WebKit also makes typing take effect as the default action for
keypress, at least for normal typing. It's more complicated when
international text input methods are in play.
Yeah, when IME is involved I
Hi all,
seems like the draft doesn't specify properly what should happen when
dropping something to a (text) form control.
The draft says that if dragover isn't canceled, then drag operation
becomes none, and then later if the current drag operation is none...
then the drag operation failed.
contentEditable may need special handling too.
Haven't tested how IE (or other browsers) handles that.
-Olli
On 10/21/09 3:15 PM, Olli Pettay wrote:
Hi all,
seems like the draft doesn't specify properly what should happen when
dropping something to a (text) form control.
The draft says
On 10/8/09 5:01 PM, Maciej Stachowiak wrote:
On Oct 8, 2009, at 4:37 AM, Henri Sivonen wrote:
In reference to https://bugzilla.mozilla.org/show_bug.cgi?id=520969:
Gecko currently looks at the doctype passed to createDocument() in
order to decide what interfaces to offer on the returned
Hi,
seems like HTML5 doesn't properly specify what should happen if the
'previous top level page' contained frames and go(-some value) is
used to navigate back.
Browsers also do different things. A pretty simple testcase is here
http://mozilla.pettay.fi/moztests/history/Start.html
Just click
On 9/10/09 11:13 AM, Jonas Sicking wrote:
On Thu, Sep 10, 2009 at 12:41 AM, Maciej Stachowiakm...@apple.com wrote:
On Sep 9, 2009, at 10:26 PM, Robert O'Callahan wrote:
If you call cloneNode on a media element, the state of the resulting media
element seems unspecified. Should it be playing
On 9/10/09 2:24 AM, Robert O'Callahan wrote:
On Thu, Sep 10, 2009 at 6:37 AM, Darin Fisher da...@chromium.org
mailto:da...@chromium.org wrote:
Yes, exactly. Sorry for not making this clear. I believe implicit
locking for LocalStorage (and the implicit unlocking) is going to
yield
On 6/25/09 11:44 AM, Olli Pettay wrote:
Hi all,
currently 6.11.9 History traversal doesn't seem to handle
nested hashchange events too well.
If there is a fragment id change to A, hashchange is dispatched, then
if the listener changes the fragment to B, there is a new hashchange and
after
On 8/9/09 7:10 PM, Aaron Boodman wrote:
[If this has been discussed before, feel free to just point me there]
I frequently see the comment on this list and in other forums that
something is too late for HTML5, and therefore discussion should be
deferred.
I would like to propose that we get rid
Hi all,
copy-pasting an IRC conversation about session history.
Seems like HTML5 isn't compatible with any implementation.
[22:58] smaug Hixie: ping
[22:58] Hixie hey
[22:59] smaug Hixie: about HTML5's session history
[22:59] Hixie yes
[22:59] smaug I'm trying to understand the Each
Hi,
I wonder what (and where) are the reasons to use XHTML namespace also
with HTML elements.
The behavior causes few issues like
https://bugzilla.mozilla.org/show_bug.cgi?id=501312 and
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6777 and
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7059
Hi all,
currently 6.11.9 History traversal doesn't seem to handle
nested hashchange events too well.
If there is a fragment id change to A, hashchange is dispatched, then
if the listener changes the fragment to B, there is a new hashchange and
after that the page will scroll to B. But the
And it seems like IE scrolls first and then dispatches hashchange events.
On 6/25/09 11:44 AM, Olli Pettay wrote:
Hi all,
currently 6.11.9 History traversal doesn't seem to handle
nested hashchange events too well.
If there is a fragment id change to A, hashchange is dispatched
IE8 seems to fire hashchange asynchronously.
So it fires some time after window.location = somenewvalue; has been
called.
Perhaps asynchronous firing is good enough (and it certainly is easier
to implement safely) and could be added to the spec.
-Olli
On 6/25/09 1:46 PM, Olli Pettay wrote
On 6/24/09 4:42 AM, Ojan Vafai wrote:
SUMMARY
Currently, textareas and text inputs support the oninput event
The event is input ;)
that
fires on all user-initiated modifications to their content. We should
add this event to contentEditable elements as well and add an action
property the
On 6/24/09 6:49 PM, Anne van Kesteren wrote:
On Wed, 24 Jun 2009 12:21:41 +0200, Olli Pettay
olli.pet...@helsinki.fi wrote:
Why would you need paste? There is paste event
(though, not properly specified anywhere, I think);
I'd think you want an event that covers all editing actions. Also
On 11/26/2008 05:35 PM, Calogero Alex Baldacchino wrote:
anyway I think key events handling may
be improved and become easier to adopt by adding to a somewhat interface
a few constants representing the modifiers combination used by the
browser to activate access keys, so those modifiers could be
Hi all,
currently it isn't specified anywhere (AFAIK) what should happen
if the element which has an accesskey attribute is hidden using
display:none.
HTML4 says the following:
Pressing an access key assigned to an element gives focus to the element. The action that occurs when an element
On 11/25/2008 11:17 PM, Calogero Alex Baldacchino wrote:
Maybe, the standard behaviour (for both 'display:none' and
'visibility:hidden') could be just focusing (and changing visibility)
after pressing the access key (so the user notices what's happening
before activating any 'control'), then
On 11/26/2008 12:39 AM, Benjamin Hawkes-Lewis wrote:
Olli Pettay wrote:
Couldn't you style such elements visible with :focus and :active?
What you mean? How do you focus a display:none element?
Good point. You can't. Isn't that a problem in practice? i.e. When do
you want a control to have
Chapter 5.4.4.3. Events and the Window object [1] says that event is
also dispatched to window before (and after) dispatching to DOM
nodes. I'd rather say window object is part of the event target chain
(unfortunately load event is a special case), so events automatically
propagate from document
Peter Michaux wrote:
Using delegate listeners in JavaScript is a technique that has grown
quite popular.
Not sure what you mean here - I may guess it right or wrong.
A minimal example would be always useful.
Not all event types bubble, however, so using pure
delegate solutions is impossible.
100 matches
Mail list logo
