Re: [webkit-dev] svns...@macosforge.org ?
On Wed, 2012-08-08 at 13:52 -0700, Adam Barth wrote: I noticed today that some patches are authored by svns...@macosforge.org: http://trac.webkit.org/search?q=svnsync Is this behavior expected? I guess this is a bug in one of the SVN commit hooks? Philippe ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] svns...@macosforge.org ?
Bill would know. On Tue, Aug 14, 2012 at 1:58 AM, Philippe Normand ph...@igalia.com wrote: On Wed, 2012-08-08 at 13:52 -0700, Adam Barth wrote: I noticed today that some patches are authored by svns...@macosforge.org: http://trac.webkit.org/search?q=svnsync Is this behavior expected? I guess this is a bug in one of the SVN commit hooks? Philippe ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New runtime setting: css3TextDecoration
On Aug 14, 2012, at 10:05 AM, Bruno Abinader brunoabina...@gmail.com wrote: A series of CSS3 text decoration properties implementations are currently on the works. These adds new properties which specifications are not finished yet, thus subject to changes. In order to avoid early web exposure, a new setting (aka. runtime flag) is going to be added: css3TextDecoration. As discussed with Julien, this flag provides easier maintenance than adding a whole new compile flag (as seen in https://bugs.webkit.org/show_bug.cgi?id=93863 ). This new runtime flag comes disabled by default and is going to affect parsing of the following CSS3 text-decoration properties: -webkit-text-decoration-line ( https://bugs.webkit.org/show_bug.cgi?id=90959 ) -webkit-text-decoration-style ( https://bugs.webkit.org/show_bug.cgi?id=90958 ) -webkit-text-decoration-color ( https://bugs.webkit.org/show_bug.cgi?id=91638 ) -webkit-text-decoration-skip ( https://bugs.webkit.org/show_bug.cgi?id=92801 ) And finally CSS3 specification support for text-decoration ( https://bugs.webkit.org/show_bug.cgi?id=92000 ) The bug related to this implementation is https://bugs.webkit.org/show_bug.cgi?id=93966 . Any comments will be kindly appreciated! I don't think it's appropriate to add settings for CSS features that are under development, for a number of reasons: * If we did this for every feature, we'd end up with hundreds of Settings. * Traditionally, Settings don't tend to get removed, resulting in an ever-accumulating number of Settings. * If your feature is protected by an ENABLE flag, vendors that want to ship release software can turn it off. * If developing your feature in trunk is so disruptive that you need a Setting to turn it off for most people, then perhaps you should be working on a branch up to the point where your feature is mostly usable. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New runtime setting: css3TextDecoration
I agree with Simon. Setting is a wrong mechanism to guard new features under development. On Tue, Aug 14, 2012 at 11:10 AM, Simon Fraser simon.fra...@apple.comwrote: On Aug 14, 2012, at 10:05 AM, Bruno Abinader brunoabina...@gmail.com wrote: A series of CSS3 text decoration properties implementations are currently on the works. These adds new properties which specifications are not finished yet, thus subject to changes. In order to avoid early web exposure, a new setting (aka. runtime flag) is going to be added: css3TextDecoration. As discussed with Julien, this flag provides easier maintenance than adding a whole new compile flag (as seen in https://bugs.webkit.org/show_bug.cgi?id=93863 ). This new runtime flag comes disabled by default and is going to affect parsing of the following CSS3 text-decoration properties: -webkit-text-decoration-line ( https://bugs.webkit.org/show_bug.cgi?id=90959 ) -webkit-text-decoration-style ( https://bugs.webkit.org/show_bug.cgi?id=90958 ) -webkit-text-decoration-color ( https://bugs.webkit.org/show_bug.cgi?id=91638 ) -webkit-text-decoration-skip ( https://bugs.webkit.org/show_bug.cgi?id=92801 ) And finally CSS3 specification support for text-decoration ( https://bugs.webkit.org/show_bug.cgi?id=92000 ) The bug related to this implementation is https://bugs.webkit.org/show_bug.cgi?id=93966 . Any comments will be kindly appreciated! I don't think it's appropriate to add settings for CSS features that are under development, for a number of reasons: * If we did this for every feature, we'd end up with hundreds of Settings. * Traditionally, Settings don't tend to get removed, resulting in an ever-accumulating number of Settings. * If your feature is protected by an ENABLE flag, vendors that want to ship release software can turn it off. * If developing your feature in trunk is so disruptive that you need a Setting to turn it off for most people, then perhaps you should be working on a branch up to the point where your feature is mostly usable. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Disjointed selection ranges
Hi WebKit, We are using embedded WebKit in our application, and we need to be able to use disjointed selection ranges for table editing. I was wondering whether anybody is currently working on implementing this, and is there any bug number for it? If not, I will attempt to implement it based on the approach described by Eric in [1] and [2]. Thanks, Shezan [1] https://bugs.webkit.org/show_bug.cgi?id=15921 [2] https://bugs.webkit.org/show_bug.cgi?id=23793 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New runtime setting: css3TextDecoration
I don't think it's appropriate to add settings for CSS features that are under development, for a number of reasons: * If we did this for every feature, we'd end up with hundreds of Settings. * Traditionally, Settings don't tend to get removed, resulting in an ever-accumulating number of Settings. ENABLE has a slightly better track of record but I don't think we should push back on runtime flags just because of that. Having tons of #ifdef's is a lot more worrying from my perspective, on top of not being able to build / test the feature before you toggle the flag on one platform (with all the surprises coming from platform differences when a port maintainer decide to do so). * If your feature is protected by an ENABLE flag, vendors that want to ship release software can turn it off. That's true, except that the original thread didn't mention any form of feature flag [1]. Nobody objected at the time and thus patches that implemented part of the spec arrived on bugzilla: prefixed but not protected by any flag. Due to the bar to landing such a change and exposing directly, I requested that a feature flag be introduced so that patches could be split into atomic pieces that can be reviewed one at a time (and also checking that the testing is appropriate). This update isn't about bringing a discussion about ENABLE vs runtime, more about mentioning that there will be a new flag contrary to what was said previously. There is definitely a trend to use runtime flags on core features lately (region, grid, custom filters...) sometimes along with ENABLE flags. This should be discussed separately. Thanks, Julien [1] http://lists.webkit.org/pipermail/webkit-dev/2012-July/021715.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Disjointed selection ranges
On Tue, Aug 14, 2012 at 11:51 AM, Shezan Baig shezbaig...@gmail.com wrote: We are using embedded WebKit in our application, and we need to be able to use disjointed selection ranges for table editing. I was wondering whether anybody is currently working on implementing this, and is there any bug number for it? If not, I will attempt to implement it based on the approach described by Eric in [1] and [2]. I don't think we should implement general multi-range selection. It causes all sorts of hell in editing. Having said that, I would want to see us supporting proper table editing as well. What kind of features for table editing do you have in your mind? Can we discuss this on public-webapps before proceeding with our implementation? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Disjointed selection ranges
On Tue, Aug 14, 2012 at 3:25 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 14, 2012 at 11:51 AM, Shezan Baig shezbaig...@gmail.com wrote: We are using embedded WebKit in our application, and we need to be able to use disjointed selection ranges for table editing. I was wondering whether anybody is currently working on implementing this, and is there any bug number for it? If not, I will attempt to implement it based on the approach described by Eric in [1] and [2]. I don't think we should implement general multi-range selection. It causes all sorts of hell in editing. Having said that, I would want to see us supporting proper table editing as well. What kind of features for table editing do you have in your mind? Essentially, something like http://jsfiddle.net/4BwGG/14/ Clicking on a table header should select all cells within that column, which in turn should allow me to format the column (e.g. set left/right alignment, change font size etc). Can we discuss this on public-webapps before proceeding with our implementation? Sure, we can discuss it there. But this seems to work fine in other browsers like Firefox, so I figured this was a WebKit-specific issue. Thanks, Shezan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New runtime setting: css3TextDecoration
On Tue, Aug 14, 2012 at 3:06 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 14, 2012 at 11:56 AM, Julien Chaffraix * If your feature is protected by an ENABLE flag, vendors that want to ship release software can turn it off. That's true, except that the original thread didn't mention any form of feature flag [1]. Nobody objected at the time and thus patches that implemented part of the spec arrived on bugzilla: prefixed but not protected by any flag. I had certainly assumed that this was done under a new build flag. If that were not the case, I expected relevant reviewers to r- those patches. Maybe this was a bad assumption to make. I've studied CSS Region implementation and basically it contains both compile and runtime flags: The former gets enabled by default while the latter gets disabled, so we can still catch compile-time code errors while not automatically exposing the feature to the web without explicitly enabling the setting. I guess we can implement this feature the same way? I do have a working patch with compile flag implementation [1] . The -webkit-text-decoration-line code works most of the time as an alias to original text-decoration, so it was assumed that no special build flag was required at that time. This is fixed also in [1]. The runtime flag patch [2] works on top of [1], so we end up with the same behavior as CSS region implements. Links: [1] https://bugs.webkit.org/show_bug.cgi?id=93863 [2] https://bugs.webkit.org/show_bug.cgi?id=93966 -- Bruno de Oliveira Abinader ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New runtime setting: css3TextDecoration
On Tue, Aug 14, 2012 at 12:42 PM, Bruno Abinader brunoabina...@gmail.comwrote: I do have a working patch with compile flag implementation [1] . The -webkit-text-decoration-line code works most of the time as an alias to original text-decoration, so it was assumed that no special build flag was required at that time. As I have said on the previous thread, adding this property may break editing in unexpected ways. In particular, we probably wouldn't preserve new values properly when modifying styles. So we need to fix that before shipping it on any browser. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New runtime setting: css3TextDecoration
On Tue, Aug 14, 2012 at 3:47 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 14, 2012 at 12:42 PM, Bruno Abinader brunoabina...@gmail.com wrote: I do have a working patch with compile flag implementation [1] . The -webkit-text-decoration-line code works most of the time as an alias to original text-decoration, so it was assumed that no special build flag was required at that time. As I have said on the previous thread, adding this property may break editing in unexpected ways. In particular, we probably wouldn't preserve new values properly when modifying styles. So we need to fix that before shipping it on any browser. - Ryosuke This is exactly why we need a a flag, whether it is compile, runtime or both :) ps: I've run a bunch of tests with editing with and without the flag set and so far it shows no changes (ie. one underlined line can be copied/pasted with same style, and -webkit-text-decoration-line makes no difference to editing because it is not contained in WebCore::editingProperties vector. -- Bruno de Oliveira Abinader ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New runtime setting: css3TextDecoration
On Tue, Aug 14, 2012 at 1:08 PM, Bruno Abinader brunoabina...@gmail.comwrote: This is exactly why we need a a flag, whether it is compile, runtime or both :) ps: I've run a bunch of tests with editing with and without the flag set and so far it shows no changes (ie. one underlined line can be copied/pasted with same style, and -webkit-text-decoration-line makes no difference to editing because it is not contained in WebCore::editingProperties vector. In editing, unfortunately, just passing existing layout tests isn't enough. We need to make sure editing code works as expected when those new values of text decorations are used. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Disjointed selection ranges
On Tue, Aug 14, 2012 at 12:25 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 14, 2012 at 11:51 AM, Shezan Baig shezbaig...@gmail.comwrote: We are using embedded WebKit in our application, and we need to be able to use disjointed selection ranges for table editing. I was wondering whether anybody is currently working on implementing this, and is there any bug number for it? If not, I will attempt to implement it based on the approach described by Eric in [1] and [2]. I don't think we should implement general multi-range selection. It causes all sorts of hell in editing. keep in mind that you need this or something much like it to handle correct selection in some complex scripts (e.g., indic scripts) as well as bidi contexts for example, a single displayed ligature glyph may map to multiple *disjoint* characters in the original unicode text ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Disjointed selection ranges
On Tue, Aug 14, 2012 at 1:14 PM, Glenn Adams gl...@skynav.com wrote: On Tue, Aug 14, 2012 at 12:25 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 14, 2012 at 11:51 AM, Shezan Baig shezbaig...@gmail.comwrote: We are using embedded WebKit in our application, and we need to be able to use disjointed selection ranges for table editing. I was wondering whether anybody is currently working on implementing this, and is there any bug number for it? If not, I will attempt to implement it based on the approach described by Eric in [1] and [2]. I don't think we should implement general multi-range selection. It causes all sorts of hell in editing. keep in mind that you need this or something much like it to handle correct selection in some complex scripts (e.g., indic scripts) as well as bidi contexts What do you mean by correct? Selection in bidirectional text follow logical order on all major browsers although Gecko supports a non-default option to use visual-order selection. I've talked with many native RTL speakers who have a lot of experience working with bidirectional text but they almost unanimously agreed that selecting text in visual order is a bad idea. Also, when you copy the text selected by visual order and pasting it to somewhere else, we need to somehow serialize the text and the algorithm by which to do this is not well defined. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New runtime setting: css3TextDecoration
On Tue, Aug 14, 2012 at 12:06 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 14, 2012 at 11:56 AM, Julien Chaffraix julien.chaffr...@gmail.com wrote: I don't think it's appropriate to add settings for CSS features that are under development, for a number of reasons: * If we did this for every feature, we'd end up with hundreds of Settings. * Traditionally, Settings don't tend to get removed, resulting in an ever-accumulating number of Settings. ENABLE has a slightly better track of record but I don't think we should push back on runtime flags just because of that. Having a runtime flag incurs runtime cost. Performance is one of our core goal and any WebKit hacker will agree that it's important. Here you forgot to mention that we care about is if it has a *notable* runtime cost in which case there is no proof that the current flags incur such a cost. We know of patches from feature under a flag that have been rolled out because of measurable performance regression [1] so we would know if that was the case. It's also better to catch such slow-down earlier rather than later. The most significant performance impact is probably the increase in the binary size which I won't deny and don't have insights into. Having tons of #ifdef's is a lot more worrying from my perspective, Having a runtime flag is significantly worse in that it affects end users. Having a compile flag is a painful for developers but has absolutely zero cost for end users. You will need to define end users here. WebKit is meant to be embedded and as such you can think of different end users. People embedding WebKit are expected to know about our flags. Browsers' end users are only impacted insofar as browsers vendors implement the right UI and this claim is making strong assumption about how this is done. Now, both options with respect to the flag have their trade-offs but there seems to be majority in favor of ENABLE flags. Brushing aside one option based on FUD is not really something I am supportive of though. Thanks, Julien [1] for example, see https://bugs.webkit.org/show_bug.cgi?id=76064 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New runtime setting: css3TextDecoration
On Tue, Aug 14, 2012 at 3:10 PM, Julien Chaffraix julien.chaffr...@gmail.com wrote: The most significant performance impact is probably the increase in the binary size which I won't deny and don't have insights into. This is only a part of the performance problem but it is actually fairly bad. We do not realize it that much because our development machines have huge CPU caches. Many CPUs in the wild do not have 8Mb of fast cache and sometime we pay a high price for the size of WebKit. I prefer compile flag over runtime flag for experimental features. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New runtime setting: css3TextDecoration
On Tue, Aug 14, 2012 at 3:10 PM, Julien Chaffraix julien.chaffr...@gmail.com wrote: On Tue, Aug 14, 2012 at 12:06 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 14, 2012 at 11:56 AM, Julien Chaffraix julien.chaffr...@gmail.com wrote: I don't think it's appropriate to add settings for CSS features that are under development, for a number of reasons: * If we did this for every feature, we'd end up with hundreds of Settings. * Traditionally, Settings don't tend to get removed, resulting in an ever-accumulating number of Settings. ENABLE has a slightly better track of record but I don't think we should push back on runtime flags just because of that. Having a runtime flag incurs runtime cost. Performance is one of our core goal and any WebKit hacker will agree that it's important. Here you forgot to mention that we care about is if it has a *notable* runtime cost in which case there is no proof that the current flags incur such a cost. http://en.wikipedia.org/wiki/Creeping_normalcy Given how many build flags we already have, I'm not excited about the prospect of having many runtime flags. Brushing aside one option based on FUD is not really something I am supportive of though. We have already had regressions like https://bugs.webkit.org/show_bug.cgi?id=90367 due to runtime flags so this is not a theoretical concern. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Disjointed selection ranges
On Tue, Aug 14, 2012 at 1:43 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 14, 2012 at 1:14 PM, Glenn Adams gl...@skynav.com wrote: On Tue, Aug 14, 2012 at 12:25 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 14, 2012 at 11:51 AM, Shezan Baig shezbaig...@gmail.comwrote: We are using embedded WebKit in our application, and we need to be able to use disjointed selection ranges for table editing. I was wondering whether anybody is currently working on implementing this, and is there any bug number for it? If not, I will attempt to implement it based on the approach described by Eric in [1] and [2]. I don't think we should implement general multi-range selection. It causes all sorts of hell in editing. keep in mind that you need this or something much like it to handle correct selection in some complex scripts (e.g., indic scripts) as well as bidi contexts What do you mean by correct? I mean understandable and repeatable. Selection in bidirectional text follow logical order on all major browsers although Gecko supports a non-default option to use visual-order selection. I've talked with many native RTL speakers who have a lot of experience working with bidirectional text but they almost unanimously agreed that selecting text in visual order is a bad idea. In my experience working with middle eastern and indic display and editing systems, both (logical and visual selection) modes have legitimate uses, and one mode should not be eliminated simply because there may be a majority (of a random sample) that prefers one mode. Personally, I use both modes for different reasons. Also, when you copy the text selected by visual order and pasting it to somewhere else, we need to somehow serialize the text and the algorithm by which to do this is not well defined. Agreed. Existing specs covering browser behavior do not define this very well. My point in bringing it up was simply that there are legitimate use cases for supporting disjoint, multi-range selection. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Disjointed selection ranges
On Tue, Aug 14, 2012 at 3:28 PM, Glenn Adams gl...@skynav.com wrote: On Tue, Aug 14, 2012 at 1:43 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 14, 2012 at 1:14 PM, Glenn Adams gl...@skynav.com wrote: On Tue, Aug 14, 2012 at 12:25 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 14, 2012 at 11:51 AM, Shezan Baig shezbaig...@gmail.comwrote: We are using embedded WebKit in our application, and we need to be able to use disjointed selection ranges for table editing. I was wondering whether anybody is currently working on implementing this, and is there any bug number for it? If not, I will attempt to implement it based on the approach described by Eric in [1] and [2]. I don't think we should implement general multi-range selection. It causes all sorts of hell in editing. keep in mind that you need this or something much like it to handle correct selection in some complex scripts (e.g., indic scripts) as well as bidi contexts What do you mean by correct? I mean understandable and repeatable. Selection in bidirectional text follow logical order on all major browsers although Gecko supports a non-default option to use visual-order selection. I've talked with many native RTL speakers who have a lot of experience working with bidirectional text but they almost unanimously agreed that selecting text in visual order is a bad idea. In my experience working with middle eastern and indic display and editing systems, both (logical and visual selection) modes have legitimate uses, and one mode should not be eliminated simply because there may be a majority (of a random sample) that prefers one mode. Personally, I use both modes for different reasons. Also, when you copy the text selected by visual order and pasting it to somewhere else, we need to somehow serialize the text and the algorithm by which to do this is not well defined. Agreed. Existing specs covering browser behavior do not define this very well. My point in bringing it up was simply that there are legitimate use cases for supporting disjoint, multi-range selection. I have to admit there are some valid use cases for supporting multi-range selection but the complexity it adds to our codebase is unjustifiable. Gecko has tried this for a decade but they're now trying to get rid of it. See https://bugzilla.mozilla.org/show_bug.cgi?id=753718. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Disjointed selection ranges
On Tue, Aug 14, 2012 at 3:36 PM, Ryosuke Niwa rn...@webkit.org wrote: I have to admit there are some valid use cases for supporting multi-range selection but the complexity it adds to our codebase is unjustifiable. Gecko has tried this for a decade but they're now trying to get rid of it. See https://bugzilla.mozilla.org/show_bug.cgi?id=753718. One could make the same (complexity) argument (and many have) against supporting complex scripts in the first place. That is a pretty subjective argument, when certain minorities have no choice but dealing with things that many of us would find complex [look how long it took to support Tibetan|Dzongkha]. For example, one might argue that Japanese should start writing in romaji because kanji|kana is too complex. But that argument never works. Personally, I have implemented and supported disjoint, multi-range selections in a number of high-end editing products (for the preprint industry). I found this quite implementable, though admittedly not straightforward. Anyway, that's my 2 cents worth on this thread... Regards, Glenn ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Disjointed selection ranges
On Tue, Aug 14, 2012 at 4:16 PM, Glenn Adams gl...@skynav.com wrote: On Tue, Aug 14, 2012 at 3:36 PM, Ryosuke Niwa rn...@webkit.org wrote: I have to admit there are some valid use cases for supporting multi-range selection but the complexity it adds to our codebase is unjustifiable. Gecko has tried this for a decade but they're now trying to get rid of it. See https://bugzilla.mozilla.org/show_bug.cgi?id=753718. One could make the same (complexity) argument (and many have) against supporting complex scripts in the first place. That is a pretty subjective argument, when certain minorities have no choice but dealing with things that many of us would find complex [look how long it took to support Tibetan|Dzongkha]. For example, one might argue that Japanese should start writing in romaji because kanji|kana is too complex. But that argument never works. Personally, I have implemented and supported disjoint, multi-range selections in a number of high-end editing products (for the preprint industry). I found this quite implementable, though admittedly not straightforward. Anyway, that's my 2 cents worth on this thread... You can implement multi-range selection in WebKit and make all editing commands work, then please implement it by all means. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New runtime setting: css3TextDecoration
I don't think editing code breaking when the page uses -webkit prefixed properties should block launching a feature. The point of the vendor prefix is to assert the instability of the feature. This wouldn't be a regression, it's just a missing feature. On Tue, Aug 14, 2012 at 3:22 PM, Ryosuke Niwa rn...@webkit.org wrote: ... ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New runtime setting: css3TextDecoration
On Tue, Aug 14, 2012 at 5:41 PM, Elliott Sprehn espr...@chromium.orgwrote: I don't think editing code breaking when the page uses -webkit prefixed properties should block launching a feature. The point of the vendor prefix is to assert the instability of the feature. That's not the point of a vendor prefix. Other browser vendors have shown some real resentments over how we always ship half-baked features that only work in simple cases. See bugs like https://bugs.webkit.org/show_bug.cgi?id=93304. We really need to stop shipping half-baked or half-finished features. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
