[webkit-dev] Request for position: CSS Ruby Layout Module
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
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
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?
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?
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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
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?
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?
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
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)
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)
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)
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
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
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
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
* 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?
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?
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?
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?
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?
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/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
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
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
. 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
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
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
{} 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
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
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
