Re: [webkit-dev] Request for position on the aspect-ratio CSS property

2020-10-20 Thread Rob Buis

Hi,

I was looking into aspect-ratio and there is one thing Christian did not 
mention yet. There is an existing aspect-ratio implementation 
(https://bugs.webkit.org/show_bug.cgi?id=47738) that uses the property 
-webkit-aspect-ratio and seems replaced elements only. Probably 
aspect-ratio can override -webkit-aspect-ratio, anyway since this may 
influence the position I thought I should mention it.


Cheers,

Rob.

>Hello,

>I'd like to request an official position the aspect-ratio CSS
>property, as both Gecko and Blink are currently implementing it, and
>ideally we'd like to ship it soonish.

>https://drafts.csswg.org/css-sizing-4/#aspect-ratio

>https://docs.google.com/document/d/1VqD0mfkIDyCxQBrrvDw5wEbhXBsmEYIhk6ahiX_fvco/edit#

>Thanks,
>Christian

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


Re: [webkit-dev] in WebKit?

2020-10-20 Thread Antti Koivisto
I landed the updated behavior.


  antti

On Mon, Oct 19, 2020 at 11:29 AM Anders Hartvoll Ruud 
wrote:

> Yes, there's css/selectors/is-where-error-recovery.tentative.html
>
> (.tentative tag to be dropped momentarily).
>
> On Sat, Oct 17, 2020 at 10:17 AM Antti Koivisto  wrote:
>
>> Seems like a sensible change. Are there WPT tests for this behavior
>> already?
>>
>>
>>   antti
>>
>> On Fri, Oct 16, 2020 at 8:06 PM Anders Hartvoll Ruud <
>> andr...@chromium.org> wrote:
>>
>>> Hi,
>>>
>>> We are about to ship support for :is() and :where() in Chromium,
>>> including support for .
>>>  As
>>> far as I understand, :is() in Safari 14 takes a regular ,
>>> and Chromium API owners are concerned that this is a potential source of
>>> interop problems.
>>>
>>> Are there any plans to implement the  behavior
>>> in WebKit as well?
>>>
>>> Thanks,
>>> Anders
>>>
>>> FYI: https://bugs.webkit.org/show_bug.cgi?id=217814
>>> ___
>>> 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] Reducing / removing use of Makefile based DerivedSources.make

2020-10-20 Thread Andy Estes
Hi Sam,

> On Oct 18, 2020, at 11:01, Sam Weinig  wrote:
> 
> One direct benefit of moving away from DerivedSources.make would likely be (I 
> say likely, as the details of how it works out are far from certain in my 
> mind) removing at least one place that a IDL file needs to be listed as we 
> would not need to explicitly the list the IDL file in DerivedSources.make, 
> and would only need to ensure it was in some *input.xcfilelist.

The way I imagine this working is that the existing .idl file references in the 
(e.g., WebCore) project would become members in a target with a custom build 
rule for “*.idl”. Target membership is itself another list inside the 
.xcodeproj file, just one you manage through checkboxes in Xcode (and can be 
done reasonably quickly as part of adding a new file reference).

Whether or not this actually creates one fewer “place a IDL file needs to be 
listed” (which I think is a worthwhile goal), I think you should still remove 
the Makefile build phases from Xcode for the reasons you originally cited.

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


Re: [webkit-dev] in WebKit?

2020-10-20 Thread Anders Hartvoll Ruud
Nice, that's very quick, thanks Antti!

On Tue, Oct 20, 2020 at 7:25 PM Antti Koivisto  wrote:

> I landed the updated behavior.
>
>
>   antti
>
> On Mon, Oct 19, 2020 at 11:29 AM Anders Hartvoll Ruud <
> andr...@chromium.org> wrote:
>
>> Yes, there's css/selectors/is-where-error-recovery.tentative.html
>>
>> (.tentative tag to be dropped momentarily).
>>
>> On Sat, Oct 17, 2020 at 10:17 AM Antti Koivisto  wrote:
>>
>>> Seems like a sensible change. Are there WPT tests for this behavior
>>> already?
>>>
>>>
>>>   antti
>>>
>>> On Fri, Oct 16, 2020 at 8:06 PM Anders Hartvoll Ruud <
>>> andr...@chromium.org> wrote:
>>>
 Hi,

 We are about to ship support for :is() and :where() in Chromium,
 including support for .
  As
 far as I understand, :is() in Safari 14 takes a regular ,
 and Chromium API owners are concerned that this is a potential source of
 interop problems.

 Are there any plans to implement the  behavior
 in WebKit as well?

 Thanks,
 Anders

 FYI: https://bugs.webkit.org/show_bug.cgi?id=217814
 ___
 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] Reducing / removing use of Makefile based DerivedSources.make

2020-10-20 Thread Sam Weinig


> On Oct 20, 2020, at 3:36 PM, Darin Adler  wrote:
> 
>> On Oct 20, 2020, at 3:09 PM, Sam Weinig  wrote:
>> 
>> For the Platform.h issue, I think we could probably engineer things in the 
>> short term to have a script phase that produces a Defines.txt that the other 
>> script phases and build rules depend on.
> 
> We definitely can, and it’s simpler than how we do it now. I have a patch 
> that does this for the makefile partly done and set aside. My approach was to 
> revise each script, one at a time, to take a file with the defines rather 
> than requiring they be passed on the command line. It doesn’t work for the 
> parts of the makefile itself that depend directly on checking the defines 
> (grep for findstring.*FEATURE_AND_PLATFORM_DEFINES to see those).
> 

Great. 

I think we can probably easily replace the makefile checking 
FEATURE_AND_PLATFORM_DEFINES itself ones.

For the ones conditionalizing adding to ADDITIONAL_BINDING_IDLS, those IDLs 
should just have the appropriate Conditional=* extended attribute added, then 
they can be included unconditionally in the makefile.

For the ones conditionalizing adding go USER_AGENT_STYLE_SHEETS, again, there 
doesn’t seem a real reason to keep that. The sheets are all preprocessed 
anyway, so we can just move those #ifdefs into the files.

I filed https://bugs.webkit.org/show_bug.cgi?id=218001 
 for this and will get that 
done regardless.

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


Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

2020-10-20 Thread Sam Weinig


> On Oct 20, 2020, at 2:25 PM, Keith Rollin  wrote:
> 
>> On Oct 20, 2020, at 10:51, Andy Estes  wrote:
>> 
>>> On Oct 18, 2020, at 11:01, Sam Weinig  wrote:
>>> 
>>> One direct benefit of moving away from DerivedSources.make would likely be 
>>> (I say likely, as the details of how it works out are far from certain in 
>>> my mind) removing at least one place that a IDL file needs to be listed as 
>>> we would not need to explicitly the list the IDL file in 
>>> DerivedSources.make, and would only need to ensure it was in some 
>>> *input.xcfilelist.
>> 
>> The way I imagine this working is that the existing .idl file references in 
>> the (e.g., WebCore) project would become members in a target with a custom 
>> build rule for “*.idl”. Target membership is itself another list inside the 
>> .xcodeproj file, just one you manage through checkboxes in Xcode (and can be 
>> done reasonably quickly as part of adding a new file reference).
>> 
>> Whether or not this actually creates one fewer “place a IDL file needs to be 
>> listed” (which I think is a worthwhile goal), I think you should still 
>> remove the Makefile build phases from Xcode for the reasons you originally 
>> cited.
>> 
>> Andy
> 
> Overall, this sounds like an awesome endeavor. The initial reasons for using 
> Makefiles were sound ones (as Darin described), but there are also the 
> incumbent issues, such as maintainability and efficiency.
> 
> I wasn’t clear on what the alternative to Makefiles would look like, though. 
> The options that occur to me are:
> 
> * Custom build rules, as Andy describes. This seems to make sense, but I 
> wonder if it is flexible enough for all the cases we might want to put it 
> through. Our DerivedSources.make files process many types of files. I haven’t 
> checked, but I could imagine that not all of these files could be uniquely 
> distinguished by their suffixes. That is, there might be one set of *.foo 
> files that should be processed one way, and another set that should processed 
> another way. In those cases, I guess some suffixes could be changed to 
> accommodate the different processing.
> 
> * Using a set of Run Script build phases. That is, have a Run Script phase 
> for processing a specific set of *.idl files, another for processing one set 
> of *.foo files, a third for processing a different specific set of *.foo 
> files, and so on. I’m against this approach, though. While it offers lots of 
> flexibility, it’s not very maintainable. It would mean having to keep the set 
> of script inputs and outputs up-to-date, something that is fragile, even with 
> the help of the generate-xcfilelists utility script.
> 
> Of these two, the one based on custom build rules seems to make the most 
> sense. One need only add a file to an Xcode project and possibly a CMake 
> file. Of note, the dreaded .xcfilelists are not affected (and, if this 
> project can be taken to its extreme, we can get rid of the 
> DerivedSources*.xcfilelist files). I do worry about some efficiency issues, 
> though. For instance, one part of DerivedSources.make processes Platform.h 
> (and all its children) in order to extract some configuration information. 
> That processing is done once per DerivedSources.make invocation. If we move 
> to a model where a script is invoked once per *.idl file, then the overhead 
> is now multiplied by the number of *.idl files. We should watch for that. 
> (Perhaps your recent configuration/preferences/settings changes obviate the 
> need to pre-process Platform.h all the time?)

My thought is that we would be using a combination of Run Script phases and 
Build Rules, depending on the thing being generated. There are quite a few 
one-off scripts like makeprop.pl, makevalues.pl, 
makeSelectorPseudoClassAndCompatibilityElementMap.py, etc, that don’t have 
their input or output change very often at all, so are really much better 
suited for a Run Script phase. Whereas things like the IDLs are better suited 
for build rules.

For the Platform.h issue, I think we could probably engineer things in the 
short term to have a script phase that produces a Defines.txt that the other 
script phases and build rules depend on. Longer term, I would like to remove 
the need for it altogether, but that’s going to take additional work in the 
various scripts.


> Still, I’m open to a solution based on a single IDL.txt file that can be 
> shared by Xcode and CMake. It all depends on the details, the resulting 
> solution, and the trade-offs it makes.
> 
> Regarding Xcode vs. CMake, I certainly understand the reasons people would 
> like to see us move solely to CMake. But, for now, the plan is to see if we 
> can get Apple-OS ports to build with CMake at all. Replacing Xcode and 
> xcodebuild is a follow-on project with an interesting set of issues. I set up 
> #cmake on Slack to provide a place where we can talk about this for anyone 
> who’s interested.
> 


Thanks for the feedback,

- Sam

> — Keith
> 
> 

Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

2020-10-20 Thread Darin Adler
> On Oct 20, 2020, at 3:09 PM, Sam Weinig  wrote:
> 
> For the Platform.h issue, I think we could probably engineer things in the 
> short term to have a script phase that produces a Defines.txt that the other 
> script phases and build rules depend on.

We definitely can, and it’s simpler than how we do it now. I have a patch that 
does this for the makefile partly done and set aside. My approach was to revise 
each script, one at a time, to take a file with the defines rather than 
requiring they be passed on the command line. It doesn’t work for the parts of 
the makefile itself that depend directly on checking the defines (grep for 
findstring.*FEATURE_AND_PLATFORM_DEFINES to see those).

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


Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

2020-10-20 Thread Darin Adler
> On Oct 20, 2020, at 4:08 PM, Sam Weinig  wrote:
> 
> For the ones conditionalizing adding to ADDITIONAL_BINDING_IDLS, those IDLs 
> should just have the appropriate Conditional=* extended attribute added, then 
> they can be included unconditionally in the makefile.
> 
> For the ones conditionalizing adding go USER_AGENT_STYLE_SHEETS, again, there 
> doesn’t seem a real reason to keep that. The sheets are all preprocessed 
> anyway, so we can just move those #ifdefs into the files.
> 
> I filed https://bugs.webkit.org/show_bug.cgi?id=218001 
>  for this and will get that 
> done regardless.

Some of these also make it possible to build without WebKitAdditions. We may 
need some different approach to that.

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


Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

2020-10-20 Thread Keith Rollin
> On Oct 20, 2020, at 10:51, Andy Estes  wrote:
> 
>> On Oct 18, 2020, at 11:01, Sam Weinig  wrote:
>> 
>> One direct benefit of moving away from DerivedSources.make would likely be 
>> (I say likely, as the details of how it works out are far from certain in my 
>> mind) removing at least one place that a IDL file needs to be listed as we 
>> would not need to explicitly the list the IDL file in DerivedSources.make, 
>> and would only need to ensure it was in some *input.xcfilelist.
> 
> The way I imagine this working is that the existing .idl file references in 
> the (e.g., WebCore) project would become members in a target with a custom 
> build rule for “*.idl”. Target membership is itself another list inside the 
> .xcodeproj file, just one you manage through checkboxes in Xcode (and can be 
> done reasonably quickly as part of adding a new file reference).
> 
> Whether or not this actually creates one fewer “place a IDL file needs to be 
> listed” (which I think is a worthwhile goal), I think you should still remove 
> the Makefile build phases from Xcode for the reasons you originally cited.
> 
> Andy

Overall, this sounds like an awesome endeavor. The initial reasons for using 
Makefiles were sound ones (as Darin described), but there are also the 
incumbent issues, such as maintainability and efficiency.

I wasn’t clear on what the alternative to Makefiles would look like, though. 
The options that occur to me are:

* Custom build rules, as Andy describes. This seems to make sense, but I wonder 
if it is flexible enough for all the cases we might want to put it through. Our 
DerivedSources.make files process many types of files. I haven’t checked, but I 
could imagine that not all of these files could be uniquely distinguished by 
their suffixes. That is, there might be one set of *.foo files that should be 
processed one way, and another set that should processed another way. In those 
cases, I guess some suffixes could be changed to accommodate the different 
processing.

* Using a set of Run Script build phases. That is, have a Run Script phase for 
processing a specific set of *.idl files, another for processing one set of 
*.foo files, a third for processing a different specific set of *.foo files, 
and so on. I’m against this approach, though. While it offers lots of 
flexibility, it’s not very maintainable. It would mean having to keep the set 
of script inputs and outputs up-to-date, something that is fragile, even with 
the help of the generate-xcfilelists utility script.

Of these two, the one based on custom build rules seems to make the most sense. 
One need only add a file to an Xcode project and possibly a CMake file. Of 
note, the dreaded .xcfilelists are not affected (and, if this project can be 
taken to its extreme, we can get rid of the DerivedSources*.xcfilelist files). 
I do worry about some efficiency issues, though. For instance, one part of 
DerivedSources.make processes Platform.h (and all its children) in order to 
extract some configuration information. That processing is done once per 
DerivedSources.make invocation. If we move to a model where a script is invoked 
once per *.idl file, then the overhead is now multiplied by the number of *.idl 
files. We should watch for that. (Perhaps your recent 
configuration/preferences/settings changes obviate the need to pre-process 
Platform.h all the time?)

Still, I’m open to a solution based on a single IDL.txt file that can be shared 
by Xcode and CMake. It all depends on the details, the resulting solution, and 
the trade-offs it makes.

Regarding Xcode vs. CMake, I certainly understand the reasons people would like 
to see us move solely to CMake. But, for now, the plan is to see if we can get 
Apple-OS ports to build with CMake at all. Replacing Xcode and xcodebuild is a 
follow-on project with an interesting set of issues. I set up #cmake on Slack 
to provide a place where we can talk about this for anyone who’s interested.

— Keith

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