[webkit-dev] Add support for CSS3 text-decoration* properties

Bruno Abinader brunoabinader at gmail.com
Thu Aug 2 21:43:25 PDT 2012


Hi again,

On Thu, Aug 2, 2012 at 6:10 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> Does the spec require to return new values in the computed style of
> text-decoration property without authors specifying new text-decoration
> properties and values?
>
> If not, then using text-decoration property is probably better because it'll
> only affect those authors who have used new properties and values.
>
> - Ryosuke
>

If I got it right you are asking if it is necessary to designate
values for all longhand properties from "text-decoration". The answer
is no, based on what the specification says:

"This property is a shorthand for setting ‘text-decoration-line’,
‘text-decoration-color’, and ‘text-decoration-style’ in one
declaration. Omitted values are set to their initial values. A
‘text-decoration’ declaration that omits both the
‘text-decoration-color’ and ‘text-decoration-style’ values is
backwards-compatible with CSS Levels 1 and 2."

Speaking about it, I did finished a refactory on the "text-decoration"
property that now becomes a shorthand (thus removing the necessity of
having "-webkit-text-decoration" property), like CSS3 specifies.
Though I haven't upstreamed it to Bugzilla yet, it is fully
backwards-compatible with previous CSS specifications. I do have,
however, a small set of questions to ask before publishing it for
review:

1. I had a full layout test run and noticed a few test failures, but
not exactly failures. The reason they failed is because the computed
style expected something like "text-decoration: underline" and now it
produces "text-decoration-line: underline". Is it ok to update the
test expectations on these cases? IMO It doesn't makes sense having a
shorthand property behaving like a longhand one anymore.

2. The current WebKit implementation of "text-decoration" actually
parses the "blink" value, but does nothing with it later. On my
implementation I preserved the same behavior, but in order to avoid
complex parsing techniques I decided to treat it as a 4th bitwise
value of "text-decoration-line", which does not contemplates the
"blink" value on the CSS3 specification, but makes no harm since
nothing is done with it anyways.

Said this, I am going to suggest a change on the CSS3 specification of
"text-decoration", related to the "blink" value. But first, we need to
ask ourselves if this is really needed, it seems that only Firefox and
Opera implements this, and to not implement it satisfies the
checkpoint 3.3 of WAI-UAAG (
http://www.w3.org/TR/UAAG/guidelines.html#tech-on-off-blinking-text ).
I imagine two scenarios for this:

2.1 Abolish usage of "blink" value, since the same behavior is
achievable with rgba() alpha animation.

2.2 Make "blink" become a shorthand, not just a valid value inside
"text-decoration" property, so "text-property" acceptable values
become like this:
<text-decoration-line> || <text-decoration-style> ||
<text-decoration-color> || <text-decoration-blink>

Where "text-decoration-blink" would accept either "blink" or "fixed"
values, for example. In this approach, "text-decoration-blink" could
be even a shorthand property itself covering more complex instructions
like time delay between blinks, whether or not blinking animates or
only changes states from visible to hidden, etc.

I really ask for feedback on the questions above and appreciate your feedback!

Best regards,

-- 
Bruno de Oliveira Abinader


More information about the webkit-dev mailing list