- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 17 Aug 2011 15:09:05 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary: - RESOLVED: Put ltr | rtl keywords back into image(), mark as at-risk. - Discussed having a switch to have author request background printing ====== Full minutes below ====== Present: Tab Atkins David Baron Kimberly Blessing Bert Bos Arron Eicholz Elika Etemad Simon Fraser Sylvain Galineau Arno Gourdol John Jansen Brad Kemper Divya Manian Alex Mogilevsky Peter Linss Edward O'Connor Florian Rivoal Alan Stearns Steve Zilles <RRSAgent> logging to http://www.w3.org/2011/08/17-css-irc <Zakim> +Oliver_Goldman CSS3 Images ----------- Scribe: TabAtkins plinss: Any new agenda items? TabAtkins: Request to publish Image Values as WD. sylvaing: Any new features? TabAtkins: Don't think so (maybe finishing the magic corners thing?) fantasai: The i18n group sent comments. We should respond as a WG to that. <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Aug/0461.html <dbaron> What set of features are we talking about? <TabAtkins> dbaron, the ltr | rtl keywords in image() plinss: Should we wait to publish, or log as an issue and deal with it later? sylvaing: Yeah, just interested right now in getting it stable and having a testsuite, then adding new features. bradk: Anything to resolve on? Is this for CSS4? fantasai: We moved a lot of things in the split from 3->4, and one of the reasons for the split was implementation status. fantasai: But that's really for the CR phase. fantasai: We should really be splitting based on whether we think a feature is mature or not. sylvaing: We'd like to drop prefixes on gradients as soon as possible, and don't want to hold it up based on other features that haven't been implemented yet. fantasai: We don't need to implement to go to CR. sylvaing: Are we going to put things into level 3 knowing full well that in a few months we'll pull them out again? sylvaing: But if we've moved something to level 4 that makes the level 3 feature set awkward, I understand. fantasai: One issue is that if we are holding things back that are otherwise spec-stable from CR, this is bad if someone who is not in this WG is willing to implement. sylvaing: Something's not stable until it's been implemented. fantasai: I don't want to make it a policy of this WG to hold things back from CR until they have been implemented. florian: [something I couldn't understand] sylvaing: I'm not making policy for the WG here. I'm talking about Image Values, and I don't want to drag it along for any longer than necessary. <florian> I agree with Fantasai's approach in general, but for this particular case, I would side with Sylvain, so that we can drop prefixes on gradients as soon as possible <fantasai> Florian, a feature that's not gradients will not hold back prefixes on gradients. <fantasai> Florian, prefixes are dropped per feature, not per module. <florian> Fantasai, I thought they were for modules. If not, I withdraw my agreement with Sylvain on this point. sylvaing: Is there a CSS4 Image Values yet? Brad: instead of calling it css4 you could split it into 2 diff drafts Brad: have gradients in its own spec and everything else in another spec fantasai: We already discussed that option. Also stuff in css4 is less stable. TabAtkins: There's an Overview.src.html in css4-images, but it's not an actual spec right now. sylvaing: I would like to keep css3 on course of stability but I wouldn't like to remove things there right now. plinss: I think it would be good to have a list of the things that we've pulled from level 3. <sylvaing> doesn't see the point of moving things in 3 when we know full well they'll most likely go back to 4 in a few months. what is the value of that ? <florian> Can't we make an ED for level 4, to host all these things? <fantasai> florian, Tab did. It's just not very pretty right now :) TabAtkins: I can make the css4-images look half-decent and have this information. <sylvaing> I won't object to it, i just can't see what problem it fixes plinss: So I'm hearing that we leave it at level 4, and respond to i18n that we're not throwing it away, just delaying it. fantasai: My problem is that we haven't had anyone say we're implementing it, but the six-month CR period is specifically designed to request implementations and give feedback. sylvaing: What prevents someone from implementing it because it's in level 4 rather than level 3 fantasai: The perceived stability level is based on the document's status sylvaing: People implemented gradients without a stable spec <dbaron> Gradients didn't start in this draft; they started with a proprietary implementation and proposal from Apple that eventually found its way into this draft. fantasai: Gradients are shiny, much more so than bidi. plinss: I think fantasai is just advocating we put it in 3 and mark it as at-risk. plinss: Is there any problem with that? <florian> I agree with Fantasai sylvaing: Will it be shinier if it's in one document or another? plinss: It does send a message that this is ready and it's ready for implementation and feedback. plinss: So does anyone object to putting it in the draft as at-risk? sylvaing: [stuff] I'm not going to object, though I disagree. fantasai: I don't think it should hold the draft back either, and if we get tons of issues on it we can drop it. But I also don't see that it will hold things up either. RESOLVED: Put ltr | rtl keywords back into image(), mark as at-risk. Topic: Continuing the Regions discussion from last week <nimbu> alexmog: you there? vhardy: I don't feel strongly about the issue, but Alex did, so I think we should defer until he attends. Printing Backgrounds -------------------- Scribe: fantasai <smfr> http://lists.w3.org/Archives/Public/www-style/2011Aug/0436.html TabAtkins: Currently, most browsers when they print, suppress backgrounds and tweak colors to preserve contrast TabAtkins: IE9 also suppresses box-shadows * alexmog is online, can call in if you want to talk about regions TabAtkins: This is to save ink for the majority of pages that weren't designed to print. TabAtkins: So we want authors to be able to hint that they have thought about printing and trying to not waste ink TabAtkins: There are several proposals on the mailing list. * dbaron wonders if we're going to have to have this discussion all over again when howcome is on the call * sylvaing agrees with dbaron; howcome needs to be here to conclude TabAtkins: My preference is introducing a new property that says "please by default print backgrounds", although user can choose to always or never print them TabAtkins: Other option some people like is printing backgrounds if "print" style sheet exists TabAtkins: I don't like that one, I think it's hacky. dbaron and smfr and I don't like it TabAtkins: Would prefer to go with property route TabAtkins: Would like some agreement on how this should go TabAtkins: Unfortunately Håkon is not on the call <florian> Hakon and I agree with the way fantasai phrased it in answer to Tab's list of 4 options * fantasai liked the 'waste-ink: yes | auto' option :) <tantek> lol * Ms2ger too * Bert can see the check box in the print dialog already; "Do you want to waste ink? yes/no" :-) <smfr> [this checkbox Sponsored by HP] <tantek> I'm starting to believe Håkon's point - all the ink-wasters (who specifically code up ads, blocks of colors etc) will simply use this hint as well and lie about "having thought about printing and trying not to waste ink" - or from their perspective, it's not a waste, it's perfectly good advertising :) +alexmog TabAtkins: Wrt Tantek's point, images are already fully printed. TabAtkins: People who want to do advertisements will already be able to waste ink. <dbaron> tantek, as Tab just said, authors who want to force whatever-they-want to be printed can just use foreground images TabAtkins: This enables a more general design capability fantasai: I've also seen sites that hack borders with z-index to get backgrounds where they want it. I think we shouldn't be encouraging that. plinss: I think it's a valuable property. As we get more and more features, UAs will be inclined to turn them off by default, which degrades the experience on other media. plinss: The other point that came up on the list, is that other contrast-preserving transforms might be useful for other output media, e.g. saving battery life on screens TabAtkins: Yes, I think it's good to name the property so that it works for other use cases. But don't think we should get into exact color management smfr: I'm not sure about that. This about printing decorations. smfr: There's a use case for controlling color presentation on AMOLED screens and such, but ... TabAtkins: The thing is the semantics are essentially identical between AMOLED and printer suppressing color smfr: It's not about color, it's about box-decoration TabAtkins: We don't need to ... TabAtkins: It specifically suppresses things that are expensive to do. TabAtkins: It's not just about backgrounds, because it tweaks colors. TabAtkins: If it's just a matter of naming, we can discuss that after agreeing on an approach sylvaing: People can use the feature for other things, but we don't have to design for them. TabAtkins: ... sylvaing: But the more generic the name, the more you'll have requests for flags and other options etc. smfr: I can see that if we implement this generically, we'll get requests from accessibility wrt contrast TabAtkins: This seems not accessibility-related. It's about things that are expensive in one medium that wasn't considered by the author. TabAtkins: Would occur whenever the UA feels like it. bradk: Is this something that's testable? plinss: It's testable if you say what the UA does in response to ... plinss: If the UA does this, the result should look like that. <florian> This property in itself is testable, but saying the UA may apply it whenever it feels like it means the rest of CSS becomes harder to test. Something might be off because of a bug, or because this property was applied. plinss: There are various cases in our tests where you need to have X user style sheet, or set your prefs to not have a min font size or whatever Bert: I don't like this. Bert: You set a background, and then you have to say "no really I mean it" Bert: This is the UI side option TabAtkins: It's still useful for authors to say "I thought about this case and the costs and designed accordingly" ?: Already have that info if there's a print stylesheet Arron: Yeah, that seems good enough to me TabAtkins: It's for the author saying [...[ Arron: That's what the print style sheet is for. Arron: Maybe we should switch to printing backgrounds by default. * sylvaing would love a setting to keep backgrounds when I print to PDF but really not sure I want/need that in CSS * sylvaing is also concerned at testing this and achieving interop dbaron: This changes the meaning of media queries, which is supposed to be just about matching. dbaron: It's going to be confusing to teach authors about media queries if some of them are magic in addition to matching. [...] Florian: What is a print stylesheet for other than expressing the author's thoughts about print. dbaron: What if the author is using a site-wide stylesheet that has a print block? <nimbu> yes ?: What if there's a site-wide stylesheet that has print-backgrounds set? +kimberlyblessing Florian thinks it's silly to have a property that says "print backgrounds, no I really mean it" Florian: The property that's supposed to add backgrounds is the 'background' property. TabAtkins: We're already past the point where that's what happens. * sylvaing if you do want to save ink, box-shadow and text-shadow are probably things you want to turn off too plinss: You're saying that if it's in a print stylesheet it should be applied. But there are print-applicable styles in an all stylesheets. florian: The presense of a print style sheet is enough to say whether we should print or not. TabAtkins gives an example of sites built on top of a template CSS with print block. Florian: There will always be bugs. You can work around that in the UA prefs TabAtkins: People don't tweak that very often. TabAtkins: UA should do the right thing by default. TabAtkins: Don't want random bunch of pages to unintentionally print backgrounds TabAtkins: And I'm sure the HTML5 boilerplate is not the only one that does something like this Florian: What I don't like is setting the precedent of UAs ignoring the spec and then having a special property to say "follow the spec" TabAtkins: That ship has sailed [rehashing of existing arguments] <tantek> lol florian: I agree with the behaviors, just discussing the mechanism for triggering the behavior * tantek advocates rehashing (ahem, capturing) existing arguments on a wiki <tantek> is there a wiki page tracking this proposal TabAtkins? including arguments for/against? <stearns> tantek: I think there's just the thread reboot summary <tantek> sterns - email threads got lost <tantek> all I'm saying is, whoever wants to actually make progress on this proposal (ahem, TabAtkins :) ) should write-up the existing arguments on a wiki in order to avoid wasting time repeating them <stearns> or resolve not to do anything <tantek> (both / all sides of the argument) <tantek> can't determine if anyone is bringing up anything new or not until existing arguments are documented <tantek> and then you can point people at URLs of their repeated arguments instead :) TabAtkins: Nobody looks at the UI options sylvaing: A lot of times people print from the browser to e.g. PDF, not to paper sylvaing: In that case it should print colors sylvaing: Don't see what this has to do with colors TabAtkins: Then the UA knows it's printing to PDF and can use colors sylvaing: Not always. It's often expressed as printer driver. sylvaing: I don't think this can be easily captured in CSS, it's based on what the user wants. ... fantasai: Are we getting anywhere here? If not, then let's follow Tantek's suggestion and put it on a wiki. TabAtkins: Nobody's bringing up anything new. fantasai: Then we're not going to resolve on this today. sylvaing: I'm not convinced that this is something that belongs to CSS. I think it's a UA thing. sylvaing: Given where we are today, what browser do, what does having this CSS property solve? What is its value? I'm not sure I really get it. sylvaing: If it's useful, it seems very narrow and specialized to me. Florian: The argument about site-wide stylesheet holds for the property as well. TabAtkins: You're saying the feature can be polluted. But it's not right now. Whereas @media print is. plinss: I want to settle not how to do this, but do we want to do this. sylvaing: I'm not completely clear if its necessary for CSS to solve this as opposed to UAs getting smarter about it * alexmog thinks browsers were wrong to not print backgrounds to begin with. * fantasai disagrees, did you see those sites from the 90s? :) plinss: I would like UAs to be smarter. I don't think they have enough info to do better than they're using now. plinss: UAs certainly can have better UI. Have a print preview dialog before printing that presents the document 2-3 different ways plinss: But right now the UA doesn't have the information it needs to make a good default choice. plinss: This gives the extra piece of information needed to do that. * alexmog If UAs can detect crappy design and fix it, should they? * alexmog That decision was made once for backgrounds, it's unique, now we need a unique way to undo that plinss: I'm not hearing anyone saying absolutely no, we don't want this. Bert: Well, I don't want it. plinss: I don't want to hear I don't like it, vs. I have a really good technical reason why it doesn't belong in CSS. Bert: I think I gave three. Bert: I don't think the author can decide. Bert: How many levels of importance to we want? plinss: Not a matter of importance, a matter of intent Bert: We limit CSS to altering things in the viewport, not reaching into UI plinss: Nothing about this property affects UI. Only default behavior when rendering the document. Bert: Isn't that the same thing? plinss: No. Bert: What does it does if not influence print dialog? plinss: Doesn't influence dialog, influences behavior. TabAtkins: UA could choose to present this info in the dialog, but not required to do anything like that Bert: Keep hearing it's a UI problem that the user can't decide whether to print backgrounds or not. Bert: It's not just that I don't like it. I think it's bad design. plinss: Don't think your first two arguments are valid, but for the third... plinss: I think this gives a way for the author to express his intent. plinss: Would like a path forward other than a wiki page plinss: Since that just puts it off again fantasai: I think having a wiki page would be valuable. fantasai: Give a clear overview of the options, their pros and cons, etc. Give everyone a clear overview. <fantasai> http://wiki.csswg.org/ideas/print-backgrounds Meeting closed.
Received on Wednesday, 17 August 2011 22:09:38 UTC