Re: Handing off W3C Advisory Committee duties

[Tantek Çelik]

On Wed, May 20, 2020 at 3:30 PM L. David Baron  wrote:
>
> For quite a while, I've been posting reviews of proposed W3C
> charters and W3C Proposed Recommendations to this list, as part of
> being Mozilla's representative to the W3C Advisory Committee, which
> really means the person who expresses official Mozilla positions on
> things to W3C, and designates Mozilla representatives to working
> groups, who can then represent Mozilla in the discussions within
> working groups.
>
> I've just handed off the responsibility of being the Advisory
> Committee Representative to Tantek Çelik, so in the future you
> should expect to see those reviews coming from him rather than from
> me.

Thanks David. I expect to continue to reach out from time to time.

> (On a side note, it's also not clear to me that dev-platform is
> really the best way to have those discussions today; it's possible
> we should look for an alternative forum that lends itself a bit more
> to discussion.)

I'm not sure either, however for the moment I'll continue with posting
about charters & recommendations here until we figure out something
better.

In addition, this is as good a time as any to ask anyone on this list
involved in standards at Mozilla to please take a look and make sure
you've listed yourself in the groups you're participating here:
https://wiki.mozilla.org/Standards
(I've tried to maintain departures, LMK if you see something amiss and
I can take care of it).

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS subgrid

[Tantek Çelik]

Agreed with clarification. Declarative text/css stylesheets not
restricted. Imperative new APIs (like Houdini APIs) should be
restricted to secure contexts by default. Thanks, Tantek

On Fri, Oct 18, 2019 at 4:53 PM Daniel Veditz  wrote:
>
> On Fri, Oct 18, 2019 at 4:27 PM Tantek Çelik  wrote:
>>
>> Based on your reasoning, and our consistent intent emails and shipping
>> behavior, I think we should consider updating the blog post on this
>> matter regarding all CSS features (cc: annevk), or posting a separate
>> update post accordingly, using the reasoning you've provided as our
>> guidance.
>
>
> Just to be clear I was not talking about "all" CSS features but mainly the 
> ones specified in text/css stylesheets. New CSS features that are implemented 
> through JavaScript APIs (like CSS Painting API) ought to be restricted, and 
> exemptions should require an explicit compelling argument. Browsers have 
> already invented mechanisms to expose properties conditionally so it's not an 
> implementation burden, and it's possible for web developers to do feature 
> detection and deal with it. The calculus comes out differently.
>
> [I note the CSS Painting API spec doesn't mention such restrictions 
> currently, but Chrome's implementation seems to have done so anyway.]
>
> -Dan Veditz
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS subgrid

[Tantek Çelik]

Thanks Dan. I concur with the priorities, impacts, and conclusions
you've outlined.

In practice I believe 100% of the CSS features we have shipped (Intent
to Implement/Ship emails) in the past year+ have been exposed to
insecure contexts.

Based on your reasoning, and our consistent intent emails and shipping
behavior, I think we should consider updating the blog post on this
matter regarding all CSS features (cc: annevk), or posting a separate
update post accordingly, using the reasoning you've provided as our
guidance. I'd prefer the former as many have linked to that blog post.

Thanks,
Tantek




On Fri, Oct 18, 2019 at 10:32 AM Daniel Veditz  wrote:
>
> From my (personal) security-team perspective this is a fine pragmatic
> approach. Our overriding primary concern is whether exposing these new CSS
> features over insecure transport puts our users at additional risk. I don't
> see any meaningful privacy exposure here since these new features will be
> in a stylesheet that's already insecure, and style doesn't typically
> contain user data. There will be additional "attack surface" of course
> (more features ~= more bugs) but it's trivially easy for an attacker to use
> a secure stylesheet instead if that's required to access a buggy feature.
>
> Coercing site authors into better behavior is a secondary concern (user
> safety, once removed), and some amount of pragmatism is acceptable. These
> features are being standardized through the W3C, and given W3C statements
> about the importance of  switching the web to secure transport we should
> give those standards bodies a chance to do the appropriate thing. Web
> compatibility with other browsers is important given Mozilla's market
> share, and while we can take a stand against compatibility (and have) when
> there's demonstrable user harm from a feature, these incremental additions
> to CSS don't appear to come anywhere close to that bar.
>
> -Dan Veditz
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: SVG Working Group

[Tantek Çelik]

Comments inline.

On Thu, Jan 24, 2019 at 5:54 PM L. David Baron  wrote:
>
> On Sunday 2018-12-23 09:59 -0800, L. David Baron wrote:
> > The W3C is proposing a revised charter for:
> >
> >   Scalable Vector Graphics (SVG) Working Group
> >   https://www.w3.org/Graphics/SVG/svg-2019-ac.html
> >   https://lists.w3.org/Archives/Public/public-new-work/2018Dec/0006.html
> >
> > Mozilla has the opportunity to send comments or objections through
> > Friday, January 25.
> >
> > Please reply to this thread if you think there's something we should
> > say as part of this charter review, or if you think we should
> > support or oppose it.  Given our past involvement, we should
> > probably have some comment, even if it's simply in support.
> >
> > A comparison with the current charter is:
> > https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2017%2F04%2Fsvg-2017.html=https%3A%2F%2Fwww.w3.org%2FGraphics%2FSVG%2Fsvg-2019-ac.html
>
> Based on the comments from Henri and Cameron, I propose to submit
> the following comments.  Please let me know in the next 24 hours if
> there's anything wrong with them.

In general this is very good.


> -David
>
> We generally support this charter and its focus on stabilization and testing, 
> although we're not sure we'll be able to put significant effort into 
> supporting the group's work.

Add: ... especially any new features.

Based on just the past two years of new feature implementation (CSS
etc.), It's quite likely that we wouldn't be able to prioritize
allocating time to debating/discussing details of new SVG features
(much less implementing them), before the end of this charter period.

> There are two particular concerns we have with the charter.
>
> The first is with the sentence "As a secondary focus, the group may address 
> modules for new graphical features for SVG, once there is broad consensus on 
> adding each such feature to the Web Platform."  We'd like this sentence to be 
> clearer that "broad consensus" needs to include consensus of implementors; it 
> shouldn't be sufficient if there are a significant number of users interested 
> in a feature but only a single implementor.

Two things:

1. This charter sentence concerns me a lot. It feels too open ended
and underspecified as to what new graphical features. I'd prefer that
this sentence be rewritten for new feature incubation / development to
happen across the SVG CG / SVG WG similar to new feature incubation /
development happens in WICG and graduates to WPWG (Soon to be
WebAppsWG).

2. This (even the just the existing concerns noted above) is worth a
FO.  I would reword the double-negative ("shouldn't be sufficient ...
but only") for clarity, e.g.:
"We'd like this sentence to be clearer that "broad consensus" needs to
include consensus of implementors; a single implementor is
insufficient; broad consensus must be include explicit interest from
at least two implementors in addition to users interested in a
feature."


> The second is with the statement that SVG 2 updates SVG 1.1 to include 
> HTML5-compatible parsing.  While that's probably fine, we'd like it to be 
> clear that changes to the HTML parsing algorithm are out of scope; the HTML 
> parsing algorithm should be maintained in the HTML specification, and should 
> be changed very rarely due to the high costs of updating both client-side and 
> server-side software and the costs of those pieces of software being 
> out-of-sync.
>
>
> We also have a few other smaller comments:
>
> - The proposed "Core SVG" specification seems in some ways to duplicate or 
> replace the work in https://www.w3.org/TR/svg-integration/ .  It would be 
> useful to clarify the relationship.
>
> - The statement in the Scope section that "The SVG WG develops a single 
> deliverable" seems to conflict with the deliverables section.

These are good. Also perhaps drop this from 3.1 W3C Groups:
"
Web Platform Working Group
Coordinate on integration of SVG and HTML, and on compatibility with
the Canvas API specifications.
"
As that WG will not exist by the time the SVG WG gets restarted.

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: implicit rel=noopener for target=_blank on anchor and area elements

[Tantek Çelik]

For the archives, s/ref/rel in subject.

I am seeing some publisher uptake of rel="noopener" so it is good that
we are shipping this.

Thanks Andrea,

Tantek

On Thu, Jan 24, 2019 at 3:52 AM Andrea Marchesini
 wrote:
>
> I intend to turn "implicit ref=noopener for anchor and area elements for
> target=_blank" on by default in 67. It has been developed behind the
> "dom.targetBlankNoOpener.enabled" preference and enabled in nightly for ~2
> cycles (it landed in FF65).
>
> Safari has already shipped this feature:
> https://webkit.org/blog/8475/release-notes-for-safari-technology-preview-68/
>
> Bug to turn on by default:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1522083
>
> This feature was previously discussed in this "intent to implement"
> thread:
> https://groups.google.com/forum/#!searchin/mozilla.dev.platform/intent$20to$20implement$20rel$3D%7Csort:date/mozilla.dev.platform/d4R7WIHSOMY/iHBAH0koCgAJ
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: scrollbar-color and scrollbar-width properties

[Tantek Çelik]

On Tue, Sep 25, 2018 at 5:59 PM, Xidorn Quan  wrote:
> As of Firefox 64, I intend to turn scrollbar-color and scrollbar-width 
> properties on by default on all platforms. They have been developed behind 
> pref "layout.css.scrollbar-colors.enabled" and 
> "layout.css.scrollbar-width.enabled" respectively.

Great work Xidorn!!!

Also as of *today* the W3C has published the first public working
draft of CSS Scrollbars Module Level 1 which defines these properties:

https://www.w3.org/TR/css-scrollbars-1/


> Other UAs don't currently have plan to ship it,

They don't have explicit plans, however at least two have strongly
indicated they would like to in past CSSWG f2f meetings. I think we
can affect that by shipping. We will bring this up at TPAC.


> but WebKit and Blink have non-standard -webkit-prefixed scrollbar 
> pseudo-elements support for long,

And they have also indicated they want something better (simpler,
easier to maintain) to recommend for the future. The current design
incorporates a bunch of the feedback from WebKit and Blink when these
features were discussed in the CSS Working Group.


> which the CSSWG agrees that it is not something should be kept on the web 
> platform, while Gecko has been facing some compat pressure for this. These 
> two properties should cover most of the common use cases, and we can use them 
> to convince websites to support Firefox, as well as shipping our own fixup 
> stylesheets with Go Faster when necessary.
>
> Bug to turn on by default: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1492012
>
> The features were previously discussed in these "intent to implement" threads:
> * scrollbar-color: 
> https://groups.google.com/d/msg/mozilla.dev.platform/X_tv4aH4NxQ/w497k6J7CQAJ
> * scrollbar-width: 
> https://groups.google.com/d/msg/mozilla.dev.platform/JhdWiVwgQeo/tSKKqatvCQAJ
>
> Note: scrollbar-color was initially two separate properties. It has since be 
> merged into a single property because the two colors are serving a single use 
> case, and it doesn't make much sense to use them separately. This change also 
> resolves the concern over what should happen when one color property is 
> specified while the other is not, which was raised in the "intent to 
> implement" thread.

The features have definitely benefited from public iteration.

Thanks again,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

[Tantek Çelik]

LGTM. Thanks David. -t

On Fri, Jul 27, 2018 at 12:26 PM, L. David Baron  wrote:
> I submitted comments on both charters:
>
> https://lists.w3.org/Archives/Public/public-new-work/2018Jul/0016.html
> https://lists.w3.org/Archives/Public/public-new-work/2018Jul/0015.html
>
> (I'm still able to revise them in the next 8 hours if there's
> something that needs to be modified.)
>
> -David
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

[Tantek Çelik]

On Thu, Jul 26, 2018 at 10:48 PM, James Teh  wrote:
> TL;DR: Thanks for the further explanation/clarification. I (reluctantly)
> agree that these concerns make sense and have nothing else to add as far as
> the response goes.

Thanks Jamie.  I very much appreciate your thoroughness. The
additional details you provided below can help us with our charter
response.


> On Fri, Jul 27, 2018 at 2:33 PM, Tantek Çelik 
> wrote:
>>
>> > The only thing worth
>> > noting is that while you say there's no need to delay for years, that
>> > may
>> > well be what ends up happening, and Mozilla will essentially be
>> > "blocking
>> > progress" on this front.
>>
>> If there were only two browser vendors (including Mozilla) then yes
>> your statement would be correct.
>>
>> However, we have (at least) four major browser vendors, and thus it is
>> incorrect to assert that Mozilla alone could be "blocking progress"
>> when any 2 of the other 3 browser vendors could implement something
>> and have it exit CR.
>
> That's fair. I suppose there's some (now irrelevant) historical context
> here: it used to be that Mozilla championed this stuff and drove others to
> push accessibility forward. At present, that is not the case, and I'm
> concerned it'll now be very hard to make much progress in accessibility.
> Still, while that's kind of sad, I take your point that this is irrelevant
> to the requirements of the charter.

Got it. Even if we (Mozilla) are delayed with implementation, we can
still champion this stuff. We can still nominate someone to
participate in the WG with subject matter expertise to help guide what
we think will be more implementable features.


>> > We want "limited resources" to drive better
>> > standards, yet with our resources in accessibility as limited as they
>> > are at
>> > this point, it's entirely likely we won't get around to implementing new
>> > ARIA stuff for years.
>>
>> That may well be. If that is your assessment, we should add that to
>> our Charter response and be quite upfront that we are unlikely to
>> implement new ARIA stuff for (a few?) years, and perhaps ask
>> (non-F.O.) for the WG to be postponed accordingly.
>
> Honestly, there is a lot of uncertainty at this point; I certainly couldn't
> give any "formal" statement concerning what we might or might not implement.
> FWIW, I believe Mozilla *should* implement this stuff, but that all depends
> on me convincing leadership that we should provide more resources for
> accessibility. :) Again, irrelevant to our charter response.

Perhaps we can write a comment in support of developing new ARIA
features, but admit we cannot commit to helping implement or even
prototype them to prove their viability and efficacy.


>> In addition per your note about "still haven't implemented parts of
>> ARIA 1.1, let alone ARIA 1.2.", if you know of any features in those
>> specs which *no browser implements* we should call those out, and ask
>> that the Charter explicitly dictate dropping them in the next version
>> of ARIA for failure to get uptake.
>
> I'd say there's at least one implementation (probably two) of most ARIA 1.1
> stuff. I'm not sure about ARIA 1.2; I haven't even had a chance to look at
> it yet.

We could request a deliverable requirement of 100% testing and interop
(2+ implementations) of ARIA 1.2 features for the next version of
ARIA.

dbaron, is this thread sufficient to write-up a response? Our response
is due tomorrow (Friday 7/27) right?

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

[Tantek Çelik]

On Thu, Jul 26, 2018 at 8:57 PM, James Teh  wrote:
> That all seems reasonable from a process perspective. The only thing worth
> noting is that while you say there's no need to delay for years, that may
> well be what ends up happening, and Mozilla will essentially be "blocking
> progress" on this front.

If there were only two browser vendors (including Mozilla) then yes
your statement would be correct.

However, we have (at least) four major browser vendors, and thus it is
incorrect to assert that Mozilla alone could be "blocking progress"
when any 2 of the other 3 browser vendors could implement something
and have it exit CR.


> We want "limited resources" to drive better
> standards, yet with our resources in accessibility as limited as they are at
> this point, it's entirely likely we won't get around to implementing new
> ARIA stuff for years.

That may well be. If that is your assessment, we should add that to
our Charter response and be quite upfront that we are unlikely to
implement new ARIA stuff for (a few?) years, and perhaps ask
(non-F.O.) for the WG to be postponed accordingly.

In addition per your note about "still haven't implemented parts of
ARIA 1.1, let alone ARIA 1.2.", if you know of any features in those
specs which *no browser implements* we should call those out, and ask
that the Charter explicitly dictate dropping them in the next version
of ARIA for failure to get uptake.


> At that point, we have a conflict: we have Mozilla
> objecting to the minimum implementation exception, while at the same time
> not resourcing accessibility sufficiently to make any reasonable progress at
> all. I'm not sure we can have it "both ways".

This is absolutely not in conflict, because as noted, 2 of the other 3
browser vendors can make progress independent of Mozilla.

What we are saying is we are against any accessibility features being
"standardized" for which their interoperable implementability is
unproven (by anyone, not just by us).

It is much worse to have something out there claiming to be a standard
(a W3C Recommendation), when either no one is supporting it (hence
fiction), or there is only one implementation (not a standard, because
there is no interop).

Tantek


> On Fri, Jul 27, 2018 at 11:27 AM, Tantek Çelik 
> wrote:
>>
>> On Thu, Jul 26, 2018 at 6:04 PM, James Teh  wrote:
>> > On Fri, Jul 27, 2018 at 2:09 AM, L. David Baron 
>> > wrote:
>> >
>> >> So some comments on the ARIA charter at
>> >> https://www.w3.org/2018/03/draft-aria-charter :
>> >> ...
>> >> I guess it seems OK to have only one implementation
>> >> if there's really only going to be one implementation on that
>> >> platform... but allowing it in general (i.e.,  seems less than ideal,
>> >
>> > It is. However, the problem is that accessibility in general is severely
>> > lacking in resources across browser vendors (especially Mozilla!; we're
>> > currently working with just 2 engineers). Even where browser vendors
>> > agree
>> > on how something *should* be done, it often takes months or years before
>> > it
>> > gets implemented, primarily due to the aforementioned resource shortage.
>> > We
>> > (Mozilla) still haven't implemented parts of ARIA 1.1, let alone ARIA
>> > 1.2.
>> > The reality is that if multiple implementations were required for
>> > sign-off,
>> > it'd probably delay the process for years.
>>
>> Respectfully, I disagree with that use of process, and those
>> unimplemented parts of ARIA 1.1, let alone ARIA 1.2 should probably
>> have been dropped and/or postponed to future versions.
>>
>> The reality is that if a standard does not reflect what is
>> implemented/implementable (and yes, economic constraints / costs,
>> resource are a legitimate reason to criticize something as not being
>> implementable), then it should not be in the standard.
>>
>> A better answer when something lacks multiple implementations is:
>> 1. if there is only one implementation, move it to an informative
>> (non-normative) appendix
>> 2. if there are zero implementations, cut it and postpone it to the
>> next +0.1 version
>>
>> By following such a methodology, there is no need to delay "for
>> years". You ship the spec (go to PR) with what happens to be supported
>> as of that point in time, then work on the next +0.1 version to ship
>> the next year and repeat, hopefully increasing the number of features
>> that are interoperable implemented.
>>
>> > and
>> >> allowing only 75% of mappings to be implemented to count as

Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

[Tantek Çelik]

On Thu, Jul 26, 2018 at 6:04 PM, James Teh  wrote:
> On Fri, Jul 27, 2018 at 2:09 AM, L. David Baron  wrote:
>
>> So some comments on the ARIA charter at
>> https://www.w3.org/2018/03/draft-aria-charter :
>> ...
>> I guess it seems OK to have only one implementation
>> if there's really only going to be one implementation on that
>> platform... but allowing it in general (i.e.,  seems less than ideal,
>
> It is. However, the problem is that accessibility in general is severely
> lacking in resources across browser vendors (especially Mozilla!; we're
> currently working with just 2 engineers). Even where browser vendors agree
> on how something *should* be done, it often takes months or years before it
> gets implemented, primarily due to the aforementioned resource shortage. We
> (Mozilla) still haven't implemented parts of ARIA 1.1, let alone ARIA 1.2.
> The reality is that if multiple implementations were required for sign-off,
> it'd probably delay the process for years.

Respectfully, I disagree with that use of process, and those
unimplemented parts of ARIA 1.1, let alone ARIA 1.2 should probably
have been dropped and/or postponed to future versions.

The reality is that if a standard does not reflect what is
implemented/implementable (and yes, economic constraints / costs,
resource are a legitimate reason to criticize something as not being
implementable), then it should not be in the standard.

A better answer when something lacks multiple implementations is:
1. if there is only one implementation, move it to an informative
(non-normative) appendix
2. if there are zero implementations, cut it and postpone it to the
next +0.1 version

By following such a methodology, there is no need to delay "for
years". You ship the spec (go to PR) with what happens to be supported
as of that point in time, then work on the next +0.1 version to ship
the next year and repeat, hopefully increasing the number of features
that are interoperable implemented.

> and
>> allowing only 75% of mappings to be implemented to count as
>> success seems pretty bad.
>>
> Same issue as above regarding limited resources.  Still, this one is a
> little more concerning because it raises questions about whether the
> remaining 25% will *ever* be implementable.

Right, same issue with implementability, and same answer (1, 2 above).

We (especially Mozilla) want "limited resources" to be a forcing
function to drive better standards, simpler to implement, test, debug,
secure, etc.

No user benefits from unimplemented standards.

If anything, such "specifiction" causes harm in that it can cause
false expectations of what "works", wasting web developer time and
resources.

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

[Tantek Çelik]

On Thu, Jul 26, 2018 at 9:09 AM, L. David Baron  wrote:
> So some comments on the ARIA charter at
> https://www.w3.org/2018/03/draft-aria-charter :

tl;dr: We should show general support for work happening in this area
(per Jamie's email), however we should point out critical flaws in the
charter ("75%" etc.), formally object unless they are fixed, and add
explicit support/agreement with any other parties similarly formally
objecting.

Details inline:

> So one concern I've heard about these charters and that I probably
> share is that the ARIA charter says:
>
>   For every platform with mappings in an Accessibility API Mapping
>   specification, at least one implementation of 75% of the mappings
>   being tested on that platform will demonstrate implementability on
>   that platform. Multiple implementations of each platform are not
>   required because some platforms have only one implementation. For
>   features that are not platform-specific, passing test results in
>   at least two different implementations will be documented to
>   demonstrate implementability.
>
> This is a substantial weakening of the W3C's usual rules for
> demonstrating interoperability, and seems likely to be a bad
> precedent.

Yes and yes.

IIRC we had similar concerns about a previous Proposed Recommendation,
regarding the "at least one implementation ... on that platform", that
was accessibility related, and exiting CR without a confirmed (via
test suite) implementation for every feature. I can't seem to find it
in dev-platform however.

>  I guess it seems OK to have only one implementation
> if there's really only going to be one implementation on that
> platform...
> but allowing it in general (i.e.,  seems less than ideal, and

Is there some way we can ask to make this tighter (less loose)?

E.g. on platforms which only one existing implementation of previous
related spec(s)?

Like if a platform has multiple implementations already, then it is
reasonable to require 2+ implementations passing tests.

> allowing only 75% of mappings to be implemented to count as
> success seems pretty bad.

I read that as only 75% as being implementable, and 25% being
aspirational, which is not a good way to do standards, for anyone.  We
don't want specs with 25% specifiction.

We should insist that all features (including all mappings) be:
1. demonstrated to be implementable
2. pass the tests for them

If a feature is not implemented, or if it lacks tests, it should not
be able to exit CR.

We should formally object on this "75%" point.

> Also, the two references to a deliverable of the SVG working group
> when the SVG working group isn't currently chartered seems
> problematic.

Agreed, we should insist (FO) that be fixed (removed?).

> I think otherwise this seems fine.

Those were the big problems I found as well.

We should see if anyone else has filed similar criticisms and
explicitly state agreement with any that seem to agree in spirit with
the problems we see.

> On Thursday 2018-07-12 16:06 +1000, James Teh wrote:
>> I (and others in the accessibility team) think we should support these
>> charters. The ARIA working group is especially important in the future
>> evolution of web accessibility. I have some potential concerns/questions
>> regarding the personalisation semantics specifications from APA, but
>> they're more spec questions at this point and I don't think they need to be
>> raised with respect to charter. Certainly, cognitive disabilities is an
>> area that definitely needs a great deal more attention on the web, and the
>> APA are seeking to do that.
>>
>> Thanks.
>>
>> Jamie
>>
>> On Wed, Jul 11, 2018 at 3:57 PM, L. David Baron  wrote:
>>
>> > The W3C is proposing revised charters for:
>> >
>> >   Accessible Platform Architectures (APA) Working Group
>> >   https://www.w3.org/2018/03/draft-apa-charter
>> >
>> >   Accessible Rich Internet Applications (ARIA) Working Group
>> >   https://www.w3.org/2018/03/draft-aria-charter
>> >
>> >   https://lists.w3.org/Archives/Public/public-new-work/2018Jun/0003.html
>> >
>> > Mozilla has the opportunity to send comments or objections through
>> > Friday, July 27.
>> >
>> > The changes relative to the previous charters are:
>> > https://services.w3.org/htmldiff?doc1=https%3A%2F%
>> > 2Fwww.w3.org%2F2015%2F10%2Fapa-charter=https%3A%
>> > 2F%2Fwww.w3.org%2F2018%2F03%2Fdraft-apa-charter
>> > https://services.w3.org/htmldiff?doc1=https%3A%2F%
>> > 2Fwww.w3.org%2F2015%2F10%2Faria-charter=https%3A%
>> > 2F%2Fwww.w3.org%2F2018%2F03%2Fdraft-aria-charter
>> >
>> > Please reply to this thread if you think there's something we should
>> > say as part of this charter review, or if you think we should
>> > support or oppose it.
>> >
>> > -David

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Scrollbar color properties

[Tantek Çelik]

On Mon, Jul 9, 2018 at 1:57 PM, Mike Taylor  wrote:
> Hi Xidorn,
>
>> On Jul 8, 2018, at 8:24 PM, Xidorn Quan  wrote:
>> Hopefully with these properties (and one another controlling scrollbar width 
>> or style to fulfill thin scrollbar usecases), WebKit and Blink would be able 
>> to unship their current pseudo-elements, so that we wouldn't need to 
>> implement them to get web compatible.

Thanks Xidorn!


> I’m skeptical about this approach, given that it requires existing and legacy 
> sites to update their code. But I would be happy to be wrong. ^__^

MS Edge disagrees as they have been able to *drop* their legacy
proprietary -ms- prefixed properties for scrollbar coloring (which was
often provided as a back-up in ::-webkit- scrollbar code samples) with
very little impact on apparent bugs / compat from their perspective.

We confirmed this last week at the CSSWG meeting with MS Edge PMs.
Waiting on the official f2f minutes for a citation.


> To date the compat issues we care about (because they break layouts) are 
> about assigning a specific width, or hiding the track entirely (via 
> ::-webkit-scrollbar).

Agree with the use-cases "specific width, or hiding the track
entirely" and the new (not yet implemented) scrollbar-width property
addresses those.

https://drafts.csswg.org/css-scrollbars-1/#scrollbar-width

Also we are getting strong informal signals (reconfirmed as of last
week) that there is high desirability to DROP the mess of
::-webkit-scrollbar-* from existing implementations. This is a when
not if, and is largely waiting on sufficient proof of concept that CSS
Scrollbars solves enough use-cases to get at least some sites to
switch or provide both, which likely depends on us shipping the new
standard properties.

Past evidence (which shows how this has changed to be even more
negative on webkit-scrollbars over the past year) until we get last
week's minutes:

https://lists.w3.org/Archives/Public/www-style/2017May/0010.html
"smfr: It was a mistake to leak to web. We don't really like that
people can style scrollbars. We won't enhance and prefer to deprecate
it."

https://lists.w3.org/Archives/Public/www-style/2017Dec/0040.html
"TabAtkins: We would like to drop as much of our weird -webkit- stuff
as possible."
...
"smfr: We're interested only in very limited customization of
scrollbars. Would like to get rid of -webkit- scrollbar pseudo stuff.
smfr: we're only interested in coloring, and hiding scrollbars."

Not quite an official intent to deprecate / unship, but clearly that's
the direction things are headed.


>> Platform coverage: Desktop
>
> Why not on mobile?

Requires platform specific code that just hasn't been written (yet)
for mobile platforms.

Do you think this feature requires Desktop+Mobile parity/equivalency
before we ship on Desktop?

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: JSON-LD Working Group

[Tantek Çelik]

This looks good and clearly covers all the concerns we discussed. Thanks
for writing this up.

If possible let’s make our answers public on this so we may more easily
cite them in other discussions. This isn’t the last we’ve seen of the quiet
attempts to JSON-LDify the web platform.

-Tantek

On Sun, Apr 29, 2018 at 09:35 L. David Baron  wrote:

> OK, here's a draft of an explicit abtension that I can submit later
> today.  Does this seem reasonable?
>
>
> One concern that we've had over the past few years about JSON-LD
> is that some people have been advocating that formats adopt
> JSON-LD semantics, but at the same time allow processing as
> regular JSON, as a way to make the adoption of JSON-LD
> lighter-weight for producers and consumers who (like us) don't
> want to have to implement full JSON-LD semantics.  This yields a
> format with two classes of processors that will produce different
> results on many inputs, which is bad for interoperability.  And
> full JSON-LD implementation is often more complexity than needed
> for both producers and consumers of content.  We don't want
> people who produce Web sites or maintain Web browsers to have to
> deal with this complexity.  For more details on this issue, see
> https://hsivonen.fi/no-json-ns/ .
>
> This leads us to be concerned about the Coordination section in
> the charter, which suggests that some W3C Groups that we are
> involved in or may end up implementing the work of (Web of
> Things, Publishing) will use JSON-LD.  We would prefer that the
> work of these groups not use JSON-LD for the reasons described
> above, but this charter seems to imply that they will.
>
> While in general we support doing maintenance (and thus aren't
> objecting), we're also concerned that the charter is quite
> open-ended about what new features will be included (e.g.,
> referring to "requests for new features" and "take into account
> new features and desired simplifications that have become
> apparent since its publication").  As the guidance in
> https://www.w3.org/Guide/standards-track/ suggests, new features
> should be limited to those already incubated in the CG.  (If we
> were planning to implement, we might be objecting on these
> grounds.)
>
>
> -David
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: JSON-LD Working Group

[Tantek Çelik]

On Fri, Apr 27, 2018 at 2:09 PM, Adam Roach  wrote:
> On 4/27/18 2:02 PM, L. David Baron wrote:
>>
>> On Friday 2018-04-27 10:07 +0300, Henri Sivonen wrote:
>>>
>>> For this reason, I think we should resist introducing dependencies on
>>> JSON-LD in formats and APIs that are relevant to the Web Platform.

Agreed with Henri summary criticism and have been warning as much (re:
introducing dependencies on JSON-LD) for a few years.

The specific concern to call out in the charter is only implied by the
Coordination section:

https://www.w3.org/2018/03/jsonld-wg-charter.html#w3c-coordination

In particular we could state some concern about these which will
likely impact our (Mozilla) products:

"* Web of Things Working Group"
  (though I am unsure if "that ship has sailed" or not - that is, I
have not dug deep enough to determine if WoT work is actively
dependent on JSON-LD, heading that way, or not at all yet)

"
* Publishing Working Group
  The Publishing Working Group is considering using JSON-LD as a
serialization format for various types of metadata for Web
Publications, as well as a serialization format for the Web
Publication Manifest.
"

Nevermind a separate Web Publication Manifest from Web App Manifest
(which itself is an issue, cc Marcos), it is likely that Firefox will
end up having to support whatever Web Publication format(s) come out
of W3C, thus we should be actively advocating for something that does
not need JSON-LD.


>>> I
>>> think it follows that we should not support this charter. I expect
>>> this charter to pass in any case, so I'm not sure us saying something
>>> changes anything,

At a minimum we should explicitly Abstain in our review, with comments.

The other  reasonable option is a non-formal objection.


>>> but it might still be worth a try to register
>>> displeasure about the prospect of JSON-LD coming into contact with
>>> stuff that Web engines or people who make Web apps or sites need to
>>> deal with

Yes we should register our displeasure, and it is not just a
"prospect", there are (problem) examples already, most notably due to
Google Search side latest syntax du jour for serp rich snippets being
JSON-LD data islands in HTML.

The stats for JSON-LD adoption are essentially all publishing,
primarily for Google Search's opaque consumption.
* SEO types putting JSON-LD into HTML documents, with no way to verify
any actual processing impact / results (validators exist to check
syntax, but not show impact on actual results to users).

Aside: Google Search has cycled through recommending Google Base,
GData XML, microformats, RDFa, microdata, JSON-LD all in the past,
without technical reasons or evidence and yet still supports most of
what they supported in the past:
https://aaronparecki.com/2016/12/17/8/owning-my-reviews#historical-recommendations

There is no actual "need" for JSON-LD in practice for the
Google/Search SEO "use-case".



>>> and to register displeasure with designing formats whose
>>> full processing model differs from how the format is evangelized to
>>> developers (previously: serving XHTML as text/html while pretending to
>>> get benefits of the XML processing model that way).

This is a very good way of communicating the problem.

The dual message of:
* You can treat it just as a subset of JSON
* If you want extra features if you have to parse it as JSON-LD
Has had problems with such extra features in practice, especially in
any ecosystem attempting to evolve extensions (supposedly one benefit
of JSON-LD) across implementations, with forward/backward
compatibility etc. (Do you update the @context file in-place or use a
new @context? When do you update? What about implementations that
include @context information "at compile time" Etc.)


>> Yeah, I'm not quite sure how to register such displeasure.  In
>> particular, I think it's probably poor form to object to maintenance
>> work on a base specification, even if we're opposed to that
>> specification's use elsewhere.  At least, assuming we don't want to
>> make the argument that the energy being spent on that maintenance
>> shouldn't be.

On the flip side, from what I've seen, non-trivial maintenance and
extensibility issues have been found with JSON-LD due to
implementation feedback and iteration. In as much as there's a group
of folks willing to do this maintenance, it seems prudent to let them
do so, presuming the cost to W3C staff is minimal (I saw 0.1 but am
not sure if I believe that).


>> I'm inclined to leave this one alone, unless somebody else comes up
>> with a better position we could take.

I think we should register an explicit Abstain, and state our concerns
that Henri summarized, our "displeasure about the prospect of JSON-LD
coming into contact with stuff that Web engines or people who make Web
apps or sites need to deal with", and make that public.

Things we could object to:

* Seemingly open ended "new features" as referred to in the charter.

The charter refers to 

Re: Intent to ship: Allow the overflow shorthand to accept two values.

[Tantek Çelik]

Great to see this moving forward. Thanks Emilio!  -Tantek

On Wed, Apr 11, 2018 at 12:42 AM, Emilio Cobos Álvarez  wrote:
> Hi,
>
> In bug 1453148 I'm planning to implement the CSSWG resolution at:
>
>   https://github.com/w3c/csswg-drafts/issues/2484
>
> It's a very uncontroversial change that doesn't change backwards compat,
> and makes the shorthand more consistent. But it was probably worth an
> intent.
>
> WPT tests are being added as part of that bug. Let me know if there's
> any concern with proceeding here, thanks!
>
>  -- Emilio
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendation: CSS Color Module Level 3

[Tantek Çelik]

On Thu, Mar 15, 2018 at 11:02 AM, L. David Baron  wrote:
> A W3C Proposed Recommendation is available for the membership of W3C
> (including Mozilla) to vote on, before it proceeds to the final
> stage of being a W3C Recomendation:
>
>   CSS Color Module Level 3
>   https://www.w3.org/TR/css-color-3/
>   Deadline for responses: April 12, 2018
>
> This is a minor revision of a previous recommendation; the changes
> are listed at
> https://www.w3.org/TR/2018/PR-css-color-3-20180315/#changes-since-REC
>

FYI, dbaron and I are both editors of this spec.

> I intend to vote in favor, but if anybody disagrees with that or
> thinks we should make certain comments, please reply to this thread.
> (I plan to comment that it would be good for the boilerplate to link
> to the Editor's Draft.)

Agreed, not sure how we missed that.  Filed and feel free to
reference: https://github.com/w3c/csswg-drafts/issues/2445

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: ::-moz-math-anonymous.

[Tantek Çelik]

SGTM. I did not find any references on MDN, so nothing to update there AFAIK.

However with a broader web search I found https://gist.github.com/yields/6648240

Is ::-moz-math-anonymous special? (last of its kind?) Or would the
same reasoning apply to removing access to ::-moz-math-stretchy or any
of the others in that list? Or is that just an out-of-date list that
we can ignore?

Thanks,

Tantek

P.S. I also found moz-math-anonymous on
http://mdn.beonex.com/en/CSS_Reference/Mozilla_Extensions.html#Pseudo-elements_and_pseudo-classes
but that seems to just be an out-of-date copy of
https://developer.mozilla.org/en-US/docs/Web/CSS/Mozilla_Extensions#Pseudo-elements_and_pseudo-classes
which already removed the -moz-math- pseudos.


On Wed, Feb 21, 2018 at 4:30 AM, Emilio Cobos Álvarez  wrote:
> Hi,
>
> In bug 1439837 I intend to remove access to the ::-moz-math-anonymous
> pseudo-element.
>
> This is a Gecko-only pseudo-element that is there since the initial Gecko
> export, and is only used to get a style inheriting from another one for some
> MathML characters, so it has no good reason to be exposed to the web at all.
>
> I'm not aware of anything or anyone using it apart from us.
>
>  -- Emilio
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Payments Working Group

[Tantek Çelik]

On Fri, Feb 2, 2018 at 11:40 AM, Peter Saint-Andre  wrote:
> On 2/2/18 11:57 AM, Anne van Kesteren wrote:
>> On Fri, Feb 2, 2018 at 7:49 PM, Peter Saint-Andre  
>> wrote:
>>> What you have seems fine (modulo s/Web Auth/Web Authentcation/). The
>>> first comment is just housekeeping, whereas the second comment is
>>> substantive and concerning. Phrasing it as a formal objection might
>>> result in greater attention to the seemingly significant overlap. I'd be
>>> curious what other folks here think (Marcos, Tantek, Anne, etc.).
>>
>> I'd lean towards objecting as otherwise you might get a group of
>> people with lots of different objectives and nobody really getting
>> what they want.
>
> That's where we're heading at the moment.

Given that "Payments" has some history with that in the early days
(different groups trying to pull things in different directions), I
think that's a real threat that needs addressing up front.


>> (Both 1.2 and 1.3 are pretty concerning, and 1.2
>> sounds like the thing that made the Web Crypto effort somewhat
>> dysfunctional.)
>
> Agreed.

Also agreed (that we should make this an FO right?).

Thanks for your analysis on this Peter. That's exactly the kind of
precise feedback we need to give to help present a good case for an
objection (and the changes to address it).

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: overscroll-behavior

[Tantek Çelik]

SGTM.

As there's soon going to be two shipping implementations, it's long
past time to move the overscroll-behavior spec from WICG to CSSWG.
Related issue if anyone is interested in tracking this:
https://github.com/w3c/csswg-drafts/issues/2179

Thanks,

Tantek


On Mon, Jan 8, 2018 at 12:57 PM, Botond Ballo  wrote:
> I would like to ship support for the 'overscroll-behavior' CSS
> property (formerly called 'scroll-boundary-behavior') in Firefox 59.
>
> Preference behind which the feature was developed:
>   layout.css.overscroll-behavior.enabled
>
> "Intent to implement" thread:
>   https://www.mail-archive.com/dev-platform@lists.mozilla.org/msg23947.html
>
> Tracking bug for shipping:
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1428879
>
> Draft spec:
>   https://wicg.github.io/overscroll-behavior/
>
>   There have not been any significant changes to the spec since
>   the "Intent to implement" email, except for the change of name
>   from 'scroll-boundary-behavior' to 'overscroll-behavior'.
>
> Support by other browser engines:
>   Blink: Shipping in Chrome 63 [1]
>   Edge: Public support [2]
>   WebKit: No public signals
>
> Testing:
>   The feature has a manual web-platform-test [3].
>   The Chromium folks are working on upstreaming
>   an automated web-platform-test [4].
>
> Example:
>
>   #chatbox {
> /* Excess scrolling on the chatbox will not be handed off
> to its parent scrollable .*/
> overscroll-behavior: contain;
>   }
>
>   See [5] for more examples.
>
> Cheers,
> Botond
>
> [1] https://www.chromestatus.com/features/5734614437986304
> [2] 
> https://discourse.wicg.io/t/generic-scroll-chaining-prevention-mechanism-or-expand-standardize-ms-scroll-chaining/1811/5?u=majidvp
> [3] 
> https://searchfox.org/mozilla-central/rev/cf149b7b63ff97023e28723167725e38cf5df757/testing/web-platform/tests/css/cssom-view/overscrollBehavior-manual.html
> [4] https://bugs.chromium.org/p/chromium/issues/detail?id=762054
> [5] https://wicg.github.io/overscroll-behavior/#motivating-examples
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendation: WOFF 2.0

[Tantek Çelik]

Just to add a pair of unfamiliar eyes to this review, the
implementation report and test results look quite good: [1]
https://www.w3.org/Fonts/WG/WOFF2/Implementation.html

Only nit:

* The decoder test results show a single test "validation-off-012"
with no passing implementation: [2]
https://www.w3.org/Fonts/WG/WOFF2/Decoder_results.html

Since the implementation report [1] does explicitly have an
explanation for the User Agent non passing tests "The remaining
nonpassing tests are believed to be fixed by ...", I think it is
reasonable to request that the implementation report also explain
"validation-off-012" appears to have no passing implementation (is it
an optional feature? waiting for libraries to be updated? etc.)


I suggest we vote FOR Recommendation, with only a request to add an
explanation to the implementation report as to why
"validation-off-012" is non-passing.


For us:
* Kevin or Jonthan, do you know when we will (or if we've already)
incorporate(d)  "this change to the Google WOFF2 library"
(https://github.com/google/woff2/commit/e6579e6b128b4178f319d3a41acf0553a47a037f)
as called out in the implementation report [1], and can subsequently
provide updated test results?

Thanks,

Tantek

On Thu, Jan 11, 2018 at 12:29 PM, Kevin Brosnan  wrote:
> Yes we are an implementer. WOFF 2.0 was enabled in Firefox 39,
> released 2015-06-30.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1084026 and
> https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face#Browser_compatibility
>
> Kevin Brosnan
>
> On Thu, Jan 11, 2018 at 10:40 AM, L. David Baron  wrote:
>> A W3C Proposed Recommendation is available for the membership of
>> W3C (including Mozilla) to vote on, before it proceeds to the final
>> stage of being a W3C Recomendation:
>>
>>   WOFF (Web Open Font Format) File Format 2.0
>>   https://www.w3.org/TR/WOFF2/
>>   https://w3c.github.io/woff/woff2/
>>   Deadline for responses: Sunday, February 11, 2018
>>
>> If there are comments you think Mozilla should send as part of the
>> review, please say so in this thread.  Ideally, such comments should
>> link to github issues filed against the specification.  (I'd note,
>> however, that there have been previous opportunities to make
>> comments, so it's somewhat bad form to bring up fundamental issues
>> for the first time at this stage.)
>>
>> Given that this is something that I believe we implement, we should
>> be voting on this, even if that vote is just to support without any
>> comments.  I suspect Jonathan Kew knows what the status of our
>> implementation is, and about whether we should be raising any
>> issues.
>>
>> -David
>>
>> --
>> 턞   L. David Baron http://dbaron.org/   턂
>> 턢   Mozilla  https://www.mozilla.org/   턂
>>  Before I built a wall I'd ask to know
>>  What I was walling in or walling out,
>>  And to whom I was like to give offense.
>>- Robert Frost, Mending Wall (1914)
>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[Tantek Çelik]

On Thu, Jan 11, 2018 at 11:43 AM, Daniel Veditz <dved...@mozilla.com> wrote:
> On Wed, Jan 10, 2018 at 5:35 PM, Tantek Çelik <tan...@cs.stanford.edu>
> wrote:
>>
>> Also good methodology worth repeating:
>>"thinking ... through all the way up to and including the user
>> experience, makes for a much more viable approach"
>
>
> Including, of course, "how will 4chan trolls abuse this?" and "how will
> ad-tech trackers abuse this?"

Why stop there?

What about "how will state-level-actors abuse this to mislead,
surveil, and censor users?"  (only 1/2 :)

While I agree with asking the sorts of questions you're asking, I
think such abuse-cases are a distinctly different class of design
problems/considerations than what I believe was a positive UX design
methodology that Anne expressed, of making sure users can actually
viably get done what they want to get done.

That being said, perhaps consider filing issues to add your questions
to the W3C Security & Privacy questionnaire, especially if you think
we should be asking them for every web standards spec/API/feature we
consider contributing to and /or implementing.

https://github.com/w3ctag/security-questionnaire

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[Tantek Çelik]

On Wed, Jan 10, 2018 at 2:19 AM, Anne van Kesteren  wrote:
> On Wed, Jan 10, 2018 at 2:06 AM, Fabrice Desre  wrote:
>> WebShare is more a trimmed down version of the WebActivities/WebIntents
>> apis. I think it's unfortunate that instead of fixing the issues with WA/WI
>> they went with a single purpose API - this doesn't scale at all with uses
>> case they don't think about and limits the innovation for content
>> publishers.
>
> It's a little off-topic, but the overall issue with both of those
> technologies was that the approach was too general. And such overly
> generic APIs do not translate to good UX. I think starting small and
> slowly expanding the types of things we want to make extensible, and
> thinking those through all the way up to and including the user
> experience, makes for a much more viable approach.

You're both right.

WA/WI were both way-over-architected*, however with WebShare, it's
overcorrecting the other direction, it's an API that may be too
limited, and in particular limited in such a way that unnecessarily
(and badly) biases large anti-privacy (among other ills) vertical
content silos.

While I generally agree with Anne's philosophy "starting small and
slowly expanding the types of things we want to make extensible", I
think the "which small" needs to be evaluated by a frank "Is this
actually *good* for the open web, neutral, or actively bad?"
(unfortunately the latter in this case).

Also good methodology worth repeating:
   "thinking ... through all the way up to and including the user
experience, makes for a much more viable approach"

Finally Anne is right about it being a little off-topic. This github
issue may be a better place for WebShare follow-ups (more specifics
there): https://github.com/mozilla/standards-positions/issues/27

Thanks,

Tantek

*https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[Tantek Çelik]

On Tue, Jan 9, 2018 at 8:51 AM, L. David Baron  wrote:
> On Wednesday 2018-01-03 15:15 +, Jonathan Kingston wrote:
>> I am suggesting the removal of navigator.registerContentHandler
>> 
>> API used to register a web page to handle content types.
>>
>> Firefox has an implementation that only can be used to allow a web page to
>> handle RSS feeds. We don't have telemetry on this feature however we do
>> know that registerProtocolHandler has around 0.2% usage and this feature is
>> implemented in multiple browsers and isn't specific to Firefox.
>>
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1398169
>>
>> There is a small risk of breakage that we could decide to delay and instead
>> implement telemetry. However if the site is feature testing rather than
>> user agent testing there shouldn't be an issue here. As this API throws
>> errors there is likelihood websites account for it throwing anyway. I would
>> prefer however to let the removal ride the trains due to it's low risk
>> before 61 so our ESR doesn't have it.
>>
>> Alternatively we could restrict this API to Secure Context only due to the
>> risk of passing web content to an insecure context. This would be aligned
>> with our overall plan regarding HTTP APIs.
>>
>> Removal of this feature requires the removal of some internal tests and to
>> stop ignoring a web platform test.
>>
>> The rationale:
>>
>> - This API had bugs filed on it's implementation
>> - Is only implemented by Firefox
>> - The API is now non standard
>> - No other browsers have intent to implement
>
> I'm a little hesitant here -- this is an important feature for
> allowing Web apps to fulfil the function that desktop apps do, and
> I'd rather push to see it expand.
>
> For example, if we added support for registering for text/calendar,
> then Google Calendar could choose to register for that, and thus
> become the handler for random ICS files that I'm served by sites
> that allow me to make appointments.

Agreed.

There has also been a bit of a resurgence in Web (feed) reader
development in the past two years (picked up since Google Reader
shutdown), many (most?) open source at that. E.g.

https://woodwind.xyz/

Additional examples here: https://indieweb.org/feed_reader

Were these readers to implement registerContentHandler to register for
the Atom & RSS content types, it would turn the zillions of little
orange [XML] links/buttons on websites into decentralized opt-in
"Follow" buttons for the web, without having to change existing
publishers.

However: I don't know if any of these new readers support
registerContentHandler today (or why they would not have already,
whether not knowing about it, or due to being Firefox only).

I am investigating into these readers and will follow-up.


> Right now desktop calendar apps have more power than web calendar
> apps do here, for no good reason, and it seems like we ought to be
> trying to change that.

Agreed, same with desktop addressbooks, text/directory, vCard,  web
based address books, etc.

The problems with registerContentHandler noted in this thread seem
fixable, especially we're the only remaining (live) implementation, so
not reason enough to deprecate / remove per se.

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Second Screen Working Group

[Tantek Çelik]

This is an improvement and I think has a better chance of effecting
change with the specific proposals.

We're still making this an FO right? (I think we should)

perhaps:

s/We would ask that:/We ask (formal objection) that:

Your "open to other paths" closing statement provides an out to
resolving the FO without necessarily doing everything we precisely
ask, which both helps the dialog, and allows us room to declare the FO
upfront.

Thanks,

Tantek

On Fri, Jan 5, 2018 at 12:58 PM, L. David Baron  wrote:
> So after a little off-list discussion with SC, I have a somewhat
> revised proposal for comments that perhaps proposes what might be a
> more acceptable remedy (although thanks to timezones I don't
> actually know what SC thinks of this proposal).
>
> -David
>
> =
>
> The current situation with the API developed by this Working Group
> is that it is a API for a web page to interact with a connection
> between the web browser and a separate screen that exists entirely
> in a closed ecosystem.  For example, a browser made by Google might
> connect to displays that support the proprietary Chromecast
> protocol, whereas one made by Apple might connect to displays that
> support the proprietary AirPlay protocol.
>
> We know that parts of an Open Screen Protocol are in an early stage
> of development at https://github.com/webscreens/openscreenprotocol
> (as linked from the charter), and the goal of this work is to
> improve on this situation.  We hope it will allow for interoperable
> discovery of, identification of, and communication with presentation
> displays.
>
> However, we're deeply concerned about chartering a second iteration
> of the work that continues building the Presentation API on top of a
> closed ecosystem, when the work to make the ecosystem more open
> appears to have a lower priority.  While we understand that the work
> on building an open ecosystem still requires incubation, we believe
> it should have the highest priority in this space.
>
> We would ask that:
>
>  * the charter be clearer that modifications to the current CR-level
>specs that are needed to achieve interoperability are expected
>(rather than saying "This Working Group does not anticipate
>further changes to this specification."),
>
>  * the charter be clearer that building an open system that allows
>multiple browsers to interact with multiple displays is a
>requirement for the specifications advancing to Proposed
>Recommendation and to Recommendation, and
>
>  * work on a second level of the presentation API remain in
>incubation (and not yet be added to this charter) until after the
>work to build an open protocol moves from incubation into
>standardization,
>
> although we are open to other paths toward fixing this situation.
>
>
> On Friday 2018-01-05 09:36 -0700, Peter Saint-Andre wrote:
>> Agreed. Thanks for the careful wording, David! (BTW s/apple/Apple/)
>>
>> On 1/5/18 9:08 AM, Eric Rescorla wrote:
>> > LGTM!
>> >
>> > On Thu, Jan 4, 2018 at 9:56 PM, L. David Baron  wrote:
>> > >
>> > > So I think Martin, Peter, and I share similar concerns here, and I'm
>> > > inclined to turn those concerns into an objection to this charter.
>> > >
>> > > So how does this sound for proposed comments on the charter
>> > > (submitted as a formal objection)?  Note that I've tried to turn the
>> > > comments into a specific suggestion for a remedy, but I'm far from
>> > > sure if that suggestion is the right one.
>> > >
>> > > I've avoided mentioning the comment about "further changes" in the
>> > > specs that the existing working group has in CR, to avoid
>> > > distracting from what I think is the main piece.  But let me know if
>> > > you see a good way to work it in.
>> > >
>> > > But I'd be particularly interested to hear if SC thinks this might
>> > > be harmful rather than helpful to the end goal for some reason, or
>> > > if he has other disagreements with this approach, or better
>> > > suggestions for what remedy we should suggest.
>> > >
>> > > -David
>> > >
>> > > =
>> > >
>> > > The current situation with the API developed by this Working Group
>> > > is that it is a API for a web page to interact with a connection
>> > > between the web browser and a separate screen that exists entirely
>> > > in a closed ecosystem.  For example, a browser made by Google might
>> > > connect to displays that support the proprietary Chromecast
>> > > protocol, whereas one made by apple might connect to displays that
>> > > support the proprietary AirPlay protocol.
>> > >
>> > > We know that parts of an Open Screen Protocol are in an early stage
>> > > of development at https://github.com/webscreens/openscreenprotocol
>> > > (as linked from the charter), and the goal of this work is to
>> > > improve on this situation.  We hope it will allow for interoperable
>> > > discovery of, identification of, and communication with presentation
>> > > displays.  

Re: Intent to ship: CSS Shapes Module Level 1 (partial)

[Tantek Çelik]

On Thu, Nov 30, 2017 at 2:15 AM, Ting-Yu Lin  wrote:
> Thank you for all the feedback. I feel the safest plan is to ship the entire
> module at once. It also saves some work to implement two preferences to
> exclude the shape-outside:  value which we don't render in the first
> stage.

Thanks for gathering all the feedback Ting-Yu. I agree with your
conclusion of shipping the entire module at once.


> I'm implementing "shape-outside: ", and will do "shape-margin" after
> that. My gut feeling is that the entire module can be completed before
> Firefox 60, which is a cycle late than the two-stages plan.

When you feel confident (perhaps beyond "gut feeling") that we can
land/ship the entire module in 60, could you send an updated Intent to
Ship for the entire module accordingly?

Thanks much!

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove Ambient Light and Proximity sensor APIs

[Tantek Çelik]

On Mon, Dec 18, 2017 at 5:52 AM, Gervase Markham  wrote:
> On 17/12/17 15:29, Jonathan Kingston wrote:
>> I am suggesting the removal of both Ambient Light and Proximity Sensor APIs
>> via a preference so we can ensure there is no adverse impact to the web
>> with a quick mitigation if needed.

I think this removal is prudent and timely. It is consistent with our
default principles on privacy etc. and good to do it quickly while we
think the potential impact is low at worst.


> Is it fair to say that after removal of the Proximity Sensor API, no
> e.g. WebRTC-based audio-calling webapp

Do you know of a specific (URL?) mobile-device-capable (which
device(s)?) WebRTC-based audio-calling webapp that works today? I
would be very interested in testing it out.


> will be able to blank the screen
> when the user holds the device to their ear?
>
> That seems sad.

It's likely worth capturing your use-case in the Sensors Use-cases doc:
* https://w3c.github.io/sensors/usecases

That specific use-case doesn't seem to be in there, so go ahead and
file it here and feel free to cc: @tantek
* https://github.com/w3c/sensors/issues

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendation: IndexedDB 2.0

[Tantek Çelik]

On Thu, Dec 14, 2017 at 11:11 AM, Bevis Tseng  wrote:
> On Thu, Dec 14, 2017 at 12:05 PM L. David Baron  wrote:
>
>>
>> Given that we implement the specification as described in:
>> https://hacks.mozilla.org/2016/10/whats-new-in-indexeddb-2-0/
>> and that Bevis (who implemented it) agrees, I intend to vote in
>> favor.
>>
> These are small improvement of existing IndexedDB APIs wanted by web
> developers and are shipped since FF51, so I agree to vote it as proposed
> recommendation.

Thanks Bevis, and agreed, we should vote to support this implementation.

I just have a few questions (maybe worth adding as comments). See below.


In diving into the implementation report:

https://wpt.fyi/IndexedDB

It looks like nearly everything has 2+ interop implementations.

There are about a dozen test rows that *only* pass in Chrome, which is
a bit concerning.

There is one test row that is red for all implementations, digging into it.

https://wpt.fyi/IndexedDB/idbobjectstore_createIndex15-autoincrement.htm

It looks like there are problems with "Auto-Increment Primary Key",
specifically:
* Chrome & Edge fail the test
* FF & Safari - we don't have results (not sure what just "ERROR" means)

So two things.

1. For us (Firefox platform) - do we have bugs filed for the tests we
are failing?

2. For the WG: Is there an explanation for why the spec exited CR with
~ a dozen tests (or test rows) only having a single passing
implementation (Chrome) ?


Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ARIA implementation plans (was Re: W3C Proposed Recommendations: WAI-ARIA and Core Accessibility API Mappings)

[Tantek Çelik]

Thanks David Bolter, this helps a lot.

On Thu, Nov 30, 2017 at 6:25 PM, David Bolter <dbol...@mozilla.com> wrote:
> Hi Tantek,
>
> I spun this off the rec proposals thread as per your suggestion.
>
> On Thu, Nov 30, 2017 at 8:58 PM, Tantek Çelik <tan...@cs.stanford.edu>
> wrote:
>>
>> On Thu, Nov 30, 2017 at 4:10 PM, L. David Baron <dba...@dbaron.org> wrote:
>>
>
> [snip]
>
>>
>> Two things:
>>
>> 1. Do we have an Intent to Implement / Ship for the full testable
>> feature set of these specifications? (I couldn't find any such
>> "Intent" "ARIA" emails in dev-platform, but I may have missed it).
>> If not, could the implementing team please send after-the-fact
>> either/both Intent to Implement / Intent to Ship emails for both specs
>> to dev-platform?
>
>
> This work is unscheduled and TBD but we will send an intent when ready. The
> accessibility team has been explicitly deprioritized working on new ARIA
> support until the Windows multiprocess accessibility support work is in good
> shape, our priority backlog is addressed, and priority front end work is
> done.

Makes sense.

> Nonetheless, Joanie (chair of W3C ARIA spec) has been implementing some ARIA
> recently in Firefox!

Great!

>> 2. Assuming we have such intent, do we have bugs filed in Bugzilla to
>> implement the remaining testable features of both specifications?  (to
>> get the following %s to 100)
>
>
> Not exhaustively no (for similar reasons)

Understandable.

Is https://bugzilla.mozilla.org/show_bug.cgi?id=343213 the metabug for
both specs (and more)?

It might be worth creating a couple of spec-specific meta bugs for
tracking each spec (since they have separate test suites /
implementation reports), and give us the opportunity to declare
victory for each incrementally, but I'll leave that up to your
discretion.


>> From Core Mappings report above:
>> Firefox on Linux using ATK: 79% of mappings successfully implemented
>> (188/237)
>> Firefox on macOS using AX API:: 41% of mappings successfully
>> implemented (84/205)
>> Firefox on Windows using MSAA + IAccessible2: 75% of mappings
>> successfully implemented (181/242)
>> (or do we have documented somewhere reasoning why we won't implement
>> to 100% - and if so, do we have problems with some of the features?)
>>
>> From WAI ARiA report above:
>> no % tallies provided, but lots of red and yellow squares in the FF**
>> columns here:
>> https://w3c.github.io/test-results/wai-aria/all.html
>>
>
> It will be really great to get to a place where turning these green gets
> back into our top priorities, unfortunately we're not there yet.

Got it - perhaps this could be a good goal description for the
appropriate meta bug.

>> Feel free to follow-up to this part (re: specs that we implement) with
>> a reply-with-subject-change to start a new thread as needed.
>>
>> Thanks,
>>
>> Tantek
>
>
> Thanks for your detailed attention here!

Absolutely, thanks for all your work on this David. Greatly appreciated.

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendations: WAI-ARIA and Core Accessibility API Mappings

[Tantek Çelik]

On Thu, Nov 30, 2017 at 4:10 PM, L. David Baron  wrote:
> Two W3C Proposed Recommendations are available for the membership of
> W3C (including Mozilla) to vote on, before it proceeds to the final
> stage of being a W3C Recomendation:
>
>   Core Accessibility API Mappings 1.1
>   https://www.w3.org/TR/core-aam-1.1/
>   https://w3c.github.io/aria/core-aam/core-aam.html

Quick review, seems good, and we implement a good chunk of it per the
implementation report.
* https://w3c.github.io/test-results/core-aam/

tl;dr: Support Recommendation with comment

Comment:

Per the implementation report, it's hard to tell if there is at least
one implementation of each mapping (on any platform). The highest %
reported is 97% of mappings on a platform:
"WebKitGTK on Linux using ATK - DEMONSTRATES IMPLEMENTABILITY
status: 97% of mappings successfully implemented (231/237)"

Does this mean 3% of the mappings are unimplemented anywhere? or are
those 6 mappings implemented on other platforms?

We request clarification in the implementation report as to whether
each mapping is implemented on at least one platform, and if not (if
there are mappings unimplemented anywhere, we would be concerned (not
FO), that there may be a few mappings being standardized that did exit
reasonable common W3C CR exit criteria expectations.


>   Accessible Rich Internet Applications (WAI-ARIA) 1.1
>   https://www.w3.org/TR/wai-aria-1.1/
>   https://rawgit.com/w3c/aria/master/aria/aria.html


Similarly quick review, seems good (aside from the RDF/OWL point
already made), and we implement a good chunk of it per the
implementation report.
* https://w3c.github.io/test-results/wai-aria/

tl;dr: Support Recommendation with comment

Comment:

(as dbaron noted)

> The one comment I'd be inclined to make (based on feedback in that
> email thread) is:
>
>   We're not entirely sure what to make of the RDF/OWL bits of this
>   specification, which seem to be non-normative but also part of a
>   plan for future extensibility.

There's a lot of RDFisms sprinkled throughout the spec, normative parts thereof.

It doesn't seem like the RDFisms are essential to implementation
(which is why I presume the RDF/OWL references are in the Informative
section at the end).

The only thing I would add to the comment would be a stronger note of
concern. Something like:

 We are concerned that the many inline references to RDF/OWL bits in
normative text imply (perhaps without intending to) a need to
implement RDF/OWL processing to implement the specification. Please
consider adding a note stating that RDF/OWL processing is not
essential to interoperably implementing the specification, we believe
such a note would help implementers of the specification.

[If there is such a note / disclaimer already, I missed it in my
review of the spec]


>   Deadline for responses: today (oops!)
>
> Normally I'd ask for comments, but there isn't really much time
> since this slipped through until I was sent email about it recently.
> But I could still incorporate feedback in the next few hours.

The above are the only time-sensitive feedback items.


> (These are specs that we implement.)

re: specs that we implement, for Firefox Platform Dev:

Two things:

1. Do we have an Intent to Implement / Ship for the full testable
feature set of these specifications? (I couldn't find any such
"Intent" "ARIA" emails in dev-platform, but I may have missed it).
If not, could the implementing team please send after-the-fact
either/both Intent to Implement / Intent to Ship emails for both specs
to dev-platform?

2. Assuming we have such intent, do we have bugs filed in Bugzilla to
implement the remaining testable features of both specifications?  (to
get the following %s to 100)

>From Core Mappings report above:
Firefox on Linux using ATK: 79% of mappings successfully implemented (188/237)
Firefox on macOS using AX API:: 41% of mappings successfully
implemented (84/205)
Firefox on Windows using MSAA + IAccessible2: 75% of mappings
successfully implemented (181/242)
(or do we have documented somewhere reasoning why we won't implement
to 100% - and if so, do we have problems with some of the features?)

>From WAI ARiA report above:
no % tallies provided, but lots of red and yellow squares in the FF**
columns here:
https://w3c.github.io/test-results/wai-aria/all.html

Feel free to follow-up to this part (re: specs that we implement) with
a reply-with-subject-change to start a new thread as needed.

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Commerce Interest Group

[Tantek Çelik]

On Mon, Aug 28, 2017 at 5:07 PM, L. David Baron <dba...@dbaron.org> wrote:
> On Thursday 2017-07-20 04:07 -0400, Marcos Caceres wrote:
>> On July 18, 2017 at 9:58:40 AM, Tantek Çelik (tan...@cs.stanford.edu) wrote:
>> > I'd like to hear feedback from Marcos (cc'd) on how/why this group
>> > will complement or help our work in the Web Payments WG (does not seem
>> > to be addressed by the proposed Commerce IG charter).
>>
>> I think it's great if that group goes off to collect use cases and
>> requirements - we have a good 2-5 year gap between seeing adoption of
>> just "basic-card" and possibly some custom payment solutions (via the
>> Payment Handler API). So, the IG can collect requirements and
>> eventually bring them back to the WG.
>>
>> It seems like an oversight that the charter doesn't say they would
>> collaborate with the Web Payment WG - as eventually, whatever they do
>> find, the WG will potentially standardize. We could simply point that
>> out (hi Ian!), but I honestly just think it was an oversight because
>> there is so much overlap with the folks from both groups.
>
> OK, it seems like this is something we should be supportive of, but
> with a few comments.  I read through the charter and it seems pretty
> reasonable to me (although broad, but broad seems OK for an IG).

Agreed.

> So I'm inclined to vote in support of the charter, with the
> following comments:
>
> =
> There should likely be a mention of some form of interaction with
> the Web Payments Working Group.
>
> Section 6 (Patent Disclosures) uses the old name of the IG rather
> than the new one.
> =

This looks good.

I would reword the second one as change rather than error, and perhaps
incorporate the change suggested by Ian Jacobs for the first. E.g.

=
There should likely be a mention of some form of interaction with the
Web Payments Working Group.  E.g. at least:
* Change "• Review work: Review of deliverables from other groups.”
to "• Review work: Review of deliverables from other
groups (including the Web Payments Working Group).”

Section 6 (Patent Disclosures) should be updated to use the new name
of the IG (proposed charter errantly uses the old name of the IG).

=


Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: WebVR Working Group

[Tantek Çelik]

Given that we have a day left to respond to this poll, we should begin
writing up at least a draft answer with known facts that we can
iterate on as we get more information.

Rough draft WebVR proposed charter response points for consideration:


1. Timing is good. We think WebVR is ready for a WG to formally standardize it.

[Our very action of shipping a WebVR feature publicly (without pref)
speaks louder than any words on any email lists (including this one)
and communicates that we think WebVR is ready for adoption on the open
web (if that were not true, we should not be shipping it publicly, but
my understanding is that that decision has been made.), and thus ready
for rapid standardization among implementers.]

2. WG charter details bad. We have strong concerns about the proposed
WG charter as written, including apparent disconnects with the CG, and
in particular failure to involve  implementers (e.g. browser vendors
and major hardware providers).

3. Conclusion: Formal objection. Charter bad, needs to be withdrawn,
be rewritten in an open dialog with the CG, such that there is at
least rough consensus with the CG on scope, chairs, and other details.


I believe these points reflect our actions and what Lars has communicated below:

On Thu, Aug 17, 2017 at 9:14 AM, Lars Bergstrom  wrote:
> I'll follow up more with the chairs of the community group (they just had a
> face to face earlier this week and I presume it came up). The last bit that
> I heard is consistent with what Dan mentioned -  the concern is not around
> standardization

Thanks for the clarification, thus point 1.

> but that neither the chairs nor the browser vendors nor the
> major hardware providers were consulted publicly in the creation of a
> proposal to transition to a working group:
> https://lists.w3.org/Archives/Public/public-webvr/2017Jul/0083.html

Thus point 2.

> Based on that thread, I'd expect the proposal to be withdrawn or - as Dan
> mentioned - things adjusted to involve the the current spec contributors.

Thus point 3 - we should openly advocate for the proposed charter to
be withdrawn and rewritten accordingly.


> I'll try to get on the phone with folks to find out more and get something
> to dbaron by tomorrow. I'm not familiar with the inner workings of the W3C,
> but I find it hard to imagine how things will go well with none of the
> current spec contributors involved.

Short answer: historically when W3C WGs move forward without strong
implementer participation, they have very low chances of success, high
chances of failure, and especially of damaging good will in relevant
communities. Your concerns are merited.

More information definitely appreciated to help iterate on our response.

Thanks Lars,

Tantek


> On Wed, Aug 16, 2017 at 10:46 PM, Eric Rescorla  wrote:
>
>>
>>
>> On Wed, Aug 16, 2017 at 5:18 PM, Daniel Veditz 
>> wrote:
>>
>>> On Wed, Aug 16, 2017 at 3:51 PM, L. David Baron 
>>> wrote:
>>>
>>> > I still think opposing this charter because the group should still
>>> > be in the incubation phase would be inconsistent with our shipping
>>> > and promotion of WebVR.
>>> >
>>>
>>> I agree that would be exceptionally odd and require a well reasoned
>>> argument about why formal standardization was inappropriate.
>>>
>>
>> This puzzles me as well. Lars, can you explain what the argument against
>> standardization of a shipping feature is?
>>
>> -Ekr
>>
>>
>>>
>>> I'm troubled that the members of the incubation group seem to feel that
>>> chairs are being imposed on them who have been less involved (or
>>> uninvolved?) with leading the feature to the point it's gotten so far. But
>>> I don't understand the politics of that or whether we could or should get
>>> involved on that point.
>>>
>>> -Dan Veditz
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Commerce Interest Group

[Tantek Çelik]

On Mon, Jul 17, 2017 at 4:11 PM, L. David Baron  wrote:
> The W3C is proposing a new charter for:
>
>   Web Commerce Interest Group
>   https://www.w3.org/2017/03/commerce-charter.html
>   https://lists.w3.org/Archives/Public/public-new-work/2017Jul/0008.html

Context: while technically with a new name "Commerce", this is the
replacement/follow-on for the existing Web Payments Interest Group
(Payments IG) which expires around the same time Commerce IG is to
start.

https://www.w3.org/2014/04/payments/webpayments_charter.html

The chairs are the same set of three people.

And while W3C's HTML diff tool has limitations, it does seem that most
of the charter is dramatically different:

http://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2014%2F04%2Fpayments%2Fwebpayments_charter.html=https%3A%2F%2Fwww.w3.org%2F2017%2F03%2Fcommerce-charter.html


> Mozilla has the opportunity to send support, comments, or objections
> through Monday, August 28.  If this is work that we want to see
> happen at W3C, we should explicitly support it; if there are things
> we think should be different about the charter, this is the time to
> say so.
>
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it.

One glaring difference is that the previous/current Payments IG has a
long "Dependencies and Liaisons" section, while the Commerce IG has
none (not even an explicit "liason" with the Web Payments Working
Group), that seems like an odd omission.


I'd like to hear feedback from Marcos (cc'd) on how/why this group
will complement or help our work in the Web Payments WG (does not seem
to be addressed by the proposed Commerce IG charter).


Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Charter Advance Notice: Web Platform (recharter) & Service Workers WGs

[Tantek Çelik]

On Wed, Jul 5, 2017 at 8:10 PM, L. David Baron  wrote:
> I've taken what you (Tantek) wrote and made minor changes to yield
> the following Formal Objection to the Web Platform WG charter.

This looks good, appreciate your edits.

> Note
> that I added DOM 4 to the list, although perhaps there was a reason
> you didn't include it?

Being in a rush to catch a flight and somehow forgot W3C is still
publishing DOM4. Good catch.

Also, let's make our response officially public (cc www-archive)
beyond unofficially here on dev-platform.

Thanks,

Tantek

>
> -David
>
>
> We request that the charter drop all REC track specifications that
> the WHATWG has demonstrated good maintenance of (as shown by active
> implementer participation and implementation, including by Mozilla
> in Firefox).
>
> We would optionally like to see W3C republish the current versions
> as a terminal NOTE, citing the WHATWG version as normative at the
> top of the NOTE in large text as we would for any other abandoned
> document for which better, more recent, or more accurate versions
> exist elsewhere.
>
> Particular specifications that we request WPWG drop from REC track
> deliverables:
>
>  * HTML5.2: at this point we are not aware of *any implementer*
>(people actually committing code to browsers) paying any
>practical (in that it affects code) attention to HTML5.2,
>especially to any differences between HTML5.2 and WHATWG HTML,
>despite having editors from Microsoft and Google. It is unlikely
>that there are any patent/IP benefits to pursuing HTML5.2
>(whose features are already covered by HTML5 REC) at W3C.
>
>  * microdata: as previously noted, WHATWG maintains microdata, and
>there is no need for any W3C time spent on this.
>
>  * DOM 4 / DOM 4.1: likewise, the WHATWG maintains the DOM
>specification, and there is no need for W3C to duplicate that
>work.
>
> Such duplication work by W3C WPWG is actively harmful in a number of
> ways.
>
> * It harms the relationship between W3C and WHATWG, both of which a
>   number of organizations including Mozilla actively participate in.
>
> * This active relationship harm provides unnecessary friction,
>   discourages collaboration, and demonstrates either
>   neglect or outright passive ill-will from one or more of
>   chair(s)/staff of Web Platform WG toward WHATWG, which is
>   unacceptable behavior (and counter to W3C PWE).
>
> * Press and developers are continuing to be misled by the illusion
>   that HTML5.2 is providing any kind of meaningful update to HTML,
>   when meaningful updates (i.e., things that are implemented or
>   fixed in browsers that web developers can then depend on) are only
>   based on WHATWG HTML at this point.
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Charter Advance Notice: Web Platform (recharter) & Service Workers WGs

[Tantek Çelik]

On Wed, Jul 5, 2017 at 11:02 AM, L. David Baron  wrote:
> On Friday 2017-05-12 15:58 -0700, L. David Baron wrote:
>> The W3C gave advance notice that 2 new charters are under
>> development:
>>
>>   https://lists.w3.org/Archives/Public/public-new-work/2017May/0006.html
>>   (which contains brief descriptions of what has changed)
>>
>>   Web Platform Working Group
>>   http://w3c.github.io/charter-html/webplat-wg.html
>>   https://github.com/w3c/charter-html/
>>
>>   Service Workers Working Group
>>   http://w3c.github.io/charter-drafts/sw-charter.html
>>   https://github.com/w3c/charter-drafts/
>>
>> Comments on these charters can be made in their respective github
>> repositories, or, if necessary, I can make comments that should be
>> made as statements "from Mozilla" on the Advisory Committee mailing
>> list.
>
> I realize I didn't repost when the official review started, but
> these charters are under a formal review whose deadline is today, as
> sent out in
> https://lists.w3.org/Archives/Public/public-new-work/2017Jun/0002.html
> https://lists.w3.org/Archives/Public/public-new-work/2017Jun/0003.html

>From everything I understand we're ok with the Service Workers Working
Group moving forward.

Annevk, Marcos (cc'd) any additional thoughts?


For the Web Platform Working Group:

tl;dr: We should keep reiterating our Formal Objection until the
charter is changed to drop dupllication of specs that are being well
maintained by WHATWG. It's a waste of everyone (including ours) time
for such duplication.

Something with the substance of the following - feel free to reword
for terseness etc.:

Formal Objection:

We request dropping all REC track specifications that the WHATWG has
demonstrated good maintenance of (by evidence of active implementer
participation and implementation, including Mozilla in Firefox).

Optional: Republish current version as a terminal NOTE, citing the
WHATWG version as normative at the top of the NOTE in large text as we
would for any other abandoned document for which better / more recent
/ more accurate versions exist elsewhere.

Particular specifications that we request WPWG drop from REC track deliverables:
 * HTML5.2: at this point *no implementer* (people actually committing
code to browsers) are paying any practical (in that it affects code)
attention to HTML5.2, especially to any differences between HTML5.2
and WHATWG HTML, despite having editors from Microsoft and Google. It
is unlikely that there are any patent/IP benefits to pursuing HTML5.2
(existing features already covered by HTML5 REC) at W3C.
 * microdata: as previously noted, WHATWG maintains microdata, no need
for any W3C time spent on this.
* ... any others? (Annevk, Marcos?)

Such duplication work by W3C WPWG is actively harmful in a number of ways.

* It harms the relationship between W3C and WHATWG, both of which a
number of organizations including Mozilla actively participates in.

* This active relationship harm provides unnecessary friction as well
as disincentivizes collaboration and demonstrates either neglect or
outright passive ill-will from one or more of chair(s)/staff of Web
Platform WG toward WHATWG and that's unacceptable behavior (counter to
W3C PWE).

* Press and developers are continuing to be misled by the illusion
that HTML5.2 is providing
any kind of meaningful update to HTML, when meaningful updates (i.e.
things that are implemented or fixed in browsers that web developers
can then depend on) are only based on WHATWG HTML at this point.

* ... anything else? (again, Annevk, Marcos, explicitly soliciting
your additional input here)


Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: HTML scoped style sheets (

[Tantek Çelik]

On Wed, Jun 21, 2017 at 8:13 AM, Cameron McCormack  wrote:
> On Wed, Jun 21, 2017, at 10:56 PM, Ehsan Akhgari wrote:
>> Why only in the medium term?  Restyling is very costly for browser.xul
>> right now, and it would be very nice if we can use Stylo to gain some
>> advantages there, especially since costly restyles in the parent process
>> do mean UI jank for our users.  I realize that Stylo won't immediately
>> be able to style browser.xul, but it seems like we should definitely
>> prioritize getting rid of front-end side dependencies that would prevent
>> us from using it as soon as the Stylo side of things are ready and
>> sounds like the issue Jared mentioned is one such issue.  Does this
>> sound right?
>
> By medium term, I mean "not too long after 57".  :-)  But yes, it would
> be helpful to have the existing chrome document uses of 

Heads-up: CfC for W3C Microdata FPWD

[Tantek Çelik]

The Web Platform WG has issued a call for consensus to publish a FPWD
of HTML Microdata as a spec:

https://github.com/w3c/microdata/issues/7

If we don't think this should eventually become a W3C Recommendation,
it's helpful to explicitly object sooner rather than later.

Previously we (Mozilla) formally objected to the broad inclusion of
Microdata in the Web Platform WG charter, and the W3C narrowed it to
include just the markup bits (and drop the DOM API which we
specifically unimplemented in Gecko).


Summary:

Positive:
* There are legacy microdata markup publishers and consumers on the
live web (enough to consider it "incubated").
** Caveat: this is a trailing indicator at this point.

Negatives:

* The original proposers of Microdata (Google) have switched to
recommending JSON-LD data islands instead.

* There is no "microdata community"
** Even the SEO "community" has largely abandoned it since it's no
longer Google's "recommended" approach.

* Better alternatives exist with strong and growing communities (RDFa
for SemWeb folks, and the much simpler microformats2 in the growing
IndieWeb community and movement)

For these reasons I'm going to restate an objection:

Microdata markup is at this point legacy and no longer an industry nor
community recommended part of the web platform, thus W3C should not be
developing it towards a REC.

It is also thus not worth W3Cs resources to spend any WG time on
Microdata, except perhaps to update the existing Microdata Note to
drop the unimplemented DOM API due to the negative implementation
experience thereof.


I'm posting this here in case anyone has any new information,
supporting or otherwise.


Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: CSS text-justify property

[Tantek Çelik]

On Fri, Apr 7, 2017 at 11:31 AM, fantasai  wrote:
> On 02/08/2017 11:28 AM, Boris Zbarsky wrote:
>>
>> On 2/8/17 5:08 AM, Jeremy Chen wrote:
>>>
>>> Link to standard:
>>> https://drafts.csswg.org/css-text-3/#text-justify-property
>>
>>
>> How stable is this spec?
>>
>> Note that even if it's unstable that shouldn't stop us implementing; that
>> mostly affects shipping.  So as long as we're pretty
>> sure that the basic set of functionality is stable, even if the actual
>> names of the values are not, implementing makes sense.
>
>
> Not especially unstable, but IIRC there's a number of outstanding edits,

So we should wait for those edits before implementing right? So that
we don't implement an out-of-date editor's draft?

> which is the main thing holding up the updates to /TR. The spec was
> previously in Last Call, so expected changes are mainly bugfixes.

Are these bugfixes severe enough to wait on implementing, or should we
implement in parallel while waiting for the edits?

> Open issues relevant to text-justify:
>   https://github.com/w3c/csswg-drafts/issues/853
>   https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-116
>   https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-117
> (I vaguely recall this being resolved, but it's clearly not updated)
>
> ~fantasai


Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: CSS property `line-height-step`

[Tantek Çelik]

On Fri, Mar 31, 2017 at 1:16 PM, fantasai  wrote:
> On 03/31/2017 07:55 AM, L. David Baron wrote:
>>
>> On Friday 2017-03-31 12:11 +0800, Tommy Kuo wrote:
>>>
>>> **Summary**
>>>
>>> I am intent to implement the property `line-height-step`. And it would be
>>> disabled behind the pref `layout.css.line-height-step.enabled` by default.
>>> It is a property to make authors create the content with vertical rhythm
>>> easier.
>>>
>>> **Link to standard**
>>>
>>> CSS Rhythmic Sizing
>>> 
>>
>>
>> So in the discussions in the working group, I've been somewhat
>> skeptical that this feature does a good job of addressing the design
>> use cases that it's intended to address.
>
>
> As the co-editor of the spec, I agree with David Baron's concerns.
>
> Also, based on my discussions with Dave Cramer (CSSWG member who works
> in the publishing industry), my understanding is that the the most
> common problems are situations that need to be solved with block height
> stepping, not line height stepping. An author can fairly easily ensure
> that, within a paragraph, the line height follows a strict vertical
> rhythm: as long as the text is not interrupted by atomic inline content
> or text that has a larger font size / different vertical alignment (and
> this covers the majority of text), it will maintain rhythm. But when the
> paragraph text is interrupted by different content such as illustrations
> and headings, then the rhythm can be thrown off. These are block-level
> intrusions into the rhythm, and won't be solved (without hacks like
> turning them into inline-blocks) by line height stepping. But they are
> solved by block height stepping (which is also outlined in that draft).
>
> I think we should endeavor to avoid “solutions” that require hacks, so
> my advice would be to implement block height stepping first, since it
> will more directly solve most of the use cases. I'm less convinced that
> line height stepping is necessary; and also there are many issues with
> inline layout that need to be addressed before it can be an effective
> solution to the problems it addresses.
>
> * Note that even for headings, which are text, it is the margin-box of
> the heading as a whole which needs to fit into the rhythm, not necessarily
> each line of it; headings usually have large margins, but the text is set
> closely between lines. Similar concerns apply to blockquotes with smaller
> text, figures with captions, and other block-level interruptions to prose.

Completely agreed re: the prioritization of block height stepping
before line height stepping and the respective design use-cases.

The issues noted here, and the summaries of use-cases are worthy of
explicitly including in the spec. Perhaps even a coarser change like
noting/listing block height stepping *before* line height stepping
both in the introduction and structure of the overall document.

I'll file spec issues accordingly to discuss separately from this
intent to implement thread.

Thanks fantasai.

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

[Tantek Çelik]

Makes sense Mats, exactly as you divided it up. Thanks for pushing this.

Note: the 'appearance' property was previously in a CSS3 UI CR:
* https://www.w3.org/TR/2004/CR-css3-ui-20040511/#appearance
Where it was stable for nearly 8 years but dropped subsequently due to
lack of interop (actual divergence among implementations)

It was subsequently moved to CSS UI level 4, simplified to two values,
'auto' and 'none':
* https://drafts.csswg.org/css-ui-4/#appearance-switching

Thus this is an intent for the complete implementation of the latest
'appearance' property as specified in css-ui-4.

Though not (currently) in a CR, this property and those two values in
particular have been unchanged for years, and their definitions can be
considered stable.

Thanks,

Tantek



On Fri, Feb 10, 2017 at 2:27 PM, Mats Palmgren  wrote:
> Summary: add support for the CSS UI property 'appearance:none | auto' with
> '-webkit-appearance' as an alias.  Unship '-moz-appearance'.
>
> 'appearance:none' works exactly as '-moz-appearance:none' -- it turns off
> the native theme for elements that have one.  'appearance:auto' (the initial
> value) makes an element have its default appearance.  We are currently
> shipping '-moz-appearance' with a large number of other values, such as
> 'button', 'range', 'radio' etc.  '-moz-appearance' will continue to work
> exactly as is, but will now be restricted to UA and chrome style sheets,
> i.e. it will *not* be available to web content.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1333482
>
> Spec: https://drafts.csswg.org/css-ui-4/#appearance-switching
>
> Platfrom coverage: All
>
> Estimated release: 54 (tentatively)
>
> Preferences: layout.css.appearance.enabled for
> 'appearance'/'-webkit-appearance' (enabled by default),
> layout.css.moz-appearance.enabled for '-moz-appearance' (disabled by
> default).  All these properties are available to UA and chrome style sheets
> though, regardless of the preference settings.
>
> Devtools bug: None needed, I think.
>
> Status in other implementations: No other UA implements the unprefixed
> 'appearance' as far as I know.  Edge implements '-webkit-appearance:none'
> but no other values, nor do they implement it unprefixed.  WebKit/Blink
> implements '-webkit-appearance' with a plethora of values, much like we
> currently do for '-moz-appearance'.  I don't know what their plans are for
> 'appearance' and/or restricting the number of supported values.
>
> I think the fact that Edge currently only ships '-webkit-appearance:none'
> proves that's all that is needed for web compat.  I tend to think we should
> also implement the unprefixed property though, because that's what the CSS
> spec says and I don't think it'll have any negative impact in terms of web
> compat (I admit I'm not 100% certain of that though, but we can adjust as
> needed).
>
> Tests: Reftests and mochitests included.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendation: Data on the Web Best Practices

[Tantek Çelik]

On Wed, Dec 28, 2016 at 5:08 PM, Karl Dubost  wrote:
> David,
>
> Le 29 déc. 2016 à 09:15, L. David Baron  a écrit :
>>  Data on the Web Best Practices
>>  https://www.w3.org/TR/dwbp/
>
> I didn't participate to this group and this document, but I went through it 
> today.

I also did not participate in this group or document, and wasn't going
to go through it (generally suspicious from experience of any W3C spec
with "data" in the title), but since Karl thought it was worth going
through, thought I would take a look as well.


>> My inclination is to abstain from this review, but could probably be
>> convinced to send other forms of supportive response.
>
> There's nothing to implement on the browser side from Mozilla wrt to this 
> specification,

I agree with this conclusion (though I suspect we may have different reasoning).


> but the best practices which are given into the document are quite good,

I have to dispute this assertion, or at a minimum ask what is meant by "good".

If by "good" we mean the modern interpretation of good open web
standards, which is to document growing and broadly interoperable
(publishing and consuming) standards, then this specification fails
that so dramatically that it's laughable.*(expansion in footer)

From a quick skim, it appears this spec reflects a small set of niche
publishers on the web, rather than what the open web as a whole has
emergently adopted by both publishing and *consuming* code.
(publishing any format or data, without involving consuming code, over
time, is next to useless and subject to noise, rot, as well as
outright deception, see also Metacrap by Doctorow).

E.g.: the specification mentions a bunch of "namespaces" (nevermind
that being a red flag itself) explicitly:

http://www.w3.org/TR/dwbp/#namespaces

Most of which appear to be tired old W3C (mostly) academic attempts to
make RDF a thing (no pun intended).


> well articulated,

I'm not sure how to evaluate that. As is usual with RDF based
documents, the spec seemed quite abstract.


> with a nice regular template for each best practice.

I think we have a different understanding of "template". The only
"template" in the spec is for individual best practice *descriptions*
in the spec, not best practices of data publishing.

In addition, a single data "template" (as example) is provided of a
bus stop timetable: http://www.w3.org/TR/dwbp/dwbp-example.html


> It's easy to read and easy to use.

I think we have a different understanding of "easy", or perhaps "read" or "use".


> And one is basically free to pick-up the elements that will improve his/her 
> data collections for sharing.

I think we have different understandings of "improve" and "sharing".

For one, sharing depends on data consumers, which the spec (and
implementation report) recognize as important, but are scant to
actually document (typical for RDF).


Bottom line recommendation for AC vote:
===
Explicit "Abstains from review".

Comment: In our opinion, there's nothing to implement on the browser
side WRT this specification. In general we don't think this
specification reflects actual deployed and growing  modern data
publication and consumption practices on the open web of 2016, however
practices therein seem (mostly) harmless.
===

Meta-summary:

* Not worth time fighting. I think we should not object to this spec,
as it will simply waste time fighting with academics who have time to
waste (may even be paid / grant funded to do so), including by
publishing PDF papers about it (not actually using web standards, nor
even the formats in this spec).

* Bad data practices may slow or counter hostile/oppressive gov
use-cases. Another consideration (for passively allowing this spec),
especially per the spec's explicit frequent mentions of government
data use-cases, is that if these practices are as bad as I suspect
they are (per noise, rot, deception comment above), then the adoption
(by governments are other such large institutions) of poor quality and
unconsumed data practices may actually have the indirect side-effect
be *good* for individual user privacy by way of the failure of such
systems that follow the advice in this spec.

Tantek


*Laughable because the spec doesn't even bother to *mention* (except
barely in one case), the data on the web practices that have
*actually* become widely published *and* consumed (pretty much expect
most people here to have heard of most of these in contrast to the RDF
namespaces that W3C's spec mentions)

Zero mentions of:
* Atom feed format — still plenty of publishers and independent
consumers, despite Google Reader shutdown
* microformats — check any Web Data Commons crawl stats for
publication for the past 5 years (back to 2012), shows adoption in
excess of any of the namespaces provided by the W3C spec, and growing
*consumption* beyond search engines by numerous IndieWeb (mostly open
source) 

Re: Intent to implement: HTML5 element

[Tantek Çelik]

On Fri, Dec 23, 2016 at 4:02 PM, Martin Thomson  wrote:
> On Fri, Dec 23, 2016 at 6:20 PM, Boris Zbarsky  wrote:
>>> I mean, the attribute is probably a lost cause
>>
>> Why?  Is there significant usage, or at least wide implementation, of that
>> part of the API already?  The original intent said that only Chrome is
>> shipping this.
>
> Fair point.  I guess the question becomes whether Chrome compatibility
> is the reason we are doing this.

Yes this is the key question.

IF there is a webcompat issue now, THEN we have little choice but to
implement the API as is.

IF there is no webcompat issue, THEN
* We should NOT implement this "legacy" API, as us implementing in
addition to Chrome may be enough to create a compat issue (for
everyone else for this API design, and provide another point of
inconsistency for web developers). Let's avoid a platform wart if we
can.
* We should be prepared to propose fixes/updates to the API that use a
Promise per points from Joe, mt, bz, and then prototype/implement
accordingly.


Is there some other time pressure / use-case need to ship this feature
"soon" that hasn't been discussed in this thread so far?

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

[Tantek Çelik]

I'm also curious how interactions between dialog.showModal() and then
controls inside of that going Fullscreen work (and then perhaps a
dialog inside that fullscreen view, etc.) Does "escape" key escape out
of one layer of dialog/fullscreen? multiple? all?

Tantek

On Tue, Dec 20, 2016 at 4:12 PM, Mats Palmgren  wrote:
> Hi Tim, can you describe how the modality of dialog.showModal() works?
> Does a web page have the power to block the user from interacting
> with the entire browser (all windows)? Or is it just one window?
> or just one tab? or something else?
>
> Thanks,
> Mats
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Tantek Çelik]

On Fri, Dec 16, 2016 at 10:51 AM, Gervase Markham  wrote:
> On 15/12/16 14:20, Daniel Stenberg wrote:
>> Looking at that collection of existing user, basically all of them want
>> the user to anser this question:
>>
>>  "Use expensive traffic (y/n)"
>
> And this should be an OS-level switch which the browser and other apps
> both respect and reflect. Doesn't Android already have a "background
> data" switch?

Until an OS-level switch happens, I think a browser level switch could
work well.


> If I'm on the train wifi, I want to turn off all unnecessary traffic,
> both to show love to other users, and because it'll make what I'm
> actually focussed on doing faster. Now is not the time to run a backup.
> I'd love such a switch on my laptop which my apps and web pages respected.

Gerv points out another good use-case. Train/plane and other shared
limited wifi.

Honestly this is starting to sound more and more like a need for a
"Minimal Network" variant of the "Work Offline" option we have in
Firefox (which AFAIK no other current browser has), since no amount of
OS-level guess-work is going to give you a reliable answer (as this
thread has documented).

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Tantek Çelik]

On Thu, Dec 15, 2016 at 11:51 AM, Boris Zbarsky  wrote:
> On 12/15/16 12:20 PM, Ben Kelly wrote:
>>
>> Its more information than nothing.
>
>
> I'm not sure it is.  At least when you have nothing you _know_ you have
> nothing, so might think about other ways to find out what you want to know.
> This way you think you know something but you don't.

Agreed with Boris. "more information than nothing" is not an absolute
value, when that information is deceiving, which as others have
pointed out in this thread, is quite likely to occur with non-trivial
frequency in common uses of this API (the "if bandwidth>x then slow
download" example proves this point).

E.g. a high % of the time, (most of the time when I'm not at home or
work), I am on a 4G (high bandwidth) mifi (metered cost).

This API would report misleading results for me 100% of the time I am
on my mifi, and for anyone else on a 4G mifi.

Real experience, all (AFAIK) the "sync to cloud automatically" code
out there makes this mistake, e.g. iCloud, DropBox etc., so I've had
to turn all of it off or just not use it.

Let's learn from the error of "native" implementations/uses of this
kind of API / use thereof and not repeat that mistake on web,
certainly not ship an API that misleads web developers into doing the
wrong thing.


>> Bluetooth networking is also a thing.
>
>
> That's a good point.
>
>> I think being able to distinguish this stuff provides some value even if
>> its not perfect for all cases.  And I don't see how it causes any harm.
>
>
> I think it causes harm to give people information they have no business
> having ("wifi" vs "ethernet") and it does harm to given them information
> that's likely to be bogus (the last hop speed in the wifi/ethernet cases).

Precisely. Obvious harms:

1. Privacy compromise without obvious user benefit
2. Causes web apps to waste user bandwidth/financial resources

If the response to that is "but doing it right is too hard", then
don't do it all.

> Maybe the answer is that we should just reconsider the set of types that
> gets exposed and how they get mapped to connection speeds

I'm not sure that would sufficiently address harm 2.

As far as I can tell, the only useful bit of information (as bz
pointed out) is the

Am I on a cell data connection "for sure or maybe not"?
a) Where cell data "for sure" -> will *almost certainly cost the user*
b) Whereas "or maybe not" -> you have no idea whether it will cost the
user or not, do not make any assumptions.

Given that the one pseudo-code example provided earlier in this thread
makes the mistake of using case (b) to errantly initiate bandwidth/$
wasting downloads (which may not even be necessary), I think this API
has not been well thought through in terms of actual user benefit, and
needs further incubation.

Not to mention we shouldn't even be getting to an "Intent to *ship*"
on something we expect to standardize that hasn't even been published
as a FPWD yet (which only *starts* the count-down clock to IPR
commitment).

Implementing behind a flag should be good enough for prototyping
purposes to advocate for moving this from WICG to WPWG, and if that
transition doesn't happen for whatever reason it's a very clear sign
the tech is insufficiently incubated (or otherwise problematic) and we
shouldn't be shipping this. We're not even at that point yet!

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendation: Webmention

[Tantek Çelik]

Thanks very much for the detailed comments Joe.

tl;dr  We have to wrap this up tonight (W3C vote deadline) and I'm
pretty sure I've captured the suggestions you've made (greatly
appreciated) with public github issues (which hopefully you've
received notifications thereof).

public github issues filed for specifics, to which anyone is invited
to follow-up, even beyond tonight's AC vote submission deadline:
* https://github.com/w3c/webmention/issues/75
* https://github.com/w3c/webmention/issues/76
* https://github.com/w3c/webmention/issues/84

We can submit our vote to W3C approving the Webmention PR and asking
for these changes.

Details inline below:


On Fri, Nov 4, 2016 at 9:56 AM, Joe Hildebrand <jhildebr...@mozilla.com> wrote:
>> On Nov 4, 2016, at 9:29 AM, Tantek Çelik <tan...@cs.stanford.edu> wrote:
>>
>>> There should be some mention of the prior art in this space.
>>
>> Why in the spec? (honestly interested to know what you think should be
>> in a spec without making it more wordy as Martin pointed out)
>
> Because there has been a lot of security work done on the prior protocols, 
> particularly in terms of implementation detail in spam prevention.  It's also 
> just good karma to call out the giant upon whose shoulders you are standing.  
> Informative links from the in the document will be nice decades from now when 
> nobody remembers that those other protocols once existed.
>
>>> Pingbacks and trackbacks at least.
>>
>> https://indieweb.org/Webmention-faq#Why_webmention_instead_of_pingback
>
> Agree that this is much simpler than either.  That likely makes it easier for 
> spammers and other attackers to abuse.

Agreed about the explicit mention of Pingback in the spec with the
reasoning you gave, issue filed:

https://github.com/w3c/webmention/issues/76


>>> Section 4.5 "Limit access to protected resources" points out that this 
>>> protocol is an attractive nuisance.  Anyone who deploys it is likely to 
>>> make their infrastructure more insecure by mistake.
>>
>> Could you expand on this? How? Definitely interested in any and all
>> security concerns.
>
> Nobody is going to remember to sandbox the network connection of the process 
> that is checking the targets.  I send you a webmention whose target is 
> "https://intranet/;, your process requests that URL, and you post a synopsis 
> of what you found as a comment on the blog entry I put in the source.  Yes, 
> there are protections you can put in place for that, but I can't think of any 
> that can be coded generically into a piece of open source software that 
> doesn't open up your internal resources by default.
>
> Even requiring CORS (with the origin as "something interesting", like a 
> constant) on the target would be a step toward making this better.

Explicitly mentioning using CORS for this is quite sensible.

Issue filed: https://github.com/w3c/webmention/issues/84


>>> If there's a good reason to publish this that isn't obvious, I might be 
>>> more excited about it.
>>
>> It's interoperably implemented across double-digit implementations,
>> and deployed an interoperably in use across tens of thousands of
>> websites.
>
> That's a good enough reason.

Thanks much, and thanks again for your review!

And welcome on board at Mozilla as well!

Tantek

P.S. And from previously - to fix the JSON reference:
https://github.com/w3c/webmention/issues/75
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web of Things Working Group

[Tantek Çelik]

To add to this thread, I think there are still fundamental security
issues, which have only gotten worse, that the charter does not
address, nor has the incubation to date come even close to
understanding, much less prototyping / stress-testing.


1. The rapid deployment of WoT/IoT devices poses an existential threat
to the open internet (something we, Mozilla, are particularly focused
on protecting more than other orgs are) due to their fundamentally
worse security.

Since the DDoS attack on krebsonsecurity which motivated our initial
formal objection based on lack of security considerations in the
charter and incubation, there was the subsequent DYN DDoS attack which
took down major sites (Twitter, Github, Reddit, etc.), and that's only
with the current deployment of insecure IoT devices, by rogue groups
using open source malware. Basically it proved the security point of
our formal objection.

WoT/IoT devices are both known to already have worse security, and
expected to in the future, both in initial design / development, and
with the lack of incentive to do security software updates due to such
devices being so low margin, often built by small companies that have
low life expectancy themselves, then whitelabel bundled into larger
devices, with no way of updating the embedded software, e.g. the IoT
cameras used in the DDoS attacks.

The proposed charter (nor anyone's incubation efforts) does/do not
address these low cost, low margin, low life expectancy company,
whitelabel embedding issues. All of which have been shown to be real
problems.

This threat is so bad, that it's not clear that any increased
deployment of WoT/IoT is "good" for the open internet.

That regardless of tech stack, it is in the interest of maintaining an
open internet to do what we can to actually *slow down* the deployment
of of anything WoT/IoT, up to and including opposing standardization
efforts which seek to *accelerate* the deployment of such devices.
This is not an "absolute" situation, where we might as well give up
because it's going to happen anyway like somewhere other than W3C, but
rather a set of race conditions, where slowing things down anywhere at
all may still be incrementally helpful (make the internet as a whole
less vulnerable - it's a spectrum).


2. Increased invasive surveillance.

The above IoT security threat scenarios that we've experienced were
from small groups or individuals using malware they didn't even write.
There is an even worse potential threat from insecure WoT/IoT devices,
and that is state-level actors using those very same existing and
expected security flaws to turn WoT/IoT devices into the largest mass
surveillance and data gathering effort in history.

Every sensor on every such device a user puts in their home becomes a
potential surveillance data gathering node. Note that most the
above-noted insecure devices used in the attacks were IoT *cameras*.

Nothing from the proposed WoT charter, nor experiments/incubations
shows any semblance of any of the participants taking this threat
scenario seriously, nor did any of them raise or document any concerns
like what happened to Krebs.

(The only person in the W3C context who did provide warnings of the
kinds of attacks occuring that eventually did happen was Bruce
Schneier during his talk at the May W3C AC meeting at MIT. But he's
not involved in W3C WoT/IoT efforts himself.).


I don't see any evidence to show that W3C should pursue
standardization of anything WoT/IoT, and quite the opposite, that
we're at a point of WoT/IoT industry immaturity where product
development and deployment is both hurting the internet, and
presenting a potentially even larger threat to users of such products
being transparently, illegally*, invasively surveilled by their
governments hacking the devices in their own homes (*but recently
approved in the UK[1]), and thus should be opposed.


If anything, we (Mozilla) should be reaching out to EFF and any other
W3C Members who value an open internet and respecting users privacy
more than profit (perhaps university members of W3C) and asking them
to join our formal objection to anything WoT/IoT at W3C.


Tantek

[1] http://www.wired.co.uk/article/ip-bill-law-details-passed


On Tue, Nov 29, 2016 at 7:23 AM, Benjamin Francis  wrote:
> Hi David,
>
> Have you had any more correspondence with the W3C on Mozilla's behalf
> regarding this charter?
>
> From the Web of Things Interest Group mailing list
>  it appears that the
> group is happy to remove the dependency on RDF as suggested in our feedback
> (although they claim this wasn't intended as a dependency in the first
> place). Instead I understand they would like to include an extension point
> in the Thing Description such that semantic annotations could be added
> externally to the Thing Description specification if desired. This seems
> reasonable to me.
>
> On the point of the charter being 

Re: Intent to ship: CSS Grid

[Tantek Çelik]

Agreed. In the perspective of the increasing shift toward incubation
at W3C (before WG and certainly before WD or CR), subgrid has yet to
be sufficiently incubated to really implement in the context of a
spec, unlike the rest of grid which has been prototyped with multiple
iterations (by other implementers) to get us where we are (hence it's
a great thing that we're shipping grid itself, well done Mats).

The circularity that Simon refers to can be broken by prototyping
subgrid separately, i.e. behind a feature flag, and iterating with
developer feedback, and getting that iteration in the spec, and then
taking that feature to an actual CR with actual shipping
implementations.

Unless by some lucky guess subgrid has been perfectly specified
without incubation, we should be ok with it being dropped from the
spec, or rather, pushed out into a future version.

Tantek


On Thu, Nov 17, 2016 at 1:19 AM, Jet Villegas  wrote:
> Unlike other parts of the Grid spec, we don't have sufficient implementor
> feedback (from ourselves or others) to evaluate the subgrid feature's
> suitability for implementation. That will take time to get, and we do plan
> to get it, but we want Grid available to people while we do so. That's not
> the same as "nobody's implementing, so we won't either."
>
> --Jet
>
> On Wed, Nov 16, 2016 at 9:22 AM, Simon Sapin  wrote:
>
>> On 16/11/16 01:40, Mats Palmgren wrote:
>>
>>> Note about the 'subgrid' feature:
>>> We will *not* support the subgrid feature of CSS Grid in this first
>>> release.  This feature is marked as "at-risk" in the spec and thus
>>> not needed for spec compliance.  (Chrome is likewise not going to
>>> support subgrid in their first release.)
>>>
>>
>> I don’t have a strong opinion on subgrid specifically, and other arguments
>> can be made, but I’d like to note:
>>
>> It is marked at-risk in the spec *because* several vendors had said they
>> might not support it at first. So using this to justify not supporting it
>> is a circular argument.
>>
>> --
>> Simon Sapin
>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendation: Webmention

[Tantek Çelik]

On Thu, Nov 3, 2016 at 10:05 PM, Joe Hildebrand  wrote:
> The JSON reference really needs to be to RFC 7159, not 4627. (blocking, but 
> trivial issue)

Will file an issue on that.


> There should be some mention of the prior art in this space.

Why in the spec? (honestly interested to know what you think should be
in a spec without making it more wordy as Martin pointed out)


>  Pingbacks and trackbacks at least.

https://indieweb.org/Webmention-faq#Why_webmention_instead_of_pingback


> Section 4.5 "Limit access to protected resources" points out that this 
> protocol is an attractive nuisance.  Anyone who deploys it is likely to make 
> their infrastructure more insecure by mistake.

Could you expand on this? How? Definitely interested in any and all
security concerns.


> If there's a good reason to publish this that isn't obvious, I might be more 
> excited about it.

It's interoperably implemented across double-digit implementations,
and deployed an interoperably in use across tens of thousands of
websites.

Tantek


>> On Nov 3, 2016, at 7:25 PM, L. David Baron  wrote:
>>
>> A W3C Proposed Recommendation is available for the membership of W3C
>> (including Mozilla) to vote on, before it proceeds to the final
>> stage of being a W3C Recomendation:
>>
>>  Webmention
>>  W3C TR draft: https://www.w3.org/TR/webmention/
>>  W3C Editor's draft: https://webmention.net/draft/
>>  deadline: Wednesday, November 30 (23:59 in UTC-05:00)
>>
>> If there are comments you think Mozilla should send as part of the
>> review, please say so in this thread.  (I'd note, however, that
>> there have been many previous opportunities to make comments, so
>> it's somewhat bad form to bring up fundamental issues for the first
>> time at this stage.)
>>
>> -David
>>
>> --
>> 턞   L. David Baron http://dbaron.org/   턂
>> 턢   Mozilla  https://www.mozilla.org/   턂
>> Before I built a wall I'd ask to know
>> What I was walling in or walling out,
>> And to whom I was like to give offense.
>>   - Robert Frost, Mending Wall (1914)
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>
> --
> Joe Hildebrand
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendation: Webmention

[Tantek Çelik]

On Thu, Nov 3, 2016 at 8:22 PM, Martin Thomson  wrote:
> On Fri, Nov 4, 2016 at 1:25 PM, L. David Baron  wrote:
>>   W3C Editor's draft: https://webmention.net/draft/
>
> Wow, that is an extraordinarily wordy document for something that does
> so little.

It was a lot shorter at the IndieWebCamp community.

Extraordinary wordiness is often the consequence of taking something
to W3C, and having lots of issues filed that seem to need explicit
answers in the spec to various criticisms. Some of these are often
helpful!

>  It's the first I've heard of this, but it's remarkably
> similar to (albeit much narrower than):
>
> https://www.w3.org/Protocols/HTTP/Methods/Link.html
> https://tools.ietf.org/html/draft-pritchard-http-links-00
> and recently:
> https://tools.ietf.org/html/draft-snell-link-method-12

Here's the explanation of "Why not HTTP LINK":

https://indieweb.org/Webmention-brainstorming#Alternatives

Including that in the spec would of course make it wordier still,
though it's reasonable to include it in the FAQ.

https://indieweb.org/Webmention-faq#Why_webmention_instead_of_pingback

No one has reasonably* asked for using HTTP LINK instead.

*AFAIK no one actually implements and deploys HTTP LINK - it was a
brainstorm that was never incubated with real implementations and
remains theoretical.

Do you know of any implementations, deployments, actual real world
uses of HTTP LINK?


> I wouldn't bother saying anything, though, it's just yet another 
> specification.

Webmention is deployed and live on tens of thousands of Known and
WordPress sites, and many more smaller deployments of other
implementations.

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

W3C Proposed Recommendation: Webmention

[Tantek Çelik]

Support :)

I'm co-chair of the WG that produced this PR, as well as familiar with and
contributed to its incubation/prototyping/implementation (including on my
own site tantek.com) in the IndieWeb community before we brought it to
a W3C WG for broader review and consideration.

Happy to answer any questions, as well as provide a longer summary tomorrow
(PDT).

Thanks,

Tantek

On Thursday, November 3, 2016, L. David Baron > wrote:

> A W3C Proposed Recommendation is available for the membership of W3C
> (including Mozilla) to vote on, before it proceeds to the final
> stage of being a W3C Recomendation:
>
>   Webmention
>   W3C TR draft: https://www.w3.org/TR/webmention/
>   W3C Editor's draft: https://webmention.net/draft/
>   deadline: Wednesday, November 30 (23:59 in UTC-05:00)
>
> If there are comments you think Mozilla should send as part of the
> review, please say so in this thread.  (I'd note, however, that
> there have been many previous opportunities to make comments, so
> it's somewhat bad form to bring up fundamental issues for the first
> time at this stage.)
>
> -David
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Audio Working Group

[Tantek Çelik]

On Wed, Oct 26, 2016 at 7:25 PM, L. David Baron <dba...@dbaron.org> wrote:
> On Friday 2016-10-21 15:01 -0700, Tantek Çelik wrote:
>> Support revised charter, with requested changes:
>> * Hyperlink the phrase "Community Group" in the charter to the
>> specific Community Group they mean, and perhaps title the hyperlink
>> more specifically as well.
>> * List the Community Group explicitly in the coordination section
>> http://www.w3.org/2011/audio/charter/audio-2016.html#coordination and
>> describe the relationship between the WG and the CG.
>
> So the only community group mention I can see in the charter is to
> say that work that is out of scope for the working group could
> instead occur in a community group (which I think means a
> hypothetical community group).  If that's the case, I don't think
> the second comment makes sense since the intent is that the material
> be out of scope for the working group.  It could be clearer that the
> community group is hypothetical, though.
>
> I'm inclined to submit the comment as:
>> One basically-editorial suggestion:
>>
>> Either:
>>
>> * Hyperlink the phrase "Community Group" in the charter to the
>> specific Community Group intended, and perhaps title the hyperlink
>> more specifically as well.
>>
>> * Or, if no such community group exists, make it clearer that it's
>> a hypothetical community group.
>
> (and record it as a support-with-optional-changes).

Yes, support with optional-changes, and how you've worded it works for me.

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Automotive Working Group

[Tantek Çelik]

Ekr,

This sounds to me like there are sufficient reasons to formally object
to this charter, and as Martin points out, a special case of IoT/WoT
(with additional concerns!).

David,

Thus I too think we should formally object, link to our previous
formal objection of the WoT charter (since nearly all the same reasons
apply), and list the new items that Martin and Ekr provided. I suggest
we cc this response to www-archive as well.

Thanks,

Tantek



On Tue, Oct 18, 2016 at 3:10 AM, Eric Rescorla  wrote:
> I share Martin's concerns here...
>
> There's fairly extensive evidence of security vulnerabilities in
> vehicular systems that can lead to serious safety issues (see:
> http://www.autosec.org/publications.html), so more than usual
> attention needs to be paid to security in this context.
>
> In fairness, a lot of these are implementation security issues:
> i.e., how to properly firewall off any network access from the
> CAN bus. You really need to ensure that there's no way
> to influence the CAN bus, which probably means some kind of
> very strong one-way communications guarantee. At some level
> these are out of scope for this group, but it's predictable
> that if this technology is built, people will also implement
> it in insecure ways, so in that respect it's very much in-scope.
>
> The commuications security story also seems to be not well
> fleshed out. The examples shown all seem to have fixed hostnames
> (wwwivi/localhost) which don't really seem like the basis for
> strong identity. It's not just enough to say, as in S 6, that
> the server has to have a certificate; what are the properties of
> that certificate? What identity does it have?
>
> This is particularly concerning:
>
> At this point, internet based clients and servers do not know the
> dynamic IP address that was assigned to a specific vehicle. So
> normally, a vehicle has to connect to a well known endpoint,
> generally using a URL to connect to a V2X Server. The vehicle and
> the internet server typically mutually authenticate and the
> vehicle 'registers' with the server over an encrypted channel
> passing it a unique identifier e.g. its Vehicle Identification
> Number (VIN). From that point on, the server has the IP address
> that is currently assigned to a vehicle with a particular VIN, and
> can share this information with other internet based clients and
> servers, which are then able to send messages to the vehicle.
>
> How does the V2X server know that this is actually my VIN? Just because
> I claim it over an encrypted channel.
>
> In IETF we often ask at the WG-forming stage whether we feel that the
> community has the expertise to take on this work. The current proposal
> seems to call that into question and absent some evidence that that
> expertise does in fact exist, I believe we shoud oppose formation.
>
> -Ekr
>
>
> On Mon, Oct 17, 2016 at 5:11 PM, Martin Thomson  wrote:
>
>> This seems to be a more specific instance of WoT.  As such, the goals
>> are much clearer here.  While some of the concerns with the WoT
>> charter apply (security in particular!), here are a few additional
>> observations:
>>
>> Exposing the level of information that they claim to want to expose
>> needs more privacy treatment than just a casual mention of the PIG.
>>
>> Websockets?  Protocol?  Both of these are red flags.  Protocol
>> development is an entirely different game to APIs and the choice of
>> websockets makes me question the judgment of the people involved.  Of
>> particular concern is how the group intends to manage interactions
>> with SOP.  Do they intend to allow the web at large to connect to
>> parts of the car?  The security architecture is worrying in its lack
>> of detail.
>>
>> If this proceeds, the naming choice (wwwivi) will have to change.  It
>> is not OK to register a new GTLD (see
>> https://tools.ietf.org/html/rfc6761).  A similar mistake was made
>> recently in the IETF, and it was ugly. For people interested in the
>> gory details, I can provide more details offline.
>>
>> On Tue, Oct 18, 2016 at 6:32 AM, L. David Baron  wrote:
>> > The W3C is proposing a new charter for:
>> >
>> >   Automotive Working Group
>> >   https://lists.w3.org/Archives/Public/public-new-work/2016Oct/0003.html
>> >   https://www.w3.org/2014/automotive/charter-2016.html
>> >
>> > Mozilla has the opportunity to send comments or objections through
>> > Monday, November 7.  However, I hope to be able to complete the
>> > comments by Tuesday, October 25.
>> >
>> > Please reply to this thread if you think there's something we should
>> > say as part of this charter review, or if you think we should
>> > support or oppose it.
>> >
>> > Note that this is a new working group.  I don't know of anyone from
>> > Mozilla being involved in the discussions that led to this charter.
>> >
>> > -David
>> >
>> > --
>> > 턞   L. David Baron

Re: Intent to restrict to secure contexts: navigator.geolocation

[Tantek Çelik]

On Fri, Oct 21, 2016 at 2:56 PM, Ehsan Akhgari  wrote:
> On 2016-10-21 3:49 PM, Richard Barnes wrote:
>> The geolocation API allows web pages to request the user's geolocation,
>> drawing from things like GPS on mobile, and doing WiFi / IP based
>> geolocation on desktop.
>>
>> Due to the privacy risks associated with this functionality, I would like
>> to propose that we restrict this functionality to secure contexts [1].
>>
>> Our telemetry for geolocation is a little rough, but we can derive some
>> upper bounds.  According to telemetry from Firefox 49, the geolocation
>> permissions prompt has been shown around 4.6M times [2], on about 3B page
>> loads [3].  Around 21% of these requests were (1) from "http:" origins, and
>> (2) granted by the user.  So the average rate of permissions being granted
>> to non-secure origins per pageload is 4.6M * 21% / 3B = 0.0319%.
>
> Does this mean that we'd be breaking one in 5 geolocation requests as a
> result of this?  That seems super high.  :(

Agreed. For example, my understanding is that this will break
http://www.nextbus.com/ (and thus http://www.nextmuni.com/ ) location
awareness (useful for us SF folks), which is kind of essential for
having it tell you transit stops near you. -t


> Since the proposal in the bug is adding [SecureContext] to
> Navigator.geolocation, have we also collected telemetry around which
> properties and methods are accessed?  Since another kind of breakage we
> may encounter is code like |navigator.geolocation.getCurrentPosition()|
> throwing an exception and breaking other parts of site scripts...
>
>> Access to geolocation from non-secure contexts is already disabled in
>> Chrome [4] and WebKit [5].
>>
>> Please send any comments on this proposal by Friday, October 28.
>>
>> Relevant bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1072859
>>
>> [1] https://www.w3.org/TR/secure-contexts/
>> [2] https://mzl.la/2eeoWm9
>> [3] https://mzl.la/2eoiIAw
>> [4] https://codereview.chromium.org/1530403002/
>> [5] https://trac.webkit.org/changeset/200686
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Second Screen Working Group

[Tantek Çelik]

I have reviewed the charter and the current set of deliverables. The
work appears to be proceeding reasonably (pragmatically, with many
members/implementers including Apple and Google) and reasonably
minimally scoped. There is also the companion Second Screen Community
Group which appears to be used to incubate work before proceeding in
the working group, a pattern which we are generally supportive of.

Support revised charter.

I don't know of our current implementation plans on this WG's deliverables.

The most recent discussion here of any of the deliverables of the WG
was on "PresentationAPI", in particular a "[PresentationAPI] Intend to
implement" thread here in 2014 September.

Tantek


On Mon, Oct 17, 2016 at 12:28 PM, L. David Baron  wrote:
> The W3C is proposing a revised charter for:
>
>   Second Screen Working Group
>   https://lists.w3.org/Archives/Public/public-new-work/2016Sep/0011.html
>   https://www.w3.org/2014/secondscreen/charter-2016.html
>
> Mozilla has the opportunity to send comments or objections through
> next Tuesday, October 25.
>
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it.
>
> Mozilla does have participants in this group:
> https://www.w3.org/2000/09/dbwg/details?group=74168=1=org#_MozillaFoundation
>
> -David
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendation: WebIDL Level 1

[Tantek Çelik]

tl;dr: We must formally object to the advancement of W3C Proposed
Recommendation: WebIDL Level 1
. Five (areas of)
reasons (and details) given below. -t


On Mon, Oct 10, 2016 at 11:08 PM, Boris Zbarsky  wrote:
> On 10/11/16 1:23 AM, L. David Baron wrote:
>>
>> But given that it is worthwhile to advance snapshots of stable
>> features to Recommendation every so often, is there a reason to
>> oppose this particular snapshot, even though it's not a suitable
>> target for implementation?
>
>
> I think the main reason I'm wary of publishing a Recommendation based on
> this snapshot is that there are known things in there that are broken

Publishing a CR (much less a PR, and much much less advancing to REC)
of a spec that has known (open) normative issues ("known things in
there that are broken") is out of order and it would be correct to
formally object based on that alone. It also merits a "the chairs
should know better" process finger-wagging as it were, assuming the
"known things in there that are broken" all have issues filed.


> and
> just haven't been fixed yet due to lack of editor bandwidth.

Lack of editor bandwidth is no excuse to prematurely force a draft
through the process.


So let's take a look at the open issues in particular:

The PR links to:

https://github.com/heycam/webidl/issues
- 48 open issues

Subtracting "editoral" labeled issues:
https://github.com/heycam/webidl/issues?utf8=✓=is%3Aissue%20is%3Aopen%20-label%3Aeditorial
- 37 open issues

Subtracting "enhancement" labeled issues (generously assuming
"enhancement" means "for level 2+"):
https://github.com/heycam/webidl/issues?utf8=✓=is%3Aissue%20is%3Aopen%20-label%3Aeditorial%20-label%3Aenhancement
- 23 open issues

That alone is sufficient for a formal objection.
1. Too many open normative issues. Make it zero. (citation) For
example all of the following issues (1,2,3 link to below to-be-filed
issues) are each themselves worthy of independently blocking the PR
(even a CR).

That being said:

> For example, we know for a fact that the editor's draft will be fairly
> incompatible with this snapshot a few months from now (assuming everything
> goes as planned), necessitating changes to a number of webidl-using
> specifications to adopt some syntax changes to how mixins are declared.
> These changes are needed to get other parts of the document on a rigorous
> footing, as well as for basic clarity and sanity.

I searched those 23 open issues for "mixin" and found no open issue
with "mixin" in the title.

bz, could you file that paragraph as a gh issue, perhaps named
something like "mixin declaration syntax unstable"?

(We should then reference that issue in particular in our FO)


Continuing:
2. There is no disposition of comments. Searching for either word
reveals no links to anything showing what comments were received
during spec development and how they were resolved, including which
(if any, of explicitly stating none) of them have outstanding
commenter objections, or commenter failing to respond.



> Unfortunately, the "unstable feature" in this case is the definition of an
> "interface", which is a bit unfortunate in terms of having an actually
> usable Rec-level snapshot...  :(

I found 3 open issues with "interface" in the name, and from my naive
quick read, none of them appear to be *this* issue, so this should be
filed as well, again, for specific referencing in our FO.


> There are other probably-unstable features (e.g. serializers, which no one
> implements in the specced form and no one is likely to) in the PR draft.

None of the 23 issues mention "serializer" in their names.

This should be filed (and cited), also noting that the implementation
report / test suite
https://www.w3.org/WebPlatform/WG/implementations/webidl-1/report/all.html
does not mention "serializer" either, thus this feature should have
never exited CR (never tested!)

Thus add to the list
3. Spec contains unimplemented (and untested!) features (e.g. serializer)


> I'm pretty sure this part I raised before when the snapshot idea was
> proposed.

If you can find an email permalink for that, we can (and should) cite
that as well (for 3.)



> I guess as long as we don't mind the snapshot containing stuff that we know
> we plan to remove,

We do mind, for the reasons pointed out later in the thread (wasted
time in general, incorrect technical information being referenced and
misleading implementations - causing non-interop etc.)


More:
4. There is no exit criteria mentioned in the PR or the CR. Not sure
how this was overlooked, because explicitly documented exit criteria
are supposed to be a requirement to ENTER CR, much less exit CR /
enter PR, and advance to REC!


> P.S.  Yes, this is at least partly my fault for not putting nearly enough
> work into editing this spec.  It puts us into a tough position where the W3C
> is demanding progress towards stabilization and that progress just 

Re: Intent to implement: CSS shape-outside property

[Tantek Çelik]

This is great news! I've been hearing increasing web designer /
developer requests for this feature in particularly in the past couple
of months so it's really good to see some momentum here.

Thanks Ting-Yu Lin!

Tantek


On Fri, Oct 14, 2016 at 1:31 AM, Ting-Yu Lin  wrote:
> *Summary*: CSS shape-outside property could be used on float element to
> define a non-rectangular area like circle, ellipse, or arbitrary polygon
> shape such that text or inline elements could flow around it. See Jen's demo
>  for examples.
>
> *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1098939
>
> *Link to standard*:
> https://drafts.csswg.org/css-shapes/#propdef-shape-outside
>
> *Platform coverage*: All platforms
>
> *Preference behind which this will be implemented*:
> layout.css.shape-outside.enabled
>
> *DevTools bug*: Shapes Editor tool
> https://bugzilla.mozilla.org/show_bug.cgi?id=1242029
>
> *Do other browser engines implement this? *Yes. Both Blink and Webkit
> shipped this feature. http://caniuse.com/#feat=css-shapes
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendation: HTML 5.1

[Tantek Çelik]

For the record, I have reviewed the HTML5.1 changes:

https://www.w3.org/TR/2016/PR-html51-20160915/changes.html#changes

which are in themselves not the easiest to review, filed this accordingly:
https://github.com/w3c/html/issues/592

In addition to that editorial request, the one technically
objectionable change I found in HTML 5.1 is the re-addition of 'rev'.
I have commented on the issue that was used to add 'rev' back to HTML
5.1 accordingly with reasons for why that was a mistake (and should
have never happened - might be exposing process issues that I may have
to deal with separately)

https://github.com/w3c/html/issues/256#issuecomment-253674835

Other than that, I would re-emphasize Annevk's post:

https://annevankesteren.nl/2016/01/film-at-11

Which covers higher-level problems with HTML5.1, most of which are as
of yet unaddressed.

I believe this is sufficient to file a nonformal objection with those
two points (technical: drop rev, overall: HTML5.1 problematic as a
whole).

Thanks,

Tantek



On Thu, Oct 13, 2016 at 3:45 PM, L. David Baron  wrote:
> On Wednesday 2016-10-12 11:22 -0400, Chris Hutten-Czapski wrote:
>> Can you provide any details (either inline, or a sampling of links) to
>> summarize the broader concerns that might not be encapsulated in the
>> document itself?
>
> Some links:
> https://annevankesteren.nl/2016/01/film-at-11
> https://github.com/w3c/html/issues/507
>
> -David
>
>
>> On Mon, Oct 10, 2016 at 9:46 PM, L. David Baron  wrote:
>> > A W3C Proposed Recommendation is available for the membership of W3C
>> > (including Mozilla) to vote on, before it proceeds to the final
>> > stage of being a W3C Recomendation:
>> >
>> >   HTML 5.1
>> >   W3C TR draft: https://www.w3.org/TR/html/
>> >   W3C Editor's draft: https://w3c.github.io/html/
>> >   deadline: Thursday, October 13, 2016
>> >
>> > If there are comments you think Mozilla should send as part of the
>> > review, please say so in this thread.  (I'd note, however, that
>> > there have been many previous opportunities to make comments, so
>> > it's somewhat bad form to bring up fundamental issues for the first
>> > time at this stage.)
>> >
>> > Note that this specification is somewhat controversial for various
>> > reasons, mainly related to the forking of the specification from the
>> > WHATWG copy, the quality of the work done on it since the fork, and
>> > some of the particular modifications that have been made since that
>> > fork.
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web of Things Working Group

[Tantek Çelik]

On Wed, Oct 12, 2016 at 4:46 PM, Martin Thomson  wrote:
> On Thu, Oct 13, 2016 at 6:21 AM, Benjamin Francis  
> wrote:
>> Much more compelling is the member submission from EVRYTHNG which also forms
>> the basis of the book, Building the Web of Things.
>
> Yes, that is a much clearer articulation of a vision.  It starts going
> off the rails in a few places as it gets into specifics (MUST support
> all the basic HTTP verbs, WTF), but it is *much* more concrete.  I
> still don't know how to bridge the gap completely, particularly when
> it comes to things like identification and - dare I say it -
> discovery, but you can see a potential way forward at least.

Off the rails in a few places is being generous I think, but it's not
worth picking it apart with more specifics.

The one thing I will point out is the only mentions of "security" in
that member submission is some hand-waving about "just use HTTPS" and
then "may use other mechanisms" (paraphrasings).


Security is the number one problem for anything "ot" (iot, wot,
wotever), not just to the devices themselves, but frankly, to the web
and internet as a whole due to their potential deployment in numbers
that dwarf the number of existing devices. To not have that addressed
front and center IMO means they don't know what they're doing.


If you haven't been keeping up with KrebsOnSecurity in the past month,
I'll just reference these two for why:

https://krebsonsecurity.com/2016/09/krebsonsecurity-hit-with-record-ddos/
https://krebsonsecurity.com/2016/10/who-makes-the-iot-things-under-attack/


This entire industry area is fraught, and borderline being
irresponsibly developed, marketed, and deployed.

If you find anyone who claims to be successfully developing and
deploying secure IoT/WoT "devices" or "solutions", I'll leave you with
this (so far unanswered AFAIK) challenge:
http://tantek.com/2015/252/t1/wot-iot-security-expert-post-ip-appliances


All that being said, I think we should non-formally object to the
Proposed W3C Charter: Web of Things Working Group with reasons of:
* insufficient incubation of security aspects
* overall risk (greatly increased vulnerability) to the web/internet as a whole
being the reasons (with above citations).


Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Platform Working Group

[Tantek Çelik]

On Fri, Sep 30, 2016 at 12:51 PM, L. David Baron <dba...@dbaron.org> wrote:
> On Thursday 2016-09-29 07:46 -0700, Tantek Çelik wrote:
>> > Marked as deliverables to be taken up if incubation suggests likely 
>> > success:
>> >  Background Synchronisation; Filesystem API; FindText API; HTML Import; 
>> > Input Methods; Packaging; Quota API
>>
>> This section is confusing and weakly worded.
>>
>> Expanded just below this link:
>> https://www.w3.org/2016/08/web-platform-charter-draft.html#web-workers
>> as Potential deliverables (no id / fraglink)
>>
>> Either these are some sort of odd pre-incubation special treatment
>> (bad / unnecessary in a charter), or if this is a claim that the
>> listed specs *have* passed incubation, I'd expect citations that
>> document as such (not just a link to an intent template). Otherwise
>> wait for specs to pass incubation, document as such, and then propose
>> a charter update with actual (not "potential") deliverables.
>>
>> I'd prefer that these "Potential deliverables" be dropped (FO), unless
>> citations are provided to incubation successes, and if so, then just
>> make them "deliverables".
>
> I'm a little concerned about making this a formal objection.
> Rechartering is a somewhat painful process, and if a group thinks
> that a particular incubation project is likely to suceed in the near
> future and doesn't want to have to recharter again, it seems
> reasonable to allow them to say that they'd like the result of that
> incubation to be in their charter scope.

That reasoning works for me.

However:

> Or are these things that are just starting out rather than things
> that have been in progress for a while?  (That seems unlikely, since
> I've been hearing about some of them for quite a while.)

I don't know for each of the specific items, so I'm going to dig
deeper and see if I can determine their relative incubation maturity.
I too have been hearing about some of them for a while (e.g. BG sync).

I would have preferred that any such item come with a citation of a
specific "Intent to Migrate"[1] post with details for evaluation per
the WICG/WPWG's own processes but I'm not seeing any.

Also, just found this in the charter:
  announcement
Not really acceptable.

Tantek

[1] https://wicg.github.io/admin/intent-to-migrate.html

>
> -David
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Platform Working Group

[Tantek Çelik]

On Thu, Sep 29, 2016 at 8:07 AM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> On 9/29/16 10:46 AM, Tantek Çelik wrote:
>>>
>>> New deliverables:
>>>Microdata
>>
>>
>> This should be dropped from the charter (FO).
>>
>> Ironic to see this since Firefox (release!) just dropped support for
>> Microdata
>
>
> Are they talking about the HTML microdata API (what we dropped) or just
> specifying the HTML microdata attributes?  The latter seems fine as a
> deliverable, generally speaking.  The deliverable doesn't actually say what
> it's about.

All of what was previously abandoned. The charter
http://www.w3.org/2016/08/web-platform-charter-draft.html#deliverables
links to the 2013 Microdata Note.

"just specifying the HTML microdata attributes" seems like a waste of
time for a WG that already has lots of REC-track deliverables (and
sometimes shows a need for more focus, e.g. what happened with
5.1CR/PR vs what the current charter says about modularizing [1]).

Similarly, if there's anything else in the new charter that anyone
else thinks we should specifically cut (beyond "just cut it all"), I'm
interested in hearing about it. Cutting inessential things in this WG
will help with better focus and use of time / resources.

Tantek

[1] https://github.com/w3c/html/issues/507
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Platform Working Group

[Tantek Çelik]

Note the major changes summary:

https://www.w3.org/2016/08/web-platform-charter-draft.html#changes-from-wp1

This is my first pass review (already found problems).

I may try to review in more depth to see what (if any) specific
wording changes there are in the charter (is there a paragraph by
paragraph diff avaiable?)


> New deliverables:
>Microdata

This should be dropped from the charter (FO).

Ironic to see this since Firefox (release!) just dropped support for
Microdata (a form of incubation failure at the least), and last time
it was brought up in HTML WG, no one bothered to step up to edit it so
it got abandoned as a note (2013).


> Removed as deliverables:
>Streams; URL; XHR1

This seems good to me, and reflective of the reality of referencing
equivalent WHATWG specs, and increasingly positive culture towards
doing so.


> Marked as deliverables to be taken up if incubation suggests likely success:
>  Background Synchronisation; Filesystem API; FindText API; HTML Import; Input 
> Methods; Packaging; Quota API

This section is confusing and weakly worded.

Expanded just below this link:
https://www.w3.org/2016/08/web-platform-charter-draft.html#web-workers
as Potential deliverables (no id / fraglink)

Either these are some sort of odd pre-incubation special treatment
(bad / unnecessary in a charter), or if this is a claim that the
listed specs *have* passed incubation, I'd expect citations that
document as such (not just a link to an intent template). Otherwise
wait for specs to pass incubation, document as such, and then propose
a charter update with actual (not "potential") deliverables.

I'd prefer that these "Potential deliverables" be dropped (FO), unless
citations are provided to incubation successes, and if so, then just
make them "deliverables".

Tantek



On Wed, Sep 28, 2016 at 6:02 PM, L. David Baron  wrote:
> The W3C is proposing a revised charter for:
>
>   Web Platform Working Group (formerly Web Applications WG & HTML WG)
>   https://www.w3.org/2016/08/web-platform-charter-draft.html
>   https://lists.w3.org/Archives/Public/public-new-work/2016Sep/0001.html
>
> Mozilla has the opportunity to send comments or objections through
> this Friday, September 30.
>
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it.
>
> -David
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Canvas CSS/SVG filters

[Tantek Çelik]

Awesome and congrats Tobias! -tantek

On Thu, May 26, 2016 at 9:40 AM, Tobias Schneider
 wrote:
> I intend to turn Canvas CSS/SVG filters on by default on all platforms. It
> has been developed behind the canvas.filters.enabled preference. Google's
> Chrome is already shipping this in version 52.
>
> Related bugs:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=927892
> https://bugzilla.mozilla.org/show_bug.cgi?id=1173545
>
> Specification:
>
> https://html.spec.whatwg.org/multipage/scripting.html#dom-context-2d-filter
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove:

[Tantek Çelik]

Agreed.

Henri, is there a particular release you plan to "unship" this for? -t


On Tue, Apr 26, 2016 at 7:42 AM, Boris Zbarsky  wrote:
> I think removing this is reasonable at this point
>
> -Boris
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship: HTML5 and tags

[Tantek Çelik]

On Tue, Apr 19, 2016 at 12:00 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> On 4/19/16 2:44 PM, Tantek Çelik wrote:
>>
>> The key question to consider about delaying |summary::marker| support
>> is whether or not we (e.g. you) think the spec for ::marker is
>> "stable" and "good" enough to ship.
>
>
> The key question before that one is whether we want to block shipping
> details and summary on the entirety of ::marker support.  Because we do NOT
> want to ship parsing for ::marker while only supporting it for summary and
> not in general

Agreed. I'm assuming that our current ::-moz-list-bullet support (as
noted previously) does not (yet?) implement what we'd need for the
entirety of ::marker support.

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship: HTML5 and tags

[Tantek Çelik]

On Tue, Apr 19, 2016 at 8:41 AM, Ting-Yu Lin  wrote:
> To summarize the feedback so far, I'd still like to ship  and
>  without |summary::marker| because
>
> 1) No other browsers support summary::marker yet.

This is a reason to ship *with* it IMO, per showing standards
leadership, something Firefox is known for, leading the open (rather
than prefixed) web and all that.


> 2) From the webcompat point of view, even if we support summary::marker,
> our usage to customize the triangle will still be different from the
> |summary::-webkit-details-marker| usage on Blink/Webkit. So implementing
> ::marker does not solve the webcompat issue.

This is a normal transition phase in the path towards developers using
standards-based properties (border-radius etc. history has plenty of
examples). Not a reason not to ship.


> 3) The marker (triangle) is still stylable without |summary::marker|.
> Author could change the triangle via |summary { list-style-type: xxx}| or
> use pseudo element |summary::-moz-list-bullet| to add more css rules.

It's good that we have a prefixed alternative (that does not depend on
someone else's prefix).


The key question to consider about delaying |summary::marker| support
is whether or not we (e.g. you) think the spec for ::marker is
"stable" and "good" enough to ship.

That's a judgment call, and I'd like to know your opinion of that.

> Ting-Yu

Thanks,

Tantek


> On Thu, Apr 14, 2016 at 3:53 PM, Ting-Yu Lin  wrote:
>
>> As of Firefox 48 I intent to ship HTML5  and  tags on
>> all platforms.  The features has been developed behind pref
>> "dom.details_element.enabled", and had been enabled on non-release build in 
>> bug
>> 1241750 
>>
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=ship-details-summary
>> Link to standard:
>> https://html.spec.whatwg.org/multipage/forms.html#the-details-element
>>
>> This feature was previously discussed in this "intent to implement" thread:
>>
>> https://groups.google.com/d/msg/mozilla.dev.platform/b0UMDIasfq8/tW49QLgCBwAJ
>>
>> One major concern in the "intent to implement" discussion is the ability
>> to style the summary disclosure triangle.  Currently summary has default
>> style "display: list-item", so we can style the triangle via the pseudo
>> element |summary::-moz-list-bullet| like |li::-moz-list-bullet|.
>>
>> The open question is that do we want to make it prefect to implement
>> |summary::marker| (Bug 1221416
>> ) before shipping,
>> which requires more effort to implement a complete support for ::marker
>> pseudo element (Bug 205202
>> ). If not, we can
>> ship it in Firefox 48. Otherwise this feature might skip one or two
>> releases.
>>
>> Please give me some feedbacks. Thanks.
>>
>> Ting-Yu Lin (:TYLin)
>>
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

[Tantek Çelik]

Daniel, Mike, and the whole compat team, thank you for diligently
figuring out all the nasty details here and pushing this contentious
"feature" forward.

This is a tough balance for the good of our users, and I'm grateful
for all the thought and careful consideration you have put into it.

We noted a high level intent to consider doing this at the CSSWG f2f
nearly two years ago, and as this lands I'm sure it will come up again
at the next f2f. dbaron and I will be there to support your work.

Tantek


On Thu, Dec 31, 2015 at 12:40 AM, Jonas Sicking  wrote:
> Yay!
>
> (I agree that it's sad that we need to do this, but still "yay" for
> being more compatible with the web).
>
> / Jonas
>
> On Wed, Dec 30, 2015 at 10:40 PM, Daniel Holbert  wrote:
>> Summary:
>>   A good chunk of the web today (and particularly the mobile web)
>> effectively relies on -webkit prefixed CSS properties & features. We
>> wish we lived in a world where web content always included
>> standards-based fallback (or at least multiple-vendor-prefixed
>> fallback), but alas, we do not live in that world.  To be successful at
>> rendering the web as it exists, we need to add support for a list of
>> frequently-used -webkit prefixed CSS properties & features.
>>   Every other major modern browser engine implements support for these
>> aliases -- Blink & WebKit obviously have them, & Edge includes them for
>> compatibility.  (I'm not sure about IE's support, but it's not a
>> particularly important data point, given that Microsoft is focused on
>> Edge going forward.)
>>
>> Bug tracking implementation:
>>  https://bugzilla.mozilla.org/show_bug.cgi?id=1170789
>>
>> Bug to enable pref:
>>  https://bugzilla.mozilla.org/show_bug.cgi?id=1143147
>>  (Will likely land in the next few days.)
>>
>> Link to standard:
>>   Mike Taylor is working on a WHATWG spec describing the -webkit
>> prefixed features that we believe are needed for web compatibility.
>> That spec lives here: http://compat.spec.whatwg.org/
>>   There's also been some discussion on the CSSWG mailing list about
>> updating official CSS specs to mention legacy -webkit aliases (and
>> discourage authors from using them), as discussed in this thread:
>> https://lists.w3.org/Archives/Public/www-style/2015Dec/0132.html
>>
>> Platform coverage:
>>   All platforms.
>>
>> Estimated or target release:
>>   Firefox 46 (current Nightly), or 47 if we need to hold it back a
>> release to fix things.
>>
>> Preference behind which this will be implemented:
>>   layout.css.prefixes.webkit
>>
>> Side note on earlier work:
>>   Earlier this year, in bug 1107378, we shipped an experimental JS-based
>> version of this feature, which was only active for a whitelist of sites
>> (all of which strongly depend on webkit prefixes for usability). This
>> experiment proved successful at making the whitelisted sites usable in
>> Firefox.  The new implementation (behind "layout.css.prefixes.webkit")
>> will supersede the older experimental JS-based implementation and will
>> not be whitelisted.
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charters: Web Platform and Timed Media Working Groups

[Tantek Çelik]

 you can bet that
many eyes will be watching for such behavior.

Note also that since the past HTMLWGs disruptions, the W3C has adopted more
anti-trolling type policies like their PWE (Positive Work Environment)
policy.

In short, chairs have more tools today to kick out disruptors quickly than
they have in the past.



If an answer to the above is not already documented in public in a way
> that allows the W3C to be held to their word, I think we should ask
> about the above in our charter review comments.
>
> This charter includes the maintenance responsibility for a number of
> specs related to Widgets. Is this just a formality that pre-existing
> specs have to belong to *some* WG or is the group actually expected to
> spend time on maintaining Widgets? Does any vendor that can reasonably
> be expected to contribute staff time to the WG actually ship W3C
> Widgets or want to shift from whatever packaged Web app solution they
> do ship to W3C Widgets? It seems like a bad idea to put the group's
> time into Widgets if isn't the future we intend to pursue and, AFAICT,
> it isn't.
>

That's a good observation.

Shall we object to Widgets as a deliverable and ask for it to be dropped?




> On Mon, Aug 10, 2015 at 1:28 PM, Gervase Markham <g...@mozilla.org> wrote:
> > On 09/08/15 19:59, L. David Baron wrote:
> >> The Timed Media WG splits some of the media work that was happening
> >> in HTML (MSE, EME) into a separate group.
> >
> > Do we see a risk here that this group will become captured by the
> > promoters of DRM, more than was possible when it was done in the HTML WG?
>
> I think moving EME into a group of its own would carry a major risk of
> the group finding other DRM things to work on in order to perpetuate
> its own existence. That's why I've cautioned against kicking EME out
> of the HTML WG.
>
> Since the proposed WG is not a DRM WG but the media WG with
> substantial non-DRM work to do, I'm somewhat less worried about this
> proposed WG than I would be about an EME-only WG.
>

Agreed.


As noted above, the media TF has already been operating relatively
> separately. In that sense, this split doesn't involve much of a change
> in terms of who subscribes to which mailing list and who follows which
> meeting minutes. However, I don't see any benefit from having a Timed
> Media Working Group compared to having a Timed Media Task Force of the
> Web Platform Working Group and I can see potential for the separate
> working group to have a downside.
>
> The proposed Web Platform Working Group covers so many things that
> it's obvious that no single participant is going to participate in the
> development of all the deliverables. In that context, I think it's
> weird to split MSE, EME and the / parts of HTML5
> maintenance into a separate WG.
>

My understanding is that there is an intent to continuing splitting off
more such work, it's just that this was the first chunk that made sense to
split off.


I think it would be reasonable for us to record a comment along the
> lines of the above paragraph and have Media as a TF of Platform.
>

Other opinions on this?

I don't have a strong opinion about splitting media off as a separate WG or
keeping it as a TF of Web Platform.

Henri, if you want to write up a summary comment about Media TF vs WG to
submit as part of the charter review, we can include that in our charter
response as well.


Thanks,

Tantek Çelik
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: CSS and SVG filters for canvas 2D

[Tantek Çelik]

Just to keep this thread moving forward:

On Tue, Jun 16, 2015 at 2:35 AM, Markus Stange msta...@themasta.com wrote:

 On 2015-06-15 8:15 PM, Robert O'Callahan wrote:

 On Tue, Jun 16, 2015 at 11:23 AM, Robert O'Callahan rob...@ocallahan.org
 
 wrote:

 I think we're not quite there yet, but we're very close. There are two
 things I want before we ship:
 -- Get normative spec text up somewhere.
 -- Get a signal from some other browser vendor that they're OK with this
 feature. That no-one objected in WHATWG is a good sign. I've reached out
 to
 a Blnk danvas dev for a slightly stronger signal.


 I got a reply from that Blink dev saying that they want this feature, want
 to implement it soon, and just need spec text.


We're documenting our spec text for CanvasFilters on the Mozilla wiki for
now:

https://wiki.mozilla.org/CanvasFilters

Please feel free to edit with issues / questions inline.

Thanks!

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linked Data must die. (was: Linked Data and a new Browser API event)

[Tantek Çelik]

Great discussion and feedback in this thread - plenty to act on.

Thanks Ted Clancy for kicking this off with an impassioned reality
check. And Thanks in particular to Benjamin Francis for summarizing
product requirements and use-cases, and especially to both Ted and Ben
taking the time last week in Whistler to discuss all of this in person
- I definitely came away with a better understanding of the data,
problem space, and perspectives for Gaia's use-cases. I've also
followed up with Gregor and jst to broaden and double-check my
understanding and possible paths forward.


tl;dr: It's time. Let's land microformats parsing support in Gecko as
a Q3 Platform deliverable that Gaia can use.


Specifically:

On Mon, Jun 29, 2015 at 2:47 PM, Benjamin Francis bfran...@mozilla.com wrote:
 Thanks for the responses,

 Let me reiterate the Product requirements:

1. Support for a syntax and vocabulary already in wide use on the web to
allow the creation of cards for the largest possible volume of existing
pinnable content

I think there's rough consensus that a subset of OG, as described by
Ted, satisfies this. Minimizing our exposure to OG (including Twitter
Cards) is ideal for a number of reasons (backcompat/proprietary
maintenance etc.).


2. Support for a syntax with a large enough and/or extensible vocabulary
to allow cards to be created for all the types of pinnable content and
associated actions we need in Gaia

There appear to be multiple options for this, with the best (most
open, aligned with our mission, already open source interoperably
implemented, etc.) being microformats.

On that in particular:


 *Gaia Content*

 Open Graph does not have a large enough vocabulary, or (as Kelly says) the
 ability to associate actions with content, needed for the second requirement

The associate actions with content use-case is an interesting one
that's worthy of more specific follow-up on Kelly's response. More on
that separately.


 Schema.org has a large existing vocabulary which basically
 fulfils these use cases, though some parts are more tested than others,

fulfils mostly in theory. Schema is 99% overdesigned and
aspirational, most objects and properties not showing up anywhere even
in search results (except generic testing tools perhaps).

A small handful of Schema objects and subset of properties are
actually implemented by anyone in anything user-facing.

Everything else is untested, and claiming fulfils these use cases
puts far too much faith in a company known for abandoning their
overdesigned efforts (APIs, vocabularies, syntaxes!) every few years.
Google Base / gData / etc. likely fulfilled these use cases too.


 with examples given in Microdata, RDFa and JSON-LD syntaxes, eg:

- Contact - http://schema.org/Person
- Event - http://schema.org/Event
- Photo - http://schema.org/Photograph
- Song - http://schema.org/MusicRecording
- Video - http://schema.org/VideoObject
- Radio station - http://schema.org/RadioChannel
- Email - http://schema.org/EmailMessage
- Message - http://schema.org/Comment

This explicit list of use-cases is very helpful.

Existing interoperably implemented microformats support most of these:

- Contact - http://microformats.org/wiki/h-card
- Event - http://microformats.org/wiki/h-event
- Photo - http://microformats.org/wiki/h-entry with u-photo property
- Song - no current vocabulary - classic hAudio vocabulary could be
simplified for this
- Video - http://microformats.org/wiki/h-entry with u-video property
- Radio station - no current vocabulary - worth researching with
schema RadioChannel as input
- Email - http://microformats.org/wiki/h-entry with u-in-reply-to property
- Message - http://microformats.org/wiki/h-entry

For Song and Radio Station in particular - I will take the action of
bringing these use-cases to the microformats community and see what
the community can come up with, and how quickly. Discussion will be on
#microformats on Freenode (archived, see microformats.org/wiki/irc) if
anyone wants to contribute or just lurk.


 Schema.org also provides existing schemas for actions associated with items
 (https://schema.org/docs/actions.html),

The actions space has been a difficult and challenging one.

Google's (abandoned) web intents was one such effort.

Currently the IndieWeb community is pursuing Web Actions (and has them
working across sites)

http://indiewebcamp.com/webactions

There's likely potential there to connect webactions to be part of the
format of the post/page to be parsed, consumed, re-used.

Again, this is something I'll take to the #microformats community and
we can see what people there come up with.


 although examples are only given in
 JSON-LD syntax. Schema.org is just a vocabulary and Tantek tells me it's
 theoretically possible to express this vocabulary in Microformats syntax
 too - it's possible to create new vendor prefixed types, or suggest new
 standard types to be added to the 

Re: Linked Data and a new Browser API event

[Tantek Çelik]

Gordan has the right general idea to approaching this problem space.

On Mon, Jun 1, 2015 at 5:42 PM, Gordon Brander gbran...@mozilla.com wrote:
 On June 1, 2015 at 17:34:48 , Jonas Sicking (jo...@sicking.cc) wrote:
 I think we're already talking about reverse-engineering what search
 engines and twitter/facebook/etc do.

The summary among all the myriad proprietary (read: single corp /
oligopoly controlled) proposals is that Facebook OGP meta tags have a
strong lead over all the other proprietary approaches (for various
reasons we can get into offline if desired), while among the open
standards community options - i.e. per Mozilla open web principles,
microformats have the lead.


 But I'm still all for proper standardization. Including driving
 towards good technical solutions.

 Yup. We’re really talking about 2 things in parallel:

 1. Defining a standards-based approach to marking these things up (using 
 pre-existing patterns where it makes sense). Encouraging authors to use it.

 2. Creating internal APIs that will leverage this metadata, and in cases 
 where the standards-based metadata does not exist, scraping reasonable 
 results from other common metadata or markup patterns.

This analysis and conclusion matches what we've been figuring out with
implementations and deployments in the IndieWebCamp community as well
(which has several use-cases similar to pins/cards for providing
summaries/link-previews of pages on the web). In short, the general
approach involves parsing for two general sets of published data /
markup:

1. Pragmatic parsing of what's most out there:
  a) according to anecdotal sampling by the indieweb community,
Facebook OGP, and
  b) according to studies / open/common crawl datasets: classic microformats

2. Simplest open standards based approach (so we can recommend the
easiest, least work, and most openly developed/maintained approach to
authors and site owners) - microformats2.

I'm happy to provide citations/specs for these, as well as follow-up
on any detailed questions.

Thanks,

Tantek Çelik
Web Standards Lead
Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: document.execCommand(cut/copy)

[Tantek Çelik]

On Wed, May 6, 2015 at 4:17 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
 On Tue, May 5, 2015 at 7:34 PM, Tantek Çelik tan...@cs.stanford.edu wrote:

 On Wed, May 6, 2015 at 12:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
 wrote:
  On 2015-05-05 6:31 PM, Daniel Holbert wrote:
 
  On 05/05/2015 02:51 PM, Ehsan Akhgari wrote:
 
  Sites such as Github currently use Flash in order to
  allow people to copy text to the clipboard by clicking a button in
  their
  UI.

 First, this is awesome and can't wait to try it out.

 Second, cut is potentially destructive to user data, have you
 considered enabling this only for secure connections? Either way it
 would be good to know the reasoning behind your decision.


 Hmm, what would that prevent against though?  A web page could just use the
 normal DOM APIs to destroy the user data (e.g., something like the contents
 of a blog post the user is writing in a blogging web app).  Is this what you
 had in mind?

Sorry I wasn't clear.  *Both* cut and copy have the impact of
*clearing* the previous clipboard data (on typical platforms).

Thus if the user had say, cut a bunch of text from another application
(like a text editor), and then switched to a browser window, gotten
distracted and clicked something, it is *possible* the page could
select text, do a cut/copy, and blow away that bunch of text from the
other application.

Result: loss of user data that user had put into the clipboard
previously. This isn't possible with current DOM APIs and is a new
vulnerability introduced by cut/copy.

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: document.execCommand(cut/copy)

[Tantek Çelik]

On Wed, May 6, 2015 at 10:51 AM, Gervase Markham g...@mozilla.org wrote:
 On 06/05/15 08:00, Tantek Çelik wrote:
 Result: loss of user data that user had put into the clipboard
 previously. This isn't possible with current DOM APIs and is a new
 vulnerability introduced by cut/copy.

 Given that most text-editing applications have undo (if you used cut
 originally),

^^^ desktop assumption.

Most (nearly all?) text editing applications and/or applications with
editable text fields on *mobile* DO NOT have undo.


 this strikes me as a low-level web page annoyance on a par
 with auto-playing irritating music.

^^^ disagreed - no data loss with auto-playing irritating music, just
potential embarrassment / emotional annoyance.


 Although perhaps a little less
 discoverable as to the cause.

Very. Also the silent nature of this vulnerability means user might
not notice until long after damage is done.


 I doubt this will be an issue in practice

Perhaps. I might conclude similarly, yet I thought this was worth
raising as possible justification for enabling only in secure
connections.

Also this is a good concrete test-case of our blog post and indication
of direction re: features and secured connections.


 - as the page doesn't get to see the data its deleting, doing so would
 be pure vandalism, not worthy of an attacker who was trying to actually
 accomplish something.

Not pure vandalism. The user data loss is a side-effect of other incentives.

E.g. trivial attacker incentive: all those share-button-happy
news/media sites are likely to auto-copy URL + title of an article
you're reading when you do any user interaction with the article, in
the hopes that maybe you might paste the URL into an IM or email etc.
and send them some more traffic (given how much they annoyingly
sacrifice performance and page load/scroll speed with all their
like/+1/share/addthis etc. buttons, I see no reason to expect any
different behavior with this feature).

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: document.execCommand(cut/copy)

[Tantek Çelik]

On Thu, May 7, 2015 at 12:08 AM, Martin Thomson m...@mozilla.com wrote:
 On Wed, May 6, 2015 at 11:55 AM, Adam Roach a...@mozilla.com wrote:
 Keep in mind the thesis of that plan isn't that we restrict
 security-sensitive features to https -- it's that /all new stuff/ is
 restricted to https. If this falls under the definition of a new feature,
 and if it's going to be released after the embargo date, then the security
 properties of clipboard manipulation don't really enter into the evaluation.

 This is perhaps a little early to be applying that rule, since we
 haven't really gotten far with the discussion with other browser
 vendors yet (though we've had some preliminary discussions).

 I think that this is a great example of a feature that we could use to
 test out the process for applying the policy.

I think this is the strongest argument for doing this.


 Though I can understand
 why there might be some resistance, we don't find out much if we don't
 ask.

Precisely.

The upside: we try out aspects of our proposed policy with very little risk.

The possible downside: we get negative feedback from developers, and
end up delaying the broader support (whether http or other fewer
restrictions) by one release. Given how long people have already
waited for this, is this potential delay really that harmful?
Especially in exchange for the upside.


 I'm going to propose that we at least raise the question with other
 browsers about restricting this feature to secure contexts.

This is a reasonable next step.

 The
 answer might help inform us on whether pursuing the deprecation plan
 as outlined is feasible.

Exactly, we get to start trying out parts of the plan at relatively
low risk. Like a drill of sorts.

 Like Anne, I think that the benefit is
 tangible to HTTPS-only, even it is small.

Based on the arguments presented in this thread, I have been convinced
of this too (tangible but small).

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: document.execCommand(cut/copy)

[Tantek Çelik]

On Wed, May 6, 2015 at 5:49 PM, Martin Thomson m...@mozilla.com wrote:
 On Wed, May 6, 2015 at 8:42 AM, Doug Turner do...@mozilla.com wrote:
 This is important.  We could mitigate by requiring https, only allowing the 
 top level document access these clipboard apis,

Thanks Doug. I think your first two suggestions are an excellent start.

Since we have no legacy to deal with, we can start conservative, and
wait for web developer feedback, and iterate accordingly. Thus, straw
proposal, let's use your first two:

* mitigate by requiring https
* only allowing the top level document access these clipboard apis

And then if developers complain about either of these restrictions in
practice, then hopefully they'll come with specific use-cases for us
to consider.


 and doorhangering the API.  Thoughts?

 A doorhanger seems like overkill here.

Agreed.


  Making this conditional on an
 engagement gesture seems about right.

Agreed on that too.


 I don't believe that we
 should be worry about surfing - and interacting with - strange sites
 while there is something precious on the clipboard.

Having lost clipboard data personally - I think this is an actual issue.


 Ask forgiveness, not permission seems about the right balance here.

I'd phrase it in a more user-centric manner, that is, a user interface
should be forgiving of user mistakes, rather than asking permission.

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: document.execCommand(cut/copy)

[Tantek Çelik]

On Wed, May 6, 2015 at 12:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
 On 2015-05-05 6:31 PM, Daniel Holbert wrote:

 On 05/05/2015 02:51 PM, Ehsan Akhgari wrote:

 Sites such as Github currently use Flash in order to
 allow people to copy text to the clipboard by clicking a button in their
 UI.

First, this is awesome and can't wait to try it out.

Second, cut is potentially destructive to user data, have you
considered enabling this only for secure connections? Either way it
would be good to know the reasoning behind your decision.

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to change UA stylesheet of abbr and acronym (using border-bottom - CSS 3 text-decoration)

[Tantek Çelik]

On Wed, Apr 22, 2015 at 2:13 AM, Masayuki Nakano masay...@d-toybox.com wrote:
 HTML5 spec suggests the style of abbr and acronym is:

 abbr[title], acronym[title] { text-decoration: dotted underline; }
 http://www.w3.org/TR/html5/rendering.html#phrasing-content-0

 However, we still use:
 abbr[title], acronym[title] { border-block-end: dotted 1px; }

 Our style has trouble with some fonts which have large internal leading
 and/or external leading (e.g., Meiryo, new Japanese font on Windows Vista or
 later). With such fonts, the border-bottom is rendered too far from the
 glyphs and may overlap with the next line.

 Therefore, we should use the suggested style.

Agreed. The dotted border was used originally to fake that kind of
text-decoration effect, so now that we have the actual desired
feature/effect, we should use it.

 Blink uses same style as our current style. IE doesn't have any special
 style for them (i.e., rendered like simple span).

Note also that CSS3 Text Decoration (non-normatively) specifies that
updated styling of abbr and acronym:

http://www.w3.org/TR/css-text-decor-3/#default-stylesheet

Thus we can cite that as well for our change.

Thanks,

Tantek

 The bug to change the style:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1157083

 --
 Masayuki Nakano masay...@d-toybox.com
 Manager, Internationalization, Mozilla Japan.
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[meta] Intent to implement and Security Privacy concerns

[Tantek Çelik]

One of the suggested additions to intent to implement emails:

https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement

is a statement regarding Security  Privacy concerns, because those
have often been noted as brief summary statements in some past intent
to implement emails.

There has been some discussion among various W3C/TAG etc. folks of
adding a security self-review to W3C specifications, based on this
strawman list of questions to answer (e.g. perhaps informatively in a
section in a spec)

https://mikewest.github.io/spec-questionnaire/security-privacy/

Until specs start publishing their answers to these security/privacy
questions, should we consider doing so at least as part of Intent to
implement?

Thoughts?

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [meta] Intent to implement - captured some docs on wikimo

[Tantek Çelik]

Having pages go out of date can certainly be a challenge, hence why
this wiki page is descriptive (citing historical examples and other
external resources), rather than prescriptive.

No additional risk of becoming out of date beyond that from already
existing pages. It's a general good practice to write wiki-pages in
such a future-defensive way.

I'll also add a note about any questions about intent to ... should
go to dev-platform to provide direction should anything actually go
out of date and someone is potentially confused.

Thanks,

Tantek

On Tue, Mar 31, 2015 at 3:10 PM, Jonas Sicking jo...@sicking.cc wrote:
 Will someone be maintaining this page? I'm worried that having an
 out-of-date page might create more confusion than information.

 / Jonas

 On Tue, Mar 31, 2015 at 3:58 AM, Tantek Çelik tan...@cs.stanford.edu wrote:
 Having followed the Intent to implement emails for a while, and
 noticing that there was already an email template for it on wikimo:

 https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement


 I went ahead and wrote up a page about this practice, along with links
 to Blink/MS equivalents:

 https://wiki.mozilla.org/Intent_to_implement

 Hopefully others find this useful.

 Feedback and as usual, direct edits/contribution to the page welcome
 and encouraged.

 Thanks,

 Tantek
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship: CSS Scroll Snapping on Desktop

[Tantek Çelik]

From the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1138658

This will be on by default in 39 right?

Do we have any nice example pages to show it off?

Being able to use CSS Snap Points has also come up in recent
#indiewebcamp discussions, so FWIW, there are also independent web
developers who are ready and eager to implement this on their own
websites as well, in case you're looking for examples for your hacks
blog post.

Thanks,

Tantek

On Mon, Mar 16, 2015 at 3:34 PM, Robert O'Callahan rob...@ocallahan.org wrote:
 On Tue, Mar 17, 2015 at 11:07 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
 wrote:

 Is this feature worth having a hacks blog post about?  (hint: I think so!)


 Yes!

 Rob
 --
 oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
 owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
 osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
 owohooo
 osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o'oRoaocoao,o'o
 oioso
 oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
 owohooo
 osoaoyoso,o o'oYooouo ofolo!o'o owoiololo oboeo oiono odoaonogoeoro
 ooofo
 otohoeo ofoioroeo ooofo ohoeololo.
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[meta] Intent to implement - captured some docs on wikimo

[Tantek Çelik]

Having followed the Intent to implement emails for a while, and
noticing that there was already an email template for it on wikimo:

https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement


I went ahead and wrote up a page about this practice, along with links
to Blink/MS equivalents:

https://wiki.mozilla.org/Intent_to_implement

Hopefully others find this useful.

Feedback and as usual, direct edits/contribution to the page welcome
and encouraged.

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Tantek Çelik]

FWIW I am for the original set of HTTPS only restrictions proposed by Anne.

I think doing so sends a strong security minded message, even if some
think too strong.

Pop-ups:

I realize including pop-ups in this is a minority opinion (judging by
this thread), however, I have not seen a single concrete example by
those defending pop-ups of an HTTP-only site that depends on pop-ups
for functionality for which this change would inconvenience the user.

I am for including pop-ups in this set, at least up to Aurora to test
the hypothesis that others have offered that this would annoy users,
because frankly, I don't believe it in practice.

Notifications:

For notifications, Anne's argument is correct. They're not widely
adopted yet, so now is a good time to place this restriction on them,
when there is very little of site-breakage risk. If there is
real-world author/developer demand for INSECURE access to web
notifications, we can re-evaluate accordingly.

Blog post:

In addition, as part of landing these restrictions, I think a blog
post by Anne (e.g. perhaps on hacks.mo) on these changes would show
and demonstrate Mozilla's user-security focus and technical
leadership.

Such a blog post could also explicitly note that we do see a spectrum
of differences between things as invasive/creepy as camera access vs.
just annoying pop-ups  notifications, and that based on user and
developer feedback we may adjust our implementation accordingly.

Better to secure more things, and then only back-off if/when necessary.

Thanks,

Tantek


On Mon, Mar 9, 2015 at 2:07 AM, Anne van Kesteren ann...@annevk.nl wrote:
 Thanks everyone for weighing in. It sounds like we don't want to touch
 popups :-) And yes, negative persistence (never allow) should remain
 available.

 The Notifications API is a bit in flux and the most interesting
 notifications require service workers so are already restricted. I
 guess I'm okay with leaving them alone for now.

 On Fri, Mar 6, 2015 at 7:04 PM, Gijs Kruitbosch
 gijskruitbo...@gmail.com wrote:
 Can we make an exception for localhost and its IPv4 and IPv6 equivalents to
 make things easier for web devs? Bonus points if we make a mechanism that
 detects /etc/host overrides (to localhost) and allow it there, too.

 I think the exceptions of the powerful features document are
 localhost, equivalent hostnames (I can't think of any), and file
 URLs. Developer tools should provide overrides. We need overrides for
 service workers too.


 --
 https://annevankesteren.nl/
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS display:contents

[Tantek Çelik]

I'll rephrase Paul Irish's excellent question.

Rather than an email to be lost in archives, could you provide a URL
to a wiki page where the web designer / developer use-cases for
display:contents are documented, e.g. one use-case per section?

If not, I'm happy to ask the CSSWG myself.

Tantek


On Mon, Feb 2, 2015 at 11:27 AM,  paul.ir...@gmail.com wrote:
 Hey Mats, the use cases are not obvious to me, but I didn't follow the 
 original www-style threads on this so I'm lacking context. (A the spec 
 doesn't help either)

 Can you help explain why a developer would use `display:contents`?

 I think it'd help to have it described a bit. Thanks!
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship FormData on workers

[Tantek Çelik]

On Fri, Jan 30, 2015 at 7:13 AM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 1/30/15 1:30 AM, nsm.nik...@gmail.com wrote:

 Well my work on getting FormData on workers was because Fetch uses it, and
 there doesn't seem to have been demand for it on workers before.


 That's fair, but it seems like exposing it separately, if it's going to be
 ready before the rest of Fetch, reduces the risks and doesn't have much in
 the way of downsides that I see.

Yes it makes sense to expose a building block that Fetch uses, before
exposing Fetch.

 If there are no compat issues, I'm happy to just ship it.


 I can't think of obvious compat issues here offhand.

Same here. +1 no pref.

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Documenting uses of Github at Mozilla

[Tantek Çelik]

Since all these repo links are likely to become unfindable in email...

Contributions welcome: https://wiki.mozilla.org/Github

Thanks,

Tantek


On Thu, Oct 2, 2014 at 12:46 PM, Mike Hoye mh...@mozilla.com wrote:
 On 2014-10-01 12:16 PM, Ehsan Akhgari wrote:

 On 2014-10-01, 11:59 AM, Ralph Giles wrote:

 On 2014-10-01 7:17 AM, Mike Hoye wrote:

 Having to scramble to recover from data loss - particularly around
 source or bug tracking - is a miserable experience we should try to
 avoid.


 Perhaps http://gitmirror.mozilla.org/ should be our project directory.


 That is a great idea!


 There's a proposal to decommission gitmirror.m.o. in

 https://bugzilla.mozilla.org/show_bug.cgi?id=910040

 ... in favor of git.m.o for major projects. I've made the case there that
 instead, we should keep it as an automated index of tier-2 GitHub repos
 and cc'ed Ehsan and Ralph on it, for initiating this discussion and issuing
 the first pull request to the old updater script respectively.

 - mhoye

 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendation: HTML5

[Tantek Çelik]

Specifically on the subject of what URL spec to reference, I think it
should be Mozilla's position (which I'm willing to represent) that the
W3C HTML5 spec reference the dated URL spec[1] instead of the
copy/paste/modified(even if informatively) W3C WebApps URL spec.

[1] https://whatwg.org/specs/url/2014-07-30/

I'd like to make this proposal on public-html (since I'm still at
least somewhat participating in  W3C HTMLWG) by Wednesday unless there
are objections from Mozilla folks on this thread (which I expect 2
days sufficient to resolve).

Usually I'd just go ahead with this proposal, but given the diversity
of opinions on this thread, figured I'd see what folks here thought
first.

Regardless, I support providing that same feedback in our response to
the W3C HTML5 PR.

Thanks,

Tantek


On Mon, Sep 22, 2014 at 10:53 AM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 9/22/14, 1:18 PM, James Graham wrote:

 I think you'd get a better result by asking for agreement from all the
 relevant implementors that they felt that the spec was implementable.


 The problem was that in some cases this was more a less a non-goal (in some
 cases an anti-goal) for the spec editor.  Hence the process bit to somewhat
 force them to deal with the issue.  :(

 Of course in reality, if someone ships something that exposes their
 internals and content comes to depend on it, everyone else is forced to
 copy that behaviour anyway, with as much fidelity as they can.


 Yes, true.

 Specs are only helpful here in the face of good actors.


 And in making it clear when people are being bad actors, yes.

 As we both know, it's not unheard of for
 people to follow enough process to get their stuff to Rec. with two
 interoperable implementations, and gaping holes in the spec.


 Indeed.

 Note that actually sanely testing something like navigation in
 non-browser-specific ways is ... hard.  Basic things like open a
 cross-origin window and wait for it to load aren't really possible.  :(


 Using window.open(http://some.cross.origin.url;), you mean? Couldn't
 you put a postMessage() in the load event of the opened document?


 You can in some cases.  In other cases (like when you're testing the nulling
 out of window.opener by callers to disconnnect the callee from them, or
 testing opening of sandboxed things that shouldn't be allowed to run script)
 this is not an option.

 It requires your test to go async


 You need that anyway for window.open, so that's not an issue.

 and depends on how precise your needs are of course.


 Right.

 There is a hope that over time we can address more use cases that need
 access to privileged APIs. There is a work in progress that will allow
 using WebDriver from test cases, for example. It's not clear that this
 will allow us to meet all needs, but it should make a difference in some
 cases.


 Yeah, I'm very much looking forward to this.

 https://critic.hoppipolla.co.uk/r/282


 Thank you.  This is definitely something we should find time to review


 -Boris

 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform