On Jun 9, 2011, at 4:32 PM, Eric Carlson wrote:
On Jun 9, 2011, at 12:02 AM, Silvia Pfeiffer wrote:
On Thu, Jun 9, 2011 at 4:34 PM, Simon Pieters sim...@opera.com wrote:
On Thu, 09 Jun 2011 03:47:49 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
For commercial video
On 06/17/2011 08:34 PM, Aryeh Gregor wrote:
On Thu, Jun 16, 2011 at 5:39 PM, Daniel Chengdch...@chromium.org wrote:
A variation of this idea has been proposed in the past but was largely seen
as undesirable--see
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-May/026254.html. In
On Mon, Jun 20, 2011 at 6:29 PM, Mark Watson wats...@netflix.com wrote:
On Jun 9, 2011, at 4:32 PM, Eric Carlson wrote:
On Jun 9, 2011, at 12:02 AM, Silvia Pfeiffer wrote:
On Thu, Jun 9, 2011 at 4:34 PM, Simon Pieters sim...@opera.com wrote:
On Thu, 09 Jun 2011 03:47:49 +0200, Silvia
On Jun 20, 2011, at 10:42 AM, Silvia Pfeiffer wrote:
On Mon, Jun 20, 2011 at 6:29 PM, Mark Watson
wats...@netflix.commailto:wats...@netflix.com wrote:
On Jun 9, 2011, at 4:32 PM, Eric Carlson wrote:
On Jun 9, 2011, at 12:02 AM, Silvia Pfeiffer wrote:
On Thu, Jun 9, 2011 at 4:34 PM, Simon
On Mon, Jun 20, 2011 at 7:31 PM, Mark Watson wats...@netflix.com wrote:
The TrackList object has an onchanged event, which I assumed would fire when
any of the information in the TrackList changes (e.g. tracks added or
removed). But actually the spec doesn't state when this event fires (as far
On Sun, 19 Jun 2011 00:25:57 +0200, Per-Erik Brodin
per-erik.bro...@ericsson.com wrote:
The Cache-Control request header used with EventSource is not in the
list of simple request headers and a preflight request is not really an
option here in my opinion.
Agreed. I can add that to CORS. I
On Mon, Jun 20, 2011 at 3:22 AM, Anne van Kesteren ann...@opera.com wrote:
On Sun, 19 Jun 2011 00:25:57 +0200, Per-Erik Brodin
per-erik.bro...@ericsson.com wrote:
The Cache-Control request header used with EventSource is not in the list
of simple request headers and a preflight request is not
On Mon, 20 Jun 2011 12:53:02 +0200, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Jun 20, 2011 at 3:22 AM, Anne van Kesteren ann...@opera.com
wrote:
Agreed. I can add that to CORS. I already added Last-Event-ID for that
reason, but somehow missed Cache-Control.
Wait, we don't have to add any
On Mon, Jun 20, 2011 at 3:57 AM, Anne van Kesteren ann...@opera.com wrote:
On Mon, 20 Jun 2011 12:53:02 +0200, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Jun 20, 2011 at 3:22 AM, Anne van Kesteren ann...@opera.com
wrote:
Agreed. I can add that to CORS. I already added Last-Event-ID for
On Mon, 20 Jun 2011 13:02:38 +0200, Jonas Sicking jo...@sicking.cc wrote:
One thing to keep in mind though is that in the case of XHR, the
Content-Type header is often in direct control of the page, even
through means other than setRequestHeader. For example by creating a
Blob with a specific
On Mon, Jun 20, 2011 at 4:06 AM, Anne van Kesteren ann...@opera.com wrote:
On Mon, 20 Jun 2011 13:02:38 +0200, Jonas Sicking jo...@sicking.cc wrote:
One thing to keep in mind though is that in the case of XHR, the
Content-Type header is often in direct control of the page, even
through means
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1039
It says complete in Firefox, loading in Chrome and Opera and
uninitialized in IE. The spec requires complete. readyState is
originally an IE API. Why doesn't the spec require uninitialized?
(The implementation in Gecko is so recent
On Mon, Jun 20, 2011 at 4:26 AM, Henri Sivonen hsivo...@iki.fi wrote:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1039
It says complete in Firefox, loading in Chrome and Opera and
uninitialized in IE. The spec requires complete. readyState is
originally an IE API. Why doesn't
On Sat, 21 May 2011 04:48:15 +0200, Jonas Sicking jo...@sicking.cc wrote:
When we designed CORS we very intentionally did not want to allow
allow * rules for resources that are loaded with user credentials
(most significantly cookies). The reason was that we did not want
people to repeat the
On Jun 20, 2011, at 11:52 AM, Silvia Pfeiffer wrote:
On Mon, Jun 20, 2011 at 7:31 PM, Mark Watson wats...@netflix.com wrote:
The TrackList object has an onchanged event, which I assumed would fire
when
any of the information in the TrackList changes (e.g. tracks added or
removed). But
On 2011-06-20 12:53, Jonas Sicking wrote:
Headers that the implementation adds doesn't need to be added to this
list. For example the Host header is set by the browser in almost
all situations, but it does not need to be added to the list of
simple headers. Indeed, adding in there would an out
On Tue, Jun 21, 2011 at 12:07 AM, Mark Watson wats...@netflix.com wrote:
On Jun 20, 2011, at 11:52 AM, Silvia Pfeiffer wrote:
On Mon, Jun 20, 2011 at 7:31 PM, Mark Watson wats...@netflix.com wrote:
The TrackList object has an onchanged event, which I assumed would fire
when
any of the
On Jun 20, 2011, at 5:28 PM, Silvia Pfeiffer wrote:
On Tue, Jun 21, 2011 at 12:07 AM, Mark Watson wats...@netflix.com wrote:
On Jun 20, 2011, at 11:52 AM, Silvia Pfeiffer wrote:
On Mon, Jun 20, 2011 at 7:31 PM, Mark Watson wats...@netflix.com wrote:
The TrackList object has an
James Graham jgra...@opera.com schrieb am Mon, 20 Jun 2011 10:40:20
+0200:
[…] and the authors who are most likely to get the server-side
wrong are the same ones who are already storing passwords in plain
text.
What reasoning is behind the assertion that those authors will use the
provided
On Mon, Jun 20, 2011 at 7:13 AM, Per-Erik Brodin
per-erik.bro...@ericsson.com wrote:
On 2011-06-20 12:53, Jonas Sicking wrote:
Headers that the implementation adds doesn't need to be added to this
list. For example the Host header is set by the browser in almost
all situations, but it does
On Mon, Jun 20, 2011 at 6:39 AM, Anne van Kesteren ann...@opera.com wrote:
On Sat, 21 May 2011 04:48:15 +0200, Jonas Sicking jo...@sicking.cc wrote:
When we designed CORS we very intentionally did not want to allow
allow * rules for resources that are loaded with user credentials
(most
On Sun, 19 Jun 2011, Per-Erik Brodin wrote:
On 2011-06-17 21:57, Ian Hickson wrote:
On Wed, 1 Jun 2011, ilya goberman wrote:
Can EventSource be enhanced to support cross-domain requests via
Access-Control-Allow-Origin header, just like it is already done for
XHR? See
On Mon, Jun 20, 2011 at 5:09 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
Does anyone have any suggestions on how best to handle this? It seems
like no matter what we do, the best advice to authors would be to set
white-space: pre-wrap on the editable region and the resulting
editable
If the user has the cursor positioned at the beginning or end of a
line, or immediately before or after a space, and hits space,
inserting a space at the current location would result in no visible
effect. Thus browsers will typically insert an nbsp in at least some
of these conditions, and/or
On Mon, Jun 20, 2011 at 11:15 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
James Graham jgra...@opera.com schrieb am Mon, 20 Jun 2011 10:40:20
+0200:
[…] and the authors who are most likely to get the server-side
wrong are the same ones who are already storing passwords in
There's a very good reason why existing browser engines have to resort
to nbsp; hacks. It's the only practical way to make sure that
foo__bar (s/_/ /) entered into an editable element would appear the
intended way when the innerHTML of the editable area is submitted to a
server and later
Aryeh Gregor writes:
The behavior we really want here is to output regular spaces, and use
white-space: pre-wrap.
Does anyone have any suggestions on how best to handle this? It seems
like no matter what we do, the best advice to authors would be to set
white-space: pre-wrap on the
On Mon, Jun 20, 2011 at 5:32 PM, Ehsan Akhgari eh...@mozilla.com wrote:
There's a very good reason why existing browser engines have to resort to
nbsp; hacks. It's the only practical way to make sure that foo__bar
(s/_/ /) entered into an editable element would appear the intended way when
On Mon, Jun 20, 2011 at 3:00 PM, Aryeh Gregor simetrical+...@gmail.comwrote:
Is that really such a problem? At worst, there will be annoying
mismatches between the same content when it's editable and not
editable. Usually these won't really mess up the document, but if the
author notices
On 11-06-20 6:00 PM, Aryeh Gregor wrote:
On Mon, Jun 20, 2011 at 5:32 PM, Ehsan Akhgarieh...@mozilla.com wrote:
There's a very good reason why existing browser engines have to resort to
nbsp; hacks. It's the only practical way to make sure that foo__bar
(s/_/ /) entered into an editable
On Mon, Jun 20, 2011 at 4:40 AM, James Graham jgra...@opera.com wrote:
FWIW I disagree. The same argument could be used against client-side form
validation since some authors might stop doing proper server-side
validation.
I agree, HTML5 forms provide a minor net security loss. However, the
It is certainly the case that some large subset of users use spaces to align
content, not to mention really care about things like two spaces after
periods, etc. One way or another, contentEditable needs to support this.
If we were starting with a clean slate, the editing behavior we want is
15.06.2011, в 16:13, Ryosuke Niwa написал(а):
Now, in horizontal writing modes, 'left' and 'right' are used to move caret
in visual order (in the sense of bidirectional text) and 'forward' and
'backward' are used to move in logical order. However, swapping the meaning
of 'character' and
On Mon, Jun 20, 2011 at 5:33 PM, Alexey Proskuryakov a...@webkit.org wrote:
15.06.2011, в 16:13, Ryosuke Niwa написал(а):
Now, in horizontal writing modes, 'left' and 'right' are used to move
caret
in visual order (in the sense of bidirectional text) and 'forward' and
'backward' are used
In WebVTT we used start and end instead of left and right.
Might that help?
Silvia.
On Tue, Jun 21, 2011 at 11:00 AM, Ojan Vafai o...@chromium.org wrote:
On Mon, Jun 20, 2011 at 5:33 PM, Alexey Proskuryakov a...@webkit.org wrote:
15.06.2011, в 16:13, Ryosuke Niwa написал(а):
Now, in
On Mon, Jun 20, 2011 at 6:14 PM, Silvia Pfeiffer
silviapfeiff...@gmail.comwrote:
In WebVTT we used start and end instead of left and right.
Might that help?
Isn't 'start' and 'end' more analogous to 'forward' and 'backward'? They're
logical movement, right?
- Ryosuke
Moving this to a different subject, since it's all about adaptive streaming now.
On Tue, Jun 21, 2011 at 1:43 AM, Mark Watson wats...@netflix.com wrote:
On Jun 20, 2011, at 5:28 PM, Silvia Pfeiffer wrote:
On Tue, Jun 21, 2011 at 12:07 AM, Mark Watson wats...@netflix.com wrote:
On Jun 20,
On Tue, Jun 21, 2011 at 11:19 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Jun 20, 2011 at 6:14 PM, Silvia Pfeiffer silviapfeiff...@gmail.com
wrote:
In WebVTT we used start and end instead of left and right.
Might that help?
Isn't 'start' and 'end' more analogous to 'forward' and
I'm not sure how that relates to this discussion then.
- Ryosuke
On Mon, Jun 20, 2011 at 6:35 PM, Silvia Pfeiffer
silviapfeiff...@gmail.comwrote:
On Tue, Jun 21, 2011 at 11:19 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Jun 20, 2011 at 6:14 PM, Silvia Pfeiffer
I'm sorry, I probably misunderstood. I saw the discussion about left
and right and vertical writing mode.
forward and backward seem appropriate then, I guess. Disregard me. :-)
Silvia.
On Tue, Jun 21, 2011 at 11:37 AM, Ryosuke Niwa rn...@webkit.org wrote:
I'm not sure how that relates to this
40 matches
Mail list logo
