Re: [whatwg] dashed lines in Canvas
One possible use case of canvas are technical drawings. For even extremely simple drawings - think of a circle with centerlines and a diameter dimension - dash-dotted lines are needed as well as dimension text. I would like to see both (dashed lines and text) in future canvas versions. -- Stefan Goessner Garrett Smith wrote: On 5/21/07, Ian Hickson [EMAIL PROTECTED] wrote: On 5/19/07, Garrett Smith [EMAIL PROTECTED] wrote: Consider doing any diagramming. It's a necessary feature. Not really. For straight lines it's pretty trivial to do today anyway (either by drawing actual dashed lines or faking it with a pattern), and in general you can use other styles of lines instead of actual dashes. Now of course I'm not saying that this is always a good alternative, but it's not a blocker. If someone actually does this, then we might have to reconsider. http://ditchnet.org/canvasuml/ Someone actually did. I haven't tried using canvas for UML for publishing. If I want to make a diagram published, I'd use the above strategies. Trying to make UML Diagrams in the browser, current options are: 1) ASCII 2) Image 3) HTML + CSS + Images A UML widget for a bugzilla plugin could be useful, so long as it was simple and quicker to use than making ascii lines. Garrett -- Ian Hickson
Re: [whatwg] Canvas 2d methods
Vladimir Vukicevic wrote: Even without using |with|, why not just create a simple JS wrapper for the context object that can have return-this or any other desired semantics? This is possible, but I consider the canvas implementation as too performance critical to slow it down by such a wrapper. I could live with it, if it were to use only for some upgrading time. This would avoid a change that would have some apps require canvas 2D 2.0 or some such, and require authors to do version checks to see which version of canvas is supported -- and still write old code for quite some time. You are arguing here generally against any possible extension of the API in the future. Please note, that this minor change of the API does not affect existing code. Adding a different way to do the same things that can be done now without much benefit in simplicity or efficiency doesn't seem useful. Some users on this list -- me included -- and a certain part of the future user base of the canvas element may see a benefit in familiar coding style which they might call simplicity. The benefit in efficiency might be significant due to optimizing interpreters, but is measurable only with at least one implementation. Canvas supports multiple contexts for a reason; if there are compelling arguments for a complete rev of the 2D API, then a new context can be introduced to support that. Great feature of Canvas to support multiple contexts. I would welcome the introduction of such a new context. -- Stefan Gössner http://goessner.net
Re: [whatwg] Canvas 2d methods
Benjamin Joffe wrote: Each of the methods defined for the canvas 2d context return null. I think it would be very convenient if instead they would return a reference to the 2d context for that canvas. This would allow writing such code as ctx.fill().stroke() or ctx.moveTo(0,0).lineTo(10,10). This is how many of the native string and array methods work in javaScript. I strongly agree and second this. -- Stefan Gössner http://goessner.net
Re: [whatwg] Canvas 2d methods
Ian Hickson wrote: On Sat, 1 Jul 2006, Andrew Fedoniouk wrote: In prototype based languages it is almost impossible to implement 'with' effectively in the given notation. ctx.moveTo(0,0).lineTo(10,10); is more effective. In some circumstances - in times. Why is it more effective for JS? see http://yuiblog.com/blog/2006/04/11/with-statement-considered-harmful/
Re: [whatwg] Canvas 2d methods
Ian Hickson wrote:
On Sun, 2 Jul 2006, Stefan Gössner wrote:
Ian Hickson wrote:
On Sat, 1 Jul 2006, Andrew Fedoniouk wrote:
In prototype based languages it is almost impossible to implement
'with' effectively in the given notation.
ctx.moveTo(0,0).lineTo(10,10);
is more effective. In some circumstances - in times.
Why is it more effective for JS?
see
http://yuiblog.com/blog/2006/04/11/with-statement-considered-harmful/
I'm familiar with this, but it doesn't seem to be relevant for this case
since all the method names are predefined and well-known.
If I understand this correctly, in the following code
var a=1, f=function(x){}, X={b:2,c:3};
with(X) {
a=4;
f(b);
c=5;
}
*every* variable a,b,c,f in the with-block must be dynamically checked,
if it *either* belongs to the global namespace *or/and* is a member of
X. As all variables in the block are affected, this sounds inherently
inefficient.
Despite of this fact, if every method of an object X
var X = {
a: function(){ return this;}
b: function(){ return this;}
c: function(){ return this;}
};
returns that object, we can code
with (X) {
a(); b(); c();
}
as well as more elegantly in my opinion
X.a().b().c();
So existing code -- previously using methods returning nothing --
shouldn't be affected and I can see no other drawback when adding
'return this' to every method. Modern javascript libraries (e.g. jQuery)
seem to follow the mindset:
if an object method has no explicit return value, then return the object
itself in order to allow call chains.
Re: [whatwg] Canvas 2d methods
as well as more elegantly in my opinion X.a().b().c(); The latter, IMHO, is semantically bogus. But that's just a matter of opinion, of course. hmm ... ctx.scale(2,1) .rotate(Math.PI/4) .translate(4,-6); illustrates a sequence of manipulations semantically very well, doesn't it?
Re: [whatwg] Mathematics in HTML5
Michel Fortin wrote: Something that's definitely missing for elementary algebra is a construct capable of representing a fraction. So I propose that HTML 5 adds fractions, and only fractions. Yes please, that would be a great start. It is quite cheap and a reasonable way to get a certain amount of user feedback.
Re: [whatwg] Mathematics in HTML5
James Graham wrote: Is math really a core feature? Yes, absolutely .. the upcoming microlearning / nanolearning units inevitably need math. That's a really particular use case which is hardly representative of the web as a whole. As sad as it is, 99.9% of authors have no use for maths (otherwise all these problems would have been solved long ago). I wouldn't reduce the people from all schools and universities worldwide to only 0.1%. But obviously I have to accept the view -- or better the fact -- that today's web is much more commercial than scientific or educational. Maths is certainly less of a core feature for most authors than vector graphics and WHATWG aren't trying to re-implement SVG despite the fact that it too has no obvious IE6 compatibility story, poor CSS integration and various other problems. I wish, that WHATWG would have a similar motivation to offer lightweight math capabilities parallel to MathML, as they were motivated to support vector graphics via the canvas element parallel to SVG. Nowhere in the WHATWG document does it say that they're going to try and fix everything. Maybe .. You have to choose your battles and, personally, I agree with the idea that, if the proponents of CSS-based maths want to work in the structure of the WHATWG, they should demonstrate the feasibility of their approach using a microformat. Given the constraints under which they have chosen to operate it should be possible to do this without any difficulties. The microformat based approach has several advantages too, e.g. instant implementation in existing HTML4 UAs (a new markup language would require changes to the parser). This should allow the language to evolve as it encounters real-world needs so, if and when it is formally standardized, it will be a better product than typically results from an standardization-before-implementation approach. Assuming the microformat solution will work -- and that it will work is already proven by George's implementation -- why should there be a reason then in one, two, three years to substitute the well working microformats with a new set of math related elements?
Re: [whatwg] Mathematics in HTML5
Anne van Kesteren wrote: The core features of an XML vocabulary should require the use of elements from ONLY ONE NAMESPACE. Is math really a core feature? Yes, absolutely .. the upcoming microlearning / nanolearning units inevitably need math.
Re: [whatwg] Mathematics in HTML5
I would highly appreciate a lightweight, pragamatic solution for doing math on the web in a convenient way. This solution could parallel MathML the same way as Canvas parallels SVG. And that does not necessarily mean, it should be javascript or Latex based -- though it might be. Personally I like a minimal vocabulary, which allows declarative math markup and integrates well with HTML. The proposal from George, refined by Michel currently being discussed here, is definitely a good start. Even if it ends only in a 80% solution, it presumeably will have only 20% implementation cost -- compared to MathML -- if at all. And these 80% would be more, than the target audience in engineering and economics really needs. As an example for successfully creating pure HTML+CSS based math formulas using the great concept of XML-Maiden see here for an example, http://goessner.net/learn/tm/exercises/exm/2005-07-06-II/ which was authored by students using a Wiki/Latex style markup. So a proof of concept to convert Latex style markup to HTML+CSS *and back* exists and works very well. http://goessner.net/articles/wiky/ Math in HTML5 would help a lot and might lead to even better tools, widgets or whatever. Stefan Goessner --- [EMAIL PROTECTED] http://goessner.net
