[prev in list] [next in list] [prev in thread] [next in thread] 

List:       webkit-dev
Subject:    Re: [webkit-dev] Feedback on Blink's text fragment directive proposal
From:       David Bokan <bokan () chromium ! org>
Date:       2020-10-30 20:40:53
Message-ID: CANMmsAs_L3d=LPM-KUKKs_iCO=UL7f-Age5pw_JiZzkHtQrdfA () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Hi Ryosuke,

Would just like to clarify one point.

On Fri, Sep 25, 2020 at 12:42 PM David Bokan <bokan@chromium.org> wrote:

> [Sorry, meant to reply-all]
>
> On Fri, Sep 25, 2020 at 1:25 AM Ryosuke Niwa <rniwa@webkit.org> wrote:
>
>>
>> On Thu, Sep 24, 2020 at 8:19 AM David Bokan <bokan@chromium.org> wrote:
>>
>>> Can you clarify what question you're looking to have answered? Are you
>>>> asking for a new standards position in light of the replies below?
>>>>
>>>
>>>  There are two specific points:
>>>
>>>  - As I understand it, HTML requires multi-vendor interest to merge
>>> changes to specs. Is Apple's position sufficient to start that process? I'd
>>> be happy to start turning the spec into PRs but I interpreted the earlier
>>> position in this thread more as "not-opposed" rather than support (is that
>>> a fair reading?)
>>>
>>
>> Given we're concerned about compatibility and this affects how URL, which
>> is a pretty fundamental part of the Web, is interpreted, it's fair to say
>> we're not ready to endorse such a motion.
>>
>
The change we've proposed and implemented in Chrome doesn't touch anything
in the URL spec or handling; it's entirely an extension to fragment
processing in HTML documents only. If this were implemented in WebKit and
Gecko I think that'd address any compat issues? If you don't agree, could
you clarify what you see as the main compat risk?

Thanks,
David

[Attachment #5 (text/html)]

<div dir="ltr"><div>Hi Ryosuke,</div><div><br></div><div>Would just like to clarify \
one point.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On \
Fri, Sep 25, 2020 at 12:42 PM David Bokan &lt;<a \
href="mailto:bokan@chromium.org">bokan@chromium.org</a>&gt; \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
dir="ltr"><div>[Sorry, meant to reply-all]</div><br><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">On Fri, Sep 25, 2020 at 1:25 AM Ryosuke Niwa &lt;<a \
href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>&gt; \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div \
dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On \
Thu, Sep 24, 2020 at 8:19 AM David Bokan &lt;<a href="mailto:bokan@chromium.org" \
target="_blank">bokan@chromium.org</a>&gt; wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">Can you clarify what question you're looking to \
have answered? Are you asking for a new standards position in light of the replies \
below?<br></blockquote><div><br></div><div>  There are two specific \
points:</div><div><br></div><div>  - As I understand it, HTML requires multi-vendor \
interest to merge changes to specs. Is Apple&#39;s position sufficient to start that \
process? I&#39;d be happy to start turning the spec into PRs but I interpreted the \
earlier position in this thread more as &quot;not-opposed&quot; rather than support \
(is that a fair reading?)</div></div></blockquote><div><br></div><div>Given we&#39;re \
concerned  about compatibility  and this affects how URL, which is a pretty \
fundamental part of the Web,  is interpreted, it&#39;s fair to say we&#39;re not \
ready to endorse  such a \
motion.</div></div></div></blockquote></div></div></blockquote><div><br></div><div>The \
change we&#39;ve proposed and implemented in Chrome doesn&#39;t touch anything in the \
URL spec or handling; it&#39;s entirely an extension to fragment processing in HTML \
documents only. If this were implemented in WebKit and Gecko I think that&#39;d \
address  any compat issues? If you don&#39;t agree, could you clarify what you see as \
the main compat risk?</div><div><br></div><div>Thanks,</div><div>David</div></div></div>




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


[prev in list] [next in list] [prev in thread] [next in thread]