Re: [whatwg] Canvas lack of drawString method
David Hyatt wrote: and then the API would be something like: drawText(y-coord of baseline, barchart, myText) I like this idea :-) At the risk of overcomplicating, vertical text is a common requirement for graphs and charts. If this is simpler to implement than the arbitrary text rotation case, is it worth having a way of saying the baseline is vertical rather than horizontal? Or would this be a job for fitTextToPath()? Gerv
[whatwg] Suggestion: Event-source to be DOM based rather than an HTML element
Dear Sir/Madam,I am writing this mail because I've recently studied your Web Applications 1.0 specifications, and have found a rather strange point in it. As the 'event-source' element is embedded in the Markup itself, it makes little sense. It is for the simple reason that, assuming there be more than one event-source handlers, then one has to be defined first and another one, next. In that case, there is no significance of the order in which the 'even-source' elements appear. Here are my suggestion:
SEMANTIC PROBLEMSIn HTML, or any markup for that purpose, the order of elements has a special significance. As for example, if there are two p tags, then th once coming first is rendered first in the inline display and the one coming next is displayed next (the relative positioning can be changed using CSS is a different matter, however).
HTML as such is a static language (without a scripting backend). Hence, dynamic elements within the flow of an HTML element, isn't proper semantics.SUGGESTION (CLIENT SCRIPTING OBJECT)To keep the semantics in place, I'd recommend that that the event-source be rather specified as a _javascript_/DHTML object, just as the XMLHttpRequest object is. A major part of event-source seems to fulfill the the shortcomings of XMLHttpRequest object. In the same way the object 'event-source' can have following methods/properties:
Property: src (same as for the HTML element)Method: connect (initiate the initial connection)Method: disconnect (disconnect the connection or abort)Property: onrecieve (function call. execute function when data is recieved)
ADVANTAGES (BANDWIDTH LOAD REDUCTION)At the same time, this method also will enable developers to reduce the bandwidth load on both sides by allowing the script to initiate and abort the connection as and when required. There are various probelms when doing so with an HTML element.
ADVANTAGES(COMPATIBILITY)On top of it, it is more backword compatible than the HTML method. A simple check(withclientscripting) would be:window.eventSourceIn case _javascript_/Browserscripting is disabled, nothing would ever be executed and event-source can't really be used without a Client-scripting technology.
There is no way to check it using HTML methods, and if we were to specify one, we still lose support of all the browsers that exist as of now. At the same time, older browsers may not recognize the event-source element and display something that would either obstruct the flow of the document or it may abruptly quit.
ADVANTAGES(ADHERENCE TO EXISTING STANDARDS)Also, if it is completely scripting based, it can even be validated using current W3 validation services. (Since WHATWG currently doesn't have a validation service, more developers will be encouraged if they can use existing DTDs while at the same time using new technologies)
This is just a suggestion and hence I haven't worked much on it, but am ready to contribute more inputs, once this suggestion finds higher attention. I hope to hear from your side.Rohan Prabhu,Vadodara,
India-- {Ro}h(a)[n]_-_[P]{rab}(h)u
[whatwg] Suggestion: Event-source to be DOM based rather than an HTML element
Dear Sir/Madam,I am writing this mail because I've recently studied your Web Applications 1.0 specifications, and have found a rather strange point in it. As the 'event-source' element is embedded in the Markup itself, it makes little sense. It is for the simple reason that, assuming there be more than one event-source handlers, then one has to be defined first and another one, next. In that case, there is no significance of the order in which the 'even-source' elements appear. Here are my suggestion:
SEMANTIC PROBLEMSIn HTML, or any markup for that purpose, the order of elements has a special significance. As for example, if there are two p tags, then th once coming first is rendered first in the inline display and the one coming next is displayed next (the relative positioning can be changed using CSS is a different matter, however).
HTML as such is a static language (without a scripting backend). Hence, dynamic elements within the flow of an HTML element, isn't proper semantics.SUGGESTION (CLIENT SCRIPTING OBJECT)To keep the semantics in place, I'd recommend that that the event-source be rather specified as a _javascript_/DHTML object, just as the XMLHttpRequest object is. A major part of event-source seems to fulfill the the shortcomings of XMLHttpRequest object. In the same way the object 'event-source' can have following methods/properties:
Property: src (same as for the HTML element)Method: connect (initiate the initial connection)Method: disconnect (disconnect the connection or abort)Property: onrecieve (function call. execute function when data is recieved)
ADVANTAGES (BANDWIDTH LOAD REDUCTION)At the same time, this method also will enable developers to reduce the bandwidth load on both sides by allowing the script to initiate and abort the connection as and when required. There are various probelms when doing so with an HTML element.
ADVANTAGES(COMPATIBILITY)On top of it, it is more backword compatible than the HTML method. A simple check(withclientscripting) would be:window.eventSourceIn case _javascript_/Browserscripting is disabled, nothing would ever be executed and event-source can't really be used without a Client-scripting technology.
There is no way to check it using HTML methods, and if we were to specify one, we still lose support of all the browsers that exist as of now. At the same time, older browsers may not recognize the event-source element and display something that would either obstruct the flow of the document or it may abruptly quit.
ADVANTAGES(ADHERENCE TO EXISTING STANDARDS)Also, if it is completely scripting based, it can even be validated using current W3 validation services. (Since WHATWG currently doesn't have a validation service, more developers will be encouraged if they can use existing DTDs while at the same time using new technologies)
This is just a suggestion and hence I haven't worked much on it, but am ready to contribute more inputs, once this suggestion finds higher attention. I hope to hear from your side.Rohan Prabhu,Vadodara,
India-- {Ro}h(a)[n]_-_[P]{rab}(h)u
Re: [whatwg] Canvas lack of drawString method
Alfonso Baqueiro wrote: The canvas component is very promising, but the lack of drawString method could be a great error for its success, this lack is a huge limitation, how could you resolve this problem? Just for a bit of fun, I created a demo to show how it is already possible to render text on canvas. This technique has certainly got many limitations and could never be made as good as a native implementation, but it works Firefox, Opera and Safari. http://lachy.id.au/dev/2006/10/canvas-text -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Canvas lack of drawString method
Hi David,
I think it is very important to be able to determine the rendered size
of the text. Otherwise, there is no reliable way to make sure things do
not overlap. Also, some kinds of applications (flash-like effects,
labels expressing weight or distance, WYSIWYG text editors) may require
variable font sizes or styles.
What do you think about
context.textStyle = barchart; // style by reference
context.textStyle = { // set style directly
font-size: 8px,
font-family: Monaco, monospace
}
context.drawText(x,y,string);
context.getFontAscent();
context.getFontDescent();
context.getFontLeading();
context.getTextWidth(string);
Best regards,
Stefan
David Hyatt wrote:
I think a drawText method would be extremely useful.
Rather than specifying stylistic information explicitly (via a font
object), I'd use a special parenthetical pseudo-element. thus allowing
the author to specify the style as for any other element on a page
something like this...
canvas::canvas-text(barchart)
{
font-size: 8px;
font-family: Monaco, monospace;
}
and then the API would be something like:
drawText(y-coord of baseline, barchart, myText)
and letter-spacing/word-spacing would work, small-caps would work,
text-shadow would work, etc. etc.
fitTextToPath might be an interesting API too.
dave
([EMAIL PROTECTED])
On Oct 23, 2006, at 4:07 PM, Stefan Haustein wrote:
Gervase Markham wrote:
Stefan Haustein wrote:
I think drawElement(elem) opens up a whole new can of worms:
- how would an application determine the size of the text box?
- where is the baseline position, needed for exact axis label
positioning?
- there are probably issues with dynamically calculated text values
- code with lots of cross references to elements will be difficult
to read
- it needs to be specified whether css properties are inherited
from the parent element of elem.
- how much horizontal/vertical space is drawElement permitted to
use for rendering?
The answer to all of these things is that the browser renders all
the elements in the page as it would if the canvas were not
supported and the alternate content were being used. It then
basically screenshots the area corresponding to the element (yes, I
know this needs careful definition) and draws that into the canvas.
I do not see how your statement answers any of my questions except
from the last one. You can specify some CSS constraints, but how do
you determine the actual rendering height of a text box with a
specific width? How do you determine the pixel position of the
baseline? The cross reference and the dynamic text issues are not
addressed at all.
Like I said, we want to leverage the browser's deep and complex
knowledge of text rendering as much as possible, and just take the
resulting pixel output as it would be shown to the user.
- the implementation in actual browsers may be more complex than it
seems because of problems with internal data structures for
rendering hints and implicitly introducing the ability to render
the same element twice.
- what happens with contained plugins, canvas elements,
self-references... all this stuff needs to be well-defined
Indeed. I know it's easy to state and there are edge cases. But we
could put limits on it like e.g. no plugins, no object, and still
have something very useful for rendering text.
So I assume we agree that the element rendering proposal would still
need significant specification work and is probably much more
difficult to implement. The element rendering approach may make
working with bulk text simpler, but this case is already handled
quite fine by HTML outside the Canvas element. By asking for too
much, we may end up with nothing at all.
Andrew has provided a clear and simple proposal that can easily be
implemented without too much consideration of side effects. Putting
labels on maps, precise text positioning, starwars-like 3d scrolling
text, labels for game characters or in physics simulations, all the
stuff that could only be done in a canvas element, is trivial to
implement with the drawText() approach, but seems much more complex
or impossible with the element rendering approach.
Moreover, drawElement() would not solve the drawText problem for
non-browser environments such as Rhino.
How are we anticipating canvas might be used in a non-browser
context?
Canvas and some other parts of the spec (e.g. connections) may make a
lot of sense for Javascript outside of the browser context. This may
be outside of the scope of WHATWG, but if we can take out some
building blocks and use them somewhere else, this is at least a sign
of good and modular API design.
Best regards,
Stefan
