[css-fonts] About the breaking change to CSSFontFaceRule interface

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[css-fonts] About the breaking change to CSSFontFaceRule interface

Xidorn Quan-3
Currently, the CSSFontFaceRule interface described in CSS Fonts spec is
not what is implemented in browsers. There were some discussions in the
mailing list last year, and John Daggett said he would try to implement
the new interface in Firefox [1], but it seems he didn't get a chance to
finish that before he left Mozilla.

Now I'd like to try finishing that work, but before that I want to hear
from other engines if you are happy with the current shape of
CSSFontFaceRule interface in the spec, and willing to implement this
breaking change and take the compatibility risk soonish if Gecko does.

I found that Chrome Platform Status added a measure for
CSSFontFaceRule.style at the end of last year, and the data shows
~0.045% of pages try to access that attribute [2]. IIRC, Chrome's
safe-to-break line is 0.03%, so it's higher than that line. Do you think
breaking this would be acceptable?

The current impls aren't quite interoperable, e.g. the object returned
from CSSFontFaceRule.style includes all properties from
CSSStyleDeclaration in all engines except Gecko, and setting attributes
of that object would lead to different behavior in different engines. So
we would need to do something anyway.

What do you think?

In addition, any idea about how websites are currently using that
attribute would be helpful as well.

[1] https://lists.w3.org/Archives/Public/www-style/2015Dec/0144.html
[2]
https://www.chromestatus.com/metrics/feature/timeline/popularity/1082

- Xidorn

Reply | Threaded
Open this post in threaded view
|

Re: [css-fonts] About the breaking change to CSSFontFaceRule interface

Daniel Glazman
I have only one (rather big) issue with the proposal: it's not very friendly with experimental features/polyfills since there is no extra storage room for user-defined font features... I don't think we should ship any more anything at grammar-level that is not extensible because all properties/features are hardcoded.

</Daniel>

Envoyé de mon iPhone

> Le 2 août 2016 à 08:59, Xidorn Quan <[hidden email]> a écrit :
>
> Currently, the CSSFontFaceRule interface described in CSS Fonts spec is
> not what is implemented in browsers. There were some discussions in the
> mailing list last year, and John Daggett said he would try to implement
> the new interface in Firefox [1], but it seems he didn't get a chance to
> finish that before he left Mozilla.
>
> Now I'd like to try finishing that work, but before that I want to hear
> from other engines if you are happy with the current shape of
> CSSFontFaceRule interface in the spec, and willing to implement this
> breaking change and take the compatibility risk soonish if Gecko does.
>
> I found that Chrome Platform Status added a measure for
> CSSFontFaceRule.style at the end of last year, and the data shows
> ~0.045% of pages try to access that attribute [2]. IIRC, Chrome's
> safe-to-break line is 0.03%, so it's higher than that line. Do you think
> breaking this would be acceptable?
>
> The current impls aren't quite interoperable, e.g. the object returned
> from CSSFontFaceRule.style includes all properties from
> CSSStyleDeclaration in all engines except Gecko, and setting attributes
> of that object would lead to different behavior in different engines. So
> we would need to do something anyway.
>
> What do you think?
>
> In addition, any idea about how websites are currently using that
> attribute would be helpful as well.
>
> [1] https://lists.w3.org/Archives/Public/www-style/2015Dec/0144.html
> [2]
> https://www.chromestatus.com/metrics/feature/timeline/popularity/1082
>
> - Xidorn
>


Reply | Threaded
Open this post in threaded view
|

Re: [css-fonts] About the breaking change to CSSFontFaceRule interface

Xidorn Quan-3
On Tue, Aug 2, 2016, at 05:27 PM, Daniel Glazman wrote:
> I have only one (rather big) issue with the proposal: it's not very
> friendly with experimental features/polyfills since there is no extra
> storage room for user-defined font features... I don't think we should
> ship any more anything at grammar-level that is not extensible because
> all properties/features are hardcoded.

I think objects returned from DOM / CSSOM are not frozen in general, so
JS code should always be able to attach new attributes to those objects,
shouldn't it?

- Xidorn

Reply | Threaded
Open this post in threaded view
|

Re: [css-fonts] About the breaking change to CSSFontFaceRule interface

Daniel Glazman
On 02/08/2016 10:11, Xidorn Quan wrote:

> On Tue, Aug 2, 2016, at 05:27 PM, Daniel Glazman wrote:
>> I have only one (rather big) issue with the proposal: it's not very
>> friendly with experimental features/polyfills since there is no extra
>> storage room for user-defined font features... I don't think we should
>> ship any more anything at grammar-level that is not extensible because
>> all properties/features are hardcoded.
>
> I think objects returned from DOM / CSSOM are not frozen in general, so
> JS code should always be able to attach new attributes to those objects,
> shouldn't it?

In that case, fine by me.

</Daniel>


Reply | Threaded
Open this post in threaded view
|

Re: [css-fonts] About the breaking change to CSSFontFaceRule interface

Myles C. Maxfield
In reply to this post by Xidorn Quan-3

On Aug 1, 2016, at 11:59 PM, Xidorn Quan <[hidden email]> wrote:

Currently, the CSSFontFaceRule interface described in CSS Fonts spec is
not what is implemented in browsers. There were some discussions in the
mailing list last year, and John Daggett said he would try to implement
the new interface in Firefox [1], but it seems he didn't get a chance to
finish that before he left Mozilla.

This was added in [1], but that doesn’t provide a link to the discussion. Similarly, the link you point to [2] is about either implementing or reverting the spec, rather than why this was proposed in the first place. Do you think you could link me to the place where this new shape is discussed?

[2] https://lists.w3.org/Archives/Public/www-style/2015Dec/0111.html

Thanks,
Myles
Reply | Threaded
Open this post in threaded view
|

Re: [css-fonts] About the breaking change to CSSFontFaceRule interface

Tab Atkins Jr.
On Wed, Aug 3, 2016 at 1:17 PM, Myles C. Maxfield <[hidden email]> wrote:

>
> On Aug 1, 2016, at 11:59 PM, Xidorn Quan <[hidden email]> wrote:
>
> Currently, the CSSFontFaceRule interface described in CSS Fonts spec is
> not what is implemented in browsers. There were some discussions in the
> mailing list last year, and John Daggett said he would try to implement
> the new interface in Firefox [1], but it seems he didn't get a chance to
> finish that before he left Mozilla.
>
>
> This was added in [1], but that doesn’t provide a link to the discussion.
> Similarly, the link you point to [2] is about either implementing or
> reverting the spec, rather than why this was proposed in the first place. Do
> you think you could link me to the place where this new shape is discussed?
>
> [1]
> https://github.com/w3c/csswg-drafts/commit/0647473afb613e735b0cbe9ea98fb77ff244a1ac
> [2] https://lists.w3.org/Archives/Public/www-style/2015Dec/0111.html

Looks like the discussion was kicked off by bz in
<https://lists.w3.org/Archives/Public/www-style/2012Jun/0650.html>, a
few months prior to jdaggett's commit.  I fixed @counter-style to the
"descriptors directly on the interface" style as well, due to this
discussion.

(Interesting that just 2 years or so later I'd completely forgotten
about this and just blindly copied what Fonts was currently doing. Yay
institutional memory!)

~TJ