date:20130820

On Sat, 23 Mar 2013, Jürg Lehni wrote:
 
 - Paper.js has its own share of classes, and one of them is called Path. 
 We normally run scoped but allow people to inject into the global scope. 
 This would override the new Path constructor.

This was last considered last October:

   http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-October/037548.html

My conclusion then was that we didn't have much evidence that Path was 
going to work, but we also didn't have much evidence that it was going to 
be an insurmountable problem.

How much of a problem is the paper.js case?

The name Path is generic, but that's kind of the point -- this interface 
might get used by SVG and other contexts, which is why I didn't call it 
CanvasPath, Path2D, or some variant of Shape.


 - I see there are many ways to construct paths from different type of 
 data, and perform manipulations on them. addPathByStrokingPath() and 
 addPathByStrokingText() are both very welcome, for example. Will there 
 be a way to access the resulting path description again, for example as 
 SVG-style pathData? I have not seen a description of any such property 
 on the object, but would strongly suggest that one is added, since 
 having access to the result of such path manipulations would hugely 
 increase the usefulness of the Path object.

Manipulating paths is something I am punting on until browsers implement 
what's in the spec already, but I imagine at some point we'll add that, 
yeah.


On Sat, 23 Mar 2013, Rik Cabanier wrote:
 
 The current path APIs suffer from conflating path segments and geometry. 
 To fix this, I proposed to modify the API so path just describe the path 
 segments.

 http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/

I disagree with the premise of this post -- it's not the case that you 
never want to add segments. It is in fact quite common to add segments to 
a path -- that's what constructing a path is.

Also, it's not at all clear to me that there's really a distinction 
between a shape and a path. They're really the same thing -- sets of 
path segments. What distinguishes them is not anything intrinsic to them, 
it's the behaviour when you combine segments.

Thus the clearer solution, IMHO, insofar as there's a problem, is to add 
methods that describe the various ways to combine paths.

Right now we have two options (ignoring the text parts of the path API): 
concatenating path segments, and concatenating path segments after having 
first outlined one of them.

On the long run I think it would make sense to add other methods, e.g. one 
combining two or more paths together such that the resulting path would 
outline the union of the insides of the provided paths, or the 
intersections, or whatnot.


On Tue, 9 Apr 2013, Jürg Lehni wrote:
 
 Path, Shape, Gradient, Matrix all seem way too generic, and will 
 definitely clash with many libraries.

It's not that clear that this is true. There really haven't been that many 
reports of clashes, all things considered -- and it's not clear that 
Path2D, GraphicsPath, CanvasPath, or any number of other variants, would 
really be any more or less likely to clash.


 It was pointed out before that Path could also be a object describing a 
 file path, not necessarily a (2D) gemoetric path.

True, but if the argument is we can't use Path, then we couldn't use it 
for that either, so there'd be no clash.


On Mon, 17 Jun 2013, Jürg Lehni wrote:
 
 And what is required to get such a proposal through?

Convince the browser vendors. At the end of the day, the spec will follow 
whatever the browsers do. (There's no process to convince them; one way is 
to argue here and hope they care and agree; another is to approach them 
directly, e.g. via their development discussion fora.)


On Mon, 24 Jun 2013, Jürg Lehni wrote:

 Well I know there will be problems: Paper.js has a Path class since 
 2011, and these will clash when using the library without scoping, which 
 is what many people do.

How many is many? How high-profile are they?


 I was hoping that a more specific name could be adopted before the 
 standard is set in stone

We are never going to set the standard in stone. The only thing that 
prevents changes to the standard, really, is whether there's content that 
depends on it (which is usually the same as saying, whether there's 
browsers that implement it).


 I doubt we're the only library that clashes.

Do we have any data on this? Do any libraries use Path2D?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[whatwg] Canvas - Should setLineDash be a nullable sequence?

2013-08-20 Thread Simon Sarris

This is minor, but it did recently break formerly-working functionality in
Google Chrome, so maybe its worth a discussion.

The specification reads:

  void setLineDash(sequenceunrestricted double segments); // default empty
  sequenceunrestricted double getLineDash();

This means we *cannot* use:

ctx.setLineDash(null);

In Chrome 28 and previous (for at least 6 months) null was an allowed
value, but in Chrome 30 (at least) it switched to throwing a TypeError.
This is technically more correct, though lots of existing JavaScript code
will now stop working because of their change. This doubtless kills some
current JS libraries that were using null, such as mine, and now my
customers must upgrade or get errors when their clients use Chrome.

It's possible that Chrome did not mean to break functionality here, but to
their credit they are now following the spec to the letter. I wrote to them
about that here:

https://code.google.com/p/chromium/issues/detail?id=266948

But the Chrome team seems shy about using their bugtracker, so I don't
know if we'll get a response as to whether or not it was an intentional
change.

In any case, I think it would be better if setLineDash was defined in the
spec as a nullable sequence, so that when setting it back to nothing to
return to normal not-dashed path stroking (which could happen thousands of
times in a an animation frame) less stuff gets allocated in the draw loop.
JS authors can use a static empty array to avoid extra memory allocation,
but a brief look at the webkit code suggests (and I may be totally
incorrect here) that the array gets copied anyway, and that's no fun:

https://github.com/WebKit/webkit/blob/master/Source/WebCore/html/canvas/CanvasRenderingContext2D.cpp#L515

I think part of the issue is that setLineDash does two things. It sets the
dashing properties, but it also acts as the only way to enable/disable
dashing, I think that null seems appropriate.

For the record, AFAIK no other browser has implemented setLineDash yet,
though ctx.mozDash defaults to null and does accept null.

Simon Sarris

Re: [whatwg] Questions regarding Path object

2013-08-20 Thread Rik Cabanier

On Sat, 23 Mar 2013, Rik Cabanier wrote:

The current path APIs suffer from conflating path segments and geometry.
To fix this, I proposed to modify the API so path just describe the path
segments.

http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/

I disagree with the premise of this post -- it's not the case that you
never want to add segments. It is in fact quite common to add segments to
a path -- that's what constructing a path is.

I disagree. How many times does an author want to add segments to an
existing path?

Let's say an application stores a circle in a path and now want to draw a
rectangle too. You propose that the application just appends the rectangle
. However as my post points out, if the rectangle and the circle interact,
the result is not what is expected.
It is much more common to combine shapes which will always give you the
effect you're looking for.

Also, it's not at all clear to me that there's really a distinction
between a shape and a path. They're really the same thing -- sets of
path segments.

No. A shape is no longer a group of line segments.
You *could* convert it to such a thing but that requires a bunch of complex
math (ie http://www.youtube.com/watch?v=OmfliNQsk88)
For now, I'm not proposing to add that to the canvas API.

What distinguishes them is not anything intrinsic to them,
it's the behaviour when you combine segments.

Thus the clearer solution, IMHO, insofar as there's a problem, is to add
methods that describe the various ways to combine paths.

Paths don't have winding so if you combine them, it will have to be part of
the methods that union them.
The resulting 'path' will once again have no winding. This is very
confusing and extremely hard to implement

Right now we have two options (ignoring the text parts of the path API):
concatenating path segments, and concatenating path segments after having
first outlined one of them.

FYI the outlining algorithm is also not correct. It suffers from the same
issue that strokes are segments.

On the long run I think it would make sense to add other methods, e.g. one
combining two or more paths together such that the resulting path would
outline the union of the insides of the provided paths, or the
intersections, or whatnot.

I think that would be much more confusing and difficult to implement.
I didn't come up with this on my own :-). This is done by graphics
libraries that offers path manipulation support.
For instance:
skia:
http://skia-autogen.googlecode.com/svn/docs/html/classSkPathEffect.html
lib2geom: http://wiki.inkscape.org/wiki/index.php/WorkingWith2GeomFAQ
Direct2D:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd756653(v=vs.85).aspx#path_geometries

[whatwg] Promise.every() arguments

2013-08-20 Thread Alec Flett

I've been doing a lot of experimentation with Promises using the Blink
implementation. I've frequently hit an issue with the .every() / .any() /
.some()

the problem is that they support a variable number of arguments. This seems
very developer friendly in theory, as per the docs:

Promise.every(fetchJSON(foo), fetchJSON(bar), fetchJSON(baz));

This is great the first time you play with it on your local developer
console.

The problem arises in practice: it's very common to build up arrays of N
promises, and then tie them all together. Even if your own API uses
varargs, using Promise.every breaks down.

function getDocuments(requests) {
var pending = [];
for (var i = 0; i  requests.length; ++i) {
var url = extractUrl(requests[i]);
pending.push(fetchJSON(url));
};

// nope, this won't work!
// return Promise.every(pending);

// only this works
Promise.every.apply(Promise, pending);
}

this is how (and why) kiskowal's Q works with an array as the single
parameter:

https://github.com/kriskowal/q#combination

Alec

Re: [whatwg] Promise.every() arguments

On Tue, Aug 20, 2013 at 1:42 PM, Alec Flett alecfl...@chromium.org wrote:
 I've been doing a lot of experimentation with Promises using the Blink
 implementation. I've frequently hit an issue with the .every() / .any() /
 .some()

 the problem is that they support a variable number of arguments. This seems
 very developer friendly in theory, as per the docs:

 Promise.every(fetchJSON(foo), fetchJSON(bar), fetchJSON(baz));

 This is great the first time you play with it on your local developer
 console.

 The problem arises in practice: it's very common to build up arrays of N
 promises, and then tie them all together. Even if your own API uses
 varargs, using Promise.every breaks down.

ES6 has array spreading, so you can do `Promise.every(...pending)`.
This already works in Firefox, and V8 (Chrome's JS engine) is adding
these kinds of features as well.

~TJ

Re: [whatwg] Promise.every() arguments

2013-08-20 Thread Anne van Kesteren

On Tue, Aug 20, 2013 at 10:00 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 ES6 has array spreading, so you can do `Promise.every(...pending)`.
 This already works in Firefox, and V8 (Chrome's JS engine) is adding
 these kinds of features as well.

Domenic made an argument somewhere that since the value of the promise
will be an array, the input should maybe be an array too. Seemed
somewhat reasonable. I agree that due to spreading we shouldn't
consider OP's argument though.


-- 
http://annevankesteren.nl/

Re: [whatwg] Promise.every() arguments

2013-08-20 Thread Alec Flett

Hey spreading sounds great... I miss that from python.

But, the promise array issue still feels really awkward to me.

One confusing example of this is that if you *do* pass an array,
(incorrectly) the then() gets an array of an array of unresolved promises:

Promise.every([Promise.resolve(1),
Promise.resolve(2)]).then(function(results) {
// here results is [[Promise, Promise]]
})

Which again from a developer perspective seems more like Promise.every()
forgot to resolve all the promises, not that you're using the API wrong.

Whereas if the API were the other way around, and you pass
Promise.every(Promise.resolve(1), Promise.resolve(2)) by accident,
Promise.every() can throw an exception to say don't do that, you clearly
misunderstand

Promises are going to be out way before ES6, it seems unfortunate that
everyone's going to have to use Promise.every.apply though, since spreading
is a syntax error in non-ES6... it means you can't polyfill it in the
general case. (And maybe there's some generic answer to that aspect of ES6
- I'm admittedly not up to speed on the ES6 future-compatible story)

Alec


On Tue, Aug 20, 2013 at 2:23 PM, Anne van Kesteren ann...@annevk.nl wrote:

 On Tue, Aug 20, 2013 at 10:00 PM, Tab Atkins Jr. jackalm...@gmail.com
 wrote:
  ES6 has array spreading, so you can do `Promise.every(...pending)`.
  This already works in Firefox, and V8 (Chrome's JS engine) is adding
  these kinds of features as well.

 Domenic made an argument somewhere that since the value of the promise
 will be an array, the input should maybe be an array too. Seemed
 somewhat reasonable. I agree that due to spreading we shouldn't
 consider OP's argument though.


 --
 http://annevankesteren.nl/

Re: [whatwg] Should video controls generate click events?

2013-08-20 Thread Edward O'Connor

Hi,

 [W]e do want users to be able to bring up the native controls via a
 context menu and be able to use them regardless of what the page
 does in its event handlers. So, I request that the spec be explicit
 that interacting with the video controls does not cause the normal
 script-visible events to be fired.
[…]
 I've made the spec say this is a valid (and recommended)
 implemenation strategy.
 
 The change http://html5.org/r/8134 looks good to me, thanks!

I don't see why video controls should be any different than, say,
button here. If I install an event handler on an ancestor of an
element, I'm able to capture events and prevent the descendent element
from seeing them.

A UI which allows users to activate a control regardless of what the
page does in its event handlers is a general feature not specific to
media elements—and may be worth considering—but we shouldn't make a
one-off exception to the basic model of DOM events just for video.


Ted

Re: [whatwg] Should video controls generate click events?

On Wed, Aug 21, 2013 at 7:52 AM, Edward O'Connor eocon...@apple.com wrote:

 Hi,

  [W]e do want users to be able to bring up the native controls via a
  context menu and be able to use them regardless of what the page
  does in its event handlers. So, I request that the spec be explicit
  that interacting with the video controls does not cause the normal
  script-visible events to be fired.
 […]
  I've made the spec say this is a valid (and recommended)
  implemenation strategy.
 
  The change http://html5.org/r/8134 looks good to me, thanks!

 I don't see why video controls should be any different than, say,
 button here. If I install an event handler on an ancestor of an
 element, I'm able to capture events and prevent the descendent element
 from seeing them.

 A UI which allows users to activate a control regardless of what the
 page does in its event handlers is a general feature not specific to
 media elements—and may be worth considering—but we shouldn't make a
 one-off exception to the basic model of DOM events just for video.



The paragraph added in http://html5.org/r/8134 should probably be
restricted to the case where the default video controls have been enabled
by the user (e.g. through the context menu) rather than by the Web page. It
would indeed be bad if the Web page author, who is using the default
controls through a video controls attribute could not rely on the events
firing.

IMHO, the example that Philip provided in http://people.opera.com/~**
philipj/click.html http://people.opera.com/~philipj/click.html is not a
realistic example of something a JS dev would do.

Silvia.

Re: [whatwg] 2D canvas feature proposal: text decoration

On Thu, 18 Apr 2013, Justin Novosad wrote:

 This is a really simple proposal to add support for text decorations in 
 2D canvas contexts.
 
 IDL to add to interface CanvasDrawingStyles:
 
 attribute DOMString textDecoration;
 
 It would support all the same modes as the 'text-decoration' CSS 
 property (except inherit), and default would be 'none'.

That's anything but simple. :-)

The CSS text-decoration model is actually quite complex. Also, there have 
been many proposals to split 'text-decoration' into sub-properties, so it 
is only going to get more complicated from there.

What's your use case? That is, when do you need to underline text?


On Thu, 18 Apr 2013, David Dailey wrote:

 You know, I'm not quite sure why we have text in canvas at all. It's not 
 really text you know -- it's just a bunch of pixels. You can't select 
 it, you can't copy it to the clipboard, it's not accessible without a 
 bunch of effort that authors generally don't use. It's generally illegal 
 in most civilized places. Why not use SVG?

Or, indeed, HTML.


 It's got text decoration. Text is text. It's just that the more 
 conspiratorial and selfish of the browser vendors back when things were 
 being voted on seemed to push canvas since they already owned it and SVG 
 seemed hard and like they might have to learn something by way of 
 graphics in their corporate portfolios.

That's not quite how it went down.

There are times where you really need text in your canvas, e.g. if you 
want to label things in your Mandelbrot set viewer.


On Sat, 20 Apr 2013, Nils Dagsson Moskopp wrote:
 
 That said, I suspect that anything that makes it easier to create text 
 in canvas can and will be used to create inaccessible interfaces. My 
 personal experience regarding web accessability is very frustrating – 
 authors generally do not care, even if they know about it.
 
 FYI, I have problems with low-contrast text, but at least I can correct 
 for that using user stylesheets. How would I do that with canvas text?

You cannot (same as with text in a PNG).


On Thu, 18 Apr 2013, Rik Cabanier wrote:
 
 I checked and the values in CanvasDrawingStyles don't correspond with CSS
 values so it should be OK to turn them into enums.

They're mostly just DOMStrings because I haven't gotten around to changing 
them. Changing strings to enums is risky (I could introduce bugs when 
doing so), so I tend to avoid doing so unless someone makes a specific 
explicit request for a specific property to be converted.


On Fri, 19 Apr 2013, Justin Novosad wrote:
 
 That sounds OK. However, I would find it unfortunate to re-specify the 
 behavior of the property in the canvas 2d context spec, when we could 
 just spec it like 'font' by saying that it is interpreted the same way 
 as the corresponding CSS property. I think it is a good idea to keep in 
 sync with CSS whenever we can.

Unfortunately, just is not really the right word here. The CSS inline 
box model, including the text-decoration part, are non-trivial. CSS has to 
deal with all kinds of things that we don't have to deal with in canvas, 
e.g. multiple baselines, multiple lines, etc.


 FWIW, some of the other properties have good reasons for being 
 re-specified in the 2d canvas spec. For example, text alignment works 
 very differently in CSS vs. 2D canvas.

Right. Underlining may fall into this bucket too.


But before we can determine this, we need to determine what your use case 
is. What are you trying to do? Why?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Should video controls generate click events?

On Tue, Aug 20, 2013 at 3:28 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
 IMHO, the example that Philip provided in http://people.opera.com/~**
 philipj/click.html http://people.opera.com/~philipj/click.html is not a
 realistic example of something a JS dev would do.

Um, why not?  Clicking on the video to play/pause is a useful
behavior, which things like the Youtube player do.  Since video
elements don't generally do this, it seems reasonable that an author
could do pretty much exactly what Philip shows in his demo.

~TJ

[whatwg] Path API feedback

On Fri, 26 Apr 2013, Rik Cabanier wrote:
 
 I think an author would expect that 'addPathByStrokingPath' and other 
 path methods render as if you stroked/outlined directly on the canvas 
 context. Same goes for 'addPath'.
 
 I believe very few people actually want the current behavior that's in 
 the spec.

I don't know how true that is.

It seems logical to me that this:

   context.beginPath();
   context.rect(0,0,100,100);
   context.rect(50,50,150,150);
   context.fill();

...should do the same as this:

   var p1 = new Path();
   p1.rect(0,0,100,100);
   var p2 = new Path();s
   p2.rect(50,50,150,150);
   var p = new Path();
   p.addPath(p1);
   p.addPath(p2);
   context.fill(p);

...for any combination of path commands where I've put the rect()s.


   I think the spec needs to mention that
   - sections of the path where both edges are filled should be removed
   - winding needs to be done so eofill and fill give the same result
 
  I've filed a bug for adding something like this:
 
 https://www.w3.org/Bugs/Public/show_bug.cgi?id=21835
 
  I'm not sure exactly what the algorithm should be (as we discussed on 
  IRC today), so if anyone has any input here, please don't hesitate to 
  comment.
 
 I can help if needed. I know the skia people are working on this as 
 well.
 
 The algorithm is fairly straightforward to describe in prose. 
 Implementation is very hard though...

Please do add such help as comments on the bug, that would be very 
helpful.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Should video controls generate click events?

On Wed, Aug 21, 2013 at 8:32 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:

 On Tue, Aug 20, 2013 at 3:28 PM, Silvia Pfeiffer
 silviapfeiff...@gmail.com wrote:
  IMHO, the example that Philip provided in http://people.opera.com/~**
  philipj/click.html http://people.opera.com/~philipj/click.html is not
 a
  realistic example of something a JS dev would do.

 Um, why not?  Clicking on the video to play/pause is a useful
 behavior, which things like the Youtube player do.  Since video
 elements don't generally do this, it seems reasonable that an author
 could do pretty much exactly what Philip shows in his demo.


YouTube has their own controls for this, so Philip's example does not apply.

What I'm saying is that the idea that the JS developer controls pause/play
as well as exposes video controls is a far-fetched example.

Silvia.

Re: [whatwg] canvas 2d's ellipse

On Tue, 30 Apr 2013, Rik Cabanier wrote:

 1. Why are most of the [ellipse] parameters not optional?

It's supposed to be the same as arc(), but with radius split into radiusX 
and radiusY, and with the addition of the rotation argument.


 So, if you want to draw a simple circle, you have to supply 8 parameters,
 even though only 3 are needed.

If you just want a circle, you can use arc().


 All other calls have anticlockwise optional, why not ellipse?

Probably just an oversight. I've made this consistent with arc().


 2. when is an ellipse closed?
 It's not clear from the prose if there is ever a 'closepath'. So, if you
 have square end caps, you will see a discontinuity unless you call
 'closepath'.

It works the same as arc(). I'm not really sure what you're asking here.


 3. the following lines are somewhat confusing:
 
 If the anticlockwise argument false and endAngle-startAngle is equal to or
 greater than 2π, or, if the anticlockwise argument is true
 andstartAngle-endAngle is equal to or greater than 2π, then the arc is the
 whole circumference of this ellipse.
 
 and:
 
 Since the points are on the ellipse, as opposed to being simply angles from
 zero, the arc can never cover an angle greater than 2π radians.
 
 Why not simply say that the angles define the points on the ellips and draw
 the arc between them? That seems more clear.

It means something different. For example, 0..3π is supposed to cover the 
whole arc, but if we define things as points on the ellipse, it would be 
half an arc.


On Tue, 30 Apr 2013, Rik Cabanier wrote:

 I think the API should look like this:
 
 void ellipse(unrestricted double x, optional unrestricted double y,
 unrestricted double radiusX, optional unrestricted double radiusY, optional
 unrestricted double rotation, optional unrestricted double startAngle,
 optional unrestricted double endAngle, optional boolean anticlockwise);
 
 with the following behavior:
 - if radiusY is omitted, it's the same as radiusX
 - if rotation is omitted, it's equal to 0
 - if startAngle is omitted, it's equal to 0
 - if endAngle is omitted, it's equal to 0
 - if anticlockwise is omitted, it's equal to false

We could do this, sure. How much do people want something like this? Does 
anyone else think it's a good idea?


 startAngle and endAngle always refer to points on the circle. If they 
 coincide, the end result is a full circle (with a closepath).

We can't change arc()'s behaviour. ellipse() should behave as close to 
arc() as possible, for sanity. (I wouldn't have introduced it at all, if 
there was some sane way to overload arc() to add radiusY and rotation. But 
there isn't, really.)


On Tue, 30 Apr 2013, Rik Cabanier wrote:
 
 I think the exception on negative radius should also be removed.

What would a negative radius mean?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Should video controls generate click events?

2013-08-20 Thread Bob Lund



On 8/20/13 4:46 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote:

On Wed, Aug 21, 2013 at 8:32 AM, Tab Atkins Jr.
jackalm...@gmail.comwrote:

 On Tue, Aug 20, 2013 at 3:28 PM, Silvia Pfeiffer
 silviapfeiff...@gmail.com wrote:
  IMHO, the example that Philip provided in http://people.opera.com/~**
  philipj/click.html http://people.opera.com/~philipj/click.html is
not
 a
  realistic example of something a JS dev would do.

 Um, why not?  Clicking on the video to play/pause is a useful
 behavior, which things like the Youtube player do.  Since video
 elements don't generally do this, it seems reasonable that an author
 could do pretty much exactly what Philip shows in his demo.


YouTube has their own controls for this, so Philip's example does not
apply.

What I'm saying is that the idea that the JS developer controls pause/play
as well as exposes video controls is a far-fetched example.

What about a Web page that uses JS to control pause/play/etc based on
external messages, say from a WebSocket? The sender in this case acts as a
remote control.


Silvia.

Re: [whatwg] Should video controls generate click events?

On Wed, Aug 21, 2013 at 8:57 AM, Bob Lund b.l...@cablelabs.com wrote:



 On 8/20/13 4:46 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote:

 On Wed, Aug 21, 2013 at 8:32 AM, Tab Atkins Jr.
 jackalm...@gmail.comwrote:
 
  On Tue, Aug 20, 2013 at 3:28 PM, Silvia Pfeiffer
  silviapfeiff...@gmail.com wrote:
   IMHO, the example that Philip provided in http://people.opera.com/~**
   philipj/click.html http://people.opera.com/~philipj/click.html is
 not
  a
   realistic example of something a JS dev would do.
 
  Um, why not?  Clicking on the video to play/pause is a useful
  behavior, which things like the Youtube player do.  Since video
  elements don't generally do this, it seems reasonable that an author
  could do pretty much exactly what Philip shows in his demo.
 
 
 YouTube has their own controls for this, so Philip's example does not
 apply.
 
 What I'm saying is that the idea that the JS developer controls pause/play
 as well as exposes video controls is a far-fetched example.

 What about a Web page that uses JS to control pause/play/etc based on
 external messages, say from a WebSocket? The sender in this case acts as a
 remote control.


The patch applies only to the case where the user interacts with
browser-provided controls on the video element. In your case, the JS dev
would probably not use the @controls attribute on the video element, since
the playback controls comes from the remote.

Silvia.

Re: [whatwg] canvas 2d's ellipse

On Tue, Aug 20, 2013 at 3:46 PM, Ian Hickson i...@hixie.ch wrote:
 On Tue, 30 Apr 2013, Rik Cabanier wrote:
 I think the API should look like this:

 void ellipse(unrestricted double x, optional unrestricted double y,
 unrestricted double radiusX, optional unrestricted double radiusY, optional
 unrestricted double rotation, optional unrestricted double startAngle,
 optional unrestricted double endAngle, optional boolean anticlockwise);

 with the following behavior:
 - if radiusY is omitted, it's the same as radiusX
 - if rotation is omitted, it's equal to 0
 - if startAngle is omitted, it's equal to 0
 - if endAngle is omitted, it's equal to 0
 - if anticlockwise is omitted, it's equal to false

 We could do this, sure. How much do people want something like this? Does
 anyone else think it's a good idea?

I can tell you that specifying all of the arguments in SVG's ellipse
path command is rather annoying.  Having good defaults would be a good
thing.

~TJ

Re: [whatwg] Should video controls generate click events?

I'm wondering how this will effect interaction programming with Popcorn.js.
Sylvia, would you mind clearly defining the implications of this change,
given what you know about the project? Feel free to respond offline if you
feel that discussion would derail the subject.

Thanks

Rick


On Tue, Aug 20, 2013 at 7:05 PM, Silvia Pfeiffer
silviapfeiff...@gmail.comwrote:

 On Wed, Aug 21, 2013 at 8:57 AM, Bob Lund b.l...@cablelabs.com wrote:

 
 
  On 8/20/13 4:46 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote:
 
  On Wed, Aug 21, 2013 at 8:32 AM, Tab Atkins Jr.
  jackalm...@gmail.comwrote:
  
   On Tue, Aug 20, 2013 at 3:28 PM, Silvia Pfeiffer
   silviapfeiff...@gmail.com wrote:
IMHO, the example that Philip provided in
 http://people.opera.com/~**
philipj/click.html http://people.opera.com/~philipj/click.html is
  not
   a
realistic example of something a JS dev would do.
  
   Um, why not?  Clicking on the video to play/pause is a useful
   behavior, which things like the Youtube player do.  Since video
   elements don't generally do this, it seems reasonable that an author
   could do pretty much exactly what Philip shows in his demo.
  
  
  YouTube has their own controls for this, so Philip's example does not
  apply.
  
  What I'm saying is that the idea that the JS developer controls
 pause/play
  as well as exposes video controls is a far-fetched example.
 
  What about a Web page that uses JS to control pause/play/etc based on
  external messages, say from a WebSocket? The sender in this case acts as
 a
  remote control.
 

 The patch applies only to the case where the user interacts with
 browser-provided controls on the video element. In your case, the JS dev
 would probably not use the @controls attribute on the video element, since
 the playback controls comes from the remote.

 Silvia.

Re: [whatwg] Should video controls generate click events?

On Tue, Aug 20, 2013 at 3:46 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
 On Wed, Aug 21, 2013 at 8:32 AM, Tab Atkins Jr. jackalm...@gmail.com
 wrote:

 On Tue, Aug 20, 2013 at 3:28 PM, Silvia Pfeiffer
 silviapfeiff...@gmail.com wrote:
  IMHO, the example that Philip provided in http://people.opera.com/~**
  philipj/click.html http://people.opera.com/~philipj/click.html is not
  a
  realistic example of something a JS dev would do.

 Um, why not?  Clicking on the video to play/pause is a useful
 behavior, which things like the Youtube player do.  Since video
 elements don't generally do this, it seems reasonable that an author
 could do pretty much exactly what Philip shows in his demo.


 YouTube has their own controls for this, so Philip's example does not apply.

 What I'm saying is that the idea that the JS developer controls pause/play
 as well as exposes video controls is a far-fetched example.

Yes, Youtube has their own controls.  They have long-standing branding
that makes it worthwhile for them to roll their own.

Why would I want to roll my own, though, when all I want is to add
click-to-play/pause?  That seems like a lot of difficult make-work.

~TJ

Re: [whatwg] Should video controls generate click events?

On Tue, Aug 20, 2013 at 7:11 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:

 On Tue, Aug 20, 2013 at 3:46 PM, Silvia Pfeiffer
 silviapfeiff...@gmail.com wrote:
  On Wed, Aug 21, 2013 at 8:32 AM, Tab Atkins Jr. jackalm...@gmail.com
  wrote:
 
  On Tue, Aug 20, 2013 at 3:28 PM, Silvia Pfeiffer
  silviapfeiff...@gmail.com wrote:
   IMHO, the example that Philip provided in http://people.opera.com/~**
   philipj/click.html http://people.opera.com/~philipj/click.html is
 not
   a
   realistic example of something a JS dev would do.
 
  Um, why not?  Clicking on the video to play/pause is a useful
  behavior, which things like the Youtube player do.  Since video
  elements don't generally do this, it seems reasonable that an author
  could do pretty much exactly what Philip shows in his demo.
 
 
  YouTube has their own controls for this, so Philip's example does not
 apply.
 
  What I'm saying is that the idea that the JS developer controls
 pause/play
  as well as exposes video controls is a far-fetched example.

 Yes, Youtube has their own controls.  They have long-standing branding
 that makes it worthwhile for them to roll their own.

 Why would I want to roll my own, though, when all I want is to add
 click-to-play/pause?  That seems like a lot of difficult make-work.


Firefox actually implements click-to-play video by default. It's
unfortunate and all video interaction projects that I've worked on
directly or consulted for have been forced to include video surface click
- event.preventDefault() calls to stop the behaviour. This may be
irrelevant to the current discussion, but I'm trying to get a better
understanding for the behavioural changes implied by this spec update, so
correction is highly desirable.

Rick

Re: [whatwg] Should video controls generate click events?

2013-08-20 Thread Glenn Maynard

 On Tue, Aug 20, 2013 at 3:46 PM, Silvia Pfeiffer 
silviapfeiff...@gmail.com wrote:

   What I'm saying is that the idea that the JS developer controls
  pause/play
   as well as exposes video controls is a far-fetched example.


I don't understand what's far-fetched about that.  They seem orthogonal to
me.

On Tue, Aug 20, 2013 at 6:18 PM, Rick Waldron waldron.r...@gmail.comwrote:

 Firefox actually implements click-to-play video by default. It's
 unfortunate and all video interaction projects that I've worked on
 directly or consulted for have been forced to include video surface click
 - event.preventDefault() calls to stop the behaviour.


It's the behavior users expect when watching videos, which is the case
video should optimize for.  If you're doing something else where the user
interacts with the video in other ways, then it's expected that you need to
prevent this behavior explicitly.

Unlike browser controls, this is visible to scripts and something that
affects authors, so this probably should be in the spec if it isn't.

-- 
Glenn Maynard

Re: [whatwg] Styling details

On Thu, 3 Jan 2013, Brett Zamir wrote:
 
 In my ideal world, with HTML deprived of XML or XML-like extensibility 
 (no entities or namespaces), and even with what Web Components or the 
 like could do, and with JavaScript already being able to encompass this 
 functionality, there appears to me to be a far greater need for making a 
 standard and familiar/friendly JSON/JavaScript way to represent HTML 
 than an HTML way to represent JavaScript.

There've been proposals to do this at the language level, e.g.:

   http://www.hixie.ch/specs/e4h/strawman

However, in practice I've found that you can pretty easily define two 
functions in JS that make this work more or less sufficiently well.

The first function is E(), which returns an element. It's signature:

   E(name, [attrs,] [children...])

...where attrs is an optional dictionary where:

 - entries whose value is a string are added as content attributes with 
   the given value
 - entries whose value is a number are added as content attributes with
   the given value as a string
 - entries whose value is true are added as content attributes with
   the empty vlaue
 - entries whose value is false are ignored
 - entries whose value is a function are assumed to be IDL attributes that 
   are to be set to that function
 - other entries throw an exception

...and where children is zero or more arguments where:

 - values that are Element, Comment, and Text nodes are appended to the 
   element as children
 - values that are DocumentFragments have their children appended to the
   element in the same way
 - values that are strings are appended as text nodes with the given value
 - values that are numbers are appended as text nodes with the given value 
   converted to a string
 - values that are arrays are recursively processed in the same way
 - other values throw an exception

The second function is F(children...) which takes just the varargs like 
the previous function, but returns a DocumentFragment instead.

So e.g.:

   document.body.appendChild(F(
 E('p', E('input', { type: 'button', 
 value: 'Demo',
 onclick: function (event) { alert('Hello!') }, 
   }),
' Press the button, ', name, '! ', // name is a string var
E('em', { class: 'beg' }, 'Please!';

It's not as pretty as E4H, but it's functional and way better than 
constructing it using raw DOM calls.

For the record, the E4H equivalent would be:

   document.body.appendChild(pinput type=button
 value=Demo 
 onclick=alert('Hello!')/\
  Press the button, {name}!\
  em class=begPlease!/em/p/);

(If we did go down the E4H route, we'd have to find a better solution for 
event handlers, though.)


 [ // Optional document meta-attributes could come here
 ['html', [
 ['head', [
 ['script', [
 // A JSON format sans functions could be possible, but allowable
 for convenience in templating
 {$script: function (onReady) {
 require(['depend1'], function (depend1) {
 onReady(function () {
 document.body.appendChild(['p', ['World']]);
 depend1('no additional script tags needed for
 modularity');
 
 // Ready and easy conversion
 var jml = ['b', ['Hello']], html = 'bHello/b', dom
 = document.createElement(jml);
 jml === html.toJML() 
 jml === dom.toJML() 
 html === jml.toHTML() 
 html === dom.toHTML() 
 dom === html.toDOM() 
 dom === jml.toDOM(); // true
 });
 });
 }}
 ]],
 ['style', [
 // Non-array objects would normally represent attributes, but when
 prefixed with the
 //   reserved '$', other features become possible for HTML (or
 XML)
 {$css: [
 ['p[greeting]', ['color', 'blue']]
 ]
 ]]
 ]],
 ['body', [
 'text',
 ['p', {'class':'greeting'}, ['Hello!']],
 {'$#x': '263A'},
 {$comment: 'Finished file!'}
 ]]
 ]]
 ]

I don't really see the advantage of such a format. What problem are you 
solving here?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] canvas 2d's ellipse

2013-08-20 Thread Rik Cabanier

On Tue, Aug 20, 2013 at 3:46 PM, Ian Hickson i...@hixie.ch wrote:

 On Tue, 30 Apr 2013, Rik Cabanier wrote:
 
  1. Why are most of the [ellipse] parameters not optional?

 It's supposed to be the same as arc(), but with radius split into radiusX
 and radiusY, and with the addition of the rotation argument.


  So, if you want to draw a simple circle, you have to supply 8 parameters,
  even though only 3 are needed.

 If you just want a circle, you can use arc().


OK. What if you want to draw a simple ellipse?




  All other calls have anticlockwise optional, why not ellipse?

 Probably just an oversight. I've made this consistent with arc().


  2. when is an ellipse closed?
  It's not clear from the prose if there is ever a 'closepath'. So, if you
  have square end caps, you will see a discontinuity unless you call
  'closepath'.

 It works the same as arc(). I'm not really sure what you're asking here.


True. arc() has the same issue.
Here's an example of the issue: http://jsfiddle.net/2N85k/2/
Because the stroke is using square caps, you can't draw a circle or an
ellipse unless you do a closePath.

Chrome is doing an implicit closePath if start and end angle meet, but none
of the other browsers do.,




  3. the following lines are somewhat confusing:
 
  If the anticlockwise argument false and endAngle-startAngle is equal to
 or
  greater than 2π, or, if the anticlockwise argument is true
  andstartAngle-endAngle is equal to or greater than 2π, then the arc is
 the
  whole circumference of this ellipse.
 
  and:
 
  Since the points are on the ellipse, as opposed to being simply angles
 from
  zero, the arc can never cover an angle greater than 2π radians.
 
  Why not simply say that the angles define the points on the ellips and
 draw
  the arc between them? That seems more clear.

 It means something different. For example, 0..3π is supposed to cover the
 whole arc, but if we define things as points on the ellipse, it would be
 half an arc.


the spec does say 'Since the points are on the ellipse' hence my confusion
:-)




 On Tue, 30 Apr 2013, Rik Cabanier wrote:
 
  I think the API should look like this:
 
  void ellipse(unrestricted double x, optional unrestricted double y,
  unrestricted double radiusX, optional unrestricted double radiusY,
 optional
  unrestricted double rotation, optional unrestricted double startAngle,
  optional unrestricted double endAngle, optional boolean anticlockwise);
 
  with the following behavior:
  - if radiusY is omitted, it's the same as radiusX
  - if rotation is omitted, it's equal to 0
  - if startAngle is omitted, it's equal to 0
  - if endAngle is omitted, it's equal to 0
  - if anticlockwise is omitted, it's equal to false

 We could do this, sure. How much do people want something like this? Does
 anyone else think it's a good idea?


  startAngle and endAngle always refer to points on the circle. If they
  coincide, the end result is a full circle (with a closepath).

 We can't change arc()'s behaviour. ellipse() should behave as close to
 arc() as possible, for sanity. (I wouldn't have introduced it at all, if
 there was some sane way to overload arc() to add radiusY and rotation. But
 there isn't, really.)


Yes.
However the spec should be clearer on what happens if the arc is 2 π for
arc and ellipse.
Chrome believes that case should have a 'closePath' which seems reasonable.
Maybe someone on that team can tell us if this was intentional.




 On Tue, 30 Apr 2013, Rik Cabanier wrote:
 
  I think the exception on negative radius should also be removed.

 What would a negative radius mean?


Either treat it as zero, or use the absolute value. Avoiding exceptions
will make web apps more robust.

Re: [whatwg] Should video controls generate click events?

On Wed, Aug 21, 2013 at 9:11 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:

 On Tue, Aug 20, 2013 at 3:46 PM, Silvia Pfeiffer
 silviapfeiff...@gmail.com wrote:
  On Wed, Aug 21, 2013 at 8:32 AM, Tab Atkins Jr. jackalm...@gmail.com
  wrote:
 
  On Tue, Aug 20, 2013 at 3:28 PM, Silvia Pfeiffer
  silviapfeiff...@gmail.com wrote:
   IMHO, the example that Philip provided in http://people.opera.com/~**
   philipj/click.html http://people.opera.com/~philipj/click.html is
 not
   a
   realistic example of something a JS dev would do.
 
  Um, why not?  Clicking on the video to play/pause is a useful
  behavior, which things like the Youtube player do.  Since video
  elements don't generally do this, it seems reasonable that an author
  could do pretty much exactly what Philip shows in his demo.
 
 
  YouTube has their own controls for this, so Philip's example does not
 apply.
 
  What I'm saying is that the idea that the JS developer controls
 pause/play
  as well as exposes video controls is a far-fetched example.

 Yes, Youtube has their own controls.  They have long-standing branding
 that makes it worthwhile for them to roll their own.

 Why would I want to roll my own, though, when all I want is to add
 click-to-play/pause?  That seems like a lot of difficult make-work.


Indeed. As a JS dev you make a choice: either you roll your own, or you
don't.

If you roll your own, you write the JS to handle the clicks from the
controls and do video.pause() and video.play() yourself.

If you don't roll your own, you write video controls and you expect the
browser to handle pausing/playing. You don't do what Philip's demo (
http://people.opera.com/~philipj/click.html) does: handle pause and play
toggling in JS. Because the browser already does that for you.

This is why I am saying: Philip's example is not a typical use case. It
only happens when the developer made the choice to roll their own, but the
user activates the default controls (e.g. through the context menu) as
well. This can't happen on YouTube, because YouTube hide away the context
menu on the video element. It may happen elsewhere (though I've just tried
videoplayer.js and sublime video player and jwplayer and all of them have
their video controls on top of the browser-provided ones, so you can't even
get to them). It's this far-fetched use case that the patch is addressing.

However, the patch has a wider implication: namely that the User agent will
suppress all user interaction events from the browser-provided video
controls. I.e. if the user clicks on the play button, no click event is
raised on the video element and the elements that the video element is in.
That's what Edward is objecting to - and I agree.

My suggestion was therefore to limit the patch to only apply when something
that the JS developer did not prepare for happens: namely the user
activates the browser-provided video controls (through the context menu).

Hope that clarifies my position.

Cheers,
Silvia.

Re: [whatwg] Should video controls generate click events?

On Tue, Aug 20, 2013 at 7:55 PM, Silvia Pfeiffer
silviapfeiff...@gmail.comwrote:

 On Wed, Aug 21, 2013 at 9:11 AM, Tab Atkins Jr. jackalm...@gmail.com
 wrote:

  On Tue, Aug 20, 2013 at 3:46 PM, Silvia Pfeiffer
  silviapfeiff...@gmail.com wrote:
   On Wed, Aug 21, 2013 at 8:32 AM, Tab Atkins Jr. jackalm...@gmail.com
   wrote:
  
   On Tue, Aug 20, 2013 at 3:28 PM, Silvia Pfeiffer
   silviapfeiff...@gmail.com wrote:
IMHO, the example that Philip provided in
 http://people.opera.com/~**
philipj/click.html http://people.opera.com/~philipj/click.html is
  not
a
realistic example of something a JS dev would do.
  
   Um, why not?  Clicking on the video to play/pause is a useful
   behavior, which things like the Youtube player do.  Since video
   elements don't generally do this, it seems reasonable that an author
   could do pretty much exactly what Philip shows in his demo.
  
  
   YouTube has their own controls for this, so Philip's example does not
  apply.
  
   What I'm saying is that the idea that the JS developer controls
  pause/play
   as well as exposes video controls is a far-fetched example.
 
  Yes, Youtube has their own controls.  They have long-standing branding
  that makes it worthwhile for them to roll their own.
 
  Why would I want to roll my own, though, when all I want is to add
  click-to-play/pause?  That seems like a lot of difficult make-work.
 

 Indeed. As a JS dev you make a choice: either you roll your own, or you
 don't.

 If you roll your own, you write the JS to handle the clicks from the
 controls and do video.pause() and video.play() yourself.

 If you don't roll your own, you write video controls and you expect the
 browser to handle pausing/playing. You don't do what Philip's demo (
 http://people.opera.com/~philipj/click.html) does: handle pause and play
 toggling in JS. Because the browser already does that for you.

 This is why I am saying: Philip's example is not a typical use case. It
 only happens when the developer made the choice to roll their own, but the
 user activates the default controls (e.g. through the context menu) as
 well. This can't happen on YouTube, because YouTube hide away the context
 menu on the video element. It may happen elsewhere (though I've just tried
 videoplayer.js and sublime video player and jwplayer and all of them have
 their video controls on top of the browser-provided ones, so you can't even
 get to them). It's this far-fetched use case that the patch is addressing.

 However, the patch has a wider implication: namely that the User agent will
 suppress all user interaction events from the browser-provided video
 controls. I.e. if the user clicks on the play button, no click event is
 raised on the video element and the elements that the video element is in.
 That's what Edward is objecting to - and I agree.



Thank you, this is the clarification I was looking for in my previous
inquiries. Given this explanation, I absolutely object to any change (such
as this) that will effectively cripple the interaction programmability of
video elements. There are commercial products that have been developed
and are being developed that rely on the ability to add listeners for
events that occur on the video controls as part of reach and engagement
data collection, eg. Did the user click the Play button on the video and
watch it all the way through? Did they click Pause? Did they drag to seek?

Rick

Re: [whatwg] Should video controls generate click events?

2013-08-20 Thread Bob Lund

From: Silvia Pfeiffer [silviapfeiff...@gmail.com]
Sent: Tuesday, August 20, 2013 5:05 PM
To: Bob Lund
Cc: Tab Atkins Jr.; WHAT Working Group Mailing List; Edward O'Connor
Subject: Re: [whatwg] Should video controls generate click events?

On Wed, Aug 21, 2013 at 8:57 AM, Bob Lund 
b.l...@cablelabs.commailto:b.l...@cablelabs.com wrote:

On 8/20/13 4:46 PM, Silvia Pfeiffer 
silviapfeiff...@gmail.commailto:silviapfeiff...@gmail.com wrote:

On Wed, Aug 21, 2013 at 8:32 AM, Tab Atkins Jr.
jackalm...@gmail.commailto:jackalm...@gmail.comwrote:

 On Tue, Aug 20, 2013 at 3:28 PM, Silvia Pfeiffer
 silviapfeiff...@gmail.commailto:silviapfeiff...@gmail.com wrote:
  IMHO, the example that Philip provided in http://people.opera.com/~**
  philipj/click.html http://people.opera.com/~philipj/click.html is
not
 a
  realistic example of something a JS dev would do.

 Um, why not?  Clicking on the video to play/pause is a useful
 behavior, which things like the Youtube player do.  Since video
 elements don't generally do this, it seems reasonable that an author
 could do pretty much exactly what Philip shows in his demo.

YouTube has their own controls for this, so Philip's example does not
apply.

What I'm saying is that the idea that the JS developer controls pause/play
as well as exposes video controls is a far-fetched example.

What about a Web page that uses JS to control pause/play/etc based on
external messages, say from a WebSocket? The sender in this case acts as a
remote control.

The patch applies only to the case where the user interacts with 
browser-provided controls on the video element. In your case, the JS dev would 
probably not use the @controls attribute on the video element, since the 
playback controls comes from the remote.

BobThere still might be controls provided by the UA. I can use remote and TV 
controls as I choose. Should we presume what an app developer might want to do? 
What problem is being solved by making this restriction?/Bob

Silvia.

Re: [whatwg] Should video controls generate click events?

2013-08-20 Thread Peter Occil



On Tue, Aug 20, 2013 at 3:28 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:

IMHO, the example that Philip provided in http://people.opera.com/~**
philipj/click.html http://people.opera.com/~philipj/click.html is not a
realistic example of something a JS dev would do.


I'm afraid this example doesn't work well in Firefox and Google Chrome.  It 
affects not only the video itself but also the browser-provided controls, 
and in Firefox it seems to interfere with those controls.  I think that at 
most the click-to-play behavior should only affect the video itself, not the 
buttons or other controls (for this to work, this would require hit-testing 
to see if the video or a control was clicked, and only override the default 
behavior if the video itself was clicked; the hit-testing, though, will be 
browser-specific and may require defining a new method in the spec).  In 
this way, the video controls would remain unaffected or be specially handled 
in a different way.  Another -- less realistic --solution may be to define 
new event handlers (videoclick? videopauseclick?) that only affect parts 
of the video element and not the entire video element.


--Peter

Re: [whatwg] Forms-related feedback

2013-08-20 Thread TAMURA, Kent




On Sat, Jul 13, 2013 at 6:39 AM, Ian Hickson i...@hixie.ch wrote:

On Wed, 9 Jan 2013, TAMURA, Kent wrote:

On Wed, Nov 21, 2012 at 7:51 AM, Ian Hickson i...@hixie.ch wrote:
 On Fri, 7 Sep 2012, TAMURA, Kent wrote:
 
  * For date, datetime, datetime-local, month, time, week, the
  attribute returns a string in a field. If a field is text-editable,
  it should return user-editing string like email and number.  If a
  field has a fixed localized date/time string chosen by a date/time
  picker, the attribute should return the localized string. [...]
 
  - We can enable text field selection APIs for email, number, and
  other types



 How would this work when the control isn't a text control? I don't
 understand. For example, consider a date control that is actually
 three separate text fields (year month day); how do you envisage the
 selection API working and how would rawValue help with this?



I think it's ok that rawValue doesn't work with form controls without
any text. One of use cases of rawValue would be to handle user input
errors.  I think non-text form controls should be clever enough to avoid
bad user input. For example, users can't set bad values to
input[type=range].



I still don't understand how this would work. You suggest that it should
work for type=date, but how? What happens when it's mutated by script,
for instance? I really don't understand the purpose here or how it would
work to achieve that purpose.


As for type=date, rawValue should return what a user see. Value set by
script
or not doesn't matter.
In Google Chrome, rawValue should return a localized date value such
as 21/08/2013.

I saw some questions/requests of a way to get a localized date string in
crbug.com and stackoverflow.com.  One of reasons one wanted to get it was
that there are no ways for script to get localized date format used in
type=date.
One wanted to get the format to use consistent date format in a web page,
another
wanted to get the format to focus on specific field in type=date (Note that
a type=date
instance in Google Chrome contains multiple focus targets.)

As for type=number, I heard a web author wanted to get invalid value typed
by
a user in order to show friendly error message without HTML interactive
form validation.



 On Tue, 11 Sep 2012, TAMURA, Kent wrote:

  Yes, I'd like to enable selection API for at least type=email and
  type=number.  All of their existing implementations are text fields.
  I haven't seen a request to suport selection API for type=email,
  etc.. However lack of selection API looks a defect to me.

 Why does the page need to touch the selection?



It must be same as input[type=text].
e.g.
   - A page author wants to select the whole value or nothing of an email
 form control when it gets focus.



Why is that a valid thing for a page to be doing? The browser should take
care of doing that, not the page. If the page does it, it'll be different
on each page and the user will get confused.


We can't force it.  Web authors do what they want.

https://code.google.com/p/chromium/issues/detail?id=263910#c3
This is an actual case.  I talked with him, and he said datalist didn't
work
in his case because he wanted to show images on choices.



   - A user entered an email address with unacceptable domain name.
 A page author wants to move the caret to the beginning of the domain
name.



How is that possible in the case of a custom e-mail widget where the
e-mail address isn't shown, but a user picture and name is shown instead?


I think rawValue isn't necessary in such UI. However all of existing
type=email
implementation is a text field.



--
TAMURA Kent
Software Engineer, Google

Re: [whatwg] Should video controls generate click events?

2013-08-20 Thread Robert O'Callahan

On Wed, Aug 21, 2013 at 11:18 AM, Rick Waldron waldron.r...@gmail.comwrote:

 Firefox actually implements click-to-play video by default. It's
 unfortunate and all video interaction projects that I've worked on
 directly or consulted for have been forced to include video surface click
 - event.preventDefault() calls to stop the behaviour.


Just to be clear, we only do click-to-play when the controls attribute is
set. So if that's causing problems for you, I guess you want most of our
built-in controls but not all of them?

Rob
-- 
Jtehsauts  tshaei dS,o n Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
*

Re: [whatwg] Should video controls generate click events?