[whatwg] Canvas feedback (various threads)

[Charles Pritchard]

  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
>> deficiency.
>>
....
>> 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 
style.

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?

-Charles