[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: Re: [webkit-dev] Request for position on Badging API
From: Maciej Stachowiak <mjs () apple ! com>
Date: 2020-02-20 0:37:53
Message-ID: 3A0034E1-2A4F-4332-AFE5-67239FF25F51 () apple ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On Feb 19, 2020, at 4:35 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
>
>
> > On Feb 19, 2020, at 4:31 PM, Matt Giuca <mgiuca@chromium.org <mailto:mgiuca@chromium.org>> \
> > wrote:
> >
> >
> > On Thu, 20 Feb 2020 at 11:18, Ryosuke Niwa <rniwa@webkit.org <mailto:rniwa@webkit.org>> \
> > wrote:
> > On Wed, Feb 19, 2020 at 3:29 PM Matt Giuca <mgiuca@chromium.org \
> > <mailto:mgiuca@chromium.org>> wrote: On Wed, 19 Feb 2020 at 18:14, Ryosuke Niwa \
> > <rniwa@webkit.org <mailto:rniwa@webkit.org>> wrote:
> > On Tue, Feb 18, 2020 at 4:02 PM Matt Giuca <mgiuca@chromium.org \
> > <mailto:mgiuca@chromium.org>> wrote: Thanks for the replies. Folding both Dean and \
> > Ryosuke's emails into one.
> > On Mon, 17 Feb 2020 at 03:03, Dean Jackson <dino@apple.com <mailto:dino@apple.com>> wrote:
> > Not speaking for all of WebKit, and definitely not all of Apple, but I think this seems \
> > like a good idea.
> > I'm not sure I get the distinction between app badges and document badges though. I'd also \
> > like to see some specification text describing how the browser should ignore multiple \
> > set/clear operations executed in rapid succession (e.g. to create a blinking badge) - maybe \
> > the limit is one badge operation per minute or something?
> > Good suggestion. Filed an issue: https://github.com/WICG/badging/issues/68 \
> > <https://github.com/WICG/badging/issues/68>
> > Also, given that the main use case for this would be alerting the user to a notification, \
> > it seems like it should be able to link it directly to that. This would provide the ability \
> > for a push notification to trigger the badge without ever firing up the page context.
> > I'm not sure what you mean by "link directly to that". We've deliberately specified this as \
> > separate to notifications (since you may or may not want the badge to be set without one). \
> > If you want to show a notification and a badge at the same time, you can use both APIs \
> > together. If you want to have a push notification set the badge when the service worker \
> > runs, you can do that (but as has been discussed at length: \
> > https://github.com/WICG/badging/issues/28 <https://github.com/WICG/badging/issues/28>, you \
> > can't currently set a badge without a notification from a push message).
> > On Mon, 17 Feb 2020 at 03:49, Ryosuke Niwa <rniwa@webkit.org <mailto:rniwa@webkit.org>> \
> > wrote: For the record, we have two concerns raised internally at Apple:
> > * The integration of this API with push service worker would require running scripts in \
> > order to update the badge. This will pose a serious power consumption issue.
> > That isn't a feature of the current proposal. The spec doesn't give service worker push any \
> > new capabilities that it didn't already have (in particular, if the browser requires the \
> > push message to show a notification, that is still true; you simply cannot set a badge from \
> > a push message without showing a notification). See \
> > https://github.com/WICG/badging/issues/28 <https://github.com/WICG/badging/issues/28>and \
> > https://github.com/WICG/badging/blob/master/explainer.md#background-updates \
> > <https://github.com/WICG/badging/blob/master/explainer.md#background-updates>.
> > This is something we've given some thought to. We (Google) would like to eventually see it \
> > possible to set a badge in the background without a notification. But the power consumption \
> > and privacy issues are well known, and at this stage, it is not being proposed.
> > Because all background processes (including non-foreground tabs) are suspend on iOS, this \
> > makes this feature pretty much useless. If the user is currently seeing a website, then \
> > there is no need for updating the badge since the user is already there. On the other hand, \
> > if the user isn't currently seeing the website, then the website' scripts are never gonna \
> > run.
> > I see. So it sounds like this API would be useful but only once combined with a future \
> > proposal to let badges be set via push.
> >
> > * We don't want every website to start using this API to increase "engagement".
> >
> > Do you mean as a way of drawing additional attention to itself? Well, the setAppBadge API \
> > can only be used by installed applications, so that doesn't apply to every site the user \
> > might visit. And the user agent / OS can provide the user with UI to suppress badges on a \
> > per-app basis if an app is too spammy. The setClientBadge API could be used by any website \
> > to draw attention, but the user agent should make the badge sufficiently subtle that this \
> > is no more abusive than a favicon, which can already be used to show a pseudo-badge.
> > Since there is not a concept of installed web apps in Safari on macOS, this isn't going to \
> > work there.
> > The setClientBadge API still makes sense on Safari on macOS.
> >
> > It doesn't because we don't have a concept of installed apps, and we don't want to let any \
> > website use this API as that may annoy users.
> > I just want to be clear about what setClientBadge is for. (And note that nobody has \
> > implemented this yet; it's just in the draft spec as proposed by Marcos Caceres from \
> > Firefox.)
> > This has nothing to do with installed apps. It's just about being able to badge the current \
> > document's tab, as seen in the first screenshot in the explainer: \
> > https://github.com/WICG/badging/blob/master/explainer.md#overview \
> > <https://github.com/WICG/badging/blob/master/explainer.md#overview> This is something that \
> > sites can already do (by modifying the page's favicon), but the API gives sites a way to \
> > set the badge semantically, which is advantageous because it means the UA can provide a \
> > consistent look and feel across all sites, accessibility features can announce badge \
> > changes, etc.
>
> Does this mean it's specifically not intended for app icon badging at all? Would that need a \
> whole different API, then, or can this API scale to that use case?
I should have read the link. It looks like it's intended for both use cases. We were probably \
only thinking of app icon badging (macOS dock, iOS home screen, etc when reviewing the spec).
- Maciej
> - Maciej
>
> >
> >
> > - R. Niwa
> >
> > On Sun, Jan 19, 2020 at 16:27 Matt Giuca <mgiuca@chromium.org <mailto:mgiuca@chromium.org>> \
> > wrote: Hi WebKit team,
> >
> > I have previously proposed the Badging API (https://github.com/WICG/badging \
> > <https://github.com/WICG/badging>) to provide websites with a mechanism to set a badge (a \
> > small dot or number) on the current document's tab, or for installed applications, on the \
> > app icon in the system shelf or home screen.
> > Would WebKit / Safari be interested in implementing the API now or in the future?
> >
> > We are planning to ship in Chromium soon:
> > https://groups.google.com/a/chromium.org/g/blink-dev/c/fHc49JNFTAU/m/bJD25Yr7CAAJ \
> > <https://groups.google.com/a/chromium.org/g/blink-dev/c/fHc49JNFTAU/m/bJD25Yr7CAAJ>
> > Regards
> >
> >
> > Matt Giuca
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> > https://lists.webkit.org/mailman/listinfo/webkit-dev \
> > <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> > --
> > - R. Niwa
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> > https://lists.webkit.org/mailman/listinfo/webkit-dev \
> > <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev \
> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
[Attachment #5 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body \
style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" \
class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Feb \
19, 2020, at 4:35 PM, Maciej Stachowiak <<a href="mailto:mjs@apple.com" \
class="">mjs@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div \
class=""><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; \
font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; \
text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: \
0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br \
class="Apple-interchange-newline"><br class=""><blockquote type="cite" class=""><div \
class="">On Feb 19, 2020, at 4:31 PM, Matt Giuca <<a href="mailto:mgiuca@chromium.org" \
class="">mgiuca@chromium.org</a>> wrote:</div><br class="Apple-interchange-newline"><div \
class=""><div dir="ltr" class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; \
font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; \
letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: \
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><br \
class="Apple-interchange-newline"><br class=""><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Thu, 20 Feb 2020 at 11:18, Ryosuke Niwa <<a \
href="mailto:rniwa@webkit.org" class="">rniwa@webkit.org</a>> wrote:<br \
class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; \
border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); \
padding-left: 1ex;"><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 19, 2020 at 3:29 PM Matt \
Giuca <<a href="mailto:mgiuca@chromium.org" target="_blank" \
class="">mgiuca@chromium.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" \
style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; \
border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr" class=""><div \
dir="ltr" class="">On Wed, 19 Feb 2020 at 18:14, Ryosuke Niwa <<a \
href="mailto:rniwa@webkit.org" target="_blank" class="">rniwa@webkit.org</a>> wrote:<br \
class=""></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px \
0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, \
204); padding-left: 1ex;"><div dir="ltr" class=""><div dir="ltr" class=""><br \
class=""></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 18, 2020 \
at 4:02 PM Matt Giuca <<a href="mailto:mgiuca@chromium.org" target="_blank" \
class="">mgiuca@chromium.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" \
style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; \
border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr" class=""><div \
dir="ltr" class="">Thanks for the replies. Folding both Dean and Ryosuke's emails into \
one.</div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class=""><div dir="ltr" \
class="gmail_attr">On Mon, 17 Feb 2020 at 03:03, Dean Jackson <<a \
href="mailto:dino@apple.com" target="_blank" class="">dino@apple.com</a>> wrote:<br \
class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; \
border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); \
padding-left: 1ex;"><div class="">Not speaking for all of WebKit, and definitely not all of \
Apple, but I think this seems like a good idea.<div class=""><br class=""></div><div \
class="">I'm not sure I get the distinction between app badges and document badges though. I'd \
also like to see some specification text describing how the browser should ignore multiple \
set/clear operations executed in rapid succession (e.g. to create a blinking badge) - maybe the \
limit is one badge operation per minute or something?</div></div></blockquote><div class=""><br \
class=""></div><div class="">Good suggestion. Filed an issue: <a \
href="https://github.com/WICG/badging/issues/68" target="_blank" \
class="">https://github.com/WICG/badging/issues/68</a></div><div class=""><br \
class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; \
border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); \
padding-left: 1ex;"><div class=""><div class="">Also, given that the main use case for this \
would be alerting the user to a notification, it seems like it should be able to link it \
directly to that. This would provide the ability for a push notification to trigger the badge \
without ever firing up the page context.<br class=""></div></div></blockquote><div class=""><br \
class=""></div><div class="">I'm not sure what you mean by "link directly to that". We've \
deliberately specified this as separate to notifications (since you may or may not want the \
badge to be set without one). If you want to show a notification and a badge at the same time, \
you can use both APIs together. If you want to have a push notification set the badge when the \
service worker runs, you can do that (but as has been discussed at length: <a \
href="https://github.com/WICG/badging/issues/28" target="_blank" \
class="">https://github.com/WICG/badging/issues/28</a>, you<span \
class="Apple-converted-space"> </span><i class="">can't</i> currently set a badge \
without a notification from a push message).</div></div><br class=""><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 17 Feb 2020 at 03:49, Ryosuke \
Niwa <<a href="mailto:rniwa@webkit.org" target="_blank" class="">rniwa@webkit.org</a>> \
wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; \
border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); \
padding-left: 1ex;"><div class=""><div class=""><div dir="auto" class="">For the record, we \
have two concerns raised internally at Apple:</div></div><div dir="auto" class=""> * The \
integration of this API with push service worker would require running scripts in order to \
update the badge. This will pose a serious power consumption \
issue.</div></div></blockquote><div class=""><br class=""></div><div class="">That isn't a \
feature of the current proposal. The spec doesn't give service worker push any new capabilities \
that it didn't already have (in particular, if the browser requires the push message to show a \
notification, that is still true; you simply cannot set a badge from a push message without \
showing a notification). See <a href="https://github.com/WICG/badging/issues/28" \
target="_blank" class="">https://github.com/WICG/badging/issues/28</a>and <a \
href="https://github.com/WICG/badging/blob/master/explainer.md#background-updates" \
target="_blank" class="">https://github.com/WICG/badging/blob/master/explainer.md#background-updates</a>.</div><div \
class=""><br class=""></div><div class="">This is something we've given some thought to. We \
(Google) would like to eventually see it possible to set a badge in the background without a \
notification. But the power consumption and privacy issues are well known, and at this stage, \
it is not being proposed.</div></div></div></blockquote><div class=""><br class=""></div><div \
class="">Because all background processes (including non-foreground tabs) are suspend on iOS, \
this makes this feature pretty much useless. If the user is currently seeing a website, then \
there is no need for updating the badge since the user is already there. On the other hand, if \
the user isn't currently seeing the website, then the website' scripts are never gonna \
run.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I see. So it \
sounds like this API would be useful but only once combined with a future proposal to let \
badges be set via push.</div><div class=""> </div><blockquote class="gmail_quote" \
style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; \
border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr" class=""><div \
class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" \
style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; \
border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr" class=""><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; \
border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); \
padding-left: 1ex;"><div class=""><div dir="auto" class=""> * We don't want every website \
to start using this API to increase "engagement".</div></div></blockquote><div class=""><br \
class=""></div><div class="">Do you mean as a way of drawing additional attention to itself? \
Well, the setAppBadge API can only be used by installed applications, so that doesn't apply to \
every site the user might visit. And the user agent / OS can provide the user with UI to \
suppress badges on a per-app basis if an app is too spammy. The setClientBadge API could be \
used by any website to draw attention, but the user agent should make the badge sufficiently \
subtle that this is no more abusive than a favicon, which can already be used to show a \
pseudo-badge.</div></div></div></blockquote><div class=""><br class=""></div><div \
class="">Since there is not a concept of installed web apps in Safari on macOS, this isn't \
going to work there.</div></div></div></blockquote><div class=""><br class=""></div><div \
class="">The setClientBadge API still makes sense on Safari on \
macOS.</div></div></div></blockquote><div class=""><br class=""></div><div class="">It doesn't \
because we don't have a concept of installed apps, and we don't want to let any website use \
this API as that may annoy users.</div></div></div></blockquote><div class=""><br \
class=""></div><div class="">I just want to be clear about what setClientBadge is for. (And \
note that nobody has implemented this yet; it's just in the draft spec as proposed by Marcos \
Caceres from Firefox.)</div><div class=""><br class=""></div><div class="">This has nothing to \
do with installed apps. It's just about being able to badge the current document's tab, as \
seen in the first screenshot in the explainer:</div><div class=""><a \
href="https://github.com/WICG/badging/blob/master/explainer.md#overview" \
class="">https://github.com/WICG/badging/blob/master/explainer.md#overview</a><br \
class=""></div><div class="">This is something that sites can already do (by modifying the \
page's favicon), but the API gives sites a way to set the badge semantically, which is \
advantageous because it means the UA can provide a consistent look and feel across all sites, \
accessibility features can announce badge changes, \
etc.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Does \
this mean it's specifically not intended for app icon badging at all? Would that need a whole \
different API, then, or can this API scale to that use \
case?</div></div></div></blockquote><div><br class=""></div>I should have read the link. It \
looks like it's intended for both use cases. We were probably only thinking of app icon badging \
(macOS dock, iOS home screen, etc when reviewing the spec).</div><div><br \
class=""></div><div> - Maciej<br class=""><div><br class=""></div><br class=""><blockquote \
type="cite" class=""><div class=""><div style="caret-color: rgb(0, 0, 0); font-family: \
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; \
letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: \
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" \
class=""><div class=""> - Maciej</div><br class=""><blockquote type="cite" class=""><div \
class=""><div dir="ltr" class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; \
font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; \
letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: \
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div \
class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin: \
0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: \
rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_quote"><div \
class=""><br class=""></div><div class="">- R. Niwa</div><div class=""><br \
class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; \
border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); \
padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_quote"><blockquote \
class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; \
border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div \
dir="ltr" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px \
0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, \
204, 204); padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_quote"><blockquote \
class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; \
border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div \
class=""><div class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan \
19, 2020 at 16:27 Matt Giuca <<a href="mailto:mgiuca@chromium.org" target="_blank" \
class="">mgiuca@chromium.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" \
style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; \
border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr" class="">Hi WebKit \
team,<br class=""><br class="">I have previously proposed the Badging API (<a \
href="https://github.com/WICG/badging" target="_blank" \
class="">https://github.com/WICG/badging</a>) to provide websites with a mechanism to set a \
badge (a small dot or number) on the current document's tab, or for installed applications, on \
the app icon in the system shelf or home screen.<br class=""><br class="">Would WebKit / Safari \
be interested in implementing the API now or in the future?<br class=""><br class="">We are \
planning to ship in Chromium soon:<br class=""><a \
href="https://groups.google.com/a/chromium.org/g/blink-dev/c/fHc49JNFTAU/m/bJD25Yr7CAAJ" \
target="_blank" class="">https://groups.google.com/a/chromium.org/g/blink-dev/c/fHc49JNFTAU/m/bJD25Yr7CAAJ</a><br \
class=""><br class="">Regards</div><div dir="ltr" class=""><br class=""><br class="">Matt \
Giuca<br class=""></div>_______________________________________________<br class="">webkit-dev \
mailing list<br class=""><a href="mailto:webkit-dev@lists.webkit.org" target="_blank" \
class="">webkit-dev@lists.webkit.org</a><br class=""><a \
href="https://lists.webkit.org/mailman/listinfo/webkit-dev" rel="noreferrer" target="_blank" \
class="">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br \
class=""></blockquote></div></div></div>--<span class="Apple-converted-space"> </span><br \
class=""><div dir="ltr" class="">- R. \
Niwa</div></blockquote></div></div></blockquote></div></div></blockquote></div></div></blockquote></div></div></blockquote></div></div><span \
class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: \
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: \
start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; \
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline \
!important;">_______________________________________________</span><br class="" \
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; \
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; \
text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; \
-webkit-text-stroke-width: 0px; text-decoration: none;"><span class="" style="caret-color: \
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: \
normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; \
text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; \
text-decoration: none; float: none; display: inline !important;">webkit-dev mailing \
list</span><br class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: \
12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: \
normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; \
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><span class="" \
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; \
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; \
text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; \
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline \
!important;"><a href="mailto:webkit-dev@lists.webkit.org" \
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic