Re: [webkit-dev] a ping landed
Keeping it off by default until it has some mainstream acceptance seems like a bit of a self-defeating policy for new features; is this often done in WebKit? -- Dirk On Mon, Oct 4, 2010 at 10:12 PM, Maciej Stachowiak m...@apple.com wrote: Since a ping has been controversial in the past (for arguably bogus reasons, but controversial nontheless), I suggest we keep it off by default until we find it has some mainstream acceptance and/or we discover that more ports want it. Regards, Maciej P.S. We haven't decided yet if we want it on for the ports Apple ships, but it's probable we will turn it on sooner or later. On Oct 4, 2010, at 6:51 PM, Jeremy Orlow wrote: Given that a ping really doesn't open up any new privacy holes (just makes it easier for sites to get the data they're going to gather anyway without slowing down the experience for the user), it seems like we might as well enable it by default. If a port doesn't want it, they can always disable it, right? Thanks, J On Fri, Oct 1, 2010 at 12:39 PM, Nate Chapin jap...@chromium.org wrote: This is a few days late, but I just wanted to let the team know that, as of http://trac.webkit.org/changeset/68166, WebKit can support a ping (but support is disabled by default). The reason I left it disabled by default is that some ports may want to have a mechanism for disabling pings, and I didn't want anyone to accidentally pick it up before they were ready. I'm happy to flip it to enabled by default if that's what people prefer. ~Nate ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] a ping landed
I don't think it is the norm. This one is special for the reasons already stated. -Darin On Mon, Oct 4, 2010 at 11:17 PM, Dirk Pranke dpra...@chromium.org wrote: Keeping it off by default until it has some mainstream acceptance seems like a bit of a self-defeating policy for new features; is this often done in WebKit? -- Dirk On Mon, Oct 4, 2010 at 10:12 PM, Maciej Stachowiak m...@apple.com wrote: Since a ping has been controversial in the past (for arguably bogus reasons, but controversial nontheless), I suggest we keep it off by default until we find it has some mainstream acceptance and/or we discover that more ports want it. Regards, Maciej P.S. We haven't decided yet if we want it on for the ports Apple ships, but it's probable we will turn it on sooner or later. On Oct 4, 2010, at 6:51 PM, Jeremy Orlow wrote: Given that a ping really doesn't open up any new privacy holes (just makes it easier for sites to get the data they're going to gather anyway without slowing down the experience for the user), it seems like we might as well enable it by default. If a port doesn't want it, they can always disable it, right? Thanks, J On Fri, Oct 1, 2010 at 12:39 PM, Nate Chapin jap...@chromium.org wrote: This is a few days late, but I just wanted to let the team know that, as of http://trac.webkit.org/changeset/68166, WebKit can support a ping (but support is disabled by default). The reason I left it disabled by default is that some ports may want to have a mechanism for disabling pings, and I didn't want anyone to accidentally pick it up before they were ready. I'm happy to flip it to enabled by default if that's what people prefer. ~Nate ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebSocket crashes
On Mon, Oct 4, 2010 at 6:24 PM, Simon Fraser simon.fra...@apple.com wrote:
On Oct 4, 2010, at 5:30 PM, Simon Fraser wrote:
On Oct 4, 2010, at 2:33 PM, Adam Barth wrote:
As you might have noticed, the WebSocket tests are crashing on Leopard
and Snow Leopard. I thought for a while that this might be related to
my recent move of the WebSocket tests, but looks unrelated. The
crashes started with a patch that flipped off the SVN executable bit
for a bunch of files, which also seems unrelated (reverting that
change locally also don't seem to make a difference).
Here's a reduced test case:
script
var ws = new WebSocket('ws://localhost:/');
/script
Just open a local HTML file containing that code and you'll crash
WebKit on Snow Leopard (and presumably Leopard as well). The crash
looks like some kind of heap corruption. At this point, I'd like to
hand this off to someone who's more familiar with the WebSockets code.
Any volunteers?
https://bugs.webkit.org/show_bug.cgi?id=47136
People with C++ and x86 assembly skills are encouraged to help out.
The Xcode project was picking up qt/SocketStreamHandle.h in error.
Fixed in http://trac.webkit.org/changeset/69057
You may have to quit and restart Xcode to have it build with the correct
header.
Many thanks for fixing this issue (and the followup #error). :)
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Fwd: Supporting css ime-mode property
-- Forwarded message -- From: Ryosuke Niwa ryosuke.n...@gmail.com Date: Tue, Oct 5, 2010 at 2:29 AM Subject: Re: [webkit-dev] Supporting css ime-mode property To: Alexey Proskuryakov a...@webkit.org Cc: Kenichi Ishibashi ba...@google.com, webkit-dev@lists.webkit.org +1 for implementing this feature. On Mon, Oct 4, 2010 at 10:06 PM, Alexey Proskuryakov a...@webkit.org wrote: I still think that this feature would be actively harmful - even native applications that only target one platform often get IME wrong - there is no chance a web app would do it right on all major platforms. Sticking with platform default behavior is best. I highly doubt that people will misuse ime-mode because whether or not IME should be active is usually obvious from the context (e.g. username password, telephone number, etc...). And I've never felt that there was platform-specific difference in whether or not IME should be enabled / disabled (I actively use Chinese Japanese IMEs on Mac Windows). Of course, I do agree that website shouldn't be controlling IME composition since I've never seen a single native app that controls IME composition correctly. But activating and deactivating IME seems simple enough. It's really problematic that this kind of control isn't available to the Web right now because some (if not majority of) users don't even know how to activate/deactivate IME. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting css ime-mode property
05.10.2010, в 02:29, Ryosuke Niwa написал(а):
I highly doubt that people will misuse ime-mode because whether or not IME
should be active is usually obvious from the context (e.g. username
password, telephone number, etc...).
1. I sometimes use Cyrillic characters in user names, and I'm pretty sure that
some people use CJK. There is no inherent problem with non-ASCII user names.
2. Safari forces input method to an ASCII compatible one in password fields to
match Mac OS X behavior, and people complained about that in the past. The Mac
OS X behavior is reasonable in that there is a clear benefit in not letting
hidden state affect invisible typing, but it's a pain when you can't log in
because of that!
3. A phone number can contain letters, too ('P' for pause, or part of the
number encoded as numbers, e.g. 1-800-COMCAST). In any case, there is input
type=tel for us to implement the best platform specific behavior.
Even these examples aren't obvious at all.
Another example that might seem obvious to a Web designer is numeric input.
People who only use English and Chinese or Japanese usually aren't aware of the
fact that punctuation characters can be at different locations on a non-U.S.
keyboard layout. These layouts are also often different between Mac and PC. So,
if you force a particular keyboard layout in some input fields, users will be
inconvenienced by switching to a different location for '.' and ',' at your
whim.
Another example was given in bug 21279, and that was URL fields. Whatever the
best input method behavior for these could be (one can argue that we should
switch to an ASCII capable input source by default, but let the user change it
later), we should deduce it from input type=url, not from a CSS property.
So far, the only accurate use case that I've seen was developing a UI for a
back-end that doesn't support non-ASCII characters in some fields. I don't
think we should extend the Web platform just to support apps that aren't
i18n-aware. And anyway, you can always paste into any field, so css-mode
doesn't protect you from getting non-ASCII characters in these fields.
And I've never felt that there was platform-specific difference in whether or
not IME should be enabled / disabled (I actively use Chinese Japanese IMEs
on Mac Windows).
I wasn't even talking about Mac vs. Windows. When you specify ime-mode:
disabled, do you also want to disable T9 on phones? Or to somehow affect what
iPhone does?
But there are indeed dramatic differences in actual behavior between Mac and
Windows. In IE, ime-mode: disabled disables input methods, while in Firefox
on Mac, it disables non-ASCII capable input sources. The patch proposed for
WebKit implements the latter. You can't meaningfully use that in a
cross-platform manner.
Please also consider that there are 3rd party input methods for English,
Russian and other languages on Mac, even if there aren't on Windows. Why would
you ever want to disable an English input method, and force the user to use a
plain keyboard?
- WBR, Alexey Proskuryakov
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting css ime-mode property
On Tue, Oct 5, 2010 at 9:27 AM, Alexey Proskuryakov a...@webkit.org wrote: So far, the only accurate use case that I've seen was developing a UI for a back-end that doesn't support non-ASCII characters in some fields. I don't think we should extend the Web platform just to support apps that aren't i18n-aware. And anyway, you can always paste into any field, so css-mode doesn't protect you from getting non-ASCII characters in these fields. This seems to be the primary reason for the ime-mode property. It's common in forms on Japanese web sites to require that the input is formatted a certain way. For example, a site may require a phone number to be in ASCII (1234-5678) instead of unicode (１２３４ー５６７８). The web site will still enforces this by providing server side validation, but as a convenience, it may use ime-mode: disabled to avoid a server round trip. You could argue that the web site is broken because it should be able to normalize this on the server, but that doesn't change the fact that there are lots of web sites in Japan that already try to do this. Implementing ime-mode would improve the user experience on these sites. tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting css ime-mode property
On 05.10.2010, at 10:12, Tony Chang wrote: You could argue that the web site is broken because it should be able to normalize this on the server, but that doesn't change the fact that there are lots of web sites in Japan that already try to do this. Implementing ime-mode would improve the user experience on these sites. Supporting existing sites is a good reason to consider implementing a feature, even though we didn't attempt to quantify how many are affected yet. There are big questions remaining: - Do we really want to implement an IE extension in a way that's way different from IE? - What to do on platforms other than Mac and Windows? - What to do with the harm from future misuse, which is more than likely, given that most (all?) suggested use cases were wrong? Note that Mozilla documentation on ime-mode https://developer.mozilla.org/en/CSS/ime-mode has weird disclaimers like in general, it's not appropriate for a public web site to manipulate the IME mode setting. This property should be used for web applications and the like. I'm reading this as we're now sorry that we implemented it. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Fwd: Supporting css ime-mode property
-- Forwarded message --
From: Ryosuke Niwa ryosuke.n...@gmail.com
Date: Tue, Oct 5, 2010 at 10:45 AM
Subject: Re: [webkit-dev] Supporting css ime-mode property
To: Alexey Proskuryakov a...@webkit.org
Cc: Kenichi Ishibashi ba...@google.com, webkit-dev@lists.webkit.org
On Tue, Oct 5, 2010 at 9:27 AM, Alexey Proskuryakov a...@webkit.org wrote:
05.10.2010, в 02:29, Ryosuke Niwa написал(а):
I highly doubt that people will misuse ime-mode because whether or not
IME should be active is usually obvious from the context (e.g. username
password, telephone number, etc...).
1. I sometimes use Cyrillic characters in user names, and I'm pretty sure
that some people use CJK. There is no inherent problem with non-ASCII user
names.
I don't think there are popular CJK websites that lets you use CJK
characters in usernames. If a website allows non-ASCII, then they can
choose not to use ime-mode property. But in either case, we need to let
websites make such decisions.
3. A phone number can contain letters, too ('P' for pause, or part of the
number encoded as numbers, e.g. 1-800-COMCAST). In any case, there is input
type=tel for us to implement the best platform specific behavior.
We never use Japanese letters in phone numbers, or at least I've never seen
one in my life. But you're right that the website should be using type=tel
in such cases.
Another example that might seem obvious to a Web designer is numeric input.
People who only use English and Chinese or Japanese usually aren't aware of
the fact that punctuation characters can be at different locations on a
non-U.S. keyboard layout. These layouts are also often different between Mac
and PC. So, if you force a particular keyboard layout in some input fields,
users will be inconvenienced by switching to a different location for '.'
and ',' at your whim.
I was never aware that turning on/off IME changes the keyboard layout but I
can't think of a good usage of ime-mode: inactive / disabled in CJK where
users need to type in those special characters.
Another example was given in bug 21279, and that was URL fields. Whatever
the best input method behavior for these could be (one can argue that we
should switch to an ASCII capable input source by default, but let the user
change it later), we should deduce it from input type=url, not from a CSS
property.
I agree. In general, whenever we have an input type for it, ime-mode isn't
so useful or that it shouldn't be used.
So far, the only accurate use case that I've seen was developing a UI for a
back-end that doesn't support non-ASCII characters in some fields. I don't
think we should extend the Web platform just to support apps that aren't
i18n-aware. And anyway, you can always paste into any field, so css-mode
doesn't protect you from getting non-ASCII characters in these fields.
+1 to Tony's response.
I wasn't even talking about Mac vs. Windows. When you specify ime-mode:
disabled, do you also want to disable T9 on phones? Or to somehow affect
what iPhone does?
What I'd expect to happen in iPhone is to switch CJK input pad or any other
languages's IME to English input pad but I think this can be considered as
an implementation detail. In general, ime-mode property is probably only
useful in CJK websites. If website is targeted towards global users, then
it can not to use ime-mode. If website is big enough that it is localized
for different languages, it can use ime-mode only in CJK and do no harm in
other languages.
But there are indeed dramatic differences in actual behavior between Mac and
Windows. In IE, ime-mode: disabled disables input methods, while in
Firefox on Mac, it disables non-ASCII capable input sources. The patch
proposed for WebKit implements the latter. You can't meaningfully use that
in a cross-platform manner.
The latter makes sense at least for CJK.
Please also consider that there are 3rd party input methods for English,
Russian and other languages on Mac, even if there aren't on Windows. Why
would you ever want to disable an English input method, and force the user
to use a plain keyboard?
I agree that it doesn't makes any sense to disable English input method.
Nonetheless, this feature is useful for things like credit card number,
postal code, age, etc...
- Rysouke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting css ime-mode property
On Tue, Oct 5, 2010 at 10:38 AM, Alexey Proskuryakov a...@webkit.org wrote: There are big questions remaining: - Do we really want to implement an IE extension in a way that's way different from IE? We support many features that IE initially implemented; HTML editing is a good example. Also, I don't think the difference between IE and Firefox's implementation affects CJK websites, which presumably will be the primary users of ime-mode. We really should have named this property as cjk-ime-mode! - What to do on platforms other than Mac and Windows? We can do whatever is appropriate or not support it at the moment. - What to do with the harm from future misuse, which is more than likely, given that most (all?) suggested use cases were wrong? I think it's websites' fault if they misuse CSS property. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting css ime-mode property
On 05.10.2010, at 10:56, Ryosuke Niwa wrote: - Do we really want to implement an IE extension in a way that's way different from IE? We support many features that IE initially implemented; HTML editing is a good example. How is this relevant? This topic is complicated as is, let's not try to confuse each other. Also, I don't think the difference between IE and Firefox's implementation affects CJK websites, which presumably will be the primary users of ime-mode. I think it does. An example that was given by Kenichi Ishibashi in https://bugs.webkit.org/show_bug.cgi?id=21279 was a site that used ime-mode to limit input to Katakana. You can't type Katakana when an ASCII-capable IM is forced on Mac, can you? We really should have named this property as cjk-ime-mode! Yes, every feature that's added to the Web is only put to good use, exactly as envisioned by its creators. Do you suggest limiting the feature to pages that specify lang=ja? I didn't respond to you previous e-mail, because I don't see how any argument of usefulness on CJK websites in specific circumstances is an answer to concerns about possible harm. - What to do on platforms other than Mac and Windows? We can do whatever is appropriate or not support it at the moment. Making it easier for web sites to support only a subset of important platforms is not something that I see as a good thing. I think that whoever proposes adding a feature to desktop WebKit needs to make sure that it doesn't make mobile users miserable. We need to improve both. - What to do with the harm from future misuse, which is more than likely, given that most (all?) suggested use cases were wrong? I think it's websites' fault if they misuse CSS property. We cannot expect this level of i18n awareness from web site authors. Pretty much every use of this feature is a misuse, but it takes considerable experience to know why. On 05.10.2010, at 10:38, Alexey Proskuryakov wrote: Note that Mozilla documentation on ime-mode https://developer.mozilla.org/en/CSS/ime-mode has weird disclaimers like in general, it's not appropriate for a public web site to manipulate the IME mode setting. This property should be used for web applications and the like. I'm reading this as we're now sorry that we implemented it. I now tested, and it looks like Mac Firefox doesn't actually implement ime-mode, despite documentation claims. That's surprising, could you please check that? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting css ime-mode property
On Tue, Oct 5, 2010 at 11:26 AM, Alexey Proskuryakov a...@webkit.org wrote: Also, I don't think the difference between IE and Firefox's implementation affects CJK websites, which presumably will be the primary users of ime-mode. I think it does. An example that was given by Kenichi Ishibashi in https://bugs.webkit.org/show_bug.cgi?id=21279 was a site that used ime-mode to limit input to Katakana. You can't type Katakana when an ASCII-capable IM is forced on Mac, can you? That's exactly why we need to activate IME there. If I understood his comment, Kenichi is saying that we need to activate IME to type names in Katakana while we need to deactivate IME to type in card numbers, etc... not that website disables IME to restrict the input to Katakana. We really should have named this property as cjk-ime-mode! Yes, every feature that's added to the Web is only put to good use, exactly as envisioned by its creators. Do you suggest limiting the feature to pages that specify lang=ja? I didn't respond to you previous e-mail, because I don't see how any argument of usefulness on CJK websites in specific circumstances is an answer to concerns about possible harm. I don't think we can limit it to pages with lang=ja because I speculate that most of Japanese websites don't specify the language. I'm quite confused as to why you're so concerned about adding this property because we're not changing the default behavior of WebKit by supporting this new property. If anything, developers don't use this property and their websites work as they do today. And if some websites decide to use ime-mode, I'd expect them to know what they're doing. This might mean that such websites won't work for users who don't regularly use CJK languages but many of CJK websites don't target such users anyways. - What to do on platforms other than Mac and Windows? We can do whatever is appropriate or not support it at the moment. Making it easier for web sites to support only a subset of important platforms is not something that I see as a good thing. I think that whoever proposes adding a feature to desktop WebKit needs to make sure that it doesn't make mobile users miserable. We need to improve both. I'm not saying we can't implement it. I'm just suggesting to implement it only for Mac and Windows (or Windows only if we're so inclined) first until we figure out what's correct on other platforms. I'm confident that there's a way to support this feature in almost every platform with IMEs. - What to do with the harm from future misuse, which is more than likely, given that most (all?) suggested use cases were wrong? I think it's websites' fault if they misuse CSS property. We cannot expect this level of i18n awareness from web site authors. Pretty much every use of this feature is a misuse, but it takes considerable experience to know why. Yes, that's why I expect most of developers will not use this feature. As MDC points out, this feature is for Web apps and alike that require heavy localization; they don't target international users and i18n isn't a concern for them. I now tested, and it looks like Mac Firefox doesn't actually implement ime-mode, despite documentation claims. That's surprising, could you please check that? As far as I checked on Firefox 4.0b6, it is implemented and works as expected. Do you have a different version of Firefox? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting css ime-mode property
On 05.10.2010, at 14:31, Ryosuke Niwa wrote: That's exactly why we need to activate IME there. If I understood his comment, Kenichi is saying that we need to activate IME to type names in Katakana while we need to deactivate IME to type in card numbers, etc... not that website disables IME to restrict the input to Katakana. Not sure. He wrote For instance, name of the user must contain only Katakana, which seems to be a restriction. I have also been surprised by that - it sounded like Katakana can be typed even with IME disabled on Windows. I don't think we can limit it to pages with lang=ja because I speculate that most of Japanese websites don't specify the language. I'm quite confused as to why you're so concerned about adding this property because we're not changing the default behavior of WebKit by supporting this new property. If anything, developers don't use this property and their websites work as they do today. And if some websites decide to use ime-mode, I'd expect them to know what they're doing. This might mean that such websites won't work for users who don't regularly use CJK languages but many of CJK websites don't target such users anyways. These are expectations that don't usually work on the Web. Every feature is used everywhere, as long as it can be passed for working upon a cursory inspection. Someone usually finds a way or two do something intentionally malicious, too. Many features also indirectly take away user's ability to do something that was possible before, and workarounds are often complicated. For an ancient example, advanced CSS and (even more) DHTML took away the ability to print any page. Fixing this involved media specific stylesheets, additional author effort, expectation change from users (lots of pages still cannot be meaningfully printed, and users now find it OK). Many new features negatively affect accessibility. For the majority, benefits far outweigh the drawbacks, and workarounds are found. Now, ime-mode is not such a grande feature that's likely to change how people use the Web :-). I just took some extreme examples to explain why adding features isn't harmless, even if they are initially expected to only be used for good only. Since ime-mode is obviously backwards looking (better support for existing sites that do a wrong thing), and doesn't make the Web platform more powerful, it shouldn't be a surprise that it was met with criticism. As far as I checked on Firefox 4.0b6, it is implemented and works as expected. Do you have a different version of Firefox? I tested https://www.aeoncredit.co.jp/NetBranch/cardinit.do with 3.6.10 on Mac. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting css ime-mode property
On Tue, Oct 5, 2010 at 3:04 PM, Alexey Proskuryakov a...@webkit.org wrote: As far as I checked on Firefox 4.0b6, it is implemented and works as expected. Do you have a different version of Firefox? I tested https://www.aeoncredit.co.jp/NetBranch/cardinit.do with 3.6.10 on Mac. It works on 4.0b6. Maybe it only works for CJK IME. It doesn't enable Dutch IME for example. But Firefox's implementation seems to have a bug that it leaves IME active even when I moved to other apps, which is quite annoying. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting css ime-mode property
Though this property is useful in some situation, it's very confusing regarding to its real purpose. If I understand correctly, this property is mostly used for restricting the input character set of an input box. But an IME is actually only one of many ways can be used by the user to input Unicode characters, so only enabling/disabling the IME actually doesn't solve the underlying problem. If we really want to provide the ability of restricting the input character set, I'd rather suggest to add an attribute to the input element explicitly for this purpose, and make it into the standard. If we just want to provide compatibility to IE, adding ime-mode would be ok, but we may want to warn web developers about the limitations and problems of this property explicitly. Regards James Su 2010/10/4 Kenichi Ishibashi ba...@google.com Hi, I'd like to implement CSS ime-mode property, which activates/deactivates input methods, to WebKit. Here is the MDC's document about this property: https://developer.mozilla.org/en/CSS/ime-mode This property is not a part of any public standard, but both of IE and Firefox support this property. Like Safari and Chrome, they are widely used browsers so the ime-mode property is frequently used when one wants to control input methods. So, if WebKit supports this property, it would improve compatibility of web pages and make web developers easier to implement their pages and services. I recently posted a patch to support the ime-mode property for mac (See https://bugs.webkit.org/show_bug.cgi?id=21279), but alexey asked me to discuss at WHATWG mailing list whether we really should implement this property. Before going to WATWG, I'd like to ask opinions from webkit-dev mailing list. In comments of https://bugs.webkit.org/show_bug.cgi?id=21279, I mentioned the motivation and benefits of supporting this property. In sammary, there are pros and cons for supporting the ime-mode property. Pros: - Can provide a suitable input mode of input methods for particular input elements. For instance, one might deactivate the input method on a credit card number form or telephone number form, while might activate th input method on a address form. - Improves page compatibility. As I mentioned in the comment of the issue, there are many pages which uses the ime-mode property, espacially in CJK web pages. Providing the same behavior regardless of what browser the use uses would be helpful both web authors and users. Cons: - Some users not always feel good when the browser controls input methods automatically. - Input validation is still needed even if this property is specified on an input element and the user input are restricted. FYI, discussion on implementing ime-mode property in Firefox is also available at: https://bugzilla.mozilla.org/show_bug.cgi?id=279246. As the MDC document noted, it's not appropriate for excessive use of this property, but, IMHO, supporting this property would be helpful for people who musta take care of input method related stuff. Regards, ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting css ime-mode property
On Tue, Oct 5, 2010 at 3:18 PM, James Su james...@gmail.com wrote: Though this property is useful in some situation, it's very confusing regarding to its real purpose. If I understand correctly, this property is mostly used for restricting the input character set of an input box. Not quite. This property is used to assist users typing in the correct IME mode. For example, when a CJK user types in names, he/she wants to type in characters as supposed to Latin alphabets so the user needs to active IME manually. But websites can assist him/her by enabling IME automatically in such an input element. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing new port: EFL
Hi Gustavo,
I think Webkit/EFL is now EFL backend independent isn't it?
I'm trying to build it over EFL/directfb librairies.
after calling the build-webkit --efl the build starts but after a while I
got the following error:
I set SET(CMAKE_VERBOSE_MAKEFILE ON) to get the full verbose.
/usr/bin/cmake -E cmake_progress_report
/home/rahmanih/work/WebKit/WebKitBuild/Release/CMakeFiles
[ 0%] Building CXX object
JavaScriptCore/wtf/CMakeFiles/wtf_efl.dir/gobject/GOwnPtr.cpp.o
cd /home/rahmanih/work/WebKit/WebKitBuild/Release/JavaScriptCore/wtf
/usr/lib/ccache/c++ -DBUILDING_WITH_CMAKE=1 -DHAVE_CONFIG_H=1 -DXP_UNIX
-DWTF_PLATFORM_EFL=1 -DWTF_USE_PTHREADS=1 -DWTF_USE_ICU_UNICODE=1
-DWTF_PLATFORM_CAIRO=1 -DUSE_FREETYPE=1
-DDATA_DIR=\/usr/local/share/ewebkit-0\ -DHAVE_ECORE_X -DWTF_USE_SOUP=1
-DUSE_SYSTEM_MALLOC=1 -DBUILDING_WTF -O3 -DNDEBUG
-I/home/rahmanih/work/WebKit/JavaScriptCore
-I/home/rahmanih/work/WebKit/JavaScriptCore/wtf
-I/home/rahmanih/work/WebKit/JavaScriptCore/wtf/unicode
-I/home/rahmanih/work/WebKit/WebKitBuild/Release/DerivedSources
-I/home/rahmanih/work/WebKit/JavaScriptCore/wtf/gobject
-I/usr/local/include/ecore-1 -I/usr/local/include/eina-1
-I/usr/local/include/eina-1/eina
-I/home/rahmanih/work/WebKit/WebKitBuild/Release -W -DANOTHER_BRICK_IN_THE
-Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat -Wformat-security
-Wmissing-format-attribute -Wno-format-y2k -Wno-parentheses
-Wno-unused-parameter -Wpointer-arith -Wreturn-type -Wundef -Wwrite-strings
-fno-exceptions -fno-strict-aliasing -fPIC -fvisibility=hidden -o
CMakeFiles/wtf_efl.dir/gobject/GOwnPtr.cpp.o -c
/home/rahmanih/work/WebKit/JavaScriptCore/wtf/gobject/GOwnPtr.cpp
/home/rahmanih/work/WebKit/JavaScriptCore/wtf/gobject/GOwnPtr.cpp:22:21:
error: gio/gio.h: No such file or directory
/home/rahmanih/work/WebKit/JavaScriptCore/wtf/gobject/GOwnPtr.cpp:23:18:
error: glib.h: No such file or directory
/home/rahmanih/work/WebKit/JavaScriptCore/wtf/gobject/GOwnPtr.cpp: In
function ‘void WTF::freeOwnedGPtr(T*) [with T = _GError]’:
/home/rahmanih/work/WebKit/JavaScriptCore/wtf/gobject/GOwnPtr.cpp:30: error:
‘g_error_free’ was not declared in this scope
/home/rahmanih/work/WebKit/JavaScriptCore/wtf/gobject/GOwnPtr.cpp: In
function ‘void WTF::freeOwnedGPtr(T*) [with T = _GList]’:
/home/rahmanih/work/WebKit/JavaScriptCore/wtf/gobject/GOwnPtr.cpp:35: error:
‘g_list_free’ was not declared in this scope
/home/rahmanih/work/WebKit/JavaScriptCore/wtf/gobject/GOwnPtr.cpp: In
function ‘void WTF::freeOwnedGPtr(T*) [with T = _GCond]’:
/home/rahmanih/work/WebKit/JavaScriptCore/wtf/gobject/GOwnPtr.cpp:41: error:
‘g_cond_free’ was not declared in this scope
/home/rahmanih/work/WebKit/JavaScriptCore/wtf/gobject/GOwnPtr.cpp: In
function ‘void WTF::freeOwnedGPtr(T*) [with T = _GMutex]’:
/home/rahmanih/work/WebKit/JavaScriptCore/wtf/gobject/GOwnPtr.cpp:47: error:
‘g_mutex_free’ was not declared in this scope
/home/rahmanih/work/WebKit/JavaScriptCore/wtf/gobject/GOwnPtr.cpp: In
function ‘void WTF::freeOwnedGPtr(T*) [with T = _GPatternSpec]’:
/home/rahmanih/work/WebKit/JavaScriptCore/wtf/gobject/GOwnPtr.cpp:53: error:
‘g_pattern_spec_free’ was not declared in this scope
/home/rahmanih/work/WebKit/JavaScriptCore/wtf/gobject/GOwnPtr.cpp: In
function ‘void WTF::freeOwnedGPtr(T*) [with T = _GDir]’:
/home/rahmanih/work/WebKit/JavaScriptCore/wtf/gobject/GOwnPtr.cpp:59: error:
‘g_dir_close’ was not declared in this scope
/home/rahmanih/work/WebKit/JavaScriptCore/wtf/gobject/GOwnPtr.cpp: In
function ‘void WTF::freeOwnedGPtr(T*) [with T = _GFile]’:
/home/rahmanih/work/WebKit/JavaScriptCore/wtf/gobject/GOwnPtr.cpp:65: error:
‘g_object_unref’ was not declared in this scope
make[2]: ***
[JavaScriptCore/wtf/CMakeFiles/wtf_efl.dir/gobject/GOwnPtr.cpp.o] Error 1
make[2]: Leaving directory `/home/rahmanih/work/WebKit/WebKitBuild/Release'
make[1]: *** [JavaScriptCore/wtf/CMakeFiles/wtf_efl.dir/all] Error 2
make[1]: Leaving directory `/home/rahmanih/work/WebKit/WebKitBuild/Release'
I don't know why the gio and the glib cflags are missing.
could help me please ? I'm newbie regarding Cmake.
also is there any mailing list for the webkitefl ?
Kind regards.
Haithem.
On Wed, Apr 7, 2010 at 1:05 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Wed, Apr 7, 2010 at 3:01 AM, haithem rahmani
haithem.rahm...@gmail.com wrote:
Hi,
Just a simple question:
- It seems that the EFL port of webkit is based on EFL/X11 api.
is there plans to support other EFL backends especially directfb ?
WebkitGtk is doing that with (--with-target=directfb) option.
Yes, there are other peers interested in such support, including SDL,
FrameBuffer and DirectFB.
However we're focused on getting the patches merged into SVN first.
Any reviewer attention can help, we're almost there, just some files
pending. They are:
Pending Review:
https://bugs.webkit.org/show_bug.cgi?id=35915 Add
FrameLoaderClientEfl.{cpp,h}
https://bugs.webkit.org/show_bug.cgi?id=35918 Add
Re: [webkit-dev] Supporting css ime-mode property
2010/10/5 Ryosuke Niwa rn...@webkit.org On Tue, Oct 5, 2010 at 3:18 PM, James Su james...@gmail.com wrote: Though this property is useful in some situation, it's very confusing regarding to its real purpose. If I understand correctly, this property is mostly used for restricting the input character set of an input box. Not quite. This property is used to assist users typing in the correct IME mode. For example, when a CJK user types in names, he/she wants to type in characters as supposed to Latin alphabets so the user needs to active IME manually. But websites can assist him/her by enabling IME automatically in such an input element. The ime-mode property is also very problematic for this purpose: 1. Activating/deactivating the IME is a very special concept only available on Windows, and may not suitable for other platforms. 2. disabled makes no sense for this purpose. 3. IMO, it's more like a hint instead of a mandatory restriction. The user should have right to override it. So for this purpose, I still think having an explicit attribute to hint the desired character set of an input element is better than ime-mode solution. So that the UA can decide the proper action for it. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting css ime-mode property
Hi, Thanks a lot of discussion about this matter. A bunch of Ryosuke-san's replies is exactly what I'd like to say. I still believe that the property can make web page authors provide appropriate input mode by default and isn't harmful as long as the authors use the property in a gentle manner. Not sure. He wrote For instance, name of the user must contain only Katakana, which seems to be a restriction. I have also been surprised by that - it sounded like Katakana can be typed even with IME disabled on Windows. Sorry for making a misleading, but Ryosuke-san's understanding is correct. I intended to say that the input must contain Katakana so it would be helpful if IME could be automatically activated to input Katakana, which is appropriate input mode in this case. I didn't intent to force the user to input Katakana by this property (and actually it will be impossible because we can paste any non-Katakana characters into the form). Now, ime-mode is not such a grande feature that's likely to change how people use the Web :-). I just took some extreme examples to explain why adding features isn't harmless, even if they are initially expected to only be used for good only. Here is another use-case. Some modern CJK web pages provide a way to input Chinese or Japanese text without OS-provided IMEs. You can see an example at http://www.baidu.com/. Click the text next to the search button and select 拼音 or appropriate one, then input text in the search box so you will get the candidate window in a similar way that OS-provided IMEs. When developers want to provide such feature, they might want to control system-level IMEs and the ime-mode property could provide the solution. I think this feature likely to change how people use the Web. Regards, ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby Text Enhancements
On Sep 24, 2010, at 8:02 PM, David Hyatt wrote: This is a tough problem. It seems like you have to get involved in the line layout code e.g., findNextLineBreak in order to really do the right thing. findNextLineBreak uses an iterator that walks the objects, so it's easier to tell what text came before you and what text comes after you. You can also tell whether or not that text will even fit on the line and possibly do the margin hacking there. I just did a prototype that checks for a RenderRubyRun in the isReplaced() code inside findNextLineBreak and calls a method on the RenderRubyRun that takes the last and the next object and sets negative margins by calling setMarginLeft() and setMarginRight(). I stepped through this code and it computes the correct margins, but the margins don't seem to take - the ruby doesn't overlap the surrounding text. Guessing that some other code is resetting the margins, I modified the code to cache the computed margins in the RenderRubyRun object and return the cached values through subclassed marginLeft() and marginRight() methods. With this change, the ruby displays as I would expect. Does anybody have any idea what code resetting the margins, and what I need to do to talk it out of doing this? Regards, Eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting css ime-mode property
I also have a concern on this proposal. The assumption that this property makes on the semantic of the input system of the platform does necessary universally true and it could be potentially harmful. On Mac OS X and iOS, there is no notion of disabling or enabling input method or mode. You can switch between different input modes, or you can request an input mode that is suitable for a particular purpose (e.g. ascii, email address, etc.). I will catch up with the thread and will make more comment. Thanks, - kida On 2010/10/05, at 13:06, Alexey Proskuryakov wrote: 04.10.2010, в 18:59, Kenichi Ishibashi написал(а): As the MDC document noted, it's not appropriate for excessive use of this property, but, IMHO, supporting this property would be helpful for people who musta take care of input method related stuff. I still think that this feature would be actively harmful - even native applications that only target one platform often get IME wrong - there is no chance a web app would do it right on all major platforms. Sticking with platform default behavior is best. In the use cases the were discussed in the bug, support for ime-mode would have harmed international savvy behavior. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting css ime-mode property
On 05.10.2010, at 17:16, Kenichi Ishibashi wrote: Here is another use-case. Some modern CJK web pages provide a way to input Chinese or Japanese text without OS-provided IMEs. You can see an example at http://www.baidu.com/. Click the text next to the search button and select 拼音 or appropriate one, then input text in the search box so you will get the candidate window in a similar way that OS-provided IMEs. When developers want to provide such feature, they might want to control system-level IMEs and the ime-mode property could provide the solution. I think this feature likely to change how people use the Web. I'm not sure if I understand the exact use case. Are you saying that the page will want to suppress OS provided input methods if it does its own? That doesn't seem necessarily useful, and anyway, they don't need ime-mode for this - OS provided input methods won't be invoked if the page returns false from keydown event handler. What I see on baidu.com right now seems much different from an input method though - they are just making a guess at what the user intended to type. Google search works exactly the same, as long as the page language is set appropriately. For Russian, it detects both typing with a wrong keyboard layout (if the user forgot to switch it), and transliteration. For Chinese, it supports at least transliteration. It also detects and corrects typos. All this functionality doesn't seem specific to CJK at all. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting css ime-mode property
I meant does NOT necessary universally true. The property assumes input mode takes two states, on and off, but on some platforms it can take multiple values. an alternative way of achieving the same thing in more predictive way: http://developer.apple.com/library/ios/#documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/KeyboardManagement/KeyboardManagement.html - kida On 2010/10/06, at 8:36, Yasuo Kida wrote: I also have a concern on this proposal. The assumption that this property makes on the semantic of the input system of the platform does necessary universally true and it could be potentially harmful. On Mac OS X and iOS, there is no notion of disabling or enabling input method or mode. You can switch between different input modes, or you can request an input mode that is suitable for a particular purpose (e.g. ascii, email address, etc.). I will catch up with the thread and will make more comment. Thanks, - kida On 2010/10/05, at 13:06, Alexey Proskuryakov wrote: 04.10.2010, в 18:59, Kenichi Ishibashi написал(а): As the MDC document noted, it's not appropriate for excessive use of this property, but, IMHO, supporting this property would be helpful for people who musta take care of input method related stuff. I still think that this feature would be actively harmful - even native applications that only target one platform often get IME wrong - there is no chance a web app would do it right on all major platforms. Sticking with platform default behavior is best. In the use cases the were discussed in the bug, support for ime-mode would have harmed international savvy behavior. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting css ime-mode property
On Tue, Oct 5, 2010 at 5:48 PM, Alexey Proskuryakov a...@webkit.org wrote: What I see on baidu.com right now seems much different from an input method though - they are just making a guess at what the user intended to type. Google search works exactly the same, as long as the page language is set appropriately. For Russian, it detects both typing with a wrong keyboard layout (if the user forgot to switch it), and transliteration. For Chinese, it supports at least transliteration. It also detects and corrects typos. All this functionality doesn't seem specific to CJK at all. Select 拼音 and then try typing nihao into the search box. You get IME. It even supports moving back forth between Chinese English mode by Shift key! - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby Text Enhancements
On Oct 5, 2010, at 7:33 PM, Eric Mader wrote: On Sep 24, 2010, at 8:02 PM, David Hyatt wrote: This is a tough problem. It seems like you have to get involved in the line layout code e.g., findNextLineBreak in order to really do the right thing. findNextLineBreak uses an iterator that walks the objects, so it's easier to tell what text came before you and what text comes after you. You can also tell whether or not that text will even fit on the line and possibly do the margin hacking there. I just did a prototype that checks for a RenderRubyRun in the isReplaced() code inside findNextLineBreak and calls a method on the RenderRubyRun that takes the last and the next object and sets negative margins by calling setMarginLeft() and setMarginRight(). I stepped through this code and it computes the correct margins, but the margins don't seem to take - the ruby doesn't overlap the surrounding text. Guessing that some other code is resetting the margins, I modified the code to cache the computed margins in the RenderRubyRun object and return the cached values through subclassed marginLeft() and marginRight() methods. With this change, the ruby displays as I would expect. It's probably RenderBlockLineLayout line 348 getting you in trouble (computeInlineDirectionPositionsForLine). computeLogicalWidth is called again, and that will recompute the left/right margins and blow away the changes you made to them. I have no idea why that call is there. It should not be necessary, but maybe there's something subtle I'm missing. You could try removing it, and see if that fixes the problem (it should). dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting css ime-mode property
05.10.2010, в 18:14, Ryosuke Niwa написал(а): Select 拼音 and then try typing nihao into the search box. You get IME. It even supports moving back forth between Chinese English mode by Shift key! Per an off-list discussion, one needs to click 输入法 or the arrow next to it and then you can select 拼音 first. After that, an IME UI appears - although it seems unstable - I get it sometimes, but not every time for whatever reason. The technology is quite impressive. This page disables non-ASCII input sources in Firefox, and I wouldn't call it a good idea. I could search for Russian words (almost) fine in Safari, but not in Firefox. One problem with Russian was that I couldn't type letters that are located on the same keys as punctuation on U.S. layout, due to the page handling them from keydown to produce CJK punctuation. It would've been perfect if it used keypress for that. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting css ime-mode property
05.10.2010, в 21:42, Alexey Proskuryakov написал(а): This page disables non-ASCII input sources in Firefox, and I wouldn't call it a good idea In other words, I think that it works better in Safari thanks to the lack of ime-mode. I might be overlooking some missing functionality, but the ability to use other languages without switching page operation mode is a plus. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
