RE: Questions about microsoft tests (3nd version)

Robert Stam wrote
> I checked with that version now, but the problems are still present, I updated
> the file-names (and ordered on chapter) below:
> 
> Thanks in advance for any feedback on those issues.
> 
> 1) ---------
> chapter_6\HTML-attribute-019.xht
> 
> The DOCTYPE of this test is XHTML 1.0 Transitional in which there's no
> baseline space reserved below an image. This causes the images to overlap
> slightly. Changing the DOCTYPE to strict will results in the correct output..
> 

The transitional doctype is required because the 'vspace' attribute is used in the test case. The overlap of the images don't really matter in this particular case and it is perfectly fine to have them overlap.

> 2) ---------
> chapter_8\border-width-005.xht
> chapter_8\border-width-006.xht
> chapter_8\border-width-007.xht
> chapter_8\border-width-008.xht
> 
> Incorrect test: the computed value of property border-width at element
> 'body' is 0, because border-style is 'none'. The value 'inherit'
> inherits the computed value, so at element div.test the border-width is also 0
> and no rectangle is shown. (Chrome, FireFox and Opera render this correctly,
> by displaying only one square).
> 

Corrected all the border-width cases.
 
> 3) ---------
> chapter_9\display-008.xht
> 
> Invalid test. Only the first row is part of the table row group that has a blue
> background.
> 

Corrected text to reflect the case.

> 4) ---------
> chapter_9\inline-formatting-context-017.xht
> 
> Test expects the text to fit on two lines where the first line is justified.

I see no issue here. The test always has two lines of text. If you are zoomed or text size is increased then you violate the rules for running the test suite cases. Those guidelines state you have the browser defaults.

> 5) ---------
> chapter_9\positioning-float-002.xht
> 
> The width of the container is not big enough to fit all the text.
> Besides that the test is rendered correctly.
> 

At the default font size the text is able to fit  correctly. It seems as if you are not running at the browser default font setting.

> 6) ---------
> chapter_9\viewport-004.xht
> 
> Frames are not supported in CSS, expected HTML-xxxx test.
> 

Frames are supported by markup languages and CSS does mention that user agents may render more than one canvas. That is what this test is testing. There is no need to rename the file because this is a valid XHTML 1.0 Frameset test case.

> 7) ---------
> chapter_16\text-align-white-space-003.xht
> chapter_16\text-align-white-space-008.xht
> 
> We consider both test as incorrect tests: only pre and pre-line (not
> pre-wrap) cause text-align value 'justify' to be replaced by its initial value.
>

I believe the spec has not been updated with this change. All UAs that I could find reset to the initial value when text-align is 'pre-wrap'. It just looks like a spec issue right now. It is actually issue #53 http://wiki.csswg.org/spec/css2.1#issue-53 I need to update the issue with test cases.

> 8) ---------
> chapter_16\white-space-control-characters-001.xht
> 
> #22 is the Unicode character for 'Synchronous Idle', but no font was found
> that displays it as mentioned in the test description.

Fixed case to not mention the rendering of the character.

> 9) ---------
> chapter_16\word-spacing-remove-space-002.xht
> 
> Looks like IE8 specific behavior.
> 

This is specified behavior in the 'word-spacing' property definition.

# Word spacing algorithms are user-agent dependent. Word spacing is also influenced by justification (see 'text-align' property). Word spacing affects each space (U+0020), non-breaking space (U+00A0) left in the text after the white space processing rules have been applied.

> 10) ---------
> chapter_17\empty-cells-exceptions-004.xht
> 
> Whitespace is preserved in the table, so whitespace between <table> and
> <tr> is considered non-empty content and is wrapped in an anonymous
> table-row and an anonymous table-cell.
> 

Even if white space is preserved it is then handled by the rules under section 17.2.1 #5. Since the anonymous inline box contains only white space the box basically is display: none. From what I read there are no changes necessary to this test case.

> 11) ---------
> chapter_17\table-height-algorithm-005.xht
> 
> CSS 2.1 specification does not specify how extra table height space should be
> distributed over the rows. Since a cell-height percentage computes to auto,
> all rows will get an equal part of the remaining space. A more sophisticated
> algorithm could inspect cell and row percentage heights and try to satisfy
> them.
> 

The spec does state how height percentage works however. Percentage is calculated off the containing block in this test case that is the table element. This is defined by section 10.1 #2 since table is a block level element. I believe that the spec is incorrect in stating that percentage is undefined. That isn't true, it is defined. That undefined clause needs to be removed from 17.5.3 paragraph 2, the last sentence or it needs to be clarified further.

If we follow the rule from Chapter 10... The table is 4em high. If you take a 25% of that you get 1em. This is the result of the blue box. So far everything works out ok. Now the next part how high is the second row, cell? In this case it doesn't matter since the cell is black and the background of the table is black. The only thing that matters is that the blue box is shorter than the remaining part of the black box.

Note: that the assert is actually incorrect and I have updated that to correctly reflect the test case but the case itself is fine.

> 12) ---------
> chapter_18\outline-width-095.xht
> 
> We consider this test as invalid test: In div1, the computed value of outline-
> width is 0, because outline-style is none (the default value).
> The 'outline-width: inherit' inherits this computed value, so the width of the
> outline is zero.
> 

You are correct this is incorrect. I have corrected the case.

Please let me know if I missed anything or I an incorrect with a resolution.

--
Thanks,
Arron Eicholz

Received on Monday, 1 February 2010 22:38:20 UTC