[webkit-dev] Request for position: CSS Ruby Layout Module

2020-09-23 Thread TAMURA, Kent
I'd like to request an official position of WebKit on CSS Ruby Layout
Module [1], especially on the following features in the specification:

- Ruby-specific 'display' property values: ruby, ruby-base, ruby-text,
ruby-base-container, ruby-text-container
- 'ruby-merge' property
- 'ruby-align' property, and remove 'text-align' property support for .
   with text-align is used in 0.002% of page views. [2]
- 'ruby-overhang' property

Note that Firefox already shipped them.


[1] https://drafts.csswg.org/css-ruby-1/
[2] https://www.chromestatus.com/metrics/feature/timeline/popularity/3313

-- 
TAMURA Kent
Software Engineer, Google
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Request for position: 'display: list-item' by default for

2020-09-23 Thread TAMURA, Kent
Hi,

I'd like to request an official position of WebKit on changing the default '
display' property value of  to 'list-item', and the relevant
changes below:
 - Add 'disclosure-closed' and 'disclosure-open' keywords to '
list-style-type' property
 - Add ::marker pseudo element selector support to 
 - Remove ::-webkit-details-marker pseudo element selector
   [1] is the usage counter for ::-webkit-details-marker, and it shows the
ratio of pages with elements matched to ::-webkit-details-marker in author
stylesheets.  Currently the ratio is 0.0%.

Firefox already shipped all of them.


Specification:
https://html.spec.whatwg.org/C/#the-details-and-summary-elements
Specification:
https://drafts.csswg.org/css-counter-styles-3/#disclosure-open

[1] https://chromestatus.com/metrics/feature/timeline/popularity/3337


-- 
TAMURA Kent
Software Engineer, Google
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] WebKit position on unprefixed 'appearance' CSS property

2020-01-15 Thread TAMURA, Kent
Hi,

We, Chromium project, would like to change -webkit-appearance CSS property
behavior so that it follows the current css-ui-4 draft [1], and I'd like to
know your opinions about the changes. Do you support each of the following
changes?

1) Add support of 'auto' keyword

2) Unship keywords which are not necessary for web compatibility
  Low usage keywords such as 'inner-spin-button'.  This doesn't mean we'll
remove painting code for such keywords. 'auto' keyword will be used instead.

3) Ship unprefixed 'appearance' property


[1] https://drafts.csswg.org/css-ui-4/#propdef-appearance


-- 
TAMURA Kent
Software Engineer, Google
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Do we need ENABLE(SQL_DATABASE) guards?

2014-12-15 Thread TAMURA, Kent

FYI.  We removed Web SQL support for Workers in Blink, and already shipped
the removal in Google Chrome stable channel.  The removal made the code
much simpler because we don't need synchronous-version classes.


On Sat, Dec 6, 2014 at 9:13 AM, Benjamin Poulain benja...@webkit.org
wrote:


I hope we will be able to get rid of WebSQL at some point. The guard would
be useful for cleanup.


But given how popular WebSQL is, I don't see us doing that anytime  
soon. :(



I am in favor of removing the flag.



Benjamin




On 12/5/14 6:38 AM, Osztrogonác Csaba wrote:



Hi all,



it seems ENABLE(SQL_DATABASE) is enabled on all ports,
but there are still ifdef guards for it in 300+ files.



Is there anybody shipping WebKit with disabled SQL_DATABASE?
If no, I'd propopse removing these guards.



br,
Ossy



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev




--
TAMURA Kent
Software Engineer, Google



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Do we need ENABLE(SQL_DATABASE) guards?

2014-12-15 Thread TAMURA, Kent

Yes.

openDatabase on WorkerGlobalScope:
https://www.chromestatus.com/metrics/feature/timeline/popularity/313

openDatabaseSync on WorkerGlobalScope:
https://www.chromestatus.com/metrics/feature/timeline/popularity/314

openDatabase on Window: (We can't remove this yet.)
https://www.chromestatus.com/metrics/feature/timeline/popularity/10


These graph contains a period in which Google Chrome still had Web SQL for
Workers.  However the usage was almost zero.


On Tue, Dec 16, 2014 at 9:43 AM, Benjamin Poulain benja...@webkit.org
wrote:


That's interesting information.



Did you add usage counters before the removal? Any idea how much usage
there is?



On 12/15/14 4:28 PM, TAMURA, Kent wrote:



FYI.  We removed Web SQL support for Workers in Blink, and already
shipped the removal in Google Chrome stable channel.  The removal made
the code much simpler because we don't need synchronous-version classes.




On Sat, Dec 6, 2014 at 9:13 AM, Benjamin Poulain benja...@webkit.org
mailto:benja...@webkit.org wrote:



 I hope we will be able to get rid of WebSQL at some point. The guard
 would be useful for cleanup.



 But given how popular WebSQL is, I don't see us doing that anytime
 soon. :(



 I am in favor of removing the flag.



 Benjamin




 On 12/5/14 6:38 AM, Osztrogonác Csaba wrote:



 Hi all,



 it seems ENABLE(SQL_DATABASE) is enabled on all ports,
 but there are still ifdef guards for it in 300+ files.



 Is there anybody shipping WebKit with disabled SQL_DATABASE?
 If no, I'd propopse removing these guards.



 br,
 Ossy



 _
 webkit-dev mailing list
 webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
 https://lists.webkit.org/__mailman/listinfo/webkit-dev
 https://lists.webkit.org/mailman/listinfo/webkit-dev




 _
 webkit-dev mailing list
 webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
 https://lists.webkit.org/__mailman/listinfo/webkit-dev
 https://lists.webkit.org/mailman/listinfo/webkit-dev





--
TAMURA Kent
Software Engineer, Google






--
TAMURA Kent
Software Engineer, Google



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Is anyone interested in maintaining INPUT_SPEECH?

2014-08-05 Thread TAMURA, Kent

FYI. It was removed from Blink too.


On Wed, Aug 6, 2014 at 11:40 AM, Benjamin Poulain benja...@webkit.org
wrote:


Hi,



Is anyone interested in INPUT_SPEECH?



It looks like no port enable that feature. The code looks unmaintained.
Everyone skip all the tests.



I will remove the code if nobody maintains it.



Benjamin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev





--
TAMURA Kent
Software Engineer, Google



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Are Qt and GTK+ intentionally returning false in shouldShowPlaceholderWhenFocused?

2013-08-20 Thread TAMURA, Kent

FYI.
Chromium and Firefox have shouldShowPlaceHolderWhenFocused==true behavior
in all platforms.
Web authors can specify shouldShowPlaceHolderWhenFocused==false behavior
with CSS if the default is shouldShowPlaceHolderWhenFocused==true, but they
can't specify shouldShowPlaceHolderWhenFocused==true behavior if the
default is shouldShowPlaceHolderWhenFocused==false.



On Tue, Aug 20, 2013 at 2:16 PM, Ryosuke Niwa rn...@webkit.org wrote:


Hi,



Once my patch for https://bugs.webkit.org/show_bug.cgi?id=120049 is
landed, Mac port will no longer return false in
shouldShowPlaceholderWhenFocused.



Mac, Windows, and EFL all return true in this function.



Are Qt and GTK+ (and other) ports intentionally returning false
in shouldShowPlaceholderWhenFocused?  Or is this just an oversight due to
the fact the default implementation returned false?




- R. Niwa




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev





--
TAMURA Kent
Software Engineer, Google



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Using ENABLE_INPUT_MULTIPLE_FIELDS_UI and/or ENABLE_CALENDAR_PICKER

2013-05-26 Thread TAMURA, Kent

It seems no one is interested in them.
Ok, I'll remove them.

https://bugs.webkit.org/show_bug.cgi?id=116795
https://bugs.webkit.org/show_bug.cgi?id=116796



On Mon, May 20, 2013 at 6:15 AM, TAMURA, Kent tk...@chromium.org wrote:


Is any port interested in using ENABLE_INPUT_MULTIPLE_FIELDS_UI and/or
ENABLE_CALENDAR_PICKER ?



Don't you know what they are? Please look at [1]. These flags provide
date/time input controls like desktop Google Chrome.
These flags were enabled only in Chromium port, and they are dead code in
WebKit for now. If no port has a plan to use them, we had better remove
them.




[1] http://trac.webkit.org/wiki/EnableFormFeatures



--
TAMURA Kent
Software Engineer, Google






--
TAMURA Kent
Software Engineer, Google



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Using ENABLE_INPUT_MULTIPLE_FIELDS_UI and/or ENABLE_CALENDAR_PICKER

2013-05-19 Thread TAMURA, Kent

Is any port interested in using ENABLE_INPUT_MULTIPLE_FIELDS_UI and/or
ENABLE_CALENDAR_PICKER ?

Don't you know what they are? Please look at [1]. These flags provide
date/time input controls like desktop Google Chrome.
These flags were enabled only in Chromium port, and they are dead code in
WebKit for now. If no port has a plan to use them, we had better remove
them.


[1] http://trac.webkit.org/wiki/EnableFormFeatures

--
TAMURA Kent
Software Engineer, Google



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Guide: How to enable Form features

2013-02-13 Thread TAMURA, Kent

We made a wiki page to describe how to enable HTML5 form-related features:
http://trac.webkit.org/wiki/EnableFormFeatures

If you have questions, please ask me and Keishi Hattori.


--
TAMURA Kent
Software Engineer, Google



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Please do not enable ENABLE_INPUT_TYPE_DATETIME

2013-01-24 Thread TAMURA, Kent

Unfortunately I don't have data on mobile-targeted sites.  The number
'0.08% of input[type=date]' came from Google's web search repository.  So
it is basically on desktop-targeted sites.




On Tue, Jan 22, 2013 at 5:54 PM, Maciej Stachowiak m...@apple.com wrote:



On Jan 22, 2013, at 12:32 AM, TAMURA, Kent tk...@chromium.org wrote:





 The two mail threads bounce back and forth between Hixie's opinion and
 yours. Was there a conclusion reached anywhere on what to do with
datetime
 and datetime-local?

 We agreed that existing implementations of input[type=datetime] were
wrong.
 But we have no
 conclusion of the type renaming and the expected UI.
 So, I don't think we can provide reasonable implementation of
 input[type=datetime] in WebKit
 anytime soon, and we had better stop shipping the wrong implementation
 before it is used widely.



Do we have any data on how much usage there is currently (most
particularly on mobile-targeted sites)?



Regards,
Maciej





--
TAMURA Kent
Software Engineer, Google



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Please do not enable ENABLE_INPUT_TYPE_DATETIME

2013-01-22 Thread TAMURA, Kent




The two mail threads bounce back and forth between Hixie's opinion and
yours. Was there a conclusion reached anywhere on what to do with datetime
and datetime-local?


We agreed that existing implementations of input[type=datetime] were wrong.
But we have no
conclusion of the type renaming and the expected UI.
So, I don't think we can provide reasonable implementation of
input[type=datetime] in WebKit
anytime soon, and we had better stop shipping the wrong implementation
before it is used widely.


--
TAMURA Kent
Software Engineer, Google

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Please do not enable ENABLE_INPUT_TYPE_DATETIME

2013-01-21 Thread TAMURA, Kent




Please do not enable ENABLE_INPUT_TYPE_DATETIME to ship input
type=datetimeimplementation in your products.



What do you recommend for products that have shipped it already?


I recommend to disable it in the next release of the products.  I'll
disable it for Android Chrome.

It's an incompatible change. However I think it won't have large impact
because the number
of input[type=datetime] in the web is only 0.08% of the number of
input[type=date]



--
TAMURA Kent
Software Engineer, Google
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Please do not enable ENABLE_INPUT_TYPE_DATETIME

2013-01-20 Thread TAMURA, Kent

Please do not enable ENABLE_INPUT_TYPE_DATETIME to ship input
type=datetimeimplementation in your products.

We had some discussion in WHATWG [1] [2] and realized input type=datetime
UIs in iOS Safari and Android Chrome are wrong and harmful. The current
code for input type=datetime in WebCore can't make a reasonable UI and
should not be shipped in products.


For other new input types, they are ready to implement platform-specific
code.  We're going to post an implementation guide or make a wiki page to
explain what is needed.


[1]
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/thread.html#msg119
[2]
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jan/thread.html#msg45

--
TAMURA Kent
Software Engineer, Google
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] New feature announcemnt: ValidityState::badInput

2012-11-20 Thread TAMURA, Kent

I'd like to start to implement ValidityState::badInput, which was
introduced in the WHATWG HTML specification [1] some hours ago.

This is a small addition to the Form validation feature.

Bug: webkit.org/b/102861
Flag plan: No ENABLE flag
Prefix plan: No vendor prefix


[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#dom-validitystate-badinput


--
TAMURA Kent
Software Engineer, Google




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] New WebKit reviewer: Yuta Kitamura

2012-09-13 Thread TAMURA, Kent

I'd like to announce that Yuta Kitamura yu...@chromium.org is now a
WebKit reviewer.

He has contributed to WebKit project for three years mainly in WebSocket
area. He is a trustworthy authority on WebSocket area. If you worked on
WebSocket issues, please involve him.

--
TAMURA Kent
Software Engineer, Google

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Forms: Re-implement validation message implementation

2012-08-30 Thread TAMURA, Kent

The current implementation of the form validation message UI [1] is built
of Shadow DOM.  I'll change the implementation so that it doesn't use
Shadow DOM, but uses native code via ChromeClient to show bubble message UI.

Shadow DOM is good to build platform-independent UI, but I realized it
didn't fit for such popup-like UI. We have some bug reports for Chromium.
crbug.com/90958
crbug.com/92816
crbug.com/90252
crbug.com/106621
crbug.com/113352
crbug.com/115451


I'll add a compile flag for the new implementation
(WTF_USE_NATIVE_VALIDATION_MESSAGE_UI ?), and will remove the current
implementation when all of ports have platform-specific part of the new
implementation.

Master bug for this change: https://bugs.webkit.org/show_bug.cgi?id=95527

--
TAMURA Kent
Software Engineer, Google



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Using the WebExposed keyword for web-facing changes

2012-06-10 Thread TAMURA, Kent

Do you want WebExposed for a simple bug fix of an existing feature? Do you
want it for bugs with no patches?

On Sat, Jun 9, 2012 at 5:24 AM, Peter Beverloo pe...@chromium.org wrote:


Hi webkit-dev,



*If you work on web-facing features, or run into another bug which does,
please consider adding the WebExposed keyword to it.*



Many of you will be familiar with my WebKit updates, which are now also
being published on the WebKit blog. Writing these involves reading every
commit that lands in WebKit's repository. Last year, May counted 2,126
revisions. This year there were 3,068. As a result of the steep increase  
in

volume, it's becoming increasingly hard for all parties to keep up --
Web(Kit) developers, ports and all other interested parties. Not every one
of them has time to read through all changes.



In an effort to increase visibility of Web Platform facing changes, I'd
like to introduce the WebExposed keyword. It is intended to be applied  
to

any bug which introduces, modifies (including behavioral changes) or
removes features important to Web developers, such as DOM properties and
methods, JavaScript features and CSS properties and values.



https://bugs.webkit.org/buglist.cgi?keywords=WebExposed



Increased visibility of these changes has a number of advantages.



Firstly, Web Developers will have more insight in what's happening in
WebKit. The changes will be visible on the bug list itself, but also
through the RSS feed Bugzilla will curate for it.



Furthermore, it may be used as an overview for ports to keep track of the
web-facing changes which happen during their release cycles, and it will
also come in useful for evangelizing features, writing documentation and
managing outreach. With work being done by many vendors in many areas of
WebCore, I'm hoping the keyword can become a valuable aid in this respect.



If you work on web-facing features, or run into another bug which does,
please consider adding the WebExposed keyword to it. This of course  
isn't

mandatory, but it will help others who are interested in keeping track.



Thanks,
Peter



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev





--
TAMURA Kent
Software Engineer, Google



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Adding ENABLE_HTML_MEDIA_CAPTURE to WebCore

2012-05-09 Thread TAMURA, Kent

I wonder if the standardization is active.  Even the editor's draft has not
been updated for one year.

On Mon, Feb 20, 2012 at 1:44 PM, JongSeok Yang js45.y...@samsung.comwrote:



Hi webkit-dev!



I want to let you know that I plan to add HTML Media Capture to WebKit.
HTML Media Capture :
http://www.w3.org/TR/2011/WD-html-media-capture-20110414/



The spec has two sparate features - 1) to invoke a capture panel  2)
WebIDL inteface for MediaFile.getFormatData()
First, my plan is just to implement the interface to invoke a capture
panel and it will be behind the ENABLE_HTML_MEDIA_CAPTURE feature define.
See: https://bugs.webkit.org/show_bug.cgi?id=63062



I expect this feature to be eventually enabled by all ports.
If you have any commnet, please let me know.



Thank you.
Jongseok Yang.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev





--
TAMURA Kent
Software Engineer, Google



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] When should we turn on new features?

2012-03-15 Thread TAMURA, Kent

I made https://trac.webkit.org/wiki/FeatureFlags .
I extracted all of ENABLE(FOO) in *.cpp and *.mm, and added some comments.
 Feel free to edit it!

On Wed, Mar 14, 2012 at 13:03, TAMURA, Kent tk...@chromium.org wrote:


I'll add a Wiki page for the table of existing feature flags and their
descriptions.




On Tue, Feb 14, 2012 at 11:09, Maciej Stachowiak m...@apple.com wrote:




I think we're talking about a couple of different things now:



1) Table of what the WebKit community as a whole (instead of individual
point maintainers) thinks should be enabled in stable releases. This  
would

be input to port maintainers looking to make a release.




2) Documenting what enable flags are actually on for given ports as
shipped. Probably hard to gather this info, but might be useful input for
the WebKit community.



3) Changing build systems to enable compiling nightly and stable
versions from the same tree, so both modes are documented in trunk.
Requires some coding for various build systems.



I like (2) and (3), but I don't think they replace the usefulness of (1).
I think the mention of the feature-table page is blending (2) and (1),
which would serve different purposes.



Regards,
Maciej




On Feb 13, 2012, at 4:21 PM, Hajime Morrita wrote:



 (Re-sending from the right address...)

 I'd +1 Adam's point.

 It would be great if we can do something like webkit-build --gtk
 --stable, webkit-build --chromium --canary or webkit-build
 --nightly where the script read the central configuration file and
 find an appropriate configuration. In this way, there would be no
 duplication we should maintain.

 Even though some ports currently don't support switches through
 build-webkit, we can gradually switch over to the central list-based
 configuration settings by, for example, generating features.gypi,
 FeatureDefines.xcconfig or a set of flags for autoconf.

 Also the feature-table page could be generated from the list. We can
 even start from simply generating an HTML from the machine-readable
 configuration file, then integrate it to each build system.

 Although it might be overkill, I personally prefer this kind of don't
 repeat youself direction.
 --
 morrita

 On Tue, Feb 14, 2012 at 8:11 AM, Maciej Stachowiak m...@apple.com
wrote:

 On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote:

 On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak m...@apple.com
wrote:

 I think you raise a good point. Another point worth mentioning is  
that

 sometimes a feature can be complete and useful in one port, but
half-baked
 in another (for example, fullscreen API was shipped in Safari and at
the
 same time present but non-functional in Chrome).

 I think in the past, port owners have made clear that they want to
own the
 final decisions on what features are enabled in their ports.

 But we as a community could do better, by having a shared
recommendation
 of what features we think should be enabled in shipping releases. In
some
 cases, this may not match the settings on trunk, as some features may
be
 desirable to enable for experimental builds, but not in shipping
product.
 For features that we recommended disabling, ideally we'd identify a
reason.
 And in some cases, those might be port-specific issues.


 Right. Even just having a list of new features with flag(s) to
 enable/disable and the status (e.g. list of outstanding bugs) on wiki
page
 will be helpful.

 For example, vertical writing mode doesn't work on Windows, Chromium,
etc...
 but port owners may not necessarily realize that the feature is
enabled by
 default and each port needs to modify the code that draws text.


 I personally think such a page would be a good idea. I'd love to hear
input
 from more folks on whether this is a good idea and what the right
approach
 is.

 Cheers,
 Maciej

 ___
 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






--
TAMURA Kent
Software Engineer, Google







--
TAMURA Kent
Software Engineer, Google




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] When should we turn on new features?

2012-03-13 Thread TAMURA, Kent

I'll add a Wiki page for the table of existing feature flags and their
descriptions.


On Tue, Feb 14, 2012 at 11:09, Maciej Stachowiak m...@apple.com wrote:



I think we're talking about a couple of different things now:



1) Table of what the WebKit community as a whole (instead of individual
point maintainers) thinks should be enabled in stable releases. This would
be input to port maintainers looking to make a release.




2) Documenting what enable flags are actually on for given ports as
shipped. Probably hard to gather this info, but might be useful input for
the WebKit community.



3) Changing build systems to enable compiling nightly and stable
versions from the same tree, so both modes are documented in trunk.
Requires some coding for various build systems.



I like (2) and (3), but I don't think they replace the usefulness of (1).
I think the mention of the feature-table page is blending (2) and (1),
which would serve different purposes.



Regards,
Maciej




On Feb 13, 2012, at 4:21 PM, Hajime Morrita wrote:



 (Re-sending from the right address...)

 I'd +1 Adam's point.

 It would be great if we can do something like webkit-build --gtk
 --stable, webkit-build --chromium --canary or webkit-build
 --nightly where the script read the central configuration file and
 find an appropriate configuration. In this way, there would be no
 duplication we should maintain.

 Even though some ports currently don't support switches through
 build-webkit, we can gradually switch over to the central list-based
 configuration settings by, for example, generating features.gypi,
 FeatureDefines.xcconfig or a set of flags for autoconf.

 Also the feature-table page could be generated from the list. We can
 even start from simply generating an HTML from the machine-readable
 configuration file, then integrate it to each build system.

 Although it might be overkill, I personally prefer this kind of don't
 repeat youself direction.
 --
 morrita

 On Tue, Feb 14, 2012 at 8:11 AM, Maciej Stachowiak m...@apple.com
wrote:

 On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote:

 On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak m...@apple.com
wrote:

 I think you raise a good point. Another point worth mentioning is that
 sometimes a feature can be complete and useful in one port, but
half-baked
 in another (for example, fullscreen API was shipped in Safari and at
the
 same time present but non-functional in Chrome).

 I think in the past, port owners have made clear that they want to own
the
 final decisions on what features are enabled in their ports.

 But we as a community could do better, by having a shared
recommendation
 of what features we think should be enabled in shipping releases. In
some
 cases, this may not match the settings on trunk, as some features may
be
 desirable to enable for experimental builds, but not in shipping
product.
 For features that we recommended disabling, ideally we'd identify a
reason.
 And in some cases, those might be port-specific issues.


 Right. Even just having a list of new features with flag(s) to
 enable/disable and the status (e.g. list of outstanding bugs) on wiki
page
 will be helpful.

 For example, vertical writing mode doesn't work on Windows, Chromium,
etc...
 but port owners may not necessarily realize that the feature is enabled
by
 default and each port needs to modify the code that draws text.


 I personally think such a page would be a good idea. I'd love to hear
input
 from more folks on whether this is a good idea and what the right
approach
 is.

 Cheers,
 Maciej

 ___
 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





--
TAMURA Kent
Software Engineer, Google




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] Additional two feature flags for input type=date

2012-02-16 Thread TAMURA, Kent

Hi,

I'd like to add two more feature flags for input type=date
implementation. We already have ENABLE_INPUT_TYPE_DATE.

* ENABLE_CALENDAR_PICKER
It enables graphical calendar picker UI for input type=date.  We need to
introduce this flag because we don't need the calendar picker on mobile
platforms such as iOS and Android.  Also, this flag will depend on the
following flag.
This flag will be used for input type=datetime and input
type=datetime-local too.

* ENABLE_HTML_POPUP
This is a framework to make a popup window which can contain an HTML
document.  This flag is needed because we don't need this if the calendar
picker is not needed, and this framework requires platform-dependent
implementation.
This framework is similar to IE's window.createPopup().  However I don't
have a plan to implement createPopup().


See a WIP patch in http://wkb.ug/53961 for more information though it
doesn't have these flags yet.

--
TAMURA Kent
Software Engineer, Google




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] More feature flags for input types (Re: New Feature Flag Proposal: INPUT_COLOR)

2011-10-04 Thread TAMURA, Kent

Filed a bug: https://bugs.webkit.org/show_bug.cgi?id=68971

On Mon, Aug 8, 2011 at 11:03, TAMURA, Kent tk...@chromium.org wrote:


 But is there any grouping we can do? Does each need a separate feature
flag?



I think separated feature flags are better.



Suppose that all types are in ENABLE_INCOMPLETE_INPUT_TYPES and we finish
to implement UI of one input type:
* We can't enable ENABLE_INCOMPLETE_INPUT_TYPES because other types are  
not

ready.
* If the UI requires port-specific code, we can't move the input type out
of ENABLE_INCOMPLETE_INPUT_TYPES flag for a port which already has the
port-specific code because other ports are not ready.
* Even if the UI is implemented by shadow DOM and requires no  
port-specific

code, mobile ports might need another implementation and might want to
disable the shadow DOM implementation.



If we introduce separated features flags, we won't have such issues.




On Sat, Aug 6, 2011 at 03:05, Darin Adler da...@apple.com wrote:



On Aug 4, 2011, at 6:40 PM, TAMURA, Kent wrote:



 Like INPUT_COLOR, I'd like to introduce feature flags for date,
datetime, datetime-local, month, time, and week types.
 * We're going to implement dedicated UIs for them, and will want to
disable it temporarily.
 * Their current implementations are insufficient and one might not want
to ship them in browsers, but they were already shipped in some browsers.



These are both good reasons to have a feature flag and I think it’s
critical we do that. But is there any grouping we can do? Does each need  
a

separate feature flag?



-- Darin






--
TAMURA Kent
Software Engineer, Google







--
TAMURA Kent
Software Engineer, Google



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] More feature flags for input types (Re: New Feature Flag Proposal: INPUT_COLOR)

2011-08-07 Thread TAMURA, Kent

But is there any grouping we can do? Does each need a separate feature

flag?

I think separated feature flags are better.

Suppose that all types are in ENABLE_INCOMPLETE_INPUT_TYPES and we finish to
implement UI of one input type:
* We can't enable ENABLE_INCOMPLETE_INPUT_TYPES because other types are not
ready.
* If the UI requires port-specific code, we can't move the input type out of
ENABLE_INCOMPLETE_INPUT_TYPES flag for a port which already has the
port-specific code because other ports are not ready.
* Even if the UI is implemented by shadow DOM and requires no port-specific
code, mobile ports might need another implementation and might want to
disable the shadow DOM implementation.

If we introduce separated features flags, we won't have such issues.


On Sat, Aug 6, 2011 at 03:05, Darin Adler da...@apple.com wrote:


On Aug 4, 2011, at 6:40 PM, TAMURA, Kent wrote:


 Like INPUT_COLOR, I'd like to introduce feature flags for date,  
datetime,

datetime-local, month, time, and week types.
 * We're going to implement dedicated UIs for them, and will want to
disable it temporarily.
 * Their current implementations are insufficient and one might not want
to ship them in browsers, but they were already shipped in some browsers.



These are both good reasons to have a feature flag and I think it’s
critical we do that. But is there any grouping we can do? Does each need a
separate feature flag?



-- Darin





--
TAMURA Kent
Software Engineer, Google




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] More feature flags for input types (Re: New Feature Flag Proposal: INPUT_COLOR)

2011-08-04 Thread TAMURA, Kent

Like INPUT_COLOR, I'd like to introduce feature flags for date, datetime,
datetime-local, month, time, and week types.
* We're going to implement dedicated UIs for them, and will want to disable
it temporarily.
* Their current implementations are insufficient and one might not want to
ship them in browsers, but they were already shipped in some browsers.

On Tue, May 24, 2011 at 09:57, Keishi Hattori kei...@webkit.org wrote:


Hi webkit-dev,



I just wanted to notify everyone that I will be adding a new feature
flag, INPUT_COLOR. http://webkit.org/b/61273



This flag will enable input type=color



I need this flag because the color picker UI needs to be implemented
individually for each platform, and it is going to take some time.



Also the current text field implementation will be disabled. This is
to avoid feature detection so that web pages can fall back to JS color
pickers.



Thanks!



Keishi
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev





--
TAMURA Kent
Software Engineer, Google




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Adding CSS3 font feature propreties

2011-06-29 Thread TAMURA, Kent

Do you have a master bug for them?


On Fri, Jun 24, 2011 at 12:16, Kenichi Ishibashi ba...@chromium.org wrote:


Hi webkit-dev,



I'm thinking about adding CSS3 font feature properties[1] support to
WebKit.  It allows page authors to control over advanced typographic
features.  Firefox has an experimental implementation and an article[2]
shows how these properties work.  I really would like to add this feature  
so

I'd like to ask comments and suggestions in advance.



My current plan is starting with adding the font-feature-settings property
(6.12 Low-level font setting control) as -webkit-font-feature-settings,
following a similar approach that Firefox did.  For OpenType fonts, other
properties can be treated as specific cases of the font-feature-settings
property and I think adding this property is good starting point.



One shortcomings of this approach is that it requires OpenType support for
each port.  A port which uses AAT might not be able to support this
property, or we need to add an extra text rendering subsystem which can
handle OpenType features to the port.



If I get started with this plan, I will start implementing css parsing
part, then implement font rendering part on a specific port (Chromium  
Linux

port is in mind for now) on trial.



I'd also like to put some notes of supporting CSS3 font feature properties
with AAT and CoreText here:
- AAT features are listed at [3].
- While the spec lists the equivalent OpenType feature tag for each
property, it is unclear that what AAT feature setting corresponds with  
each

property.  An email written by the spec editor[4] lists them partially but
not complehensive.
- [5] describes OpenType support of CoreText (I'm not sure this is  
correct,

though).



Comments and suggestions are highly appreciated.



[1] http://dev.w3.org/csswg/css3-fonts/#font-rend-props
[2] http://hacks.mozilla.org/2010/11/firefox-4-font-feature-support/
[3] http://developer.apple.com/fonts/registry/
[4] http://lists.w3.org/Archives/Public/www-style/2009Jun/0506.html
[5] http://en.wikipedia.org/wiki/OpenType_feature_tag_list



Regards,




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev





--
TAMURA Kent
Software Engineer, Google




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Writing a new XML parser with no external libraries

2011-06-28 Thread TAMURA, Kent

I'm a little negative of developing a new XML parser. I'm afraid that the
new parser introduces a lot of security/stability problems which existing
parsers already resolved.

How about importing Expat parser to WebKit repository and maintain it by
ourselves?


On Wed, Jun 29, 2011 at 10:12, Jeffrey Pfau jp...@apple.com wrote:


Currently, WebCore uses libxml2, or, if available, QtXml to parse incoming
XML. However, QtXml isn't always available, and using libxml2 exposes its
own share of problems. As such, I'm undertaking writing an XML parser that
uses no external libraries.



The first step to doing this is to add a new flag that switches off the
other two parsers. As the parsers are already independent and can be
switched between by checking USE(QXMLSTREAM), I am adding USE(LIBXML2)
checks, replacing the #else conditionals, and also a new ENABLE check,
tentatively called NEW_XML (although names such as NATIVE_XML or  
XML_NATIVE,

etc, may be more appropriate).



As there will probably be a new slew of files pertaining to XML parsing, I
will put these files in WebCore/xml/parser, and move the existing
XMLDocumentParser* file into this new directory. As far as I know, the
placement of these files in WebCore/dom/ is legacy, and, assuming the  
build

on each platform is changed, it makes sense to move them.



Once all the files are in a logical place, I plan to make a new file for a
skeleton of the new XMLDocumentParser, at least to get it to link until a
real one is in place, even if the XML parser at that point is just a data
sink.



 From there, I plan to copy and modify a good chunk of the lower level HTML
tokenization and parsing code, and make changes as necessary to make it  
work
on generalized XML, at least until I can generalize the common code in  
such

a way that the HTML and XML tokenizers can be subclasses and use common
code. I'd probably do the refactoring at the end.


I'm still exploring the existing parsing code, but I'd probably work my  
way
up from there. I've read a lot of the XML 1.0 spec in preparation, as  
well,

but it doesn't have much on implementation itself. If QtWebKit or parsing
people have any comments, concerns, or help, I'd be more than willing to
listen--I'm just starting here, and I'm not completely familiar with the
codebase.



Although no code is checked in so far, I've started on this list already
and have gotten as far as the new flags, a skeleton
XMLDocumentParserNew.cpp, and making a tokenizer that compiles and links,
but is completely untested.



Jeffrey Pfau
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev





--
TAMURA Kent
Software Engineer, Google




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Experimental cr-linux-ews now runs tests

2011-06-07 Thread TAMURA, Kent

Is it woking for now?
I posted a patch which must fail on Chromium-linux, but the EWS didn't post
any errors.
https://bugs.webkit.org/show_bug.cgi?id=62196

On Tue, May 3, 2011 at 10:37, Adam Barth aba...@webkit.org wrote:


The result of the experiment is success!  These are now running for
real.  I'm not sure how much capacity we'll need.  I've got three
instances running now.  We'll see if that's enough.



If you see any strange behavior, let me know.



Thanks!
Adam




On Fri, Apr 22, 2011 at 9:08 PM, Adam Barth aba...@webkit.org wrote:
 I just wanted to let you know that I'm experimenting with having
 Chromium Linux EWS bots run the LayoutTests.  There are a bunch of
 bugs to work out, but it seems to be more or less working with a bunch
 of local hacks.  Please don't be surprised if the bot acts strangely
 for a while.

 Thanks!
 Adam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev





--
TAMURA Kent
Software Engineer, Google




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Experimental cr-linux-ews now runs tests

2011-06-07 Thread TAMURA, Kent

* My patch updates the render tree dump of thumbslider-no-parent-slider.html
significantly.
* Chromium-linux has an old result,
platform/chromium-win/fast/forms/thumbslider-no-parent-slider-expected.txt.
  (Chromium-linux searches chromium-win directory for fallback results.)
* test_expectations.txt doesn't contain the test.

On Wed, Jun 8, 2011 at 14:05, Adam Barth aba...@webkit.org wrote:


Why must it fail on Chromium Linux?  We're not running pixel tests
yet, if that's what you're concerned about.



Adam




On Tue, Jun 7, 2011 at 9:49 PM, TAMURA, Kent tk...@chromium.org wrote:
 Is it woking for now?
 I posted a patch which must fail on Chromium-linux, but the EWS didn't
post
 any errors.
 https://bugs.webkit.org/show_bug.cgi?id=62196

 On Tue, May 3, 2011 at 10:37, Adam Barth aba...@webkit.org wrote:

 The result of the experiment is success!  These are now running for
 real.  I'm not sure how much capacity we'll need.  I've got three
 instances running now.  We'll see if that's enough.

 If you see any strange behavior, let me know.

 Thanks!
 Adam


 On Fri, Apr 22, 2011 at 9:08 PM, Adam Barth aba...@webkit.org wrote:
  I just wanted to let you know that I'm experimenting with having
  Chromium Linux EWS bots run the LayoutTests.  There are a bunch of
  bugs to work out, but it seems to be more or less working with a  
bunch

  of local hacks.  Please don't be surprised if the bot acts strangely
  for a while.
 
  Thanks!
  Adam
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



 --
 TAMURA Kent
 Software Engineer, Google









--
TAMURA Kent
Software Engineer, Google




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Dropping support for WML?

2011-04-26 Thread TAMURA, Kent

I think it's ok to keep WML code if we can avoid the form control issue.
We can terminate the form control abstraction for HTML and WML. e.g.

- Merge dom/InputElement to html/HTMLInputElement
- Merge dom/InputElement to wml/WMLInputElement
- Remove dom/InputElement
- Copy RenderTextControlSingleLine as RenderTextControlWML
- RenderTextControlSingleLine only supports HTMLInputElement
- RenderTextControlWML only supports WMLInputElement

We would have some duplicated code.  But it would be better than the current
situation.


On Fri, Apr 8, 2011 at 10:08, Darin Adler da...@apple.com wrote:


On Apr 8, 2011, at 2:09 AM, Ryosuke Niwa wrote:


 We have been discussing the possibility of dropping WML support in  
WebKit

on IRC for a while now because
   • None of core ports (Mac, Windows, GTK, Qt,  Chromium) use it by
default
   • Maintenance cost is high



I’ll just add one other thing: HTML form element implementations have
factoring that are twisted and complicated because of WML in a way that
makes working on those classes unpleasant for me. It would make form work
considerably easier if we drop WML support.



-- Darin



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev





--
TAMURA Kent
Software Engineer, Google




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Script programming language: Perl, Python, or Ruby?

2010-09-01 Thread TAMURA, Kent

Thanks.
So porting PrettyPatch to Python will make good benefit and should have no
drawbacks.  I should go ahead.

On Wed, Sep 1, 2010 at 09:21, William Siegrist wsiegr...@apple.com wrote:


On Aug 31, 2010, at 4:43 PM, TAMURA, Kent wrote:



   Can we run python scripts on bugs.webkit.org server?



Yes.



-Bill





--
TAMURA Kent
Software Engineer, Google




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] Script programming language: Perl, Python, or Ruby?

2010-08-31 Thread TAMURA, Kent

Do we have any recommendation of programming language for scripts such as
WebKitTools/Scripts?
It seems new scripts are written by Python and Ruby code is very rare.

Is it reasonable to port a Ruby script to Python?
I tried to port PrettyPatch.rb to Python in
https://bugs.webkit.org/show_bug.cgi?id=43617 in order to remove Ruby
dependency for many developers and buildbots.  However bdash objected it.

--
TAMURA Kent
Software Engineer, Google




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Script programming language: Perl, Python, or Ruby?

2010-08-31 Thread TAMURA, Kent

WebKitTools/iExploder has some ruby scripts.
  
LayoutTests/platform/mac/fast/loader/resources/mimeTypeExamples/example-rb.rb

is an empty file.  I don't know others.

PrettyPatch on Python would remove Ruby dependency from new-run-webkit-tests
and webkit-patch. But I'm not sure if we can remove BugsSite/PrettyPatch.
 Can we run python scripts on bugs.webkit.org server?

On Wed, Sep 1, 2010 at 04:26, Dirk Pranke dpra...@chromium.org wrote:


I think generally most scripts are written in Python nowadays, and we
have a large legacy of perl scripts that are getting ported over.



bdash mentions in the bug that there are other scripts written in Ruby
besides PrettyPatch, but that's news to me. What are they, and what
are they used for? Is there a particular reason that they're in Ruby?



I agree with Jeremy that, all other things being equal, fewer
languages is better, and I'm not sure that Ruby offers many compelling
advantages over Python (disclaimer: I personally like Ruby the
language better than Python, although I have a lot more experience w/
Python than I do w/ Ruby).



On Tue, Aug 31, 2010 at 7:56 AM, TAMURA, Kent tk...@chromium.org wrote:
 Do we have any recommendation of programming language for scripts such  
as

 WebKitTools/Scripts?
 It seems new scripts are written by Python and Ruby code is very rare.
 Is it reasonable to port a Ruby script to Python?
 I tried to port PrettyPatch.rb to Python
 in https://bugs.webkit.org/show_bug.cgi?id=43617 in order to remove Ruby
 dependency for many developers and buildbots.  However bdash objected  
it.

 --
 TAMURA Kent
 Software Engineer, Google




 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev







--
TAMURA Kent
Software Engineer, Google




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] IDL attribute vs Content attribute?

2010-06-02 Thread TAMURA, Kent

http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#terminology

IDL attributes mean properties of JavaScript objects defined by IDLs.
Content attributes mean HTML/XML attributes.

2010/6/3 Prasad Tammana pras...@chromium.org


I'm looking at the HTML5 spec for the command element and it talks about
IDL attributes vs Content attributes?  What does each mean?



Thanks,
Prasad



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev





--
TAMURA Kent
Software Engineer, Google



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Style question: static, protected, or public members

2010-05-25 Thread TAMURA, Kent

2010/5/25 Darin Adler da...@apple.com


On May 20, 2010, at 8:54 PM, TAMURA, Kent wrote:



 What's the naming rule for non-const static members?

 Some classes give s_ prefixes:
 WebCore/page/DOMTimer.h:        static double s_minTimerInterval;
 WebCore/page/GeolocationPositionCache.h:    static int s_instances;

 FrameView gives s prefix:
 WebCore/page/FrameView.h:    static double sCurrentPaintTimeStamp; //  
used for detecting decoded resource thrash in the cache


 Settings gives g prefix:
 WebCore/page/Settings.h:        static bool gShouldPaintNativeControls;
 WebCore/page/Settings.h:        static bool  
gShouldUseHighResolutionTimers;



If we have to use a prefix for this, I suggest the s_ prefix.


I think s_ is reasonable.

 And what about public and protected members?  The style guide has no  
exceptions for them, so I think they should have m_.  But many classes in  
WebCore don't use m_ for public members.


Generally speaking I suggest we do not use the m_ prefix for the  
members of structs. And I suggest that classes with public data members  
be structs instead of classes. Classes that have public data members only  
for historical reasons should be changed so the data members are not  
public. We should talk some specific examples.


ok, public data members in classes should be changed.
As for protected data members, many classes use m_ prefix.
I found protected members without m_ in HTMLTableCellElement and
HTMLTableColElement.  I guess they are legacy code and we should use m_
for protected members too.

--
TAMURA Kent
Software Engineer, Google



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] Style question: static, protected, or public members

2010-05-20 Thread TAMURA, Kent

What's the naming rule for non-const static members?

Some classes give s_ prefixes:
WebCore/page/DOMTimer.h:static double s_minTimerInterval;
WebCore/page/GeolocationPositionCache.h:static int s_instances;

FrameView gives s prefix:
WebCore/page/FrameView.h:static double sCurrentPaintTimeStamp; // used
for detecting decoded resource thrash in the cache

Settings gives g prefix:
WebCore/page/Settings.h:static bool gShouldPaintNativeControls;
WebCore/page/Settings.h:static bool gShouldUseHighResolutionTimers;


And what about public and protected members?  The style guide has no
exceptions for them, so I think they should have m_.  But many classes in
WebCore don't use m_ for public members.

--
TAMURA Kent
Software Engineer, Google



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] FYI: Buildbot monitor extension for Chrome

2010-02-16 Thread TAMURA, Kent

https://chrome.google.com/extensions/detail/dfomjpbnljkkohdofbhnphphdkaojklg

https://chrome.google.com/extensions/detail/dfomjpbnljkkohdofbhnphphdkaojklgI
made a Chrome extension to monitor WebKit buildbot status.
It shows a red badge when any of Leopard/Windows build/Chromium bots is red.
It is the same rule as our commit-queue, and you can change the set of bots
with the option view.


--
TAMURA Kent
Software Engineer, Google



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Implementation thoughts on HTML5 elements

2009-12-25 Thread TAMURA, Kent
. Are there real use cases for all 6? Do all 6 exhaustively
cover the types of time and date input you may want to do in forms?






___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev





--
TAMURA Kent
Software Engineer, Google



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Proposing style guide change regarding braces on conditional arms

2009-12-02 Thread TAMURA, Kent




Are you satisfied with the existing rule, then?  If so, you would be the
first developer I have asked who is.




I am satisfied with the existing rule.



I'm frustrated by this existing rule.
I would be very happy if the rule was changed to We may omit braces for
one-line control clauses.

--
TAMURA Kent
Software Engineer, Google
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] Character encoding of ChangeLog

2009-09-11 Thread TAMURA, Kent

What's the encoding of ChangeLog files? UTF-8 or ISO-8859-something?They
have some non-ASCII characters and my editor can't detect their encodings.

--
TAMURA Kent
Software Engineer, Google




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] unwritten rules of webkit style

2009-09-02 Thread TAMURA, Kent




{} should be added in this case:




if (condition1  condition2)
 statement;




Not according to current WebKit style because it is a single line
statement.



I don't like this rule. We need to be careful to add/remove a sentence in an
existing block, need to guess how many sentences to be added when we add
if.

A few days ago, this rule brought a real bug to me.

Existing code:
  if (attr-name() == fooAttr)
  doSometing();
  else if (attr-name() == barAttr) ...

I added if like:

  if (attr-name() == fooAttr)
  if (isBaz())
  doSometing();
  else if (attr-name() == barAttr) ...

The else clause unexpectedly attached to if (isBaz())
I wasted about an hour to found this bug.

--
TAMURA Kent
Software Engineer, Google



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] HTML5 Forms UI Proposal

2009-06-29 Thread TAMURA, Kent

Hi all,

Michelangelo De Simone (a Google Summer of Code student) and I
(Google) are working on implemenation of HTML5 Forms.  The following
page is a proposal of the validation UI and the UI of the input types:

http://docs.google.com/View?id=dch3zh37_0cf8kc8c4

Any comments?

We'll start the implementation for WebKit soon.
Don't suppose this proposal is *final*.  We would change the UI after
implementing the proposal if the implemented UI was not good.

--
TAMURA, Kent
Software Engineer, Google



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] HTML5 Forms UI Proposal

2009-06-29 Thread TAMURA, Kent

Yeah, I understand we should use native controls.  However, AFAIK neither
Mac OS nor Windows has a native control for input type=week and we need
to create it and keep consistency with other types.

Of course the implementation will be multiple bugs and patches.  But the
design should be consistent.

On Mon, Jun 29, 2009 at 16:16, Eric Seidele...@webkit.org wrote:

In general we mimic native controls on all platforms.  I don't think
WebKit has ever invented any controls before, but I could be wrong.



I think more interesting than a comprehensive document is individual
bugs and patches to add these.  These are small features.  I don't
think there is much that needs to be said in an over-arching design
doc.



Adele Peterson is probably the right person to talk to about Forms.
Entertainingly she worked with Michelangelo last summer as his GSoC
mentor.



-eric



On Mon, Jun 29, 2009 at 12:04 AM, TAMURA, Kenttk...@chromium.org wrote:

Hi all,



Michelangelo De Simone (a Google Summer of Code student) and I
(Google) are working on implemenation of HTML5 Forms.  The following
page is a proposal of the validation UI and the UI of the input types:



http://docs.google.com/View?id=dch3zh37_0cf8kc8c4



Any comments?



We'll start the implementation for WebKit soon.
Don't suppose this proposal is *final*.  We would change the UI after
implementing the proposal if the implemented UI was not good.



--
TAMURA, Kent
Software Engineer, Google





___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev






--
TAMURA Kent
Software Engineer, Google




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev