W3C home > Mailing lists > Public > www-style@w3.org > November 2010

Minutes and Resolutions TPAC F2F 2010 Monday Morning: Transforms, EPUB, CSS2.1 test suite, Bidi Images and Lists

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 16 Nov 2010 15:43:23 -0800
Message-ID: <4CE3171B.7000602@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
2D Transforms
-------------

   - Discussed next steps and blocking issues for CSS 2D Transforms
   - RESOLVED: Discuss an API to parse the specified value into an
               author-convenient form, before pushing CSS 2D Transforms
               spec forward.
   - RESOLVED: Any Transforms tests that can be reftests must be reftests.
   - RESOLVED: Remove the value API from 2d Transforms.

EPUB Liaison
------------

   Markus Gylling, AC rep of DAISY consortium, visited to talk about
   EPUB and the IDPF and coordination with the CSSWG. Discussion topics
   included:
     - IDPF process, and comparison/contrast to W3C process
     - EPUB goals and status of relevant CSS drafts
     - CSS3 Speech; EPUB plans to send an editor to move it forward.

CSS2.1 Testing
--------------

   - RC3 published last week as a snapshot: planning RC4 as a
     "known bugs fixed" release.
   - RESOLVED: Target Nov 22nd for CSS2.1 test suite RC4 freeze.
   - RESOLVED: Target Dec 8th for RC4 implementation report
               submissions; telecon dedicated to reviewing test
               changes and completing IR.

Bidi Images and Lists
---------------------

   Aharon Lanin introduced his proposals to solve two problems:
     - Ability to automatically flip images for RTL.
       (This will be considered for css3-images.)
     - Ability to assign list item marker position to match
       list directionality rather than item directionality.

====== Full minutes below ======

Present:
   Tab Atkins
   David Baron
   Bert Bos
   John Daggett
   Elika J. Etemad
   Sylvain Galineau
   Daniel Glazman
   Markus Gylling (observer)
   Soonbo Han
   Koji Ishii
   John Jansen
   Håkon Wium Lie
   Peter Linss
   Markus Mielke
   Alex Mogilevsky
   Ilkka Oksanen
   David Singer
   Anne van Kesteren
   Steve Zilles

Agenda: http://wiki.csswg.org/planning/tpac-2010
<RRSAgent> logging to http://www.w3.org/2010/11/01-CSS-irc
<RRSAgent> http://www.w3.org/2010/11/01-CSS-minutes.html

Scribe: Tab Atkins

Agenda
------

   <tabatkins> glazou: First agenda is the agenda.
   <glazou> http://wiki.csswg.org/planning/tpac-2010
   glazou: What's most timportant?  I think we need clilley for the
           charter discussion.
   jdaggett: Two things I want to discuss tomorrow are Fonts and Writing Modes.
   sylvaing: We'd like to do Grid first thing tomorrow morning.
   Bert: We have a guest who wants to talk about Writing Modes, and Mike.
   glazou: Microsoft guys, wanna talk about Flexbox before Grid?
   sylvaing: Not that important, just want to talk about both.
   glazou: We can probably start this morning with css3 values.
   glazou: FXTF wants to take ownership of 2d transforms.  But I want the WG
           to talk about it too, even if only for a little bit.
   glazou: Markus Gylling is here, so can we talk about EPUB liaison stuff
           later this morning?
   Markus Gylling: Yes.
   glazou: Slow font downloading, should it be lumped with CSS3 Fonts?
   jdaggett: Yes, and hopefully Tues afternoon, because Slye will be here then.
   glazou: So I suggest we start with 2d transforms, epub, and css2.1
           testing this morning.

Transforms
----------

   glazou: We now have 4 impls on the table: gecko, webkit, opera, and ms.
   glazou: We need tests.  If we have interop impls - I suppose we have a
           fairly good level of interop - I think we can move pretty quickly
           to REC.
   sylvaing: We have some things that need to be resolved, like the DOM
             interface relying on some obsolete stuff.
   sylvaing: No one but Webkit implements it yet, I think.
   anne: Maybe we should drop it for now until we figure out what we want
         to do with the Values APIs.
   glazou: I think marking as at-risk would be better.
   dbaron: The section on Transitions has several bugs in the spec. bzbarsky
           forwarded a message from Tim Terriberry explaining several of them,
           and you can see these bugs in Webkit.
   <sylvaing> CSS3 2D Transforms transition/animation section:
              http://www.w3.org/TR/css3-2d-transforms/#animation
   dbaron: The other issue is transforms that affect layout.
   dbaron: I could see getting a first version to REC without that, but I'd
           rather fix it first.
   jdaggett: Isn't that a big issue?
   dbaron: Not necessarily.
   dbaron: Some big things, but some small things.
   sylvaing: That affects things like offsetTop, etc.
   dbaron: Right, but they kind of suck without a layout-effecting transform
           anyway.
   sylvaing: It would definitely lengthen the time it would take to get to CR.
   dbaron: Yeah, I think it does make sense to move it to CR first without this.
   szilles: I drafted a spec for the layout-affecting Transforms 2 or 3
            years ago.  It's not bug-free, but it exists - we won't be
            starting from scratch.
   anne: The concern is that nobody's tried to ipmlement it yet.
   anne: I think that Transforms should redefine the boxes that already exist
         when transformed; the border box should get bigger, etc.
   anne: So I don't have to constantly reference Transforms when talking
         about boxes.
   dbaron: You've got 3 or 4 boxes now.
             1) Element in its original coord space.
             2) Element in the transformed coord space.
             3) Rectangle containing the 1st in the 2nd coord space,
             4) Rectangle containing the 2nd in the 1st coord space.
   anne: I think browsers act like the transform didn't happen for now.
   anne: Which works for me - if the border box doesn't change, and only
         alters for painting, that's easy.
   anne: At some point Dean asked me to draft an api that was aware of
         transforms, but I wasn't sure how to do it.
   sylvaing: We have 4 impls, is what we have enough for authors?  Are
             we missing use-cases?
   dbaron: I think we're definitely missing use-cases, but I think we're
           still okay to move forward.

   glazou: I'd like to talk about canonicalization of the computed value.
           When you query a transform, I think all browsers respond with
           a matrix, which is totally unuseful for authors.  Is there
           something we could do to ease this pain?
   anne: I think that, as a string value, having the matrix is fine and
         the most sane.  But I think when people start prototyping the
         Values API, we'll get a dedicated api for transforms.
   jdaggett: Once you compose several operations, the matrix loses the
             state.  You can't get the compounded effects anymore.
             So, glazou, what do you want?
   glazou: For example, if you have a rotation and want to rotate it a
           bit further, it's a huge pain.
   sylvaing: You can do that now through the matrix api, but it uses
             CSSValue, which we're not going to implement.
   jdaggett: Like, if you do a rotate, transform, rotate, you lose
             something.  What do you want to show to authors?
   glazou: The three operations, hopefully - a stack.
   dbaron: We have to store that information and pass it through anyway
           to do the transitions.
   glazou: I feel that as a web author, releasing this without having a
           way to get the scale/rotate/etc of the transform is bad.
   dbaron: Do you really need it at the computed level?  Is specified
           enough?  You already have it on the specified level.
   glazou: Yes, but it's a string that you have to parse, which is unacceptable.
   tabatkins: So make Anne work on the Values API faster.  ^_^
   szilles: What does SVG do?  Also, is the matrix decomposition unique?
   dbaron: There's a reference to an algorithm for a unique decomposition,
           but it's buggy (I raised this earlier).
   dbaron: I think that authors want back the order they originally specified,
           though, rather than some canonical transform.
   <anne> tabatkins, the last on that is that people should start experimenting
   sylvaing: Also, SVG can do each transform from a different origin, while
             CSS does the whole thing from a single origin.
   Anthony (SVG): Doesn't look like SVG has a neat way of getting back
                  the original transforms either.
   glazou: Sounds like something we can discuss in the FXTF meeting.
   RESOLVED: Discuss an API to parse the specified value into an
             author-convenient form, before pushing the spec forward.

   glazou: Next, tests.  What kind of tests do we need for Transforms,
           who will write them, what schedule?
   glazou: Corollary - do we have enough interop that we can remove prefixes?
   dsinger: If Transitions is going to move slower than Transforms, we
            should move the section on Transitioning Transforms to the
            Transitions spec.
   anne: Can we require that this testsuite only has reftests?
   johnjan: No, we can't require it.
   anne: Why not?
   tabatkins: Can we resolve that everything that *can* be reftests,
              *must* be reftests?
   johnjan: Yeah, that's acceptable.
   RESOLVED: Any Transforms tests that can be reftests must be reftests.

   dbaron: We have 107 reftests for Transforms.  I'd need to ensure
           they're all test-suite worthy.
   glazou: We'd probably need a lead on the 2d testsuite.
   johnjan: I can do that.
   <dbaron> (also a bunch of parsing tests)
   glazou: dbaron, can you estimate how many tests we might need for the
           Transforms spec?
   johnjan: My gut says a few hundred.  Right now we have far too few, at
            least.  I'd like to look at SVG and Moz testcases and see how
            we interop.
   <anthony> SVG test suite is here: http://dev.w3.org/cvsweb/SVG/profiles/1.1F2/test/svg/?sortby=file#dirlist
   dbaron: Also, a whole lot of our Transforms tests are in our Transitions
           tests now, because I wrote a whole lot of tests about
           transitioning transforms.
   <anthony> Transforms tests specifically: coords-transformattr-01-f.svg -
             coords-transformattr-05-f.svg and coords-trans-01-b.svg -
             coords-trans-14-f.svg
   glazou: 4 impls signals that impls are very interested in this. If we can
           move fast on this it would be a good signal to the w3c.
   glazou: So, maybe a CR/PR by June would be awesome.
   glazou: Are there immediate actions we can take on the spec, like
           removing the Transition section, mark layout as at-risk,
           remove the value api?
   RESOLVED: Remove the value API from 2d Transforms.

   shepazu: Once you've transformed, getting a point back is no longer in
            screen space, and there's some tricky transforms you need to do.
   shepazu: So people are going to get a point, expect it to be in one place,
            and it's not there.
   shepazu: It's a tricky solution but that can be exposed simply for authors.
   shepazu: smfr already has a very good idea of what's evolved there, and
            he'll add it to the 2d transforms spec.

glazou: More agenda!
glazou: howcome, we have some things for you.
howcome: 15 minutes each, they're all easy.  ^_^
glazou: today, beginning of afternoon?
howcome: Yeah.


EPUB Liaison
------------

   Gylling: I'm the AC rep of the DAISY consortium, but here today for
            EPUB and the IPDF.
   gylling: This isn't really intended to be a primer for epub, so let's
            move quickly through that.
   gylling: In the current revision of epub, we have adobe, apple, google,
            and other organizations working with us.
   gylling: What makes epub stand out in the ebook wars is that epub uses
            w3c standards as the highest priority.
   gylling: epub is currently undergoing a revision; version 2 has been
            out for several years, and the new one started this year.
            We'd like to have the new one out by May 2011.
   jdaggett: What does that mean?  Final spec, or impls?
   gylling: Final spec.  The ipdf bylaws do not echo the w3c in requiring
            2 independent impls.
   gylling: Of course, as we use existing web techs, generally there were
            already sufficient impls by the time we used something.
   gylling: But the situation is becoming somewhat more tricky now.
   gylling: bert, you sent a few questions earlier?
   Bert: Last time we talked about epub, we tried to discover which
         documents on the epub wiki were important; which dates, what
         schedule, etc should we look at?
   <mgylling> http://code.google.com/p/epub-revision/wiki/ImplementationPipeline
   gylling: This is the current schedule.
   <tantek> greetings from SF.
   <tantek> sorry I couldn't be there in person!
   gylling: So we started out this summer collecting requirements.
            it was an open-ended process initially.
   gylling: In our SF meeting two weeks ago, we deferred/postponed a large
            number of our requirements.
   gylling: So we now have a smaller set of requirements that can be reviewed.
   gylling: This is what the epub wg has set out to have done by May next year.
   gylling: There are a few outstanding items, that we'll talk about tomorrow.
   gylling: But one of th emajor things we intend to do in this revision
            is to increase ou support for i18n.
   gylling: Writing Modes is one of the most critical features for us
           right now in epub.
   gylling: The ipdf bylaws enumerates the process to use.  Right now the
            ipdf doens't have an established rule that there must be two
            independent implementations of each feature.
   gylling: Inverting the question, though, would an implementation in an
            ebook device suffice to satisfy the w3c requirements?
   Bert: That's what I was trying to get at.  Are your results public?
   gylling: If we can submit test results based on ebook devices, there's
            not a bunch of problem.

   jdaggett: There's a bit of dependency problem, where there are some
             drafts that haven't even reached first public draft yet.
             It seems like that would cause  some problems for you guys.
   <dbaron> http://dbaron.org/css/test/2010/transition-negative-determinant
            is a testcase showing some of the issues with animation of
            transforms, and
            http://lists.w3.org/Archives/Public/www-style/2010Oct/0440.html
            is the post by Tim Terriberry suggesting an approach to fix that
   * sylvaing Billy Idol just entered the room. Or Mike Smith.
   fantasai: I'm trying to stabilize the specs as fast as possible.
   fantasai: If we cannot come to any conclusion on the logical directions
             issue, we can just not deal with it and do it later, though
             I'd not like to.
   jdaggett: I just don't believe we should be making any kind of promise
             until there is some kind of consensus in this group.
   howcome: There seems to be some kind of consensus that epub has accepted
            the alternate stylesheet approach.
   fantasai: Right.  I think epub is clear that Writing Modes is unclear
             until after TPAC.
   szilles: We shouldn't be having a discussion about what we'll do after
            a discussion until after the discussion.
   howcome: If I'm right, you're aiming for a per-document writing-mode
            switch, right?
   fantasai: Right, though you'll have some form of mixed content.
   fantasai: In terms of being able to switch the entire stylesheet, epub
             has accepted the alternate stylesheet mechanism.
   fantasai: Also, epub has their own way of handling unsupported features,
             so fallback isn't something we have to address *for epub*.
             CSS should address that for themselves, but we don't have to
             worry about that as much.
   <dbaron> But how we want implementations that don't support something
            to handle it is often fundamental to the design rather than
            something you tack on at the end.

   howcome: CSS now has a way to do running headers and footers.  Will
            epub adopt that as well?
   gylling: Our rendering stuff is generally going to be replaced by
            references to css 2.1.  We haven't discussed running headers
            and footers yet, but expect that we'll be able to refer to
            the CSS spec.
   Bert: How does your collab/discussion process work?
   Bert: If we have a question, how do we send it?
   gylling: I think the easiest is to set up a liaison.
   gylling: They would participate in our weekly telcons and our mailing
            list, which is public.
   jdaggett: The way epub is set up, different "working groups" handle
             different areas.  One handles i18n, another handles styling, etc.
   jdaggett: I think there's a minor dependency on CSS3 Speech?
   gylling: Right - i18n and css aren't the only thing.  We also need,
            frex, pagination.
   howcome: What do you mean by pagination?
   gylling: Dynamic reflow and pagination.  Also page templates.
   gylling: The feature that overshadows everything else is Writing Modes,
            though.
   Bert: I'd like to have some names to follow who know what's going on.
   kojiishi: I'm fine with being the liaison for egls (?), but would like
              someone else that can handle the other groups.
   gylling: I think the main group is 21:00utc, and all the other groups
            will be re-merging, so everyone should have this as well.
   MikeSmith: kennyluck has some insights into the vertical text issues as well.
   discussion of timezones
   fantasai: I can attend the epub telcon - it's at a sane time in pacific
             timezone.
   gylling: So if I understand correctly, we have a liaison, we'll find
            out if ebook impls can serve as impls for tests.
   fantasai: ebook readers can certainly serve.
   fantasai: But multiple WebKit implementations don't count as multiple
             independent implementations.
   Bert: Also a question is the test format.
   gylling: I think epub with write access could do the tests in css
            format and contribute the results directly.
   Bert: Are there resources set aside for testing purposes?
   gylling: I can't give you firm numbers, but yes, there will be
            resources for testing.
   Bert: Any idea how many impls you expect to exist?
   gylling: Can't say.  But in terms of rendering, there are 4 separate
            entities, only one of which is based on webkit.

   gylling: CSS3 Speech now.
   gylling: One of the things we're doing in epub is to enhance, for a11y
            reasons, speech synthesizers.
   gylling: We'd like to bring new life into the css3 speech module.
   gylling: The daisy consortium has a person we'd like to submit as a
            new editor.
   glazou: No problem.
   jdaggett: As long as they're a W3C member.
   fantasai: I looked over the spec, and I think claudio did a good
             job of cleaning it up.
   * dbaron doesn't see css3-speech in http://www.w3.org/Style/2008/css-charter
   fantasai: I think there's a section we should keep, another we should
             drop, but otherwise sounds good.
   glazou: Is there already interest in implementing it?
   gylling: Yes, especially from the a11y who wants to interact with epub.
   szilles: There was a point when some phone/voice companies wanted to
            go with a completely different approach; I don't remember
            the details, but it seems that we should get whatever we're
            doing reviewed by the mobile community.
   gylling: The people you mentioned are currently meeting as the Speech
            Incubator group.  I'll be meeting with them.
   glazou: Could you report to the WG after you meet with them?
   gylling: I'll try.
   <myakura> re css3-speech, WebKit implemented 'speech' property about
             a month ago. http://webkit.org/b/46827

<br type='coffee' />

CSS2.1 Testing
--------------

   round of intros
   <ilkka> my name is Ilkka Oksanen
   glazou: Test suite current status?
   fantasai: Published a snapshot last week.
   fantasai: I haven't done any work on it since then.
   dsinger: Because it's perfect?
   fantasai: No, I've just been working on other stuff.
   fantasai: There's still a lot of error reports that haven't been addressed.
             I'm guessing a couple weeks.
   glazou: What are the IR results? How many tests that don't pass 2 impls?
   plinss: As of RC3, 135 marked as invalid that havne't been updated yet,
           908 tests that are considered required that don't have 2 passes.
   tabatkins: To be clear, a lot of those tests are rc3 and haven't been
              tested by several browsers yet.
   jdaggett: Question on what versions are allowed?
   plinss: Public availability, and results must be a month old.
   jdaggett: I have a problem with using source-code versions, because it's
             hard to ensure that I run the exact same version that the test
             results were generated for.
   jdaggett: I think we should require a public *binary*, not just source.
   tabatkins: So, we only release binaries for our public channel, every
              6 weeks or so.
   johnjan: So, IE9 developer previews count?
   jdaggett: Sure, as long as we can get historical versions that the suite
             was run for.
   johnjan: I'll check to see if, say, when we release preview 7, if preview
            6 is still available.  if not, I'll stick with beta.
   dsinger: Are there tests that are failing because the spec is wrong?
   dbaron: There were some, yes.  I marked some of them, but others I didn't
           feel strongly enough about to file a bug about.
   dbaron: There were some invalids where the test was requiring something
           the spec doesn't actually require.  There were some that were
           actually testing the wrong thing.  And then there was a third
           category that were testing something where I believe the spec
           itself was wrong.
   glazou: I'd like to see all info about that in front of the group as
           soon as possible.
   dsinger: I'd just like a good wiki page somewhere that lists all the
            tests in each of those categories.
   dsinger: And then slowly see that page empty out until we're done.
   dbaron: I've gone through every mozilla failure and figured out if it
           was a bug in the test or in our impl, based on what the spec
           currently said.
   dbaron: There were some places where the test was testing things the
           spec didn't require and I could have marked invalid, but I
           went ahead and marked it a mozilla fail because our actual
           behavior was so wrong.  Like Lists numbering, frex.
   fantasai: CSS3 Lists defines list numbering, but CSS2.1 doesn't.
   glazou: My problem is that I don't have any stable visibility on the
           status of the testsuite.

   jdaggett: So what are you proposing, daniel?  A specific date?
   glazou: I propose we buckle down on CSS2.1 issues again.  I think that
           rather than cancelling the first conf call after tpac, we have
           it and talk about test suite.
   johnjan: Is Nov 15th still the date for not changing the testsuite,
            or at least just triaging at that point?
   fantasai: That's a little early. I'll need two weeks after this for
             my changes.
   johnjan: Yeah, and we'll also need to do reviews of the changes.
   johnjan: So is 2 weeks enough time?
   dbaron: What I want is, when we think we have all the changes done,
           I want to go through and rerun/reverify.  So that's a
           dependency there.
   fantasai: I think I'm about halfway through the reported issues in
             my tests, and have responded to each test issue email as
             I completed the fix.
   fantasai: But I don't know that arronei did it to all of his, and
             that would make it much more difficult to judge what all
             has been done.
   johnjan: So we can review the changes as they come in now, and on
            the 22nd review what's gone on and see if we're ready or
            we need another 2 weeks, etc.
   <dbaron> I just went through the list of things that I thought were
            "too silly to file a bug" on, and one more I noticed is
            the test that tests that the root element's background is
            propagated to the canvas even when the root element is
            display:none.
   glazou: So we'll have IRs based on the locked version by the end of year?
   johnjan: Early december, I think.

   plinss: [explains how results are handled in each version of the
            test suite harness, and how results are grandfathered over
            when tests don't change]
   jdaggett: Also, could you record the useragent language?  Some of
             the font tests are locale-specific.
   plinss: Yes, I have the useragent data, so I'll pull that data out.
   RESOLVED: Target Nov 22nd for test suite RC4 freeze.

   dbaron: Did you publish change lists from rc1-2, and rc2-3?
   fantasai: I think I did rc2-3.
   plinss: I have changed test data, so I can generate a list like that.
   <fantasai> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0369.html
   <fantasai> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0005.html
   ACTION fantasai: update links from W3C to implementation reports and
                    test suite releases
   <trackbot> Created ACTION-272
   johnjan: I'd like to bring up a question about a consistent place to
            store the impl reports - the .data files.
   johnjan: I can't find a consistent place, and I don't think attachments
            on the list are a good place to store them.
   plinss: I've put them in the rc1 and rc2 folders as appropriate.

   * dbaron wants to bring up an issue with Ahem-related tests
   dbaron: We have a large enumber of IR bugs because of one issue with Ahem
           fonts where the tests are questionably valid.
   dbaron: The Ahem font has a lot of glyphs that are boxes - they are exactly
           1em tall and wide.
   dbaron: The baseline of the font is 4/5ths from the top to the bottom
           of the font.
   dbaron: So all the ascent metrics are 80% of the em square, the descents
           are 20%.
   dbaron: So the issue is that if the ahem font is used at a size that
           is not a multiple of 5px, then the ascent/descent/x-height
           aren't a round number of pixels.
   dbaron: On Windows, our font metrics backend makes it okay.
   dbaron: We don't get good enough information anyway, so we just throw
           one out and subtract from the height.
   dbaron: But on Linux we get good info, so we use both the ascent and
           descent data, and both are rounded up.
   dbaron: So a pretty large amount of our test failures are because the
           Ahem font isn't a multiple of 5px.
   dbaron: I marked them as Moz bugs, but I could equally mark them as
           invalid, which could flip 50-80 tests.
   jdaggett: I think that in general we shouldn't be relying on rounding
             behavior.
   chrisl: And we don't have a canonical place to look for font data,
           since different font apis on different platforms return
           different data.
   alexmog: The spec doesn't say that fonts have to be round numbers of pixels.
   jdaggett: Yes, but the spec also doesn't specify how to round, so we
             can't rely on rounding in our tests.
   chrisl: Can we just ignore the fact that windows GDI does weird things?
           We have two impls that use correct platform behavior.
   <jdaggett> waterfall test for non-integer font sizes:
   <jdaggett> http://people.mozilla.org/~jdaggett/tests/decimalfontwaterfalls.html
   <jdaggett> alexmog: ^
   dbaron: The rounding behavior is part of freetype, actually.  I've tried
           to change our rounding behavior, but it actually broke several
           things, like text-decorations no longer lining up exactly.

   glazou: We need a way to report invalid/problematic tests.  Everyone
           should report invalid tests asap, and try to meet the guidelines
           we discussed today.
   dbaron: For the record, i went through all the mozilla failures. There
           were a small number of tests I gave up on.  I haven't gotten
           to those yet.
   dbaron: Some were font ones, which I handed to jdaggett.
   jdaggett: I fixed the tests.
   <dbaron> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0178.html
   <dbaron> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0175.html
   jdaggett: But the metric ones we still need to look at.
   dbaron: And also some margin-collapse issues, which I skipped because
           it takes me too long to try and figure out what's intended there.
   <dbaron> And the other Moz failures I didn't analyze were margin-collapse-157,
            margin-collapse-clear-005 and margin-collapse-clear-011
   chrisl: Perhaps that's a spec problem, if an implementor finds it too
           difficult to figure out from the spec what should happen.
   fantasai: Note we just rewrote that section of the spec.
   <johnjan> so 11/22 for Elika's changes to the Test Suite, 12/8 Conf Call
             for getting complete on reviewing those test changes and
             completing the IR submissions.

Internationalization
--------------------

   Richard ishida and Aharon Lanin introduce themselves
   also David Clarke (sp?)
   also kennyluck
   fantasai: The point of i18n is to make everyone in the world happy
             with our technologies.
   fantasai: 2 major topics: bidi, and vertical text.
   fantasai: We're doing vertical text tomorrow.
   fantasai: aharon wanted to discuss bidi-related proposals for css3.
   Aharon: First thing i wanted to discuss was a couple of new proposals
           that I emailed to the list last night.
   Aharon: Second is to get a feeling on the acceptance level on the
           other bidi stuff that has been dsicussed over the last year.

   Aharon: New stuff.  (1) A small addition to Images.
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Nov/0000.html
   Aharon: I'd like an ability to flip an image based on directionality.
   <myakura> http://www.w3.org/International/docs/html-bidi-requirements/#image-flip
   Aharon: One option is an 'rtlflip' keyword, so the image would be
           flipped horizontally when the direction is rtl.
   jdaggett: This isn't just bidi - vertical text may want to do rotations
             too.  So, this is a writing-mode thing.
   Aharon: The other way was to declare the directionality of the image,
           and then auto-flip as appropriate.
   Aharon: So if the image is ltr and the text is ltr, leave it alone.
           If the text is rtl, then flip the image.
   szilles: One slight modification; I think this is a much better way
            to go as it describes the image.  I think you need to separate
            the idea of the image directionality from whether or not to
            flip it.
   szilles: Because an image might be neutral in horizontal, but not in
            vertical.
   szilles: Would this apply to any replaced element?
   fantasai: If this should apply to replaced elements, this should be
             handed to the HTMLWG as this would be a content attribute.

   johnjan: One problem is backwards compat.
   fantasai: Not a problem in CSS, as you can count on the declaration
             being ignored in legacy and just add a fallback.
   szilles: So I'm hearing that we aren't intended to cover <img>?
   fantasai: For content images, in most cases I don't believe you'd
             generally want to flip those images.
   fantasai: The types of images you get in CSS are very often something
             you want to flip.
   fantasai: But images that belong in the content tend to be pictures,
             charts, etc. that you are much less likely to want to flip.
   fantasai: Now, if the use-case pops up and proves important, then at
             that point we'd push this back to the HTMLWG and ask them
             to fix the problem.
   szilles: Good, I just wanted to be clear on the scope.
   dbaron: should look into how this interacts with Exif orientation
   dbaron: Didn't we have a boolean to honor the exif orientation?
   dbaron: We had a spec somewhere relating to EXIF transformations and
           similar.  We might want to think about how this transformation
           compounds with the exif orientation.
   <fantasai> http://dev.w3.org/csswg/css3-images/#image-orientation
   * fantasai notes that the spec there needs updating to add back that
              auto value
   tabatkins: If honored, it should happen at a level below the rtl flipping.
   dsinger asks why exif data is not honored
   dbaron: While it's arguably correct to honor the EXIF orientation,
           there's probably a lot of web content that depends on EXIT
           not being honored.
   dsinger: Any image editor that doesn't set EXIF correctly is buggy.
            It's not our responsibility to fix their bugs.
   tabatkins: We can't break webpages either.
   howcome: We should mandate a default behavior of not honoring, and
            have a property allowing honoring it.
   dbaron: Also, theoretically attr() and Generated Content could let us
           handle <img>s in HTML.

   <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Nov/0004.html
   <fantasai> btw, I would suggest the syntax
                list-style-direction: left | right | start | match-parent
              (parallel with text-align)
   Aharon: Next topic.  You have list-style-position, which lets you put
           the marker inside or outside.
   Aharon: I'm only talking about the outside case.
   Aharon: Currently the bullet goes on the "start" side, based on the item's
           directionality.
   Aharon: Which sounds reasonable, until one realizes that one often has a
           list where the items are mixed directionality.
   Aharon: For example, a bibliography where some are english and some are
           hebrew.
   Aharon: The obvious answer is to put @dir on the <li>s directly, but that
           swaps bullets around inconsistently.  so you have to instead wrap
           a span and tag *that* with directionality, which is suboptimal.
   Aharon: Further, the list itself creates a gutter for the bullet based on
           the list's direction.
   Aharon: If the bullets are mixed, then the bullets for items in the other
           direction are often invisible because they're off-page.
   Aharon: So my proposal is list-style-direction, which indicates the
           direction of the marker.
   Aharon: Four values: ltr, rtl, match-list, match-item.
   dbaron: I'm inclined to think we should instead find the right answer,
           and not expose this directly at all.
   Aharon: The use-case for having it match item is that in arabic, they
           sometimes like having markers on different sides.
   dbaron: You said that the gutter for the list is a function of the list's
           direction.  I think that varies between browsers.  In gecko it
           should match the child's direction.
   dbaron: Wait, maybe I've got that wrong.  The gutter is always generated
           by the list.
   dbaron: Also, in CSS Lists, there's no concept of a "list", just list
           items.  So you'd need match-parent, not match-list.
   dbaron: What I think is that, semantically, in the case that you have a
           list with differing directionality items, the list-items
           themselves are all the same directionality, but the *content*
           has different directions.
   szilles: I'm curious why dbaron doesn't want a property there.
   dbaron: I don't think a full property is warranted to just change the
           behavior of a single value of another property.
   Aharon: Maybe we can just do this as another value on list-style-position?
           Currently 'outside' refers to the direction of the list-item.
           Maybe a 'list' value that would be like outside but use the
           parent's directionality?
   aharon: When you text-align anything but start, in IE the outside marker
           follows the text, so they don't line up.
   aharon: Webkit doesn't make the marker move, so they still all line up.
   aharon: In my opinion, the webkit behavior is more useful.  You can use
           list-style-position:inside to make the marker follow the text.
   dbaron: We received a ton of feedback from authors that they don't like
           the bullet being separated from the text.
   dbaron: This is also tied somewhat to issues of floats and such.  When
           the linebox is shortened we need to specify where the bullet goes.
   dbaron: Right now we tie the bullet to the first line box.
   tabatkins: It seems conceptually consistent to make 'outside' follow the
              list-item's text, but make the new value 'match-parent' or
               whatever line them up separate from the text.
   <fantasai> tabatkins, did you catch Aharon's last set of comments?
   dbaron: We still need to displace bullets from floats by match-parent
   aharon: Finally, I want to check on the status of the bidi things that
           I haven't been directly working on, which fantasai has been
           keeping on top of.
   glazou: Tab, could you keep up a wiki or something for an issues list
           for Lists?
   tabatkins: Yeah.
   ACTION Tab: Make issues list for css3-lists

   The minutes missed the following discussions:
     - Aharon was describing the behavior of match-parent on both list markers
       and text alignment and how they interact. See below for fantasai's
       partial notes.
     - The entire discussion of text-align and its interaction with the list
       marker position was not minuted; see below for dbaron's summary.

   <dbaron> Basically the idea is that with list-style-position: outside,
            bullets should stick to the line box (wrap for both text-align
            and floats), but with list-style-position: outside-parent the
            direction of the bullet position matches the parent, and the
            wrapping only accounts for floats and does not account for
            text-align
   <fantasai> Aharon was discussing how that behavior handles certain use
              cases that are needed:
   <fantasai> Because, e.g. some lists are rendered with bullets all on
              one side, but an item of opposite directionality might be
              aligned to the opposite side, while leaving the bullet
              aligned with the others in the list.
   <dbaron> (and with list-style-position:outside the side for the bullet
             matches the item, as now)

<br type=lunch/>
Received on Tuesday, 16 November 2010 23:44:02 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:34 GMT