Cascading Style Sheets (CSS) Working Group Teleconference -- 18 Jul 2012

<trackbot> Date: 18 July 2012

<arron> Zakim: Who is on the phone?

<rbetts> same

<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

<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 note says that it's been deprecated
... 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

<florian> http://lists.w3.org/Archives/Public/www-style/2012Mar/0327.html

ITEM: DOM issue

florian: function called removeProperty
... 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> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cbody%20style%3D%22color%3A%20blue%22%3E%0A%3Cscript%3E%0Avar%20s%20%3D%20document.body.style%3B%0Adocument.write(s.removeProperty(%27color%27))%3B%0A%3C%2Fscript%3E

<dbaron> is a testcase

Bert: I think that's what the recommendation already says
... the current DOM spec

florian: Oh?
... 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

ITEM: css-device-adaptation

florian: descriptor called 'resolution'
... 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> 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
... 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> 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
... 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 they want
... 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 worlds
... 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

<glenn> http://www.microsoft.com/typography/otspec/features_ko.htm#liga

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 behaviour
... 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?

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

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

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

<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 to reject:
... <see e-mail>

<glenn> http://xmlgraphics.apache.org/fop/1.1rc1/complexscripts.html#Disabling+complex+scripts

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

ChrisL: any objections?

RESOLUTION: reject change proposal

<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: <fantasai describes issue>
... 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

fantasai: no

szilles: then I agree with the rejection

RESOLUTION: 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
... 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'
... 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 the process
... 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

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

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

- DRAFT -

Cascading Style Sheets (CSS) Working Group Teleconference
18 Jul 2012

Attendees

Contents

Summary of Action Items