- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 15 Feb 2013 14:16:56 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Counter Styles
--------------
- RESOLVED: Remove the example about simulating filled counter styles and
add a feature for filled counter styles.
- RESOLVED: 2-byte minimum for counters.
- RESOLVED: If current value + increment is outside of the range, then
do not increment. (Not allowed to overflow the integer.)
- RESOLVED: Current spec is OK for fallback cycle detection per counter value
(rather than per counter style).
- RESOLVED: Keep ethiopic-numeric in spec, but mark at risk.
Top Layer Positioning
---------------------
Discussed top layer positioning (as used for fullscreen) and how it can
be accessed via CSS. Seems that nobody's really clear on exactly how it's
supposed to work wrt positioning and scrolling behavior [?] and more
investigation is needed on what the "magic" requirements of HTML5 actually
should be.
Variables
---------
- RESOLVED: "var-" is lowercase and case-sensitive.
- RESOLVED: Publish Cascading Variables as LC
- dbaron noted that variables should be defined to allow
[ value | CDO S* | CDC S* ]+
====== Full minutes below ======
Counter Styles
--------------
ScribeNick: Bert
TabAtkins: [looking up the issues]
<TabAtkins> http://dev.w3.org/csswg/css-counter-styles-3/#alphabetic-system
TabAtkins : section 5
TabAtkins: example 6
TabAtkins: Fixed-width counter style, example
TabAtkins: It's a hack, using alphabetic style and counter-reset
to create zero-filled numbers.
TabAtkins: Is this important enough to add a fixed width system?
fantasai: This is not good practice.
fantasai: If we do them, let's do them properly.
fantasai: Otherwise, remove example.
fantasai: Reading from a screen reader, or something, gets the wrong values.
glazou: They read 0-0-0-3
fantasai: you want them to read "3"
TabAtkins: Just remove it? Or add fixed width system?
glazou: The latter
TabAtkins: And what about negative values and out of range?
fantasai: Say fill with how many digits.
TabAtkins: negative prefix
SteveZ: another sign position
SteveZ: Need to say if you have space for sign or not.
SteveZ: Can ad a value 'sign' to say you want space for sign.
SteveZ: So that neg values still same width.
fantasai: Maybe then prefix it with spaces.
SteveZ: And for overflow, just overflow.
TabAtkins: OK, I'll do that.
RESOLVED: Remove the example about simulating filled counter styles and
add a feature for filled counter styles.
TabAtkins: Sect 3.5,
TabAtkins: issue 2
<dbaron> http://dev.w3.org/csswg/css-counter-styles-3/#counter-style-range
TabAtkins: Infinite range obviously not actually supported.
TabAtkins: should we specify a minimum required range?
TabAtkins: Something like at least 16 bits?
TabAtkins: A nice base-2 number?
fantasai: more than 256!
TabAtkins: Yes, 2 bytes or so
fantasai: We discussed this elsewhere, too.
TabAtkins: Currently between 16 and 32 bits
TabAtkins: 16 bits should make everyone happy.
TabAtkins: Nobody actually does 32, maybe 31 bits
Rossen: [missed]
TabAtkins: Easier to test with required range
SteveZ: [...]
dbaron: We have 32 bit signed int.
TabAtkins: Opera something like 2 billion
fantasai: 32,000 is more than we need.
SteveZ: No, it's not. Machines generate more than that.
dbaron: Yes, I can imagine that
plinss: Can also start a count at 20mln and than have only 20 entries.
fantasai: 3 bytes, then?
plinss: Should we have a minimum range?
SteveZ: Yes, we can always raise it.
TabAtkins: Yes
tantek: Unit length: what did we decide?
TabAtkins: Doesn't require a range right now.
TabAtkins: We couldn't get consistent answer in time.
tantek: We are going to LC?
TabAtkins: yes
TabAtkins: Lengths are more complicated
fantasai: They can be represented as either floats or integers.
TabAtkins: And same range in number of inches and pixels is not the
same range in absolute lengths.
TabAtkins: Should I pick 2 bytes?
dbaron: Fine as a minimum.
SimonSapin: More important than a minimum range is to define what to
do what an implementation-specific range is reached
plinss: Should not wrap.
TabAtkins: yes
glenn: 1114112
<dbaron> (17 * 2^16)
RESOLVED: 2-byte minimum, clamp, no wrap
TabAtkins: Whenever you hit your maximum, clamp to that instead of
wrapping into negatives
TabAtkins: When you read the top, don't wrap, just stop there.
dbaron: It's about counter-reset with some value
SteveZ: Incrementing a clamped value doesn't increment it.
SteveZ: Incrementing maximum value has no effect.
dbaron: You can increment with more than 1
dbaron: So have to say you become the maximum.
plinss: Other option is to stay and not increment.
Peter: so if the increment would put you over the maximum, do you increment
to the maximum, or stay where you are?
SteveZ: Can also say that, increment that would go beyond does nothing.
plinss: Say you're at max-1 and increment is 100
plinss: Should not go to max
dbaron: OK with that
RESOLVED: if current value + increment is outside of the range, then
do not increment
TabAtkins: issue about fallback cycles
TabAtkins: For styles with limited range.
TabAtkins: e.g., circled numbered in Unicode.
TabAtkins: You normally drop back to decimal.
TabAtkins: Fallback is currently per representation
TabAtkins: Can have e.g. two styles, even num and odd number, and they fall
back to each other, no cycle, so it works.
TabAtkins: Alternately, if two styles refer to it, can call that a cyle.
TabAtkins: Cycles fall back to decimal.
TabAtkins: What do implementers think?
SimonSapin: Did implement first (per representation). Fall back to decimal
is fine.
dbaron: Don't understand the issue yet, so can't say.
TabAtkins: [drawing on white board]
TabAtkins: @counter-style only-even {fallback: only-odd}
TabAtkins: @counter-style only-odd {fallback: only-even}
dbaron: curent spec is OK, then. Fallback per counter value, not per
counter style.
RESOLVED: current spec is OK for fallback per counter value
TabAtkins: Issue with Ethiopic
TabAtkins: Was in 2.1, not in 2.0
TabAtkins: Cannot be represented with @counter-style
TabAtkins: Everything else can, or was already in 2.0
TabAtkins: Do we care about this style to predefine it?
fantasai: Leave and mark at risk.
TabAtkins: Not sure we'll resolve it, then.
fantasai: If after CR nobody implemented it, we drop it.
fantasai: Nothing to resolve, just depends on implementers.
tantek: In general, put it at risk if not implemented.
dbaron: We have 5 ethiopic styles
TabAtkins: The alphabetic styles are fine.
dbaron: We have a 62-line algo for the ethiopic-numeric style.
TabAtkins: I suspect it is there because hixie knew moz had some support.
TabAtkins: I can mark it at risk.
RESOLVED: mark ethiopic-numeric at risk.
fantasai: So only some edits and then last call?
TabAtkins: yes
Text
----
[longer than 1 hour, move to tomorrow]
Top Layer Positioning
---------------------
<smfr> http://lists.w3.org/Archives/Public/www-style/2013Jan/0223.html
TabAtkins: DOM spec for dialog and full screen have concept of something
on top of everything else.
TabAtkins: We don't have that in CSS.
TabAtkins: Abs pos doesn't guarantee the top.
smfr: stacking contexts can be on top.
TabAtkins: I proposed to address this directly, some extension to
position or z-index
TabAtkins: separate stacking context
TabAtkins: that is put on top of everything else.
glazou: Seems similar to alerts
TabAtkins: Yes
glazou: Security issue?
tantek: yes
glazou: Same issues with alerts
TabAtkins: Can already do it now.
smfr: Not overlaying the chrome
glazou: But if a page does that now, you can still put something above it.
glazou: user style sheet, e.g..
TabAtkins: Maybe users cannot do that anyway, right now.
TabAtkins: Order in the document may prevent it.
smfr: Security issues not unique to this.
dbaron: So it needs to escape from filters, etc.?
TabAtkins: Yes, no effect on ancestor of [...]
SteveZ: Only one such stacking context?
TabAtkins: Yes, only one.
SimonSapin: What happens to fixed-pos elements in a transform?
SimonSapin: Are transformed?
TabAtkins: Yes, but not fixed pos anymore; treated like abspos.
Rossen: And with full screen?
TabAtkins: This is a non-magic full-screen. You can get it without magic
in CSS.
TabAtkins: Seems wasteful to have magical capabilities in browser that
user cannot invoke himself.
smfr: We want to be able to implement everything through CSS.
smfr: Fullscreen has a backdrop element.
TabAtkins: That goes down in the top context, too, doesn't it?
TabAtkins: Put it as sibling of the root... no... We'll figure it out.
TabAtkins: Does anybody see problems?
dbaron: Where is the proposal?
TabAtkins: [points at screen]
TabAtkins: the top layer cannot fixed pos, but it can be canvas-relative.
glazou: Scollable?
TabAtkins: Yes
smfr: fullscreen describes a dialog centered in the viewport. We cannot
currently do that in CSS.
Rossen: [...] go into top layer?
TabAtkins: Yes.
smfr: So what spec does this go into?
TabAtkins: Could be positioning spec.
TabAtkins: Arron is editor.
TabAtkins: I can become co-editor as well.
smfr: What is syntax?
TabAtkins: Don't know yet.
fantasai: would change order, but not position?
smfr: Position, too
fantasai: relative to what?
smfr: initial containing block, maybe.
Rossen: yes, initial CB, but also above everything else.
Rossen: like position: page
Rossen: escapes all its ancestors.
Rossen: sized into the root, but then scrolled with everything else.
fantasai: 'pos: page' doesn't exactly do that.
Rossen: positioning spec seems right place.
Rossen: let's start discussing it, and when you have something we put
it in.
SteveZ: We talked about Extension to let you pick which ancestor to be
relative to.
SteveZ: this is similar.
TabAtkins: All current position values have to unmagic themselves.
TabAtkins: one more value doesn't seem bad.
SteveZ: Split it into two: choose CB and choose layer?
TabAtkins: Haven't thought about syntax yet.
SteveZ: So you say everything can go into that top layer.
fantasai: Seems more complicated than it looks at first glance.
fantasai: scrolling issues as well
fantasai: if you have a long scrolling document and you want to put
something into the top layer, you want it visible right there,
not positioned into the ICB which is scrolled way off the screen
Rossen: Maybe not only positioned elements in top layer.
Rossen: e.g. a form where each element in turn can be on top.
Rossen: pop it up.
TabAtkins: what does that mean.
smfr: Like graying out everything but the element.
smfr: Would like to not separate positioning from layering.
smfr: Makes it harder to implement.
smfr: a child of a fixed element can then move.
SteveZ: You may want to position it at its current position, but in
top level.
plinss: Sticky positioning?
plinss: Two or three attributes that are orthogonal.
plinss: viewport aspect, positioning aspect, layering aspect.
plinss: But I can see smfr's concerns.
SteveZ: You can get some of that already.
smfr: If you abs pos it, it may be relative to an animated ancestor...
smfr: but it is not contained within its hierarchy
smfr: Offset is magically computed, even if CB is ICB.
smfr: Don't really like proposals where something is laid out and depends
on arbitrary elements.
smfr: All these dependencies.
SteveZ: Understand, but trying to solve fantasai's problem.
fantasai: We need use cases.
TabAtkins: We have some.
smfr: See html5
<smfr> http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#set-up-the-position
TabAtkins: Trying to solve fullscreen in CSS.
fantasai: OK, I think I understand better now.
fantasai: Seems like you want effectively a new canvas on top of the old
canvas and the scrollbars control that new canvas.
fantasai: This is very different from throwing it into the ICB.
smfr: HTML spec says "magically aligned"
smfr: we want to remove the magic.
TabAtkins: Just one new canvas.
fantasai: When that new canvas has content, than you cannot scroll the
old canvas?
tantek: You can still scroll it.
SteveZ: So there is a lock between them and you scroll them together.
tantek: Different from fullscreen. That doesn't scroll along. Dialog does.
smfr: Fullscreen is for backdrop element,
smfr: that does other magical things.
fantasai: Do you want to ever scroll the dialog off the screen?
TabAtkins: Scroll it a bit.
SteveZ: You want to scroll what's behind it, because the dialog is
obscuring it!
fantasai: Not a bad idea, can be investigated. Maybe not right now.
TabAtkins: I'll figure out more requirements and proposals
SteveZ: We have a whole bunch of things this must fit into. HTML5 doesn't
have that. Just has magic.
SteveZ: I'm OK with positioning other than to CB.
Variables
---------
<TabAtkins> http://dev.w3.org/csswg/css-variables
glazou: I spoke about this in Paris and saying that it is not variables,
but user-defined properties helped people a lot.
TabAtkins: But we made them because we needed variables
TabAtkins: But "user-defined properties" doesn't explain what they are for,
fantasai: Somebody proposed this mechanism a long time ago
fantasai: before 2008
fantasai: and described them as variables
fantasai: So I think that is fine.
fantasai: If want to call them something else, then should also change
the prefix from "var-" to something else.
TabAtkins: They are made for use as variables.
bert: I explained them recently in the same way as glazou.
<tantek> Cascading Variable Sheets? CVS?
<fantasai> no, they're part of CSS, not a separate language
bert: arbitrary property-value pairs attached to element
fantasai: Leave title alone, but change the prefix?
TabAtkins: Section is already called "custom properties"
glazou: I saw how people reacted. They didn't get variables.
glazou: People do look at the name of the document.
glazou: The name matters.
glazou: more than the abstract.
fantasai: "Custom referenceable properties"
glazou: I can live with variables. It's unfortunate.
Rossen: Naming is important.
glazou: I explained earlier why these were not variables.
glazou: I had an action item for it.
glazou: Explain why there are custom properties.
* fantasai has to say, kindof leaning towards' François' suggestion
to use my- instead of var- ... and also my() instead of var()
<fantasai> emphasizes we're grabbing the property value from this element,
not somewhere else in the style sheet
<dbaron> I'd like "unclosed" to change to "unmatched" in section 2
plinss: case-insensitivity of prefix is odd, b/c variable name is
case-sensitive.
fantasai: Would changing the dash to a space help that?
fantasai: "var" <space> <name>, 'var foo' instead of ''var-foo'
TabAtkins: Would be relatively easy to change.
glazou: No, I don't want that.
<TabAtkins> p { var foo: blue; color: var(foo); }
TabAtkins: Force lowercase?
plinss: That would be more consistent.
plinss: not necessarily falls under general rule we decided yesterday.
jdaggett: Simple exception is ok.
jdaggett: consistency as much as possible, but in this it's ok
plinss: If it is case-insensitive, then will be reserialized in lowercase.
dbaron: not so great for people who write their CSS in uppercase
plinss: make the whole thing case-sensitive, and var must be in lowercase.
[discussion about fashions for upper and lowercase. HTML used be written
with tag names in uppercase, before XML]
plinss: if VAR- is changed to var-, a naive script writer will make a bug.
RESOLVED: "var-" is lowercase and case-sensitive.
glazou: In section 4, API, can you add an example?
TabAtkins: Sure.
SimonSapin: Want to switch to referencing css3-syntax instead of CSS2.1
TabAtkins: yes.
TabAtkins: it's minor change
TabAtkins: what do other implementers think?
glazou: Do we not have a class for invalid example in specs?
[discussion about flashy styles for wrong examples]
TabAtkins: Value of custom property is defined as anything matching
'value' production in CSS2.1 grammar
TabAtkins: value production in CSS2 grammar
TabAtkins: It's very wide
Scribe: fantasai
TabAtkins: However, some surprising lacks, due to 2.1 not being a total
grammar
TabAtkins: None are actually necessary, e.g. according to 2.1
TabAtkins: Technically could put something like var-a: {a:b};
TabAtkins: but var-a: {a}; is not valid
TabAtkins: It's a particularity of how CSS2.1's grammar production works
plinss: Any reason you'd want something like that?
TabAtkins: If you're just using it to pass data around and using in JS,
would be nice to take more arbitrary values without parsing
into a string
glenn: CSSOM issue, DOM2Style specifies that properties had to have
some value
glenn: Can't be null
TabAtkins: Doesn't seem like a necessary restriction to apply
glenn: Useful b/c tells you that it as never specified in the first place
glenn: Parse in CSS2 a value list property vs entry that doesn't have a value
glenn: enumerate items list, ask for property that wasn't specified
glenn: return null
glazou: Since value of a variable is usable right now only on the
right-hand side of a property, is it worth discussing this?
TabAtkins: This isn't useful in CSS itself, but to pass around in JS
it's useful
TabAtkins: François Remy is using this to pass information for some
polyfills, e.g.
TabAtkins: Think making it easy to polyfill is a good idea
TabAtkins: When you were saying, "This isn't variables, it's custom
properties", this is exactly that
Bert asks for clarification
dbaron: You're wrong, TabAtkins.
dbaron: They're both valid.
dbaron: I'm not sure that the value production..
dbaron: I went back to this at one point, only one very minor change
I would make
dbaron: It really allows pretty close to anything.
TabAtkins: would have to look at it more closely myself then
dbaron: Value can be any or block
dbaron: and in that case both are block
dbaron: block is a brace and then can have, first option is any,
dbaron: any can be ident
dbaron: another one is colon
dbaron: so you're done
dbaron: A block can contain another block
TabAtkins: Then I'll look to see if there's any change we need to make
dbaron: There's a change I proposed awhile ago, looking for it.
TabAtkins: Ok, I will look to see if we need any changes.
plinss: I remember CDO/CDC only allowed in top level of style sheet
glazou: Only a few minutes remaining
glazou: Any objections to publishing LC?
Rossen: What about the name?
plinss, fantasai: We'll rename it at Last Call.
RESOLVED: Publish Cascading Variables as LC
Bert: Which other groups should we ping?
WebApps, SVG, i18n (wrt case-sensitivity)
glazou: Side comment: At some point wouldn't someone say we should map
data attrs to var properties?
Meeting closed.
<dbaron> I would prefer the definition be [value | CDO S* | CDC S* ] +
<dbaron> so that we don't have to deal with forbidding CDO/CDC at top-level
but allowing them inside () [] {}
<dbaron> maybe we could discuss that tomorrow
Received on Friday, 15 February 2013 22:17:24 UTC