Re: [whatwg] Fetch SVG images with No CORS tainted cross-origin

On Wed, Nov 27, 2013 at 1:13 AM, Boris Zbarsky wrote: > Note that Gecko has serious security concerns with allowing subresource > loads like this in SVG loaded via ; we currently disallow them > altogether due to those concerns. Such SVG documents can link to things > internal to themselves and t

Re: [whatwg] Configurability of document.domain

On Thu, Nov 21, 2013 at 10:48 AM, Anne van Kesteren wrote: > At the moment Safari has the document.domain property defined with > configurable set to false. ([Unforgeable] in IDL.) Should we adopt > this in the specification or just leave things as is? > > It's been sugges

Re: [whatwg] Configurability of document.domain

On Thu, Nov 21, 2013 at 10:48 AM, Anne van Kesteren wrote: > (In other news, Object.getOwnPropertyDescriptor(document, "domain") > does not work in Gecko or IE10...) Please ignore this, it works with s/document/HTMLDocument.prototype/. The bug is in WebKit/Blink for not having i

[whatwg] Configurability of document.domain

At the moment Safari has the document.domain property defined with configurable set to false. ([Unforgeable] in IDL.) Should we adopt this in the specification or just leave things as is? It's been suggested some sites might rely on document.domain being trustworthy, though I don't have data for t

Re: [whatwg] Add "Switch" Type

On Tue, Nov 19, 2013 at 2:25 PM, Domenic Denicola wrote: > "Use a toggle switch for binary settings when changes become effective > immediately after the user changes them." > > "Use a checkbox when the user has to perform extra steps for changes to be > effective." On the other hand, we have t

Re: [whatwg] Implementation question about Notifications

On Mon, Nov 18, 2013 at 2:08 PM, Andrew Wilson wrote: > I think having them return the empty string would be fine (and would, > coincidentally, match our current implementation in Chrome). Okay. > My one concern is that according to the current spec, "" is a valid |tag| > and so Notification("t

Re: [whatwg] Notifications: usage feedback

On Tue, Oct 29, 2013 at 3:51 PM, Jonas Sicking wrote: > On Tue, Oct 29, 2013 at 8:26 AM, Anne van Kesteren wrote: >> That seems like an implementation detail. Activation could mean >> dismissal, but e.g. on Mac OS X activation does not mean dismissal. >> It's up to the

Re: [whatwg] Notifications: usage feedback

On Tue, Oct 29, 2013 at 3:47 PM, Jasper St. Pierre wrote: > On Tue, Oct 29, 2013 at 11:26 AM, Anne van Kesteren > wrote: >> We currently do not have a way to have events out-of-band for the web. > > What about providing a URL that the user-agent will open? If the origin

Re: [whatwg] Notifications: usage feedback

On Tue, Oct 29, 2013 at 3:43 PM, Jonas Sicking wrote: > Strings certainly solves the use cases since anything can be encoded > into a string. However it seems to me that using structured clones > will make things a lot easier for pages in many cases. This was always > *the* top complaint about loc

Re: [whatwg] Specify getSVGDocument

On Tue, Nov 19, 2013 at 10:31 AM, Erik Dahlström wrote: > SVG2 has not yet seen any edits related to this method. But it's not > unlikely that SVG2 will drop it given that SVG 1.1 states: "This interface > is deprecated and may be dropped from future versions of the SVG > specification". What do

Re: [whatwg] Implementation question about Notifications

On Thu, Nov 14, 2013 at 10:45 PM, Andrew Wilson wrote: > var n1 = new Notification("title"); > var n2 = new Notification("title", {icon: "invalid_icon_url"}); > var n3 = new Notification("title", {icon: "http://non-existent-icon.com"}); > > I think that it should be: > > n1.dir == "auto" > n1.lang

Re: [whatwg] Mailing List Archive Link

On Tue, Nov 12, 2013 at 4:10 PM, Anselm Hannemann wrote: > If it’s the wrong place here, could you forward it to the right persons or > tell me where to ask for such feature-requests? This is hard to solve giving the software we use last I checked. I recommend bookmarking http://lists.w3.org/Arc

Re: [whatwg] Questions regarding Path object

On Mon, Nov 4, 2013 at 10:07 AM, Jürg Lehni wrote: > Wouldn't it have been more aligned with this existing API also to have a > ctx.createPath() ? Objects not having constructors is a bad API practice we are moving away from. -- http://annevankesteren.nl/

Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

On Sat, Nov 2, 2013 at 1:59 AM, Boris Zbarsky wrote: > I can obviously adjust our in-tree tests, but this test was part of jQuery's > regression test suite, and I would be slightly surprised if there's no one > out there using jQuery 1.2.6 (or later, up until the code went away; I did > check that

Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

On Wed, Oct 23, 2013 at 4:47 AM, Boris Zbarsky wrote: > On 10/22/13 7:00 AM, Anne van Kesteren wrote: >> So do you think we should add getElementById() to ParentNode in DOM? > > I actually do, yes. http://dom.spec.whatwg.org/#parentnode I also filed some browser bugs just in case

Re: [whatwg] Notifications: usage feedback

On Fri, Sep 27, 2013 at 2:15 AM, James Burke wrote: > 2) General notification callback entry point > > We are avoiding use of notification.onclick/onclose and would prefer > to have a generic entry point to receive notification events. Right > now we use navigator.mozSetMessageHandler('notificatio

Re: [whatwg] Notifications: usage feedback

On Wed, Oct 16, 2013 at 9:22 PM, James Burke wrote: > On Mon, Oct 14, 2013 at 7:09 AM, Anne van Kesteren wrote: >> It seems using a structured clone makes the most sense. Transfering >> objects won't work here. It's not entirely clear to me what the best >> is f

Re: [whatwg] Reorganizing and fixing "origin"

On Fri, Jul 12, 2013 at 9:34 PM, Ian Hickson wrote: > What exactly is it you want moved, from where to where? Just the "origin > of a URL"? I'm guessing Adam would be interested in revving the Origin > spec to be more accurate if there's a problem with it; that would be my > preference if at all p

Re: [whatwg] The behaviour of Notification.requestPermission() in Workers

On Thu, Oct 24, 2013 at 12:46 PM, Tobie Langel wrote: > On Thursday, October 24, 2013 at 11:05 AM, Anne van Kesteren wrote: >> Given that Notificaiton.permission exists, I'm not sure what the >> additional value of Notification.requestPermission() in a worker >> context

Re: [whatwg] The behaviour of Notification.requestPermission() in Workers

On Thu, Oct 24, 2013 at 2:19 AM, Nikhil Marathe wrote: > The easiest solution for implementors and authors is to make the > requestPermission() call in a HTML page before spawning a worker or > registering a service worker. Inside the Worker scope we then have two > options: > 1) requestPermission

Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

On Tue, Oct 22, 2013 at 7:42 PM, Ryosuke Niwa wrote: > On Oct 22, 2013, at 4:00 AM, Anne van Kesteren wrote: >> So do you think we should add getElementById() to ParentNode in DOM? > > Why not to Element? ParentNode encompasses Document, DocumentFragment, and El

Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

On Fri, Oct 18, 2013 at 10:56 PM, Boris Zbarsky wrote: > So it looks to me like in practice Element.getElementById could be quite a > bit faster than the equivalent querySelector call, for both the in-tree case > (where both can avoid walking the tree) and the out-of-tree case (where both > need t

Re: [whatwg] Canvas in workers

On Wed, Oct 16, 2013 at 9:23 PM, Kenneth Russell wrote: > While the Promise returned from createImageBitmap(HTMLCanvasElement) > can be fulfilled immediately, is it worth introducing a special > overload with a different return type? Well if you want a synchronous method a promise is not going to

Re: [whatwg] Notifications: usage feedback

On Fri, Sep 27, 2013 at 2:15 AM, James Burke wrote: > 1) Ability to pass data with the Notification > > Right now, we URL-encode some args to the iconURL to pass data to the > handler function that is registered via > navigator.mozSetMessageHandler('notification', function(){}) [1]. > > It would b

Re: [whatwg] onclose events for MessagePort

On Fri, Oct 11, 2013 at 9:38 AM, Andrew Wilson wrote: > *"or while there exists an event listener on either port for the > channeldropped event."* Once you do that you basically rely on the developer to handle GC and you'll end up with memory leaks instead. -- http://annevankesteren.nl/

Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

On Thu, Oct 10, 2013 at 10:26 PM, Scott González wrote: > I don't think there was any response to this. What is the reason for > keeping these methods off of DocumentFragment if new APIs which inherit > from DocumentFragment are going to have the methods anyway? That's not going to happen. --

Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

On Thu, Oct 10, 2013 at 8:51 PM, Boris Zbarsky wrote: > On 10/10/13 2:41 PM, Ian Hickson wrote: >> I feel this is a case where we're not putting authors first, but are >> instead putting spec purity first. > > Ah, that sums up my vague feelings of discontent here perfectly. +1000. ;) FWIW, I'm

Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?

On Tue, Oct 8, 2013 at 8:35 PM, Philip Jägenstedt wrote: > I don't know anything about the move of those attributes, has it been > attempted in spec and implementation and run into trouble? http://dom.spec.whatwg.org/ is the specification, but I don't think it's been implemented yet. Moving more

Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?

On Tue, Oct 8, 2013 at 4:26 PM, Erik Dahlstrom wrote: > On Tue, 08 Oct 2013 15:49:48 +0200, Philip Jägenstedt > wrote: >> 1. Do what Gecko does, even though there's no SVG spec requiring it yet. >> 2. Just say "Element implements GlobalEventHandlers". >> >> I would prefer option 2, since we alrea

Re: [whatwg] Supporting scanners on the web

On Thu, Sep 26, 2013 at 11:19 AM, Benjamin Smedberg wrote: > One of the use cases that has come up for why people are still using plugins > is supporting scanning to the web, in particular multi-page scanning. It > seems to me that we could hook this up to , but > that we should try to provide UAs

Re: [whatwg] [Workers] CSP and SharedWorkers

On Wed, Sep 25, 2013 at 11:00 PM, Kyle Huey wrote: > Thoughts? What happens today for ? The load itself seems to be governed by the parent. Does the policy inherit into it? I feel like workers should work like as they're essentially their own global objects. -- http://annevankesteren.nl/

Re: [whatwg] HTML: A DOM attribute that returns the language of a node

On Wed, Sep 18, 2013 at 11:10 AM, L. David Baron wrote: > In Gecko it's also implemented through CSS inheritance, but it's not > exposed to Web content as a CSS property. (Internally it's > '-x-lang', but that name isn't exposed.) > > We use the language for: > * font selection > * language-spe

Re: [whatwg] Zip archives as first-class citizens

On Mon, Sep 16, 2013 at 8:09 AM, Julian Reschke wrote: > Because it's an invalid URI. "%" needs to be percent-escaped. That was the whole point of that particular proposal. It seems something like $zip= might be better though it wouldn't be fully backwards compatible with all valid data URLs to d

Re: [whatwg] Zip archives as first-class citizens

On Fri, Sep 13, 2013 at 1:24 PM, Robin Berjon wrote: > This has also been done, perhaps not to a sufficient extent, in Widgets: > > http://www.w3.org/TR/widgets/#zip-archive That looks like a mess. To be fair, for the format I don't have much more than http://wiki.whatwg.org/wiki/Zip#Format a

Re: [whatwg] Fetch SVG images with No CORS tainted cross-origin

On Fri, Sep 13, 2013 at 10:52 AM, Dirk Schulze wrote: > If Fetch is not just fetching external (as not in the current document) then > we still need it for SVG. References within the same document must still work. Fragment identifiers are to be handled by SVG. Again, your "SVG fetch" wrapper cou

Re: [whatwg] Why are we merging Document and HTMLDocument again?

On Fri, Sep 13, 2013 at 8:42 AM, Simon Pieters wrote: > * XHR response (uses interface "Document" and is an "XML document", even for > text/html if I read the spec correctly) I assumed :/ that HTML would do the marking. Let's consider this a bug. It's not entirely clear to me what the suggestio

Re: [whatwg] Fetch SVG images with No CORS tainted cross-origin

On Fri, Sep 13, 2013 at 9:27 AM, Dirk Schulze wrote: > So, I wonder how that behavior could be described. I think you'd have a mode switch and maybe a wrapper for Fetch that only calls it for data and blob URLs. It seems like you don't really want to invoke Fetch at all for SVG as image. Do scrip

Re: [whatwg] [XHR] changes in abort() steps

On Fri, Sep 13, 2013 at 6:42 AM, Jungkee Song wrote: > In the recent change in abort() steps, is it intended to NOT change the > state to UNSENT for an ongoing (the send() flag set) request? It's observed > that Chrome, Firefox, IE all set it to UNSENT. Also, a few test cases in W3C > tests have a

Re: [whatwg] URL resolution of fragment urls in html5 webapps

On Thu, Sep 12, 2013 at 5:28 PM, Boris Zbarsky wrote: > Or from SVG presentation attributes. Fill, filters, masks, etc, etc, etc. > > But again, it's not clear that anything needs to be done here. If something > _does_ need to be done, then it needs to be done at a low level (e.g. url() > needs

Re: [whatwg] URL resolution of fragment urls in html5 webapps

On Thu, Sep 12, 2013 at 4:51 PM, Boris Zbarsky wrote: > On 9/12/13 5:24 AM, Anne van Kesteren wrote: >> On Wed, Sep 11, 2013 at 7:22 PM, Ian Hickson wrote: >>> Well presumably we wouldn't want to only do it for , since then links >>> would work but SVG wou

Re: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use

On Wed, Sep 11, 2013 at 7:21 PM, Ian Hickson wrote: > Surely the consistency of the API matching the input is more important > than the consistency of the API _not_ matching the input... The input will be mangled anyway. E.g. domain label separators are normalized to ".". And all kinds of other p

Re: [whatwg] URL resolution of fragment urls in html5 webapps

On Wed, Sep 11, 2013 at 7:22 PM, Ian Hickson wrote: > Well presumably we wouldn't want to only do it for , since then links > would work but SVG wouldn't (the exact opposite of the situation in Chrome > now, for what it's worth). Yeah, we should have to do it for everything we classify as "hyperl

Re: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use

On Tue, Sep 10, 2013 at 8:54 PM, Ian Hickson wrote: > On Fri, 12 Jul 2013, Anne van Kesteren wrote: >> But then we shouldn't garble pathname either and we do because we have >> to. So I'm not sure that line of reasoning makes sense. I do think we >> should offer

Re: [whatwg] URL resolution of fragment urls in html5 webapps

On Tue, Sep 10, 2013 at 8:34 PM, Ian Hickson wrote: > On Wed, 10 Jul 2013, Rafael Weinstein wrote: >> I'm curious: Is it useful to have fragment URL resolve against anything >> other than the "display" url? I.e. when is the current behavior wrt >> fragments appropriate. > > It's a good question. I

Re: [whatwg] Forcing orientation in content

On Tue, Sep 10, 2013 at 10:22 PM, Ian Hickson wrote: > On Mon, 15 Jul 2013, Kornel Lesiński wrote: >> Since specific, locked screen orientation is mostly needed in games, and >> forced rotation is disruptive to other things on the screen (e.g. moving >> buttons/addressbar to other physical edge of

Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

On Fri, Sep 6, 2013 at 2:50 AM, Boris Zbarsky wrote: > In that case I think we need to add a function to the platform that > CSS-escapes a string. Maybe a thing for window.CSS? Simon? Such a function already exists in the wild btw: http://mothereff.in/css-escapes -- http://annevankesteren.nl/

Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

On Fri, Jun 28, 2013 at 9:19 PM, Zirak A wrote: > Currently, a DocumentFragment only inherits from Node, and thus loses methods > like getElementById. However, the Selector API > (http://www.w3.org/TR/selectors-api/) defines querySelector and > querySelectorAll on document fragments. > My propo

Re: [whatwg] Zip archives as first-class citizens

On Thu, Sep 5, 2013 at 7:18 AM, Alex Russell wrote: > On Wed, Aug 28, 2013 at 9:20 AM, Jonas Sicking wrote: >> 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 expe

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 i

[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 f

Re: [whatwg] Zip archives as first-class citizens

On Mon, Sep 2, 2013 at 2:04 PM, Nicholas Shanks wrote: > Am I missing something? I assume you want to basically send a whole > bunch of files down the pipe when any one of them is requested, not > send the individual file's bytestream from a zip. If so, then why is > this not acceptable: > > === >

[whatwg] Notifications: associating state

Having Notification.get() makes associating state more desirable, but even in its absence we have requests to store arbitrary state on Notifications object. We could have a mechanism similar to pushState() to store such state. It's kinda similar to having data-* on elements. My main worry is that

Re: [whatwg] Zip archives as first-class citizens

On Thu, Aug 29, 2013 at 2:37 PM, Boris Zbarsky wrote: > On 8/29/13 9:32 AM, Anne van Kesteren wrote: >> Doing a mixture of sniffing and labeling has not served us very well. >> We cannot rely solely on sniffing because of CSS and SVG. We can rely >> solely on a standard

Re: [whatwg] Zip archives as first-class citizens

On Thu, Aug 29, 2013 at 2:26 PM, Boris Zbarsky wrote: > On 8/29/13 9:02 AM, Anne van Kesteren wrote: >> Using the file extension and no sniffing of any sorts > > Why? Doing a mixture of sniffing and labeling has not served us very well. We cannot rely solely on sniffing because

Re: [whatwg] Zip archives as first-class citizens

On Thu, Aug 29, 2013 at 1:19 PM, Jake Archibald wrote: > Causing a network error in existing browsers is a shame. It'd be great if > older browsers requested a url which included the zip location & the file > within, so the server could unpack the zip and deliver the right file. > Whereas modern b

Re: [whatwg] Zip archives as first-class citizens

On Thu, Aug 29, 2013 at 1:15 PM, Alexandre Morgaut wrote: > In the solution mentioned with tag and a "pack:" like scheme > > title="My app global resources"> I don't think adding a level of indirection is a good idea. I think the added complexity is the reason this proposal failed the last time

Re: [whatwg] Zip archives as first-class citizens

On Wed, Aug 28, 2013 at 6:10 PM, Matthew Kaufman wrote: > This sounds like a great opening for a discussion about the pros and cons of > doing such a thing. But until such a discussion has happened, isn't it a > little premature to worry about the URL details? Those are not details. What has been

Re: [whatwg] Zip archives as first-class citizens

On Wed, Aug 28, 2013 at 5:36 PM, Boris Zbarsky wrote: > I think this comes back to use cases. > > If the idea of having the zip is "here is stuff that should live in its own > world", then we do not want easy ways to get out of it via relative URIs. > > If the idea is to have "here is a fancy way

Re: [whatwg] Zip archives as first-class citizens

On Thu, Aug 29, 2013 at 2:14 AM, Mark Nottingham wrote: > I'm sure you've thought about this more than I have, but can you humour me > and dig in a bit here? Thanks Mark, I had not fully explored this one yet! > If I wanted to link *within* the HTML, it could still be , > correct? That would

Re: [whatwg] Zip archives as first-class citizens

> On Wed, Aug 28, 2013 at 8:47 AM, Eric U wrote: > Without commenting on the other parts of the proposal, let me just > mention that every time .zip support comes up, we notice that it's not > a great web archive format because it's not streamable. That is, you > can't actually use any of the con

Re: [whatwg] Zip archives as first-class citizens

On Wed, Aug 28, 2013 at 4:50 PM, Michal Zalewski wrote: > 1) Both jar: and mhtml: (which work or worked in a very similar way) > have caused problems in absence of strict Content-Type matching. In > essence, it is relatively easy for something like a valid > user-supplied text document or an image

Re: [whatwg] Zip archives as first-class citizens

Resending. I recommend that people replying trim the address list as apparently "Too many recipients to the message" is a thing for this mailing list. On Wed, Aug 28, 2013 at 4:54 PM, Eric Uhrhane wrote: > Without commenting on the other parts of the proposal, let me just > mention that every tim

Re: [whatwg] Zip archives as first-class citizens

On Wed, Aug 28, 2013 at 4:04 PM, Boris Zbarsky wrote: > What's the issue with that? Gecko supports that (with jar:, not zip:), > fwiw. As far as the web platform is considered today, URL objects are just that. In Gecko you either have a URL object, or a linked list of URL objects. I guess the qu

[whatwg] Zip archives as first-class citizens

A couple of us have been toying around with the idea of making zip archives first-class citizens on the web. What we want to support: * Group a bunch of JavaScript files together in a single resource and refer to them individually for upcoming JavaScript modules. * Package a bunch of related resou

Re: [whatwg] Web Notification: API inconsistency

On Fri, Aug 23, 2013 at 6:41 PM, Boris Zbarsky wrote: > Given the last definition of then() I saw, this has a bit of a gotcha. First we need to decide whether we care about making this promise-based. If we do, and we decide we care about compatibility for this edge-case, we can solve this using a

Re: [whatwg] Web Notification: API inconsistency

On Fri, Aug 23, 2013 at 6:09 PM, Boris Zbarsky wrote: > If we want to continue returning void when a callback is passed, we need to > add some webidl magic for that... My idea was to always return a promise. And if a callback is passed you just pass that to the promise "as listener". -- http:/

Re: [whatwg] Web Notification: API inconsistency

On Fri, Aug 23, 2013 at 1:16 PM, Jeremie Patonnier wrote: > The spec define two static methods: `requestPermission` and `get` > I'm a bit puzzled because `requestPermission` expect a callback function > where `get` return a `Promise`. It's not clear to me we can change the design of requestPermis

Re: [whatwg] Can the maximum allowed value length be changed to restrict the number of characters?

On Wed, Aug 21, 2013 at 8:19 PM, Alexey Proskuryakov wrote: > FWIW, this is tracked for WebKit as > . I think Darin's comment about the server component makes sense. My remark was mostly as to what is exposed to JavaScript. I don't think we expose

Re: [whatwg] Forms-related feedback

On Wed, Aug 21, 2013 at 2:27 AM, TAMURA, Kent wrote: > As for type=date, rawValue should return what a user see. Value set by > script or not doesn't matter. > In Google Chrome, rawValue should return a localized date value such > as "21/08/2013". If we start doing this (and other things you prop

Re: [whatwg] Promise.every() arguments

On Tue, Aug 20, 2013 at 10:42 PM, Alec Flett wrote: > Promises are going to be out way before ES6, it seems unfortunate that > everyone's going to have to use Promise.every.apply though, since spreading > is a syntax error in non-ES6... it means you can't polyfill it in the > general case. (And ma

Re: [whatwg] Promise.every() arguments

On Tue, Aug 20, 2013 at 10:00 PM, Tab Atkins Jr. wrote: > ES6 has array spreading, so you can do `Promise.every(...pending)`. > This already works in Firefox, and V8 (Chrome's JS engine) is adding > these kinds of features as well. Domenic made an argument somewhere that since the value of the pr

Re: [whatwg] Can the maximum allowed value length be changed to restrict the number of characters?

On Tue, Aug 20, 2013 at 12:30 AM, Ryosuke Niwa wrote: > Can the specification be changed to use the number of composed character > sequences instead of the code-unit length? In a way I guess that's nice, but it also seems confusing that given data:text/html, pasting in U+0041 U+030A would give

Re: [whatwg] URL standard: Query string parsing; host parsing

On Thu, Mar 21, 2013 at 3:12 PM, Anne van Kesteren wrote: > As far as I can tell the most prominent implementations still > implement IDNA2003. In fact, with Rebel Opera gone, all browsers do > IDNA2003. So maybe we should standardize on that. The problem with > standardizing on that

Re: [whatwg] URL testing

On Fri, Nov 23, 2012 at 7:39 PM, Chris Weber wrote: > Hello, I've been trying to follow Anne's work with the URL spec, and > working on using the W3C testharness.js for URL testing. I have some > URL testing running, with still more work to do: > > http://www.lookout.net/test/url/ > > The test ca

Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob

On Mon, Aug 12, 2013 at 6:16 PM, Joshua Bell wrote: > FWIW, I've landed an experimental (behind a flag) implementation of the API > in Blink/Chromium; changing it is definitely possible for us. I believe Moz > is shipping it web-exposed already in FF? Yes, since Firefox 18 (since Firefox 20 in wo

Re: [whatwg] XML data islands related question

On Thu, Aug 8, 2013 at 3:01 PM, Jukka K. Korpela wrote: > 2013-08-08 9:13, Ian Hickson wrote: >> XHR uses the same underlying logic as and

Re: [whatwg] XML data islands related question

On Thu, Aug 8, 2013 at 1:38 PM, Charles McCathie Nevile wrote: > On Thu, 08 Aug 2013 01:08:54 +0400, Ian Hickson wrote: >> I don't understand why XHR doesn't work for you. > > I can see why not. Imagine an app that wants to collect all my current email > when it connects, but is then going to be

Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob

On Wed, Aug 7, 2013 at 11:55 AM, Alain Couthures wrote: > Because I implemented MS-Office files manipulation in my browser-side XForms > implementation, such TextDecoder and TextEncoder are very interesting. To be clear, they are part of http://encoding.spec.whatwg.org/ and implemented in various

Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob

On Tue, Aug 6, 2013 at 9:48 PM, Chang Shu wrote: > But it appears to me we have to introduce > another pair of coders, say BinaryDecoder/BinaryEncoder, in addition > to TextDecoder/TextEncode since the signatures of the decode/encode > functions are different. So TextDecoder is bytes to string an

Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob

On Tue, Aug 6, 2013 at 1:41 AM, Kenneth Russell wrote: > The Encoding spec at http://encoding.spec.whatwg.org/ seems to have > handled issues like these. Perhaps a better route would be to fold > this functionality into that spec. Yeah, I think my preference would be at this point to expose API-o

Re: [whatwg] Challenging canvas.supportsContext

On Wed, Jul 31, 2013 at 4:26 PM, Benoit Jacob wrote: > Ping --- I thought that there was sufficient agreement in this thread, > around the fact that supportsContext, as currently spec'd and currently > implementable, is a feature without a valid use case, that removing it from > the spec is the ri

Re: [whatwg] HTML5 parsing and specification challenges and difficulties

On Tue, Jul 30, 2013 at 12:21 PM, Mohammad Al Houssami (Alumni) wrote: > I am implementing an HTML5 parser and as part of the project I have to write > a report that should include what are the major challenges faced during > writing the specs of the parser and the actual parsing process. I have

Re: [whatwg] Script-related feedback

On Wed, Jul 24, 2013 at 11:18 AM, Ian Hickson wrote: > Yeah, but the multipart logic has pretty big disadvantages -- mainly the > opposite of the advantages for a built-in feature: > > - not backwards compatible > - not as simple to understand, use, implement, or spec > - doesn't really work ou

Re: [whatwg] Page reflow when entering/exiting fullscreen

On Tue, Jul 23, 2013 at 11:19 AM, Matt Falkenhagen wrote: > By placeholder, I mean a dummy renderer with the same dimensions as the > element before it went full screen, added in its place when it goes > fullscreen to prevent the page from reflowing. There are probably other > ways to prevent refl

Re: [whatwg] Page reflow when entering/exiting fullscreen

On Mon, Jul 22, 2013 at 6:58 PM, Matt Falkenhagen wrote: > When an element goes fullscreen, should the browser try to retain the > layout of the underlying document, e.g., by creating a placeholder for > the element? It's not entirely clear to me what you mean by placeholder. > With the top lay

Re: [whatwg] Background of covering the whole page – is this described somewhere?

On Tue, Jul 23, 2013 at 10:37 AM, Jukka K. Korpela wrote: > Is this described somewhere in HTML or CSS specifications or drafts? I think > it should be, since it is what browsers do (tested on Firefox, Chrome, IE), > and even though it sounds absurd, I’m afraid pages may rely on it. A natural > pl

Re: [whatwg] Notifications: reviving Notification objects

On Tue, Jul 9, 2013 at 8:32 AM, Anne van Kesteren wrote: > A requires being able to get the notifications associated with a > certain site. That can also be useful in case multiple windows are > open of the same site and can help workers and pages coordinate once > we enable noti

[whatwg] Notifications: eventTime

Chrome supports Notifications.eventTime: http://developer.chrome.com/extensions/notifications.html#type-NotificationOptions I suggest we add that to the specification. By default it's not there, but if specified it signifies the notification is for an event at a specific time, such as a calender en

Re: [whatwg] Proposal: createImageBitmap should return a "Promise" instead of using a callback

On Wed, Jul 17, 2013 at 5:22 PM, Silvia Pfeiffer wrote: > It may well be that Promises are the right way to go for > createImageBitmap(), but we are blazing a new trail here and need to > be careful about the implications. For example, here is an interesting > discussion thread with a statement th

Re: [whatwg] URL: file URL "C|" quirk

On Tue, Jul 9, 2013 at 10:48 AM, Benjamin Smedberg wrote: > I am certain that we must continue to support this in Firefox in some cases > (URLs passed in on the command line or via DDE). I am not sure what we'd > break by removing support for it for URLs in general. Unless there is a > compelling

Re: [whatwg] URL: "relative" file URL starting with "c:" quirk

On Tue, Jul 9, 2013 at 2:03 PM, Peter Kasting wrote: > I don't see this as a security risk, and if the behavior is desirable, it > seems fairly well-scoped in terms of specifying it. For now I've not done this because it would mean that purported absolute URLs would not round trip. "file:c:..." i

Re: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use

On Fri, Jul 12, 2013 at 2:50 PM, Boris Zbarsky wrote: > If nothing else because that seems user-hostile (both to web developers > examining location values and users who are shown document.URL or > location.href in web pages). But then we shouldn't garble pathname either and we do because we have

Re: [whatwg] [URL] Resolving against the base of the current page

On Thu, Jul 11, 2013 at 7:56 AM, Jake Archibald wrote: > http://url.spec.whatwg.org/ > > How would I create a URL relative to the page, but taking into account > (and anything else that may affect relative urls on the page)? document.baseURI? > It feels like the 2nd constructor parameter shoul

Re: [whatwg] URL: "relative" file URL starting with "c:" quirk

On Mon, Jul 8, 2013 at 6:23 PM, Peter Kasting wrote: > Given how unlikely it is that someone will have registered a scheme handler > for the one-character drive letters, the Chrome/IE behavior seems more > forgiving and more likely what the author wants, to me. But it also forks the semantics of

Re: [whatwg] Notifications: reviving Notification objects

On Sun, Mar 31, 2013 at 10:33 AM, Anne van Kesteren wrote: > There are a couple of scenarios http://notifications.spec.whatwg.org/ > does not address at the moment. > > A) User navigates to chat site. Chat site creates a notification from > a chat with P while the user does somet

[whatwg] URL: "relative" file URL starting with "c:" quirk

Both Chromium and Internet Explorer treat ... in a file served from e.g. file:///C:/Users/Anne%20van%20Kesteren/Desktop/file.html in a special way. The resolved URL becomes file:///c:/test (uppercase C in Chromium) rather than c:/test (note that c: is a valid URL scheme) as it does in Gecko. I

[whatwg] URL: file URL "C|" quirk

Both Gecko and Chromium have a quirk with "C|" and similar patterns (drive letter followed by |). They treat it similarly to "C:". However, Internet Explorer does not do this. Should we remove this quirk? -- http://annevankesteren.nl/

Re: [whatwg] Requiring the Encoding Standard preferred name is too strict for no good reason

On Tue, Jul 2, 2013 at 9:24 AM, Jukka K. Korpela wrote: > Such evangelism is a different issue. If you want to nag “you should use > UTF-8”, as a warning, each and every time when someones declares any other > encoding, you will confuse or irritate many people and will reduce the > popularity of v

Re: [whatwg] Requiring the Encoding Standard preferred name is too strict for no good reason

On Tue, Jul 2, 2013 at 8:05 AM, Jukka K. Korpela wrote: > [...] I think a much more interesting problem is when they update that old page with an IRI, , or some XMLHttpRequest, and shit hits the fan. That's why you want to flag all non-utf-8 usage and just get people to migrate towards sanity.

Re: [whatwg] Questions about ::backdrop

On Fri, Jun 28, 2013 at 9:46 AM, Matt Falkenhagen wrote: > I'm working on implementing the ::backdrop pseudo-element[1] for top > layer elements such as modal and have some questions. Awesome. > 1. Should ::backdrop have the same properties as a real top layer > element, such as "Its containin

<    1   2   3   4   5   6   7   8   9   10   >