Re: [whatwg] postMessage: max length / size

On Thu, 22 Oct 2009, Brian Kuhn wrote: > > Is there any limit to the length of message you can send with > postMessage (HTML5 Cross-document messaging)? > > I didn't see anything in the spec about this. I thought this might be > one area where implementations might end up differing. There are

[whatwg] postMessage: max length / size

Is there any limit to the length of message you can send with postMessage (HTML5 Cross-document messaging)? I didn't see anything in the spec about this. I thought this might be one area where implementations might end up differing. Thanks, Brian

Re: [whatwg] .tags()

On Thu, Oct 22, 2009 at 5:26 PM, Ian Hickson wrote: > On Mon, 19 Oct 2009, Jonas Sicking wrote: >> >> I've been meaning to send a formal email on this subject, and with the >> recent discussion going on over in the W3C webapps mailing list I >> figured now was a good time. >> >> I'd like to formal

Re: [whatwg] A call for tighter validation standards

On Thu, 22 Oct 2009, Curtiss Grymala wrote: > > 1. Unquoted attributes > 2. Implied tags (such as leaving out a closing paragraph tag) > 3. Inconsistent use of the closing slash on empty elements > > My concern with all three of these points is that they are relying on > the browse

Re: [whatwg] Issues with Web Sockets API

(cc'ing hybi by request, since changes to the WebSocket spec are discussed below) On Thu, 22 Oct 2009, Alexey Proskuryakov wrote: > 17.10.2009, в 3:20, Ian Hickson написал(а): > > > > I'm not really sure what else to say to be honest. Should I just leave > > it at cookies and nothing else? Real

Re: [whatwg] Superset encodings [Re: ISO-8859-* and the C1 control range]

On Wed, 21 Oct 2009, �istein E. Andersen wrote: > > ASCII-compatibility: > The note in �2.1.5 Character encodings� seems to say that �variants of > ISO-2022� (presumably including common ones like ISO-2022-CN, ISO-2022KR and > ISO-2022-JP) are ASCII-compatible, whereas HZ-GB-2312 is not, and I can

[whatwg] A call for tighter validation standards

Much of what I wanted to discuss was discussed rather elegantly within a post from August 2009 (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021725.html) on this mailing list, but I would like to take it a step further. Henri Sivonen made some very valid points within that post

Re: [whatwg] Only allow md5WithRSAEncryption with ?

On Wed, 21 Oct 2009, Adam Roben wrote: > > HTML5 currently says that the signature algorithm used with keytype=rsa> should be any of "those listed in section 2.2.1 ('RSA > Signature Algorithm') of RFC 3279." > > However, both WebKit and Gecko only ever use the md5WithRSAEncryption > signature a

Re: [whatwg] Drop event on form controls

On Wed, 21 Oct 2009, Olli Pettay wrote: > > 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

Re: [whatwg] Issue on drag & drop example in specification?

On Wed, 21 Oct 2009, Shumpei Shiraishi wrote: > > > > > > > > ul, li { > -webkit-user-drag: element; > } > > > function onDragStart(event) { > if (event.target.tagName.toLowerCase() == "li") { > var dt = event.dataTransfer; > dt.dropEffect = "copy"; > dt.setData("listItemId",

Re: [whatwg] noreferrer link relation clarifications

On Tue, 20 Oct 2009, Nate Chapin wrote: > > I was wondering if I could get some clarification about a couple things in > the specification of the noreferrer link relation: > 1. Is it the intent for the opener attribute to potentially be non-null > when a hyperlink does not create a new browsing co

Re: [whatwg] .tags()

On Mon, 19 Oct 2009, Jonas Sicking wrote: > > I've been meaning to send a formal email on this subject, and with the > recent discussion going on over in the W3C webapps mailing list I > figured now was a good time. > > I'd like to formally request that .tags() is removed from the > HTMLCollec

Re: [whatwg] Superset encodings [Re: ISO-8859-* and the C1 control range]

On 22 Oct 2009, at 22:45, Philip Taylor wrote: On Thu, Oct 22, 2009 at 9:23 PM, Øistein E. Andersen wrote: On 22 Oct 2009, at 17:15, NARUSE, Yui wrote: Finally, Why ISO 2022 series is discouraged is not clear. We agree on this point. The string "숍訊昱穿" encoded as ISO-2022-KR is the bytes 0e 3

Re: [whatwg] Superset encodings [Re: ISO-8859-* and the C1 control range]

On Thu, Oct 22, 2009 at 9:23 PM, Øistein E. Andersen wrote: > On 22 Oct 2009, at 17:15, NARUSE, Yui wrote: > >> Finally, Why ISO 2022 series is discouraged is not clear. > > We agree on this point. The string "숍訊昱穿" encoded as ISO-2022-KR is the bytes 0e 3c 73 63 72 69 70 74 3e. A UA that doesn'

Re: [whatwg] Superset encodings [Re: ISO-8859-* and the C1 control range]

Øistein E. Andersen wrote: > On 22 Oct 2009, at 17:15, NARUSE, Yui wrote: > >> First, JIS-X-0208 and JIS-X-0212 are not in IANA Charsets, > > I am not sure what you mean; they are both listed at > : > > Name: JIS_C6226-1983

Re: [whatwg] Superset encodings [Re: ISO-8859-* and the C1 control range]

On 22 Oct 2009, at 17:15, NARUSE, Yui wrote: First, JIS-X-0208 and JIS-X-0212 are not in IANA Charsets, I am not sure what you mean; they are both listed at : Name: JIS_C6226-1983 [RFC1345,KXS2] MIBenum: 63 So

Re: [whatwg] Issues with Web Sockets API

17.10.2009, в 3:20, Ian Hickson написал(а): I'm not really sure what else to say to be honest. Should I just leave it at cookies and nothing else? Really I just want to support Basic (and I guess Digest) authentication (primarily for over-TLS connections), so that sites that use Basic auth

Re: [whatwg] Superset encodings [Re: ISO-8859-* and the C1 control range]

Øistein E. Andersen wrote: >> Discouraged encodings: >> ‘4.2.5.5 Specifying the document's character encoding’ advises against >> certain encodings. (Incidentally, this advice probably deserves not >> to be ‘hidden’ in a section nominally reserved for character encoding >> *declaration* issues.)

Re: [whatwg]

On Thu, Oct 22, 2009 at 9:47 AM, Daniel Glazman wrote: > Tab Atkins Jr. wrote: > >> I actually consider that a loss.  It's addressing a different problem, >> you see.  HTMLOverlays is basically client-side includes.  While you > > It's client-side only because I implemented in JS that way! Explain

Re: [whatwg]

Tab Atkins Jr. wrote: I actually consider that a loss. It's addressing a different problem, you see. HTMLOverlays is basically client-side includes. While you It's client-side only because I implemented in JS that way! Explain me what prevents from implementing server-side? I think you m

Re: [whatwg]

On Thu, Oct 22, 2009 at 1:56 AM, Daniel Glazman wrote: > Hi there, > > That onlyreplace attribute is not enough, and trust me, I have > spent quite a while on solutions transforming HTML documents using > bits contained in external instances... > > Hixie referenced at some point in the thread my H

Re: [whatwg] behavior

On Thu, 22 Oct 2009 08:23:33 -0400, Ian Hickson wrote: On Sun, 18 Oct 2009, Michael A. Puls II wrote: However, if I use createDocument() to create an HTMLDocument and then append an HTMLObjectElement to that document, the plug-in shouldn't load as the document is not active/has no browsing co

Re: [whatwg] behavior

On Sun, 18 Oct 2009, Michael A. Puls II wrote: > > However, if I use createDocument() to create an HTMLDocument and then > append an HTMLObjectElement to that document, the plug-in shouldn't load > as the document is not active/has no browsing context or something. Good point. Fixed. -- Ian Hi

Re: [whatwg]

Markus Ernst wrote: They are crucially different in some points: - HTMLOverlays is a ready-to-use script solution. It does not require any specification nor implementation by UAs. Instead, it requires work on the authoring side; using HTMLOverlays means totally re-writing your websites. It'

Re: [whatwg]

Looking at this (simplified) example from Markus: My title Text Would it be better to be able to specify multiple onlyload base elements? Like so: My title Replace the title

Re: [whatwg]

Daniel Glazman schrieb: > Hi there, > > That onlyreplace attribute is not enough, and trust me, I have > spent quite a while on solutions transforming HTML documents using > bits contained in external instances... > > Hixie referenced at some point in the thread my HTMLOverlays proposal > [1] and