Re: [whatwg] Icon mask and theme color
On Thu, Jun 18, 2015, at 19:19, Edward O'Connor wrote: Maciej replied: I find this use case pretty compelling. There’s no reasonable set of processing steps that could get you salmon pink for use as a background, but black for use as a foreground. I think this is compelling evidence that it needs to be at least possible to specify a mask icon color relative to the theme color. Yeah, I agree. I wish we had a time machine to rename theme-color to theme-background-color! :) Allow me to toot my own horn: https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jun/0144.html --tobie
Re: [whatwg] Shared storage
On Tue, Oct 28, 2014 at 6:33 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 15 Feb 2014, Brett Zamir wrote: The desktop PC thankfully evolved into allowing third-party software which could create and edit files shareable by other third-party software which would have the same rights to do the same. The importance of this can hardly be overestimated. Yet today, on the web, there appears to be no standard way to create content in such an agnostic manner whereby users have full, built-in, locally-controlled portability of their data. Why can't you just do the same as used to be done? Download the resource locally (save, using a href download), then upload it to the new site (open, using input type=file)? Because that's a terrible user experience? --tobie
Re: [whatwg] Web API for Health Sensors
On Wed, Oct 8, 2014 at 9:40 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Indeed, a Web Bluetooth API would be a great start! Also, we are writing standards here, so standardizing the communication of the data between the devices and UAs would be useful. Both would probably fall within the work of a device API group like http://www.w3.org/2009/dap/ , where media capture was standardized. Absolutely. This seems to tie in pretty well with the Generic Sensor API discussion planned at this year's TPAC[1]. --tobie --- [1]: https://www.w3.org/wiki/TPAC2014/SessionIdeas#Generic_Sensor_API
Re: [whatwg] Notifications: making requestPermission() return a promise
On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
The question is whether it's not natural to assume that *if the promise
fulfills*, that means they got permission. This allows them to do things
like using Promise.all() to join multiple permission requests together and
get a nice combined promise that fulfills when everything succeeds,
This is as simple as:
Promise.all(permissionRequests).then(function(results) {
if (results.every(x = x === granted)) // …
});
But I don't think it's the right approach to handling permissions in
general. Developers should handle granted permissions as progressive
enhancements, not balk when they don't get all the permissions they
required. Using exceptions for denied permissions sends a completely wrong
message imho, especially when it's combined with Promise.all.
--tobie
Re: [whatwg] Notifications: making requestPermission() return a promise
On Wed, Oct 8, 2014 at 5:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Oct 8, 2014 at 1:31 AM, Tobie Langel tobie.lan...@gmail.com
wrote:
On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
The question is whether it's not natural to assume that *if the promise
fulfills*, that means they got permission. This allows them to do things
like using Promise.all() to join multiple permission requests together
and
get a nice combined promise that fulfills when everything succeeds,
This is as simple as:
Promise.all(permissionRequests).then(function(results) {
if (results.every(x = x === granted)) // …
});
But I don't think it's the right approach to handling permissions in
general. Developers should handle granted permissions as progressive
enhancements, not balk when they don't get all the permissions they
required. Using exceptions for denied permissions sends a completely
wrong
message imho, especially when it's combined with Promise.all.
I don't think moral arguments really have a place here. Whatever
mitigation code that authors write to handle failed permissions can go
in the reject handler exactly as easily as in the fulfill handler.
That we believe authors should handle permission failures
intelligently doesn't, itself, mean that we should make the success
path less convenient.
I don't see how your definition of success is less of a moral argument than
mine, but I'm happy to be enlightened.
--tobie
Re: [whatwg] Notifications: making requestPermission() return a promise
On Wed, Oct 1, 2014 at 5:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: I've never heard this opinion explicitly expressed, and it has never shown up in any API reviews of promise-using specs. It's directly contrary to the way that existing non-promise async APIs are constructed, and I expect quite contrary to most people's expectations. I'm with Domenic, here. We had these conversations for the Service Worker Cache's .match() method and dropped promise rejection in favor of resolving with null when a relevant Response object couldn't be found in the cache. Rejecting the promise was left for truly exceptional cases, such a data corruption issues. I agree with you that the code branching provided by the resolve/reject pair looks appealing at first, but it's terrible once awaits comes in the picture.
Re: [whatwg] Notifications: making requestPermission() return a promise
On Wed, Oct 1, 2014 at 7:22 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Note that Python, for example, throws errors on dict keys not being found (unless you specifically tell it a sentinel value to return instead). Do you think that's terrible? Sure. But JS doesn't.
Re: [whatwg] Notifications: making requestPermission() return a promise
On Wed, Oct 1, 2014 at 11:43 PM, Anne van Kesteren ann...@annevk.nl wrote: Given async/await the only reasonable thing to do seems to me to model them after functions and only use rejection for something exceptional, but with the level of disagreement this has created in several different standards group thus far, I'm not hopeful initial promise APIs will be consistent in this. If that's not work for the TAG, then I don't know what their purpose is. Seriously, there needs to be agreement and consistency here, and unless there a design guidelines adopted across the board, this is just going to suck for Web developers. --tobie
Re: [whatwg] `brand-color` meta extension
On Jun 26, 2014, at 21:20, Marcos Caceres w...@marcosc.com wrote: On June 26, 2014 at 1:58:17 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote: Here's a first crack at a better spec: Moved your text here: https://github.com/whatwg/meta-brand-color Could we change the name to something a tad more neutral and extendable, e.g.: ua-background-color? Like that, people that use the Web for things other than brand promotion don't feel offended, and we can add ua-color once devs start requesting it while keeping consistent with CSS. --tobie
Re: [whatwg] Fetch: use separate methods instead of one `to` method in FetchBodyStream
On Wed, Jun 18, 2014 at 12:08 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Jun 16, 2014 at 6:57 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
var doesFetchSupportJson = function () {
return fetch(data:application/json;base64,e30=).then(function
(response) {
return response.body.to(json);
}).then(function () {
return true;
}).catch(function () {
return false;
});
};
I agree with this. We're told time and again that feature detection is
important, as is the ability to polyfill. It seems like the current
API fails both these tests.
Likewise.
What's the rationale for using a string here instead of separate methods?
--tobie
Re: [whatwg] HTTP status code from JavaScript
On May 25, 2014, at 8:59, Michael Heuberger
michael.heuber...@binarykitchen.com wrote:
Thanks Silvia for your comment but I think we turn in circles.
I know you mean it well but this is not the case as I mentioned it over
and over again in my previous emails.
Let me repeat, the whole SPA of mine is always loaded, no matter if it's
a 404 or not so that a nice 404 can be rendered on the client-side. No
piece is missing here. To make this work, Javascript needs to be able to
have access to the HTTP status code of the initial page load. I can
count more reasons or read my previous emails.
Something like `window.http.status` would be really awesome.
Why can't you just set that value server-side (e.g. In a meta tag or
even using a script tag) and retrieve it on the client? E.g. In pseudo
PHP:
scriptvar http = { status: ?php print response-status php};/script
--tobie
Re: [whatwg] HTTP status code from JavaScript
Hi again, On May 25, 2014, at 9:35, Michael Heuberger michael.heuber...@binarykitchen.com wrote: * It is a redundancy. The browser already knows the status code, just not JavaScript. That argument can equally well be used the other way round: it's a redundancy to expose in JS something that be easily exposed by the server. * Adding inline JS script slows down the page load. In that case, use a meta tag: meta name=http-status content=404 Then in JS: var status = parseInt(document.querySelector(meta[name=http-status]).getAttribute(content)); Should this pattern become pervasive, it might bathe sense to standardize it and expose it in JS. Frankly, though, it's the first time I hear of such a request. --tobie
Re: [whatwg] Proposal: navigator.cores
On May 4, 2014, at 7:45, Rik Cabanier caban...@gmail.com wrote: On Sat, May 3, 2014 at 10:32 PM, Eli Grey m...@eligrey.com wrote: The proposal specifically states using logical cores, which handles all of the CPUs you mentioned properly. Intel CPUs with hyperthreading enabled report logical cores as double the hardware cores. Depending on the version and configuration of the Samsung Exynos Octa big.LITTLE CPUs, you will get either 4 logical cores (only one cluster can run at a time) or 8 logical cores (big.LITTLE MP, available in Exynos 5420 or later only). Great! Make sure this is captured when it is put in a specification. Otherwise the subtlety between an actual and a logical core might get lost. Shouldn't this also be captured in the API's name? --tobie
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thursday, October 31, 2013 at 12:42 PM, Anne van Kesteren wrote: Should really have a way to file a bug on all browsers whenever something like this comes up... Yes please. --tobie
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thursday, October 31, 2013 at 4:27 PM, Ms2ger wrote: On 10/31/2013 04:13 PM, Boris Zbarsky wrote: In particular, I don't believe browser vendors typically run W3C test suites en masse regularly, Just going to note here that James Graham is, in fact, working on doing that for Mozilla. … and a similar effort is happening for Blink. --tobie
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thursday, October 31, 2013 at 5:07 PM, Bjoern Hoehrmann wrote: * Boris Zbarsky wrote: If the goal is to get browsers to implement, how is it more valuable? Browser vendors ignore W3C test suites to an even greater extent than they ignore bug reports. In particular, I don't believe browser vendors typically run W3C test suites en masse regularly, whereas they do regularly look at the bug reports that get filed on them. My purpose was to lament that we currently lack the infrastructure needed so that people interested in new features or other changes can contribute tests for those features and changes to such suites. That very much includes that many of the existing suites suck badly. That would have many benefits, for instance, it makes it easy to track the implementation status of something across many implementations, which is information that web developers critically need, and it helps to identify cases where one browser is the odd one out. I would rather people help us work on tests than helping Anne fill out web forms. Such an infrastructure is in the process of being built[1]. See the Test the Web Forward effort[2] which now regroups all of Open Web platform testing[3]. You're welcome to contribute. --tobie --- [1]: http://testthewebforward.org/blog/2013/02/20/testing-the-open-web-platform.html [2]: http://testthewebforward.org/ [3]: http://testthewebforward.org/blog/2013/10/30/welcoming-testtwf-to-w3c.html
Re: [whatwg] The behaviour of Notification.requestPermission() in Workers
On Thursday, October 24, 2013 at 11:05 AM, Anne van Kesteren wrote: On Thu, Oct 24, 2013 at 2:19 AM, Nikhil Marathe nsm.nik...@gmail.com (mailto:nsm.nik...@gmail.com) 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() is not defined. 2) requestPermission() does not ask the user, but uses the permission associated with that origin, or denied. I believe option 2 is better in terms of having a complete API. Feedback is appreciated about what the right approach should be. Given that Notificaiton.permission exists, I'm not sure what the additional value of Notification.requestPermission() in a worker context would be. Portability of code between worker and non worker? --tobie
Re: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll
On Wednesday, September 18, 2013 at 5:27 PM, Glenn Maynard wrote: On Wed, Sep 18, 2013 at 7:18 AM, Niels Keurentjes niels.keurent...@omines.com (mailto:niels.keurent...@omines.com) wrote: The spec should only concern itself with exposing functionality. Practical considerations such as length of code are the responsibility of the developer - if you like to have q and qq aliases you can add them yourself at runtime, that's the whole point of a prototyped language. Common libraries like jQuery, prototype and Mootools expose the behaviour as $ and $$ for exactly the reason given, no reason to impose that on every developer if they choose not to use a library. This is nonsense. Usability and practicality are absolutely concerns of the spec. If libraries like jQuery need to be used for it to be convenient to develop for the platform, and everyone has different and incompatible convenience wrappers for everything, then that's a failure of the platform. (I don't think this proposal is a good idea, though.) ^ this. --tobie
Re: [whatwg] Forcing orientation in content
On Tuesday, September 10, 2013 at 11:22 PM, Ian Hickson wrote:
On Sat, 13 Jul 2013, Tobie Langel wrote:
It is not uncommon for mobile experiences to rely on the accelerometer
as an input mechanism, for example to control page scrolling (e.g.
Instapaper) or for gameplay.
In such cases, auto-rotation of the viewport is completely disruptive to
the user's experience and needs to be inhibited.
Sure, but that's an OS-level feature.
Arguably. Signaling auto-rotation inhibited requirements isn't, though. That's
application-level. Auto-rotation inhibition needs to be automatic and scoped to
the document.
So this isn't so much about forcing orientation as it is about
inhibiting auto-rotation.
This would only work if the page was already in the orientation the user
wants, but how can we ensure that?
The UA is free to provide whatever UI it wants to allow the user to
enable/disable auto-rotation inhibition and/or pick a preferred orientation.
From the use cases can be derived requirements for the content author to be
able to signal to the UA the preference to inhibit auto-roation. Whether the UA
decides to comply to this stated pref, allow its user to override it, etc.
should be implementation-specific.
Your desktop comparison is inadequate, as there aren't comparable
auto-rotation mechanisms there.
It would be equivalent to forcing a particular window size.
No. A better analogy is the autoplay feature of video elements. Merely a hint
that can be overridden by the user/UA.
And frankly even that comparison is dodgy: playing a video doesn't have close
to the discoverability and usability issues inhibiting auto-rotation at the OS
level has.
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 the screen), maybe it
should be tied to the Fullscreen API?
element.requestFullscreen({orientation:'landscape', autorotation:false})
That makes sense to me. Anne?
Agreed these requirements are generally tied to fullscreen/absence of
browser-chrome context. Unfortunately, this is achieved using a variety of AP
across implementations (e.g. iOS/Android?). So this proposition would only
cater to those situation where the fullscreen API was used.
--tobie
Re: [whatwg] Proposal: location.parentOrigin
On Tuesday, July 16, 2013 at 7:53 PM, Ian Hickson wrote: Can't you do window.isSameOrigin by just trying to access window.location.href and seeing if you get an exception? Unfortunately not, because of the previously mentioned WebKit bug which logs an error message but doesn't throw (so there's no way of knowing whether an exception was thrown or not). --tobie
Re: [whatwg] Forcing orientation in content
On Friday, July 12, 2013 at 9:45 PM, Ian Hickson wrote: On Thu, 18 Apr 2013, David Bruant wrote: Currently working on a web project where tablet support (iPad especially) is important, I'm facing a need which apparently the platform doesn't support. I would need to lock the screen in landscape mode. Why? As a user on desktop, I can resize my window however I want, to be landscape or portrait. Why wouldn't I be allowed to do the same on any other device? It is not uncommon for mobile experiences to rely on the accelerometer as an input mechanism, for example to control page scrolling (e.g. Instapaper) or for gameplay. In such cases, auto-rotation of the viewport is completely disruptive to the user's experience and needs to be inhibited. So this isn't so much about forcing orientation as it is about inhibiting auto-rotation. Your desktop comparison is inadequate, as there aren't comparable auto-rotation mechanisms there. --tobie
Re: [whatwg] asynchronous JSON.parse
On Friday, March 8, 2013 at 10:44 AM, Robin Berjon wrote:
On 07/03/2013 23:34 , Tobie Langel wrote:
Wouldn't some form of event-based API be more indicated? E.g.:
var parser = JSON.parser();
parser.parse(src);
parser.onparse = function(e) { doSomething(e.data); };
I'm not sure how that snippet would be different from a single callback API.
There could possibly be value in an event-based API if you could set it
up with a filter, e.g. JSON.filtered($.*).then(function (item) {});
which would call you for ever item in the root object. Getting an event
for every information item that the parser processes would likely flood
you in events.
Agreed, you need something higher-level than just JSON tokens. Which is why
this can be very much app-specific, unless most of the use cases are to parse
data of a format similar to [Object, Object, Object, ..., Object]. This could
be special-cased so as to send each object to the event handler as it's parsed.
--tobie
Re: [whatwg] asynchronous JSON.parse
I'd like to hear about the use cases a bit more.
Generally, structured data gets bulky because it contains more items, not
because items get bigger.
In which case, isn't part of the solution to paginate your data, and parse
those pages separately?
Even if an async API for JSON existed, wouldn't the perf bottleneck then simply
fall on whatever processing needs to be done afterwards?
Wouldn't some form of event-based API be more indicated? E.g.:
var parser = JSON.parser();
parser.parse(src);
parser.onparse = function(e) {
doSomething(e.data);
};
And wouldn't this be highly dependent on how the data is structured, and thus
very much app-specific?
--tobie
On Thursday, March 7, 2013 at 11:18 PM, David Rajchenbach-Teller wrote:
(Note: New on this list, please be gentle if I'm debating an
inappropriate issue in an inappropriate place.)
Actually, communicating large JSON objects between threads may cause
performance issues. I do not have the means to measure reception speed
simply (which would be used to implement asynchronous JSON.parse), but
it is easy to measure main thread blocks caused by sending (which would
be used to implement asynchronous JSON.stringify).
I have put together a small test here - warning, this may kill your browser:
http://yoric.github.com/Bugzilla-832664/
While there are considerable fluctuations, even inside one browser, on
my system, I witness janks that last 300ms to 3s.
Consequently, I am convinced that we need asynchronous variants of
JSON.{parse, stringify}.
Best regards,
David
Glenn Maynard wrote
(It's hard to talk to somebody called j, by the way. :)
On Thu, Mar 7, 2013 at 2:06 AM, j at mailb.org (http://mailb.org) wrote:
right now JSON.parse blocks the mainloop, this gets more and more of an
issue as JSON documents get bigger
Just load the data you want to parse inside a worker, and perform the
parsing there. Computationally-expensive work is exactly something Web
Workers are meant for.
and are also used as serialization
format to communicate with web workers.
There's no need to serialize to JSON before sending data to a worker;
there's nothing that JSON can represent that postMessage can't post
directly. Just postMessage the object itself.
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
Re: [whatwg] Canvas: dash list API
On Sat, Dec 22, 2012 at 2:57 PM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, Dec 22, 2012 at 2:43 PM, Cameron McCormack c...@mcc.id.au wrote: On 23/12/12 12:40 AM, Anne van Kesteren wrote: I guess dashList is somewhat simpler, but I think it would be nice if it still did type coercion. In that case, I guess we are reliant on whatever ES-allowed Array extending is possible, and I haven't followed that for a bit. Is this actually possible now? The feedback I got on es-discuss was https://mail.mozilla.org/pipermail/es-discuss/2012-December/027248.html which seems to suggest to create our own kind of object that looks like an Array. That seems however somewhat cumbersome to do each time we need something simple. I guess I should ask some more questions there. Array-like objects which don't inherit from the Array object and are thus missing methods one would expect to find on them (forEach, join, etc.) is one of the biggest WTF of the Web platform. We should be doing whatever it takes to fix this. --tobie
Re: [whatwg] Standardizing Console object
On Tue, Dec 18, 2012 at 7:09 PM, Rick Waldron waldron.r...@gmail.comwrote: Has there been any work or discussion with regard to standardizing the Console object? FWIW, the Browser Testing and Tools Working Group is chartered to work on it, but I don't know whether there's actual work going on or not. --tobie --- [1]: http://www.w3.org/2011/08/browser-testing-charter.html
Re: [whatwg] API for unique identification of devices (mobile/tablet/pc)
On Dec 13, 2012, at 8:42 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 13 Dec 2012, Stan wrote: The reasoning for this API is the need to uniquely identify every device in many web-applications. Why do you need to identify the device? What about if the user uses the same browser profile on multiple devices? More than half of our users login with multiple user agents on a given day. Or multiple browser profiles on the same device? Perhaps surprisingly, that's a highly common scenario on mobile devices, particularly out of the US. -- tobie
Re: [whatwg] Proposal: location.parentOrigin
On Tue, Nov 20, 2012 at 6:47 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 26 Mar 2012, Adam Barth wrote: For nested browsing contexts, expose the origin of the parent browsing context via location.parentOrigin. (For non-nested browsing context, the property would null.) This ended up implemented in WebKit as Location.ancestorOrigins(), a method that returns a static DOMStringList with the origins of the ancestor browsing contexts in reverse order (top-level browsing context last, parent browsing context first). It doesn't respect sandboxing. This API is painful to use and doesn't contain any info for window.opener or sibling browsing contexts (see WebKit bug[1] and related discussion on G+[2]) which makes it useless for some of the use cases. A better API would allow to get the origin of a referenced browsing context, e.g.: window.getOrigin(otherWindow); and to check whether it came from the same origin (sugar around window.getOrigin(otherWindow) == window.getOrigin(window)): window.isSameOrigin(otherWindow); That said, one of the key use cases for this API is to code around a Webkit bug[3] so maybe that should be fixed first. --tobie --- [1]: https://bugs.webkit.org/show_bug.cgi?id=83493 [2]: https://plus.google.com/116910304844117268718/posts/QyHfGL9GBd5 [3]: https://bugs.webkit.org/show_bug.cgi?id=43504
Re: [whatwg] New URL Standard
On Mon, Sep 24, 2012 at 10:58 AM, Anne van Kesteren ann...@annevk.nl wrote: The kind of predictability we have for the HTML parser, I want to have for the URL parser as well. Yes, please!! --tobie
Re: [whatwg] WebIDL nested interfaces
On Sep 11, 2012, at 7:09, Cameron McCormack c...@mcc.id.au wrote: Tobie Langel: No. It sounds like I should be fast asleep instead of making a fool of myself and wasting everybody's time. It is however the kind of thing that Tab wants to do for CSS (have a window.CSS object that is like a namespace object for some CSS interfaces -- the concept for which used to exist in Web IDL a while ago, but which I removed due to disuse). So it might well make sense to add something to Web IDL to handle this again. Agreed it's a terrible limitation of WebIDL if spec editors are creating globals because the language misses something like namespaces. One that should be fixed. --tobie
Re: [whatwg] [canvas] Proposal for supportsContext
On Tue, Sep 11, 2012 at 10:34 AM, Simon Pieters sim...@opera.com wrote: On Tue, 11 Sep 2012 00:14:25 +0200, Glenn Maynard gl...@zewt.org wrote: If you really want to protect users from the behavior of pages, you'd really need to make creating the context cheap. This was exactly my reaction as well. Introducing a new method doesn't solve the problem. There will still be pages that create the context and then don't use it. Browsers just have to suck it up and be fast anyway, just like with all other features on the Web. I think we shouldn't add supportsContext() since it doesn't provide authors with new information and browsers will have to do the above anyway. I actually like Ashley Gullen's proposal (canPlayType-inspired) because it brings consistency to the platform and offers a general pattern on how to test for the presence of features which can't be asserted for certain without costly lookups. navigator.onLine property is another example where a similar pattern would make (more) sense (than the current boolean returned instead). Basically, this is trading performance for the risk of false positives. --tobie
Re: [whatwg] [canvas] Proposal for supportsContext
On Sep 10, 2012, at 8:14 PM, Dean Jackson d...@apple.com wrote:
I propose adding a new method to HTMLCanvasElement:
interface HTMLCanvasElement : HTMLElement {
boolean supportsContext(DOMString contextId, any... arguments);
};
supportsContext takes the same parameters as getContext, and simply returns
true if the corresponding call to getContext would have returned a valid
context, false otherwise.
What about enabling feature detection by providing a method per context?
interface HTMLCanvasElement : HTMLElement {
object get2DContext();
object getWebGLContext(any... args);
};
That way, developers can use idiomatic JS for feature testing like
pretty much everywhere else on the Web platform:
if (canvas.get2DContext) {
// do stuff with 2D canvas
}
--tobie
Re: [whatwg] [canvas] Proposal for supportsContext
On Sep 10, 2012, at 9:32 PM, Dean Jackson d...@apple.com wrote:
On Sep 10, 2012, at 12:28 PM, Tobie Langel tobie.lan...@gmail.com wrote:
On Sep 10, 2012, at 8:14 PM, Dean Jackson d...@apple.com wrote:
I propose adding a new method to HTMLCanvasElement:
interface HTMLCanvasElement : HTMLElement {
boolean supportsContext(DOMString contextId, any... arguments);
};
supportsContext takes the same parameters as getContext, and simply returns
true if the corresponding call to getContext would have returned a valid
context, false otherwise.
What about enabling feature detection by providing a method per context?
interface HTMLCanvasElement : HTMLElement {
object get2DContext();
object getWebGLContext(any... args);
};
That way, developers can use idiomatic JS for feature testing like
pretty much everywhere else on the Web platform:
if (canvas.get2DContext) {
// do stuff with 2D canvas
}
This doesn't address the problem we are hitting, which is that
it is expensive to create a context.
It does. Only expose the API when you can create the context.
It's also a big change to
an existing operational API.
Agreed. You can always leave the previous method around for backward
compatibility.
--tobie
Re: [whatwg] [canvas] Proposal for supportsContext
This is actually what we could do now. We could hide window.WebGLRenderingContext when we can't create one. But then we'd have to hide all these too: attribute [Conditional=WEBGL] WebGLActiveInfoConstructor WebGLActiveInfo; attribute [Conditional=WEBGL] WebGLBufferConstructor WebGLBuffer; attribute [Conditional=WEBGL] WebGLFramebufferConstructor WebGLFramebuffer; attribute [Conditional=WEBGL] WebGLProgramConstructor WebGLProgram; attribute [Conditional=WEBGL] WebGLRenderbufferConstructor WebGLRenderbuffer; attribute [Conditional=WEBGL] WebGLRenderingContextConstructor WebGLRenderingContext; attribute [Conditional=WEBGL] WebGLShaderConstructor WebGLShader; attribute [Conditional=WEBGL] WebGLShaderPrecisionFormatConstructor WebGLShaderPrecisionFormat; attribute [Conditional=WEBGL] WebGLTextureConstructor WebGLTexture; attribute [Conditional=WEBGL] WebGLUniformLocationConstructor WebGLUniformLocation; Oh my. All of these are globals!? *Sigh* --tobie
Re: [whatwg] WebIDL nested interfaces
On Tue, Sep 11, 2012 at 12:52 AM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Sep 10, 2012 at 5:39 PM, Tobie Langel tobie.lan...@gmail.com
wrote:
It's too late; WebGL is a shipping, widely-used API. (This isn't a
WebGL
problem, either; it's just doing what every other API on the platform
does.
I don't think WebIDL even has a mechanism to put interfaces inside
other
objects.)
Really? Wouldn't this do the trick:
interface WebGLActiveInfo {
readonly attribute GLint size;
readonly attribute GLenum type;
readonly attribute DOMString name;
};
interface WebGLGlobal {
attribute WebGLActiveInfo activeInfo;
};
partial interface Window {
attribute WebGLGlobal WebGL;
};
This is just creating a global object WebGL containing an object using the
WebGLActiveInfo interface. It's not moving the WebGLActiveInfo interface
itself into an object. It sounds like you want something like
interface WebGL {
interface WebGLActiveInfo {
...
}
}
interface WebGLRenderingContext {
WebGL.WebGLActiveInfo? getActiveAttrib(WebGLProgram? program, GLuint
index);
}
No. It sounds like I should be fast asleep instead of making a fool of
myself and wasting everybody's time.
Sorry folks.
--tobie
Re: [whatwg] input type=barcode?
On Fri, Sep 7, 2012 at 6:35 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 30 Aug 2012, Jonas Sicking wrote: I think while in theory we could rely on UAs to enable barcode entry anywhere, which definitely would provide the maximum capabilities for the user. In practice it seems hard to create UI which enables that while at the same time isn't annoyingly shoving a barcode button in your face which you generally is not interested in using. Agreed. I think a UA that wanted to support this would want to know which attributes to provide the feature for. In this respect it's similar to the WebKit-proprietary x-webkit-speech attribute on input. In fact, this suggests that if other browsers are interested in supporting speech input, maybe we should standardise it as an inputmode value, e.g. inputmode=speech. Possible the inputmode= attribute in that case could be switched to a list of tokens, so you could in fact do inputmode=latin-prose speech or inputmode=numeric barcode in order to provide the user agent with more flexibility in the UI. There seems to be some overlap, at least in semantics, with the capture attribute described in HTML Media Capture[1] and recently filed for inclusion in the Living Standard HTML spec[2]. Anyway these two concepts can be reconciled or their distinction clarified? --tobie --- [1]: http://dev.w3.org/2009/dap/camera/ [2]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17879
Re: [whatwg] Hardware accelerated canvas
I apologize in advance, as this is slightly off-topic. I've been unsuccessfully looking for info on how Canvas hardware acceleration actually works and haven't found much. Would anyone have pointers? Thanks. --tobie
Re: [whatwg] Archive API - proposal
On Aug 14, 2012, at 21:21, Glenn Maynard gl...@zewt.org wrote:
(I've reordered my responses to give a more logical progression.)
On Tue, Jul 17, 2012 at 9:23 PM, Andrea Marchesini b...@mozilla.com wrote:
// The getFilenames handler receives a list of DOMString:
var handle = this.reader.getFile(this.result[i]);
This interface is problematic. Since ZIP files don't have a standard
encoding, filenames in ZIPs are often garbage. This API requires that
filenames round-trip uniquely, or else files aren't accessible t all. For
example, if you have two filenames in CP932, 日 and 本, but the encoding
isn't determined correctly, you may end up with two files both with a
filename of ??. Either you can't open either file, or you can only open
one of them. This isn't theoretical; I hit ZIP files like this in the wild
regularly.
Instead, I'd recommend that the primary API simply returns File objects
directly from the ZIP. For example:
var reader = archive.getFiles();
reader.onsuccess = function(result) {
// result = [File, File, File, File...];
console.log(result[0].name);
// read the file
new FileReader(result[0]);
}
This allows opening files without any dependency on the filename. Since
File objects are by design lightweight--no decompression should happen
until you actually read from the file--this isn't expensive and won't
perform any extra I/O. All the information you need to expose a File
object is in the central directory (filename, mtime, decompressed size).
I would like to receive feedback about this.. In particular:
. Do you think it can be useful?
. Do you see any limitation, any feature missing?
It should be possible to get the CRC32 of files, which ZIP stores in the
central directory. This both allows the user to perform checksum
verification himself if wanted, and all the other variously useful things
about being able to get a file's checksum without having to read the whole
file.
(I don't think CRC32 checks should be performed automatically, since it's
too hard for that to make sense when random access is involved.)
// The ArchiveReader object works with Blob objects:
var archiveReader = new ArchiveReader(file);
// Any request is asynchronous:
The only operation that needs to be asynchronous is creating the
ArchiveReader itself. It should parse the ZIP central record before before
returning a result. Once you've done that you can do the rest
synchronously, because no further I/O is necessary until you actually read
data from a file.
This gives the following, simpler interface:
var opener = new ZipOpener(file);
opener.onerror = function() { console.error(Loading failed); }
opener.onsuccess = function(zipFile)
{
// .files is a FileList, representing each file in the archive.
if(zipFile.files.length == 0) { console.error(ZIP file is empty);
return; }
var example_file = zipFile.files[0];
console.log(The first filename is, example_file.name, with an
expected CRC of, example_file.expectedCRC);
// Read from the file:
var reader = new FileReader(example_file);
// For convenience, add getter File? (DOMString name) to FileList, to
find a file by name. This is equivalent
// to iterating through files[] and comparing .name. If no match is
found, return null. This could be a function
// instead of a getter.
var example_file2 = zipFile.files[file.txt];
if(example_file2 == null) { console.error(file.txt not found in ZIP;
return; }
}
(To fit expectedCRC in there, it would actually need to use a subclass of
File, not File itself.)
This also eliminates an error condition (no getFile error callback), and
since .files looks just like HTMLInputElement.files, it can be used
directly with code written for it. For example, if you have a function
uploadAllFiles(files), you can pass in both an input type=file
multiple's .input or a zipFile.files, and they'll both work.
How are nested directories handled in your counter proposal?
--tobie
Re: [whatwg] Features for responsive Web design
On Mon, Aug 13, 2012 at 6:39 PM, Henri Sivonen hsivo...@iki.fi wrote: If it indeed is the case that there are really only two realistic bitmaps samplings for catering to differences in weeding device pixel density (ignoring art direction), it would make sense to have simply img src=1xsampling.jpg hisrc=2xsampling.jpg alt=Text alternative instead of an in-attribute microsyntax for the non-art-directed case. Agreed that avoiding the in-attribute micro syntax--if at all possible--is a mighty worthy goal. --tobie
