Re: [whatwg] Form submission progress display by UA (incl. file upload)
On Jan 25, 2008 2:48 PM, Mikko Rantalainen [EMAIL PROTECTED] wrote:
It's wise to always trying to minimize the battery usage in a battery
operated device. However, if the device is already using wireless or
wired communication for transmitting the data set it cannot just do
nothing.
from my unfortunate experience in this area, timers cost extra. (even
above wifi cost.)
Notice, also, that I wasn't suggesting that the above text is
a MUST but instead just SHOULD. Perhaps it could be even recommended.
that's better :)
How can the file picker posting system know something like actual
bandwidth beforehand? Perhaps the user is using a mobile device that is
currently on WLAN connection (say 54mbps) and the user starts sending
the file. If the file picker has told the user that sending takes
approximately 5 minutes for the selected file, how is the user supposed
to know the actual sending time after he starts moving and the
connection drops to 3G mobile network (around 0.5mbps) or GPRS or GSM
data mobile network (around 0.001mbps).
i think we're supposed to send offline notifications, i'd assume that
network changes would trigger that.
whether they do or don't, your ip address will change (unless you have
a really magical vpn), and as such your connection will fail. without
some magical resume features (perhaps as i described below), you'll
have to start over. so no problem here.
I cannot imagine anything but a
progress bar displaying the current rate (or transfer rate for the
previous 30 seconds if that's how often the progress can be updated
because the battery must be conserved).
http://mxr.mozilla.org/seamonkey/source/content/base/public/nsIDOMFile.idl
lists a fileSize property. I think it'd be nice if gmail could tell me
that this file will take an hour to upload. I also wonder if it'd be
a good idea to support getting chunks of a file, because if I had a
4gb file, using DOMFile().getAsBinary() would probably crash my
browser. I'd kinda like for gmail to be able to do partial uploads
In order for this to work, there should be DOMString hash() which has
an optional argument for a hash algorithm (md5sum, a const for
md5sum, or maybe an object { processBlock:function(data) {},
getHash:function() }. Otherwise a user could try feeding sequential
blocks from different files.
I agree that something like that would be nice to have for some cases.
However, I do not think that such behavior would make upload progress
monitoring unneeded.
The current fix for this problem is to connect
the receiving server with HttpXmlRequest() and ask the server how much
data the server has received. Then this result can be displayed somehow
to the user.
implementation demos are probably a good thing before discussing a standard :)
I don't think that IE has a working upload progress meter. I have always
experienced IE just to simply slowly increase the progress meter until
the page is done; it's advancing even if I disconnect the network cable
during the progress... (just tried IE6 and IE7)
interesting (clever even)
If it will probably be added in the future anyway shouldn't the spec
recommend doing so sooner?
spec after implementation experience, not before. preferably including
experience with mobile devices.
I'm not saying that every UA MUST do so but
they should (unless they have a good reason not to).
[whatwg] Some video questions
Hello, Apologies in advance if I've missed these details in the specification. The video element supports width and height. Does this include the additional area needed (if necessary) by the controls? It strikes me that it shouldn't, since it would be odd for the video width and height to change when non-video decorators are shown/hidden. I don't see a standard controls height and width, which is fine, but will there be read-only attributes for the width, height and position for controls? -- Charles
Re: [whatwg] accesskey
Michael(tm) Smith wrote: Jerason Banes [EMAIL PROTECTED], 2008-01-25 23:41 -0600: Long story short, accesskeys were an idea that worked better on paper than they did in practice. They inevitably interfered with normal browser operation as well as other accessibility features in such a way as to * reduce* the accessibility of many web pages. Another long story short: accesskey mark is already in use in a significant amount of existing content, so leaving it unspec'ed for implementors does not seem like a practical option -- not if we care about trying to ensure that behavior of that content is consistent/ interoperable across UAs. But that's precisely the problem: accesskey= *can't* be consistent and interoperable across UAs, or even across browsers, because browsers compete (amongst other things) on their user interfaces, and therefore they have different user interfaces, and therefore they conflict with different values of accesskey=. If that problem had a good solution, removing the attribute would not have been necessary. The specification could include an explicit statement of the form UAs must ignore the accesskey= attribute, but any such statement would be in the yet-to-be-written Rendering section. ... Most handsets don't have keyboards or real pointing devices that let you quickly point and click on links; instead they just have numeric keypads and 5-way directional pads that are basically the equivalent of arrow keys plus an enter key/mouse button. In the context of delivering content to those devices, it's useful to provide numbered access keys for quick access to certain links on a page -- to save users the time and trouble of needing to use the 5-way on the handset to scroll to the links and activate them. ... Since most pages that contain links don't also use accesskey=, handset vendors should find a way to allow easy navigation of links regardless of whether the attribute is present. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Some video questions
Hi Charles, It was my understanding that video controls should be able to be added through style sheet mechanisms. Thus, there is no pre-set specification, but it is rather left to the web page designer. The javascript API will allow to hook up the controls with the video player. The controls could be overlayed over the video or added to any side of it or left out completely - just as the web page designer desires. Thus, they are outside the specification of the standard, IIUC. Regards, Silvia. On Jan 28, 2008 9:06 AM, Charles [EMAIL PROTECTED] wrote: Hello, Apologies in advance if I've missed these details in the specification. The video element supports width and height. Does this include the additional area needed (if necessary) by the controls? It strikes me that it shouldn't, since it would be odd for the video width and height to change when non-video decorators are shown/hidden. I don't see a standard controls height and width, which is fine, but will there be read-only attributes for the width, height and position for controls? -- Charles
Re: [whatwg] accesskey
On Mon, 28 Jan 2008 10:02:26 +1100, Matthew Paul Thomas [EMAIL PROTECTED] wrote: Michael(tm) Smith wrote: Jerason Banes [EMAIL PROTECTED], 2008-01-25 23:41 -0600: ... Another long story short: accesskey mark is already in use in a significant amount of existing content, so leaving it unspec'ed for implementors does not seem like a practical option -- not if we care about trying to ensure that behavior of that content is consistent/ interoperable across UAs. But that's precisely the problem: accesskey= *can't* be consistent and interoperable across UAs, or even across browsers, because browsers compete (amongst other things) on their user interfaces, and therefore they have different user interfaces, and therefore they conflict with different values of accesskey=. If that problem had a good solution, removing the attribute would not have been necessary. The problem does indeed have a god solution, which is to remove the stupid suggestion about the activation behaviour (alt/cmd/etc) in the spec. iCab, Opera, Amaya and Firefox have already implemented something intelligent that lets you avoid conflicts. The specification could include an explicit statement of the form UAs must ignore the accesskey= attribute, but any such statement would be in the yet-to-be-written Rendering section. And an unimaginatve and unintelligent approach anyway. ... Most handsets don't have keyboards or real pointing devices that let you quickly point and click on links; instead they just have numeric keypads and 5-way directional pads that are basically the equivalent of arrow keys plus an enter key/mouse button. In the context of delivering content to those devices, it's useful to provide numbered access keys for quick access to certain links on a page -- to save users the time and trouble of needing to use the 5-way on the handset to scroll to the links and activate them. ... Since most pages that contain links don't also use accesskey=, handset vendors should find a way to allow easy navigation of links regardless of whether the attribute is present. They do. However, accesskey, which is to primarily designed to give an increased navigation priority to certain links, is very useful for handsets, and not actually very complicated to implement, in a way that is consistent with the existing markup. It might not be the same across all implementations, but there is very little restriction needed to make an implementation compatible with almost any imaginable UI. And all of this has been proposed before, implemented by people in various ways in javascript or via proxy-based scripting as well as in user agents, and is hardly rocket science. http://lists.w3.org/Archives/Public/public-html/2007Jul/0213.html gives you a set of implementation techniques, links to a set of minimal changes required to the spec, etc. (There is more that could be done in an advanced implementation, but it isn't really complicated). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] Opera SVG Re: How to use SVG in HTML5?
Hi Vlad, as I read these, Opera is doing the right thing. Since the SVG you use doesn't have a viewBox attribte to say how the thing should fit, it creates an initial viewport where the size in px that the image element gets corresponds to a view in SVG user units. So a 300x100 img shows a portion of the SVG that goes from 0,0 (the top left) to 300,100 at the bottom right - in other words, only a part of the tiger. If you add a viewBox then the preserveAspectRatio attribute can be used, and has the default value of none, which squeezes the SVG to fit the space you give it. Without viewBox the preserveAspectRatio has no effect, since there is nothing that says how what size the contents of the SVG should be. So I don't think there is a bug at all. If you use something like inscape that doesn't add a viewBox, your SVG will do what your demos do. We can in fact change that in Opera for example by adding a default viewBox of some kind, but technically that is in violation of the current specs for SVG up to and including 1.2. I've cc'ed Erik, our SVG lead and the hair of the SVG WG, in case he wants to offer anything more, or correct anything I have misunderstood. cheers Chaals On Sat, 26 Jan 2008 00:10:08 +1100, Vlad Alexander (xhtml.com) [EMAIL PROTECTED] wrote: Hi Charles, Thanks for looking into this. Here you go: http://xhtml.com/misc/svg-img1.htm http://xhtml.com/misc/svg-img2.htm http://xhtml.com/misc/svg-img3.htm Regards, -Vlad http://xhtml.com Original Message From: Charles McCathieNevile Date: 2008-01-24 10:47 PM Hi Vlad, On Fri, 25 Jan 2008 00:50:45 +1100, Vlad Alexander (xhtml.com) [EMAIL PROTECTED] wrote: ... I tested Opera's support for SVG through the img element and it incorrectly clips the SVG image. The width and height attributes of the img element need to set the viewport for the SVG image and scale the SVG non-uniformly to fit the viewport. What was your test case? Can you share it so we can check whether this is a known problem or issue? cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
