W3C home > Mailing lists > Public > www-style@w3.org > March 2015

[CSSWG] Minutes Sydney F2F 2015-02-11 Part IV: ID-less Referencing, Referencing Properties, Text in a Shape, Flexbox, ::selection

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 20 Mar 2015 02:43:28 -0400
Message-ID: <CADhPm3trNVp=+6tGpSJe0=a1LLh61YQwB-dHi4F=jZx+i+vKyw@mail.gmail.com>
To: www-style@w3.org
ID-less Referencing
-------------------

  - RESOLVED: Accept the 'child' keyword in all referencing
              properties.

Referencing Properties
----------------------

  - The group discussed what level properties need to be at to be
      referenced in SVG 2
  - RESOLVED: CSS WG agrees to publish Shapes 2 as a FPWD

Text In A Shape
---------------

  - Tav requested that he'd like to retain a property that allows
      you to wrap into a shape.
  - There was discussion on if that's still possible. Regions was
      one option, but it was complex for the use-case. Floats and
      exclusions seemed to offer the correct behavior, though having
      a child keyword for positioning was also a possibility.

Flexbox
-------

  - RESOLVED: Publish flexbox CR under the new process

::selection
-----------

  - RESOLVED: add ::inactive-selection to Pseudo Element Level 4

===== FULL MINUTES BELOW ======

  Scribe: Cyril

ID-less Referencing
-------------------

  <birtles> http://people.mozilla.org/~bbirtles/pres/referencing-proposal-2015/
  birtles: Quick proposal about referencing elements from CSS
           properties without using ID.
  birtles: The motivation is masking for example.
  birtles: You want to point to another element
  birtles: but mash-ups can have conflicts.
  birtles: Unique IDs is a solution but that's a bit too much:
  birtles: readability, file size,
  birtles: and a pain to generate from JS.
  birtles: Semantically not great.

  birtles: It'd be better if we could nest mask in path.
  ChrisLilley: The downside is you can only have one child in some
               cases.
  birtles: We could try nesting,
  birtles: but that's not good for backward compatibility.

  birtles: I proposed a keyword:
  birtles: 'child' to say the first descendant.
  birtles: If you have multiple masks, child would mean the last one.
  birtles: It would work for paint servers.
  birtles: The one issue is both fill and stroke refer to the
           children.
  birtles: The proposal is to use a select syntax.
  Tav: You could also need a list: gradient and pattern as a fill.

  birtles: The proposal is to use selectors scoped to the subtree.
  birtles: That was removed from CSS masking to find a more generic
           solution.
  ChrisLilley: I don't see how it could be more generic than
               selector.
  ChrisLilley: The only constraint is the fact that it selects
               amongst the children.
  heycam: Using selectors you could have things depending on
          attribute values, structure of the tree
  heycam: making it difficult to watch mutations in the tree.
  heycam: If the selector would be limited to children or element
          names
  heycam: it'd make it easier to track.

  fantasai: We have an outstanding issue in GCPM
  fantasai: that the element function in GCPM and CSS 4 don't agree.
  fantasai: Changing syntax is on the table.
  birtles: element() with an ID doesn't help.

  heycam: Concerns are different with navigation
  heycam: where you don't watch for changes.
  ChrisLilley: Previously it was not enough generic, now it is too
               generic.

  cyril: Why don't we restrict selectors to nth-child?
  TabAtkins: We could add full selectors in the future.
  ChrisLilley: I would rather use selectors and constrain it.
  TabAtkins: select(nth-child(2)) is longer than child(2).
  TabAtkins: What if you want the 2nd linearGradient here and not
             the 2nd child?
  birtles: If you allow element name and child
  birtles: we could disambiguate by giving the element name.
  TabAtkins: I don't like remembering what arbitrary things I'm
             allowed to use.
  heycam: I don't see use cases for selecting things other than
          children.
  heycam: I don't like to write mask="select(mask)".
  heycam: The GCPM function takes a custom identifier.

  krit: Do we care if we have a different solution for both?
  ed: We could restrict the order in which you put children elements
      for fill and stroke.
  krit: You can have fill with multiple layers.
  TabAtkins: the child keyword does not allow that.
  krit: That's why it's not useful.
  TabAtkins: Is that a huge deal if we restrict selectors to
             matching children?
  heycam: You'd still have to watch for class changes...
  heycam: it's unlikely I'd be able to reuse the existing machinery
          for style changes.
  heycam: I'd like to see if Erik's model could work,
  heycam: it needs more thoughts.

  ed: Do we expect that it will be common for people to use multiple
      fill and strokes?
  TabAtkins: We could solve the common case now (1 child per paint
             server) and expand later.
  TabAtkins: fill="child child child" could be use the 3 first
             children to use for fill.
  heycam: We could use that for markers
  heycam: but markers have zillions of properties.
  TabAtkins: I don't think we want to use paint order.
  TabAtkins: The mental model isn't as intuitive.

  RESOLVED: Accept the 'child' keyword in all referencing properties.

  krit: Do we define in it in the common spec?
  heycam: Yes, in the SVG 2 spec.
  ed: The order is we consume children for fill first and then for
      stroke.
  cyril: What if the same paint server is used for fill and stroke?
  TabAtkins: You have to repeat it.
  Tav: Or give an ID.

Referencing Properties
----------------------

  <Tav> http://tavmjong.free.fr/SVG/PROPERTIES/index.html
  Tav: I've been working on the text part of SVG
  Tav: and one of the problems is that it references so many
       properties.
  Tav: The modules are in various stages of preparation.
  Tav: What do we allow to reference?
  Tav: For example writing modes redefines writing-mode a little bit
       differently.
  fantasai: text-decoration-fill would go in Level 4 of Text
            Decoration.
  krit: So you could put it in SVG.

  Tav: Are we allowed to reference a WD?
  ChrisLilley: Yes, but you can't go past CR.
  Tav: Shapes 2 is needed but it's in ED.
  astearns: But it's ready to be in WD.
  heycam: What's new?
  astearns: shape-margin, shape-inside, referencing SVG shapes ...
  ed: Can we have a resolution to publish WD?
  fantasai: We probably have quorum for publishing.
  fantasai: Adobe is ok with publishing, Google is.
  dbaron: That seems fine.
  dino: I'm ok.

  RESOLVED: CSS WG agrees to publish Shapes 2 as a FPWD

  tav: I'm happy to have a agreement that I can reference those
       specs.

  fantasai: About baseline-shift
  fantasai: Do you output it in the CSS form or SVG form?
  Tav: In the CSS form.
  heycam: I have a separate topic on that.

  Tav: How soon can it be done?
  fantasai: I can get you a very rough draft today.
  <fantasai> Plan is to have a dominant-baseline property
  <fantasai> and then a vertical-align property with longhands
             alignment-baseline and baseline-shift
  Tav: We need to do that in the SVG 2.

  heycam: You have a future model in mind, reducing the number of
          properties by half, simplifying the model.
  heycam: In Firefox we implement only dominant-baseline.
  heycam: People have content that uses it to position text.
  heycam: Webkit supports alignment-baseline, dominant-baseline and
          baseline-shift.

  heycam: The effect if you specify alignment-baseline and
          dominant-baseline is unclear.
  fantasai: The initial value of alignment-baseline should be auto
            and auto should look at the dominant-baseline property
            of the parent.
  dbaron: Not alignment-baseline?
  heycam: baseline-shift has length + keywords: superscript ...
  heycam: My overriding concern is to make sure we just have what
          SVG needs without constraining your model.
  heycam: If you're happy to write a minimal document that we can
          reference then we're fine.
  fantasai: I can have a document in a year.
  heycam: Ok.
  heycam: That has 4 properties instead of 3.
  heycam: The XSL properties were used at some point in the SVG spec
          and then tweaked.
  fantasai: What is in the SVG spec is what I might put in the CSS
            spec.
  <dbaron> There are some useful definitions in
           http://www.w3.org/TR/xsl/#vertical-align and
           http://www.w3.org/TR/xsl/#area-alignment
  [discussing new process]
  <liam> [The XSL-FO properties were in turn supposed to be aligned
         with CSS 2 where possible, modulo the evolving box model.
         http://www.w3.org/TR/xslfo20/#vertical-align was the most
         recent/final draft before we stopped working on it, but I
         think it unchanged from 1.1 ]

  heycam: The other part is what to do about the old writing-mode
          values and glyph orientation vertical stuff.
  heycam: fantasai seems to be of the opinion that there are
          interesting things even if not in the open web.
  heycam: krit showed some output of Photoshop for vertical text
          using writing mode TB.
  <heycam> In SVG there are old keyword values for writing-mode, and
           an old glyph-orientation-vertical property that lets you
           control how Latin glyphs are oriented in vertical text.
  <heycam> In writing modes spec, there are new keywords for
           writing-mode, and a text-orientation property for
           controlling glyph orientation.
  krit: Glyph orientation horizontal and vertical have the same
        usage statistics.
  krit: I would suggest we deprecate them but not remove them.
  heycam: I haven't seen bug reports about them, but I have about
          alignment-baseline.
  ChrisLilley: Some people said that most fonts don't give that
               information.
  heycam: I have enough information about the plan for those
          properties.

text-orientation keywords
-------------------------

  Chrisl pokes fantasai to explain random side comment to everyone
  fantasai: On previous topic, I was just commenting that I should
            have named sideways-left and sideways-right as
            sideways-lr and sideways-rl, but it's probably too late
            to change that.

  fantasai: writing-mode has values that are horizontal-tb and
            vertical-lr and text-orientation: sideways-left,
            sideways-right
  fantasai: text-orientation could change from sideways-left and
            sideways-right... could change to sideways-lr and
            sideways-rl
  heycam: Why not sideways-tb etc.?
  fantasai: text-orientation talks about orientation of glyphs --
            where is top/bottom of line -- not where is start/end of
            line.
  fantasai: The correct text-orientation:sideways-* for horizontal
            scripts is the one that matches the writing-mode:
            vertical-*
  heycam: Question.
  fantasai: [diagram that's hard to minute because it's in vertical
            writing]
  fantasai: Might be deployed content in Japan that relies on these
            things, is why we probably can't change.

Text In A Shape
---------------

  <Tav> http://tavmjong.free.fr/SVG/TEXT_FLOWED/index.html
  Tav: SVG 2 reintroduces text flow in a shape,
  Tav: The initial version 1.2 got supported only by Batik and
       Inkscape.

  <liam> [ Tav -- http://www.w3.org/TR/xslfo20/#fo_extension-region
         and scroll up to figure 50 with the yellow hexagons ]

  Tav: Back to the text in shape topic.
  Tav: In SVG1.2Tiny you could wrap into one box and another and
       another.
  Tav: Could we retain that property?
  astearns: We've proposed several ways.
  astearns: Florian also proposed another method.
  Tav: I looked at regions and it seemed complicated for that.
  astearns: Overflow fragments have to be siblings
  astearns: not regions.
  astearns: I don't now what your requirements are.
  Tav: 3 references comma separated.
  heycam: In the old way, you had SVG shapes in the document, child
          of some special flow document
  heycam: and the text flows in then one by one, no automatic
          generation of shape.
  heycam: Do you want that behavior?
  Tav: No, I don't want automatic generation of shapes.
  astearns: And if it overflows ?
  Tav: It goes nowhere.
  Rossen: You need regions then.
  astearns: The concepts are in the regions spec.
  Tav: A simple comma separated list of shapes would not work?
  astearns: We did not want to add that syntax in shape-inside
  astearns: that would need to be something for SVG to define.
  heycam: That goes on the text element.
  astearns: I don't know if it needs to extend shape-inside or have
            a new shape-inside-list.
  * ed <text shape-inside="child">foobar<path .../></text>?

  Tav: In SVG there would be two ways to get the content region:
       width for horizontal text and height for vertical text or by
       giving the shape in which it will wrap.
  Tav: I wanted to check the syntax.
  Rossen: The behavior in SVG 2 seems to combine 2 or 3 specs.
  Tav: The text doesn't flow in the 2 rectangles.
  Rossen: So you don't need regions
  Rossen: but you need exclusion.
  Tav: Two separate text elements both shape-inside (different) but
       one has a shape-outside.
  <heycam> [this is pointing to the "An example of using
           'shape-outside'" example currently in the spec]
  astearns: shape-outside only apply to floats.
  Rossen: Or exclusions.
  astearns: You'd need wrap flow too.
  astearns: In CSS to get wrapping behavior you need floats or
            exclusions.
  astearns: It's adding one more property.
  astearns: It adds the ability to have the content overlapping or
            wrapping.
  Tav: I'm wondering if SVG needs that level of complexity.
  Rossen: But you are positioning with x and y.
  astearns: I think you need it.

  ed: Have you considered having a child keyword for this as well to
      keep the shape inside the text?
  Tav: possible.
  <heycam> <text shape-inside="child">ABC DEF <circle .../></text>
  ed: I don't think a rectangle (or shape) is rendered currently in
      a text.
  Tav: And also having a text inside a rectangle.
  heycam: You think the syntax is more natural to have the text
          inside the rectangle?
  Tav: Yes.

  <AndreyR> Another topic from CSS agenda can we discuss issues?
            http://dev.w3.org/CSSwg/CSS-pseudo/#highlight-pseudos

Flexbox
-------

  fantasai: Can we go to CR ?
  Florian: What do we do about the order issue?
  fantasai: So far there are several proposals:
             a) don't change anything
             b) make order affect all things and extend later
                with longhands that affect one thing or another
             c) and drop the order property
  Florian: I'm not excited about opening new things
  Florian: but the shorthand longhand thing made sense to me.
  fantasai: We don't have the person to discuss this
  fantasai: but I would like to publish things, because we're out of
            date.
  Florian: I'm happy with publishing.

  Rossen: Any objection?
  [silence]
  dbaron: Are there any big things that don't match what it used to
          do?
  fantasai: No.
  dbaron: Sounds good then.

  RESOLVED: Publish flexbox CR under the new process

::selection
-----------

  <AndreyR> http://dev.w3.org/CSSwg/CSS-pseudo/#highlight-pseudos
  fantasai: There is an issue in the spec on how to select inactive
            selections.
  fantasai: Do we want to add another pseudo for that?
  fantasai: I don't think that's a good idea.
  Florian: Inactive selection?
  fantasai: Select and then focus another window.
  Florian: That does not match selection, but nothing selects it.

  RESOLVED: add ::inactive-selection to Pseudo Element Level 4

-- meeting adjourned --
Received on Friday, 20 March 2015 06:43:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:30 UTC