Re: [whatwg] TCPConnection feedback

I think a major problem with raw TCP connections is that they would be the nightmare of every administrator. If web pages could use every sort of homebrew protocol on all possible ports, how could you still sensibly configure a firewall without the danger of accidentally disabling mary sue grand

Re: [whatwg] Implementation of a good HTTPSocket (TCP-socket)

On Thu, Jun 19, 2008 at 12:46 AM, Frode Børli <[EMAIL PROTECTED]> wrote: > Web pages should only be allowed to access other servers when the > script has been digitally signed, and when the user has agreed to > giving the script elevated privileges - or there should be a > certificate on the origi

[whatwg] Suggestion of an alternative TCPConnection implementation

> I think a major problem with raw TCP connections is that they would be > the nightmare of every administrator. If web pages could use every > sort of homebrew protocol on all possible ports, how could you still > sensibly configure a firewall without the danger of accidentally > disabling mary su

Re: [whatwg] more drag/drop feedback

On Wed, Jun 18, 2008 at 4:46 PM, Neil Deakin wrote: > The initDragEvent/initDragEvent methods take a DataTransfer as an argument. > Is it expected that the DataTransfer to use here can be created with 'new > DataTransfer'? > > IE and Safari allow a no-argument form of clearData as well which clears

Re: [whatwg] Making it possible to do an anchor link to any DOM node

Lukas Kahwe Smith wrote: Hi, Currently when linking to specific places in a document one is limited to the places the original author made linkable via an anchor tag. While this is a nice touch (though not well exposed by modern browsers), the reality is that most of the time the person who

[whatwg] TCPConnection feedback

> Still I do not believe it should have a specific protocol. I think a major problem with raw TCP connections is that they would be the nightmare of every administrator. If web pages could use every sort of homebrew protocol on all possible ports, how could you still sensibly configure a firewall

Re: [whatwg] TCPConnection feedback

On Wed, 18 Jun 2008, Frode Børli wrote: > > Still I do not believe it should have a specific protocol. If a protocol > is decided on, and it is allowed to connect to any IP-address - then > DDOS attacks can still be performed: If one million web browsers connect > to any port on a single server

Re: [whatwg] TCPConnection feedback

> Still I do not believe it should have a specific protocol. If a > protocol is decided on, and it is allowed to connect to any IP-address > - then DDOS attacks can still be performed: If one million web > browsers connect to any port on a single server, it does not matter > which protocol the clie

Re: [whatwg] TCPConnection feedback

>> The protocol should not require any data (not even hello - it should >> function as an ordinary TCPConnection similar to implementations in >> java, c# or any other major programming language. If not, it should be >> called something else - as it is not a TCP connection. >> I agree completely.

Re: [whatwg] Making it possible to do an anchor link to any DOM node

On Wed, 18 Jun 2008, Lukas Kahwe Smith wrote: > > So I think it should be possible to "dynamically" get an implicit anchor > on essentially anything. This would be specific DOM id's or any css > selector or xpath expression. Browsers could be extended to not only > feature a "copy link" context

Re: [whatwg] TCPConnection feedback

On Wed, Jun 18, 2008 at 12:59 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > On Wed, 18 Jun 2008, Michael Carter wrote: > > > > In that case I agree that the name shouldn't be TCPConnection. I propose > > SocketConnection instead. > > I was thinking WebSocket (with the protocol itself called the Web

[whatwg] Making it possible to do an anchor link to any DOM node

Hi, Currently when linking to specific places in a document one is limited to the places the original author made linkable via an anchor tag. While this is a nice touch (though not well exposed by modern browsers), the reality is that most of the time the person who writes a document tha

Re: [whatwg] TCPConnection feedback

On Wed, 18 Jun 2008, Michael Carter wrote: > > In that case I agree that the name shouldn't be TCPConnection. I propose > SocketConnection instead. I was thinking WebSocket (with the protocol itself called the Web Socket Protocol or Web Socket Communication Protocol or some such). -- Ian Hick

Re: [whatwg] TCPConnection feedback

> > The protocol should not require any data (not even hello - it should > function as an ordinary TCPConnection similar to implementations in > java, c# or any other major programming language. If not, it should be > called something else - as it is not a TCP connection. > > > > I agree completel

Re: [whatwg] Creating An Outline oddity

On 15 Jun 2008, at 04:06, Ian Hickson wrote: On Sun, 15 Jun 2008, Geoffrey Sneddon wrote: Having implemented the creating an outline algorithm (see ), I'm getting some odd results (the only TODO won't affect HTML 4.01 documents such as the following issues). Using

[whatwg] more drag/drop feedback

The initDragEvent/initDragEvent methods take a DataTransfer as an argument. Is it expected that the DataTransfer to use here can be created with 'new DataTransfer'? IE and Safari allow a no-argument form of clearData as well which clears all formats. The description for the 'types' property

[whatwg] Any "other" end tag in after head

After head talks about any "other" end tag, but has no definitions for end tags but "other". Is that intentional? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/

Re: [whatwg] TCPConnection feedback

Frode Børli wrote: XMLHttpRequest only allows connections to the origin server ip of the script that created the object. If a TCPConnection is supposed to be able to connect to other services, then some sort of mechanism must be implemented so that the targeted web server must perform some sort

[whatwg] vtab as an NCR expansion

Is it intentional that the vtab change didn't cause a change to vtab treatment when expanding NCRs? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/

Re: [whatwg] Javascript API to query supported codecs for and

On Jun 18, 2008, at 13:34, Philip Jägenstedt wrote: Implementation-wise it might be less than trivial to return an exhaustive list of all supported mime-types if the underlying framework doesn't use the concept of mime-types, but can say when given a few bytes of the file whether it supports

Re: [whatwg] Javascript API to query supported codecs for and

On Wed, 2008-06-18 at 17:38 +0700, Philip Jägenstedt wrote: > Implementation-wise it might be less than trivial to return an > exhaustive list of all supported mime-types if the underlying framework > doesn't use the concept of mime-types, but can say when given a few > bytes of the file whether it

Re: [whatwg] Javascript API to query supported codecs for and

The spec clearly says the following http://www.whatwg.org/specs/web-apps/current-work/#video1 "User agents should not show this content to the user; it is intended for older Web browsers which do not support video," Although we fully understand the reasoning behind this, there's an use case missin

Re: [whatwg] Javascript API to query supported codecs for and

Sorry, my reply was cut short. Again: It seems to me that it's a good idea to wait with this until we know more about what will happen with baseline codecs etc. Implementation-wise it might be less than trivial to return an exhaustive list of all supported mime-types if the underlying framework d

Re: [whatwg] TCPConnection feedback

> without informing the user. This would allow a popular page (say a facebook > profile or banner ad) to perform massive DOS against web servers using > visitors browsers without any noticeable feedback (though I guess this is > also true of current HTTPXMLRequestObjects). XMLHttpRequest only allo

Re: [whatwg] Javascript API to query supported codecs for and

It seems to me that it's a good idea to wait with this until we know more about what will happen with baseline codecs etc. Implementation-wise it might be less than trivial to return an exhaustive list of all supported mime-types if the underlying framework doesn't use the concept of mime-types, bu

Re: [whatwg] Javascript API to query supported codecs for and

On Wed, 2008-06-18 at 12:03 +0200, Anne van Kesteren wrote: > Why is that needed? The elements provide a way to link to multiple codecs > of which the user agent will then make a choice. i do not intend to provide multiple codecs since that would require multiple backend implementations for pla

Re: [whatwg] Javascript API to query supported codecs for and

On Wed, 18 Jun 2008 12:01:13 +0200, <[EMAIL PROTECTED]> wrote: as it looks like there will not be a common base codec any time soon, there is a need to be able to detect the supported codecs in javascript. are there any plans to provide such an interface or is this already possible? Why is that

[whatwg] Javascript API to query supported codecs for and

Hi, as it looks like there will not be a common base codec any time soon, there is a need to be able to detect the supported codecs in javascript. are there any plans to provide such an interface or is this already possible? j

Re: [whatwg] Sandboxing to accommodate user generated content.

Let’s sort things out, folks. There is nothing in the spec to prevent a browser vendor to format the user’s hard drive and to drain her bank account as a bonus when the page displayed contains the string "D357R0Y!N0\V!". The spec does not tell the vendors what not to do, therefore it cannot guara

Re: [whatwg] Sandboxing to accommodate user generated content.

Frode Børli wrote: >>> I have been reading up on past discussions on sandboxing content, and >>> >>> My main arguments for having this feature (in one form or another) in >>> the browser is: >>> >>> - It is future proof. Changes to browsers (for example adding >>> expression support to css) will ne