[webkit-dev] Request for position: CSS Ruby Layout Module

[TAMURA, Kent]

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

Re: [webkit-dev] Problems with code review tool

[Aakash Jain]

Interesting. I haven't noticed such problem myself and wasn't aware of this 
issue. I was aware that the EWS status-bubble loading time has been increasing 
steadily as we have been increasing number of EWS queues. Tracked in 
https://bugs.webkit.org/show_bug.cgi?id=214821. I will prioritize fixing it.

Also bugs.webkit.org loads ews status-bubbles from ews.webkit.org in an iframe. 
I never noticed any issue on bugs.webkit.org itself because of slow loading of 
status-bubble. It would be interesting to know if this is a browser specific 
issue.

Thanks
Aakash

> On Sep 23, 2020, at 5:39 PM, Ken Russell  wrote:
> 
> Thanks Saam for your reply.
> 
> Unfortunately this happens nearly every time I use the code review tool.
> 
> Aakash, since this seems to be related to the EWS, is it something you might 
> be able to debug? I also frequently see bugs.webkit.org 
>  tabs display the spinner forever, and it seems to 
> be caused by loading resources from ews.webkit.org . 
> It's likely the same problem.
> 
> Thanks,
> 
> -Ken
> 
> 
> 
> On Tue, Sep 22, 2020 at 7:25 AM Saam Barati  > wrote:
> Hi Ken,
> 
> I think this is a known problem. Unfortunately, this happens to me a few 
> times a year as well.
> 
> - Saam
> 
>> On Sep 21, 2020, at 2:26 PM, Ken Russell > > wrote:
>> 
>> Hi,
>> 
>> Often when I publish code reviews on bugs.webkit.org 
>> , my browser tab gets stuck waiting for 
>> ews.webkit.org . Reloading the bug shows my 
>> comments, but because the submission doesn't complete, the review comments 
>> are still treated as pending by the tool, so publishing again causes 
>> duplicates.
>> 
>> Has anyone else run into this?
>> 
>> (My browser is Chrome on macOS.)
>> 
>> Thanks,
>> 
>> -Ken
>> 
>> 
>> -- 
>> I support flexible work schedules, and I’m sending this email now because it 
>> is within the hours I’m working today.  Please do not feel obliged to reply 
>> straight away - I understand that you will reply during the hours you work, 
>> which may not match mine. (credit: jparent@)
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> 
> 
> 
> 
> -- 
> I support flexible work schedules, and I’m sending this email now because it 
> is within the hours I’m working today.  Please do not feel obliged to reply 
> straight away - I understand that you will reply during the hours you work, 
> which may not match mine. (credit: jparent@)
> 

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

Re: [webkit-dev] Smart Pointer Analysis Tool for WebKit

[Jan Korous]

Hi all,

I am an engineer at Security Tools team at Apple responsible for the tooling 
support for this effort.

> On Sep 23, 2020, at 12:34 PM, Darin Adler  wrote:
> 
>> On Sep 23, 2020, at 12:18 PM, Ryosuke Niwa  wrote:
>> 
>> There are quite a few cases where data members are references but then those 
>> can also be replaced by a simple member function which retrieves the value 
>> of the smart pointer member variable and returns a reference.
> 
> I think this should be an explicit recommendation in the project of 
> refactoring to follow these rules.
> 
>> For now, a trivial function is defined as a member function defined in the 
>> class declaration whose definition simply returns a member variable (the 
>> result of get() or a copy if the member variable is a smart pointer).
> 
> That seems like a rule that’s too narrow. I would not want a function to 
> become non-trivial just because I moved it from being inline within the class 
> definition to an inline below the class definition in the same header.
> 
> This rule worries me a lot right now; it seems like it could result in an 
> explosion of local variable copies of arguments.
> 
>> We probably also need to figure out a way to exempt all lambda functions 
>> that never get stored anywhere. We have a bunch of helper functions like 
>> WTF::map which just calls lambdas on each item while iterating over an 
>> array, etc... and there is no need to create a separate Ref / RefPtr in 
>> those cases since lambdas are never stored and re-used later.
> 
> Does seem important. I am pretty sure I have seen this concept in other 
> languages. We often try to use const Function& for one type of lambda 
> argument and Function&& for the other type, but that’s far from complete.

Re: lambda captures - I think we have two ideas here.

1. Allow WeakPtr captures.
This makes sense to do but it implies we have to add the notion of ownership to 
the rules. The thing is that WeakPtr is safe on its own (and technically 
reference-counted) but it can’t be used as a safety measure in the way of 
RefPtr or Ref since it doesn’t own the memory (not even in a shared manner).

2. Allow raw pointer/reference captures.
This makes sense given you use generic algorithms in the codebase. I will 
implement a new version of the checker - currently it is still based on simple 
AST analysis and for this kind of reasoning we’ll need to use symbolic 
execution in Clang Static Analyzer.

Thanks,

Jan

> — Darin

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

Re: [webkit-dev] Question: referrerpolicy in Safari

[Michael Catanzaro]

On Wed, Sep 23, 2020 at 1:50 pm, Dominic Farolino 
 wrote:
I haven't dug too deep here, but just going to post this in case it 
answers your question and saves you some time. As documented here, it 
appears that Safari is starting to not honor the `referrerpolicy` 
attribute on HTML elements where it would override the referrer 
policy redaction that their cross-site tracking work has performed, 
or at least in cases where it would expose more information than what 
was intended by the cross-site tracking protection. That may be an 
oversimplification, (I trust someone from WebKit can clarify), but it 
may explain the behavior you are seeing.


That probably explains case 1. There's some documentation of this at 
https://webkit.org/tracking-prevention/. The actual URLs matter here. 
With https://site-one.example/path/foo and https://site-two.example/, 
the top privately-controlled domains are different (site-one.example 
vs. site-two.example) so the referrer will be downgraded to its origin. 
But say you were instead testing https://site-one.example.com/path/foo 
and https://site-two.example.com/, then the top privately-controlled 
domain in both cases is example.com, and there's no forced downgrade.


That doesn't explain what's going on in case 2 or case 3, though. 
Smells like bugs?


Michael


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

Re: [webkit-dev] Question: referrerpolicy in Safari

[Dominic Farolino]

On Wed, Sep 23, 2020 at 12:16 PM Maud Nalpas  wrote:

> Hi,
>
> I'm reaching out for a question about Referrer-Policy, more specifically
> about *element**-level* referrer policies (referrerpolicy=...)
> 
> .
>
> I would expect referrerpolicy on HTML elements to override a page's
> policy for the corresponding request.
>
> But this is not what I'm observing on Safari iOS (12) and Desktop (13,
> with "Prevent cross site tracking" on). And this diverges from Chrome's and
> Firefox's behaviour, which seem to honor referrerpolicy on elements.
>
> It's very possible that I'm mistaken and/or that my test site is wrong --
> your input would help!
>

I haven't dug too deep here, but just going to post this in case it answers
your question and saves you some time. As documented here
,
it appears that Safari is starting to not honor the `referrerpolicy`
attribute on HTML elements where it would override the referrer policy
redaction that their cross-site tracking work has performed, or at least in
cases where it would expose more information than what was intended by the
cross-site tracking protection. That may be an oversimplification, (I trust
someone from WebKit can clarify), but it may explain the behavior you are
seeing.

>
> Test
>
> Test site
> 
>
> A policy can be selected in the blue button bar. To test referrerpolicy,
> the useful section is "Let's test element-based referrerpolicy" at the
> bottom of the page.
>
> Examples of unexpected behaviour (can be reproduced on the test site)
>
> 1. On https://site-one.example/path/foo with a document-level policy of
> strict-origin-when-cross-origin:
>
>-
>
>An  element with referrerpolicy=no-referrer-when-downgrade links to
>https://site-two.example (href).
>-
>
>Upon clicking the link and navigating to site-two, site-two gets the
>origin as a Referer in the request (Referer=https://site-one.example).
>-
>
>I would expect Referer=https://site-one.example/path/foo instead (and
>this is the behaviour in Chrome and Firefox).
>
> 2. On https://site-one.example/path/foo with a document-level policy of
> no-referrer:
>
>-
>
>An  element with referrerpolicy=strict-origin-when-cross-origin
>loads an image from *https://site-two.example
>* (src).
>-
>
>site-two gets the full URL in this image request (Referer=
>https://site-one.example/path/foo).
>-
>
>I would expect Referer=https://site-one.example instead (and this is
>the behaviour in Chrome and Firefox).
>
> 3. On https://site-one.example/path/foo with an document-level policy of
> no-referrer-when-downgrade:
>
> A *referrerpolicy* on a 

Re: [webkit-dev] Smart Pointer Analysis Tool for WebKit

[Darin Adler]

> On Sep 23, 2020, at 12:18 PM, Ryosuke Niwa  wrote:
> 
> There are quite a few cases where data members are references but then those 
> can also be replaced by a simple member function which retrieves the value of 
> the smart pointer member variable and returns a reference.

I think this should be an explicit recommendation in the project of refactoring 
to follow these rules.

> For now, a trivial function is defined as a member function defined in the 
> class declaration whose definition simply returns a member variable (the 
> result of get() or a copy if the member variable is a smart pointer).

That seems like a rule that’s too narrow. I would not want a function to become 
non-trivial just because I moved it from being inline within the class 
definition to an inline below the class definition in the same header.

This rule worries me a lot right now; it seems like it could result in an 
explosion of local variable copies of arguments.

> We probably also need to figure out a way to exempt all lambda functions that 
> never get stored anywhere. We have a bunch of helper functions like WTF::map 
> which just calls lambdas on each item while iterating over an array, etc... 
> and there is no need to create a separate Ref / RefPtr in those cases since 
> lambdas are never stored and re-used later.

Does seem important. I am pretty sure I have seen this concept in other 
languages. We often try to use const Function& for one type of lambda argument 
and Function&& for the other type, but that’s far from complete.

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

Re: [webkit-dev] Smart Pointer Analysis Tool for WebKit

[Ryosuke Niwa]

On Wed, Sep 23, 2020 at 10:32 AM Darin Adler  wrote:

> On Sep 16, 2020, at 11:32 PM, Ryosuke Niwa  wrote:
>
>1. Every data member to a ref counted object must use either Ref,
>RefPtr, or WeakPtr. webkit.NoUncountedMemberChecker
>
> 
>
> My only worry here is performance. Do we know yet if we can afford it?
>

We still need to find that out. So far, our deployment of smart pointers in
various DOM objects haven't caused perf regressions yet.

The worst case here is Ref, which is much worse than a reference since we
> end up having to use -> instead of . everywhere and you can’t see that
> there is no null involved.
>

In practice, this may not matter much because in many of our codebases,
most of references are used as function arguments, in which case, they're
still allowed without having to store in a local Ref / RefPtr. There are
quite a few cases where data members are references but then those can also
be replaced by a simple member function which retrieves the value of the
smart pointer member variable and returns a reference.

>
>1. Every ref counted base class, if it has a derived class, must
>define a virtual destructor. webkit.RefCntblBaseVirtualDtor
>
> 
>
> The style system has an optimization that intentionally violates this for
> performance reasons (StyleRuleBase).
>

Interesting. I wasn't aware of this example. We're planning to add some
kind of compiler-level annotations to exempt these warnings so we may need
to apply that here if it's important for performance.

>
>1. Every ref counted object passed to a non-trivial function as an
>argument (including "this" pointer) should be stored as a Ref or RefPtr in
>the caller’s local scope unless it's an argument to the caller itself by
>transitive property [1]. alpha.webkit.UncountedCallArgsChecker
>
> 
>
> What is a non-trivial function?
>

For now, a trivial function is defined as a member function defined in the
class declaration whose definition simply returns a member variable (the
result of get() or a copy if the member variable is a smart pointer).

>
>1. Every ref counted object must be captured using Ref or RefPtr for
>lambda. webkit.UncountedLambdaCapturesChecker
>
> 
>
> Ref, RefPtr, or WeakPtr, right?
>
> Same concern about Ref vs references.
>

This is an interesting point. We should probably amend the rule to allow
WeakPtr as well.

Jan: do we currently allow WeakPtr or just Ref / RefPtr?

We probably also need to figure out a way to exempt all lambda functions
that never get stored anywhere. We have a bunch of helper functions like
WTF::map which just calls lambdas on each item while iterating over an
array, etc... and there is no need to create a separate Ref / RefPtr in
those cases since lambdas are never stored and re-used later.

I wonder if there is a way for your tool to automatically figure that out?
e.g. notice that a function never stores lambda anywhere, and then
propagate that information as some kind of function attribute. Then any
function that doesn't store lambda anywhere and only calls those functions
that also don't store lambda anywhere can marked as "safe".

>
>1. Local variables - we’re still working on this (
>https://reviews.llvm.org/D83259)
>
> I am looking forward to learning more about the proposal here.
>
> Same concern about Ref vs. references.
>
> I really want to see before/after for some non-trivial source files with
> significant problems; where will this drive the most change and what will
> things look like after?
>

Right, for both performance measurements and code changes, we probably want
to fix warnings in a large quality in some important files and see
before/after.

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

[webkit-dev] Question: referrerpolicy in Safari

[Maud Nalpas]

Hi,

I'm reaching out for a question about Referrer-Policy, more specifically
about *element**-level* referrer policies (referrerpolicy=...)

.

I would expect referrerpolicy on HTML elements to override a page's policy
for the corresponding request.

But this is not what I'm observing on Safari iOS (12) and Desktop (13, with
"Prevent cross site tracking" on). And this diverges from Chrome's and
Firefox's behaviour, which seem to honor referrerpolicy on elements.

It's very possible that I'm mistaken and/or that my test site is wrong --
your input would help!

Test

Test site


A policy can be selected in the blue button bar. To test referrerpolicy,
the useful section is "Let's test element-based referrerpolicy" at the
bottom of the page.

Examples of unexpected behaviour (can be reproduced on the test site)

1. On https://site-one.example/path/foo with a document-level policy of
strict-origin-when-cross-origin:

   -

   An  element with referrerpolicy=no-referrer-when-downgrade links to
   https://site-two.example (href).
   -

   Upon clicking the link and navigating to site-two, site-two gets the
   origin as a Referer in the request (Referer=https://site-one.example).
   -

   I would expect Referer=https://site-one.example/path/foo instead (and
   this is the behaviour in Chrome and Firefox).

2. On https://site-one.example/path/foo with a document-level policy of
no-referrer:

   -

   An  element with referrerpolicy=strict-origin-when-cross-origin
   loads an image from *https://site-two.example *
   (src).
   -

   site-two gets the full URL in this image request (Referer=
   https://site-one.example/path/foo).
   -

   I would expect Referer=https://site-one.example instead (and this is the
   behaviour in Chrome and Firefox).

3. On https://site-one.example/path/foo with an document-level policy of
no-referrer-when-downgrade:

A *referrerpolicy* on a 

Re: [webkit-dev] Smart Pointer Analysis Tool for WebKit

[Darin Adler]

> On Sep 23, 2020, at 10:32 AM, Darin Adler  wrote:
> 
>> On Sep 16, 2020, at 11:32 PM, Ryosuke Niwa > > wrote:
>> Every data member to a ref counted object must use either Ref, RefPtr, or 
>> WeakPtr. webkit.NoUncountedMemberChecker 
>> My
>>  only worry here is performance. Do we know yet if we can afford it?
> 
> The worst case here is Ref, which is much worse than a reference since we end 
> up having to use -> instead of . everywhere and you can’t see that there is 
> no null involved.

I don’t mean performance worst case. I meant “outside of performance concerns, 
the worst downgrade of our programming idioms is Ref”.
>> Every ref counted base class, if it has a derived class, must define a 
>> virtual destructor. webkit.RefCntblBaseVirtualDtor 
>> The
>>  style system has an optimization that intentionally violates this for 
>> performance reasons (StyleRuleBase).

So are we saying we must not do that optimization, or will we have a way to 
suppress the warning for this?

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

Re: [webkit-dev] Smart Pointer Analysis Tool for WebKit

[Darin Adler]

> On Sep 16, 2020, at 11:32 PM, Ryosuke Niwa  wrote:
> Every data member to a ref counted object must use either Ref, RefPtr, or 
> WeakPtr. webkit.NoUncountedMemberChecker 
> My
>  only worry here is performance. Do we know yet if we can afford it?

The worst case here is Ref, which is much worse than a reference since we end 
up having to use -> instead of . everywhere and you can’t see that there is no 
null involved.
> Every ref counted base class, if it has a derived class, must define a 
> virtual destructor. webkit.RefCntblBaseVirtualDtor 
> The
>  style system has an optimization that intentionally violates this for 
> performance reasons (StyleRuleBase).
> Every ref counted object passed to a non-trivial function as an argument 
> (including "this" pointer) should be stored as a Ref or RefPtr in the 
> caller’s local scope unless it's an argument to the caller itself by 
> transitive property [1]. alpha.webkit.UncountedCallArgsChecker 
> What
>  is a non-trivial function?
> Every ref counted object must be captured using Ref or RefPtr for lambda. 
> webkit.UncountedLambdaCapturesChecker 
> Ref,
>  RefPtr, or WeakPtr, right?

Same concern about Ref vs references.
> Local variables - we’re still working on this 
> (https://reviews.llvm.org/D83259 )
I am looking forward to learning more about the proposal here.

Same concern about Ref vs. references.

I really want to see before/after for some non-trivial source files with 
significant problems; where will this drive the most change and what will 
things look like after?

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

Re: [webkit-dev] Smart Pointer Analysis Tool for WebKit

[Ryosuke Niwa]

On Thu, Sep 17, 2020 at 2:51 AM Emilio Cobos Álvarez 
wrote:

> Interesting. This looks fairly similar to some of the checkers we use in
> mozilla-central, fwiw.
>
> One interesting difference is that we opted for explicitly annotating
> the functions that can run script (think updateStyleIfNeeded(),
> dispatchEvent() etc equivalents) to be able to not warn for cases where
> using raw pointers is fine. See [1] for the current rules we're using.
>

That's an interesting alternative. We should consider that if the current
approach proves to cause perf issues.

So, I wonder... for a concrete example like [2], what is what would
> allow you to use shadowHost() without storing it on a local RefPtr
> otherwise, for example? Or is the plan to either pay the refcount churn,
> or silence the warnings on a per-case basis?
>

In this case, we'd like to store shadowHost() on a local RefPtr. "contains"
might be a common enough function that we could consider marking as safe
but in more generic case, there is no guarantee that contains would never
trigger a style or layout update, either of which may execute arbitrary
scripts. Also, script execution isn't the only way to get to memory
unsafely. Any piece of code that manipulates a complex enough data
structure may lead to use-after-free even if there was no arbitrary script
execution involved.

[1]:
>
> https://searchfox.org/mozilla-central/rev/f4b4008f5ee00f5afa3095f48c54f16828e4b22b/build/clang-plugin/CanRunScriptChecker.cpp#5-49
> [2]:
>
> https://webkit-search.igalia.com/webkit/rev/4c54a6d287d7fba30e1fb37d5afda692fb12a758/Source/WebCore/dom/Node.cpp#1041


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

Re: [webkit-dev] Smart Pointer Analysis Tool for WebKit

[Ryosuke Niwa]

On Thu, Sep 17, 2020 at 2:11 AM Konstantin Tokarev 
wrote:

>
> Sounds great! A few questions:
> * Do I understand correctly that analyzer is a part of upstream clang and
> can work on any platform?
>

Yes.

* Does it require WebKit trunk or can work with older branches?


It should work with older branches as well as trunk since it doesn't rely
on any code-level annotations for now.

However, the plan is to add some annotations in the future to suppress
warnings where appropriate although we're hoping that we wouldn't need them
in too many places.

* Any plans to detect other kinds of misuses like circular references?
>

Not for now. For now, our primary focus is to detect dangerous use of
RefCounted objects and possibly any objects that can make WeakPtr in the
future.

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

Re: [webkit-dev] Request for position on isInputPending

[Ryosuke Niwa]

On Fri, Sep 18, 2020 at 11:56 AM Andrew Comminos  wrote:

> We're looking to gather a position from WebKit folks on isInputPending,
> an API to query for the presence of pending input events. It allows
> sites to reduce event latency by yielding during longer computational
> tasks, without sacrificing throughput otherwise.
>
> Explainer: https://github.com/WICG/is-input-pending/
>
> Spec: https://wicg.github.io/is-input-pending/
>

As we have discussed in other avenues, we're skeptical that this API is
needed given native apps on iOS and macOS don't need such an API and many
iOS apps are considered as a pinnacle of good performance.

Also, there are many other things an app needs to yield to respond /
process. There could be another frame pending to be rendered, or a network
request for which a response is ready. There are no ways to inspect whether
such a task is pending or not, and we don't want to end up with isXPending
for every X we can think of in the future.

Furthermore, a well performing app should be yielding at least every frame,
and in that case, there is no need for isInputPending since AppKit will
only send at most one NSEvent of a given type per frame by design.

As such, Apple's WebKit team does not support the current proposal.

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

Re: [webkit-dev] Feedback on Blink's text fragment directive proposal

[Ryosuke Niwa]

On Fri, Sep 18, 2020 at 7:35 AM David Bokan  wrote:

> Friendly ping to get an answer here.
>
> Do my answers above address those points or is there anything else I can
> clarify?
>
> Thanks,
> David
>
> On Mon, Aug 31, 2020 at 1:42 PM David Bokan  wrote:
>
>> [sending (again, sorry) from correct e-mail]
>>
>> I think Nick's replies
>>  
>> mostly
>> still apply, some updated answers to those questions.
>>
>> (1) We’re concerned about compatibility issues in a world where some
>>> browsers support this but not all. Aware browsers will strip `:~:`, but
>>> unaware browsers won’t. I saw that on the blink-dev ItS thread, it was
>>> mentioned that at least one site (webmd.com) totally breaks if any
>>> fragment ID is exposed to the page. This makes it difficult to create a
>>> link that uses this feature but which is safe in all browsers:
>>> - Since there is no feature detection mechanism, it’s hard for a webpage
>>> to know whether it should issue such a link. It would have to be based on
>>> UA string checks, which is regrettable.
>>> - A link meant for a supporting browser can end up in a non-supporting
>>> browser, at the very least by copy paste from the URL field, and perhaps
>>> through other features to share a link.
>>>
>>
>> We do have a feature detection
>> 
>>  mechanism
>> for this.
>>
>> On the latter point, this is true but we think implementing fragment
>> directive stripping (removing the part after and including `:~:`) is
>> trivial even if the UA doesn't wish to implement the text-fragment feature.
>> FWIW, we haven't seen or heard of another such example since.
>>
>
We're continued to be concerned about this backwards compatibility issue.

(3) Text fragment trumping a regular fragment ID seems a bit strange. The
>>> more natural semantic would be that the text search starts at the fragment,
>>> so if there are multiple matches it’s possible to scroll to a more specific
>>> one. It’s not clear why the fragment is instead entirely ignored.
>>>
>>
>> This was discussed in more detail in issue#75
>> ; I agree
>> with Nick's point that the disambiguation syntax is already specific enough
>> that starting from a fragment isn't necessary. This also keeps us
>> mostly-compatible with the TextQuoteSelector
>>  specified
>> in WebAnnotations which I think may have benefits for interaction with
>> annotation applications.
>>
>
This will limit the utility of this feature. For something as board
impacting as a URL format change, it seems rather short sighted.

Also, Web Annotations Data Model allows other kinds of annotations:
https://www.w3.org/TR/2017/REC-annotation-model-20170223/#selectors

Is there any reason this particular matching algorithm was picked and only
picked with no possibility of the future extensibility?

- R. Niwa
___
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

[TAMURA, Kent]

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