[whatwg] 2D canvas feature proposal: text decoration
cabanier at gmail.com
Fri Apr 19 08:42:09 PDT 2013
yeah, except your proposed attribute matches a multi-value CSS property so
it should be a DOMString.
I think we can keep your proposal as-is. Breaking it into pieces doesn't
help an author that much.
We can decide later if we want to update the spec to move the other
attributes to enums.
On Fri, Apr 19, 2013 at 6:51 AM, Justin Novosad <junov at google.com> wrote:
> Rik, just to be clear, what you are suggesting is: use IDL enum in the
> spec, and implementors could use DOMString just the same.
> 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.
> 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.
> On Thu, Apr 18, 2013 at 10:51 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>> On Thu, Apr 18, 2013 at 6:38 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
>>> On Thu, Apr 18, 2013 at 4:42 PM, Rik Cabanier <cabanier at gmail.com>
>>> > On Thu, Apr 18, 2013 at 4:18 PM, Tab Atkins Jr. <jackalmage at gmail.com>
>>> > wrote:
>>> >> On Thu, Apr 18, 2013 at 3:40 PM, Rik Cabanier <cabanier at gmail.com>
>>> >> > I think that all enumerated DOMStrings in CanvasDrawingStyles should
>>> >> > move
>>> >> > to enums. This seems cleaner and have no compatibility issues.
>>> >> > However, if we keep them as DOMStrings, I agree that textDecoration
>>> >> > should
>>> >> > be one too.
>>> >> If they're trying to take on the value of CSS properties, they should
>>> >> absolutely *not* be enums. DOMStrings are the correct data type for
>>> >> that.
>>> > Why is that? There's no difference to an author.
>>> There is, the moment you have a multi-keyword value. ^_^
>>> (Also, it lets you more easily just defer to CSS for the
>>> interpretation of the property, rather than having to manually update
>>> the enum when we add new values.)
>> I checked and the values in CanvasDrawingStyles don't correspond with CSS
>> values so it should be OK to turn them into enums.
>> Only 'font' corresponds to an actual CSS value  and must not be
>> The proposed 'textDecoration' property would follow CSS so it *could* be
>> a DOMString (even though I feel the IDL is cleaner with enums).
More information about the whatwg