Re: Proposed W3C Charter: Verifiable Claims Working Group

[L. David Baron]

OK, I sent the response far enough before the deadline (which is
Sunday January 15) that other W3C members may have a chance to see
it before the deadline:
https://lists.w3.org/Archives/Public/public-new-work/2016Dec/0010.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)


signature.asc
Description: PGP signature
___
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) implementations on tens of thousands of we

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

[Karl Dubost]

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.

> 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, but the best practices which are given into the document are 
quite good, well articulated, with a nice regular template for each best 
practice. It's easy to read and easy to use. And one is basically free to 
pick-up the elements that will improve his/her data collections for sharing. 

-- 
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

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

W3C Proposed Recommendation: Data on the Web Best Practices

[L. David Baron]

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:

  Data on the Web Best Practices
  https://www.w3.org/TR/dwbp/
  http://w3c.github.io/dwbp/bp.html
  Deadline for responses: Sunday, January 15, 2017

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.)

My inclination is to abstain from this review, but could probably be
convinced to send other forms of supportive response.

-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)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Verifiable Claims Working Group

[Eric Rescorla]

On Wed, Dec 28, 2016 at 3:52 PM, L. David Baron  wrote:

> Here's an attempt to write up comments to submit on this charter.
> I'm not sure I understood ekr's reply to mt, though.  So corrections
> and clarifications are certainly welcome.
>
> Sorry for the delay circling back to this.
>
> -David
>
> We don't think the W3C should be putting resources behind
> standardization of verifiable claims.  We're not convinced of either
> sufficient demand for this or sufficient incubation of the technology.
>
> However, based on the proposed architecture at
> https://w3c.github.io/webpayments-ig/VCTF/architecture/ ,
> linked from the charter, we're very concerned about the privacy
> properties of this work if the W3C were to proceed with it.
>
> This architecture appears to propose a system in which verification of
> claims leaks substantial information about a user.  For example,
> presenting a credential that is tied to an identity of a user allows for
> tracking of that identity across sites, which the user may not want.  Or
> if, for example, a site accepts claims from various government
> authorities for proof of a user's age, then presentation of a claim of
> age from the California DMV would provide the data that the user lives
> in California, even if that was not the information requested or needed.
>

This seems correct.

I would add:
Even if claims are not directly tied to identity, it appears that the
proposed
architecture would allow the Issuer and the Inspector to collude to
determine
which Holder a claim applies to.


> There has been substantial work on using cryptography to allow proof of
> specific claims without leaking information, such as
> https://www.microsoft.com/en-us/research/project/u-prove/ .  However,
> this effort seems to ignore that work and instead propose a design with
> much worse privacy properties.
>
> If the W3C were to pursue this work, we think it would be best to pursue
> a system with strong privacy properties such as this one.  However, if
> that is not done, we would be particularly opposed to a system that ties
> claims to a single identity for the user, which would be most prone to
> unsanctioned tracking.  However, even transitory and pseudonomous
> identifiers can leak substantial information, contrary to the
> expectations of the user (in the proposed architecture, the Holder),
> particularly if some or all of the Issuer, Identifier Registry, and
> Inspector cooperate to track the Holder.
>

Yes, this seems good.

-Ekr


>
> --
> 𝄞   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

W3C Proposed Recommendation: Web Cryptography API

[L. David Baron]

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:

  Web Cryptography API
  https://www.w3.org/TR/WebCryptoAPI/ 
  http://w3c.github.io/webcrypto/Overview.html 
  Deadline for responses: Friday, January 13, 2017

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.  But I'd definitely like to hear from somebody
knowledgable about the spec and our implementation before just doing
that.

-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)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

6 W3C Candidate Recommendations on XPath and XQuery

[L. David Baron]

6 W3C Candidate Recommendations are available for the membership of
W3C (including Mozilla) to vote on, before they proceed to the final
stages of being a W3C Proposed Recommendation and W3C Recomendation:

  deadline: Tuesday, February 28, 2017
  working groups: XML Query WG *and* XSLT WG

  XML Path Language (XPath) 3.1
  https://www.w3.org/TR/xpath-31/

  XQuery 3.1: An XML Query Language
  https://www.w3.org/TR/xquery-31/

  XQueryX 3.1
  https://www.w3.org/TR/xqueryx-31/

  XPath and XQuery Functions and Operators
  https://www.w3.org/TR/xpath-functions-31/

  XQuery and XPath Data Model 3.1
  https://www.w3.org/TR/xpath-datamodel-31/

  XSLT and XQuery Serialization 3.1
  https://www.w3.org/TR/xslt-xquery-serialization-31/

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, although that's a little less true
now that the review is taking place against a CR rather than a PR.)

However, I'd note that I'm inclined to abstain from this review.
This is a set of XML-related work that's happening at W3C and isn't
particularly related to the browser world these days.

-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)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

W3C Candidate Recommendation: Digital Publishing WAI-ARIA Module 1.0

[L. David Baron]

A W3C Candidate Recommendation is available for the membership of
W3C (including Mozilla) to vote on, before it proceeds to the final
stages of being a W3C Proposed Recommendation and W3C Recomendation:

  Digital Publishing WAI-ARIA Module 1.0
  TR draft: https://www.w3.org/TR/dpub-aria-1.0/ 
  Editor's draft: http://w3c.github.io/aria/aria/dpub.html 
  deadline: Tuesday, February 28, 2017

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, although that's a little less true
now that the review is taking place against a CR rather than a PR.)

-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)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

5 W3C Candidate Recommendations from Social Web WG

[L. David Baron]

5 W3C Candidate Recommendations are available for the membership of
W3C (including Mozilla) to vote on, before they proceed to the final
stages of being a W3C Proposed Recommendation and W3C Recomendation:

  deadline: Thursday, January 12, 2017

  Activity Streams 2.0
  https://www.w3.org/TR/activitystreams-core/

  Activity Vocabulary
  https://www.w3.org/TR/activitystreams-vocabulary/

  Micropub
  https://www.w3.org/TR/micropub/

  Linked Data Notifications
  https://www.w3.org/TR/ldn/

  ActivityPub
  https://www.w3.org/TR/activitypub/

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, although that's a little less true
now that the review is taking place against a CR rather than a PR.)

I suspect Tantek is in support given that he's a co-chair of the
working group.

-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)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Verifiable Claims Working Group

[L. David Baron]

Here's an attempt to write up comments to submit on this charter.
I'm not sure I understood ekr's reply to mt, though.  So corrections
and clarifications are certainly welcome.

Sorry for the delay circling back to this.

-David

We don't think the W3C should be putting resources behind
standardization of verifiable claims.  We're not convinced of either
sufficient demand for this or sufficient incubation of the technology.

However, based on the proposed architecture at
https://w3c.github.io/webpayments-ig/VCTF/architecture/ ,
linked from the charter, we're very concerned about the privacy
properties of this work if the W3C were to proceed with it.

This architecture appears to propose a system in which verification of
claims leaks substantial information about a user.  For example,
presenting a credential that is tied to an identity of a user allows for
tracking of that identity across sites, which the user may not want.  Or
if, for example, a site accepts claims from various government
authorities for proof of a user's age, then presentation of a claim of
age from the California DMV would provide the data that the user lives
in California, even if that was not the information requested or needed.

There has been substantial work on using cryptography to allow proof of
specific claims without leaking information, such as
https://www.microsoft.com/en-us/research/project/u-prove/ .  However,
this effort seems to ignore that work and instead propose a design with
much worse privacy properties.

If the W3C were to pursue this work, we think it would be best to pursue
a system with strong privacy properties such as this one.  However, if
that is not done, we would be particularly opposed to a system that ties
claims to a single identity for the user, which would be most prone to
unsanctioned tracking.  However, even transitory and pseudonomous
identifiers can leak substantial information, contrary to the
expectations of the user (in the proposed architecture, the Holder),
particularly if some or all of the Issuer, Identifier Registry, and
Inspector cooperate to track the Holder.

-- 
𝄞   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)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement CSS Box Alignment on block containers

[L. David Baron]

On Wednesday 2016-12-21 14:45 -0800, Bradley Werth wrote:
> Summary: CSS Box Alignment is broadly available for css-flex containers,
> and will soon be available for css-grid containers. Web developers who are
> using flex containers to take advantage of "justify-content" or
> "align-content" will appreciate being able to apply those styles on block
> containers also. Implementing this now will help diminish future web
> compatibility problems if site owners are overapplying these styles to
> block containers and are expecting continued no-op behavior.
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1105571
> Link to standard: https://drafts.csswg.org/css-align/#overview
> Platform coverage: Desktop and Android
> Estimated or target release: TBD
> Preference behind which this will be implemented:
> layout.css.block-align.enabled
> DevTools bug: TBD
> Do other browser engines implement this? Chrome positive signals:
> https://bugs.chromium.org/p/chromium/issues/detail?id=226252
> Tests: TBD tests added to
> http://test.csswg.org/suites/css-align-3_dev/nightly-unstable/html/chapter-4.htm

It's good to see this happening.

I think it's important to do because it the CSS Working Group's
current plan to address some very common developer complaints about
CSS, such as "can't do vertical centering".  These are already
addressed for flex and grid, because these properties apply to flex
and grid already, and this work will make them apply to blocks as
well.

However, it does have some Web-compatibility risk, because we and
other browsers have already been shipping these properties for a
while for flex and grid, so sites might be using them and starting
to depend on the fact that they *don't* work on blocks.

I'm happy to see this happen sooner rather than later, to reduce
this risk.

-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)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Firefox Desktop] Issues found: December 19th to December 23rd

[Andrei Vaida]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *December 19 - December 23* (week 51).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



*RELEASE CHANNEL*
none

*BETA CHANNEL
*
ID  Summary Product Component   Is a regression 
Assigned to
1324765 
Crash in std::vector::_Buy
Core
Canvas: WebGL
NO  NOBODY
1325592 
[Linux] Unable to mute Flash v24 on Linux
Firefox
Tabbed Browser
NO  NOBODY
1325597 
Mouse click issues with pointer lock on WebGL2 demo sample page
Core
DOM
YES NOBODY

*
***
*AURORA CHANNEL
*
ID  Summary Product Component   Is a regression 
Assigned to
1324437 
Scrolling via keyboard does not work up/down
Firefox
Developer Tools: Responsive Design Mode
NO  NOBODY
1324449 
Drop down lists are exceeding the RDM viewport
Firefox Developer Tools: Responsive Design Mode NO  
NOBODY
1324469 
Poor rendering when opening RDM on wikipedia
Firefox
Developer Tools: Responsive Design Mode NO  NOBODY
1325056 
Pause button on youtube while RDM activated is faulty
Firefox
Developer Tools: Responsive Design Mode NO  NOBODY
1325077 
Playing a video on Vimeo when RDM active goes fullscreen
Firefox
Developer Tools: Responsive Design Mode
YES NOBODY
1325124 
Youtube becomes blank while on RDM if the user changes between devices
Firefox Developer Tools: Responsive Design Mode YES 
NOBODY
1325108 
	Closing window (application) will continue to display latest preview in 
the sharing area

Core
WebRTC
NO  NOBODY
1325365 
	Window (application) is not displayed in the sharing drop down list 
while minimized

Core
WebRTC
NO  NOBODY
1325378 
	Clicking outside the sharing doorhanger will not remember the last 
chosen application (window) in the sharing drop down

Core
WebRTC
NO  NOBODY
1325397 
	The number of open windows is only updated in the sharing drop down 
after a page refresh

Core
WebRTC
NO  NOBODY
1325411 
	The sharing drop down displays incorrect number of open windows for 
some applications

Core
WebRTC
NO  NOBODY
1325417 
The sharing drop down displays incorrect name for some open applications
CoreWebRTC  NO  NOBODY
1325560 
	Show that DPR is not changeable in a better way once you select a 
device (dark theme)

Firefox
Developer Tools: Responsive Design Mode NO  NOBODY
1325571 
Focus dotted rectangle not visible inside modal
Firefox Developer Tools: Responsive Design Mode YES 
NOBODY
1325576 
	Entering fullscreen on a video inside RDM will enter entire Fx in 
fullscreen and breaks the content displayed after exiting

Firefox Developer Tools: Responsive Design Mode NO  
NOBODY
1325578 
DPR value is changed when zooming in or out when in RDM
Firefox
Developer Tools: Responsive Design Mode NO  NOBODY
1325557 
RDM can be enabled on non-remote pages
Firefox Developer Tools: Responsive Design Mode NO  
NOBODY
1325563 
The viewport is on focus while the modal is opened
Firefox Developer Tools: Responsive Design Mode NO  
NOBODY
1325567 

Intent to Implement: adding vector effects non-scaling-size, non-rotation and fixed-position to SVG

[Ramin]

Intent to Implement: adding vector effects  non-scaling-size,  
non-rotation and fixed-position to SVG


Contact emails

te-fuk...@kddi-tech.com, g-ra...@kddi-tech.com, sa-...@kddi-tech.com

Summary

To offer vector effects regarding special coordinate transformations and  
graphic drawings as described in following Spec link,
SVG Tiny 1.2 introduced the vector-effect property. Although SVG Tiny  
1.2 introduced only non-scaling stroke behavior, this version introduces  
a number of additional effects.


We intend now to implement non-scaling-size, non-rotation and  
fixed-position, as well as their combination to Gecko/SVG.


Motivation

It is a point of interest in many SVG content providers to let the  
outline of an object keep its original size or to keep the position of  
an object fix, regardless of type of transforms that are applied to it.  
For example, in a map with a 2px wide line representing roads it is of
interest to keep the roads 2px wide even when the user zooms into the  
map, or introductory notes on the graphic chart in which panning is  
possible. Therefore, there is a high need for supporting these features  
in browsers.



Spec(Link to standard)

https://svgwg.org/svg2-draft/coords.html#VectorEffects

Platform coverage

Starting from Windows and Linux.

Bug

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

Estimated or target release

2017/1/30

Requesting approval to ship?

No.  Implementation is expected to take some time.

Tests

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

Intent to Implement CSS Box Alignment on block containers

[Bradley Werth]

Summary: CSS Box Alignment is broadly available for css-flex containers,
and will soon be available for css-grid containers. Web developers who are
using flex containers to take advantage of "justify-content" or
"align-content" will appreciate being able to apply those styles on block
containers also. Implementing this now will help diminish future web
compatibility problems if site owners are overapplying these styles to
block containers and are expecting continued no-op behavior.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1105571
Link to standard: https://drafts.csswg.org/css-align/#overview
Platform coverage: Desktop and Android
Estimated or target release: TBD
Preference behind which this will be implemented:
layout.css.block-align.enabled
DevTools bug: TBD
Do other browser engines implement this? Chrome positive signals:
https://bugs.chromium.org/p/chromium/issues/detail?id=226252
Tests: TBD tests added to
http://test.csswg.org/suites/css-align-3_dev/nightly-unstable/html/chapter-4.htm
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement: adding vector effects non-scaling-size, non-rotation and fixed-position to SVG

[ktecramin99]

> Does this change any invariants that we depend on in terms of how
> SVG images with a viewBox respond to size changes by scaling?

To be able to answer your question, please kindly write an example of what kind 
of invariant or what kind of use-case concerns you. Also please refer to 
following link for checking behavior of this implementation:
http://svg2.mbsrv.net/devinfo/devstd/non-scaling-objects-2/VectorEffect_polyfill.html

thank you in advance.
Ramin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform