Re: [whatwg] Zip archives as first-class citizens
On Wed, Aug 28, 2013 at 9:20 AM, Jonas Sicking wrote: > On Wed, Aug 28, 2013 at 8:04 AM, Boris Zbarsky wrote: > > On 8/28/13 9:32 AM, Anne van Kesteren wrote: > >> > >> I'm not sure we need to consider sub-scheme if zip-path can work as > >> it's more complex and not very well thought out. E.g. imagine > >> view-source:zip:http://www.example.org/zip!test.html. > > > > > > What's the issue with that? Gecko supports that (with jar:, not zip:), > > fwiw. > > I have two concerns with the scheme-based approach. > > * It dramatically complicates origin handling. This is something we've > seen multiple times in gecko and something that I expect authors will > struggle with too. > > * It makes it impossible to have create a relative URL from inside the > zip file to refer to something on the same server but outside of the > zip file. Since anything outside of the zip file uses a different > scheme, it means that you have to use an absolute URL. Not even URLs > starting with "/" nor "//" can be used. Apologies for being late to the thread. Just wanted to agree with both of these points. This only seems valuable to me if we can do it in the context of http(s)://. > > 3) We have implementation experience with the "sub-scheme" approach and > we > > know it can work just fine (existence proof is jar: in Gecko). The main > > difficulty it introduces is that computing the origin needs to be done > via > > object accessors, not string-parsing... Do we have any implementation > > experience with "zip-path"-like approaches? > > I don't know about "can work just fine". Sure, if everyone does the > right thing, then it works. But we're having to strictly enforce that > no one does string parsing by hand and instead use URL objects and > Principal objects. Neither of which really are an option on the web > right now as all URL-related APIs use strings. > > > I don't think relative URIs should ever escape a zip archive (though I do > > appreciate the way that would let someone replace directories with > zipped-up > > versions of those directories). The reason for that is that allowing it > > sometimes but not others seems really weird to me, and it seems like we > > don't want to allow it for toplevel zip archives. > > Why not? > > / Jonas >
Re: [whatwg] Alignment of empty buttons
On 9/4/13 8:07 PM, Ian Hickson wrote: As far as I can tell, browsers keep treating it as an inline-block box in those cases. OK, that works, I guess. That does mean that buttons are a replaced element, clearly, though... Something needs to spell that out. -Boris
Re: [whatwg] Alignment of empty buttons
On Fri, 12 Jul 2013, Boris Zbarsky wrote: > On 7/12/13 4:08 PM, Ian Hickson wrote: > > The HTML spec is pretty explicit about it not being: > > > > # When the button binding applies to a button element, the element is > > # expected to render as an 'inline-block' box rendered as a button whose > > # contents are the contents of the element. > > -- http://www.whatwg.org/specs/web-apps/current-work/#the-button-element-0 > > Hmm. Is that compatible with the sizing of absolutely positioned > buttons with "left:0; right: 0"? > > For that matter, what happens to buttons if their display style is > changed (e.g. to block)? As far as I can tell, browsers keep treating it as an inline-block box in those cases. Do you have a specific case in mind that isn't handled that way? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] scrdoc and session history don't play along in the spec
On Fri, 12 Jul 2013, Boris Zbarsky wrote: > On 7/12/13 3:39 PM, Ian Hickson wrote: > > That wasn't the intent. I've tried to clarify it. > > Hmm. It might help to make it clearer in > http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate > > that "new resource" does not mean "URL". Maybe have some explicit thing > that represents the resource being navigated to (which might, for > example, consist of a (url, srcdoc data) pair or something along those > lines)? Yeah... I've thought about doing something like this several times (this is by far not the only part of the spec with this issue -- the word "resource" is in the spec over a thousand times). Fundamentally I'm not really sure what to do to define "resource" in a useful way here and elsewhere. I've added a note before the navigation algorithm, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Challenging canvas.supportsContext
On 4 Sep 2013, at 10:47 am, Boris Zbarsky wrote: > On 9/3/13 7:13 PM, Ian Hickson wrote: >> Wouldn't checking for window.WebGLRenderingContext be just as unreliable >> then? I don't understand why it's ok to be able to test that, but why >> probablySupportsContext() wouldn't be ok. > > I'm a lot more OK with the "probablySupportsContext" naming than > "supportsContext" here. I will update WebKit to probablySupportsContext asap. Dean
Re: [whatwg] Default draggable elements
On Thu, 11 Jul 2013, Daniel Cheng wrote: > Regarding elements that are draggable by default: > The spec says: > > img elements and a elements with an href attribute have their > > draggable attribute set to true by default. > > I've noticed that in IE and Firefox, an tag embedding an image > also defaults to draggable. It does not default to draggable in > Blink/WebKit. Should the spec be amended to include this special case? Seems reasonable. Done. > Blink/WebKit also make input[image] elements default to draggable (no > other browser does this). I'm not really sure why, but can I confirm > that this won't be in the spec? I'd like to remove it from Blink at > least. Yeah, that seems bad since it's an interactive widget. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Cross-Origin Cookies Sharing Proposal
On Fri, 21 Jun 2013, Huan Du wrote: > > As privacy awareness becomes prevelant, the trend is that future > browsers are going to ban third-party Cookies by default. > > This is a good thing for users, but for giant internet companies, this > has no doubt increases the difficult and complexity of implementing user > session synchronization. > > Is it possible to, like Cross-Origin Resource Sharing, allow a site to > indicate which domains it would like to share Cookies with? Why would a user be ok with sharing cookies with these sites if they're not ok with sharing them otherwise? I don't really understand what the user threat model is here. On Fri, 21 Jun 2013, Nils Dagsson Moskopp wrote: > > I have a suspicion that the only thing that cannot be done easily > without cookies is tracking – that is, pretending that a user has an > account, but ensuring that she has not made that choice consciously. That's pretty easy to do even without cookies or other storage mechanisms. You can fingerprint a user pretty precisely. On Sat, 22 Jun 2013, Huan Du wrote: > > There are 3 web sites in Alibaba at least: taobao.com, tmall.com, > etao.com. all of them are using a same account management system > including Sign up, Sign in. > > The requirement is simple for the account management system. when user A > signed in taobao.com, we expect A is signed in tmall.com and etao.com. Right. There are lots of cases such as this where third-party cookies (or a similar mechanism) are an integral part of the experience. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Structured Clone of Map and Set objects
On Wed, Sep 4, 2013 at 7:56 PM, Oliver Hunt wrote: > The current structured clone algorithm does not include support for the Map > and Set types, so a developer would need to manually implement the > serialisation and deserialisation. While this would not be impossible it > does seem like it is an unnecessary inconvenience for a core type in ES6. I suggested this to TC39 a while back and I still think it's a good idea even though reception was lukewarm at best (the people replying didn't like to acknowledge the existence of this seemed like). They should define this as a primitive of the Object type and define which objects support it and how. The monkey patching we do now is not great. -- http://annevankesteren.nl/
[whatwg] Structured Clone of Map and Set objects
The current structured clone algorithm does not include support for the Map and Set types, so a developer would need to manually implement the serialisation and deserialisation. While this would not be impossible it does seem like it is an unnecessary inconvenience for a core type in ES6. The semantics of Map and Set are stable so unless someone objects i see no reason we should not amend the internal structured clone algorithm to specially handle Set and Map in addition to Array. To support cloning of Map and Set we will want to recursively call the structured clone algorithm on each key or key/value pair in the %SetData% or %MapData% internal arrays, and maintain the order of those entries (as the Map/Set ordering is well defined) --Oliver
Re: [whatwg] Prioritizing subresources (Was Script preloading)
On Sep 3, 2013, at 11:06 PM, William Chan (陈智昌) wrote: > On Sep 3, 2013 8:00 PM, "Ryosuke Niwa" wrote: > > > > On Sep 3, 2013, at 5:01 PM, William Chan (陈智昌) > > wrote: > > > > > Hello folks. Sorry for the late response to several comments in this > > > mega-thread, I've mostly been traveling/vacationing for the past 2 months. > > > A teammate asked me to look at this in case I had comments. I don't know > > > web dev issues very well, so I'm going to restrain myself from offering > > > many opinions about the new proposals other than wow, all this dependency > > > stuff looks complicated, but maybe it's worth it? I'll keep to some > > > observations from a networking performance perspective, in case it's > > > relevant to the discussion: > > > > > > * Any advantages the preloader currently gives is probably only going to > > > be > > > magnified with HTTP/2. Browsers today will in key situations hold back > > > lower priority resource loads, even after the resource has been discovered > > > by the parser/preloader, in order to reduce network contention and > > > prioritize resources. But with HTTP/2, the browser almost never has to do > > > this since it can express the request priority in the HTTP/2 protocol > > > itself, and let the server order responses appropriately. > > > * is great for resource discovery. Given the above > > > observation, note that it has some deficiencies. Most obviously, it does > > > not indicate the resource type. Browsers today can heuristically assign a > > > priority based on the resource type (script/image/stylesheet/etc). > > > Arguably, browsers could just use the filename extension as a hint to the > > > resource type, and that'd get us most of the way there. In any case, > > > Chromium, when it encounters is going to assign the > > > resource load the lowest priority level, and only when the parser > > > encounters the actual resource via a
Re: [whatwg] Encoding: lone surrogates and utf-8, utf-16be, and utf-16le encoders
On Wed, Sep 4, 2013 at 4:36 AM, Anne van Kesteren wrote: > The way the utf-8, utf-16be, and utf-16le encoders are written is that > they accept code points (not code units). If the code points are in > the surrogate range, they raise an error. > > That seems problematic. Encoders for utf-8 and utf-16be, and utf-16le > are assumed to be safe, because you typically forget about lone > surrogates. > > The API deals with this by having the [EnsureUTF16] flag which > converts lone surrogates into U+FFFD. So by the time code points hit > the encoder they're no longer in the lone surrogate range. > > Gecko however has not implemented this for utf-16be and utf-16be, but > has for utf-8. (Or maybe the utf-8 encoder is better.) For now I'll > assume this is a bug in Gecko. > > > I can see several options for potentially improving this setup, but I > need some feedback before going there: > > 1. Require Unicode scalar value input for encoders, and guarantee it > as decoder output. > 2. Change the utf-8, utf-16be, and utf-16le encoders to emit the byte > sequence for U+FFFD rather than raise an error for input in the lone > surrogate range. This would simplify the API and other callers to the > utf-8, utf-16be, and utf-16le encoders as they no longer need to worry > about them terminating with failure. > 3. Move towards defining the entire platform in terms of 16-bit code > units and forget about the nicer theoretical model of Unicode scalar > values. I prefer option 2 - CSS is now defined to do the same thing when parsed (nulls, lone surrogates, and out-of-range codepoints are all converted to u+fffd). ~TJ
[whatwg] Encoding: lone surrogates and utf-8, utf-16be, and utf-16le encoders
The way the utf-8, utf-16be, and utf-16le encoders are written is that they accept code points (not code units). If the code points are in the surrogate range, they raise an error. That seems problematic. Encoders for utf-8 and utf-16be, and utf-16le are assumed to be safe, because you typically forget about lone surrogates. The API deals with this by having the [EnsureUTF16] flag which converts lone surrogates into U+FFFD. So by the time code points hit the encoder they're no longer in the lone surrogate range. Gecko however has not implemented this for utf-16be and utf-16be, but has for utf-8. (Or maybe the utf-8 encoder is better.) For now I'll assume this is a bug in Gecko. I can see several options for potentially improving this setup, but I need some feedback before going there: 1. Require Unicode scalar value input for encoders, and guarantee it as decoder output. 2. Change the utf-8, utf-16be, and utf-16le encoders to emit the byte sequence for U+FFFD rather than raise an error for input in the lone surrogate range. This would simplify the API and other callers to the utf-8, utf-16be, and utf-16le encoders as they no longer need to worry about them terminating with failure. 3. Move towards defining the entire platform in terms of 16-bit code units and forget about the nicer theoretical model of Unicode scalar values. -- http://annevankesteren.nl/
