- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 19 Feb 2020 19:51:48 -0500
- 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
property.
- 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
===== FULL MINUTES BELOW ======
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
half-leading
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
behavior
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
line-height
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
borders
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
interoperable
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
now
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
position)
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
vertical-align
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
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=7710
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
text-top/text-bottom/etc
<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
inlines
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/
below
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:
https://lists.w3.org/Archives/Public/www-archive/2020Jan/att-0009/IMG_6676.jpg
]
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
baselines
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
first-line
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
now
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
implement
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
size?
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
chart
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
` ` 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
paragraphs
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
good
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
behavior
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
textbooks
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
alphabet
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