W3C home > Mailing lists > Public > www-style@w3.org > February 2013

[CSSWG] Minutes Tucson F2F 2013-02-05 Tue PM II: Counter Styles, Top Layer Positioning, Variables

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 15 Feb 2013 14:16:56 -0800
Message-ID: <511EB3D8.7010506@inkedblade.net>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:06 GMT