- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 26 Oct 2016 21:03:13 -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
---------------------------------------------
- RESOLVED: Rich text copy/paste is undefined in text level 3.
- Originally the group resolved that plain text copied to the
clipboard must (or should) not be affected by text-transform
in text 3, but there was an objection from koji so the group
will revisit next week.
Absolutely positioned boxes in inline relatives: not interoperable
------------------------------------------------------------------
- dbaron requested more time on the topic, so discussion will
continue on github
Positioning boxes with { float:left; width:0px; }
-------------------------------------------------
- RESOLVED: 0px width float that is next to a line box does count
as shortening a line box
Deal with first vs last baseline
--------------------------------
- RESOLVED: Change "baseline|last-baseline" to "[ first | last ]?
baseline"
Initial value of mask-repeat and mask-position
----------------------------------------------
- RESOLVED: Match webkit/blink behavior for initial value of
mask-repeat and mask-position
- RESOLVED: ChrisL, TabAtkins, and shane as editors for masking
spec.
Hoisting things to table wrappers
---------------------------------
- RESOLVED: Add hoisting of listed properties
(https://drafts.csswg.org/css-transforms/#grouping-property-values)
other than overflow.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Oct/0126.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Alex Critchfield
Tantek Çelik
Dave Cramer
Elika Etemad (IRC only for part of the call)
Simon Fraser
Tony Graham
Koji Ishii
Dael Jackson
Brad Kemper
Vladimir Levantovsky
Chris Lilley
Peter Linss
Simon Pieters
Liam Quin
François Remy
Florian Rivoal
Alan Stearns
Lea Verou
Johannes Wilm
Regrets:
Daniel Glazman
Michael Miller
Anton Prowse
Jen Simmons
Greg Whitworth
Scribe: dael
Define effect of text-transform on copy/paste
---------------------------------------------
Rossen: Let's get going.
Rossen: As usual, any additional agenda items?
<dauwhe> https://github.com/w3c/csswg-drafts/issues/627
Rossen: There were a couple of topics linked to the same issue
last week.
Rossen: I wasn't on the call, but there was a bunch of discussion
on this already. There were requests for data gathering
which we did on our end and hopefully others did too.
Rossen: This idea is to box this discussion to 5 minutes. We could
stretch to 7 if needed. We want to get to the bottom of
this. If there's nothing we can get out of this that's a
strong signal as well.
Rossen: In my e-mail I asked the people with strong feelings to
have a quick summary of their proposal
Rossen: I know fantasai is only on IRC so I'll try and allow her
to get in her proposed behavior.
<tantek> I still have the opinion that text-transform should be
IGNORED for plain text copy/paste.
Rossen: In the meantime is there anyone with something new or
concrete?
<fantasai> I agree with Tantek and Florian, obviously.
<fantasai> The proposed behavior is that rich text copy/paste is
not defined
<fantasai> And in the absence of the user's explicit direction to
the contrary (through some kind of option or variant
abilities), text-transform is ignored.
johanneswilm: I talked to 5 editor projects and they had various
opinions on plain text. In Chrome text-transform is
also on HTML version which is highly problematic for
at least 4 projects because one can't make a
different plain text version. Otherwise what plain
text does isn't that important because you can
create a different plain text version using the html
version.
<tantek> the fact that text-transform is applied in Chrome for the
HTML copy/paste makes it seem like it's a side-effect of
the code, not a deliberate design, as that seems like an
obvious bug.
<tantek> and thus undesirable
<tantek> I think Chrome is buggy here - is there a bug filed on
this?
Rossen: Do you have any proposed behavior to define or is this
just a summary?
johanneswilm: Proposed is for the html version to not apply
text-transform and keep it in a style. It's changing
the HTML structure and so there's no way you can get
original text.
<fantasai> +1 johanneswilm
Rossen: I'm going to real-time try and rephrase fantasai.
Rossen: [reads]
Rossen: So fantasai tantek and Florian propose we leave this
undefined
Rossen: I'll also +1 on that.
tantek: Just one clarification. I'm okay undefined for HTML but
for plain text we should state text-transform should be
ignored.
tantek: Follow-up for johanneswilm: that seems like an obvious
bug. Is there a bug filed on that and, if not, can you
file a bug on Chrome? Because that doesn't seem
deliberate. It seems an error
johanneswilm: I haven't looked for bugs, but I can file if there
isn't one.
* bradk wonders if there is a reason/limitation that causes Chrome
to do that.
tantek: I think filing the bug would help.
Florian: I still agree with the previous, but I want to raise a
github possibility. The idea would be treating rendering
into plain text as a separate media and have a MQ for
that.
<fantasai> Florian, I think that level of complexity atm is not
necessary :)
<tantek> +1 fantasai
Florian: You would say text-transform is technically applied but
you could have an @media clipboard that does
text-transform none but the editors could indicate when
something is important. I'm not sure I have an opinion.
Rossen: That's a good discussion for MQ. WE should have the
conversation there. Having the sync around that may be
overkill in my opinion.
<bradk> @media clipboard { body{ display:none; }}
<fantasai> Florian, It could be interesting, but I think rarely
used. It won't interact properly with the cascade since
we want the default behavior to be a set of UA-defined
behavior.
<fantasai> Florian, so I'm against going in that direction.
<fantasai> (the MQ direction)
Rossen: It sounds like there is growing consensus on undefined
which makes these conversations moot.
<tantek> where is the consensus on undefined for plain text?
Florian: There's not consensus on undefined.
Rossen: We can ask for consensus.
Florian: For defining rich text there's consensus for undefined.
For plain text koji pushed undefined, lots of people not
caring, and a bunch of us pushing to define it.
tantek: Yes.
<tantek> I agree with Florian's summary
<tantek> that seems like an accurate assessment of the current
situation
Rossen: So we have 2 proposed resolutions. 1) leave it undefined.
2) define plain text unaffected by text-transform. Fair
summary?
Florian: What's the 'it' undefined. Rich text?
Rossen: Correct.
Rossen: [pauses for fantasai comments]
<fantasai> Proposal 3: make it SHOULD rather than must ;)
<tantek> I can live with SHOULD (yuck)
<astearns> I could live with SHOULD
<tantek> I would prefer MUST IGNORE
<tantek> MUST > SHOULD > undefined
<fantasai> Then people who for some reason think it gives a better
result can do something "with deliberate consideration
of the consequences" or whatever it was RFC2119 defined
<fantasai> But otherwise they have to ignore.
<fantasai> So any UA that wants to ignore the SHOULD needs to
submit an essay instead of a passing test result ;)
Florian: I could live with should but I'm not sure it helps. We're
trying to go for interop. A should just lets browser do
what they currently do.
Rossen: If we can get 2 impl to agree on this we'll be fine.
<fremy> at Rossen, fantasai: plain text is affected by
text-transform in Microsoft Word (copy from Word to
Notepad)
<johanneswilm> notice that at least word (?) and some of the
webbased editors create their own plaintext version
based on the html version.
Rossen: We have proposed resolution: leave rich text undefined and
define text-transforms should not effect plain text on the
clipboard
Florian: There's a bunch of people who can live with should but I
think they prefer must. Can anyone not live with must?
<tantek> +1 MUST IGNORE, +0 SHOULD IGNORE, -1 undefined
<bradk> Must +1
<Florian> +1 MUST IGNORE, -1 SHOULD IGNORE, -13.5 undefined
<fremy> -1
<liam> +1 should, -1 must for text
Rossen: From reading minutes I think there were people that felt
stronger...maybe Apple? I want to hear from them.
smfr: I think that was myles and I disagree so Apple isn't
cohesive.
myles: I'll defer to smfr.
Rossen: So proposed resolution: rich text is undefined in text
level 3.
Rossen: Objections?
RESOLVED: Rich text is undefined in text level 3.
<fantasai> Rossen, I think johanneswilm's point that HTML paste
shouldn't transform the text
<fantasai> is valid
<fantasai> We shouldn't define how styles are kept or not
<fantasai> but that's an issue.
<fantasai> The underlying text shouldn't be converted for HTML
paste
Rossen: Proposal: plain text copied to the clipboard must not be
affected by text-transform in text 3
<tantek> +1
RESOLVED: plain text copied to the clipboard must not be affected
by text-transform in text 3
Rossen: Is the next topic fantasai's?
<fantasai> defer pls
Florian: Didn't we close last time on this with waiting on a
concrete proposal from fantasai?
koji: I don't think it's a good idea to define plain text.
Rossen: koji are you saying you didn't hear proposal about copy/
paste?
koji: Yes.
Rossen: We resolved that the rich text is undefined in text level
3.
koji: Fine with me.
Rossen: Plain text is defined that text-transforms must not effect
plain text.
koji: I'd like that undefined.
Rossen: Are you objecting?
koji: Yes.
koji: Last week in straw poll it was half and half.
Rossen: This week you're the only one not okay with it.
Rossen: Apple has changed their mind since then.
koji: I saw myles defer to smfr. smfr said something?
smfr: I tested and our current behavior is respect text-transform
when copy/paste plain text. So I'm less convinced.
<tantek> smfr, we knew that already as legacy behavior in Webkit,
but as an accident, not deliberate design
<tantek> smfr, would you consider fixing this?
<johanneswilm> And apparently we all agree that Chrome changing
the html structure and directly applying
text-transform is just a bug and doesn't require
the decision by us?
<tantek> johanneswilm, certainly you got consensus on that from
the editor makers, so mention that in the bug. You can
cite these logs too.
<johanneswilm> ok
Florian: So are we back on should not?
smfr: I'd prefer not a must.
Rossen: I can live with should.
koji: So smfr you said you respect but you'd be okay to change?
smfr: We respect text-transform now. I don't know if we're okay to
change I'd have to talk to other people.
koji: Proposal is must not.
Rossen: Yes and we're proposing to make it should not.
Rossen: So koji can you live with that resolution?
koji: I need to go back to the team and discuss.
Rossen: Would you object to should not? You can come back next
week and discuss if you still feel it should be undefined.
Rossen: Current consensus is around should not which gives you a
way out of the behavior.
<tantek> also, would prefer that more discussion require new data
on this
<bradk> Should be at least SHOULD
koji: So apple is going to change?
Rossen: Nobody is asking you to change anything at the moment.
koji: hum.
Rossen: Let's try this one more time. Proposed resolution is text
level 3 defines that plain text copied to the clipboard
should not be effected by text-transform
koji: I object.
Rossen: Okay.
Rossen: So let's record the objection and we'll revisit next week.
<tantek> if koji is objecting to both MUST and SHOULD, then we
might as well resolve on the MUST
<tantek> since the consensus is equivalent
<fantasai> koji, when you go back to talk to your team about
text-transform and copy/paste, please send them links
to both
https://lists.w3.org/Archives/Public/public-editing-tf/2016Apr/0005.html
and
https://lists.w3.org/Archives/Public/www-style/2016Oct/0115.html ?
Make hanging-punctuation scrollable overflow
--------------------------------------------
Florian: fantasai said on IRC we should defer. And we said last
time we should defer until she writes a proposal.
Absolutely positioned boxes in inline relatives: not interoperable
------------------------------------------------------------------
<Rossen> https://github.com/w3c/csswg-drafts/issues/609
Rossen: fremy could you rejoin the call?
fremy: Yes, I'm here.
fremy: The issue is simple. When you have an inline box that
tracks across 2 lines and you said position: relative it's
not defined which anchor you should use in CSS 2.
fremy: This changed in position 3. It's not what Edge and Chrome
implement. In ltr we match so I was asking if we can change
the spec and do the same thing in reverse for rtl.
dbaron: You mentioned Edge and Chrome [missed]
fremy: I guess Safari is doing same.
dbaron: Gecko?
<smfr> github says “ltr: Firefox considers "bottom" and "right" to
be the bottom/right of the first fragment.”
ChrisL: Gecko does the right thing.
fremy: It's not as defined in position 3 either. From my notes
Firefox considers bottom right to be bottom right of first
fragment. Spec requires you to have bottom right to be of
second fragment. Chrome/Edge does right to be left of first
fragment.
fremy: I think it's fine to say we have interop and we follow this.
* bradk thinks gecko behavior sounds much better
dbaron: So right is based on left edge of first fragment?
fremy: Yes.
dbaron: That's strange
TabAtkins: I agree.
dbaron: About the test cases you should separately test if the
right of the last fragment is the right of the left of the
first fragment or the left of the left of the first
fragment.
fremy: Test cases were conclusive. I'm fine leaving spec as-is.
dbaron: I'd like more time on this.
fremy: Okay. Let's defer to next week.
dbaron: I won't be on for next two weeks. Maybe we can continue on
github.
Rossen: Let's take it back to github.
fremy: Yep. Let's do that.
Positioning boxes with { float:left; width:0px; }
-------------------------------------------------
<Rossen> https://github.com/w3c/csswg-drafts/issues/576
Rossen: Who added this?
fremy: Probably me.
TabAtkins: astearns put it back on.
Rossen: Is it close? Do we need discussion?
fremy: We need to resolve. Last time we concluded but people
wanted more time to review. We said if you have 0px floats
it's shortening the line so you wrap to the next line.
fremy: If people are fine we can resolve.
TabAtkins: This means if you have an inline that exactly fills
space a 0px float stays. If it's larger the float wraps?
fremy: Yes.
TabAtkins: Perfect. I agree.
Rossen: Which test case in github is an example of what you just
described?
fremy: First 2.
Rossen: Both I see interoperability.
<tantek> is this bugwards / accidental interop? or deliberate?
fremy: You must be on a different Edge version..
Rossen: 0px floats cannot fit in a 0px available width?
fremy: It's when you have a negative avail width. If your line
already overflows you're on the next line.
Rossen: I'm fine with it.
<dbaron> these testcases are complicated enough that I'm not
incredibly confident that we're even discussing the right
issue to cover the testcases
<tantek> agreed with dbaron
Rossen: Objections to defining that floats in an over-constrained
scenario drop to the next line?
dbaron: That's not really the resolution.
Rossen: No? That's what I heard.
dbaron: The issue is about if the inlines are pushed down. It's a
0 width float constitutes a float that shortens the
linebox.
Rossen: I can live with that as well.
TabAtkins: That's if the float is before. If the float is after
it's pushed down.
Rossen: Correct.
fremy: Yes.
Rossen: How is the 0px width any significance?
TabAtkins: Because 0px don't take space. You can always cram them
onto a line without making it worse.
dbaron: We should be very careful, but the reason I thought it was
is because the spec says "if a float shortens the linebox"
A 0px width float counts as a float shortening the
linebox. I believe that's the clarification.
TabAtkins: I think so. I think that's the actual spec change.
fremy: I think that's it. A 0px float is shortening the line box.
Rossen: Okay. I can live with this behavior
<fantasai> Proposal for hanging-punctuation is,
hanging-punctuation is scrollable overflow. UAs *may*
trim the blank half of overflowing CJK punctuation that
takes up 1ic but only has ink on the inner half. (This
will have no effect on rendering but may affect the
scrollable area.)
dbaron: Specifically 0px width. Not height.
TabAtkins: It's the same as flexbox. If you have a 0px flexbox and
a really big thing, the really big wraps. If you
reverse the big stays and the 0 wraps.
TabAtkins: Flexbox spec is explicit about this. Float is less. It
gives you constraints. Flexbox should be interoperable
on that because it has an algorithm that says do this
thing.
Rossen: Okay.
Rossen: dbaron can you summarize proposal one more time?
dbaron: Proposed resolution: 0px width float that is next to a
line box does count as shortening a line box
Rossen: Objections?
fremy: It's fine.
RESOLVED: 0px width float that is next to a line box does count as
shortening a line box
Deal with first vs last baseline
--------------------------------
<Rossen> https://github.com/w3c/csswg-drafts/issues/210
TabAtkins: I believe this was raised by fantasai.
Rossen: Given that she's not on the call...
Rossen: We can postpone in the call or next week
Rossen: So she doesn't have to write.
<fantasai> I can call in 2 min
Rossen: Are there any issues that aren't fantasai's?
Initial value of mask-repeat and mask-position
----------------------------------------------
<Rossen> https://github.com/w3c/csswg-drafts/issues/599
dbaron: At some point we resolved that mask-repeat and
mask-position have different initial values than
background. It's not compat with webkit-mask-repeat and
webkit-mask-position. There's a bunch of web content that
depends on the values. We've had what the spec says in FF.
dbaron: We've gotten some of the sites to fix the behavior. We do
still have compat problems.
dbaron: Question is; we're close to rolling back and doing same
initial values as background-position.
dbaron: In the chromium bug there was a suggestion that we behave
different for prefix and unprefix though it's not clear to
me how you do that. If everyone uses shorthand maybe
webkit-mask shorthand would specify different values. I
don't have data on shorthand usage.
dbaron: We're having enough compat problems we're likely to roll
back.
Rossen: Any other opinions?
TabAtkins: We're for keeping spec as-is. Though twitter fixed it
there's likely other stuff around. no-repeat is a
better value in isolation in mask, masking for similar
properties makes sense too. I'm fine changing spec to
match Chrome behavior.
Rossen: Any objections to matching webkit/blink behavior and
record that into the spec?
fantasai: Do we have a editor?
TabAtkins: Kinda? krit is technically the editor but shane and I
will do edits.
fantasai: There were some other issues with masking that I'm
guessing isn't edited in. They may be on stats page. We
need an active editor for masking.
<ChrisL> agree we need an active editor for masking
Rossen: That's a great point.
RESOLVED: match webkit/blink behavior
Rossen: Next we need official editors. I heard TabAtkins and shane
stepping in. Yes?
TabAtkins: Yep.
<krit> I would welcome another active editor on mask
Rossen: Anyone else want to be an editor?
ChrisL: TabAtkins you edit an awful lot of specs.
ChrisL: Applying TabAtkins doesn't necessarily increase output.
TabAtkins: Which is why we're adding shane as well.
ChrisL: This is graphics-y. I'd be interested.
Rossen: Okay, so ChrisL TabAtkins and shane as editors for masking
spec?
RESOLVED: ChrisL, TabAtkins, and shane as editors for masking spec.
Rossen: That means you guys get to do all the actions and
resolutions retroactively.
Deal with first vs last baseline
--------------------------------
fantasai: I don't know if there's been progress.
fantasai: We discussed a couple of months ago. There's no comments
on github.
fantasai: I have a slight preference for separate keywords but I
haven't thought deeply.
fantasai: Or if it should be incorporated into which baseline do
we care about. That's the bigger issue. For inline we
have several prop for controlling layout. Which baseline
and how much do you shift. We can incorporate first/last
into which baseline we use as a spec keyword or it's an
independent control.
fantasai: I haven't thought deeply. Another opinion would be
useful.
fremy: I like the idea of an independent property. I didn't think
much further, but I like being able to say I care about the
first or the last.
Rossen: Did anyone else look or can add anything to the discussion?
Rossen: The way I hear it is it's a call for attention and we want
to make progress?
fantasai: Given what I've heard I'd propose going forward for
alignment property in box alignment to take away the
hyphens so that first vs last baseline is distinguished
with an keyword. In alignment add new property with
first|last|auto.
fantasai: Spec that and review and see if we want that since that
part of align isn't as close to done.
fantasai: Does that sound reasonable?
dbaron: Why do you want to remove the hyphen?
fantasai: Consistency with vertical align which doesn't have
hyphens.
TabAtkins: Note that means replacing with a space, not smuching
together.
dbaron: Which seems weird since it's a single value.
fantasai: Kinda. In most cases you want baseline alignment but you
can choose first or last. Current is baseline for first
and last-baseline for last.
<Rossen> baseline | last-baseline
<TabAtkins> Current is "baseline | last-baseline". Proposed is
"[ first | last ]? baseline"
fantasai: Current baseline|last-baseline. Proposed is [ first |
last ]? baseline
fantasai: This is for consistency in terms of hyphenation. Even if
we choose to incorporate into which baseline do I care
about there's 5 options there so we wouldn't want a
hyphen there. In either case in the inline module we
want to not have a hyphen there.
fantasai: So for consistency in the box alignment we'd drop the
hyphen so authors don't have to remember. You can do
first|last or leave it off which implies first.
* bradk likes the proposed change
dbaron: I'm okay if it's first followed by baseline and not
anything in the middle.
fantasai: Immediately adjacent would be the requirement.
Rossen: I see some people like this. I don't hear push back. Do
you want a resolution?
fantasai: Let's record one and we can close off box alignment
issues. We'll revisit is first and last should be
independent or merge, but we're leaning independent.
Rossen: Objections?
RESOLVED: Change to [ first | last ]? baseline
fantasai: TabAtkins can you make the edits?
TabAtkins: Yes.
Hoisting things to table wrappers
---------------------------------
<Rossen> https://github.com/w3c/csswg-drafts/issues/324#issuecomment-235652352
Rossen: Who wants this?
astearns: This was left over from TPAC.
astearns: There were a list of properties Simon thought we should
add to the list getting hoisted?
fremy: Yes. I'm fine as the editor with changing this, but I'd
prefer saying the caption is inside the table box.
fantasai: It's not. We cannot do that.
fremy: I can.
fantasai: Width border and background apply to a box. Caption is
not inside that.
fremy: That's a discussion we should have apart.
fremy: For me this issue doesn't make sense. I have no strong
opinions. These properties should just work.
Rossen: What do you mean by "this property"
fremy: Opacity is resolved. They want to resolve on all the
transforms properties.
fremy: The list is overflow, opacity, filter, clip, mask, blend
modes and transforms.
fremy: So if you apply on table they effect the caption.
Rossen: Okay. Is there a problem with that?
fremy: No. It's just not how it works at this point.
fantasai: I'm not sure about overflow but others make sense.
Rossen: Overflow. So if you set overflow scroll on the table it
should affect the caption?
fremy: Proposal is to have the property apply on table wrapper
box. I didn't think much about overflow. Let's say all but
overflow.
Rossen: Yes. Overflow on table is all over the place in terms of
impl.
fremy: Okay then we can say overflow should apply.
fantasai: I think I would hesitate to put overflow on the list
Rossen: Why?
fantasai: You can't overflow the table wrapper box because it's
defined to be as big as contents. I guess you could. It
would be really weird if there were scrollbars not
connected to an actual box.
fantasai: It seems a weird case. I don't know if overflow applies
to tables.
Rossen: In some implementation it does. There's close to not
interop.
fantasai: I'd say no overflow on tables. I think it is currently
defined as may be for table row groups.
fantasai: In any case, I would hesitate to hoist the overflow
property.
fantasai: Have the scroller inside the table
Rossen: I wouldn't mind leaving overflow out for now.
fremy: Let's.
<Bert> (http://www.w3.org/TR/CSS22/visufx.html#overflow says
overflow applies to "boxes that establish a formatting
context" and tables *do* establish a f. context.)
Rossen: Proposed resolution is accept the list minus the overflow
property.
fantasai: The one down side to hoisting these is coordinate system
is less predictable. Upside is most of the time you'd
expect it to apply to caption.
fantasai: I think that's the trade off.
Rossen: Right.
Rossen: Do we have any indication of what current impl do?
fremy: It's not my issue. So unless there's something in the issue
I don't know.
dbaron: Gecko hoists transform but I don't think the others.
dbaron: Rossen you read a list that I don't see
<Rossen> https://drafts.csswg.org/css-transforms/#grouping-property-values
[List is:
overflow: any value other than visible.
opacity: any value less than 1.
filter: any value other than none.
clip: any value other than auto.
clip-path: any value other than none.
isolation: used value of isolate.
mask-image: any value other than none.
mask-border-source: any value other than none.
mix-blend-mode: any value other than normal.
]
Rossen: They're out of the spec ^
dbaron: Ah, okay.
Rossen: We're out of time.
Rossen: In terms of table I don't think any implementation is
trying to change tables. We're looking for interop. We
shouldn't define new behaviors for spec purity. Going
back...are we ready to resolve or should we push it off?
Rossen: Objections?
Rossen: To adding hoisting of listed properties other than
overflow?
RESOLVED: Add hoisting of listed properties
(https://drafts.csswg.org/css-transforms/#grouping-property-values)
other than overflow.
Rossen: hiroshi sent an e-mail about the April F2F dates
fantasai: Should we buy tickets?
Rossen: As soon as he says the space is reserved.
fantasai: Thank you.
Rossen: Thanks very much!
Received on Thursday, 27 October 2016 01:04:18 UTC