- From: Koji Ishii <kojiishi@gmail.com>
- Date: Fri, 2 Oct 2015 17:20:51 +0900
- 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>
- Message-ID: <CAN9ydbVhikUHoLNPsaK4LKAv8FD2dAdTgM3KYyhbhDTdY4h7pw@mail.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