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,
implemente
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 pull request or wants to make
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 position
> of an element to the
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 every
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 remove your application
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 web? If the latter, so
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 interested and wanting to w
On Tue, Apr 18, 2017 at 10:25 AM, Roger Hågensen 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
>> URLs and we
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, those are about making appl
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 decisions.
> I think "p
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 or part of the web
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 mailto: URLs) is o
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 since an admin-ish interface is
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 to
> "lose" this custom UI on
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 like to do
>
> form.addEventL
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 issue
> https://githu
On Fri, Mar 3, 2017 at 11:01 PM, Alex Jordan 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.
>
> Great, thanks! I
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 concrete ideas thus fa
On Wed, May 25, 2016 at 7:32 AM, Михаил Гаврилов
wrote:
> I propose to standardize locale settings (datetime, number
> delimeters) can be specified only by user via the operating system
> settings. Sites should not change the locale that the user has chosen
> for himself.
There is a proposal to
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 Canadian French with the
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 requirement for the first two to
align, t
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 other English langu
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 treat as
> visible for the
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,
> there’s a delay between
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 t
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 place. And then from
there
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
> https://bugzilla.mozilla.org/show_bug.cgi?id=1231619#c3 for deta
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.)
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 trailing whitespace trimme
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/
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 eventually
> perform the actio
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 out-of-memory behavior,
period
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 instead:
>>
This is now h
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.)
Chrom
On Tue, Aug 11, 2015 at 4:08 PM, Majid Valipour wrote:
> Does anybody know if there was any specific reasons behind the current
> order?
Are the reasons you discovered yourself not sufficient? I guess the
question is whether Chrome can still change at this point and what
will happen to Safari.
On Fri, Aug 7, 2015 at 8:56 AM, Chia-Hung Tai 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 define constructors.
On Mon, Jul 13, 2015 at 3:58 PM, Majid Valipour 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 History interface
On Mon, Jul 13, 2015 at 8:09 AM, Elliott Sprehn 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 browser
> systems
On Sun, Jul 12, 2015 at 11:52 PM, Elliott Sprehn 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 of
> method like:
On Sun, Jul 12, 2015 at 7:49 PM, Jonas Sicking 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 serve a
purpose
On Sat, Jul 11, 2015 at 11:41 PM, Rick Byers 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 - less
> weird). If
On Sat, Jul 11, 2015 at 8:19 PM, Domenic Denicola 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 checks the
ev
On Fri, Jul 10, 2015 at 10:54 PM, Majid Valipour 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 semantics (e.g.,
On Fri, Jul 10, 2015 at 9:12 PM, Rick Byers 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 overloading the thir
On Thu, Jul 9, 2015 at 5:15 PM, Rick Byers 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 Google Analytics to o
On Thu, Jul 9, 2015 at 3:58 PM, Rick Byers 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 it would need to b
On Wed, Jun 24, 2015 at 10:56 PM, Ryan Sleevi 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, https://url.
On Mon, Jun 29, 2015 at 5:14 PM, Majid Valipour 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 don't really understan
On Wed, Jun 24, 2015 at 9:06 AM, Tab Atkins Jr. 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/
On Wed, Jun 24, 2015 at 3:46 AM, timeless 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 happens at the URL
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 result
On Thu, Jun 18, 2015 at 7:19 PM, Edward O'Connor wrote:
> On the other hand, seems like
> it should Just Work™.
I guess we could add support for named colors to too.
--
https://annevankesteren.nl/
On Wed, Jun 17, 2015 at 9:42 PM, Benjamin Francis 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 that in your cas
On Wed, Jun 17, 2015 at 9:23 PM, Maciej Stachowiak wrote:
> (A.2) Add an attribute to specifically for use in specifying the color
> for that icon, e.g. .
> (B.1) If the the color isn’t specified using the A method, use the theme
> color.
>
> My current preference out of these is (A.2)/(B.1).
On Tue, Jun 16, 2015 at 10:42 PM, Tab Atkins Jr. 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, say so.
Maciej alr
On Tue, Jun 16, 2015 at 8:29 PM, Boris Zbarsky 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 much feedback beyo
On Tue, Jun 16, 2015 at 8:18 PM, Boris Zbarsky 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 maybe that's not to
On Tue, Jun 16, 2015 at 7:51 PM, Boris Zbarsky 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 since non-Gecko-bro
On Tue, Jun 16, 2015 at 7:01 PM, Boris Zbarsky 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 this brave ne
On Tue, Jun 16, 2015 at 6:52 PM, Boris Zbarsky 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-
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 ha
On Mon, Jun 15, 2015 at 7:33 PM, Edward O'Connor 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 icon given the
On Mon, Jun 15, 2015 at 12:18 PM, Kornel Lesiński 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.
--
https://annevankesteren.nl/
On Fri, May 8, 2015 at 7:09 PM, Tab Atkins Jr. 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.
--
https://annevank
On Fri, May 8, 2015 at 12:07 PM, Ramya Vadlamudi 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 button.dispatchEvent(new
> Event('
On Thu, May 7, 2015 at 12:21 PM, Ramya Vadlamudi 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
> element.
>
> Which
On Thu, May 7, 2015 at 11:23 PM, Tab Atkins Jr. wrote:
> Well, beyond the existing conflicts of
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
we'
On Mon, May 4, 2015 at 9:47 PM, Jonas Sicking 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 navigator.perm
On Fri, May 1, 2015 at 9:40 PM, Jonas Sicking 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 "this"
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
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/
I removed some people from the cc. The WHATWG list seems to bite.
On Thu, Apr 16, 2015 at 6:57 PM, Ryan Sleevi 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 user experience in
On Wed, Apr 15, 2015 at 6:45 PM, Martin Thomson
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 the script principa
On Tue, Apr 14, 2015 at 9:38 PM, Domenic Denicola 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 stream and the
On Mon, Apr 13, 2015 at 10:34 PM, Matthew Wolenetz 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
> Streams API, Fetch,
On Thu, Apr 9, 2015 at 9:05 PM, Ian Hickson 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, etc.
If t
On Sat, Apr 11, 2015 at 12:24 AM, Matthew Wolenetz 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/
On Tue, Mar 31, 2015 at 12:47 AM, Seth Fowler 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?
--
https://annevankesteren.nl/
On Wed, Mar 18, 2015 at 1:38 AM, Krinkle 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 (always) and let the netw
On Fri, Mar 27, 2015 at 1:50 PM, Brett Zamir 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 abstracts it..
On Fri, Mar 27, 2015 at 1:28 PM, Brett Zamir 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 first argument
On Thu, Mar 26, 2015 at 3:57 PM, Majid Valipour 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 any legacy one
On Thu, Mar 26, 2015 at 1:22 AM, Majid Valipour 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 different methods
On Wed, Mar 25, 2015 at 3:21 PM, Andrea Rendine
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 add some flair.
Instead, we
On Thu, Mar 19, 2015 at 6:31 PM, Majid Valipour 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
> url, in optional S
On Fri, Mar 20, 2015 at 11:15 PM, Robert O'Callahan
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 discussion. svn
On Tue, Mar 24, 2015 at 11:06 PM, Andrea Rendine
wrote:
> Is there a reason why it does not apply to browsing
> contexts?
Yes. does too much (it can handle both browsing contexts and
embedding contexts) and therefore we shouldn't extend it more. Both
and are problematic for offline solutions
On Mon, Mar 16, 2015 at 5:23 PM, Joshua Bell wrote:
> On Mon, Mar 16, 2015 at 1:38 AM, Anne van Kesteren 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 goo
On Mon, Mar 16, 2015 at 4:12 AM, Biju 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 sites in
about:prefe
On Fri, Mar 13, 2015 at 3:25 PM, Janusz Majnert 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
On Fri, Mar 13, 2015 at 5:06 PM, Joshua Bell 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 before the dat
On Fri, Mar 13, 2015 at 2:58 PM, Janusz Majnert 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 data and nobody com
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.
Howeve
On Tue, Mar 10, 2015 at 12:01 AM, Seth Fowler wrote:
> I wanted to get the opinion of this list on how image-orientation and the
> element’s naturalWidth and naturalHeight properties should interact.
I thought there was some agreement that image-orientation ought to be
a markup feature as it af
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
i
On Fri, Feb 27, 2015 at 7:31 PM, Ashley Gullen 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
> independent ifr
On Fri, Feb 27, 2015 at 7:52 PM, Fady Samuel 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
> basic primitive here
On Fri, Feb 27, 2015 at 4:37 PM, David Bruant 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 iframes among themse
On Fri, Feb 27, 2015 at 4:28 PM, Boris Zbarsky 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 - 100 of 1841 matches
Mail list logo
