[webkit-dev] Request for position: contain-intrinsic-size auto & longhands

2021-04-15 Thread Christian Biesinger via webkit-dev
Hello!

Chrome would like to implement the recent additions to the
constrain-intrinsic-size spec
(https://drafts.csswg.org/css-sizing-4/#intrinsic-size-override),
specifically the "auto" value as well as the contain-intrinsic-width,
contain-intrinsic-height, contain-intrinsic-block-size, ,
contain-intrinsic-inline-size properties.

Does Webkit have a position on these additions?

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


[webkit-dev] Request for position on mapping a source's width/height attributes to width/height/aspect-ratio CSS properties on the in a

2021-02-12 Thread Christian Biesinger via webkit-dev
Hello webkit-dev,

I would like to request an official position on the HTML spec change
described in this pull request:
https://github.com/whatwg/html/pull/5894/files

Together with https://github.com/whatwg/html/pull/6032, this means
that width/height attributes on a  element inside a 
will get mapped to CSS properties width/height/aspect-ratio on the
 in the .

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


Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Christian Biesinger
For what it's worth, my personal solution to this was to put a symlink
in / for the resources directory:

lrwxrwxrwx 1 root root 55 Dec 11  2015 /resources ->
/home/cbiesinger/csswg-test/resources/

Hm, I guess I should update that to web-platform-tests now!

Christian

On Fri, May 12, 2017 at 5:10 PM, Simon Fraser  wrote:
>
> On May 12, 2017, at 12:04 PM, Alexey Proskuryakov  wrote:
>
>
> 12 мая 2017 г., в 11:52, Ben Kelly  написал(а):
>
> On Fri, May 12, 2017 at 2:26 PM, Rick Byers  wrote:
>>
>> On Fri, May 12, 2017 at 2:06 PM, Alexey Proskuryakov 
>> wrote:
>>>
>>> Since imported WPT tests are very flaky, and are not necessarily written
>>> to defend against important regressions, investigating issues with them is
>>> relatively lower priority than investigating issues observed with WebKit
>>> tests. So I would recommend not mixing tests for WebKit regressions with WPT
>>> tests - if your test eventually ends up in LayoutTests/imported, it will
>>> become a lot less effective.
>>
>>
>> FWIW this is absolutely NOT how we're treating this in chromium.  If this
>> is how things end up in practice then we will have failed massively in this
>> effort.
>>
>> We figure if we want the web to behave consistently, we really have no
>> choice but to treat web-platform-tests as first class with all the
>> discipline we give to our own tests.  As such we are actively moving many of
>> our LayoutTests to web-platform-tests and depending entirely on the
>> regression prevention they provide us from there.  Obviously there will be
>> hiccups, but because our product quality will depend on web-platform-tests
>> being an effective and non-flaky testsuite (and because we're starting to
>> require most new features have web-platform-tests before they ship), I'm
>> confident that we've got the incentives in place to lead to constant
>> ratcheting up the engineering discipline and quality of the test suite.
>
>
> FWIW, mozilla also treats WPT as first class tests.  We're not actively
> moving old tests to WPT like google, but all new tests (at least in DOM) are
> being written in WPT.  Of course, we do have exceptions for some tests that
> require gecko-specific features (forcing GC, etc).
>
>
> We don't have a concept of "first class", but I hope that when choosing
> between looking into a simple test that was added for a known important bug,
> and looking into an imported test whose importance is unclear, any WebKit
> engineer will pick the former. And since no one can fix all the things, such
> prioritization makes imported tests less effective.
>
>
> I just ran into a classic example of how a WPT incurred more overhead. I
> made a code change that broke
> LayoutTests/imported/w3c/web-platform-tests/cssom-view/elementFromPoint.html.
> I tried loading it in Safari and it doesn't run the test code because it
> can't find /resources/testharness.js when loaded from a local file.
>
> So then I have to figure out how to fire up the WPT server
> (run-webkit-httpd), then figure out which host to use (localhost or
> 128.0.0.1?) and which port, and finally to figure out the right path to the
> test.
>
> There's no reason this test should not work when loaded from file://.
>
> Simon
>
>
> ___
> 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] Unprefixing intrinsic size keywords (-webkit-min-content et al)

2015-08-07 Thread Christian Biesinger
On Fri, Aug 7, 2015 at 3:22 PM, Dean Jackson d...@apple.com wrote:

 On 7 Aug 2015, at 2:44 AM, Christian Biesinger cbiesin...@chromium.org 
 wrote:

 Hi all!

 We (blink) would like to unprefix the intrinsic sizing keywords:
 https://drafts.csswg.org/css-sizing/#width-height-keywords

 We support them for widths and for heights (though they all do the
 same thing for heights)

 We were wondering what Webkit's plan for those keywords is -- are you
 also interested in unprefixing? Are you happy with the keywords as
 specced? Would you rather stop supporting them?

 Is there a test suite?

 I think WebKit should unprefix these keywords.

Thanks for the response! Unfortunately I'm not aware of an official testsuite.

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


[webkit-dev] Unprefixing intrinsic size keywords (-webkit-min-content et al)

2015-08-06 Thread Christian Biesinger
Hi all!

We (blink) would like to unprefix the intrinsic sizing keywords:
https://drafts.csswg.org/css-sizing/#width-height-keywords

We support them for widths and for heights (though they all do the
same thing for heights)

We were wondering what Webkit's plan for those keywords is -- are you
also interested in unprefixing? Are you happy with the keywords as
specced? Would you rather stop supporting them?

thank you!
-christian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)

2013-10-02 Thread Christian Biesinger
On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Tue, Oct 1, 2013 at 4:53 PM, James Craig jcr...@apple.com wrote:

 Follow-up question:  Since this hasn’t made it into the CSS4 spec yet,
 should we temporarily use “-webkit-alt” for the property name? I know there
 has been a push to move away from vendor prefixes lately, so if there are no
 objections, I propose we use the unprefixed version.


 I think that's what Mozilla and Google are doing but I don't think we
 necessary have to follow the suit.

FYI, because IMO this is an important clarification - Mozilla and
Google use unprefixed versions only *behind a (runtime) flag*, until
the spec is stable. That way experimental features are not exposed to
the web at large until it is unlikely that the spec will change, to
avoid cross-browser compatibility risks.

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


[webkit-dev] Ports: Converting media controls to -webkit-flex

2013-02-14 Thread Christian Biesinger
Hi,

currently, media controls all use the deprecated flex box
(-webkit-box). In https://bugs.webkit.org/show_bug.cgi?id=109775, I am
converting them to use the new flex box (-webkit-flex).

I have verified that the result looks correct on the Chromium and Mac
ports, but I am unable to build/test the other ports. You may want to
double-check that the layout looks correct (if you have more than one
flexing control, the layout may be different, e.g. if you have both a
timeline and a volume slider. Otherwise there should be no difference)

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