See also: IRC log
<trackbot> Date: 18 July 2012
<arron> Zakim: Who is on the phone?
<glenn> i'm also hearing clicking
<rbetts> better now
<glenn> it went away
<sylvaing> that was intense
<scribe> ScribeNick: antonp
Extra agenda item: css3-color errata
will be item 1.5
<arron> Zakim: aabb is me
<scribe> ACTION: Chris to follow up on invited expert issue: ask about employment status [recorded in http://www.w3.org/2012/07/18-css-minutes.html#action01]
<trackbot> Created ACTION-484 - Follow up on invited expert issue: ask about employment status [on Chris Lilley - due 2012-07-25].
ITEM: css3-color errata
<scribe> new comment: css3-color says don't use system colors, use something else
It's a change to a non-normative note
fantasai: it makes sense
dbaron: are we still pushing the 'appearance' property forward? I thought we weren't
ChrisL: the note says that it's
... the change deletes the entire note, and says that it's deprecated
... it removes the admonition to use the 'appearance' property
glenn: avoiding having specs referring to future features would be a good idea
RESOLUTION: accept ChrisL's suggested change
<fantasai> fantasai: There was also an errat on currentColor that's missing
ITEM: DOM issue
florian: function called
... not defined what it returns
... 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
... any objections?
sylvaing: should we check implementations first?
<glenn> can someone file a bug against cssom to record this?
florian: I don't see what other behaviours could be useful
<glenn> ok, i will do so
RESOLUTION: accept the proposal from florian
<dbaron> is a testcase
Bert: I think that's what the
recommendation already says
... the current DOM spec
... 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> DOM 2 style
<glenn> so it doesn't exactly say return what getPropertyValue() returns
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
<dbaron> well, actually, it's a copy-paste with a bugfix
RESOLUTION: florian to file CSSOM bug and glenn to update CSSOM spec
florian: descriptor called
... introduced to be an equivalent to ??? dip
... introduced to be an equivalent to ??? dpi
... 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)
<fantasai> alexmog_: Did you get a chance to look at http://lists.w3.org/Archives/Public/www-style/2012Jul/0385.html ?
<tabatkins_> FYI, WebKit also returns the getPropertyValue() value from removeProperty().
RESOLUTION: drop 'resolution' descriptor from css-device-adaptation
<scribe> ACTION: florian to make that edit [recorded in http://www.w3.org/2012/07/18-css-minutes.html#action02]
<trackbot> Created ACTION-485 - Make that edit [on Florian Rivoal - due 2012-07-25].
<alexmog_> fantasai: yes, it seems reasonable
ITEM: default font features
jdaggett: we've talked about the
way font features are supported. Spec all along has wording
that turns things like ligatures on by default
... When I was looking at implementations, I noticed that they were using two different modes
... default mode has no default font features
... enabling any value other than normal for a setting would flip the mode, and other settings would be change too
jdaggett: odd model; features pop
on based on whether some random property is used or not
... test case shows rendering in different browsers
... there are distinct variations depending upon browser
... look at the 't' and 'o'; kerning is on in Fx but not in Wk or IE
... if you turn on a random feature, kerning gets enabled
... <jdaggett describes more examples>
... Microsoft said that this is a performance problem, and that we shouldn't turn on features by default
<jdaggett> Existing def'n 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
... 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 dont' 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
... font designers have designed the font knowing that it works well with certain settings
... 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
jdaggett: within MS, is it just Sergey, or are there other people worried about performance
sylvaing: performance is always an issue
<glenn> says "UI suggestion: This feature serves a critical function in some contexts, and should be active by default."
<ChrisL> would be interested to hear what Si Daniels from Microsoft Typography thinks about this
sylvaing: recent raw memories about a past migration to a different tech that changed font layout
<glenn> so a number of registered OT features says they "should" be active by default
sylvaing: using an 'auto' magic
value is ok, but prefer to reach an agreement on concrete
... Fx proves that perf is ok, but we'd like more time to understand impact
... maybe we can recover from the perf hit, but we are cautious because it requires further work
jdaggett: would you object to spec as it currently is/
sylvaing: if this is about going
to CR, we would probably want to object
... we want to convince Sergey first
<fantasai> jdaggett^: you can recover some perf by checking if the font uses features, and if not, go with the fast path
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 agains
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
<alexmog_> fantasai -- reread your proposal on table captions, still agree
jdaggett: I wouldn't start to put test cases into normal W3 form until LC
<fantasai> alexmog_: good, I'll close that issue pending edits, then :)
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?
<conflicting opinions about need for test cases sooner rather than later>
szilles: where do we put incoming test cases that haven't been verified?
ChrisL: can you submit any tests you already have?
<stearns> test cases that aren't ready for official submission can go into an "incoming" folder
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
... 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
<scribe> ACTION: jdaggett to supply fonts and tests [recorded in http://www.w3.org/2012/07/18-css-minutes.html#action03]
<trackbot> Created ACTION-486 - Supply fonts and tests [on John Daggett - due 2012-07-25].
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
ITEM: flexbox issues
<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'
fantasai: Change request we want
... <see e-mail>
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
<szilles seeks clarification>
ChrisL: any objections?
RESOLUTION: reject change proposal
fantasai: Issue 14
fantasai: <fantasai describes
... in Hamburg we decided that it should redo line breaking
szilles: did Kenny give additional reasons why he wanted a change?
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
... if you want things on different lines, usually that's a semantic things
... so you wouldn't use flexbox's multiline support
<szilles reasks his question>
szilles: then I agree with the rejection
RESOLUTION: reject the change proposal
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
... I don't feel that the comment adds anything new
fantasai: display-order and
box-order weren't specifically rejected; we just straw-polled
... and we hadn't decided on tab order, for example
sylvaing: I don't understand why
we're causingin people pain by renaming
... 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
szilles: I think we should think
about having a name freeze time that predates LC as a step in
... but I observe that this name change is relatively recent
... 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
... I'm not going to object to anything, but this issue has been in the open for a while
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 only good reason
szilles: I agree with fantasai
RESOLUTION: reject the change proposal for reason of being too late in the process
ITEM: flexbox issue 17
Bert: "too late in process" is not a good reason on an WD
fantasai: please could everyone try to think about the issue for the next call
alexmog: why is it even an issue?
Tab: I argue the other way; placeholders should "inherit" reasonable properties from their abspos
fantasai: they dont' get padding or margin, why should they get 'order'?
dbaron: does it concern painting order?
Tab: that would be a separate question
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/does something relevant/does that, i.e., calls getPropertyValue(), removes the property, and returns what getPropertyValue() returned before removing the property/ Succeeded: s/??/sylvaing/ Succeeded: s/??/glenn/ Succeeded: s/ChrisL:/ChrisL: in summary,/ Succeeded: s/??/JohnJansen/ Succeeded: s/principal/principle/ Succeeded: s/next issue/flexbox issue 17/ Found ScribeNick: antonp Inferring Scribes: antonp WARNING: No "Topic:" lines found. WARNING: No "Present: ... " found! Possibly Present: Apple Bert CSSWG_LogBot ChrisL Hixie ITEM JohnJansen Liam Microsoft Mozilla Ms2ger P12 P15 P57 Rossen ScribeNick SimonSapin SteveZ Tab TabAtkins aa aaa aabb alexmog alexmog_ antonp arno arron arronei ayanes bradk css dbaron decadance dglazkov drublic fantasai florian glenn gsnedders heycam hober isherman jarek jdaggett jet_ jkew joined krijnhuman krit1 logbot macpherson miketaylr paul___irish plinss rbetts shans shepazu stearns sylvaing szilles tabatkins_ tantek trackbot vhardy You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 18 Jul 2012 Guessing minutes URL: http://www.w3.org/2012/07/18-css-minutes.html People with action items: chris florian jdaggett WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]