Cascading Style Sheets (CSS) Working Group Teleconference -- 03 Mar 2009

<ChrisL> trackbot, start telcon

<trackbot> Date: 03 March 2009

<jdaggett> http://www.w3.org/Style/Group/2009/Tokyo.html

Media Queries

<ChrisL> Scribe: Hakon

<ChrisL> scribenick: howcome

Chris: specific MQ issues?

Anne: several comments have been made
... Dean Jackson has proposed changes in aspect-ratio syntax

<ChrisL> Dan Jackson asked for syntax changes in some queries

<anne> http://lists.w3.org/Archives/Public/www-style/2008Dec/0019.html

<anne> http://lists.w3.org/Archives/Public/www-style/2008Oct/0328.html

howcome: aren't we dropping these

Anne: they're marked at risk
... I would be fine dropping the features at risk, and keep orientation unchanged
... the use case is to have a DOM interface to the orientation

<ChrisL> portrait or landscape is much more useful

steve: is there a square pixel issue involved?

dbaron: 3.1 supports aspect-ratio

<fantasai> Anne: s/the use case/the use case for degrees/

<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

dbaron: the use case for device-* is weak

<fantasai> Steve: In that case you'd want landscape/portrait in addition to the orientation angle

<fantasai> dbaron: the use case for device-* is weak

dbaron: but we implement both aspect-ratio and device-aspect-ratio

<ChrisL> I could see a stylesheet that gave 4 columns for a 16:9 landscape and 3 for 4:3

<ChrisL> s/shet/sheet/

fantasai: one use case is having more columns if the display is wide

<fantasai> anne: in that case you care about the width

<fantasai> fantasai: Not if you're doing a presentation that scales to fill the space

steve: if I have several images, I could select the right one to fill the sceen
... I thought we went through this in great detail, why are we discussin this?

annevk: apple has proposed a syntax change

dbaron: given that we now support exact matching, we should stick to our current syntax

<ChrisL> yes, trying to match on a float is liable to error

<fantasai> howcome is skeptical that aspect-ratio is useful

<fantasai> fantasai: you can use it to select a different video, widescreen vs fullscreen

<fantasai> anne: device-aspect-ratio would be useful for videos too

<jdaggett> shinyu: http://krijnhoetmer.nl/irc-logs/

<fantasai> fantasai: Media queries are used for more than just CSS

<fantasai> Chris: Mozilla and Opera both implement it

<ChrisL> common industry use is ratio - 16:9, 16:10, 4:3 not 1.623

<ChrisL> so we have implementations in firefox, opera and webkit

resolved: no current changes

chrisl: any other comments?

<fantasai> RESOLVED: Keep aspect-ratio and device-aspect-ratio, no changes to syntax

annevk: some editoral comments, some comments on tty
... we don't clarify what px unit means for tty devices
... that clarification should possibly go into the Values and Units draft

<ChrisL> there was one about malformed queries

<ChrisL> http://lists.w3.org/Archives/Public/www-style/2008Dec/0064.html

chrisl: is there as disposition of comments?

annevk: I can add the new issues to the previous disposition of comments

dbaron: what's the issue with the formal grammar

<anne> http://www.w3.org/mid/Pine.LNX.4.63.0902242324240.6949@master.abisoft.spb.ru

howcome: so, it seems we currently can't take all grammars in all CSS specs, concatinate them and have something valid comes out

steve: the formal grammar is only a hint

jdaggett: there are things that cannot easily be expressed in formal grammars

szilles: do we say anywhere what the goal of the formal grammars are?

howcome: HTML5 writes it out in prose

Mike: by design

<shinyu> hi

<ChrisL> The spec could state that, due to grammar overrides in the prose, the grammar is not sufficient by itself for creating a parser

<ChrisL> The snapshots could collect together the 2.1 grammar plus the patches defined in each module, to goive a consistent grammar

annevk: i agree with the comment that the css grammar is rather hacky

dbaron: if we think this is important, somebody should sit down and think about it

fantasai: the grammar could be described in a snapshot

annevk: the alterative is for MQ to define its own grammar, like the CSS selectors spec

steve: there are selveral pieces to this: all the bits are not meant to go into a grammar generator

<ChrisL> Meeting: CSS WG f2f, Tokyo

steve: 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

<ChrisL> s/black/white/

<ChrisL> s/good/bad/g

fantasai: anne can either define a grammar for MQ or resolve the differences with the global grammar.

chrisl: somebody has to sit down and propose a solution

RESOLUTION: anne can choose to either define a grammar for MQ or resolve the differences with the global grammar

<fantasai> I don't think we have anything to discuss with namespaces, just need implementation reports

<fantasai> The test suite went through a very meticulous review process and has already been published.

Paged Media

<shinyu> http://lists.w3.org/Archives/Public/www-style/2009Mar/0005.html

<ChrisL> So, its not possible to select the initial containing block and set its size (and then set the margins to be auto)

<ChrisL> ee: can set the document root element to be a fixed width

<MikeSmith> jdaggett: 基本半面 in Japanese?

<jdaggett> hmmm

<jdaggett> check jp version?

<jdaggett> http://lists.w3.org/Archives/Public/www-style/2009Mar/0005.html

<MikeSmith> thanks

<jdaggett> 基本版面

<jdaggett> MikeSmith: ^

<MikeSmith> hmm, OK

<MikeSmith> thanks

<MikeSmith> so seems like it's 基本版 as as unit modifying 面 .. translates as "baseline page"

<jdaggett> compound noun, no? 基本 + 版面

<MikeSmith> jdaggett: I never seen the word 版面 ... trying to figure out what it might mean

<jdaggett> http://ext.dictionary.goo.ne.jp/leaf/jn/160482/m0u/%E7%89%88%E9%9D%A2/

<MikeSmith> ah, template, I guess?

<fantasai> Discussion of kohon hanmen and Japanese layout.

<fantasai> Elike summarizes what is meant by "kihon hanmen".

<fantasai> It refers to three things:

<fantasai> 1. The box that is the equivalent of the page area,

<fantasai> i.e. the box in which the content is laid out on

<fantasai> the page.

<fantasai> 2. The settings used to arrive at the size of this

<fantasai> box, namely:

<fantasai> - font-size

<fantasai> - number of columns per page

<fantasai> - column gap

<fantasai> - width of column

<fantasai> - line gap

<fantasai> - number of lines per page

<fantasai> 3. The grid formed by those settings ...

<fantasai> Murakami-san writes:

<fantasai> @page {

<fantasai> margin: auto;

<fantasai> width: 40em;

<fantasai> height: calc(20*16pt);

<fantasai> font-size: 10pt;

<fantasai> line-height: 16pt;

<fantasai> }

<fantasai> Murakam-san explains that in Japanese layout, you start

<fantasai> with the kihon hanmen, and then center it within the page,

<fantasai> or specify one side of the margin and let the other margin

<fantasai> be auto. Suggests a unit for line-height would be useful.

<fantasai> fantasai suggests that allowing @page to accept width and

<fantasai> height should be sufficient. The author (or authoring tool)

<fantasai> may have to do so some math to get the width and height of

<fantasai> the kihon hanmen from the settings, but then the margin

<fantasai> auto positioning should work.

<fantasai> dbaron suggests the rem unit might be useful here

<fantasai> Discussion of whether font-size and line-height in @page

<fantasai> should affect the root element. No, it should not.

<fantasai> Should @page inherit from the root element?

<fantasai> Murakami-san writes column-count, writing-mode, and column-width

<fantasai> into the @page rule. Discussion of page-based templates.

<fantasai> Chris: So the bit of consensus that I heard was that 'width' and 'height' can be used on @page

<fantasai> Steve: Also inheritance is as before, the :root element is the top of the inheritance chain and does not inherit from anything else

<fantasai> Discussion of copying values between @page and :root

<fantasai> fantasai does not want inheritance from @page to :root

<fantasai> fantasai suggests inheritance from :root to @page

<fantasai> Lots of discussion about page templates and getting @page templates to match up with elements in the tree

<fantasai> e.g. an Appendix template that matches up with <div class="appendix">

<fantasai> Proposed resolutions:

<fantasai> 1. Apply width and height to the page box, following rules in CSS2.1:10 wrt calculating margins

<fantasai> 2. @page inherits from the root

<fantasai> 3. Synchronization of property values between named page templates and content deferred until later

<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

<fantasai> RESOLVED: 'width' and 'height' apply to the page box, follow rules in CSS2.1:10 wrt calculating margins. This behavior is at-risk.

<fantasai> RESOLVED: @page inherits from the root. B/c this was not defined in previous CR, conformant implementations may instead use the initial value

<fantasai> Murakami-san shows an example where different parts of the document have different kihon-hanmen

<fantasai> fantasai writes up an example that uses just the new 'width' resolution and named pages to accomplish this use case

<fantasai> Steve suggests adding fantasai's example to the spec

<fantasai> Example is:

<fantasai> .main { page: main; columns: 2; column-gap: 1em; } /* 2*30ch width +gap = 61em; */

<fantasai> .index { page: index; columns: 3; column-gap: 1em; } /* 3*20ch width + gap = 62em; */

<fantasai> @page { margin: auto; }

<fantasai> @page main { width: 61em; }

<fantasai> @page index { with: 62em; }

<fantasai> ACTION: fantasai add this example to the spec [recorded in http://www.w3.org/2009/03/04-css-minutes.html#action01]

<trackbot> Created ACTION-125 - Add this example to the spec [on Elika Etemad - due 2009-03-11].

<fantasai> Introductions

<fantasai> Joined by

<fantasai> Kobayashi-sensei

<fantasai> Kobayashi-san

<fantasai> Yasuhiro Anan-san

<fantasai> Tatsuo Kobayashi-san, Justsystem, chair of JLTF

<fantasai> Anan-san, Microsoft, will be translating for Kobayashi-sensei

<szilles_> EE: offers to discuss the specs that are relevant to the JLTF requirements

<szilles_> EE: there are 3 relevant specs plus GCPM

<szilles_> EE: the first spec is Paged Media that covers the description of the page, its margins, headers and footers, ...

<szilles_> EE: there is a default page, plus pages forfirst, left and right pages and a set of named pages.

<szilles_> EE: the content has to fit inside the page box else it gets clipped

<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.

<szilles_> K-san: what about line-staking-strategy?

<fantasai> Note to self: css3-page should not clip to the page area, but to the padding box of the page box

<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.

<szilles_> DB: the current line stacking rules are not ideal for Western topography and they certainly do not consider things like Rugy annotations.

<fantasai> Discussion of line-stacking-strategy

<fantasai> dbaron: The current rules aren't even ideal for Western typogrpahy

<fantasai> dbaron: We might want different options for what gets considered

<fantasai> Anan-san, Kobayashi-san: ruby above the first line spills outside the kihon hanmen

<fantasai> Steve: Do we flag this as an issue to come back to later?

<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

<szilles_> K-san: figure 37 of the current JLTF draft shows the ruby outside the Kihonhanmen on the first line.

<fantasai> dbaron asks if the ruby crosses the midline between two lines

<fantasai> yes, it does

<szilles_> The current JLTF draft is

<szilles_> http://www.w3.org/2007/02/japanese-layout/docs/aligned/japanese-layout-requirements-en.html

<fantasai> Kobayashi-san: The line gap is usually smaller than the line width, e.g. 2/3

<fantasai> Kobayashi-san: Ruby is usually 1/2 the size of the font size

<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.

<fantasai> Anan-san: The current MSFT implementations grow the line-height to accommodate ruby, but this is not correct

<fantasai> Anan-san: the ruby characters should fit within the line-gap

<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

<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.

<szilles_> EE: CSS3 Page module covers margin boxes, their position, their content

<szilles_> EE: for styling the boxes the many of the normal CSS properties can be used.

<szilles_> EE: page numbers can be inserted

<szilles_> EE: various paper sizes can be selected

<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

<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

<szilles_> EE: this allows explicit setting of the Kihonhanmen size in EMs and centering the resultant area on the paper.

<szilles_> EE: named pages provide a kind of styling template that can be applied to different sections of the content (using selectors)

<szilles_> EE: The second document is CSS Text which is, itself, not a complete module (it is an extract of a prior module.

<szilles_> EE: it covers wihite space control, line breaking and word boundaries.

<szilles_> EE: We know that Japanese has its own line breaking rules which are different than western text rules.

<szilles_> EE: There are some named rules for controlling line breaking

<szilles_> Anan-san: Appendix 3 of the JLTF document has an explicit description of line-breaking for Japanese based on character classes

<szilles_> Anan-san: There are at least two sets of rules for line breaking: basic ones such as the Unicode line breaking rules

<szilles_> Anan-san: and stricter rules that cover a more complete set of cases, such as those in Appendix 3 of the JLTF report

<szilles_> Anan-san: for example, Firefox does a better job of handling rules than some other implementations

<szilles_> Anan-san: Microsoft Word adopted an earlier version of the rules in JIS4051 and, therefore, allows some breaks that would not be expected.

<szilles_> EE: for western text, there are 2 options, break where allowed by the language and break anywhere (including inside a word)

<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.

<szilles_> Murasaki-san: breaking before small kana is fairly common in Japanese

<fantasai> Kobayashi-san: There are three levels: newspaper level, magazine level, book level

<szilles> There are 3 levels: newspaper level, magazine level and book level

<fantasai> Murakami-san: Many books use normal level, not strict level

<fantasai> Kobayashi-san discusses house rules

<szilles> There are also "house rules" used by a particular publication house

<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

<szilles> K-san: we do not, however, need to have rules at that level of detail

<fantasai> Kobayashi-san: Although some implementations use house rules, we can still define some base levels

<fantasai> Murakami-san writes: loose, normal, strict

<szilles> K-sensei: there are 4 options: loose, normal, strict and very-strict

<szilles> very-strict forbids breaks before small-kana, the sound lengthen mark and decoration marks.

<szilles> K-san: almost all publications do not not use very-strict

<szilles> From now on we will use levels 1,2,3 and 4 where 4 is most strict and 1 is least strict

<szilles> level 4 is not often used.

<szilles> K-san agrees that the JLTF will define the rules for the 4 classes of line-breaking rules.

<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?

<szilles> EE: which level is the default level?

<szilles> K-san/K-sensei: level 3 is the default

<szilles> EE: do these breaking rules also cover numbers and foreign language text?

<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.

<szilles> K-san/K-sensei: Japanese link-breaking does not allow line-breaking inside a word.

<szilles_> Resuming after a break

<szilles_> EE: The WG thanks the JLTF for agreeing to provide us guidance on line breaking

<dbaron> We also need to keep the line-breaking compatible with English. :-)

<szilles_> EE: text-wrap gives control over chuncks of text beyond the word level

<ChrisL> dictionary-based English hyphenation ftw!

<szilles_> EE: Alignment (horizontal) controls aligning to start, end, center, justify and control over last line as well

<szilles_> EE: in CSS, a single line is also a last line.

<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

<fantasai> Issue: text-align-last: justify center;

<trackbot> Created ISSUE-97 - Text-align-last: justify center; ; please complete additional details at http://www.w3.org/Style/CSS/Tracker/issues/97/edit .

<szilles_> Murakami-san: if there is only one character on the last line where is it placed with Justtify?

<szilles_> EE: there is control over which space adjustments are used for justification:

<szilles_> Anan-san: How does "inter-graphemic" apply to east asian languages?

<szilles_> Many: it is there primarily for scripts like indic scripts that have grapheme clusters.

<szilles_> Anan-san: Japanese characters with diacrictics for voicing do form a grapheme

<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.

<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 http://www.w3.org/Style/CSS/Tracker/issues/98/edit .

<dbaron> (I asked a few minutes ago what happens with halfwidth characters and justification.)

<fantasai> ISSUE: make sure justification allows not justifying between various bits of punctuation

<trackbot> Created ISSUE-99 - Make sure justification allows not justifying between various bits of punctuation ; please complete additional details at http://www.w3.org/Style/CSS/Tracker/issues/99/edit .

<szilles_> Anan-san: the vertical kana repeat mark upper half should not be split from the lower half mark during justification

<szilles_> JD: Implementations that use the typographic data in a font should not be considered non-conforming

<szilles_> EE: there is spacing that does "tracking"

<szilles_> EE: Word spacing does not (should not) apply to the Ideographic Space.

<szilles_> Anan-san: Tsumegumi controls the reduction of spaces between characters up to the collision of the glyphs

<szilles_> JD: letter spacing is problematic becuase when kerning is involved you want a multiplicative property rather than a adative one.

<szilles_> EE: the current design has a percentage of the letter space; what is wanted?

<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.

<fantasai> Issue: percentage should be wrt character advance, (before or after kerning?)

<trackbot> Created ISSUE-100 - Percentage should be wrt character advance, (before or after kerning?) ; please complete additional details at http://www.w3.org/Style/CSS/Tracker/issues/100/edit .

<szilles_> Note that kerning changes the advance between certain characters

<fantasai> Steve says after kerning

<fantasai> fantasai: that would create uneven spacing in, e.g. "filling"

<fantasai> "milling"

<ChrisL> "Anyone who would letterspace blackletter would steal sheep."

<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"

<dbaron> fantasai, so why are you introducing a new feature (% letter spacing) if you don't think it does something reasonable?

<szilles_> EE: with evenly spaced tsumegumi, how do measure the space added or subtracted?

<fantasai> fantasai, we're missing a measurement that accounts for the character advance width

<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

<fantasai> dbaron, so I picked a way to reference the advance with of a space character

<fantasai> dbaron, right now you can reference ems

<fantasai> dbaron, but that gives weird results if you compare a narrowly-designed font with a widely-designed one

<szilles_> a;nan-san/K-sensei: the tsumegumi can be specified in ems because the amount is typically a percent of the font size.

<fantasai> anan-san: the letter-spacing applied to cjk would usually be too much for latin

<fantasai> anan-san: so you may need a way to separate

<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

<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

<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.

<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.

<fantasai> K-san: tsumegumi like this is usually only used for short bits of text in large fonts, such as headings

<fantasai> K-san: so this solution should be sufficient

<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

<fantasai> EE shows definition for punctuation-trim

<fantasai> jdaggett: is this in addition to or instead of kerning?

<fantasai> jdaggett: if the font is already doing this kerning, we can't tell

<fantasai> anan-san: Also, the same Unicode code-point is different depending on what language the font was designed for

<fantasai> k-san: Three issues interrelated: where to break the line, where to position characters by default, where to adjust (justify) the line

<fantasai> k-san: There are several places to solve the issue. The CSS level, the font level, OS-level

<fantasai> k-san: Justsystem and MSFT, between ours the handling of parentheses is slightly different

<fantasai> k-san: CSS should explicitly define its position, this will be helpful to other parties

<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

<szilles_> earlier lost data:

<szilles_> EE: punctuation-trim property - this handles the conversion of full width punctuation to half width

<szilles_> JD: asks how this interacts with information in kerning tables in the fonts

<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.

<fantasai> EE: so do we assume the font is wide or not?

<fantasai> no real answer

<fantasai> Murakami-san: Antenna House implements punctuation-trim

<fantasai> Murakami-san: It applies only to CJK fonts

<fantasai> Murakami-san: That have fixed-em width

<fantasai> Murakami-san: full-width brackets only

<fantasai> Murakami-san: Not applied to narrow punctuation

<fantasai> Murakami-san: Interaction with kerning is not a problem.

<fantasai> EE: how do you know if it's full-width?

<fantasai> Murakami-san: MS Mincho has full-width fixed-width glyphs for punctuation

<fantasai> Murakami-san: But MS P Mincho has narrower glyphs for Japanese punctuation

<fantasai> Murakami-san: Antenna House punctuation-trim controls MS Mincho, but not MS P Mincho

<fantasai> jdaggett: With a proportional font, the "half-width" characters are proportionally spaced

<fantasai> jdaggett: whereas in a full-width font they are not (end of summary of P vs not P)

<fantasai> K-san: In Unicode, fullwidth punctuation marks usually have half-width default size

<fantasai> K-san: in the JLTF document

<fantasai> K-san: In Japanese typsetting tradition, especially hot-metal era, usually the punctuation marks are 1/2 em size

<fantasai> K-san: So when the punctuation mark need to be 1em we add 1/2em space

<fantasai> K-san: Steve and us made 6 hours discussion on this at the last meeting

<fantasai> K-san: And we decided to describe every punctuation mark as 1/2 width size as a default

<fantasai> K-san: And with some other half-width space added

<fantasai> K-san: Our document is based on such an agreement

<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

<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

<fantasai> Steve: So we picked one that made sense to the ppl writing the document and use that consistently

<fantasai> jdagget: Fonts, and OpenType especially, have many ways of doing the same thing. E.g. kerning

<fantasai> Murakami-san: professional Japanese fonts use fullwidth pucntuation

<fantasai> discussion of P Gothic black magic

<fantasai> Anan-san: You can do pairs kerning in Uniscribe, but it's performance-expensive

<fantasai> Anan-san: ...

<fantasai> jdaggett: FF uses Uniscribe for a lot of text rendering

<fantasai> jdaggett: for desktop, it's ok

<fantasai> jdaggett: for mobile device, ehhh

<fantasai> Murakami-san: Meiryo also has fixed full-width punctuation

<fantasai> Murakami-san: even though Latin is proportional

<szilles_> K-san: the JLTF is willing to consider having levels w.r.t the punctiuation-trim as will be done for line-breaking

<szilles_> EE: the CSS WG has to explain the requirements for punctuation-trim in a way that implementers can implement it.

<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

<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.

<szilles_> K-sensei: Kendots should be used only for vertical text

<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

<szilles_> Note, also, that the "dots" do not occur in the content, they are generated by CSS UA.

<anne> good idea

<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.

<szilles_> K-sensei: Ruby and dots will not be used together; therefore dots should be ignored (for Japanese) if specified with ruby.

<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

<szilles_> EE: Hanging Punctuation has 3 values

<shinyu> http://lists.w3.org/Archives/Public/www-style/2007Oct/0204.html

<szilles_> Start allows the bracket to occur prior to where the first non-punctuation character is to occur

<szilles_> End does the same for the last line

<fantasai> Murakami-san presents his proposal

<szilles_> end-edge allows hanging on end of every line

<szilles_> CL: is there a use case for "start-edge" in analogy to "end-edge"

<szilles_> EE: if there is an indent of the first line, then hanging means into the indent space, not the content area.

<szilles_> EE: what punctuation characters are allowed to hang with "end-edge"?

<szilles_> Murakami-san/K-sensei: only 4 characters (stop, ideographic stop, comma and ideographic comma) can hang with "end-edge"

<szilles_> Murakami-san/EE: for "start" the punctuation that hangs are opening brackets and quotes; for "end" they are ending brackets and quotes.

<szilles_> It was ageed that there is no Japanese use case for "start-edge".

<fantasai> end should have end-auto functionality

<fantasai> forcing the punctuation to hang should be 'force-end'

<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.

<szilles_> EE and Murakami-san: In the above discussion, replace "end-edge" with "end"; replace "start" with "first" and "end" with "last"

<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"

<fantasai> Murakami-san suggests maybe 'end' might be confusing with 'forced-end' for Western typographers

<fantasai> Western typography typically only hangs the hyphen, and it's not common

<fantasai> Suggestion: 'allow-end' 'forced-end'

<fantasai> Other suggestion, need 'hypens' value? since Japanese doesn't hang hyphens

<fantasai> Meeting closed

<szilles_> EE: suggests that "end" be called "allow-end" to make it relationship to "force-end" to be more clear.

<szilles_> At 6:10, the meeting adjourned for the day.

- DRAFT -

Cascading Style Sheets (CSS) Working Group Teleconference
03 Mar 2009

Attendees

Contents

Media Queries

Paged Media

Summary of Action Items

Scribe.perl diagnostic output

- DRAFT -

Cascading Style Sheets (CSS) Working Group Teleconference 03 Mar 2009

Attendees

Contents

Media Queries

Paged Media

Summary of Action Items

Scribe.perl diagnostic output

Cascading Style Sheets (CSS) Working Group Teleconference
03 Mar 2009