W3C home > Mailing lists > Public > www-svg@w3.org > October 2015

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

From: Koji Ishii <kojiishi@gmail.com>
Date: Fri, 2 Oct 2015 17:20:51 +0900
Message-ID: <CAN9ydbVhikUHoLNPsaK4LKAv8FD2dAdTgM3KYyhbhDTdY4h7pw@mail.gmail.com>
To: Doug Schepers <schepers@w3.org>
Cc: Dirk Schulze <dschulze@adobe.com>, Erik Dahlström <erik@xn--dahlstrm-t4a.net>, www-svg <www-svg@w3.org>, fantasai <fantasai.lists@inkedblade.net>, Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, Cameron McCormack <cam@mcc.id.au>, Tavmjong Bah <tavmjong@free.fr>, Jonathan Kew <jfkthame@gmail.com>
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> 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> 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 (access code: 649 040 824)
>
>> IRC for minutes/discussion: #svg on 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
>>>>>
>>>>>
>>>>
>>
>
Received on Friday, 2 October 2015 08:21:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:03 UTC