RE: [css3-linebox] Proposal to add "auto" value for the line-stacking-ruby property

Hi Dave,

Great to hear that WebKit took the way, and has already implemented. And yeah, I meant "overlap", sorry for
the confusion and thank you for pointing this out.

You're right that I was missing the case of the first line in paginated content. It's actually a good point.
Since author will not know which part of the document is the first line of pages, I agree that it should be
part of the behavior of "auto".

Given that, as you said, exclude-ruby is probably only useful for proof-reading purpose as far as I think.

I was thinking to add "auto" value, but if we ended up not being able to find any good use cases for
include-ruby/exclude-ruby values after this behavior is added, it may be better to change the section to
describe just the behavior rules and get rid of the property.

If anyone see use cases of include-ruby and/or exclude-ruby, I'd appreciate to know.

Regards,
Koji

-----Original Message-----
From: David Hyatt [mailto:hyatt <at> apple.com] 
Sent: Wednesday, December 01, 2010 3:02 AM
To: Koji Ishii
Cc: www-style <at> w3.org list
Subject: Re: [css3-linebox] Proposal to add "auto" value for the line-stacking-ruby property

For reference:

https://bugs.webkit.org/show_bug.cgi?id=49717

Re: [css3-images] Repeating oblique gradients

> For raster images the only sensible
>>> options are to do nothing (transparent everywhere outside the view
>>> box) or to tile it in some way (we chose simple tiling in one or both
>>> directions).  Gradients theoretically have infinite paint, so
>>> background-repeat:extend needs to be defined to give the option "just
>>> use the rest of the image outside of the view box".
>> 
>> Yes, and that effect would be fine for 'background-repeat:no-repeat', if we thing we would never need it
to not extend, or a new 'background-repeat:extend' if we want to have it optional. But I see no reason why
this should exclude the other 'background-repeat' values if the image is sized down to something less
than '100% 100%'.
> 
> I don't understand what you're trying to say here, and so expect that
> we're talking past each other.  background-repeat:extend will make the
> gradient fill the entire background layer with its paint.  

You act as though 'background-repeat:extend' has already been agreed to. All I am saying is that having an
'extend' value there is one idea. Another is to simply let it extend automatically when the value is
'no-repeat'. Which idea is best depends on whether or not it is important to allow 'no-repeat' without
automatically extending the color into the non-image area of the background. 

> Resizing the image via background-size just changes the default image
> sizing area, and thus the way the gradient draws itself.  It's
> irrelevant when considering how to fill the rest of the background
> layer.

Well, it's relevant to seeing with you eyes if the color extends or not, or to being able to see more than one
tile. 

> 

Re: [css3-images] Repeating oblique gradients

At this point I'm too confused about what you think I'm saying to be
able to usefully respond to this email.  I just know that there's
still significant lingering confusion where you're responding to
things that I'm not saying.

Can you restate what the problems you have are, so I can respond to
them directly?

~TJ

Re: [css3-images] Repeating oblique gradients

Issues with box-shadow spread

Hi all,

Re:

http://www.w3.org/TR/2010/WD-css3-background-20100612/#the-box-shadow

In reading the CSS Backgrounds and Borders Module Level 3 W3C Working Draft 12
June 2010 it occurred to me that the spread distance value of a box-shadow
property is not correctly specified.

Currently, the spec says that:

"""The fourth length is a spread distance. Positive values cause the shadow
shape to expand in all directions by the specified radius."""

However, in the Example XXVIII case, the "Spread Applied" contour does not
follow the word of the spec.  If you check the lower left, if one was to
follow the word of the spec, one would get a round corner, but what we see is
a acute corner.  Ie. the lower-left corner of the Spread Applied contour is
simply farther away from the lower-left corner of the box than the specified
box-shadow spread value.

What seems to be the *intent* of the spec is that, in Postscript terms, the
spread box is the union of the box and the result of the stroke operation,
with line-join=miter and an infinite miter-limit.  I can't describe it in a
simpler way.  Negative values of the spread can be prescribed as the box with
the stroke area removed instead of added.

behdad

Re: Issues with box-shadow spread

On Nov 30, 2010, at 9:15 PM, Behdad Esfahbod wrote:

> Hi all,
> 
> Re:
> 
> http://www.w3.org/TR/2010/WD-css3-background-20100612/#the-box-shadow

I do have to update that picture, because the blur doesn't match the spec any more.

> In reading the CSS Backgrounds and Borders Module Level 3 W3C Working Draft 12
> June 2010 it occurred to me that the spread distance value of a box-shadow
> property is not correctly specified.
> 
> Currently, the spec says that:
> 
> """The fourth length is a spread distance. Positive values cause the shadow
> shape to expand in all directions by the specified radius."""
> 
> However, in the Example XXVIII case, the "Spread Applied" contour does not
> follow the word of the spec.  If you check the lower left, if one was to
> follow the word of the spec, one would get a round corner, but what we see is
> a acute corner.  Ie. the lower-left corner of the Spread Applied contour is
> simply farther away from the lower-left corner of the box than the specified
> box-shadow spread value.

You must have missed this line:

"For corners with a zero border-radius, however, the corner must remain sharp—the operation is
equivalent to scaling the shadow shape."

> What seems to be the *intent* of the spec is that, in Postscript terms, the
> spread box is the union of the box and the result of the stroke operation,
> with line-join=miter and an infinite miter-limit.  I can't describe it in a
> simpler way.  Negative values of the spread can be prescribed as the box with
> the stroke area removed instead of added.

That is more or less accurate in PostScript terms.

Re: Implementation Report Template for CSS2.1 Test Suite

On 10/14/2010 06:18 PM, Geoffrey Sneddon wrote:
> On 10/08/10 02:03, fantasai wrote:
>> The rest of the lines give the test's local path and the result.
>
> This and the examples below (e.g., xhtml1/at-charset-001.xht ?) are different to what the template
gives, which doesn't have
> the extension. I guess the documentation and the template should match each other (I have no strong
opinion either way).

Should be fixed for RC4.

~fantasai

RE: [css3-ruby][css3-linebox] Proposal to add "auto" value for the line-stacking-ruby property

Dave,

Would you mind if I ask a question? It may be odd for me to ask this, but how accurate can a browser detect when
"ruby overlaps the previous line"?

Given the case of the first line after page break, I started to think if there were any other such cases. Is it
possible to share with us what you have in WebKit now?

Cases I thought are:
* Floating box moves to either left or right, so it can still detect where the previous line is.
* Text after floating box probably knows where the line before the floating box is.
* If the element has top or bottom (left or right in vertical) property specified, it's probably hard to
determine what the "previous" line is.

As far as I thought for a while, the top/bottom case and the first line after page break (and column break if
multicol) you mentioned are the only two cases where browser cannot know where the previous line is.

Do I miss any other cases?

Please note that I added [css3-ruby] to the subject just in case as the behavior of line-stacking-ruby is
written there.

Regards,
Koji

-----Original Message-----
From: Koji Ishii 
Sent: Wednesday, December 01, 2010 9:33 AM
To: 'David Hyatt'
Cc: www-style <at> w3.org list
Subject: RE: [css3-linebox] Proposal to add "auto" value for the line-stacking-ruby property

Hi Dave,

Great to hear that WebKit took the way, and has already implemented. And yeah, I meant "overlap", sorry for
the confusion and thank you for pointing this out.

You're right that I was missing the case of the first line in paginated content. It's actually a good point.
Since author will not know which part of the document is the first line of pages, I agree that it should be
part of the behavior of "auto".

Given that, as you said, exclude-ruby is probably only useful for proof-reading purpose as far as I think.

I was thinking to add "auto" value, but if we ended up not being able to find any good use cases for
include-ruby/exclude-ruby values after this behavior is added, it may be better to change the section to
describe just the behavior rules and get rid of the property.

If anyone see use cases of include-ruby and/or exclude-ruby, I'd appreciate to know.

Regards,
Koji

-----Original Message-----
From: David Hyatt [mailto:hyatt <at> apple.com] 
Sent: Wednesday, December 01, 2010 3:02 AM
To: Koji Ishii
Cc: www-style <at> w3.org list
Subject: Re: [css3-linebox] Proposal to add "auto" value for the line-stacking-ruby property

For reference:

https://bugs.webkit.org/show_bug.cgi?id=49717

This change to a more complicated "auto" behavior came about when we tried to make "exclude-ruby" the
default and ran into compatibility problems with existing Ruby on the Web.  

dave
(hyatt <at> apple.com)

On Nov 30, 2010, at 11:49 AM, David Hyatt wrote:

> On Nov 29, 2010, at 11:57 PM, Koji Ishii wrote:
> 
>> Hi All,
>> 
>> I would like to propose to add "auto" value to the line-stacking-ruby property:
>> http://dev.w3.org/csswg/css3-linebox/#line-stacking-ruby
>> 
>> This value behaves exactly same as "exclude-ruby", except when the ruby text overwraps with the
previous line, the UA should increase line spacing to avoid overwraps.
>> 
>> The idea is that, usually "exclude-ruby" is the correct behavior for the ruby text in most of cases, I
believe no one objects on this, but when the ruby text overwraps previous/next line, it splits; some wants
to increase the line spacing, while some wants to leave it overwrapped.
>> 
>> If you listen to people who wants to leave it overwrapped, it is because it makes them easier to find
issues, and it is considered to be editor's responsibility to take necessary actions depending on the
situation; sometimes increase line spacing for the line, sometimes increase all line spacing of the body
text, sometimes change the size of ruby text, and so forth. I believe no one wants to leave overwraps left as is.
>> 
>> I think "exclude-ruby" is very good for professional publishers, but I also think the default value
should be a little more friendly to the browser users. The "auto" value must help users to use their user
style sheets and prevents overwraps of ruby text over the previous lines, while keeping a good typography
when the line height has enough space for ruby text.
>> 
>> Any opinions are greatly appreciated.
> 
> I believe you mean "overlap" instead of overwrap?
> 
> It's an odd coincidence, but I just changed this behavior in WebKit about a week ago.
> 
> WebKit now implements this behavior by default for Ruby.  WebKit will not include the Ruby at first when
laying out a line, and if after it's done, some Ruby overlaps the previous line (or the next line in
vertical-lr), then the spacing is increased to accommodate the Ruby.
> 
> The one use case I can think of for line-stacking-ruby:exclude-ruby is in paginated content, you might
like the Ruby on the first line to be in the margin area of the page. Maybe that could just be part of the
default behavior at page breaks though.  If the property does have to exist, then that's fine I guess, but
the default should not be "always exclude" or "always include."
> 
> dave
> (hyatt <at> apple.com)
> 
> 

[css-ruby] Proposal to publish new WD

Folks,

I'd like to publish the version of the CSS3 Ruby Module at http://dev.w3.org/csswg/css3-ruby/ as a new WD. 
This will take the ruby module out of CR and revert it to a Working Draft.

Before publishing I'd like to apply all change marks in the editor's version of the document, *with the
exception of* those in Section 4.1, so I'd like the Working Group to comment on whether those proposed
changes are controversial.  They are essentially editorial in nature, but note, in particular, that I
have replaced most references to JIS X-4051 with references to Requirements for Japanese Text Layout (http://www.w3.org/TR/jlreq/).

I expect all editorial notes and change marks in section 4.1 to remain.

I'd like to ask the Working Group to take a decision to publish the new version.

Thanks,
RI

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/International/
http://rishida.net/

RE: [css3-text] text-emphasis marks in Tibetan