- 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