[CSSWG] Minutes Sophia-Antipolis F2F 2014-09-08 Part II: Line Grid, CSS UI, Geometry Working Draft, z-index and SVG, Prioritizing image(color), randomize(), Animation and calc() of Keywords

Line Grid

  - RESOLVED: publish WD of line-grid


  - RESOLVED: add 'caret-color' to css3-ui
  - A desire to color the background/foreground of selected text
      lead to a conversation about bringing ::selection back and
      potential issues with exposing security-sensitive items (such
      as spell-check)
  - RESOLVED: Add ::selection to Pseudo-elements 4
  - RESOLVED: Outline corners follow border-radius (no additional
              outline-radius property needed)

Geometry Working Draft

  - RESOLVED: Publish working draft for geometry interfaces

z-index and SVG

  - RESOLVED: The root SVG element automatically creates a stacking
      context, as does <foreignObject>.
  - RESOLVED: SVG elements honor z-index automatically (like flex
      items), without requiring 'position'

Prioritizing image(color)

  - image() function is undergoing edits for Level 3


  - RESOLVED: Not pursuing randomness at this time.

Animation and calc() of Keywords

  - There is generally high interest in animating to/from keyword
    values, but that means the keywords must be acceptable within
    calc(), which presents behavioral complications for many keywords

  - Krit will investigate implementer interest and draft up a
    preliminary whitelist of keywords that could be included in

  - The question of why calc() doesn't have min/max functions was


  Scribe: Bert

Line Grid

  <astearns> http://dev.w3.org/csswg/css-line-grid/#change-log

  astearns: Mainly I took things out.
  astearns: I think we should publish with these changes I just
            linked above.
  Several: No objection to publishing

  fantasai: What about the value names for navigation?
  astearns: I'm happy to discuss the names, but maybe not hold up
  fantasai: Yes, we renamed to start/end elsewhere. We should do
            something similar here.

  RESOLVED: publish WD of line-grid

  <fantasai> old draft:
  <fantasai> none of the values are in common except none

CSS UI: caret-color

  andreyr: We have been using webkit for the terminal.
  andreyr: We'd like to control the color of the caret.
  fantasai: There is interest in coloring the caret.
  fantasai: There should be something like 'cursor-color'.
  glazou: And what if you set color on a cursor defined as an image?
  dbaron: Caret and cursor are not the same
  andreyr: Yes, I mean the caret.
  andreyr: Orange is great.
  TabAtkins: 'caret-color' is fine.
  andreyr: We have a patch for chromium.

  hober: In the existing css3-UI thread,
  hober: Tantek has the notes for this in the planning page, but
         there hasn't been any edits to any documents
  hober: Lea raised something. Tantek has some notes for it in UI
         planning page.
  hober: So, where would this live?
  hober: Where would this go?
  fantasai: css3-ui (which is bit of a mess right now...)

  <Clilley> how is caret different to cursor: text?
  Clilley: How is the caret different from the text cursor?
  TabAtkins: The cursor is the I-beam.
  TabAtkins: The caret is the editable point in the text.
  fantasai: It's the one that blinks :-)

  hober: If you have text in several colors, caret should reflect
         that as it moves along the text.
  hober: 'invert' is suboptimal for that. Take the case with
  hober: I'm not enthusiastic about implementing 'invert'
  TabAtkins: 'invert' still fails on gray, anyway.
  hober: Yes, something with invert only after a threshold...
  hober: And the case of two authors, author of content and author
         of content-editable thing, one doesn't know the color of
         the other.

  RESOLVED: add 'caret-color' to css3-ui

CSS UI: styling selections

  andreyr: I'd also like to set foreground/background of selected
  glazou: We proposed ::selection for that.
  fantasai: We all want it, we had it at some point.

  <dbaron> http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html
  dbaron: I did half of the required analysis. Most engines have
          some sort of selection feature.
  dbaron: I listed five requirements and three solutions. But I
          didn't do enough testing.
  dbaron: I think that not all implementations meet the five
  dbaron: A useful next step would be to test what implementors do.

  fantasai: And andreyr wanted to propose equivalent selections for
            highlighted spelling errors.
  dbaron: Different DOM selections can maybe be associated with
          particular styles.
  TabAtkins: A style without the need to put in a SPAN.
  hober: A DOM range.

Scribe: fantasai
  glazou: Is this related to what we discussed earlier about
          selecting non-elements?
  fantasai: No, it's different,
  dbaron: This is an extension of ::selection, where you could
          associate a DOM range with a name, and select (in the same
          way as ::selection) based on that DOM range
  dbaron: Want to create it using ranges, then create styles for
  dbaron: The styling would work the same as ::selection, so it's a
          limited set of things.
  hober: I love this idea.
  glazou: Me too.

  TabAtkins: If we ever explicitly expose browser spell check, it
             could need to be restricted even further.
  TabAtkins: That's because of concerns with regard to exposing user
  dbaron: It would expose user's language and also user's dictionary.

  Andrey: The problem is that color of underline is hard-coded and
          we want to change that
  dbaron: Once we solve for ::selection, we will be most of the way
          through solving for multiple selection. Though there's a
          few more issues.
  hober: I imagined that I wrote an email for a similar thing, but I
         might not have actually written it...
  hober: It was a proposal for creating identified DOM ranges and
         syntax to select it
  * glazou loves it

  <dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=256773
  fantasai: Andrey's immediate problem is changing the color of
            squiggly underlines; can we do anything about that?
  <fantasai> ::spelling-error { text-decoration-color: orange; }
  fantasai: Would that be something that we can do?
  hober: You shouldn't be able to discover this style by checking.
  zcorpan: There's spelling errors, and also spelling suggestions.

  plinss: An extension mechanism should also be able to handle
          spelling and grammar check, etc.
  TabAtkins: Things that are security-sensitive need to be built in.
  TabAtkins: If they're using information not available to the page,
             you can't build into the page.
  TabAtkins: That's why I said spell check; if we want customization
             of it, it has to be built-in.
  hober: Or you build your own.

  dbaron: Gecko currently has 9 different types of internal
  <dbaron> (FWIW, Gecko has 9 different types of custom selection,
           listed at

  TabAtkins: Wasn't there talk of exposing find to the page?
  TabAtkins: Ignoring url secondary (we don't know what it is),
             doesn't seem like any others need to be security-
  fantasai: IME stuff might also expose user dictionaries.
  fantasai: Aren't there 2 finds? One you're on currently, and
            others on the page?

  glazou: Should we resolve to add ::selection back? Who's going to
          work on it?
  hober: Which spec should this be in?
  fantasai: Pseudo-elements Level 4
  fantasai: Should probably have L4 just be this and the L3 pseudos.
            Do fancy extra stuff in L5.
  dbaron: I'm happy for adding an issue to the spec.

  Rossen: Stuff is happening in WebApps for selection
  <Rossen> http://w3c.github.io/editing-explainer/
  hober: Editing Task Force.
  Rossen: Efforts in that direction are toward defining most of the
          things that we actually want, from what I'm hearing.
  Rossen: Not sure how much overlap there is.
  Rossen: Would be good to sync up with them.
  Rossen: Wouldn't expect us to define ::selection
  fantasai: We don't define what is selected, but define how the
            styling works.

  RESOLVED: Add ::selection to Pseudo-elements 4

  glazou: So who is working on this?
  glazou counts astearns, fantasai, andreyr

CSS UI: outline-radius

  <andreyr> https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-outline-radius
  andreyr: Mozilla has it implemented, no one else does.
  dbaron: We agreed at some point that we didn't want this property,
          just wanted outline to follow border-radius
  dbaron: The spec says that's what should happen.
  dbaron: We have a bug on dropping outline-radius and implementing
          what the spec says, but haven't gotten around to it.
  krit: The default implementation uses outline of the operating
  krit: It might not be able to allow border-radius.
  krit: So this would only be for styled outlines, e.g. said it
        should be solid red.
  krit: Focus-ring and outlines are basically the same thing.
  <fantasai> http://www.w3.org/TR/CSS21/ui.html#dynamic-outlines

  Rossen: We don't have such limitations in Windows, but I can't
          speak for others...
  fantasai: CSS3 UI doesn't say anything about border-radius.
  fantasai: So if we want that behavior, we need to add it to the
  fantasai: I agree that makes more sense.

  dbaron: Definitely we discussed this before. I brought up
          outline-radius, and people said it should just follow
  fantasai: So do implementors agree they want to do this?
  fantasai: Make inner outline radius match border-radius?
  Rossen: Trying to think if there's fragmented inlines, I'm unsure
          what should happen in that case... but I do want to match

  krit: Might need to account for
  krit: Outline-offset

  hober: I agree we should do this. If there's a problem, bring it up
  dbaron: If anyone does this for Gecko, we will have to go through
          our existing uses of outline-radius, and will find out if
          there's reasons for wanting something different.

  krit: Might possibly want rounded outline for square border-radius.
  hober: Maybe need some text with regard to default outline
         matching system conventions, which may or may not match
  fantasai: In cases where outline is just outside border, it should
            match the border.
  fantasai: For buttons, e.g., focus outline is around just the text
            sometimes, not the button shape, in that case could say
            whatever that thing is that is surrounded, it has a

  andreyr: Mozilla had it. I was hoping that others would implement.
  fantasai: Now you can just say that "your behavior is wrong,
            here's a patch"
  fantasai: Mozilla wants to drop outline-radius and just follow
  <dbaron> Is outline-radius expansion the same as box-shadow spread
  gregwhitworth: Do we have any author feedback on this?
  ACTION: glazou Ask authors for feedback on this
  <trackbot> Created ACTION-635

  RESOLVED: Outline corners follow border-radius (no additional
            outline-radius property needed)

  [lunch break]

Geometry Working Draft
Scribe: andreyr

  <krit> http://dev.w3.org/fxtf/geometry/

  krit: First up, geometry working draft
  krit: The main feedback was there shouldn't be interfaces which
        are described as magic
  krit: The feedback was to create constructors.
  krit: Read-only interfaces have constructors now.

  krit: Any objections?
  krit: Comments?
  dbaron: I worry it might be confusing where some properties are
          writable and some are not
  dbaron: Did the original proposal have these?
  krit: The spec has not really changed.

  krit: We would like to have a working draft.
  krit: It's intended to have constructor defined in the spec.

  RESOLVED: Publish working draft for geometry interfaces

Stacking context within SVG

  krit: We would like to have feedback making SVG elements embedded.
  <TabAtkins> :not(svg|*) > svg { stacking-context: new !important; }
  <zcorpan> :not(svg|*) > svg|svg { stacking-context: new
            !important; }

Scribe: fantasai
  [discussion of display property applied to SVG, problem with
     backwards compatibility due to people applying random other
     display values and it having no effect]

  Bert: z-index applies then, don't need to set position: absolute?
  TabAtkins: Correct.

  [Discussion is that SVG automatically creates stacking context.
     Also that SVG allows z-index without requiring position:

  [Clilley asks about foreignObject]
  * fantasai missed the answer
  Clilley: <foreignObject> should also create a stacking context,
           and shouldn't intermix with other SVG things

  RESOLVED: The root SVG element automatically creates a stacking
            context, as does <foreignObject>.

  RESOLVED: SVG elements honor z-index automatically (like flex
            items), without requiring 'position'

  Rossen: Grid automatically creates a stacking context for grid
  fantasai: I thought that was a pseudo-stacking context.
  fantasai: For SVG elements, it should be full stacking context.
            Think grid/flexbox is pseudo-stacking.
  <fantasai> http://dev.w3.org/csswg/css-flexbox/#painting

  Rossen: With regards to performance concerns of stacking context
          in SVG...
  Rossen: People might use that a lot. It might result in creating
          too many stacking contexts.
  krit: We have CSS properties that create a stacking context. Some
        of them, like transforms, are used very commonly in SVG.
  krit: So we resolved that properties like transform don't create
        stacking context unless 3D.
  Rossen: Should we do the same thing with z-index?
  Rossen: Then we're good.

Prioritizing image(color)

  krit: image() function
  krit: We had lots of discussion with regard to image() function,
        syntax thereof, responsive images, etc.
  TabAtkins: We have that already.
  fantasai: What's in Images 3 is a superset of that at the moment.
            We're going to strip it down.


  Tab leads discussion on selecting random values from a list.
  fantasai: Is that like cycle(), except non-deterministic?

  [Tab writes on the board]
  [We discover that the board doesn't erase.]
  [Tab finds another board]
  [Which also doesn't erase]
  [We find some paper, which doesn't erase, but there are multiple

  TabAtkins writes:
      @random foo
      red, blue
  TabAtkins: This is a random generator. It'll first try to exhaust
             its list. Then it'll generate from the generator.

  TabAtkins: If I write el { color: random(foo); }
  TabAtkins: Do I get a brand new color for every single element? Or
             a color that changes over time?
  TabAtkins: Need to specify when the randomness is applied.
  TabAtkins: Options we consider so far are per-element or per-rule.

  dauwhe: Why do we want to do this?
  hober: My use case is that I want to make a really ugly web page.
  krit: It's for abspos, want randomly-positioned items.
  Rossen: If the only use case is sprites, one line of JS is a good
          enough solution.
  TabAtkins: If we are going to do random, should be something like
             this, and need to be able to say when randomness is

  Rossen: What about interoperability testing?
  TabAtkins: Dunno, we might want to be able to specify seed.
  florian: Is this stable across page loads?

  fantasai: I think I'm with Rossen, this should be solved with JS
            for now.
  hober: It's already possible to make really ugly webpages, so my
         use case is already solved without this.
  plinss: Is this solve-able right now in JS?
  TabAtkins: Yes.
  TabAtkins: For per-element, alter .style of the elements; for
             per-rule, alter the rule in the style sheet.

  krit: So what's feedback?
  various: Need more use cases to justify something this complicated
           for something so simple to do in JS

  RESOLVED: Not pursuing randomness at this time.

  plinss: We will pursue it at some random future date.

Animation and calc() of Keywords

  * krit <shape-radius> closest-side/furthest-side and calc()
  krit: Got request for shape-radius to have half of farthest-side/
        closest-side keyword
  krit: Would like something like calc(farthest-side/2)
  krit: And would like to be able to animate that.

  astearns: Can we do keywords in calc()?
  TabAtkins: Not yet. But rejecting the white space change request
             at last F2F makes it easier to do.

  TabAtkins: These become lengths.
  fantasai: So does auto keyword for width.
  fantasai: But the lengths aren't the computed values.
  TabAtkins: Can't do a transition on it, but could you do a calc on
  fantasai, dbaron: If you can do a calc() on it, then you can do a
                    transition on it.

  fantasai: We know we want to do this. We've discussed it before.
            We deferred it from css3-values because it's complicated
  fantasai: Right now, you can implement calc() as a tuple of
            absolute length and percentage.
  fantasai: If you allow keywords, which have to be maintained as
            keywords, you need to store calc() as an expression.

  TabAtkins: So is the implementation work feasible? Because that is
             what is stopping us.
  krit: Expanding data structure should be straightforward
  dbaron: The data structure is the easy part.
  dbaron: You have to also modify other things to handle, e.g. all
          things that handle input of 'auto' to handle input of
          'auto' with calc()
  fantasai: Have to consider, e.g. for height of 'auto', have margin
            collapsing, but non-auto have no margin collapsing, what
            do you do with calc involving auto?
  TabAtkins: Might be hard for auto.

  plinss: Do we want a whitelist or blacklist?
  Rossen: Probably want a whitelist
  fantasai: Whitelist isn't per-keyword, it's per keyword-property
  fantasai: Going to have to modify propdef table again. Though I
            suspect animate-ability, computed value, and calc()-
            ability are closely related and could be compressed down.

  fantasai: So, what action do we give krit?
  TabAtkins: Make sure implementations are willing to do this.
  fantasai: And maybe come up with the whitelist.
  TabAtkins: I want to also see if we can come up with generalizable

  TabAtkins: Would Firefox be interested in doing this, if we
             whitelist some keywords?
  dbaron: Yes, just depends on prioritization.

  fantasai: There was also min()/max(), which had complications. Are
            those complications related?
  dbaron: No, it's different.
  dbaron: For example, if you have a div that has a 200px-wide image
          inside it, and has margin-left: 50%
  dbaron: The div's parent might, depending on other things, have an
          intrinsic width of 400px depending on other things
  dbaron: You say this div needs to be 50% + 200px wide, so the
          total has to be 400px.
  dbaron: That inversion of logic depends on being able to say that
          "this element has a length of 200px+50%".
  dbaron: Once you have a min or a max that has a length on one side
          and a percentage on the other.
  dbaron: Then you can't do that.
  dbaron: This happens most often in table layout, though there are
          a few other cases.
  dbaron: I think this was the issue that made me give up on min/max
  dbaron: The percentage and length thing, you can use a length and
          a percentage where, essentially, if you have something
          that is 50% plus 200px,
  dbaron: If you graph the percentage basis against the result.
  dbaron: This is some monotonic line.
  dbaron [draws graph of basis (x) time result (y) line goes from
         200px at zero upwards]
  dbaron: With min/max you can have any continuous and piecewise-
          linear line
  [draws a zigzag]
  dbaron: You might find more than one solution, or none.
  dbaron: Maybe we need to go back and define table layout and what
          you do here.
  dbaron: Or maybe not, just say we don't care...
  dbaron: I think that was the main issue with min/max
  <dbaron> http://lists.w3.org/Archives/Public/www-style/2011Oct/0735.html

  [quick look at css3-values to see if any other issues for
     discussion, no not really]

Received on Monday, 13 October 2014 20:40:25 UTC