Intent to Prototype and Ship: support “JIS-B5” and “JIS-B4” @page sizes

87 views
Skip to first unread message

Felipe Erias Morandeira

unread,
Feb 18, 2020, 4:36:43 PM2/18/20
to blink-dev

Contact emails

felip...@gmail.com 


Spec

https://www.w3.org/TR/css-page-3/#typedef-page-size-page-size 


I’ve been informed that a TAG review is not needed in this case.


Explainer/Summary

The CSS Paged Media Module Level 3 spec includes a list of page size names that may be used in the "size" property of the @page rule.


Among these are two names for Japanese Industrial Standard page sizes which are currently not being recognized by Chrome:

  • “JIS-B5” refers to JIS B5 size (182mm wide by 257mm high)

  • “JIS-B4” refers to JIS B4 size (257mm wide by 364mm high)


This feature completes the implementation of this section of the standard by adding support for these two page size names.


Chromium Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1047642 


CL: https://chromium-review.googlesource.com/c/chromium/src/+/2059029 


Motivation

The detailed description of bug 1047642 links to some related discussions and documents. Chromium's implementation of the “size” property follows a now-obsolete version of the spec which didn't include the Japanese JIS B4 and JIS B5 paper sizes. Those were added later on following demand from Japanese users:


The B4 and B5 sizes included are very confusing for Japanese users, as they are defined as ISO B4 (250×353mm) and ISO B5 (176×250mm), different from the JIS-B4 (257×364mm) and JIS-B5 (182×257mm) commonly used in Japan. [www-...@w3c.org archives]


We need jis-b5 and jis-b4 only because (ISO) b5 and b4 are already defined and those would confuse Japanese users. [public-cs...@w3.org archives]



Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


Risks

Interoperability and Compatibility

If support for the “size” property itself is already in place (as is the case with Chromium), adding support for the page size names listed in the spec is pretty much straightforward.


Edge: No signals

Firefox: No signals

Safari: No signals

Web / Framework developers: already defined in CSS Paged Media Module Level 3 by the CSS Working Group.


Ergonomics

This feature will have no impact on the browser's ability to maintain good performance.


Activation

No specific extra work required: these two values are already part of the spec and mentioned in online documentation sites like MDN Web Docs.


Debuggability

No extra work needed by DevTools.


Is this feature fully tested by web-platform-tests?

Not yet. I have created an issue and pull request to add those tests:


Entry on the feature dashboard

I would need somebody to create an entry for this feature, as I don’t have the necessary permissions yet.


Requesting approval to ship?

Yes.

Florian Rivoal

unread,
Feb 18, 2020, 9:17:27 PM2/18/20
to blink-dev
Hi,

This sounds like a good idea to me. The B4 B5 sizes are in common use in Japan, but that's the JIS B4 / B5, not the ISO B4/B5, so having (implicitly ISO) B4/B5 without the JIS variant is highly misleading to those users. That's what motivated the decision of the CSSWG, recorded in https://lists.w3.org/Archives/Public/www-style/2015Nov/0226.html.

As for interest to implement from other browsers, it is a little hard to tell, as other browsers don't support @page's size property at all yet, so discussing which values they should add is a little moot. As far as I know, as the minutes listed above showed, there was explicit support at least from Edge, and no opposition from anyone.

Also, @page's size property in general is supported by all HTML+CSS->pdf/print formatters, and the "JIS-B4" "JIS-B5" values specifically are supported at least by Antenna House Formatter and Vivliostyle, so implementing these values is expected to improve compatibility with documents prepared with those engines in mind.

—Florian

Daniel Bratell

unread,
Feb 19, 2020, 2:00:25 PM2/19/20
to Florian Rivoal, blink-dev

The things you learn...

LGTM1

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a8ffb1b8-836f-4fe8-aeb4-2ee4f59d5c3a%40chromium.org.

Mounir Lamouri

unread,
Feb 19, 2020, 4:01:13 PM2/19/20
to Felipe Erias Morandeira, blink-dev
On Tue, 18 Feb 2020 at 13:36, Felipe Erias Morandeira <felip...@gmail.com> wrote:

Contact emails

felip...@gmail.com 


Spec

https://www.w3.org/TR/css-page-3/#typedef-page-size-page-size 


I’ve been informed that a TAG review is not needed in this case.


I assume that the TAG review isn't needed because it's only adding new type of @page sizes and doesn't actually change anything else. Is this correct?
 

Explainer/Summary

The CSS Paged Media Module Level 3 spec includes a list of page size names that may be used in the "size" property of the @page rule.


Among these are two names for Japanese Industrial Standard page sizes which are currently not being recognized by Chrome:

  • “JIS-B5” refers to JIS B5 size (182mm wide by 257mm high)

  • “JIS-B4” refers to JIS B4 size (257mm wide by 364mm high)


This feature completes the implementation of this section of the standard by adding support for these two page size names.


Chromium Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1047642 


CL: https://chromium-review.googlesource.com/c/chromium/src/+/2059029 


Motivation

The detailed description of bug 1047642 links to some related discussions and documents. Chromium's implementation of the “size” property follows a now-obsolete version of the spec which didn't include the Japanese JIS B4 and JIS B5 paper sizes. Those were added later on following demand from Japanese users:


The B4 and B5 sizes included are very confusing for Japanese users, as they are defined as ISO B4 (250×353mm) and ISO B5 (176×250mm), different from the JIS-B4 (257×364mm) and JIS-B5 (182×257mm) commonly used in Japan. [www-...@w3c.org archives]


We need jis-b5 and jis-b4 only because (ISO) b5 and b4 are already defined and those would confuse Japanese users. [public-cs...@w3.org archives]



Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


Risks

Interoperability and Compatibility

If support for the “size” property itself is already in place (as is the case with Chromium), adding support for the page size names listed in the spec is pretty much straightforward.


Edge: No signals

Firefox: No signals

Safari: No signals

Web / Framework developers: already defined in CSS Paged Media Module Level 3 by the CSS Working Group.


I don't think that the change being part of a Working Group spec is seen as a signal from Web or Framework developers. I think the intent of this question is more to check if you are aware of any web developer asking for this feature. Basically, are there strong concrete real life use cases that makes this addition useful to the platform. I think in your case, the motivation section answers this and it seems that there is a demand.

Also, did you reach out to Firefox or Safari? Are there bugs open for this feature? What's the story behind it being added to the spec. Who proposed it? and why? I see that two Mozillians are editing the spec. Did you reach out to them directly maybe?
 

Ergonomics

This feature will have no impact on the browser's ability to maintain good performance.


Activation

No specific extra work required: these two values are already part of the spec and mentioned in online documentation sites like MDN Web Docs.


Debuggability

No extra work needed by DevTools.


Is this feature fully tested by web-platform-tests?

Not yet. I have created an issue and pull request to add those tests:


Entry on the feature dashboard

I would need somebody to create an entry for this feature, as I don’t have the necessary permissions yet.


Requesting approval to ship?

Yes.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

TAMURA, Kent

unread,
Feb 19, 2020, 6:37:36 PM2/19/20
to Daniel Bratell, Florian Rivoal, blink-dev
LGTM2.

No signals from other browser vendors, but the necessity of the change is obvious, and this is a small addition to an existing feature.  I don't think other browser vendors have objections.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a2af681b-d007-b77e-4d62-71a569765fe2%40gmail.com.


--
TAMURA Kent
Software Engineer, Google


Felipe Erias Morandeira

unread,
Feb 19, 2020, 8:10:05 PM2/19/20
to blink-dev, felip...@gmail.com
On Thursday, 20 February 2020 06:01:13 UTC+9, Mounir Lamouri wrote:
On Tue, 18 Feb 2020 at 13:36, Felipe Erias Morandeira <felip...@gmail.com> wrote:

…


I assume that the TAG review isn't needed because it's only adding new type of @page sizes and doesn't actually change anything else. Is this correct?

Yes, this CL only adds two new page size names, plus tests.
 

…


I don't think that the change being part of a Working Group spec is seen as a signal from Web or Framework developers. I think the intent of this question is more to check if you are aware of any web developer asking for this feature. Basically, are there strong concrete real life use cases that makes this addition useful to the platform. I think in your case, the motivation section answers this and it seems that there is a demand.

Also, did you reach out to Firefox or Safari? Are there bugs open for this feature? What's the story behind it being added to the spec. Who proposed it? and why? I see that two Mozillians are editing the spec. Did you reach out to them directly maybe?

Florian did a much better work than I did at providing the background for this addition to the standard (thanks!).

These two values are part of the CSS3 Paged Media spec; there are open bugs to add support for this spec in Firefox (#286443) and Webkit (#15548). I haven't reached out to them regarding this particular change, although it seems worthy to do so regarding support for the spec as a whole.
 
…
 
Great, thank you very much.

Mounir Lamouri

unread,
Feb 19, 2020, 8:18:13 PM2/19/20
to Felipe Erias Morandeira, blink-dev
Thank you for the additional information Felipe. I've updated the chromestatus entry with the Firefox and WebKit bugs.

non-owner LGTM.

-- Mounir

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2df894a8-efde-4b2c-a123-9ce2f37c86d9%40chromium.org.

Chris Harrelson

unread,
Feb 19, 2020, 8:41:26 PM2/19/20
to Mounir Lamouri, Felipe Erias Morandeira, blink-dev
LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B-LeH-TpK1kz8Q3j-B24-2CX7LvHYCi2L1uurbJJpUubXTbkg%40mail.gmail.com.

Felipe Erias Morandeira

unread,
Feb 20, 2020, 8:38:21 AM2/20/20
to blink-dev
This change has been merged, thank you very much everyone for your help!

One last thing: the status of bug 1047642 should be updated, but I don't have bug-editing permissions yet. Could somebody take care of that, please?

Manuel Rego Casasnovas

unread,
Feb 21, 2020, 1:01:24 AM2/21/20
to blin...@chromium.org

On 18/02/2020 17:48, Felipe Erias Morandeira wrote:
> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
>
> Not yet. I have created an issue and pull request to add those tests:
>
> *
>
> https://github.com/web-platform-tests/wpt/issues/21858 
>
> *
>
> https://github.com/web-platform-tests/wpt/pull/21859

Just reviewed and merged them, those are manual tests similar to other
on that folder. Thanks for writing them.

It'd be great if we can upstream at least the test that verifies parsing
from your CL as a testharness.js test into WPT (the other one uses
internals stuff so moving it to WPT is not an option).

One day we'll be able to do automatic tests for printing stuff too:
https://github.com/web-platform-tests/rfcs/pull/41

Bye,
Rego
Reply all
Reply to author
Forward
0 new messages