- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 26 May 2017 20:42:42 -0400
- To: "www-style@w3.org" <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 Grid 2
----------
- The group reviewed the subgrid section of Grid
https://www.w3.org/TR/2017/CR-css-grid-1-20170209/#subgrids to
come to a common understanding of how it stands right now.
- fantasai to clarify that subgrids with orthogonal flows have rows
and column axes flipped within the subgrid, just as with nested grids.
- The current subgrid text will be moved to level 2 and then
fantasai will update the text.
- RESOLVED: Publish FPWD Grid Level 2 with the inline issue
pointing to the discussion of independent subgrid axes
CSS Fonts 3
-----------
- RESOLVED: Move CSS OM section from Fonts Level 3 to Fonts Level 4;
Leave CSSFontFaceRule existant with a note explaining the
current inconsistent state of specs/implementations.
- ChrisL will port Gecko font variant tests into WPT.
- RESOLVED: dbaron's explanation above will go into the spec for
min/max font size. (Explanation: They affect the
computed value of font size, so they affect em units.
therefore, em units on these properties work just like
em units on font-size and thus use the parent's
computed font size.)
- RESOLVED: First Public Working Draft of Fonts level 4 will be
published. Chris to handle the request.
- RESOLVED: Add a font-language-override descriptor to Fonts L4.
- High-DPI font rendering creates a problem with reftests relying
on Ahem; this needs investigation.
https://lists.w3.org/Archives/Public/public-css-testsuite/2017Feb/0001.html
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics
Scribe: fantasai
Grid
====
Subgrid
-------
[Images referenced in this section are available here:
https://lists.w3.org/Archives/Public/www-archive/2017Apr/0004.html ]
[Rossen reviews what a grid is]
<rachelandrew> https://github.com/w3c/csswg-drafts/issues/958
<rachelandrew> https://github.com/w3c/csswg-drafts/issues/796 is
the issue referring to auto placement and named
lines
<rachelandrew> i put some subgrid notes here
https://4075834c10a34498ade2a927666cc81a.codepen.website
Rossen: Also good to have a way to group things in a grid
Rossen: Don't remember subgrid discussions
Rossen: We started discussing subgrid and how it could work, but
wasn't until later it made it in the spec.
Rossen: I believe first version had ability of snapping of grid
items in only columns and not rows or vice versa.
Rossen: So allowing subgrid to allow overriding one of the two
dimensions of grid.
fantasai: I think first version was both axes together, and then
we split it out later (and then merged it later).
[Rossen describes weird overflow columns cases]
jet: Feedback from mats isn't that A is better than B, but that
current version is written to get to CR
jet: and some normative text was lost there.
<fantasai> [A: split axis; B: current version]
Scribe: tantek
fantasai: We didn't lose any normative text.
fantasai: There were some changes to simplify things, like
changing how overflow was handled
fantasai: changing one case to see what implementations picked up
on-
fantasai: we didn't lose any interesting aspects of subgrid,
other than single-axis subgrids, at Igalia's request.
fantasai: The thing that was confusing people was a subgrid that
had more rows & columns than the # of rows or columns
it spanned in the parent grid.
fantasai: I don't consider that to be significant feature.
fantasai: In terms of significant use-cases
fantasai: it was more like we need to deal with this case so we
defined something
fantasai: and people were like this is scary
fantasai: (flippy window use-case).
fantasai: We didn't lose anything except independent axis
subgridding (that was significant).
Rossen: If we look at the current version that is in the draft, it
snaps to areas of the parent grid
Rossen: it does not affect any of the area of the columns or rows
Rossen: it acts as a grouping mechanism.
Rossen: In a sense you can draw a parallel between subgrid and
non-BFC blocks in a block layout.
Rossen: They are there to just group things nicely
Rossen: like document layout defines paragraphs, and divs can put
borders around them.
fantasai: It doesn't establish a new grid formatting context.
fantasai: It continues with the old [it's parents] grid formatting
context.
Rossen: I took a look at scenarios in the office.
Rossen: At some point this is something that has to be done by
every engine
Rossen: measuring the sizes of things inside
Rossen: arranging things, align things
Rossen: (stages).
Rossen: If we take those stages
Rossen: how does subgrid affect measuring?
Rossen: If we assume all rows and columns are auto
Rossen: they have to snap to content.
Rossen: Extreme case: one subgrid, no items, but has border.
Rossen: I'm trying to highlight the fact that subgrid contributes
to measuring rows and columns by its MBP.
<fantasai> https://www.w3.org/TR/2017/CR-css-grid-1-20170209/#subgrids defined in item c
Rossen: The width height min-width max-width and other sizing
related properties are forfeit because it snaps /
stretches to the areas of the grid that were defined.
Rossen: However if everything was empty and the parent grid was
auto, then it will be the size of the subgrid's borderbox.
fantasai: Then what's not perfect.
fantasai: If it's perfect we publish it.
Rossen: First we have to define min & max widths are not applied.
Rossen: Currently spec only talks about height and width.
Rossen: The other thing that is not covered is overflow.
fantasai: That's specified item h
fantasai: width and max-width etc. are item f
fantasai: Any specified width and height constraints.
TabAtkins: That includes min and max.
Rossen: And there are no gaps.
Florian: The overflow is defined as you may do it so...
TabAtkins: But it is defined in terms of layout effects.
TabAtkins: It is still well defined how it and the parent grid get
laid out accordingly.
Rossen: Do we honor position relative?
fantasai: I don't see why not.
Rossen: Can that be a container ...
fantasai: Yeah.
Rossen: What about position absolute.
fantasai: then it is no longer a subgrid, it is a grid.
TabAtkins: It is no longer participating in the grid's layout.
fantasai: If it is not itself a grid item then it becomes a grid.
many: It's still not a grid item.
Rossen: So then, when we go to auto flow all the grid items as
well as the items of the subgrid?
Rossen: What order are we taking?
Rossen: My assumption is depth first search.
fantasai: Auto placement happens inside subgrid.
fantasai: The subgrid has an explicit position by its start end
and grid-position properties
fantasai: before you even look at its contents you know how many
grid areas it takes up.
Rossen: That's not what I was asking.
Rossen: Now that we have positioned the subgrid
Rossen: then we position the items of the grid.
TabAtkins: No the subgrid items.
Rossen: Hold on-
Rossen: let's say that I have in the parent grid G, I1, SG has I2
and I3.
Rossen: So let's say I1 is placed at 2,2 where it overlaps the
subgrid.
Rossen: So now I'm doing auto placement of items.
Rossen: I've come in here, processed everything else
Rossen: then the first item outside the subgrid has to be placed.
fantasai: The subgrid is taking up that spot, so you can't place
it there with auto.
TabAtkins: The subgrid is also a grid item so it takes up space
like any item.
Rossen: Why not do depth first? So we can auto place?
fantasai: A lot of the time you want to place stuff inside the
subgrid, then auto place others.
TabAtkins: Subgrid sometimes because you want a border around that
area.
TabAtkins: You are yourself an independent chunk of content.
fantasai: You have to treat the subgrid as a nested grid.
Rossen: we could consider placing the subgrid more transparent
Rossen: and place other items.
(unparseable from Rossen)
fantasai: It should behave like a nested grid.
fantasai: The only difference is instead of an explicit set of
lines, you are aligning to the lines of the parent grid.
fantasai: They want alignment but they want that subgrid item to
be an atomic thing.
Rossen: I can live with either of those.
TabAtkins: subgrid is just a nested grid, and ...
Florian: You placed your block analogy too far.
TabAtkins: Another interesting question, your subgrid has
auto-placed items, your parent grid places an item on
top of the subgrid, what happens?
Rossen: What I heard is that you can place two grid items on the
same area.
TabAtkins: Even if the parent grid places an item explicitly, you
can still auto place the subgrid's sub-items on top of it.
Rossen: So, writing modes:
Rossen: If this was a LtR grid and the grid inside here says RtL
that should just work.
Rossen: For vertical / orthogonal changes, where the subgrid
changes.
Rossen: So let's say the subgrid was not square, like 2x3.
Rossen: If I change the subgrid so that it is orthogonal to the
parent, what happens?
fantasai: We need to clarify that.
Rossen: On other words I would be surprised that in tables we do
that.
Rossen: So that to me is the same.
ACTION fantasai clarify that subgrids with orthogonal flows have
rows and column axes flipped within the subgrid
<trackbot> Created ACTION-842
Rossen: So if I say an item is at 1,2 then it is here and not here.
TabAtkins: That always works.
TabAtkins: What is not defined is your horizontal span becomes
your row count.
fantasai: We can clarify it.
Rossen: Alignment should work fine.
Rossen: What about align-self on the subgrid.
fantasai: That's also in item f
fantasai: because we ignore all sizing stuff
fantasai: alignment triggers shrink to fit, so we turn it off for subgrids
Rossen: In terms of drawing, any implications to stacking context?
fantasai: Same as a nested grid.
Rossen: So none.
Rossen: Can we allow repeat on a subgrid.
fantasai: No because you are taking your rows and columns from the
parent.
Rossen: Do we need to be explicit?
fantasai: We already say ignore grid template properties, that's
item a.
(discussion clarification)
Rossen: With all of that, we are happy with how subgrid is
specified currently, and I would like to hear from others.
rachelandrew: I think mats concern is locking it to both
dimensions, and I have a concern with that too.
rachelandrew: What I'm seeing people expect what subgrid to do, is
columns locked to the grid, and not the rows because
they'll be adding content there.
TabAtkins: There are use-cases but it makes the algorithm so
complicated.
fantasai: I don't think we tried (to write it down).
rachelandrew: I think that's what mats was asking for.
TabAtkins: I couldn't figure it out.
TabAtkins: The Igalia folks were like LOL no we can't do this.
TabAtkins: Plus my French co-worker,
TabAtkins: our original grid implementer,
TabAtkins: julien,
TabAtkins: he was also like no.
fantasai: We are creating a new FPWD here.
fantasai: If it helps I'm happy to take a try at defining a
one-axis grid, just so we can see what that looks like
fantasai: if that would make Mozilla happier
fantasai: it might not be as scary once defined.
rachelandrew: What I'm hearing is that people expect that subgrid
will work that way.
Rossen: What is the use-case?
rachelandrew: People are thinking grid like bootstrap 12 column
grid
rachelandrew: and then things on that top level are using that
rachelandrew: like a bunch of products.
rachelandrew: You know how many columns you want
rachelandrew: but you don't know how many rows you'll use because
that depends on content
rachelandrew: there's also like the BBC home page.
Rossen: Is it the case where you start with a subgrid
Rossen: I have one item, it goes no problem
Rossen: now I have another item, and then the expectation is that
the subgrid will grow?
rachelandrew: Yes. People have these layouts that are used for
multiple things.
[fantasai draws a picture]
[6-column master grid on the page; header has several rows of
stuff with different interesting spanning stuff; main section
has a 2-column wide sidebar and a 4-column wide main section]
[it's unknown how many rows of auto-placed content is in the main
section, but the sidebar has to span it all, so it needs to
span 1 in the parent grid and the main section takes the main
parent's column divisions, but subdivides into as many rows as
needed for auto-placed items]
tantek: I heard a proposal from fantasai to try to write it down
so why are we still arguing?
rachelandrew: This was the issue that mats was pointing to and
that he wants discussed, and I would agree.
rachelandrew: I think subgrid is important that we get it.
rachelandrew: If we have it locked to two dimensions it is not
what people are expecting subgrid to be
rachelandrew: when I talk to regular developers.
Rossen: What if I go subgrid in a subgrid?
Rossen: If I have a subgrid that takes only the columns, and
inside of it I have only one subgrid that takes only rows.
[fantasai and Rossen draw and discuss at the whiteboard]
fantasai: We have parent grid which is black lines, we have a
subgrid (blue lines) which cares about columns but not
rows, it spans 3 columns, it makes its own rows:
fantasai: like four rows for example.
fantasai: It has some items
fantasai: and then it has a subgrid itself
fantasai: which cares about the rows from its parent, but not
columns.
fantasai: So it takes the rows from its parent, so it gets two
rows, and then it defines its own columns, and it has
maybe like a lot of columns.
fantasai: So now we have to do the grid sizing.
fantasai: The placement is a nested structure
fantasai: so it looks at this one this one this one [points at
diagram]
fantasai: but doesn't care about this (two nested subgrid).
fantasai: When it asks the subgrid to figure out how big are you
when you are spanning your columns
fantasai: it takes its columns from the parent so it won't resize
those
fantasai: but I have four rows so...
fantasai: so then I have four rows, one item in this one, two in
this one, one item plus a spanning item in here
fantasai: it does row sizing there
fantasai: so when it asks it ...
Florian: When you're doing the green (2 nested deep)... the width
dimension is based on its own auto-sizing?
fantasai: In the current spec it must have both, but assuming
single-axis subgrids,
fantasai: In the subgridded dimension we honor the width, in the
non-subgridded dimension we ignore it.
fantasai: You just treat it as a bunch a content.
fantasai: In the subgridded dimension we stretch it out to take
all of the available grid area.
Rossen: Let's consider that this here would be another subgrid
item.
fantasai: So it too aligns.
Rossen: And it has two items.
(Rossen draws another subgrid at same level as 2nd level deep
green line subgrid)
Florian: While we are discussing level 2, maybe I just missed a
section.
Florian: How often have you found people using spacer gifs?
rachelandrew: They're using generated content
rachelandrew: for backgrounds and borders.
rachelandrew: Everyone wants to put backgrounds and borders on
empty areas.
rachelandrew: Also want to name every other line so they can place
things.
rachelandrew: Auto place against
rachelandrew: set some structure in the naming.
fantasai: You basically have different grids.
Florian: Should we just acknowledge that this is a problem and we
don't have a solution yet?
Rossen: We could have the current subgrid published as a WD
Rossen: and then have fantasai add text for how this could work.
Rossen: Ideally if we have the current version published so we
don't lose it
Rossen: because we said we would remove it from level 1 and put it
in level 2.
Rossen: Anyone objecting to publishing the current subgrid?
tantek: my request is to put an inline issue in the FPWD pointing
to the issue of independent axes.
Florian: I don't think grid fragmentation has been figured out.
fantasai: I think that and and the same in flexbox is a huge
feature that has not gotten any love.
Florian: Given limited resources I'm not sure Vivliostyle can work
on it unless people are going to look at it.
fantasai: I think that issue of fragmentation and grid, needs
someone to care about printing, file issues against
the spec.
fantasai: I think that...
fantasai: we did in flexbox
fantasai: there is question about how do you distribute space
across a fragmentation boundary
fantasai: It is tricky.
fantasai: We shouldn't try to spec it in any more detail unless
we are in the process of implementing it.
fantasai: It's not that we don't want it; we don't want it in
theory, we want it in practice
fantasai: for flexbox the theory aspects are spec'd.
fantasai: In terms of distributing space there is a variety of
possible algorithms of more or less complexity.
Florian: And I think that description fits with Vivliostyle.
Florian: The difference is that both of these specs are big efforts
Florian: if we do that will anyone listen?
Rossen: Definitely we'll listen.
Rossen: Take a look at the current strawman we have there.
Rossen: It works in a lot of cases fairly well, but not all.
Rossen: If you want to take this and start improving on it.
TabAtkins: While chrome cannot currently fragment worth crap, as
we move things internally to our own Houdini APIs, then
we will care.
Rossen: I want to go back to the resolution for the FPWD for Grid
level 2
Rossen: Any objections to publishing FPWD of Grid level 2?
tantek: I gave my requirement of asking for inline issue.
Rossen: Then let's call that resolved to publish FPWD with the
inline issue.
RESOLVED: Publish FPWD Grid Level 2 with the inline issue pointing
to the discussion of independent subgrid axes
Decorative grid-cell pseudo-elements
------------------------------------
fantasai: People want to style this area of nothing
Florian: Empty div?
Florian: We don't have a way to generate boxes
rachelandrew: It's visual styling, it's a CSS thing
(something events)
TabAtkins: At some point we'll address this more generally.
Florian: You mean just use empty divs for now?
TabAtkins: No I'm for pseudo element or an infinite collection of
pseudo elements.
Florian: Also how you solve the consume that space.
TabAtkins: The original version from Bert's draft had a way to say
this is an empty cell.
Florian: In the limited examples I've tried to write, I've found
the "consume this cell so nothing goes there" would solve
it, but another way would be auto-place, but start here,
and not before.
fantasai: So position the first one, and auto-place the rest.
fantasai: The main thing is we need stylable things in the grid.
fantasai: That's a very strong use requirement coming from the
authoring community.
rachelandrew: It's like question one coming when people look at
grid.
iank: So the specific request is styling row 1 col 2 red.
rachelandrew: Yeah at the moment people are either sticking in an
empty div or generated content to style.
iank: This is like page background effects.
Rossen: We are wrapping up.
Rossen: Do we have an issue for this?
fantasai: I think we do.
<fantasai> https://github.com/w3c/csswg-drafts/issues/499
CSS Fonts 3
===========
Scribe: dino
Testing
-------
<ChrisL> https://www.w3.org/People/chris/fwf/
ChrisL: Myles made an interesting font.
ChrisL: For each char, it displays a cross or tick depending if a
feature is on or off.
ChrisL: It allows you switch high/low level features on and see
the output.
ChrisL: The link above shows the results of testing.
ChrisL: Staged at the moment because they are easier to see live.
ChrisL: The amount of greeniness shows how many implementations we
have. Red is zero greeniness.
Implementation status of font-variant-east-asian
------------------------------------------------
ChrisL: The one that sticks out is font-variant-east-asian, only
Gecko passing.
ChrisL: Chrome passes the low level test, but the syntax isn't
hooked up.
eae: We will try to fix this quarter.
CSSFontFaceRule
---------------
ChrisL: Scroll to the bottom, see the object model. Nobody
implements what the spec says, but they do implement stuff
from DOM Level 2.
SimonSapin: iirc, the conclusion was that we'd copy the interface
from DOM 2 into the Fonts spec
SimonSapin: and there was only a few attributes missing.
SimonSapin: I'll make a pull request.
<dbaron> The OM thing is https://github.com/w3c/csswg-drafts/issues/825
jdaggett: The OM rule is non-functional. To make it work you have
to jam things into the style.
jdaggett: You can manipulate unicode range on a style property -
this is weird.
jdaggett: It is badly defined. We are not speccing out what the
implementors are implementing.
ChrisL: What do you suggest?
jdaggett: That implementors follow the spec.
jdaggett: We should not spec out whacky behavior on style rules.
myles: Content that already exists, will access the descriptors
inside the rule. So we need a .style property.
jdaggett: Are people actually using this functionality, that's
been there since CSS 2? Last time I looked, if you went
in and changed the font family, font matching didn't
respond correctly.
myles: Works in Safari.
jdaggett: Not in Chrome
jdaggett: this is broken in practice.
ChrisL: Where do we want to go?
jdaggett: If you're looking to go to REC, then put something in that
says it is not defined and push the OM to CSS Fonts 4.
ChrisL: What you have specced is better, but the implementors
don't agree.
astearns: We have to move the OM section from Fonts 3 into Fonts
4. Any objection?
SimonSapin: I am fine with moving the attributes. But the
@font-face rule interface exists.
astearns: We can copy over what is in CSS 2 to Fonts 3, or we can
have a section saying that CSS 2 exists but we are not
putting it in the spec.
ChrisL: People seemed to push back that DOM Level 2 is ancient.
jdaggett: But all the implementations are in the same boat.
RESOLVED: Remove CSS OM section from Fonts Level 3 to Fonts Level 4
SimonSapin: Just the attributes?
SimonSapin: Option - define CSSFontFaceRule, but without any
attributes.
myles: Why is that valuable?
SimonSapin: Because you want something to show up in the CSSRules.
Florian: Is that implemented? Pushing it out doesn't mean we don't
want it.
SimonSapin: CSSFontFaceRule with a style attribute is implemented.
The font spec has one attribute for each descriptor.
SimonSapin: This comes from DOM Level 2.
dbaron: If we do this, we should add a note saying that this is
actually defined in Fonts 4, but what is currently
implemented is defined in DOM Level 2.
astearns: Objections to amending the resolution to leave
CSSFontFaceRule and add a Note?
RESOLVED: As above, but leave CSSFontFaceRule with a note
explaining the current state
Stylistic Alternates
--------------------
ChrisL: I would like to talk about the @font-feature-rules for
alternates.
ChrisL: myles's fonts don't do stylistic alternates.
myles: I have now included all of the font features that don't
require a numerical argument to turn on.
jdaggett: There are some reftests in gecko, testing font variant
alternates/position/caps. They have normative fallback
behaviour.
jdaggett: They test what you want.
ChrisL: Does it require a specific testing framework?
jdaggett: They are probably Gecko reftests. You'll need to convert
them.
ChrisL: Any volunteers to convert them to Web Platform Tests?
dbaron: <explains how to do it>
Ahem Anti-aliasing vs Reftests
------------------------------
ACTION: ChrisL to port Gecko font variant tests into WPT
<trackbot> Created ACTION-843
Florian: A while back we discovered that Ahem didn't work great
for testing on high-res screens?
Florian: Can we fix this?
myles: Not easily.
myles: Use the CSS property to turn off font fringing. Or size
your box correctly.
Florian: I think I tried that. You can't get the standard 100x100
green box with Ahem.
myles: Renderers treat text very differently. You can't get pixel
perfect.
TabAtkins: So what do we do? That's the idea of using Ahem.
dbaron: It's worth digging into a bit.
Florian: <links to an email with the failing test>
<Florian> https://lists.w3.org/Archives/Public/public-css-testsuite/2017Feb/0001.html
astearns: This test will be investigated.
Max Font Size
-------------
astearns: Next up in min/max font size.
fantasai: The min and max font-size props were added in Level 4.
we need to decide how they impact font-relative units.
dbaron: They affect the computed value of font size, so they
affect em units. therefore, em units on these properties
work just like em units on font-size.
<dbaron> ... and thus use the parent's computed font size
myles: I agree with everything after "therefore", and asked if
there was precedent to have the computed value of a
property depend on the specified value of another property.
fantasai: The 'display' property has this issue. depends on its
parent's 'display' and its 'float' and 'position' values.
myles: I agree then
astearns: Does it need to be added to the draft?
fantasai: Yes.
RESOLVED: dbaron's explanation above will go into the spec for min/
max font size.
ACTION: Myles to put this into the min/max section of the spec
<trackbot> Created ACTION-844
Publication
-----------
myles: CSS fonts 4 includes font variations, font display
scriptor, min/max font size properties, and color font
support for palettes, and text style v emoji style.
myles: This is a lot of work, and pretty close to what the final
collection of work will be.
myles: We should go to First Public Working Draft?
astearns: Objections?
<none>
<fantasai> +1
RESOLVED: First Public Working Draft of Fonts level 4 will be
published. Chris to handle the request.
Font Load Events
----------------
astearns: Font Load Events
jdaggett: I put that on the agenda. The spec was tweaked on
Monday. There was a Last Call WD in 2014, nothing since.
We have three implementations. We should go ahead?
fantasai: Any open issues?
jdaggett: Unknown
dbaron: Any tests?
TabAtkins: I have some issues. Minor. I just need to do them.
jdaggett: Gecko have tests.
myles: WebKit has tests too.
astearns: Are the WebKit tests being submitted to WPT?
myles: No.
astearns: It seems font loading can be on our list of things to
push to CR.
astearns: I will follow up on tests and closing issues and so on.
Font Language Override
----------------------
myles: font-language-override
ChrisL: Jonathan Kew wanted it as a descriptor
dbaron: font-language-override was specced as only a property, but
other things were also a descriptor. Gecko has implemented
it as both.
dbaron: The argument is that it should be a descriptor.
ChrisL: This makes sense to me.
ChrisL: font stylistic sets are font-specific, so we have them on
@font-face
ChrisL: font-language-override can also be font-specific, so
should also be on @font-face.
myles: In WebKit, we distinguish between fast and complex text
paths. We need to determine with path to take before
working out which elements in the fallback to use.
myles: This means they are slightly problematic. There are already
some descriptors that cause this issue. I'm a bit hesitant
about adding more.
ChrisL: But you're not arguing that the others should be taken out?
myles: No.
fantasai: But you'll have to fix the others?
myles: I doubt we ever will.
dbaron: John Hudson's example was of writing Macedonian, and this
font has Macedonian, so I'll use that, but this other font
doesn't, but the Serbian is close enough, so I'll use that.
Florian: Would that make sense for CJK fonts, where you want to
pick particular bits?
jdaggett: This is when you want to override the OpenType language
implied by the lang attribute for certain features such
as shaping.
<ChrisL> https://drafts.csswg.org/css-fonts/#font-language-override-prop
ChrisL: This example <link> shows what we are talking about.
astearns: It seems that a property is going to be used much more
often than a descriptor.
astearns: Fonts 3 currently only has a property. Gecko does
descriptor as well.
astearns: Florian proposes putting it into level 4.
ChrisL: We could put both property and descriptor into level 4
dbaron: Does anyone else implement font language override?
<no>
astearns: I'm inclined to leave the property where it is. Add
descriptor to level 4. Objections?
<none>
RESOLVED: Add a font language override descriptor to Fonts Level 4
ChrisL: Do you have tests, jdaggett ?
jdaggett: I think so.
ACTION: Myles to add font-lang-override descriptor to Fonts Level 4
<trackbot> Created ACTION-845
ACTION: jdaggett to look for Gecko tests for various font things
<trackbot> Created ACTION-846
Received on Saturday, 27 May 2017 00:43:28 UTC