[whatwg] Canvas feedback (various threads)
chuck at jumis.com
Sun Oct 3 15:44:37 PDT 2010
On 8/11/2010 1:35 PM, Ian Hickson wrote:
> On Tue, 10 Aug 2010, Charles Pritchard wrote:
>> I've worked on a substantial amount of code dealing with text editing.
>> At present, the descent of the current font has been the only
>> I feel that using Canvas to implement HTML5/CSS provides a quality proof
>> of the completeness of the 2D API.
> The 2D API isn't complete by a long shot, there's no difficulty in proving
> that. It's not trying to be complete.
Having worked quite awhile with WebApps APIs, Canvas included, I've
concluded that HTML can be implemented within the web stack.
CSS, Canvas and DOM interfaces are sufficient to provide an HTML and SVG
user agent, and WebApps APIs associate well with the host environment.
To this date, there have been very issues that have blocked me from
implementing such agents.
It's my firm belief that the Web Apps specifications can and should be
proven complete. Hypertext and DOM manipulation are well tested, parsing
has been well documented. We should hold HTML5 elements to the same
standard: the WebApps API should be sufficient to implement HTML UI
elements. Canvas contexts are the de facto standard for painting to a
screen. If an HTML element or an SVG element can not be produced within
the Canvas API, the WebApps spec is deficient.
Currently, there's a deficieny in the interoperability of these
standards: Web Fonts, HTML Forms, CSS line boxes, and SVG text, in
relation to baseline positioning. It's not a "canvas" issue; it simply
came to light while I was using "canvas".
I'm certain that you've not heard a browser vendor tell you that
returning additional font data would be costly, or take away valuable
resources. I'm concerned that the issue is being avoided because it
originated from a project you disagree with; and has biased your
judgment of additional use cases or possible remedies.
We need to expose baseline positioning somewhere; we typically have
start positions by checking directionality and getting the compute style
of the css box. There are some items in range selectors as well as
TextMetrics that can help in returning the positioning of glyphs within
a string. What we don't have are standard ways to access baseline
metrics. It's a one-way process, it is not currently exposed as a
scripting API. Lets fix it.
John Daggett has given me some constructive feedback; he let me know
that a string may be composed of several fonts, and that the condition
may effect metrics. This is why, he believes, returning baseline metrics
on a given font is not a complete solution. He recommended revising
TextMetrics in canvas. I provided an alternative solution, getting the
computed style of a string within an inline element. That is... using
document.createElement('span').textContent = 'complex string'; And
gathering the computed value of that span.
Some issues in the interoperability of Web Fonts and Canvas text APIs
still exist. I recommend implementing both solutions, adding baseline
metrics to TextMetrics in canvas,
and returning baseline attributes for CSS inline elements, as a computed
This approach would avoid the interop issue I mentioned, and return
reliable information to scripting APIs across CSS, HTML and Canvas.
That information, about baseline positioning of text, could then be used
for various use cases. The computed information is already available to
browser vendors, and would be inexpensive to expose to existing APIs.
Nobody wants to see another vendor-specific extension; can we try to
form an agreement on this, so we can avoid that?
More information about the whatwg