Image.src as resolved by the browser. In IE, Chrome and FF I noted today
(something different than it was a year or so ago) that for content served
from the local drive space (in Windows anyhow), document.images[x].src
resolves to file:///C:/ [path]. In Opera, it still resolves to
On 26.03.2009, at 1:01, Drew Wilson wrote:
* Shared (or persistent) worker contexts should be associated with
an appcache according to the same resource loading and cache
selection logic used for top-level browsing contexts. (So just like
navigating a window.)
That may make sense for
On Thu, Mar 26, 2009 at 3:58 AM, Alexey Proskuryakov a...@webkit.org wrote:
Letting faceless background processes update themselves without user
consent is not necessarily desirable. I think that they need browser UI for
this, and/or associated HTML configuration pages that could (among other
It seems that major browsers all support URL decomposition on
HTMLAnchorElement, but this doesn't seem to be stated anywhere in the HTML5
spec. The jQuery/tabs library seems to depend on this (specifically, on the
hash property) being available. Could the HTMLAnchorElement interface be
updated
Browsers also support partially setting each of the url fields separately,
although error handling between all of them is very inconsistent.
Note: if you specify this behavior, then you need to specify what happens for
http:, https:, data:, mailto: and unknown:
On Thu, 26 Mar 2009 19:32:46
João Eiras wrote:
Browsers also support partially setting each of the url fields separately,
although error handling between all of them is very inconsistent.
Note: if you specify this behavior, then you need to specify what happens for
http:, https:, data:, mailto: and unknown:
If you
On 26.03.2009, at 19:26, Drew Wilson wrote:
Letting faceless background processes update themselves without user
consent is not necessarily desirable. I think that they need browser
UI for this, and/or associated HTML configuration pages that could
(among other duties) trigger application
On Thu, Mar 26, 2009 at 1:19 PM, Alexey Proskuryakov a...@webkit.org wrote:
But I was looking at this in terms of a model for users, not any specific
security threats - if we think of persistent workers as an equivalent of
native applications that need installation, then we should consider
Boris wrote:
If you specify the setters then you also need to specify how this
affects the value of the href attribute in the DOM. For example, in
Gecko if you have an a href=foo#bar which has base URI
http://example.com/; and you set anchor.hash on that anchor to baz,
then the attribute
On Thu, Mar 26, 2009 at 5:26 PM, Kartikaya Gupta
This behavior seems rather inconsistent and possibly buggy.
At first look I also thought it is inconsistent
But later I found Firefox is very consistent.
I think reason why it happening like that is because Firefox clean up
URL by removing extra
I have a poor memory,
hence not good in spelling,
if there is not much gain with a change,
i wish every thing follow a similar pattern
and with short spelling,
which make my life little easier.
On C:\fakepath\ in HTML5 thread Anne mentioned fileList for input
type=file
On Thu, Mar 26, 2009 at 8:26 PM, Biju bijumaill...@gmail.com wrote:
I have a poor memory,
hence not good in spelling,
if there is not much gain with a change,
i wish every thing follow a similar pattern
and with short spelling,
which make my life little easier.
On
12 matches
Mail list logo
