- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 7 Jun 2016 21:25:15 +0300
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Text 3 & 4
--------------
- RESOLVED: Not breaking on nbsp; for the break-all value.
- RESOLVED: break-all should do the same as normal for preserved
spaces.
- RESOLVED: break-spaces goes into overflow-wrap instead of
word-break.
- RESOLVED: Keep current hanging-punctuation values in Level 3.
- RESOLVED: Add note that more non-CJK-relevant keywords will be
added to Level 4.
Logical properties and margins in vertical text
-----------------------------------------------
- RESOLVED: margin/border/padding logical properties use the
element's own writing-mode, not their parent's
writing-mode.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/san-francisco-2016#proposed-agenda-topics
Scribe: iank
CSS Text 3 & 4
==============
work-break
----------
<smfr> https://drafts.csswg.org/css-text-3/#word-break-property
Florian: If you have either a nbsp or whitespace-prewrap so you
have a bunch of spaces go off the line.
Florian: The spec just got updated to do nothing within the spaces.
Florian: Firefox will break all types of spaces (preserved spaces
and nbpsps).
Florian: Safari will break nbsp;
Florian: Safari doesn't preserve spaces at the end of lines.
Florian: Chrome doesn't preserve, and doesn't break nbsp;
TabAtkins: Firefox behaviors seems to be the best here.
fantasai: I think we put the glue rules to be at a higher priority;
nbsp should never break.
Florian: break-all is poorly named.
Florian: I don't strongly care either way, just want consensus.
fantasai: break-all doesn't mean break everything. It also
maintains a bunch of line-breaking rules.
fantasai: word-break controls what is a word for line breaking
purposes.
fantasai: These are all used in normal text. In Japanese you'll
have Latin text inside, which follows Japanese line
breaking rules.
fantasai: break-all makes Latin break like CJK text.
fantasai: spacing controls and other breaking controls should
be at a higher level.
fantasai: These are formatting characters, which is why they
should be at a higher level.
TabAtkins: So this is really poorly named.
<TabAtkins> So having your explanation, that one makes CJK act
like Latin, and the other makes Latin act like CJK,
really prominent in the spec would be great.
Florian: For extra context the reason I run into this, for preserved
spaces, we'll have an additional keyword called break-spaces.
Florian: Didn't know if this was in addition or instead.
fantasai: We made a decision on this.
<fantasai> word-break is about what's considered a "word"
for line-breaking, which is what this switch is about
<Florian> I think break-spaces works as a value of overflow-wrap
as well, since preserved spaces only need to be wrapped
if they already overflow
PROPOSAL: Not breaking on nbsp; for the break-all value
Florian: What about preserve spaces?
Florian: Firefox wraps, IE/Edge don't.
Florian: Which way do we go?
TabAtkins: I think nbsp; is different.
tantek: Doesn't sound author intuitive?
tantek: Treating them differently seems bad.
TabAtkins: This is specifically about the word breaking behavior
of CJK and making Latin act like that.
Florian: Neither of them break on nbsp;
RESOLVED: Not breaking on nbsp; for the break-all value.
fantasai: Don't have an opinion for preserved spaces.
TabAtkins: What is the ideal behavior for pure CJK
TabAtkins and preserve spaces overflowing..
Florian: I think this is (a) subjective and (b) not different to
Latin.
Florian: Don't care about default, just as long you can switch.
Florian: Preserved spaces that overflow the end of line don't get
wrapped, they overflow as inked overflow.
Florian: ink-overflow unless the element is editable, then they
should be scrollable overflow.
TabAtkins: How much do we care about editable things.
Florian: That's probably the behavior that people want.
Florian: proposal: break-all should do the same as normal for
preserved spaces.
RESOLVED: break-all should do the same as normal for preserved
spaces.
Florian: Where does the break-spaces go?
TabAtkins: Goes in overflow-wrap
Florian: I'm cool with that.
Rossen: <thinking looks>
Rossen: Why overflow-wrap
[missed]
fantasai: I think this switch should be in word-break.
TabAtkins: Let's move this to hallway discussion.
Florian: Resolved to add break-word, does funky stuff.
fantasai: A lot of these switches should exist just more clearly
named.
<br = 15mins>
Scribe: Florian
<Florian> Proposed resolution: break-spaces goes into overflow-wrap
instead of word-break
RESOLVED: break-spaces goes into overflow-wrap instead of
word-break
Hanging Punctuation
-------------------
Scribe: TabAtkins
<dauwhe> https://drafts.csswg.org/css-text-3/#propdef-hanging-punctuation
astearns: There was ML discussion about adding a "start" value so
that the current hanging-punctuation property would be
usable for roman text as well as CJK.
fantasai: For level 4, right?
fantasai: Level 3 was supposed to have been finished 2 years ago.
smfr: Yes, we prefer that.
astearns: Sure.
astearns: So: add "start" as a value?
fantasai: I think that was my goal, to have start and end be this
parallel thing.
fantasai: Open question is how it's defined.
fantasai: Currently works for CJK - you have a grid, you want an
optical alignment effect while preserving it.
fantasai: Roman text doesn't do that, it's just optical alignment.
astearns: It *can* be.
fantasai: I want the visual effect of a strong line, that's what
this is about.
fantasai: There are various techniques; strictly hanging, half
hanging, etc.
fantasai: But we don't want that behavior to leak into CJK.
fantasai: We need some syntactic flag to separate this out.
fantasai: So we have a "roman" start and end.
Florian: CJK doesn't matter because it *doesn't* hang on the
start side.
astearns: But roman start only makes sense if there's a roman end,
which works slightly differently than CJK end.
astearns: So question is if it needs to be a separate value, or
if we can do some special accommodation.
fantasai: I don't think we can - just because there's some Latin
text at the end of a line, doesn't mean they want the
roman-style hanging behavior.
fantasai: Don't have opinion on how we do it - just an end-roman,
or a pair of start-roman/end-roman; it just needs to be
distinguishable.
astearns: It sounded on the ML like Safari wanted roman hanging
punctuation soon.
smfr: We have a basic implementation already.
fantasai: What do you do?
smfr: For the punctuation chars listed in the spec, we hang them
outside the line box. They're layout-overflow I believe
currently,
smfr: Our main issue were posted by Jon Lee.
<smfr> https://lists.w3.org/Archives/Public/www-style/2016Apr/0004.html.
<fantasai> This was my reply:
https://lists.w3.org/Archives/Public/www-style/2016Apr/0102.html
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016Apr/0105.html
smfr: He has a proposal to amend hanging-punctuation to handle
roman text.
smfr: He intends to respond to the last mail in the thread, but
hasn't sent it yet.
astearns: My initial thoughts on his classifications is that this
might be something that shouldn't be specifically in CSS
as a property, but as a recommendation outside to handle
different char classes differently.
astearns: Unsure if it makes sense to specify "punctuation is this,
dashes are this, other punctuation are this" - instead
just say "here are the classes, come up with something
that looks good".
Florian: fantasai's point stands - author needs to indicate what
style of hanging they want. Don't want to get Latin
hanging just because the line ends in Latin.
astearns: Right. I hadn't considered the mixed-language scenario
at the time.
Florian: CJK is commonly mixed with Latin, without wanting
Latin-style typography.
smfr: We definitely want a mode that looks reasonable with lots
of scripts automatically.
fantasai: Agree.
fantasai: The ML proposal seems complicated. I'd rather have
"please do some sort of hanging punctuation optical
alignment thing".
smfr: And for CJK what would you do?
fantasai: The auto would just do whatever you'd do for Latin.
CJK rules would still work.
fantasai: Some Latin typographical engines, you can either
hang a char or not, nothing in between.
fantasai: So they can decide what chars look good with that.
fantasai: Others might have special kerning for end-of-line/etc.
fantasai: Or optical analysis of glyph shapes, whatever.
fantasai: I haven't heard anyone arguing they want an engine
to have both of these and switch between them; I've
only heard people wanting them to look good.
fantasai: I'd rather we had one switch which was "do some kind
of edge alignment, whatever" rather than having the
author have to specify everything, we have to deal
with keywords for different scripts, etc.
fantasai: There's a ton of scripts, we don't want that complexity.
astearns: But they do need a switch for CJK vs Latin.
fantasai: Yes.
astearns: So what happens with the Latin-specific values later...?
fantasai: Why use something different for Latin vs Cyrillic vs
Thai? CJK is different because it has a grid system
it aligns to. Everything else is basically similar.
astearns: I think we don't know the conventions. We know CJK,
we know some Roman conventions. There may be, for
example, Indic hanging conventions that are different.
fantasai: If they require an independent switch, we should deal
with that. But so far as I know right now, everyone's
the same.
astearns: So if we add roman-specific values, it sounds like
the extension point is more script-specific ones.
Florian: I think she wants the new value to not be roman-specific;
it'll apply to everything.
Florian: And if another language comes up that doesn't use the
CJK grid *or* the Latin-ish optical alignment, then we
can add more values.
Florian: But as long as we don't get into details, we don't need
to be roman-specific.
smfr: I think we'd like a switch that is like auto, make it look
good as much as we can.
Florian: How about calling it auto?
myles: There are many different news publications on the web
that have their own style guides.
myles: "Just make it good" won't suffice.
fantasai: What are the types of good we have to switch between?
dauwhe: You mentioned hyphens - I probably don't want those to
hang, but I do want quotes to hang, periods and commas.
fantasai: What categories?
dauwhe: I don't think they're categories...
smfr: "I want W's to hang."
myles: Or some chars, like em-dash, half-hang
myles: I agree that a list of chars + percentages isn't a great
idea. We just don't want a boolean, either.
myles: In the middle is a series of keywords, the approach Jon
has taken.
fantasai: But the keywords are script-specific. As far as I can
tell, your prefs aren't script-specific. They're
varying *within* a writing system.
fantasai: So we need some idea of what those variances are.
astearns: So we have a plan to add non-CJK values for
hanging-punctuation in Text 4.
astearns: Do we have a resolution to do that?
dauwhe: Leaving level 3 as it is.
astearns: Yes. And leaving open the question of *how* to do
the switches.
Florian: I think we have consensus on adding *something*,
just not what.
astearns: I was thinking we understand prefixes exist, we just
have no idea how to do them.
<dauwhe> http://stevehickeydesign.com/blog/2012/12/04/hanging-punctuation-with-css/
smfr: Another idea is to defer hanging-punctuation from level 3.
smfr: Do we have enough implementations to keep it in level 3?
dauwhe: I'm confused - if I read level 3 right now, there's no
indication this is a CJK feature.
TabAtkins: Like word-break!
astearns: So *do* we have impls?
Florian: AH and 超縦書 (BPS's viewer)
astearns: And WK has started.
dauwhe: Prince doesn't have it, though we've been bothering them.
astearns: Doesn't sound like a *bad* plan to punt it to level 4,
with an issue for roman, and a note that the current
value is for CJK.
fantasai: This was added for the Japanese community, and we have
some implementations. Don't think the current set of
values are problematic.
smfr: My concern is that an author that uses hanging-punctuation
will expect it to work on Latin text.
TabAtkins: So punting it is just a signal to authors reading the
spec? That would be served similarly by a prominent note
in level 3?
smfr: Yeah, maybe. Just concerned about locking on current values.
astearns: I'd prefer to hit CR sooner rather later.
TabAtkins: Are the current values bad, then?
Florian: When we add the new values, we might rename the old ones.
TabAtkins: Then it's not stable, punt it.
fantasai: I don't want to punt it.
TabAtkins: Are you sure the current values don't change?
fantasai: No.
TabAtkins: Then it's not stable, punt it. Or lock down the current
values and resolve to work around naming issues in the
future.
fantasai: I want to keep it in level 3 and keep working on the new
ones.
TabAtkins: Should Safari ship what they have?
fantasai: What do they have?
smfr: Certainly first, last, ...
smfr: We somehow made them work in Latin languages.
smfr: I think we just made more punctuation hangable.
fantasai: I think just adding more chars is fine.
astearns: I thought the problem is there wasn't a start value.
astearns: You can hang at the start of first line, end of other
lines, but not at the start of non-first lines.
TabAtkins: We're consistent on letting Latin stuff go in level 4.
Question is if the CJK stuff currently in 3 is stable
or not. Can Safari ship with what's in the spec today,
or something that's trivially fixable?
fantasai: Dunno.
astearns: I propose we put a note in the draft now saying that the
current values are designed for CJK, and that level 4 is
going to do Latin more significantly.
fantasai: First definitely works on Latin, the end ones only work
on CJK.
dauwhe: Why that restriction? Looks Latin-ish.
astearns: force/allow are accommodations for the grid, which makes
them CJK.
astearns: You wouldn't use force-end, just "end" for Latin.
TabAtkins: Do they do different things in Latin text?
dauwhe: I think you could. Maybe something weird if a period is
*right* at the margin...
astearns: If you have force-end and a short line, will it pull
things out?
fantasai: Yes. force-end doesn't count the punctuation for the
purpose of justifying. It is *always* pushed out.
fantasai: If you don't justify, nothing happens. But right-align
also makes it hang.
fantasai: For Latin there was some additional considerations about
hanging hyphens and dashes, maybe brackets.
dauwhe: Quotes are biggest one.
fantasai: They're defined for CJK, but also work for Latin for a
subset. Future Latin-y things (like brackets) will be
additional keywords. That was my plan.
fantasai: So current values are fine. New behaviors, we'll add
new keywords.
dauwhe: Current keywords look fine, just insufficient.
<liam> [ some systems in the past have treated hung punctuation as
a sort of kerning that could be overridden by particular
fonts ]
[??? something about periods at the beginning of the line]
fantasai: So the keywords that would have start and end variants
don't exist yet.
fantasai: [current *-end keywords are for characters that don't
appear at the beginning of lines, e.g. periods and
commas]
RESOLVED: Keep current hanging-punctuation values in Level 3.
RESOLVED: Add note that more non-CJK-specific keywords will be
added to Level 4.
ACTION dauwhe to work with fantasai to figure out what non-cjk
keywords need to exist for hanging-punctuation
<trackbot> Created ACTION-776
Logical properties and margins in vertical text
===============================================
<astearns> https://lists.w3.org/Archives/Public/www-style/2016May/0098.html
zcorpan: When you mix vertical and horizontal, for margin-block-
start...
fantasai: The spec hasn't been synced with implementations, it was
resolved one way, now you're saying it should go another
way.
zcorpan: So impls use the element's own writing-mode to determine
logical margin mappings; spec says to use parent's
writing-mode.
zcorpan: Since browsers use logical props in the UA style sheet,
there may be content that depends on current behavior.
zcorpan: So I suggest we align the spec with impls, and if we want
to solve the use-case of using the parent's writing-mode,
we use new properties.
astearns: Are you aware of use-cases?
zcorpan: Yes for both.
zcorpan: Using parent is if you want to position children with
margins and don't care about the WM of the children.
fantasai: There's been arguments both ways, use-cases for both.
fantasai: But insofar as m/b/p is concerned, they're used for
lists, to control the indentation in the UA style sheets.
fantasai: We'll have compat issues with just RTL, not even writing-
mode.
fantasai: So we need margins to calculate according to impls,
based on writing-mode of element.
zcorpan: I think right now <ul> and <ol> use padding on the
container to indent children, but <dl> uses margin on the
children.
TabAtkins: Wut???
Florian: Can we separate direction and writing-mode?
fantasai: No, you'd have only a partial mapping then, be very weird.
TabAtkins: Ah, dt/dd use indentation to separate the elements.
zcorpan: So can we resolve on the first proposal? To make spec
match reality?
Rossen: Every meeting we decide this back and forth. :/
fantasai: But now we have a content dependency to stick ourselves
with.
RESOLVED: m/b/p logical properties use the element's writing-mode,
not the element's parent's writing-mode.
zcorpan: I think if we want to solve the use-case of getting
parent's writing-mode, we can use a new property.
Florian: Is this parent, or containing block?
fantasai: Parent. CB is better, but this has to be done at cascade
time (determining CB is complex at that point) and CB
can be arbitrarily high up the tree.
Florian: What's use-case for abspos basing on parent/CB?
fantasai: If abspos is like a display mode, you're positioning in
some container, and there you care about the container
context.
fantasai: You can get around this today by using a wrapper element
with the parent's writing-mode
fantasai: Think we'll end up sticking with that, instead of new
properties. It's simpler.
fantasai: Or maybe have some notion of an "internal" writing mode.
<br dur=1h>
Received on Tuesday, 7 June 2016 18:26:13 UTC