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

[CSSWG] Minutes Sydney F2F 2015-02-09 Part II: Selectors, Text Level 4

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 11 Mar 2015 20:30:54 -0400
Message-ID: <CADhPm3uCrXetd5jMr_iS7=4A3oJR_DnhjT9kaw3Uopfdwng9Ug@mail.gmail.com>
To: www-style@w3.org
Selectors
---------

  - Florian brought back some documented need for a selector that
    propagates input states to the corresponding label.
      - RESOLVED: Florian to work on a proposal for a selector that
                  propagates input states to the corresponding label
                  and/or other associated elements.

  - TabAtkins brought back his previous idea of allowing :has() with
        some previous-child and -parent combinators in fast profile.
      - There were still a lot of concerns about the performance
            implications. dbaron will test to see what the effects
            would be so that a more informed decision can be made.

  - fantasai brought her proposal to add ::marker to pseudo-elements
        spec, takes properties from color module and fonts module (
        color, font-*, and opacity)
      - RESOLVED: Add ::marker with font properties and color to
                  pseudo-elements spec (and still plan to do more
                  later in the lists spec).

Text Level 4
------------

  - fantasai and astearns brought the CSS Text Level 4 document that
        they'd created to the group.
  - For their text-wrap: balance proposal, there was some concern
        about the inheritance behavior.  Instead, they will work on
        creating wrap-inside, wrap-before, and wrap-after properties.
  - The white-space properties were well received, though it was
         thought that discard would be a better word than consume.
  - RESOLVED: Make css-text-4 an editor's draft (currently a
              different spec)
  - RESOLVED: fantasai and astearns to edit

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

Selectors
=========

:for() Selector
---------------
  Scribe: dbaron

  glazou: First topic is :for() selector by Florian
  <glazou> https://lists.w3.org/Archives/Public/www-style/2014Dec/0064.html
  Florian: This spun out of earlier discussion on :focus-within.
  Florian: When writing form controls in HTML, can have labels
           associated with inputs, either by putting input inside
           label, or using for attribute and pointing to ID of form
           element.
  Florian: There's a bunch of states the form input can be in that
           you use for styling, e.g., invalid.
  Florian: There's demand from authors to also style label that goes
           with the form, based on these states (focus, active,
           disabled, invalid, etc.).
  Florian: The proposal is to have a functional pseudo-class that
           lets you point "label for this control :disabled"
  Florian: Then can style label.
  Florian: The last time it wasn't clear authors wanted it, went and
           found requests on stackoverflow for it.

  fantasai: Why can't we just propagate the state to the label?
  Florian: Because that is defined in HTML and Hixie's not
           interested.
  fantasai: That's a ridiculous reason.
  SimonSapin: I don't that's the best reason; another reason is that
              content today uses the pseudo-classes and expects it
              to apply only to the inputs and not the labels.
  fantasai, tantek: That's a much better reason.
  Florian: Also there's a small but worrying-to-some performance
           impact
  Florian: which makes only the people interested in using this bear
           this cost.
  Florian: You can potentially associate a thousand labels with a
           single form element.
  Florian: It's a corner case ...

  Tantek: Otherwise difficult to describe with existing selectors.
  Florian: People sometimes use hacks to put label after, use
           + selector, and then float to put label where they want
           it.
  Tantek: That corrupts the natural order of the markup, which we
          should seek to avoid.

  Tantek, glazou: I support this.
  dbaron: What is the syntax?
  dbaron: :for(<selector>)?
  florian: Could do that, or just put an ID.
  fantasai: Don't want an ID.
  fantasai: You want to style these things generically.
  Tantek: It doesn't have to be a label?
  Florian: :for() attribute only exists on labels.
  Tantek: It doesn't have to...
  plinss: We could define more generically
  Florian: The way :for() associates is up to the host language.
  fantasai: For HTML, it's the for attribute or containment.
  Florian: Yes, HTML does by nesting or attribute; other languages
           can do as they want.
  plinss: We should leave it defined by the host language.
  plinss: If it's not clear enough for HTML we should say what HTML
          does, but leave it defined by host language.

  gregwhitworth: IE already does this, and we've gotten no bugs
  Florian: In HTML spec, :active and :focus propagate from HTML to
           control. IE does that *and* the other way around.
  Florian: We previously resolved the IE way was good, I was
           actioned to go to Hixie, he disagreed.
  Florian: :hover and :active (not :focus?).
  Florian: I don't think IE does it for :invalid, :disabled, and all
           the others.

  glazou: I didn't get an answer to question: :for() pseudo that
          initially works only in HTML because knowledge of the for
          attribute comes from above and will not appear in the UA
          stylesheet or anywhere.
  glazou: Two ways to do that: more generic, or with for attribute
          mentioned.
  glazou: My opinion is for attribute mentioned is better because
          applies to more languages.
  glazou: I want to avoid the mess of the class selector where class
          was originally defined only for HTML and not other
          languages.
  Florian: Should be at least for attribute in HTML.
  fantasai: And containment.
  Florian: Could also extend in HTML where a form control is for its
           form.
  fantasai: Or fieldset.

  fantasai: My initial preference would be to propagate state out to
            fieldset, label, form.
  fantasai: If we can't do that because of web compat then I'd
            support other syntax.
  fantasai: I think :for() syntax is vague and confusing, but in
            favor of solving problem.
  glazou: Agreed.
  Florian: I don't think syntax is so ugly, but not married to it.
  glazou: :for() seems to me confusing, especially if it's generic
          enough that it could be an attribute other than for.
  Florian: If you don't think of attribute for, but just the English
           word, "the label for invalid things". 4

  SimonSapin: Why are we discussing extending this to fieldset and
              form as well?
  fantasai: You might want to style form / fieldset if any control
            is invalid.
  SimonSapin: The research was for labels, not fieldsets and forms,
  Florian: But styling form that contains something invalid is not
           science fiction.
  Tantek: Need for something to change somewhere else -- label is
          most obvious example. Focus in text input-- label most
          obvious, but might also have help text that shows up.
          Having that trigger without JS is helpful; can't do that
          right now.

  Tantek: My concern is that feature is too limited in scope to just
          handling HTML Label for.
  Tantek: Other use cases in forms: help text, hover causing
          information to show up elsewhere. I don't want to preclude
          those with a narrow definition.

  Florian: If we define it to work #1 for :for() attribute, #2 for
           nesting control in label, fieldset, and then leave room
           for future extensions maybe through @-rule.
  Tantek: Already have selector in :for()
  Florian: One part is state, other part is associating element.
  Florian: Current proposal relies on association being done already.
  Tantek: Don't need association; could just apply to all labels.
  fantasai, Florian: You need an association.
  Florian: Which label is for the form control?
  fantasai: Don't want to define the association between the label
            and the input in the CSS file, with separate rules for
            each instance of a form control.

  Florian: There are 2 levels, a mechanism for associating. We
           currently have a label<->control mechanism. Other is
           using existing associated to match states and propagate
           states along existing association. I'm only talking about
           the latter.
  Florian: That said, happy to use combinator instead of pseudo, etc.
           Just functionality I'm after.
  Florian: In previous life existing as /for/.
  Florian: I'm confused by what other word could go there.
  fantasai: That wasn't for any attribute; it was for any IDREF
            attribute.

  Tantek: Let's look at your real-world example.
  <tantek> Florian, the link from your email for TabAtkins's example
           is 404:
https://www.dropbox.com/s/cyu9je5a6cvolyf/Screenshot%202014-12-03%2023.51.47.png?dl=0
  <TabAtkins> http://www.xanthir.com/recipes/showrecipe.php?id=55
  Florian: In TabAtkins's site in the example, he has convoluted
           markup because he doesn't have this.
  TabAtkins: If you click on ingredients they get crossed out, done
             through CSS; had to do weird things.
  Tantek: Label around input isn't weird.
  TabAtkins: I forget what was weird.
  Florian: There was something wrong; maybe fixed since?

  (multiple conversations)

  Florian: I think we can put an action on this to construct a
           document that would benefit.
  TabAtkins: There are tons of examples on stackoverflow.
  TabAtkins: I don't think there's a need for more discovery.
  Tantek: I'm just looking for a sample simple document that would
          benefit.
  glazou: I'd rather see Florian spend time on the technical
          proposal and us on reviewing and getting feedback.
  <andreyr> +1 for technical proposal
  glazou: I almost see it as a blocking tactic.
  Tantek: It's not a blocking tactic. If we don't have a markup to
          look up then we don't know if it can be solved with
          existing selectors or others that are being proposed.
  Florian: Last time I proposed this, it stopped with request to go
           look up examples. I did.
  glazou: Tantek, let's try to find the best design without looking
          at the markup.
  Tantek: OK.

  fantasai: Resolution is we agree we should do something, not
            convinced about this particular proposal. Maybe come up
            with something easier to understand?
  glazou: Florian was looking for approval to continue working.
  glazou: I think discussion shows interest from WG. Doesn't say
          we'd eventually accept proposal.
  Tantek: I think can make stronger statement: best proposal we've
          seen so far. If a better alternative shows up we can
          debate that later.
  glazou: Any objection to Florian spending time spec'ing this?
  <tantek> +1 on more formal proposal

  fantasai: This would go in selectors level 5.
  fantasai: Level 4 needs to be trimmed down and pushed out.

  RESOLVED: Florian to work on :for() or whatever it is.

  zcorpan: For :active and :hover, we have 2 behaviors. We have IE
           going 2 ways and others going 1 way (with HTML spec).
  Florian: We previously resolved it should go 2 ways but failed to
           convince Hixie.
  zcorpan: Then the correct next spec is violating the HTML spec in
           other browsers and then getting the spec changed.
  Tantek: Other step is to propose a patch to HTML.
  Tantek: Could submit that to the HTML Working Group. I could help
          liaison that.
  Tantek: If there's consensus there...
  Florian: Does it help in the WHATWG to get HTMLWG to accept it?
  Tantek: Sometimes.
  Tantek: If browsers respond to that, Hixie will likely spec it.

previous-sibling and -parent combinators
----------------------------------------

  <glazou> Topic: Prev-sibling and parent combinators - allow :has()
           with some combinators in fast profile?
  glazou: Next, previous-sibling and parent combinators.

  TabAtkins: Say you have elements #foo and #bar.
  TabAtkins: Can already select #bar if it has #foo as previous
             sibling
  TabAtkins: with :has() combinator.
  TabAtkins: #foo ~ #bar
  TabAtkins: #foo:has(~#bar)
  TabAtkins: If we allow :has() can select #foo if bar as a
             following sibling, though only in fast profile.
  TabAtkins: Benjamin came up with a fun example, which is that you
             can write :nth-last-child(2 of #foo, #foo ~ bar), which
             is equivalent.
  TabAtkins: (explains how these are equivalent)
  TabAtkins: It's not quite a general previous-sibling combinator;
             we're back-dooring it in in the fast profile.

Scribe: fantasai

  dbaron: I'm skeptical about moving too quickly here.
  dbaron: You have one implementor that has done this.
  dbaron: The other thing I'm worried about is I would like the
          performance characteristics of selectors to be visible to
          authors when they're using them.
  dbaron: Some of them look scarier than others, and you want the
          slow things to look scarier than the fast things.

  TabAtkins: :has() with combinator is not available in CSS, only
             for querySelector.
  TabAtkins: But you can do the :nth-last-child( of ) today in CSS.
  dbaron: This is only :has() for siblings, not for descendants,
  dbaron: which is the more expensive case.
  TabAtkins: bzbarsky said looking for a parent shouldn't be too
             expensive.
  TabAtkins: Just going to the parent addresses the vast majority of
             cases.

  Florian: What is your proposal for this? Allow general syntax, or
           having special syntax?
  TabAtkins: Allowing special-cased things might also be okay.
  TabAtkins: e.g. :hasChild()

  dbaron: If I wanted to implement :has() for selector matching.
  dbaron: I'd probably want to rewrite it internally to look like
          the subject indicator.
  dbaron: Although I'm not sure.
  dbaron: I don't know if that has too many implications.
  dbaron: The subject indicator is more straightforward.
  dbaron: It doesn't allow branching.
  TabAtkins: Does in combination in :matches().
  dbaron: Lots of new stuff without much implementation experience...

  TabAtkins: People really want previous sibling and parent.
  TabAtkins: Arbitrary ancestor is kind of not great, but the other
             two are not too bad performance-wise.
  TabAtkins: I think we should allow them.
  TabAtkins: At least direct previous direct sibling.
  dbaron: Having some reasonable syntax that allows just parent and
          sibling doesn't seem too bad.
  TabAtkins: ... specialized syntax like :hasSibling :hasChild.
  fantasai: I don't like that, I think we should just say that you
            have to have a combinator at the beginning of :has().
  TabAtkins: It's got parsing issues, have to require white space.
  [discussion of syntax]
  astearns: The problem with :has is you have to explain which
            versions of :has() work in a stylesheet and which don't.

  Whiteboard says:
    #foo:has(~#bar)
    :nth-last-child(2 of #foo, #foo~bar)

  1) a:has(> foo) a:has(+foo)
  2) a:has-child(foo) a:has-next-sibling(foo)
  a:has(>foo>bar) vs a:has-child(foo:has-child(bar))

Scribe: dbaron

  Florian: ?
  fantasai: People will end up chaining to multiple levels of
            :has-child.
  Florian: We just discovered that this part of :has() is fast
           enough to be in the fast profile. If we've already
           allowed :has(), changing which subset sounds...
  TabAtkins: I doubt there's such subdivisiions. ??? ???
  TabAtkins: I don't know if we want to first poll to see if we want
             to allow this, which syntax we prefer.

  Florian: Do we have hope we'll one day we'll make :has() fast
           enough.
  fantasai: Totally possible, just have to do some fancy caching.
  dbaron: I disagree.

  Florian: If people write uses that don't work and depend that they
           don't work then we can't activate it anymore.
  fantasai: As long as you put a combinator in the front then you're
            in one of the safe cases.
  TabAtkins: No, you have to require all combinators on restricted
             list.

  SimonSapin: Do we allow more combinators inside the parentheses
              with (2)?
  TabAtkins: Maybe allow child combinators in :has-child() and
             sibling combinators in :has-sibling(),
  TabAtkins: or maybe just disallow nesting of :has-pseudoclasses().
  TabAtkins: Dunno if looking arbitrarily far distance into
             ancestors with terrible selectors is something we want
             to allow.

  Florian: For future-compat I'm not in favor of option (1).
  fantasai: Selectors are aggressive about being invalid; throws out
            entire rule...
  fantasai: You'd notice.
  Florian: I wouldn't count on that; definitely wouldn't want to
           make that rule start matching later.

  TabAtkins: Are there objections to concept still?
  dbaron: I want to think about it more
  dbaron: There's a lot of stuff with a lot of interesting
          performance implications in selectors currently, not much
          use/testing/impl yet.
  dbaron: I'm not okay with it yet, I might after thinking about it
          some more.

  fantasai: I also think you should get some authors to look into
            this.
  fantasai: The syntax proposed looks horrible.

  TabAtkins: Should dbaron and bzbarsky review for performance
             characteristics?
  TabAtkins: We discussed them before, but wasn't seriously
             proposing it before; now I'm seriously proposing it.

  ACTION dbaron review performance characteristics of parent and
         previous-sibling combinator, potentially combinable
  <trackbot> Created ACTION-668

::marker
--------

  glazou: Next item on agenda is ::marker
  fantasai: This has been in lists spec for a while. Don't have
            concrete lists spec. A lot of issues on positioning; not
            well nailed down.
  fantasai: The main use cases for ::marker are changing color and
            font.
  fantasai: I think those are reasonable without entire Lists spec,
            could define in pseudo-elements spec with just colors
            and fonts.
  fantasai: My proposal is add ::marker to pseudo-elements spec,
            takes properties from color module and fonts module (
            color, font-*, and opacity).
  roc: Why opacity?
  fantasai: Ok, can just do rgba().
  fantasai: Color property and font properties.

  Tantek: Offsets? People want marker closer, etc.
  fantasai: We just want to postpone that.
  fantasai: Involves speccing the layout details.

  RESOLVED: Add ::marker with font properties and color to
            pseudo-elements spec (and still plan to do more later in
            the lists spec).

  dbaron: We want to defer transitions, fx day is fine.

Text Level 4
============

text-wrap: balance
------------------

  <fantasai> http://dev.w3.org/csswg/css-text-4/
  <astearns> http://dev.w3.org/csswg/css-text-4/#text-wrap
  fantasai: astearns and I drafted a placeholder for text level 4.
            We pasted in stuff that was pulled out of level 3.
  fantasai: These are all pretty fuzzy.

  fantasai: The stuff that's in there is basically splitting
            whitespace into 2 separate properties: text-space-
            collapse and text-wrap.
  fantasai: and adding a new text-space-trim property.
  fantasai: Features that were deferred are ability to discard
            whitespace and ability to trim whitespace just inside
            element, or just before/after element (needed for
            footnote formatting).
  fantasai: A couple issues on last line length that were requested
  fantasai: extra hyphenation controls:
            (hyphenate-limit-{zone,chars,lines,last})
  fantasai: String justification for tables deferred from level 3.
  fantasai: text-spacing property that deals with East Asian stuff
            not fully worked out yet.
  fantasai: and text-wrap property has 2 new values.
  fantasai: One of them proposed is text-wrap: avoid value, which
            says please don't break me, but if I don't fit on the
            line, then break,
  fantasai: allows more controlled breaking with phrase-sensitivity.

  Florian: example using it on an Address
  (rapid conversation)
  fantasai: More control than just <wbr> inside of nowrap; here you
            can use nesting to provide prioritization.
  fantasai: Was in level 3, were some issues, maybe w.r.t.
            inheritance,
  fantasai: so needs to be pulled into separate property.
  fantasai: Then there's the text-wrap: balance property, which only
            works on blocks with direct line box descendants
  fantasai: and inherits.
  astearns: The whole spec is a different spec.

  fantasai: There's stuff here that definitely needs work. Feedback:
            what to do with it? Suggestions on directions?
  Florian: For balance specifically, had comments, but spec now took
           feedback.
  Florian: I haven't reviewed rest.
  Florian: This should slowly be worked on.
  astearns: Of all the things in the spec at the moment,
            text-wrap: avoid and balance are the ones developers are
            calling for most strongly.

  fantasai: A related issue is dealing with break-inside/break-after.
  astearns: One issue with text-wrap: avoid is whether it should be
            tied in with break-avoid properties which have a few
            more settings that you can use.
  astearns: My take is that block breaking and inline breaking
            should be separately controllable things, because inline
            breaking almost always has to do with text-wrap, it's
            not a great thing to graft the same block-avoid/break
            properties onto inline wrapping.
  astearns: If anyone has contrary idea, we should discuss.

  fantasai writes:
           text-wrap: avoid          [ inheritance BAD]
           vs.
           break-inside: avoid       [ traditionally for block axis ]
           vs.
           new property

  fantasai: I think we can't use text-wrap: avoid because text-wrap
            inherits.
  fantasai: So I think it has to be break-inside: avoid or a new
            property.
  fantasai: astearns, you're suggesting don't want
            break-inside: avoid.
  fantasai: So we need a new property; don't know the name.
            wrap-inside?
  astearns: I'm not sure text-wrap: avoid inheriting is a terrible
            thing.
  fantasai: text-wrap: avoid inheriting means that with
            <span> ... <em>Yo!</em> ... </span>, means that breaks
            not inside the em will be preferred over breaks inside
            the em.
  astearns: The example you added relies on inheriting, so in some
            cases it's good.
  johanneswilm: So avoid doesn't actually mean avoid, it means ...
  fantasai: It means avoid, not forbidden.
  fantasai: We have forbidden, it's called nowrap.

  dbaron: My understanding is you want something where nested avoids
          increase the priority,
  dbaron: and you can't do that with inheritance.
  fantasai: You do want nesting to increase the priority.
  TabAtkins: I can see math structures wanting to do that.
  dauwhe: Would you need to set explicit priorities on various
          things?
  TabAtkins: You just wrap extra wrappers.

  johanneswilm: Couldn't you have numbers on it?
  fantasai: Then you have the z-index problem with really big numbers
  fantasai: and most cases with this sort of wrapping, there's a
            hierarchical structure, where using avoid takes care of
            it for you.
  fantasai: We might need priorities in addition to nesting, but
            nesting takes care of most cases.
  johanneswilm: So if I have a span and would prefer no breaks
                inside of it, but inside the em, I'd prefer the
                break inside the em, how would I express that?
  TabAtkins: You could put avoid on spans that are siblings of the
             em.
  fantasai: Inheritance makes it convenient, says every additional
            element increases avoidance.
  fantasai: In simple cases like a headline, don't have any extra
            markup.
  fantasai: If you have a footer on a slideshow: date, location,
            talk title: each individually should stay together, but
            links inside that shouldn't increase avoidance.
  astearns: There's definitely cases where it's convenient to
            inherit, but not much where it would be wrong.
  fantasai: Because most markup corresponds to things that mean
            things.

  SteveZ: (something about a URL)
  SteveZ: But in that case can also label the URLs as
          text-wrap: normal.

  fantasai: So should either be text-wrap: avoid or a separate
            property?
  SteveZ: Turning it the other way around, why do I need the other
          property?
  fantasai: It's easier to turn on inheritance than it is to turn it
            off.
  dbaron: Weird to inherit.
  dbaron: Model we have is that adding inlines or blocks with no
          styling is essentially a no-op.
  dbaron: This breaks that model.
  astearns: We haven't specified that it increases.
  dbaron: Yeah, if there's only one level of avoidance it's not a
          problem.

  johanneswilm: Say I have a book title with subtitle. I'd prefer
                whole thing not to be broken, but if it needs to be
                broken, I'd prefer break between title and subtitle.
                How would I do that?
  fantasai: Mark up title and subtitle in separate spans
  fantasai: and a span around both.
  astearns: So should specify priority increases
  astearns: and then question of whether that requires
            text-wrap: avoid at the top, or in 3 places.

  fantasai: I think dbaron's point is important, and requires a
            separate property.
  astearns: text-wrap is a new property -- why can't it just not
            inherit?
  fantasai: Wrap value and nowrap value must inherit.
  fantasai: Or we could just stick with white-space, and have
            text-wrap only controlling avoidance behavior.

  Florian: {asks question}
  fantasai: text-wrap is a longhand of shorthand white-space
  fantasai: and 'text-wrap: none' value should have been 'nowrap'.
  <astearns> http://dev.w3.org/csswg/css-text-4/#white-space-property

  astearns: There's hand waving about the shorthand in the intro
            section; I'd be happy not making shorthand.
  fantasai: You don't want to define one property that always
            overrides another.
  SteveZ: dbaron's principle requires that nowrap inherit and
          requires that avoid not inherit
  fantasai: I think we need a separate property for avoid.

  SteveZ: Part of problem is that we can't use avoid-break in -- two
          breaks that could avoid, blocks or lines, and don't know
          which is intended.
  SteveZ: With the fragmenting spec, we've been trying to get
          generic terminology that applies, and here that doesn't
          quite work.
  SteveZ: I wonder if there are other places where there are
          multiple possible fragmentations at the same time.
  fantasai: Yes, flexbox has lines.
  fantasai: We could use same properties for flex lines as for text.
  SteveZ: Introduce a new property that had more than one use?
  fantasai: wrap-inside wrap-before wrap-after?
  dauwhe: That sounds almost useful to me.
  fantasai: Works for me.
  astearns: Should we try fleshing it out?
  fantasai: We'll take an action to update spec

  ACTION fantasai and astearns to try fleshing out spec for
         wrap-inside wrap-before wrap-after in css-text-4
  <trackbot> Created ACTION-669

white-space
-----------

  fantasai: white-space: normal | nowrap | pre | pre-line
  fantasai:  |- text-wrap: nowrap | normal | balance
  fantasai:  |- text-space-collapse: collapse | discard | preserve |
preserve-breaks
  fantasai: text-space-trim: none | trim-inner || consume-after ||
consume-before

  fantasai: white-space controls two different things: collapsing
            and whether text is allowed to wrap.
  fantasai: We split this into 2 different properties.
  fantasai: Discard is a new value, throws out all whitespace
  fantasai: Preserve is pre, preserve-breaks is pre-line.
  fantasai: The 2 new sub-properties inherit since white-space
            inherits.

  fantasai: text-space-trim needs to not inherit, so pulled into
            separate property.
  fantasai: trim-inner gets rid of space that's just inside the
            beginning and end of the element.
  fantasai: consume-before ... pulling a footnote out, don't want to
            format source code so markup is right up against last
            letter, but want the footnote marker to have no space
            before it.
  fantasai: Or if you format it with parentheses, you want the space
            before the opening parenthesis.

  fantasai: That's the set of whitespace stuff pulled in from old
            level 3 ideas. What do you all think?

  Rossen: Where is word-break in this?
  fantasai: line-break and word-break control where line breaking
            opportunities are in the text.
  fantasai: This controls whether or not you're wrapping.

  heycam: Consume and discard seem to be similar things, so maybe
          should use the same names?
  fantasai: discard-after and discard-before?

  heycam: In SVG, we're making SVG text be defined in terms of CSS
          text layout.
  heycam: One of the weirdo things about SVG text is that if you use
          the old mechanism to say pre-formatted text, with
          xml:space=preserve, it preserves all the spaces within
          lines but discards newlines.
  heycam: So we have a special value in Gecko that's like pre, but
          discards newlines.
  fantasai: text-space-collapse: discard-breaks -- implies you
            preserve the other things.
  SteveZ: If that, then poetry one should be
          discard-extra-whitespace
  fantasai: I think it's clear enough...
  SteveZ: ???
  heycam: You could have separate values for breaks and the inline
          things.
  fantasai: It feels unnecessary.
  SteveZ: Suggestions: either preserve-non-breaks parallel to
          preserve ...
  fantasai: Do you discard the breaks or collapse them?
  heycam: They get discarded.
  johanneswilm: (something about whitespace at start and end of line)
  heycam: Let me just confirm that it doesn't convert the newline
          into a single space.

  fantasai: Any other comments?
  fantasai: OK, go with this, then.
  fantasai: Thoughts on turning this into an editor's draft when we
            have this in?
  various: yes
  <tantek> definitely editor's draft

  <fantasai> Edits to do
  <fantasai> 1. consume-before/after -> discard-before/after
  <fantasai> 2. add discard-breaks (or collapse-breaks, as
                appropriate) for SVG
  <fantasai> 3. spec wrap-before/after/inside
  <fantasai> (and remove 'avoid')

  heycam: Actually it looks like implementations turn newlines into
          spaces, and not collapse consecutive ones, except in IE
  heycam: Maybe IE doesn't implement xml:space=preserve
  fantasai: So we need a new name, say spacify-breaks for now.
  <tantek> how about 'breaks-to-spaces'

  RESOLVED: Make css-text-4 an editor's draft (currently a diff spec)
  RESOLVED: fantasai and astearns to edit

  <glazou> http://glazman.org/tmp/IMG_0153.JPG (Image of Whiteboard)

  <fantasai> astearns: I don't think breaking flex items across
             flex-lines makes sense
  <fantasai> astearns: I think flex just needs wrap-before+
             wrap-after, not wrap-inside
  <astearns> fantasai: right - I was thinking of a range of flex
             items not getting a wrap, but that doesn't quite work
Received on Thursday, 12 March 2015 00:31:25 UTC

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