W3C home > Mailing lists > Public > www-style@w3.org > February 2020

[CSSWG] Minutes A Coruña F2F 2020-01-24 Part II: CSS Inline, CSS Text [css-inline] [css-text]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 19 Feb 2020 19:51:48 -0500
Message-ID: <CADhPm3s6y9uAvS2UPWQuU9KV5cMpWLgJ8FoeRtLSb4fFQ6GFng@mail.gmail.com>
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.

CSS Inline

  - RESOLVED: Spec that text-top/bottom and background boxes of
              inlines ought to match (Issue #3978: Make `text` of
              `leading-trim` interoperable?)
  - RESOLVED: Make leading-trim's text value match the same value for
              text-top/text-bottom/etc (Issue #3978)
  - RESOLVED: leading-trim applies to inlines by changing the content
              box edges (Issue #3955: Apply leading-trim to inlines?)
  - RESOLVED: Use shape-margin on initial letter when shape-outside is
              none and `initial-letters-wrap: all` and 'first' (Issue
              #4171: initial-letters; feedback from implementation)
  - fantasai and faceless will go through issue #4171 and break still
      open questions into separate githubs
      - Faceless will add more details for how item #3 in Issue #4171 (
          Alignment and font-sizing) can be achieved without the
      - For item #6 in Issue #4171 there is a proposal to set some
          initial-letter calculations against the used font-size which
          will be discussed further during breaks.

CSS Text

  - RESOLVED: Atomic inlines by default always introduce a break
              opportunity, regardless of context, at least for
              line-break: normal (Issue #4576: Atomic inlines being
              equivalent to ID for line breaking is not web-compatible)
  - RESOLVED: Mark this section at risk, and close the issue (Issue
              #4445: Writing System prose is currently unimplementable
              on ICU)
      - Florian will file an issue with ICU


Agenda: https://wiki.csswg.org/planning/galicia-2020

Scribe: emilio

CSS Inline

Make `text` of `leading-trim` interoperable?
  github: https://github.com/w3c/csswg-drafts/issues/3978

  <fantasai> https://drafts.csswg.org/css-inline-3/#leading-trim-property
  fantasai: We have some proposals in the early-brainstorming phases,
            and one of them is leading-trim which allows you to
            visually align some text so that it's aligned with the top
            of an image or such
  fantasai: There's several values like cap-height x-height etc
  fantasai: and the normal one which is laying out the text and then
            add the half-leading
  fantasai: but there's also leading-trim: text which doesn't add the
  fantasai: koji pointed out that these metrics don't have interop
  fantasai: so if we did trim out the half-leading above and below the
            text we'd probably get no interop
  florian: Can you clarify what's not interoperable? I think unless
           you use line-height: normal stuff should mostly match
  fantasai: Different browsers use different font-metrics
  fantasai: I don't have a solution and don't understand the full
            issue from koji, but I hope we can close it somehow

  koji: In the current implementation stuff is not interoperable. I'd
        like to ask about jfkthame and myles' opinion if any
  jfkthame: I don't have an answer here, it's not clear to me there'd
            be any useful metric for text-top value because the
            metrics in font vary considerably across fonts
  jfkthame: So the ascender in a font may or may not what you actually
            want. It may correspond to the ascenders of some glyphs,
            but it may instead have been defined to allow for accents
            are such
  jfkthame: so that's probably not what you want as a designer
  jfkthame: Not clear there's a good answer
  fantasai: There's vertical-align: text-{top,bottom}, we should
            probably be consistent with them
  jfkthame: I'd bet that's not interoperable
  koji: jfkthame is right, but even with the same font Chrome picks
        different ascent behavior in mac / windows to match platform
  koji: I'd like browsers to match at least given the same font binary

  faceless: We've been trying to figure out what browsers do
  faceless: We find different behavior between FF and Chrome when a
            font specifies a zero line-gap in OS/2
  faceless: Not sure if this is about
  fantasai: That's probably the answer for why line-height:normal is
            not interoperable. But this feature should probably not
            use line-gap anyway

  myles: There's content out there that places elements so that they
         match up what the browser does... Whatever we do, let's say
         we add some switch to have an interoperable metric. It
         probably can't be default behavior
  fantasai: This is opt-in
  <fantasai> initial value is normal, which just does the usual thing
             with half-leading and whatever
  stantonm: I think if you give authors the ability to do this even
            for a particular case of having a font it'd be nice
  myles: There are three ascent/descent pairs in fonts, I don't think
         we want three options
  koji: I agree... Any specific set you can accept?
  myles: Not particularly, I just have a general aversion to parsing
         font files, and any interoperable solution requires code that
         parses font files, and that makes me sad Myles
  hober: In terms of a general principle I think there's a good thing
         that browser engines can rely on other platform frameworks
  hober: the job of parsing fonts is the job of the font library not
         the browsers
  fantasai: Can you pull out the cap height and such metrics?
  myles: I think the best answer is we work very closely with CoreText
  fantasai: One of the goals of these features is exposing the values
            the font author has chosen, the remaining issue is that
            which metrics are not interoperably chosen across
            platforms, so we'd hit the issue of authors hitting
            different results on different platforms

  fantasai: I have two related concerns here: Can we give authors an
            interoperable way to strip the half-leading? If not, can
            we strip the half leading without stripping down all the
            way to the cap height?
  myles: Not 100% sure about the question but I don't think we can
         change default text rendering
  fantasai: We're not proposing that
  fantasai: One of the features that we drafted is that you remove the
            half leading so that you get to align with the specified

  fantasai: I think we have two options, either figure out an
            interoperable metric
  fantasai: or drop this value
  <fantasai> https://drafts.csswg.org/css-inline-3/#propdef-leading-trim-over
  florian: Right now, the total size you have after the leading is well
           defined, but the leading itself is not interoperable so we
           don't know the starting point

  fantasai: There's several places where the top and bottom edge of
            the text comes into play
  fantasai: one is vertical alignment
  fantasai: the other is when we're trying to draw backgrounds and
  fantasai: So the content box edges of the inline
  fantasai: I don't think that's well defined, either
  koji: Canvas TextMetrics exposes this but I don't think it's
  fantasai: The last one is vertical-align text-{top,bottom}
  fantasai: but I don't know what they do
  fantasai: so I don't know what to put in the spec
  myles: So if text layout is different between browsers, is it so bad
         that these new properties are also different between
         browsers? We're already in this world
  fantasai: I think authors want a little bit more control /
            consistency about what's happening in the documents
  fantasai: The other thing is that I'm supposed to write the spec for
            these things, and I don't know what to put in them right

  dbaron: myles has asked about the lack of interop. I think that
          causes real bugs for minority browsers
  dbaron: Like cases where a minimal amount of space perturbs the
          whole layout (e.g., if going from 20px high to 21px high
          bumps into a float and moves it to a totally different
  dbaron: We do hit these things occasionally, probably a bit less
          during the last few years, probably because of the choice of
          layout techniques people are using lately is changing
  RossenF2F: But that's not true for the long tail of the web
  <RossenF2F> +1 to dbaron
  dbaron: There's another source of lack of interop (which we
          discussed when we last met at Keio University in Tokyo)
          about how you deal with all these sizes for text / inlines
          when these things have multiple fonts in them
  dbaron: Sort of the same points fantasai mentions but even more
          complicated and less interoperable
  dbaron: so probably worth separating it

  fantasai: We can also drop the feature of leading-trim that allows
            you to drop the half-leading
  fantasai: but I'd still have the issue of text-top/text-bottom in
  florian: With flex / grid people can do more robust design and
           they're more likely to start trying improve typography, and
           then these interop differences are more likely to come up

  fantasai: What do people do for text-top / text-bottom?
  hober: myles described a simple way to do this with information you
         already have in the engine. Can we specify that as a baseline?
  RossenF2F: What's that?
  myles: That's using the ascent / descent that you already have
         during text layout
  RossenF2F: That feels like "keep doing what you're doing", which may
             be fine but I want to clarify what you're trying to say
  myles: I agree that interoperability is good
  myles: but I think there are constraints that make that difficult
  florian: So this is about using text-top/text-bottom, whatever
           they're currently doing right?
  florian: But that's exactly about what this issue is about
  koji: I think we need at least one interoperable value
  koji: so that authors can have control

  <fantasai> testcase for content-edge vs vertical-align: text-top

  myles: In some other issue I proposed somewhere else is additional
         descriptors in @font-face
  myles: that the browser could use
  faceless: For fonts that have incorrect info that'd be of huge help
  myles: and that also allows avoiding to parse font files
  hober: That is a good idea, I think
  koji: I'm fine with that
  florian: So you'd add descriptors for where the text-top /
           text-bottom are and the browser would use these values
  florian: everywhere
  florian: Seems worth looking into
  myles: It's in some comment of some issue a long time ago, can dig
         it up
  florian: If we manage to characterize how these behaviors differ we
           could let authors choose
  myles: That'd reintroduce the problem of parsing font files
  fantasai: So we should open an issue about this against fonts-5, and
            that'd get rid of the interoperability problem

  fantasai: The other thing is how we define how to use these metrics
  fantasai: At least in Firefox on Linux the text-top edge seems to be
            the same as the background of the inline, so if that
            happens in other platforms we can specify that they have
            to match
  fremy: They don't seem to match in Chrome
  florian: It matches here
  koji: I think it can change across OSes
  fantasai: Does it match on Safari?
  florian: Yeah, looks like
  dbaron: They don't see to match by a pixel in Firefox here, but
          might be a pixel-snapping issue
  fantasai: I'd like to resolve that text-top and the background-box
            of inlines use the same metrics
  fantasai: Can we resolve that they ought to match?
  <fremy> (I want to clarify, that neither Chrome nor Firefox do match
          on my Windows device)
  <dbaron> (I see a 1px mismatch for the serif example.)
  florian: So the non-matching behavior is something we want to fix?
  dbaron: We could try to understand why they don't match first
  RossenF2F: But the intent is pretty good modulo bugs/rounding issues

  RESOLVED: Spec that text-top/bottom and background boxes of inlines
            ought to match
  RESOLVED: Make leading-trim's text value match the same value for

  <tantek> both really hoping this works / happy to see this from a
           web author perspective, and frankly a bit suspicious about
           odd pixel compat issues that will show up when this stuff
           gets tweaked in implementations
  fantasai: We should try to request vendors to describe what's
            happening to have better spec text

  <florian> On my system (macOS 10.14, FF72), Firefox matches at all
            zoom levels except 110%, where there's 5px difference on
            the "serif" part of the test case

Apply leading-trim to inlines?
  github: https://github.com/w3c/csswg-drafts/issues/3955

  fantasai: The purpose of leading-trim is to change the top/bottom
            edge of a block so that you can make more useful alignment
            of block
  fantasai: May be useful to make it apply to inlines
  fantasai: so that you can change the edge of the background boxes of
  fantasai: Right now people try to find padding values to make text
            look centered
  fantasai: this property allows to control the edge of blocks, but we
            could make it apply to inlines too
  fantasai: This wouldn't affect layout, because even right now when
            you add block-axis padding / borders to an inline it
            doesn't affect the position of the inline or content above/

  dbaron: Feels like making this apply to inlines make people use
          backgrounds on inlines reliably, so it seems good to me
  <florian> +1
  dbaron: Particularly noting that it doesn't affect the line-height
          calculations, only the content-box
  koji: This proposal looks like we're trying to change text-top based
        on something which sounds like a circular dependency
  koji: with leading-trim
  fantasai: Well not really, this allows to override the content edge
            of backgrounds, I don't think it's inconsistent or circular
  koji: So leading-trim: cap will only affect the background?
  fantasai: If set on a block it changes the position of the line
  fantasai: but I propose that when you're using it on an inline it
            only changes the edge of the background
  [ blackboard time:
  koji: I want to ship the block part first so I'd prefer this to be a
        separate property
  koji: so that authors can detect support for it with @support
  fantasai: We have the same issue with alignment properties
  fantasai: it's not great
  dbaron: I think it's a little risky to do that, but it's allowed
  dbaron: but I think once you have it working for one type it
          shouldn't be a lot of work to have it working for inlines too
  koji: If the WG is fine with use shipping the block part first
        that's fine for me
  fantasai: Yeah seems better to have an awkward transition than
            needing a property per box type
  koji: It's a bit risky...
  fantasai: Backgrounds on inlines are fairly uncommon

  iank: I don't think you could detect this via script
  fantasai: You coud, it'd change getBoundingClientRect()
  fantasai: It wouldn't change layout because the layout of an inline
            doesn't depend on the content area
  fantasai: but you can observe it via script

  RESOLVED: leading-trim applies to inlines by changing the content
            box edges

initial-letters feedback from implementation
  github: https://github.com/w3c/csswg-drafts/issues/4171

  faceless: we implemented initial-letters, it works broadly
  faceless: I think it should be simplified to work in non-latin
  faceless: The way it's currently defined is that you specify the
            number of lines that is supposed to cover and the amount
            that it's supposed to shift
  faceless: The second parameter is redundant
  faceless: We already got the ability to shifts baselines up / down
            using baseline-shift
  fantasai: I think there are a bunch of issues in this issue and we
            should take one at a time

  faceless: Sure. you can't add margins around the initial-letter...
            You can add some padding to the right
  faceless: but it's not great with varying shapes
  fantasai: So proposal would be to apply shape-margin only when
            wrapping around the glyph shape
  <dbaron> sounds reasonable
  astearns: So for the rest we apply shape-outside
  fantasai: Interaction between shape-outside and initial-letter is tbd
  fantasai: but you can wrap around the glyph
  astearns: Makes sense to use shape-margin when shape-outside is none
            and `initial-letters-wrap: all`
  <florian> sounds good to me

  RESOLVED: Use shape-margin on initial letter when shape-outside is
            none and `initial-letters-wrap: all` and 'first'

  <fantasai> (we're skipping issue 2 in the issue, because it's
             covered in https://github.com/w3c/csswg-drafts/issues/719 )

  faceless: (describes issue 3)
  faceless: I think the text about the alignment points is not relevant
  faceless: once you drop the letter on the first-line it fits right
  fantasai: You need the second value of `initial-letters` for raised
            or sunk caps, that's what it's for
  <dbaron> I think this doesn't work both because it's hard to match
           the correct size, and because you need to control which
           lines wrap around the initial letter.
  faceless: I can try to demonstrate you can achieve the same effects
            without that value

  hober: I'd really love it if didn't file giant issues like this so
         that we can clear where the discussion is separately
  hober: this style of bug-filing is very hard to follow
  <tantek> +1 hober
  RossenF2F: That being said all the detail is awesome

  faceless: Let's move to issue 4... You can have atomic inlines as an
            initial letter, is that allowed? Otherwise it needs to be
            clarified how to align these
  faceless: We discussed about having baselines on svg which would
            solve this problem, probably
  fantasai: We have an attempt to synthesize baselines for boxes
  fantasai: so cap-height corresponds to top-height of the box
  <fantasai> https://drafts.csswg.org/css-inline-3/#initial-letter-box-size
  <fantasai> For atomic initial letters, sizing follows the usual
             rules for that type of atomic inline. However, if the box
             has an automatic block size (auto), then its block size
             is determined as for an inline initial letter with
             border-box alignment, and is definite.
  chris: This has come up before for images
  myles: #4116 is the baselines in images
  <chris> https://github.com/w3c/csswg-drafts/issues/4116
  myles: issue I filed a while ago
  iank: This is not only for images right? Other atomic inlines
  fantasai: I think the spec says how to size the box
  fantasai: so if you set an explicit size on an atomic inline you get
            that size
  fantasai: If the size doesn't match the amount of space you use the
            alignment properties to align it in that space
  faceless: I suspect that'd probably do it for now but probably
            should be explicit about how baselines work
  fantasai: Agreed

  faceless: Issue 5
  faceless: The spec allows for inlines as initial-letter
  faceless: The initial letter uses font-size not the computed size
  faceless: so if you use superscripts or what not it produces really
            odd results

  Scribe: fantasai
  Scribe's scribe: emilio

  <fantasai> on issue 6
  faceless: If you have inlines as part of initial letter, e.g. a
            superscript in 1st, it doesn't scale up with the rest of
            the initial letter
  emilio: What you're proposing is some weird inheritance behavior in
  emilio: If you have span in first-line, it inherits from ::first-line
  fantasai: There's regular element initial letters, and
            ::first-letter first-letters
  fantasai: If can't have element in ::first-letter, then it's not a
            problem there
  fantasai: but for regular elements, shouldn't be a problem to
            inherit like usual
  faceless: Should set the computed font size based on initial-letter,
            so that it will inherit as usual and affect the children
  emilio: Not great, because a lot of stuff depends on font-size right
  emilio: Would need to compute based on initial-letter
  dbaron: Might be able to specify the desired results without
          changing computed value of font-size
  dbaron: Might be more difficult to specify, but more realistic to
  emilio: Can you set the initial-letter size in em units
  faceless: No, it's derived from the algorithm
  florian: The algorithm gives you the size of the glyph, if we say
           therefore this must affect the font size, do browsers agree
           on which font size you get from that
  fantasai: You have requirements for that calculation, to use
            specific metrics
  fantasai: Like, my line-height is X or Y, and the alphabetic-baseline
  fantasai: that's all deterministic
  fantasai: Assuming everyone pulls the same metrics

  florian: Is there a really a single font-size that gets you the
           right size?
  fantasai: Yes
  fantasai: There's only one cap height metric
  dbaron: modulo rounding issues
  <dbaron> https://wiki.csswg.org/spec/property-dependencies
  emilio: But the computed line height depends on the computed font
  emilio: Think it's more reasonable to not affect the computed value
          and then do something, but...
  florian: Don't need the line-height/font-size of the initial letter,
           but of the paragraph
  emilio: But not easy to find that value at the time you're doing
          style computation
  emilio: You cannot get to the containing block, you can get to the
          nearest non-"display: contents" thing...

  dbaron: It's not super clear to me whether what you're proposing
          would make the computed value of font size on layout
  dbaron: but even if it's not, still refer you to this dependency
  dbaron: If you're proposing to add something, make sure it doesn't
          create a cycle
  dbaron: font-size is one of the most basic dependencies
  faceless: It definitely doesn't depend on layout
  florian: Computed font size of initial-letter would not affect the
           line height of the parent paragraph, so no circularity
  florian: The computed line-height of the initial letter affects
           nothing, so the loop stops here
  emilio: Affects nothing if you don't add lh units or other things
          that are proposed
  florian: If you're trying to set the border of your initial-letter
           to 0.1lh, you can use it, but won't have ripple effects
           that mess up everything
  emilio: I still think getting to the right parent paragraph's
          line-height is not trivial
  florian: The alternative would be to say that within the
           initial-letter, a specific set of things do math against
           the used font-size instead?
  emilio: You would need some kind of multiplier, which seems OK
  emilio: You need to multiply by the ratio of the font-size of the
          initial letter to the computed font-size
  florian: I'm not concerned about having the ratio, I'm concerned
           about the whitelist of what it applies to
  florian: Not understanding the difficulty of inheriting through...
  fantasai: Discuss at break?

  [Issue 7]
  Scribe: emilio

  faceless: Inline boxes don't take width/height anywhere else,
            doesn't seem like a good idea here
  fantasai: The reason we did this is that you can't make an atomic
            inline into an initial letter it doesn't resize the font
  fantasai: The content of the inline-block that is an initial letter
            are not affected by that
  fantasai: What this does is you do the resizing of the glyph as usual
  fantasai: but then you also define the size of the box
  fantasai: This was requested by tantek, to handle the case of
            colored boxes with initial letters in them, want the boxes
            to all be the same size
  faceless: Alright, scratch that then
  astearns: It'd be nice to have a note/example in the spec

  faceless: number 8
  faceless: I'm ok dropping this
  dbaron: Can I suggest that the issues that are viable after this
          discussion should become separate issues?

  ACTION: fantasai to go through the issues after doing the spec work
          and split the remaining issues

CSS Text

Atomic inlines as ID for line breaking is not web-compatible
  github: https://github.com/w3c/csswg-drafts/issues/4576

  florian: It's specified in CSS text that atomic inlines are
           equivalent to ideograph
  florian: but apparently authors expect that there would be a break
           where breaks would usually be forbidden between a break and
           an ideograph
  florian: (See https://bugs.chromium.org/p/chromium/issues/detail?id=1025715 )
  fantasai: I'm sad about this
  fantsai: There's a number of cases where images should behave more
           like characters
  fantsai: and if we always break stuff like gaiji
  fantsai: Will typeset badly
  hober: If it's possible for authors to write content to do the right
         thing and we have consistent behavior
  hober: then we should put that on the spec and indicate how to tweak it
  fantasai: The current spec behavior doesn't match implementations
            but it's easy to tweak into solving all the different use cases
  florian: If we treat images like ID then you can use standard
           properties to allow it to break
  florian: otherwise we can't control breaking
  myles: Well I agree we should solve it but we can't solve this this
         way because it's not web-compatible

  fantasai: We could reuse the line-break property
  fantasai: and make the strict value make atomic inlines as ID?
  faceless: So this seems like the breakness depends on the image
  faceless: Can we set a property on an image?
  <fremy> (for the record, +1 to what faceless just said)
  florian: line-break on the image would tweak this
  fantasai: The `line-break` property is exactly about the
            interactions between breaks and punctuation so I think it
            makes sense to reuse the strict value here.
  <fantasai> there are wrap-* properties in css-text-4 that allow
             control over breaking, to forbid or allow
             unconditionally, but they're not context-dependent on
             surrounding punctuation, so they're not appropriate for
             this situation

  hober: I like the shape of fantasai's compromise here... I think
         there are a couple open questions but I think that's the
         right direction
  hober: I'm still kinda leaning for it to be a different property,
         but mostly for aesthetic reasons
  hober: I'm concerned with the compat effect of reusing strict
  hober: I'd be willing to agree that we should do something like this
  hober: but whether it's the strict keyword or a new keyword should
         probably have some kind of research
  fantasai: I think not a lot of pages use line-break strict
  fantasai: and they're likely CJK which are more likely to need this
            behavior anyway

  koji: I'd like to combine line-break: normal with this behavior
  fantasai: You can have your paragraph with line-break: normal, but
            the images with line-break: strict
  koji: What about inline-block? Those are a block inside
  fantasai: I suspect those are much less likely to want this behavior
  florian: I think we could make the lossy image breaking behavior if
           we use `line-break` != `auto`
  florian: That way it'd just work... non-default line-break is weird

  florian: Widening the scope of the issue a bit, is that there's
           another issue with breaking around images, which is that
           `&nbsp;` around it behave like normal spaces
  fremy: When I try to solve this myself is just putting a span on the
         break elements, but doesn't seem to be interoperable
  RossenF2F: Also there's a lot CJK elements
  <fremy> testcase: <nobr><img /></nobr> https://jsfiddle.net/4rL9jh8t/

  myles: I like that you can select the gaiji with a selector
  myles: koji makes a really good point
  myles: When I think about line-break values I think about text and
  myles: not images and inline-blocks
  fantasai: I think we can go with florian's proposal
  <astearns> I'm less enthusiastic about having a text property modify
             the behavior of images as a side-effect
  <emilio> astearns++

  myles: Some people may want the break on the left of the image
  fantasai: We have controls for that in level 4
  myles: Can this use them instead?
  fantasai: No you can't, because those are not contextual
  fantasai: but opting in to treat this as an ideographic character is
  fantasai: The level 4 properties are unconditional
  fantasai: Emojis, small kana and such things these images should be
            treated like this
  fantasai: which is why it fits with line-break
  myles: I'd like some more time to think about this
  myles: maybe a way to tell an image which kind of text it wants to be
  myles: I also think it's important to get the default behavior in
         the spec agreement with implementations

  RESOLVED: Atomic inlines by default always introduce a break
            opportunity, regardless of context

  ACTION: Investigate using the line-break property to tweak this

Writing System prose is currently unimplementable on ICU
  github: https://github.com/w3c/csswg-drafts/issues/4445

  florian: So css-text that says that line-breaking can be changed
           language behavior
  florian: Most impls use ICU
  florian: but the spec says it should depend on the writing-system,
           not just language
  florian: and nobody does it
  florian: My feeling it's we'll get there slowly, and it's just not
           implemented yet
  florian: Unless we have an objection against it I think we should
           keep it in the spec

  hober: Do you think ICU has a bug?
  florian: Whether it's a bug or a feature is fuzzy but sure
  fantasai: I think we don't want to remove that restriction just
            because ICU doesn't implement it
  hober: I think we should file an ICU bug and if they wontfix remove
         this from the spec because everybody uses ICU
  florian: Seems reasonable
  stantonm: I thought ICU took the BCP-47 language tag as an input,
            which includes script
  fantasai: They do but they ignore the script part
  astearns: Should we mark this at risk pointing to the bug?
  hober: Given we're dependent on ICU here I agree

  koji: Is there any use case for this?
  koji: I see the spec point of view but don't see any
  fantasai: There are different languages that can be written in
            multiple writing systems like Japanese or Chinese
  fantasai: they use Latin letters, so you don't want to format them
            as Chinese
  koji: But justification / font-selection / etc don't change by
        writing system
  koji: it probably should change
  florian: Justification does change in the Arabic / Cyrillic
           languages sometimes
  florian: if you have a book that's written in Japanese-Latin you
           shouldn't use a Japanese font
  koji: That seems fine to me...
  chris: A better example, Turkish used to be written in the Arabic
  chris: Wouldn't you want to use an Arabic font for old turkish?
  <dbaron> some other examples might be Mongolian, Tajik, or Uzbek
  <dbaron> (Tajik and Uzbek, according to Wikipedia, have had 3
           scripts at different times: Arabic, Latin, and Cyrillic.)

  jfkthame: I'm totally in agreement about filing a bug against ICU
  jfkthame: but I disagree with the idea of ripping it out of the spec
            if the bug is wontfix
  jfkthame: I think this is correct behavior and browsers could
            implement it with additional processing on top of ICU
  hober: Goal of the spec is interoperability, if the ICU bug is
         wontfix it'd be science fiction

  ACTION: florian file a bug with ICU on this

  jfkthame: Firefox is not using ICU
  jfkthame: and we'd like to fix this
  faceless: We implement this correctly also

  RESOLVED: Mark this section at risk, and close the issue

break: lunch
Received on Thursday, 20 February 2020 00:52:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:15 UTC