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

[CSSWG] Minutes and Resolutions 2010-04-14

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 21 Apr 2010 12:55:46 -0700
Message-ID: <4BCF5842.7060406@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - Request to review table anonymous boxes proposal for next telecon:

   - Namespaces waiting for two complete test suite passes to exit CR.

   - border-clip property shifted from GCPM to CSS4 Backgrounds

   - 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:

   - Discussed writing-mode and relative directions.
     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 ======

   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
   [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,
   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.

   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.
   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
   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
   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
   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
   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
   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
   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
   szilles: I think that in Japan they'll probably start using the
            start/end/etc, but they'll also sometimes want different
   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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:45 UTC