- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 22 Oct 2018 18:25:58 +0000
- To: public-css-archive@w3.org
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.` <details><summary>The full IRC log of that discussion</summary> <heycam> Topic: Text-spacing is too strict<br> <heycam> github: https://github.com/w3c/csswg-drafts/issues/3229<br> <heycam> myles: this is about text-spacing property, has a buynch of examples that control spacing between script changes on a single line<br> <heycam> ... desirable for mixed CJK and latin on a single line<br> <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<br> <heycam> ... also things like because CJK punctuation tried to fit in a whole em block there's usually a lot of white space<br> <heycam> ... two punctuation characters next to each other is to push them together<br> <heycam> ... this is a good thing<br> <heycam> ... the concern we have is that there are different typographic design houses with different style guides<br> <heycam> ... and how much space to add between full width kana vs a latin character, etc.<br> <heycam> ... so different design studios have different rules abotu where they insert these spaces and how much to add<br> <heycam> ... we'd like to implement this property, but the definition is very strict<br> <heycam> ... lists which characters and how much space to add<br> <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<br> <heycam> ... I've listd a few examples<br> <heycam> florian: without going throguh the examples, at the conceptual level yes there are different opinions on spacing<br> <heycam> ... some of these topics we can find agreement on, others not<br> <heycam> florian: for people who don't care, it doesn't matter<br> <heycam> ... for people who do care, they will only turn it on if it's predictable<br> <heycam> ... if they can't quite know what they'll get out of it, they'll do it manually<br> <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<br> <heycam> ... but a ua should be able to improve the typography of the entire web<br> <heycam> astearns: if you loosen things, you have an inconsistency between UAs, and authors are put in a bind<br> <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<br> <heycam> ... so a publishing house could say this variation is the one I want<br> <heycam> myles: I don't think the proposal is contrary to that<br> <heycam> ... the thing that I'm aiming for is a way to have platform dependent spacing<br> <heycam> ... also having a way to have a specific well defined one, that's great too<br> <heycam> ... conceptually an auto value is distinct<br> <heycam> florian: could we keep the existing auto value as that? [...]<br> <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<br> <heycam> ... two things that people want. if we dont have either, better to start with a looser definition<br> <heycam> ... if they say they really want some particular behavior we can add some more strict definitions<br> <heycam> florian: I think having an auto value would be nice for that general case of 'I want better typo'<br> <heycam> ... I'm concerned that this will cause compat problems<br> <heycam> ... that's when you end up with 1 line in one browser and 2 lines in another<br> <heycam> ... I wouldn't be opposed to an auto value, but that is a concern<br> <heycam> ... make the existing values fuzzy doesn't sound great<br> <heycam> myles: i share concern about web compat<br> <heycam> ... there would need to be an investigation phase<br> <heycam> florian: adding another value would be nice<br> <heycam> ... if we start changing in different browsers what they do that sounds scary<br> <heycam> myles: the question about whether it should be the default value, I don't think we have information yet<br> <heycam> florian: I suspect auto can't be default<br> <heycam> fantasai: i would love it if auto did beautiful typo by default<br> <heycam> drott: ...<br> <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<br> <heycam> ... but not in markup<br> <heycam> ... this property allows you to inject the right kind of space<br> <heycam> ... you could give some flexibility to the browser, to choose 1/4em or 1/6em<br> <heycam> ... there's also things relating to collapsing white space<br> <heycam> ... e.g. in CJK punctuations<br> <heycam> ... the boundary between characters<br> <heycam> drott: my question was how many values would we need<br> <heycam> ... to make it possible for the user to specify that<br> <heycam> ... within a run of the same script could be handle by opentype<br> <heycam> ... but how many additional ones would be needed<br> <heycam> fantasai: the spec triggers the opentype features when the settings are set<br> <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<br> <heycam> ... trimming/spacing controls depends on context<br> <heycam> ... and it crosses text runs in the same language<br> <heycam> ... OT can't do this for us<br> <heycam> ...but we can use OT to do the glyph transformations or make full width be typset half width for example<br> <heycam> myles: so you're asking how many combinations are required to do....?<br> <heycam> drott: one was 1/4 em ...<br> <heycam> florian: the existing property have 15 keywords<br> <heycam> ... not all combinations of them are valid<br> <heycam> drott: for these 15, I'm trying to get an idea of how many lengths you'd need to specify<br> <heycam> ... just to gauge how many additional values you'd need<br> <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<br> <heycam> florian: do we want to resolve on an auto value, which lets the UA do whatever it feels like?<br> <heycam> fantasai: the initial value is normal<br> <heycam> ... happy with that or add an auto to do something<br> <heycam> myles: is there interop on what normal means?<br> <heycam> florian: yes, the initial value is what the web does today<br> <heycam> ... it's just not good typography<br> <heycam> ... for now, the auto value, isn't the default, since it's different from what UAs do<br> <heycam> fantasai: if you want to try having it be the initial value ...<br> <heycam> florian: that's going to break every good typographic website<br> <heycam> ... if you do it on top of them doing it manually<br> <heycam> ... maybe the spacing between latin and ideographic might be web compatible?'<br> <heycam> ... I suggest adding an auto and experimenting with it<br> <heycam> fantasai: if they're experimenting to see with what the initial value can do, may as well do it for normal itself<br> <heycam> myles: right now I think adding a new auto value is the best way to go<br> <heycam> RESOLVED: Add a new text-spacing:auto value, which is not the initial value.<br> <heycam> florian: I encourage looking at what subset of auto behavior could move to the initial normal value<br> <heycam> -- lunch break until 1pm --<br> <heycam> (1:10pm)<br> <eae> ScribeNick: eae<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3229#issuecomment-431806206 using your GitHub account
Received on Monday, 22 October 2018 18:25:59 UTC