W3C home > Mailing lists > Public > www-style@w3.org > January 2012

[CSSWG] Minutes and Resolutions Telecon 2012-01-25

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sat, 28 Jan 2012 00:47:58 -0800
Message-ID: <4F23B63E.7030808@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
   - Discussed posting agendas to www-style
   - Discussed adding CSS2.1 to F2F agenda
   - Discussed scriptability media query
   - Discussed whether to add color math functions
   - Discussed device-pixel-ratio proposal and using the
     standardized 'resolution: <number>dppx' instead.
   - Discussed application of 'box-decoration-break' to bidi splits

====== Full minutes below ======

   Glenn Adams (via IRC)
   David Baron
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman
   Arno Gourdol
   Vincent Hardy
   Koji Ishii
   John Jansen
   Brad Kemper
   Chris Lilley
   Peter Linss
   Alex Mogilevsky
   Edward O'Connor
   Anton Prowse
   Florian Rivoal
   Alan Stearns
   David Storey
   Daniel Weck
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2012/01/25-css-irc
ScribeNick: vhardy


   glazou: we have a few extra items. The first one is about sending
           the agenda to the public list instead of the WG. I would
           like to give a few days to everyone to contribute.
   glazou: if we reach consensus, we will start to send the agenda to
           the public list starting from next week. If you hit reply,
           the regrets would go to the public list, so be careful.
   <tantek> glazou, +1 on sending the agenda to the public.

   glazou: meal restrictions?
   * ChrisL restricted to good food
   * tantek is pescatarian (vegetarian + fish ok)
   glazou: please send me the dietary restrictions before the F2F.
   glazou: we will not be able to have food during the F2F in the meeting
           room. there are restrictions about what can be done in the
           meeting rooms.
   <tantek> should we put a "food prefs" column on the f2f wiki page
            table of attendees?


   glazou: I wanted to talk about the 2.1 issue. Anton posted a large
           number of 2.1 issues recently. I saw a few questions on the
           web about what we are doing about the errata.
   glazou: Peter and I discussed it and we think it would be good to
           work on it during the F2F to give a signal that the issues
           remain on the radar. Opinions about that?
   chris: I think it is good to show that 2.1 is not abandoned. It is
          the basis for CSS3.
   johnjansen: we resolved that Bert would make sure he would have all
               the issues on the wiki.

   anton: the majority are from the mailing list since the wiki page
          was created. They are new issues. I am in the process of
          moving the issues; there are about 30 of them.
   <glazou> #antonp { speech-rate: slower; }
   anton: the ones from Jan-April 2011 need to be reviewed. It was a
          high volume feedback period and I want to make sure we cover
   anton: There are about 100 issues total that need to be taken care of.
   <tantek> for CSS 2.1 issues, would it be possible to request that
            people raising them add them directly to the wiki? e.g.
            we could indicate that issues added to the wiki will
            likely get attention first (which might provide sufficient
            incentive for issue contributors to do so)
   * plinss notes Anton clocked at .75 TimBLs
   * sylvaing i'm pretty sure you need a license for that
   anton: we will have 100 issues to take care of. I am trying to get
          them on Bugzilla before the F2F. I may only have 75 total,
          but I'll try to do all.
   anton: should we have all of them in the errata. Some are easy, some
   anton: this is the number I was expecting.
   johnjansen: do you need help?
   <tantek> vhardy, depends on the conclusion of the issue. Some issues
            may not require a spec change but clearly still caused a
            question to be asked so could use an answer on a wiki page
            FAQ for example.
   antonp: I have done the difficult mining on the mailing list. The
           issue is to move the ones from the wiki. I could just copy
           to Bugzilla. I am trying to write bug descriptions that are
           understandable without having to read the whole thread.
   johnjansen: we will have a large number of issues on Bugzilla and we
               will talk about it at the F2F, so we will demonstrate
               that we are focused and make progress.
   glazou: yes.
   johnjansen: I will be regrets for the F2F
   glazou: will you be there?
   antonp: yes
   florian: as long as we schedule enough time to address significant
            chunks, we do not need to address all of them at the F2F.
   glazou: I agree. I plan to write a blog entry on w3.org to say we
           are going to address the 2.1 issues during the F2f.
   glazou: anything else?

CSS Transform parsing rules

   vhardy: request to move to a future meeting when Dirk can be here.

Media Features

   <glazou> http://wiki.csswg.org/ideas/media-features
   glazou: I would like everybody to review this so that it can be
   florian: it is fairly simply, there is a new feature for scripts.
            If your browser supports javascript and has it turned on,
            then you get 1, otherwise you get 0. Which is what you need
            to turn on styles that need to apply when you do not have
            script support.
   florian: no support for fine-grained detection for situations where
            some scripts are enabled and some not. There is a suggestion
            in the proposal. It is kind of an edge case.
   rossen: what is the prime use-case for this?
   florian: because scripts may actually affect the style as they run.
   florian: it is different when the script that were going to modify
            the layout do not run. Currently, there is a javascript
            library that addresses that, by removing classes when
            scripts run. A declarative solution would be better.
   sylvaing: so we would do what Modernizr does.
   antonp: except in a less fine grained manner.
   florian: to my question. We might be able to turn what I proposed
            on its head and have a 'no-script' media feature instead
            of a 'script' media feature.
   florian: ... the problem with the script media feature is that i
            a browser supports javascript but does not support this
            media feature, then you will get the wrong style. If we
            do 'no-style', you would not be worse of than today.
   florian: if you have a media feature that is not supported in the
            media query, the entire query is equivalent to not all.
   florian: as an author, if you write script:0 rather than just script,
            it does the fallback properly, so may be we do not need to
   antonp: I wonder about the case where you turn off the script but
           the media feature is supported.
   florian: it works in that case.
   dbaron: would script:0 lead to the same error handling as no-script ?
   florian: what happens when the new media feature is not supported
            should be least disturbing to the page.
   florian: if you use it explicitly with a value, then either is fine.
            Without an explicit value, no-script is better.
   florian: if we want to add finer grain later, script() is a better option.
   florian: harder with no-script.
   florian: do we care to extend later on.
   glazou: we are not going to discuss the whole feature right now.
   florian: If people could think about it, that would help.
   glazou: will discuss at the F2F if we get enough feedback.

GCPM Issues raised by Tab and fantasai

   <glazou> http://lists.w3.org/Archives/Public/www-style/2012Jan/0895.html
   fantasai: nothing major, just things Hakon needs to take care of.
   (Hakon not on the call).
   fantasai: as long as Hakon is tracking it, we are fine.

color tweaking

   glazou: since the release of CSS 2, we got requests to do color
           tweaking like lighter(). We refused so far, sometimes for
           technical reasons, sometimes not. We need to come up with
           an articulated technical answer.
   chris: we originally said that filters could do that but Tab argued
          back and I agreed. We are looking for a calc function.
   chris: for lightness, additive is not going to be sufficient,
          because you lose your colors. Some sort of hue rotate seems
          useful functionality to me.
   glazou: what do other people thinkg?
   florian: I think it did not make sense to address before variables.
            I think a big blocker has been removed.
   glazou: I tend to agree with that.
   glazou: I think variables will be immensly useful here.
   glazou: how could we do that.
   fantasai: until we have a concrete proposal, we are not going to make
             progress on a telecon.
   glazou: but do we want to dedicate time on that.
   chris: yes, and we already have filter functions/equations that could
          be reused here.
   * fantasai thinks this belongs to css4-color or css5-color
   ACTION: Chris to create a concrete proposal to address the color
           tweaking requirement.
   <trackbot> Created ACTION-417
   <tantek> I'd like to see examples of real world web pages where
            authors are currently doing color lightening/darkening
            (by any method, CSS preprocessing, or in a javascript
            function etc.) before committing to adding it to CSS.
   <tantek> I'm not convinced it is something that is broadly necessary,
            feels more like a "wouldn't it be cool if" type of feature
   <tantek> if there's an advocate for this feature, please capture it
            as a theoretical request for css4-color on the wiki.
   <sylvaing> I think this is something that makes sense once you have
   glazou: a lot of people have been asking for that at the Paris web
           conference, they were all web authors.
   <sylvaing> I even think it's a variable scenario, period
   * ChrisL wonders why 5
   <fantasai> because color-correction and #rrggbbaa seem a little more
              baked, so might wind up shipping 4 before we have a concrete
              spec for color math :)
   glazou: anything else to discuss now?
   <tantek> (until someone shows at least *some* real world attempts at
            doing so, so far I have seen none in the emails)
   <sylvaing> tantek, there is one on the list: designer defines a color
              scheme for an entire design then wants to adjust it in one
              place vs. overwriting each instance of a color value all
              over the place
   <bradk> Here is an example of a color tweaker on the Web that includes
           tint and saturation variations of a base color:
   <tantek> sylvaing - I know the use-case, I just didn't see a page on
            the web doing so. (URL?)
   <sylvaing> tantek, why would you see it on a page? by the time the
              page is out the color scheme has been tweaked
   <tantek> bradk - I agree there are tools for doing so, now show me a
            URL with tweaked colors where the author has used that tool
            to do so
   <tantek> sylvaing - I'm asking for examples of pages from authors
            where they simply claim they've had to do such math (or
            used a tool) beforehand
   <tantek> with actual color values we can look at
   <bradk> tantek - I think that would be hard to prove.
   <sylvaing> tantek - i don't follow. you want me to provide a page
              where the same color values are used multiple times?
   <tantek> bradk - not asking for "proof", just for authors statement
   <tantek> "this is a page I built by hand with tweaked colors,
            example: color1, color2 which is a lighter/version of
            color1" etc.
   <sylvaing> tantek - the use-case is called css variables. easy color
              tweaking by designers is a special case of that imo
   * tantek wants real world examples so we can look at the *actual*
            colors people have used and what they *claim* is the
            transform (lighter/darker, other) that they've done by
            hand or otherwise.
   <tantek> sylvaing, css variables is not a "use-case" it's a solution.
   * glazou notes that with the "real examples" requirement, we would
            not have standardized a lot of stuff that proved to be useful
   <sylvaing> tantek - fine; this is one css variables use-case
   <bradk> tantek, that just seems extremely unlikely that a designer
           would go into such detail about how he/she figured out the
           colors that are all shades or saturation variations of each
   <tantek> glazou - note that I'm not saying "don't do it", I'm simply
            saying I will classify this as a theoretical use-case until
            someone provides real-world URLs of authors manually (or
            through a script etc.) doing it.
   <tantek> and theoretical use-case doesn't mean don't do it, it means
            it gets lower priority than real-world use-cases / problems.
   <sylvaing> tantek - you cannot find such a URL. all you can see is a
              page after it's been tweaked.
   <tantek> sylvaing - see above.
   <sylvaing> tantek: ok, i don't get it.
   <tantek> sylvaing, from above:
     [17:36] tantek: bradk - not asking for "proof", just for authors
                     statement thereof
     [17:37] tantek: "this is a page I built by hand with tweaked colors,
                     example: color1, color2 which is a lighter/version
                     of color1" etc.
   <sylvaing> tantek, then give that answer to the authors on www-style
              who ask for it?
   <tantek> and you *could* find such a URL if there were a javascript
            library that did lightening.
   <glazou> tantek: will post a call for contributions on color tweaking
            on my blog, with my co-chair hat on
   <tantek> sylvaing, burden is on the feature requester.
   <sylvaing> tantek i think doing this with JS is specifically a
              non-goal for authors
   <tantek> otherwise, I may get to it eventually with adding it to the
            css4-color wiki page
   <glazou> right
   <sylvaing> tantek, anyway. we don't need to resolve this now and we're
              adding noise to IRC
   <tantek> sylvaing - not asking for pre-existing JS library as a
            requirement, that's just one way of demonstrating an existing
            real-world use-case
   <tantek> saying it's a non-goal is not useful
   <tantek> in general, if authors are using a JS library (or server-side
            library, like SASS) to achieve some presentational effect,
            then it may be a good candidate for consideration for a CSS
            feature. but absence of such library does not prove anything,
            so saying no such library would be expected to exist is also
            not useful.

Media Queries: device-pixel-ratio

   florian: I wanted to ask something about media queries.
   florian: device pixel ratio is a media feature. It exists in various
            browsers (WK, Opera have it).
   florian: that seems useful, we should add it to the next level of
            media queries.
   dbaron: I looked at the images draft, and I think there is a better
           way to do it. The css3-images draft introducts the dppx
           (dots per CSS px) unit. If you have that unit, you do not need a
           new media query. All you do is use these ddpx units and query
           on resolution.
   florian: the primary usecase is when you are on a device with a px
            that maps to many device pixels.
   edward: the device pixel ratio was more explicit about that.
   edward: I prefer the media query since it is already implemented.
   fantasai: is it prefixed?
   florian: yes.
   fantasai: then, I do not see a reason to standardize it.
   florian: if we standardize, we can drop prefixes.
   fantasai: if we drop prefixes, we can just drop to 'resolution'.
   florian: why not.
   florian: I am a bit confused. Do we need to change anything about
            how resolution is defined?
   dbaron: no, I do not think so. Just use dppx with the resoulution.
   fantasai: just make sure there is an example, that should be good.
   florian: sure. For the next level of media queries, we just need an
            example with that unit and we are good?
   dbaron: I think so.
   florian: I'll get feedback from Opera implementors. Seems like it
            would work.
   florain: that is all I had on this topic.

CSS3 Background: box-decoration-break and bidi

   fantasai: Background and borders issues from previous call.
   <fantasai> CSS3 Background: Applying box-decoration-break to
              bidi-induced splits
   http://lists.w3.org/Archives/Public/www-style/2011May/0059.html (ISSUE-182)
   dbaron: do we define precisely where the splits happen?
   dbaron: I worry that different implementations may split in different
           places and if borders show up, then we have issues.
   fantasai: wouldn't you have the same issues even without the borders.
   dbaron: with borders, you only see where the begining and end are.
           You do not not see all the pieces.
   dbaron: does box-decoration-break also affect that?
   fantasai: yes.
   dbaron: I am afraid of that. Implementations may put extra breaks in
           that do not cause problems but are not necessary needed.
   dbaron: may be they don't.
   fantasai: how do we address your concerns.
   dbaron: we need to specify what those bidi splits are and see if they
           are interoperable.
   fantasai: I think that should be a separate issue. If we decide it
             does not apply, then it does not apply ever.
   dbaron: if we go with does not apply, then fine. However, if they do
           apply, then we need to address the issue.
   fantasai: could we say that if two pieces of the same box are exactly
             adjacent, then they should be treated as one box.
   dbaron: this is scary. We would need to go rewrite our implementations
           for something for which there is no demonstrated use cases.
   fantasai: today, if there are two adjacent boxes, they are already
             treated as a single piece.
   dbaron: would that still be true if the breaks applied?
   dbaron: I think you make a bunch of assumptions. I do not know it is
           true that implementations merge boxes like you said.
   fantasai: I did not say they should. They need to render as if.
   dbaron: my position is that the breaks should not apply, but I am not
   brad: what are the use cases?
   dbaron: I want to know the use cases and what implementations do now.
   fantasai: I do not think we have use cases, because I do not think you
             would visually highlighting boxes are discontinous due to
             bidi reordering. You would typically not decorate it. It
             would look weird.
   fantasai: the problem is not use cases. We have a feature that applies
             to boxes that split and it is not defined what happens in
             that case. We can say that it does not apply or that it
   dbaron: I would like to know what implementations do and what the use
           cases are.
   fantasai: imo there is no use case to put decorations on boxes that
             are split because of bidi reordering.
   dbaron: I think that what implementations do now is probably what
           people do not want. Right now they do apply box decoration
           breaks to bidi splits.
   dbaron: if you put border on an inline with bidi reordering, you will
           see the effect, even if the boxes are contiguous. Should the
           spec. say that, or should the spec. have bidi reordered boxes
           with merges.
   <tantek> fantasai - test case that demonstrates the situation you are
            discussing / asking for clarification/definition on?
   <tantek> URL?
   <fantasai> tantek: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1309

   florian: if we do not have a use case, and we do not seem to have one,
            it seems better to leave this undefined.
   dbaron: there are questions about whether people put borders on
           inlines in the first place.
   dbaron: ... and thus whether to bother with box-decoration-break at all
   plinss: people do that, I have seen it.
   brad: most people would not want a border between two words becase a
         word goes in the opposite direction. We should say that in the
         spec. and explains it does not apply.
   fantasai: I am happy with florian's suggestion.
   plinss: I think we need to specify it.
   florian: we could start with undefined and then nail it down later.
   florian: when we have use cases.
   <glenn> adobe in-design arabic version supports this type of feature,
           but proprietary format
   glazou: any more comments?
   szilles: what is the conclusion?
   szilles: I thought there was support for what florian was proposing.
   brad: I think it should be defined. I do not think we should default
         to whatever uas do.
   fantasai: whatever you do, it looks weird.
   szilles: at a minimum, there should be a comment saying that we are
           looking for use cases.
   szilles: brad, I think we should leave it undefined and say so, is
            that it will drive people to come up with use cases if there
            are any.
   dbaron: the url I pasted, shows that there are two boxes in this case.
           If we started to apply it, we would get bad results. May be
           we need to resolve this problem.
   dbaron: I think that getting it right for the bidi cases is going to
           be hard implementation-wise.
   florian: we do not want to rewrite all our code. I say we should not
            define it until we have use cases. Until then, say it is
   brad: then we end up with incompatibility.
   fantasai: yes, but it is a weird edge case.
   <SteveZ> +1 for Florian's statement
   florian: may be it is better to let implementations do different
            things, and later consolidate on the best behavior.
   dbaron: I think the use cases are the same as borders on inlines.
   dbaron: some people probably want it to look like this.
   dbaron: then people who write in arabic for example, may have these
           use cases.
   dbaron: if you want borders around the boxes instead of open borders
   dbaron: The right behavior is obvious but hard to implement.
   dbaron: we want the borders to close where the borders are physically
   fantasai: we could give two options:
   fantasai: close the borders when they are separated
   fantasai: or treat bidi split as always slicing.
   fantasai: an implementation would be conformant if it does slicing or
             if it does the 'correct' behavior. If it cannot, it can
             treat it as slice.
   fantasai: then we can see how uas implement it.
   glazou: we are not going to resolve this issue today.
   florian: can we agree on the next step?
   florian: given dbaron's feedback, I do not think we should define the
            behavior until we are clear on the desired result.
   <dbaron> I think we are clear on the desired result but it requires
            defining a whole bunch of new things we don't have already,
            and it's not clear to me whether it's worth doing that.
   glazou: we should get back to this during the F2F.
   <dbaron> I think this is a pretty classic example of the problem I
            described in http://dbaron.org/log/20100531-specs

Meeting closed.
Received on Saturday, 28 January 2012 08:48:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:54 UTC