Re: [webkit-dev] Removal of the Grid Layout runtime flag
Hi, Since nobody seems to object to my proposal of removing the grid runtime flag, here is the patch to do it. https://bugs.webkit.org/show_bug.cgi?id=183484 I appreciate any feedback, specially if this change could break any platform still needing to disable the grid feature for some reason. Thanks, -- Javier On 03/02/18 00:26, Javier Fernandez wrote: > Hi, > > The CSS Grid Layout feature is shipped and enabled by default since > Safari 10.1. It's also shipped by default in Chrome, Firefox and Edge. > > Do we still need the 'cssGridLayoutEnabled' runtime flag ? > In my opinion it's safe to remove the flag and the conditional code we > have in the CSS parser and layout. > > Thanks, > > Javier > > ___ > 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
[webkit-dev] Removal of the Grid Layout runtime flag
Hi, The CSS Grid Layout feature is shipped and enabled by default since Safari 10.1. It's also shipped by default in Chrome, Firefox and Edge. Do we still need the 'cssGridLayoutEnabled' runtime flag ? In my opinion it's safe to remove the flag and the conditional code we have in the CSS parser and layout. Thanks, Javier ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Unified sources build errors when adding new source files
Hi, The patch at https://bugs.webkit.org/show_bug.cgi?id=179633 it's just a refactoring of the Grid Layout code which defines a new namespace with a bunch of Grid related utility functions, only used from the RenderGrid and GridTrackSizingAlgorithm classes. The patch adds a new entry to the WebCore/Source.txt, for the file GridLayoutFunctions.cpp. It builds perfectly with the no-unify tag, but I produces totally unrelated errors when using the unified building. I wonder whether my patch could make those errors arise because of altering the building units (8 files, as far as I know) when adding the mentioned new entry to the WebCore/Source.txt file. Thanks. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Improve selection with floats
I'd really appreciate any feedback on this thread from layout experts. I have a few ideas and some time to work on them, but I'd need to know if WebKit is interested on exploring them. I know it's a complex logic and the lack of specification does not help at all. Thanks. On 07/09/17 16:40, Javier Fernandez wrote: > Hi, > > I've been working lately on some cases where selection shows an > unpredictable behavior when applied to cases with float elements; > basically, selection boundaries jump when dragging over floats. I've > found this old bug (https://webkit.org/b/101771) which described some of > these cases. I've attached another case with the same problem. > > This weird Selection's behavior is also present in Blink and Gecko: > - https://crbug.com/758526 > - https://bugzilla.mozilla.org/show_bug.cgi?id=1397514 > > I'm aware of the issues we have with Selection when the Render Tree > differs from the DOM Tree's structure, but that's not the case of the > examples I've been evaluating so far; I think for these cases we can do > better. > > My theory is that the root cause of this issue in most, if not all, the > cases is that we are not considering floats as valid HitTest candidates. > Additionally, we exclude floats from the positionForPoint logic, > implemented in the different render objects. > > I'm evaluating a preliminary approach based on considering floats as > valid HitTest candidates. I started to address a very specific case in > https://webkit.org/b/176096 and, if it gets enough support, I have plans > to continue addressing as many cases as possible. > > I think we have to assume that we will have issues with floats when they > create complex render trees, like it happens with other layout models, > but at least we can improve the simplest cases. > > I appreciate any feedback on my current approach and reviews of my > patches, if we finally want to give this proposal a shot. > > > > ___ > 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
[webkit-dev] Improve selection with floats
Hi, I've been working lately on some cases where selection shows an unpredictable behavior when applied to cases with float elements; basically, selection boundaries jump when dragging over floats. I've found this old bug (https://webkit.org/b/101771) which described some of these cases. I've attached another case with the same problem. This weird Selection's behavior is also present in Blink and Gecko: - https://crbug.com/758526 - https://bugzilla.mozilla.org/show_bug.cgi?id=1397514 I'm aware of the issues we have with Selection when the Render Tree differs from the DOM Tree's structure, but that's not the case of the examples I've been evaluating so far; I think for these cases we can do better. My theory is that the root cause of this issue in most, if not all, the cases is that we are not considering floats as valid HitTest candidates. Additionally, we exclude floats from the positionForPoint logic, implemented in the different render objects. I'm evaluating a preliminary approach based on considering floats as valid HitTest candidates. I started to address a very specific case in https://webkit.org/b/176096 and, if it gets enough support, I have plans to continue addressing as many cases as possible. I think we have to assume that we will have issues with floats when they create complex render trees, like it happens with other layout models, but at least we can improve the simplest cases. I appreciate any feedback on my current approach and reviews of my patches, if we finally want to give this proposal a shot. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] MathML layout refactor proposal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On 12/14/2015 08:03 PM, Frédéric WANG wrote:
> Le 14/12/2015 19:39, Zalan Bujtas a écrit :
>> It’s great to hear that MathML is getting some proper cleanup. I
>> think the proposal sounds good and I am looking forward to the
>> patches.
>>
>> Minor observation: I noticed that, since MathML block is no
>> longer a flexbox, but it still needs some of the flexbox
>> functionality, the following pattern has been introduced to the
>> generic renderbox/block code. -if
>> (parent()->isFlexibleBox()) { +if (parent()->isFlexibleBox()
>> || parent()->isRenderMathMLBlock()) { I just wish there was
>> another way to handle this.
>>
>> Zalan.
> Alex will correct me if I'm wrong, but I think the changes in
> RenderBox are just a temporary solution to avoid breaking tests
> while we continue to rewrite the MathML layout code. Hopefully,
> these won't be needed anymore when we are done.
>
Fred is totally right. That's just legacy code from the old Flexbox
functionality, which we had to adopt temporary in order to keep
passing the current layout tests. We won't need it anymore in the new
layout logic.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iEYEARECAAYFAlZvKusACgkQoNRbE6zycrm/QACeMthQoiPUoVL7KBBLn1c9+irj
1SQAnj4703KlHyMnsxLzKDmMSN8KW5wJ
=MBbI
-END PGP SIGNATURE-
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Remove ENABLE(SUBPIXEL_LAYOUT)
Hi, On 08/18/2014 08:14 PM, Zalan Bujtas wrote: Hi Everyone, I’d like to propose removing ENABLE(SUBPIXEL_LAYOUT), as every port has it enabled. As part of this activity, I am planning to enable SATURATED_LAYOUT_ARITHMETIC by default. Thanks, Zalan. I've already opened a bug to address this issue, but unfortunately, didn't find the time to complete the task. See https://bugs.webkit.org/show_bug.cgi?id=124234 for details. -- javi ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] CSS Grid Layout status review
Hi all,
It's been a while since Igalia started contributing to the development
of the CSS Grid Layout spec in WebKit (enabled in the nightly builds
since May) and we'd like to report about the implementation status to
gather feedback from the community (comments, issues, questions, etc.).
CSS Grid Layout is a browser feature that allows to define responsive
and flexible 2D layouts using just CSS declarations. Visit
http://www.w3.org/TR/css-grid-1/ for more information about the standard.
First of all, the following meta-bug can be used to track the
implementation: http://webkit.org/b/60731
Besides a quite active bugfixing, these are the most important changes
that have been landed recently:
* Introduce compilation flag (http://webkit.org/b/129153) and remove
runtime feature http://webkit.org/b/132382 (thus CSS Grid Layout is
enabled in the nightly builds since May).
* Syntax implementation:
- Adapting some properties to the last specification:
http://webkit.org/b/127987
+ grid-template-{columns, rows} and grid-template-areas
- grid-template: Explicit Grid shorthand: http://webkit.org/b/128980
- grid: Grid Definition Shorthand: http://webkit.org/b/132122
* Code refactoring:
- Grid position resolution code moved to its own class:
http://webkit.org/b/131732
* Auto-Placement algorithm:
- Add support for spanning items: http://webkit.org/b/110633
* Z-index:
- Properly support z-index property on grid items:
http://webkit.org/b/103329
* Alignment and justification:
- Implement justify-self css property: http://webkit.org/b/134419
In addition, we're actively working on the following features:
* Alignment and justification:
- Implement row-axis Alignment: http://webkit.org/b/133222
- Implement column-axis Alignment: http://webkit.org/b/133224
- Improve margin, border and padding support.
* Auto-placement algorithm:
- Implement the new sparse and stack modes: http://webkit.org/b/103316
* Performance optimizations:
- meta-bug to track future optimizations: http://webkit.org/b/125145
- Dirty bit on grids: http://webkit.org/b/132332
We hope you find this report useful so people interested on this feature
could be aware of our progress and future work. Please, don't hesitate
to give us any kind of feedback; it's really appreciated.
Finally, stating that we're planning to continue working on the
implementation of this spec with the goal of asking before the end of
the year to be considered for shipping . Let's see how all this evolves
and we'll keep you informed.
Best regards.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] CSS Grid Layout status review
Hi Benjamin, On 08/02/2014 12:53 AM, Benjamin Poulain wrote: Do you know if Fuzzinator covers CSS Grid Layout? I don't think so. It might be a good idea to add support for Grid Layout. Could you give me some directions on how to do it ? -- javi ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Selection and new layout models
Hi, During the last WebKit Contributors Meeting we had a discussion about how to improve Selection in the new layout models. We agreed that it would be great to have a repository where we can share use cases to study the main Selection issues. At Igalia we have been working on Selection for CSS Regions for a while and we've also detected similar problems in other layout models. This is what we've got so far: http://igalia.github.io/web-selection-examples/ We will continue working on improving the site, adding more use cases and examples and also considering other layout models. Feedback would be really appreciated. -- Javi ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Blog post on the contributor's meeting?
Hi, On 04/26/2014 12:22 AM, Benjamin Poulain wrote: It would be redundant to post the same information on the WebKit blog. In my opinion, your blog post is already a good summary. I agree, but anyway, as I promised, this is mine about my experience in the meeting. http://blogs.igalia.com/jfernandez/2014/04/30/2014-webkit-contributors-meeting/ I think we should make several small blog post about specific subjects. I have seen really nice stuffs in the session I attended. From what I -CSS Grid Layout Perhaps I should write a new one with the contents I presented in my talk, but I think one of those already published by my colleges sergio and rego are good ones to introduce the feature: http://blogs.igalia.com/mrego/2014/03/13/welcome-css-grid-layout/ http://blogs.igalia.com/svillar/2014/03/31/adventures-in-the-grid/ -- Javi ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Enabling CSS Grid Layout runtime flag by default
Hi, As we discussed in the last WebKit Contributors Meeting, I think it would be useful to have the runtime feature enabled by default. We already have a compilation flag since r164659 [1], so enabling the runtime flag by default would make easier for developers to try out and test the new feature. Of course, in release builds the compilation flag is kept to false as expected. If everybody agrees, we have a patch ready to do this change: http://webkit.org/b/132189 FWIW, in WebKit nightly builds the runtime feature is set to true or false depending on the compilation flag since r166614 [2]. However, this is only affects the Mac port. -- Javi [1] http://webkit.org/b/129153 [2] http://webkit.org/b/130013 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Blog post on the contributor's meeting?
Hi, On 04/24/2014 08:00 PM, Bem Jones-Bey wrote: In addition, there are many sessions from the contributor meeting that don't have notes or anything on them on the meeting page[2]. If you have anything you could add for any of the sessions, that would be very useful. I think it's a good idea; actually, I was about to publish mine, where I'll mainly talk about the nice discussion we held about Selection on new layout models, like CSS Regions, CSS Grid Layout and Multi-Column. I'll also give my impressions about the other sessions I attended. -- Javi ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should SATURATED_ARITHMETIC_LAYOUT be forced when enabling SUBPIXEL_LAYOUT ?
Hi, On 09/06/2013 10:12 PM, Ryosuke Niwa wrote: Thanks for the analysis! Perhaps we should merge two build flags and turn on the saturated arithmetic whenever subpixel is enabled. I think that would be the ideal solution, since it has been probed enabling SUPIXEL_LAYOUT only implies actual potential problems. I posted a patch to 118595 (the bug which spot this issue) to reduce the max-height value a bit without altering the purpose of the test. This issue could be tracked in the bug I filled specifically for this, 119273; I could implement a patch here to merge both flags, since it would solve the bug. However, I think some feedback from the maintainers of the affected ports would be really appreciated. For the case of the gtk+ port, I'm currently investigating 120583, but I think it won't be a problem. I'll try to gather feedback form the ports maintainers, tough. -- Javi ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should SATURATED_ARITHMETIC_LAYOUT be forced when enabling SUBPIXEL_LAYOUT ?
Hi, On 07/31/2013 10:40 PM, Ryosuke Niwa wrote: Can't we encounter the same bug if we you multiplied the same height by 64 even if the sub pixel layout is not turned off? Or is there some parser and other component that prevents such an overflow to happen? I've been debugging and analyzing this issue a bit more and I concluded that the scenario described in bug 119273 is already protected if SUBPIXEL_LAYOUT is not enabled. The CSS max-height property value is clamped to max float during the parsing phase. Further arithmetic operations are already protected, so only the case of using the 64 factor defined for the SUBPIXEL_LAYOUT is still causing problems. So, this issue affects only the ports enabling SUBPIXEL_LAYOUT by default and not using the SATURATED_ARITHMETIC_LAYOUT. As far as I know, gtk+, Qt and EFL are the ports affected by this issue. Regarding the gtk+ port, the SATURATED_ARITHMETIC_LAYOUT would be enabled as soon as I verify bug 120583 is solved enabling this flag. Could anyone responsible of the other ports give some insight to this issue ? BR. -- Javi ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should SATURATED_ARITHMETIC_LAYOUT be forced when enabling SUBPIXEL_LAYOUT ?
Hi, On 31/07/13 22:40, Ryosuke Niwa wrote: Can't we encounter the same bug if we you multiplied the same height by 64 even if the sub pixel layout is not turned off? Or is there some parser and other component that prevents such an overflow to happen? For the specific case of max-height, if subpixel_layout is not enabled, I think the LayoutUnit class will use the REPORT_OVERFLOW macro to spot the issue during the CSS parsing stage; the LayoutUnit will call MathExtras::clampTo on the initial CSS value. Precisely, SATURATED_ARITHMETIC_LAYOUT, which requires SUBPIXEL_LAYOUT support, is intended to protect the arithmetic operations, since the initial values are already under control. But, targeting your specific question, it would b possible to define a maxh-height CSS Property value which does not overflow, hence multiplying by 64 during the layout phase will spot the same bug, so the answer to your specific question is: yes, the same bug will appear in some cases even if subpixel_layout is not enabled. Perhaps that's a interesting scenario to study, so I'll prepare some test to verify whether I manage to reproduce the issue without subpixel_layout support. Regards, -- Javi ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should SATURATED_ARITHMETIC_LAYOUT be forced when enabling SUBPIXEL_LAYOUT ?
Hi, On 31/07/13 22:35, Benjamin Poulain wrote: It looks to me like it is a good idea on the long term to have saturated arithmetic enabled when you have subpixel layout. I believe only GTK and EFL enable subpixel layout at the moment(?). You can probably lead the way and mature the feature and others will follow. I've been in conctact already with the GTK+ port maintainers and they seem willing to enable SATURATED_ARITHMETIC_LAYOUT by default in the future. I think besides the two ports you mentioned the Qt port enables subpixel_layout as well, so I'll try to get feedback from the port maintainers. Regards, -- Javi ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Do we need subpixel layout (Was: Should SATURATED_ARITHMETIC_LAYOUT be forced when enabling SUBPIXEL_LAYOUT ?)
Hi, On 01/08/13 00:26, Balazs Kelemen wrote: I think first we should clarify some more basic questions about subpixel layout. 1. Is it actually mantained? 2. Do any port really need it? Please correct me if these questions are too obvious or have been resolved before. Note that I am not a fan of subpixel layout, neither an enemy of it - in fact I do not know or care much about it. But from what I know it seems like this is a feature that makes an essential difference on the engine and I don't understand how can we allow such huge divergence across WebKit ports. Isn't it a maintenance burden? Doesn't it result in that test results across ports will diverge a lot more? This is an important topic, since as far as I know, most of the ports enable subpixel_layout by default. It would be good to know their future plans on this regard. IIMHO, just considering the theory, it looks like a nice feature to have. Regarding whether is maintained or not, I see recent commits to the LayoutUnit for adding subpixel support on some APIs. Anyway, as I said before, I think the idea behind the SATURATED_ARITHMETIC_LAYOUT flag to protect the LayoutUnit class against arithmetic overflows looks like something we want anyway. Regards, ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Should SATURATED_ARITHMETIC_LAYOUT be forced when enabling SUBPIXEL_LAYOUT ?
Hi, While looking into the bug #118595 I've found out that the root cause was an arithmetic overflow during the layout process, at least in the case of the WebKitGtk+ port, but I guess other ports have similar root cause. Notice that webkitgtk+ port enables the SUBPIXEL-LAYOUT by default. Later, I've concluded that the bug is not related to Regions at all, but something generic happening when the max-height CSS property value is set to a huge number. I've filled a new bug #119273 for this. The arithmetic overflow is gone when enabling the SATURATED_ARITHMETIC_LAYOUT flag, which actually, as far as I could understand, it's the purpose of such experimental feature. However, I've provided a patch for the #119273 facing the specific case of the max-height. I don't think that's the right approach, because I think other CSS property might have the same problem, but I thought it was useful to understand the issue. I think the right solution would be to enable the SATURATED_ARITHMETIC_LAYOUT whenever the SUBPIXEL_LAYOUT flag is enabled. Perhaps, eventually, both flags will become part of the same feature; that's one of the points to be discussed here. I'm sending this email to this list in order to get an agreement between all the ports using the SUBPIXEL_LAYOUT feature, but perhaps this should be debated independently on each port's mailing list. Regards, -- Javi ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] CSS Regions and multi-range Selection
hi, During the last Contributors Meeting there was a discussion about how to improve the Selection when using CSS Regions. These are some of the conclusions got at that meeting: * multi-range selection would help with this. * come up with a better way to do selection that would allow a single-range selection to select through regions. * It's hard because of the difference in order between what is displayed and what is in the DOM. * one option could be like the way selection works with iframes, where if you select inside the regions, the selection cannot go to the outside of the region. * this could be very surprising, since people don't think of regions like iframes, might want to select the region content as well as an image next to it, for example. * suggestion of a different mode for selection that would be render tree based. I've been investigating how the Selection works with Regions now and trying different approaches (see bug 106817 for details), but the most promising one was based on multi-range Selection, which was discarded because of WebKit not interested in multi-range support. In order to simplify things I've followed the Iframe approach, considering Regions in the same FlowThread as content not directly related to other FlowThreads or outside Regions. However that's not always the case, so the final goal would be to allow the user to select content from both, inside and outside Regions. Besides, even that the mentioned solution uses the rangeCount and getRangeAt APIs, there is no actual multi-range selection but a way to get the Selection content skipping some DOM nodes not directly related to the content the user selected (this would solve the issues related to the differences between DOM and Render trees). The key idea is that the VisibleSelection class, besides providing start/end Positions to define the selection boundaries, it provides a set of intermediate points to consider the Region boundaries as well. Even though allowing user gestures to select multiple regions would fit better with CSS Regions usability, I think it's not a problem to make the selection working properly with Regions. However, just using multiple ranges to define more complex and richer selections it's a different concept, in my opinion. Would it be a valid approach ? I would like to start a discussion to evaluate different alternatives to improve the Selection with CSS Regions. BR. -- Javi ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
