- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 19 Oct 2016 21:12:03 -0400
- 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.
=========================================
Define effect of text-transform on copy/paste (Text Issue #108)
---------------------------------------------------------------
- As a general principle there was a desire to have copy/paste
match what users are seeing when they copy, however several
people believed that the actual use cases in this case
overrode the principle.
- There were four main use cases that the group uncovered:
1) Turning a heading into all caps
2) Turning a first line into all caps
3) Turning acronyms into small case when they're all caps in
the source
4) A ruby use case around ruby where in Japanese "じゃ" reads
"sha", and "しや" reads "shiya". If that's your ruby, and
there can be a text-transform to turn one into the other,
because at small sizes it is hard to tell apart. But out of
context, you don't want to change the pronunciation.
- Though mostly in the above use cases preserving the
text-transform would be the worse user experience, there are
times where you would expect preservation.
- Consistency between inner text, paste to plain text, and range
to string was another thing to be considered in the decision.
- In a straw poll the group was about evenly split between copied
plain text ignoring text-transform or leaving it up to UA for
UX decision.
- Group members will look through browser bugs to try and
determine user expectations.
- There was also a desire to conduct a through user survey, though
no one was tasked with creating one.
- RESOLVED: White space property is applied to plain text paste
output.
Interaction of hanging-punctuation and kerning (Text Issue #122)
----------------------------------------------------------------
- RESOLVED: Don't define interaction between hanging punctuation
and kerning and leave it up to UA to decide how to
adjust.
Make hanging-punctuation scrollable overflow (Text Issue #123)
--------------------------------------------------------------
- fantasai will write up her proposal for review as there wasn't
time on the call.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Oct/0102.html
Present:
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Tony Graham
Koji Ishii
Dael Jackson
Brian Kardell
Brad Kemper
Ian Kilpatrick
Chris Lilley
Peter Linss
Myles Maxfield
Simon Pieters
Anton Prowse
Liam Quin
Florian Rivoal
Geoffrey Sneddon
Alan Stearns
Greg Whitworth
Regrets:
Rachel Andrew
Rossen Atanassov
Daniel Glazman
Jen Simmons
Lea Verou
Scribe: dael
CSS Text
========
astearns: Let's get started.
astearns: Does anyone have any extra items?
Define effect of text-transform on copy/paste (Issue #108)
----------------------------------------------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2015Apr/0015.html
fantasai: I think there was a later agenda item which was the same.
astearns: I was wondering
<astearns> https://lists.w3.org/Archives/Public/public-editing-tf/2016Apr/0005.html
<dbaron> presumably this is talking about plaintext copy/paste
rather than HTML?
<tantek> this is a long-standing debate
<tantek> as long as I can remember in the WG :)
fantasai: It's if text-transforms are preserved in copy/paste.
This got into a larger issue as to what is preserved on
copy/paste. The second URL is a proposal that you take
the source text and the only things CSS effects are
display property, content property and possibly
visibility. Text-transform has no effect, you take
source.
fantasai: The argument for is text-transforms are done stylistic
capitalization. So you capitalize an entire heading. It
doesn't affect how content is used. If you use font
transformation that shouldn't make a difference.
fantasai: Also ruby transformation is loss-y. It can change the
meaning of the word. We definitely want source text.
fantasai: Proposal is add text that says what is used as plain
text. If you're doing computation for rich text you'll
take info from HTML and I'm not proposing we define that.
<tantek> also ellipsed text should be copied!
<tantek> that is, text-overflow should not stop text from being
copied
myles: My concerns are about usage for text-transform. When a user
does copy/paste almost all users don't have knowledge of
distinction between dom and style. They'll expect to see
what they're seeing on the screen.
Florian: I'd say that if they're copy/pasting something in caps in
the middle of a legal document that should be in the
source. If you have the first line as caps from a
transform and you paste into a smaller line it will work
strangely.
* fantasai agrees 100% with Florian
myles: The difference is text-transform is used across the web
today. We have to work with the web we've got. Saying
authors should style differently doesn't work on existent.
Florian: If people use all caps for a title how is that different
from text-transform?
myles: Text only copy-paste you can't preserve.
<gregwhitworth> so, in this example:
http://jsbin.com/jaziqelifo/edit?html,css,output
<gregwhitworth> what does everyone do?
<zcorpan> gregwhitworth, safari/chrome/opera copy uppercase;
firefox copies original DOM case
<gregwhitworth> yep, Edge does the same as everyone else
<gregwhitworth> FF is the only one not copying
tantek: I think conceptually I'd start with a similar approach to
myles. There's a sense of user expectation where if they see
something they expect that. That's clear with things like
copying a list.
tantek: The problem happens when you look at actual uses of
text-transform. The most frequent use case I've seen is
turning a heading or a first line all caps. In both of
those cases the effect is less than what's desired.
tantek: What I've seen in the heading cases it's a style effect
that works on the page but when copied into plain text it
doesn't look right. I find authors have used titlecase in
their source content. So when you copy/paste you get the
titlecase.
<ChrisL> Yes, I am pleasantly surprised when copy and paste on a
title does not give me ALL CAPS
<fantasai> tantek, yes totally made sense :) Thanks for great
explanation
tantek: While I agree in principle once you look at specific
examples you get a better effect when you don't copy the
transform. I don't know how to further analyze. But I find
the specific case trumps the general principle, but that
doesn't preclude the general principle in other cases.
astearns: myles do you find that convincing?
myles: I guess...does anyone else have an opinion?
<dauwhe> I've wasted much of my life fixing all-caps text.
gregwhitworth: Everyone matches except FF. Is there a reason to
make the rest of us change? Is there outcry?
tantek: With FF we think it's higher fidelity. I think that's why
we did it. But I can't speak for other browsers.
ChrisL: I think it was designed that way. I'm always pleased when
I copy and the all caps becomes a titlecase. What we're
asking for is we want to know what users want without a
user study.
gregwhitworth: I think it's important to understand user want. I
just don't want to create more work without a
reason.
<Bert> (In my personal experience, I always wanted the original,
lowercase, but I haven't studied the use cases.)
<zcorpan> I'll note that .innerText applies text-transform. it's
not necessarily the same as plain-text copy but still
<johanneswilm> if you create an editor, you need to handle paste
anyway. and so it would be good if the browsers
provide somewhat similar html/inline-styles
tantek: That's another approach where we could leave it undefined
and see where it goes. Also, if you find other examples
for text-transform I'm interested in analyzing them.
fantasai: Another example is for acronyms where they're upper in
the source but if you want small case you do
text-transform: lowercase and font variant small caps.
If you copy that with the transform you'd get your
acronyms in small case.
tantek: Does Chrome or Opera do that?
fantasai: You'd have to find a page that's using small case for
acronyms. I haven't run a test on this. Whatever browser
preserves the text-transform will give you the lower
case. When you have the font it looks right, but when
you copy it out you lose the font.
fantasai: That seems like a reasonable thing to do.
tantek: I'd like to see a test to verify that. I wouldn't assume
browsers are doing the right thing. They may have a hack
to fix that up.
<gregwhitworth> http://jsbin.com/jaziqelifo/edit?html,css,output
<gregwhitworth> Edge preserves it
<dauwhe> Chrome is returning lowercased text
<tantek> gregwhitworth: you need to put "world" as "WORLD" in the
source
<tantek> otherwise the text-transform has no effect
<tantek> or use the actual noted example "HTML"
<zcorpan> test case
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4586
- lowercase in opera/chrome/safari
<Bert> (Seems Webkit-based browsers return the abbrev *after*
transforming to lowercase, Presto and Gecko return the
original, uppercase)
<fantasai> thanks, Bert
<tantek> sounds like webkit et al then illustrate the bug of
transforming an acronym to lowercase then
<tantek> ok I'm convinced
fantasai: If you make all small caps into text that would give you
very broken behavior. I can run a test case, but my
point is that's a case where you want the source text.
That's only appropriate where you can choose a font.
fantasai: Another use case if the Ruby transformation where if you
use full size kana and you copy it out you've lost the
distinction between small and large kana.
fantasai: When you present them as the same size it's totally
inappropriate. IF you're trying to copy just the ruby
text you change the meaning of the word in some cases.
fantasai: That's another case where text-transform shouldn't be
preserved on moving to plain text.
<Florian> to illustrate the ruby story, In Japanese "じゃ" reads
"sha", and "しや" reads "shiya". If that's your ruby, and
there can be a text-transform to turn one into the
other, because at small sizes it is hard to tell apart.
But out of context, you don't want to change the
pronunciation.
gregwhitworth: I think I want to go back to solid use cases. Where
Chris wants to preserve stuff paste as plain text.
fantasai: That's the case we're talking about.
ChrisL: We're not pasting and preserving style, It's where you're
pasting plain text.
gregwhitworth: Oh, okay.
fantasai: So far we've given four specific use cases and all of
them you want the text-transform to be dropped when
pasting to plain text. If you think it should be where
would it be more appropriate to preserve?
<dauwhe> I want the non-transformed text
fantasai: If someone thinks casing is important to preserve that
should be in the DOM. And in most cases it would be in
the DOM.
koji: I think I'm with gregwhitworth where heading case the user
expectation could be either way.
koji: When you said DOM currently the text spec says we should
apply transform. We share the plain text with [missed]
koji: We share the plain text we inner text and rendered. [missed]
Consistency there would be great.
astearns: I think I heard koji says we should have consistency
between inner text, paste to plain text, and range to
string.
<tantek> I think reasoning by specific examples trumps the
reasoning by general principles in theory. Theory is a
good place to start, but the specific examples provide
much stronger bases for conclusions.
dauwhe: This is something I run into all the time. I've wasted
half my life trying to un-capitalize things from the web.
We use the proper casing and transforms for effects but
when I paste I want the untransformed.
* BradK came in late, but agrees with what fantasai was saying,
and has long disagreed with all-caps copying based on
text-transforms.
<tantek> I agree with dauwhe, uncapitalizing things is a massive
pain
koji: It varies by how you're using pasted results. You're using
it as a source. If people want plain text to be the same the
text-transform should be applied. I think there's both cases.
Florian: I think it's tricky. In the copy/paste story there's a
million variations where you want to preserve here and
not there. I don't think we're looking at doing a million
different options. If we're saying plain text is plain
text we should keep it simple. Which is don't apply the
transform.
Florian: There are cases where you want text-transform, but this
is starting to look for where you want markdown.
<bkardell> ChrisL: the results of that on twitter so far are
surprising to me
<bkardell> Is this something that we should be consulting people
who are not in this WG?
<ChrisL> https://twitter.com/svgeesus/status/788776037098385413
<bkardell> current results on that twitter poll are almost 50-50
consistently between a) and c)
<tantek> I have yet to hear a single concrete example where
copying ALL CAPS done via text-transform actually
provides a better UX
<tantek> so that's my question to the folks advocating for that
<tantek> Where are the specific examples where applying
text-transform is *helpful* to the user?
<tantek> BTW UX design by "consistency with programming" is a
HORRIBLE way to do UX design
astearns: I'm hearing most people argue for not applying, but
there is a block of people that want consistency with
inner text or that what you see when you copy is what
you get when you paste.
astearns: I'm not hearing overwhelming consensus.
astearns: We could leave things unspecified and let the browsers
decide how to deal with this user action. That's
something the browsers can complete on giving the
experience their users want.
<Bert> (Sometimes I want to copy-paste the generated list numbers,
but not the uppercase...)
fantasai: I hear people want consistency. Authors want
consistency. I think this is a problem we want to solve.
I think tantek question to people wanting it to apply
hasn't been answered.
fantasai: He asked that the people on the other side have provided
arguments on implementation side and coding level side,
but as far as user facing examples there have not
provided a concrete example.
Florian: koji said for headings you could argue on which way users
prefer.
tantek: I think there's 2 strong examples. I think both I and
dauwhe mentioned that when you have to uncapitalize a
heading from copy it's a massive pain. I haven't heard a
single person want all caps.
astearns: What I heard from myles is users want to paste what they
see in the browser.
Florian: In what scenario? In the heading I agree with dauwhe and
tantek but I could see the other side. In the other
stories not really.
<johanneswilm> as long as there is a html version, you can always
create your own plaintext version following either
logic in the app that handles the paste. The
important part is that nothing is stripped in the
html version on copy.
tantek: I think myles principle is the right starting point. When
you dig deeper and look for specifics I think that trumps
the general principle. Data wins over theory.
dauwhe: And text-transform is lossy
tantek: Yes. If it's title case and transformed you lose
information.
dauwhe: Yes, and sometimes it's hard to restore.
koji: If you copy and preserve information as HTML it's not lost.
dauwhe: But we're talking losing meaning
dauwhe: It can sometimes take a skilled editor, at least in
English, to restore original capitalization
<ChrisL> Good point about it being lossy
<ChrisL> But also good point about plain text losing any inline
attributes, language changes, etc
koji: If author used capital for information purposes it seems
necessary
<BradK> If it is semantics, it should be in the source
dauwhe: I think that's a less common case. I don't have data, but
we see a huge number of headings. But the web has lots of
other ways of indicating emphasis.
koji: In terms of data if it's that big of a pain then 3 browsers
should have received user feedback. I don't think we have
that kind of feedback.
<tantek> perhaps we need a straw poll for copied plain text: A
ignore text-transform, B apply text-transform, C leave it
up to UA for UX decision
astearns: I'm not sure stories from people on the call that's not
what we should base it on.
<gregwhitworth> I agree with Alan
ChrisL: I put a poll on twitter.
<fantasai> ChrisL, your poll is limited in scope.
bkardell: I think it would be worth constructing a good poll with
actual examples and have everyone in the group promote
this.
bkardell: It's really interesting that so far it's been 50/50 on
Chris's poll.
fantasai: I'll point out that's the case with the most ambiguity.
Other cases we brought up you would see a much stronger
direction.
bkardell: Right, and a really good poll would capture those.
astearns: Koji asserted that the browsers not doing it have
received feedback. I'm not sure this will be a minor
bug. It might be good to look at the bug databases.
tantek: dauwhe just brought it up.
dauwhe: I'll go file bugs. It makes my life miserable.
<dauwhe> not Amazon-level misery, to be honest :)
<bkardell> but would people even open that with a browser - a lot
of people wouldn't know if that was OS level or browser
level or what
<BradK> suspects it has been reported as a bug already
<gregwhitworth> Make sure to point at the spec
<fantasai> gregwhitworth, there is no spec, that's the point
<gregwhitworth> fantasai: that was my point :)
<gregwhitworth> he can file bugs, but if there is no spec - we
won't be changing just for the sake of changing
astearns: Let's collect more data. I like the idea of a straw poll
to see what this current small group thinks at the
moment.
Florian: I have a bit of a question. When you have screen readers,
do we expect they operate on the same text basis as we're
talking at here?
tantek: They're looking at markup, so it's totally different.
astearns: Straw poll in IRC.
<astearns> copied plain text: A ignore text-transform, B apply
text-transform, C leave it up to UA for UX decision
<BradK> A
<ChrisL> A
<dauwhe> A
<fantasai> A
<Florian> A
<johanneswilm> A
<tantek> A, can live with C
<zcorpan> C
<astearns> A
<gregwhitworth> C
<fremy> C
<myles> C
<koji> B or C
<TabAtkins> C, fine with A
<Bert> C, 2nd choice A
<bkardell> A but would really like to not have a decision in this
room without a better study of people outside the room
<gsnedders> B or C
<smfr> A or C
<liam> C if the browsers might actually implement a Copy Special
(seems unlikely)
astearns: This straw polls is to get a sense of where we are. We
need additional data.
<ChrisL> @bkardell yes we need way more data from people who are
not us
<ChrisL> we can see that B was not at all popular, though
<bkardell> ChrisL indeed - that was interesting
<dauwhe> there seems to be some correlation with browser people vs
non-browser people
<Florian> dauwhe: I think this last comment of yours is worth
having on the record
astearns: It looks about 50/50 between A and C.
astearns: Lets collect more data, but at the moment I'm not seeing
a warranted spec change.
<gsnedders> I think as soon as we phrase it as involving
text-transform we're cutting out many people's
expectations
<gsnedders> And many of the people we should be listening to most
fantasai: I'd like to know who is collecting the data. If they're
talking about just headings or more cases. And I'll note
people have asked for interop. I understand C might be
great if a browser would allow a preference, but if
there isn't a preference it seems it would be good for
us to settle on an answer.
tantek: There's a preference. You switch browsers :D
<bkardell> can we take an action item for a few people to design a
post/poll that we can get feedback from the group on
before posting?
koji: I think the data is not use cases, but data from user
feedback and bug DB.
astearns: koji will look at Blink bug base.
gregwhitworth: I'm scrolling through Edge. Based on the use cases
you provided I think we should focus on things
where what I saw and pasted seems broken. Cases
that inform what the user wants. Do you want
everything I'm finding or just the specific
text-transform?
astearns: I think we should look for bugs on plain text paste.
gregwhitworth: Most of these are text format because they're going
into word. If I find it I'll share pending privacy
issues.
Florian: This is the kind of edge case because where it's not
clear if the user will be annoyed at the browser or at
where they're pasting.
<ChrisL> good point, florian
<dbaron> People are more likely to know there's something with the
browser if they see something different on paste than
they do in the browser
gregwhitworth: We're all in the same DB, so Word will give them to
us when it's us. I'm not sure about FF and Chrome,
but I suspect the word editors do share with
browsers.
tantek: I'm curious to see what gregwhitworth comes up with.
<dbaron> (I think there is a bug in bugzilla.)
Florian: I am too. But if there's nothing in the bug DB I think
this is just an indicator that this is obscure.
<zcorpan> https://bugs.chromium.org/p/chromium/issues/list?can=2&q=copy+text-transform&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids
<BradK> https://bugs.webkit.org/show_bug.cgi?id=43202
<zcorpan> https://bugs.chromium.org/p/chromium/issues/detail?id=325231
<dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=35148
tantek: This is the tip of a very large iceberg. I remember taking
up hours and hours of time 18 years ago. We won't solve it
on one telecon. I encourage people to look up bugs on copy/
paste because it'll be inconsistent a lot.
myles: I'll look at webkit bug base
astearns: Can someone look through FF bug base?
dauwhe: I guess I can look there.
<gregwhitworth> fantasai: what is the timeframe for this, I like
to put actions on my calendar and I work best with
deadlines
<fantasai> gregwhitworth: Novemberish?
fantasai: On the copy/paste topic, one of the things that should
affect plain text output is the white-space. Is anyone
arguing it should not?
astearns: Is white space a separate issue?
fantasai: It's part of the issue.
fantasai: But it could be separated out. They don't have to be the
same.
koji: I think the consistency with innerText is something JS
editors can use and innerText says apply white-space so I'm
fine to apply it.
astearns: So that's one opinion that white space collapsing should
be preserved.
<liam> +1 preserve
<liam> i.e. apply
<dauwhe> +1 apply
<Florian> no disagreement from me, apply it.
fantasai: And I agree. Does anyone disagree with preserving white
space transformation?
astearns: We could resolve that plain text pasting preserves white
space collapsing.
<tantek> AND when white-space pre-wrap etc., preserve that too
astearns: Objections?
tantek: Modification. Not just collapsing, but white space
property.
astearns: Okay, white space property is applied to plain text
paste output.
<dbaron> Is that what implementations do?
<dbaron> (or do they just always do whitespace collapsing?)
RESOLVED: White space property is applied to plain text paste
output.
koji: Which spec is this added to? Text 3 or 4?
<fantasai> CSS3 Text
astearns: 3. This is issues in test 3 DoC
dbaron: Is that what impl actually do?
<gregwhitworth> based on a quick test, Edge does keep in plain
text the white-space settings
<fantasai> FF does
astearns: Edge does.
gregwhitworth: I just tested a white-space:pre-wrap.
<gregwhitworth> https://developer.mozilla.org/en-US/docs/Web/CSS/white-space
<fantasai> Chrome also does
<koji> looks like Blink collapses
<Bert> (I think all browsers preserve white space when copied from
<pre>)
<BradK> White-space: nowrap isn't preserved, is it? It isn't in
Safari.
<fantasai> Hm, no, I think it's just the collapsing that'd be
preserved. Nowrap would involve transforming text,
which is probably not desired
<BradK> I take it back: even in plain text, nowrap is preserved.
I'm surprised.
<BradK> Nope, I fooled myself. Nowrap is not preserved in
plaintext paste from Safari.
Florian: Copy/paste code would be horrible if we didn't do that.
Florian: If you copy/paste a piece of code with line breaks in the
dom...?
gregwhitworth: As we always said we can un-resolve, but I think we
should try and do everything in this area.
myles: Webkit honors what the whitespace property describes.
tantek: Another example where we're saying the user does not get
what they're seeing is text-overflow which is speced in
CSS UI where it says selecting the ellipsis you copy the
ellipsed text. So that says text overflow doesn't effect
copy/paste of plain text.
<fantasai> tantek, I think you already have that
<tantek> https://www.w3.org/TR/css-ui-3/#propdef-text-overflow
<zcorpan> https://html.spec.whatwg.org/multipage/dom.html#the-innertext-idl-attribute
is the spec for innerText btw. "The CSS 'white-space'
processing rules are slightly modified: collapsible
spaces at the end of lines are always collapsed, but
they are only removed if the line is the last line of
the block, or it ends with a br element. Soft hyphens
should be preserved. "
astearns: I have a feeling that a number of issues with copy/paste
will be quite a bit of work to get interop. To get L3 of
text done we may punt to 4.
Florian: What tantek mentioned isn't in CSS 3 Text. Only the
copy/paste for text properties need to be defined in it.
astearns: That's fair.
astearns: In any case, I think 50 minutes is enough today.
Interaction of hanging-punctuation and kerning (Issue 122)
----------------------------------------------------------
fantasai: Question was about what happens if you have kerning
between hanging punctuation character and the subsequent
character. It's not a problem in CJK typography but
happens when you have a " and an A. Do you push the " to
hang left or do you pull it with the A?
fantasai: I don't have an answer.
dauwhe: I've been looking at this in inDesign and as far as I can
tell it has a fixed position for the hanging character and
that doesn't move regardless of the next letter, but it
will change the position of the next letter. So the A will
move somewhat but the " stays.
<liam> https://lists.w3.org/Archives/Public/www-style/2016Mar/0074.html
may be helpful here, from John Hudson
Florian: Can we action someone from Adobe to see if this is
something people are happy about?
astearns: I know this is the expected behavior from customers I've
talked to. I'm basing my intuition on the implementation
dauwhe described.
Florian: But people aren't complaining.
dauwhe: Punctuation doesn't hang entirely out, it's only about 2/3
out.
liam: Theory is you're making an optical vertical line of the
margin and the punctuation is a little fly on the edge. The
kerning brings the punctuation in a little closed to the A
is inline.
Florian: So you're saying opposite?
astearns: And the message from liam says that too.
myles: Is this a place where introp is critical? It seems that
browsers could kern differently and that's not so bad.
dauwhe: That seems plausable to me.
liam: I think impl would benefit from guidance rather than needing
interop.
myles: We don't need a resolution for guidance.
fantasai: The spec is at a point where any guidance effecting impl
needs consent of WG. Nicer examples I don't need
permission, but any guidance affects implementation.
<tantek> I think I need to see pictures.
<tantek> preferably of book typography
Florian: I'm leaning undefined in level 3.
astearns: That's where I'm leaning. Since we have opposed opinions
I don't think it makes sense to define it.
fantasai: Works for me.
dauwhe: fantasai do you want a picture of inDesign?
fantasai: Sure
<tantek> send pics to the list!
fantasai: If you would like to add illustrations to the spec
please go ahead.
Florian: Be careful of how you add the illustration if we're not
defining it.
<liam> would like to see the example
<tantek> dauwhe - perhaps post illustrations to www-style first?
astearns: So do we need a resolution saying not going to define?
Florian: I think so.
astearns: Proposed resolution: don't define interaction between
hanging punctuation and kerning and leave it up to UA to
decide how to adjust.
RESOLVED: Don't define interaction between hanging punctuation and
kerning and leave it up to UA to decide how to adjust.
Make hanging-punctuation scrollable overflow (Issue 123)
--------------------------------------------------------
fantasai: We had resolved hanging punctuation is ink overflow, he
preferred scrollable. Florian pointed out a lot of CJK
glyphs only take half the glyph space and author may
have made that ignored overflow. That half would be ink
overflow and the other half scrollable but that's weird
fantasai: We can say the hanging punctuation are scrollable but
for CJK characters that would get trimmed in text
spacing property they maybe trim at end of the line if
punctuation hanging.
Florian: If you're going this way I don't want maybe trim, I want
must. That will let the author predict if they're getting
a scrollbar.
fantasai: I think because text spacing isn't in this level of the
spec I think I would insist on a may for this level.
Florian: Should?
fantasai: The layout won't change based on this distinction other
than the presence of a scroll bar.
Florian: But having a scrollbar in some browsers is terrible.
fantasai: It's that or all of it. You can only trim in certain
fonts. Some Chinese will place punctuation in middle of
glyph. This is not a simple issue.
astearns: We're out of time. fantasai can I ask you to put your
proposal in github or on ML so we have on thing to talk
about and give people some time to take a look?
fantasai: Yep.
astearns: Okay. I think we're done for the day. Thanks everybody.
Received on Thursday, 20 October 2016 01:13:11 UTC