Re: [whatwg] Run javascript code once
On Fri, 10 Jun 2011 22:30:42 + (UTC), Ian Hickson wrote: On Thu, 31 Mar 2011, Diogo Resende wrote: I would like your opinion on this use case: I have an app divided in several modules, each one has a javascript code that needs to run to show the module page and init the interactions. The app is not supposed to reload to show each module. What is the best way to fetch the javascript code and run it? Add a script for that module and remove it when switching to another module? Download using AJAX or other technology and use eval()? I'm not sure I understand the use case exactly. If you just mean that you have several different panels or modes that the user can switch between, then I would recommend just having several section elements, one for each module, and all but the active one have a hidden= attribute. Script-wise, you'd just have each script loaded and active from the start, they'd just only work with their own sections. The sections are not possible to enumerate or can be too many to enumerate. Imagine MobileMe, where each section of the web app has it's own interaction (java)script (I suppose). I'm looking for the best way to load that when switching between sections/modules and discarding it when switch back. Perhaps MobileMe could have the interaction all bundled in one script, but for a bigger app to have a fast load/response time, the scripts should be divided.. I think.. -- Diogo
[whatwg] Run javascript code once
Hi, I would like your opinion on this use case: I have an app divided in several modules, each one has a javascript code that needs to run to show the module page and init the interactions. The app is not supposed to reload to show each module. What is the best way to fetch the javascript code and run it? Add a script for that module and remove it when switching to another module? Download using AJAX or other technology and use eval()? -- Diogo
Re: [whatwg] Form input element for value-unit pairs
On Mon, 14 Mar 2011 22:09:26 +0200, Jukka K. Korpela wrote: Christoph Päper wrote: A new type is probably not necessary, because a new attribute that is called something like ‘unit’ and is only valid in the ‘number’ and ‘range’ states could be enough. input type=number id=fontsize value=12 unit=pt I don't quite see the point (no pun intended). It seems that the unit=pt attribute just says that the input number will be interpreted as a number of points, i.e. a certain unit will be implied. This sounds unnecessary, as the form data processing can handle such things without any extra attributes. Or do you mean that the presence of the unit=... attribute would trigger a special implementation of numeric input, so that the user is expected to enter both a number and a unit, with the latter defaulted according to the unit attribute? For me it would be great that a UA would implement an numberic input with a visible but unchanged unit. Something like an input+span but the span looking to be inside the input. [__12_pt_] ^-- cursor would not pass this point Extra: This is more interesting for other types of input, not necessarily numeric, like IPv4, currencies, HH:MM, ..
Re: [whatwg] datalist @exclusive
On Thu, 10 Mar 2011 21:28:44 -0500, Aryeh Gregor wrote: On Wed, Mar 9, 2011 at 5:08 PM, Diogo Resende drese...@thinkdigital.pt wrote: That is perfect for 1 date scope. What if I have a meeting to schedule in a month (eg. March) and (according to other meeting attendees) the meeting can only happen from 10-15, 19, 20-28 and 30. Do I have to make a data-list with every possible day? input type=date pattern=2011-03-(1[0-59]|2[0-8]|30) You meant 0-5 and not 0-59 :P. A good UI implementation could at least check the pattern against every day currently displayed in the date-picker and gray out any that don't match it. I don't know how feasible it would be to gray out the next/previous month buttons or anything just based on patterns, though. Also, I'm not sure we really want to force people to use regex for this . . . What if I would like to set a future event that cannot happen on weekends? That might be possible with regex in theory, but I really don't want to see it. :) I love regex but I agree with you that for that pattern is seems pretty obvious, but for others it's not that simple. And no, my weekend question cannot be done with regex (at least in a short way :P). Maybe 2 methods for enabling/disabling days in the input would be better for more complex scenarios.
Re: [whatwg] datalist @exclusive [was: Please reconsider: Set restricted palette for input type=color]
On Tue, 8 Mar 2011 16:51:25 -0800, Jonas Sicking wrote: On Tue, Mar 8, 2011 at 10:46 AM, Markus Ernst derer...@gmx.ch wrote: Am 08.03.2011 19:02 schrieb Anne van Kesteren: On Tue, 08 Mar 2011 12:26:56 +0100, Jukka K. Korpela jkorp...@cs.tut.fi wrote: For example, consider a date picker. Quite often, whether trying to make dates or selling flights, there is a known set of (non-consecutive) days that are possible, so we would like to write, say, input type=date id=date name=date value=2011-04-01 list=datelist datalist id=datelist option value=2011-04-01 label=April 1st option value=2011-04-08 label=April 8th option value=2011-04-09 label=April 9th /datalist (...) / Jonas I was thinking.. what about allowing big time spans, like: from April 1st to June 30th? Giving that the date has - as date element separators we could not use 1-MM1-DD1-2-MM2-DD2. Couldn't this be useful? Even more common might the usecase where a date must be from some date onward (or until some date). How is this addressed? - Diogo
Re: [whatwg] Form input element for value-unit pairs
This is just a numeric input. It has a unit, just like a monetary value, but besides that it's just a number. Maybe a numeric input should have some type of formatting to proper show the unit (prefix/suffix, decimals places, decimal sep., ...). On Sat, 5 Mar 2011 18:26:52 +0100, Christoph Päper wrote: Imagine a richt text processor done in HTML5. If you want to select the font size (of a template or class, of course) how would you do it? Standalone word processors usually have a combo field that lets the user enter a number [12] possibly adding controls for increasng and decreasing [12]±[12]↕ or they may allow the user to select one of the predefined recommended or frequent values. [12 ↓] These are commonly using, without explicitly mentioning it, the magic unit ‘point’, which users usually don’t know, especially if they’re not from the US and are not trained typographers. In other places, software interface designers honor the variety of absolute and relative (length) units by introducing a widget that bears the number and the unit symbol, [12 pt]± which can both be changed, although not independently. ‘pt’→‘px’ ⇒ [12 px] not [16 px] Some implementations are even broken in that they accept many unit symbols, but always autoconvert (and round) to a preferred unit. [4 mm] → [11.34 pt] Thus, would it make sense to add another new type for the ‘input’ element?
Re: [whatwg] wrapper element
I agree with Bjartur, div does the work fine. On Sun, 27 Feb 2011 19:40:15 -0500, ddailey wrote: Given that SVG and HTML are now interminglable in the same document, why not start intermingling their tag definitions? Please don't start mixing SVG+HTML properties or one day it will be a hell of a mess..
Re: [whatwg] Thoughts on recent WhatWG blog post
On Mon, 7 Feb 2011 15:03:55 -0500, Aryeh Gregor wrote: On Mon, Feb 7, 2011 at 12:33 PM, Adam van den Hoven a...@littlefyr.com wrote: ... Further, in CommonJS, the library has to export an object in order to make it available. If we could define things in such a way that the browser compiled the library independent of the page that loads it, the browser could cache the *compiled* code and provide that to the browser page. It would also be necessary to either enforce that these cached libraries be immutable or that a copy of the compiled code be made available. I couldn't implement this so I'm not sure how feasible this is but I suspect that requiring immutability would be the easier to implement. What problem does this solve? How is it better than inserting a script element, when the returned resource has suitable caching headers? I think Adam's opinion is a bit influenced by CommonJS. Although I like the require() thingy, I think this feature would be much more appreciated for author app objects and extensions (similar to RequireJS) than HTML specific things like crypto et al.
Re: [whatwg] Limiting the amount of downloaded but not watched video
downloadBufferTarget in seconds is not that good. Think about a movie that takes more to load than to see. Depending on the settings the developer done, you might have to pause the video at some point to load the rest of the movie. On Mon, 17 Jan 2011 17:41:13 +0100, Jeroen Wijering wrote: Hello all, We are getting some questions from JW Player users that HTML5 video is quite wasteful on bandwidth for longer videos (think 10min+). This because browsers download the entire movie once playback starts, regardless of whether a user pauses the player. If throttling is used, it seems very conservative, which means a lot of unwatched video is in the buffer when a user unloads a video. I did a simple test with a 10 minute video: playing it; pausing after 30 seconds and checking download progress after another 30 seconds. With all browsers (Firefox 4, Safari 5, Chrome 8, Opera 11, iOS 4.2), the video would indeed be fully downloaded after 60 seconds. Some throttling seems to be applied by Safari / iOS, but this could also be bandwidth fluctuations on my side. Either way, all browsers downloaded the 10min video while only 30 seconds were being watched. The HTML5 spec is a bit generic on this topic, allowing mechanisms such as stalling and throttling but not requiring them, or prescribing a scripting interface: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-resource Are there people working on ways to trim down the amount of not-watched data for video playback? Any ideas on this, anything in the pipeline? --- A suggestion would be to implement / expose a property called downloadBufferTarget. It would be the amount of video in seconds the browser tries to keep in the download buffer. When a user starts (or seeks in) a video, the browser would try to download downloadBufferTarget amount in seconds of video. When downloaded currentTime + downloadBufferTarget, downloading would get stalled, until a certain lower treshold is reached (e.g. 50%) and the browser would start downloading additional data. A good default value for downloadBufferTarget would be 60 seconds. Webdevelopers who have short clips / do not care about downloads can set downloadBufferTarget to a higher value (e.g. 300). Webdevelopers who have long videos (15min+) / want to keep their bandwidth bill low can set downloadBufferTarget to a lower value (e.g. 15). Webdevelopers might even change the value of downloadBufferTarget per visitor; visitors with little bandwidth get a sizeable buffer (to prevent stuttering) and visitors with a big pipe get a small download buffer (they don't need it). The buffered timeranges could be used to compare the actual download buffer to the buffer target, should a user-interface want to display this feedback. Note that the download buffer is not the same as the playback buffer. A download buffer underrun should not result in pausing the video. The download buffer does also not apply to live streaming. Kind regards, Jeroen Wijering Longtail Video PS: Having the preload=none property available in all browsers will also help in keeping the amount of downloaded but not watched data low. In our tests, only Firefox (4 b9) seems to honor this property at present.
Re: [whatwg] Device Element
Flash is insecure, so HTML5 should be too? Seriously? Flash is insecure because there's no security policies. It's similiar to the firefox feature to read files: you read all or you read none. That's not a good policy. Something similar to the geolocation would be better (this specific site/app can access this specific device).
Re: [whatwg] Bluetooth devices
Replied inline.. On Sat, 2010-12-18 at 21:56 +, Bjartur Thorlacius wrote: On Fri, 17 Dec 2010 10:42:52 -, Diogo Resende drese...@thinkdigital.pt wrote: Let's think about an example, perhaps a bluetooth weather station. For the OS it's just another bluetooth device. What if a web app could have permission (granted by the user/browser) to scan for bluetooth devices and fetch weather information, save it on the weather history and process it in some way. Then someone would create a web app that scans for specific models of bluetooth devices, connects to them, fetches weather information and processes it in some way. All is fine and dandy, as long as everybody is using exactly the same model as the author (or one of the models supported by the company maintaining the app), and needs to apply that process and that process alone. Bluetooth was an example. We were discussing a serial connection in general. It could be BT or RSR232/USB or anything else. I was not thinking specifically about a web app that would do that, I was just thinking that talking to a serial device could be very handy. Say someone creates a web app that applies a process to weather information gathered from an hypothetical Weather-o-Meter connected via Bluetooth. Say I'm doing a research on global warming and the Gulf stream, and want to apply that process to weather information gathered from all over the country. Even if all the weather stations in Iceland are using Weather-o-Meter, I won't receive the information over Bluetooth. For this to work weather information gathered on the weather stations must be encoded in a standardized format, transferred to me over a network for me to decode and apply said process to. I'm thusly required to persuade the author to add an alternative input mechanism to the app, hack my Bluetooth stack and create a virtual Bluetooth device or rewrite the app. - Does the OS need to know how to fetch this information? Yes, the purpose of an OS is to abstract and multiplex hardware. Does a web app need to know how to fetch this information? - Is a browser plugin really a better idea? Which browser/version? Then how is the page going to fetch that? How secure is that? Can't another page do it? This reminds me the use of embed which I personally hate. I agree that a browser plugin would the wrong approach, but I argue that a web page would be as well. I can't imagine a scenario where I'm developing software support for a Bluetooth weather station and I figure: Heck, I should put a web browser between the Bluetooth stack and the weather station abstraction. Again, the app should not (but maybe could) listen for bluetooth-specific devices. If you develop web apps you wouldn't say that, it would be more like: Heck, I have a wonderfull web app and now I have to do some kind of abstraction on several diferent OS (win,unix,..) so I can in some way export the bluetooth information to the browser. I hope this kind of example enlights some people to forget about storage, cameras, keyboards and all the stuff you can get in any general technology store. Where do you draw the line? What's inherently different about hardware you can find in general technology stores? General technology stores: cameras, lcds, mouses, keyboards, microphones. We're not talking about this kind of devices. Why should there even be so low-level webapps that they interface with hardware? HTML forms don't care if their input comes from a pipe. No web technology should. I think I already made my point.
Re: [whatwg] Bluetooth devices
Let's think about an example, perhaps a bluetooth weather station. For the OS it's just another bluetooth device. What if a web app could have permission (granted by the user/browser) to scan for bluetooth devices and fetch weather information, save it on the weather history and process it in some way. - Does the OS need to know how to fetch this information? - Is a browser plugin really a better idea? Which browser/version? Then how is the page going to fetch that? How secure is that? Can't another page do it? This reminds me the use of embed which I personally hate. I hope this kind of example enlights some people to forget about storage, cameras, keyboards and all the stuff you can get in any general technology store. -- Diogo On Fri, 2010-12-17 at 01:02 +0100, Roger Hågensen wrote: Something that specific would be better implemented as a browser plugin that wrap OS API or a OS driver's API functionality, if it becomes popular then one or more browser developers would probably be interested in supporting it without the need for a browser plugin/wrapper, at which point one just need to follow the guidelines that Ian posts here quite frequently to get it standardized.
Re: [whatwg] Bluetooth devices
Bjartur, I think you misunderstood our point. The idea is to have a way of accessing this kind of devices (not necessarily by bt or usb). The difference of this kind of devices is they're not keyboard, mics, headphones or cameras. Sent from my iPhone On 12 de Dez de 2010, at 13:05, Bjartur Thorlacius svartma...@gmail.com wrote: On 12/12/10, Anne van Kesteren ann...@opera.com wrote: On Sat, 11 Dec 2010 22:53:47 +0100, Bjartur Thorlacius svartma...@gmail.com wrote: On 12/2/10, Diogo Resende drese...@thinkdigital.pt wrote: For example, a medical device may have no interest to the OS but a web app (just like a desktop app) could get some interesting information and perhaps send some instructions. Maybe some API like the geolocation.. Wrong layering. HTML is for providing information, not deciding what to do with it. Provide data, information, let UA gather and user use. What do you mean with this? A medical device provides data. What does Bluetooth have to do with anything? If the computer can reach the medical device and the medical device can supply data this data might be fed to the app. The app has no idea whatsoever whether this data is coming from a physical health-o-meter, whether someone is comparing old and new results or whether someone curious just wanted to input theoretical measures. I don't think Don was talking about mouse/kb/video/gps stuff. That should be handled by the OS and reflected to the current APIs as wired alternatives do. I think Don meant to be able to scan other types of devices and be able to interact with them. What makes other devices so different that they need special exposition? They are far more common. We always try to optimize the common case. I fail to grasp what giving direct access to networked devices achieves. If you've got an application that takes a video stream at runtime, request a video stream. If that video stream happens to be linked to /dev/cam0, /usr/vid/funny/watchme, /n/screen or /n/fifo/record is unimportant to the application. Read in the video, do your thing. Let the user feed you video. This can and should apply to _all_ media types. If you've written a contact management application, you don't want to spend time implementing Bluetooth stuff so you can import contacts from some wireless handheld storage devices, just for the next app writer to do the same. If Bluetooth becomes obsolete, everything should work the same. Whether you use SCSI, USB, FireWire, Light Peak or Bluetooth to get data doesn't matter. You're still working with data. I want my contact manager to manage my contacts, not my PAN.
Re: [whatwg] Bluetooth devices
On Fri, 2010-12-03 at 09:13 -0800, David Singer wrote: But there is still a whole OS, and a piece of hardware (the bluetooth chip) between the browser and the bluetooth device. If the OS considers the device 'visible' or 'connected' then it's available to the browser. It doesn't matter what the means of connection is. Agree. Right now, it might be available to the browser, not the developer. There's no way to reach such devices. If you're suggesting that we should have ways of browsing what devices/services you *might* connect to (the equivalent of the panels that OSes offer to set up pairing), on Bluetooth (or, I guess, the network), that raises a whole host of questions and issues. I described the whole process but the search/pairing could still be done by the OS. So I still think, if the OS thinks you can talk to it (it's paired or connected), the fact that Bluetooth is the 'wire' is irrelevant. If the OS does *not* think it's connected, then you're talking about establishing connectivity through some kind of browser/web-mediated interaction. The OS might find it and pair with it. The idea is that the OS might not know what kind of device it is but a web app might and should be able to talk in some way. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Bluetooth devices
I don't think Don was talking about mouse/kb/video/gps stuff. That should be handled by the OS and reflected to the current APIs as wired alternatives do. I think Don meant to be able to scan other types of devices and be able to interact with them. For example, a medical device may have no interest to the OS but a web app (just like a desktop app) could get some interesting information and perhaps send some instructions. Maybe some API like the geolocation.. -- Diogo On Tue, 2010-11-30 at 16:14 -0800, David Singer wrote: I would repeat, that I think the form of the (logical) wire between the browser and the device is out of scope, and that (effectively) we *do* provide access to bluetooth devices. Heck, my bluetooth keyboard and mouse work today. Connect the devices however you like, we don't care.
Re: [whatwg] Bluetooth
What about having the possibility to use a device other than a video? Maybe a specific hardware. I agree about not having a distinction on the hardware stack being used, but there should be a way for an app to be able to access an USBx/BT/FW device. -- Diogo On Wed, 2010-12-01 at 22:16 +1100, Silvia Pfeiffer wrote: On Wed, Dec 1, 2010 at 9:52 PM, Anne van Kesteren ann...@opera.com wrote: On Wed, 01 Dec 2010 06:37:09 +0100, Saurabh Jain saur...@skjworld.com wrote: We need access to Bluetooth devices using the Device element. Without Bluetooth access some of the use cases, specially in the mobile device domain would not be achievable. I think the question is why does it matter they are connected via Bluetooth? Should we really have a USB/Bluetooh/Firewire/etc. distinction at the web platform level? That seems like a bad thing. I agree. The Web developer should not have to worry about how the user connects the device to their system. They should just be able to say: give me the video (or audio or whatever) data from an appropriate device. The type of data matters much more than the way in which it is connected. Silvia.
Re: [whatwg] Bluetooth
This is exactly my point (and probably Don). I was not thinking about common i/o devices. I was thinking about a way to somehow connect to an uncommon device. Maybe something like websockets, maybe devsockets :P I can see 3 important steps to do this: - have a way expose diferent devices (so the app can search/list) - have permission to access a specific device (yes/no/remember) (the browser should do the bluetooth pairing stuff) - talk to the device with some kind of stream/socket Does anyone think this could be a good idea? -- Diogo On Thu, 2010-12-02 at 15:10 +0100, Anne van Kesteren wrote: On Thu, 02 Dec 2010 15:05:06 +0100, Diogo Resende drese...@thinkdigital.pt wrote: What about having the possibility to use a device other than a video? Maybe a specific hardware. I agree about not having a distinction on the hardware stack being used, but there should be a way for an app to be able to access an USBx/BT/FW device. Ideally we can have some abstract layer -- so type of hardware does not need to be exposed -- that JavaScript can script against. Not sure how feasible that is though. It would be quite cool if all kinds of devices such as game controllers, medical devices, etc. can be connected in a browser-agnostic way (i.e. no extensions) and the page could provide the implementation. Seems somewhat far away though. :-)
Re: [whatwg] Bluetooth
I forgot to mention that maybe only one bluetooth stack is relevant here, the RFCOMM (serial). I think this makes the API more simple and consistent (as USB and firewire are also serial). -- Diogo On Thu, 2010-12-02 at 15:56 +0100, Anne van Kesteren wrote: On Thu, 02 Dec 2010 15:50:07 +0100, Diogo Resende drese...@thinkdigital.pt wrote: This is exactly my point (and probably Don). I was not thinking about common i/o devices. I was thinking about a way to somehow connect to an uncommon device. Maybe something like websockets, maybe devsockets :P Heh. I can see 3 important steps to do this: - have a way expose diferent devices (so the app can search/list) - have permission to access a specific device (yes/no/remember) (the browser should do the bluetooth pairing stuff) These two should be done via device I think. Giving blatant access to external devices from web pages would be quite the security risk. - talk to the device with some kind of stream/socket Does anyone think this could be a good idea? I certainly think it's cool. :-)
[whatwg] link onLoad event
Hi, Is there a way to know that a link has been loaded (and processed)? I'm more interested in CSS links than others but the process should be the same. In my opinion it's a better way of loading stylesheets than downloading using XmlHttpRequest and then creating the style with all that inside (seems style does not support onLoad either..). This is important for developers to create elements knowing they will have the correct styling immediately and not some moments after. I'm sorry if there's already something to do this. Please hint me if so. -- Diogo
Re: [whatwg] link onLoad event
I see already information on the latest draft about a load and error event, I think this is it. I was hoping some browser vendors would implement it sooner :) -- Diogo On Wed, 2010-10-27 at 11:18 -0200, Davis Peixoto wrote: Interesting question indeed On Wed, Oct 27, 2010 at 11:15 AM, Diogo Resende drese...@thinkdigital.pt wrote: Hi, Is there a way to know that a link has been loaded (and processed)? I'm more interested in CSS links than others but the process should be the same. In my opinion it's a better way of loading stylesheets than downloading using XmlHttpRequest and then creating the style with all that inside (seems style does not support onLoad either..). This is important for developers to create elements knowing they will have the correct styling immediately and not some moments after. I'm sorry if there's already something to do this. Please hint me if so. -- Diogo -- Um abraço, Perdigão.
Re: [whatwg] rendering WebSRT cue parts in use for subtitling songs
Maybe the browser could simulate :hover (or :focus) for those words so
it would be easy to style it.
--
Diogo
On Sun, 2010-10-17 at 10:18 +1100, Silvia Pfeiffer wrote:
I've just looked into using WebSRT for subtitling songs where I'm also
using it to provide more detailed timing on the individual words
within the cue. This can obviously used for Karaoke-style display, but
is also very educational for learning the lyrics to a song or even for
a deaf person to follow along and get a feeling for the rhythm of a
piece of music.
I've come up with the following example markup, which I believe is
correct according to the spec.
1
00:00:10,000 -- 00:00:12,210
00:00:10,035Chocolate 00:00:11,000Rain
2
00:00:12,210 -- 00:00:15,910
00:00:13,250Some 00:00:13,500stay 00:00:13,750dry
00:00:14,25and 00:00:14,50others 00:00:15,00feel
00:00:15,25the 00:00:15,50pain
3
00:00:15,910 -- 00:00:15,920
00:00:16,000Chocolate 00:00:16,500Rain
00:00:13,250Some 00:00:13,500stay 00:00:13,750dry
00:00:14,25and 00:00:14,50others 00:00:15,00feel
00:00:15,25the 00:00:15,50pain
4
00:00:15,920 -- 00:00:18,000
00:00:16,000Chocolate 00:00:16,500Rain
5
00:00:18,000 -- 00:00:21,170
00:00:18,250A 00:00:18,500baby 00:00:19,000born
00:00:19,250will 00:00:19,500die 00:00:19,750before
00:00:20,500the 00:00:20,750sin
6
00:00:21,180 -- 00:00:23,000
00:00:21,200Chocolate 00:00:21,500Rain
My question now is: how can I apply CSS to this and render the words.
I would expect a style of rendering where all words are first
displayed in ordinary display and e.g. painted in a different color as
the time reaches them. Something like:
::cue {
color: black;
}
// this is in-valid as per spec right now
::cue timestamp {
color: red;
}
But FAIK we don't currently have a means to address the
timestamp-activated parts within a cue through CSS. How should that be
done?
Cheers,
Silvia.
Re: [whatwg] SearchBox API
Hi,
Are you covering such a use case: user enters a website, goes to the
search box (of the browser, not the page), and it is able to search
based on suggestions given by the page?
I think this would be great and would be a good way to normalize the way
people search inside a given page/app.
--
Diogo
On Wed, 2010-10-13 at 15:59 -0700, Tony Gentilcore wrote:
Hi All,
We're adding instant search integration [1] to Google Chrome, allowing
the search provider to communicate suggestions to the user agent.
If there is interest, we'd like to make sure that we do this in such a
way that any search provider or user agent can implement it.
While the search boxes in most user agents support suggestions via an
HTTP API, instant requires a DOM API. We propose exposing a
window.navigator.searchBox object. There is some precedence for this
with window.navigator.registerProtocolHandler()/registerContentHandler()
[2].
Is this something that others are interested in? If so, any feedback
on our working API [3]?
-Tony
[1]
http://googlesystem.blogspot.com/2010/09/instant-search-in-google-chrome.html
[2] http://dev.w3.org/html5/spec/Overview.html#navigator
[3]
interface SearchBox {
// Search query and cursor position.
readonly attribute DOMString value;
readonly attribute unsigned long selectionStart;
readonly attribute unsigned long selectionEnd;
// Dimensions of the portion of the search box (e.g. a dropdown)
// that overlaps the window.
readonly attribute unsigned long x;
readonly attribute unsigned long y;
readonly attribute unsigned long width;
readonly attribute unsigned long height;
// Set ordered suggestions. Valid for current this.value.
void setSuggestions(in DOMStringArray suggestions);
// Notification that the user has changed the input value.
attribute Function onchange;
// Notification that the user has committed input (e.g. pressed enter).
attribute Function onsubmit;
// Notification that the user has selected a suggestion (e.g. down
arrow to suggestion).
attribute Function onselect;
// Notification that the user has cancelled input (e.g. closed dropdown).
attribute Function oncancel;
// Notification that the dimensions of the overlapping region have changed.
attribute Function onresize;
}
[Supplemental]
interface NavigatorAbilities {
// Raises permission denied if page isn't default search provider.
readonly attribute SearchBox searchBox;
}
// Example usage.
var searchBox = window.navigator.searchBox;
searchBox.onchange = function() {
if (this.selectionStart == this.selectionEnd
this.selectionStart == this.value.length)
alert('Cursor is at end of input');
alert('Setting suggestions for: ' + this.value);
this.setSuggestions([one, two]);
}
searchBox.onsubmit = function() {
alert('User searched for: ' + this.value);
}
searchBox.onselect = function() {
alert('User selected suggestion: ' + this.value);
}
searchBox.oncancel = function() {
alert('Query when user cancelled: ' + this.value);
}
searchBox.onresize = function() {
alert('Resized to: ' +
[this.x,
this.y,
this.width,
this.height].join(','));
}
Re: [whatwg] input type=location proposals
On Mon, 2010-08-09 at 23:45 +, Ian Hickson wrote: On Fri, 18 Jun 2010, Eitan Adler wrote: Two separate use cases 1) For entry of locations into something like Google Maps or MapQuest. In this case the form should look as it does now (a text box) but browsers would be able to assist you in entering locations like it can for for emails. 2) For entry of Lat/Long coordinates which can be entered either manually or with some kind of map like interface. These are two separate proposals and I both could co-exist one as type=location and the other as type=gps Could you give some examples of sites that would use this, and examples of how they're working around the lack of this feature currently? Any CRM with clients/suppliers/partners/people might want to define a GPS location for a building/office/destination. Currently they usually use a text input. On Sun, 20 Jun 2010, Eitan Adler wrote: For type=gps I was thinking something like the following: 1) type=gps results in a (double?) text box which takes a latitude and a longitude 2a) there is some css option that tells the text box to act like a map instead. 2b) If the css option is on there is also some method of requesting a map source this source could be any existing map provider Then again now that I think about it some more I don't see this working out too well. Does this solve a problem that two type=number controls wouldn't solve? type=url and type=email are here for what? We could all use type=text for everything. On Fri, 25 Jun 2010, Ashley Sheridan wrote: I think it's quite a fringe case. What about things that are more used: * type=number - a browser could aid input with some sort of spinner * type=price - a browser could use the locale to select a monetary format, or at least display the amount in the locale format specified by the document itself These are just a couple that I think would potentially be more useful than type=location, as I see their use quite a lot. The price one is probably more reserved to CMS's and auction sites, but these are fairly common enough in use I feel. Number could be used for a whole plethora of cases, such as a quantity amount in a shopping cart, an age field in a form, or anything else where you might need a number that wouldn't necessarily be sensible to use a type=range for. Well we have type=number. I don't know that type=price would be _that_ useful; mostly prices are output, not input. An invoice app would want price input for products or for specific invoice adjustments.
Re: [whatwg] input type=location proposals
On Tue, 2010-08-10 at 10:00 -0700, Tab Atkins Jr. wrote: On Tue, Aug 10, 2010 at 2:53 AM, Diogo Resende drese...@thinkdigital.pt wrote: On Sun, 20 Jun 2010, Eitan Adler wrote: For type=gps I was thinking something like the following: 1) type=gps results in a (double?) text box which takes a latitude and a longitude 2a) there is some css option that tells the text box to act like a map instead. 2b) If the css option is on there is also some method of requesting a map source this source could be any existing map provider Then again now that I think about it some more I don't see this working out too well. Does this solve a problem that two type=number controls wouldn't solve? type=url and type=email are here for what? We could all use type=text for everything. Those both offer validation, and in devices that can expose specialty keyboards (such as phones), they can offer a slightly different keyboard for entering data into those (one that makes :, /, and @ easier to type, for example). Thus these are both more powerful than type=text. Does a type=location offer any similar benefits over a pair of type=number inputs? Yes, of course. Instead of a numeric keyboard (I never saw one on my iphone), I could just point my current location, or select a location nearby using a map or so. Don't forget about other devices; phones are great but there are bigger screens, like tablets that don't require a special keyboard for input. I think a better validation and a way of context-aware to the browsers would be good. Well we have type=number. I don't know that type=price would be _that_ useful; mostly prices are output, not input. An invoice app would want price input for products or for specific invoice adjustments. Once again, though, what benefit can you gain from type=price over using type=number for this? I don't recall ever seeing an app that allowed you to enter a price in multiple currencies; I've only seen apps that have several price inputs, one for each currency (this can't be replaced by an input type=price, as it means something quite different), and currency converters, which need more information than the browser can provide to be useful in the first place. ~TJ I was just giving an input example. I agree with you on this one, I would be just a matter of localization (currency symbol, number of decimal digits, ..).
Re: [whatwg] Article: Growing pains afflict HTML5 standardization
I hate it. From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Schalk Neethling Sent: sábado, 10 de Julho de 2010 18:54 To: wha...@whatwg.org Subject: [whatwg] Article: Growing pains afflict HTML5 standardization Hi all, Would love to hear everyones comments on the following article: http://goo.gl/VNg0
Re: [whatwg] Directory upload via input type=file directory
On Wed, 2010-04-07 at 11:28 +0100, Ashley Sheridan wrote: Double-click can only be performed by people using a mouse. What about people suffering RSI who might prefer to use a keyboard? Have you ever tried to navigate one of those file dialogues without using a mouse? I have, and it's a pain in the posterior. But, it does mean that there are further problems to allowing the existing dialogue to just handle directories as if they were files. I use it everyday. It's not a pain, you just need to know how to use ctrl/shift/alt+tab/arrows. But that's not the point. You just gave a reason not to use the dialog at all. Do you want to ignore the possibility of dragdrop too? When I don't have a mouse, I use lynx. I done software in the past for people with disabilities and is not easy. For those people I would not even consider a FileDialog as it is.
Re: [whatwg] Storage quota introspection and modification
Agree 100% (even with geolocation). On Wed, 2010-03-10 at 07:54 -0800, Ian Fette (イアンフェッティ) wrote: As I talk with more application developers (both within Google and at large), one thing that consistently gets pointed out to me as a problem is the notion of the opaqueness of storage quotas in all of the new storage mechanisms (Local Storage, Web SQL Database, Web Indexed Database, the Filesystem API being worked on in DAP, etc). First, without being able to know how large your quota currently is and how much headroom you are using, it is very difficult to plan in an efficient manner. For instance, if you are trying to sync email, I think it is reasonable to ask how much space do I have, as opposed to just getting halfway through an update and finding out that you hit your quota, rolling back the transaction, trying again with a smaller subset, realizing you still hit your quota, etc. I would like to see a method added, for any storage mechanism, something like GetCurrentQuota() and GetCurrentQuotaUsed(). (I specifically don't care what they're called or the details, e.g. whether they need to be callbacks, I just want to see us address this use case.) Secondly, I think we need a better answer for obtaining a larger quota. Let's think for a moment about the use cases -- in most instances, I am going to make a decision that I want to use an application offline. (I personally would not expect to browse to a site and then just happen to be able to use it offline, nor do I expect users to have that expectation or experience. Rather, I expect going through some sort of flow like clicking something that says Yes, I want to use Application X offline. At this point, I want to get any permissioning issues out of the way. I don't want to wait until the data sync to the Web XXX Database starts failing 10 minutes later to pop up an infobar that is no longer in the user's current flow / state of mind, I don't want to then pop up another infobar 30 minutes later saying their Filesystem quota is full, etc. I want to be able to get this out of the way all at once, at a point in time where I believe the user is actually in the mindset / task of deciding that they want to use my web application. I specifically do not want to have to deal with 4 different infobars, potentially at 4 different points in time, to use an application I have decided I want to use. To that point, I would like to see a method added (presumably that can only be called in response to a user action) that would allow my page to request a bundle of permissions. I am going to go out on a limb here and include geolocation in this bundle. Some sort of a callback type API where I pass in a list of permissions that I want, the UA is free to display this to the user in whatever mechanism it determines appropriate (if at all -- e.g. if the user has already denied geolocation and that's being requested again, as a UA i might decide not to present that request). That is, I could pass in something like [LocalStorageQuota, 20*1024*1024 /* 20M */, WebSQLQuota, 1*1024*1024*1024 /* 1GB */, FileSystemQuota, 10*1024*1024*1024 /* 10GB */, Geolocation, true], and the callback could then (as a convenience) indicate the current quota for all of the things that I asked for, so that I could figure out whether the user accepted, denied, or accepted and modified the request and how I can then proceed (or not proceed). Again, I don't care terribly about the details of how the API looks, the above is just meant for illustration. -Ian
Re: [whatwg] HTML Cookie API
What about something like:
document.pushCookies(function () {
// cookies have been pushed to the js process
var x = document.getCookie(x);
// whatever...
});
This seems similar to Adam's proposed document.getAllCookies.
-Darin
No. pushCookies would be a way of pushing cookies to the current js and
then you could call getCookie several times without defining a callback.
It would be almost like:
document.observe(cookieload, myAppLoad)
Re: [whatwg] HTML Cookie API
No. pushCookies would be a way of pushing cookies to the current js and then you could call getCookie several times without defining a callback. It would be almost like: document.observe(cookieload, myAppLoad) Right. My point was that you could implement pushCookies on top of Adam's API. -Darin Agree. Just like you could implement Adam's API on top of current browsers cookies spec :P
Re: [whatwg] HTML Cookie API
On Wed, 2010-02-24 at 11:21 -0800, Darin Fisher wrote:
For reference, reading document.cookie has measurable performance cost
in Chromium since the cookie jar lives in a process separate from the
process running JavaScript. We could have minimized this cost by
caching the cookies locally, but then there are cache coherency
issues.
I think the cookie APIs should have been asynchronous from the start.
Whenever an API is backed by I/O, asynchronous should be the rule.
-Darin
What about something like:
document.pushCookies(function () {
// cookies have been pushed to the js process
var x = document.getCookie(x);
// whatever...
});
Re: [whatwg] Multiple file download
What about 10K files to download? I don't like this idea. One could create a multiple file download page that could flood the client host. I would like to see the list of files I'm going to download before choosing save destination. For multiple download, I would prefer a dragdrop usability (just like for uploading). -- Diogo Resende drese...@thinkdigital.pt ThinkDigital On Tue, 2010-02-23 at 18:12 +, Jose Fandos wrote: On Tue, Feb 23, 2010 at 5:07 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/23/10 5:10 AM, Jose Fandos wrote: What doesn't seem to be there, unless a java applet is used (haven't come across one using flash) is the multiple file download. Even Google Docs uses a zip file to download multiple files. What do you mean in terms of multiple file download? Download 10 files as 10 separate files, without having to a) Okay the saving of each file to your drive independently b) Downloading them as a zip file that then needs to be uncompressed by the end user Imagine a list of files showing on a website (like google docs, or like you would have in a default ftp listing in firefox). Scripting would allow a selection of a number of these files and a download button would open a dialog on the UA to select the folder where the files will be copied to. You can do this right now in two ways: 1) An archive file (your zip example) with the files in it. This is b) which we have, agreed, but not what I meant by allowing multiple file download. It's allowing the download of just one file, the zip file. 2) A multipart response with the files as parts, each part having Content-Disposition: attachment. as far as I know, and I could be wrong, this would suffer from what I described in a), i.e. there would be a dialog propping up to accept each downloaded file. You can gzip this multipart response to get the compression behavior you want. I was suggesting the resource packages as a way to make use of compression/decompression. /J -Boris -- Jose Fandos CEO Andekan LLC 5727 Claremont Avenue Oakland, CA 94618 Phone: 415.366.7755 Fax: 415.373.3858 UK: +44 797 198 7757 www.andekan.com smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Web API for speech recognition and synthesis
I agree 100%. Still, I think the access to the mic and the speech recognition could be separated. -- Diogo Resende drese...@thinkdigital.pt ThinkDigital On Thu, 2009-12-03 at 12:06 +, Bjorn Bringert wrote: On Wed, Dec 2, 2009 at 10:20 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Dec 2, 2009 at 11:17 AM, Bjorn Bringert bring...@google.com wrote: I agree that being able to capture and upload audio to a server would be useful for a lot of applications, and it could be used to do speech recognition. However, for a web app developer who just wants to develop an application that uses speech input and/or output, it doesn't seem very convenient, since it requires server-side infrastructure that is very costly to develop and run. A speech-specific API in the browser gives browser implementors the option to use on-device speech services provided by the OS, or server-side speech synthesis/recognition. Again, it would help a lot of you could provide use cases and requirements. This helps both with designing an API, as well as evaluating if the use cases are common enough that a dedicated API is the best solution. / Jonas I'm mostly thinking about speech web apps for mobile devices. I think that's where speech makes most sense as an input and output method, because of the poor keyboards, small screens, and frequent hands/eyes busy situations (e.g. while driving). Accessibility is the other big reason for using speech. Some ideas for use cases: - Search by speaking a query - Speech-to-speech translation - Voice Dialing (could open a tel: URI to actually make the call) - Dialog systems (e.g. the canonical pizza ordering system) - Lightweight JavaScript browser extensions (e.g. Greasemonkey / Chrome extensions) for using speech with any web site, e.g, for accessibility. Requirements: - Web app developer side: - Allows both speech recognition and synthesis. - Easy to use API. Makes simple things easy and advanced things possible. - Doesn't require web app developer to develop / run his own speech recognition / synthesis servers. - (Natural) language-neutral API. - Allows developer-defined application specific grammars / language models. - Allows multilingual applications. - Allows easy localization of speech apps. - Implementor side: - Easy enough to implement that it can get wide adoption in browsers. - Allows implementor to use either client-side or server-side recognition and synthesis. signature.asc Description: This is a digitally signed message part
Re: [whatwg] Web API for speech recognition and synthesis
I was not thinking of raw access to the mic. I was just thinking of a 2 step method to do it so you could just do 1 step :) I was thinking of something like: 1. Call Sound API and ask to record (maybe something like the geolocation on Firefox [1]). 2. Pass it to text2speech or save or stream or whatever.. This way one could record audio and do something else like save/stream. If other want to translate into text, just do the next step. [1]: http://www.mozilla.com/en-US/firefox/geolocation/ -- Diogo Resende drese...@thinkdigital.pt ThinkDigital On Thu, 2009-12-03 at 12:30 -0500, Fergus Henderson wrote: On Thu, Dec 3, 2009 at 7:32 AM, Diogo Resende drese...@thinkdigital.pt wrote: I agree 100%. Still, I think the access to the mic and the speech recognition could be separated. While it would be possible to separate access to the microphone and speech recognition, combining them allows the API to abstract away details of the implementation that would otherwise have to be exposed, in particular the audio encoding(s) used, and whether the audio is streamed to the recognizer or sent in a single chunk. If we don't provide general access to the microphone, the speech recognition API can be simpler, implementors will have more flexibility, and implementations can be simpler and smaller because they won't have to deal with conversions between different audio encodings. So I'm in favour of not separating out access to the microphone, at least in v1 of the API. -- Fergus Henderson fer...@google.com signature.asc Description: This is a digitally signed message part
Re: [whatwg] Web API for speech recognition and synthesis
I missunderstood too. It would be great to have the ability to access the microphone and record+upload or stream sound to the web server. -- D. On Wed, 2009-12-02 at 10:04 -0800, Jonas Sicking wrote: On Wed, Dec 2, 2009 at 9:17 AM, Bjorn Bringert bring...@google.com wrote: I think that it would be best to extend the browser with a JavaScript speech API intended for use by web apps. That is, only web apps that use the speech API would have speech support. But it should be possible to use such an API to write browser extensions (using Greasemonkey, Chrome extensions etc) that allow speech control of the browser and speech synthesis of web page contents. Doing it the other way around seems like it would reduce the flexibility for web app developers. Hmm.. I guess I misunderstood your original proposal. Do you want the browser to expose an API that converts speech to text? Or do you want the browser to expose access to the microphone so that you can do speech to text convertion in javascript? If the former, could you describe your use cases in more detail? / Jonas signature.asc Description: This is a digitally signed message part
Re: [whatwg] Web API for speech recognition and synthesis
If you're able to read from the mic, you don't need to upload. You could save it locally (for example for voice memos). The read+upload was just 2 steps I sugested instead of direct streaming. Speech recognition could be done separatly. One could use the mic to capture a voice note. Other could use the speech recognition without the mic (saved file?). Divide and conquer :) -- Diogo Resende drese...@thinkdigital.pt ThinkDigital On Wed, 2009-12-02 at 19:17 +, Bjorn Bringert wrote: I agree that being able to capture and upload audio to a server would be useful for a lot of applications, and it could be used to do speech recognition. However, for a web app developer who just wants to develop an application that uses speech input and/or output, it doesn't seem very convenient, since it requires server-side infrastructure that is very costly to develop and run. A speech-specific API in the browser gives browser implementors the option to use on-device speech services provided by the OS, or server-side speech synthesis/recognition. /Bjorn On Wed, Dec 2, 2009 at 6:23 PM, Diogo Resende drese...@thinkdigital.pt wrote: I missunderstood too. It would be great to have the ability to access the microphone and record+upload or stream sound to the web server. -- D. On Wed, 2009-12-02 at 10:04 -0800, Jonas Sicking wrote: On Wed, Dec 2, 2009 at 9:17 AM, Bjorn Bringert bring...@google.com wrote: I think that it would be best to extend the browser with a JavaScript speech API intended for use by web apps. That is, only web apps that use the speech API would have speech support. But it should be possible to use such an API to write browser extensions (using Greasemonkey, Chrome extensions etc) that allow speech control of the browser and speech synthesis of web page contents. Doing it the other way around seems like it would reduce the flexibility for web app developers. Hmm.. I guess I misunderstood your original proposal. Do you want the browser to expose an API that converts speech to text? Or do you want the browser to expose access to the microphone so that you can do speech to text convertion in javascript? If the former, could you describe your use cases in more detail? / Jonas signature.asc Description: This is a digitally signed message part
