- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 26 May 2015 19:19:02 -0400
- To: www-style@w3.org
Pre-Wrap and White Space Processing
-----------------------------------
- RESOLVED: pre-wrap preserves all spaces visibly and allows
wrapping before and after every space.
(Goes into level 3 and marked as at-risk.)
- RESOLVED: Add pre-wrap-auto* which does system-dependent
behavior for multi-line text fields
(Goes into level 3 and marked as at-risk)
* to be bikeshedded; better naming suggestions welcome
- RESOLVED: Add pre-wrap-trim to level 4
CSS 2.2
-------
- RESOLVED: FPWD of CSS2.2
- RESOLVED: Republish CSS2.1 with more angry red boxes
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/new-york-2015#agenda
Scribe: shane
Pre-Wrap and White Space Processing
-----------------------------------
<smfr> http://florian.rivoal.net/csswg/wrap/wrap.html
Florian: white-space:pre-wrap interoperability.
Florian: Runs of spaces are preserved interoperably except at the
end of the line.
Florian: Firefox does the specified base behavior.
Florian: nbsps are part of the word before.
Florian: The spec also says you can visually collapse these spaces,
which is what Chrome does.
Florian: IE doesn't match the spec - doesn't wrap, but preserves
the spaces (which then overflow the box).
Florian: Switching word-wrap to break-word changes things. For
Firefox, moves spaces down to the next line. Not for
Chrome or IE.
Florian: Possibly that's due to ambiguity in spec which doesn't
define what a word is.
fantasai: The spec says you can break between any two letters.
<fantasai> Nevermind, I'm thinking of word-break, not word-wrap.
Florian: IE has different interpretations depending on whether in
a regular element or a text area.
Florian: In a text area it behaves like Firefox.
Rossen: Editable or not makes a difference
Florian: Another one - word-break: break-all. Firefox will break
between anything (letters or nbsps). That's not what spec
says (spec says letters only).
Florian: Chrome and IE break in words but not in spaces, like the
spec says.
Florian: Finally, combining both. In IE on text areas it does
something ... weird.
Florian: Go to http://florian.rivoal.net/csswg/wrap to see.
Florian: Things get more interesting if you text-align:right
instead of text-align:left.
Florian: It's consistent with what's happening before, but the
fact that Firefox doesn't collapse spaces amplifies the
differences.
Florian: The same is true of centering or justifying.
Florian: Point is: there's no interop at end-of-line with a bunch
of spaces in pre-wrap.
Florian: Do we agree that there's something that needs to be fixed?
Florian: Going back to align: left. Even though Firefox is
compliant, I don't think the result is very nice.
Florian: Chrome and IE have more reasonable behavior in the simple
case.
Florian: In the Chrome view, though, if you want to apply
word-wrap: break-word then you never get spaces wrapping
on the next line.
Florian: I think this is nice - you're asking for space to be
preserved and things to be wrapped, so the spaces should
be wrapped.
Florian: So I think we should choose Chrome or IE behavior for
base case, and either preserve the spaces (IE case) or
reinsert them (Chrome case) when wrapping.
Florian: One issue is that word-break: break-all and word-wrap:
break-word would then start to behave the same for spaces.
Florian: My proposal: add break-spaces to word-wrap (which is now
overflow-wrap, btw) to support the case previously
word-break: break-all.
fantasai: I think we want to have another value for white space
which allows breaking in runs of spaces, and makes those
spaces kind of visible.
fantasai: Another issue, should we underlining the trailing spaces?
Florian: In the base case, we probably don't care about the spaces
so everything should get pushed right.
Florian: Only if you really really ask for the spaces to be
preserved.
Florian: The difference between kinda preserve the spaces
sometimes and, no, really, preserve them.
SteveZ: Why are the ones on the left important but not the ones on
the right?
SteveZ: Left with left-align are preserved. Why not right with
right-align?
Florian: If you do want the spaces on the right edge to be taken
into account you do pre-wrap. If not you do pre-line.
fantasai: pre-line will also collapse the spaces within the line.
fantasai: It seems like people might want to do special things at
beginning/end only.
Florian: (1) Is there a problem? (2) Can we agree on the base
case? (3) Which additional switches are important?
Florian: I think we should at least be interoperable in the base
case.
Florian: It will also cause problems in content-editable. Pressing
space in Chrome won't do anything but in IE it will
advance the cursor to the right.
Rossen: That's why we did it. Similar to Word behavior.
Florian: So IE probably has the best behavior but isn't spec
compliant.
Florian: We should fix it.
johanneswilm: What's the relation between that and the white-space
property?
Florian: In all of these cases, white-space is pre-wrap. So spaces
are preserved.
[debate over which behavior is best in each case]
Florian: And what about the other alignments? Same behaviors?
johanneswilm: With the poetry example, wouldn't you just set the
white-space to something else?
Rossen: e.g. white-space: pre?
Florian: Do we have agreement that we should seek interoperability?
That will require changes in browser behaviors.
smfr: For Safari we'll need to look at which clients use the
combinations that would change and see if that would cause
deviations in their behavior.
Rossen: So last time we were wondering: does this really matter?
Florian: Why do we have these properties if it doesn't matter?
Rossen: We haven't seen any bugs.
Florian: Maybe because there's no interoperability so no-one is
using them.
Florian: Bloomberg had a requirement for something that is none of
the above.
Florian: word-wrap: break-word on, with spaces being preserved on
the next line.
fantasai: So basically they want a break opportunity anywhere in
the spaces rather than at the end,
fantasai: which I think makes a lot more sense.
Florian: But nobody does that in the base case yet.
Rossen: So you want to be able to break on any space that happens
to hit the end of the containing block space, but you
don't want to break inside words?
Rossen: and also preserve all the space?
Florian: I think that's one desirable behavior.
fantasai: That would be my preferred default.
[discussion about priorities]
smfr: Is it really about where to break, or about ignoring the
trailing spaces on the line?
Florian: I don't think there's a single thing that authors want.
Having the spaces go off and disappear might be one thing
they want. Wrapping spaces when they hit the end of the
line might be another.
Rossen: What does content-editable do?
Florian: The same as text areas, I think. Strange things if not
white-space: pre-wrap (for legacy). Inserts alternating
string of space and nbsp.
Florian: The spec says this is insane so authors should opt into
sanity by using white-space: pre-wrap,
Florian: which doesn't do the right thing.
fantasai: I think we should have 2 values, one for content-
editable thing and one for looking pretty thing.
fantasai: If there's a wrap opportunity and we're not taking it
but we are overflowing - that's weird.
fantasai: So, one mode where spaces are visible chunks of
wrappable text, and underline,
fantasai: and another which [...]
johanneswilm: Just to note, in content-editable there are lots of
problems in various browsers.
Florian: The intent is reasonable but the way of achieving it is a
huge hack that's only kind of working.
fantasai: Smfr, if we made the behavior of pre-wrap different to
what you're doing and added another value that does what
you're doing, would that be OK?
smfr: We'd need to change our UA stylesheet for text areas. Might
also have other clients but could deal with that. Preference
would be not to change the behavior but if necessary could
switch to a new value.
fantasai: The current behavior hard to explain. Would be more
understandable if we did it differently.
smfr: We don't want a behavior change in text area.
fantasai: That would be up to the UA.
glazou: I want to avoid liberties for UA to do things inside text
areas that become too hacky for WYSIWYG editors to rely on.
fantasai: If you set pre-wrap then you get the base behavior,
fantasai: You probably want default behavior for text areas to
match the platform, which we're not going to be able to
standardize.
Florian: That doesn't happen currently.
Florian, fantasai, et all: So have a default that is 'same as
system text' (auto?) then change base case (word-wrap:
normal) to something sensible and interoperable, and have
another case for text input that is interoperable.
Florian: So are browsers happy with that?
<Bert> (white-space: pre-wrap-but-keep-spaces-at-line-breaks' but
with a slightly shorter name?)
<Chris_Lilley> (white-space: preserve-spaces)
fantasai: We have a combinatorial problem here: white-space:
pre-wrap|new-value; word-wrap: normal|break-word;
word-break: normal|break-word;
fantasai: So white-space is the two base cases, for nice text and
for editable text.
fantasai: Then word-wrap and word-break are two properties that
modify that.
fantasai: word-break: break-word is treat English characters like
Chinese characters, essentially.
fantasai: word-wrap: break-word is do terminal-style wrapping.
Florian: So if you're in the Chrome behavior (collapsing spaces at
EOL) and you turn on break-word then you resurrect the
spaces?
fantasai: No.
fantasai: So there's 8 combinations.
Florian: Do we want another keyword for an interoperable edit
behavior?
fantasai: We should wait and see if there's a demand.
fantasai: A lot of those cases will be dealt with by pre-line.
smfr: How does pre-line and pre-wrap differ?
fantasai: pre-line collapses all the spaces but preserves line
breaks.
SteveZ: How does it interact with hyphenation?
fantasai: It's a different switch. Hyphens never insert into
sequences of white-space.
fantasai: Hyphenate first, chunk if unhyphenatable.
Florian: Call it do-whatever-the-platform-does-auto.
Bert: What does pre-wrap do then?
Florian: Preserves the spaces, and wraps.
Bert: It should drop spaces at wrap points.
fantasai: That's asymmetric - spaces at left side are preserved.
Bert: That's what the new value should be for, rather than auto.
Florian: That's what we wanted to wait for demand for.
Florian: Can we?
Florian: There's no consistency between editors.
fantasai: In a text editor, when you wrap to the next line the
space is gone. Not invisible, gone.
fantasai: We're just talking about the rendering.
fantasai: It's not modifying the DOM,
fantasai: or exporting.
[more discussion about asymmetry]
Florian: So, conceptually, three values exist. May not need to add
Bert's just yet. Default should be auto.
smfr: auto is awkward - it's a pre- behavior.
Florian: auto-pre-wrap?
fantasai: Can we resolve on this?
ChrisL: I heard explicit agreement from Apple - is that OK with
you, Microsoft?
Rossen: Once we start defining it, we'll see.
Rossen: We're not ready for discussion yet but, won't block it.
Rossen: I will revisit when it's better defined.
smfr: Can UAs specify this behavior for content-editable?
Florian: Yep.
fantasai: But would you want to?
plinss: I'm concerned that if we're changing behavior at LC for
level 3, no one will change behavior for years
fantasai: Could just put a note in L3 that things are going to
change in L4.
Florian: But what L3 permits, L4 would forbid
fantasai: Let's put it in L3 and mark it at risk.
RESOLVED: pre-wrap preserves all spaces visibly and allows
wrapping before and after every space (to go into level
3 and mark as at risk)
RESOLVED: Add auto-pre-wrap* which does system-dependent behavior
for multi-line text fields (to go into level 3 and mark
as at risk) *TBB
RESOLVED: Add pre-wrap-trim to level 4
RESOLVED: And the name shall be pre-wrap-auto
Florian: The ch unit doesn't mean the same thing in IE to
everywhere else
Rossen: File a bug
CSS 2.2
-------
<ChrisL> http://www.w3.org/TR/CSS2/
<ChrisL> W3C Recommendation 07 June 2011, edited in place 17
December 2014 to point to new work
ChrisL: There's a big red scary box that says don't look at CSS2.1
anymore because we've got new work and it's better.
<ChrisL> http://dev.w3.org/csswg/css2/cover.html
ChrisL: But that work has never been published. We have an ED but
no FPWD.
dbaron: Is there a different version around?
[a resounding maybe]
<ChrisL> http://dev.w3.org/csswg/css2/changes.html
ChrisL: Yes there's a changes list. So does anyone object to
publishing an FPWD?
smfr: How long-lived is this going to be? Does it contain anything
that isn't in another module?
fantasai: Tables. So it'll exist for a while.
ChrisL: The plan was to migrate eventually but it won't happen
soon.
fantasai: So we're publishing 2.2 as a way of updating the REC
without updating the REC?
ChrisL: Yeah. We already made this decision though - see the big
red box.
dbaron: It needs to refer to itself as CSS2.2 more consistently
Bert: I'll update.
dbaron: Mostly just the abstract.
SimonSapin: Can we make the scary red box appear on every page of
2.1?
plinss: Yes, we should do that.
smfr: Can we annotate this to point out the sections that have
been superseded?
??: TabAtkins has an action to track this in bikeshed
ChrisL: Yeah, but it should also be an issue on the spec.
ChrisL: So is there agreement to do minimal cleanup then publish
as FPWD?
<SimonSapin> https://github.com/servo/servo/wiki/Relevant-spec-links#css-2
maps CSS2 sections to CSS 3+ documents that replace
them, to the best of my knowledge.
RESOLVED: FPWD of CSS2.2
RESOLVED: Republish CSS2.1 with more angry red boxes
Received on Tuesday, 26 May 2015 23:19:29 UTC