- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 17 Apr 2013 23:59:38 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Discussed Colors Level 4, particularly
- whether proposed syntax extensions are a good idea
- whether 'color-correction' is still needed
http://lists.w3.org/Archives/Public/www-style/2013Apr/0051.html
- RESOLVED: Publish CSS Marquee as a NOTE with a note that says
it is discontinued.
- RESOLVED: Scientific notations also allowed in percentages and
dimensions. (Just not integers.)
- RESOLVED: Publish CSS3 UI LC with added cursor values. Move nav
props to level 4. Contact Web and TV and Opera about
nav changes. Ask LC comments from WAI PF and SVG and
any groups we asked for prev LC.
- Discussed importing ICC profiles and Lab color additions to SVG
into CSS4 Color.
====== Full minutes below ======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Sylvain Galineau
Daniel Glazman
Arron Eicholz
Elika Etemad
Simon Fraser
Rebecca Hauck
Koji Ishii
Dael Jackson
Brad Kemper
Philippe Le Hégaret
Chris Lilley
Peter Linss
Edward O'Connor
Matt Rakow
Florian Rivoal
Simon Sapin
Dirk Schulze
Alan Stearns
Nick Van den Bleeken
Lea Verou
Scribe: Bert
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Apr/0381.html
Colors 4
--------
TabAtkins: Some syntax improvements form past few years, plus
color-correction (suggestion from dbaron).
TabAtkins: I pulled them together into a module.
<ChrisL> so colors4 is just syntax options plus a bad color property
ChrisL: So it is syntax, plus a bad, horrible property?
TabAtkins: It was dbaron's suggestion.
dbaron: Web browsers do not follow the spec now.
ChrisL: Depends on what you mean by that.
ChrisL: sRGB as device-RGB is fine and fairly common.
ChrisL: wide gamut monitor is different.
ChrisL: Treating it as sRGB will give good results.
ChrisL: So current situation is good and allows for future. This new
property makes things worse.
dbaron: It's for PNG images with info in them.
ChrisL: Chromaticity oo ICC tag
dbaron: Those will not use CSS colors.
dbaron: So you cannot match PNG to CSS colors.
ChrisL: In that past we had problems with flash. But flash can now be
color managed, too.
ChrisL: So no reason anymore.
CHrisL; So the situation has changed since 3 \years.
dbaron: OK, so we should look at it again.
ChrisL: I can help.
ChrisL: Editors for css3-colors?
TabAtkins: css4-color so far a private draft.
ChrisL: I'd be happy to be co-editor.
TabAtkins: Seems you're in the editors list already.
plinss: Do we work on it?
dbaron: I've heard some objections to every single thing in the draft.
<ChrisL> ok to work on it subject to discussing the contentious property
<tantek> oh good times, we're talking color matching again :)
dbaron: I'm not happy with the new syntax additions.
It creates compat problems, because authors using the new
syntax create style sheets that aren't backwards-compatible.
dbaron: Syntax could have been better originally, but not worth changing now.
ChrisL: What do current impls do with new syntax?
dbaron: Error and fall back.
ChrisL: OK.
ChrisL: So no pages can depend on the new syntax.
florian: There *may* be pages that depend on it *not* working.
TabAtkins: Low possibility.
florian: Yes, but this syntax it is something people might try, because
it looks reasonable, and then never remove.
<ChrisL> in practice its not going to break anything
TabAtkins: Maybe not discuss all features today.
TabAtkins: Just whether we want the draft or not.
dbaron: The question is if there are any features we want to do.
dbaron: Not convinced it is worth our time implementing compared to other
stuff.
TabAtkins: Some of them are 15 minute work.
dbaron: And than compat problems to chase down.
arronei: and testing.
TabAtkins: hex-with-alpha is long-standing request.
TabAtkins: and [...] I trip over every time I write Canvas code.
plinss: So, do we want to work on it?
* ChrisL weak agree but if we decide not to do it, that is fine too
TabAtkins: glazou was against me starting it on W3C server.
<sgalineau> TabAtkins: was daniel against starting a draft, or against
starting it without getting a WG decision to do so first?
<TabAtkins> sgalineau: With me starting a draft *in a W3C server* without
a WG decision.
* dbaron is probably slightly against, but would want to hear from other
people
* florian think we have better things to do, but not absolutely opposed.
Just a matter of priority
TabAtkins: As long as I can use the mailing-list for discussion, I'm fine.
<tantek> regardless of what repository a draft is in, the problems that
dbaron mentions are still there
<tantek> of distracting implementations from other more important things etc.
plinss: OK, so no formal draft of colors 4, but folks can discuss possible
contents on mailing list.
<tantek> that being said, why not document the incremental additions
on our wiki?
Marquee
-------
plinss: Spec is very old, discontinued.
plinss: Should we publish a new one with a disclaimer?
florian: Webkit has impl, I think.
florian: should we revisit marquee, or just drop it?
<SimonSapin> +1 for big red obsoletion notices in obsolete specs
TabAtkins: Impl is terrible, we want to remove it.
* sgalineau speaking of higher priorities: marquee!
* tantek agrees with immediate obsoletion
<tantek> and if anyone wants to re-raise it as a draft in the future,
they can do so
* leaverou Opera has a partial impl too fwiw
<florian> marquee is worth removing because it introduces properties that
interfere with stuff with actually want to do
ChrisL: Isn't there a knock-on affect, some parts about box model that
are only there?
<ChrisL> I recall some part of box model is only there for marquee
bert: I'd suggest making a note, somebody reads through it to look for
things to save.
<BradK> So we can ignore 'overflow-style'?
florian: overflow-style. Also in paged-x overflow.
<tantek> I wouldn't even suggest a note. Just the discontinued warning.
TabAtkins: Once it is officially discarded I can then remove our code.
<florian> to bert: it is the in the gcpm spec, but not in the only
implementation of it (opera) which uses overflow-x/-y
* BradK agrees that overflow-style should be thoroughly killed.
ChrisL: Can move to WD without any difficult process.
dbaron: WD or NOTE?
<tantek> Note: this spec is discontinued.
florian: NOTE sounds like a good thing.
<ChrisL> is there anything else in it apart from marquee?
<tantek> I agree, leaving it as CR will send an ambiguous message.
Chris: nothing else than marquee in it? Then whole thing can become a Note.
dbaron: [quotes from Process]
<dbaron> http://www.w3.org/2005/10/Process-20051014/tr.html#tr-end
<dbaron> "If W3C decides to discontinue work on a technical report before
completion, the technical report SHOULD be published as a
Working Group Note."
<plh> example of a discontinued work:
http://www.w3.org/TR/2010/NOTE-webdatabase-20101118/
(style may vary :)
florian: Also add a note to GCPM about overflow-style?
florian: In the overflow spec there are issues noted, but not in gcpm.
Peter: should probably move to the overflow spec
florian: So just a note to say be careful.
florian: paged-x/y no longer on 'overflow-style'
RESOLVED: Publish an update to Marquee with a note that says it is
discontinued. Make it a NOTE.
florian: I propose to action howcome.
florian: Spec says overflow-style won't be used. Don't say what would
be used instead.
ACTION howcome: add an issue to GCPM to say that paged-x/paged-y won't
be on 'overflow-style' but something else.
<trackbot> Created ACTION-556
Bert protests that action shouldn't be given to somebody who isn't here
* florian filed https://www.w3.org/Style/CSS/Tracker/issues/324
Scientific Notation
-------------------
Topic: scientific notation for percentage and dimension
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Apr/0215.html
Bert: didn't we already discuss sciencific notation?
TabAtkins: for numbers, not percentages/dimensions
TabAtkins: SVG allows it everywhere.
TabAtkins: So we should, too.
<dbaron> I'd interpreted our previous resolution that we were including
percentages and dimensions.
<dbaron> We just didn't want to allow scientific notation for <integer>.
11:36 -!- ChrisL [clilley@public.cloak] has joined #css
<ChrisL> +1 to what Tab said
<dbaron> I support Tab's proposal.
TabAtkins: As dbaron says, we don't want it for integers.
<SimonSapin> let’s do it
florian: The reason for the notation was SVG in the 1st place.
dirk: [missed]
dirk: Upper bounds?
Tab: We talk about overflow, but haven't settled bounds.
Tab: Plan to put it in Values 4
plinss: Objections?
RESOLVED: scientific notations also in percentages and dimensions
<glazou> florian, yes
Topics on the Radar
-------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Apr/0187.html
<ChrisL> issue-316?
<trackbot> ISSUE-316 -- #ident vs #1hash for ID selectors -- raised
<trackbot> http://www.w3.org/Style/CSS/Tracker/issues/316
Topic: table cells and pseudo-stacking contexts
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Apr/0145.html
dbaron: Not sure it needs telecon time.
dbaron: Nobody replied to msg yet.
dbaron: I'd encourage TabAtkins and fantasai to read it, and everybody
who is interested,
dbaron: Complex enough that we shouldn't discuss on telecon before some
more list discussion.
RESOLVED: will revisit table cells and pseudo-stacking contexts later
CSS3 UI
-------
plinss: hasn't been updated in a while.
Tantek:: A request came in for cursor values.
Tantek: Got a reply from Tab.
Tantek: But want group to discuss if we need another LC
* smfr wonders why box-sizing is in css3-ui
<plinss> smfr: because we needed it in 1998 to be able to size buttons
properly...
<TabAtkins> smfr: Today, it should probably go in the Sizing spec with
the new width/height keywords.
<TabAtkins> smfr: But no reason to not keep it in UI's CR for now. ^_^
<tantek> http://lists.w3.org/Archives/Public/www-style/2013Apr/0056.html
tantek: LC with those two new cursor values.
tantek: And various things at risk.
tantek: This is your chance to propose more features :-)
glenn: nav-* properties in CSS UI in draft?
tantek: Yes, at risk.
tantek: If it is on the web, that is a good reason, otherwise just
misleading authors.
tantek: I heard no implementers implementing it.
tantek: Want to keep it at risk.
<dbaron> If we're going to do another last call, should we make an attempt
to fix 'nav-index'?
glenn: Was some activitiy in DLNA television space.
glenn: Has a normative ref to CSS.
tantek: There are problems with nav properties
tantek: Fixed for TABINDEX in HTML, but not gotten round to fixing CSS.
tantek: No sense in referencing them, because they are broken.
glenn: Anybody fixing them? Or docs on why they are broken?
<tantek> http://wiki.csswg.org/ideas/nav-index
dbaron: There are some... After discussion with accessibility people,
I described some problems in e-mail.
TabAtkins: If they are broken, take them out?
tantek: No problem with that.
tantek: Can store the old text on wiki.
<dbaron> http://lists.w3.org/Archives/Public/wai-xtech/2011Nov/0034.html
<dbaron> http://lists.w3.org/Archives/Public/wai-xtech/2011Nov/0035.html
<dbaron> (and threads following)
<dbaron> were the issues I was thinking of
glenn: Somebody should contact Web and TV IG.
glenn: TV people will be unhappy with us removing them.
plinss: [summarizing] new LC, drop nav, but contact web and tv folks first.
* glazou notes that nav- are used in GCPM too ...
tantek: Could chairs do the liasing?
tantek: I can do the editing.
<dbaron> should probably also contact WAI-PF
florian: While contacting tv people, also contact Opera. They are active
there and will probably have an opinion.
tantek: Presto was dropped.
florian: Not said what happens with Opera in TV space
* ChrisL can't see much further development on presto if it is only used
on embedded devices and not on mobile or desktop
<florian> further development would be surprising indeed, but long-term
maintenance might not, and removing actively used features
would be unpleasant
dbaron: Contact WAI PF about nav props
plinss: How long LC period?
tantek: minimum. Small change.
ChrisL: Sounds fine.
<tantek> thanks dbaron for the email links. have added to:
http://wiki.csswg.org/ideas/nav-index
plinss: Other than WAI PF, wh do we want to ask for review?
ChrisL: Let me check if SVG refs css3-ui...
glenn: Can we record a resolution?
plinss: Yes, but still collecting the data.
ChrisL: SVG2 refs css3-ui, So we should ask SVG WG.
plinss: Other groups?
RESOLVED: publish LC with added cursor values. Move nav props to level 4.
Contact Web and TV and Opera about nav changes. Ask LC comments
from WAI PF and SVG and any groups we asked for prev LC.
<tantek> I have added nav properties as explicitly dropped from CSS3 in
the CSS4 UI wiki page:
http://wiki.csswg.org/spec/css4-ui#dropped-css3-features
<tantek> that's where we'll track them for moving forward
<glazou> LOL https://twitter.com/css3ui
* oyvind doesn't know much about TV but
http://lists.w3.org/Archives/Public/www-style/2013Apr/0164.html
mentions webkit too
glenn: There was ATSC standard with nav props.
glenn: That could be references by anybody who can no longer ref CSS.
<glenn> ATSC A/100-2 did define nav-* props
http://www.atsc.org/cms/standards/a100/a_100_2.pdf
<glenn> just for historical note only
bert: Who will contact Web and TV and Oepra?
plinss: The chairs.
* plh notes that Guiseppe from Opera is co-Chair of Web/TV IG
ICC profiles and Lab colors
---------------------------
dirk: If we don't publish css4-color, then maybe makes no sense to discuss
this now.
plinss: color-correction properties?
SimonSapin: These features might be enough to make css4-color.
ChrisL: Yes, these are significant properties.
ChrisL: Browsers are behind with color mgmt. Other SVG impls are ahead.
ChrisL: It's great functionality. Happy to see it moving into CSS4 or 5.
dbaron: What does it allow you to do?
ChrisL: Match with an image, e.g.
ChrisL: Directly specify LAB colors as well.
ChrisL: Says how to interpolate and transform. Also allows polar form of
Lab color.
dbaron: For color profile, it's author convenience, but no new capability.
ChrisL: No, it *does* add new function.
dbaron: But it maps to sRGB.
TabAtkins: [missed]
ChrisL: No, ICC profiles give you colors not in sRGB.
dbaron: CSS can go outside sRGB.
ChrisL: Yes, but badly implemenbted and somwehat underdefined.
dbaron: I'd rather fix it by allowing sRGB outside [0,1] than by adding
more color profiles.
ChrisL: That's different from the whole industry. What is the benefit?
dbaron: Keep CSS simple.
ChrisL: Not really simple if CSS is different from other systems.
dbaron: It adds quite a bit of syntax.
dbaron: Which seems unnecessary.
<dbaron> if the point is to just reference a thing used elsewhere
ChrisL: The syntax gives you 3 or more params and a (link to) an ICC profile.
ChrisL: No need for a full URL.
ChrisL: Reference e.g., Adobe RGB profile.
ChrisL: Or a CMYK color, etc.
ChrisL: Exact same value can be written in CSS as in corporate style or logo.
plinss: [missed]
ChrisL: Scope.
plinss: Maybe this becomes css4
plinss: Is that reasonable path forward?
<leaverou> if we add the capability for ICC color profiles, it might be
useful to add cmyk() colors everywhere, not just paged media.
Graphic designers are very accustomed to them.
<SimonSapin> leaverou, with a default conversion for RGB-based displays?
<leaverou> possibly
<SimonSapin> leaverou, it’s even device-cmyk() which is obviously device-dependent
<leaverou> SimonSapin: It was cmyk() a few years ago, didn't notice it changed.
<SimonSapin> leaverou, I’m reading GCPM. Maybe cymk() is/was another spec?
<leaverou> SimonSapin: I think it was an older version of GCPM, circa 2009
<SimonSapin> indeed
<SimonSapin> http://www.w3.org/TR/2010/WD-css3-gcpm-20100608/#cmyk-colors
<SimonSapin> http://www.w3.org/TR/2011/WD-css3-gcpm-20111129/#cmyk-colors
Meeting closed.
<ChrisL> lea, gcpm changed cmyk() to device-cmyk following a comment I
made asking them to clarify if it was color managed or not
(it isn't)
<SimonSapin> ChrisL: do you think it could make sense to convert somehow
a cmyk() notation to RGB, for screen display?
<leaverou> ChrisL: good call. I do think that color managed CMYK would
be useful, and not just for print
<leaverou> Many graphic designers are used to CMYK colors
<ChrisL> lea yes, converting a specific color space to another one
(including rgb) is what color management does
<leaverou> yes, I know :) I'm saying we need it
<ChrisL> however, you want to preserve the original color definition and
convert at display time, not convert early and put it in the css
because that is lossy
<ChrisL> glad to hear your support. dbaron did not seem to think it helped
any. lots of designers would disagree
<ChrisL> yes, its not just for print
<ChrisL> although the drive to implement comes from print; or more
precisely from folk repurposing media for both screen and print
<SimonSapin> would linear-gradient(rgba(…), cmyk(…)) be well-defined?
<leaverou> SimonSapin: yes, it would be converted to sRGB using the declared
ICC profile
<ChrisL> simon - yes, it would, provided interpolation-colorspace is defined
<ChrisL> lea - no
<ChrisL> it would not necessarily be converted to sRGB
<leaverou> well, it could be a solution. Yours sounds better :)
<SimonSapin> I’m not seeing this any time soon in WeasyPrint, though :/
Not until cairo has some support for it
<ChrisL> does cairo not?
<SimonSapin> cairo does RGBA everywhere
<SimonSapin> without color profile AFAICT
<leaverou> as a designer, I'd love to be able to use cmyk() values and
have them converted to RGB for screen and used as device CMYK
for print. If that makes sense. Does it, ChrisL?
<ChrisL> https://blueprints.launchpad.net/inkscape/+spec/icc-for-cairo
<ChrisL> lea - yes that makes sense and is exactly what the SVG2 color
stuff does. I'd like to see that used in general CSS.
<SimonSapin> ChrisL: interesting, thanks
[Further discussion clipped; see IRC logs for details on Cairo's color
support and other super-exciting stuff like that]
http://www.w3.org/2013/04/17-css-irc
Received on Thursday, 18 April 2013 07:00:07 UTC