[webkit-dev] Fwd: Proposal: Move CSS3 Text Decoration properties out of CSS3_TEXT feature flag / remove vendor prefix

[Ryosuke Niwa]

On Tue, Aug 20, 2013 at 4:20 PM, Ryosuke Niwa <> wrote:

> On Tue, Aug 20, 2013 at 4:11 PM, Bruno de Oliveira Abinader <
> bruno.d at partner.samsung.com> wrote:
>
>>
>>    From: Ryosuke Niwa <ryosuke.niwa at gmail.com>
>> Date: Tuesday, August 20, 2013 1:59 PM
>> To: Bruno de Oliveira Abinader <bruno.d at partner.samsung.com>
>> Subject: Re: [webkit-dev] Proposal: Move CSS3 Text Decoration properties
>> out of CSS3_TEXT feature flag / remove vendor prefix
>>
>>    On Tue, Aug 20, 2013 at 10:08 AM, Bruno de Oliveira Abinader <
>> bruno.d at partner.samsung.com> wrote:
>>
>>>  The CSS Level 3 Text Decoration specification [1] has recently changed
>>> status to "W3C Candidate Recommendation", which means it has been widely
>>> reviewed and is ready for implementation (so we can expect no further
>>> syntax changes). So far the following properties from that specification
>>> are implemented behind a feature flag (CSS3_TEXT):
>>>
>>>  -webkit-text-decoration (shorthand)
>>> -webkit-text-decoration-line
>>> -webkit-text-decoration-style
>>> -webkit-text-decoration-color
>>> -webkit-text-underline-position
>>>
>>>  Please notice all of these properties are implemented with vendor
>>> prefix on WebKit. There are other properties implemented behind CSS3_TEXT
>>> feature flag that do not belong to CSS Level 3 Text Decoration
>>> specification and thus are not going to be handled in this proposal. Said
>>> this, I would like to propose the following changes:
>>>
>>
>>  I'd like to know how well these properties work well in contenteditable
>> regions.  Namely, when a user edits text with text decoration color, line
>> style, etc... would it properly preserve them?
>>
>> I believe this requires some discussion – currently the HTML Editing APIs
>> [1] specification does not provide methods for modifying text decoration's
>> style and color. That said, these prefixed properties implementations are
>> not currently handled in EditingStyle – but if you paste HTML code
>> containing these on an editable element, it would preserve the properties
>> information (I could write a test in editing/ to verify that).
>>
>
> We should probably do that and make sure it's not completely broken.
>
>      1) Move the aforementioned properties out of CSS3_TEXT feature flag
>>> - currently it is enabled by default on EFL/GTK ports, must obtain
>>> acknowledgement from all other ports maintainers.
>>>
>>
>>  How complete and compatible is our implementation with other browsers
>> and with respect to the W3C specification?  Does W3C have tests?  If so, do
>> we pass all of them?
>>
>>
>>  In terms of completeness, we are not providing support for all
>> properties specified in CSS Level 3 Text Decoration specification, but for
>> the ones we have implemented, those are full implementations (with
>> exception of "blink" value from text-decoration-line which is valid but
>> ignored, as in CSS 2.1 text-decoration implementation in WebKit).
>>
>>  Speaking of compatibility, besides WebKit, Gecko implements
>> text-decoration shorthand unprefixed, text-decoration{-line,-style-color}
>> prefixed (-moz-), and does not implement text-underline-position (which is
>> only implemented on Trident). The syntax for values is the same for all
>> implementations, and does so for visual expectations/computed styles.
>>
>>  As for W3C tests, according to [2] there are currently no tests for
>> latest release, but on the nightly unstable [3] I could find at least 12
>> tests, all passing for now (w/ exception of text-decoration-line-014 which
>> expects text to blink).
>>
>
> Do we have those tests imported into LayoutTests?  If we haven't, we
> should do that.
>
>>   2) Remove the vendor prefix from these properties – probably the only
>>> side-effect that I see is that the current computed style from
>>> text-decoration (which is implemented according to CSS 2.1 specification)
>>> would change to support the shorthand implementation (as currently
>>> implemented on Blink), thus requiring us to modify some layout test results
>>> that depends on text-decoration computed style.
>>>
>>
>>  Do EFL and GTK ports not want to support the prefixed version?  It
>> seems desirable to keep both the prefixed version and the unprefixed
>> version.
>>
>>
>>  I'd feel comfortable with whatever decision the port maintainers
>> decide, though un-prefixing these properties would match Blink's
>> implementation.
>>
>
> Blink takes a completely different approach to prefixes than WebKit. While
> I personally like their approach, I don't think there is any benefit or
> consensus to match what Blink does.
>
> - R. Niwa
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130820/2a74072f/attachment.html>