IRC log of css on 2009-03-04

Timestamps are in UTC.

00:24:26 [RRSAgent]
RRSAgent has joined #css
00:24:26 [RRSAgent]
logging to
00:24:30 [dbaron]
RRSAgent, make logs public
00:24:33 [ChrisL]
trackbot, start telcon
00:24:35 [trackbot]
RRSAgent, make logs member
00:24:35 [Zakim]
Zakim has joined #css
00:24:37 [trackbot]
Zakim, this will be Style_CSS FP
00:24:37 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
00:24:38 [trackbot]
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
00:24:38 [trackbot]
Date: 03 March 2009
00:24:46 [dbaron]
RRSAgent, make logs public
00:24:50 [ChrisL]
zakim, remind us in 8 hours to go home
00:24:50 [Zakim]
ok, ChrisL
00:25:42 [jdaggett]
00:30:13 [ChrisL]
Topic: Media Queries
00:30:18 [ChrisL]
Scribe: Hakon
00:31:19 [ChrisL]
scribenick: howcome
00:33:36 [szilles]
szilles has joined #css
00:35:46 [howcome]
Chris: specific MQ issues?
00:35:47 [MikeSmith]
RRSAgent, make minutes
00:35:47 [RRSAgent]
I have made the request to generate MikeSmith
00:35:53 [howcome]
Anne: several comments have been made
00:36:21 [howcome]
Anne: Dean Jackson has proposed changes in aspect-ratio syntax
00:36:24 [ChrisL]
Dan Jackson asked for syntax changes in some queries
00:36:43 [anne]
00:37:03 [anne]
00:37:18 [howcome]
howcome: aren't we dropping these
00:37:30 [howcome]
Anne: they're marked at risk
00:38:12 [howcome]
Anne: I would be fine dropping the features at risk, and keep orientation unchanged
00:38:46 [shinyu]
shinyu has joined #css
00:39:14 [shinyu]
shinyu has joined #css
00:39:19 [howcome]
Anne: the use case is to have a DOM interface to the orientation
00:39:39 [masayuki]
masayuki has joined #css
00:41:03 [ChrisL]
portrait or landscape is much more useful
00:41:33 [howcome]
steve: is there a square pixel issue involved?
00:42:07 [howcome]
dbaron: 3.1 supports aspect-ration
00:42:14 [howcome]
00:42:16 [fantasai]
Anne: s/the use case/the use case for degrees/
00:42:39 [fantasai]
Chris: If you're using it for games and things, then you also want to know the tilt, the acceleration, etc. Just make another API
00:43:02 [howcome]
dbaron: the use case for device-aspect-ration is weak
00:43:06 [fantasai]
Steve: In that case you'd want landscape/portrait in addition to the orientation angle
00:43:17 [fantasai]
dbaron: the use case for device-* is weak
00:43:31 [howcome]
dbaron: but we implement both aspect-ratio and device-aspect-ratio
00:43:38 [dbaron]
00:45:03 [ChrisL]
I could see a stylesheht that gave 4 columns for a 16:9 landscape and 3 for 4:3
00:45:10 [ChrisL]
00:45:36 [howcome]
fantasai: one use case is having more columns if the display is wide
00:46:08 [ChrisL]
00:46:37 [fantasai]
anne: in that case you care about the width
00:46:46 [fantasai]
fantasai: Not if you're doing a presentation that scales to fill the space
00:47:10 [howcome]
steve: if I have several images, I could select the right one to fill the sceen
00:47:43 [howcome]
steve: I thought we went through this in great detail, why are we discussin this?
00:47:58 [howcome]
annevk: apple has proposed a syntax change
00:48:21 [howcome]
dbaron: given that we now support exact matching, we should stick to our current syntax
00:48:46 [ChrisL]
yes, trying to match on a float is liable to error
00:51:40 [fantasai]
howcome is skeptical that aspect-ratio is useful
00:51:56 [fantasai]
fantasai: you can use it to select a different video, widescreen vs fullscreen
00:52:33 [fantasai]
anne: device-aspect-ratio would be useful for videos too
00:52:54 [jdaggett]
00:53:22 [fantasai]
fantasai: Media queries are used for more than just CSS
00:54:02 [fantasai]
Chris: Mozilla and Opera both implement it
00:54:04 [ChrisL]
common industry use is ratio - 16:9, 16:10, 4:3 not 1.623
00:54:20 [ChrisL]
so we have implementations in firefox, opera and webkit
00:54:41 [howcome]
resolved: no current changes
00:55:23 [howcome]
chrisl: any other comments?
00:55:27 [fantasai]
RESOLVED: Keep aspect-ratio and device-aspect-ratio, no changes to syntax
00:55:55 [howcome]
annevk: some editoral comments, some comments on tty
00:57:05 [howcome]
annevk: we don't clarify what px unit means for tty devices
00:59:52 [howcome]
annevk: that clarification should possibly go into the Values and Units draft
01:00:52 [ChrisL]
there was one about malformed queries
01:00:53 [ChrisL]
01:01:40 [howcome]
chrisl: is there as disposition of comments?
01:02:07 [howcome]
annevk: I can add the new issues to the previous disposition of comments
01:02:35 [howcome]
dbaron: what's the issue with the formal grammar
01:02:53 [anne]
01:05:26 [howcome]
howcome: so, it seems we currently can't take all grammars in all CSS specs, concatinate them and have something valid comes out
01:05:34 [howcome]
steve: the formal grammar is only a hint
01:06:27 [howcome]
jdaggett: there are things that cannot easily be expressed in formal grammars
01:06:50 [howcome]
szilles: do we say anywhere what the goal of the formal grammars are?
01:07:22 [howcome]
howcome: HTML5 writes it out in prose
01:07:32 [howcome]
Mike: by desing
01:07:43 [howcome]
01:19:52 [sylvaing]
sylvaing has joined #css
01:20:17 [jdaggett]
jdaggett has joined #css
01:20:23 [ChrisL]
ChrisL has joined #css
01:20:32 [szilles]
szilles has joined #css
01:20:35 [anne]
anne has joined #css
01:20:40 [shinyu]
01:20:46 [ChrisL]
The spec could state that, due to grammar overrides in the prose, the grammar is not sufficient by itself for creating a parser
01:20:48 [ChrisL]
The snapshots could collect together the 2.1 grammar plus the patches defined in each odule, to goive a consistent grammar
01:20:55 [dbaron]
dbaron has joined #css
01:21:01 [masayuki]
masayuki has joined #css
01:21:17 [howcome]
howcome has joined #css
01:21:25 [howcome]
annevk: i agree with the comment that the css grammar is rather hacky
01:21:41 [howcome]
dbaron: if we think this is important, somebody should sit down and think about it
01:21:46 [howcome]
fantasai: the grammar could be described in a snapshot
01:21:50 [howcome]
annevk: the alterative is for MQ to define its own grammar, like the CSS selectors spec
01:21:55 [howcome]
steve: there are selveral pieces to this: all the bits are not meant to go into a grammar generator
01:22:08 [ChrisL]
rrsagent, here
01:22:08 [RRSAgent]
01:22:32 [ChrisL]
Meeting: CSS WG f2f, Tokyo
01:22:32 [szilles_]
szilles_ has joined #css
01:22:37 [ChrisL]
Chair: Chris
01:23:37 [MikeSmith]
MikeSmith has joined #css
01:24:10 [howcome]
fantasasi: the productions for one specific module is prefixed with an identifier specific to the module; if a production is intended to replace an existing one, this will be marked
01:24:15 [ChrisL]
s/ odule/ module/
01:24:21 [fantasai]
01:24:38 [ChrisL]
01:24:43 [ChrisL]
01:26:38 [howcome]
fantasai: anne can either define a grammar for MQ or resolve the differences with the global grammar.
01:28:14 [howcome]
chrisl: somebody has to sit down and propose a solution
01:28:50 [howcome]
RESOLVED: anne can choose to either define a grammar for MQ or resolve the differences with the global grammar
01:30:46 [fantasai]
I don't think we have anything to discuss with namespaces, just need implementation reports
01:31:02 [fantasai]
The test suite went through a very meticulous review process and has already been published.
01:58:16 [fantasai]
Topic: Paged Media
01:59:04 [shinyu]
02:01:57 [ChrisL]
So, its not possible to select the initial containing block and set its size (and then set the margins to be auto)
02:02:15 [ChrisL]
ee: can set the document root element to be a fixed width
02:15:11 [dbaron]
dbaron has joined #css
02:15:50 [jdaggett]
jdaggett has joined #css
02:16:12 [szilles]
szilles has joined #css
02:17:26 [anne]
anne has joined #css
02:17:50 [MikeSmith]
MikeSmith has joined #css
02:19:06 [sylvaing]
sylvaing has joined #css
02:23:47 [MikeSmith]
jdaggett: 基本半面 in Japanese?
02:24:22 [jdaggett]
02:24:32 [jdaggett]
check jp version?
02:25:26 [jdaggett]
02:25:35 [MikeSmith]
02:26:07 [jdaggett]
02:26:19 [jdaggett]
MikeSmith: ^
02:26:49 [MikeSmith]
hmm, OK
02:26:50 [MikeSmith]
02:30:42 [ChrisL]
ChrisL has joined #css
02:32:08 [MikeSmith]
so seems like it's 基本版 as as unit modifying 面 .. translates as "baseline page"
02:33:34 [jdaggett]
compound noun, no? 基本 + 版面
02:34:58 [ChrisL]
rrsagent, here
02:34:58 [RRSAgent]
02:37:43 [MikeSmith]
jdaggett: I never seen the word 版面 ... trying to figure out what it might mean
02:39:05 [jdaggett]
02:39:26 [masayuki]
masayuki has joined #css
02:39:35 [MikeSmith]
ah, template, I guess?
02:40:26 [fantasai]
Discussion of kohon hanmen and Japanese layout.
02:40:26 [fantasai]
Elike summarizes what is meant by "kihon hanmen".
02:40:26 [fantasai]
It refers to three things:
02:40:26 [fantasai]
1. The box that is the equivalent of the page area,
02:40:26 [fantasai]
i.e. the box in which the content is laid out on
02:40:28 [fantasai]
the page.
02:40:31 [fantasai]
2. The settings used to arrive at the size of this
02:40:33 [fantasai]
box, namely:
02:40:36 [fantasai]
- font-size
02:40:38 [fantasai]
- number of columns per page
02:40:41 [fantasai]
- column gap
02:40:43 [fantasai]
- width of column
02:40:46 [fantasai]
- line gap
02:40:48 [fantasai]
- number of lines per page
02:40:51 [fantasai]
3. The grid formed by those settings ...
02:40:53 [fantasai]
Murakami-san writes:
02:40:56 [fantasai]
@page {
02:40:58 [fantasai]
margin: auto;
02:41:01 [fantasai]
width: 40em;
02:41:03 [fantasai]
height: calc(20*16pt);
02:41:06 [fantasai]
font-size: 10pt;
02:41:08 [fantasai]
line-height: 16pt;
02:41:11 [fantasai]
02:41:14 [fantasai]
Murakam-san explains that in Japanese layout, you start
02:41:16 [fantasai]
with the kihon hanmen, and then center it within the page,
02:41:19 [fantasai]
or specify one side of the margin and let the other margin
02:41:21 [fantasai]
be auto. Suggests a unit for line-height would be useful.
02:41:24 [fantasai]
fantasai suggests that allowing @page to accept width and
02:41:26 [fantasai]
height should be sufficient. The author (or authoring tool)
02:41:29 [fantasai]
may have to do so some math to get the width and height of
02:41:31 [fantasai]
the kihon hanmen from the settings, but then the margin
02:41:34 [fantasai]
auto positioning should work.
02:41:36 [fantasai]
dbaron suggests the rem unit might be useful here
02:41:39 [fantasai]
Discussion of whether font-size and line-height in @page
02:41:42 [fantasai]
should affect the root element. No, it should not.
02:41:44 [fantasai]
Should @page inherit from the root element?
02:41:47 [fantasai]
Murakami-san writes column-count, writing-mode, and column-width
02:41:49 [fantasai]
into the @page rule. Discussion of page-based templates.
02:41:52 [fantasai]
Chris: So the bit of consensus that I heard was that 'width' and 'height' can be used on @page
02:41:55 [fantasai]
Steve: Also inheritance is as before, the :root element is the top of the inheritance chain and does not inherit from anything else
02:47:34 [fantasai]
Discussion of copying values between @page and :root
02:47:45 [fantasai]
fantasai does not want inheritance from @page to :root
02:47:54 [fantasai]
fantasai suggests inheritance from :root to @page
03:02:54 [fantasai]
Lots of discussion about page templates and getting @page templates to match up with elements in the tree
03:03:06 [fantasai]
e.g. an Appendix template that matches up with <div class="appendix">
03:03:59 [fantasai]
Proposed resolutions:
03:04:24 [fantasai]
1. Apply width and height to the page box, following rules in CSS2.1:10 wrt calculating margins
03:04:34 [fantasai]
2. @page inherits from the root
03:05:03 [fantasai]
3. Synchronization between named page templates and content deferred until later
03:10:15 [fantasai]
fantasai explains that because the print industry is relying on css3-page for their own standards, we may need to add loopholes that allow implementations to be conformant if they don't do the above
03:12:57 [fantasai]
RESOLVED: 'width' and 'height' apply to the page box, follow rules in CSS2.1:10 wrt calculating margins. This behavior is at-risk.
03:14:11 [fantasai]
RESOLVED: @page inherits from the root. B/c this was not defined in previous CR, conformant implementations may instead use the initial value
03:15:40 [fantasai]
s/Synchronization/Synchronization of property values/
03:28:26 [fantasai]
Murakami-san shows an example where different parts of the document have different kihon-hanmen
03:29:05 [fantasai]
fantasai writes up an example that uses just the new 'width' resolution and named pages to accomplish this use case
03:29:25 [fantasai]
Steve suggests adding fantasai's example to the spec
03:29:28 [fantasai]
Example is:
03:29:30 [fantasai]
03:29:32 [fantasai]
03:30:01 [fantasai]
.main { page: main; columns: 2; column-gap: 1em; } /* 2*30ch width +gap = 61em; */
03:30:25 [fantasai]
.index { page: index; columns: 3; column-gap: 1em; } /* 3*20ch width + gap = 62em; */
03:30:29 [fantasai]
03:30:33 [fantasai]
<div class="main"> ... </div>
03:30:39 [fantasai]
<div class="index"> ... </div>
03:30:40 [fantasai]
03:30:45 [fantasai]
@page { margin: auto; }
03:30:55 [fantasai]
@page main { width: 61em; }
03:31:01 [fantasai]
@page index { with: 62em; }
03:31:23 [fantasai]
ACTION: fantasai add this example to the spec
03:31:24 [trackbot]
Created ACTION-125 - Add this example to the spec [on Elika Etemad - due 2009-03-11].
03:31:46 [fantasai]
<br type="lunch"/>
04:26:13 [dbaron]
dbaron has joined #css
04:28:33 [sylvaing]
sylvaing has joined #css
04:28:41 [jdaggett]
jdaggett has joined #css
04:30:26 [dbaron]
dbaron has joined #css
04:32:01 [ChrisL]
ChrisL has joined #css
04:35:52 [fantasai]
04:37:13 [fantasai]
Joined by
04:37:16 [fantasai]
04:37:21 [fantasai]
04:37:26 [fantasai]
Yasuhiro Anan-san
04:38:04 [fantasai]
Tatsuo Kobayashi-san, Justsystem, chair of JLTF
04:38:19 [fantasai]
Anan-san, Microsoft, will be translating for Kobayashi-sensei
04:39:24 [szilles_]
szilles_ has joined #css
04:42:14 [szilles_]
EE: offers to discuss the specs that are relevant to the JLTF requirements
04:42:21 [anne]
anne has joined #css
04:42:31 [szilles_]
EE: there are 3 relevant spects plus GCPM
04:42:39 [dbaron]
04:43:08 [szilles_]
EE: the first spec is Paged Media that covers the description of the page, its margins, headers and footers, ...
04:44:03 [szilles_]
EE: there is a default page, plus pages forfirst, left and right pages and a set of named pages.
04:44:45 [szilles_]
EE: the content has to fit inside the page box else it gets clipped
04:46:47 [szilles_]
EE: the current Paged Media model does not have a concept of "spread" (that is two facing pages together), that is a topic for a future version.
04:48:09 [szilles_]
K-san: what about line-staking-strategy?
04:48:56 [fantasai]
Note to self: css3-page should not clip to the page area, but to the padding box of the page box
04:50:15 [szilles_]
DB: Some of the goals of the line box module are contradictory; e. g., since an author cannot really know what font (and other) resources will acctually be used.
04:51:26 [szilles_]
DB: the current line stacking rules are not ideal for Western topography and they certainly do not consider things like Rugy annotations.
04:52:34 [fantasai]
Discussion of line-stacking-strategy
04:52:47 [fantasai]
dbaron: The current rules aren't even ideal for Western typogrpahy
04:53:23 [fantasai]
dbaron: We might want different options for what gets considered
04:54:29 [fantasai]
Anan-san, Kobayashi-san: ruby above the first line spills outside the kihon hanmen
04:54:52 [fantasai]
Steve: Do we flag this as an issue to come back to later?
04:55:32 [fantasai]
fantasai: yes. We don't have anyone working on a module that involves this. Nobody will be able to fix it within the next 6 months
04:56:36 [szilles_]
K-san: figure 37 of the current JLTF draft shows the ruby outside the Kihonhanmen on the first line.
05:00:52 [fantasai]
dbaron asks if the ruby crosses the midline between two lines
05:00:54 [fantasai]
yes, it does
05:00:58 [szilles_]
The current JLTF draft is
05:01:00 [szilles_]
05:01:10 [fantasai]
Kobayashi-san: The line gap is usually smaller than the line width, e.g. 2/3
05:01:24 [fantasai]
Kobayashi-san: Ruby is usually 1/2 the size of the font size
05:03:06 [szilles_]
K-san and K-sensei: the ruby chars are set without and "leading" between the base characters and the ruby characters; this assumes internal leading in the fonts.
05:03:11 [fantasai]
Anan-san: The current MSFT implementations grow the line-height to accommodate ruby, but this is not correct
05:03:22 [fantasai]
Anan-san: the ruby characters should fit within the line-gap
05:03:23 [masayuki]
masayuki has joined #css
05:07:28 [szilles_]
SZ: One reason that line-stacking-strategy was created was to allow a user to specify whether he wanted to guarantee that no overlap (the CSS rule) or he wanted to guarantee consistent spacing between lines
05:08:27 [szilles_]
SZ: Since CSS tries to guarantee no overlap of lines, it would be reasonable to have the Ruby chars taken into account in determining the actual line height.
05:09:23 [szilles_]
EE: CSS3 Page module covers margin boxes, their position, their content
05:09:47 [szilles_]
EE: for styling the boxes the many of the normal CSS properties can be used.
05:10:09 [szilles_]
EE: page numbers can be inserted
05:10:27 [szilles_]
EE: various paper sizes can be selected
05:11:28 [szilles_]
EE: the current rules in Paged Media select the paper size, and determine the page area by setting values for the margins. This does not guarantee a specified numbers o lines or line lengths
05:13:42 [szilles_]
EE: this morning we proposed that Paged Media would allow explicit setting of the Width and Height using the rules of CSS2.1 section 10
05:15:37 [szilles_]
EE: this allows explicit setting of the Kihonhanmen size in EMs and centering the resultant area on the paper.
05:16:47 [szilles_]
EE: named pages provide a kind of styling template that can be applied to different sections of the content (using selectors)
05:17:55 [szilles_]
EE: The second document is CSS Text which is, itself, not a complete module (it is an extract of a prior module.
05:18:49 [szilles_]
EE: it covers wihite space control, line breaking and word boundaries.
05:19:24 [szilles_]
EE: We know that Japanese has its own line breaking rules which are different than western text rules.
05:20:05 [szilles_]
EE: There are some named rules for controlling line breaking
05:22:47 [szilles_]
Anan-san: Appendix 3 of the JLTF document has an explicit description of line-breaking for Japanese based on character classes
05:25:13 [szilles_]
Anan-san: There are at least two sets of rules for line breaking: basic ones such as the Unicode line breaking rules
05:26:46 [szilles_]
Anan-san: and stricter rules that cover a more complete set of cases, such as those in Appendix 3 of the JLTF report
05:27:27 [szilles_]
Anan-san: for example, Firefox does a better job of handling rules than some other implementations
05:29:02 [szilles_]
Anan-san: Microsoft Word adopted an earlier version of the rules in JIS4051 and, therefore, allows some breaks that would not be expected.
05:31:04 [szilles_]
EE: for western text, there are 2 options, break where allowed by the language and break anywhere (including inside a word)
05:32:19 [szilles_]
EE: for japanese, there are also two options: loose and strict, with strict being the default. Specifying what these mean, however, is a problem.
05:33:40 [szilles_]
Murasaki-san: breaking before small kana is fairly common in Japanese
05:38:39 [szilles]
szilles has joined #css
05:38:45 [fantasai]
Kobayashi-san: There are three levels: newspaper level, magazine level, book level
05:38:53 [szilles]
There are 3 levels: newspaper level, magazine level and book level
05:38:59 [fantasai]
Murakami-san: Many books use normal level, not strict level
05:39:01 [jdaggett]
jdaggett has joined #css
05:39:12 [dbaron]
dbaron has joined #css
05:39:20 [masayuki]
masayuki has joined #css
05:39:33 [fantasai]
Kobayashi-san discusses house rules
05:39:33 [szilles]
There are also "house rules" used by a particular publication house
05:39:51 [dbaron]
Perfect line breaking rules for English probably don't exist either. Consider finding the allowed breaks in bis(4-chlorophenyl)-1,1,1-trichloroethane
05:39:58 [szilles]
K-san: we do not, however, need to have rules at that level of detail
05:40:10 [fantasai]
Kobayashi-san: Although some implementations use house rules, we can still define some base levels
05:40:29 [fantasai]
Murakami-san writes: loose, normal, strict
05:42:16 [szilles]
K-sensei: there are 4 options: loose, normal, strict and very-strict
05:43:03 [sylvaing]
sylvaing has joined #css
05:44:22 [szilles]
very-strict forbids breaks before small-kana, the sound lengthen mark and decoration marks.
05:45:17 [szilles]
K-san: almost all publications do not not use very-strict
05:45:49 [szilles]
From now on we will use levels 1,2,3 and 4 where 4 is most strict and 1 is least strict
05:46:26 [szilles]
level 4 is not often used.
05:48:46 [szilles]
K-san agrees that the JLTF will define the rules for the 4 classes of line-breaking rules.
05:49:42 [szilles]
EE: could we also get a textual summary of the rules that would give an author an sense of what to expect without tracing thru the table?
05:50:36 [szilles]
EE: which level is the default level?
05:50:52 [szilles]
K-san/K-sensei: level 3 is the default
05:55:58 [szilles]
EE: do these breaking rules also cover numbers and foreign language text?
05:57:54 [szilles]
EE: for example, there is a property value that applies to latin text that allows breaking anywhere within a word. This occurs, for example, in Korean usage.
05:58:37 [szilles]
K-san/K-sensei: Japanese link-breaking does not allow line-breaking inside a word.
06:22:22 [jdaggett]
jdaggett has joined #css
06:24:18 [jdaggett]
jdaggett has joined #css
06:24:26 [jdaggett]
jdaggett has joined #css
06:25:39 [jdaggett]
jdaggett has joined #css
06:29:34 [szilles_]
szilles_ has joined #css
06:31:04 [masayuki]
masayuki has joined #css
06:33:06 [anne]
anne has joined #css
06:34:29 [szilles_]
Resuming after a break
06:34:35 [ChrisL]
ChrisL has joined #css
06:34:57 [dbaron]
dbaron has joined #css
06:35:05 [szilles_]
EE: The WG thanks the JLTF for agreeing to provide us guidance on line breaking
06:35:06 [dbaron]
We also need to keep the line-breaking compatible with English. :-)
06:35:52 [szilles_]
EE: text-wrap gives control over chuncks of text beyond the word level
06:36:08 [ChrisL]
dictionary-based English hyphenation ftw!
06:36:43 [szilles_]
EE: Alignment (horizontal) controls aligning to start, end, center, justify and control over last line as well
06:37:53 [jdaggett_]
jdaggett_ has joined #css
06:39:54 [szilles_]
Anan-san/K-sensei: there are cases in Japanese in which a single line is justified.
06:40:09 [szilles_]
EE: in CSS, a single line is also a last line.
06:40:43 [jdaggett]
jdaggett has joined #css
06:41:30 [szilles_]
EE: because a window can always be resized, one cannot guarantee that a "single line" will fit within the window so ti would be justified in two or more lines unless wrapping is forbidden
06:43:15 [glazou]
glazou has joined #css
06:43:54 [fantasai]
Issue: text-align-last: justify center;
06:43:54 [trackbot]
Created ISSUE-97 - Text-align-last: justify center; ; please complete additional details at .
06:44:09 [szilles_]
Murakami-san: if there is only one character on the last line where is it placed with Justtify?
06:46:30 [szilles_]
EE: there is control over which space adjustments are used for justification:
06:51:02 [szilles_]
Anan-san: How does "inter-graphemic" apply to east asian languages?
06:51:44 [szilles_]
Many: it is there primarily for scripts like indic scripts that have grapheme clusters.
06:52:41 [szilles_]
Anan-san: Japanese characters with diacrictics for voicing do form a grapheme
06:54:30 [sylvaing]
sylvaing has joined #css
06:55:17 [szilles_]
Issue: If the same about of extra space that is being used between full width characters (for justification) is also put between half width characters, then the alignment of two half width characters with one full width character will be broken.
06:55:17 [trackbot]
Created ISSUE-98 - If the same about of extra space that is being used between full width characters (for justification) is also put between half width characters, then the alignment of two half width characters with one full width character will be broken. ; please complete additional details at .
06:56:19 [dbaron]
(I asked a few minutes ago what happens with halfwidth characters and justification.)
06:56:43 [fantasai]
ISSUE: make sure justification allows not justifying between various bits of punctuation
06:56:43 [trackbot]
Created ISSUE-99 - Make sure justification allows not justifying between various bits of punctuation ; please complete additional details at .
06:56:44 [szilles_]
Anan-san: the vertical kana repeat mark upper half should not be split from the lower half mark during justification
07:00:40 [szilles_]
JD: In implementation that use the typographic data in a font should not be considered non-conforming
07:01:11 [szilles_]
07:01:27 [szilles_]
s/In i/I/
07:01:47 [szilles_]
EE: there is spacing that does "tracking"
07:02:19 [szilles_]
EE: Word spacing does not (should not) apply to the Ideographic Space.
07:04:34 [szilles_]
Anan-san: Tsumegumi controls the reduction of spaces between characters up to the collision of the glyphs
07:06:29 [szilles_]
JD: letter spacing is problematic becuase when kerning is involved you want a multiplicative property rather than a adative one.
07:06:55 [szilles_]
EE: the current design has a percentage of the letter space; what is wanted?
07:08:38 [szilles_]
JD: what is desired for letter spacing is to add/subtract a percentage of the character advance rather than a fixed amount between all characters.
07:08:52 [fantasai]
Issue: percentage should be wrt character advance, (before or after kerning?)
07:08:52 [trackbot]
Created ISSUE-100 - Percentage should be wrt character advance, (before or after kerning?) ; please complete additional details at .
07:09:04 [szilles_]
Note that kerning changes the advance between certain characters
07:09:24 [fantasai]
Steve says after kerning
07:12:42 [fantasai]
fantasai: that would create uneven spacing in, e.g. "filling"
07:12:54 [fantasai]
07:12:58 [ChrisL]
"Anyone who would letterspace blackletter would steal sheep."
07:13:29 [szilles_]
SZ: the specification of these properties should not require the implementation of bad typography; it should allow an implementation to do "better than a minimum level"
07:13:53 [dbaron]
fantasai, so why are you introducing a new feature (% letter spacing) if you don't think it does something reasonable?
07:14:19 [szilles_]
EE: with evenly spaced tsumegumi, how do measure the space added or subtracted?
07:16:00 [fantasai]
fantasai, we're missing a measurement that accounts for the character advance width
07:16:05 [szilles_]
discussion: the tracking value is not applied to the full character advance, but (in an as yet undefined way) to the space between characters after kerning is done
07:16:13 [fantasai]
fantasai, so I picked a way to reference the advance with of a space character
07:16:23 [fantasai]
07:16:38 [fantasai]
dbaron, right now you can reference ems
07:16:52 [fantasai]
dbaron, but that gives weird results if you compare a narrowly-designed font with a widely-designed one
07:18:12 [szilles_]
a;nan-san/K-sensei: the tsumegumi can be specified in ems because the amount is typically a percent of the font size.
07:18:50 [fantasai]
anan-san: the letter-spacing applied to cjk would usually be too much for latin
07:19:00 [fantasai]
anan-san: so you may need a way to separate
07:19:42 [szilles_]
Anan-san/K-sensei: when a line has mixed latin and ideographic text the space adjustments are not uniform across the line but are different for the different kinds of text
07:23:03 [szilles_]
CL: rather than have different letter spacing values for each language, it would be better to markup each section of text with its language and use selectros to apply differn letter spacing values to the different spans
07:26:10 [szilles_]
K-san: I like CL's solution because it also handles cases where in a span things liek the font-size is changed and the letter spacing needs to change.
07:26:54 [szilles_]
EE: but, there will be cases where the foreign text is not marked up and there needs to be a way to deal with those cases.
07:27:22 [arronei]
arronei has joined #CSS
07:28:17 [fantasai]
K-san: tsumegumi like this is usually only used for short bits of text in large fonts, such as headings
07:28:23 [fantasai]
K-san: so this solution should be sufficient
07:28:30 [szilles_]
EE: trying to use Unicode ranges to control the letter-spacing is not a good idea because it does not deal with punctuation characters
07:30:54 [fantasai]
EE shows definition for punctuation-trim
07:31:15 [fantasai]
jdaggett: is this in addition to or instead of kerning?
07:33:28 [fantasai]
jdaggett: if the font is already doing this kerning, we can't tell
07:33:55 [fantasai]
anan-san: Also, the same Unicode code-point is different depending on what language the font was designed for
07:37:58 [fantasai]
k-san: Three issues interrelated: where to break the line, where to position characters by default, where to adjust (justify) the line
07:39:46 [szilles_]
szilles_ has joined #css
07:39:53 [fantasai]
k-san: There are several places to solve the issue. The CSS level, the font level, ...
07:40:14 [fantasai]
k-san: Justsystem and MSFT, between ours the handling of parentheses is slightly different
07:40:54 [fantasai]
07:41:12 [fantasai]
k-san: CSS should explicitly define its position, this will be helpful to other parties
07:41:43 [fantasai]
anan-san: Technically we can define the pairs at the font level, but once you put the characters in the line you may want different results
07:41:52 [szilles_]
earlier lost data:
07:41:58 [szilles_]
EE: punctuation-trim property - this handles the conversion of full width punctuation to half width
07:42:11 [szilles_]
JD: asks how this interacts with information in kerning tables in the fonts
07:42:23 [szilles_]
It is really hard to know if such kerning data is in the font which makes it difficult to tell whether the lower level enging (e.g. Uniscribe) will do the xform or not.
07:42:43 [melinda]
melinda has joined #CSS
07:43:13 [fantasai]
EE: so do we assume the font is wide or not?
07:45:24 [fantasai]
no real answer
07:45:33 [fantasai]
Murakami-san: Antenna House implements punctuation-trim
07:45:42 [fantasai]
Murakami-san: It applies only to CJK fonts
07:45:48 [fantasai]
Murakami-san: That have fixed-em width
07:45:57 [fantasai]
Murakami-san: full-width brackets only
07:46:06 [fantasai]
Murakami-san: Not applied to narrow punctuation
07:46:22 [fantasai]
Murakami-san: Interaction with kerning is not a problem.
07:46:35 [fantasai]
EE: how do you know if it's full-width?
07:46:55 [fantasai]
Murakami-san: MS Mincho has full-width fixed-width glyphs for punctuation
07:47:07 [fantasai]
Murakami-san: But MS P Mincho has narrower glyphs for Japanese punctuation
07:47:20 [fantasai]
Murakami-san: Antenna House punctuation-trim controls MS Mincho, but not MS P Mincho
07:47:58 [fantasai]
jdaggett: With a proportional font, the "half-width" characters are proportionally spaced
07:48:09 [fantasai]
jdaggett: whereas in a full-width font they are not (end of summary of P vs not P)
07:48:34 [fantasai]
K-san: In Unicode, fullwidth punctuation marks usually have half-width default size
07:48:44 [fantasai]
K-san: in the JLTF document
07:49:13 [fantasai]
K-san: In Japanese typsetting tradition, especially hot-metal era, usually the punctuation marks are 1/2 em size
07:49:26 [fantasai]
K-san: So when the punctuation mark need to be 1em we add 1/2em space
07:49:45 [fantasai]
K-san: Steve and us made 6 hours discussion on this at the last meeting
07:50:06 [fantasai]
K-san: And we decided to describe every punctuation mark as 1/2 width size as a default
07:50:13 [fantasai]
K-san: And with some other half-width space added
07:50:20 [fantasai]
K-san: Our document is based on such an agreement
07:50:56 [fantasai]
Steve: The reason that the discussion took 6 hours was primarily because there were several kinds of terminology being used in different parts of the document
07:51:18 [fantasai]
Steve: this contributed confusion on the part of the non-Japanese speakers who were tyring to read the document and weren't sure how many different principles were used
07:51:32 [fantasai]
Steve: So we picked one that made sense to the ppl writing the document and use that consistently
07:52:39 [fantasai]
jdagget: Fonts, and OpenType especially, have many ways of doing the same thing. E.g. kerning
07:55:47 [Lachy]
Lachy has joined #css
08:02:06 [fantasai]
Murakami-san: professional Japanese fonts use fullwidth pucntuation
08:02:49 [fantasai]
discussion of P Gothic black magic
08:04:00 [fantasai]
Anan-san: You can do pairs kerning in Uniscribe, but it's performance-expensive
08:04:05 [fantasai]
Anan-san: ...
08:04:20 [fantasai]
jdaggett: FF uses Uniscribe for a lot of text rendering
08:04:29 [fantasai]
jdaggett: for desktop, it's ok
08:04:41 [fantasai]
jdaggett: for mobile device, ehhh
08:05:11 [fantasai]
Murakami-san: Meiryo also has fixed full-width punctuation
08:05:20 [fantasai]
Murakami-san: even though Latin is proportional
08:09:36 [szilles_]
K-san: the JLTF is willing to consider having levels w.r.t the punctiuation-trim as will be done for line-breaking
08:10:35 [szilles_]
EE: the CSS WG has to explain the requirements for punctuation-trim in a way that implementers can implement it.
08:12:02 [szilles_]
EE: underline position does not really support Japanese because the convention in Japanese is to use underlines on horizontal text and before-edge lines in vertical text
08:14:50 [szilles_]
K-san: the spacing of the "underline" relative to the character box is up to the implementation; they may or may not be useful information for this in the font.
08:15:26 [szilles_]
K-sensei: Kendots should be used only for vertical text
08:18:21 [szilles_]
K-san: there are two code point for the dots; it is the context of usage, horiz or vert, that determines which glyph is used, independently of which code point is used to represent the dots
08:19:05 [szilles_]
Note, also, that the "dots" do not occur in the content, they are generated by CSS UA.
08:24:51 [Zakim]
ChrisL, you asked to be reminded at this time to go home
08:26:19 [anne]
good idea
08:27:37 [szilles_]
K-san/K-sensei: w.r.t. middle dot or the accent character, the normal size of the full width character is used, but 1/4 em is trimmed off the top and bottom of the character in a dot above the character or from the left and right of the character in a dot on the before edge.
08:30:33 [szilles_]
K-sensei: Ruby and dots will not be used together; therefore dots should be ignored (for Japanese) if specified with ruby.
08:32:13 [szilles_]
K-sensei: if text with Ruby annotation is to be emphasized, it can be done by using brackets before and after the emphasized text
08:32:53 [szilles_]
EE: Hanging Punctuation has 3 values
08:33:21 [shinyu]
08:33:37 [szilles_]
Start allows the bracket to occur prior to where the first non-punctuation character is to occur
08:33:48 [szilles_]
End does the same for the last line
08:34:15 [fantasai]
Murakami-san presents his proposal
08:34:17 [szilles_]
end-edge allows hanging on end of every line
08:36:21 [szilles_]
CL: is there a use case for "start-edge" in analogy to "end-edge"
08:37:46 [szilles_]
EE: if there is an indent of the first line, then hanging means into the indent space, not the content area.
08:38:58 [szilles_]
EE: what punctuation characters are allowed to hang with "end-edge"?
08:39:37 [Zakim]
Zakim has left #css
08:40:38 [szilles_]
Murakami-san/K-sensei: only 4 characters (stop, ideographic stop, comma and ideographic comma) can hang with "end-edge"
08:43:56 [szilles_]
Murakami-san/EE: for "start" the punctuation that hangs are opening brackets and quotes; for "end" they are ending brackets and quotes.
08:44:21 [szilles_]
It was ageed that there is no Japanese use case for "start-edge".
08:50:03 [fantasai]
end should have end-auto functionality
08:50:15 [fantasai]
forcing the punctuation to hang should be 'force-end'
08:51:02 [szilles_]
K-sensei: there is a requirement for a "forced-end" value which forces the final stop to be hanging and then justifies the chararacters that remain on the line.
08:56:21 [szilles_]
EE and Murakami-san: In the above discussion, replace "end-edge" with "end"; replace "start" with "first" and "end" with "last"
08:57:49 [glazou]
glazou has joined #css
08:58:17 [szilles_]
This renaming leaves "forced-end" meaning that the hang is forced on any line that ends with one of the four punctuation symbols that can hang with "end"
09:01:51 [MikeSmith]
MikeSmith has joined #css
09:02:30 [fantasai]
Murakami-san suggests maybe 'end' might be confusing with 'forced-end' for Western typographers
09:03:01 [fantasai]
Western typography typically only hangs the hyphen, and it's not common
09:03:13 [fantasai]
Suggestion: 'allow-end' 'forced-end'
09:03:40 [fantasai]
Other suggestion, need 'hypens' value? since Japanese doesn't hang hyphens
09:04:55 [fantasai]
Meeting closed
09:05:17 [szilles_]
EE: suggests that "end" be called "allow-end" to make it relationship to "force-end" to be more clear.
09:05:38 [szilles_]
At 6:10, the meeting adjourned for the day.
09:09:07 [MikeSmith]
RRSAgent, make minutes
09:09:07 [RRSAgent]
I have made the request to generate MikeSmith
09:09:27 [glazou]
have a nice evening
09:09:52 [MikeSmith]
RRSAgent, make logs public
09:15:14 [anne]
anne has left #css
09:21:24 [masayuki]
masayuki has joined #css
10:09:58 [A]
A has joined #Css
10:57:12 [myakura]
myakura has joined #css
12:11:03 [dbaron]
dbaron has joined #css
12:32:50 [szilles]
szilles has joined #css
12:38:23 [szilles__]
szilles__ has joined #css
13:03:19 [sylvaing]
sylvaing has joined #css
13:36:21 [annevk]
annevk has joined #css