-
astearns
trackbot, start meeting
-
» trackbot is preparing a teleconference.
-
RRSAgent
-
trackbot
RRSAgent, make logs public
-
RRSAgent
I have made the request, trackbot
-
trackbot
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
-
trackbot
Date: 17 July 2019
-
smfr
present+
-
Rossen_
present_
-
Rossen_
present+
-
astearns
present+
-
dael
present+
-
plinss
present+
-
dael
ScribeNick: dael
-
gregwhitworth
present+
-
jensimmons
present+
-
rachelandrew
present+
-
» fantasai present+
-
AmeliaBR
present+
-
cbiesinger
present+
-
melanierichards
present+
-
antonp
Present+ antonp
-
dael
astearns: Looks like almost enough people. We'll wait another minute or so
-
fantasai
ACTION fantasai Send out publication announcements...
-
» trackbot is creating a new ACTION.
-
trackbot
Created ACTION-882 - Send out publication announcements... [on Elika Etemad - due 2019-07-24].
-
dael
astearns: We should get started
-
bradk
Happy world emoji day
-
dael
astearns: Anything to add or change about the agenda?
-
» florian fantasai if you run into an announcement I was supposed to do but didn't, please let me know.
-
dael
-
dael
astearns: Particularly is myles on?
-
dael
astearns: Lets skip until we get myles
-
dael
Topic: text-decoration-width claims to be a sub-property of text-decoration, but text-decoration disagrees.
-
dael
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #3993 ([css-text-decor] text-decoration-width claims to be a sub-property of text-decoration, but text-decoration disagrees.).
-
dael
astearns: emilio added this and fantasai commented.
-
dael
astearns: Anything we need to do?
-
» emilio omw, sorry
-
dael
fantasai: Not unless someone disagrees with making it a sub property
-
» fantasai is waiting for things to load
-
bradk
๎ ๐ ๐
-
» TabAtkins present on IRC, can't call in today
-
dael
astearns: I have not read through the text. Is there a spec change?
-
emilio
astearns: I'm fine with fantasai's comment, updating the spec would be nice
-
bradk
present+
-
dbaron
Present+
-
dael
fantasai: Hang up is text-decor L3 text isn't folded into L4. I need to cross check before I copy over and merge in. L4 is basically a diff spec atm
-
drousso
present+
-
dael
astearns: So we'll close this as soon as you cross check and poss. update spec
-
dael
fantasai: Yeah
-
dael
astearns: Any disagreement with that course of action?
-
dael
??: nope
-
dael
astearns: Let's leave it at that.
-
dael
Topic: pre-wrap and tabs at the end of the line
-
-
dael
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #3869 ([css-text] pre-wrap and tabs at the end of the line).
-
dael
astearns: florian added example
-
» myles_ astearns i'm here now
-
» astearns thanks myles_
-
dael
florian: 2 parts to the discussion. one is hardly discussed and non-controversial. Other was and needed example
-
dael
florian: The hardly discussed is just like spaces tabs do not hang and you can break between. Mentioned in issue and no one pushed back.
-
dael
florian: I'd like to resolve on that before going to whitespace prewrap
-
dael
astearns: Treat tabs the same as issues for this?
-
emilio
present+
-
fantasai
for break-spaces, right?
-
dael
florian: They can't hang and you can wrap between two consecutive tabs
-
dael
astearns: Tabs do not hang and you can break between for whitespace: break spaces
-
dael
astearns: Objections?
-
fantasai
s/break spaces/break-spaces/
-
dael
RESOLVED: Tabs do not hang and you can break between for whitespace: break-spaces
-
fantasai
s/whitespace/white-space/
-
dael
florian: Now what happens with tabs at end of line with whitespace-prewrap
-
» fantasai :)
-
dael
florian: Example in document with line empty with tabs at end. What happens if line is too short?
-
dael
florian: First is what line is long enough, second is when tab hangs.
-
dael
florian: If you disallow hanging and disallow breaking between tabs you get second rendoring. 3rd is disallow hanging but allow breaking between tabs. No one does 3rd, browsers are split between first 2.
-
dael
florian: I don't have a strong preference. Weak for option 3 which no one does. But we should try and align on something. Would want to hear if anyone has preference.
-
nigel
Present+ Nigel
-
dael
florian: Questions on example? Thoughts on why one is preferable?
-
dael
astearns: I don't have much of a preference. Not sure the 3rd is preferable either
-
dael
astearns: I don't know why you have weak preference for that
-
dael
dbaron: Drawing in example assumes tab stop lines up with end of container.
-
dael
florian: I could be a different length, that's correct. I have a line length of 16 in this example. If you did 17 for example line breaking position wouldn't change in any example but you'd have empty space at end of it.
-
dael
fantasai: Only difference visually is container is slight wider, but otherwise render same
-
dael
dbaron: Complexity with not line up is you would also have to decide if can break in middle of tab
-
tantek
present+
-
dael
florian: I assumed you could not, but fair enough. it renders as a shift not a character.
-
dael
dbaron: You'd have to decide if you have tab stop at beginning/end of line. If you don't you can break in middle of tab. If you don't have tab stop and your next position is early in next line but not start; I guess it doesn't matter if tab is on first line or part on each line
-
dael
fantasai: Tab stop is at beginning of line, but not end of line unless lines up with a multiple of 8 spaces from start of the line
-
» tantek RRSAgent, pointer?
-
-
dael
florian: If we don't have a use case driven preference we can ask the web author folks to fish for one. We have split between browsers now. We can ask who is easier to change.
-
dael
florian: Going by use case would be better. Haven't ID'ed any. Should we draw in rachelandrew or jensimmons ?
-
dael
dbaron: THis feel obsure to me.
-
dael
florian: it does
-
dael
astearns: Could resolve on behavior 1 since we have 2 engines doing it
-
dael
florian: Yeah...not particular reason to think behavior 1 is terrible so I'm okay with that. It is similar to what happens to spaces in white-space:pre-wrap. That implies FF has to change.
-
dael
dbaron: I think consistancy with spaces is reasonable thing. I don't have strong opinions.
-
dael
florian: Suspect any impl difficulty?
-
dael
dbaron: Hard to say
-
dael
astearns: Main difficulty is reason to make the change. I could just be a bug in FF forever
-
tantek
is there any way to apply the principle of least surprise here?
-
tantek
all other things being equal?
-
dael
myles_: Engines have special case for tabs. IT'll be a slightly smaller or larger special case then it would have been. Picking an option is more important then which
-
dael
florian: And as to the point about no rush to fix I think this will be low in priority, but there will eventually be a lump of bugs to fix and this will be in.
-
dael
astearns: tantek asked in IRC: [reads]. One of the problems is no one has strong opinion on actual expectation
-
dael
florian: Being consistent with spaces goes slightly to least surprise. If you know one you know the other
-
dael
astearns: Sounds like we are driving toward a preference for the first option since consistent with spaces
-
dael
florian: Right, the tabs hang
-
dael
astearns: In which?
-
dael
astearns: Prop: for white-space:pre-wrap tabs hang like spaces do
-
dael
astearns: Objections?
-
tantek
that seems reasonable and less noisy (random tabs/ws at end of line won't change layout)
-
dael
RESOLVED: For white-space:pre-wrap tabs hang like spaces do
-
dael
Topic: Limits on text-underline-offset to preserve semantic meaning
-
-
dael
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #4059 ([css-text-decor] Limits on text-underline-offset to preserve semantic meaning).
-
dael
astearns: Discussed this, what, last week? Been more discussion in GH. jensimmons gave 3 options
-
dael
astearns: 1. Don't do any clamping. 2. Wide clamp 3. Narrow clamp
-
dael
astearns: Any additional information to add?
-
» florian opinions yes, but nothing new
-
dael
astearns: From my pov we shouldn't have a clamp at all. Whatever clamp we choose might be difficult to come at an interop consensus as to what it should be. I am not concerned with semantic implications of moving an underline.
-
dael
astearns: Agree we should have these offsets for strikethrough and overline as well
-
florian
+1 to astearns
-
TabAtkins
1
-
dael
astearns: I think that's an arguement to add more offset properties and not clamping any
-
dael
??: I agree
-
TabAtkins
+1, rather
-
bradk
s/??/bradk
-
fantasai
I'm against the narrow clamping definition.
-
dael
florian: One nuance. If there are impl difficulties having an allowance for clamping for the reason of not painint many pages away I would accept that. Not go any further then that.
-
dael
smfr: If you don't clamp do you allow underline to be clipped out? So UA must paint howeevr far or is it okay to not paint if it's "too far away". If you don't clamp need to say if can do clipping
-
bradk
Ink overflow only.
-
dael
florian: Do we expect impl to be more difficult to put underline 3000 px away?
-
dael
smfr: More difficult for text decor
-
dael
myles_: Performance hit where any part of page changes have to redraw entire paragragh
-
dael
AmeliaBR: True for things like box shadows
-
dael
myles_: Unfortunate there too
-
dael
AmeliaBR: Shouldn't have special rules for this. SHould have general rule for at point you can reasonably clip
-
dael
myles_: Have webcompat for others. THis is new so can change
-
dael
jensimmons: Sounds to me this is an argument for a wide clamp. TO smfr point I meant any obstruction of author ability to put underline where they thought. A clip or a clamp is a level of sophestication we haven't reached.
-
dael
florian: If you're going to limit it should be clamp rather then clipping.
-
dael
florian: I would go for wide clamp or no clamp
-
dael
Rossen_: Sounds like discussing merit of feature again. There was good consensus last time we wanted clamping
-
dael
florian: no
-
florian
I don't think there was emerging consensus
-
dael
Rossen_: And also of the opinion that if we don't have clampping of offset then any other impl that do underline-offset will have fairly different semantic meanings as to where they'll draw underline or one that looks like a strikethrough.
-
dael
Rossen_: For a new feature we have control over we have a chance to make it right.
-
dael
Rossen_: If there are use cases to pay around with a background in the middle of the line box, use the striketrhough. If that's not good enough use a background. CHanging underline and allowing it to escape to be a strikethrough is bad from many PoV. Esp. for impl that don't have it. Having poor fallback is not a good idea
-
jensimmons
q+
-
» Zakim sees jensimmons on the speaker queue
-
dael
florian: I disagree it's poor. If you design an underline in such a way that it's thick and shifted up it's reasonable for the fallabck to be a normal underline. Argues for no local clamping. Wide is different.
-
bradk
Strike though cannot be a background because it is in front of the text
-
tantek
Why are *under*lines not drawn *under* the text (layerwise), so they can't actually strike-through? (they could strike-under?)
-
dael
jensimmons: What I'm hearing Rossen_ is an argument for narrow clamp. I don't htink we've had consensus. After call esp hearing more and more no clamp. We can keep trying to articulate reasons, btu I haven't heard lack of consensus of the reasons for each. I've hear arguments as to why each is a good idea. I don't think there is consensus
-
fantasai
tantek, they are drawn under the text
-
florian
tantek: they are
-
fantasai
tantek, and strike-throughs are drawn over
-
florian
s/tantek:/tantek,/
-
dael
jensimmons: Personally I prefer no clamp. Okay with wide clamp if it's for performance. narrow is much harder and we don't have to prevent authors from doing dumb things. We should pick which of the 3 and discuss details
-
dael
myles_: Maybe comprimise is wide clamp. b/c wide spec can just recommend a general idea of where to put it.
-
jensimmons
+1 for what Myels jsut said
-
jensimmons
*Myles just
-
fantasai
s/Myels/Myles/
-
dael
astearns: Another way of casting narrow vs wide is narrow is for semantic argument to keep underline and underline and not mistaken for anything else. Wide is for perfromance reasons but not semantic. Is that correct?
-
dael
fantasai: yes
-
dael
florian: That's how I understan
-
tantek
thanks fantasai, then I'm not as worried about underline abuse, cosmetically, semantically or otherwise
-
bradk
<u> is semantic. *-decoration is not
-
florian
+1 to tantek and to bradk
-
fantasai
Specific proposal for wide clamp: within the larger of 2 x max(line-box-height, font-height)
-
dael
Rossen_: I think first is characterized well. Second is a little unfair. Impl will become more complex for unknown reasons. Performance will be potentially impacted. Having to go in and validate and keep validation out of current bounds for overflowing underlines is not great. I would say both impl and performance
-
dael
astearns: To move discussion, can we resolve not to add a clamp to this property for mearly semantic reasons. Would anyone like to argue for narrow clamp to satisfy semantic concerns?
-
fantasai
+1 to bradk
-
dbaron
Implementations already need to keep track of underlines for overflow.
-
tantek
I wonder if there are some math related display hacks we could do with underlines far from their text
-
» fantasai suggests a straw poll
-
dael
Rossen_: I would be willing to continue to argue this. I would want to hear from other groups on this issue, including a11y
-
dael
astearns: I wonder if makes sens eto break issue into 2 concerns. There are separate arguments for each.
-
dael
astearns: Is there anyone besides Rossen_ who is up to argue for semantic concerns?
-
tantek
this is still WD right? why not put the issue in the text as a question linking to the issue and leave the presence/absence of clamping open til we have more implementations?
-
astearns
tantek: we are getting a second implementation now, so we can't punt
-
fantasai
tantek, we have implementations
-
dael
myles_: Our original purpose was this. THere's a diff between existing prop and this new property. You could never draw a text shadow and not move it. But you can draw an underline and not move it. Semantic is a11y but also if you view new website in old browser it will look totally different. I don't think that's a concern for existing css properties
-
tantek
I feel like we can punt a bit longer until Chrome intents to implement, or have we seen that already?
-
dael
fantasai: If you as an author want fallback for this underline to be no underline you can do that. If you want fallback to look regular you can do that. Both are possible
-
dael
myles_: Authors have to think about that and add code
-
dael
florian: To disappear yes
-
dael
bradk: Have to think about that for any new
-
dael
jensimmons: Fallback is natural and makes sense. If you're doing fancy in a new browser your fallback is a normal browser. I don't see it as complex, it seems natural from author PoV
-
bradk
+1 jensimmons
-
fantasai
s/browser/underline/ ?
-
dael
astearns: On wide clamp side I'm a bit concerns about doing it right for new prop means we have a set that behave one way and a set behaving a different way.
-
dael
astearns: That's a difficult story to tell
-
dael
astearns: As we introduce more properties you have to keep in mind which do you clip and which do not
-
dael
florian: A valid use case was brought up for not wide clamp. Since they're animatibe you can shift overline from way for to right position with the offset. I would expect people to try and do that. Yes perf implications and complexity but if you go for it you go for it. There's no good taste design law that says we should ban this
-
dael
myles_: Seen websites that do that effect. All those have underline in a reasonable position through any point in animation. I think all 3 options would work on those sites. Sites I've seen move underline rfom 5 px below natural position to its natural position
-
dael
florian: Not from outside screen?
-
dael
myles_: Never seen a website that did that
-
dael
jensimmons: I agree with myles. Don't have to worry about underline flying in from off page. Small move from hover is use case
-
dael
jensimmons: I wonder if one thing to agree one is question of if we were to have a clamp are there people that want to clip and have it disappear or can we agree with will never clip. We'll clamp and it won't move anymore. You hit a limit and it no longer moves
-
bradk
-1 to any clipping at all
-
dael
AmeliaBR: I think it's important that if we allow clipping we have to be consistent where it happens so you don't have accidently disappearing. Clamping is easier to leave to UA discretion b/c will never have content disappear
-
dael
myles_: Underline 700px away is effectively lost
-
jensimmons
I disagree with what AmeliaBR just said. But she also changed the subject
-
dael
AmeliaBR: Are we clipping at 700px or at 2em. We've been throwing a lot of things around.
-
dael
myles_: 700px is the no clamp situation
-
dael
astearns: jensimmons question is if we do agree on a limit do we agree underline will be drawn at that limit if author spec something outside limit.
-
dael
astearns: I'm for resolving on always drawing underline
-
dael
myles_: fine with that
-
fantasai
I think if we resolve on always drawing the underline, whatever clamping limit we choose should be relatively close to the line
-
dael
florian: Along lines AmeliaBR said we can make argument it's less important with strong interop. But I think it's better to always draw
-
dael
bradk: can all agree on that
-
dbaron
+1 to always drawing
-
dael
astearns: And fantasai point that if we do decide to always draw limit will need to be fairly close. If we say always draw helps to define limit
-
fantasai
because if the limit is ~ 700px, then the author might want to draw the underline off-screen but it'll only be off-screen on some UAs/some screen sizs
-
dael
astearns: Obj to always draw the underline?
-
dael
RESOLVED: always draw the underline even if it's spec to be outside a limit we choose
-
dael
astearns: Remaining issue is do we have a limit. If we do what is it
-
dael
astearns: I heard from some people they wanted to talk to other groups like a11y
-
dael
fantasai: If clamping and not clipping we need to clamp relatively close. WIthin a couple of lines. If we allow anywhere on screen and UA limit is 1000px author will try for 9000px and on some monitors it's visible which is not intended.
-
dael
fantasai: If we're clamping rather then clipping underline needs to show up in most cases
-
dael
florian: You're aruging no clamp or mid-range clamp but not wide
-
dael
jensimmons: I think she's arguing narrow or wide but not no clamp
-
jensimmons
The problem fantasai just described already exists for authors.
-
dael
fantasai: I'm against narrow; I agre with jensimmons and bradk arguments
-
jensimmons
Authors putting things off-screen, thinking they are gone, when in fact they are on-screen for some people
-
dael
bradk: If you're going to clamp position need to clamp thickness too. If top of underline is 3em away it can be 6em width
-
dael
fantasai: It'll be visible enough for author to notice it's there. Interensting point if we want to allow underlines that are 500x width of line.
-
dael
bradk: I'm for not restraining creative uses. It's a decoration. If there's a great reason to cover height of page, fine. If it's performance hit it's author's responsibility to deal
-
tantek
+1 bradk
-
florian
agree with bradk
-
dael
astearns: I'm not hearing consensus. Some people interested in a limit for semantic, some people want a limit for impl difficulty or perf, and others not up for a limit at all.
-
dael
fantasai: Straw poll?
-
tantek
priorities: authoer > implementation > semantic purity
-
dael
astearns: I suppose we can.
-
dael
myles_: Fourth is allow impl to decide
-
tantek
so I think we should lean towards bradk & jensimmons opinions here
-
dael
fantasai: I think we need some interop. If one does semantic and the other does none it'll be bad for everybody
-
bradk
Does it help to agree that it is an ink effect only, which doesnโt break to other pages and columns?
-
florian
agreed with jen
-
dael
jensimmons: If we land on narrow needs to be very specific. If we land on wide it can be more like the allowed zone needs to be something specific but beyond browsers can do what they want. Then you're out of author impact zone and into engineering impact zone.
-
fantasai
bradk, we're already agreed on that, but good to remind
-
dael
jensimmons: If it's about effecting authors need tight interop
-
dael
Rossen_: Currently all browser clamp at semantic place. If you say differences are bad for everyone not having clamping close to semantic puts in that effect for everyone
-
dael
AmeliaBR: Do we have more than one impl?
-
dael
jensimmons: FF nightly and it has no clamp
-
» myles_ jensimmons Firefox Nightly!!! Very exciting!
-
dael
Rossen_: All browsers that don't support offset draw underline at semantic height
-
dael
astearns: Not relevent b/c discussing new property
-
» jensimmons myles_ turn it on in about:config :)
-
dael
Rossen_: Is based on amount of difference we impose on users without that property
-
jensimmons
straw poll??
-
dael
florian: THat's progress of enhancing. They do a sensible fallback
-
dael
Rossen_: that's what I'm arguing about
-
fantasai
s/progress of enhancing/called progressive enhancement/
-
dael
astearns: I agree with myles_ and jensimmons there is a 4th optino of we have a wide clamp and we spec you must allow this much and where you decide liit is impl dependent
-
myles_
**9:18
-
dael
jensimmons: Can I suggest we don't do details in straw poll. It's no clamp, wide clamp, narrow clamp. We realize those might need to be refined and need allowance. THis is about what is important to people
-
» tantek dr. evil face ๐๐ clamp one meeeeelion pixels
-
bradk
A
-
dael
astearns: IRC straw poll. a. No clamp. b. Narrow Clamp. c. Wide clamp
-
astearns
A
-
florian
+1 to A, -1 to B, 0 to C
-
jensimmons
A or C โย no clamp or wide clamp
-
dael
astearns: Please put in IRC, can vote for >1
-
Rossen_
B, C
-
tantek
A
-
myles_
B C
-
fantasai
C, A
-
drousso
B C
-
emilio
A
-
dbaron
A or C
-
nigel
+1 to A, 0 to B, -1 to C
-
dael
astearns: About half of people on call have voted
-
AmeliaBR
A
-
smfr
A
-
bradk
C would be OK if it is 1 meeeelion ems
-
rachelandrew
A
-
cbiesinger
A
-
dael
florian: Surprised by nigel vote
-
gregwhitworth
B, C
-
gregwhitworth
present+
-
dael
nigel: It seem slike underline is the thing that belongs near text. having a wide clamp doesn't seem helpful. If you're saying it can be 5 lines away from text but not 6 it seems arbitrary. Either the underline is associated to text and we enforce or we don't clamp it.
-
melanierichards
B, C
-
dael
florian: Narrow version of clamping tries to prevent overlapping underline with text so you can't mistake for a striketrhough
-
fantasai
"Narrow clamp" forces the underline below the descenders and above the next line of text
-
dael
nigel: May have misunderstood
-
fantasai
"Wide clamp" has varying interpretations, but is not trying to make such a restriction.
-
dael
florian: So you're for wide but not too wide?
-
dael
nigel: Authors need to be able to overlapunderline with text. If it's a different color they can put text on top of it.
-
dael
florian: So that means you disagree with what has been called narrow clamp.
-
dael
nigel: Okay, I guess I should refine my vote.
-
nigel
Revised vote: +1 to A, -1 to B, 0 to C
-
dael
astearns: Looks like no clamp wins the straw poll, but wouldn't resolve on
-
» nigel thank you!
-
emilio
yes
-
smfr
can live with C
-
dael
fantasai: Question for people that voted a. Can you live with c?
-
dael
florian: can
-
» cbiesinger can live with C
-
dael
bradk: Can if it's sufficiently far
-
dael
AmeliaBR: For every css prop we allow impl to have reasonable limits
-
dael
bradk: 1mil em away doesn't matter
-
tantek
yes the dr. evil option!
-
rachelandrew
yes can live with C
-
fantasai
Q - Limit is super-far, based on how big can you draw a box and things like that
-
dael
fantasai: 3 ranges of clamping we could have. q: limit is super far based on how big can you draw a box.
-
fantasai
R - Medium-range, like 6-10 lines - enough for author to notice that there's clamping, but not particularly restrictive
-
dael
fantasai: r- medium range, like fixed to10 lines. lets author notice clampping, but not particularly restricted
-
» tantek wonders if we can time clamp clamping?
-
dael
Rossen_: Define in terms of line box?
-
dael
Rossen_: I think that's more concrete
-
dael
fantasai: That's what I'm talking about.
-
fantasai
S - Short-range, 1-2 line boxes, tries to keep the line with the next, not overlapping the adjacent lines
-
dael
fantasai: s- short range keeps line wiht text
-
dael
Rossen_: q means no limits.
-
dael
fantasai: I would equate q with basically no clampping. We've got medium and short range. Medium you can put it around but you can notice there's clamping. On screen most devices. Short is within range that gives author freedom within line box and slightly outside, but stay within range and avoid overlapping next text
-
dael
fantasai: r and s are variations of [missed] clamp
-
dael
fantasai: For people that voted a and can't live with r or s it means you can't live with c
-
dael
jensimmons: Can you use medium and far words?
-
bradk
-1 to R, -10 to S
-
florian
voted for A, can live with all versions of C (but prefer further)
-
dael
fantasai: Far is basically same as no clamp b/c based on memory usage. Equate with a. Wide clamping there's 2 approaches. One is a lot of room but clamp it close enough you can see there's a clamp. Or we pull tighter and say our goal is within range of line box and not too far down
-
dael
astearns: For people that voted b and c is there anyone that could not live with a?
-
dael
myles_: Totally confused with all the letters
-
dael
a. No clamp. b. Narrow Clamp. c. Wide clamp
-
dael
AmeliaBR: Everyone that said narrow also said wide. Maybe enough consensus with wide and then we get to what is wide clamp really mean.
-
dael
s/ AmeliaBR / jensimmons
-
bradk
A good compromise is when everyone is a little unhappy
-
dael
jensimmons: I was thinking with a few line boxes away, I couldn't fine use cases to go any more then the line above it. I'm fine with it being +/- 1 line box. Doesn't get into not allowed above x height. It's much more forgiving, but it's like you don't want 2 line boxes away.
-
» tantek braces himself for the phone clamp
-
dael
florian: I think bradk dislikes this.
-
dael
astearns: I think it does improve discoverability of limit if we stop moving within a linebox of original position
-
» Rossen_ Have to leave for a different meeting
-
dael
myles_: Have we thought about moving other direction? We did clamp to not do striketrhough. Clamping moving toward text?
-
dael
fantasai: This is all directions. This is in scope
-
tantek
I'd like to allow authors to animate text-decorations into view from outside the viewing area
-
dael
florian: That's option b
-
tantek
that's my no-clamp use-case
-
dael
astearns: We are at time. We'll come back to this again
-
-
» github-bot Because I don't want to spam github issues unnecessarily, I won't comment in that github issue unless you write "Github: <issue-url> | none" (or "Github issue: ..."/"Github topic: ...").
-
dael
topic: end
-
-
dael
florian: I'd like to encourage anyone show cares to look at issue #3440. THat was next on agenda. Good to look.
-
dael
astearns: Thanks everyone for calling in
-
florian
s/show cares/show cares about how lines wrap/
-
fantasai
I wonder if we were almost at consensus on Jen's last proposal?
-
florian
I think we were
-
» tantek github-bot, how much time did we spend on #4059?
-
» github-bot tantek, Sorry, I don't understand that command. Try 'help'.
-
florian
It seems that bradk strongly dislikes it, but everyone else either likes it or can live with it
-
tantek
I'd rather allow authors the option
-
» fantasai wonders if tantek would object?
-
tantek
so I'd lean towards bradk's position
-
» fantasai also wonders if Rossen can live with
-
florian
I'd rather allow the authors the option too, but I can live with that if that's the only place we can find consensus
-
fantasai
Rossen_?
-
tantek
I'd rather ask if folks can live with A / no-clamp
-
jensimmons
I don't think limiting the underline to +/- one or two line boxes is a creative limit at all
-
florian
also, we didn't get into whether we meant "must clamp there" or "may clamp, must not clamp closer than that"
-
tantek
do we limit text-shadow?
-
florian
we don't
-
tantek
ok that seems obvious then. they'
-
jensimmons
I do think it helps discoverability of "WTF I moved the underline where?" and if browser engineers are saying they want to do this for performance sake, I'm like cool. It won't impact Authors.
-
tantek
they're both decorative
-
bradk
I think authors would be confused by why the change in value stopped having any effect on the line
-
tantek
principles of least surprise, don't limit text-decoration positioning if we don't limit text-shadow
-
bradk
Confounded even
-
AmeliaBR
I'm at the point where I strongly dislike ALL the options because we've been debating too long. But I'd be happier with one of the other extremes: either no clamp & leave it up to authors, or clamp to a semantically meaningful definition of "underline" (e.g., midline in between x-height and 1em below the baseline). I don't like arbitrary restrictions.
-
tantek
I think strawpoll demonstrated far more A than other options
-
bradk
And the line thickness would still cause the same performance issues
-
tantek
so I'd really like us to find a way to get consensus on A, rather than begrudgingly picking a far less preferred option
-
bradk
If text shadow doesnโt have a limit, then neither should underline
-
tantek
boom
-
tantek
that's what authors are going to think
-
tantek
limitless text-shadow is already out of the box (so to speak)
-
florian
myles said he considered the lack of limit on text shadow to be a historical mistake that we cannot fix there for compat reasons, but can fix here because it's new. I disagree, but that was the claim.
-
tantek
limitless text-shadow is excellent for retro 1980s style effects
-
bradk
Exactly. A cool creative effect that wasnโt necessarily anticipated by spec authors
-
tantek
yes
-
bradk
I also have used box shadow with giant spread values for backdrops for dialogs
-
florian
I think it'd go with: "UAs may limit how far the underline may be placed. If they do so, the limit must be enforced by clamping the numerical value of the offset, not by visual clipping. The limit must not be less than ...." and we pick the largest ... that gets no objection.
-
florian
that way, UAs that want to allow authors creativity can do so, and those who want to enforce a limit are at least forced to keep the underline visible
-
fantasai
That gets into the interop problem again
-
tantek
๐๐ one meeelion ems
-
fantasai
Someone tries to put an underline off-screen
-
fantasai
it works in one browser
-
bradk
2vmax
-
fantasai
it ends up on-screen in another browser
-
florian
true
-
florian
but you can do that with shadows, outlines, etc.
-
fantasai
they clip, they don't clamp
-
fantasai
bradk, I don't think implementations want to use viewport units in their clamping limits
-
fantasai
they require recalculation every time the window size changes
-
florian
sure, but if you have your shadow offset by 500px, it will be off screen on my phone, and on screen on my desktop. no need to invoke clamping for that problem to occur
-
florian
So I don't get why this is a problem now and not before.
-
fantasai
That's fine because you designed for desktop, and some things you have to scroll to on a phone, it's OK
-
fantasai
the problem is you *try* to put something off-scren
-
fantasai
and then it's visible on someone else's computer
-
florian
maybe you designed for phone, and it bugs out on desktop
-
fantasai
really?
-
bradk
If you could have viewport units, it would solve that part though
-
florian
I put my shadow 500px away to make it off screen, so that I can animate it into view when $foo happens, but I failed and it shows on big phones and desktop.
-
florian
same problem with the underline
-
bradk
Sort of
-
florian
but while I agree it's a problem in theory, I don't recall ever running into that
-
fantasai
If the limit is going to be as far away as 2vmax or thereabouts, then I'd like to reresolve on clipping
-
florian
"may clamp, but not closer than X" has the same problem, which I think is theoretical, not real life
-
fantasai
which is why I am disagreeing with it
-
florian
good. At least we know what we disagree about :)
-
fantasai
If we're going with "no clamping, effectively, because the limit is huge" then we should have "and you clip if it's too far"
-
bradk
fantasai: Why clip?
-
fantasai
If we're going with "clamping within reasonably visible range" then "clamp, don't clip"
-
fantasai
bradk, results are less arbitrary, and if it's a UA-defined limit, you don't get an underline overlapping some random other content on the page in one browser but not on another
-
bradk
Offset 1vh, thickness 1vh
-
fantasai
draw a box, not an underline
-
bradk
Sorry I keep thinking we are offsetting the center of the line
-
florian
or maybe we leave the clip vs clamp question open in the "may clamp, but no closer than X" version, and browsers who limit to nearby clamp, and those who limit to 65536px clip
-
jensimmons
-
» github-bot Because I don't want to spam github issues unnecessarily, I won't comment in that github issue unless you write "Github: <issue-url> | none" (or "Github issue: ..."/"Github topic: ...").
-
jensimmons
I drew a drawing.
-
bradk
Offset -1vh, thickness 1vh
-
florian
Jen, do you mean "must clamp there" or "may clamp, but no closer than there".
-
fantasai
Florian, our job is to create inteorp.
-
florian
I take that as a vote for "must clamp there" :)
-
fantasai
Thanks jensimmons :)
-
astearns
topic: end
-
florian
:)
-
astearns
trackbot, end meeting
-
» trackbot is ending a teleconference.
-
trackbot
Zakim, list attendees
-
Zakim
As of this point the attendees have been smfr, Rossen_, astearns, dael, plinss, gregwhitworth, jensimmons, rachelandrew, fantasai, AmeliaBR, cbiesinger, melanierichards, antonp,
-
Zakim
... bradk, dbaron, drousso, emilio, Nigel, tantek
-
trackbot
RRSAgent, please draft minutes
-
RRSAgent
I have made the request to generate
w3.org/2019/07/17-css-minutes.html trackbot
-
trackbot
RRSAgent, bye
-
RRSAgent
I see no action items
-
astearns
(sorry - didn't mean to stop the discussion here. I just wanted to make sure the bot was done)
-
fantasai
I gotta leave anyway :)
-
» fantasai needs to find breakfast and drive a long ways
-
aja
something to consider for text-{decoration|overline|strikethrough|underline}-width: thin|medium|thick values?
-
aja
issue-worthy?
-
aja
-
» Zakim excuses himself; his presence no longer seems to be needed