- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 11 Mar 2015 20:30:54 -0400
- 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