Re: canvas text: ctx.font='inherit'

On Sat, 1 Aug 2009, Simon Pieters wrote:
> On Sat, 01 Aug 2009 10:16:07 +0200, Ian Hickson <ian@hixie.ch> wrote:
> > On Sat, 1 Aug 2009, Simon Pieters wrote:
> > > On Sat, 01 Aug 2009 03:13:09 +0200, Boris Zbarsky <bzbarsky@mit.edu>
> > > wrote:
> > > > Ian Hickson wrote:
> > > >
> > > > So basically the behavior should be as Firefox now except:
> > > >
> > > > 1)  Treat inherit and initial as CSS syntax errors.
> > > > 2)  Always use "font: 10px sans serif" as the parent's font, not
> > > >      just when the <canvase> is outside of a DOM tree.
> > > >
> > > > Right?
> > > 
> > > ...except when using a relative unit (em, ex, %) or using a relative
> > > keyword (smaller, larger, bolder, lighter), in which case you inherit
> > > from the canvas element.
> > > 
> > > I think it's weird to sometimes inherit from the canvas element and
> > > sometimes use 10px sans-serif. If we're going to use 10px sans-serif,
> > > could we make the relative units relative to 10px sans-serif instead of
> > > the canvas element?
> > 
> > The spec never uses 10px sans-serif except as the default, unless I'm
> > mistaken.
> 
> Well, it's the initial value.
> 
> Consider an author who uses the text API to write some text, and doesn't 
> set the font. Then the author decides that the text is slightly too 
> small, and adds this line to his code:
> 
>    ctx.font = '110% sans-serif';
> 
> It seems reasonable to expect that this will make the text 10% bigger 
> than it was before.
> 
> I think this is the confusing part; it would be less confusing if the 
> initial value was inherited from the canvas element, or if relative 
> units and keywords are relative to 10px sans-serif.
> 
> Since you have explicitly made 10px sans-serif the initial value, and 
> banned the 'inherit' keyword, it is surprising that relative keywords 
> and units inherit from the element.

"initial" and "inherit" aren't really banned, they're just not part of the 
CSS 'font' value. They're part of CSS syntax itself. They're not more 
"banned" than, say, the trailing semicolon.

Anyway, I see what you're saying. I'm not really sure what to do about it. 
On the one hand we do want to be able to handle using the element's font, 
so that CSS can affect the style, but on the other we don't want that to 
be the default, since then CSS can have unexpected results. And we don't 
want to have special infrastructure for this kind of thing. I'm not really 
sure what else to do.


> > > <canvas dir> (or rather the canvas element's 'direction') affects 
> > > canvas text rendering. Maybe direction should be an attribute on the 
> > > 2d context instead for consistency with .font?
> > 
> > I considered that, but what would you make the default?
> 
> "ltr".

Wouldn't that be a pain for people in the rtl world?


On Sat, 1 Aug 2009, L. David Baron wrote:
> On Friday 2009-07-31 22:44 +0000, Ian Hickson wrote:
> > I've clarified that 'initial' and 'inherit' must be ignored. I haven't 
> > changed the spec to match either WebKit or Gecko here.
> 
> Two other notes on this issue:
> 
> (1) the summary text at the very start of the section says:
>   # Relative keywords and lengths are computed relative to the
>   # default font, 10px sans-serif.
> which disagrees with the text later on (which I think is the text
> that's currently under discussion).

Fixed, thanks.


> (2) If relative units continue to be relative to the canvas element,
> I think the definition of the font property's *getter* needs a
> little more clarification.  It currently says:
>   # On getting, the font  attribute must return the serialized form
>   # of the current font of the context (with no 'line-height'
>   # component).
> My understanding of the term serialization means that something
> specified as "200% sans-serif" would be returned in essentially that
> form; perhaps with changes to things like capitalization, spacing,
> and (if allowed, which it isn't in this case) the order of values --
> but that the values would not be *computed*.  This means that if
> a page:
>   (a) sets ctx.font = "200% sans-serif"
>   (b) changes the font size on canvas (or, alternatively, removes
>       the canvas from the document or inserts it into the document)
>   (c) sets ctx.font = ctx.font
> step (c) actually changes the state of the context (whereas step (b)
> does not).  If that's actually the case, I think the spec should be
> more explicit about both that (b) doesn't change the canvas context
> state and that (c) does (i.e., that ctx.font returns what was set,
> which may now compute to something different).

Fixed, thanks.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 4 August 2009 23:45:17 UTC