- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 10 Jul 2019 19:42:56 -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.
=========================================
Values & Units 4
----------------
- RESOLVED: For interpolation math functions are treated as atomic
algebraic terms. You interpolate a calc expression that
is the weighted sum of all the terms. (Issue #4082: How
to interpolate min/max/clamp?)
CSS Images
----------
- RESOLVED: Add section to CSS images defining computed value of an
image type. This value has colors links and lengths all
made absolute per usual computed value rules for those
sub types and fix specs referring to images to make sure
use correct language. (Issue #4042: Computed gradient
colors)
Resize Observer
---------------
- RESOLVED: SVG elements generating CSS layout boxes are included as
part of resize observer and resize observer rectangles
with a definition [for layout box] of `svg:root, *:not(
svg|*) > SVG, SVG|foreignObject > SVG { /* SVG elements
with CSS layout box */} (Issue #4032: SVG Interaction)
Text Decor
----------
- Much of the on call discussion on issue #4032 (Limits on
text-underline-offset to preserve semantic meaning) was about
where a clamp should be.
- There continued to be concern about text-underline-offset being
used in place of a strikethrough. This could lead to problems in
styling with browsers that have not fully implemented the
property as well as discrepancies between what is visually
presented and what's in the a11y tree.
- One possible way to prevent the strikethrough case is to
ensure that authors have just as much style control on
overlines and strikethroughs so that there is no incentive
to misuse an underline.
- The other option presented was to clamp at a mid-point in the
text so that it can't get to the point where it looks like a
strikethrough.
- The other argument for clamping was to ensure that the underline
was visually presented in near proximity to the text it is
underlining.
- This lead to an argument that clamping shouldn't be done at
all since box-shadows can end up anywhere in the document,
not just in close proximity to the box, and therefore
limiting the text-underline-offset will limit flexibility in
design. Changing a value and not having it change on screen
is often a bad authoring experience.
- Since there were several different opinions on where to clamp as
well as some arguments that we shouldn't be clamping at all,
discussion will continue on github.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Jul/0010.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Dave Cramer
Elika Etemad
Simon Fraser
Dael Jackson
Brian Kardell
Brad Kemper
Peter Linss
Myles Maxfield
Anton Prowse
Melanie Richards
Florian Rivoal
Jen Simmons
Sean Voisen
Greg Whitworth
Regrets:
Christian Biesinger
Manuel Rego Casasnovas
Stanton Marcum
Scribe: dael
Values & Units 4
================
How to interpolate min/max/clamp?
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4082
AmeliaBR: I agenda+ it, though thinking of it for next week.
AmeliaBR: We're starting to get consensus, at least TabAtkins and I
and Alan C agree
AmeliaBR: We have new math functions including these functions. We
don't have anything that defines how work in animations
and transitions. They generally work on computed values
and these functions exist at computed time so need to
define how to interpolate
AmeliaBR: Proposal is that interpolation would be a linear
interpolation of the terms where the functions on the
initial side of interpolation are scaled and multiplied by
0 and on the result side the scaled up from 0 to 1.
Intermediary result is the sum of those terms
AmeliaBR: Important benefits of the approach is you can define the
intermediary value as a computed value without needing to
substitute in values from layout. And you can do
mathematical simplification and it won't change result
AmeliaBR: If author wants different interpolation like changing
power and want power interpolated instead of results they
can do by custom properties and interpolate the custom
property rather then final mathematical expression
Rossen: Other comments or thoughts?
AmeliaBR: Proposal: For interpolation math functions are treated as
atomic algebraic terms. You interpolate a calc expression
that is the sum of all the terms
<dbaron> weighted sum, I hope :-)
Rossen: Okay. Any objections?
<fremy> LGTM
AmeliaBR: Yes, weighted sum by the interpolation factor
<TabAtkins> Aka, if interpolating between any two expressions A and
B, the interpolation is *defined as* calc(.X*A +
(1-.X)*B) (plus any algebraic simplifications)
RESOLVED: For interpolation math functions are treated as atomic
algebraic terms. You interpolate a calc expression that is
the weighted sum of all the terms
Variables
=========
Substitution of invalid variables into other variables
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4075
Rossen: I'm not sure who the commentor is
TabAtkins: One of our implementors.
TabAtkins: This isn't appropriate for agenda + though. Still
discussing in issue.
AmeliaBR: I tagged because looked like a conclusion, but still
something not resolved.
CSS Images
==========
Computed gradient colors
------------------------
github: https://github.com/w3c/csswg-drafts/issues/4042
TabAtkins: With regards to images we have boiler plate for computed
values. That doesn't technically cover things like
absolutizing colors and links. Because it's boiler plate,
things like gradient colors don't turn into consistent
versions per spec.
TabAtkins: But we don't want copy/paste from boiler plate to mean
something wrong. Proposal is we 1) define what a computed
image is which does absolutizing and then 2) file bugs to
make sure everyone serializes in same way across usages
AmeliaBR: For gradients key things is colors inside gradient should
behave like colors everywhere and links like links. We
don't have cross browser so need impl to update
AmeliaBR: Second is having one definition is what should happen to
make consistency. I think that goes in replaced images and
everywhere references it.
<gregwhitworth> mozilla folks: do you all have any compat issues
from this, I presume not - but thought I'd ask if
you've ever had reports
<dbaron> I don't know of them off the top of my head -- though that
doesn't mean we haven't.
AmeliaBR: gregwhitworth asked on IRC. Mozilla currently is doing
things as we want them to be done. They're the only one.
Question was on compat complaints on that?
dbaron: I don't know of any. We could search but I haven't heard of
any escalated
gregwhitworth: That's good enough for me. Thanks.
dbaron: Is this mostly a gradient thing?
TabAtkins: I believe that's the only thing in image that exposes
colors and links. If anyone supports image() like we want
that does take a color and would be impacted, but no one
impl yet.
AmeliaBR: Also filter image function with I think is in Safari. Will
need to be defined.
dbaron: Only compat bugs I find with gradients is 0 vs 0deg and a
graphics bug. Doesn't seem relevant here
Rossen: Okay
Rossen: Additional thoughts? Sounds like we have consensus on
expected behavior and what clarifications to spec are
needed. Don't see pushback
<fantasai> +1 to the change
Rossen: Objections?
<AmeliaBR> Proposal: Add section to CSS images defining computed
value of an image type. This value has colors links and
lengths all made absolute per usual computed value rules
for those sub types
TabAtkins: And fix specs referring to images to make sure use
correct language
RESOLVED: Add section to CSS images defining computed value of an
image type. This value has colors links and lengths all
made absolute per usual computed value rules for those sub
types and fix specs referring to images to make sure use
correct language
Resize Observer
===============
SVG Interaction
---------------
github: https://github.com/w3c/csswg-drafts/issues/4032
bkardell: Sounds like have agreement what it's doing with SVG
element and maybe some cases AmeliaBR described is looking
at wrong box. I think gregwhitworth agreed.
Rossen: Can you summarize?
bkardell: Resize observer observes a box. First take was content and
then it expanded to border.
bkardell: In SVG terms means things line SVG rendering context where
box is translated into SVG viewport. Those dimensions are
adjusted for viewport. In main doc where thinking about
CSS boxes you want CSS boxes.
bkardell: Difference between element inside SVG or SVG itself is
easiest example
AmeliaBR: Current spec has special rules for SVG elements. As
specified and implemented those special rules are used for
all SVG elements, even those with CSS box so you can't use
resize observer to see if your SVG has been resized.
AmeliaBR: That's where we have agreement from gregwhitworth this is
unintentional oversite. Elements with CSS layout boxes you
should be able to observe those values.
AmeliaBR: This is a spec change that requires implementations to
change to match.
AmeliaBR: Question of what to do about SVG elements that don't have
CSS layout boxes I don't know if there's clear agreement.
No matter the box you ask for you get SVG bounding box
<fantasai> https://github.com/w3c/csswg-drafts/issues/857 is
relevant here
<fantasai> See e.g. https://drafts.fxtf.org/fill-stroke/#fill-origin
gregwhitworth: AmeliaBR I think what you said is fine. I don't have
knowledge on inner workings of SVG. We have bounding
box as universal thing, but you say it won't be
useful inside SVG. Majority of use cases would end up
doing what bkardell tried. Having the fallback where
it doesn't have a CSS box fallback to the SVG
bounding box. Seems reasonable to me.
gregwhitworth: Maybe other SVG folks can think about it as well
bkardell: I don't know use cases for what you would observe inside
an SVG. I guess I can think of some. Seem different and
more complex. Missing the one fitting in where this thing
has a CSS box and it's not reporting it.
Rossen: Defining this on CSS boxes sounds more sane then defining on
anything that creates a bounding box. Effect of computing
trees and subtrees will be intense.
Rossen: I'm leaning toward agreeing with bkardell and stick to
defining the behavior on CSS box
gregwhitworth: Sounds like based on your and AmeliaBR expertise
there isn't value for bounding box. Could remove SVG
special case
emilio: It sounds fine to just not have. If it's on CSS bounding
boxes. We had discussion on resize observer v2 about
different types of boxes. Weird if you get SVG bounding box
when that's not what you asked for. I'm good with
restricting to those with CSS bounding boxes.
fantasai: As we were defining how SVG doesn't have border box. There
are definitions in fill and stroke that we adopt that map
things like border box in a standard way. If we're going
to allow any kind of lookup on SVG shapes we should be
consistent with that resolution
AmeliaBR: Not sure we got that adopted beyond one spec.
fantasai: Had a resolution though. If specs were updated is
separate. But we said we'd do it across all specs so
they're consistent. Resize observer shouldn't be
exception. If we're allowing it to be set on SVG shape
should be consistent
bkardell: I think there's 2 ends to this. One is if SVG bounding
boxes should be reported. If they have CSS content boxes
they should be, most basic version of resize observer is
at least that
bkardell: If my SVG resizes I should be able to observe that
bkardell: According to spec and impl you can't. At a minimum we'd
like that resolved.
<gregwhitworth> Proposed Resolution: Remove special case for SVG
which will allow SVG elements to be observed rather
than using the SVG bounding box
Rossen: I think that's where everyone is leaning. We spent some time
in the past defining top level viewport. as far as I
remember we defined as viewport that is generated by SVG/svg
element. That's the outermost element that creates a box.
Rossen: It essentially lives in CSS/html world and governed by CSS
rules. You can apply anything to that box you can apply to
other boxes. Inside that it's the SVG world. Until you hit a
foreign element that transitions from SVG back into CSS
world and creates a CSS box
Rossen: It's very natural and reasonable to expect both these boxes
would be included in resize observer. If that's explicitly
omitted or forbidden by resize observer we need to adjust
the spec.
<AmeliaBR> `svg:root, *:not(svg|*) > SVG, SVG|foreignObject > SVG {
/* SVG elements with CSS layout box */}`
AmeliaBR: We have clear agreement SVG elements with CSS layout boxes
should be able to observer the CSS layout boxes from
resize observer.
AmeliaBR: Pasted in IRC the definition of those elements as a CSS
selector.
AmeliaBR: Those SVG elements have a CSS layout box and you should be
able to observe it
Rossen: fantasai will this contradict anything you said?
fantasai: No
Rossen: What you mentioned is important. As we add spec around what
we map in terms of boxes and CSS box concepts I want to make
sure we won't add additional confusion.
Rossen: Is that going to be the case?
<fantasai> https://github.com/w3c/csswg-drafts/issues/857 is the
issue where we resolved the box correspondence
<fantasai> See definitions at https://drafts.fxtf.org/fill-stroke/#fill-origin
fantasai: I think it's fine. Since the boxes AmeliaBR mentioned
don't have strokes there's nothing we need to worry about.
But we should make sure specs align going forward
<bkardell> can we punt the things specifically inside of SVG to a
level 2, is that what emelio was asking for ?
<fantasai> bkardell, yes, as long as we're comfortable with how it's
not working right now and that we can change and update
it in the future
<bkardell> fantasai, I think this is the important part - can we
resolve on that?
AmeliaBR: Important thing is when we have the correspondence they
don't override actual boxes. If you have a padding box we
don't defer to stroke bounding box.
AmeliaBR: Aspect without clear agreement is what happens for SVG
elements that don't have CSS layout boxes. Current spec is
they always give regular bounding box. fantasai comments
come down to they should give a specific SVG bounding box
with a direct correspondence to CSS bounding box. My
concern is could be difficult to compute for a fast api
AmeliaBR: The bounding boxes in general, browsers have rough and
dirty calc and precise calc. Rough is for dirty paint
Rossen: Let's take this with SVG WG. If SVG WG has rec for how
resize observer should be defined on non-css boxes let's
discuss later. Want to close those topic
<bkardell> +1
Rossen: proposal: SVG elements generating CSS layout boxes are
included as part of resize observer and resize observer
rectangles
Rossen: Objections?
Rossen: With definition of layout box is `svg:root, *:not(svg|*) >
SVG, SVG|foreignObject > SVG { /* SVG elements with CSS
layout box */}
<bkardell> rossen - is there a second resolution necessary for
punting some of what is in the spec currently to v2
RESOLVED: SVG elements generating CSS layout boxes are included as
part of resize observer and resize observer rectangles
with a definition of `svg:root, *:not(svg|*) > SVG,
SVG|foreignObject > SVG { /* SVG elements with CSS layout
box */}
bkardell: Do we need second resolution to punt some of spec that
deals with stuff that's not that to a v2? I think even
fantasai was saying as long as comfortable with not
working now...I think that's what emilio asked for
AmeliaBR: Right now we have a spec and browsers matching. We don't
have clear agreement spec is wrong. Unless rushing to get
spec to publication why don't we have discussion about
what spec should be and make edits after
Rossen: I would agree. I don't think ready for second resolution
Text Decor
==========
Limits on text-underline-offset to preserve semantic meaning
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4059
jensimmons: text-underline-offset lets authors move up and down,
speaking in Latin. Negative is up, positive is down, 0
is baseline.
jensimmons: Implementation is in Safari and they clamped it to avoid
turning underline into strikethrough. In Safari clamp
was at any negative number and what happens is it
disappears. Implemented in FF behind a flag. When I've
been looking at this the last image in the issue is
best. I think legitimate use cases to let it rise up. Do
we want to have any kind of clamp? Maybe want to prevent
use as strikethrough and have a mid-line clamp. Or we
say no clamp, we'll trust authors.
jensimmons: You can style strikethroughs, though you can't move up
and down.
<jensimmons> https://codepen.io/jensimmons/pen/wLrjGG?editors=1100
jensimmons: Codepen in irc if people want to look at this
florian: I agree with jensimmons. Use cases seem legit and I
wouldn't want to block. If we want generous clamping or no
clamp is different. All jensimmons cases have different
color on underline. If it's same color could be different.
<bradk> +1 no clamping at all
fantasai: We have a shorthand that lets you set both.
Rossen: Making properties depend on each other is not great.
<fantasai> +1 to Rossen
<bradk> Underlines are behind the text and strikethroughs are in
front of the text right?
<astearns> bradk: yes
<jensimmons> bradk — yes. Underlines are behind. Strikethroughs are
in front.
AmeliaBR: I agree these are neat effects. Important to recognize
different text decor have different semantic meanings.
Strikethrough is different then underline.
<bradk> Text decorations are not semantic
<jensimmons> AmeliaBR that's why I explained how strikethroughs can
be styled.
AmeliaBR: Don't want to encourage wrong text decoration because one
has a lot of flexibility in rendering and the other
doesn't. There will always be rendering in less complete
CSS impl. And the basic is on the a11y tree where it's
this is an underline or a strikethrough
AmeliaBR: As far as outcomes for clamping, I don't necessarily mean
need to clamp
AmeliaBR: We want to encourage people to use correct text decor. If
a visual effect is past the point where it really is an
underline it shouldn't be represented by an underline. If
the visual effect is a strikeout it should be using one.
If facilities for a strikeout modification aren't as good
as an underline might be a problem.
myles: Suggesting add same controls on strikethrough?
AmeliaBR: Might be necessary.
myles: Thanks for all these examples jensimmons. I think you've
shown where we draw the boundary is not the right place. It
is important to distinguish between the 2. I think UA should
be allowed to place limits. Perhaps ours are not best
myles: Would be bad if in one browser look struck through and other
looks emphasized. I would prefer a 'should' try and
distinguish between strike through text and underlined text.
Once those limits are agreed can spec
[audio problems trying to get dauwhe's comment. He put his feedback
in GitHub:
https://github.com/w3c/csswg-drafts/issues/4059#issuecomment-510145258
]
dbaron: I was on queue to suggest that given problems we may want
text strikethrough offset sooner. jensimmons said in
introduction that 0 was relative to baseline rather than
initial position. If going to add strike through and maybe
overline offset might have different conclusions of 0
<bradk> +1 Offset overline and strike-though offsetting.
fantasai: 0 depends on text underline position property. It defaults
to alphabetic-ish. If we get specific offset we snap to
alphabetic offset so you have something stable. If you
chose a different position that becomes origin of offset
dbaron: Okay. Given concern...seems likely authors will use
underlines for things not underlines if we give them more
controls then strikethrough and overline. Especially strike
through. I recognize it's a lot of properties but it's work
thinking through.
myles: We've heard plenty of authors asking for underline control. I
know of 0 for strike through and overline.
Rossen: Because they can do it with underline. Only partly kidding.
We don't want to give something where they use underline all
the time
<bradk> Why not text-decoration-offset?
dbaron: Possibly want single property to move all
fantasai: I don't think so. If you have 2 or 3 might not want up by
same amount
dbaron: But 2 or 3 is rare so not clear worth another property
<fantasai> dbaron, text-underline-offset inherits
<fantasai> dbaron, so that you can set it once and forget about it
<fantasai> dbaron, so making it apply to all the lines wouldn't be
very usable
<astearns> I'm a bit worried about hacks to get around clamping -
adding a blank line to the beginning, then giving an
underline a large offset to move it to the next line
below gets you back into the 'looks like strikethrough'
case
jensimmons: I agree with dbaron we should think about strike through
and overline to mitigate abuse of underlines. Maybe they
haven't asked for but lots of things with typographic
get lumped in one giant bucket.
<astearns> +1 to interop - I don't see a big need to allow UA
inconsistency here
<fantasai> +1 to astearns and jensimmons
jensimmons: Also think we should have interop. I don't want too
loose for browsers because could be painful for authors.
If in one browser underline looks great and an untested
browser the underline disappears is dangerous. I think
disappearing is bad. Maybe have it not move so if you
say -10 it clamps and doesn't move.
jensimmons: I would be fine with a clamp if it's a magical mid-line.
Maybe at x height?
<bradk> +1 to dbaron and jensimmons
<AmeliaBR> +100 to clamping (if it is used) being clamping the
offset, not making the underline disappear
jensimmons: Some of the things in the issues like check for color
contrast could get really complex and over engineered
and hard to impl. I want to keep simple and make it
possible to impl. I'm not a browser engineer maybe it's
easy.
myles: One other point is if underlines can go arbitrarily far you
might have to scroll down 5 pages to get the underline. So if
you invalidate one piece of content you have to redraw whole
page.
jensimmons: Makes sense to have a clamp to the line box.
dbaron: I think underlines are ink but not scrollable overflow
myles: Yes, but if page is 3 viewports tall might be at bottom
Rossen: Yeah, I'm with dbaron.
Rossen: Are we considering underlines that are visually...missing
the term but the ones that break underline when something
else is around. Or is this just solid line segments
myles: Skipping in our implementation only considers text the
underline is on. It won't skip next line of paragraph
fantasai: I wanted to agree with jensimmons. Making argument about
if underline should allowed to be higher because we think
so, don't want that clamp. Reasonable distance of text
clamp makes sense. Needs to be able to leak outside line
box, but not by lots. Maybe text *1.5
<jensimmons> +1 for allowing past the line box — yeah, maybe can't
be two lines boxes away or something
<jensimmons> right now, btw, Safari allows any distance down — will
go very far. There's not a clamp yet
fantasai: I think jensimmons case of using central baseline is fine.
myles: For small text it's hard to get underline, like 5px text,
hard to get it in the linebox. Has to have case outside line
box. Some general same clamping is important. Probably not
where our impl does it today.
<fantasai> myles, I'd use the greater of the line box boundary or
slightly outside the descent (e.g. 0.25em past descent or
0.5em past descent)
Rossen: bkardell you're next
bkardell: My questions are big so will ask in another forum
Rossen: I don't think we'll resolve. Meta idea of if we want any
kind of clamping.
Rossen: I remember last time we discussed we resolved to continue
work. Without specific number or formula can we resolve we
want some kind of clamping for underline offset? That way we
know we have a direction and won't have half group say no
clamping.
fantasai: I think need to decide if clamping to enforce
underline-ness or if we're looking for reasonable distance
of text
Rossen: Both require clamping.
<tantek> could it be clamped to the linebox?
<fantasai> tantek, no, because line box can be smaller than the text
<tantek> to resolve the "underline down to page 5" problem
<fantasai> tantek, see my comment to myles above
<tantek> fantasai is there some box that contains the text?
Rossen: In favor of continuing discussion. Can we resolve we want
some clamping as part of underline offset either to enforce
semantic meaning of underline or to keep it within visual
distance
bkardell: I heard different things talking about semantics. I don't
know that someone can explain what they mean in a minute.
The semantics seem wishy-washy
<florian> I want clamping for one, not the other, so I'm not sure
what to do about a resolution to clamp for either...
fantasai: We all agree clamping withing reasonable distance of text
is something UA can do
AmeliaBR: If we allow visual effects, we allow them. I don't see a
reason to clamp in either direction.
<astearns> box-shadow not clamping is a good argument against not
clamping here
<tantek> I'm (a little) worried about the effect on printing, e.g.
do text decorations count as part of widows and orphans
computations?
Rossen: Let's continue that in the issue.
<bradk> -/+ 1em clamp
fantasai: Can we resolve on being able to clamp within range of text?
Rossen: That's what I was pushing for.
<dbaron> I'd note *normal* underlines often extend outside the
font's bounding box at the bottom
<dbaron> (especially if they're wavy, etc.)
fantasai: Just resolving a clamp to keep line in reasonable range of
the text
<bkardell> I'm fine with that much
<tantek> would prefer more discussion before a resolution on this -
that seems too wishy washy
AmeliaBR: I have an objection. I don't see that as a strong
argument. Paint can be all over page from box shadow.
<tantek> defer resolution please
jensimmons: It's after the hour, I think need to do another time.
Rossen: We'll do that next week.
<florian> I would like to encourage people who care about
white-space:pre-wrap and its end of line effects to look at
https://github.com/w3c/csswg-drafts/issues/3869 and
https://github.com/w3c/csswg-drafts/issues/3440 (myles,
koji)
Rossen: Thank you everyone, we'll continue next week.
Post Meeting IRC Conversation
-----------------------------
<jensimmons> Dave said (in the issue, since his phone didn't work) I
worry that clamping can result in a bad author
experience. It's quite frustrating when you change the
value of a property but there is no visible change.
Even worse is changing a value of the property and the
line disappears.
<jensimmons> More generally, why is CSS now restricting what authors
can do? I can create unreadable text in a thousand
different ways. CSS gives authors tremendous power, and
talented people can use features in unexpected and
beautiful ways. Is it the role of the CSS Working Group
to say that some designs are OK, and some designs
shouldn't even be possible?
<bradk> jensimmons: I agree with you.
<bradk> After wavering just a bit
<tantek> jensimmons, I can see clamping of text decoration related
stuff being useful for implementations being able to do
more sane things with pagination
<tantek> e.g. trying to keep text and its decorations "together" and
not broken across page breaks
<jensimmons> You should write these comments in the issue, everyone:
https://github.com/w3c/csswg-drafts/issues/4059
<jensimmons> and to be clear, I was quoting dauwhe above ^^ (in the
very last comment)
<fantasai> tantek, I AmeliaBR was the one arguing that there
shouldn't be any clamping
<tantek> I wrote it as part of the chat during the topic in the
call, so it should make it into that log
<fantasai> tantek, no your point about page breaks isn't in the
log... I think it's a good one though :)
<tantek> I said "I'm (a little) worried about the effect on
printing, e.g. do text decorations count as part of widows
and orphans computations?"
<tantek> as a specific example of pagination concerns. that's enough
of a hook IMO
<tantek> also wondering if there is a need for a new term besides
linebox that actually encloses all the text (ink?)
generated by that line box
<bradk> clamping for performance and memory management should be OK.
For example, not allowing an underline to be a thousand
miles from the text.
<tantek> since per fantasai, text can go outside its linebox
<fantasai> tantek, maybe. Hasn't been needed so far, but we haven't
defined line layout that closely yet
<tantek> bradk, beyond performance, just trying to keep an underline
with its text like on the same page
<fantasai> tantek, it is clear that line boxes and their contents
can't fragment, though
<bradk> Yes, I didn’t think ink overflow got paginated
<tantek> fantasai what happens when contents of a linebox exceed the
page box?
<fantasai> tantek, gets clipped
<fantasai> tantek, or sliced, if the UA prefers
<fantasai> https://www.w3.org/TR/css-break-3/#possible-breaks
<AmeliaBR> I think so far we just talk about this as ink overflow of
the box. Doesn't affect breaks or pagination as far as I
know. But, I can tell you that at least some browsers do
ugly things where they let the paint from one box get
sliced across a column break and show up at the top of
the next column, and that should definitely be something
we discourage!
<bradk> text-decoration-break: clone|slice ?
<fantasai> Seems like we should specify that ink overflow doesn't
get paginated. I don't think that's been made explicit
anywhere
<fantasai> files https://github.com/w3c/csswg-drafts/issues/4099
<jensimmons> tantek There are definitely places in
https://codepen.io/jensimmons/pen/wLrjGG?editors=1100
where allowing the underline to go beyond the "ink
area" of a line box — and into the inked area of the
next line box, would be fine. I would want to allow
such things.
<fantasai> jensimmons: So maybe the clamp should be max(line box
height, font height) + font height?
<fantasai> jensimmons: alternately 2*max(line box height, font
height)
<jensimmons> How about (2 * max(line box height, font height) + font
height) ?
<fantasai> which is slightly looser
<jensimmons> jinks!
<jensimmons> or 3*
<fantasai> jensimmons: that's three times the height of the text?
<jensimmons> I can't imagine any reason to beyond 3x
* fantasai can't imagine any reason beyond 2x
<jensimmons> maybe 2* does it
<fantasai> once you're one full line height below the bottom of the
line box...
<fantasai> I think you've lost any visual association with the text
<bradk> Is the thickness of the line clamped?
<jensimmons> oh yeah, playing with my demo, I can't see a reason to
go beyond 2x
<fantasai> no, it can be zero. Hence the max against font height
<bradk> If the line thickness is 4em, then don’t clamp the offset to
less than that
<fantasai> oh
<fantasai> I thought you meant the line of text :)
<fantasai> Yeah
<bradk> Reasons we can’t imagine are not necessarily bad reasons
<fantasai> you're right, we need to account for that.
<jensimmons> fantasai Are you formulating a specific proposal in
your mind? To drop into the issue? I think that'd be
good.
<bradk> Wavy lines are also thicker than straight lines
<bradk> I mean, they take up more vertical space
<jensimmons> WAVY
<fantasai> Spec says “The line is aligned to the outside of the
specified position.”
<fantasai> So, clamping the offset wouldn't clamp the outer edge
<AmeliaBR> Reason to have an extreme offset underline: Fancy heading
with mildly obnoxious hover effect that causes an
underline to appear, but it doesn't just appear it slides
into place from offscreen. I'm not saying it's good
design, I'm just saying that once you allow animated
underline offset distances, some designer is going to
want to take it to the extreme.
<jensimmons> also, we haven't articulated whether the clamp measures
from the outside or inside edge of an underline line.
Potentially very thick line. Maybe it's obvious to
folks, but I'm not clear.
<fantasai> AmeliaBR: That's a case where the designer might equally
want it to slide in from the left or the right
<fantasai> AmeliaBR: And that's not even possible here
<fantasai> AmeliaBR: That's a use case for some different way to
create the line, I think
<fantasai> jensimmons, see spec quote above
<jensimmons> an underline that slides in is just wrong. people
aren't going to try to do that
<jensimmons> people *are* going to animate this line
<jensimmons> they are already asking me about it
<jensimmons> like a very slight movement up or down on hover
<bradk> People can be very creative, and I don’t want to stifle the
creativity with artificial limits
<jensimmons> could start at 0.5em offset, and move to 1em offset on
hover
<tantek> web designers will use overlines and underlines as
alternative borders
<tantek> or alternative to outline-top and outline-bottom
<bradk> Could be used as an offset solid background too
<tantek> graphical effects you can position without affecting layout
<jensimmons> gotta go. meeting. bye
<bradk> Bye
Received on Wednesday, 10 July 2019 23:43:54 UTC