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 < > brun...@partner.samsung.com> wrote: > >> >> From: Ryosuke Niwa <ryosuke.n...@gmail.com> >> Date: Tuesday, August 20, 2013 1:59 PM >> To: Bruno de Oliveira Abinader <brun...@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 < >> brun...@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 > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev