Hi again, On Thu, Aug 2, 2012 at 6:10 PM, Ryosuke Niwa <rn...@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev