[CSSWG] Minutes and Resolutions Telecon 2011-08-10 from fantasai on 2011-08-10 (www-style@w3.org from August 2011) (original) (raw)

Summary:

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

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

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

Administrative

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 retrograde 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 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 something RESOLVED: Add logical keywords to gradients RESOLVED: Publish next WD with 'to ' 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

CSS Speech LCWD

I am on a high-latency and generally slow wifi connection (scrambled VoIP audio), so I will be dumping IRC text while I speak. voice-family: fantasai All of the issues that were raised for CSS-SPEECH on the public mailing list have now been addressed in the specification. I would like to renew my thanks to Fantasai for finding problems, and in helping to design solutions too ;) The editors' working draft is ready for Last Call publication, and contains the full list of changes since the last public Working Draft (April 2011). http://www.w3.org/TR/css3-speech/ http://dev.w3.org/csswg/css3-speech/ 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. 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 HTML-Speech Voice Browser (SSML ) fantasai: yes, definitely SSML :) my previous email - The "Voice Browser" Working Group [1] published SSML1.1 [2], so we should definitely ask them to review CSS3-Speech. - The "HTML Speech" Incubator Group [3] maintains a W3C Note [4] that explicitly refers to CSS3-Speech effort, so we should contact them too. - Given the likelihood of CSS3-Speech being used with/by assistive technologies, I suggest involving the WAI [5] folks as well. [1] http://www.w3.org/Voice/ [2] http://www.w3.org/TR/speech-synthesis11/ [3] http://www.w3.org/2005/Incubator/htmlspeech/ [4] http://www.w3.org/2005/Incubator/htmlspeech/live/NOTE-htmlspeech.html [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 vacation] end of september sounds good. (summer holidays) (now) +1 for end of september Bert: Yes, end of September is good RESOLVED: End comment period at end of September 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 there are a bunch of calc()-related resolutions in http://lists.w3.org/Archives/Public/www-style/2010Jan/0468.html ACTION TabAtkins : Discuss editor change on css3-values at FXTF Here's the result of applying our patch queue: http://lists.w3.org/Archives/Public/www-archive/2011Aug/att-0010/Overview.html 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 full patch queue: http://lists.w3.org/Archives/Public/www-archive/2011Aug/0010.html 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? Also, there was a resolution somewhere on making certain things at-risk. TabAtkins: Bug was on HTML for allowing styling of anonymous blocks created by block-in-inline split

para1para2
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 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 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 flow-from: 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 http://lists.w3.org/Archives/Member/w3c-css-wg/2011JulSep/0164.html response from Elika: http://lists.w3.org/Archives/Member/w3c-css-wg/2011JulSep/0165.html 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 +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 markers 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 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