W3C home > Mailing lists > Public > public-houdini@w3.org > May 2019

[CSSWG] Minutes San Francisco F2F 2019-02-27 Part III: Getting images' aspect ratio right from html attributes, CSS Inline, Houdini <3 Text (aka Houdini and text layout) [css-inline] [houdini]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 16 May 2019 18:55:26 -0400
Message-ID: <CADhPm3uo_kr=9T3HE7G+bN_G2qJ5-bnUgMDiwVcvhkiuLf6-Cg@mail.gmail.com>
To: www-style@w3.org
Cc: public-houdini@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.

Getting images' aspect ratio right from html attributes
    (continued from Monday)

  - After a few days to think about the proposal as there was no
      consensus on what was the best way forward - add new attributes
      (original plan) or do property mapping (new plan).
  - Chrome is committed to investigating further and will analyze both
      approaches before selecting one and putting the work into WICG.

CSS Inline

  - RESOLVED: We'll add a separate property for this [first/last
              baseline values of `vertical-align`] (Issue #861: Should
              first/last baseline values of `vertical-align` belong to
              `alignment-baseline` or separate longhand?)

Houdini <3 Text (aka Houdini and text layout)

  - There are several different paths the group could take when
      Houdini builds its API for interacting with Text (Houdini Issue
      #854). These range from a region-like API, where your content
      flows from one box to the other to exposing glyph indices and
      font metrics through the API. These approaches also come with a
      similar range of potential for footguns.
  - Widely the group leaned toward collecting use cases and solving
      the safest of them first (that still would have broad usage)
      before extending the API further.
  - Exposing justification was one possible first step. Another
      possibility was a property set to assist minority languages such
      as what's being done in Graphite and AAT.
  - Work will continue one scoping out a preliminary feature set and
      drafting a proposal.

CSS Text

  - RESOLVED: Add the stable value [to text-wrap] (Issue #672: Allow
              for paragraph-level line breaking)


Agenda: https://wiki.csswg.org/planning/sf-2019

Scribe: argyle

Getting images' aspect ratio right from html attributes
    (continued from Monday)

  florian: My understanding is that we all agreed this would be a good
           idea if possible, and we should check if possible
  florian: Tab disagrees, I want to hear that
  florian: For context: "it" is using the width and height HTML
           attributes to trigger the intrinsic aspect ratio
  fantasai: Specifically, where we map the width and height HTML
            attributes to width and height CSS properties, we could
            also use them to calculate the ratio and also map that
            back to CSS (using the new aspect-ratio property).
  fantasai: That would solve the problem around the aspect ratio
            information would be lost due to waiting for the image to
            load, waiting to discover auto sizing
  fantasai: so the proposal was to do that instead of introducing new
            attributes to solve the same problem
  Rossen: What is the data we need to gather then?
  florian: So we don't break the web
  Rossen: For the width and height
  florian: Do we not agree?

  TabAtkins: Having width and height be presentation attributes, and
             not affecting those new and exciting ways
  TabAtkins: The other reason I liked it, some of the other things,
             like picture, you wanted to give an intrinsic size to
             them, and it feels semantically better to be specific
             about being intrinsic than doing css things that also set
             intrinsic sizes.
  florian: There's no intrinsic tools to do this
  * fantasai thinks ojan should be here
  <AmeliaBR> +1 to Tab's argument about `<picture><source
             intrinsicsize="...">` making more sense than width &

  myles: What about canvas?
  myles: We should consider the interaction with canvas where w and h
         have other meanings other than mapping to css
  TabAtkins: It sets the backing store on width/height, which is

  dbaron: ... If this is a major thing sites can do to improve
          loading, if a cms can just do this, that's great, and it
          means that lots of sites can get it cheaply
  dbaron: I think, if it's it's own attribute it we can do that, I
          don't think it's as safe to do if we're re-using width and
  florian: If the cms wanted to check if there was previously a width
           and height, they could still inject the w/h and multiply by
           what's needed, but they also need to check min-height and
           max-height, and then it gets messy

  astearns: We're theorizing about things Ojan has experience in, at
            the most this conversation should inform what he continues
            to do as he tries to find a solution
  astearns: but I'm not sure I see the utility of theorizing when we
            have an experimenter
  florian: Utility is we don't need to experiment if we have other
           demos, not worth checking if we don't want to do it anyway

  <TabAtkins> `<style>img { width: 100%; }</style> <img
              intrinsicsize="350x450">` works by default. Changing it
              to <img width=350 height=450> doesn't work; you have to
              manually set `height: auto` in CSS too.

  jensimmons: I think the original intention behind what fantasai was
              saying, here's an idea, might be much simpler than
              adding new attributes, we'd like this considered
  jensimmons: I do think there's a way to do it that hooks into CMSes
              and existing things, instead of making it more
  jensimmons: If only width is coming out of a cms, and there's no
              height, there's no mapping to intrinsic, we can map with
              that limited data
  jensimmons: Maybe there's something more complex needed, and we do
  jensimmons: But I think there's an elegance here tapping into what
              we already have. Perhaps that's what ojan is intending
  jensimmons: Hey, we're going to solve some of this in css, and to
              have that really heard, .. that's what I'd like to see

  Rossen: Where does this leave us?
  jensimmons: Sounds like someone's going to find something out
  AmeliaBR: I think it's great, we're leveraging something that
            already works, but I think I agree with the arguments
            there's too many cases where things can get messy for
  AmeliaBR: If browsers implemented the attr() function that maps
            values to lengths, ... any image, grab these values,
            put them together, here's the ratio
  AmeliaBR: Not sure if there's utility if no one's has implemented it
  <jensimmons> +1 to what AmeliaBR just said
  <jensimmons> maybe that could even be included in a project called
               CSS Remedy
  TabAtkins: I feel like there's just more discussion, but in the way
             of being explicit with cases and approaches, and I don't
             know if I want to spend time trying to nail it down

  fantasai: There are advantages of using existing attributes. Like
            for images in pages already out there, we get the faster
            layout/loading for free. Info is already there
  fantasai: No updating cms, no html file updates, it would let
            browsers hook into it via current functionality
  jensimmons: There's 100,000s of sites that put height and width on
              images in the CMS already. Then in their code, put
              width: 100%; height: auto in their CSS. Decade of work
              is built that way, and likely aren't maintained
  jensimmons: Quick way to boost all sites by re-using existing attrs
  jensimmons: Don't get deep into picture element, ..., hey this is a
              performance thing, but it back in and it'll be faster
  jensimmons: Other proposals will use it for be used for simple and
              complicated things, and some it'll be too much
  fantasai: Historically, we've asked users to put weight and height
            on images for performance, all the way back into the 90s,
            and we'd be hooking into that advice. This proposal hooks
            into existing content and knowledge better. It won't only
            work on new things developed by people who keep up with
            latest tech.

  TabAtkins: Happy to do more discussion, but not confident enough to
             decide now, or for us.
  chrishtr: Maybe we could break out and talk about it?
  chrishtr: I don't think I fully understand, and I'd like time for

  Rossen: Okay so, I didn't hear that say the HTML width and height
          attributes is the worst idea I've ever heard, we shouldn't
          do it
  Rossen: I also didn't hear we shouldn't think about the intrinsic
          aspect ratio, because it'll just work
  Rossen: TabAtkins has committed to work on this fully
  TabAtkins: Chrome people will be working on this
  Rossen: Kidding aside, we'll close this issue for now. Thanks for
          introducing it to the working group, and making it an actual

  Rossen: I think there was another bit in this, which was css
          property, which will then have to map using either the
          height or width attributes, as a ratio, or whatever else is
          there, if anything is added as an additional attribute
  Rossen: I think the property can be discussed at a later point, or
          is this something you want to discuss later today
  fantasai: It's already in the draft, we resolved to add awhile back
  jensimmons: So this discussion about not doing other things in HTML,
              just stuff we've already talked about
  jensimmons: There will be more to talk about aspect-ratio with
              min-height and min-width
  jensimmons: There is a question of: do we put in what's there
              already in the draft, support for ??, whether it's
              happening in the UA style sheet, we do have the ability
              to grab information about height and width
  jensimmons: Might be right in between, and I think we should do what
              Rossen mentioned
  Rossen: Great point, thank you. Before we move on

  AmeliaBR: I have a question: it's not being proposed by a web group.
            Before we get a css spec, we need to get that moving up
            into the HTML wg, so it's outside our scope, so long as
            it's going through process and getting standardized.
            chrome pushed it without standardization, we need to make
            sure that happens
  TabAtkins: Definitely should be in wicg - we'll get it there

CSS Inline

Should first/last baseline values of `vertical-align` belong to
    `alignment-baseline` or separate longhand?
  github: https://github.com/w3c/csswg-drafts/issues/861

  dauwhe: No opinions
  fantasai: Ditto
  fantasai: This issue keeps coming up because I don't have any points
            in favor or against either options, and I'd like to hear
            why we should pick one over the other
  fantasai: Do we have the board, do you want the [..] baselines,
            [fantasai explains the problem]
  fantasai: When aligning inline boxes to each other, you first match
            corresponding baselines, then you shift if there's an
  fantasai: Once one of those has multiple lines of text in it,
            do we use first or last? We wanted to add keywords to
  fantasai: Do we put it in it's own property,
            align-baseline-preference, and it cascades independently?
  fantasai: Or do we merge it with alignment-baseline, which chooses
            the type of baseline (alphabetic, mathematical,
            ideographic, hanging)?
  AmeliaBR: Reminder: long hands exist for legacy compat. So svg had
            alignment-baseline, baseline-shift, css had
            vertical-align...they describe the same functionality but
            behave slightly differently
  AmeliaBR: ..., adding new features to the longhand, when it's just
            for compat, seems questionable. Also, not sure how first/
            last would work in SVG. I don't see benefit there
  [fantasai outlines things on the easel]
  fantasai: We can't just add values to the vertical-align shorthand:
            they need to be part of a longhand, too. So if there's a
            reason to choose one over the other, it'll help us resolve
  AmeliaBR: New property may not be used

  fantasai: Related issue: from the MATH ML folks, they want to take
            the baseline not from the first or last item, but from a
            specific item
  [See https://github.com/w3c/csswg-drafts/issues/1339 ]
  fantasai: So that ties in a little bit with this. We don't have a
            proposal, but we have an idea we should do it. So that
            might tie into we end up with another that helps us solve
            this as well.

  AmeliaBR: I suppose the value of a new property is that vertical
            align is already supported with current functionality
  AmeliaBR: you may end up with duplication anyway
  fantasai: Does anyone want to think about it more, or push it off to

  dbaron: I can imagine there's reasons you want them separate,
          unknown how important they are. Consider multiple
          languages [...]
  fantasai: Alright, we have a reason, we can resolve the issue!
  dbaron: I'm not convinced anyone will want to do this, but it does
          seem like a good thing to do
  dbaron: You might want to set alignment-baseline as a function of
          the language without messing with the first/last choice set
          for other reasons
  AmeliaBR: Resolve to make a new longhand property
  astearns: We figure the name out later
  fantasai: No matter how silly, make suggestions in IRC, we'll
            evaluate later
  <astearns> best-baseline
  <dauwhe> good-baseline | better-baseline | best-baseline
  <TabAtkins> west-baseline
  <AmeliaBR> baseline-line

  Rossen: Okay, any other opinions that can top dbaron's?
  Rossen: Anyone object to dbaron's proposal? or oppose?
  Rossen: No objections. Resolved.
  astearns: So, dbaron, could you put your actual suggestion into
            resolve line
  dbaron: The question was a boolean, do we want a separate prop or not

  RESOLVED: We'll add a separate property for this

  astearns: Great
  fantasai: Thank you

Houdini <3 Text
  Scribe: emilio

Houdini and text layout
  github: https://github.com/w3c/css-houdini-drafts/issues/854

  myles: So, houdini has a lot of stuff, and I think everything is
         things that browsers do already, which is cool
  myles: There's one of these things that is not in houdini so far,
         which is text
  myles: so there's a chance that authors are going to want text layout
  myles: There's a lot of ways this could go. Text is complicated, and
         different to other parts of houdini, in the sense that (a)
         it's pretty easy to get wrong and (b) if it is, users will be
         misled and confused
  myles: It's easy to get it wrong when things like how BiDi works
         should work by default, we don't want authors to have to
         remember how to do these
  myles: There's a bunch of things like that listed in the issue
  myles: so I wanted to discuss how should we approach such an API to
         avoid causing pain

  myles: A strawman proposal just to get the discussion started would
         be a region-like API, where your content flows from one box
         to the other, and regular CSS properties apply in that box
  myles: That'd be very high level. Another approach would be to
         expose glyph indices and fonts and let the author place all
         of them
  myles: I think that'd be bad
  <fantasai> +1 to that being bad
  myles: So, there are these two extremes, these high-level things,
         and there's this low-level thing which we can agree it's a
         bad idea. There's a range in there that we should figure out

  AmeliaBR: (summarizing her comment in the issue)
  AmeliaBR: (https://github.com/w3c/css-houdini-drafts/issues/854#issuecomment-459146355)
  AmeliaBR: There's a lot of steps, like [...], that we need to break
            this down into.
  AmeliaBR: Within all the individual steps which happen during text
            layout, we need to figure out which of them authors want
            to customize. One of them could be justification
  AmeliaBR: other things like bidi unicode stuff we don't want to ever
  AmeliaBR: We could expose (though maybe trickier) glyph selection
           (sounds scary, but there's lot of fun stuff you could do
           with OT glyph selections instead of having to create a new
           font because you want to create a space-maximizing layout)
  AmeliaBR: That's something that people may want but that is easy to
            get wrong / break
  AmeliaBR: Also, the steps are very dependent on one another, so we
            need to come up with a nice model of the data that goes
            through the pipeline if we want authors to insert their
            custom stuff
  fantasai: This is not just a sequential pipeline, some of the steps
            interact with each other. An excellent line-breaking
            engine will account for glyph selections and such
  fantasai: so you can't just break that up into ordered steps

  iank: I think we agree in spirit with myles, we don't want to get
        into the business of bidi resolution or glyph selection or such
  iank: We may want to get smarter about where to break and such, but
        not atm
  iank: The current model in the spec is a box where you run layout
        giving the available width and you get back an inline box /
        line box fragment
  iank: You can re-request that if the resulting height is too big for
        your layout
  iank: Some layouts require the available width to change on a
        per-line-box basis
  iank: We want to prototype that
  myles: So, I also agree that we mostly agree
  myles: The idea of giving available width works well if the area has
         vertical end, but if you're not a perfectly vertical
         container it doesn't, it's not clear how much we care for
         shapes in Houdini
  iank: We care about shapes a lot
  iank: In our engine we do at most two layout passes to avoid shapes
  iank: which sort of fits in this model
  myles: I think doing two layouts is unfortunate, describing geometry
         would be nicer
  iank: That'd be difficult, a lot of the use cases that devs want to
        place a line depending on how the previous line has been laid
  iank: I think describing all the geometry upfront would be limiting
  iank: One of the examples we want to work is an arbitrary line grid
  iank: The avail width of the next line really depends on the line
        height of the previous line box

  dauwhe: My industry is very interested in using Houdini to improve
          justification / hyphenation, since the browsers have
          different requirements

  florian: I share the concern that this is important and hard to let
           people do a lot of random stuff
  florian: but Dave shared examples about hyphenation and
           justification, and there are many more of the same kind of
           when you consider i18n where a lot of effects needs a lot
           of low-level access
  florian: For example, Japanese people may want to increment distance
           between some glyphs or such
  florian: or implement stuff that isn't in browsers yet
  florian: The approach of getting line boxes doesn't get far enough,
           but I'm not sure how to get far enough but not being
  myles: You're right, but we have competing desires, letting authors
         implement nice effects, and making pages legible, the latter
         has been historically more of a priority
  <fantasai> +1 to ensuring legibility

  fantasai: Side comment, about justification and the model that is in
            Houdini, which I agree is the right one to get started.
            For justification would it make sense to return the
            fragment without filling the available width, but also let
            the user set it to be wider and that'd trigger
            justification and alignment
  fantasai: That way I can see where it fits much more easily, and
            position it more easily
  fantasai: and justification and alignment properties would work the
            same way it works when you place it in a bigger size.
            Justification would still be in control of the user-agent
  myles: dauwhe, when you said for example you wanted to improve
         justifications, is ^ what you were referring to?
  dauwhe: I think we want more

  Rossen: Thanks for bringing the issue, and I'm glad it's getting
          more and more traction. The one common theme that I see so
          far is that we are trying to get the "custom" part of layout
          out of custom layout. Everything that's been discussed so
          far how to force people to do the thing what we're already
          doing and tweak it a bit here and there
  Rossen: The nice thing of custom layout is that we're not giving
          restrictions for where people to position boxes in the block
          layout case, but when it comes around text we through our
          hands in the air and say it's too hard, and I don't agree
          with that
  TabAtkins: We have existence proof that every single custom layout
             has done bidi wrong.
  Rossen: It seems to me that we're talking about levels of
  Rossen: one where you expose bidi and shaping at every breaking
          opportunity, the other where you give it a box and we'll do
          the layout inside
  Rossen: I'd be interested to go and explore the options in the
          middle which would allow most custom layouts that people want
  Rossen: so that we're still not insisting on that rigid one box
  Rossen: We're also assuming that we're doing inline layout the way
          browsers do it now, but maybe my lines are spiral, or I want
          to go on top of floats
  Rossen: Let's not try to take the custom part of layout outside
          of css

  dbaron: I just wanted to bring up another use case that hasn't come
          up today
  dbaron: I think having a low level API is very important for
          minority languages
  [general nodding]
  dbaron: Gecko has shipped graphite support
  <dbaron> https://en.wikipedia.org/wiki/Graphite_(SIL)
  dbaron: One of the things it does is let languages that have shaping
          requirements that aren't in browsers do it in fonts instead
  dbaron: Another approach for this would be a low-level JS API using
  <dholbert> (I believe "glat" is one of these graphite font tables
             that dbaron is referencing)
  <dauwhe> "For example, it may be the case that a minority language
           is tonal, while the national language is not, and the
           orthographic solution involves using the standard writing
           system with some extra diacritics to indicate tone. Or the
           minority language might have a set of sounds characterized
           by a certain linguistic feature, such as aspiration or
           breathiness, that are not present in the national language,
           and the desire is to add to the standard orthography a set
           of variant characters to represent these variant sounds."
  dbaron: I think that's a potential real use case

  skk: From Japanese digital books perspective, more precise Ruby
       would be amazing
  skk: We'd like more control over ruby text positioning
  <xfq> more than what ruby-position/merge/align currently provides?

  dauwhe: Responding to the philosophical point, being able to explain
          and expose all the platform features?
  Rossen: It is, what I'm saying is, let's not prevent that
  Rossen: So that we can avoid limiting the inner pinnings of how
          things work. Said that, we want to open the engine so that
          we don't need to implement all the stuff people want, that's
          the fun part of it.
  Rossen: We've never said "and we don't want to let you do this
          because it's hard"
  Rossen: why?
  myles: If your layout is quite not what the author intended, the text
         still exists. For box layout, bad layout is wrong for
         everyone; for text, bad layout can be completely unreadable
         only for some
  Rossen: If it's unreadable it's unreadable because of me
  fantasai: It may be because somebody typed something you (the Houdini
            author) didn't expect
  fantasai: and you didn't care of thinking of those users
  fantasai: and those users are our users
  Rossen: That's my problem, those users are going to complain to me

  koji: From my POV I think "don't do bidi and don't you your own
        thing" is more "we want to start from simple things", and as
        we can confirm it performs properly and works we can extend
  koji: but I'm not very confident that JS running through glyphs is
        performant enough, so box-level layout seems simpler
  koji: so re. Rossen's point, we're not against, but we want to start
        from the simple thing

  AmeliaBR: I agree with Rossen and dauwhe, the point of Houdini is
            being able to tweak one of the little things the browser
            does without having to re-implement the browser, and we
            want to let authors do what they want
  AmeliaBR: You can do some sort of custom layout with SVG, but
            probably badly. We should let authors do what they want
            without forcing to reimplement what they don't want to
  AmeliaBR: I think we should prioritize our work to start with the
            safest things to change and isolate
  <dauwhe> I want to tweak what the browser does, not build my own
           rendering engine
  <skk> +1 to dauwhe
  <heycam> Agree with AmeliaBR -- we should bias towards coming up
           with APIs that allow users to benefit automatically from
           the browser implemented bidi, complex text shaping, etc.
           features that the author doesn't want to reimplement
  <heycam> make it harder for them to accidentally not support those

  florian: So, I think when we say is "this is too hard", this is not
           saying that devs in this room are smarter than all of them.
           But very little people have resources to implement all the
           complexities right
  florian: Very few people have the business justification to deal
           with all languages
  florian: Minority languages is where this is interesting and
  florian: The low level things that enable minority languages to work
           on the web, are also what enable companies to write
           western-only layouts that don't work with other minority
           languages that browsers support today
  florian: In the process of creating an api that's good enough to
           support minority languages we'd have created the chance of
           Chinese pages where you only can write in Chinese, or
           English pages that allow you to only work in English
  florian: So if you force people to rebuild text-layout itself, they
           will not do the right thing, and we'd have disabled some
           languages instead of enabling others
  florian: So I'm more on the side of caution, and making sure that
           everything we add to this API is a thing we can tweak
  <fremy> very good point florian
  florian: And yes, people will break stuff for their own customers,
           but we'll also break the fact that the web is multilingual

  fantasai: I think koji and AmeliaBR and florian said everything I
            wanted to say

  myles: Most of my job is fixing bugs that the text experts in the
         piece of software they created because they only spoke English
  myles: There's tons of places in WebKit where there are assumptions
         because it was coded by English-only speakers
  myles: I agree we should investigate the middle parts in the
         spectrum, but I think we disagree with the criteria for
  myles: I think text is different, where if you get it wrong it may
         work for you but not for your users
  myles: An approach where we take everything the browser does and
         making it scriptable is not the highest priority
  myles: Raising use cases is a good way to prioritize, the idea of
         tweaking specific parts of the browser is great and makes
         total sense
  myles: Picking specific use cases and filing in holes is probably
         the right idea, creating a low level platform and tell people
         to write it yourself is probably not
  <florian> +111!1!1
  <fantasai> myles++
  myles: Minority languages is a very interesting case, apart from
         Graphite we also have a similar thing with AAT
  myles: I wish we could find a way to solve that problem in a way
         where safety is preserved

  Rossen: I see a lot of passion and interest, zero reasons for us to
          stop working on this. A lot of things said will hopefully be
          taken into account as we move forward. One thing that I
          wanted to make sure that the record reflects what I said.
  Rossen: I wasn't suggesting to start exposing the far end, like
  Rossen: but as we go forward we should start walking towards the
          end, I just want to ensure that we don't preclude us from
          going forward
  Rossen: Myles, is there something that you think it wasn't discussed?
  myles: I think the next thing is gathering use cases, so we're done

  iank: To try to wrap up, is there anything inside of the current
        version of the spec that particularly scares you?
  myles: My biggest concern is about encouraging authors to do layouts
         in loops
  myles: where they try over and over, but I understand such an
         approach allows for dynamic use-cases, so I guess the
         question is to which side we fall
  iank: I think we agree, but we don't want to limit people which is
        why we chose this approach
  myles: We heard a lot of use-cases in this discussion that aren't
         covered by the API, so maybe it's too early to create APIs
  Rossen: We have a proposal and we have a lot of discussions, let's
          not say yay or nay

  dauwhe: I wanted to make a point regarding the responsibility about
          us making software for our use case vs. browsers
  dauwhe: We publish English and Spanish, I don't think there should
          be obligation for us to handle vertical or rtl
  * dauwhe admits that some of our books have snippets of Arabic,
           Hebrew, Japanese, Chinese, and MathML :)

  AmeliaBR: I'm glad myles brought this discussion
  AmeliaBR: One thing that myles and fantasai said is that text was
            different because it made stuff unreadable
  AmeliaBR: I don't think that's true, there are lots of ways you can
            break content in another ways
  AmeliaBR: I agree with Rossen that the developers of the websites
            are responsible for being user friendly and would be the
            ones to pay the price. I don't think that this proposed
            ways which could break websites are worse that other ways
            to break stuff with CSS
  fantasai: I think it is actually worse
  <astearns> I disagree with AmeliaBR's comment, and agree with
             fantasai. Bad text layout has uniquely bad ways of making
             content inaccessible

  <fremy> iank myles: I do have some ideas on how to progressively
          enhance the current api to cover more cases that have been
          discussed here without starting from scratch and would like
          your opinion, so maybe we can talk about this during break?
          or in the github issue if not.

  Rossen: This is not the end of the discussion, but some of the
          starting points
  Rossen: We need go back and work more on this, we should keep
          participating passionately
  Rossen: Next steps is engaging in the specs
  Rossen: So go help iank ;)
  iank: I'd love that

CSS Text

Allow for paragraph-level line breaking
  github: https://github.com/w3c/csswg-drafts/issues/672

  myles: Similar to houdini, there are lots of different ways to do
         line-breaking. Houdini solves some of them. Other ways people
         want to do line breaking are some fancy book-like
  myles: ine-breaking on the web is greedy, and doing something
         slower but higher quality is a longstanding request
  myles: I proposed a value for this, which got to the spec and then
         got removed because of lack of consensus
  myles: I'd like to see which opinions for this
  myles: it's a very high-level switch
  <xfq> will the behavior be UA-defined?

  florian: I want to know which one is the editing value
  florian: I want one of the values to be stable when you type
  <astearns> default is 'wrap' which is stable
  myles: Right now the default is stable in every browser
  florian: Not for print [PDF renderes like PrinceXML and AntennaHouse]
  myles: You don't type in print preview
  myles: I don't think you need another value, we already have it
  florian: I think there should be a stable value
  myles: I think reflecting reality and saying that auto should be
         stable is fine
  fantasai: I think the initial value should allow the UA to do

  dauwhe: If the property is added to iBooks I'll add it everywhere
  fantasai: I think iBooks should just add it to its default UA
  [ compat? ]
  dauwhe: I think you want to change it in existing books too
  dauwhe: Having the text break better is just going to be a win

  eae: I think this is a great idea, I'm a bit concerned that if we
       don't define what pretty does we'd get interop issue, so we
       should try to explain what pretty would do
  <xfq> https://github.com/w3c/csswg-drafts/issues/803 is the related
        issue for the algorithm ("pretty")
  myles: In the issue I listed a dozen different criteria
  myles: So describe it explicitly is probably not realistic, do you
         think agreeing on the goals is fine?
  eae: yeah, I think that's ok
  fantasai, dauwhe, myles: I think it's important to _not_ get compat
  <AmeliaBR> There will always be perf trade-offs, so that it makes
             sense that a print book will get prettier `pretty`
             results than a browser on a low-CPU device.

  heycam: I was going to make eae's point, though maybe I'm a bit more
          worried about the compat impact, I don't we can change the
          default algorithm because of compat, why wouldn't that
          happen with `pretty`?
  astearns: The current algorithm is not that interoperable
  myles: Also, this is an opt-in
  heycam: Once we have this, why would we not expect authors to just
          use it all the time. Why would they not do that?
  myles: It's the same answer for text-rendering: optimizespeed vs.
  fremy: It's mostly useless
  myles, AmeliaBR: it's not
  heycam: I don't think people will think about speed, and many people
          will just use it without thinking about it, having a perf
  astearns: I think that's the reason for the auto value
  astearns: so that the UA can change it
  heycam: I'm skeptical about changing line-breaking (by default)
  myles: I'd like to keep the discussion less about the existence of

  dauwhe: I think there are a lot of trade-offs. Browsers are optimized
          for speed right now, and taking any step to opt in to better
          systems is going to be great regardless of interop
  dauwhe: text layout is so sensitive that there's never going to be

  myles: I want to resolve to put this value back in
  Rossen: Objections?
  florian: I want to make sure we have the three values, including
  fantasai: I think we should rename it, but no objection
  fantasai: I'm a bit concerned that we are going to add another
            switch that does nothing
  fantasai: but if people feel strongly I won't object
  fremy: not an objection either but we need a better definition on
         what it does

  RESOLVED: Add the value back in

  fantasai: Are we adding stable?
  myles: There are three values: auto, balance and this new thing
  fantasai: I object to the multi-line name
  myles: Proposals?
  fantasai: 'pretty' sounds good to me
  fantasai: It's what we used to discuss it here

  RESOLVED: add the stable value
Received on Thursday, 16 May 2019 22:56:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:53:28 UTC