- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 13 Mar 2016 08:38:01 -0400
- 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.
=========================================
Writing Modes
-------------
- Koji shared that there are now over 900 test cases for Writing
Modes, allowing a good sense of what properties don't have two
interoperable implementations.
- A document listing the properties where yellow items don't
have enough implementations is available here:
http://kojiishi.github.io/generate-w3c-implementation-report/css-writing-modes-3/status-2016-01.html
- Everyone praised the document and the work done in creating
the test cases.
- With this feedback, Koji would like to target PR at TPAC.
- sideways-* had a lot of failures, but still a lot of support for
its need, so it will stay in the spec for now and drop to
level 4 if it becomes the last blocker for REC.
- Some of the failures for unicode-bidi are in the details of the
embed behavior, which Unicode and the Web Platform are moving
away from anyway. Those failures will be identified as
failures in UAX9 implementation, not Writing Modes failures.
- Several people received actions in order to continue progress on
understanding these test results and getting more
interoperable implementations.
- RESOLVED: Make TCY fullwidth->proportional transform optional
(text-combine-upright)
Line Grid
---------
- koji presented this proposal for a new line grid spec that is
simplified in order to get more implementor interest.
- The proposal changes the snapping to grid behavior to an
attempt to control heights.
- It also replaces line-grid with snap-height relying on css
custom-properties to add more versatility.
- Though everyone understood the goal of getting something
implemented, there was a lot of concern that the proposal is
too fragile to be useful, especially for vertical-rhythm.
- RESOLVED: Make an ED for snap-sizing to work out details of
proposal
- RESOLVED: Editors koji and fantasai
- RESOLVED: Add ideographic advance unit to Values and units 4,
come back to WG for approval after details worked out.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sydney-2016
Scribe: fantasai (with zcorpan scribing when fantasai spoke)
Writing Modes
-------------
koji: Some Japanese companies have been funding gtalbot and some
test engineers for a bit more than a year,
koji: Have 900 testcases for Writing Modes.
koji: The team also ran the tests for most browsers, not every,
but all the tests were mostly were run by test team.
koji: We now know which tests don't have two or more interoperable
implementations.
koji: I want to share the status of that,
koji: and figure out plans for moving Writing Modes to PR/REC.
koji: One reason I'd like this spec to move to REC
koji: is that other organizations, e.g. IDPF EPUB are relying on
this spec
koji: but is not REC in CSSWG.
koji: So if it's possible to move major part of the feature to
REC, that's helpful
koji: for those other organizations.
Florian: Different people in different organizations are
differently sensitive to status of the spec.
Florian: People who care about Writing Modes care about the status
and stability of the spec.
koji: Wiki page there's a link to the status document I wrote up
http://kojiishi.github.io/generate-w3c-implementation-report/css-writing-modes-3/status-2016-01.html
koji: Yellow row means that test doesn't have 2+ implementations.
koji: Going to go over the yellow rows:
koji: For section 1, all failures are for sideways-lr or
sideways-rl
koji: These two values are added at TPAC, are at-risk,
koji: These values are not interoperable.
koji: Next section is 2: Inline Direction and Bi-directionality.
koji: Almost 10 tests, all for new values for unicode-bidi
property,
koji: These do not have 2 implementations today.
koji: Most of the layout tests are done by adding prefixes, btw.
koji: We run parsing tests without prefixes, but most layout
koji: unicode-bidi values currently only Blink is unprefixed.
koji: So these values don't have 2 implementations as of today.
koji: Next one is 2.1: Specifying Directionality: the direction
property
koji: As you can see from filenames
koji: failures are for sideways-*
koji: Then there is some failures for rtl+upright.
koji: More unicode-bidi ... only blink unprefixed these values.
koji: This test is controversial, tests bidi reordering algorithm.
koji: CSS spec defines how to map CSS properties to bidi control
characters. And unicode spec defines how to reorder
characters based on bidi controls.
koji: These tests are testing rendering results.
koji: So it's not really testable for CSS only, can only test
combination of CSS and Unicode.
koji: For blink, these tests are Unicode failures.
Florian: So you want the spec to progress, not block, on unicode
failures?
koji: We have a failure for row-reverse (flexbox)
koji: Don't know CSSWG strategy for combination of two specs.
fantasai: We don't have a policy, but maybe we could have a policy
if you have a test that tests the interaction of 3
specs, should we be able to move all of the specs but
the last one to rec?
astearns: If there are interactions where some specs are already
in REC, that could hold a spec back.
Florian: Makes sense in general, but it's tricky if some browsers
implement one spec and some implement the other
Florian: If different browsers are working on different specs,
unclear which specs are held up.
Florian: But in this case, see no problem.
koji: Next is table progression.
koji: We have a bunch of failures for atomic inline baselines for
vertical-lr and multiple lines in inline-block/table;
koji: Complex case, only in Mongolian.
koji: vertical-rl passes.
koji: So vertical-lr is less interoperable today.
koji: There are a bunch of tests for text-orientation that fail.
koji: Orientation of unicode codepoints-
koji: Uses JavaScript to render all codepoints.
koji: Unfortunately that JS doesn't work for vertical flow,
koji: in Gecko, it's failing,
koji: But the reftests, Gecko passes.
koji: So although these tests don't pass, I consider the property
itself passes,
koji: The failure is in CSSOM View.
fantasai: Given Gecko would pass an equivalent reftest. I agree
with that.
koji: Next section we have some abspos failures
koji: No excuses, they are failures.
koji: I want to note that abspos has lots of combinations. Have
250 tests.
koji: About 25% of test suite is about abspos.
koji: Those 270 are combination of [lots of things];
koji: All the failure are about orthogonal flows.
koji: When author sets abspos, that abspos box has different
writing mode from its parent.
koji: My take is that the basic cases of abspos are interoperable,
but orthogonal cases are not really handled.
koji: 9.1 text-combine-upright
koji: Most failures in parsing.
koji: Quite well implemented in Edge/Trident/Blink/Webkit,
koji: But only Blink has unprefixed support.
koji: For other layout tests, these implementations pass.
koji: Last section is 9.1.3.1: Full-width Characters
koji: Says that for text-combine, when author puts full width
characters, should convert it to ascii characters.
koji: Nobody implements that.
koji: Need to either make it... or remove it
fantasai: I think we can put it as a MAY, so won't block moving
forward.
Florian: Is this something to address with text-transform?
fantasai: No.
koji: After list of test failures, have list of non-interoperable
items.
koji: Questions?
Florian: Other than thing we just talked about, have you found
through these tests areas where the browsers disagree
with the spec but agree with each other in a way that
suggests changing the spec?
koji: Abspos is a little...
koji: It's likely unintentional, but as a result this browser test
fails this combination, that one fails that combination.
koji: That's what you call disagree?
Florian: These are clearly bug.
Florian: If we're trying to rush to REC, might be tempted to
change spec, so not something to do here.
Florian: Is there a case where browsers agree with each other,
spec disagrees, and spec makes less sense and should be
changed?
koji: Full-width is the only one.
fantasai: Thank you Koji for this report, it's really excellent.
fantasai: I think from what we have here, we should encourage
browsers to unprefix their implementations.
fantasai: That's a relatively simple fix to move a lot forward.
fantasai: Should also fix the full-width issue by changing to MAY
in the spec.
fantasai: Other than that, looks like some bugs we just have to
wait to fix.
heycam: Looks like a lot of failures for sideways-*, maybe should
drop.
Florian: I don't think it's a big issue.
Florian: This syntax was introduced very recently, so not
surprising people haven't caught up yet.
Florian: If everything else was green, would consider what to do
with that.
Florian: When you support the rest, supporting this is actually
easy.
Florian: Nothing fundamentally new for these two values.
Florian: By the time we have the rest, I expect these can be fixed
as well.
Florian: If not, then can drop.
Florian: But relatively easy compared to the rest of things.
koji: Depends who you ask,
koji: But from viewpoint of relationship with EPUB.
koji: text-combine is the only thing they refer to.
koji: There is a possibility that if we can get text-combine, then
we can move the all the rest to Level 4 and move all the
rest to REC.
koji: That make EPUB people very happy.
Florian: We still have to fix the other bugs.
koji: Make undefined in L3, move to L4.
fantasai: I think we can probably make the EPUB happy by moving
to snapshot stability.
fantasai: With regard to sideways stuff, I think Mozilla
implements that correctly.
fantasai: The question is if other browsers will implement that.
fantasai: If it's just abspos issues that shouldn't be too hard to
fix.
fantasai: If nobody is going to update to do sideways that that
can be a problem.
fantasai: This report does a good job on what we should focus on.
fantasai: I'd prefer to not drop sideways because it's important
for non-CJK use cases.
fantasai: This is new syntax from 3 months ago so we should give
more time before we move to PR.
fantasai: There's a minimum time before we can move forward anyway.
koji: REC doesn't indicate importance, but whether W3C saying
these are interoperably implemented.
koji: From that POV, if sideways are not implemented at some point
moving to level 4 is natural to me.
Florian: I agree, just don't think we're at that point.
Florian: I think if we revisit at next TPAC, likely there's a lot
more green.
Florian: If by then sideways are the only thing holding us from
PR, dropping makes reasonable sense.
Florian: I'm optimistic that sideways values can be implemented as
these other bugs are fixed
astearns: Amazing job at getting so many tests together.
astearns: Is work still ongoing?
fantasai: Have funding for another 5 months at least.
Florian: Do the people who have worked on this test suite consider
the test suite complete, or should there be more tests
written?
koji: Hard question.
koji: Test suite is never really complete...
koji: I think it's a good level to move on, imho
koji: For me, if generally it's reasonable to say we could target
PR for next TPAC.
koji: One really blocking factor from my perspective is
text-combine and upright.
koji: It would be really great if Edge can unprefix, or Gecko can
implement.
Rossen: If it's only about unprefixing, should be possible.
koji: Blink has unprefixed, WebKit is prefixed but good, Edge
needs to unprefix.
koji: If we count webkit separately from blink, we have two.
Rossen: Let's not have that discussion now.
heycam: I think xidorn was going to ask about all vs 2-3.
xidorn: Is it just the value 'all' or also the digits values?
koji: Edge/Trident are the only implementations of 'digits'.
koji: Digits are at-risk.
koji: And EPUB doesn't use digits today.
Rossen: And yet they were the ones that were asking for it the
most,
Rossen: Because they didn't want to pre-process their content.
Rossen: Representatives from Japanese publishing companies were
asking the most for 'digits' to be implemented.
Florian: Wanted to discuss earlier comment about bidi support
comments.
Florian: How do others feel about those bugs?
koji: There is actually a Unicode test suite for UAX9.
koji: Since the test is not really unicode testable, Blink has a
separate test harness to run it.
koji: We have about 20-25,000 failures there,
koji: Over 1 million testcases.
koji: So its 2-2.5%.
koji: I also converted that testcase to HTML and ran across
browsers.
koji: All browsers fail somewhere between 20-30000 tests.
koji: So my current view on those failures is not to make those
failures to zero.
koji: But if users file bugs, then we try to fix it.
koji: It's not really hard to make failing testcases.
Florian: Is it possible to write the testcases to check the
mapping is correct?
Florian: Even if underlying unicode is being wrong?
Florian: Should this hold up spec going to CR or not?
fantasai: I don't know. I'd have to look at the specific tests
SteveZ: Are these failures on simple testcases or complex
combinations?
SteveZ: How likely will real people come across the kinds of
things that are failing?
koji: I don't speak bidi languages.
koji: Looking at spec logic, so can't tell.
koji: If bugs are filed in our database, we'll look into it and
try to fix. Those failures are not filed yet.
koji: One more thing, not sure familiar with bidi-isolate.
koji: In Unicode 6.3, 3 years ago, they came up with new kind of
embedding, affects algorithm itself,
koji: Everyone tells me isolate is the way to go in the long run.
koji: We're moving towards it.
koji: Talked about it last TPAC with Apple and ?
koji: We're working on it.
koji: Among those failures, many are for old embed style.
koji: If you limit test to isolate mode, we have less failures.
koji: Depends on timing, not sure how much want to fix those embed
failures.
koji: If everyone has moved to isolate mode, people might not be
using embed.
koji: But still testing this, so test might fail.
fantasai: If embed is what's failing, that's already in CSS 2.1
REC and we can move on.
fantasai: We need to make sure the mapping is correct and we're
trying to do the right thing with regard to nesting etc.
and then can say edge cases is unicode's problem.
fantasai: If you load a plain text with all the code points
instead of CSS and it has the same failures then it's
not a CSS bug.
koji: So next step is ask fantasai to look at test failures and
get some feeling.
ACTION fantasai: Look over Writing modes test failures
<trackbot> Created ACTION-748
ACTION gregwhitworth: Look into unprefixing text-combine-upright
<trackbot> Created ACTION-749
ACTION hober: Look into unprefixing writing modes features in
WebKit
<trackbot> Created ACTION-750
fantasai: In the spec we should change full-width transform to may?
fantasai: Any combination of 1 to 2 digits should be upright,
fantasai: and you have a sequence of 2 digits, the spec says first
try to squeeze these ...?
RESOLVED: Make TCY fullwidth->proportional transform optional
(text-combine-upright)
Rossen: Let's focus on L3 first.
fantasai: I'd encourage blink and MS teams to look into sideways
values.
Rossen: We'll "look" into it.
fantasai: sideways-rl at least should be easy because it's mostly
the same as text-orientation: sideways + writing-mode:
vertical-rl.
Line Grid
---------
koji: The line grid, this is a proposal
<astearns> https://github.com/kojiishi/snap-height
koji: The basic idea is that line grid spec has been around for
3-4 years without enough interest from implementers.
koji: I just wonder if it can be more interesting if the spec is
simplified.
koji: This is a proposal to try to simplify further:
koji: I want to see if this increases implementer interest, and
also if it will still be interesting for solving use cases.
koji: One thing is world is changing in 2-4 years.
koji: Last time we discussed this, I googled about vertical rhythm
or line grid,
koji: All I hit was professional typography papers.
koji: But this month when I go searching, everyone is talking
about CSS, how to do it in Web browsers.
koji: People are doing lots of complex calculations using SASS and
SASS macros,
koji: To provide that kind of capabilities.
koji: I think this demand is coming to browsers, and people are
hacking around,
koji: But hacks do not work when page is zoomed,
koji: Or are not responsive,
koji: So doesn't work for mobile browsers or desktop browsers.
koji: People are trying to solve this, but there is no really good
solution yet.
koji: So even with minimum level of line grid
koji: I'm seeing it solves, helps a lot of web developers today.
koji: Overview section of proposal
koji: Speaks how I tried to simplify.
koji: Basically 2 points of simplification.
koji: One is instead of snapping to grid, this proposal tries to
control heights
koji: So that every line and box is multiple of grid.
koji: As result of stacking, produces a grid effect.
koji: Send point is instead of defining grid for elements or named
grids,
koji: We can now rely on CSS custom properties to define a value
across documents,
koji: So no longer need to define grids, just accepts values.
koji: Assumes that CSS custom properties can fill in the gaps.
koji: Proposal follows.
koji: With regard to naming, talking to people, since only
heights, not really a grid;
koji: But please disregard naming for now.
koji: First item is snap-height,
koji: Very similar to line-grid,
koji: Takes none or length.
koji: What it does it just increase the height of line,
koji: To be multiple of specified line length.
koji: There is an example below
koji: With help from css custom-property.
koji: You can make all line heights as multiple of specified value.
koji: There was some discussion of margins being multiple of grid
unit.
koji: With custom properties, this is easy to achieve.
koji: Just use calc() and custom properties combination.
koji: 2nd feature is snapping to Baseline, primarily for Latin.
koji: This has a little tricky expression.
koji: The basic idea is that author specifies in the grid, where
you want to draw a virtual baseline.
koji: Control spacing is that the baseline matches to the
specified ratio in the grid.
koji: Does that make sense?
astearns: This doesn't work.
astearns: If you have 2 lines snapping to different multiples.
astearns: One to one multiple of a length, and one that is 2
multiple of the length, then ratio is not going to get
the baselines to align.
koji: Ratio is for one grid, if your line is higher than one grid,
you skip one grid, matches to same ratio of next grid
Florian: ...
SteveZ: If you've got a big descender, might creep into next box.
koji: Basically the idea is to round up line-height to multiple of
grid.
koji: Then shift so that baseline matches to specified ratio.
SteveZ: So I've got a "q" that's 3x larger than the other font.
SteveZ: I move the descender to match the 3rd baseline down, and
then that descender is going to go well below the line box.
koji: But baseline matches...
astearns: I think the idea of snapping heights and widths to
multiples of values is probably a useful thing.
astearns: I don't think it does enough to give you a vertical
rhythm features.
astearns: I think you should just drop the baseline ratio thing,
and just get the multiple widths/heights thing you're
looking for.
astearns: How this proposal matches up to giving the Web a
vertical rhythm feature.
astearns: My main concern with this, like with existing solutions,
have to control everything on the page in order to get
it to stack up right.
astearns: If anything is not participating in this multiple-height
scheme, it throws off the rhythm.
astearns: In order to have a vertical-rhythm, really need to have
a grid that everything is working towards.
astearns: That means you define a grid that things can participate
in.
astearns: You don't try to give every item on the page a
particular height to make it conform to a grid that
doesn't exist.
astearns: There are too many failure modes to constructing a grid
out of making things conform.
astearns: You really have to have a grid, and have thing
participate in the grid or not,
astearns: to get the vertical rhythm feature.
koji: I actually understand the concern, but if author wants
vertical rhythm, he has to pay attention to every space
anyway.
koji: How it fails differs by having a grid or controlling heights.
koji: If you have a grid, fails, need to jump to next grid.
koji: Author doesn't want that big space, it's a failure anyway.
Florian: I think my view is similar to astearns's.
Florian: You are right, this is probably simpler to implement than
existing proposal for line grid.
Florian: Increasing chance of happening is useful.
Florian: In very controlled situation, can get decent results with
this.
Florian: But it's quite fragile.
Florian: So many situations that will break the rhythm.
Florian: If it only sort of works, instead of really works, then
we still want the other proposal.
Florian: If we implement this sort-of-works thing, is that worse
because we sort-of-solve the problem?
Florian: And therefore not motivated to fix the good enough thing?
koji: I actually agree with that.
koji: I'm not saying grid is bad.
koji: I'm fine to have 2 specs, Level 1 / 2 or something.
koji: But for the fragility, it exists even with grid.
koji: People who care about rhythm also care about unintentional
large spaces.
koji: So if fail to set space correctly, not pay enough attention,
then in this proposal they break rhythm.
koji: In real grid they get big space, which is also bad.
koji: That's my view.
astearns: It's the same problem in both.
astearns: If you have something that doesn't fit the grid,
astearns: In your proposal, then get a space.
astearns: In grid, you get a space, but grid is also resumed.
astearns: Once you have a stacking failure in this proposal, then
everything is off.
koji: That's true, so I'm not ..
koji: My proposal is only that before we have grid, is this good
to have or is it useless.
astearns: Like I said, I think snapping to intervals is a fine
feature to have.
astearns: There's other use cases for that also.
astearns: Probably belongs to sizing module.
SteveZ: Could you extend line-height using the algorithms that
you're talking about, so it always came out to an integral
number of the snap unit?
astearns: Doesn't give you a different property, just a different
way to have line-height.
astearns: Could have something that's a new length type,
astearns: A function, or length unit.
astearns: I'm not sure.
koji: I thought about it, but functions or unit can introduce
complex cases because can apply anywhere.
koji: Goes against making things simper to implement.
koji: The other one, is after this one, I applied it to block
heights.
koji: I don't care much about syntax or how many properties to use.
koji: But not really positive about making too general.
Florian: You were asking whether useful or useless.
Florian: I think this is useful,
Florian: But I'm concerned about being a little useful, but not
enough, and decrease priority of real solution.
astearns: I'm not as worried about it, as long as we don't sell
this as a solution to line grids.
astearns: Another argument for doing more generally is that line
box heights, or block heights, maybe they are the only
thing that stack...
astearns: But I assume people would want to use multiples of a
particular length for margins/padding/other things.
Florian: If the multiple is 1, then we can probably introduce a
unit that is the line height.
Florian: And you can use margins and paddings in that.
Florian: I can easily imagine ...
fantasai: if all of you margins are a multiple...
fantasai: I think I see 1.5lh on top and bottom margins being
useful.
SteveZ: Also have to worry about margin-collapsing.
fantasai: No, not really a problem. If all input margins are
multiples, output margin will be multiple.
koji: Florian's concern is hard to answer.
koji: But when I google vertical-rhythm css, 37K hits
koji: These are asking how to do that.
Florian: Pain is great, want to solve problem as well.
koji: I know people hate to hear this, but Word shipped this
height feature 20 years ago.
koji: From what I hear from colleagues, not hearing any complaints
about that. Turned on by default in East Asian versions.
Bert: If I understand correctly, was looking at Example 1 in
current line-grid spec.
Bert: Trying to figure out how to do that in Koji's spec,
Bert: But can't figure out how to do that.
astearns: You'd have the headline's block-height snapped to a
multiple of the line height,
astearns: And leave the line boxes alone.
astearns: The line boxes within the headline would stack as you
see it in the example of the spec.
astearns: You'd just have more space above and below,
astearns: In order for the next paragraph to fit on the grid.
Bert: Wondering if that's possible to specify with snap-height?
Florian: You would need to use it with custom-properties so you
have a repeating value.
astearns: There would have to be a block-height-snap added to
koji's proposal.
koji: If the heading wraps to multiple lines, astearns is correct,
koji: If it's simple line, then it works.
SteveZ: That's an example of the problem!
koji: Here the heading is larger than one grid, so automatically
expands to 2 grids.
koji: As you see, centered to 2 grids.
koji: Haven't explained that yet, but see below -- snapping block
boxes option.
astearns: So, interest?
koji: I'm interested in this, any other implementers?
Florian: Vivliostyle might be interested. We're interested in
line rhythm, not sure what we will consider first.
<skk> BPS is also interested slightly. Small contribution might be
possible.
fantasai: How feasible is it to have a property that snaps the
margin-box height of a box to an interval of length X.
dbaron: what's a margin box?
<dbaron> (in the presence of margin collapsing)
fantasai: The margin box is the border box with the margins added
to it
...
astearns: One failure mode of the SASS approach is solved, if
everything buys into this model.
fantasai: Could you do it with the border box? (dbaron??)
koji: Adjusting line-height, adjusting margin is second part.
koji: That's problematic?
Rossen: In general, if you marry the size of a box to the its
position.
Rossen: If you're fixing the height of the box based on its
position.
Rossen: Then the problem becomes hard.
dbaron: So, if you were to...
dbaron: I'm curious why you want the height.
fantasai: The goal is to snap the height of an element's margin
box to a multiple of the line height.
dbaron: If it always breaks margin collapsing, then maybe it's
implementable.
Florian: Why does margin collapsing matter here?
fantasai: If we don't have any collapsing margins, does this work?
dbaron: Part of the issue is, is there going to be a problem when
you try to implement and fuzz it, and is there an infinite
loop.
dbaron: Hard to answer off the top of my head.
Florian: For this use case, if it would be with an uncollapsible
margin, that's fine.
Florian: Not sure if that's necessary, but if necessary to make
sane to implement, sounds okay.
dbaron: To be clear, my worry is about the margin inside the box
collapsing to outside the box.
koji: I myself don't really understand margin collapsing code atm.
Rossen: It's pretty straightforward. :)
koji: I'm sure I'll run into issues.
koji: But haven't discussed how block snaps in my proposal.
fantasai: I'm actually more worried about line part than block part.
koji: There's a table about use cases and what gets adjusted.
koji: I'm seeing that centering is quite difficult for us.
koji: For first phase, only adjust margin-bottom.
koji: After layout.
koji: After height, determine position.
koji: Height or margin is not affected by position in this proposal.
koji: Only about adjusting margin bottom, output from height.
* fantasai thinks this is worth working on, but doesn't think this
proposal is ready for implementation yet.
Rossen: Are you looking into A) sampling implementer interest B)
moving into a spec and making a spec out of it or C) both
Rossen: Think we should start wrapping up.
koji: Asking both.
koji: Want to see how much technical troubles I would get into by
experimentally implementing in blink.
Rossen: Is this something that should move to line grid spec?
astearns: I'm of the opinion that this should be a more general
thing,
astearns: that can be applied to any length.
* fantasai agrees with that too
astearns: It's a multiple length, will snap to a multiple of the
length you supply.
astearns: Useful thing in all sorts of situations.
fantasai: I think it's a useful direction to go in. Wouldn't
implement just yet, want to work out e.g. interaction
with margin collapsing etc. before trying to implement.
koji: So make an ED?
fantasai: Yeah, work out the details a bit, then decide where to
put it.
Rossen: For the B) part of the question is, let's start with an
editor's draft, and go from there.
Rossen: For other ones, implementers intent, that's an answer that
we'll be getting as we work on the spec.
Rossen: At least our reaction is, this is an interesting problem
to solve.
Rossen: Heard quite a bit in terms of interest at least in Japan.
Rossen: That was one of the very clear asks from the Japan
Industry Meetup.
Rossen: Would we just throw everything away and start working on
this immediately? Probably not.
Florian: Another comment...
Rossen: Not sure how much will bring to the table.
Rossen: If there is an implementer really interest, engage with
koji.
Rossen: Otherwise let's take a break and come back.
RESOLVED: Make an ED for snap-sizing
RESOLVED: Editors koji and fantasai
* fantasai proposes css-rhythm
<Bert> (As the use case is double-sided printing, I guess it is
more interesting if PDF formatters want to implement it
than browsers...)
<liam> (i think that's only one use case, but also it'd be a
mistake to think people don't print web pages)
<br>
Florian: For CJK layout, in addition to line height snapping, it's
important to do the same thing in the inline direction.
Florian: The problem is slightly simpler, don't need to snap every
character. Line length is sufficient.
Florian: When you want to do such a thing, you use a font where
each character is exactly the same width,
Florian: No need for magic.
Florian: The other reason is that at least in Japan, and mainland
China, if some chars aren't full-width.
Florian: You don't line up to the grid, you line up the start and
the end and justify between.
Florian: There are some cases where you want something else, but
usually that's enough.
Florian: Koji's spec, and mine, trying to address working on that
line being a multiple of the char width.
Florian: So that it works fine within the line.
Florian: My proposal is an extension or variant of the line grid
spec.
Florian: Koji's proposal is more in line of size snapping.
Florian: Same differences apply.
Florian: What we discussed briefly during the break is that we can
add my proposal to line grid spec.
Florian: And as we work in parallel on line grid spec and snap
heights do the same thing on these two features for
inline axis.
Florian: Proposal is to fold my proposal into Line Grid spec and
figure out details there.
SteveZ: One comment -- seems to be em based, need to use multiple
of ideographic advance which is not necessarily 1em.
Florian: Need to base on a different char,
Florian: Similar to ch unit.
Florian: Should probably use that unit instead of em.
fantasai: On the topic of units, we've discussed line height unit
and ideographic char unit. Are there other units we
need, maybe add to Value sand Units 4?
Florian: I wanted to add my proposal to spec.
fantasai: We deliberately left it out to keep the draft simpler.
astearns: I'm okay to add back in and split out later.
Florian: Would prefer to have it in a spec rather than in people's
heads.
fantasai: I would be okay with it if we clearly mark it as
targeted at level 2.
Florian: Second issue is adding unit for ideographic character.
fantasai: Seems useful for me.
fantasai: Would be a unit based on the advance width of the
character for water.
dbaron: Need height and width.
<dbaron> ...since it has a fixed orientation
fantasai: So ih and iw?
fantasai: Does it need just a single thing that's the advance
measure?
dbaron: If you do that, need to write down entire property
dependency graph, to make sure it doesn't introduce any
cycles.
RESOLVED: Add ideographic advance unit to Values and units 4, come
back to WG for approval after details worked out.
Received on Sunday, 13 March 2016 12:39:05 UTC