[Bug 23332] Support Binary Keys
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23332 Bug 23332 depends on bug 23369, which changed state. Bug 23369 Summary: Provide hooks for Typed Arrays (ArrayBuffer and friends) https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26153] Allow ArrayBuffer as argument to send()
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26153 Bug 26153 depends on bug 23369, which changed state. Bug 23369 Summary: Provide hooks for Typed Arrays (ArrayBuffer and friends) https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 23211] Add iterator support to FormData
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23211 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Anne ann...@annevk.nl --- https://github.com/whatwg/xhr/commit/f82ad6268c067593fd39424fcfa1489a9829ac1f -- You are receiving this mail because: You are on the CC list for the bug.
Re: Relative URLs in Web Components
On Thu, Oct 2, 2014 at 3:09 PM, Anne van Kesteren ann...@annevk.nl wrote: This is a hard problem: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20976#c8 I saw you commented on the bug, but I prefer keeping that bug focused on several other problems around base URLs so let's continue here. You gave this example: # Consider this document, located at # https://example.com/some-component/import-me.html: # # img src=foo # # It would be nice if the import process would *somehow* # turn that into… # # img src=https://example.com/some-component/foo # # …before inserting it into the parent document. As far as I can tell this particular example should already work. The base URL for that img element will be that of the document it is in, which is the import (at least per the algorithms in HTML Imports). What makes you think it would not work? The problem is with template as that isolates elements which will therefore not be processed and their associated URLs will therefore not parse, etc. Now we could perhaps add a special in-template-processing model for all elements that can have one or more associated URLs, or something along those lines, but it's not clear that's worth it. -- https://annevankesteren.nl/
Re: Relative URLs in Web Components
An issue is that a relative URL is only correct as long as the `img` (for example) is owned by the import. If you migrate the element to the main document, the path is now relative to the wrong base, and users are confused. One can do `img.src = img.src;` before migrating the node, and that will freeze the resolved path, but this is somewhat arcane. As Anne points out, this issue is worse when you start using templates. The `img` in the template isn't live and never has a resolved `src` property. If the use cases are: - migrating a sub-tree from an import to another document - migrating a sub-tree from a template to another document In both cases, users frequently want migrated elements to retain a base URL from the original document (except when they don't, for example when they are using anchor links, href=#foo =/). I've hand-waved definitions of 'migrating', 'base URL', and 'original document', but I'm only trying to frame the (as Anne said, hard) problem. Scott On Sat, Oct 4, 2014 at 6:27 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Oct 2, 2014 at 3:09 PM, Anne van Kesteren ann...@annevk.nl wrote: This is a hard problem: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20976#c8 I saw you commented on the bug, but I prefer keeping that bug focused on several other problems around base URLs so let's continue here. You gave this example: # Consider this document, located at # https://example.com/some-component/import-me.html: # # img src=foo # # It would be nice if the import process would *somehow* # turn that into… # # img src=https://example.com/some-component/foo # # …before inserting it into the parent document. As far as I can tell this particular example should already work. The base URL for that img element will be that of the document it is in, which is the import (at least per the algorithms in HTML Imports). What makes you think it would not work? The problem is with template as that isolates elements which will therefore not be processed and their associated URLs will therefore not parse, etc. Now we could perhaps add a special in-template-processing model for all elements that can have one or more associated URLs, or something along those lines, but it's not clear that's worth it. -- https://annevankesteren.nl/
