Re: agenda+ css-writing-modes-3 review

On Oct 2, 2015, at 5:22 AM, Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com<mailto:amelia.bellamy.royds@gmail.com>> wrote:

Thanks for the outline of the specific outstanding issues, Koji,

I will be on the call next week, and between now and then I will look into the issues and test cases you and fantasai have brought up.

Quite frankly, existing implementations of the SVG vertical writing spec are so inconsistent and/or incomplete, and the spec itself is so vague in places, that I have no problem setting an interpretation based on consistency with the new spec.  (Maybe implementers will disagree!)  But either way, it's good to then have a clear list of which previously undefined behaviors we are now defining, and where existing implementations need to change.

Since Adobe’s authoring tools and authoring tools from other vendors already use vertical text in the SVG export I would not mind if we take more than just browsers under consideration :) Anyway, I will try my best to review the issues and comment next week before the meeting.

Greetings,
Dirk


Amelia


On 2 October 2015 at 04:20, Koji Ishii <kojiishi@gmail.com<mailto:kojiishi@gmail.com>> wrote:
Dirk and Doug,

In addition to what Doug said, a bit more clarification is appreciated. The clarification is blocking the spec to go CR, and two implementers appreciate the clarification for their work doing right now; Jonathan is working on it right now for Gecko, and I plan to do it next week for Blink.

fantasai might explain this better in the conf call, but here's a summary.

1. The spec defines "treat as" map[1] between CSS and SVG values. Does that mean values in this table are completely equivalent, or does some of them have different semantics and the map indicates super/subset relationships? If equivalent, it means that "lr" and "rl" for instance behaves exactly the same.

2. If equivalent, can we pick one of the equivalent values as the canonical value? This will affect CSS serialization, which is used by getComputedValue and a few other places; whenever you parse CSS but then later want to stringfy, serialization kicks in.

3. If not equivalent, which value is not equivalent, and how is it different?

I can read from SVG specs that writing-mode lr/rl sets "the initial inline-progression-direction" and direction ltr/rtl sets "the base writing direction", but I couldn't find what "the initial inline-progression-direction" is from the spec.

If these two terminologies actually are the same thing, and "writing-mode lr/rl sets the initial inline-progression-direction" is not a valid definition, these values can be equivalent. Blink does so, and from the tests, other browsers seem to be doing so too.

Given that, Jonathan and I prefer these values are equivalent, and pick the current CSS values as canonical. We appreciate SVG WG thoughts and resolution on this.

[1] https://drafts.csswg.org/css-writing-modes-3/#svg-writing-mode-css


/koji


On Fri, Oct 2, 2015 at 1:21 PM, Doug Schepers <schepers@w3.org<mailto:schepers@w3.org>> wrote:
Hi, Dirk–

Fantasai wrote up the results from the discussion and wants the SVG WG to confirm that it matches what was agreed.

Regards–
–Doug


On 10/2/15 12:14 AM, Dirk Schulze wrote:

On Oct 1, 2015, at 4:08 PM, Doug Schepers <schepers@w3.org<mailto:schepers@w3.org>> wrote:

Hi, Dirk, Amelia, Cameron–

We decided that we need (at least some of) you on the telcon to
really deal with this issue and help move the CSS Writing Modes 3
spec to CR.

Are you available to be on the telcon next week?

I wonder what the issue is. I thought we resolved the last open
issues at the FX TF meeting in Paris a couple of weeks ago?  fantasai
and Cameron were both it the meeting and overruled me :D. I myself
will not be able to join.

Greetings, Dirk


Tav is going to be reviewing the spec in depth, and you can
coordinate with him to provide feedback, if you can't be on the
telcon.

Thanks– –Doug

On 9/30/15 9:58 PM, Doug Schepers wrote:
Hi, Erik–

Can we please add the CSS Writing Modes 3 spec review to the
agenda? Fantasai says she needs our feedback on 2 issues (listed
below), and she's available to attend the telcon tomorrow to
explain the issue.

(Fantasai, telcon details below in Erik's original agenda
email.)

[[ I'm blocked on the SVGWG here:
https://drafts.csswg.org/css-writing-modes-3/issues-cr-2014


Two issues require SVGWG review

first one is
https://lists.w3.org/Archives/Public/www-svg/2015Sep/0016.html


That's the one that needs review of spec wording

second issue is this
https://lists.w3.org/Archives/Public/www-svg/2015Sep/0017.html


The question on hand is whether we can fold 'writing-mode: rl'
and 'writing-mode: lr' together

From a CSS perspective, they're the same

The different values don't affect anything in the CSS model

They're both horizontal writing modes, and the rl vs. lr doesn't
affect bidi

But the SVG spec says they affect the "inline progression
direction" and I can't figure out what that means or should have
an effect on

But it's quite clear that it doesn't affect reordering!

There's a test file here
https://lists.w3.org/Archives/Public/www-svg/2015Sep/att-0027/test.svg




which does very interesting things in Presto

but otherwise renders the two values identically in Blink and
InkScape

So, yeah, have fun with that?

maybe someone in the group knows what the SVG spec was trying to
say, and whether or not it was important ]]

Regards– –Doug

On 9/30/15 4:46 PM, Erik Dahlström wrote:
Please find the agenda for this week’s telcon below.

Time:
http://www.timeanddate.com/worldclock/fixedtime.html?month=10&day=1&year=2015&hour=20&min=30&sec=0&p1=0





Phone: +1-617-324-0000<tel:%2B1-617-324-0000> (access code: 649 040 824)
IRC for minutes/discussion: #svg on irc.w3.org<http://irc.w3.org/>, port 6665
Agenda requests: http://www.w3.org/Graphics/SVG/WG/wiki/Agenda

WebEx logistics: https://www.w3.org/Graphics/SVG/WG/wiki/WebEx


Agenda:

* Path stroking for paths that end with tight curves (Tav)
http://tavmjong.free.fr/blog/?p=1257


* Declarative animation and conformance
https://github.com/w3c/svgwg/issues/23


* SVG 2 chapter progress