[CSSWG] Minutes and Resolutions Telecon 201-08-17

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