[webkit-dev] New Rich Text Editing Test suite

[Ryosuke Niwa]

I think we shouldn't be hard-coding 18px here:

{'value': '18px', 'pad': '<span style="font-size:
large">[foobarbaz]</span>', 'expected': ['<span style="font-size:
large">[foobarbaz]</span>', '<span style="font-size:
large">[foobarbaz]</span>'], 'command': 'fontsize', 'id':
'FS:18px_SPANs:fs:l-1_SW', 'desc': 'Change existing font size to equivalent
px size (should be noop, or change unit)'}

The pixel font value of font-size: large is different depending on whether
or not we're in strict/quirks modes and whether or not we're using fixed
font (at least in WebKit and probably in Firefox).  We should be using the
computed style value of the text instead.

- Ryosuke

On Fri, Oct 1, 2010 at 1:14 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> I also noticed:
>
> RTE2-CC_FN:a_FONTf:a-1_SI fontname 'courier' y y y y FAIL <font
> face="arial">foo[bar]baz</font> <font face="arial">foo[bar]baz</font> <font
> face="arial">foo</font><spanclass="apple-style-span" style="font-family:
> courier">[bar]</span><font face="arial">baz</font> Change existing font
> name to same font name, using CSS styling (should be noop)
>
> Isn't supposed to be fontname 'arial' instead?  There are 4 other tests
> below this one with the seemingly the same problem.
>
> - Ryosuke
>
> On Fri, Oct 1, 2010 at 1:07 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>
>> However, we pass JustifyLeft, JustifyRight, JustifyCenter even though we
>> also add BR in those cases.  I don't quite understand the difference
>> there...
>>
>> - Ryosuke
>>
>>
>> On Thu, Sep 30, 2010 at 6:58 PM, Roland Steiner <rolandsteiner at google.com
>> > wrote:
>>
>>> On Fri, Oct 1, 2010 at 10:49 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>>>
>>>> Mn... I realized something strange here.
>>>>
>>>> RTE2-AC_JF_TEXT-1_SC fails on WebKit TOT and the test is: JustifyFull on
>>>> "foo^bar".  However, it clearly works on WebKit when I test it manually.  It
>>>> generates <div style="text-align: justify;">foobar<br></div>.  I'm not sure
>>>> why the test claims that WebKit fails on this particular test.
>>>>
>>>
>>> That is probably one of the areas that needs discussion - the way the
>>> suite is set up currently, it doesn't allow for "superfluous" HTML elements.
>>> I.e., my guess is that it fails because of the extra <br> (ATM I don't have
>>> a TOT WebKit browser, so can't confirm for sure). I have added cases like
>>> this as "acceptable" (but not ideal) results for some tests, but not yet all
>>> of them (if we want to add this, then I guess I should implement some
>>> systematic way to check these rather than adding it by hand, though).
>>>
>>> Cheers,
>>>
>>> - Roland
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101001/094e3c70/attachment.html>