- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 10 Jul 2019 20:06:47 -0400
- To: www-style@w3.org
On Wed, Jul 10, 2019 at 7:42 PM Dael Jackson <daelcss@gmail.com> wrote:
>
> =========================================
> 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.
Correction, this is issue #4059
> - 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 Thursday, 11 July 2019 00:07:46 UTC