Re: [whatwg] Proposal: navigator.cores
On Tue, 06 May 2014 01:29:47 +0200, Kenneth Russell k...@google.com wrote: Applications need this API in order to determine how many Web Workers to instantiate in order to parallelize their work. On Tue, 06 May 2014 01:31:15 +0200, Eli Grey m...@eligrey.com wrote: I have a list of example use cases at http://wiki.whatwg.org/wiki/NavigatorCores#Example_use_cases (...) I guess everyone that is reading this thread understands the use cases well and agrees with them. The disagreement is what kind of API you need. Many people, rightly so, have stated that a core count gives little information that can be useful. It's better to have an API that determines the optimal number of parallel tasks that can run, because who knows what else runs in a different process (the webpage the worker is in, the browser UI, plugins, other webpages, iframes, etc) with what load. Renaming 'cores' to 'parallelTaskCount' would be a start. On Tue, 06 May 2014 01:31:15 +0200, Eli Grey m...@eligrey.com wrote: Also, allowing webapps to set thread priority is very dangerous and can cause system lockup. Nobody mentioned giving direct unsanatized access to setting low level thread/process priority. On Tue, 06 May 2014 01:29:47 +0200, Kenneth Russell k...@google.com wrote: A prioritization API for Web Workers won't solve this problem, because all of the workers an application requests must actually be spawned for correctness purposes. There's no provision in the web worker specification for allocation of a web worker to fail gracefully, or for a worker to be suspended indefinitely. Even if a worker had its priority designated as low, it would still need to be started. You're identifying limitations in the workers API. That's good. Would be very useful to add the missing bits you're asking to the worker API. On 32-bit systems, at least, spawning too many workers will cause the user agent to run out of address space fairly quickly. That seems like a user agent with a bad implementation. Limiting the resources that an unprivileged application can use on the system is a really old idea. That's already done in browsers with disk quotas for local storage, databases and application cache, for instance. I wouldn't want to use that browser either. Typing a url into the address bar does not imply that I give the web page the permission to hog my computer or device with excess CPU and memory usage.
Re: [whatwg] URL: file: URLs
On Wed, 31 Oct 2012 15:38:36 +0100, Benjamin Smedberg benja...@smedbergs.us wrote: On 10/30/2012 7:41 PM, João Eiras wrote: I currently do not have Windows to test but I think I recall IE (or Opera?) opening file://server/share if there was a network share at \\server\share Firefox has considered and rejected that kind of proposal for security reasons. I can't find the bug right now, but I suspect that we would not implement that feature even if it were specced. Obviously supporting such thing would require implementing security checks between origins, and the origin generation algorithm updated to allow file://host, while currently it specifies that all file: uris have a null origin. And, FF is no the only program that can interpret file uris. Any application should be able to open file uris, just like they can open local file paths now, or http uris.
Re: [whatwg] URL: file: URLs
On Tue, 30 Oct 2012 16:25:30 -, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Oct 29, 2012 at 4:24 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/29/12 10:53 AM, Anne van Kesteren wrote: But at that point in a URL you cannot have a path. A path starts with a slash after the host. The point is that on Windows, Gecko parses file://c:/something as file:///c:/something As in, it's an exception to the general if there are two slashes after the file: then the next thing is a host rule. Thanks, I missed that. It seems however we could have that parsing rule for all platforms without issue, no? After all, file://c:/ does not parse currently on non-Windows platforms. I suppose, I would hate it though for new URL(...) to depend on the platform. I'm not sure there are great solutions here. :( Yeah, I'm willing to suck it up, but I would like to explore our options before we go that route. In both Firefox and Chrome if you type file://aaa/some/path, or file://localhost/some/path, the aaa and localhost parts are ignored, and the rest of the path is interpreted as a local file path. In Opera, anything that is not localhost gives an error. I currently do not have Windows to test but I think I recall IE (or Opera?) opening file://server/share if there was a network share at \\server\share In a previous job I had, where the environment was a bit windows centric, there was a wiki with documentation with links to files on network shares. I recall the urls looked something like file:\\server\some\path in the HTML. IE opened the files (hence people continued to write them). The other browsers didn't. The point is that the file uri can and should have the authority part, or host, and that can be the local machine, or a network share.
Re: [whatwg] proposal for a location.domain property
On Thu, 24 May 2012 23:02:00 +0200, Maciej Stachowiak m...@apple.com wrote: I agree. Even though there are still legacy features like cookies and document.domain that use domain-based security, most of the Web platform uses origin-based security, and that has proved to be a sounder model. While I acknowledge the use cases for exposing location.domain, it's also likely to become an attractive nuisance that pulls developers in the wrong direction. Although I understand this opinion and agree with it, the domain based security checks are used for cross frame interaction, cookies, security certificates, etc, therefore it has to be specified and documented. I don't think adding a location.tld property or location.topDomain would pull developers away from anything. It would just make the legacy domain based security checks a bit more easy to handle and understand. It's the specifications and APIs that tell which security model to use, not the developer.
[whatwg] [Cross-document messaging] Restrictions on targetOrigin
Hi. Step 1 of the spec [1] for postMessage says: 1. If the value of the targetOrigin argument is neither a single U+002A ASTERISK character (*), a single U+002F SOLIDUS character (/), nor an absolute URL, then throw a SyntaxError exception and abort the overall set of steps. The absolute URL part will create problems when the origin of the scripting environment does not serialize to an absolute URL. For instance, if you have two documents A and B in a non http context, where typically the origin will be null, like file: or data:, and post a message from A to B, B will receive a message event which event.origin property has a value of null. If the listener then does # event.source.postMessage(reply, event.origin) (which is a code snippet easily found in online tutorials) step 1 causes that call to fail with a SYNTAX_ERR exception. Step 1 should be changed to instead of referring to an absolute URI, refer to a valid origin, as serialized by the origin serialization algorithm. Thoughts ? [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#posting-messages
Re: [whatwg] Fullscreen CSS
On Tue, 15 Nov 2011 00:10:09 +0100, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Nov 15, 2011 at 10:54 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: I think we should go the route that the dialog element did in Ted's change proposal and have a pseudo-element that gets created when an element is fullscreened. Simple and easy, and trivial for the author to manipulate to get most effects they could want. Interesting. I did not know about that. That proposal requires layout engine changes --- specially, at least one new rule for CSS stacking contexts in the infamous appendix E. Also, it doesn't address situations where an ancestor of the dialog or fullscreen element has 'opacity', 'transform', 'filter', 'mask' or 'clip-path' (and maybe other things I've forgotten). I think we should probably define a unified mechanism that can be used for the fullscreen element and the dialog element and anything else like it we need. And figure out what happens if you make part of a page fullscreen and that uses dialog. Or if you have nested dialogs mixed with fullscreen... Hmm. This proposal seems like will make fullscreen styling non-transparent and non-trivial. Currently the elements are just resized and that very easy to implement, understand and workaround with CSS. How would that affect, for instance, a canvas element that is resized to fit the whole screen ?
[whatwg] Fullscreen and keyboard focus.
Hi. Perhaps keyboard focus should be limited only to the fullscreen element or its descendants. If you have a canvas or video fullscreen, alt-tabbing can move the focus outside the fullscreen element, say into form elements. But then this would require giving focus, and dispatching focus events, if the focused element is not inside the fullscreen element subtree.
[whatwg] Fullscreen and event dispatch
Hi. The requestFullscreen steps tells to dispatch a fullscreenchange event on the context object, and all containing objects (frames). First, there should be a better clarification of 'context object'. While is remarked that it is the object used for the last requestFullScreen call which was allowed, it should also refer that for ancestor browsing contexts, it should be the containing frame. This way, fullscreening a contained document will work just as fine as any other kind of element reusing the same css, while for the containing document, it's transparent. Second, the requestFullscreen steps do not cope well if there is already a previous fullscreen element, either in the same document, or in a descendant, ancestor or sibling document. The steps tell to loop all the way up to the top level document and dispatch fullscreenchange events. I would suggest dispatching it *only* for elements and documents where there was a fullscreen change, so if we have a top level document A and a child B, B has two elements, a' and b'. Changing fullscreen from a' to b' would result in two fullscreenchange events, one for each element, inside B, while A should not get a event. I have some doubts if the spec allows this use case though, because the steps for requestFullscreen also mention that if an ancestor browsing context has a non-null fullscreen element, then it should not be allowed to proceed, but this restriction does not apply, again, to sibling elements, or sibling/descendant documents. Third, perhaps fullscreenchange should be split into fullscreenon and fullscreenoff events ?
Re: [whatwg] Canvas ScrollBar
On Thu, 20 Oct 2011 14:14:12 +0200, Bronislav Klučka bronislav.klu...@bauglir.com wrote: Hello, Would it be possible to extend canvas specification to include scroll bar functionality? To add scroll bar, to manage scroll bar (total size, page size). Creating control based on canvas that needs scrollbar at this point is unnecessarily difficult at this point. Brona Klucka Which is your use case ? It doesn't make any sense at all to me to have scrollbars in a canvas. However, if you need scrolling, you can wrap the canvas with an element with specified dimensions and overflow:auto.
Re: [whatwg] Fullscreen Update
2) Chris brought forward the case of nesting. You have a fullscreen presentation (lets assume API-based activated for now) and in that presentation there's some video that the presenter wants to display fullscreen (lets assume the video player is a custom widget with API-based fullscreen activation for now). Once the presenter exits displaying the video fullscreen, the presentation should still be fullscreen. Initially this was brought up with the video being hosted in a separate descendant document, but the video could be in the same document as well. roc suggested a model that works when you have separate documents and it could be made to work for the single document case too, as long as the level of nesting remains is no larger than required for the presentation scenario mentioned above. Is that an acceptable limitation? Alternatively we could postpone the nested fullscreen scenario for now (i.e. make requestFullscreen fail if already fullscreen). +1 for punting on the nested case. I think you'd ever only want to have one thing fullscreen at a time. Thus, if you go from a fullscreen to another, the previous one should naturally leave fullscreen. I think that's how presentation functionality works on ppt and similar tools, too. Silvia. I can see the use case when Document is fullscreen, and then an element is fullscreened. So if another element goes fullscreen it replaces the previous, if any, but the document keeps its state. Another alternative would be to have a stack, but I think that's overkill.
[whatwg] Fullscreen events
Hi. The spec tells that fullscreenchanged is dispatched for API initiated fullscreen. It should too specify that fullscreenchanged should be dispatched for fullscreen toggled by the user like pressing F11 ou double clicking a video element. Thanks.
Re: [whatwg] Fullscreen Update
On Wed, 19 Oct 2011 16:45:34 +0200, Glenn Maynard gl...@zewt.org wrote:
On Wed, Oct 19, 2011 at 12:40 AM, Anne van Kesteren
ann...@opera.comwrote:
1) How much should UI-based and API-based fullscreen interact? To me it
seems nice if pressing F11 would also give you fullscreenchange events
and
that Document.fullscreen would yield true. Why would you not want to
give
the same presentation via native activation and API-based activation? Of
course when you activate it UI-wise, navigation should not exit it.
The most obvious way to write a fullscreen button is:
b.onclick = function(e) {
if(document.fullscreen)
document.exitFullscreen();
else
gameDiv.enterFullScreen();
}
If F11-fullscreen sets document.fullscreen, this breaks; enterFullScreen
would never be called. This could be dealt with, of course (check
document.fullscreenElement == gameDiv instead), but it's a corner case
that
people aren't going to test.
I think you just solved your own issue :) Your if check is wrong given
your use case. Besides, if the developer failed to test, it would just
require an extra click.
Re: [whatwg] Fullscreen Update
On Wed, 19 Oct 2011 17:31:40 +0200, Glenn Maynard gl...@zewt.org wrote: On Wed, Oct 19, 2011 at 11:00 AM, João Eiras jo...@opera.com wrote: I think you just solved your own issue :) Your if check is wrong given your use case. No, that's missing the point. These obscure corner cases should be minimized (in any API, and especially web APIs). People won't know to test them, and everyone's browsing experience will be buggier when in F11-fullscreen. Can anyone suggest a use case for having fullscreen be true when in browser (F11) fullscreen? I can't think of any. Besides, if the developer failed to test, it would just require an extra click. It wouldn't work at all. The exitFullscreen call would fail or no-op (you can't exit F11 fullscreen with this API, of course; it's not yours to exit), so the next click would just call exitFullscreen again. F11 and document.requestFullscreen() should produce exactly the same results, so, document.fullscreen would be enabled. And there's no reason not to (and otherwise would make the spec needlessly more complex).
Re: [whatwg] Fullscreen Update
On Wed, 19 Oct 2011 17:15:11 +0100, Glenn Maynard gl...@zewt.org wrote: On Wed, Oct 19, 2011 at 11:49 AM, João Eiras jo...@opera.com wrote: F11 and document.requestFullscreen() should produce exactly the same results, so, document.fullscreen would be enabled. And there's no reason not to (and otherwise would make the spec needlessly more complex). There's no such thing as document.requestFullscreen() in the current draft. (It was suggested in passing on IRC, but it hasn't been discussed here.) There's definitely a reason that the fullscreen API can't act like F11-fullscreen. F11 causes the whole browser window to be fullscreened, affecting all tabs in the window. If you change tabs or create a new tab, the browser window stays fullscreened. It isn't exited on navigation. Pages should no more be able to affect F11-fullscreen than they can resize the browser window. I don't understand how that is an issue. It has been mentioned that navigating a document which has a fullscreen element would exit fullscreen, but not a document. Indeed the spec lacks document.requestFullscreen. It should be there for the traditional fullscreen without browser chrome, just like F11. Or instead, mention that calling requestFullscreen on the root would have the same effect. I'd rather have it directly on Document though.
Re: [whatwg] Fullscreen
On Sat, 15 Oct 2011 05:27:21 +0100, Anne van Kesteren ann...@opera.com
wrote:
I wrote up a draft:
http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
(...)
a)
The fullscreen media query is missing (I seriously suggest supporting it)
# @media all and (full-screen) { /* ... */ }
Does it make sense to have on/off as in the Mozilla proposal ? e.g. and
(full-screen:on/ff) ?
b)
I think that :fullscreen should not apply if there is no fullscreen
element. It would make the CSS snippet simpler, and the media query would
still allow fullscreen styles to be applied. It also allows the user agent
from optimize a bit to skip that fullscreen CSS snippet if there is no
fullscreen element bound. And the CSS snippet as mentioned applies only to
HTML, so another use case to have a media query.
c)
There should be a security note for request/cancel/enter/exitFullscreen
that the user agent might choose to dishonor the calls to these methods,
like if fullscreeen is not supported, or the browsing context is child of
another one that does not allow fullscreen, or the call to these methods
is not from a user initiated action. I would remark that user agents
should ignore calls to those methods if not coming from a user initiated
action (kind like the way pop ups are handled). So, the click to go
fullscreen button use case works, but a webpage going fullscren during
load and then spoof the browser UI would not. It would also make the use
case for requestFullScreenWithKeys API less interesting.
d)
Perhaps a non normative note just to explain that the flags do would be
nice for authors. fullscreen tells if the document is being rendered
fullscreen (a shortcut to check if the media query applies), and
fullscreenEnabled tells if the document is allowed to go fullscreen using
the enter/requestFullscreen API.
e)
Given their use cases, the flag fullscreenEnabled would be better called
fullscreenAllowed, and the fullscreen flag would be better called
fullscreenEnabled.
So far, nice work.
Re: [whatwg] [fullscreen] cancelFullScreen()
It seems to me that being fullscreen is a property of the top-level
browsing context. All that is potentially associated with a document is
the fullscreen element. If you have a document A with two
sub-documents B and C, it does not make much sense to me that if you go
fullscreen from B, C would not report as being fullscreen. I mean
sure, there is no fullscreen element but it is definitely rendered
fullscreen.
As the proposed spec is written so far, I think Document.fullscreen is
meant to convey that:
1. If the document's full-screen element is in the document, the
full-screen element is rendered at viewport dimensions with browser
UI hidden, or
2. if the document's full-screen element is not in the document, the
document is rendered at viewport dimensions.
Does it make any sense to say there is a fullscreen element ? Documents
are fullscreen, elements wrap some content and add structure.
How can 1. be achieved in a predictable non-magic manner ? If you have a
video element with a custom UI, the custom UI, which will be nothing more
than some elements, needs to stretch, and then if you use javascript to
query layout information, that needs to be visible.
So, the only thing that the user agent should do (which they do now
already) is to remove the browser chrome.
The webpage can then with a fragment if css stretch whatever needs
stretching.
# .my-fullscreen-video.container {
position:fixed;z-index:999;left:0;top:0;width:100%;height:100% }
Or do something even more complex. So, the user agent should not do any
kind of implicit resizing of elements.
The key is the :full-screen psuedo-class, for which the suggested UA
style rules enables the full-screen element appear to break out of
containing frames and be rendered at the view-port size (assuming the
browser window is made viewport dimensions by the UA).
The :full-screen pseudo-class is defined to also apply to an iframe,
object or embed element whose child browsing context's Document is
in the full-screen state. So if a child document in an iframe doesn't
have its full-screen element in the document, unless the document
reports being in full-screen state the :full-screen pseudo-class won't
apply to that document, and that document thus won't be rendered at
viewport dimensions.
If we specified a Document.currentFullScreenElement attribute, then
Document.fullScreen would be equivalent to
(Document.currentFullScreenElement != null).
Why the need for a :full-screen selector ? Aren't media queries enough or
even more semantically correct ?
And then why the need for document.fullScreen ? The media query API that
Anne was writing should work too to query if fullscreen is enabled. [1]
# var in_fullscreen = matchMedia((fullscreen:on)).matches
If the use cases can be cleanly represented using just CSS and generic
APIs, then better,
[1] http://dev.w3.org/csswg/cssom-view/#the-mediaquerylist-interface
Lastly, where is the specification ? If there an official working draft ?
[whatwg] document.all quickiness
Hi ! The spec for HTMLAllCollection [1] says The HTMLAllCollection interface represents a generic collection of elements. After some quick testing in IE [2], IE returns the doctype, processing instructions and comment nodes too. If converts them all to comments but that's something else we shouldn't even touch with a long stick. I would suggest that the spec be updated to match IE better. Thank you. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#htmlallcollection-0 [2] http://dl.dropbox.com/u/9681493/procinsts.html
Re: [whatwg] document.all quirkiness
On Tue, 04 Oct 2011 19:58:56 +0200, João Eiras jo...@opera.com wrote: Hi ! The spec for HTMLAllCollection [1] says The HTMLAllCollection interface represents a generic collection of elements. After some quick testing in IE [2], IE returns the doctype, processing instructions and comment nodes too. If converts them all to comments but that's something else we shouldn't even touch with a long stick. I would suggest that the spec be updated to match IE better. After further testing (and getting someone to test in IE9), IE9 only returns Elements, even in quirks mode, so I presume the change is not needed. Thanks.
Re: [whatwg] Please disallow javascript: URLs in browser address bars
On Thu, 22 Jul 2010 21:32:39 +0100, Luke Hutchison luke.hu...@mit.edu wrote: [snip] Comments, please? This is entirely out of scope of any specification and 100% an user agent UI issue.
Re: [whatwg] Form validation against invisible controls
On Thu, 03 Jun 2010 16:16:00 +0100, TAMURA, Kent tk...@chromium.org wrote: An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) You'd need to check the visibility or display also of all ancestors, that opacity is not 0, that the bounding box has enough size to render the form to the user and etc. That's quite complicated to specify. Would be easier to tell that user agents might chose to ignore form controls that they do not *paint* if that is possible for the UA to implement. I couldn't find exceptional rules for validating invisible controls in the current draft. Chrome 5 was released with a part of interactive validation, and we received a bug report about validation against invisible form controls.
Re: [whatwg] Need document.available_fonts() call
On Tue, 11 May 2010 16:26:43 +0200, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Tue, 2010-05-11 at 16:14 +0200, Anne van Kesteren wrote: On Tue, 11 May 2010 16:08:01 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 5/11/10 9:39 AM, Ashley Sheridan wrote: Is there really much of a need for this though? Good question. What _is_ the use case here, exactly? E.g. allowing the user to select a font in a text editing or drawing application. However, for portability it would probably be better if these were limited to fonts already on the Web. I agree, portability dictates that they should stick to the few common fonts, or we end up with the same situation I've had countless times where someone sent an MSWord file with all the bullets as some character from the Wingdings font then wonder why people complain that all their bullets are letters. Embedding the font isn't feasible in this case because you really can't trust the end-user to observe the legal aspects of the fonts they have on their system. The designer of a font may not have given user rights to distribute the font in a document that is publically available like this. I've suggested this back in 2007 http://lists.w3.org/Archives/Public/public-webapi/2007Jul/0021.html Regarding filtering which fonts, do note that a web page is not the only place where web standards and APIs are used. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [whatwg] prompts, alerts and showModalDialog during beforeunload/unload events
Though I'm not sure what exactly Ojan is proposing we forbid? I think his suggestion is to forbid all of window.prompt, window.alert, and window.showModalDialog. Persumably window.confirm as well. Exactly. But we don't need a spec to tell that. It's 100% user agent feature, so you're free to have better or worse UI. Same could be said when the user right-clicks.
Re: [whatwg] HTMLCanvasElement.toFile()
This function takes the same arguments as toDataURL(), plus an additional 'name' argument. It produces the same result as toDataURL(), except that it returns the result as a File object rather than as a data-url encoded string. This can then be directly sent using XMLHttpRequest. I think it would make more sense to have an actual type for binary data (for example along the lines of my proposal on public-script-coord and es-discuss) and enable getting one from canvas and sending via XHR. How about just overloading xhr.send() to handle a canvas element ?
Re: [whatwg] window.print() when printing is not supported
Throwing an error does not seem very compatible either. Returning a boolean from print() would not be problematic. Note that desktop UAs support printing most of the time, while handheld or tv ones don't.
Re: [whatwg] window.print() when printing is not supported
Only issue is that pages might want to be able to detect if printing is available without actually trying to print. I.e. in order to not display a print button in kiosk browsers. Something like navigator.isPrintingEnabled ?
Re: [whatwg] Web API for speech recognition and synthesis
On Wed, 02 Dec 2009 12:32:07 +0100, Bjorn Bringert bring...@google.com wrote: We've been watching our colleagues build native apps that use speech recognition and speech synthesis, and would like to have JavaScript APIs that let us do the same in web apps. We are thinking about creating a lightweight and implementation-independent API that lets web apps use speech services. Is anyone else interested in that? Bjorn Bringert, David Singleton, Gummi Hafsteinsson This exists already, but only Opera supports it, although there are problems with the library we use for speech recognition. http://www.w3.org/TR/xhtml+voice/ http://dev.opera.com/articles/view/add-voice-interactivity-to-your-site/ Would be nice to revive that specification and get vendor buy-in. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [whatwg] Web API for speech recognition and synthesis
On Thu, 03 Dec 2009 01:50:20 +0100, Dave Burke davebu...@google.com wrote: We're envisaging a simpler programmatic API that looks familiar to the modern Web developer but one which avoids the legacy of dialog system languages. Ok. I referenced that XHTML+Voice because there is already a specification with markup, css 2 aural stylesheets and javascript APIs, and one implementation. I quite sure someone can revisit this whole issue, and refactor the xhtml+voice specification into something more acceptable and implementable. I don't think anyone would implement it the way it is. Dave On Wed, Dec 2, 2009 at 7:25 PM, João Eiras jo...@opera.com wrote: On Wed, 02 Dec 2009 12:32:07 +0100, Bjorn Bringert bring...@google.com wrote: We've been watching our colleagues build native apps that use speech recognition and speech synthesis, and would like to have JavaScript APIs that let us do the same in web apps. We are thinking about creating a lightweight and implementation-independent API that lets web apps use speech services. Is anyone else interested in that? Bjorn Bringert, David Singleton, Gummi Hafsteinsson This exists already, but only Opera supports it, although there are problems with the library we use for speech recognition. http://www.w3.org/TR/xhtml+voice/ http://dev.opera.com/articles/view/add-voice-interactivity-to-your-site/ Would be nice to revive that specification and get vendor buy-in. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [whatwg] window.setInterval if visible.
On Thu, 15 Oct 2009 21:35:03 +0200, Gregg Tavares g...@google.com wrote: I was wondering if there as been a proposal for either an optional argument to setInterval that makes it only callback if the window is visible OR maybe a window.setRenderInterval. You're trying to solve a real problem with a very specific API. You might use setInterval, but someone else might use a worker or setTimeout. The best way would be an attribute on the window, like window.isVisible returning either true of false which would return true if the document is partially or totally visible. This way, all other possible use cases to prevent animations or other complex and heavy dom/layout operations could be postponed just by checking that value. I personally think it's a good idea to have that info available.
Re: [whatwg] Storage events
On Thu, 15 Oct 2009 20:37:48 +0200, Jeremy Orlow jor...@chromium.org wrote: I'd like to propose we remove the source attribute from storage events. ( http://dev.w3.org/html5/webstorage/#the-storage-event) In Chrome, we cannot provide access to a window object unless it's in the same process. Since there's no way to guarantee that two windows in the same origin are in the same process, Chrome would need to always set it to null in order to avoid confusing developers (since what process a page is in is really an implementation detail). The specification tells source is a WindowProxy, so if the underlying window is deleted, or inaccessible, accessing any member of source could just throw an INVALID_STATE_ERR. The problem is there also if a storage event is queued and the originating window is deleted meanwhile, or the document with the listener keeps a reference to the originating window for a long time, and that window is closed, unless the user agent keeps the originating window live while it's WindowPRoxy is not garbage collected, which is not desirable. So, I support Jeremy's suggestion. source should probably be removed from the spec. Which are its use cases anyway ?
Re: [whatwg] Web Storage: structured clones lead to ambiguity in detecting if a key is set w/ getItem()
On Wed, 23 Sep 2009 20:19:43 +0200, Brett Cannon br...@python.org wrote: Before the move to structured clones one could tell if a key was set by calling getItem() and seeing if it returned null (had to use === as someone could have called setItem() w/ null, but that would be coerced to a string for storage). But with the latest draft's switch to structured clones that test no longer clearly differentiates between whether the value returned by getItem() signifies that the key was not set, or the key was set with the value null. As written right now the only way to detect if a key was truly set is to iterate through all of them with 'length' and key(). Perhaps a contains() function that returns true/false based on whether the key is set is warranted? Otherwise you could do something like Python's get() method on dicts where an optional second argument is provided to getItem() which is returned only if the key is not set, allowing a user-provided object represent a key not existing w/ ===. Yes, there is ambiguity in getItem() between the case of non existent key or the case or null key. But does storing null keys adds any value, or relevant information ? The User Agent could optimize by treating a setItem(key, null) as a removeItem() because getItem() would return in both cases null, and it would be an opportunity to spend less quota of the storage area. The only side effect of such optimization would be that setItem(key, null) would not produce a new key entry that could be read by key(index). But back on the original issue, doing a setItem(key,null) is just redundant overhead that does not had any information, so the spec could just allow the harmless ambiguity to happen. I personally would prefer setItem(key,null/undefined) to be treated as removeItem(key).
Re: [whatwg] Structured clone algorithm on LocalStorage
and the more browser UI jank users will be sure to experience. If I may, as a side note, locking the UI is a user agent specific issue. No specification requires user agents to lock their UIs while scripts execute. Opera has achieved this long time ago, by properly dividing ecmascript execution with all the other tasks, and the new browsers with multi-process architecture also do not suffer from this problem.
Re: [whatwg] Web Storage: structured clones lead to ambiguity in detecting if a key is set w/ getItem()
On Wed, 23 Sep 2009 23:03:38 +0200, Erik Arvidsson erik.arvids...@gmail.com wrote: What are the arguments against adding a containsKey method? This would map consistently to the in operator and hasOwnProperty in ES5. object.containsKey(name) would be mapped to [[GetOwnProperty]](object, name) !== undefined in ES5 meta language. That seems most consistent to existing APIs. A containsKey or hasItem, preferably, would still not address the ambiguity issue.
Re: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
2. The location of an icon like a favicon.ico file or png etc. This is actually a real privacy issue. The user agent would periodically fetch a remove favicon, which discloses the end user's ip. If any, such favicon would need to be made available offline immediately when installing the protocol handler, or a data uri could be used.
Re: [whatwg] Removing versioning from HTML
On Fri, 14 Aug 2009 12:01:31 +0100, Ian Hickson i...@hixie.ch wrote: On Sun, 9 Aug 2009, Aaron Boodman wrote: I frequently see the comment on this list and in other forums that something is too late for HTML5, and therefore discussion should be deferred. I would like to propose that we get rid of the concepts of versions altogether from HTML. In reality, nobody supports all of HTML5. Each vendor supports a slightly different subset of the spec, along with some features that are outside the spec. This seems OK to me. Instead of insisting that a particular version of HTML is a monolithic unit that must be implemented in its entirety, we could have each feature (or logical group of features) spun off into its own small spec. We're already doing this a bit with things like Web Workers, but I don't see why we don't just do it for everything. Just as they do now, vendors would decide at the end of the day which features they would implement and which they would not. But we should never have to say that the spec is too big. If somebody is interested in exploring an idea, they should be able to just start doing that. I agree in principle. I wholeheartedly agree with all the reasoning, but there are issues. From an implementor's point of view it is much harder to implement and keep up with a mutating specification. During implementation a stable spec is preferred. So versioning will allow an implementor to decide to implement the latest stable version of some spec, while work proceeds on a newer one. And when I refer mutating specification I'm not referring to the whole html5 spec, but each separate component, like web storage, web workers, video, etc... Currently, because specs are being edited and might take a while to get to CR, we have different implementors implement different parts of the specifications, and then meanwhile the specification mutates and implementors have to waste time updating their implementation which could have been right from the start. I understand that implementation feedback is necessary, but this is not very optimal. After a spec gets to CR it can't just mutate out of thin air, hence forking it into a new version is the way to go. Example: Gecko, Webkit and IE have localStorage, but the spec changed a few days ago to allow structured storage.
Re: [whatwg] DOMTokenList is unordered but yet requires sorting
On Mon, 15 Jun 2009 21:38:05 +0200, Darin Adler da...@apple.com wrote: On Jun 15, 2009, at 12:22 PM, Ian Hickson wrote: On Tue, 9 Jun 2009, Erik Arvidsson wrote: I was about to follow up on this. Requiring sorting which is O(n log n) for something that can be done in O(n) makes thing slower without any real benefit. Like João said the order should be defined as the order of the class content attribute. Fair enough. Done. Since DOMTokenList requires uniqueness, then I suspect it's still O(n log n) even without sorting, not O(n). -- Darin Oh, I have forseen that. Is it really necessary to remove duplicates ? I imagine DOMTokenList to be similar to what can be achieved with a String.split(), but then it would be just more duplicate functionality.
Re: [whatwg] DOMTokenList is unordered but yet requires sorting
Ensuring consistency between browsers, to reduce the likelihood that any particular browser's ordering becomes important and then forcing that browser's ordering (which could be some arbitrary ordering dependent on some particular hash function, say) into the platform de facto. This is similar to what happened to ES property names -- they were supposedly unordered, UAs were allowed to sort them however they liked, and now we are locked in to a particular order. I strongly think the order should not be sorted, but should reflect the order of the token in original string which was broken down into tokens. It would also make implementations much simpler and sane, and would spare extra cpu cycles by avoiding the sort operations.
Re: [whatwg] document.contentType
In HTML5, HTML elements in text/html are put in the XHTML namespace and text/html might contain SVG or MathML elements, so you probably want to conditionally call getElementsByTagNameNS based on e.g. the root element's namespaceURI rather than the document's HTMLness. I think the major advantage of document.contentType is to know the value of the Content-Type header (without charset) sent by the server. This would be good for 3rd party libraries or client side scripts.
Re: [whatwg] several messages
The ImageData APIs already provide the ability to do this and are already supported by Firefox, Opera and Safari. Given the ImageData APIs, and given that they are generally more efficient at the typical use cases for getPixel/setPixel, I haven't added getPixel/ setPixel to the spec. Cheers, The opera-2dgame context also has APIs for collision detection and control painting http://my.opera.com/WebApplications/blog/show.dml/200788 I'm not familiar with the current canvas spec, but are these features supported somehow? Or would they have the potential to be included ?
Re: [whatwg] DOMParser / XMLSerializer
On Wed, 20 May 2009 23:20:34 +0200, Anne van Kesteren ann...@opera.com wrote: Although it seems most browsers have adopted these APIs, HTML5 offers basically identical APIs in the form of document.innerHTML or is there something that DOMParser / XMLSerializer can do that document.innerHTML cannot? XMLSerializer must generate well formed xml (all tags closed, no attributes without values, case preserved, etc) and it accepts a full document, so you get a serialized output with doctype, processing instructions, comments which are not descendants of the root, and the root itself. DOMParser parses xml into a full document so if I have a doctype subset, those will be recognized and replaced on the document. That does not happen with innerHTML. If the input source has processing instructions, these will be preserved also in the result document. These are duplicates of the functionality provided on DOM 3 LS, and developer prefer these because their APIs are simpler and more convenient.
Re: [whatwg] SVG extensions to canvas
SVG images often don't have an intrinsic size. What's the intrinsic size of this image? svg xmlns=http://www.w3.org/2000/svg; linearGradient id=g x1=0 y1=0 x2=1 y2=0 stop stop-color=red offset=0/stop stop-color=lime offset=1/ /linearGradient rect x=0% y=0% width=100% height=100% fill=url(#g)/ /svg Rob This is the same as tabletrtdtextarea/textarea/td/tr/table where the Ua shrink wraps the table but the textarea inherit the parents width. This would cause a 0 width table, but currentl user agents rely on other attributes to get the intrinsic dimensions, like rows and cols for the table. In the SVG case, the UA could use default dimensions, like 300 per 300 -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [whatwg] [html5] Pre-Last Call Comments
On , Kristof Zelechovski giecr...@stegny.2a.pl wrote: Character set x-x-big5 cannot be registered because it is private. Now that classid is gone, what will be the workaround for ActiveX objects where they are needed? classid is nevertheless proprietary, and no other user agent but IE will require it (unless others implement ActiveX as well). The spec does not forbid to use non supported attributes and elements. It only specifies the handling for the known ones.
Re: [whatwg] How long should sessionStorage data persist?
On , Jeremy Orlow jor...@google.com wrote: I think this also applies: NOTE: The lifetime of a browsing context can be unrelated to the lifetime of the actual user agent process itself, as the user agent may support resuming sessions after a restart. Should that restore sessionStorage data ? Aren't you making sessionStorage much more complicated while the same use cases are covered by localStorage ? sessionStorage could be optimized to be just a volatile amount of data in memory, but these requirements require sessionStorage to implement the same disk IO heuristics, and a complex heuristic to decide when to erase sessionStorage completly. I vote for the data to be present just while a page is open or is restored from history or by going back. Thank you. -- João Eiras Core Technology developer
Re: [whatwg] URL decomposition on HTMLAnchorElement interface
Interestingly, it looks like Opera doesn't support the hostname setter at all. Safari ignores the call in this case. I don't have IE to test offhand. True. Opera currently does not support setting these values separately.
Re: [whatwg] URL decomposition on HTMLAnchorElement interface
Browsers also support partially setting each of the url fields separately, although error handling between all of them is very inconsistent. Note: if you specify this behavior, then you need to specify what happens for http:, https:, data:, mailto: and unknown: On Thu, 26 Mar 2009 19:32:46 +0100, Kartikaya Gupta lists.wha...@stakface.com wrote: It seems that major browsers all support URL decomposition on HTMLAnchorElement, but this doesn't seem to be stated anywhere in the HTML5 spec. The jQuery/tabs library seems to depend on this (specifically, on the hash property) being available. Could the HTMLAnchorElement interface be updated to reflect this? Cheers, kats -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [whatwg] C:\fakepath\ in HTML5
Which sites? Any site that *requires* a Windows path clearly isn't interested in inter-operating with other browsers/platforms; heck, it means they've limited their testing to just Windows/IE. Don't punish the rest of us for their poor testing/programming. My friend ! Welcome to the internet :) opera adopted this behavior because for a long time we were the only ones with only the file name. And for a long time we always had compatibility problems, and sites that simply refused to fix. I recall Orkut avatar upload (checked for : in input.value), and some router firmwares. So, while keeping the privacy of the user we added c:\fake_path for the reasons mentioned. It's a sad true, but it was necessary. - Bil -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [whatwg] script-related feedback
On , Ian Hickson i...@hixie.ch wrote: On Fri, 12 Dec 2008, Martin Atkins wrote: Could browsers handle confirm() and friends in such a way that they only block the contents of the tab, not the whole browser? In particular, the close tab and close window features, ideally along with things such as Back, Forward and Home should still be available. It'd have to block any page in the same unit of related browsing contexts, but otherwise yes. Chrome does this, mostly. IE8 probably too. That is a browser issue. Chrome and IE8 don't have it because they are multi-process. Opera never had the issue because processing is always divided between the UI and webpages. No spec should go into great lengths specifying how UI should behave and look, although it can make recommendations.
Re: [whatwg] Modal dialogs in HTML5
On , Ian Hickson i...@hixie.ch wrote: On Mon, 28 Apr 2008, Joao Eiras wrote: What happened to the 3rd parameter (sFeatures) ? http://msdn2.microsoft.com/en-us/library/ms536759.aspx This parameter is needed to specific the window features (size, position, ...). I couldn't find any features that I could justify specifying, so I omitted it. IMHO the UA should determine the size and position automatically; why would the author specify them? The author has no way to know what a reasonable value is. While I myself don't find any decent use case for positioning the window, I think sizing the popup is a common and useful use case,besides controlling other aspected already covered by window.open(). Because the behavior for the features argument in window.open() and showModalDialog are similar (if not equal), I would recommend adding it to showModalDialog for the sake of normalization (you could link one spec to the other) and because UA would eventually reuse the implementation of window.open for both cases, therefore not requiring extra work from scratch.
Re: [whatwg] Use cases for Node.getElementById (was: Re: Early feedback on header association algorithm)
IMO, anyone suggesting a Node.getElementById clearly does not know very well how getElementById is supposed to work. There are ways to transverse a DOM tree currently, either DOM properties and methods, XPath, selectors API and such. Considering ids are required to be unique in the context of a single document, implementations can, and do, implement id lookup using optimized data structures like a hash table, which is much more performant than doing transversal. So if there is a special node in a document, add an id to it and get its reference will be performant (ideally O(1)). If the uniqueness requirement is removed, then getElementById looses its whole meaning and should actually be removed from the specification entirely, else then we would need more bloat like getElementById or getElementListById and whatever. If you really need to get the element with id in a subtree, connected or disconnected from the main tree, one can use selectors API, DOM transversal, XPath, etc. So, IMO the DOM spec is just fine. What is asked for Node.getElementById is already supported by other APIs.
Re: [whatwg] ---
Who ever said that the standards are here for browsers? That's the whoe point of standards: to ensure interoperability between the laters. HTML is a markup language that is meant to describe how content is to be tagged so it can be retrieved based on markup. This has absolutely nothing, and I mean NOTHING to do with browsers, screenreaders, bots, or even humans as far as I am concerned. HTML still needs to be interpreted and rendered. You mention the DOM for example. Good, the DOM is a way of describing how HTML can be implemented in a browser. If you as browser vendors want to describe that and agree upon it amongst yourselves...fine, I would welcome that. That's what the WHATWG and W3C are for: to agree a common set of rules for web technologies. Thanks for the laugh. Now, think twice before rewritting such non-sense. Goodbye.
Re: [whatwg] Constrains of the value propety of Controls
On , Ian Hickson [EMAIL PROTECTED] wrote: I have attempted to answer this question in the HTML5 specification. Please let me know if the resulting text is inadequate. Cheers, It's much better. Thanks
Re: [whatwg] video tag : loop for ever
I shudder to think about looping audio, however. Animated GIFs are often called dancing baloney ... and looping audio would be...? One can program a game with svg or canvas with background music and sound effects, which is something proprietary plugins already allow.
Re: [whatwg] video tag : loop for ever
Is there any possible usefulness whatsoever in making playcount=0 not play the video at all? That's what autoplay is for. On Wed, Oct 15, 2008 at 5:53 PM, Andy Lyttle [EMAIL PROTECTED] wrote: On Oct 15, 2008, at 8:38 AM, João Eiras wrote: Why not just assuming that playcount=0 means loops forever ? This was exactly my thought. If playcount=5 causes the video to be played 5 times, what should the result of each of these be? playcount=1 playcount=0 playcount=-5 playcount=foobar Is there any possible usefulness whatsoever in making playcount=0 not play the video at all? If not, I don't see a good reason not to use that to mean infinite looping. Either that, or some keyword, but I don't know what it should be. infinite and forever come to mind. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] video tag: pixel aspect ratio
The entire problem is that it is not simple. It is less simple to spec, less simple to declare, less simple to parse, and less simple to test, and there is zero real-world gain in it. sarcasmOh! Then just drop video completly. Better, drop html5 and there will be even less trouble with specifications./sarcasm If you can come up with a argument that supports a float value, like a real world use case, other than we don't feel like editing the spec to add better, more robust functionality, then you have my support :)
Re: [whatwg] Safari-compatible input type=search
Would it be desirable to allow the icon to be specified in css? That's up to the author/user agent, and currently you can have a small icon in the background of an edit field with regular css. On Wed, Oct 1, 2008 at 8:29 AM, Garrett Smith [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 3:46 PM, Andy Lyttle [EMAIL PROTECTED] wrote: On Sep 30, 2008, at 2:55 PM, Christoph Päper wrote: Anyhow, the appearance of this or other types of |input| should not be specified by HTML5 / WF2+. Of course browsers could choose what the icon should look like; Would it be desirable to allow the icon to be specified in css? -- Andy Lyttle
Re: [whatwg] Placeholder option for text input boxes
This usage is deprecated because it can not be generalized to all possible attribute names We recommend the use of generic methods on the core Element interface for setting, getting and removing attributes. Although I understand your reasoning, I disagree. The DOM does not exist only to wrap the representation of the original document markup. The DOM is a programming API and programmings API should make programs more easy to code nd more performant. Having a get/setAttribute indirection plus type conversions between serialized strings and back to a usable type (number, function) are not friendly at all. The idea of dom properties for attributes is not to find a generic structure for all atributes, but to have support for known attributes with known behavior. Please, don't make such claim again, they are misleading, and clearly not realistic. On Wed, Oct 1, 2008 at 12:39 PM, Kristof Zelechovski [EMAIL PROTECTED] wrote: The attributes are exposed as properties for compatibility with DOM Level 0. This usage is deprecated because it can not be generalized to all possible attribute names, as is required both for XML and potentially for future versions of HTML. We recommend the use of generic methods on the core Element interface for setting, getting and removing attributes. http://www.w3.org/TR/2000/WD-DOM-Level-1-2929/level-one-html.html#ID-64 2250288 -Original Message- From: Benjamin Hawkes-Lewis [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 12:42 PM To: Kristof Zelechovski Cc: 'Garrett Smith'; [EMAIL PROTECTED] Subject: Re: [whatwg] Placeholder option for text input boxes Kristof Zelechovski wrote: DOM properties are not becoming obsolete; accessing attributes by properties is. Hmm. Citation? -- Benjamin Hawkes-Lewis
Re: [whatwg] Placeholder option for text input boxes
Which attributes return a number directly? Which attributes return a function directly? This is already clearly defined in DOM 2 HTML. So following your line of reasoning, the entire DOM 2 HTML spec is deprecated ?
Re: [whatwg] Placeholder option for text input boxes
Another thing:
if( 'placeholder' in referencetoInput ){ ... }
can be used for feature detection, else a javascript fallback could be
supplied as the later is the common case.
On Wed, Oct 1, 2008 at 6:27 PM, Aaron Boodman [EMAIL PROTECTED] wrote:
On Wed, Oct 1, 2008 at 10:05 AM, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
Please. This thread is not abort how to write JavaScript code in general.
It is about how to write the feature detection code. This kind of code
should be especially robust and relying on deprecated features does not make
it more so.
Ok, let's separate out the 'how people should program' part from the
'what we will support part'. My opinion is that input.placeholder
should be supported, because it is consistent with how everything else
works.
I don't think that most web developers even know that accessing
attributes as properties is deprecated, and would be surprised that
setting input.placeholder does nothing.
- a
Re: [whatwg] Client-side includes proposal
include src=static-header / include src=user-specific-data / include src=dynamic-daily-content / This is something that would probably not be represented with a new element, because elements are preserved in the DOM tree so they can be accessed and queried. So then you'd have a question: keep includein the dom and allow access to children like an iframe, or replace include entirely ? The answer could be intuitive, but that can open a can of worms. Then you can do all sorts of dynamic manipulation, which would have to be very well specified. I think the way to go would be a processing instruction. The idea is good though ! But I think could be better implemented with a css template like feature. I don't like the idea of a new element. Bye.
Re: [whatwg] VIDEO tag height/width best fit
Hi ! In this regard, video should be handled like img. While handling an image, if you specify a width and leave height as auto, the UA will resize the height to keep the aspect ratio, because the UA known the images intrinsic dimensions. The same behavior happens if you specific height and leave width as auto. IF you specifi non, intrinsic dimensions will be used. So, for video, the behavior should be the same. The UA knowns the video file intrisinc dimensions, so the samebehavior can be applied too. This way we would not overspecify new behavior, which is good, and IMO enough, therefore simplifying the work of the web authors by reusing the old algorithm used for images. Bye. On , Biju [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I apologize if I did not understood http://www.whatwg.org/specs/web-apps/current-work/#video I see a situation where we want to specify the height and width of the BOX in which a video need to be displayed. And while writing HTML code we dont know the height/width of the video. But when playing we want the video to be displayed with maximum size which can fit in the BOX without loosing the aspect ratio. After reading the video tag specification I dont see a way to achieve this with out javascript code. We should have one more attribute to tell how to fit the image/video == fit attribute values === * center - if it is small keep at center * stretch - stretch/skew height and width to fit * stretch-height - stretch/skew height only to fit, adjust width to maintain aspect ratio. * stretch-width - stretch/skew width only to fit, adjust height to maintain aspect ratio. * stretch-best- stretch/skew height or width to maximum so that other will fit in and maintain aspect ratio. May be we can also have a tile option This problem also exist for img tag.
Re: [whatwg] What should the value attribute be for multi-file upload controls in WF2?
Hi
There's a small problem with that too, because we would need a way to handle
file names
that contained quote marks, which is possible on Mac and Linux, but not on
Windows.
Not only that, but in unix flavours, paths are separated with : while
in windows they're separated with ;
In *nix special char are escaped with \ while in windows \ separates
directories in paths.
So IMO, it won't be possible to com up with a solution that is cross
platform without making up something completly new.
I'd suggest for HTMLInputElement to have a .files or .paths property
which would be an array of all the files choosen, names only.
On Fri, Jun 20, 2008 at 2:44 PM, Lachlan Hunt [EMAIL PROTECTED] wrote:
Adele Peterson wrote:
I'm looking at the Web Forms 2 specification for the multi-file upload
control that uses the min/max attributes. When multiple files are selected,
its unclear what the value attribute should contain.
Assuming you're referring to the value DOM attribute, not the value=
content attribute, It seems to be unclear what the value should contain even
when there's only a single file selected.
I did some testing to see what each returned. All tests use this markup to
obtain the value, using the Live DOM Viewer:
!DOCTYPE html
input type=file id=test size=100
input type=button onclick=w(document.getElementById('test').value);
value=Read Value...
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cinput%20type%3D%22file%22%20id%3D%22test%22%20size%3D100%3E%0D%0A%3Cinput%20type%3Dbutton%20onclick%3D%22w(document.getElementById('test').value)%3B%22%20value%3D%22Read%20Value...%22%3E
In each one, I selected a file named test.txt from within my home or My
Documents directory. These are the vaules returned in each browser:
Windows browsers:
IE 8: test.txt
IE 7 mode:test.txt
Firefox 2:D:\My Documents\test.txt
Firefox 3:test.txt
Opera 9.5:C:\fake_path\test.txt
Safari 3.1.1: D:\My Documents\test.txt
Mac browsers:
Firefox 3:test.txt
Opera 9.5:C:\fake_path\test.txt
Safari 4 (Developer Preview): /Users/lachlanhunt/test.txt
It could contain just the first filename, or a comma separated list of all
of the filenames. I think it will be useful though to add something about
this in the specification for consistency.
Opera 9.5 supports multiple file selection when a max= attribute is set to
a value greater than 1. It currently only returns the fake path of the
first file, as shown above. However, the control displays to the user the
real paths of all files selected as quoted strings separated by semi-colons.
e.g.
/Users/lachlanhunt/test.txt;/Users/lachlanhunt/other.txt
Since Both Firefox 3 and IE 8 only return the file name, and Opera 9.5
refuses to return the real path anyway, maybe we should define that when
there's only a single file selected, it returns just the file name. When
there are multiple files selected, would a string containing the file names,
each surrounded by quotes and separated by semi-colons work?
e.g. test.txt;other.txt
There's a small problem with that too, because we would need a way to handle
file names that contained quote marks, which is possible on Mac and Linux,
but not on Windows.
But it really depends what use cases we need to address. Do authors ever
actually obtain the file name using JavaScript for anything? If so, what
for? With multiple file selection, is it likely they would want to inspect
each individual file name for anything, in which case, should we find a way
to make it easier to obtain individual file names?
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] Javascript API to query supported codecs for video and audio
The spec clearly says the following http://www.whatwg.org/specs/web-apps/current-work/#video1 User agents should not show this content to the user; it is intended for older Web browsers which do not support video, Although we fully understand the reasoning behind this, there's an use case missing. The user agent may support video but might not support the file format. So in this case, video should do fallback, because: a) video tags are markup and therefore its error handling is not available to scripts b) the author may not want to use scripts, or may want to make the page fully usable with scripting c) it's a predictable scenario without any written solution 2008/6/18 Philip Jägenstedt [EMAIL PROTECTED]: Sorry, my reply was cut short. Again: It seems to me that it's a good idea to wait with this until we know more about what will happen with baseline codecs etc. Implementation-wise it might be less than trivial to return an exhaustive list of all supported mime-types if the underlying framework doesn't use the concept of mime-types, but can say when given a few bytes of the file whether it supports it or not. Allowing JavaScript to second-guess this seems like a potential source of incompatibility. Isn't it sufficient to look for MEDIA_ERR_DECODE and add fallback content when that happens? Philip On Wed, 2008-06-18 at 17:34 +0700, Philip Jägenstedt wrote: It seems to me that it's a good idea to wait with this until we know more about what will happen with baseline codecs etc. Implementation-wise it might be less than trivial to return an exhaustive list of all supported mime-types if the underlying framework doesn't use the concept of mime-types, but can say when given a few bytes of the file whether it supports it or not. Allowing JavaScript to second-guess this doesn't seem great On Wed, 2008-06-18 at 12:18 +0200, [EMAIL PROTECTED] wrote: On Wed, 2008-06-18 at 12:03 +0200, Anne van Kesteren wrote: Why is that needed? The elements provide a way to link to multiple codecs of which the user agent will then make a choice. i do not intend to provide multiple codecs since that would require multiple backend implementations for playing files form an offset, encoding files in multiple codecs on the server, more disk space etc, instead i would only use the video tag if the codec i use is supported and fall back to other means via object / java / flash or whatever to playback the video or indicate that the user has to install a qt/dshow/gstreamer plugin. in an ideal world i could use video like i can use img now and be done with it, but since this is not the case we need tools to make the best out of video, not knowing what the browser supports and just hoping that it could work is not an option. j -- Philip Jägenstedt Opera Software
Re: [whatwg] Proposal: target=_tab
2008/6/13 Borek Bernard [EMAIL PROTECTED]: Hi João, you're right that everything important has been already said. I have withdrawn this proposal because it has been pointed out that it is not backwards compatible and the correct solution will be part of CSS3 anyway (which is much more flexible - we will have not only target-new, but also target-position; I guess you strongly dislike both of them). What's lovely about css, is that features like this can be easily disabled with local stylesheet. Overriding _tab would requiring running local script, which greater performance impact, and migh thave unforseen consequences. So css gives greater control, with less effort. But the discussion has been interesting anyway. There is probably no point in carrying on because we see the problem from two different standpoints - you want to have the specs as pure as possible while I want them to be as flexible as possible so that it can accommodate any use case you can think of. It's not about being pure, it's about not giving more control to the webpage than it should have. For a webpage running in a tab or separate window is exactly the same thing. I kind of understand why simpler standards are better than the longer ones but on the other hand, the lack of _tab or something similar makes my user experience on some websites suboptimal (heck, even frustrating sometimes). If you can't appreciate that different users can have different user preferences (I can't honestly come up with a single reason why a webpage should open a new window instead of tab), This is not a user preference. It's the complete opposite. The spec would allow a user preference to be broken by spaning windows or tabs accordingly to the webpage author's liking. Historically, we've seen that giving webpage control over the user's browser in someway can be abused: alert(), open(), oncontextmenu ... you will probably have hard times understanding my points. But your view is quite common as I've learned :) Regards, Borek - Original Message From: João Eiras [EMAIL PROTECTED] To: Borek Bernard [EMAIL PROTECTED]; whatwg@lists.whatwg.org Sent: Thursday, 12 June, 2008 7:17:19 PM Subject: Re: [whatwg] Proposal: target=_tab Hi ! I didn't saw that reply. I'm not sure why you keep insisting that it's up to the browser -- IMO, it's up to the USER. You're not understanding me: when I say browser, obviously I mean client, client-side, browser, user or whatever you want to call it, as opposed to web application or server-side Also, having means to open new tabs as opposed to new windows in the specs is nothing against the user preference, in fact, it helps to express the user preference if the browser fails to provide it. Then we're going to bloat a specification due to browser idiosyncrasies ? Allowing a page to control such behavior would be bad. Currently browsers with tabbed interface manage to unclutter the taskbar and desktop, while aggregate pages inside a single window, which is overall good for the user's experience, good for performance, good usability. We'd be providing a mechanism that is not backwards compatible with the current state of the art user agents, although we've seen that new features heavily demanded get implemented quickly, and we'd be providing, again, authors with mechanism to degrade the user's experience. I can't honestly come up with a single reason why a webpage should open a new window instead of tab. All use cases you can come up fit better if new tabs are open. If you don't like the fact that a tab fits the entire window, you can either detach it, your use a user agent that support MDI interface. With all this say now your going to tell me I'm contradicting myself by supporting windows now. No, you'd be wrong. I'd expect a browser to always open tabs if there's a _blank target. Having _target and_tab would require UA's to support two different way of opening new pages: tabbed and detached ones. For me it's all a matter of letting the user control the web page. Considering this discussion is still going to last a bit, and everything significant that could be said by me and others was said, I rest my case. Cheers. 2008/6/12 Kristof Zelechovski [EMAIL PROTECTED]: Programmatically controlling the containment of a new window is a two-edged sword: you can provide for the lame user agent but you can also override user settings. The latter possibility is more painful; upgrading the browser is easier than dealing with an impertinent Web site. IMHO, Chris P.S.: If you want your answer to go to João only, just send it exclusively to him. -Original Message- From: Borek Bernard [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 11:25 AM To: Joao Eiras; Kristof Zelechovski; Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi João, I'm not sure why you keep insisting that it's up
Re: [whatwg] Proposal: target=_tab
Hi ! I didn't saw that reply. I'm not sure why you keep insisting that it's up to the browser -- IMO, it's up to the USER. You're not understanding me: when I say browser, obviously I mean client, client-side, browser, user or whatever you want to call it, as opposed to web application or server-side Also, having means to open new tabs as opposed to new windows in the specs is nothing against the user preference, in fact, it helps to express the user preference if the browser fails to provide it. Then we're going to bloat a specification due to browser idiosyncrasies ? Allowing a page to control such behavior would be bad. Currently browsers with tabbed interface manage to unclutter the taskbar and desktop, while aggregate pages inside a single window, which is overall good for the user's experience, good for performance, good usability. We'd be providing a mechanism that is not backwards compatible with the current state of the art user agents, although we've seen that new features heavily demanded get implemented quickly, and we'd be providing, again, authors with mechanism to degrade the user's experience. I can't honestly come up with a single reason why a webpage should open a new window instead of tab. All use cases you can come up fit better if new tabs are open. If you don't like the fact that a tab fits the entire window, you can either detach it, your use a user agent that support MDI interface. With all this say now your going to tell me I'm contradicting myself by supporting windows now. No, you'd be wrong. I'd expect a browser to always open tabs if there's a _blank target. Having _target and_tab would require UA's to support two different way of opening new pages: tabbed and detached ones. For me it's all a matter of letting the user control the web page. Considering this discussion is still going to last a bit, and everything significant that could be said by me and others was said, I rest my case. Cheers. 2008/6/12 Kristof Zelechovski [EMAIL PROTECTED]: Programmatically controlling the containment of a new window is a two-edged sword: you can provide for the lame user agent but you can also override user settings. The latter possibility is more painful; upgrading the browser is easier than dealing with an impertinent Web site. IMHO, Chris P.S.: If you want your answer to go to João only, just send it exclusively to him. -Original Message- From: Borek Bernard [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 11:25 AM To: Joao Eiras; Kristof Zelechovski; Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi João, I'm not sure why you keep insisting that it's up to the browser -- IMO, it's up to the USER. Please read all my arguments before, it's not true that a user using a tabbed browser always prefers opening new tabs instead of new windows. That's just your user preference. Also, having means to open new tabs as opposed to new windows in the specs is nothing against the user preference, in fact, it helps to express the user preference if the browser fails to provide it.
Re: [whatwg] Proposal: target=_tab
As mentioned multiple times, that up to the user agent, or browser if you prefer, to control. Users with browsers with tabbed interface want tabs and that it. Leaving such usability in control of a webpage is bad. All browser that support tabs allow the user to choose if they want the browser to open new windows of just tabs. Na , Kristof Zelechovski [EMAIL PROTECTED] escreveu: You can use A.click instead of window.open. I have ignored the keyboard shortcut requirement because it is irrelevant. I agree that modifying window.open to support tabs would be more consistent; I just wanted to make you realize that neither is it strictly necessary nor does it require any support from JS itself (your postulated modification of the window.open interface method is perfectly suited for the current JS language, I hope?). HTH, Chris -Original Message- From: Borek Bernard [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:27 AM To: Kristof Zelechovski; Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi Kristof, my knowledge of JS is limited but how would you handle this situation: in your web app, you want to provide a keyboard shortcut for opening current item into a new tab. You need to invoke this action from JavaScript so setting CSS to some DOM element is not enough (AFAIK). I think window.open() would need some new optional parameter or something similar to support this. --- Borek
Re: [whatwg] Proposal: target=_tab
IMO, both _blank and _tab should always open in the same window, under a new tab. Else that would be bad usability. Browsers currently already support this. So, I think it's therefore redundant. Na , Simon Pieters [EMAIL PROTECTED] escreveu: In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that authors should have the ability to suggest that links open in new windows and new tabs. The suggested solution is to introduce a new browsing context keyword _tab. Use case for opening a new window with specified size: help popup. Use case for opening a new window without specified size: print page. Use case for opening a new tab: links in GReader for later reading. Demand for this feature: http://www.google.com/search?q=_tab
Re: [whatwg] Modal dialogs in HTML5
Na , Ian Hickson [EMAIL PROTECTED] escreveu: This is a first draft. It has issues, I'm sure. Let me know what I should fix... Hi! What happened to the 3rd parameter (sFeatures) ? http://msdn2.microsoft.com/en-us/library/ms536759.aspx This parameter is needed to specific the window features (size, position, ...). Also, IE supports the properties dialogLeft, dialogWidth, dialogTop and dialogHeight. Two of these can be read from innerWidth and innerHeight, while the other two are irrelevant, and hardly useful for a webpage. But, omitting these from the spec will create implementation discrepancies. Probably you could add an extra section with features that were purposely left out of the spec ? I've built some time ago a comprehensive testcase (it's attached), to test IE's showModalDialog implementation, and besides what is common sense, IE drops hashes from the url which is passed to showModalDialog, and IE truncates, on purpose, the dialogArguments parameter to 4096 chars, if it's a string. I see no possible reasoning for these design choices. Regarding the spec: - about step 1. : you could mention that showModalDialog might be blocked by popup blockers too, which is easier to understand for the crowd. - about step 3. : there's this clause from running scripts. Well showModalDialog blocks so all script execution must be halted while showModalDialog does not return. So is this wording correct ? - about step 8. : you could add the browing context can signal the UA to terminate, e.g. calling window.close() Another thing: while the use cases for showModelessDialog can already be covered by window.open(), there is a difference in behavior: - window.open creates a new window, which can be lose focus, and go behind it's opener window. - showModelessDialog creates a new popup window, which can too lose focus, but will never go behind it's opener. It'll say always in front of it. Use cases ? Consider you have a web application, and some help documents. While you have the main application open, you can open a dialog with a help manual and continue to work on the application while you have the manual on top, without the user needing to fiddle with windows and/or tabs. Implementing this is pretty straightforward. MS spec on showModelessDialog: http://msdn2.microsoft.com/en-us/library/ms536761.aspx Cheers. Title: testcase FAILED (script did not run)
Re: [whatwg] postMessage() issues
Hi! I agree with everything Maciej said, but I'm rather impartial. The word post implies posting something to a queue of messages, like we've seen in other programming APIs. There are use cases for both sync and async API, so we should support both. We could have either a new parameter for postMessage, like with have for XHR, which defines the behavior (if async or not), or we could have two functions postMessage asynchronous and sendMessage synchronous. Then everyone would be happy. Thank you. 2008/4/16, Maciej Stachowiak [EMAIL PROTECTED]: On Apr 15, 2008, at 5:10 PM, Ian Hickson wrote: At the moment people have proposed that the API be asynchronous, and some people are ok with that, but other people are strongly opposed to it. I am not sure where to go with this. Input from other browser vendors -- yourself and WebKit in particular -- would be very useful. Right now the API is synchronous, and Mozilla reps have indicated they strongly prefer that, Opera reps have indicated they don't mind, and Gears reps have indicated they'd rather it be async. I think async is better, for the following reasons: - PostMessage seems to imply a message queue model. - Processing a reply synchronously is awkward in any case, since you need a callback. - This is different from event dispatch because replies are expected to be common; two way communication channels like postMessage make more sense as asynchronous, while event dispatch is typically one-way. - Saying that runaway two-way messaging should be handled by a slow script dialog seems weak to me, compared to making the mechanism intrinsically resistant to runaway behavior. - Making new communication APIs async makes it more practical to partition browsing contexts into separate threads, processes, operation queues, or other concurrency mechanisms (within the limitations of what kind of things must be serialized. - We can foresee that workers in the style of Gears will be a future use case for postMessage; in that case, it clearly must be async. However, I don't feel very strongly about this and I would consider synchronous postMessage acceptable. (Note also that Eric Seidel, who commented on this issue earlier, was also giving his feedback as a WebKit developer, though in both cases we speak mainly for ourselves and not as an official position of the whole project.) Regards, Maciej
