[Oops! initially sent off list, sorry for the dupe David]
On Mon, Nov 17, 2008 at 3:03 AM, ddailey [EMAIL PROTECTED] wrote:
4. Concerning the first thing I need to fix, I am not sure if HTML5
currently provides a solution for. Here's the sitch: because of an extensive
use of CTRL sequences in
On Wed, 21 Feb 2007, Wolfram Kriesing wrote:
I was searching, but didnt find a hint-attribute for an input. The
more often we are using inline editing, the more the need for the
following is rising, imho:
input type=whatever hint=Enter your title here /
The text Enter your title here
Just to let everyone know that I posted the following to rest-discuss this
morning, any thoughts? :
I've read that HTML5 will be providing markup for the PUT and DELETE methods.
This is definitely good news - but I considered something else recently that,
from what I can gather, is not in the
On Fri, 11 Jul 2008, Mike Wilson wrote:
Blocking I/O on the main thread is ok if it's possible to specify a
timeout for the I/O operation, see:
http://www.openajax.org/runtime/wiki/Synchronous_XHR_Enhancements
and if the UA'a user interface is kept responsive (running animated
GIFs,
On 17/11/2008 11:29, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Does anyone else agree that an Accept attribute would be a useful tool for
making browser interaction more RESTful? Is it worth persuing this issue with
the HTML5 working group?
I don't see why the Accept header when following
Adrian,
The server is not obliged to respect the Accept header, there is nothing
preventing the server from returning a gif even if the Accept header indicates
solely png. This is actually the case with specifying content type in the URL,
since there is nothing preventing
Just to clarify - I was suggesting that the type-less URI and Accept header
method was a better solution, not the
example.com/report?type=application/rss+xml example I gave.
Also; including an optional header should be including an optional
attribute.
Sorry for any confusion!
Regards,
Mike
Hey Mike,
Good answers. :)
The server is not obliged to respect the Accept header, there is nothing
preventing the server from returning a gif even if the Accept header indicates
solely png. This is actually the case with specifying content type in the URL,
since there is nothing preventing
Thomas Broyer schrieb:
On Mon, Nov 17, 2008 at 3:03 AM, ddailey [EMAIL PROTECTED] wrote:
4. Concerning the first thing I need to fix, I am not sure if HTML5
currently provides a solution for. Here's the sitch: because of an extensive
use of CTRL sequences in the interface, the user will
[EMAIL PROTECTED] writes:
as an example:
a href=http://example.com/report;html report/a
a href=http://example.com/report; Accept=application/pdfpdf report/a
a href=http://example.com/report; Accept=application/rss+xmlxml
report/a
So I can send a colleague a message; 'you can get the
Pentasis writes:
2) When using small on different text-nodes throughout the document,
one would expect all these text-nodes to be semantically the same. But
they are not (unless all of them are copyright notices).
In printed material users are typically given no out-of-band information
about
Except that in practice on receiving a URL like the above, nearly all
users will try it in a web browser; they are unlikely to put it into
their PDF viewer, in the hope that a PDF version of the report will
happen to be available.
I've adressed this subsequently:
'here's the URL:
[EMAIL PROTECTED] writes:
It's also the most common case. Supposing I opened the above URL in a
browser, and it gave me the HTML version; how would I even know that
the PDF version exists?
Hypertext.
OK.
Except that in practice on receiving a URL like the above, nearly all
users will
2) When using small on different text-nodes throughout the document,
one would expect all these text-nodes to be semantically the same. But
they are not (unless all of them are copyright notices).
In printed material users are typically given no out-of-band information
about the semantics of
Pentasis writes:
In printed material users are typically given no out-of-band
information about the semantics of the typesetting. However,
smaller things are less noticeable, and it's generally accepted that
the author of the document wishes the reader to pay less attention
to them
On Mon, Nov 17, 2008 at 2:05 AM, Ian Hickson [EMAIL PROTECTED] wrote:
On Tue, 30 Sep 2008, Andy Lyttle wrote:
As I understand it, it was sort of an accident that Safari supports
placeholder on anything other than search fields, but there's no reason
it shouldn't apply to all text input
Would the sender of that link necessarily know all the formats the URL
provides? Anyway, that's an unrealistic amount of typing -- typically
round here people just copy and paste a URL into an instant message and
send it without any surrounding text.
Whereas without any other information, people
On Wed, Nov 12, 2008 at 12:14 AM, Ian Hickson [EMAIL PROTECTED] wrote:
On Tue, 11 Nov 2008, Samuel Santos wrote:
On Thu, 6 Nov 2008, Samuel Santos wrote:
If changing the button text can be a security issue (e.g. induce
the user to an action that he's not aware of), we can come up
[EMAIL PROTECTED] schrieb:
[...]
Please quote properly. Otherwise it's incredibly hard to follow
the discussion. Thanks.
Philipp Kempgen
Robert O'Callahan wrote:
On Mon, Nov 17, 2008 at 3:19 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Ian Hickson wrote:
Video and audio playback is already extremely CPU intensive,
we shouldn't require the UA to burn extra cycles doing
unnecessary work.
On Tue, Nov 18, 2008 at 8:48 AM, Jonas Sicking [EMAIL PROTECTED] wrote:
It seems like a pretty big waste of resources to have the following script
executing 50 times per second:
function timeupdatehandler(e) {
video = e.target;
completed = video.currentTime / video.duration;
thumb =
Hallvord R M Steen wrote:
as an example:
a href=http://example.com/report;html report/a
a href=http://example.com/report; Accept=application/pdfpdf report/a
a href=http://example.com/report; Accept=application/rss+xmlxml report/a
Sorry, both as an author and as a user I'd prefer this:
a
And the suggested hack is not even really usable: if you have a
video coming
from a NTSC DV source as 720x480 improperly transcoded to say MP4
720x480
square pixels, using the theoretical 10:11 pixel aspect ratio will
_not_ make
it look right: it needs to be clipped to 704x480 first.
Are
On Mon, Nov 17, 2008 at 1:58 PM, Pierre-Olivier Latour [EMAIL PROTECTED]wrote:
1) I don't remember any major media system I've dealt with so far having an
explicit pixel aspect ratio override API,
2) on the web, neither QT plug-in nor Flash have it,
3) in the case of this spec, the way it's
i would hope that repainting a progress bar that has not moved 50x/second
would not be a normal implementation too. 2x/second seems more realistic (a
300s video with a 600 pixel-wide playbar).
On Mon, Nov 17, 2008 at 1:23 PM, Robert O'Callahan [EMAIL PROTECTED]wrote:
On Tue, Nov 18, 2008 at
I should point out that the pixelratio attribute isn't only for authors,
it's also useful when the media framework used doesn't recognize the
(pixel) aspect ratio even when it's correctly set. From reading the
mplayer man page I see that AVI files can have aspect ratio set in the
OpenDML vprp
Jeremy Doig wrote:
i would hope that repainting a progress bar that has not moved
50x/second would not be a normal implementation too. 2x/second seems
more realistic (a 300s video with a 600 pixel-wide playbar).
Well, pages are most likely going to update the progress bar as often as
we fire
no - all I'm saying is that in 48 of the 50x/sec you get called, you can
trivially figure out that nothing needs to be done, so return quickly.
On Mon, Nov 17, 2008 at 3:05 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Jeremy Doig wrote:
i would hope that repainting a progress bar that has not
On 16.11.2008, at 16:16, Ian Hickson wrote:
First of all, I'm not sure I fully understand the problem you are
solving here. Could you summarize it?
You don't have to fire the event if nobody is listening for it.
(Browsers
likely already have this implementation for mutation events if
On Tue, Nov 18, 2008 at 12:09 PM, Antti Koivisto [EMAIL PROTECTED] wrote:
On 16.11.2008, at 16:16, Ian Hickson wrote:
With polling, the polling will miss key points, e.g. when the playback
loops, which will result in the UI appearing to lag behind the playback.
It will also cause higher
[EMAIL PROTECTED] writes:
Would the sender of that link necessarily know all the formats the URL
provides? Anyway, that's an unrealistic amount of typing -- typically
round here people just copy and paste a URL into an instant message and
send it without any surrounding text.
Whereas
Jeremy Doig wrote:
On Mon, Nov 17, 2008 at 3:05 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Jeremy Doig wrote:
i would hope that repainting a progress bar that has not moved
50x/second would not be a normal implementation too. 2x/second
seems more realistic (a 300s
Date: Tue, 18 Nov 2008 12:19:06 +1300
From: Robert O'Callahan [EMAIL PROTECTED]
On Tue, Nov 18, 2008 at 12:09 PM, Antti Koivisto
[EMAIL PROTECTED] wrote:
On 16.11.2008, at 16:16, Ian Hickson wrote:
snip
With polling, the polling will miss key points, e.g. when
the playback loops,
Summary:
* added window.location.resolveURL(). I haven't added it to the Location
in Workers -- should I?
* no other normative changes.
On Thu, 13 Nov 2008, Jonas Sicking wrote:
Actually, i think we should remove the location accessor as well. I
can't think of a common enough use
Indeed. Blobs is a great idea. We'll probably have to create further
JSON extensions to support that.
/ Jonas
Aaron Boodman wrote:
+1, because I think it will be useful to pass other things to workers
that JSON cannot represent (blobs) in the future.
- a
On Mon, Nov 17, 2008 at 8:03 PM,
If you support worker.sendMessage(stuff), where stuff is defined
by convenience to be: whatever you are allowed to send
JSON.stringify(), then you could expand this in the future to also
allow blobs w/o changing anything about JSON.
- a
On Mon, Nov 17, 2008 at 8:10 PM, Jonas Sicking [EMAIL
Well, you'd probably want to support things like
w.postMessage({ command: do cool thing,
data: myBlob });
/ Jonas
Aaron Boodman wrote:
If you support worker.sendMessage(stuff), where stuff is defined
by convenience to be: whatever you are allowed to send
JSON.stringify(), then
Yeah definitely.
You said: We'll probably have to create further JSON extensions to
support that.
My point is that there is no need to change JSON at all if we ever add
blobs to the list of supported types. Even if you happen to use JSON
internally for the implementation now, you could change it
On Tue, Nov 18, 2008 at 7:28 PM, Sander van Zoest [EMAIL PROTECTED]wrote:
By the way, the pixel-aspect-ratio on video caps in the GStreamer
framework has precisely the same meaning as this attribute, overriding
it on a video sink also has an effect similar to what is suggested in
the HTML5
The spec has changed a lot since this e-mail was sent...
On Mon, 22 Nov 2004, Matthew Raymond wrote:
Ian Hickson wrote:
On Sun, 19 Sep 2004, Matthew Raymond wrote:
I was looking at the example in the 2.1. Tutorial section of Web
Applications 1.0[1] when I noticed something. Here's a
On Fri, 10 Dec 2004, Matthew Raymond wrote:
An unassociated label element has no semantic meaning.
It's a label. It just doesn't label anything. I don't see any reason
to say that it stops being a label just because it isn't labelling
anything.
I'm going to have to disagree
41 matches
Mail list logo
