Re: [whatwg] Requiring the Encoding Standard preferred name is too strict for no good reason
2013/8/1 Ian Hickson : > On Thu, 1 Aug 2013, Martin Janecke wrote: >> >> I don't see any sense in making a document that is declared as >> ISO-8859-1 and encoded as ISO-8859-1 non-conforming. Just because the >> ISO-8859-1 code points are a subset of windows-1252? So is US-ASCII. >> Should an US-ASCII declaration also be non-conforming then -- even if >> the document only contains bytes from the US-ASCII range? What's the >> benefit? >> >> I assume this is supposed to be helpful in some way, but to me it just >> seems wrong and confusing. > > If you avoid the bytes that are different in ISO-8859-1 and Win1252, the > spec now allows you to use either label. (As well as "cp1252", "cp819", > "ibm819", "l1", "latin1", "x-cp1252", etc.) > > The part that I find problematic is that if you use use byte 0x85 from > Windows 1252 (U+2026 "…" HORIZONTAL ELLIPSIS), and then label the document > as "ansi_x3.4-1968", "ascii", "iso-8859-1", "iso-ir-100", "iso8859-1", > "iso_8859-1:1987", "us-ascii", or a number of other options, it'll still > be valid, and it'll work exactly as if you'd labeled it "windows-1252". > This despite the fact that in ASCII and in ISO-8859-1, byte 0x85 does not > hap to U+2026. It maps to U+0085 in 8859-1, and it is undefined in ASCII > (since ASCII is a 7 bit encoding). ISO-8859-1 vs. Windows-1252 issue sounds little issue because 0x85 is Next Line. As far as I know 0x85/U+0085 is used only in some IBM system. For Japanese encoding, there's Shift_JIS vs. Windows-31J issue, which people long annoyed. Windows-31J has many new characters which aren't included in Shift_JIS, and many different Unicode mappings from Shift_JIS. But many existing Web pages specify "Shift_JIS" and uses characters only in Windows-31J. Therefore if people want to specify a document as truly Shift_JIS, there's no way on the existing framework. It needs a new way for example a new meta specifier like and browser recognize the document's encoding as true Shift_JIS. But such people should use UTF-8 instead of introducing such new one. -- NARUSE, Yui
Re: [whatwg] Parsing the string
On Sat, Aug 3, 2013 at 1:29 AM, Mohammad Al Houssami (Alumni) wrote: > If you go to http://livedom.validator.nu/ and try to add the DOM tree > shows the head and body elements. I am using this as a reference to compare > to my results. Its not reliable then? I... don't understand what you're asking. As we keep explaining, *that's the intended behavior*. ~TJ
Re: [whatwg] Disabling document.domain setting on iframe@sandbox (especially with allow-same-origin)
Le 03/08/2013 16:02, Boris Zbarsky a écrit : On 8/3/13 9:48 AM, David Bruant wrote: "a.example.org" can sandbox the iframe to "b.example.org" and process isolation becomes possible again Yes, agreed. This might be a good idea. It just has nothing to do with protecting one from attacks by the other in general, because they can use window.open and loads... Yes yes, that's only for iframe isolation, not "any-frame" isolation, but I feel it already gets a long way. As a developer, I'm dreaming of a world (10 years from now? :-/) where an iframe would be a WebWorker with a UI. That would make ideas like CanvasProxy [1] (transferable part of a canvas for off-main-thread drawing) obselete. What I'm suggesting is the following: poison the document.domain setter in sandboxed iframes regardless of whether there is allow-same-origin. I like it, yes. Awesome! Looking forward to other browser vendors opinion! The only case this doesn't allow to optimize is "a.example.org" with an iframe to "example.org", where "a.example.org" might set document.domain to "example.org". It doesn't matter, because _both_ have to set document.domain. oh ok. I guess I misunderstood the spec after all, but that supports the idea of poisonning the document.domain setter, yay! David [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#canvasproxy
Re: [whatwg] Disabling document.domain setting on iframe@sandbox (especially with allow-same-origin)
On 8/3/13 9:48 AM, David Bruant wrote: "a.example.org" can sandbox the iframe to "b.example.org" and process isolation becomes possible again Yes, agreed. This might be a good idea. It just has nothing to do with protecting one from attacks by the other in general, because they can use window.open and loads... What I'm suggesting is the following: poison the document.domain setter in sandboxed iframes regardless of whether there is allow-same-origin. I like it, yes. The only case this doesn't allow to optimize is "a.example.org" with an iframe to "example.org", where "a.example.org" might set document.domain to "example.org". It doesn't matter, because _both_ have to set document.domain. As in, a.example.org setting .domain to "example.org" does not make it same-origin with example.org unless the latter also explicitly sets .domain to "example.org". Which we would disallow in sandboxed iframes. -Boris
Re: [whatwg] Disabling document.domain setting on iframe@sandbox (especially with allow-same-origin)
Le 03/08/2013 03:03, Boris Zbarsky a écrit : On 8/2/13 6:44 PM, David Bruant wrote: And apparently @sandbox doesn't help here if there is allow-same-origin. So here is an idea: make the document.domain setter throw inside an iframe@sandbox, *regardless* of allow-same-origin. That solves the mail.google.com VS calendar.google.com case. How exactly does it solve it? How is @sandbox even relevant here? (feeling this might be again an instance of me misunderstanding the spec. sigh. sorry about that if that's the case) I mistakenly wrote "VS" giving the impression that this is a security oriented thread, but that's not what I meant. Sorry for the mislead. I was following up on the iframe process isolation idea. document.domain requires opt-on on both sides Indeed and that's the reason what I describe works I believe. Let's say we have pages from 2 domains "a.example.org" and "b.example.org". One has an iframe to the other. iframe process isolation is not possible, because at any point, both could set their domains to "example.org" (or process isolation is possible, but the deoptimization would have a violent cost) "a.example.org" can sandbox the iframe to "b.example.org" and process isolation becomes possible again, because the parent and iframe are guaranteed to be of a different origin. However, this looses the origin of the iframe which breaks localstorage, etc. This can be solved with allow-same-origin, but process isolation is lost back because we're pretty much back in the previous case. What I'm suggesting is the following: poison the document.domain setter in sandboxed iframes regardless of whether there is allow-same-origin. This way, in the "a.example.org"/"b.example.org" case, the iframe can be process isolated (because guaranteed to be of a different origin). This also applies to "example.org" with a "b.example.org" iframe. The only case this doesn't allow to optimize is "a.example.org" with an iframe to "example.org", where "a.example.org" might set document.domain to "example.org". David
Re: [whatwg] Parsing the string
If you go to http://livedom.validator.nu/ and try to add the DOM tree shows the head and body elements. I am using this as a reference to compare to my results. Its not reliable then? Thank you -Original Message- From: Tab Atkins Jr. [mailto:jackalm...@gmail.com] Sent: Saturday, August 03, 2013 1:18 AM To: Mohammad Al Houssami (Alumni) Cc: Ian Hickson; wha...@whatwg.org Subject: Re: [whatwg] Parsing the string On Fri, Aug 2, 2013 at 5:08 PM, Mohammad Al Houssami (Alumni) wrote: > That is totally correct. But are the head and body elements added to the > document? So basically when we stop parsing the document should only have the > html element is that correct? No, the spec clearly says "Insert an HTML element..." for those as you trace through the parsing. ~TJ
