W3C home > Mailing lists > Public > www-style@w3.org > May 2017

[CSSWG] Minutes Tokyo F2F Wed 2017-04-19 Part III: Grid Layout / Subgrid, Fonts 3 & 4 [css-grid-2][css-fonts]

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 26 May 2017 20:42:42 -0400
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <4107d637-439a-9d9e-0d74-016417b72087@inkedblade.net>
=========================================
   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

This archive was generated by hypermail 2.3.1 : Saturday, 27 May 2017 00:43:29 UTC