Re: [webkit-dev] New Rich Text Editing Test suite
On Sat, Oct 2, 2010 at 5:14 AM, Ryosuke Niwa rn...@webkit.org wrote:
I also noticed:
RTE2-CC_FN:a_FONTf:a-1_SI fontname 'courier' y y y y FAIL font
face=arialfoo[bar]baz/font font face=arialfoo[bar]baz/font font
face=arialfoo/fontspanclass=apple-style-span style=font-family:
courier[bar]/spanfont face=arialbaz/font Change existing font
name to same font name, using CSS styling (should be noop)
Isn't supposed to be fontname 'arial' instead? There are 4 other tests
below this one with the seemingly the same problem.
Whoops, the evils of copy-paste programming strike again! :p Fixed in the
last commit (not yet live).
On Sat, Oct 2, 2010 at 6:04 AM, Ryosuke Niwa rn...@webkit.org wrote:
I think we shouldn't be hard-coding 18px here:
{'value': '18px', 'pad': 'span style=font-size:
large[foobarbaz]/span', 'expected': ['span style=font-size:
large[foobarbaz]/span', 'span style=font-size:
large[foobarbaz]/span'], 'command': 'fontsize', 'id':
'FS:18px_SPANs:fs:l-1_SW', 'desc': 'Change existing font size to equivalent
px size (should be noop, or change unit)'}
The pixel font value of font-size: large is different depending on whether
or not we're in strict/quirks modes and whether or not we're using fixed
font (at least in WebKit and probably in Firefox). We should be using the
computed style value of the text instead.
The code to normalize units (colors and font sizes) is cribbed from the
original RichText suite. It does allow for some variation, but of course I'm
open for any suggestions. Esp. actually rendered font size (as opposed to
what's contained in the attributes/style) would be interesting, since that
may yet again be modified by inherited style. However, I'm not sure how to
portably test this across browsers.
Cheers,
- Roland
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New Rich Text Editing Test suite
I don't have a ToT WebKit browser ATM, but I'll check once I updated and compiled. FWIW, this seems to be a regression anyways, since release Chromium (Chrome 6.0) at least passes all those tests, without extra br (?) Cheers, - Roland On Sat, Oct 2, 2010 at 5:07 AM, Ryosuke Niwa rn...@webkit.org wrote: However, we pass JustifyLeft, JustifyRight, JustifyCenter even though we also add BR in those cases. I don't quite understand the difference there... - Ryosuke On Thu, Sep 30, 2010 at 6:58 PM, Roland Steiner rolandstei...@google.comwrote: On Fri, Oct 1, 2010 at 10:49 AM, Ryosuke Niwa rn...@webkit.org wrote: Mn... I realized something strange here. RTE2-AC_JF_TEXT-1_SC fails on WebKit TOT and the test is: JustifyFull on foo^bar. However, it clearly works on WebKit when I test it manually. It generates div style=text-align: justify;foobarbr/div. I'm not sure why the test claims that WebKit fails on this particular test. That is probably one of the areas that needs discussion - the way the suite is set up currently, it doesn't allow for superfluous HTML elements. I.e., my guess is that it fails because of the extra br (ATM I don't have a TOT WebKit browser, so can't confirm for sure). I have added cases like this as acceptable (but not ideal) results for some tests, but not yet all of them (if we want to add this, then I guess I should implement some systematic way to check these rather than adding it by hand, though). Cheers, - Roland ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] PSA: Don't try to hold onto temporaries with references
On Mon, Oct 4, 2010 at 12:41 PM, Hans Wennborg h...@chromium.org wrote: On Mon, Oct 4, 2010 at 12:23 PM, Leandro Graciá Gil leandrogra...@chromium.org wrote: In summary, looking at code like this B b = c-foo(); ... b.m(); If c-foo() returns a temporary (return B();), then it is safe. Maybe I'm wrong, but are you completely sure about this one? I would say that the temporary object created in return B() will cease to exist as soon as it returns (just after the constructor finishes). Actually, the temporary object ceases to exist as soon as *the expression containing the call completes*, as Peter Kasting pointed out. So this should be ok: B b = c-foo(); // foo() returns a reference to a temporary, and the temporary is then copied to b, then destroyed And this too: c-foo().m(); But not this: B b = c-foo(); // the temporary is gone now b.m(); // trouble Hans I take it all back! I read that standards quote a bit too fast :) A temporary bound to the returned value in a function return statement persists until the function exists. I suppose that says it all. Leandro is right, I think. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Safari for Windows symbol server updated
The Safari for Windows symbol server has been updated with symbols for all releases through Safari 5.0.2. You can find instructions for using the symbol server at http://developer.apple.com/internet/safari/windows_symbols_agree.html. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] PSA: Don't try to hold onto temporaries with references
In summary, looking at code like this B b = c-foo(); ... b.m(); If c-foo() returns a temporary (return B();), then it is safe. Maybe I'm wrong, but are you completely sure about this one? I would say that the temporary object created in return B() will cease to exist as soon as it returns (just after the constructor finishes). So you will be returning a reference to a temporary which, I think, no longer is valid. I made a quick test to be sure and the destructor of B is indeed called. Why is it safe? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] PSA: Don't try to hold onto temporaries with references
On Mon, Oct 4, 2010 at 12:23 PM, Leandro Graciá Gil leandrogra...@chromium.org wrote: In summary, looking at code like this B b = c-foo(); ... b.m(); If c-foo() returns a temporary (return B();), then it is safe. Maybe I'm wrong, but are you completely sure about this one? I would say that the temporary object created in return B() will cease to exist as soon as it returns (just after the constructor finishes). Actually, the temporary object ceases to exist as soon as *the expression containing the call completes*, as Peter Kasting pointed out. So this should be ok: B b = c-foo(); // foo() returns a reference to a temporary, and the temporary is then copied to b, then destroyed And this too: c-foo().m(); But not this: B b = c-foo(); // the temporary is gone now b.m(); // trouble Hans ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] PSA: Don't try to hold onto temporaries with references
Date: Mon, 4 Oct 2010 12:23:06 +0100 From: leandrogra...@chromium.org To: le...@google.com CC: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] PSA: Don't try to hold onto temporaries with references In summary, looking at code like this B b = c-foo(); ... b.m(); If c-foo() returns a temporary (return B();), then it is safe. Maybe I'm wrong, but are you completely sure about this one? I would say that the temporary object created in return B() will cease to exist as soon as it returns (just after the constructor finishes). So you will be returning a reference to a temporary which, I think, no longer is valid. I made a quick test to be sure and the destructor of B is indeed called. Why is it safe? ok, I avoided saying anything since I have yet to contrib code and quite frankly don't have an authoritiative answer but I do recall when I was learning cpp the compiler would warn if you even tried to return a ref to a temp( maybe this is just msvc or you need to try it with -Wall ). If the thing it points to is on the stack, and presumably the stack gets popped on return, you would probably need to generate some really odd code to save this reference once the thing for which it is a synonym goes out of scope. If you are defending this as safe it may be nice to show what kind of code the compiler generates to keep this thing valid. ___ 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] HTML5 Parsing amp; MathML
On Sat, Oct 2, 2010 at 3:48 PM, David Carlisle d.p.carli...@gmail.com wrote: Alex Milowski alex at milowski.org writes: From reading the section on in foreign content' [1], it would seem that it should assign the 'svg' elements to the MathML namespace when they are embedded as above. That means cutting and pasting the same content fragment gives two very different interpretations--which is more of a problem for the HTML5 spec than webkit. As (since?) confirmed elsewhere on another list, but mentioned here for the record, the example becomes valid (and parse-able by html5 parser) if you wrap the svg in mi elements. the presentation mathml token elements, mi, mtext, etc are specified as being the extension points where you can embed html (and thus svg). That presents a challenge to the way the MathML implementation is current organized. In the current implementation, token elements are not suppose to contain element content. We'll need to completely re-architect the token elements to handle this in all situations as we won't get it by default in several cases. For example, if the SVG is embedded in an 'mo' element, the SVG will be ignored. That also questions what should be done in cases like: mo random text svg ... /svg /mo I still stand by my position that wrapping foreign elements in token elements in MathML is completely unnecessary for SVG, HTML, or other vocabularies that have rendering semantics that translate into some sequence of inline or block boxes. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] PSA: Don't try to hold onto temporaries with references
The standard is clear on this. The temporary does persist for the lifetime of the reference. See https://bugs.webkit.org/show_bug.cgi?id=47055#c4, a comment I posted yesterday morning, for the reference to the appropriate section in the C++ standard. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] PSA: Don't try to hold onto temporaries with references
On Mon, Oct 4, 2010 at 4:23 AM, Leandro Graciá Gil leandrogra...@chromium.org wrote: In summary, looking at code like this B b = c-foo(); ... b.m(); If c-foo() returns a temporary (return B();), then it is safe. Maybe I'm wrong, but are you completely sure about this one? I would say that the temporary object created in return B() will cease to exist as soon as it returns (just after the constructor finishes). foo() is returning a temp by value. On the caller side, that value is copied to a (hidden) temp whose lifetime is the same as the lifetime of |b|, and then |b| is set to be a reference to that temp. By contrast, if foo were returning a temp by reference, then the reference would be invalid on return because the (foo()-scoped) temp it referred to would be destroyed when foo() exited. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Parsing MathML
On Fri, Oct 1, 2010 at 12:52 PM, Adam Barth aba...@webkit.org wrote: Our parser follows the spec (modulo late-breaking spec changes that we haven't picked up yet). The different namespaces can only be nested in certain ways, unlike in XML where arbitrary nesting is possible. Actually, I don't think a MathML annotation-xml with an SVG child element is going to work properly in WebKit the way the current code is setup. I'll test that. This is place where I think the parsing rules for HTML5 need to be adjusted so we get the same results for HTML or SVG embedded in MathML regardless of HTML or XHTML syntax. Digging deeper into what the HTML5 specification says for foreign content, the HTML div element would generate a parse error: p ... math mfenced open='[ close=] div ... random stuff /div /mfenced /math /p It would then pop the open stack back to the parent p element and the div element would be a child of the paragraph and not of the fencing. In XHTML, assuming there are appropriate uses of namespaces, everything would work fine and you'd get a div element fenced with stretching square brackets. So, if you cut-n-pasted the same content with the 'xmlns' attributes, you'd get two very different results. That really feels fixable but I'm going to need to think a bit more about what adjustments there would need to be to the rules. I wonder what the intersection of local names is between MathML and HTML ... This is, of course, an HTML5 issue and not really an WebKit issue except for the question of difficulty of implementation. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] When to use FastAllocBase?
For general reference, when is it appropriate to use FastAllocBase? If you subclass RefCountedT or Noncopyable, which is very common, you pick up FastAllocBase. So, my naive guess is that any class/struct which doesn't pick up FastAllocBase through its inheritance chain should subclass it directly. Is that a reasonable guideline? Thanks, -Tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Parsing MathML
On Mon, Oct 4, 2010 at 10:03 AM, Alex Milowski a...@milowski.org wrote: On Fri, Oct 1, 2010 at 12:52 PM, Adam Barth aba...@webkit.org wrote: Our parser follows the spec (modulo late-breaking spec changes that we haven't picked up yet). The different namespaces can only be nested in certain ways, unlike in XML where arbitrary nesting is possible. Actually, I don't think a MathML annotation-xml with an SVG child element is going to work properly in WebKit the way the current code is setup. I'll test that. This is place where I think the parsing rules for HTML5 need to be adjusted so we get the same results for HTML or SVG embedded in MathML regardless of HTML or XHTML syntax. Digging deeper into what the HTML5 specification says for foreign content, the HTML div element would generate a parse error: p ... math mfenced open='[ close=] div ... random stuff /div /mfenced /math /p It would then pop the open stack back to the parent p element and the div element would be a child of the paragraph and not of the fencing. In XHTML, assuming there are appropriate uses of namespaces, everything would work fine and you'd get a div element fenced with stretching square brackets. So, if you cut-n-pasted the same content with the 'xmlns' attributes, you'd get two very different results. That really feels fixable but I'm going to need to think a bit more about what adjustments there would need to be to the rules. I wonder what the intersection of local names is between MathML and HTML ... This is, of course, an HTML5 issue and not really an WebKit issue except for the question of difficulty of implementation. If you have feedback on the HTML5 working group, it's probably a good idea to convey that to the working group sooner rather than later. The HTML5 specification is close to Last Call, after which it will be more difficult to make changes. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] When to use FastAllocBase?
On Mon, Oct 4, 2010 at 11:31 AM, Tony Gentilcore to...@chromium.org wrote: For general reference, when is it appropriate to use FastAllocBase? If you subclass RefCountedT or Noncopyable, which is very common, you pick up FastAllocBase. So, my naive guess is that any class/struct which doesn't pick up FastAllocBase through its inheritance chain should subclass it directly. Is that a reasonable guideline? My understanding is that FastAllocBase is supposed to be on the inheritance chain for every object that's allocated on the heap. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] When to use FastAllocBase?
On Oct 4, 2010, at 11:31 AM, Tony Gentilcore wrote: If you subclass RefCountedT or Noncopyable, which is very common, you pick up FastAllocBase. Yes, so in those cases you don’t want to use it. So, my naive guess is that any class/struct which doesn't pick up FastAllocBase through its inheritance chain should subclass it directly. Is that a reasonable guideline? That’s OK, but: 1) FastAllocBase has been causing object size bloat, so we are planning to switch from base classes to macros. See bug 42998 https://bugs.webkit.org/show_bug.cgi?id=42998. 2) If the object will not ever be allocated with new, there is no benefit to deriving from FastAllocBase. 3) Our original plan was to that on platforms where ENABLE_GLOBAL_FASTMALLOC_NEW, such as Mac OS X, we would change the operator new to check at runtime and immediately assert in debug builds if someone forgot to use FastAllocBase. But as you can see if you look at FastMalloc.h, this has not been done yet. So for the moment it’s fine to follow the guideline you mention, but (1) will change how we do it soon, (2) is worth considering, and (3) will eventually make the guideline clearer than it is now because we’ll notice when we do it wrong! -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] When to use FastAllocBase?
Thanks for the responses. That clears everything up for me. I would recommend we add something to http://webkit.org/coding/coding-style.html, but it sounds like we shouldn't do anything at this point since everything is change. On Mon, Oct 4, 2010 at 11:46 AM, Darin Adler da...@apple.com wrote: On Oct 4, 2010, at 11:31 AM, Tony Gentilcore wrote: If you subclass RefCountedT or Noncopyable, which is very common, you pick up FastAllocBase. Yes, so in those cases you don’t want to use it. So, my naive guess is that any class/struct which doesn't pick up FastAllocBase through its inheritance chain should subclass it directly. Is that a reasonable guideline? That’s OK, but: 1) FastAllocBase has been causing object size bloat, so we are planning to switch from base classes to macros. See bug 42998 https://bugs.webkit.org/show_bug.cgi?id=42998. 2) If the object will not ever be allocated with new, there is no benefit to deriving from FastAllocBase. 3) Our original plan was to that on platforms where ENABLE_GLOBAL_FASTMALLOC_NEW, such as Mac OS X, we would change the operator new to check at runtime and immediately assert in debug builds if someone forgot to use FastAllocBase. But as you can see if you look at FastMalloc.h, this has not been done yet. So for the moment it’s fine to follow the guideline you mention, but (1) will change how we do it soon, (2) is worth considering, and (3) will eventually make the guideline clearer than it is now because we’ll notice when we do it wrong! -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] PSA: Don't try to hold onto temporaries with references
On Tue, Oct 5, 2010 at 3:42 AM, Peter Kasting pkast...@chromium.org wrote:
On Mon, Oct 4, 2010 at 4:23 AM, Leandro Graciá Gil
leandrogra...@chromium.org wrote:
In summary, looking at code like this
B b = c-foo();
...
b.m();
If c-foo() returns a temporary (return B();), then it is safe.
Maybe I'm wrong, but are you completely sure about this one? I would say
that the temporary object created in return B() will cease to exist as soon
as it returns (just after the constructor finishes).
foo() is returning a temp by value. On the caller side, that value is
copied to a (hidden) temp whose lifetime is the same as the lifetime of |b|,
and then |b| is set to be a reference to that temp.
By contrast, if foo were returning a temp by reference, then the reference
would be invalid on return because the (foo()-scoped) temp it referred to
would be destroyed when foo() exited.
Thanks Darin and Peter.
I left out an important detail: the full function signature .(I mentally
used my standard way of writing such code.)
#1 was B foo() { return B();}
vs
#2 was const B foo() { return m_b; }
I suspect that the the example code written to test it looked like this:
B foo() { return B();}
PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebSocket crashes
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?
Thanks,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] a ping landed
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 pinghttp://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#hyperlink-auditing(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
Re: [webkit-dev] WebSocket crashes
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.
Simon
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebSocket crashes
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.
Simon
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Supporting css ime-mode property
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
Re: [webkit-dev] Supporting css ime-mode property
On Oct 4, 2010, at 6:59 PM, Kenichi Ishibashi wrote: 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. CSS properties should be discussed on www-style, not what-wg. Simon ___ 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 Oct 4, 2010, at 10:49 PM, Simon Fraser wrote: On Oct 4, 2010, at 6:59 PM, Kenichi Ishibashi wrote: 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. CSS properties should be discussed on www-style, not what-wg. If it helps with WinIE compatibility, I have no real objection to adding the property. I do find it unfortunate that Microsoft implemented this feature as a CSS property though. I think it should have been done as an extension to HTML instead. Turning off CSS shouldn't break the author's IME intent. 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
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
Re: [webkit-dev] a ping landed
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
