- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 14 Jan 2010 00:55:20 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary: - Discussed color management in Flash - Discussed persistent table headers http://lists.w3.org/Archives/Public/www-style/2009Dec/0155.html - CSS3 Backgrounds and Borders and Multicol CRs to be published shortly ====== Full minutes below ====== Present: César Acebal Tab Atkins Bert Bos Beth Dakin Elika Etemad Simon Fraser Sylvain Galineau Daniel Glazman Anne van Kesteren (via IRC) Peter Linss David Singer Steve Zilles <RRSAgent> logging to http://www.w3.org/2009/12/16-CSS-irc Scribe: Sylvain Color Management in Flash ------------------------- szilles, glazou: adding color management in Flash to the agenda szilles: Flash 10 implemented some level of color management. It assumes the Flash file to be in sRGB. There are two ways to get this to show up 1) use default color correction of the browser 2) grab monitor profile through unspecified means and color-corrects the Flash file independently of the browser szilles: 3) also, it can do no color correction szilles: the feature is intended to follow what the browser is doing szilles: overall, it means that Flash cooperates with sRGB overall; it doesn't mean that Flash content out there is sRGB-friendly szilles: Flash files do not contain ICC profiles <dsinger> steve -- could you put that in email? I think you're saying what others of us have been saying, but I'd like to read it <dsinger> and review it with my colleagues smfr: we also need to understand if we need a new plugin interface so the browser can tell the plugin whether to color-correct or not szilles: yes, this is something that needs to get investigated szilles: I think there is a need to coordinate turning this on so that it works reliably szilles: I read that color correction is hard to get right today even using browsers that support it <szilles> here is a public write up on how to use http://www.adobe.com/devnet/flash/quickstart/color_correction_as3/ szilles: there was an issue last week re: using the 601 video profiles szilles: chris lilley noted no one produced 601 video these days but it seemed that was not the consensus ? dsinger: if a video is untagged then 601 is the right profile <CesarAcebal> Sorry for the delay: I've arrived home right now. http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html Feature queries --------------- fantasai: I would like to let the conversation follow its public course until such time as the WG has something to resolve glazou: I wanted to make sure the WG was aware of this discussion as many web designers have been asking for this for a long time to avoid hacks Persistent table headers ------------------------ http://lists.w3.org/Archives/Public/www-style/2009Dec/0155.html fantasai: it is a positioning mode whereby an item hits the top/bottom of the screen it will remain there as long as its containing block is visible in the viewport fantasai: this is clearly useful for fix table headers in place while the content of the table is scrolled glazou: this behavior could be extended to other elements fantasai: yes, and that is part of the discussion. I wanted to propose this for a long time glazou: any concrete proposal ? fantasai: not yet, although syntax is emerging but no concrete proposal yet fantasai: this would solved many issues with fixed positioning, specifically that fixed elements do not take space fantasai: when it comes to making this general, I'm concerned about the selection of your fixed 'origin'. right now, it assumes the containing block szilles: this would definitely work well for headers glazou: we don't really need x/y positions for this, because we always want the fixed element to stick to edges right ? <general agreement> smfr: an issue is what happens when these elements nest, and how/whether they stack up bradk: on the iphone, such items do not stack up, the previous one is pushed aside <discussion of a dl/dt use case> glazou: is the discussion very general or does it target use-cases ? I'm concerned it could get lost if it doesn't focus fantasai: we have a few use-cases but we want to stay open to what else is out there bradk: it's a very useful feature, although not a requirement. tab: I agree. <glazou says something scary about selectors on the right side. scribe denies it happened> <glazou> selectors on the right hand side could select the elements controlling the sticky one <Bert> (As usual, the DT/DD case is difficult because HTML forgot to define the DI element that groups them. :-( ) <TabAtkins> Why doesn't ::di exist yet? <fantasai> because it should be <di> <szilles> FYI: I will miss the phone calls on the 5th and 12th of January; I will be on vacation. <sylvaing> can someone minute for a few minuntes ? Publishing Specs ---------------- Scribe: TabAtkins Bert: We're waiting on Ian Jacobs; I need to send him some text tonight/tomorrow along with the new publications and documents. fantasai: For B&B, Multicol? Bert: Yeah. Fantasai: Published by end of week? Bert: tomorrow glazou: Moratorium starts at end of week. Bert: Not a problem. Other Topics ------------ glazou: comments on transitions, david and dean aren't here. dsinger: Isn't the second comment just a typo? dsinger: Yeah, Hyatt responded. Definitely just a spec mistake. glazou: CSSOM, but Anne isn't here. He's sick. glazou: Last topic is bidi issues. I think we need dbaron here. glazou: Remember to tell you AC rep about Selectors PR. glazou: No conf call the next two weeks. glazou: Next is 6th Jan. Merry christmas and happy new year! <dsinger> happy hols everyone!
Received on Thursday, 14 January 2010 08:55:55 UTC