Re: [whatwg] proposed canvas 2d API additions
On 2006-04-26, Ian Hickson i...@hixie.ch wrote: On Mon, 24 Apr 2006, Vladimir Vukicevic wrote: Assuming nobody has any problem with: boolean isPointInPath(in float x, in float y); ...then I'll add that to the spec when you reply to this mail. Sure, isPointInPath sounds fine. Added. We can always add isPointInStrokedPath if we ever want to bother with that (which is where the ...Fill bit came from in my API, because the region covered by a stroked path and that covered by a filled path are different, even though testing for a hit against a filled region would by far be the common case). We can also call the other one isPointOnPath(), if we want to keep the method names reasonably short. I'm not sure we'll ever need to add it, though. Getting people to click on a line is generally silly. We do have a need of isPointOnPath() for editing Bezier lines interactively (on a font editing interface). When people want to add a new point on an already existing curve, we have to know if the click is on path. besides, we need double click on the curve to pickup the whole path and then drag on the line to move the whole path. So I dig up a 2006 post... Of course it's hard to get people click on a line precisely. But we can check isPointOnPath for an 5x5 square instead to make the operation easier. Doing point on curve in javascript is painful. And since checking isPointInPath() already need to detect the on edge case, this shouldn't be too much a burdern on the browser developers. So please conside add the isPointOnPath() call to the function.
Re: [whatwg] Dates and coordinates in HTML5
In message 49a5d6e8.5070...@lachy.id.au, Lachlan Hunt lachlan.h...@lachy.id.au writes [Resending this to the list now that the problem that prevented it from accepting any mail has been fixed.] [Likewise] Andy Mabbett wrote: Use-cases for machine-readable date mark-up are many: as well as the aforesaid calendar interactions, they can be used for sorting; for searching (find me all the pages about events in 1923 — recent developments in Yahoo's YQL searching API (which now supports searching for microformats): http://developer.yahoo.net/blog/archives/2009/01/yql_with_microformats .html have opened up a whole new set of possibilities, which is only just beginning to be explored). They can be mapped visually on a SIMILE http://simile.mit.edu/timeline/ or similar time-line. Neither of those appear to be using BCE dates, non-Gregorian calendars or imprecise dates. It's not clear how they are use cases for the features that you are asking for. I haven't tried using Yahoo to search for BCE or imprecise dates (I don't have the coding sills to construct such a search), but I don't see why that wouldn't work, since both are supported and published in hCard/hCalendar and ISO8601, and Yahoo say they support hCard/hCalendar, which use ISO8601. Incidentally, the time element and BCE dates are both supported by the microformat parser Swignition: http://buzzword.org.uk/swignition/ If Yahoo aren't supporting searches for such non-Gregorian dates, that's probably because there is currently no method of marking them up. Do we really have to illustrate use cases in action, before we can develop the technology which allows them to be demonstrated exists? On the other hand, this SIMILE timeline has dates which are BCE, imprecise and non-Gregorian: http://simile.mit.edu/timeline/examples/dinosaurs/dinosaurs2.html I note that you make no comment about the other use-cases I gave. -- Andy Mabbett
Re: [whatwg] proposed canvas 2d API additions
On Sat, Feb 28, 2009 at 8:38 PM, JustFillBug mozbug...@yahoo.com.au wrote: On 2006-04-26, Ian Hickson i...@hixie.ch wrote: On Mon, 24 Apr 2006, Vladimir Vukicevic wrote: We can always add isPointInStrokedPath if we ever want to bother with that (which is where the ...Fill bit came from in my API, because the region covered by a stroked path and that covered by a filled path are different, even though testing for a hit against a filled region would by far be the common case). We can also call the other one isPointOnPath(), if we want to keep the method names reasonably short. I'm not sure we'll ever need to add it, though. Getting people to click on a line is generally silly. (Or maybe we could add a convertStrokeToPath() function, which replaces the current path with a path representing the outline of what you'd get if you stroked the current path, and then use isPointInPath on it.) We do have a need of isPointOnPath() for editing Bezier lines interactively (on a font editing interface). [...] Doing point on curve in javascript is painful. And since checking isPointInPath() already need to detect the on edge case, this shouldn't be too much a burdern on the browser developers. So please conside add the isPointOnPath() call to the function. What makes it painful? If you're only using Beziers, it doesn't seem too hard to approximate the curves as line segments and then calculate distances from that. http://philip.html5.org/demos/canvas/bezier-approx.html is fairly straightforward (and a much more accurate version shouldn't be much more complex) and can detect when your mouse is near a curve. (But if this is a common problem, it would indeed be nicer if the canvas API provided the functionality instead of forcing you to reimplement it.) -- Philip Taylor exc...@gmail.com
Re: [whatwg] Dates and coordinates in HTML5
On Sat, Feb 28, 2009 at 4:39 PM, Andy Mabbett a...@pigsonthewing.org.uk wrote: Do we really have to illustrate use cases in action, before we can develop the technology which allows them to be demonstrated exists? Though I admit it seems ass-backwards until you get it, the answer is yes, you do have to provide such use-cases. More precisely, you have to show that such an addition/change to the language would be of significant help to authors, where significant is somewhat vague and depends on the difficulty of the change. It just so happens that one of the easiest ways to show that something would help authors is showing that authors are currently hacking around the problem, and that their efforts could be made significantly easier with language support. That establishes that there *is* a problem in need of solving, so that we don't spend time on insignificant problems when there are more important things to do. It also shows what authors think the solution is shaped like, so we don't end up implementing something that doesn't actually help authors in their real use-cases. http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_the_spec.3F ~TJ
