W3C home > Mailing lists > Public > public-css-testsuite@w3.org > July 2015

Re: [css-writing-modes-3] value-all-002 and value-all-003 : comments, feedback and question

From: Masataka Yakura <myakura.web@gmail.com>
Date: Thu, 9 Jul 2015 17:57:33 +0900
Message-ID: <CANJXhd3Kn7mA264EqTw74R1kffRTDadYemTjSfc=ZJifHLMzxA@mail.gmail.com>
To: Gérard Talbot <css21testsuite@gtalbot.org>
Cc: Public CSS Test suite mailing list <public-css-testsuite@w3.org>, Koji Ishii <kojiishi@gluesoft.co.jp>
Hi Gérard,

On Mon, Jun 22, 2015 at 9:10 AM, Gérard Talbot <css21testsuite@gtalbot.org>
wrote:

> Masataka,
>
> [src]
> http://test.csswg.org/source/css-writing-modes-3/value-all-002.html
>
> [nightly-unstable]
>
> http://test.csswg.org/suites/css-writing-modes-3_dev/nightly-unstable/html/value-all-002.htm
>
> [reference file]
>
> http://test.csswg.org/source/css-writing-modes-3/reference/vertical-ahem-1x1-ref.html
>
> If you use the Ahem font, then it is preferable to also define the
> line-height on block elements when you define the Ahem font size.
> Otherwise, the gap between line boxes will be different from browsers to
> browsers.
>
> When line-height is not defined, then 'line-height' defaults to 'normal'
> and 'normal' computes to 1 in Webkit-based browsers and IE while it will
> compute to 1.2 in Firefox for the Ahem font.
>
> Try this page in several browsers:
>
>
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/experiments-va-lineheight-02.html
>
> Not specifying the line-height can make your reference file or your test
> unreliable. Here, how you created the reference file vertical-ahem-1x1-ref
> does not make your test incorrect.
>

Thanks for reviewing. I didn't know the default value for line-height
differs by browser.
Updated tests (including others needing the same fix) and sent a PR.
https://github.com/w3c/csswg-test/pull/798

Personally, I try to use images in reference file: that way, I am sure the
> reference file uses a different method from the test. What you did in the
> reference file vertical-ahem-1x1-ref looks fine.
>
> If the test should create an 80px by 80px black area, then I recommend to
> replace "rectangles" with "squares": this will help the person taking that
> test in the test harness.
>

Updated.

I examined your value-all-002 test because the black shapes are not
> perfectly identical (Koji also noticed this! [1]) in Chrome 45.0.2431.0 ...
> for unknown reasons right now. I tried to use a font-size of 75px which
> would be dividable by 3 and dividable by 5 to avoid rounding issues but
> this does not seem to be the reason why the black areas are not perfectly
> identical. So, there may be a bug in Chrome after all.
>
> [1] :
>
> http://test.csswg.org/shepherd/testcase/value-all-002/spec/css-writing-modes-3/status/issue/#comment-2f386058f4ee
>

Yeah... I noticed that while developing these test cases but thought that
might be a bug in Chrome.


> [src]
> http://test.csswg.org/source/css-writing-modes-3/value-all-003.html
>
> [nightly-unstable]
>
> http://test.csswg.org/suites/css-writing-modes-3_dev/nightly-unstable/html/value-all-003.htm
>
> [reference file]
>
> http://test.csswg.org/source/css-writing-modes-3/reference/vertical-ahem-1x1-ref.html
>
> I would like you to help me understand the spec thanks to this test.
>
> "
> all
>     Attempt to typeset horizontally all consecutive characters within the
> box such that they take up the space of a single character within the
> vertical line box.
>
> digits <integer>?
>
>     Attempt to typeset horizontally each maximal sequence of consecutive
> ASCII digits (U+0030–U+0039) that has as many or fewer characters than the
> specified integer such that it takes up the space of a single character
> within the vertical line box. If the integer is omitted, it computes to 2.
> Integers outside the range 2-4 are invalid.
> "
> 9.1 Horizontal-in-Vertical Composition: the text-combine-upright property
> http://www.w3.org/TR/css-writing-modes-3/#text-combine-upright
>
> There seems to be no implicit (and no explicit) range limit to the number
> of consecutive characters when using 'text-combine-upright: all' but there
> is a range 2-4 limit with 'text-combine-upright: digits n': is that
> correct? To me, this seems odd and incoherent.
>
> If there is no range limitation with 'text-combine-upright: all', then why
> should there be one with 'text-combine-upright: digits n' where 'n' would
> be a [2-9] digit?
>

So sorry for catching up late; it looks like editors have already answered
the questions...

-- 
Masataka Yakura
<myakura.web@gmail.com>
Received on Thursday, 9 July 2015 08:58:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 20 January 2023 19:58:21 UTC