[whatwg] Canvas feedback (various threads)

[Charles Pritchard]

On Sun, 3 Oct 2010, Charles Pritchard wrote:
>> Having worked quite awhile with WebApps APIs, Canvas included, I've
>> concluded that HTML can be implemented within the web stack.
>> It's my firm belief that the Web Apps specifications can and should be
>> proven complete.
> If by "complete" you mean "self-hosting", then: why? That seems like a
> very arbitrary goal.
>
> If not, what do you mean?
I intended that section 4, "The elements of HTML", with minor 
exceptions, should be
displayable with Canvas, and operable with a minimal canvas+webapps profile.

Exceptions include, but are not limited to: script, iframe, embed, 
object, and for some time, video and audio.

There are minimal instances in the current spec, which prohibit this.

For those instances, there are additional use cases, outside of 
'completion',
mainly having relevance to accessibility (a11y).

>> 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.
> Good lord no. This is merely a prioritisation issue. I'm sure we'll add
> lots of metrics over time.
But I'm not requesting a discussion on various aspects of fonts.

I'm pointing to the non-availability of one particular metric, as a 
blocking issue in my ability to keep
a string of text on the same baseline.
> The problem is that anytime we add anything to canvas, implementors get so
> excited that they drop what they're doing and implement it (in some cases,
> overnight!). This takes resources away from other features. If we're to
> get the whole platform to improve, we need to make sure that everything
> gets a chance to be implemented. This means we can't just be adding stuff
> to canvas all the time.
I'm no newbie, I understand and appreciate your oversight on html 5 
implementations,
your flexibility in exploring new standards (like WebSRT), and your 
conscientious approach
to managing a living document.

You're making a slippery slope argument, I don't think it fits:
I'd asked for one property to be added to the specs document; as an 
extension
of the textBaseline attribute already in the document.

It's implementation-time is minimal.

It's part of my approach, to give weight to implementation time and scope.

>> We need to expose baseline positioning somewhere
> Why? What's the use case? Implementing a browser isn't a sane use case,
> sorry.
Continuing that discussion is not sane...

Exposing the baseline position of inline data would allow for 
fine-grained positioning
of elements and better control of interactivity with text.

Currently, I can't use fillText with two separate font sizes, and 
underline them.

The textBaseline attribute gets me close, but it's insufficient.

>> Nobody wants to see another vendor-specific extension; can we try to
>> form an agreement on this, so we can avoid that?
> On the contrary, we _do_ want to see vendor-specific extensions. That's
> how we get implementation experience and how the Web improves.
>
> Standardisation is the penultimate stage in a feature's development, after
> studying author practices, experimental implementations in vendor-specific
> features, and studying use cases, and ahead only of the final convergence
> of browser implementations

Your enthusiasm for the "final convergence" is charming.

I made a poor generalization. Most of us do not want to see 
vendor-specific extensions which stick.
Example:
moz..transform = webkit..transform = transform = ...;