- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 17 Jul 2019 19:09:27 -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.
=========================================
Text Decoration
---------------
- Issue #3993 (text-decoration-width claims to be a sub-property of
text-decoration, but text-decoration disagrees) should be
addressed once the text-decor-3 text is edited into L4
- RESOLVED: Always draw the underline even if it's specified to be
outside a limit we choose [meaning that even if we clamp
the underline we won't clip it] (Issue #4059)
- The discussion on if there should be a clamp on
text-underline-offset (and by extension strikethrough and
overline offset) continued without resolution. There were three
options to pick from:
A) No clamping
B) Wide clamping
C) Narrow clamping
- The argument for no clamping is that there shouldn't be
restrictions on the designs people produced.
- The argument for wide clamping is to avoid design restrictions but
also limit performance and implementation difficulties.
- The argument for narrow clamping to avoid the underline being used
to replace a strikethrough or overline.
- There's a desire to hear from the a11y working group on their
views about this concern
- A straw poll was taken of the three options, but there was no
clear winner between the three options.
- As the meeting drew to a close there was discussion to
understanding more specifics about the limits intended when the
group spoke of wide vs narrow clamping. The offered more
specific details were:
Q) Limit is super-far, based on how big can you draw a box and
things like that
R) Medium-range, like 6-10 lines - enough for author to notice
that there's clamping, but not particularly restrictive
S) Short-range, 1-2 line boxes, tries to keep the line with the
next, not overlapping the adjacent lines
CSS Text
--------
- RESOLVED: Tabs do not hang and you can break between for
white-space: break-spaces (Issue #3869: pre-wrap and
tabs at the end of the line)
- RESOLVED: For white-space:pre-wrap tabs hang like spaces do (Issue
#3869)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Jul/0023.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins (IRC Only)
David Baron
Amelia Bellamy-Royds
Christian Biesinger
Tantek Çelik
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Dael Jackson
Brad Kemper
Peter Linss
Nigel Megitt
Anton Prowse
Jen Simmons
Alan Stearns
Melanie Richards
Greg Whitworth
Regrets:
Dave Cramer
Scribe: dael
astearns: We should get started
astearns: Anything to add or change about the agenda?
astearns: Do we have the people to discuss
https://github.com/w3c/csswg-drafts/issues/4059#issuecomment-510148922
?
astearns: Particularly is myles on?
astearns: Let's skip until we get myles
Text Decoration
===============
text-decoration-width claims to be a sub-property of text-decoration,
but text-decoration disagrees
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3993
astearns: emilio added this and fantasai commented.
astearns: Anything we need to do?
fantasai: Not unless someone disagrees with making it a sub property
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
fantasai: Hang up is text-decor-3 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
astearns: So we'll close this as soon as you cross check and
possible update spec
fantasai: Yeah
astearns: Any disagreement with that course of action?
??: nope
astearns: Let's leave it at that.
CSS Text
========
pre-wrap and tabs at the end of the line
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3869#issuecomment-509811620
astearns: florian added an example
florian: 2 parts to the discussion. One is hardly discussed and
non-controversial. Other was controversial and needed an
example
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.
florian: I'd like to resolve on that before going to
white-space:pre-wrap
astearns: Treat tabs the same as issues for this?
<fantasai> for break-spaces, right?
florian: They can't hang and you can wrap between two consecutive
tabs
astearns: Tabs do not hang and you can break between for
white-space: break-spaces
astearns: Objections?
RESOLVED: Tabs do not hang and you can break between for
white-space: break-spaces
florian: Now what happens with tabs at end of line with
white-space:pre-wrap
florian: Example in document with line empty with tabs at end. What
happens if line is too short?
florian: First example is when line is long enough, second is when
tab hangs.
florian: If you disallow hanging and disallow breaking between tabs
you get second rendering. 3rd is disallow hanging but allow
breaking between tabs. No one does 3rd, browsers are split
between first 2.
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.
florian: Questions on example? Thoughts on why one is preferable?
astearns: I don't have much of a preference. Not sure the 3rd is
preferable either
astearns: I don't know why you have weak preference for that
dbaron: Drawing in example assumes tab stop lines up with end of
container.
florian: It 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.
fantasai: Only difference visually is container is slight wider, but
otherwise render same
dbaron: Complexity with not line up is you would also have to decide
if can break in middle of tab
florian: I assumed you could not, but fair enough. It renders as a
shift not a character.
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
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
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.
florian: Going by use case would be better. Haven't ID'ed any.
Should we draw in rachelandrew or jensimmons to do a
Twitter poll?
dbaron: This feel obscure to me.
florian: It does
astearns: Could resolve on behavior 1 since we have 2 engines
doing it
florian: Yeah...no 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.
dbaron: I think consistency with spaces is reasonable thing. I don't
have strong opinions.
<tantek> is there any way to apply the principle of least surprise
here?
<tantek> all other things being equal?
florian: Suspect any impl difficulty?
dbaron: Hard to say
astearns: Main difficulty is reason to make the change. I could just
be a bug in FF forever
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
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.
astearns: tantek asked in IRC: [reads]. One of the problems is no
one has strong opinion on actual expectation
florian: Being consistent with spaces goes slightly to least
surprise. If you know one you know the other
astearns: Sounds like we are driving toward a preference for the
first option since consistent with spaces
florian: Right, the tabs hang
astearns: Proposal: for white-space:pre-wrap tabs hang like spaces do
astearns: Objections?
<tantek> that seems reasonable and less noisy (random tabs/ws at end
of line won't change layout)
RESOLVED: For white-space:pre-wrap tabs hang like spaces do
Text Decoration
===============
Limits on text-underline-offset to preserve semantic meaning
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4059#issuecomment-510148922
astearns: Discussed this, what, last week? Been more discussion in
GitHub. jensimmons gave 3 options
astearns: 1. Don't do any clamping. 2. Wide clamp 3. Narrow clamp
astearns: Any additional information to add?
<florian> opinions yes, but nothing new
astearns: From my pov we shouldn't have a clamp at all. Whatever
clamp we choose might be difficult to come at an
interoperable consensus as to what it should be. I am not
concerned with semantic implications of moving an
underline.
astearns: Agree we should have these offsets for strikethrough and
overline as well
<florian> +1 to astearns
<TabAtkins> +1
astearns: I think that's an argument to add more offset properties
and not clamping any
bradk: I agree
<fantasai> I'm against the narrow clamping definition.
florian: One nuance. If there are implementation difficulties having
an allowance for clamping for the reason of not paining
many pages away I would accept that. Not go any further
then that.
smfr: If you don't clamp do you allow underline to be clipped out?
So UA must paint however 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.
florian: Do we expect impl to be more difficult to put underline
3000 px away?
smfr: More difficult for text decor
myles: Performance hit where any part of page changes have to redraw
entire paragraph
AmeliaBR: True for things like box shadows
myles: Unfortunate there too
AmeliaBR: Shouldn't have special rules for this. Should have general
rule for at point you can reasonably clip
myles: Have webcompat for others. This is new so can change
jensimmons: Sounds to me this is an argument for a wide clamp. To
smfr's point I meant any obstruction of author ability
to put underline where they thought. A clip or a clamp
is a level of sophistication we haven't reached.
florian: If you're going to limit it should be clamp rather then
clipping.
florian: I would go for wide clamp or no clamp
Rossen: Sounds like discussing merit of feature again. There was
good consensus last time we wanted clamping
florian: no
<florian> I don't think there was emerging consensus
Rossen: And also of the opinion that if we don't have clamping of
offset then any other implementations that do
underline-offset will have fairly different semantic
meanings as to where they'll draw underline or one that
looks like a strikethrough.
Rossen: For a new feature we have control over we have a chance to
make it right.
Rossen: If there are use cases to pay around with a background in
the middle of the line box, use the strikethrough. 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. Especially for implementations that don't have it.
Having poor fallback is not a good idea
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
jensimmons: What I'm hearing from Rossen is an argument for narrow
clamp. I don't think we've had consensus. After call
especially hearing more and more no clamp. We can keep
trying to articulate reasons, but 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
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
myles: Maybe compromise is wide clamp. Because wide spec can just
recommend a general idea of where to put it.
<jensimmons> +1 for what Myles just said
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 performance
reasons but not semantic. Is that correct?
fantasai: Yes
florian: That's how I understand
<tantek> Why are *under*lines not drawn *under* the text
(layerwise), so they can't actually strike-through? (they
could strike-under?)
<fantasai> tantek, they are drawn under the text
<florian> tantek, they are
<fantasai> tantek, and strike-throughs are drawn over
<tantek> thanks fantasai, then I'm not as worried about underline
abuse, cosmetically, semantically or otherwise
<bradk> <u> is semantic. *-decoration is not
<fantasai> +1 to bradk
<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)
Rossen: I think first [narrow] is characterized well. Second is a
little unfair. Implementations 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 implementation and performance
<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
<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
<tantek> I feel like we can punt a bit longer until Chrome intents
to implement, or have we seen that already?
astearns: To move discussion along, can we resolve not to add a
clamp to this property for merely semantic reasons. Would
anyone like to argue for narrow clamp to satisfy semantic
concerns?
* fantasai suggests a straw poll
Rossen: I would be willing to continue to argue this. I would want
to hear from other groups on this issue, including a11y
astearns: I wonder if it makes sense to break issue into 2 concerns.
There are separate arguments for each.
astearns: Is there anyone besides Rossen who is up to argue for
semantic concerns?
myles: Our original purpose was this. There's a difference between
existing properties 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
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
myles: Authors have to think about that and add code
florian: To disappear yes
bradk: Have to think about that for any new
jensimmons: Fallback is natural and makes sense. If you're doing
fancy in a new browser your fallback is a normal
underline. I don't see it as complex, it seems natural
from author PoV
<bradk> +1 jensimmons
astearns: On wide clamp side I'm a bit concerned about doing it
right for new property means we have a set that behave one
way and a set behaving a different way.
astearns: That's a difficult story to tell
astearns: As we introduce more properties you have to keep in mind
which do you clip and which do not
florian: A valid use case was brought up for not doing wide clamp.
Since they're animatable you can shift overline from way
far to the side to the right position with the offset. I
would expect people to try and do that. Yes performance
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
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 from 5 px below natural position to its
natural position
florian: Not from outside screen?
myles: Never seen a website that did that
jensimmons: I agree with myles. Don't have to worry about underline
flying in from off page. Small move from hover is use
case
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
AmeliaBR: I think it's important that if we allow clipping we have
to be consistent where it happens so you don't have
accidentally disappearing. Clamping is easier to leave to
UA discretion because will never have content disappear
<jensimmons> I disagree with what AmeliaBR just said. But she also
changed the subject
myles: Underline 700px away is effectively lost
AmeliaBR: Are we clipping at 700px or at 2em. We've been throwing a
lot of things around.
myles: 700px is the no clamp situation
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.
astearns: I'm for resolving on always drawing underline
myles: fine with that
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
bradk: Can all agree on that
<dbaron> +1 to always drawing
<fantasai> I think if we resolve on always drawing the underline,
whatever clamping limit we choose should be relatively
close to the line
astearns: And fantasai's 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 sizes
astearns: Objections to always draw the underline?
RESOLVED: Always draw the underline even if it's specified to be
outside a limit we choose
astearns: Remaining issue is do we have a limit. If we do what is it
astearns: I heard from some people they wanted to talk to other
groups like a11y
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.
fantasai: If we're clamping rather then clipping underline needs to
show up in most cases
florian: You're arguing no clamp or mid-range clamp but not wide
jensimmons: I think she's arguing narrow or wide but not no clamp
<jensimmons> The problem fantasai just described already exists for
authors.
<jensimmons> Authors putting things off-screen, thinking they are
gone, when in fact they are on-screen for some people
fantasai: I'm against narrow; I agree with jensimmons' and bradk's
arguments
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
fantasai: It'll be visible enough for author to notice it's there.
Interesting point if we want to allow underlines that are
500x width of line.
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
astearns: I'm not hearing consensus. Some people interested in a
limit for semantic, some people want a limit for impl
difficulty or performance, and others not up for a limit
at all.
fantasai: Straw poll?
<tantek> priorities: author > implementation > semantic purity
<tantek> so I think we should lean towards bradk & jensimmons
opinions here
astearns: I suppose we can.
<bradk> Does it help to agree that it is an ink effect only, which
doesn’t break to other pages and columns?
<fantasai> bradk, we're already agreed on that, but good to remind
myles: Fourth option is allow impl to decide
fantasai: I think we need some interop. If one does semantic and the
other does none it'll be bad for everybody
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.
<florian> agreed with jen
jensimmons: If it's about effecting authors need tight interop
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
AmeliaBR: Do we have more than one impl?
jensimmons: FF nightly has it and it has no clamp
Rossen: All browsers that don't support offset draw underline at
semantic height
astearns: Not relevant because discussing new property
Rossen: Is based on amount of difference we impose on users without
that property
florian: That's called progressive enhancement. They do a sensible
fallback
Rossen: That's what I'm arguing about
<jensimmons> straw poll??
astearns: I agree with myles and jensimmons there is a 4th option of
we have a wide clamp and we spec you must allow this much
and where you decide it beyond that much is impl dependent
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
astearns: IRC straw poll. a. No clamp. b. Narrow Clamp. c. Wide clamp
astearns: Please put in IRC, can vote for >1
<bradk> A
<astearns> A
<florian> +1 to A, -1 to B, 0 to C
<jensimmons> A or C — no clamp or wide clamp
<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
astearns: About half of people on call have voted
<AmeliaBR> A
<smfr> A
<rachelandrew> A
<cbiesinger> A
<gregwhitworth> B, C
<melanierichards> B, C
florian: Surprised by nigel's vote
nigel: It seems like 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.
florian: Narrow version of clamping tries to prevent overlapping
underline with text so you can't mistake for a strikethrough
<fantasai> "Narrow clamp" forces the underline below the descenders
and above the next line of text
<fantasai> "Wide clamp" has varying interpretations, but is not
trying to make such a restriction.
nigel: May have misunderstood
florian: So you're for wide but not too wide?
nigel: Authors need to be able to overlap underline with text. If
it's a different color they can put text on top of it.
florian: So that means you disagree with what has been called narrow
clamp.
nigel: Okay, I guess I should refine my vote.
<nigel> Revised vote: +1 to A, -1 to B, 0 to C
astearns: Looks like no clamp wins the straw poll, but wouldn't
resolve on
fantasai: Question for people that voted a. Can you live with c?
<emilio> yes
<smfr> can live with C
florian: I can
* cbiesinger can live with C
bradk: Can if it's sufficiently far
<rachelandrew> yes can live with C
AmeliaBR: For every css property we allow impl to have reasonable
limits
bradk: 1mil em away doesn't matter
fantasai: 3 ranges of clamping we could have.
<fantasai> Q - Limit is super-far, based on how big can you draw a
box and things like that
<fantasai> R - Medium-range, like 6-10 lines - enough for author to
notice that there's clamping, but not particularly
restrictive
<fantasai> S - Short-range, 1-2 line boxes, tries to keep the line
with the next, not overlapping the adjacent lines
Rossen: Define in terms of line box?
Rossen: I think that's more concrete
fantasai: That's what I'm talking about.
Rossen: Q means no limits.
fantasai: I would equate Q with basically no clamping. 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
fantasai: R and S are variations of [missed] clamp
fantasai: For people that voted A and can't live with R or S it
means you can't live with C
<bradk> -1 to R, -10 to S
<florian> voted for A, can live with all versions of C (but prefer
further)
jensimmons: Can you use medium and far words?
fantasai: Far is basically same as no clamp because it's 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
astearns: For people that voted b and c is there anyone that could
not live with a?
myles: Totally confused with all the letters
[a. No clamp. b. Narrow Clamp. c. Wide clamp]
jensimmons: Everyone that said narrow also said wide. Maybe enough
consensus with wide and then we get to what is wide
clamp really means.
<bradk> A good compromise is when everyone is a little unhappy
jensimmons: I was thinking with a few line boxes away, I couldn't
find 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.
florian: I think bradk dislikes this.
astearns: I think it does improve discoverability of limit if we
stop moving within a linebox of original position
myles: Have we thought about moving other direction? We did clamp to
not do strikethrough. Clamping moving toward text?
fantasai: This is all directions. This is in scope
florian: That's option b
<tantek> I'd like to allow authors to animate text-decorations into
view from outside the viewing area
<tantek> that's my no-clamp use-case
astearns: We are at time. We'll come back to this again
<florian> https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-509638587
florian: I'd like to encourage anyone who cares about how lines wrap
to look at issue #3440. That was next on agenda. Good to
look.
astearns: Thanks everyone for calling in
Post Call IRC
- - - - - - -
<fantasai> I wonder if we were almost at consensus on Jen's last
proposal?
<florian> I think we were
<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
<tantek> so I'd lean towards bradk's position
* fantasai wonders if tantek would object?
* fantasai also wonders if Rossen can live with
<fantasai> Rossen?
<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
<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'
<tantek> they're both decorative
<tantek> principles of least surprise, don't limit text-decoration
positioning if we don't limit text-shadow
<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.
<bradk> I think authors would be confused by why the change in value
stopped having any effect on the line
<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.
<bradk> And the line thickness would still cause the same
performance issues
<tantek> I think strawpoll demonstrated far more A than other options
<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
<fantasai> Someone tries to put an underline off-screen
<fantasai> it works in one browser
<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
<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-screen
<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> 2vmax
<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
<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> https://github.com/w3c/csswg-drafts/issues/4059#issuecomment-512421819
<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 interop.
<florian> I take that as a vote for "must clamp there" :)
<fantasai> Thanks jensimmons :)
<florian> :)
Received on Wednesday, 17 July 2019 23:10:27 UTC