/irc-logs / w3c / #css / 2010-09-23 / end

Options:

# Session Start: Thu Sep 23 00:00:00 2010
# Session Ident: #css
# [00:38] * Quits: hyatt (hyatt@98.200.224.166) (Quit: hyatt)
# [01:57] * RRSAgent excuses himself; his presence no longer seems to be needed
# [01:57] * Parts: RRSAgent (rrs-loggee@128.30.52.169)
# [02:54] * Quits: dbaron (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [02:57] * Joins: dsinger (dsinger@17.197.20.4)
# [03:40] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
# [03:40] <RRSAgent> logging to http://www.w3.org/2010/09/23-CSS-irc
# [03:40] <fantasai> Topic: CSS3 Text
# [03:41] <fantasai> Present: Murakami-san, Ishii-san, fantasai
# [03:41] <fantasai> Scribe: fantasai
# [03:41] <fantasai> ScribeNick: fantasai
# [03:41] <fantasai> M: The line breaking strictness and word-break should be separate properties
# [03:41] <fantasai> M: The old version is better, with two properties
# [03:43] <fantasai> M shows a proposal from Toppan Printing and Sony Corp for EPUB requirements
# [03:43] <fantasai> M: They propos characters-not-starting-line property and characters-not-ending-line property
# [03:43] <fantasai> f: um.....
# [03:45] <fantasai> M: They have a default 'none' value. I think the default value should be 'auto'
# [03:46] <fantasai> f: I would prefer to have Kobayashi-sensei define several levels of strictness
# [03:46] <fantasai> f: If individual character control is needed by some people, that can be an additional level of control.
# [03:48] <fantasai> I: If I think about authors writing HTML with text editors, I agree with you.
# [03:52] <fantasai> I: But if I assume most users will be using editing tools, each can have different preset
# [03:52] <fantasai> f argues that CSS is a dynamic layout format, and this level of control is excessive when you can't even control the font size
# [03:55] <fantasai> [unminuted discussion]
# [03:58] <fantasai> also that authors shouldn't have to deal with this low-level of control
# [04:17] <fantasai> discuss having line-break: loose \ normal | strict and having a separate property as a diff against the default set of restrictions
# [04:43] <fantasai> We study a matrix of breaking options
# [04:43] <fantasai> CJK breaking restrictions on one axis, non-CJK breaking restrictions on another
# [04:43] <fantasai> question is, do we need two properties, or is one linear axis of strictness enough
# [05:03] <fantasai> Current proposal:
# [05:03] <fantasai> break-non-CJK: break-all | hyphenate | keep-together
# [05:04] <fantasai> break-CJK: newspaper | normal | strict | keep-together
# [05:04] <fantasai> defaults are
# [05:04] <fantasai> break-non-CJK: keep-together
# [05:04] <fantasai> break-CJK: normal
# [05:04] <fantasai> break-CJK: keep-together is used for Korean and (known to be) non-CJK texts
# [05:04] <fantasai> Discuss naming and IE compat
# [05:05] <fantasai> Current proposal:
# [05:05] <fantasai> word-break: break-all | hyphenate | normal
# [05:05] <fantasai> ine-break: newspaper | normal | strict | keep-all
# [05:05] <fantasai> s/ine/line/
# [05:05] <fantasai> This is compatible with IE except that IE's "word-break: keep-all" is "line-break: keep-all"
# [05:05] <fantasai> The change is so that one property deals only with non-CJK and one property deals with only CJK -- it is a more logical division
# [05:06] <fantasai> Question: how are fullwidth characters treated? As CJK or non-CJK?
# [05:06] <fantasai> Murakami-san and Ishii-san suspect as CJK. UAX14 confirms.
# [05:13] <fantasai> <br type="lunch">
# [06:08] <fantasai> M and I are studying the white-space controls in css3-text
# [06:19] <fantasai> Topic: text-emphasis
# [06:19] <fantasai> fantasai reviewed Ken Lunde's chart of emphasis shapes
# [06:19] <fantasai> suggested syntax:
# [06:20] <fantasai> [ filled | open ] || [ dot | circle | double-circle | triangle | sesame ]
# [06:21] <fantasai> Suggestion to rename "filled" to "solid"
# [06:21] <fantasai> But it is confusing with double-circle
# [06:21] <fantasai> Ishii-san also points out it could be confused with a solid-stroke circle vs. dotted-stroke circle
# [06:21] <fantasai> Seem to be settling on "filled"
# [06:21] <fantasai> Filled is the default
# [06:22] <fantasai> If the shape is left out, then it computes to "dot" in horizontal writing mode and "sesame" in vertical writing mode
# [06:27] <fantasai> Murakami-san notes that we need text-emphasis-color
# [06:28] <fantasai> Discussing options for text-emphasis-position
# [06:28] <fantasai> current values in the spec are before | after
# [06:28] <fantasai> but does this make sense in Mongolian writing mode, where the before edge doesn't coincide with the "top" edge of the line?
# [06:29] <fantasai> Ishii-san suggests an 'auto' value, that maps from the language to the correct side
# [06:29] <fantasai> Japanese uses above in horizontal; Chinese uses below
# [06:30] <fantasai> We would need a chart in the spec
# [06:35] <fantasai> probably use "before" for Japanese and traditional chinese, "after" for everything else
# [06:35] <fantasai> (We have examples of Tibetan text using after.)
# [06:36] <fantasai> Question: Should text-emphasis marks be applied to punctuation?
# [06:41] <fantasai> JLTF document says not to apply them to commas, full stops, opening brackets (cl-01) or closing brackets (cl-02)
# [06:42] <fantasai> should also skip spaces
# [06:43] <fantasai> If text-emphasis dots conflict with ruby, they should be skipped
# [06:43] <fantasai> alternatively, the ruby or dots sides can be switched?
# [06:44] <fantasai> Settled on making the dots go away; it's the author's responsibility to use text-emphasis-position or ruby-position to avoid such conflicts
# [06:50] <fantasai> Proposed starting point: follow suggested rules for which punctuation gets emphasized in JLTF document. All punctuation not mentioned in that document gets skipped.
# [06:55] <fantasai> Back to text-emphasis-position
# [07:00] <fantasai> and the fact that in Mongolian text the before edge is on the left but the top of a line is on the right
# [07:00] <fantasai> Suggestion:
# [07:00] <fantasai> text-emphasis-position: above | below
# [07:01] <fantasai> to avoid confusion with 'before' and 'after' terminology
# [07:03] <fantasai> Changed to above | below, marked as issue for feedback
# [07:03] <fantasai> Would need corresponding changes to css3-ruby, though.
# [07:04] * Joins: shepazu (schepers@128.30.52.169)
# [07:05] * fantasai waves to shepazu
# [07:05] <fantasai> Question: should emphasis dots factor into the line height?
# [07:06] <fantasai> f suggests it should follow the same rules as for ruby, whatever those are
# [07:06] * shepazu waves back
# [07:06] <shepazu> fantasai: just turning in, though... attending Web Directions USA in Atlanta
# [07:07] <shepazu> that makes sense... I personally don't think that any glyph characteristics should factor into line height, only the "glyph/character cell" and the font size
# [07:07] * kennyluck waves to fantasai
# [07:13] <fantasai> Discussing justification now
# [07:13] <fantasai> M asks what inter-word is for. It's for e.g. Latin texts, where CJK should not space out
# [07:14] <fantasai> M and I want more details for auto
# [07:14] <fantasai> f suggests providing examples; doesn't want to recommend anything because there are many different ways of being smart
# [07:16] <fantasai> Discuss kashida value.
# [07:16] <fantasai> It's for Arabic, which has two methods of justification: stretching glyphs, or stretching spaces
# [07:16] <fantasai> "clustered" should probably shift to 3rd priority
# [07:16] <fantasai> Everything except those two would be a fallback case
# [07:22] <fantasai> Discussion of what would be a good default justification algorithm for all scripts
# [07:22] <fantasai> Probably like distribute, but with "discrete" dropped to 2nd priority
# [07:27] <fantasai> Ishii-san suggests having that as an example for 'auto' to encourage UAs to do something that works better for non discrete scripts
# [07:35] <fantasai> Murakami-san draws up the chart for this
# [07:35] <fantasai> M: This should be the baseline. The UA can do better, but this would be the suggestion in the chart
# [07:36] <fantasai> fantasai notes to self that the "connected" and "cursive" categories probably should be last priority for all groups...
# [07:37] <fantasai> Note to previous discussion: add <string> as possible value for text-emphasis-style
# [07:48] <fantasai> short break
# [07:48] <fantasai> Topic: punctuation-trim
# [07:48] <kennyluck> fantasai, can I make the log public?
# [07:48] <fantasai> oh
# [07:48] <fantasai> yeah
# [07:48] <fantasai> I forgot to do that
# [07:49] <kennyluck> RSSAgent, make log public.
# [07:49] <fantasai> It's publicly logged at krijnh's site anyway :)
# [07:49] <kennyluck> RRSAgent, make log public.
# [07:49] <RRSAgent> kennyluck, access must be one of public, world, memberEditors, memberSearchers, wsridirectors, member, i18n, w3f, offices, alumni, team, HEADER.html, ab, or wstar
# [07:49] <fantasai> RRSAgent: make logs public
# [07:49] <RRSAgent> I have made the request, fantasai
# [07:49] <fantasai> M: Current draft is ok, but we need more options
# [07:50] <fantasai> M writes "start-except-first-line"
# [07:50] <fantasai> f: We had a previous version that had none | start | start-edge | end-edge | hyphens
# [07:51] <fantasai> f: oh wait, that's hanging-punctuation
# [07:51] * Quits: kennyluck (kennyluck@128.30.52.28) (Quit: kennyluck)
# [07:51] <fantasai> M pulls up an example
# [07:51] * Joins: kennyluck (kennyluck@128.30.52.28)
# [07:53] <fantasai> M: Here is some plaintext. Paragraph breaks represented by line breaks, indent represented as space
# [07:53] <fantasai> M: Open parentheses replaces the indent space
# [07:53] <fantasai> f: you could handle that type of formatting, if you had markup, with hanging-idnent: start
# [07:56] <fantasai> s/start/first/
# [07:58] <fantasai> p {
# [07:58] <fantasai> margin: 0;
# [07:58] <fantasai> text-indent: 1em;
# [07:58] <fantasai> hanging-punctuation: first;
# [07:58] <fantasai> punctuation-trim: start adjacent end;
# [07:58] <fantasai> }
# [07:58] <fantasai> (M writing into his notebook)
# [08:02] <fantasai> M: This works if I have correct markup with <p> and use text-indent for indentation
# [08:02] <fantasai> But if someone is using ideographic space for indentation
# [08:02] <fantasai> Then a fullwidth opening bracket should not be trimmedon the first page
# [08:03] <fantasai> Ishii-san, fantasai: This is incorrect markup. The space should not be there. The text should be transformed to correct markup.
# [08:04] <fantasai> Ishii-san, fantasai: Run a preprocessor.
# [08:04] <fantasai> on the source
# [08:11] <fantasai> Topic: text-justify-trim
# [08:12] <fantasai> http://www.w3.org/TR/2003/CR-css3-text-20030514/#text-justify-trim-prop
# [08:13] <fantasai> f: How does this interact with punctuation-trim?
# [08:14] <fantasai> M: This interacts with line-breaking
# [08:42] <fantasai> whiteboard work
# [08:42] <fantasai> Draw a bunch of boxes. One half-width box with a bracket followed by a fullwidth bracket
# [08:42] <fantasai> one box on the second line
# [08:42] <fantasai> two half-shaded boxes (trimmable) on the first line
# [08:42] <fantasai> Notes on conclusions:
# [08:43] <fantasai> * First, apply punctuation-trim. (This is like kerning; it effectively changes the width of the characters.)
# [08:45] <fantasai> * If everything fits perfectly, no text-justify-trim
# [08:45] <fantasai> * If hanging punctuation solves the gapping problem, no tjt
# [08:45] <fantasai> * If tjt would prevent gap at end of line, apply tjt. Does not have to be in fixed increments: arbitrary trimming amounts ok.
# [08:46] <fantasai> * Q: relative priority to other justification methods?
# [08:46] <fantasai> Suggestion: text-justify: inter-ideograph punctuation-trim;
# [08:46] <fantasai> Define relative priority in text-justify definition/charts
# [08:46] <fantasai> * Japanese (CJK?) favors compression. Other scripts favor expansion.
# [08:47] <fantasai> * tjt might be applied even when not justifying
# [08:47] <fantasai> text-justify: punctuation-trim; ?
# [08:49] <fantasai> i.e. if text-align is not justify and text-justify has punctuation-trim, apply the trim?
# [08:49] <kennyluck> RRSAgent, make minutes.
# [08:49] <RRSAgent> I'm logging. I don't understand 'make minutes.', kennyluck. Try /msg RRSAgent help
# [08:51] <kennyluck> RRSAgent, draft minutes.
# [08:51] <RRSAgent> I'm logging. I don't understand 'draft minutes.', kennyluck. Try /msg RRSAgent help
# [08:51] <fantasai> RRSAgent: make minutes
# [08:51] <RRSAgent> I have made the request to generate http://www.w3.org/2010/09/23-CSS-minutes.html fantasai
# [08:51] <fantasai> kennyluck: he's fussy about punctuation :)
# [08:51] <kennyluck> RRSAgent、make minutes
# [08:52] <kennyluck> Huh
# [08:54] <fantasai> kennyluck: that looks like ideographic comma.
# [08:54] <fantasai> kennyluck: try ascii comma
# [08:54] <fantasai> :P
# [08:54] <fantasai> M: Maybe text-justify: avoid-trim;
# [08:54] <fantasai> M: Allow punctuation-trim by default
# [08:55] <fantasai> f: Doesn't make sense for most other scripts.
# [08:56] <fantasai> Do we want inter-ideograph to punctuation-trim by default?
# [08:56] <fantasai> f: What if you want inter-ideograph without punctuation-trim?
# [08:57] <fantasai> ...
# [08:58] <fantasai> M: Default of punctuation-trim is 'none'. That's not good for Japanese layout. You want "start adjacent end"
# [08:58] <fantasai> M: You also would want text-justify: inter-ideograph punctuation-trim; for Japanese
# [08:58] <fantasai> M: But that doesn't need to be the default
# [09:03] <fantasai> Looking at punctuation-trim. Is there a problem with making the default not 'none'?
# [09:03] <fantasai> Some trimmed characters are not FULLWIDTH characters, but are stndard punctuation, which may not be full width
# [09:07] <fantasai> :lang(ja) { punctuation-trim: start adjacent end; }
# [09:08] <fantasai> We should add an Appendix with suggested rules for the default style sheet
# [09:08] <fantasai> this can be one of them
# [09:09] <fantasai> We could even do this instead of the 'auto' value for text-emphasis
# [09:09] <fantasai> although that might not work so well if we have a shorthand that resets text-emphasis-position...
# [09:15] <fantasai> Murakami-san writes into his notebook:
# [09:15] <fantasai> text-justify: auto | [ [inter-word|...] || trim ]
# [09:16] <fantasai> text-justify: trim; means prefer trimming, but do auto
# [09:16] <fantasai> auto is allowed to use trim, although it should be careful about when it does so
# [09:16] <fantasai> trim means prefer compression to expansion
# [09:16] <fantasai> and allows trimming of punctuation
# [09:17] <fantasai> text-justify: inter-word trim; means trim punctuation and compress spaces first priority; if that doesn't work, then expand spaces
# [09:19] <fantasai> Topic: text-autospace
# [09:20] <fantasai> (to close previous discussion, Ishii-san and fantasai will draft something based on above notes, and we will review again with Murakami-san next week)
# [09:27] <fantasai> Looking at definition in old css3-text CR. Not sure what values are needed. Text needs more details (e.g. how much space)
# [09:29] <fantasai> Also doesn't explain what happens when there's punctuation involved at the boundary
# [09:29] <fantasai> IE apparently implements all values (according to MSDN)
# [09:30] <fantasai> This property should have some values to handle French punctuation's non-breaking-thin-space before ! ? and guillemots
# [09:31] <fantasai> U+202F
# [09:33] <fantasai> http://unicode.org/udhr/n/notes_fra.html
# [09:35] * Joins: anne (annevk@83.85.115.123)
# [09:36] <fantasai> Random notes:
# [09:36] <fantasai> add text-transform: fullwidth; to transform letters to fullwidth
# [09:36] <fantasai> e.g. acronym { text-transform: fullwidth; }
# [09:38] <fantasai> fantasai asks if text-transform: katakana; is needed to transform hiragana to katakana
# [09:39] <fantasai> Murakami-san doesn't think so
# [09:39] <fantasai> but notes that translating small kana to full-size kana might be necessary for ruby
# [09:40] <fantasai> fantasai: jdaggett mentioned that a good font would have a variant for use in Ruby. Wouldn't it take care of this?
# [09:43] <fantasai> M: rt { text-transform: large-kana; }
# [09:56] <fantasai> Murakami-san notes that automatic transformation of numbers is also needed
# [09:56] <fantasai> e.g. from ASCII to Fullwidth or ASCII to ideographic
# [09:56] <fantasai> fantasai: we also have a font-variant-numeric property
# [09:57] <fantasai> I'm not sure if that's more appropriate or not
# [09:58] <fantasai> We could put it in text-transform and ask jdaggett for comments
# [10:07] <fantasai> side conversation about <acronym>
# [10:07] <fantasai> Would be useful if it didn't use the dictionary to define its meaning
# [10:07] <fantasai> http://en.wikipedia.org/wiki/Acronym_and_initialism
# [10:10] <anne> note that <acronym> is gone from HTML5
# [10:11] <fantasai> yes, I know
# [10:11] <anne> there's only <abbr>
# [10:11] <fantasai> It would be useful if <acronym> were defined in a way that it could be used for all abbreviations that get capital letters
# [10:12] <fantasai> because those are styled specially sometimes
# [10:12] <fantasai> sometimes in small-caps in western typography
# [10:12] <fantasai> usually in fullwidth variants in eastern typography
# [10:12] <fantasai> etc.
# [10:13] <anne> yeah maybe, people hardly use these elements though
# [10:14] <anne> and <abbr class=caps></abbr> is only three characters longer
# [10:15] <fantasai> Yeah, if <acronym> didn't already exist I probably wouldn't think of it
# [10:15] <fantasai> :)
# [10:19] <fantasai> but it does already exist and is implemented,
# [10:20] <fantasai> would be useful in some cases we're discussing
# [10:23] <fantasai> Ok, so summary is new values for text-transform
# [10:24] <fantasai> fullwidth | large-kana | fullwidth-digits | ideographic-digits
# [10:37] * fantasai thinks its naptime, but the local clocks don't quite agree
# [10:38] <fantasai> Ishii-san is skeptical that the *-digits values are needed
# [10:38] <fantasai> fantasai doesn't have an opinion
# [10:39] <fantasai> Ishii-san: If you convert digits, would you also convert punctuation like commas and slashes?
# [10:39] <fantasai> OS/2
# [10:39] <fantasai> 21,200
# [10:39] <fantasai> '98
# [10:40] <fantasai> text-transform: fullwidth transforms anything that has a fullwidth variant into that variant
# [10:40] <fantasai> use markup to restrict scope
# [10:45] <fantasai> text-transform: fullwidth | large-kana
# [10:46] <fantasai> f: could add note wrt large-kana to look into whether font can handle it
# [11:01] <fantasai> break
# [11:14] * Quits: plinss_ (plinss@68.107.116.23) (Ping timeout)
# [11:21] <fantasai> Murakami-san shows implementation of vertical text with rotated layout
# [11:21] * Joins: plinss_ (plinss@68.107.116.23)
# [11:21] <fantasai> width and height are swapped
# [11:22] <fantasai> except for replaced elements
# [11:22] <fantasai> due to UA stylesheet img { writing-mode: horizontal; }
# [11:22] <fantasai> which prevents the rotation of its contents
# [11:22] <fantasai> and the swapping of its width and height properties
# [11:25] <fantasai> correction - the contents dont' rotate if the writing mode stays vertical; the width and height properties just swap
# [11:25] * Quits: tabatkins (tabatkins@216.239.45.4) (Ping timeout)
# [11:25] * Joins: tabatkins (tabatkins@216.239.45.4)
# [11:26] <fantasai> Ishii-san thinks it makes sense for the contents to rotate too
# [11:30] <fantasai> Murakami-san shows floats to the left and right
# [11:30] <fantasai> they float to the top and bottom
# [11:30] <fantasai> we probably have to do this even in an absolute coordinate system, because there are no top/bottom floats
# [11:30] <fantasai> (except in gcpm, but most implementations don't support those)
# [11:30] <fantasai> Murakami-san shows repeat-x
# [11:30] <fantasai> in this implementation it stays as repeat-x
# [11:31] <fantasai> which gives a very different effect...
# [11:31] <fantasai> Murakami-san: Have a sizing problem with background-size as well
# [11:32] <fantasai> Murakami-san: and the implementor thinks the image might need to be rotated
# [11:36] <fantasai> fantasai, Ishii-san: whether background image is rotated depends on the image
# [11:38] <fantasai> Ishii-san: If there are rules for transforming, they should transform everything to be consistent and easy to understand.
# [11:38] <fantasai> Ishii-san: The author can then predict what will happen and tweak the style sheet accordingly.
# [11:39] <fantasai> Murakami-san writes: image-orientation-vertical: upright | 90deg
# [11:40] <fantasai> fantasai: You want to control image rotation per image, not per element
# [11:42] <fantasai> Murakami-san: page-break-before: left and right would need to swap
# [11:43] <fantasai> Murakami-san: In this implementation, "right" is "odd-page"
# [11:50] <fantasai> Murakami-san draws a horizontal writing mode box with a top-border inside a vertical text flow
# [11:50] <fantasai> How do the margins map?
# [11:50] <fantasai> How do the borders map?
# [11:50] <fantasai> fantasai: block formatting context is horizontal, box behaves as vertical box
# [11:50] <fantasai> Ishii-san: what about tables? want borders to match contents there.
# [11:51] <fantasai> Ishii-san: Maybe make the boundary the border edge
# [11:51] <fantasai> Ishii-san: so margins match outer context, borders and padding match inner context
# [11:51] <fantasai> Ishii-san: width and height follow inner context, just like replaced elements.
# [11:52] <fantasai> fantasai: Another thing about tables is that there's an outer box and an inner box.
# [11:54] <fantasai> fantasai: so treating the table borders the same as the inner context would not be inconsistent.
# [11:54] <fantasai> Murakami-san: The box with writing-mode change is a very special box.
# [11:55] <fantasai> Murakami-san proposes an anonymous box.
# [11:55] <fantasai> for the writing-mode-switching div.
# [11:56] <fantasai> Murakami-san: outer box has outer writing mode
# [11:57] <fantasai> Murakami-san: The margin is on the outer box
# [11:57] <fantasai> Murakami-san: borders and padding are set on the inner box
# [11:59] <fantasai> Ishii-san: I made a list of properties that could possibly be affected.
# [12:00] <fantasai> Ishii-san: We talked about border and padding and backgrounds
# [12:00] <fantasai> Ishii-san: also have box-shadow
# [12:00] <fantasai> Ishii-san: position
# [12:00] <fantasai> Ishii-san: caption-side could also be an issue
# [12:00] <fantasai> Ishii-san: clear is ok, just like floats
# [12:00] <fantasai> Ishii-san: clip needs discussion
# [12:00] <fantasai> Ishii-san: multi-column is not a problem
# [12:01] <fantasai> Ishii-san: crop is like clip
# [12:01] <fantasai> fantasai: crop?
# [12:01] <fantasai> Ishii-san: css3-content
# [12:01] <fantasai> fantasai: Oh, we're going to cut that out.
# [12:01] <fantasai> Along with most of the rest of the spec :)
# [12:02] <fantasai> Ishii-san: object-position
# [12:02] <fantasai> Ishii-san: float-offset might not need anything
# [12:02] <fantasai> Ishii-san: width/height/etc we discussed
# [12:02] <fantasai> Ishii-san: image-orientation should be discussed
# [12:03] <fantasai> Ishii-san: overflow-x/y needs discussion
# [12:03] <fantasai> Ishii-san: @page size, I think we can easily agree not to rotate in this case
# [12:04] <fantasai> Ishii-san: Do we need to discuss css-3d-transform perspective-origin?
# [12:04] <fantasai> don't know
# [12:04] <fantasai> Ishii-san: rotation, rotation-point
# [12:04] <fantasai> Ishii-san: And template layout
# [12:05] <fantasai> fantasai: uhh, you'd need to transpose the layout......
# [12:05] <fantasai> Ishii-san: text-align is ok. Text-shadow similar to box-shadow
# [12:05] <fantasai> Ishii-san: form elements and object elements, do they rotate?
# [12:05] <fantasai> Ishii-san: Tables would transpose.
# [12:05] <fantasai> fantasai: yes, certainly
# [12:06] <fantasai> Ishii-san: So basically my idea is that since there are so many properties, and future properties coming every year, just transform the axis and think everything rotates 90deg
# [12:06] <fantasai> Ishii-san: easier than picking which property to rotate
# [12:07] <fantasai> Murakami-san: writing-mode: vertical-transform would mean changing the coordinate system, not just the properties
# [12:07] <fantasai> Ishii-san: My idea is to also rotate the image contents, so it's more than that.
# [12:09] <fantasai> fantasai: whether we define this rotation as a layout thing or as part of a style sheet transformation process, we still have to deal with all these issues
# [12:12] <fantasai> ...
# [12:12] <fantasai> fantasai: If your replaced element is a Flash application, you can't just rotate it like you can with an image
# [12:16] <fantasai> Ishii-san: Back to the image
# [12:59] <fantasai> fantasai writes:
# [12:59] <fantasai> html {
# [12:59] <fantasai> transform: rotate(90deg);
# [12:59] <fantasai> font-variant: vertical;
# [12:59] <fantasai> }
# [12:59] <fantasai> Done.
# [12:59] <fantasai> If we're rotating everything, why don't we actually rotate everything
# [12:59] <fantasai> full-on graphical transform should do the trick
# [12:59] <fantasai> just reset the font
# [13:00] <fantasai> to pretend its vertical
# [13:06] * Quits: anne (annevk@83.85.115.123) (Quit: anne)
# [15:01] * RRSAgent excuses himself; his presence no longer seems to be needed
# [15:01] * Parts: RRSAgent (rrs-loggee@128.30.52.169)
# [15:03] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
# [15:04] * Quits: lhnz (lhnz@188.223.83.48) (Ping timeout)
# [15:30] * Joins: lhnz (lhnz@188.223.83.48)
# [16:09] * Quits: Martijnc (Martijnc@91.176.75.32) (Connection reset by peer)
# [16:16] * Joins: Martijnc (Martijnc@91.176.128.34)
# [16:49] <kennyluck> Hmm... was Ishii-san's 'directional-mode' idea completely rejected?
# [17:22] <fantasai> It has the problem of making the style sheet completely unpredictable
# [17:23] <fantasai> kennyluck: When you have style rules coming in from multiple sources, as we do in CSS, mode switches can really screw things up
# [17:23] <fantasai> kennyluck: because each author has a certain set of expectations of how things will behave
# [17:24] <kennyluck> fantasai: I see.
# [17:24] <fantasai> kennyluck: Consider that the UA style sheet wants to set indentation margins, the user style sheet wants to modify them, the sitewide style sheet is setting some sitewide tweaks, and the local section author is trying to design a page
# [17:24] <fantasai> kennyluck: if any one of them sets a global mode switch on an element to make things easier to specify on his end
# [17:24] <fantasai> kennyluck: it affects the rules by everyone else
# [17:25] <fantasai> kennyluck: and for something like directional-mode, that can really screw things up
# [17:26] <fantasai> kennyluck: One of the things that trips up CSS feature proposers the most is the cascade. They don't think about it.
# [17:27] <fantasai> kennyluck: We've had many proposals in the CSSWG, often from WG members even, that trip up on the cascade...
# [17:27] <kennyluck> fantasai: Hmm...how 'block-flow'?
# [17:27] <kennyluck> how about
# [17:27] <fantasai> yeah, and box-shadow
# [17:27] <fantasai> er
# [17:27] <fantasai> box-sizing
# [17:28] <fantasai> I agree block-flow has this kind of problem. It's really impossible to represent a decent UA style sheet when an author can trigger a different writing mode.
# [17:28] <kennyluck> I mean, it seems to me like 'block-flow' is very unpredictable as well.
# [17:29] <fantasai> it is
# [17:30] <kennyluck> fantasai: Do you actually prefer a solution beyond CSS for vertical text?
# [17:30] <fantasai> what do you mean?
# [17:31] <kennyluck> I don't know. Since you say you think 'block-flow' is unpredictable.
# [17:32] <fantasai> it has a similar messing-with-expectations problem
# [17:32] <fantasai> I pointed this out years and years ago
# [17:32] <fantasai> but there's no really good solution afaict
# [17:33] <fantasai> ideally we'd have margin-start/end/etc
# [17:33] <fantasai> but that has its own cascading issues
# [17:33] <kennyluck> Yeah.
# [17:34] <fantasai> My current suggestion is to modify @import to take a transform function
# [17:34] <kennyluck> I am a bit surprised that *-start and *-end are not yet part of any stable spec yet, even though there's bidi issues.
# [17:34] <fantasai> It's for two reasons
# [17:34] <fantasai> a) nobody's figured out a good cascading story
# [17:34] <fantasai> b) there's a lot of resistance from many members of the CSSWG to adding so many new properties
# [17:36] <kennyluck> fantasai: Yeah. As r12a said, no company really wants to spend much time on internationalization.
# [17:36] <fantasai> kennyluck: That's not the issue
# [17:37] <fantasai> kennyluck: it's not about developer time
# [17:37] <fantasai> kennyluck: it's about perceived need vs. perceived bloat
# [17:38] <fantasai> kennyluck: and, as I mentioned, the cascading problem
# [17:38] <kennyluck> fantasai: But at least *-start and *-end are already shipped.
# [17:39] <fantasai> kennyluck: not really
# [17:39] <kennyluck> without a good cascading theory I suppose?
# [17:40] <fantasai> kennyluck: like, Mozilla has implemented -start and -end
# [17:40] <fantasai> kennyluck: but only for the few properties it needs for the UA style sheet
# [17:40] <fantasai> kennyluck: not generally
# [17:41] <fantasai> kennyluck: and it deals with the cascade in a way that make the computed style output really confusing
# [17:42] <kennyluck> fantasai: Why do they need -start and -end for UA style sheet but not just some internal implementation trick?
# [17:43] <kennyluck> (Sorry, this must be a dummy question)
# [17:43] <kennyluck> I suppose they what people to use it, since it is documented.
# [17:43] <fantasai> kennyluck: probably because in Mozilla, the easiest way to do an internal implementation trick that behaves like a CSS property is to implement it as a property?
# [17:45] <kennyluck> fantasai: OK... By the way, what's your plan for Taiwan? I heard that you are going for the EPUB meeting.
# [17:46] <kennyluck> s/for/to/
# [17:47] <fantasai> yes
# [17:48] <fantasai> my plan is to draft up CSS3 Writing Modes, at least the "implemenation" of its "api", given the "api" is still under discussion.
# [17:49] <fantasai> and try to prevent epub and css from diverging too much
# [17:49] <fantasai> or rather, standard css and epub css from diverging too much....
# [17:50] <fantasai> If we're lucky, we find an api that everyone's happy with.
# [17:50] <fantasai> anyway, bedtime for me
# [17:50] <fantasai> or rather, past bedtime :)
# [17:50] <kennyluck> Oh, good night!
# [17:56] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
# [17:56] <RRSAgent> logging to http://www.w3.org/2010/09/23-CSS-irc
# [17:56] <kennyluck> RRSAgent: make minutes
# [17:56] <RRSAgent> I have made the request to generate http://www.w3.org/2010/09/23-CSS-minutes.html kennyluck
# [18:06] * Quits: arronei (arronei@131.107.0.111) (Ping timeout)
# [18:12] * Joins: arronei (arronei@131.107.0.75)
# [19:06] * Quits: fantasai (fantasai@66.225.200.148) (Ping timeout)
# [19:56] * Joins: dbaron (dbaron@63.245.220.240)
# [20:14] * Quits: dsinger (dsinger@17.197.20.4) (Quit: dsinger)
# [22:37] * RRSAgent excuses himself; his presence no longer seems to be needed
# [22:37] * Parts: RRSAgent (rrs-loggee@128.30.52.169)
# [22:46] * Quits: plinss (plinss@192.6.114.30) (Quit: plinss)
# [22:46] * plinss_ is now known as plinss
# [22:49] * Joins: plinss_ (plinss@192.6.114.30)
# Session Close: Fri Sep 24 00:00:00 2010

The end :)