[CSSWG] Minutes and Resolutions Telecon 2011-08-10


   - RESOLVED: Add logical keywords to gradients
   - RESOLVED: Publish next WD with 'to <keyword>' syntax for gradients
   - RESOLVED: No change to how repeating gradients are handled
               (use repeat-* functions)
   - RESOLVED: Publish updated WD of css3-images with these change
   - RESOLVED: Publish LCWD of css3-speech, comment period to end September 30th
   - Discussed editing CSS3 Values and Units
   - RESOLVED: Assign request for block-in-inline anonymous box pseudo
               as an issue to the CSS3 Box module.
   - Discussion of flow-from syntax and which property it belongs in.

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

   Tab Atkins
   David Baron
   Kimberly Blessing
   Bert Bos
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Brad Kemper
   Håkon Wium Lie
   Peter Linss
   Alex Mogilevsky
   Florian Rivoal
   Edward O'Connor
   Alan Stearns
   Daniel Weck

<RRSAgent> logging to http://www.w3.org/2011/08/10-css-irc
Scribe: fantasai


   plinss: Any items to add to agenda?
   plinss: got Alex's note about regions flow

Gradient Issues

   TabAtkins: Mainly issues we didn't close on  at F2F
   TabAtkins: First item is repeating gradients, whether they should be
              done by repeating syntax in gradient functions, or by
              background-repeat magic
   TabAtkins: Other issue is gradient keywords, i've now set the keyword
              'to' and either a side or corner
   TabAtkins: e.g. 'to bottom left'
   TabAtkins: Put keywords back and made corners magic
   Florian is happy with this too
   smfr: I think it's ok, but why not use 'from' and make the 'from'
         optional so we have compat with the old syntax?
   TabAtkins: Using 'from' rather than 'to' would give the opposite
              directionalitiy thing that confused people
   smfr: Only some people
   TabAtkins: Since we're changing behavior for corner to corner, so ...
   fantasai: I think this is also confusing, with 'to left' I'm not sure
             whether a fixed-length gradient is attached to the left or
             right edge -- I would guess left edge
   Florian: Think this is good enough

   fantasai: Another question is animating the gradients, given corners
             aren't equivalent to angle gradients anymore?
   TabAtkins: They're still equivalent
   TabAtkins: It's just a different angle computation
   bradk: Does the spec take into account that changing the angle changes
          if the box size changes?
   TabAtkins: yes. More details to in css4-images -- I pushed animations
              out of L3
   bradk: How is it defined now?
   TabAtkins: Right now images aren't animatable at all, rules are pushed to L4
   TabAtkins: Since I pushed cross-fade() to L4, you can't do generic
              animations for images anyway, so pushed gradient animations
              out too
   plinss: If you're animating the width and height of a box independently
           and using corner-to-corner gradient, you are by definition of
           the gradient angle?
   plinss: If you're then simultaneously animating angle of gradient.. if
           you compute start point and endpoint, might have animation go
   TabAtkins: Yeah, that should not happen.
   TabAtkins: have similar problems in other situations
   TabAtkins: At each step you need to recalculate your range
   TabAtkins: Different than snapshotting values at the beginning
   Florian: You set your course, and your percentage done changes over time
   plinss: Back to keywords issue
   fantasai: Would like to push to WD and see if we get any comments
   bradk: I like what's happening in linear gradient, still trying to give
          full review to radial gradients
   bradk: Not ready for LC yet

   Florian: The default for linear gradients has been downward for a long
            time, which is now either 'to bottom' or '180deg'
   Florian: Usually default is 0deg or top
   TabAtkins: He's suggesting that we flip the default around they colors
              start at the bottom and go upward
   TabAtkins: I don't have a problem with this, but don't have a particular
              reason to change. It's been default for awhile
   bradk: Fallback is still reasonable, because we're changing the syntax
   fantasai: We're not changing that part of the syntax
   fantasai: I think the default should stay. I think from the top makes
             the most sense
   bradk: Wouldn't changing it mess up prefixed versions?
   fantasai: dbaron already said he won't do that
   plinss: In general we're not going to not make a good change to a property
           because of prefixed versions
   plinss: If it doesn't matter much, sure, but in general don't want to
           consider prefixed versions
   Florian: Since there's no consensus to change, let's leave as-is
   smfr: Mark as an issue?

   smfr: Do we need direction keywords that are writing-mode-aware?
   Florian: And bidi-aware, too
   Florian: Should we add that to writing-modes?
   fantasai: No, belongs in the appropriate module. writing-modes only
             deals with CSS2.1 issues directly
   TabAtkins: Could add them. Although the keywords are a bit weird, e.g.
              'to start before'.
   TabAtkins: Would like to see some examples of this
   bradk: Gradient from black to white from top to bottom, and reversed-color
          headline at the top
   fantasai: Example of sidebar menu items with horizontal gradient that
             fades out towards the end edge. Would want that logical as well
   Florian: [something about writing modes dependency]
   TabAtkins: Don't believe I need any keywords from writing modes
   TabAtkins: Could maybe refer to 2.1
   <florian> Yes
   fantasai: Nothing in 2.1, but if it becomes an issue we could pull out
             a glossary from writing-modes and publish it as a WG Note or
   RESOLVED: Add logical keywords to gradients
   RESOLVED: Publish next WD with 'to <keyword>' syntax

   TabAtkins: back to repeating gradient issue
   bradk: Already made my case. Not keep arguing it
   bradk: Someday we'll have background-rotate, and it will just be redundant
   some muttering about issue wording
   RESOLVED: No change to how repeating gradients are handled
             (use repeat-* functions)
   RESOLVED: Publish updated WD of css3-images with these changes


   <danielweck> I am on a high-latency and generally slow wifi connection
                (scrambled VoIP audio),
   <danielweck> so I will be dumping IRC text while I speak.
   <plinss> voice-family: fantasai
   <danielweck> All of the issues that were raised for CSS-SPEECH on the
                public mailing list
   <danielweck> have now been addressed in the specification.
   <danielweck> I would like to renew my thanks to Fantasai for finding problems,
   <danielweck> and in helping to design solutions too ;)
   <danielweck> The editors' working draft is ready for Last Call publication,
   <danielweck> and contains the full list of changes since the last public
                Working Draft (April 2011).
   <danielweck> http://www.w3.org/TR/css3-speech/
   <danielweck> http://dev.w3.org/csswg/css3-speech/
   <danielweck> any objections?
   TabAtkins: I haven't given it a thorough review, but I know fantasai has,
              so I trust that.
   smfr: I have no objection, but I'm concerned about making a test suite
   TabAtkins: I know someone suggested audio reftests shoudl be possible.
   <danielweck> I saw the discussion about tests, but wanted to focus on
                fixing the spec first
   fantasai: And we can always use human-verifiable tests. Not automatable,
             but still testable.
   plinss: Any reasons not to publish?
   RESOLVED: Publish LCWD of css3-speech

   fantasai: How long is the LC period, and which other WGs to contact?
   TabAtkins: Accessibility TF
   <danielweck> HTML-Speech
   <danielweck> Voice Browser (SSML )
   fantasai: yes, definitely SSML :)
   <danielweck> my previous email
   <danielweck> - The "Voice Browser" Working Group [1] published SSML1.1 [2],
                   so we should definitely ask them to review CSS3-Speech.
   <danielweck> - The "HTML Speech" Incubator Group [3] maintains a W3C Note [4]
                  that explicitly refers to CSS3-Speech effort, so we should
                  contact them too.
   <danielweck> - Given the likelihood of CSS3-Speech being used with/by
                  assistive technologies, I suggest involving the WAI [5]
                  folks as well.
   <danielweck> [1] http://www.w3.org/Voice/
   <danielweck> [2] http://www.w3.org/TR/speech-synthesis11/
   <danielweck> [3] http://www.w3.org/2005/Incubator/htmlspeech/
   <danielweck> [4] http://www.w3.org/2005/Incubator/htmlspeech/live/NOTE-htmlspeech.html
   <danielweck> [5] http://www.w3.org/WAI/
   Bert: Can't think of any other groups, but because it's summer maybe we
         should add a few weeks since it's August [and many people are on
   <danielweck> end of september sounds good.
   <danielweck> (summer holidays)
   <danielweck> (now)
   <florian> +1 for end of september
   Bert: Yes, end of September is good
   RESOLVED: End comment period at end of September
   <danielweck> thanks.

CSS3 Values

   plinss: Request to add some editors [specifically, Tab and fantasai]
   howcome: What does it need?
   fantasai: Organizational overhaul, fix issues that have outstanding edits
             not done for past two years, sync with 2.1
   TabAtkins: This isn't theoretical, fantasai and I went ahead and did th
              majority of the work we'd like to see done
   TabAtkins: We created a patch queue that could be applied to show what
              we'd like to see out of the draft
   fantaai: We didn't change any of the features, just fixed up the definitions
   howcome: I believe dbaron and clilley are co-editors as well
   howcome: It also affects SVG, not sure it's up to us to just take it
   howcome: Very important spec for other modules, don't necessarily think
            we can bring it to closure
   howcome: Is dbaron on the call?
   howcome: You've gone through this?
   dbaron: I thought I had an action to do one thing at some point, but I
           have no record of it
   howcome: You did the definitions that's in there for calc(), right?
   dbaron: I might've written some of it
   howcome: I'm not trying to block progress here. Trying to avoid that we
            see a lot of changes come out that are not ...
   howcome: we saw for example the hyphenation things that we had a lot of
            unnecessary conflicts as a result of that change
   TabAtkins: We're not trying to change any features.
   TabAtkins: Any conflicts would be about more basic definitions that should
              be nailed down in any case
   howcome: You plan to take it to CR?
   fantasai: yes
   howcome: What if a spec needs other values?
   TabAtkins: Can define it themself. And if it's a common value type, push
              it to Values Level 4
   plinss: Sounds like a reasonable path forward.
   plinss: Would like to not keep this in ED forever
   howcome: I'm just concerned about making lots of substantial changes
   TabAtkins: We think the features are fine, just reorganized a bit and
              updated definitions
   howcome: I think there's issues with calc()
   howcome: Not sure about implementations
   TabAtkins: We're in the middle of implementing
   dbaron: And IE's implemented it too
   howcome: Great. Should check with SVGWG if they're ok with this
   TabAtkins: Again, since we're not actually changing any features, shouldn't
              be an issue. Although if SVGWG wants to add stuff to the draft,
              then good to get that feedback
   <dbaron> there are a bunch of calc()-related resolutions in
   ACTION TabAtkins : Discuss editor change on css3-values at FXTF
   <fantasai> Here's the result of applying our patch queue:
   fantasai: The only feature change we did was to add dbaron's cycle()
             proposal to the draft; there was an open action on that since
             Jan 2009
   plinss: Not hearing any objections to adding you-guys as co-editors
   plinss: Ready to publish WD?
   fantasai: dbaron just pointed to some resolutions on calc(), need to make
             sure they're folded in
   dbaron: I think they have been folded in, but prose could use some work
   TabAtkins: So let's look at publishing next week
   <fantasai> full patch queue:
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2010Sep/0003.html
            has resolutions on marking things in values at risk

Anonymous-box Pseudo-element Selector

   Topic: HTML talking about paragraphs pseudo-element selector?
   <dbaron> Also, there was a resolution somewhere on making certain things
   TabAtkins: Bug was on HTML for allowing styling of anonymous blocks created
              by block-in-inline split
   <hober> <div>para1<ul><li>foo</li></ul>para2</div>
   TabAtkins: So you could give it padding, margin, etc.
   TabAtkins: Guessing what it means is that ::paragraph would match all
              anonymous block children of an element
   <hober> div ::paragraph matches para1 and para2 above
   plinss: Is this something we want to accept? Where would ot go?
   TabAtkins: The pseudo-element section of Selectors?
   fantasai: There isn't one anymore. Could add it to CSS3 Box.
   fantasai: That's what defines where boxes are generated
   RESOLVED: Assign this as an issue to the box module
   <plinss> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12778

HTMLWG/CSSWG Coordination

   TabAtkins: Is this the best way for HTMLWG to send comments to CSSWG?
   fantasai: Did they email www-style?
   fantasai: They should post a message to www-style, just like everyone else.
   plinss: If they want to make sure we get to it, they can CC the internal
           list or put it on the agenda so we discuss it on the call

CSS Regions: flow-from

   plinss: Alex sent an email about content: flow-from() vs flow-from: property
   Alex: We discussed what the right property for making something a region
   Alex: We decided that we like content: flow-from() more than property
   Alex: At the moment it sounded totally syntactical
   Alex: Looks like difference is even more
   Alex: The 'content' property is part of generated content
   Alex: Includes ::before and ::after
   Alex: That property is what is supposed to put content in the box, not
         change the nature of the box
   Alex: It's not whatever layout it was anymore, it's a viewport into
         something else
   Alex: It's still possible to parse the property and if the only thing it
         has is flow-from() then that particular value overrides ::before
         and ::after
   Alex: and changes layout model
   Alex: I feel pity for content property that it gets such a weird definition
   <vhardy> http://lists.w3.org/Archives/Member/w3c-css-wg/2011JulSep/0164.html
   <vhardy> response from Elika: http://lists.w3.org/Archives/Member/w3c-css-wg/2011JulSep/0165.html
   <vhardy> response from Vincent: http://lists.w3.org/Archives/Member/w3c-css-wg/2011JulSep/0171.html
   plinss: I think having ::before and ::after work in regions is valuables
   <stearns> +1 to using before and after in regions
   vhardy: We had a long discussion about ::before and ::after, because
           we had talked about having these continue-before / continue-after
   vhardy: Our proposals are to have different pseudos that have a different
           processing model, that are exclusions
   vhardy: It's different from ::before and ::after
   Alex: Generic ::before and ::after is not really helpful
   bradk: What about ::marker?
   bradk: Isn't that equivalently a problem?
   Alex: vhardy said his preference is still content: flow-from(). My
         preference is flow-from:
   Alex: content property can have fallbacks. If one of those is a flow-from(),
         then first we have to visit all the URLs first.
   Alex: Unless flow-from() has to be its only value

   TabAtkins: You said that a region is not a normal element, like it becomes
              a viewport onto this embedded document
   TabAtkins: Wouldn't that indicate that the 'display' property is appropriate?
   Alex: It would make sense for display-inside to have a region value
   TabAtkins: Then that seems like an appropriate way to do this
   vhardy: So your suggestion is display-inside: flow-from(..) ?
   Alex: ...
   Alex: Region has to say that it ignores ::before and ::after
   <smfr> am I hearing "display: region"?
   TabAtkins: Having a value for display makes more sense to me, clearer that
              it has all these other side-effects
   Alex: Should we make css3-regions be the pioneer for display-inside?
   bradk: What does a new display type gain you?
   TabAtkins: The significant switch is that 'display' is very clear that
              this is doing something very different
   TabAtkins: ... [something about conflict resolution] ...
   TabAtkins: If 'display' is the switch, then you won't ever have conflicts,
              it's only one type of display or another
   bradk: Is it just because of ::marker?
   TabAtkins: yes, but also it's changing how you display what's inside of you
   Alex: Display property says what it is, and content property says what it has
   smfr: If you have display: region; how do you say what model you're using?
   TabAtkins: You'd need display-inside
   fantasai suggests moving this discussion to www-style

Meeting closed.

Received on Wednesday, 10 August 2011 23:29:35 UTC