- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 13 Feb 2017 20:20:53 -0500
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Writing Modes
-------------
- RESOLVED: No interaction between ::first-letter and
text-combine-upright (other than what's already
specified -- that text-combine-upright can't combine
across element boundaries). The use case can be solved
using markup and 'text-combine-upright: all' if needed.
https://github.com/w3c/csswg-drafts/issues/653
- RESOLVED: Create Level 4 of Writing Modes as current draft,
Level 3 to drop all at-risk items, publications TBD
CSS Tables
----------
- RESOLVED: Publish new WD of css-tables
Values & Units 4
----------------
- RESOLVED: Reject all changes in
https://github.com/w3c/csswg-drafts/issues/837
- There was resistance to adding support for pica because it
doesn't parse well
- RESOLVED: Add cap unit (In response to
https://github.com/w3c/csswg-drafts/issues/660)
- RESOLVED: Add issue to css-values-4 asking for whether didot,
cicero, ens are needed.
- RESOLVED: Add an issue to ask if there's a need for ideographic
character face unit.
- RESOLVED: Add unit math to css-values-4
- RESOLVED: add min() and max() to css-values-4, valid within and
without calc(), accepts calc expressions as arguments,
N arguments
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/seattle-2017
Scribe: fremy
Writing Modes
=============
<koji> https://drafts.csswg.org/css-writing-modes-3/issues-cr-2015
koji: Last tpac I was actioned to update the
https://drafts.csswg.org/css-writing-modes-3/issues-cr-2015
koji: We have two open issues.
text-combine-upright and initial-letter
---------------------------------------
koji: Myself and Florian think issue 8 should go to css-pseudo
florian: There is another sub issue in issue 8
florian: about what happens to quotation around text-combined text.
fantasai: The answer should be no, if you want this, you put a
span around it.
florian: Is skk in the room?
skk: Yes, I can agree with this.
RESOLVED: No change on the sub-issue
(https://github.com/w3c/csswg-drafts/issues/653),
this can be solved using markup if needed.
Publication
-----------
koji: I propose we move this to PR, is there any objection?
<dbaron> Where's the link to the test results?
astearns: What about the various categories of failures?
florian: We don't have two implementations for sideways, so we
would need to drop them.
jensimmons: I don't like that.
astearns: Delay them to next level is what we meant.
jensimmons: Could we sponsor another implementation to get rid of
this problem?
koji: We are looking into it but it won't happen very soon.
florian: So you don't think that changing the level will make it
slower to be implemented? that is right?
myles: I can't comment on plans, we won't change them based on the
level.
florian: Then I am fine.
<jensimmons> is there a link to the issue for implementing
sideways-* in Blink?
<jensimmons> well, of course…. I should say, could someone drop
the link
<jensimmons> here’s the ticket for implementation in webkit
https://bugs.webkit.org/show_bug.cgi?id=166941
tantek: A behind-flag implementation counts btw.
myles: That sounds weird though.
fantasai: Since we have received a lot of help from the Japanese
government, and they care a lot about schedules, we
should consider moving forward without this feature
rather than waiting for it to be completed.
fantasai: How long does it take to go from one stage to the other?
Bert: Six weeks.
dbaron: Plus some one month or two of padding (laugh)
Bert: (details the "six" weeks which means three weeks minimum but
a few more weeks of padding)
fantasai: Ten weeks before the Tokyo f2f then?
dbaron: That seems pretty soon, February 6.
dbaron: So we can delay for as much as two weeks without risking
not having a rec in Japan.
dbaron: Seems short to attempt any implementation.
<dbaron> CSP2 did it in about 6 weeks
<dbaron> actually CSP2 did it in 5 weeks and 2 days
astearns: Proposal is therefore to drop sideways and go to PR as
soon as possible then.
florian: Is there anything else waiting for level 4?
florian: Otherwise you can make a level 4 right away and push a
very light level 4, we could get sideways pretty soon.
gsnedders: I thought we could get away with the waiting time if
there is good indication the features aren't likely to
cause trouble.
gsnedders: Since they are in current CR, that match the criteria.
tantek: I had the same point; plus you can also overlap the
exclusions periods.
tantek: The process doesn't have special consideration for levels.
tantek: Other solution would be to spit the spec.
Florian: We won't get an implementation in the time we would save
anyway, lets just do the normal way.
astearns: Can we resolve on taking the current spec to PR minus
the sideways features?
dbaron: Can we get the link to the implementation report?
<Bert> http://test.csswg.org/harness/review/css-writing-modes-3_dev
<gsnedders> https://test.csswg.org/harness/results/css-writing-modes-3_dev/grouped/filter/1/
specifically shows what doesn't meet CR-exit criteria
<koji> http://kojiishi.github.io/generate-w3c-implementation-report/css-writing-modes-3/status-2016-09.html
fantasai: Since some tests are failing, we would need to write a
document on why some of the tests do not really matter..
Florian: We really need some document because some things are red
and we will need to justify why for the transition
Florian: and don't forget to also include all the tests that we do
pass, there should be a lot of green and a bit of red to
put all the chances on our side.
Florian: 232 tests don't pass because new tests seem to have been
added
Florian: that seems a lot
<tantek> also need to have feature coverage in tests
koji: In September there were 118
Florian: The other problem is that features themselves have
failure, even if we can always find two implementations
for any test.
Rossen: Well the criteria is clear, it is by feature.
Florian: Yes, and features can require more than one test.
??: so what do we do?
???: Also we can draw a line on the test suite, and keep letting
people contribute tests, we cannot keep the report up to date
all the time.
Florian: Is there a text-combine implementation?
Rossen: Yes, in Edge it now does.
tantek: Second implementation?
Florian: So do we drop?
Florian: Also some features we will remove may need errata in the
future.
Florian: The look-ahead feature.
????: we could make it undefined in the level 3 then.
(Florian and fantasai reviewing the features)
fantasai: multicol + orthogonal flow which is too long for the
document => do something smart (but nobody implemented
it)
Florian: But this is not a feature, just a behavior clarification;
we can use SHOULD and get away with it without actually
removing the recommendation.
gsnedders: Are webkit and blink able to be considered two
implementations?
eae: That happened during the fork, so a fair amount is shared,
but a fair amount is likely not too.
Florian: So, anyway, can we use SHOULD, I don't like un-defining
the feature, we have a goal.
fantasai: Or we could use MAY.
astearns: So, looks like we need an updated draft, then we can ask
for PR.
fantasai: I will work on the edits.
astearns: And koji will work on the implementation report.
Florian: With a test snapshot from September minus things we will
have removed?
plinss: It is possible (but requires some work).
astearns: And then we split the spec, with what name for the
second version?
fantasai: Writings Modes Level 4; levels is a css thing not in the
process.
SteveZ: I don't see any rule who seem to either encourage nor
discourage that.
SteveZ: The other problem is that changing the MUST to SHOULD risk
to be considered a substantial change and trigger another
CR.
Florian: Well, the change will not risk having an impact on
existing implementations, everyone that was compliant
still is.
tantek: I disagree with SteveZ too.
Rossen: Let's keep the split process out of the f2f.
<dauwhe> does anyone know if the new PR of writing modes will
cover all the prefixed features in EPUB?
<skk> dauwhe, do you mean EPUB3.0.1? or EPUB3.1?
<dauwhe> 3.1
ACTION fantasai: drop at-risk features that were not implemented
(with possibly a "soft-drop") and publish updated L3, and
republish what we have now as L4.
<trackbot> Created ACTION-815
ACTION koji compile impl report for writing-modes
<trackbot> Created ACTION-816
ACTION plinss create snapshot of writing modes test suite
<trackbot> Created ACTION-817
RESOLVED: Create Level 4 of Writing Modes as current draft, Level
3 to drop all at-risk items, publications TBD
CSS Tables
==========
Scribe: Florian
<gregwhitworth> https://github.com/w3c/csswg-drafts/projects/3
fremy: We added some text for width distribution in fixed table
layout.
fremy: Please review.
fremy: Also fixed some bugs.
fremy: The spec missed some references to css2.1.
fremy: It's been clarified with regards to percentage heights.
fremy: It would be good to have a new WD.
Florian: We have a bit of an ongoing discussion on repeated
headers and footers, but that doesn't have to block.
RESOLVED: Publish new WD of css-tables
gregwhitworth: Please give feedback on the things that are marked
as "need UA review"
dbaron: It's called "ready for UA review"
gregwhitworth: This is better to get confirmation from existing
implementation first that this is fine before
trying to get WG discussions / resolution.
[discussing what to discuss]
Scribe: fantasai
Values & Units 4
================
<fantasai> https://drafts.csswg.org/css-values-4/
<fantasai> https://drafts.csswg.org/css-text-decor-4/
<astearns> https://drafts.csswg.org/css-values-4/#changes
<fantasai> https://drafts.csswg.org/css-values-4/#changes
<fantasai> Added the vi, vb, ic, lh' and rlh'' units.
fantasai: Should we publish FPWD, or are there other things we
want to handle before FPWD?
fantasai: calc() serialization rules are also "new", marked as
under discussion.
jensimmons: Aspect ratio unit?
fantasai: Still not clear whether that should be unit or property.
Florian: Lots of proposals for units.
Issue 837
---------
dauwhe: I propose closing issue 837 with prejudice.
Florian: And person proposing them explicitly said, not discussing
use cases.
astearns: So, resolve to close issue?
tantek: I propose requesting that the person proposing these units
incubate them in the WICG. :)
astearns: I'm hearing no objection to close this issue per WG
resolution.
RESOLVED: Reject all changes in https://github.com/w3c/csswg-drafts/issues/837
Adding older typographic units
------------------------------
fantasai: Wanted to see if anyone has other things to add to this
draft before FPWD.
dauwhe: Have we discussed adding old-school typographic units?
dauwhe: I've done a bunch of conversions from pica notation.
dauwhe: <picas>p<points>
astearns: I've been waiting for properties and values to get to
the point where you can put your own parsing for this.
astearns: Would you want to see picas in this draft, or wait for
the future, or...?
dauwhe: As long as we're drawing up a FPWD, might be worth putting
in.
SteveZ: Role of FPWD is to trigger patent review, so more complete
is better than less complete.
astearns: Would anyone object?
fantasai: Would like to hear from dbaron/TabAtkins because this
involves the parser.
TabAtkins: This doesn't parse well with CSS.
TabAtkins: Strongly opposed to that particular notation going into
CSS, unless we adjusted Syntax to allow for it.
TabAtkins: And then I'd still be unhappy about it.
dbaron: are you allowed to use e notation in both halves?
Florian: What about introducing a functional notation?
Florian: It would at least allow you to convert existing designs
very easily.
TabAtkins: Kinda would prefer to wait for Houdini to see if it's
popular enough.
Florian: Doubt these units are patented.
* liam notes to dauwhe that Point Cicero is still in use (or was
last time I checked) in Europe as well
dauwhe: There's 19th century prior art here.
dauwhe: It's nice, but not critical.
<liam> thinks it'd be better to add @unit tip { size: 12cm; range:
linear; } or something rather than every possible unit
<TabAtkins> liam: Yeah, a Houdini API for units (+ a declarative
version) would be nice.
Cap Height Unit
---------------
fantasai: There was a request for a cap height unit.
<fantasai> https://github.com/w3c/csswg-drafts/issues/660
myles: Problems with cap-height aren't any worse than ex-height
SteveZ: i18n issues?
Florian: Are there fonts that don't contain ASCII range?
dauwhe: Inline does have heuristics for figuring these out,
because it needs the cap height.
astearns: Objections to cap height?
SteveZ: Use case?
astearns: Sizing things to match capital letters.
SteveZ: Thai?
<liam> +1
myles: ex-height in Thai?
myles: We've certainly had requests for this unit. Haven't had as
many request for all of the various other typographic units.
SteveZ: We don't get much requests for things that aren't English
or European.
SteveZ: Indic/SEAsian don't talk to us very much.
Bert: There are various TFs writing typography requirements for
various languages.
Bert: Should at some point read them.
SteveZ: I won't object strenuously.
Florian: I would like to see specific use case.
fantasai: Bert had a magazine where the title was in caps, and
there was a wide stripe of color exactly the cap height.
astearns: We need to know this measure for initial letter anyway.
Florian: There we have the feature but not the unit.
astearns: We know the feature is inadequate for some other
languages. Adding this in would allow doing something
slightly different if that's what you wanted.
SteveZ: So for languages that have caps, you'd use this unit, and
for others you'd use some other measure.
astearns: Say you have fancy roman font, and fancy background.
Initial letter will alight top of fancy background with
top of first line. But what you really want to do is to
match the perceived cap height of those glyphs.
dauwhe: initial-letter will take the cap-height of the glyph.
astearns: Depends on how the font is put together.
Florian: But then the cap height unit wouldn't help either,
because it comes from same source.
Florian: Not strongly oppose, just might come up with better
solution to use cases if we don't need the use cases.
TabAtkins: Core use case is image replacement for glyphs that are
matched exactly to the capital letters.
plinss: That's what it use to be.
astearns: Objections to cap unit?
SteveZ: Given there's a definition in initial-letter, no objection.
RESOLVED: Add cap unit
ACTION TabAtkins Fix bikeshed errors in css-values-4
<trackbot> Created ACTION-818
ciceros, didot, and ens
------------------------
plinss: Propose to add ciceros, didot, and ens
<plinss> didot (dt) where 15dt=16pt, cicero (cc) where 1cc=12dt,
en=0.5em
<liam> +1 to adding didot and cicero and ens
<dauwhe> https://github.com/w3c/csswg-drafts/issues/315
Bert: People use mm now,
smfr: Don't want to add if no one's going to use them.
fantasai: Since these are simply multiples of existing units,
might be worth waiting to see if there is author demand.
Florian: What about height of kanji characters?
fantasai: Why not use ems?
<liam> +1 though to way of adding user-defined units instead.
<liam> [en is useful because it approximates average character
width for a lot of fonts]
<myles> liam: isn't that just calc?
<liam> [no, not calc really, although a preprocessor could do that
for the static cases (not e.g. cap height)]
astearns: dt, cc, etc. can be done through preprocessor
astearns: For those units that aren't simple conversions, might
want to see evidence
astearns: that people are putting in the effort to make those
conversions.
dauwhe: Might be worth checking PDF renderers as well.
plinss: It's a multiple, but not so convenient.
SteveZ: Put an issue in the document?
Florian: If you have use cases, come forward.
RESOLVED: Add issue to css-values-4 asking for whether didot,
cicero, ens are needed.
myles: When do we know when to cut off feedback on this issue?
astearns: When we want to close issues to go to CR.
* liam notes indesign supports cicero
Kanji Unit
----------
Florian: Kanji character
Florian: If you size a gaiji image to 1em, ink area will be a bit
too big.
dbaron: ic unit is wrong axis?
fantasai: It's equivalent to an em generally.
fantasai: Includes the extra space around the glyph ink
....
fantasai: I understand the use case perfectly, and if we get that
request from CJK people, then I'm ok to add it. But so
far doesn't seem to be a high request.
dbaron: Are the font metrics for that any good?
dauwhe: Font metrics are a constant disappointment
myles: It's important for a UA to be able to figure out if the
metric is bad and provide an alternate. For cap-height,
very simple.
fantasai: We actually have the heuristics for this in the initial
letter spec, because needed there.
SteveZ: People at Adobe reviewed that section and said it was OK.
astearns: We have a use case, idea of how it'd be done...
Florian: But don't have strong demand.
RESOLVED: Add an issue to ask if there's a need for this unit.
Unit Math
---------
astearns: Anything else for this draft?
fantasai: unit math, e.g. divide length by length and use in a
formula
<fantasai> https://github.com/w3c/csswg-drafts/issues/545
fantasai: Also min() and max()
<fantasai> https://github.com/w3c/csswg-drafts/issues/544
astearns: Do we want to put unit math in the draft?
dbaron: I think we already have a resolution to do this.
RESOLVED: Add unit math to css-values-4
astearns: Don't have to get all the details in, just get it
roughly sketched in.
min/max
-------
astearns: I think we should get min/max in as well
dbaron: Question about min/max
dbaron: Are we only adding them inside calc, or also as top-level
things?
[discussion of what that means]
TabAtkins: Would min() and max() accept expressions then at top
level?
dbaron: Early drafts of calc() accepted min() and max()
dbaron: They were things that could be in calc()
dbaron: If the calc() only contained min() or max() and nothing
else, could eleminate the calc() wrapper
RESOLVED: add min() and max() to css-values-4, valid within and
without calc(), accepts calc expressions as arguments, N
arguments<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
<tr>
<td style="width: 55px; padding-top: 13px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon"
target="_blank"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
<td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link"
target="_blank" style="color: #4453ea;">www.avast.com</a>
</td>
</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
height="1"></a></div>
Received on Tuesday, 14 February 2017 01:21:58 UTC