Re: [webkit-dev] WebKit Contributors Meeting 2014 - UPDATED DATES
I’ll only be at the meeting on Tuesday (I’ve already booked the flight back to Seattle and vacation starting Wednesday). So I’ll be lurking in the vicinity on Monday - if anyone has suggestions on a good place to hang out nearby (good wifi, perhaps espresso?) please contact me off-list. Thanks, Alan On 3/25/14, 4:15 PM, Sam Weinig wei...@apple.com wrote: Hi all, I’m really sorry abut this, but we have to move the WebKit Contributors Meeting by one day. We previously told you that the meeting will be Monday, April 14th and Tuesday, April 15th but instead it will be Tuesday, April 15th and Wednesday, April 16th. So just to be clear: the new dates for the meeting are Tuesday, April 15th and Wednesday, April 16th. I apologize for any inconvenience. - Sam ___ 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
Re: [webkit-dev] Feature removal: CSS variables
Andreas, Don't take the ranking in that poll as an indicator. There's no way to compare interest in Variables against the other specifications, as it was omitted from the original poll and the only data points are from write-ins. That's what the gray styling means in the page you linked. I have no strong opinion on your implementation and syntax concerns. Thanks, Alan On 4/7/13 9:36 AM, Andreas Kling akl...@apple.com wrote: Hi WebKittens! I'd like to remove the CSS variable feature from the tree now that Chromium has left, as they were the only ones shipping it AFAIK. The feature is awkwardly implemented, the syntax has not been well received by web developers, and in the CSS WG priorities poll[1] last October, there was very little interest in the spec (it ranked 50 out of 58.) Unless there are any objections, I'll be pursuing the removal here: https://bugs.webkit.org/show_bug.cgi?id=114119 -Andreas [1] http://disruptive-innovations.com/zoo/customers/CSSWG/Priorities.html ___ 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
Re: [webkit-dev] New feature: CSS3 GCPM
On 8/20/12 10:07 AM, David Hyatt hy...@apple.com wrote: On Aug 20, 2012, at 11:32 AM, Peter Beverloo wrote: Addendum: The current Editor's Draft is significant different from the published WD, and includes something similar to CSS Exclusions. Since Adobe is implementing these in WebKit, it may be good to know what your ideas on these are as well :-). http://dev.w3.org/csswg/css3-gcpm/ Thanks, Peter We're not touching the controversial stuff. :) Specifically we're looking into implementing the screen pagination mode (paged-x/paged-y overflow) and the associated features that come along with that. We're also going to implement page floats and the general improvements to multi-column layout that are in the draft. Do the multi-column improvements you're considering include column selectors? Thanks, Alan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Multiple inheritance in the DOM
On 7/26/12 2:36 PM, Adam Barth aba...@webkit.org wrote: On Thu, Jul 26, 2012 at 2:29 PM, Alexandru Chiculita ach...@adobe.com wrote: I don't see any advantage in having the interface anyway, so why don't we just it let be a separate object and add two helper methods instead. I can only imagine that other browsers might have the same issue anyway. document.getRegionForElement(element) - where element can be both Element and CSSPseudoElement - this may return null in case of no region being associated, so there's no need for instanceof tricks anymore. region.element - that can return either Element or CSSPseudoElement BTW, is there any base class shared across Element and CSSPseudoElement? Greping for CSSPseudoElement in WebCore appears to return zero results. Discussing this issue with Sam in #webkit, we wondered whether another solution is to not implement the CSSOM for Regions. Is there are strong use case for having this CSSOM in the first place? Adam CSSPseudoElement is something I want to bring up soon in the CSS WG. Future extensions like this as to what can become a CSS Region is the motivation for separating out the Region interface. Whether there's a shared base class that makes sense is still to be determined. There are strong use cases for the object model for CSS Regions. Adobe has projects we'd like to base on CSS Regions, and script access will be vital for these efforts. We've also been building prototypes of other CSS extensions using the CSS Regions OM. I understand that there are projects based on IE10's version of CSS Regions where script access is required. And in general I'd rather avoid adding new things to the platform that are opaque to scripting. For Alex's suggestion above, would there be any problems with a parameter (for the first method) and return type (for the second) that could be an Element or something else? Adding two helper methods seems messier to me than what's currently specced, but I'm open to the idea if it's much easier to implement. Thanks, Alan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Multiple inheritance in the DOM
On 7/26/12 3:15 PM, Adam Barth aba...@webkit.org wrote: On Thu, Jul 26, 2012 at 2:58 PM, Alan Stearns stea...@adobe.com wrote: On 7/26/12 2:36 PM, Adam Barth aba...@webkit.org wrote: ... Discussing this issue with Sam in #webkit, we wondered whether another solution is to not implement the CSSOM for Regions. Is there are strong use case for having this CSSOM in the first place? Adam ... There are strong use cases for the object model for CSS Regions. Adobe has projects we'd like to base on CSS Regions, and script access will be vital for these efforts. We've also been building prototypes of other CSS extensions using the CSS Regions OM. I understand that there are projects based on IE10's version of CSS Regions where script access is required. And in general I'd rather avoid adding new things to the platform that are opaque to scripting. That all seems very vague. Can you explain what you have in mind? Here's a few: 1. Modifying the region chain based on content changes or window resizing. This could involve adding or removing CSS Regions, or changing region geometry. 2. Handing events on named flow contents - using the OM to determine the CSS Region(s) that contain the content. 3. Layout extensions implemented via script (script-based layout constraints can change region chain geometry). 4. Paginated views that use script to navigate or search (use the OM to determine the page to display). Thanks, Alan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Multiple inheritance in the DOM
On 7/25/12 4:49 PM, Kentaro Hara hara...@chromium.org wrote: A) Should we push back on the folks writing the CSS Regions specification to avoid using multiple inheritance? As far as I know, this is the only instance of multiple inheritance in the platform. Historically, EventTarget used multiple inheritance, but that's been fixed in DOM4 [4]. If it is possible to avoid the multiple inheritance, that would be best. From the WebIDL side, it's not strictly multiple inheritance. It's merely a supplemental interface that more than one object can implement. None of the members of the Region interface can clash with any of the members of the object that implements it. Right now Elements can become CSS Regions, but in the future other objects will be able to become CSS Regions. As far as I know, the correct way to specify this kind of relation is with WebIDL supplemental interfaces. I'd rather figure out the correct way to add this WebIDL functionality to WebKit now, than put something else into the spec and WebKit that we'll have to change later. Thanks, Alan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Multiple inheritance in the DOM
On 7/25/12 5:37 PM, Sam Weinig s...@webkit.org wrote: On Jul 25, 2012, at 5:13 PM, Alan Stearns stea...@adobe.com wrote: On 7/25/12 4:49 PM, Kentaro Hara hara...@chromium.org wrote: A) Should we push back on the folks writing the CSS Regions specification to avoid using multiple inheritance? As far as I know, this is the only instance of multiple inheritance in the platform. Historically, EventTarget used multiple inheritance, but that's been fixed in DOM4 [4]. If it is possible to avoid the multiple inheritance, that would be best. From the WebIDL side, it's not strictly multiple inheritance. It's merely a supplemental interface that more than one object can implement. None of the members of the Region interface can clash with any of the members of the object that implements it. Right now Elements can become CSS Regions, but in the future other objects will be able to become CSS Regions. As far as I know, the correct way to specify this kind of relation is with WebIDL supplemental interfaces. I'd rather figure out the correct way to add this WebIDL functionality to WebKit now, than put something else into the spec and WebKit that we'll have to change later. Thanks, Alan What other objects do you envision implementing CSSRegion? With the spec written the way it is now, I see no reason to make anything virtual, or even have a Region class. Just implement it in Element. If need to pull things out for code reuse purposes, we can do that when it comes to that, but right now, there doesn't seem to be a need to complicate things. -Sam I have an upcoming proposal for a CSSPseudoElement object. You can make a pseudo-element like ::before or ::after into a CSS Region right now in WebKit. All that's lacking is a way to access those pseudo-elements from script. Thanks, Alan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Multiple inheritance in the DOM
On 7/25/12 6:12 PM, Sam Weinig s...@webkit.org wrote: On Jul 25, 2012, at 5:37 PM, Sam Weinig s...@webkit.org wrote: On Jul 25, 2012, at 5:13 PM, Alan Stearns stea...@adobe.com wrote: On 7/25/12 4:49 PM, Kentaro Hara hara...@chromium.org wrote: A) Should we push back on the folks writing the CSS Regions specification to avoid using multiple inheritance? As far as I know, this is the only instance of multiple inheritance in the platform. Historically, EventTarget used multiple inheritance, but that's been fixed in DOM4 [4]. If it is possible to avoid the multiple inheritance, that would be best. From the WebIDL side, it's not strictly multiple inheritance. It's merely a supplemental interface that more than one object can implement. None of the members of the Region interface can clash with any of the members of the object that implements it. Right now Elements can become CSS Regions, but in the future other objects will be able to become CSS Regions. As far as I know, the correct way to specify this kind of relation is with WebIDL supplemental interfaces. I'd rather figure out the correct way to add this WebIDL functionality to WebKit now, than put something else into the spec and WebKit that we'll have to change later. Thanks, Alan What other objects do you envision implementing CSSRegion? With the spec written the way it is now, I see no reason to make anything virtual, or even have a Region class. Just implement it in Element. If need to pull things out for code reuse purposes, we can do that when it comes to that, but right now, there doesn't seem to be a need to complicate things. -Sam So, what I said isn't quite right, as I understand you actually can get a Region object (via getRegions()). But, the point of not needing to solve the issue right now remains true (though thin). No, you'll never actually get a Region object. What you get is a sequenceRegion whose members will all be Elements or some other object that implements the Region interface. That said, adding this type of multiple inheritance to the platform seems undesirable, and I think the standards body should work harder to come up with a solution that does not require it. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Multiple inheritance in the DOM
From: Adam Barth aba...@webkit.org Date: Wednesday, July 25, 2012 6:05 PM To: Sam Weinig s...@webkit.org Cc: Elliott Sprehn espr...@google.com, Alan Stearns stea...@adobe.com, Kentaro Hara hara...@chromium.org, webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Multiple inheritance in the DOM On Wed, Jul 25, 2012 at 6:00 PM, Sam Weinig s...@webkit.org wrote: On Jul 25, 2012, at 5:53 PM, Elliott Sprehn espr...@google.com wrote: It seems like this should really be a [NoInterfaceObject]. That resolves the issue of multiple inheritance since you can no longer do instanceof Region, and I'm not sure why you'd ever want to do that anyway. I agree. That doesn't solve the problem. But it's a good idea. I'll add it to the spec. Thanks, Alan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] About WebIDL supplemental interfaces
Adam, Currently, an Element is the only thing represented in the object model that can become a CSS Region. Pseudo-elements (::before and ::after) can become CSS Regions, but AFAIK there isn't yet a representation of those in the OM. I'm hoping this changes in the future (I'm working on a spec that addresses this), so that could be a second copy. I can construct a region chain now that includes pseudo-element Regions, and the NamedFlow interface is supposed to return a sequence of Regions from its getRegions() method. So ideally we'd have a way of returning a Region interface for those pseudo-elements that have been added to the region chain. Alan On 7/19/12 10:50 AM, Adam Barth aba...@webkit.org wrote: What else can become a region besides an element? If there aren't too many interfaces, we can just copy/paste this stanza into each IDL, like we do for EventTarget. If there are a lot of them, then I agree that you'll probably want a fancier Supplemental feature. One way to approach that is to make the [Supplemental] attribute take a list of interfaces. That should be straightforward to implement given our current implementation of Supplemental. Adam On Thu, Jul 19, 2012 at 9:58 AM, Andrei Bucur abu...@adobe.com wrote: Hello Adam, Sure: http://www.w3.org/TR/2012/WD-css3-regions-20120503/#the-region-interface The spec does not explicitly states that the Region should be supplemental, however after raising some issues on www-style ( http://lists.w3.org/Archives/Public/www-style/2012Jul/0251.html ) and talking them through (offline) it seemed the best way to solve them was making Region supplemental for Element and any other object that could become region. Right now, I'm feeling out the situation to see how feasible this is to be implemented in WebKit. Andrei. From: Adam Barth aba...@webkit.org Date: Thursday, July 19, 2012 7:31 PM To: Andrei Bucur abu...@adobe.com Cc: Kentaro Hara hara...@chromium.org, webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] About WebIDL supplemental interfaces Can you say what specifically in the CSS regions spec is giving you trouble? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Web APIs and class name collisions
The spec itself consistently and deliberately calls them CSS Regions, so a CSS prefix could be appropriate. Thanks, Alan From: Adam Barth aba...@webkit.orgmailto:aba...@webkit.org To: Andrei Bucur abu...@adobe.commailto:abu...@adobe.com Cc: webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Web APIs and class name collisions One common thing we do is prefix DOM to DOM-level concepts. For example, DOMWindow and DOMFileSystem. I'm not sure if we have an established convention for CSS-level concepts. Adam On Thu, Jul 12, 2012 at 9:18 AM, Andrei Bucur abu...@adobe.commailto:abu...@adobe.com wrote: Hello Webkittens! While implementing the Region interface ( http://dev.w3.org/csswg/css3-regions/#the-region-interface ) I've noticed that the name Region is already taken by a class in platform/graphics. I'd like to know what's the best approach in these kind of situations: 1. Rename the existing WebCore class to something else and use the name Region for the Web API so there's parity between the implementation and the spec 2. Somehow prefix the Web API implementation class name? As the Web APIs expand I suppose this situation may occur again in the future and I suppose there should be a rule describing what's the best approach to take. Thanks! Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] CSS 2.1 Test Suite
The best way to judge whether a reference result is correct is to submit the result to the W3C CSS 2.1 test suite and have it reviewed. The only way this test suite will get more reference results is if people like us volunteer to submit references. If it's useful to us to have these 'homebrew reference results' then it will be useful to everyone else who uses the suite. The previous thread mentioned checking Mozilla to see if their test suite had references for particular tests. If that's the case, then we should either encourage them to submit the references to the W3C, or just do that ourselves on their behalf. Alan From: Ryosuke Niwa rn...@webkit.org As we have previous discussed following https://lists.webkit.org/pipermail/webkit-dev/2012-March/019782.html, it's hard to judge whether a given reference result is enough to cover everything the test intends to test. e.g. you can have a bug such that both the test and the reference file ends up having the same rendering result. - Ryosuke On Tue, Apr 10, 2012 at 2:26 PM, Robert Hogan li...@roberthogan.net wrote: Hi there, We currently add tests from the CSS 2.1 suite as we fix them. They get added to the css2.1/20110323 folder in LayoutTests. Most of them don't have native reference tests yet in the suite so we (mostly I) have been adding homebrew reference results to the folder to avoid generating pixel results on all platforms. (see http://webkitmemes.tumblr.com/post/20788159625 !) These reference-results are easily removed once superseded but it might be cleaner just to move them, and the associated css tests, to a folder of their own in fast/css. That will allow css2.1/20110323 to be a clean import that the 8500 or so passing tests can be added to in 20 or 30 batches.[1] It will also make NRWT's reftests harness work with the suite. Does anyone object to that approach? The only thing going against it seems to be the principle that imported tests should be stored separately and together but this is more a case of using them to fix bugs and prevent future regressions while allowing a clean import of the CSS 2.1 test suite to take place in parallel. The problem this does not solve is how we avoid creating pixel results for tests that already pass but which do not have reftests of their own. Again I would be in favour of putting these in fast/css and keeping them there until reftests are added to the suite. This would allow us to prevent them regressing and come up with a reftest for them that can be submitted to the CSS test suite guys. The end result would be that we only directly import to the css2.1 folder those tests in the CSS test suite that have ref tests native to the suite. Thanks, Robert [1] I keep a local and relatively up to date copy of the passing and failing tests in separate folders in my checkout. Yes I know I should create bugs for them and get started on landing the passes. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Test conversion to use W3C testharness.js
I’m told that changes to the file are meant to be backwards-compatible. The API should not change, except to add new methods. On 3/9/12 2:28 PM, Jacob Goldstein jac...@adobe.com wrote: I recently uploaded a patch to https://bugs.webkit.org/show_bug.cgi?id=80709 which converted an existing JavaScript regions parsing test to use the W3C testharness.js in place of js-test-pre.js/js-test-post.js. This patch also places testharness.js and a WebKit-specific testharnessreport.js file in LayoutTests/fast/js/resources. In cases where tests need to be written for both the WebKit and W3C testing suites, having the ability to use testharness.js with WebKit tests would mean that the test file only needs to be written once, and yet can still rely on the functionality from both test harnesses. As it stands now, if someone needs to write a test for both suites, they either have to implement all functionality from scratch, or write one version of the test to use js-test-pre.js and another to use testharness.js. The inclusion of testharness.js in the WebKit repository alleviates the need for this duplication of effort. The testharnessreport.js file was intended for customization of the capabilities provided by testharness.js, I've added a call to layoutTestController.dumpAsText() to this file to allow it to function as a WebKit JavaScript test. There is some potential issues that I wanted feedback on. testharness.js uses a css file to format the test output. The path to this css file is assembled by the script. For the time being, I have not included the css file in the patch I attached to 80709. The CSS file has no impact when testharness.js is used along with dumpAsText as I have in the test I converted. It may provide some value, but I am going to suggest to the W3C that the CSS styling of results should move from testharness.js to testharnessreport.js (where it can be overridden). Another concern is that changes to testharness.js in the future that break backward compatibility could then break WebKit tests. This is an issue I plan to discuss with W3C members to determine if backward compatibility can be ensured. I'd appreciate any thoughts or feedback people have on this issue. Thanks, Jacob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Style bot complains of missing binary data in diff when deleting .png test results
If I delete a .png test result and I make a git diff without using the --binary flag, the style EWS bot complains. I can see why it would complain if I were rebasing the file - you need the binary data to see what's changed. It makes less sense to me to add the binary data to the diff if the file is just being deleted. Should VCSUtils.pm detect a ... and /dev/null differ line and let it through? Are there dependencies on the binary data in svn-apply or other tools? I'm planning on replacing some pixel-based verification with reftests in the near future, and so I'll be deleting quite a few .png files. I don't mind slinging around all that binary data, but if it's not really needed I'd rather leave it out. Thanks, Alan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Style bot complains of missing binary data in diff when deleting .png test results
David, This is a bug where I accidentally turned on a pixel result, then needed to remove the .pngs when I fixed the problem: https://bugs.webkit.org/show_bug.cgi?id=73343 The patch had two lines like this: Binary files a/LayoutTests/platform/efl/fast/regions/no-split-line-box-expected.png and /dev/null differ Which resulted in this output from style-queue: Failed to run [u'/mnt/git/webkit-style-queue/Tools/Scripts/svn-apply', u'--force'] exit_code: 9 Error: the Git diff contains a binary file without the binary data in line: Binary files a/LayoutTests/platform/efl/fast/regions/no-split-line-box-expected.png and /dev/null differ. Be sure to use the --binary flag when invoking git diff with diffs containing binary files. at /mnt/git/webkit-style-queue/Tools/Scripts/VCSUtils.pm line 667, ARGV line 45. Thanks, Alan On 11/30/11 5:36 PM, David Levin le...@chromium.org wrote: Perhaps you could give a bug that has an example of what you are talking about. For me it is hard to guess at what the complaint by the style bot is. dave On Wed, Nov 30, 2011 at 5:20 PM, Alan Stearns stea...@adobe.com wrote: If I delete a .png test result and I make a git diff without using the --binary flag, the style EWS bot complains. I can see why it would complain if I were rebasing the file - you need the binary data to see what's changed. It makes less sense to me to add the binary data to the diff if the file is just being deleted. Should VCSUtils.pm detect a ... and /dev/null differ line and let it through? Are there dependencies on the binary data in svn-apply or other tools? I'm planning on replacing some pixel-based verification with reftests in the near future, and so I'll be deleting quite a few .png files. I don't mind slinging around all that binary data, but if it's not really needed I'd rather leave it out. Thanks, Alan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting w3c ref tests and changing our convention
On 11/14/11 12:07 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Nov 14, 2011 at 11:41 AM, Darin Adler da...@apple.com wrote: We may find we can automate (3) with a script. It sounds pretty mechanical. It appears that W3C mandates author name, etc... be included in the meta data as well but I guess we can add something like WebKit Community or WebKit Authors? W3C folks told us we can create a WebKit directory under submissions so we can put all tests we export from our layout tests suite there with some canonical author name. AFAIK the mandate is only that there be an author link with a title and an appropriate href. There are many examples of tests with only this author data: link rel=author title=Microsoft href=http://microsoft.com/; / So I assume something like this would be fine for WebKit submissions: link rel=author title=WebKit href=http://webkit.org/; / Tests can have more than one author link if anyone wants to add additional contact info. Alan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting w3c ref tests and changing our convention
On 11/4/11 7:20 PM, Ojan Vafai o...@chromium.org wrote: On Fri, Nov 4, 2011 at 7:16 PM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Nov 4, 2011 at 7:07 PM, Ojan Vafai o...@chromium.org wrote: On Fri, Nov 4, 2011 at 7:03 PM, Ryosuke Niwa rn...@webkit.org wrote: I am, but I'm particularly concerned about W3C tests. It'll be nice if we had exactly one way of running / writing ref tests. I think we can easily automate the process of generating manifest files. The work flow will be as follows: 1. Write new ref tests using link element 2. Run some tool (maybe we can teach run-webkit-tests to do it automatically) 3. Upload patch with auto-regenerated manifest file It's mainly step 2 that I have a problem with, although I also don't like that the test is not self-contained. Generating manifest file when we add a test is much more efficient than generating it every time we run tests because we tend to do the latter much more often than the former. I think we're at an empass here. I don't see that further technical arguments will sway either of us. I do, however, expect that the vast majority of webkit developers would prefer to avoid a manifest file given the way the project has been structured up to now. What if we defer some of the W3C metadata work until tests were actually submitted to the W3C? 1. Tests we pull from W3C can run from manifests, since they are provided. 2. Tests we develop ourselves just use a naming convention (refs are named *-ref.html, and there's one ref per test even if that's duplicative) 3. When we choose to share a set of tests with the W3C, we do the extra work of adding metadata to the tests and possibly refactoring to reduce the number of -ref files. Once the W3C approves the tests we pull their copies and delete ours. Alan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Putting layout tests on a separate repository (was Supporting w3c ref tests and changing our convention)
On 11/4/11 3:09 PM, Ryan Leavengood leaveng...@gmail.com wrote: On Fri, Nov 4, 2011 at 5:58 PM, Ryosuke Niwa rn...@webkit.org wrote: Indeed, I'm against this idea. You make good points. There may be solutions to your objections, but they might not be much better than having a slow git status right now. Do other people who use WebKit with Git see this problem? If so, what do you do to stay productive? If not then I'll just be sure to only develop WebKit on a faster machine (which I do have and look forward to testing soon.) Note that supporting reftests has the possibility of slowing LayoutTests folder growth for WebKit-specific tests. If you have the choice of writing a reftest with a single html reference as the expected result, you should not get a proliferation of dumprendertree or png baselines in the platform folder. Once we figure out how to support imported reftests, we should be encouraging people to use reftests internally (even for tests we have no intention of pushing to the W3C) instead of dumprendertree or pixel tests (where possible - I assume reftests won't always work for visual tests). Alan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Using inline-block divs for line breaking tests
I have an idea for writing LayoutTests where what's being tested are line
breaks. Take the case of this recent bug fix:
https://bugs.webkit.org/show_bug.cgi?id=2
The problem here was that if you had a left float and text-indent combined,
the text-indent was not being considered in the line break, so text was
running outside of the container box. Checking this fix seems to require
using text, and test results that contain text are notoriously
platform-dependent (apparently even if you use Ahem, see
https://lists.webkit.org/pipermail/webkit-dev/2011-June/016930.html). The
patch for this fix had platform/mac/... txt and png expected files, and I
assume there will be other platform files created and maintained for this
test.
If I could test the line break without using text, this test (and a class of
other seemingly text-reliant tests) could be platform-independent. I think I
have something that works, but I'd like to get feedback from people with
more WebKit testing experience.
The test currently looks like this:
style
#container {
text-indent: 100px;
width: 200px;
border: 1px solid black;
}
#float {
float: left;
width: 50px;
height: 50px;
background: green;
}
/style
div id=container
div id=float/div
Some text that should not overlap the edge of the container.
/div
What's really being tested is whether the first line contains a short (up to
50px) amount of text or a longer (50-150px) amount. If I change the text
content to inline-block elements at a specific pixel width (and set
line-height as well) the dump-render-tree output should be
exactly the same on each platform. I can use that output to check for a
regression as the positions of the RenderBlocks for the word divs will
change based on whether the line breaks correctly.
style
#container {
line-height:20px;
text-indent: 100px;
width: 200px;
border: 1px solid black;
}
#float {
float: left;
width: 50px;
height: 50px;
background: green;
}
.word{
display:inline-block;
background: blue;
height:12px;
}
.short {
width:40px;
}
.long {
width:90px;
}
/style
div id=container
div id=float/divdiv class=short word/divdiv class=long
word/div
/div
With this version of the test you lose the self-documenting nature of the
text, but this also happens if you use the Ahem font. I think this would be
an OK tradeoff versus having to maintain platform-specific dumps and
bitmaps. The test expectation could be added to the test source as a
comment.
If a test really does need to verify that text is being rendered correctly,
this technique would not be applicable. But I think there are a number of
tests that are only concerned with line length or height, where the text
content is incidental.
Does this seem like a good idea? Are there any refinements that can be made?
Thanks,
Alan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using inline-block divs for line breaking tests
On 8/24/11 1:52 PM, Dan Bernstein m...@apple.com wrote: On Aug 24, 2011, at 1:08 PM, Alan Stearns wrote: ... Idea for platform-proofing some DumpRenderTree results You can make a text-only test that uses Ahem (you can still rely on its horizontal metrics, at least) and DOM API such as Range¹s getClientRects() to test that the first character after the line break is positioned where you expect it to be. If I chose to validate using getClientRects() (or some other API) then I expect I'd be using dumpAsText() instead of DumpRenderTree output. That seems OK to me, too. And if I'm using the API to validate, my checks could have a bit of tolerance to account for platform font differences. So I would not necessarily need to use Ahem. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Location of tests for new CSS features (regions and exclusions)
There are two patches in the works for regions and exclusions that include tests: https://bugs.webkit.org/show_bug.cgi?id=61726 https://bugs.webkit.org/show_bug.cgi?id=61730 The patches started with tests in these paths: LayoutTests/fast/regions LayoutTests/fast/exclusions But during the responses to feedback, the test path schemes have diverged. They are currently: LayoutTests/fast/css-regions LayoutTests/fast/css/exclusions I am assuming that neither of these current paths are correct, since there are no other examples using paths like them. But I do see CSS3 features in different places - transitions tests have their own folder, but selector tests are in a css3 folder. So I'm guessing that either we should (1) use the original paths: LayoutTests/fast/regions LayoutTests/fast/exclusions Or (2) move the folders into the css3 folder: LayoutTests/fast/css3/regions LayoutTests/fast/css3/exclusions Unless I hear an argument for (2) I'm planning on submitting test patches using (1). Thanks, Alan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The case for disallowing alerts in unload, redux
On 6/26/11 12:10 PM, Adam Barth aba...@webkit.org wrote: It would be useful to know what fraction of those users would have a better experience with this change. Sreeram, of the example sites that you've seen, how many would be improved by suppressing these alerts? One example of a useful confirm (I think) is a web-based irc client like irc.w3.org. It warns that you will close all active IRC connections, and lets you decide whether to stay on the page or navigate away. Alan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding CSS Regions and Exclusions to WebKit
On 5/26/11 3:08 PM, David Hyatt hy...@apple.com wrote: On May 26, 2011, at 4:31 PM, Eric Seidel wrote: I appreciate that you've followed the master-bug idiom which is so common in bugs.webkit.org http://bugs.webkit.org/ these days! I also would *strongly* encourage you to post your changes in as small of patches as possible. Integrating features which have been developed outside webkit.org http://webkit.org/ is always difficult, but doing things in small (or even tiny!) patches will make your life easiest in the long run. I'm happy to help review your (small!) changes if CC'd. I've encouraged them to begin with the CSS property back end, i.e., getting the new properties and values in and parsed. I think it will be a good introduction to our process to start there, and it will also let them get familiar with writing regression tests. I think those patches are more easily reviewed by many people as well, unlike the layout and rendering changes, which are quite advanced. Following this advice, we’re preparing some initial patches that only contain the parsing code. I have been looking for pure parsing tests to use as examples for the tests we will need to submit with these patches, but I haven’t yet found anything to go on. I’m guessing that I’m not looking in the right place, or (for those who have followed this patch trajectory before) initial parsing tests get replaced with functional tests over time. Does anyone have an example of good parsing validation they can point me to? Thanks, Alan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
