Re: Intent to Use Counter: Everything

[Boris Zbarsky]

On 5/11/16 12:46 PM, Mike Taylor wrote:

Is there any handy way of identifying these, other than
cross-referencing with the relevant specs?


Generally they are in a separate partial interface in the webidl file. 
And typically that partial interface is documented as non-standard or 
Gecko-only or something.  At least that's how it works when people are 
being careful and annotating all the IDL snippets with the spec links 
for where they come from.


-Boris

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

Re: Intent to Use Counter: Everything

[Mike Taylor]

On 5/11/16 3:56 AM, Cameron McCormack wrote:

Recording use counter information as we parse CSS is not too expensive,
although if we were doing it for all ~300 properties I’d be wanting to
check that we don’t slow sheet parsing speed down appreciably.  It’s
probably fine, but see the work that is done when recording one here:

  https://dxr.mozilla.org/mozilla-central/source/dom/base/nsDocument.cpp#13129

We use a std::bitset<> on the document to store the “use counted or not”
for each use counter so the memory overhead is low.  Someone with more
familiarity about the actual Telemetry payload can say whether it would
be alarming to have ~300 new entries, if you plan to eventually include
all properties.


bsmedberg got pinged in the bug to give feedback on that.


But starting with recording all of our non-standard property usage
sounds fine.


I've changed the bug title to start with non-standard props and we can 
take it from there.



Note that UseCounters.conf only supports longhand
properties currently, since we record them in here, where we’ve already
expanded shorthands out to their component longhands:

  
https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSDataBlock.cpp#712

We could handle shorthands by recording them earlier, up in nsCSSParser
somewhere.


Good to know, thanks.

--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Use Counter: Everything

[Mike Taylor]

On 5/10/16 6:53 PM, Jonas Sicking wrote:

The moz-isms aren't as easy to spot in the DOM since there's much less
of a history of prefixing DOM-API names, but they certainly exist.


Is there any handy way of identifying these, other than 
cross-referencing with the relevant specs?


--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Use Counter: Everything

[Cameron McCormack]

Mike Taylor:
> Having recently discovered UseCounters.conf[1], I'd like to add use
> counters for all CSS properties, starting with prefixed props. And
> likewise for Moz-prefixed DOM props and methods.
> 
> Ultimately, I'd like us to have a Firefox equivalent to
> https://www.chromestatus.com/metrics/css/popularity to help us make
> decisions around removing support for non-standard-isms without
> breaking the web.
> 
> (https://platform-status.mozilla.org/ seems like a good home for
> this kind of data)
> 
> Before I start writing patches, is there any reason to not do this?

Recording use counter information as we parse CSS is not too expensive,
although if we were doing it for all ~300 properties I’d be wanting to
check that we don’t slow sheet parsing speed down appreciably.  It’s
probably fine, but see the work that is done when recording one here:

  https://dxr.mozilla.org/mozilla-central/source/dom/base/nsDocument.cpp#13129

We use a std::bitset<> on the document to store the “use counted or not”
for each use counter so the memory overhead is low.  Someone with more
familiarity about the actual Telemetry payload can say whether it would
be alarming to have ~300 new entries, if you plan to eventually include
all properties.

But starting with recording all of our non-standard property usage
sounds fine.  Note that UseCounters.conf only supports longhand
properties currently, since we record them in here, where we’ve already
expanded shorthands out to their component longhands:

  
https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSDataBlock.cpp#712

We could handle shorthands by recording them earlier, up in nsCSSParser
somewhere.

-- 
Cameron McCormack ≝ http://mcc.id.au/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Use Counter: Everything

[Jonas Sicking]

On Tue, May 10, 2016 at 1:31 PM, Mike Taylor  wrote:

> On 5/10/16 3:05 PM, Jack Moffitt wrote:
>
>> We have the Chrome popularity data, and we have the Edge team's data
>> which covers the CSS spectrum quite well. I think it would be far more
>> useful to start covering the DOM API spectrum.
>>
>> For example, it's pretty clear from existing data sources which CSS
>> properties Servo should focus on. But we have very little data for
>> which DOM APIs are important.
>>
>
> Interesting, my own interests are naturally skewed towards finding the
> moz-isms and understanding how and when we can get rid of them (if ever).
> But I can see how understanding DOM API usage is more relevant when
> building a new browser engine.


There are lots of moz-isms in the DOM as well.

The moz-isms aren't as easy to spot in the DOM since there's much less of a
history of prefixing DOM-API names, but they certainly exist.

And there are definitely cases when we'd like to deprecate APIs even if
they aren't moz-isms. Two recent examples are showModalDialog and the XSLT
API.

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

Re: Intent to Use Counter: Everything

[Mike Taylor]

On 5/10/16 3:05 PM, Jack Moffitt wrote:

We have the Chrome popularity data, and we have the Edge team's data
which covers the CSS spectrum quite well. I think it would be far more
useful to start covering the DOM API spectrum.

For example, it's pretty clear from existing data sources which CSS
properties Servo should focus on. But we have very little data for
which DOM APIs are important.


Interesting, my own interests are naturally skewed towards finding the 
moz-isms and understanding how and when we can get rid of them (if 
ever). But I can see how understanding DOM API usage is more relevant 
when building a new browser engine.



What value does having even more CSS property data provide above and
beyond the value that can be extracted from the existing sources? Is
that value greater than the value we could extract by focusing on data
that doesn't currently exist?

I assume the answer to the first question is that it gives us data
that doesn't exist about -moz prefixed properties. Regarding the
second question, my opinion is that we can get a lot more benefit from
covering other areas than CSS. I'm curious to hear more informed
opinions on this than my own.


¿Porqué no los dos?

Right now no source of data will tell us if it's safe to remove 
:-moz-dir() once we ship :dir(), for example.


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

And as Steve already replied, making decisions based on CSS (or JS) 
served to browsers with different UA strings can be problematic. If 
you're Safari Mobile, you'll end up with a lot more WebKit-isms than if 
you're Fennec.


But yes, I absolutely agree we should Use Counter DOM APIs as well.


As to where this should live, it seems unfortunate that we would end
up with three repositories of data: Chrome's use counters, Edge's
platform status, and now a Mozilla one. Is it not possible to
consolidate this collection effort?


I don't have any strong opinions on where the data lives.

--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Use Counter: Everything

[Steve Fink]

On 05/10/2016 01:05 PM, Jack Moffitt wrote:

We have the Chrome popularity data, and we have the Edge team's data
which covers the CSS spectrum quite well. I think it would be far more
useful to start covering the DOM API spectrum.

For example, it's pretty clear from existing data sources which CSS
properties Servo should focus on. But we have very little data for
which DOM APIs are important.

What value does having even more CSS property data provide above and
beyond the value that can be extracted from the existing sources? Is
that value greater than the value we could extract by focusing on data
that doesn't currently exist?

I assume the answer to the first question is that it gives us data
that doesn't exist about -moz prefixed properties. Regarding the
second question, my opinion is that we can get a lot more benefit from
covering other areas than CSS. I'm curious to hear more informed
opinions on this than my own.

As to where this should live, it seems unfortunate that we would end
up with three repositories of data: Chrome's use counters, Edge's
platform status, and now a Mozilla one. Is it not possible to
consolidate this collection effort?


Why is this an either/or? Both seem valuable.

Multiple data sources provide opportunities to detect discrepancies 
between them. (eg, say feature-detection triggers a hit count in one 
browser's collection mechanism and not another's.) I agree that a 
unified reporting facility would be useful. But I'd bet we'd learn 
*something* by looking at where our numbers mismatch other browsers'.


Another example: consider the case where UA detection prevents the usage 
of a CSS property. If everyone avoids a particular CSS property on 
Firefox only, perhaps there is a real reason for it that we should 
figure out. Maybe we need to evangelize the fact that we now support 
property X, or have fixed the bug causing it to be blacklisted.


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

Re: Intent to Use Counter: Everything

[Jack Moffitt]

We have the Chrome popularity data, and we have the Edge team's data
which covers the CSS spectrum quite well. I think it would be far more
useful to start covering the DOM API spectrum.

For example, it's pretty clear from existing data sources which CSS
properties Servo should focus on. But we have very little data for
which DOM APIs are important.

What value does having even more CSS property data provide above and
beyond the value that can be extracted from the existing sources? Is
that value greater than the value we could extract by focusing on data
that doesn't currently exist?

I assume the answer to the first question is that it gives us data
that doesn't exist about -moz prefixed properties. Regarding the
second question, my opinion is that we can get a lot more benefit from
covering other areas than CSS. I'm curious to hear more informed
opinions on this than my own.

As to where this should live, it seems unfortunate that we would end
up with three repositories of data: Chrome's use counters, Edge's
platform status, and now a Mozilla one. Is it not possible to
consolidate this collection effort?

jack.

On Tue, May 10, 2016 at 1:11 PM, Mike Taylor  wrote:
> Having recently discovered UseCounters.conf[1], I'd like to add use counters
> for all CSS properties, starting with prefixed props. And likewise for
> Moz-prefixed DOM props and methods.
>
> Ultimately, I'd like us to have a Firefox equivalent to
> https://www.chromestatus.com/metrics/css/popularity to help us make
> decisions around removing support for non-standard-isms without breaking the
> web.
>
> (https://platform-status.mozilla.org/ seems like a good home for this kind
> of data)
>
> Before I start writing patches, is there any reason to not do this?
>
> [1] https://dxr.mozilla.org/mozilla-central/source/dom/base/UseCounters.conf
>
> --
> Mike Taylor
> Web Compat, Mozilla
> ___
> 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 Use Counter: Everything

[Mike Taylor]

On 5/10/16 2:11 PM, Mike Taylor wrote:

Having recently discovered UseCounters.conf[1], I'd like to add use
counters for all CSS properties, starting with prefixed props. And
likewise for Moz-prefixed DOM props and methods.


Link to bug:

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

--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Use Counter: Everything

[Mike Taylor]

Having recently discovered UseCounters.conf[1], I'd like to add use 
counters for all CSS properties, starting with prefixed props. And 
likewise for Moz-prefixed DOM props and methods.


Ultimately, I'd like us to have a Firefox equivalent to 
https://www.chromestatus.com/metrics/css/popularity to help us make 
decisions around removing support for non-standard-isms without breaking 
the web.


(https://platform-status.mozilla.org/ seems like a good home for this 
kind of data)


Before I start writing patches, is there any reason to not do this?

[1] https://dxr.mozilla.org/mozilla-central/source/dom/base/UseCounters.conf

--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform