- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 16 Nov 2010 15:43:23 -0800
- 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 UTC