- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 21 Apr 2010 12:55:46 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Request to review table anonymous boxes proposal for next telecon:
http://lists.w3.org/Archives/Public/www-style/2010Mar/0551.html
- Namespaces waiting for two complete test suite passes to exit CR.
- border-clip property shifted from GCPM to CSS4 Backgrounds
http://dev.w3.org/csswg/css4-background/
- Discussed interaction of animations and transitions, event
triggers, use cases, and pseudo-elements.
- Anne requests review of serialization rules for cssText and
selectorText in CSSOM:
http://dev.w3.org/csswg/cssom/#serializing-selectors
- Discussed writing-mode and relative directions.
http://lists.w3.org/Archives/Public/www-style/2010Apr/0278.html
Previous discussions had concluded that absolute directions
(top/left/bottom/right) should retain their physical meaning,
and that before/start/after/end should be introduced to allow
writing-mode relative declarations. Discussed use case for
this and level of urgency wrt ePub (which will find its own
solutions, good or not, if we don't act). fantasai actioned to
write a spec with SteveZ and Murakami-san.
====== Full minutes below ======
Present:
Tab Atkins
David Baron
Beth Dakin
Arron Eicholz (via IRC)
Elika Etemad (mostly IRC)
Simon Fraser
Sylvain Galineau
Daniel Glazman
Håkon Wium Lie
Peter Linss
Shinyu Murakami
David Singer
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2010/04/14-CSS-irc
Scribe: TabAtkins
Administrative / Action Items
-----------------------------
glazou: Any extra agenda items?
glazou: First item on agenda is CSS2.1, status and next steps.
<fantasai> No progress the last 2 weeks
<fantasai> unless it was by someone other than me
glazou: peter, you had an action item at the ftf?
<fantasai> http://lists.w3.org/Archives/Public/www-style/2010Mar/0551.html
<fantasai> Everyone had an action item to review that proposal,
if they have, we should close on it if possible.
glazou: For me, make namespaces implementation reports. I sent
that to the list.
glazou: Discovered we don't have the same exit criteria as CSS2.1.
I think we need two implementations that pass the whole
thing, not two impls per feature.
glazou: So right now we don't meet the exit criteria.
glazou: For fantasai, put border-clip into CSS4 backgrounds.
TabAtkins: I believe she's done that; I saw it in the CVS.
<fantasai> done
<fantasai> http://dev.w3.org/csswg/css4-background/
Animations and Transitions
--------------------------
glazou: Hakon, produce an alternate proposal for mixing
animations and transitions.
howcome: I think there are multiple proposals on the table. I'd like
to see some feedback from Apple concerning the use-cases
that it can't currently do.
smfr: We're thinking of addressing the case of running an animation
when you exit a state, such as :hover.
smfr: Had a few proposals of that kicked around internally. One was
keying it to a transition, another was doing it when it was run.
smfr: The problem with either of those was that the animation running
isn't tied to any current style, so it's hard to cancel, which
I think is important for accessibility.
smfr: I don't think there's a magic bullet.
smfr: I'd like to see your table given a column where the things are
written out longhand.
smfr: I think using the shorthand hides some of the complexity.
smfr: I'd also like to see an example of an exit-animation that then
needs to be killed.
plinss: What is the problem with animations attached to transitions?
they should run forever, right?
TabAtkins: me and Brad were discussing transition-animations that
were limited by the transition duration.
smfr: Sure, but you might not run the animation a whole number of
times.
[talk about whether on-exits are something like an event model]
howcome: I also think Andrew's proposal is somewhat interesting, but
he hasn't written it up yet.
howcome: I think we could use some more explicit use-cases that
express important cases and show the differences in
various proposals.
TabAtkins: I proposed to do so privately, and have a number of cases
that I think would be useful to bring up explicitly.
I'd take an action on it.
howcome: I agree that writing out the longhand would be useful too.
Andrew doesn't think that the longhand should exist at all,
maybe.
smfr: Have you thought about moving your page to a wiki?
howcome: Maybe, but I don't want it to go totally overboard. I'd
just want an editor to "control" it.
howcome: Or would CVS be okay?
smfr: That's fine with me.
howcome: I'm happier with CVS, and it lets me edit plain HTML too.
smfr: It can go in the Transitions folder.
howcome: And I'd be happy for people to add cases directly to it
as well.
ACTION howcome: put transition/animation proposal document on the
CVS server
glazou: Question for Simon. Do transitions and animations apply
to generated content?
smfr: I think they should.
smfr: I think we decided not for certain things like ::first-letter.
glazou: I was thinking of for ::marker and ::before and such.
smfr: Yes, but we don't do it quite yet.
glazou: I'm trying to reproduce the Mac OSX disclosure element where
the little triangle rotates when you fold/unfold the element.
glazou: Or if you have a tree structure.
howcome: Can you attach transitions to the content property?
TabAtkins: I think it would fall under the category of
"non-transitionable elements" and would just go all at
once at the beginning or end of the duration.
glazou: Next two agenda items are about fonts, one related to
szilles' action about character-transform.
More Action Items
-----------------
glazou: Tabatkins, rewrite issue 161.
TabAtkins: Haven't done it yet, will have it done by end of day.
<glazou> http://dev.w3.org/csswg/cssom/#serializing-selectors
glazou: Anne, serialization of cssText and selectorText in CSSOM
The goal is to preserve the ability to parse cssText and selectorText,
so it is still valid.
glazou: I'd like to action everyone to review it by next week.
glazou: Speaking of OM, we have a request from Arthur Barstow to
handle VM spec in CSS, because it belongs in the OM.
glazou: Following a chat with Peter, we're happy to handle it in
the CSS group, as long as we have someone handling it.
glazou: Right now only Anne is working on OM, and he probably can't
handle all the requests coming in about different things.
-smfr
glazou: Next is calc(), but dbaron isn't here.
Writing-mode Issues
-------------------
glazou: Last item, writing-mode issues. I think Murakami-san is
on the call?
<glazou> http://lists.w3.org/Archives/Public/www-style/2010Apr/0278.html
murakami: In Japan, ePub layout is very important. Japanese epub
group published a minimal set of requirements for japanese
text layout.
murakami: The problem is the writing-mode property in CSS.
murakami: Whenever writing-mode is changed, margin-top, frex, isn't
the right layout. It should match the writing mode.
murakami: When writing-mode is vertical, frex, margin-top becomes
treated as margin-right.
murakami: This does not conform with the CSS standard.
murakami: I request in my post three features to resolve this issue
of physical vs logical properties.
murakami: In my proposal, media queries can be used to describe the
UA support for writing-mode or not.
+fantasai
glazou: When you say media query, you mean a CSS media query? I see
that you are also proposing a pseudoclass.
sylvaing: murakami originally proposed using media queries, but I
had a discussion with him where I said that we weren't
comfortable with that, so he changed to a pseudoclass.
fantasai: What we need is margin-start/end/etc. margin-top meaning
margin-right is confusing. For that reason, last time we
discussed it we decided that absolute directions must
remain absolute. And that we should introduce
margin-start/end/etc for relative directions
sylvaing: the CSSWG hasn't done it yet, though, and we have people
coming up with their own solutions here.
szilles: I'm unaware of any document ever published that said that
top/left/etc *weren't* absolute.
sylvaing: In [some implementation] you can lay out your text in
the "western way", and then change the writing mode and
everything "rotates".
sylvaing: This will be the natural expectation of the right way to
do it. If it's the wrong way, we have to get on top of
this *very soon*, because ePub isn't going to get smaller
any time soon.
fantasai: We can write a draft that introduces *-start, etc. We
just need to resolve the cascading issues. There have
been two proposals for resolving that for *years*, but
there's never been interest in resolving that.
sylvaing: I think the basic problem is that the impls on the WG so
far just didn't really worry about that medium. Now we
have a new group of impls that have different needs, and
they're not in the wG.
glazou: We didn't have a strong use-case before, and now we do
have a strong use-case.
howcome: But you don't need any new functionality to do this right now.
fantasai: The problem is that if you write a page that uses vertical
text, and then load it in an impl that doesn't have support
for writing-mode, your layout will break horribly.
fantasai: Using a media query just makes you write two nearly identical
stylesheets. Better is to have relative properties that will
apply properly.
fantasai: Now, sometimes the layouts will be slightly different based
on writing-mode, so, as with many other features, it is
useful to have some mechanism for a "dependency check" on
writing-mode.
fantasai: But the issues that aren't addressed by relative directions
are relatively minor.
fantasai: Like line-height might be a little different ideally, but
it's still readable.
howcome: We're talking ePub, though, not all browsers. We don't
really need to think about backwards compat.
sylvaing: That's not the issue. If you're an ePub vendor trying to
fix this problem, you might do it the way you're familiar
with, which is the way IE does it (rotates directions).
sylvaing: If there's a better way to do it, it needs to be communicated
soon.
sylvaing: It's not an issue of actually running IE6 on the ereaders,
but rather just copying what the dominant impl in Japan does.
howcome: The number of Japanese web authors writing websites is
relatively small, and I don't think they're asking for these
features.
sylvaing: Murakami-san is asking for it.
<fantasai> I think the point is that ePub readers and printing software
such as antenna house need this functionality
glazou: When we had the AC meeting in Tokyo, I was approached by people
in Japanese newspapers asking for this. that was 4 years ago.
glazou: That was not for paper, it was for websites.
howcome: I'm sure you can find it some places, but I think more people
would be happier without it than with it.
sylvaing: They'd be happier to not write multiple stylesheets just to
display their site in both horizontal and vertical.
<fantasai> I would like to solve the problem, and I don't think how IE
does it is the right way
<fantasai> and I'd rather have a spec that specifies the right way to
handle it
<fantasai> than specify IE's behavior
glazou: I don't want us to talk about statistics that we don't know
the details of.
sylvaing: I'm fine with saying that the current IE solution is wrong,
that's fine. But I'm not fine with saying "use a media query
and just duplicate all your stylesheets".
<murakami> Japanese ebook publisher and authors really want vertical
writing.
howcome: It's not good enough to print if you just rotate the numbers.
<fantasai> What is the objection to specifying margin-start/end/etc ?
<fantasai> And putting that in a spec?
glazou: [points to fantasai's question in IRC]
sylvaing: I have no objection.
howcome: I object to that.
glazou: CSS was written originally with mostly western text in mind.
We didn't design things with vertical text in mind.
glazou: I remember requests from 97, 99 asking for *-start, *-end
properties.
howcome: There is no western bias in top/left/bottom/right.
<fantasai> sylvaing, murakami, In that case I propose creating such a
spec, and I am happy to work on that with Murakami-san in
September/October.
glazou: Graphically, yes. Top means top. But if you're doing
something script-related, you want them to easily change when
you swap writing direction.
howcome: So you write another stylesheet.
glazou: Frex, in Mozilla we have a lot of stylesheets that *do not
work* if you change the writing direction.
howcome: Having a feature query could work.
sylvaing: What specifically is the media query checking for?
howcome: Whether writing-mode is implemented or not.
sylvaing: You realize that people will then ask for media queries for
every property?
howcome: I think we can make a case that writing-mode is special.
glazou: I don't think so.
howcome: We can ask if vertical layout is supported.
sylvaing: I don't trust UAs.
glazou: It's still not workable. We'll need two stylesheets, one for
browsers that support things properly, and one for ones that
do it the IE way. It becomes feature detection.
<sylvaing> clarification: we don't trust UAs to report property-level
capability and this is one reason why we always said no to
stylesheet-level capability checks
glazou: Let's talk IE. Next version of IE does writing-mode.
[some example of bad automatic choice of stylesheets]
?: I think it's extremely unique that this one property has so much
power to change the layout of the page.
sylvaing: Okay, Håkon, now you've detected that vertical writing is
supported. Now do top/etc logical or physical?
howcome: Physical.
sylvaing: So now if I'm writing an ebook I have to write two different
stylesheets for vertical and horizontal text layout.
glazou: Why do you object to *-start, etc?
howcome: We'll see an explosion of new properties.
sylvaing: I think people will be able to just use a single property
howcome: I think it's very expensive to duplicate all the properties.
sylvaing: It's very expensive for authors to write two stylesheets.
They're come up with their own solutions around it.
howcome: I don't think that just rotating the values is good enough.
I think you'll need different values for some things.
sylvaing: I don't think writing two stylesheets is good enough.
glazou: I'd like to ask Steve about what Adobe does to solve this problem.
sylvaing: Do we know anyone in the epub space who could help us out here?
szilles: There are indeed times where you do want different stylesheets
for vertical and horizontal. There are also times when "good
enough" is fine, and there should be a place for doing it only
once.
szilles: I think that in Japan they'll probably start using the
start/end/etc, but they'll also sometimes want different
stylesheets.
szilles: So I think we'll end up needing both mechanisms.
szilles: I recommend we write up start/end and get it out the door first.
szilles: To follow along with what fantasai said.
glazou: Hakon, is that fine for you?
glazou: In the meantime we're progressing.
ACTION fantasai , steve: write up a proposal for the start/end stuff.
murakami: What about the pseudoclass proposal?
glazou: It's difficult to test the value of a property in a pseudoclass.
murakami: We can already do things with ltr and rtl languages.
glazou: Ah, like current language stuff. Maybe. We'll discuss, come
back to it next week's telcon.
Meeting closed.
<fantasai> No, that's referring to information in the document
<fantasai> not in the style sheet
<TabAtkins> Yeah, bidi direction is carried by the elements themselves.
<sylvaing> sylvaing has joined #css
Received on Wednesday, 21 April 2010 19:56:55 UTC