W3C home > Mailing lists > Public > www-style@w3.org > April 2013

[CSSWG] Minutes Telcon 2013-04-17

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 17 Apr 2013 23:59:38 -0700
Message-ID: <516F99DA.5030206@inkedblade.net>
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

This archive was generated by hypermail 2.3.1 : Thursday, 18 April 2013 07:00:08 UTC