[CSSWG] Minutes and Resolutions Telecon 2012-07-18


   - RESOLVED: accept ChrisL's suggested change to the note about deprecating
               system colors in CSS3 Color
   - RESOLVED: Accept Florian's proposal for defining the return value of
   - RESOLVED: drop 'resolution' descriptor from css-device-adaptation
   - Default font features must be on by default, for now;
     MSFT to conduct some perf testing, jdaggett to investigate adding 'none'
     values to turn things off
   - RESOLVED: Alignment of overconstrained block-level flex containers
               remains dependent on containing block's direction; 'flex-flow'
               is not consulted. (No change.)
   - RESOLVED: 'visibility: collapse' redoes line breaking, as there are
               good reasons to want that. (No change.)
   - RESOLVED: 'order' is not renamed to better indicate that it only affects
               visual rendering (and not speech or tab-order) because
               it's too late in the process and the WG doesn't know of a
               significantly better alternative
   - Handling of abspos placeholders in flex containers (issues 17 and 18)
     is up as a topic for next week.

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

Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
Date: 18 July 2012
Agenda: http://lists.w3.org/Archives/Public/www-style/2012Jul/0417.html (ChrisL)
Chair: Chris Lilley
Scribe: Anton Prowse

   Glenn Adams
   Rossen Atanassov
   Tab Atkins
   David Baron
   Ryan Betts
   Bert Bos
   John Daggett
   Arron Eicholz
   Elika Etemad
   Sylvain Galineau
   Brad Kemper
   Jonathan Kew
   John Jansen
   Chris Lilley
   Alex Mogilevsky
   Edward O'Connor
   Anton Prowse
   Florian Rivoal
   Alan Stearns
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2012/07/18-css-irc

ACTION: Chris to follow up on invited expert issue: ask about employment status
<trackbot> Created ACTION-484

CSS3 Color Errata

   new comment: css3-color says don't use system colors, use something else
   It's a change to a non-normative note
   <ChrisL> http://lists.w3.org/Archives/Public/www-style/2012Jul/0423.html
   fantasai: it makes sense
   dbaron: are we still pushing the 'appearance' property forward? I thought we weren't
   ChrisL: the change deletes the entire note including the admonition to use 'appearance',
           replaces it with another one that says that system colors deprecated
   ChrisL: it removes the admonition to use the 'appearance' property
   glenn: avoiding having specs referring to future features would be a good idea
   RESOLVED: accept ChrisL's suggested change
   fantasai: There was also an erratum on currentColor that's missing


   <florian> http://lists.w3.org/Archives/Public/www-style/2012Mar/0327.html
   florian: function called removeProperty
   florian: not defined what it returns
   florian: we propose it returns same thing as getPropertyValue
   dbaron: our implementation does that, i.e., calls getPropertyValue(),
           removes the property, and returns what getPropertyValue()
           returned before removing the property
   ChrisL: sounds like change would be compatible with at least 2 implementations
   ChrisL: any objections?
   sylvaing: should we check implementations first?
   florian: I don't see what other behaviors could be useful
   <glenn> can someone file a bug against cssom to record this?
   * fantasai proposes the cssom editor files the bug :)
   <glenn> ok, i will do so
   RESOLVED: accept the proposal from florian
   <dbaron> is a testcase
   Bert: I think that's what the recommendation already says
   Bert: the current DOM spec
   florian: Oh?
   florian: maybe I missed that.
   dbaron: lots of things in DOM spec didn't get into CSS
   <glenn> DOM-2 currently says "Returns the value of the property if
           it has been explicitly set for this declaration block.
           Returns the empty string if the property has not been set
           or the property name does not correspond to a known CSS property."
   <Bert> -> http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html DOM 2 style
   <glenn> so it doesn't exactly say return what getPropertyValue() returns
   <dbaron> well, actually, it's a copy-paste with a bugfix
   ChrisL: since DOM-2 Style doesn't have much life expectancy,
           so my opinion is to put it in CSS
   dbaron: I'm happy to have it in CSS
   ACTION: florian to file CSSOM bug and glenn to update CSSOM spec
   <tabatkins> FYI, WebKit also returns the getPropertyValue() value from removeProperty().

   <fantasai> alexmog: Did you get a chance to look at http://lists.w3.org/Archives/Public/www-style/2012Jul/0385.html ?
   <alexmog> fantasai: yes, it seems reasonable
   <alexmog> fantasai -- reread your proposal on table captions, still agree
   <fantasai> alexmog: good, I'll close that issue pending edits, then :)

Device Adaptation

   florian: descriptor called 'resolution'
   florian: introduced to be an equivalent to ??? dpi
   florian: we introduced resolution to be compatible with lots of things,
            but we think it's actually harmful because it tricks people
            into thinking it's good to use it
   <florian> equivalent to target-densityDpi. Generally useless, only
             supported in the android version of webkit (not including chrome)
   RESOLVED: drop 'resolution' descriptor from css-device-adaptation
   ACTION: florian to make that edit

Default Font Features

   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012Jul/0155.html
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012Jul/0184.html
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012Jul/0377.html
   jdaggett: we've talked about the way font features are supported.
             Spec all along has wording that turns things like ligatures
             on by default
   jdaggett: When I was looking at implementations, I noticed that they were
             using two different modes
   jdaggett: default mode has no default font features
   jdaggett: enabling any value other than normal for a setting would flip
             the mode, and other settings would be change too
   <jdaggett> http://people.mozilla.org/~jdaggett/tests/simplekerningligs.html
   <jdaggett> http://people.mozilla.org/~jdaggett/images/fftrunk-ie10-chrome-defaults.png
   jdaggett: odd model; features pop on based on whether some random property
             is used or not
   jdaggett: test case shows rendering in different browsers
   jdaggett: there are distinct variations depending upon browser
   jdaggett: look at the 't' and 'o'; kerning is on in Fx but not in Wk or IE
   jdaggett: if you turn on a random feature, kerning gets enabled
   jdaggett: <jdaggett describes more examples>
   jdaggett: Microsoft said that this is a performance problem, and that
             we shouldn't turn on features by default
   <jdaggett> Existing definition of font-kerning:
   <jdaggett>   font-kerning : auto | normal | none
   <jdaggett> Additions needed to support "user agent decides defaults" behavior:
   <jdaggett>   font-feature-settings : auto | normal | <feature-tag-value>#
   <jdaggett>   font-variant : auto | normal | ...
   <jdaggett>   font-variant-ligatures : auto | normal | [ <common-lig-values> || <discretionary-lig-values> ... ]
   jdaggett: would need to have an additional 'auto' value, meaning that
             UAs could do whatever they want
   jdaggett: Not a good authoring model; too magic

   ChrisL: re performance: I saw an assertion that it slowed down, and
           another assertion that the slow-down was due to something else.
           Which is correct?
   jdaggett: Sergey (Microsoft) says there's a hit, but I think it's not major
   glenn: failing to pay attention to default features makes browsers non-compliant
   jdaggett: Sergey doesn't want IE to be non-compliant
   <bradk> ("bla" on) is the new 'zoom:1' for mode switching.
   jdaggett: I don't think there's any wording in the OpenType spec saying
             that you're non-compliant if you don't use the settings
   florian: I agree with jdaggett, better to have a good default
   <SteveZ> +1 for current default
   ChrisL: I agree, if authors could switch it off via stylesheet then
           we get best of both worlds
   ChrisL: font designers have designed the font knowing that it works well
           with certain settings
   ChrisL: better to trust what the font designer thought.
   jdaggett: we make the problem more difficult if authors are given ability
             to make lots of feature switches
   <ChrisL> would be interested to hear what Si Daniels from Microsoft
            Typography thinks about this

   <glenn> http://www.microsoft.com/typography/otspec/features_ko.htm#liga
   <glenn> says "UI suggestion: This feature serves a critical function in
           some contexts, and should be active by default."
   <glenn> so a number of registered OT features says they "should" be active by default

   jdaggett: within MS, is it just Sergey, or are there other people worried
             about performance?
   sylvaing: performance is always an issue
   sylvaing: recent raw memories about a past migration to a different
             tech that changed font layout
   sylvaing: using an 'auto' magic value is ok, but prefer to reach an
             agreement on concrete behaviour
   sylvaing: Fx proves that perf is ok, but we'd like more time to understand impact
   sylvaing: maybe we can recover from the perf hit, but we are cautious
             because it requires further work
   jdaggett: you can recover some perf by checking if the font uses features,
             and if not, go with the fast path
   jdaggett: would you object to spec as it currently is?
   sylvaing: if this is about going to CR, we would probably want to object
   sylvaing: we want to convince Sergey first
   JohnJansen: next step is to get an apples to applies comparison
   sylvaing: good to have test case to test against
   ChrisL: In summary, no objections at this stage, general agreement to go
           forward, but want a test case to test against

   szilles: important that default is default, but that there's a way of
            getting rid of things.  'none' value?
   <glenn> +1 for a 'none' value

   jdaggett: we need to finish spec before test cases
   ChrisL: I disagree: the sooner we have tests the better, since the spec
           isn't finished without them
   jdaggett: tests aren't ready for submission
   jdaggett: I wouldn't start to put test cases into normal W3 form until LC
   jdaggett: I don't see there would be a big lag between LC and test cases
   ChrisL: My personal opinion: I find it easier to understand spec when
           there are tests, and easier to spot problems.  Can be easier to
           get test out before LC
   <stearns> +1 on more test cases sooner
   <Ms2ger> What he said
   JohnJansen: We're ok in principle, but want test cases to test with
   <conflicting opinions about need for test cases sooner rather than later>
   szilles: where do we put incoming test cases that haven't been verified?
   <stearns> test cases that aren't ready for official submission can go
             into an "incoming" folder
   ChrisL: can you submit any tests you already have?
   ChrisL: easier for people to contribute tests if we can see what's already
           been done
   jdaggett: half of the problem is designing the font, not the test
   jdaggett: we have some fonts, but we will need more
   ChrisL: I understood that Tal Lemming was designing some fonts; would
           be good to see them
   ACTION: jdaggett to supply fonts and tests
   <trackbot> Created ACTION-486

   ChrisL: no resolution needed because it's not a change
   glenn: how about a resolution on the 'none' value?
   jdaggett: I'll think about it and write it up

   <glenn> apache FOP recently added a complex text path and chose to make
           it enabled by default, with a means for user to disable it,
           i.e., an equivalent to 'none'
   <glenn> http://xmlgraphics.apache.org/fop/1.1rc1/complexscripts.html#Disabling+complex+scripts


   <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012

   <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012#issue-10
   fantasai: Change request we want to reject:
   fantasai: We think it doesn't make sense to follow the flex flow of the item itself
   florian: What I understood makes me agree with fantasai
   * alexmog agrees with fantasai
   <szilles seeks clarification>
   ChrisL: any objections?
   RESOLVED: reject change proposal for flexbox LC issue 10

   <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012#issue-14
   fantasai: Issue 14
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jul/0121.html
   ... <fantasai describes issue>
   fantasai: in Hamburg we decided that it should redo line breaking
   fantasai: if you have a flexbox toolbar, don't have enough room, things
             flow into multiple line, if you want to collapse a set of items,
             you want to save that space
   florian: why not use visibility:hidden?
   fantasai: that just makes it invisible; doesn't save space
   fantasai: if you want things on different lines, usually that's a semantic thing
   fantasai: so you wouldn't use flexbox's multiline support
   szilles: did Kenny give additional reasons why he wanted a change?
   fantasai: no
   szilles: then I agree with the rejection
   RESOLVED: reject the change proposal

   <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012#issue-4
   ITEM: open issue, #4
   fantasai: comment was that since order doesn't affect speech or tab order,
             why does it have a generic name?
   florian: Tab also objected to renaming
   Tab: we did all the renaming before LC, and we discussed this specific
        issue knowing the consequences
   Tab: I don't feel that the comment adds anything new
   fantasai: display-order and box-order weren't specifically rejected;
             we just straw-polled on 'order'
   fantasai: and we hadn't decided on tab order, for example
   sylvaing: I don't understand why we're causing people pain by renaming
   sylvaing: renaming is important, but it has to happen early in spec roadmap
   florian: irrelevant for flexbox; what's done is done.  What do we think
            about this spec/issue?
   sylvaing: I don't see a strong case for renaming
   Tab: there's not a strong case
   * alexmog is not in love with some naming in flexbox and would welcome
             new names that are obviously awesome.
   * alexmog "awesome" is required though, unless something much awesomer
             is proposed, leave the names alone!

   szilles: I think we should think about having a name freeze time that
            predates LC as a step in the process
   szilles: but I observe that this name change is relatively recent
   szilles: any name change probably needs a couple of months to smooth
            itself out
   <JohnJansen> +1 to szilles on having a freeze to names that predates LC
   szilles: let's try to fix it so we don't do this in future, so that
            we can have those months
   <sylvaing> +1 to szilles as well
   <dbaron> I agree with Steve that we have to be able to revisit a decision
            two months after we make it.
   ChrisL: a way forward is to not change the name but have a note explaining
           why the name is what it is, and why there might be issues about it
   fantasai: that's not the issue; the spec is clear about what the property does
   fantasai: I'm not going to object to anything, but this issue has been
             in the open for a while, and was filled very shortly after the
             previous resolution
   ChrisL: Will we make an exception for this one case?
   sylvaing: we don't have a new name!
   florian: if we change, we must change sooner not later
   fantasai: question would be: if we redid the straw poll, would people
             change their minds
   Tab: I wouldn't, but I would still be objecting
   fantasai: what's the rationale for rejecting the change proposal?
   Tab: small benefit, and too late in process
   fantasai: too late is the good reason you're giving not to change
   szilles: I agree with fantasai
   RESOLVED: reject the change proposal for reason of being too late in the process
   Bert: "too late in process" is not a good reason on a WD

   <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012#issue-17
   fantasai: please could everyone try to think about the issue for the next call
   alexmog: why is it even an issue? placeholders have no properties
   Tab: I argue the other way; placeholders should "inherit" reasonable
        properties from their abspos
   fantasai: they don't get padding or margin, why should they get 'order'?
   fantasai: You'd have to specify this explicitly
   dbaron: does it concern painting order?
   Tab: that would be a separate question
   alexmog: two adjacent abspos, is there one or two placeholders?
   alexmog: does alignment apply?
   Tab: yes
   dbaron: I think that by default, nothing applies to the placeholder,
           and if you want something to, you should say so.
   szilles: I think we should deal with 18 first, then 17
   antonp: I hate placeholders.

Meeting closed.

====== Post-meeting logs wrt placeholders n' things ======

   <fantasai> tabatkins: So, what was your rationale that wasn't "it's too
             late in the process"?
   <Ms2ger> It's too late in the real world?
   <fantasai> Ms2ger: note "process" is lower-case :)
   <Bert> I think the argument is that the WG can't find any better name.
   <Ms2ger> No
   <Ms2ger> The argument is that flexbox properties have been renamed ten
            times too much already
   <tabatkins> I gave it in the call.  The benefit is arguable (I think
               'order' is a great name). If we assume there's a benefit,
               it's very small.  The pain of changing names this late in
               the process outweighs the benefit.
   <antonp> display-order might be more appropriate in one sense, but it
           looks like a longhand component property of display
   <antonp> Which makes it a bad choice IMO
   <fantasai> I think Florian suggested 'visual-order' as an alternative,
              maybe that's better?
   <fantasai> Bert: That is a better rationale to give
   <alexmog> if I was making a call right now to implement flexbox unprefixed,
             I would say wait for a while, naming can still change
   <antonp> Yeah, visual-order is worth thinking about
   <alexmog> oh wait, we just have done that...
   <alexmog> "late in the process" is a valid argument, but lack of a better
             name is a stronger one
   <tabatkins> And with their powers combined...
   <antonp> it's an invincible argument
   <alexmog> "late" really means that a change has to be really really
             awesome to be accepted
   <tabatkins> Exactly.  Please don't read "late" as "lol too late, pay
               more attention"

   <alexmog> on placeholders....
   <alexmog> earlier decisions on placeholders were based on the agreement
             that absolutely-positioned flex items don't have any meaningful
             use cases
   <alexmog> then whatever is defined for absolute flex items needs to be
             definite and simple to implement
   <tabatkins> Yes.
   <alexmog> placeholders with no properties whatsoever IMO are best
   <alexmog> no order or alignment
   <fantasai> that's what Mozilla implements, too
   <fantasai> although bz says it would be easy to make it accept 'order'
   <alexmog> of course it is easy. alignment is easy too. just why we care???
   <tabatkins> I'm perfectly fine either way.
   <alexmog> we can even define that placeholders are zero size and are
             all at (start, before)
   <fantasai> and therfore don't affect layout :)
   <alexmog> yes
   <fantasai> which solves #18
   <tabatkins> That's called "there's no such thing as placeholders,
               tables are an aberration".
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jul/0419.html
   * fantasai would be perfectly happy with that
   <alexmog> note that with the latest change to how text wrappers work,
             it may be reasonable
   <fantasai> looks like Proposal A in Kenny's email
   <tabatkins> Yes, it is.
   <alexmog> before, abspos element in the middle of text would behave
             just as if it was in the middle of that text anywhere
   <alexmog> now, abspos elements split text blocks... could just as well
             get collected at a random place, like table captions...
   <tabatkins> I'm fine with anything reasonably consistent.  I was trying
               to line up with the model suggested by table layout, but if
               we'd prefer to ignore that as a mistake and just say that
               complex layouts don't play with well abspos auto positioning,
               I'm fine with that as well.
   <alexmog> (but don't take this too seriously, I don't think I actually
             like that more than plain vanilla placeholders with no
             properties propagated to them)
   <fantasai> is the static position of an abspos a point or a box?
   <arronei> it should be a point.
   <fantasai> http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width
   <fantasai> There's different positions for left and right
   <fantasai> so maybe it's a line segment
   <fantasai> :)
   * fantasai trying to figure out the implications of Proposal A, which
              makes the hypothetical box the flex container
   <arronei> Maybe its a line segment that is a point.
   <fantasai> arronei: that would make the left and right static positions
              identical, which they are not in 10.3.7
   <fantasai> if the "hypothetical box" in Chapter 10 is made to be the flex
   <fantasai> then the effect is the same as having it be a point placed
              in the start head corner
   <fantasai> yes?
   <arronei> yes that is what I would think
   <fantasai> Ok, so that's proposal A
   <fantasai> Proposal B is to define it as halfway between the margin edges
              off the two flex items its between
   <fantasai> but that doesn't say what the behavior is at the edges
   * fantasai is going off http://lists.w3.org/Archives/Public/www-style/2012Jul/0419.html
   <fantasai> Proposal C is to make each abspos placeholder a flex item
   <tabatkins> He elaborates (it's what I tried to do earlier, where it
               depends on the justify-content)
   <fantasai> B and C have the issue of, do 'order' and/or 'align-self'
              have an effect on the placeholder
   <tabatkins> B has the further problem of actually being work, when
               this is probably a non-issue.
   <fantasai> yeah
   <arronei> 'order' I don't think would either
   * fantasai leans towards A, which makes all these issue snon-issues
   <arronei> Yeah I think "A" makes more sense.
   <tabatkins> It just means that we're abandoning the precedent set by tables,
               and killing any possible usefulness of auto positioning.
   <fantasai> Spec prose would just be then "The hypothetical box used to
              calculate the static position of an abspos box corresponds
              to the content-box of the flex container."
   <fantasai> tabatkins: if we're going to make it useful, we should
              actually make it useful. Right now it's half-assed.
   <tabatkins> I'm not objecting.  Just laying the consequences out fully. ^_^
   <arronei> I think this is an issue we should really target in the next
             level if we think its important.
   <fantasai> I can't think of a good use case.
   <fantasai> The ones people brought up seem to make more sense by putting
              the abspos inside a flex item
   <arronei> I can't either at the moment.
   <fantasai> I think it's more likely that authors will be annoyed that
              abspos elements take up space than that they'll be annoyed
              it doesn't sort-of-kind-of follow its would-be flex position
   <arronei> So I think we are settled on "A" for the moment.
   <fantasai> You and I are, anyway :)
   <fantasai> tabatkins, alexmog ?
   <tabatkins> Don't particular care, but let me ping ojan and tony.
   * fantasai thinks antonp would be happy with A, too
   <alexmog> if "A" means the container is the auto position, I am personally
             fine with that
   <alexmog> I think the placeholder is marginally more useful though,
             and more consistent with abspos elsewhere (e.g. grid)
   <alexmog> both us and mozilla already implement placeholders in some way,
             so it is not more work.
   <alexmog> but I would be ok either way
   <tabatkins> Ojan and Tony are okay with the change.

Conclusion pending further WG discussion. Cliffhanger until the next episode! :D

Received on Thursday, 19 July 2012 05:04:08 UTC