css-meeting-bot
commented
6 years ago The CSS Working Group just discussed Text-spacing is too strict, and agreed to the following:
RESOLVED: Add a new text-spacing:auto value, which is not the initial value.
The full IRC log of that discussion
<heycam> Topic: Text-spacing is too strict<heycam> github: https://github.com/w3c/csswg-drafts/issues/3229
<heycam> myles: this is about text-spacing property, has a buynch of examples that control spacing between script changes on a single line
<heycam> ... desirable for mixed CJK and latin on a single line
<heycam> ... good typo style says if you have a bunch of ideographic characters then some latin words, between those two things should be a bit of extra space
<heycam> ... also things like because CJK punctuation tried to fit in a whole em block there's usually a lot of white space
<heycam> ... two punctuation characters next to each other is to push them together
<heycam> ... this is a good thing
<heycam> ... the concern we have is that there are different typographic design houses with different style guides
<heycam> ... and how much space to add between full width kana vs a latin character, etc.
<heycam> ... so different design studios have different rules abotu where they insert these spaces and how much to add
<heycam> ... we'd like to implement this property, but the definition is very strict
<heycam> ... lists which characters and how much space to add
<heycam> ... we understanding this came from jlreq, and that's a good starting place, but since this is up to typo conventions of the platform you're on, it would be good to looosen this for some wiggle room
<heycam> ... I've listd a few examples
<heycam> florian: without going throguh the examples, at the conceptual level yes there are different opinions on spacing
<heycam> ... some of these topics we can find agreement on, others not
<heycam> florian: for people who don't care, it doesn't matter
<heycam> ... for people who do care, they will only turn it on if it's predictable
<heycam> ... if they can't quite know what they'll get out of it, they'll do it manually
<heycam> myles: this is a property for changing general behavior, I understand a particular publisher doesn't like the way a particular impl or the whole web does it, and they may impl it thsemelves
<heycam> ... but a ua should be able to improve the typography of the entire web
<heycam> astearns: if you loosen things, you have an inconsistency between UAs, and authors are put in a bind
<heycam> ... the problem your'e pointing out means we need more properties to change the way we deal with spacing to hit those uses cases
<heycam> ... so a publishing house could say this variation is the one I want
<heycam> myles: I don't think the proposal is contrary to that
<heycam> ... the thing that I'm aiming for is a way to have platform dependent spacing
<heycam> ... also having a way to have a specific well defined one, that's great too
<heycam> ... conceptually an auto value is distinct
<heycam> florian: could we keep the existing auto value as that? [...]
<heycam> koji: I think I'm with myles in general. I agree with florian that some people want exact typographic characteristics, but currently we dont have anyhting
<heycam> ... two things that people want. if we dont have either, better to start with a looser definition
<heycam> ... if they say they really want some particular behavior we can add some more strict definitions
<heycam> florian: I think having an auto value would be nice for that general case of 'I want better typo'
<heycam> ... I'm concerned that this will cause compat problems
<heycam> ... that's when you end up with 1 line in one browser and 2 lines in another
<heycam> ... I wouldn't be opposed to an auto value, but that is a concern
<heycam> ... make the existing values fuzzy doesn't sound great
<heycam> myles: i share concern about web compat
<heycam> ... there would need to be an investigation phase
<heycam> florian: adding another value would be nice
<heycam> ... if we start changing in different browsers what they do that sounds scary
<heycam> myles: the question about whether it should be the default value, I don't think we have information yet
<heycam> florian: I suspect auto can't be default
<heycam> fantasai: i would love it if auto did beautiful typo by default
<heycam> drott: ...
<heycam> florian: there are many things affected by this property. in the french context, you have a space before a column, a narrow non breakable space
<heycam> ... but not in markup
<heycam> ... this property allows you to inject the right kind of space
<heycam> ... you could give some flexibility to the browser, to choose 1/4em or 1/6em
<heycam> ... there's also things relating to collapsing white space
<heycam> ... e.g. in CJK punctuations
<heycam> ... the boundary between characters
<heycam> drott: my question was how many values would we need
<heycam> ... to make it possible for the user to specify that
<heycam> ... within a run of the same script could be handle by opentype
<heycam> ... but how many additional ones would be needed
<heycam> fantasai: the spec triggers the opentype features when the settings are set
<heycam> ... you might want to be able to control particular spacing operations, so we will use the right OT things, but it won't do them automatically
<heycam> ... trimming/spacing controls depends on context
<heycam> ... and it crosses text runs in the same language
<heycam> ... OT can't do this for us
<heycam> ...but we can use OT to do the glyph transformations or make full width be typset half width for example
<heycam> myles: so you're asking how many combinations are required to do....?
<heycam> drott: one was 1/4 em ...
<heycam> florian: the existing property have 15 keywords
<heycam> ... not all combinations of them are valid
<heycam> drott: for these 15, I'm trying to get an idea of how many lengths you'd need to specify
<heycam> ... just to gauge how many additional values you'd need
<heycam> fantasai: if we're adding control over lengths, it would be in a separate property, so you could switch the behavior on and off without having to reset at every stage the length you want to set
<heycam> florian: do we want to resolve on an auto value, which lets the UA do whatever it feels like?
<heycam> fantasai: the initial value is normal
<heycam> ... happy with that or add an auto to do something
<heycam> myles: is there interop on what normal means?
<heycam> florian: yes, the initial value is what the web does today
<heycam> ... it's just not good typography
<heycam> ... for now, the auto value, isn't the default, since it's different from what UAs do
<heycam> fantasai: if you want to try having it be the initial value ...
<heycam> florian: that's going to break every good typographic website
<heycam> ... if you do it on top of them doing it manually
<heycam> ... maybe the spacing between latin and ideographic might be web compatible?'
<heycam> ... I suggest adding an auto and experimenting with it
<heycam> fantasai: if they're experimenting to see with what the initial value can do, may as well do it for normal itself
<heycam> myles: right now I think adding a new auto value is the best way to go
<heycam> RESOLVED: Add a new text-spacing:auto value, which is not the initial value.
<heycam> florian: I encourage looking at what subset of auto behavior could move to the initial normal value
<heycam> -- lunch break until 1pm --
<heycam> (1:10pm)
<eae> ScribeNick: eae
xfq
macnmm
litherum
https://drafts.csswg.org/css-text-4/#text-spacing-property
The spec states:
... and includes definitions of "ideographs" and "non-ideographic letters."
Later, the spec also provides required collapsing rules:
When discussing this with our team of designers at Apple, it turns out that we have our own similar behavior for native text. Our design team at Apple does increase spacing between script changes and decrease spacing between adjacent punctuation on a line, and the details of how we do it are similar but don't exactly match JLREQ or CSS. We used JLREQ as an input to the design, but there were other inputs too. From speaking to our designers, it turns out the specific rules for exactly how much space to expand or shrink can vary from one design house to the next.
Therefore, I'd like to propose the following changes to the spec:
ideographic-alphaandideographic-numeric, change "Creates 1/4em extra spacing between" to "Creates extra spacing between."lang="ja"on content, it should be free to modify the spacing differently than when it seeslang="zh-Hans".punctuationvalue. Make the mechanism for opting-out of fullwidth punctuation collapsing also opt out of the French narrow no-break space thing.ideographic-alphaandideographic-numericimprove typography, and should be in the initial value of the property. (We realize this may not be possible given web compat, but we'd like to at least try.)The goal of these modifications is not to wreck the intention of the property, but just to allow for more flexibility for different publishing houses to match their own internal style guide. For all of these relaxations, we can certainly add in some explanation about what good choices would be for a new implementation.
P.S. "Unless text-spacing is set to space-adjacent or none" is perhaps not what is meant, since this property includes a bunch of other values in addition to those. Perhaps it should be "Unless text-spacing includes space-adjacent or none?"