Re: [whatwg] [blink-dev] Intent to Ship: Scroll To Text Fragment

On Fri, Oct 25, 2019 at 10:59 AM 'David Bokan' via blink-dev wrote: > The kind of feedback we received here would have been wonderful to have > several weeks ago. What should we be doing to get to this step earlier? For WHATWG, PRs against standards tend to help as they require review,

Re: [whatwg] rendering for case min == max

On Mon, Mar 19, 2018 at 11:13 AM, Mikko Rantalainen wrote: > The spec should specify one way or the other for this corner case. Agreed, we're tracking this in https://github.com/whatwg/html/issues/3520. If anyone would like to help clarify the prose in the form of a

Re: [whatwg] [CSSWG][css-scroll-snap] Updated CR of CSS Scroll Snapping Level 1

On Mon, Dec 25, 2017 at 11:54 AM, fantasai wrote: > A related concern was brought up that some DOM APIs define scrolling to > an element in a way that conflicts with scroll-snapping; such APIs should > allow for an element's snap position, if defined, to dictate the

[whatwg] Further working mode changes

Last week we made some further refinements to the way the WHATWG operates and are pleased that as a result Microsoft now feels comfortable to participate: https://blog.whatwg.org/working-mode-changes https://blog.whatwg.org/copyright-license-change Let me also take this moment to remind

Re: [whatwg] Accessing local files with JavaScript portably and securely

On Wed, Apr 19, 2017 at 9:55 PM, Yay295 wrote: > Maybe a solution then would be to provide a way to request more storage > space? Sounds like it. At least in Firefox https://storage.spec.whatwg.org/ will provide that soonish, including the guarantee that the browser won't

Re: [whatwg] Accessing local files with JavaScript portably and securely

On Wed, Apr 19, 2017 at 11:08 AM, duanyao wrote: > This is really not intended. I just don't quite understand some of those > points. For example, > Is "the web being fundamentally linked to HTTP" just the current status of > the industry, or > the inherent philosiphy of the

Re: [whatwg] Accessing local files with JavaScript portably and securely

On Wed, Apr 19, 2017 at 5:45 AM, duanyao wrote: > These have been a lot of discussion on that in this thread. Do you think > writing a more formal document would be helpful? Perhaps. Fundamentally, I don't think you've made a compelling enough case for folks to become

Re: [whatwg] Accessing local files with JavaScript portably and securely

On Tue, Apr 18, 2017 at 10:25 AM, Roger Hågensen <rh_wha...@skuldwyrm.no> wrote: > On 2017-04-18 10:08, Anne van Kesteren wrote: >> Right, those are about making applications distributed over HTTPS work >> when the user is not connected. That idea doesn't necessitate file &g

Re: [whatwg] Accessing local files with JavaScript portably and securely

On Tue, Apr 18, 2017 at 9:57 AM, Roger Hågensen wrote: > Searching Google for "offline webapp discussion group" turns up > https://www.w3.org/wiki/Offline_web_applications_workshop > and that's sadly from 2011. > > There is https://www.w3.org/TR/offline-webapps/ Right,

Re: [whatwg] Accessing local files with JavaScript portably and securely

On Mon, Apr 17, 2017 at 5:53 PM, duanyao wrote: > When we want to write a web application portable across multiple server > OSes, these issues could happen too. Yes, but then you run into implementation bugs. Which are a very different category from proprietary OS design

Re: [whatwg] Accessing local files with JavaScript portably and securely

On Mon, Apr 17, 2017 at 3:32 PM, duanyao wrote: > So you mean file: protocol is not portable? For absolute file: url, true; > for relative url, almost not true. > > When writing web pages, no one use absolute file: urls in practice, so this > is a non-issue. Neither is portable

Re: [whatwg] Accessing local files with JavaScript portably and securely

On Mon, Apr 17, 2017 at 2:54 PM, duanyao wrote: > 在 2017年04月15日 02:09, Domenic Denicola 写道: >> file: URLs are part of the web, e.g. parsing such URLs when used in >> tags, just like gopher: URLs or mailto: URLs. The behavior once navigating >> to file: URLs (or gopher: URLs, or

Re: [whatwg] metadata

On Fri, Apr 14, 2017 at 10:23 PM, Andy Valencia wrote: > But the overarching issue is that you're doing JS-initiated > network operations, and origin policy is going to stop you. > You can claim Shoutcast/Icecast should give permissive > origins, but they don't, and

Re: [whatwg] Adding progress event for native ?

On Wed, Apr 12, 2017 at 9:16 AM, Mikko Rantalainen wrote: > The default use case would not need to use frames. The expected use case > would be to display custom UI for submission progress (e.g. nice > progress bar and ETA with custom algorithm). It would be just fine

Re: [whatwg] Adding progress event for native ?

On Tue, Apr 11, 2017 at 2:44 PM, Mikko Rantalainen wrote: > I see that https://xhr.spec.whatwg.org/ already defines ProgressEvent > for XMLHttpRequest. > > Would it be possible to add "progress", "load", etc. events to normal > form elements, too? Basically, I would

Re: [whatwg] metadata

On Mon, Apr 10, 2017 at 6:44 AM, Philip Jägenstedt wrote: > There is a very old bug for exposing the metadata: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=5755 > > In order to make progress, there needs to be implementer interest. Although > it may well fizzle out, a new

Re: [whatwg] Subresource Integrity-based caching

On Fri, Mar 3, 2017 at 11:01 PM, Alex Jordan <a...@strugee.net> wrote: > On Fri, Mar 03, 2017 at 09:21:20AM +0100, Anne van Kesteren wrote: >> I think https://github.com/w3c/webappsec-subresource-integrity/issues/22 >> is the canonical issue, but no concrete ideas thus far. &g

Re: [whatwg] Subresource Integrity-based caching

On Thu, Mar 2, 2017 at 6:07 PM, Domenic Denicola wrote: > I don't know what the latest is on attempting to get around this, although > that document suggests some ideas. I think https://github.com/w3c/webappsec-subresource-integrity/issues/22 is the canonical issue, but no

Re: [whatwg] Should navigator.language and and/or HTTP Accept-Language include locale?

On Wed, May 25, 2016 at 4:50 AM, Geoffrey Garen wrote: > My claim is that if you want English language with Russian regional settings > then browsers must report “en-ru” in navigator.language. That doesn't work. What if you want British English and the Russian locale? Or

Re: [whatwg] Should navigator.language and and/or HTTP Accept-Language include locale?

On Tue, May 24, 2016 at 1:55 AM, Nils Dagsson Moskopp wrote: > • navigator.language is the language of the interface > • HTTP Accept-Language is the language of content > • ECMA-402 DefaultLocale() is the user's locale The HTML Standard has a should-level

Re: [whatwg] Should navigator.language and and/or HTTP Accept-Language include locale?

On Mon, May 23, 2016 at 11:58 PM, Geoffrey Garen wrote: > For example, if I speak English but I like Polish number formatting, should > navigator.language report “en-pl”? I don't think so. That would only make sense if English was a language spoken in Poland that differs from

Re: [whatwg] Expose the 'renderport' to content

On Tue, Apr 5, 2016 at 10:26 PM, Matt Woodrow wrote: > Our suggested solution to this is to add a callback to scrollable elements > that fires before painting (similar to requestAnimationFrame) and exposes > the (approximate) region of the element that the UA is going to

Re: [whatwg] Support filters in Canvas

On Fri, Feb 26, 2016 at 4:34 PM, Ali Juma wrote: > The current canvas filters proposal [1] allows using SVG reference filters > defined in external documents (e.g. “url(file.svg#filter)”). Since the > external document needs to be loaded before the filter can be applied, >

[whatwg] Standards development happening on GitHub

I wanted to remind the mailing list that currently all WHATWG standards are being developed on GitHub. This enables everyone to directly change standards through pull requests and start topic-based discussion through issues. GitHub is especially useful now that the WHATWG covers many more topics

Re: [whatwg] Using time-origin-relative times for the .timeStamp property of animation events is not web-compatible

On Thu, Dec 10, 2015 at 10:00 AM, Boris Zbarsky wrote: > It looks like at least the angular-animate assumes that the .timeStamp > property of animation events produces values that can be compared to > Date.now() return values. See >

Re: [whatwg] Signature Link Relation for Cryptographic Resource Verification

On Wed, Dec 9, 2015 at 10:05 AM, Sean B. Palmer wrote: > I expect that I will be continuing this discussion largely with the > WebAppSpec team, as their work is so obviously related to the contents > of the Internet-Draft. Thank you, that does indeed seem like the right

[whatwg] OffscreenCanvas

Thanks to Olli I discovered https://wiki.whatwg.org/wiki/OffscreenCanvas is much further along than I thought. Is anyone planning on creating a PR against https://github.com/whatwg/html for the more formal specification of this feature? (And simultaneously ripping out the old worker canvas text.)

Re: [whatwg] : Issue reported by the web developers

On Wed, Nov 26, 2014 at 9:50 AM, Simon Pieters wrote: > Make the end tag optional and have , and generate > implied end tags. (Maybe other tags like and can also > imply .) The label attribute be honored if specified, otherwise > use the textContent with leading and

[whatwg] Removing mediagroup/MediaController from HTML

In https://github.com/whatwg/html/issues/192 we're planning on removing mediagroup/MediaController from HTML since other than WebKit no implementations appear interested in implementing these features. -- https://annevankesteren.nl/

Re: [whatwg] Handling out of memory issues with getImageData/createImageData

On Sun, Sep 27, 2015 at 6:14 PM, Allen Wirfs-Brock wrote: > Actually, that's not completely correct. Within ES2015, the only way > explicitly allocate a large, dense area of memory is by creating a large > ArrayBuffer instance. All attempts to create such instances

Re: [whatwg] Handling out of memory issues with getImageData/createImageData

On Fri, Sep 25, 2015 at 4:48 PM, Justin Novosad wrote: > Currently there is no spec'ed behavior for handling out-of memory issues > for the specific case of attempting to allocate a large buffer through > image data APIs. Actually, there is no specified behavior for

Re: [whatwg] Icon mask and theme color

On Mon, Sep 14, 2015 at 12:11 AM, Karl Dubost wrote: > Nicolas Hoizey spotted on Apple forums and added a comment on the bug > >> The markup changed in Developer Seed 3 and Public Beta 1 >> to simplify and have better backwards compatibility. >> Use the following markup

[whatwg] New ruby elements in HTML

I emailed some folks individually, but I suppose I should also make a note here. At least Chrome, Firefox, and Safari have extended the HTML parser beyond the HTML Standard with the addition of special parsing rules for and elements. (And slightly changed parsing rules for and elements.)

Re: [whatwg] [whartwg] Video processing ability for MediaStreamTrack

On Fri, Aug 7, 2015 at 8:56 AM, Chia-Hung Tai c...@mozilla.com wrote: http://chiahungtai.github.io/mediacapture-worker/ Given that removeVideoProcessor() does not take arguments, should addVideoProcessor() not check for duplicates? VideoProcessEventThe looks like a typo. The events don't

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

On Mon, Jul 13, 2015 at 3:58 PM, Majid Valipour maji...@chromium.org wrote: It is only used as way to group properties (perhaps similar to ValidityState?) and to keep History interface clean and stack-like. If that is not valuable enough to introduce a new interface then putting these on the

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

On Sun, Jul 12, 2015 at 11:52 PM, Elliott Sprehn espr...@chromium.org wrote: This is what I had in mind as well. Also it occurs to me there's a missing primitive here for how the browser knows that all listeners have mayCancel: false so it can make this optimization. EventTarget needs some kind

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

On Mon, Jul 13, 2015 at 8:09 AM, Elliott Sprehn espr...@chromium.org wrote: Without such a function there's no primitive to explain how the scrolling and touch systems utilize this mayCancel bit unless we're saying the browser stores hidden state for event listeners in some WeakMap and all the

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

On Sat, Jul 11, 2015 at 11:41 PM, Rick Byers rby...@chromium.org wrote: What Anne describes is perfect! I'm not hung up on the value of cancelable itself - some internal bit on Event that makes preventDefault a no-op (or event throw) during listener invocation is fine with me (and I agree -

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

On Sun, Jul 12, 2015 at 7:49 PM, Jonas Sicking jo...@sicking.cc wrote: I think we've already made that assumption given that history.state already relies on this. Good point. I'm still somewhat skeptical of introducing new objects just for the purpose of grouping some properties if they don't

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

On Fri, Jul 10, 2015 at 10:54 PM, Majid Valipour maji...@chromium.org wrote: Minor bikeshed: I have put scrollRestoration on history.options instead of directly history itself in order to use history.options as an interface to contain any other restoration related attributes which have similar

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

On Sat, Jul 11, 2015 at 8:19 PM, Domenic Denicola d...@domenic.me wrote: I'm not sure that actually matters though, since canceling inside setTimeout(,0) shouldn't have much affect besides changing `e.defaultPrevented`. So maybe it's OK. It's fine. The code that dispatches an event and then

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

On Fri, Jul 10, 2015 at 9:12 PM, Rick Byers rby...@chromium.org wrote: 1) Should we extend the existing addEventListener API or change the API names (and perhaps other things) completely. https://github.com/RByers/EventListenerOptions/issues/18 It seems most other DOM peers are okay with

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

On Thu, Jul 9, 2015 at 5:15 PM, Rick Byers rby...@chromium.org wrote: I think there's a big opportunity to substantially improve scroll performance on the web in the relatively short term by doing something incremental. I.e. I'm pretty sure I can get major scroll-blocking libraries like

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

On Thu, Jul 9, 2015 at 3:58 PM, Rick Byers rby...@chromium.org wrote: I'd love to hear other ideas! Well, we have had some discussions in the past about introducing a better event API: https://gist.github.com/annevk/5238964 Maybe the time has come... (I agree with Philip that if we add this

Re: [whatwg] IPv4 parsing

On Wed, Jun 24, 2015 at 10:56 PM, Ryan Sleevi sle...@google.com wrote: [...] All the forms except for decimal octets are seen as non-standard (despite being quite widely interoperable) and undesirable. They are no longer non-standard, though still non-conforming. Or, in other words,

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

On Mon, Jun 29, 2015 at 5:14 PM, Majid Valipour maji...@chromium.org wrote: Do you have a preference one way or another for either of the above APIs? Not really. The fact that history and navigation is not really cross-browser makes me a bit wary about extending it further, since we obviously

Re: [whatwg] IPv4 parsing

On Wed, Jun 24, 2015 at 3:46 AM, timeless timel...@gmail.com wrote: Also fun and probably worth documenting is how http://127.1/ and http://127.2.1/ are parsed. I doubt the average developer knows (unless they specifically deal with low level networking). The question is whether the parsing

Re: [whatwg] IPv4 parsing

On Wed, Jun 24, 2015 at 9:06 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: You swap between 0.0.0.66 and 66.0.0.0 in your OP. Actually, the input URL in that case is different. 0x42.0. != 0x42. -- https://annevankesteren.nl/

[whatwg] IPv4 parsing

I've done some research into how Chrome parses IPv4 addresses to see if that's worth standardizing. Most browsers do not have special parsing rules for IPv4 vs domain names. That is, they pass the domain name to the network layer and let that figure out what should happen. Typically, that results

Re: [whatwg] Icon mask and theme color

On Thu, Jun 18, 2015 at 7:19 PM, Edward O'Connor eocon...@apple.com wrote: On the other hand, link rel=mask-icon color=darkslategray seems like it should Just Work™. I guess we could add support for named colors to input type=color too. -- https://annevankesteren.nl/

Re: [whatwg] A mask= advisory flag for link rel=icon

On Wed, Jun 17, 2015 at 9:42 PM, Benjamin Francis bfran...@mozilla.com wrote: It makes sense to me, an image element can have a src attribute of image.jpg and have a mask set to mask.svg in the mask CSS property. The equivalents here are the href attribute and the mask attribute, It's just

Re: [whatwg] A mask= advisory flag for link rel=icon

On Wed, Jun 17, 2015 at 9:23 PM, Maciej Stachowiak m...@apple.com wrote: (A.2) Add an attribute to link specifically for use in specifying the color for that icon, e.g. link rel=mask-icon href=whatever.svg color=lightred. (B.1) If the the color isn’t specified using the A method, use the theme

[whatwg] Relative URL plan

I've been trying to figure out a better data model for URLs so we can handle relative URLs for any scheme. The motivation for supporting relative URLs for any scheme can be found here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27233 Per my testing the URL parser would still need special

Re: [whatwg] Relative URL plan

On Tue, Jun 16, 2015 at 7:51 PM, Boris Zbarsky bzbar...@mit.edu wrote: about: is not standardized enough across UAs to really reason about. about and mailto are the reasons query is split out. Not so much that you can set it (you can't), but so that you can reason about it independently. And

Re: [whatwg] Relative URL plan

On Tue, Jun 16, 2015 at 6:52 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/16/15 8:06 AM, Anne van Kesteren wrote: I also think we should change the API such that you cannot change anything for non-relative URLs Why would you disallow setting fragment for a non-relative URL? You're right

Re: [whatwg] Relative URL plan

On Tue, Jun 16, 2015 at 7:01 PM, Boris Zbarsky bzbar...@mit.edu wrote: What are examples of non-relative URIs that use query? mailto:, I guess? about, data, etc. Though note that there's no such thing as non-relative URL. That completely depends on the first code point after the scheme and : in

Re: [whatwg] Relative URL plan

On Tue, Jun 16, 2015 at 8:18 PM, Boris Zbarsky bzbar...@mit.edu wrote: Why can't you? If it's something you want to reason about as a separate entity, why doesn't it make sense to set it as a separate entity? Actually, it seems like you can, though that would equally affect data URLs, but

Re: [whatwg] Relative URL plan

On Tue, Jun 16, 2015 at 8:29 PM, Boris Zbarsky bzbar...@mit.edu wrote: What optimizations are we talking about here, specifically? Not sure. Was just indicating that we have that option if it would be particularly painful/pointless/footgun. I haven't exactly thought it through and there's not

Re: [whatwg] A mask= advisory flag for link rel=icon

On Tue, Jun 16, 2015 at 10:42 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Before we start bikeshedding, can you commit to actually changing your implementation? Safari has already shipped with the exact proposal given in this thread; if you're seeking a rubberstamp rather than a collab,

Re: [whatwg] Icon mask and theme color

On Mon, Jun 15, 2015 at 12:18 PM, Kornel Lesiński kor...@geekhood.net wrote: The new Safari is still only a preview, so I hope Apple will switch to a better solution. It would be great if we could get some feedback from Ted colleagues on what the thinking here was. --

Re: [whatwg] Icon mask and theme color

On Mon, Jun 15, 2015 at 7:33 PM, Edward O'Connor eocon...@apple.com wrote: Our proposal is simply to add mask= to this list of advisory attributes that are used to determine an icon's appropriateness here. User agents that don't understand mask= should continue to pick the most appropriate

Re: [whatwg] Regarding spec clarification on dispatching click event on disabled form controls

On Thu, May 7, 2015 at 12:21 PM, Ramya Vadlamudi ramy...@samsung.com wrote: https://html.spec.whatwg.org/multipage/forms.html#concept-fe-disabled A form control that is disabled must prevent any click events that are queued on the user interaction task source from being dispatched on the

Re: [whatwg] Regarding spec clarification on dispatching click event on disabled form controls

On Fri, May 8, 2015 at 12:07 PM, Ramya Vadlamudi ramy...@samsung.com wrote: Is there any specific reason to prevent click events that are queued on the user interaction task source only? Presumably that's the legacy behavior. What should be the behavior of other events like

Re: [whatwg] Case-sensitivity of CSS type selectors in HTML

On Fri, May 8, 2015 at 7:09 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: I don't think ascii case-insensitivity is a mistake here. (ASCII) case-insensitivity is a mistake. JavaScript doesn't have it and wherever we do have it it's sticking out as sore thumb with a dozen subtleties attached.

Re: [whatwg] Case-sensitivity of CSS type selectors in HTML

On Thu, May 7, 2015 at 11:23 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Well, beyond the existing conflicts of style, script, and a. (font too, but that's dropped from SVG2, so who cares.) textArea is out too? With respect to case-insensitive matching, I don't really understand why we

[whatwg] Outstanding URL bugs

I won't have much time to work on URLs until July most likely. However, I was asked to provide an update of sorts with respect to changes that are planned: * Support relative URLs outside of the whitelist of relative schemes. We'll still need special parsing rules for the relative schemes, and

Re: [whatwg] Storage Standard

On Fri, May 1, 2015 at 9:40 PM, Jonas Sicking jo...@sicking.cc wrote: Can't we use the permission API [1] for this? I.e. use the permission name persistent-storage or some such? So rather than default we're return prompt. [1] https://w3c.github.io/permissions/ I'm sorry, what do you mean by

Re: [whatwg] Storage Standard

On Mon, May 4, 2015 at 9:47 PM, Jonas Sicking jo...@sicking.cc wrote: By this I mean the API discussed in this thread :) Well this thread is for the Storage Standard, which has several APIs. More specifically, I'm proposing to remove the persistentPermission() function in favor of using

[whatwg] Storage Standard

Based on the discussion on this list and on: https://wiki.whatwg.org/wiki/Storage https://github.com/slightlyoff/StorageDurability Here's a first draft: https://storage.spec.whatwg.org/ https://github.com/whatwg/storage https://twitter.com/storagestandard It does not address multiple

[whatwg] EventSource and data URLs

Currently Chrome supports data URLs inside EventSource whereas in Firefox EventSource is restricted to http/https URLs: https://bugzilla.mozilla.org/show_bug.cgi?id=1156137 What's the convergence we want here? -- https://annevankesteren.nl/

Re: [whatwg] Fetch, MSE, and MIX

I removed some people from the cc. The WHATWG list seems to bite. On Thu, Apr 16, 2015 at 6:57 PM, Ryan Sleevi sle...@google.com wrote: I think as we look to provide a compelling story for EME over wholly-proprietary (... rather than partially-proprietary) solutions, or look to improve the

Re: [whatwg] Fetch, MSE, and MIX

On Wed, Apr 15, 2015 at 6:45 PM, Martin Thomson martin.thom...@gmail.com wrote: I believe that the easiest way to avoid this is to make an attempt to read Response.body raise a SecurityError if the origin is different (in Firefox terms, we would say if the response principal is not subsumed by

Re: [whatwg] Fetch, MSE, and MIX

On Mon, Apr 13, 2015 at 10:34 PM, Matthew Wolenetz wolen...@google.com wrote: Certainly. As I understand it, the reasons for reusing appendStream() rather than adding appendResponse() to MSE are generally two-fold: a) MSE already has appendStream(). In combination with the other changes to

Re: [whatwg] Fetch, MSE, and MIX

On Tue, Apr 14, 2015 at 9:38 PM, Domenic Denicola d...@domenic.me wrote: I also imagine it won't be too hard to spec, as the point of an opaque stream type is that most of its methods consist of magic happens here (roughly speaking). Well, we also need to ensure that nothing that takes a

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

On Thu, Apr 9, 2015 at 9:05 PM, Ian Hickson i...@hixie.ch wrote: I'd strongly recommend against adding new methods. It'll mean we now have two different ways to do the same thing, which means more bugs, which means less interoperability, more confusing behaviour for authors, more to document,

Re: [whatwg] Fetch, MSE, and MIX

On Sat, Apr 11, 2015 at 12:24 AM, Matthew Wolenetz wolen...@google.com wrote: After further internal discussion, we believe we can and should reuse appendStream() rather than adding appendResponse(). For those not privy, could you share the reasoning? -- https://annevankesteren.nl/

Re: [whatwg] Modify the Page Visibility spec to let UA's take into account whether iframes are visible on the screen

On Tue, Mar 31, 2015 at 12:47 AM, Seth Fowler s...@mozilla.com wrote: I think we should modify the Page Visibility spec to let UA’s take actual visibility of iframes into account when deciding if an iframe is hidden. Wouldn't it be better to discuss that on public-web-perf? --

Re: [whatwg] Persistent and temporary storage

On Wed, Mar 18, 2015 at 1:38 AM, Krinkle krinklem...@gmail.com wrote: I'd like to share a use case and problem we have at Wikipedia with localStorage. Thanks, this is great feedback. I imagine HTTP2 might make it appropriate to phase out batches and just request modules individually

Re: [whatwg] Array as first argument to fetch()

On Fri, Mar 27, 2015 at 1:28 PM, Brett Zamir bret...@yahoo.com wrote: Since fetch() is making life easier as is and in the spirit of promises, how about taking it a step further to simplify the frequent use case of needing to retrieve multiple resources and waiting for all to return? If the

Re: [whatwg] Array as first argument to fetch()

On Fri, Mar 27, 2015 at 1:50 PM, Brett Zamir bret...@yahoo.com wrote: Thanks, I realize it's doable that way, but I think it makes for less distracting code when the implementation details of the map call and such are avoided for something as basic as loading resources... Write a function that

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

On Thu, Mar 26, 2015 at 1:22 AM, Majid Valipour maji...@google.com wrote: My only concern is to make sure that these new methods replace history.pushState() and history.replaceState() in the spec. Otherwise I feel the benefits of a cleaner API is not worth the additional confusion of having

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

On Thu, Mar 26, 2015 at 3:57 PM, Majid Valipour maji...@google.com wrote: That is fair. Assuming clear documentation helps alleviate potential confusion I am fine with deprecation route. I suppose the purpose of the spec is to not only document the current recommended behavior but also capture

Re: [whatwg] Seamless browsing context in object elements

On Tue, Mar 24, 2015 at 11:06 PM, Andrea Rendine master.skywalker...@gmail.com wrote: Is there a reason why it does not apply to object browsing contexts? Yes. object does too much (it can handle both browsing contexts and embedding contexts) and therefore we shouldn't extend it more. Both

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

On Thu, Mar 19, 2015 at 6:31 PM, Majid Valipour maji...@chromium.org wrote: partial interface History { void pushState(in any data, in DOMString title, in optional DOMString url, in optional StateOptions options); void replaceState(in any data, in DOMString title, in optional DOMString

Re: [whatwg] Responsive image maps

On Wed, Mar 25, 2015 at 3:21 PM, Andrea Rendine master.skywalker...@gmail.com wrote: Yes, I think I should have expressed it better. Why not improving *this* specific feature? That's generally not how we do things. We don't start looking at an existing set of features and figure out how we can

Re: [whatwg] Canvas image to blob/dataurl within Worker

On Fri, Mar 20, 2015 at 11:15 PM, Robert O'Callahan rob...@ocallahan.org wrote: My understanding is that the current consensus proposal for canvas in Workers is not what's in the spec, but this: https://wiki.whatwg.org/wiki/WorkerCanvas See Canvas in Workers threads from October 2013 for the

Re: [whatwg] Persistent and temporary storage

On Mon, Mar 16, 2015 at 5:23 PM, Joshua Bell jsb...@chromium.org wrote: On Mon, Mar 16, 2015 at 1:38 AM, Anne van Kesteren ann...@annevk.nl wrote: But that for persistent it can be the whole disk. ... and we're waffling on that one. Going that far implies that the UA does a really good job

Re: [whatwg] Persistent and temporary storage

On Fri, Mar 13, 2015 at 3:25 PM, Janusz Majnert j.majn...@samsung.com wrote: On 13.03.2015 15:01, Anne van Kesteren wrote: The reason developers want it is to know how much they can download and store without getting an exception. Which still doesn't guarantee they won't get an exception

Re: [whatwg] Persistent and temporary storage

On Fri, Mar 13, 2015 at 5:06 PM, Joshua Bell jsb...@chromium.org wrote: A handful of us working on Chrome have been having similar discussions around what we've been calling durable storage. In its simplest model a bit granted by the user to an origin, which then requires explicit user action

Re: [whatwg] Persistent and temporary storage

On Mon, Mar 16, 2015 at 4:12 AM, Biju bijumaill...@gmail.com wrote: At present data stored in indexDB is written some where deep in the profile folder, which is difficult to find. I don't think we should expect our users to traverse the directory structure at all. We need to expose UI to manage

[whatwg] Persistent and temporary storage

A big gap with native is dependable storage for applications. I started sketching the problem space on this wiki page: https://wiki.whatwg.org/wiki/Storage Feedback I got is that having some kind of allotted quota is useful for applications. That way they know how much they can put away.

Re: [whatwg] Persistent and temporary storage

On Fri, Mar 13, 2015 at 2:58 PM, Janusz Majnert j.majn...@samsung.com wrote: The real question is why having a quota is useful? The reason developers want it is to know how much they can download and store without getting an exception. Native apps are not controlled when it comes to storing

Re: [whatwg] Effect of image-orientation on naturalWidth/Height

On Tue, Mar 10, 2015 at 12:01 AM, Seth Fowler s...@mozilla.com wrote: I wanted to get the opinion of this list on how image-orientation and the img element’s naturalWidth and naturalHeight properties should interact. I thought there was some agreement that image-orientation ought to be a

[whatwg] MessageEvent and ports

Can someone explain why the postMessage() design exposes transfered ports both in .data and .ports? If that's a legacy artifact, can we call that out somewhere? (Asking around on IRC suggests it's an artifact that needs to be preserved by new variations of the postMessage() design, as e.g. seen

Re: [whatwg] iframe async

On Fri, Feb 27, 2015 at 7:52 PM, Fady Samuel fsam...@chromium.org wrote: This is obviously larger than the particular set of use cases mentioned here, but another set of iframe discussions I've seen lately have centered around going off thread or out of process. I wonder if there is a more

Re: [whatwg] iframe async

On Fri, Feb 27, 2015 at 7:31 PM, Ashley Gullen ash...@scirra.com wrote: Perhaps independent is a better name than async, indicating the iframe content is independent of the main page. Browser loading UI, load events, fast back and possibly performance tools would not take in to account

Re: [whatwg] iframe async

On Fri, Feb 27, 2015 at 3:59 PM, David Bruant bruan...@gmail.com wrote: The request is to being able to provide different priority orders to different iframes (some containing not important content like ads, others containing important content) while what I'm suggesting treats all iframes the

Re: [whatwg] iframe async

On Fri, Feb 27, 2015 at 4:37 PM, David Bruant bruan...@gmail.com wrote: The exact same question stands for implementors of the current proposal. Until what point should a browser delay loading the iframe? The difference being that the author knows the relative importance of the various

Re: [whatwg] iframe async

On Fri, Feb 27, 2015 at 4:15 PM, David Bruant bruan...@gmail.com wrote: To achieve this priorization, currently, authors would use a bit of JS to delay adding the iframe to the document. It seems like it solves all the issues listed in the original message (load UI, load event, fast back).

Re: [whatwg] iframe async

On Fri, Feb 27, 2015 at 4:28 PM, Boris Zbarsky bzbar...@mit.edu wrote: onload, if you don't want it to block onload. Yeah that seems like a pretty bad alternative. That would be quite a significant delay. -- https://annevankesteren.nl/

  1   2   3   4   5   6   7   8   9   10   >