On Tue, Jul 29, 2008 at 8:02 AM, Dave Singer [EMAIL PROTECTED] wrote:
c) that the contents of the container, once fetched and un-packed,
logically 'shadow' the directory where the container came from.
It sounds like that affects all loads, which leads to issues:
So if I load
On Tue, Jul 29, 2008 at 6:21 AM, Kristof Zelechovski
[EMAIL PROTECTED]wrote:
My complaint was about how the jar URL scheme wannabe conceptually
differs from the schemes we already officially have, not about how ugly it
is to have two consecutive colons. It is ugly but it does not matter.
Archive: is not generic enough but perhaps you could bend the URL notation
to embrace something like inside:. I still would not recommend it but it
would not make me that sore.
How about inside:local/path.html?container=http://www.site.com/app.jar?
The user agent would be required to append a
I think that just puts some restrictions on the arrangement on the server.
My guess is that once a resource is shadowed, it becomes invisible, and the
server should not serve resources that might be shadowed unless the
publisher knows what she is doing. It is not the only way to make a site
On Jul 27, 2008, at 12:06 PM, Eric Butler wrote:
It would seem Safari isn't quite following the spec here, since it
appears to never draw shadows when the shadow color is fully
transparent or something and doesn't encounter these issues. I'm not
sure that should be the correct behavior
On Fri, 4 May 2007, Henri Sivonen wrote:
Re: http://krijnhoetmer.nl/irc-logs/whatwg/20070503
First, I hope that we are in agreement that the following are realities:
* Browsers will have to support style='' on every element.
Yes.
* When you make something a critical mass of authors
(I'm replying only to the more salient e-mails in this thread, as the
others mostly just repeated stuff. I'm also only cc'ing whatwg, since that
seems to be where most of the contributors on this thread were subscribed
to -- please don't cross-post, as it results in threads that appears to be
On Jul 29, 2008, at 3:56 AM, Oliver Hunt wrote:
On Jul 27, 2008, at 12:06 PM, Eric Butler wrote:
It would seem Safari isn't quite following the spec here, since it
appears to never draw shadows when the shadow color is fully
transparent or something and doesn't encounter these issues.
So if I load
http://www.example.com/x.m21#y.htmlhttp://www.example.com/x.m21#y.html*q and
(in the same document, or in another tab?) load
http://www.example.com/z.html, and x.m21 contains a z.html but the server
also responds to http://example.com/z.html, does the second load (z.html)
come
On Sun, Jul 27, 2008 at 8:06 PM, Eric Butler [EMAIL PROTECTED] wrote:
[...]
However, following the spec's drawing model, there are a few operators that
behave rather unexpectedly if the shadow color is left at its default value.
For instance, since A in B always results in transparency if
Ian Hickson wrote:
On Fri, 25 Jul 2008, Jonas Sicking wrote:
So what I think we should do is to enforce that 'data' is a JSON
serializable object.
(We need a better term -- and definition -- for this.)
I'll check with the ECMA Script folks, but this one might be an
alternative to link to:
On Tue, Jul 29, 2008 at 5:59 AM, Russell Leggett
[EMAIL PROTECTED]wrote:
Yes, the one major hang up that I foresee is how a browser should handle
asynchronous loading. How would it know the contents of the archive before
it loaded the archive so it did not try to load the same files directly?
At 19:51 +1200 29/07/08, Robert O'Callahan wrote:
On Tue, Jul 29, 2008 at 8:02 AM, Dave Singer
mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote:
c) that the contents of the container, once fetched and un-packed,
logically 'shadow' the directory where the container came from.
It sounds
On Tue, Jul 29, 2008 at 2:52 AM, Kristof Zelechovski
[EMAIL PROTECTED]wrote:
Archive: is not generic enough but perhaps you could bend the URL
notation to embrace something like inside:. I still would not recommend it
but it would not make me that sore.
How about
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
I am not sure where it is relevant but I remember from learning Borland
Paradox that events are dispatched to window first so that the window can
intercept them universally and then they bubble bottom up if not
intercepted. This feature is called global grab (if the window decides to
handle the
On Tue, 29 Jul 2008, Jonas Sicking wrote:
I'll check with the ECMA Script folks, but this one might be an
alternative to link to:
http://wiki.ecmascript.org/doku.php?id=es3.1:json_support
State that the object passed as 'data' is passed to JSON.parse with the
second argument not
On Tue, 20 Mar 2007, Hallvord R M Steen wrote:
when a new window or tab is opened by a page it normally has a
window.opener property that points to the window object of the
original tab.
Indeed, this is now specced.
If an origin check fails when comparing the locations of the old window
On Thu, 7 Feb 2008, Hallvord R M Steen wrote:
Adam Barth and Collin Jackson pointed out to me that while investigating
frame navigation policies they found that a recipient of a postMessage
in Opera can set event.source.location, thus navigate the sender
window/document. I think this is a
On 22 May 2008, at 12:40, Ian Hickson wrote:
would you say that what the spec says now is what browsers
implement? What should we change?
The current table seems to cover the mappings between different common
compatible 8-bit encodings as implemented in IE7, yes. The table at
That is a performance killer.
I don't think it is as much of a performance killer as you say it is.
Correct me if I'm wrong, but the standard connection limit is two. It is not
as though every external file could be loaded at once. Additionally, as I
said, you could split resources into
The situation is a lot better for archives (like MPEG-21 files) that
have a directory at the front...
At 20:10 -0400 29/07/08, Russell Leggett wrote:
That is a performance killer.
I don't think it is as much of a performance killer as you say it
is. Correct me if I'm wrong, but the
On Tue, 29 Apr 2008, Adam Barth wrote:
A couple points about Section 4.1.4:
1) The spec, as written, prohibits frame-busting.
Test case: http://crypto.stanford.edu/~abarth/research/html5/frame-busting/
Browser behavior:
* Internet Explorer 8 beta: Navigation allowed.
* Firefox 3
On Tue, 20 Mar 2007, ddailey wrote:
I sometimes enjoy the ability to clone images that have no src or no
width or no style. I certainly like to vary the height and width
attributes via setAttribute, and I might like, in the future, to be able
to attach an animate tag (ala SMIL) to the
On Wed, 21 Mar 2007, Henri Sivonen wrote:
On Mar 3, 2007, at 21:58, Ian Hickson wrote:
The question isn't whether or not you should have the ability to scale
images; it's clear that this is desirable. The question is whether it
makes sense to put this in HTML as opposed to CSS. Why
On Tue, 20 Mar 2007, Nicholas Shanks wrote:
I asked for the resurrection of HTML+'s imagefallback/image element
last month. The reasons I cited were exactly the same as the reasons
being given now in favour of the video element, however I was told
(paraphrasing) Why bother, you can just
On Sat, 13 Oct 2007, Henri Sivonen wrote:
On Oct 13, 2007, at 01:55, Ian Hickson wrote:
On Tue, 7 Nov 2006, Henri Sivonen wrote:
So I think width and height should not have conformance requirements
tied to pixel dimensions of the references image file. They are
presentational, but
On Sun, 14 Oct 2007, Matthew Paul Thomas wrote:
On Oct 14, 2007, at 2:03 AM, Henri Sivonen wrote:
I don't think If both attributes are specified, then the ratio of the
specified width to the specified height must be the same as the ratio
of the logical width to the logical height in the
On Fri, 14 Dec 2007, Christoph P�per wrote:
PS: What format for animated truecolor (alpha-channeled) bitmap images
should HTML5 recommend ('should') or require ('must')? ;)
Are there any formats worth talking about other than APNG here? Do we need
to explicitly talk about APNG here? Seems
On Tue, Jul 29, 2008 at 11:20 AM, Dave Singer [EMAIL PROTECTED] wrote:
Caching is on a full URL basis, of course. Once that is decided, then yes,
I think that pre-cached items for a given URL are in the general cache for
that site.
A site that uses this feature is likely to be fragile. It
30 matches
Mail list logo
