[whatwg] HTML 5: Wording of license link type is too narrow
Hello, The scope of the license link type in section 4.12.3 seems too narrow to me. It's presently described like this: Indicates that the current document is covered by the copyright license described by the referenced document. I think the word copyright should be removed, allowing other types of intellectual property licence to be specified as well. As a use case, take for example a piece of documentation that is Apache-licensed: pThis piece of useful documentation may be used under the terms of the a rel=license ref=http://www.apache.org/licenses/LICENSE-2.0;Apache License, Version 2.0/a. Please note that Example#8482; is a trademark of Example.com Enterprises./p The license link not only refers to copyright law, but also trademark law and patent law. On a related note, should the copyright keyword really be a synonym for license? They seem to have distinct purposes to me: meta name=copyright content=Copyright 2009-2010 Example.com Enterprises link rel=license href=http://www.apache.org/licenses/LICENSE-2.0; type=text/html Thank you, Dave
Re: [whatwg] Referer header sent with a ping?
On Feb 1, 2008 2:45 PM, Julian Reschke [EMAIL PROTECTED] wrote: Ian Hickson wrote: This would make it easy to protect against unwanted ping-originated requests (one could configure server or set up application firewall to filter pings), and URL in a ping wouldn't have to contain copies of page's URL and href. What do people think of this idea: We make Referer always have the value PING. Referer takes a relative reference, or a URI. Not a good idea. Indeed :( http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 We add two headers, X-Ping-From which has the value of the page that had the link, and X-Ping-To which has the value of the page that is being opened. You don't need any new headers. Define a content type, and send the information you want to transmit in the request body. We continue to send all cookie and authentication headers. What do people think? Would this address all the issues raised? BR, Julian
Re: [whatwg] Some video questions
Your movie showed as a grey square and hanged Internet Explorer and I had to log out. Was that intended? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Sent: Friday, February 01, 2008 12:02 AM To: 'WHAT working group' Subject: Re: [whatwg] Some video questions Inserting a [SWF] file into a video element is similar to inserting an HTML file that happens to have a link to video: sure, it links to a video, but it does a billion other things too - it isn't in itself the video. I hear you. FWIW, here's a QuickTime Movie that's also not in itself the video: http://wiltgen.net/tempy/badder.mov Please pardon the content. It's what I had handy from some previous testing. :^)
Re: [whatwg] Canvas line styles comments
Some comments on the newly modified version: The lineCap attribute defines the type of endings that UAs shall place on the end of lines. - it seems weird to use shall, since this is the only place in the spec (except the list of RFC2119 keywords) that uses it. The other line* properties don't try define to conformance requirements like that (e.g. they say The lineWidth attribute gives the width of lines which is only informative), so I can't tell whether the lineCap one is trying to be a requirement. The lineJoin attribute defines the type of corners that that UAs will place where two lines meet. - s/that that/that/ A join exists at any point in a subpath shared by two consecutive pairs of lines. - should be two consecutive lines or a consecutive pair of lines. In addition to the point where the join occurs, two additional points are relevant to each join: the corners found half the line width away from the join point, perpendicular to the two lines joining at the join point. - I'm not sure what that means. Nothing can be perpendicular to both of the two lines (unless they're parallel). For each line, there are the two corners half the line width away from the join point perpendicular to that line, but that gives four corners in total. I suppose it'd be alright to say there's four corners, and then talk about the two corners on the outside of the join since the meaning of outside is obvious enough even if it's not defined (at least when the lines aren't parallel). A filled triangle connecting ... with the third point of the triangle being the point of the join itself (where the lines touch on the inside of the join), must be rendered at all joins. - the inside of the join bit seems unhelpful and unclear (since it's not the opposite of the outside of the join) - it'd be better just to say ... being the join point, must be ..., since that's the term used earlier for that point. The round value means that a filled arc connecting the two corners on the outside of the join, with the diameter equal to the line width and the origin at the point of the join, must be rendered at joins. - if I was being pedantic (which I am) I'd say there's two possible arcs connecting those two corners (one clockwise, one anticlockwise), so it should specify which one is meant. But I don't know how to easily say that, and an implementor would have to be silly to do it the wrong way, so maybe a precise definition isn't needed. Should lineJoin='round';moveTo(0,0);lineTo(100,0);lineTo(0,0);stroke() draw a semicircle at (100,0) pointing rightwards? There is no outside of the join there, so the spec doesn't say what should happen. The miter value means that a filled four-sided polygon must be rendered at the join, with two of the lines being the perpendicular edges of the joining lines, ... - the miter-polygon lines aren't the perpendicular edges - they're only half of each edge (between the join point and the outside corners). It's probably easier to define the polygon's points (being the join point, the two outside corners, and the point where the two continuated outside edges intersect). -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] Canvas patterns, and miscellaneous other things
On 31/01/2008, Ian Hickson [EMAIL PROTECTED] wrote: I've made toDataURL() return data:, if it's faced with a 0-pixel image. It's arbitrary, but I guess it represents the image, at least! That makes the Note: When trying to use types other than image/png, authors can check if the image was really returned in the requested format by checking to see if the returned string starts with one the exact strings data:image/png, or data:image/png;. now incorrect. The non-image/png format might be unsupported, but someone might be drawing a 0-pixel image and they'll get back something that doesn't start with data:image/png[,;]. It does seem pretty weird to return text/plain content when asked for an image. But I guess it's safer than e.g. returning an empty string, since it won't get misinterpreted as a relative address when people do img.src=canvas.toDataURL(), and I can't think of a better idea. User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations. (See ...#hardwareLimitations.) Does anything say that those limitations should be imposed by throwing an exception, and not by e.g. returning null or aborting the entire script? I'm assuming that the DOM Bindings for JS spec will define how 'undefined' really means 'null' Hmm, I can imagine 'undefined' converted to a DOMString becoming the string undefined. (That's at least what document.createTextNode(undefined) does). But I can just assume for now it's meant to work like null. -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] Canvas line styles comments
A pair cannot be consecutive unless it follows after another pair, which would be irrelevant anyway. The rounding arc should be chosen so that it is not contained in the convex hull of the stroke path segments terminated at the points where the arc begins. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philip Taylor Sent: Saturday, February 02, 2008 8:48 PM To: Ian Hickson Cc: WHATWG Subject: Re: [whatwg] Canvas line styles comments Some comments on the newly modified version: [snip] A join exists at any point in a subpath shared by two consecutive pairs of lines. - should be two consecutive lines or a consecutive pair of lines. [snip] The round value means that a filled arc connecting the two corners on the outside of the join, with the diameter equal to the line width and the origin at the point of the join, must be rendered at joins. - if I was being pedantic (which I am) I'd say there's two possible arcs connecting those two corners (one clockwise, one anticlockwise), so it should specify which one is meant. But I don't know how to easily say that, and an implementor would have to be silly to do it the wrong way, so maybe a precise definition isn't needed. Should lineJoin='round';moveTo(0,0);lineTo(100,0);lineTo(0,0);stroke() draw a semicircle at (100,0) pointing rightwards? There is no outside of the join there, so the spec doesn't say what should happen. [snip] -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] Canvas arcTo
On 31/01/2008, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 2 Jul 2007, Philip Taylor wrote: If the point (x2, y2) is on the line defined by the points (x0, y0) and (x1, y1) then the method must do nothing, as no arc would satisfy the above constraints. - why would no arc satisfy the constraints? If P0, P1, P2 are collinear and non-coincident, then (I think) any of the (infinitely many) circles which have the given radius and touch tangential to the line P0-P2 will satisfy the constraints (i.e. being tangential to P0-P1 at some point and to P1-P2 at some point). The idea is to just take the two (infinite) lines that are defined by the points (end at P1, cross P0 and P2), and draw a circle with the given radius between them. When the lines are the same line (i.e. P0-P1 is parallel to P1-P2) then no circle with a finite non-zero radius can touch the line tangentially at more than two points, since for each half of the circle, every point has a different tangent, and the two points on opposite sides of the circle are tangents to parallel but distinct lines unless the radius is zero. No? The circle can't touch tangentially at two distinct points, but nothing said there had to be two distinct points. There just had to be one point on the circle tangential to one line, and one point tangential to the other line, so they could easily be equal points. About the updated specification: the method must add a point (xinf;, yinf;) - s/inf;/infin;/ the infinite line that crosses the point (x0, y0) and ends at the point (x1, y1) - it could be clearer to say half-infinite line. (It seems the technical term is ray or half-line, but those aren't as clear.) -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] Canvas arcTo
On Sat, 2 Feb 2008, Philip Taylor wrote: The circle can't touch tangentially at two distinct points, but nothing said there had to be two distinct points. IIRC it used to say another point. It's certainly more explicitly now. About the updated specification: the method must add a point (xinf;, yinf;) - s/inf;/infin;/ the infinite line that crosses the point (x0, y0) and ends at the point (x1, y1) - it could be clearer to say half-infinite line. (It seems the technical term is ray or half-line, but those aren't as clear.) Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas line styles comments
On 02/02/2008, Kristof Zelechovski [EMAIL PROTECTED] wrote: The rounding arc should be chosen so that it is not contained in the convex hull of the stroke path segments terminated at the points where the arc begins. I believe I can see the idea there, but I can't quite tell what that phrase means about terminating. The contained within also seems inaccurate, because e.g. lineWidth=100;moveTo(0,0);lineTo(1,0);lineTo(1,1) would result in a convex hull that doesn't contain either arc, though I think it'd be alright if said does not intersect instead. A possible alternative that seems simpler and (I think) correct (except in the special parallel case): The rounding arc should be chosen so that if it was closed, it would not contain the join point. -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] Canvas line styles comments
You considered the convex hull of the original lines to get that paradox; I had the stroke path segments in mind. (Stroke path segments are the path equivalent of the stroked curve when the stroke operator is not allowed and must be replaced by the fill operator). Each line corresponds to two parallel stroke path segments; two of them intersect and the other two get joint with an arc. One of the possible arcs is in the convex hull of those stroke path segments. While talking intersection instead of convexity is mathematically simpler, convexity is what is intended, intersection may be a technicality. I think the specification should specify the intention and not the technical means wherever possible. Cheers, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philip Taylor Sent: Saturday, February 02, 2008 10:25 PM To: Kristof Zelechovski Cc: WHATWG; Ian Hickson Subject: Re: [whatwg] Canvas line styles comments On 02/02/2008, Kristof Zelechovski [EMAIL PROTECTED] wrote: The rounding arc should be chosen so that it is not contained in the convex hull of the stroke path segments terminated at the points where the arc begins. I believe I can see the idea there, but I can't quite tell what that phrase means about terminating. The contained within also seems inaccurate, because e.g. lineWidth=100;moveTo(0,0);lineTo(1,0);lineTo(1,1) would result in a convex hull that doesn't contain either arc, though I think it'd be alright if said does not intersect instead. A possible alternative that seems simpler and (I think) correct (except in the special parallel case): The rounding arc should be chosen so that if it was closed, it would not contain the join point. -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] Referer header sent with a ping?
On Fri, 1 Feb 2008, Julian Reschke wrote: Ian Hickson wrote: This would make it easy to protect against unwanted ping-originated requests (one could configure server or set up application firewall to filter pings), and URL in a ping wouldn't have to contain copies of page's URL and href. What do people think of this idea: We make Referer always have the value PING. Referer takes a relative reference, or a URI. Not a good idea. Interesting. I see two ways forward here. One would be to redefine Referer to remove the relative URI thing, since, to my knowledge at least, nobody uses it. The other is that we can define the magic value to be #PING instead, since that's a non-conforming Referer value right now. Would that work for people? dolphinling? Darin? We add two headers, X-Ping-From which has the value of the page that had the link, and X-Ping-To which has the value of the page that is being opened. You don't need any new headers. Define a content type, and send the information you want to transmit in the request body. The idea, as others have noted, is to keep the entity body empty so as to avoid any issues with servers that ignore the headers and process the body (which is relatively common). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Referer header sent with a ping?
Ian Hickson wrote: Interesting. I see two ways forward here. One would be to redefine Referer to remove the relative URI thing, since, to my knowledge at least, nobody uses it. That's IMHO not sufficient reason to remove it. It's not broken. The other is that we can define the magic value to be #PING instead, since that's a non-conforming Referer value right now. Would that work for people? dolphinling? Darin? It's not conforming, so are you suggesting to use a non-conforming value? Me confused. Could you please state what problem you are trying to solve, and why it needs to involve the Referer header? We add two headers, X-Ping-From which has the value of the page that had the link, and X-Ping-To which has the value of the page that is being opened. You don't need any new headers. Define a content type, and send the information you want to transmit in the request body. The idea, as others have noted, is to keep the entity body empty so as to avoid any issues with servers that ignore the headers and process the body (which is relatively common). Are you saying it wasn't a good idea to use POST after all because of these risks? BR, Julian
Re: [whatwg] Referer header sent with a ping?
Perhaps this has been suggested before, but another option is to use a new verb, such as PING, instead of GET when making the request. Servers unaware of the ping attribute will likely ignore this verb, mitigating the request-forgery attack vector. Adam On Feb 2, 2008 2:13 PM, Julian Reschke [EMAIL PROTECTED] wrote: Ian Hickson wrote: Interesting. I see two ways forward here. One would be to redefine Referer to remove the relative URI thing, since, to my knowledge at least, nobody uses it. That's IMHO not sufficient reason to remove it. It's not broken. The other is that we can define the magic value to be #PING instead, since that's a non-conforming Referer value right now. Would that work for people? dolphinling? Darin? It's not conforming, so are you suggesting to use a non-conforming value? Me confused. Could you please state what problem you are trying to solve, and why it needs to involve the Referer header? We add two headers, X-Ping-From which has the value of the page that had the link, and X-Ping-To which has the value of the page that is being opened. You don't need any new headers. Define a content type, and send the information you want to transmit in the request body. The idea, as others have noted, is to keep the entity body empty so as to avoid any issues with servers that ignore the headers and process the body (which is relatively common). Are you saying it wasn't a good idea to use POST after all because of these risks? BR, Julian
Re: [whatwg] Canvas line styles comments
On 02/02/2008, Kristof Zelechovski [EMAIL PROTECTED] wrote: You considered the convex hull of the original lines to get that paradox; I had the stroke path segments in mind. (Stroke path segments are the path equivalent of the stroked curve when the stroke operator is not allowed and must be replaced by the fill operator). Each line corresponds to two parallel stroke path segments; two of them intersect and the other two get joint with an arc. One of the possible arcs is in the convex hull of those stroke path segments. If the two lines are very short, their stroke paths will (if I understand correctly) look like .-. | | | | | | .-|-*---. '-|-|---' | | | | '-' where the * is the join point and the short lines are the two parallel stroke path segments of each line. Then the convex hull is nearly a square rotated by 45 degrees, like .-. /| |'- / | | '- /| |'-. .-|-*---. '-|-|---' '. | |.-' '-.| |_.-' '-' and so an arc with radius lineWidth/2 from the rightmost point going clockwise to the upmost point will not be contained entirely within that nearly-square. So neither arc is within the convex hull. -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] Referer header sent with a ping?
Ian Hickson wrote: On Fri, 1 Feb 2008, Julian Reschke wrote: Ian Hickson wrote: What do people think of this idea: We make Referer always have the value PING. Referer takes a relative reference, or a URI. Not a good idea. Interesting. I see two ways forward here. One would be to redefine Referer to remove the relative URI thing, since, to my knowledge at least, nobody uses it. The other is that we can define the magic value to be #PING instead, since that's a non-conforming Referer value right now. Would that work for people? dolphinling? Darin? If (X-)Ping-From/Ping-To are present, why is a referer needed at all? I'd say just leave it out. If not, #PING works for me. Cookies and authentication headers I'm ambivalent about; no one's made a persuasive case either way for them, and I haven't looked myself. We add two headers, X-Ping-From which has the value of the page that had the link, and X-Ping-To which has the value of the page that is being opened. (sorry for the double copy, Hixie, forgot to CC the list the first time) -- dolphinling http://dolphinling.net/
Re: [whatwg] Some video questions
Your movie showed as a grey square and hanged Internet Explorer and I had to log out. Was that intended? It's an ordinary QuickTime Movie and works fine. The content is irrelevant, but it shows that the files one will embed with video often won't actually contain any video media. This will be the case with every metafile format (.asx, .sdp, etc.), and nearly all modern container formats (.mov, .asf, .swf) that can reference media that lives elsewhere. -- Charles
Re: [whatwg] several messages
On Fri, 18 Jan 2008, Philip Taylor wrote:
Maybe the desired properties are:
- drawImage(img) onto a displayed canvas should look the same as
the original img, regardless of whether the image has gamma etc.
- toDataURL should return the same raw pixel data as getImageData, at
least for image/png (though other formats might make that impossible),
for consistency.
- drawImage(toDataURL()) should have no effect.
Made explicit.
I'd also like:
- fillStyle = 'rgb(r, g, b)'; fillRect(...); getImageData returns
exactly [r, g, b, 255].
mainly because that makes it possible to write test cases that use
getImageData to check the results.
That was already explicit.
function FillCload(data, x, y) { ... } - should be function
FillCloud(data, x, y) { ... }.
That error was replaced with function AddCload(data, x, y) { ... } - s/a/u/
Fixed.
On Sun, 20 Jan 2008, Henri Sivonen wrote:
[...]
On Sun, 20 Jan 2008, Darin Adler wrote:
[...]
On Sun, 20 Jan 2008, L. David Baron wrote:
[...]
On Sun, 20 Jan 2008, Maciej Stachowiak wrote:
[...]
I didn't see anything in this discussion that I could apply to the spec,
but please do let me know if there's anything in the canvas requirements
that should change (or be added).
Cheers,
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
