- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 19 Jul 2012 01:03:32 -0400
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- 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
removeProperty
http://lists.w3.org/Archives/Public/www-style/2012Mar/0327.html
- 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.)
http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012#issue-10
- RESOLVED: 'visibility: collapse' redoes line breaking, as there are
good reasons to want that. (No change.)
http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012#issue-10
- 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
Present:
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
CSSOM
-----
<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>
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
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
Flexbox
-------
<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
container
<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