W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

Re: [whatwg] 2D canvas feature proposal: text decoration

From: Justin Novosad <junov@google.com>
Date: Wed, 21 Aug 2013 15:54:01 -0400
Message-ID: <CABpaAqTWJq+-zrGj-Rnme1XLbDyp-2m5Bpnx8ubuo1QLr9SJWw@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: WHAT Working Group <whatwg@whatwg.org>
On Tue, Aug 20, 2013 at 6:32 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 18 Apr 2013, Justin Novosad wrote:
> >
> > This is a really simple proposal to add support for text decorations in
> > 2D canvas contexts.
> >
> > IDL to add to interface CanvasDrawingStyles:
> >
> > attribute DOMString textDecoration;
> >
> > It would support all the same modes as the 'text-decoration' CSS
> > property (except inherit), and default would be 'none'.
>
> That's anything but simple. :-)
>
> The CSS text-decoration model is actually quite complex. Also, there have
> been many proposals to split 'text-decoration' into sub-properties, so it
> is only going to get more complicated from there.
>
> What's your use case? That is, when do you need to underline text?
>

Take a web app that presents a view of an arbitrarily large document (map,
spreadsheet, word processor document, drawing, etc).
Using the DOM to represent such documents for the purpose of rendering can
be quite inefficient.  The two basic approaches are:
 a) Put the entire document into the DOM and incur massive layout and style
recalculation penalties.
 b) Put only the visible part of the document in the DOM and incur frequent
layout and style recalculation penalties, as you scroll around

With 2D canvas, the app can manage its own document model, often in ways
that perform better by several orders of magnitude.
There is increasing pressure from app developers for us to improve the text
feature set in 2D canvas so that so that apps can be ported to 2D canvas.
Text decoration can theoretically be drawn directly by the application by
using font metrics to compute decoration positions, but this is often very
complex to do correctly in a truly portable way.


>
> On Thu, 18 Apr 2013, David Dailey wrote:
> >
> > You know, I'm not quite sure why we have text in canvas at all. It's not
> > really text you know -- it's just a bunch of pixels. You can't select
> > it, you can't copy it to the clipboard, it's not accessible without a
> > bunch of effort that authors generally don't use. It's generally illegal
> > in most civilized places. Why not use SVG?
>
> Or, indeed, HTML.
>
>
> > It's got text decoration. Text is text. It's just that the more
> > conspiratorial and selfish of the browser vendors back when things were
> > being voted on seemed to push canvas since they already owned it and SVG
> > seemed "hard" and like they might have to learn something by way of
> > graphics in their corporate portfolios.
>
> That's not quite how it went down.
>
> There are times where you really need text in your canvas, e.g. if you
> want to label things in your Mandelbrot set viewer.
>
>
> On Sat, 20 Apr 2013, Nils Dagsson Moskopp wrote:
> >
> > That said, I suspect that anything that makes it easier to create text
> > in canvas can and will be used to create inaccessible interfaces. My
> > personal experience regarding web accessability is very frustrating 
> > authors generally do not care, even if they know about it.
> >
> > FYI, I have problems with low-contrast text, but at least I can correct
> > for that using user stylesheets. How would I do that with canvas text?
>
> You cannot (same as with text in a PNG).
>
>
> On Thu, 18 Apr 2013, Rik Cabanier wrote:
> >
> > I checked and the values in CanvasDrawingStyles don't correspond with CSS
> > values so it should be OK to turn them into enums.
>
> They're mostly just DOMStrings because I haven't gotten around to changing
> them. Changing strings to enums is risky (I could introduce bugs when
> doing so), so I tend to avoid doing so unless someone makes a specific
> explicit request for a specific property to be converted.
>
>
> On Fri, 19 Apr 2013, Justin Novosad wrote:
> >
> > That sounds OK. However, I would find it unfortunate to re-specify the
> > behavior of the property in the canvas 2d context spec, when we could
> > just spec it like 'font' by saying that it is interpreted the same way
> > as the corresponding CSS property. I think it is a good idea to keep in
> > sync with CSS whenever we can.
>
> Unfortunately, "just" is not really the right word here. The CSS inline
> box model, including the text-decoration part, are non-trivial. CSS has to
> deal with all kinds of things that we don't have to deal with in <canvas>,
> e.g. multiple baselines, multiple lines, etc.
>
>
> > FWIW, some of the other properties have good reasons for being
> > re-specified in the 2d canvas spec. For example, text alignment works
> > very differently in CSS vs. 2D canvas.
>
> Right. Underlining may fall into this bucket too.
>
>
> But before we can determine this, we need to determine what your use case
> is. What are you trying to do? Why?
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 21 August 2013 19:54:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC