On May 15, 2007, at 6:36 PM, Ian Hickson wrote:
For the graphics context functions that take floating point values, I
think the specification should say what the expected behavior is for:
1) NANs
2) non-floating point values
3) missing parameters
b) excess arguments
1, 3, and b
On 16/05/07, Darin Adler [EMAIL PROTECTED] wrote:
On May 15, 2007, at 6:36 PM, Ian Hickson wrote:
For the graphics context functions that take floating point values, I
think the specification should say what the expected behavior is for:
1) NANs
2) non-floating point values
3)
On May 16, 2007, at 11:17 AM, Philip Taylor wrote:
Existing implementations seem to try converting the value into a JS
number, which will always give a floating-point value, and that's
just NaN if the conversion is not possible (e.g. from an object, or
undefined, or a string that can't be
Ian Hickson wrote:
...which would have to be defined, including error handling logic,
including how to handle corners, including how to do dot distribution to
have nice symmetry, etc, etc, etc. It's actually quite complex.
I believe that most of these issues can and should be left to the
On Fri, 21 Jul 2006, Henri Sivonen wrote:
I gather that a normative reference to the Porter�Duff paper is needed:
http://keithp.com/~keithp/porterduff/p253-porter.pdf
On Mon, 24 Jul 2006, L. David Baron wrote:
I've written tests for the 11 operators defined in the paper, plus a
test
On Wed, 16 May 2007, Darin Adler wrote:
1) NANs
2) non-floating point values
3) missing parameters
b) excess arguments
1, 3, and b now raise exceptions except if otherwise specified. I
haven't yet defined 2. I'm not sure what it should say.
I think that (2)
On 17/05/07, Ian Hickson [EMAIL PROTECTED] wrote:
I've changed the spec to say to ignore extra arguments and raise an
exception for too few arguments.
What happens when someone calls drawImage(image, dx, dy, dw)? That's
too few arguments for void drawImage(in HTMLImageElement image, in
float
On May 16, 2007, at 5:31 PM, Philip Taylor wrote:
On 17/05/07, Ian Hickson [EMAIL PROTECTED] wrote:
I've changed the spec to say to ignore extra arguments and raise
an exception for too few arguments.
What happens when someone calls drawImage(image, dx, dy, dw)?
That's too few arguments
n Tue, 15 May 2007, Maciej Stachowiak wrote:
Also, if it's meant to be required for implementations to allow
that, the spec should say so - it's not normally assumed that any JS
object with the right properties can be used anywhere that an
interface can be used.
Isn't it?
It's not that there's no plan. It's just that the plan is more along the
lines of we'll wait and maybe add it later rather than we'll add it
now, since there are workarounds and seemingly little demand.
Please let us know if you get any input on your blog post.
The utility of dashed strokes is
On Wed, 16 May 2007, ddailey wrote:
Observe the sparseness of the JavaScript code involved in
http://srufaculty.sru.edu/david.dailey/svg/clock.svg (working in IE, FF
Opera)
compared to the canvas solution someone posted the other day here.
In response to overwhelming feedback on this issue (especially in blogs,
forums, and mailing lists other than this one, like www-html and
public-html) I've removed the predefined classes. They're opaque again.
The main use cases for predefined classes can mostly be dealt with using
some of
On Fri, 8 Dec 2006, Michel Fortin wrote:
A document must not use a class defined in the Wiki on an element
other than the elements that the Wiki says that class name is allowed
on.
Does that mean that conformant documents can suddenly become
non-conformant because a class it uses
On Fri, 27 Apr 2007, Maciej Stachowiak wrote:
How about about adding a toggle() operation to classList? Adds the token
if not present, removes it if present. This would be useful for script
code that dynamically manipulates classes to cause style changes.
Added. Made it return a boolean
14 matches
Mail list logo
