Re: http://webkit.org/specs/HTML_Timed_Media_Elements.html
There are three things I'd hope to see from a element:
1) Ease of use compared to (A common API contributes to this,
and v2 might approach it with a default UI. Lack of agreement on a
baseline format is a major problem here.)
2) Experi
2007/4/4, Martin Atkins:
* For "cancel" buttons where the server-side app just throws the
submitted form data away, it's pointless to validate it client-side.
Attach the "cancel" button to a distinct 'form' (eventually having the
same 'action' and 'method').
* Allowing the user to submit
On Apr 4, 2007, at 7:31 PM, Vladimir Vukicevic wrote:
Maciej Stachowiak wrote:
CSS Timed Media Module proposal - http://webkit.org/specs/
Timed_Media_CSS.html
Some feedback on my initial reading.. the CSS properties specified
seem like a good set that will cover most common functionality
Maciej Stachowiak wrote:
CSS Timed Media Module proposal - http://webkit.org/specs/
Timed_Media_CSS.html
Some feedback on my initial reading.. the CSS properties specified seem
like a good set that will cover most common functionality. Some
comments about the spec, though:
1. 'media-loop-
On 04/04/07, Michel Fortin <[EMAIL PROTECTED]> wrote:
Indeed it could... in this case. Sometime however the time is
indicated every 5, or 10 minutes to not overload the dialogue with
time references, in which case associating the time reference with
the speaker may not be the best thing to do.
Anne van Kesteren wrote:
On Wed, 04 Apr 2007 14:05:44 +0200, Christian Schmidt
<[EMAIL PROTECTED]> wrote:
It would be useful to be able to mark certain submit buttons as
non-validating.
There appears to be at least some demand for such a feature, and so
far there has been no negative respons
At 18:46 +0100 4/04/07, Nicholas Shanks wrote:
On 4 Apr 2007, at 08:03, Vladimir Vukicevic wrote:
I do agree that the codec discussion should be tabled
I think you mean shelved. Or did you mean we have hit a wall here,
so shelve it and get the chair to table it on the W3C floor? :-)
"tab
Dave Singer schrieb:
> um, as far as I can tell, the 950i has support for H.263 and MPEG4.
Oh, thanks for pointing that out. I mistook the 950i for something
different (without proper out-of-the-box video support). Yeah, most
video-enabled phones have hardware to help with the decoding task,
you'r
At 16:42 +0200 4/04/07, Maik Merten wrote:
> Does this include the sony walkman w950i or modern nokia phones, or
any phone for which opera mini or gmail (downloadable standalone
application) are available?
That's just another reason why we can't rely on dedicated video decoding
hardware -
On 4 Apr 2007, at 08:03, Vladimir Vukicevic wrote:
I do agree that the codec discussion should be tabled
I think you mean shelved. Or did you mean we have hit a wall here, so
shelve it and get the chair to table it on the W3C floor? :-)
- Nicholas.
smime.p7s
Description: S/MIME crypto
Rereading my former posting I fear I jumped the gun on responding. I'd
like to apologize, that sort of discussion won't get us anywhere. I must
confess I got annoyed by the "Thank you for dictating what my product
ships" because I felt we were in a normal discussion where other
opinions are not see
Some more comments/suggestions/etc on the spec, from having tried to
test the stuff up to linear gradients [1].
All my comments on implementations are about Firefox trunk, Opera 9.10
(no different to 9.20), and Safari 2.0.4 (because that's the only one
for which I can find a free online screensho
Le 2007-04-04 à 8:54, David Walbert a écrit :
If the time doesn't have to be a separate block-level element, it
could be marked up simply as
caker (21:57)
sweet
Indeed it could... in this case. Sometime however the time is
indicated every 5, or 10 minutes to not overload
timeless schrieb:
> On 4/2/07, Maik Merten <[EMAIL PROTECTED]> wrote:
>> Usually consumer hardware doesn't receive feature upgrades after it
>> shipped,
>
> since you're using (buying?) the n800, I wonder if you're counting it
> as a consumer product.
I do count it as a consumer device, but it's
On Wed, 04 Apr 2007 14:54:08 +0200, David Walbert <[EMAIL PROTECTED]>
wrote:
If the time doesn't have to be a separate block-
level element, it could be marked up simply as
caker (21:57)
sweet
...
I proposed exactly this a while back, FWIW:
http://lists.whatwg.org/piper
On Mar 30, 2007, at 12:22 PM, Michel Fortin wrote:
21:57
caker
sweet
21:57
caker
it worked
21:57
caker closes out last bug
22:04
encode
yay!
In this case it seems to me that the combination is itself
a header
On Wed, 04 Apr 2007 14:05:44 +0200, Christian Schmidt <[EMAIL PROTECTED]>
wrote:
It would be useful to be able to mark certain submit buttons as
non-validating.
There appears to be at least some demand for such a feature, and so far
there has been no negative responses. What is the next st
Martin Atkins skrev:
It would be useful to be able to mark certain submit buttons as
non-validating.
There appears to be at least some demand for such a feature, and so far
there has been no negative responses. What is the next step?
Christian
On 4/2/07, Maik Merten <[EMAIL PROTECTED]> wrote:
Usually consumer hardware doesn't receive feature upgrades after it
shipped,
since you're using (buying?) the n800, I wonder if you're counting it
as a consumer product.
so most of the already installed hardware base won't get an
upgrade to wh
Philip Taylor wrote:
> [...]
Cool stuff! I'll look through your tests and fix up the mozilla
implementation as much as possible.
I would be happy if "darker" was removed from the spec - there isn't
an obvious definition for it, and it's not interoperably implemented
at all and it sounds like
If supports fallback though, that 20% is enough to bootstrap and
build support, especially as we all hope that that 20% continues to grow.
However, I do agree that the codec discussion should be tabled and that
we should get back to the spec discussion... I've been ignoring much of
the dis
21 matches
Mail list logo
