#css IRC Log

Index

IRC Log for 2013-02-06

Timestamps are in PDT.

[00:08] * liam Quit ("Client exiting")

[00:08] * liam has joined #css

[00:13] * nvdbleek has joined #css

[00:33] * liam Quit (Ping timeout: 60 seconds)

[00:39] * tantek has joined #css

[00:41] * nvdbleek Quit ("Leaving.")

[00:41] * nvdbleek has joined #css

[00:42] * nvdbleek Quit ("Leaving.")

[00:42] * nvdbleek has joined #css

[00:43] * Ms2ger has joined #css

[00:44] * nvdbleek Quit ("Leaving.")

[00:44] * nvdbleek has joined #css

[00:45] * nvdbleek Quit ("Leaving.")

[00:45] * nvdbleek has joined #css

[00:46] * nvdbleek Quit ("Leaving.")

[00:46] * nvdbleek has joined #css

[00:53] * plinss_away is now known as plinss

[01:05] * isherman-book has joined #css

[01:06] * liam has joined #css

[01:10] * leif has joined #css

[01:15] * plinss is now known as plinss_away

[01:26] * isherman-book Quit ("Leaving.")

[01:41] * sylvaing has joined #css

[01:45] * sylvaing Quit (Ping timeout: 60 seconds)

[01:57] * isherman-book has joined #css

[02:14] * isherman-book Quit (Ping timeout: 60 seconds)

[02:17] * Ms2ger Quit (Ping timeout: 60 seconds)

[02:20] * tmpsantos has joined #css

[02:41] * isherman-book has joined #css

[02:54] * isherman-book Quit (Ping timeout: 60 seconds)

[03:22] * isherman-book has joined #css

[03:22] * cabanier has joined #css

[03:27] * nvdbleek1 has joined #css

[03:27] * nvdbleek Quit (Client closed connection)

[03:34] * isherman-book Quit (Ping timeout: 60 seconds)

[03:42] * nvdbleek1 Quit ("Leaving.")

[03:42] * nvdbleek has joined #css

[03:43] * teoli has joined #css

[03:46] * nvdbleek Quit ("Leaving.")

[03:46] * nvdbleek has joined #css

[03:47] * nvdbleek Quit ("Leaving.")

[03:48] * nvdbleek has joined #css

[04:00] * nvdbleek Quit ("Leaving.")

[04:00] * nvdbleek has joined #css

[04:02] * isherman-book has joined #css

[04:02] * nvdbleek Quit ("Leaving.")

[04:03] * nvdbleek has joined #css

[04:05] * leif Quit ("Leaving.")

[04:07] * nvdbleek Quit ("Leaving.")

[04:08] * nvdbleek has joined #css

[04:12] * leif has joined #css

[04:12] * nvdbleek Quit ("Leaving.")

[04:13] * nvdbleek has joined #css

[04:15] * nvdbleek Quit ("Leaving.")

[04:15] * nvdbleek has joined #css

[04:16] * isherman-book Quit (Ping timeout: 60 seconds)

[04:17] * nvdbleek Quit ("Leaving.")

[04:18] * nvdbleek has joined #css

[04:22] * nvdbleek Quit ("Leaving.")

[04:23] * nvdbleek has joined #css

[04:27] * nvdbleek Quit ("Leaving.")

[04:28] * nvdbleek has joined #css

[04:33] * nvdbleek Quit ("Leaving.")

[04:33] * nvdbleek has joined #css

[04:34] * nvdbleek Quit ("Leaving.")

[04:34] * nvdbleek has joined #css

[04:38] * nvdbleek Quit ("Leaving.")

[04:38] * nvdbleek has joined #css

[04:43] * nvdbleek Quit ("Leaving.")

[04:43] * nvdbleek has joined #css

[04:45] * isherman-book has joined #css

[04:46] * nvdbleek Quit ("Leaving.")

[04:46] * nvdbleek has joined #css

[04:48] * nvdbleek Quit ("Leaving.")

[04:48] * nvdbleek has joined #css

[04:53] * nvdbleek Quit ("Leaving.")

[04:53] * nvdbleek has joined #css

[04:58] * isherman-book Quit (Ping timeout: 60 seconds)

[05:15] * leif Quit ("Leaving.")

[05:18] * leif has joined #css

[05:25] * isherman-book has joined #css

[05:31] * cabanier Quit ("Leaving.")

[05:40] * isherman-book Quit (Ping timeout: 60 seconds)

[05:41] * tmpsantos Quit ("Leaving")

[05:54] * tantek Quit (tantek)

[06:08] * isherman-book has joined #css

[06:14] * glenn has joined #css

[06:20] * danielfilho Quit (Client closed connection)

[06:20] * danielfilho has joined #css

[06:21] * isherman-book Quit (Ping timeout: 60 seconds)

[06:23] * abucur has joined #css

[06:49] * isherman-book has joined #css

[06:58] * tantek has joined #css

[07:02] * Ms2ger has joined #css

[07:02] * isherman-book Quit (Ping timeout: 60 seconds)

[07:04] * tmpsantos has joined #css

[07:07] * glenn Quit (Client closed connection)

[07:30] * isherman-book has joined #css

[07:35] * tantek Quit (tantek)

[07:44] * isherman-book Quit (Ping timeout: 60 seconds)

[07:52] * mibalan has joined #css

[07:53] * mibalan Quit ("ChatZilla 0.9.89 [Firefox 18.0.1/20130116073211]")

[07:59] * plinss_away is now known as plinss

[07:59] * SimonSapin has joined #css

[08:02] * nvdbleek Quit ("Leaving.")

[08:02] * nvdbleek has joined #css

[08:03] * liam Quit (Ping timeout: 60 seconds)

[08:05] * dbaron has joined #css

[08:09] * glenn has joined #css

[08:11] * glazou has joined #css

[08:12] * isherman-book has joined #css

[08:18] * Kazutaka has joined #css

[08:23] <dbaron> jdaggett: It would be helpful to gave the module preprocessor scripts on the dev.w3.org public tree rather than the css3-src member-only CVS tree so that we can use them locally from that tree.

[08:23] <dbaron> jdaggett: Bert, would you mind that?

[08:23] <dbaron> Bert: I don't mind, but it's a lot of work.

[08:23] * isherman-book Quit (Ping timeout: 60 seconds)

[08:24] * smfr has joined #css

[08:27] * smfr changes topic to 'http://wiki.csswg.org/planning/tucson-2013'

[08:27] <dbaron> [discussion]

[08:28] <dbaron> Peter: Anolis is also more self-contained.

[08:28] * SteveZ has joined #css

[08:29] * Ms2ger listens

[08:29] <dbaron> ACTION Bert (with help from jdaggett) to move the css3 module preprocessor scripts from the member-only css3-src tree into the dev.w3.org hg public tree due 2013-06-01

[08:29] * trackbot is creating a new ACTION.

[08:29] <trackbot> Created ACTION-537 - (with help from jdaggett) to move the css3 module preprocessor scripts from the member-only css3-src tree into the dev.w3.org hg public tree due 2013-06-01 [on Bert Bos - due 2013-02-13].

[08:29] * koji has joined #css

[08:29] * jdaggett has joined #css

[08:29] * jdaggett good morning tucson!

[08:31] <fantasai> ScribeNick: fantasai

[08:31] * tantek has joined #css

[08:31] <dbaron> Topic: Variables, continued

[08:31] * TabAtkins_ has joined #css

[08:31] <fantasai> dbaron: We had some discussion on list about what exactly should and shouldn't be allow in variables.

[08:31] <fantasai> dbaron: Simple change I would like to make

[08:31] <fantasai> dbaron: Current rules have quirk that CDO/CDC are only allowed if they're inside braces, but not at top level

[08:31] <fantasai> dbaron: Would like to change this.

[08:32] <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Feb/0196.html

[08:32] <fantasai> dbaron: Some other discussion about rules

[08:32] <fantasai> dbaron: Remaining discussion was wrt allowing unmatched constructs

[08:32] <fantasai> dbaron: I'm queasy about that

[08:33] <dbaron> fantasai: Would break forward-compatible parsing.

[08:33] <fantasai> TabAtkins: Only proposing to add closing brackets

[08:33] <fantasai> dbaron: I meant six things

[08:34] <fantasai> dbaron: Opening brackets, braces, parens, baduri, badstring, bad...

[08:34] <fantasai> dbaron: These consume to end of file

[08:34] <dbaron> s/bad.../badcomment/

[08:34] <dbaron> dbaron: except for baduri and badstring

[08:35] <fantasai> fantasai: I don't think allowing closing brackets while preventing opening brackets is helpful to anyone. Just escape both of them, it's consistent and redictable

[08:36] <fantasai> dbaron: [gives example of where, a year ago, we could have allowed closing parens, but then now that would prevent use of such rules in @supports]

[08:36] <fantasai> RESOLVED: Can't put unmatched brackets, praces, parens in variables

[08:36] <fantasai> (unless escaped)

[08:36] <dbaron> s/praces/braces/

[08:37] * rhauck has joined #css

[08:37] <fantasai> RESOLVED: Accept CDO/CDC at top level in variableshttp://lists.w3.org/Archives/Public/www-style/2013Feb/0196.html

[08:38] <fantasai> dbaron: baduri is very much like an unmatched opening paren

[08:39] <fantasai> RESOLVED: No badstring in variables

[08:39] * rhauck Quit ("Leaving.")

[08:40] <fantasai> dbaron: I'm ok with accepting badurl, but would like to review the text before going to LC

[08:40] <fantasai> plinss: I'm a little uncomfortable accepting badurl...

[08:40] <fantasai> TabAtkins: It's like a function token

[08:40] <fantasai> plinss: It takes other things inside that though

[08:40] <fantasai> plinss: Inside a URL token, can't you have unmatched square brackets?

[08:40] <fantasai> dbaron: Yes

[08:41] <fantasai> plinss: That's dangerous

[08:41] * Rossen has joined #css

[08:41] <fantasai> plinss: I don't think you're gaining a whole lot by accepting badurl

[08:41] <fantasai> plinss: The URL token is a realy odd weird piece of CSS parsing

[08:41] <fantasai> plinss: I suspect we'd be opening up a danger zone and break something down the road

[08:42] <dbaron> fantasai: I think it's safer not to accept badurl, and it's a very weak use case.

[08:42] <fantasai> plinss: I'm not strongly against it, but I'd have to be convinced it's ok, and I'm not convinced it's ok

[08:42] <fantasai> RESOLVED: badurl is not allowed in variables

[08:43] <dbaron> (so all the resolutions here except for the CDO/CDC change are no-change resolutions)

[08:44] <dbaron> Topic: discussing whether to discuss placeholder styling

[08:44] <fantasai> Topic: Placeholders

[08:44] <fantasai> TabAtkins: My proposal is to do the placeholder pseudo-class and fill-opacity

[08:44] <fantasai> TabAtkins: which fantasai called her crazy proposal

[08:45] <fantasai> TabAtkins: I know dbaron had an objection to fill-opacity, didn't get into it

[08:45] <dbaron> glazou: discussion limited to 20 minutes

[08:45] <fantasai> dbaron: I'm not objecting to doing it, objecting to making decent placeholder styling depend on that

[08:46] <fantasai> tantek: Would fill-opacity affect existing pages?

[08:46] <fantasai> TabAtkins: No. You just multiply color's alpha by fill-opacity and use that. Very simple.

[08:46] <dbaron> s/existing pages/performance of existing pages using placeholder/

[08:47] <fantasai> smfr: A little odd to do fill-opacity without fill

[08:47] <fantasai> dbaron: My concern is web-compat implications

[08:48] * stearns thinks he agrees with dbaron - fill-opacity would be good to do, but seems separate from the issue of styling placeholder state versus placeholder value content

[08:48] <fantasai> dbaron: Maybe people are using it and expecting it to have no effect

[08:48] <dbaron> ... outside of SVG

[08:48] <fantasai> TabAtkins: Same problem with other SVG properties we import

[08:48] <fantasai> tantek: We could add fill-opacity, leave placeholder issue open

[08:49] <fantasai> dbaron: Point is I want placeholder issue resolved in a timeframe that's faster than resolving fill-opacity

[08:49] <fantasai> dbaron: I'm fine with pseudo-class + pseudo-element

[08:49] <dbaron> Tab: I think the only problem there was that we couldn't decide on names.

[08:50] <dbaron> [tab sets up a possibility table on the whiteboard]

[08:50] <fantasai> szilles: Could you describe what each thing is?

[08:51] <fantasai> TabAtkins: ::placeholder is a box immediately containing the placeholder text

[08:51] <fantasai> TabAtkins: :placeholder is a pseudo-class that matches the input element when the placeholder is showing

[08:52] <fantasai> TabAtkins writes various options on the whiteboard

[08:53] * isherman-book has joined #css

[08:53] <fantasai> :placeholder

[08:53] <fantasai> :has-placeholder

[08:53] <fantasai> :showing-placeholder

[08:53] <fantasai> :placeholder-showing

[08:53] <fantasai> :placeholding

[08:53] <fantasai> ::placeholder

[08:53] <fantasai> ::placeholder-text

[08:53] <fantasai> ::placeholder-content

[08:53] <fantasai> ::placeholder-value

[08:53] * stearns ::value?

[08:54] <dbaron> Tantek: eliminate ::value because of sylvaing's use case about fading out the placeholder while typing

[08:54] <stearns> ok

[08:54] * Rossen Quit (Ping timeout: 60 seconds)

[08:54] <dbaron> ?: eliminate ::placeholder-text because of Bert's objection that it might not be text

[08:55] <dbaron> fantasai: Authors might be more likely to go for the one that's called "placeholder"

[08:55] <dbaron> fantasai: Also if one author uses pseudo-class and the other uses pseudo-element, cascading rules don't apply

[08:55] * stearns has a preference for ::placeholder and some other name for the pseudo-class, as ::placeholder matches the HTML attribute

[08:55] * Rossen has joined #css

[08:56] <dbaron> dbaron: That same confusion happens with nested elements.

[08:56] <dbaron> Tantek: agree with dbaron; it's an existing style sheet cross

[08:56] <dbaron> ... -organizational problem

[08:56] * fantasai thinks she agrees with stearns, but isn't sure whta to call the other thing

[08:56] * stearns :showing-placeholder makes the most sense to me

[08:57] <dbaron> I'm in favor of ::placeholder and :showing-placeholder as well.

[08:57] <fantasai> Bert: I agree with fantasai, I think authors will think of the two as being mostly the same thing

[08:57] * fantasai agrees with dbaron and stearns

[08:57] <dbaron> Tab and Peter want :placeholder and either ::placeholder-{content,value}

[08:57] * glazou agrees with dbaron and stearns and fantasai

[08:57] * lmclister has joined #css

[08:58] <fantasai> tantek: Prever :has because it's shorter

[08:58] <fantasai> smfr: Problem with has is that it might mean "has a placeholder attribute"

[08:58] * SimonSapin agrees on ::placeholder and ( :showing-placeholder or :placeholder-showing )

[08:58] <dbaron> :placeholder-shown ?

[08:58] * Bert :waiting, :pre-fill, :hinted, :prompt

[08:58] * leif Quit ("Leaving.")

[08:59] <fantasai> tantek: :placeholder-shows

[08:59] <fantasai> plinss: :placeholder-active

[08:59] <fantasai> plinss: :placeholder-visible

[08:59] * Rossen Quit (Ping timeout: 60 seconds)

[09:00] * isherman-book Quit (Ping timeout: 60 seconds)

[09:00] * Rossen has joined #css

[09:00] <dbaron> loooking at HTML5 spec's terminology leads to :placeholder-presented, which nobody likes

[09:01] <dbaron> Tantek: :shows-placeholder ?

[09:02] * JohnJansen has joined #CSS

[09:02] <fantasai> Straw Poll

[09:03] * tantek Quit (Ping timeout: 60 seconds)

[09:03] <fantasai> A :placeholder-shows

[09:03] <fantasai> B :placeholder-active

[09:03] <fantasai> C :placeholder-visible

[09:03] <fantasai> D :shows-placeholder

[09:03] <fantasai> E :placeholder-shown

[09:03] <fantasai> glazou: E

[09:03] <fantasai> jdaggett: abstain

[09:03] <fantasai> SimonSapin: E

[09:03] <fantasai> dbaron: C

[09:03] <fantasai> glenn: abstain

[09:04] <fantasai> koji: abstain

[09:04] <fantasai> fantasai: abstain

[09:04] <dbaron> smfr: C

[09:04] <fantasai> Rossen: abstrain

[09:04] <dbaron> Tantek: D

[09:04] * Rossen Quit (Ping timeout: 60 seconds)

[09:04] <dbaron> 2 abstains

[09:04] <fantasai> The Japanese Delegation abstains

[09:04] <dbaron> Steve: weak E

[09:04] <dbaron> Bert: abstain

[09:04] <dbaron> Peter: Still prefer :placeholder and ::something-more

[09:04] <fantasai> plinss: votes for the write-in candidate

[09:05] <dbaron> Tab: C, though I prefer plinss's write-in-candidate

[09:05] <fantasai> Conclusion: E vs. C

[09:05] * JohnJansen Quit ("Page closed")

[09:06] <fantasai> glazou: I think from international audience, I think best is :placeholder-shown

[09:06] <fantasai> glazou: It's understandable. Does not confuse with visibility property

[09:06] * stearns C might be better than E - visible may be in more people's vocabularies than shown

[09:06] <dbaron> Tab: any objections to E?

[09:06] <fantasai> RESOLVED: :placeholder-shown & ::placeholder adopted

[09:07] * nvdbleek Quit ("Leaving.")

[09:07] * tmpsantos Quit ("Leaving")

[09:07] <fantasai> Topic: Regions Update

[09:07] <fantasai> szilles: Many, but not all, were at meetup last night

[09:07] <fantasai> szilles: Main new thing is that there's a polyfill out there

[09:07] <fantasai> szilles: Runs on any moder browser

[09:08] <fantasai> szilles: a) function complete, and b) perf-challenged

[09:08] <smfr> s/moder/modern

[09:08] <fantasai> szilles: But allows experimenting with the concepts

[09:08] * tantek has joined #css

[09:08] <fantasai> szilles: Example in the appendix now splits out definition of area in which regions are defined into separate file, as a Web Component, using shadow dom

[09:08] <stearns> s/function/not function/ ??

[09:08] <fantasai> szilles: Both Bert and H��kon replied that this deals with their objection.

[09:08] <fantasai> szilles: That's the essence of what I wanted to say.

[09:09] <fantasai> szilles: questions or concerns?

[09:09] <fantasai> glazou: We don't have no mechanism for easy/fast prototyping of CSS features

[09:09] <fantasai> glazou: Long ago a proposal for having selectors that map to JS boolean method

[09:10] <fantasai> glazou: We need to think about a way for prototyping CSS features via JS

[09:10] <fantasai> glazou: Would allow larger experiments and tests

[09:10] <TabAtkins_> See my recent blog post over this exact topic: http://www.xanthir.com/b4N80

[09:10] <fantasai> glazou: Web community needs it, we could also use ourselves, something to think about for the future

[09:10] <TabAtkins_> +1

[09:11] <stearns> see also: http://www.w3.org/community/nextweb/

[09:11] <SteveZ> URL for Regions Polyfill: http://adobe-webplatform.github.com/css-regions-polyfill/

[09:12] <fantasai> Topic: Conditional Rules

[09:12] * Rossen has joined #css

[09:13] <dbaron> Topic: Regions, continued

[09:13] <fantasai> Bert: The web component example refers to the web components in the HTML, not from the CSS

[09:13] <fantasai> Bert: So you still can't do this from CSS

[09:13] <fantasai> szilles: I thought we had some kind of include

[09:13] <fantasai> Bert: Yes, that's what we discussed

[09:13] <fantasai> Bert: But it appears not to be there

[09:13] <fantasai> Bert: So you still can't reuse the style sheet

[09:14] <fantasai> Bert: you need to change the HTML file if you want to change style

[09:14] <fantasai> Bert: There is no other way, apparently

[09:14] <fantasai> szilles: Ok, I will take that comment back

[09:15] <fantasai> szilles: If there was a way of including a template description via stylesheet instead of via HTML

[09:15] <stearns> there is a way using decorators, but that's not as far along as templates

[09:16] <stearns> I showed a decorator example on the wiki page

[09:16] <fantasai> fantasai: The requirement here is that you can change whether or not regions are used, or what template is used, without touching the markup

[09:16] * sylvaing has joined #css

[09:16] <fantasai> tantek: To put another way, you can make that decision via media queries

[09:17] <fantasai> fantasai^: And the comment from Bert is that this example does not meet that requirement

[09:17] <fantasai> tantek: I'd say what fantasai says, except s/markup/content/

[09:17] * sylvaing Quit ("")

[09:18] <fantasai> tantek: I'd also say, our examples should be exemplary, not bad examples, but show best practice

[09:18] * sylvaing_away is now known as sylvaing

[09:18] <fantasai> tantek: Path of sending different markup is a bad path in general. Causes problems across browsers, esp. non-majority browsers, across devices

[09:18] <fantasai> tantek: Anything we can do to discourage sending different markup is a good thing

[09:19] <fantasai> glazou: Anything else on Regions?

[09:19] <stearns> web components are bad practice?

[09:19] <fantasai> Bert: Assuming we do this Web Components, where should it be defined that you can include Web Components?

[09:19] <fantasai> Bert: Where is the syntax defined for including the Web Components?

[09:20] <fantasai> TabAtkins: In the Web Components spec

[09:20] <fantasai> Bert: But that doesn't define a CSS syntax

[09:20] <fantasai> Bert: If you include a style sheet, that style sheet has to in turn somehow include a Web Component

[09:21] <fantasai> TabAtkins: Use <link>

[09:21] <fantasai> Bert: That doesn't work for XML

[09:21] <fantasai> szilles: I have some ideas

[09:21] <fantasai> szilles: Need to think about it

[09:22] <fantasai> ACTION Steve: figure out how to link web components templates for using regions via CSS

[09:22] * trackbot is creating a new ACTION.

[09:22] * RRSAgent records action 1

[09:22] <trackbot> Created ACTION-538 - Figure out how to link web components templates for using regions via CSS [on Steve Zilles - due 2013-02-13].

[09:22] <fantasai> Topic: Conditional Rules

[09:22] * sylvaing oh great, there is ::placeholder pseudo-element. No doubt, the DoubleTree provides peyote to its guests

[09:23] * fantasai gave sylvaing honorary mention in her talk about spec-writing last night

[09:23] * sylvaing whoa.

[09:23] * fantasai for fulfilling the role of making snarky comments on IRC during the meetings :)

[09:24] * fantasai and doing a damn good job of it

[09:24] <dbaron> http://dev.w3.org/csswg/css3-conditional/doc-20121213-LCWD.txt

[09:24] * kawabata has joined #css

[09:25] * sylvaing I think you're calling me the court jester

[09:25] <fantasai> dbaron: First issue is editorial, improving examples

[09:25] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Dec/0277.html

[09:25] * glenn Quit (Client closed connection)

[09:25] * glenn has joined #css

[09:25] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Dec/0330.html

[09:26] <fantasai> 3rd issue http://lists.w3.org/Archives/Public/www-style/2013Jan/0070.html

[09:26] <fantasai> "What does @supports return when the OS prevents the support?"

[09:26] <fantasai> dbaron: Basically, this is things like "what happens if the user has a browser pref to ignore colors, or what happens if it's Windows high-contrast mode, should the UA say the color property is not supported?"

[09:27] <fantasai> dbaron: My inclination is to say not pay attention to that

[09:27] <fantasai> dbaron: These can be considered UA stylesheet rules

[09:27] <fantasai> dbaron: In some cases, might not want to expose this information

[09:27] <fantasai> jdaggett: I think this is a very slippery slope

[09:27] <fantasai> dbaron: In which direction?

[09:28] <fantasai> jdaggett: If you're defining this based on some sort of relatively subjective definition of whether this is supported or not, will be very ambiguous. Other things will come upw that will cause us to churn

[09:28] <fantasai> dbaron: So in favor of saying that it does not affected by this stuff

[09:28] <fantasai> jdaggett: yes

[09:28] <fantasai> jdaggett: Should be very cut and dry

[09:28] <fantasai> plinss: I agree with that

[09:28] <fantasai> plinss: Also, those sorts of thing,s if they're going to be exposed, should be via media queries

[09:28] <fantasai> plinss: You don't say you don't support color if you're on a monocrhome display

[09:29] <dbaron> dbaron: That's exactly what I was going to say.

[09:29] <fantasai> SimonSapin: @supports should match whether declarations are handled as invalid

[09:29] <dbaron> (er, last 2 in previous order)

[09:29] * isherman-book has joined #css

[09:29] <fantasai> dbaron: Sounds like we're all in favor of saying that it's not affected by things like UA preferences

[09:30] <fantasai> dbaron: Add text to the spec saying that

[09:30] <fantasai> RESOLVED: @supports is not affected by limitations imposed by UA or system

[09:30] <dbaron> or user preferences

[09:30] <fantasai> s/UA/user prefs/

[09:30] <fantasai> 4th issue

[09:30] <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Jan/0436.html

[09:31] <fantasai> dbaron: Replied to reject [explains rationale in message]

[09:31] <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Jan/0442.html

[09:31] <fantasai> fantasai: I agree with your rationale

[09:32] <fantasai> fantasai: If we want to go in that direction, should add some syntax for flagging individual lines as required.

[09:32] <fantasai> fantasai: But not doing that right now anyway.

[09:32] <fantasai> 5th issue

[09:32] * jarek has joined #css

[09:32] <fantasai> dbaron: WebApps posted API issues

[09:33] <fantasai> dbaron: Made some edits to clarify

[09:33] <fantasai> dbaron: One thing I need to figure out, need to test what implementations do

[09:33] <fantasai> dbaron: Haven't had a chance to do that yet

[09:33] <fantasai> fantasai: Can anyone else help with that?

[09:33] <fantasai> dbaron: It's error handling for insertRule

[09:33] <fantasai> dbaron: Same question exists for the style sheet object

[09:33] <fantasai> dbaron: We should come back on this one

[09:33] <fantasai> 6th issue should come back on

[09:33] <fantasai> dbaron: It's a long message sent not too long before LC

[09:34] <fantasai> dbaron: Rewrote a bunch of stuff, have to figure out whether addressed or not

[09:34] <fantasai> dbaron: Don't think we're quite ready for CR

[09:34] <fantasai> dbaron: But maybe next telecon

[09:34] <fantasai> [discussion of scheduling next telecon]

[09:35] <fantasai> ppl travelling next week, so next call is the 20th

[09:35] <fantasai> <br type=coffee>

[09:38] * TabAtkins_ Quit (Ping timeout: 60 seconds)

[09:57] <Bert> Scribenick: bert

[09:57] <Bert> Topic: fonts

[09:57] <Bert> jdaggett: What should the LC period be?

[09:57] <Bert> ... It's a big spec

[09:57] <Bert> ... 6 weeks? 2 months?

[09:57] <Bert> fantasai: no more than 6 weeks

[09:58] <Bert> ... You can do a 2nd LC

[09:58] <Bert> jdaggett: So plan for 2 LCs?

[09:58] <Bert> fantasai: Can also offer an extension after a while.

[09:58] <Bert> dbaron: And wait a bit after the daedline

[09:58] <Bert> ... because there will be late comments.

[09:58] <Bert> glazou: Officially not obliged to respond after deadline.

[09:59] <Bert> ... But in practice...

[09:59] <Bert> jdaggett: So 6 weeks then

[09:59] <Bert> ... Aks Webapps, SVG and i18n for cooments

[09:59] <Bert> fantasai: LC or WD?

[09:59] <Bert> jdaggett: First a WD.

[10:00] <Bert> Topic: multicol

[10:00] <fantasai> SimonSapin: Discussed multicol at tpca

[10:00] <fantasai> SimonSapin: Problem with pseudo-algorithm, which has concept of unknown available widht, and I don't think it makes sense

[10:00] <fantasai> SimonSapin: Don't see a situation in which that happens

[10:00] <fantasai> SimonSapin: After long discussion with H��kon and Bert, f2f and email, still don't have a resolution

[10:01] <fantasai> SimonSapin: Underlying issue is that from what I understand from Bert's explanation,

[10:01] <fantasai> SimonSapin: this condition is triggered when you calculate intrinsic sizes of a multicol element

[10:01] <fantasai> SimonSapin: The issue then is that we have two definitions of this

[10:01] <fantasai> SimonSapin: One in sizing, one in box

[10:01] <fantasai> SimonSapin: But whichever we pick, neither of them defines available width == unknown

[10:02] <fantasai> Bert: Multicol relies only on level 2

[10:02] <fantasai> Bert: And CSS2.1 doesn't define shrink-to-fit in many cases

[10:02] <fantasai> Bert: So cases where it's shrink-to-fit are undefined

[10:02] <fantasai> Bert: Multicol cannot defined actual size of columns because it relies on shrink-to-fit algorithm

[10:02] <fantasai> Bert: And multicol doesn't want to define it either

[10:03] <fantasai> Bert: need a sizing algo ot define shrink-to-fit

[10:03] <dbaron> fantasai: it would make sense for multicol to say that in a shrink-to-fit situation, the number of columns and width are undefined

[10:03] <dbaron> fantasai: ... and then deal with that in a later module

[10:04] <fantasai> szilles: Could add a note pointing to where the definition might appear, or a suggested strategy

[10:04] <Ms2ger> s/tpca/tpac/

[10:04] <fantasai> dbaron: I would rather partially define it than say it's undefined

[10:05] <fantasai> Bert: It defines what the final width if you have both number of columns and column width

[10:05] <fantasai> Bert: If either one is missing, then can't calculate

[10:06] <dbaron> fantasai: shrink-to-fit in CSS 2.1 tries to calculate the size incorporating the widest size it can take, the narrowest size it can take, and the available size

[10:06] <dbaron> fantasai: Saying the multicol is exactly the column-width times column-count violates that formula

[10:06] <dbaron> fantasai: the narrowest a multi-column element can take ... drops columns rather than overflowing

[10:07] <dbaron> fantasai: ... when the window is narrow... so you stay within the containing block

[10:07] <dbaron> fantasai: The formula that says you multiply the width by the column count violates the shrink-to-fit formula.

[10:07] <fantasai> Bert: If you set the column width and column count, that's what you should get

[10:07] <fantasai> fantasai: But you don't get that

[10:08] <glazou> ScribeNick: jdaggett

[10:09] <SimonSapin> http://dev.w3.org/csswg/css3-multicol/#pseudo-algorithm

[10:09] <jdaggett> bert: discussing col-width and number of columns

[10:09] <SimonSapin> lines 5~8

[10:09] <jdaggett> simon: bert is talking

[10:10] <jdaggett> bert: 8 possible cases

[10:10] <jdaggett> bert: this alg is trying to compactly specify this

[10:10] <dbaron> q+ to say that it shouldn't be talking about shrink-to-fit

[10:11] <jdaggett> simon: so you're saying in the case of mult-col with width this alg applies?

[10:11] <jdaggett> bert and simon talking about 2.1 vs. this alg

[10:11] <jdaggett> simon: this is contradiction with 2.1 alg

[10:12] <SimonSapin> http://www.w3.org/TR/CSS21/visudet.html#float-width "The shrink-to-fit width is: min(max(preferred minimum width, available width), preferred width)."

[10:12] <jdaggett> dbaron: other specs shouldn't talk about shrink to fit

[10:12] <dbaron> dbaron: they should talk about preferred intrinsic width and minimum intrinsic width

[10:12] <fantasai> dbaron: They should talk about preferred minimum width and minimum width, which are the inputs to shrink-to-fit

[10:12] <SimonSapin> Floats: "If 'width' is computed as 'auto', the used value is the "shrink-to-fit" width. "

[10:12] <jdaggett> fantasai: i agree with dbaron

[10:12] <jdaggett> fantasai: they can use shrink to fit but they shouldn't define it

[10:13] <jdaggett> bert: so lines 5-8 should be...

[10:14] <dbaron> dbaron: shrink-to-fit is simply max(minimum intrinsic width, min(preferred intrinsic width, available width)). That's it. Everything else should define the intrinsic widths.

[10:14] <dbaron> Bert: so min intrinsic should be column-count * column-width

[10:14] <Bert> (lines 05-08 effectively say that the min intrinsic width is N * W + (N - 1) * gap)

[10:14] <dbaron> fantasai: But it shouldn't be, because it won't overflow if it's smaller than that.

[10:14] <dbaron> fantasai: ... since a multicol can be narrower than that without overflow

[10:14] <jdaggett> bert: the user says i want that width, so that's the min width

[10:14] <jdaggett> dbaron: there are cases

[10:15] <fantasai> dbaron: There are cases where it is appropriate for a minimum width to be ...

[10:15] <fantasai> fantasai: You can't define table layout sensibly if you define it some other way

[10:15] <fantasai> dbaron: We could decide that it's better for the minimum intrinsic width to use or ignore column count

[10:15] <fantasai> dbaron: Doesn't have to be strictly in terms of what causes overflow, because that's a primitive and strict definition

[10:15] <dbaron> s/strict/incorrect/

[10:16] <jdaggett> bert: dbaron is correct but that's what we did in multi-col

[10:16] <jdaggett> simon: so the multi-col is defining min-width

[10:16] <jdaggett> bert: yes, should mention that...

[10:16] <dbaron> Simon: I see no relationship between what's written and defining minimum intrinsic width

[10:16] <jdaggett> simon: so what is max-width?

[10:16] <fantasai> dbaron: In case where column widht and column-count are both specified, max-content should include both of them

[10:16] <fantasai> dbaron: More interesting if some aren't specified

[10:17] <jdaggett> fantasai: tab and i worked through some examples for flexbox

[10:17] <jdaggett> fantasai: since we use these concepts everywhere

[10:17] <fantasai> http://dev.w3.org/csswg/css3-sizing/#multicol-intrinsic

[10:17] <jdaggett> fantasai: the results should be consistent

[10:18] <dbaron> fantasai: and we wrote a spec for that, which is not consistent with what multicol sys

[10:18] <jdaggett> stevez: section 19-23 talks about behavior

[10:20] <dbaron> jdaggett: Seems like multiple specs are involved; should there be an action on Bert, fantasai, Simon, dbaron to decide what should happen where?

[10:20] <dbaron> fantasai: I think the problem is we've brought this up at every face-to-face and there's no agreement.

[10:20] <jdaggett> fantasai: happens repeatedly at f2f

[10:20] <dbaron> fantasai: Maybe would help if dbaron got involved?

[10:20] <jdaggett> stevez: the disagreement is on min?

[10:20] <dbaron> SteveZ: Is the disagreement only on min? clear what preferred is.

[10:21] <jdaggett> simon: can we agree that multi-col should not define min-width or max-width?

[10:21] <dbaron> s/min-width or max-width/min-content or max-content widths/

[10:22] <jdaggett> simon and bert discussing which spec should define this

[10:22] <dbaron> Bert: The sizing spec would then have to define every type of box, and thus never be done.

[10:22] <SteveZ> lines 19-23 define what happens when all three of available-space, column-count and column-width are specified. This section clearly states that column width is preserved (as much as possible) and columns are eliminated (up to the last column). This suggests that the min-intrinsic-width should also be defined without regard to the column count; that is, it should be the width of 1 column

[10:22] <jdaggett> fantasai: b/c multi-col is further along

[10:23] <dbaron> fantasai: sizing spec would define concepts and define sizing for css 2.1 types and multicol, and new layout types would define min content and max content widths for itself

[10:23] <jdaggett> fantasai discussing size vs. box specs

[10:23] <dbaron> fantasai: but multicol is already in CR

[10:23] <jdaggett> bert: i agree

[10:23] <dbaron> Bert: I agree with that, but multicol cannot completely define things without knowing intrinsic widths of what's inside

[10:24] <jdaggett> stevez: if i have a col width, then that is the min intrinsic width?

[10:24] <dbaron> fantasai: Multicol can assume that the things inside the columns have preferred intrinsic and minimum widths

[10:24] <jdaggett> fantasai: yes

[10:24] <jdaggett> fantasai: multi-col is tricky

[10:24] <jdaggett> fantasai: sizing dealt with what happens when the containing block varies

[10:25] <jdaggett> fantasai: and we put results into the defn

[10:25] <jdaggett> fantasai discussing relation with table sizing alg

[10:26] <dbaron> fantasai: figuring out the rules for preferred and minimum intrinsic widths was an experimental process of seeing how its layout rules behave at different widths

[10:26] <fantasai> szilles: So special thing wrt multicol is that the optimal width is neither minimum nor the maximum

[10:26] <jdaggett> stevez discussing details of multi-col alg

[10:27] <dbaron> fantasai: You almost never get exactly the column-width you asked for.

[10:27] <fantasai> szilles: Wrt getting 2.1 shrink-to-fit, there's no harm in throwing away the column count

[10:28] <fantasai> szilles: and doing the right thing to get the smallest value

[10:28] <jdaggett> stevez: don't see the harm in throwing away column count

[10:28] <jdaggett> fantasai: that would make it work as the screen size changes

[10:28] <jdaggett> bert: that's the author's choice

[10:28] <dbaron> fantasai: If you include column-count in minimum inttrinsic width, you'll get overflow when a multicol happens to be in a float, but not in normal flow.

[10:28] <jdaggett> fantasai: for an inflow block you don't get what you ask for

[10:28] <dbaron> fantasai: So we should do the same thing for floats, and not include column-count in the minimum intrinsic width.

[10:29] <dbaron> I think fantasai is correct that column-count shouldn't factor into minimum intrinsic widths for multicols.

[10:29] <jdaggett> stevez: calc min width, then apply 19-23

[10:29] <fantasai> dbaron, well, it should if column-width is not specified, because then you don't drop columns...

[10:30] <fantasai> dbaron, but if both are specified, yes

[10:30] <jdaggett> bert: that could have been a choice

[10:30] <jdaggett> bert: it's easier to use what multi-col does now

[10:30] <jdaggett> stevez: this is the argument if what you want is overflow

[10:31] <dbaron> fantasai: I don't think we should overflow by default in some cases when the normal behavior is not to overflow.

[10:31] <jdaggett> fantasai stevez bert discussing details of the multi-col alg

[10:33] <fantasai> Bert: This case isn't the improtant one, could go either way, tho would prefer not to change it

[10:33] <jdaggett> glazou: simon is not happy with one of the specs, we have to solve

[10:33] <fantasai> Bert: Interesting cases are the next two

[10:33] <fantasai> SimonSapin: Issue is with concept of unknown available width in the multicol module

[10:34] <jdaggett> simon: we can decide either way but i'm objecting to how it's done in multi-col

[10:34] <fantasai> SimonSapin: I'm objecting to the way it's done in multicol right now

[10:34] <jdaggett> stevez: is that form or content, the results or how it's specified?

[10:34] <dbaron> Steve: the results or the way it's specified?

[10:34] <jdaggett> simon: how it's specificed

[10:34] <jdaggett> fantasai: i don't like the results

[10:35] <jdaggett> dbaron: i agree with both objections, how it's specified and the results

[10:35] * TabAtkins_ has joined #css

[10:35] * dino Quit (dino)

[10:35] <jdaggett> dbaron: the only way out of this is to remove instrinsic width details from multi-col

[10:36] <dbaron> dbaron: I'm not happy with removing intrinsic width stuff from multicol, but it seems like the only way out is to remove (above)

[10:37] <jdaggett> simon and bert discuss dependencies of alg in different specs

[10:37] <jdaggett> sizing solves all?

[10:38] <jdaggett> fantasai: remove from multi-col and work on in sizing

[10:38] <jdaggett> fantasai: it's an early WD so we can incorporate other layout models

[10:38] <jdaggett> fantasai: that's what's needed

[10:38] <jdaggett> bert resisting

[10:39] <jdaggett> fantasai: i want to take the fixes that were proposed by simon

[10:39] <jdaggett> simon: the changes from tpac leaves some things undefined, to be defined by sizing

[10:39] <dbaron> Simon: Changes I proposed were to remove all the parts of multicol algorithm related to "unknown available width"

[10:39] <jdaggett> bert resisting

[10:40] <jdaggett> stevez: to be clear, you're saying remove 5-8 and width alg in sizing?

[10:40] <dbaron> Simon: I want to remove the idea that available width can be unknown.

[10:40] <TabAtkins_> Dont' resist, Bert. Come to the dark side...

[10:41] <dbaron> dbaron: There is and should be no concept of "unknown available width".

[10:41] * glazou TabAtkins you finally disclose you're bert's dad ?-)

[10:41] <jdaggett> discussion of where available width is

[10:42] * TabAtkins_ glazou NOOOOOOOOOOOOOOOOOOOO

[10:42] <jdaggett> dbaron and bert discussing widths some more

[10:42] <jdaggett> and so on and so on...

[10:43] <fantasai> dbaron: Everything about width depending on concept should be encapsulated in min-content/max-content width, and there's no concept of unknown available width

[10:43] <jdaggett> repeat while (true) discuss width;

[10:44] <jdaggett> discussion of unknown available width

[10:44] <dbaron> dbaron: the rules for preferred and minimum intrinsic widths don't deal with a concept of available width

[10:45] * sylvaing Bert as Luke Skywalker sounds pretty epic

[10:45] <dbaron> dbaron: the rules for intrinsic width calculation should be separate from that algorithm, and there should be no concept of "unknown available width"

[10:45] * rhauck has joined #css

[10:45] <fantasai> SimonSapin: Where multicol says "available width", it should say "used width"

[10:45] <jdaggett> simon: when multi-col says avaiable width it should say "available width of multi-col element"

[10:46] <SimonSapin> s/"available width of multi-col element"/"used width of multi-col element"/

[10:46] <dbaron> SteveZ: Can we resolve to switch multicol from an 8-part algorithm to 4-part algorithm?

[10:46] <jdaggett> bert: now we're making things more undefined

[10:46] <jdaggett> simon: yes

[10:47] * sylvaing CSS: now with more undefined

[10:48] <jdaggett> glazou: the discussion is going in circles

[10:49] <jdaggett> stevez: throw out the cause of the disagreement and procede

[10:49] <jdaggett> stevez: not ideal but practical for proceeding with the CR

[10:49] <glazou> I suggest the corsican way ; we vite, throw the poll boxes to the sea, lock the room and the last survivor wins

[10:49] <glazou> s/vite/vote

[10:51] <jdaggett> discussions of scope of multi-col pseudo-alg

[10:51] <jdaggett> bert resisting

[10:51] <fantasai> fantasai: Scope of the pseudo-algorithm should be to calculate the number and width of the columns

[10:51] <fantasai> fantasai: It should take as input a used width (calculated by the various layout algorithms as appropriate), column-count, and column-width

[10:51] * sylvaing RESOLVED: must add a 'bert resisting' meme

[10:52] <fantasai> Bert: That's what it does already

[10:52] * jdaggett should be an emoji character

[10:52] <fantasai> fantasai: No, it tries to calculate a width in some cases

[10:52] <fantasai> it should not do that.

[10:52] * sylvaing jdaggett YES

[10:52] <fantasai> SimonSapin: This algorithm does 2 things. I am proposing to move one half into sizing or anothe rmodule

[10:52] <jdaggett> simon: this alg does two things, i suggest moving half to sizing

[10:53] <fantasai> SimonSapin: These two things are really different, and confusing to do them both with the same algorithm

[10:53] <jdaggett> simon: the two things are different, confusing to do with the same alg

[10:53] * sylvaing IRC echo is enabled

[10:53] <jdaggett> bert: might well be but how do we keep track

[10:54] <jdaggett> bert: why not do in multi-col?

[10:54] * rhauck Quit (Ping timeout: 60 seconds)

[10:54] <jdaggett> stevez: doesn't seem to make sense to do in multi-col

[10:54] <jdaggett> dbaron: any layout type can define these independently

[10:55] <jdaggett> dbaron: defn in multi-col is totally unreasonable

[10:55] <jdaggett> simon: could have in multi-col but hard to get right before CR

[10:55] <dbaron> dbaron: I don't see any reason to pull it out of this module except that the definition in css3-multicol is unreasonable.

[10:55] * rhauck has joined #css

[10:55] <jdaggett> rossen: sizing defines intrinsic sizing?

[10:55] <jdaggett> bert: yes but can't define for all layout types

[10:56] <jdaggett> simon: that's another issue

[10:56] <jdaggett> bert: sizing alg can only do that for known layout types

[10:56] <jdaggett> fantasai: they can use the terminology from sizing

[10:56] <jdaggett> stevez: we haven't finished sizing yet

[10:57] <jdaggett> stevez: so trying to define what multi-col does

[10:57] <jdaggett> stevez: doesn't make sense

[10:57] * rhauck1 has joined #css

[10:57] <jdaggett> dbaron: you can use the 2.1 terminology without any problems i think

[10:57] <jdaggett> bert resisting

[10:57] <dbaron> dbaron: I think the multicol intrinsic sizing rules are simple enough that (above)

[10:58] <jdaggett> fantasai: it's going to take a lot of work to get right before CR

[10:58] * teoli Quit (Client closed connection)

[10:58] <jdaggett> fantasai: makes more sense to tackle them together in sizing

[10:58] <dbaron> fantasai: But (1) it's going to take a lot of work to get this right, and (2) the people working on it are not considering interaction with other layout modules.

[10:58] <jdaggett> bert thinking

[10:59] <dbaron> SteveZ: can we import the text from css3-sizing into multicol?

[10:59] <jdaggett> discussion of whether to use sizing text in multi-col

[10:59] <dbaron> fantasai: Not stable enough yet.

[10:59] * sylvaing jdaggett is defining a whole collection of bert emojis

[10:59] <dbaron> fantasai: ... for a CR-level module. We can incorporate it into level 2 of multicol.

[10:59] * rhauck Quit (Ping timeout: 60 seconds)

[10:59] <jdaggett> stevez: the text in sizing wouldn't work to replace 5-8?

[11:00] <jdaggett> fantasai: wouldn't do the same thing

[11:01] <jdaggett> fantasai: might need to add more to deal with tables and floats

[11:01] <fantasai> s/more/more concepts/

[11:01] <fantasai> s/with/with both/

[11:01] <jdaggett> bert: i could try rewriting this in terms of preferred intrinsic sizes defined in 2.1

[11:02] <jdaggett> fantasai: better to file comments on the sizing spec

[11:02] <jdaggett> fantasai: need to understand what the sizing spec is trying to solve

[11:02] <jdaggett> bert: not sure that this fits the bill

[11:03] <fantasai> fantasai: Might need to have separate concept of preferred size vs. max-content size for multicol elements

[11:03] <jdaggett> glazou: need to wrap up

[11:04] * kawabata_ has joined #css

[11:04] <jdaggett> stevez: we're arguing over whether there's something in the multi-col spec that talks about intrinsic width

[11:04] <jdaggett> fantasai: that's not a good idea

[11:04] <jdaggett> bert: should ask implementors whether that's okay

[11:05] <jdaggett> glazou: what's the plan?

[11:05] <jdaggett> fantasai: remove 3-10 in the multi-col alg

[11:05] <jdaggett> fantasai: then remove the concept of available width

[11:05] <jdaggett> fantasai: define in terms of used width

[11:06] <jdaggett> fantasai: then it becomes an issue on sizing

[11:06] <TabAtkins_> REMINDER: If you haven't replied to Molly's email for tonight's dinner, DO SO RIGHT NOW. (She wanted responses in before noon.)

[11:06] <TabAtkins_> (So she can make reservations.)

[11:07] <jdaggett> fantasai: accept or reject?

[11:07] <jdaggett> bert thinking

[11:07] <jdaggett> bert: we have to ask some people first

[11:08] <jdaggett> bert: not objecting but if we remove it's a pity

[11:08] <jdaggett> stevez proposing a and b points to add to multi-col

[11:09] <jdaggett> stevez: a is intrinsic size is not defined in multi-col

[11:09] <jdaggett> stevez: b is to add a note that it'll be defined in sizing (or some other non-normative place)

[11:09] * teoli has joined #css

[11:09] <jdaggett> stevez: this is editorial so we can update

[11:10] <jdaggett> bert: ok, so i'll propose new text

[11:10] <jdaggett> resolved on the plan outlined above

[11:11] <fantasai> RESOLVED: Remove lines 3-10 of pseudo-algorithm in multicol, remove concept of available width and have pseudo-algorithm depend on used width (whose calculation is defined elsewhere by container layout modules), state that intrinsic sizes of multi-col elements is undefined in this level, add note pointing to where they will be defined

[11:11] <jdaggett> <br type=������>

[11:12] <fantasai> ACTION Bert: Propose text for the resolution above

[11:12] * trackbot is creating a new ACTION.

[11:12] * RRSAgent records action 2

[11:12] <trackbot> Created ACTION-539 - Propose text for the resolution above [on Bert Bos - due 2013-02-13].

[11:13] <dbaron> Bert: I'm not sure who'd do the actual editing, but H��kon has generally asked me to write the text for this section.

[11:14] * nvdbleek has joined #css

[11:14] * Rossen Quit (Ping timeout: 60 seconds)

[11:15] * smfr Quit (smfr)

[11:22] * plinss is now known as plinss_away

[11:24] * plinss_away is now known as plinss

[11:40] * smfr has joined #css

[11:40] * abucur Quit (Client closed connection)

[11:41] * florian has joined #css

[11:41] * TabAtkins_ Quit (Ping timeout: 60 seconds)

[11:41] <glazou> http://www.pasticheme.com/menu/default.cfm?slide=menu

[11:45] * smfr Quit (smfr)

[11:55] * jarek Quit (jarek)

[11:57] * nvdbleek Quit ("Leaving.")

[11:57] * nvdbleek has joined #css

[11:59] * isherman-book Quit (Client closed connection)

[12:04] * isherman-book has joined #css

[12:14] * nvdbleek Quit ("Leaving.")

[12:18] * smfr has joined #css

[12:18] * cabanier has joined #css

[12:24] <tantek> Scribenick tantek

[12:24] <tantek> smfr: issue summary?

[12:25] <plinss> http://lists.w3.org/Archives/Public/www-style/2013Jan/0089.html

[12:25] <fantasai> http://www.w3.org/mid/AFDF40EF-A5C9-45B0-8F74-082A461939FF@adobe.com

[12:25] <tantek> smfr goes to the whiteboard

[12:26] <tantek> smfr draws boxes on the whiteboard

[12:27] <tantek> smfr: you've got a block that's split across multicols or pages

[12:27] <tantek> fantasai: we resolved that the fragmentation occurs before ...

[12:27] <tantek> szilles: the middle one is resolved out

[12:28] <tantek> (scribenote: need image to reference)

[12:28] <tantek> szilles: as a general principles, daniel, alan, and I were talking about this, daniel proposed general principles, any property that applies to something that is fragmented, applies to the fragments.

[12:30] <tantek> szilles: ��� applies individually to the fragments, in other words I treat each fragment as if it were an independent element.

[12:31] <tantek> (photos taken of redrawn whiteboard)

[12:31] <tantek> daniel: points to whiteboard, explains rotation, origin

[12:32] <tantek> szilles: if I have two fragments and I'm going to rotate them both around the same logical point, I have to translate that same point to the second region. or alternatively do I take the first fragment rotate relative to the point in its container, and take the second one and rotate it relative to it.

[12:32] <tantek> szilles: where is the rotation point? (is the question) It ought to be relative to each fragment.

[12:32] <tantek> szilles: because that's going to guarantee its going to be on the page, or might be

[12:32] <tantek> dbaron: another principle

[12:33] <tantek> dbaron: when authors are designing a page, and not thinking about printing, users are still going to want to print that page and want to come out pretty much as it looked on screen

[12:33] <tantek> dbaron: and having the transform origin be different breaks that

[12:33] <tantek> fantasai: we are already screwed on that point...

[12:33] <stearns> having the fragmentation breaks that

[12:33] <tantek> daniel: explains options on the whiteboard

[12:34] <tantek> dbaron, simon, daniel discuss / question diagram

[12:34] <tantek> smfr,szilles joins discussion of whiteboard

[12:35] <tantek> fantasai: both of the bottom ones (of the 6 on the whiteboard) are going to give you bad results

[12:35] <tantek> smfr: I disagree

[12:35] <tantek> daniel: I'm not sure

[12:35] <tantek> fantasai: I'll show you

[12:35] <tantek> dbaron: the bottom two

[12:35] <tantek> szilles: consider a 180deg rotation

[12:35] <dbaron> s/bottom ones (of the 6 on the whiteboard)/bottom two (all the ones on the whiteboard)/

[12:36] <dbaron> fantasai: Closest thing to expected result for the user is a graphical slice rather than doing fragmentation.

[12:36] <tantek> fantasai: you don't actually do fragmentation on the box, you first rotate it and then ...

[12:36] <tantek> daniel: can we do better? (in response to szilles)

[12:36] <tantek> szilles: you can always say break-within:avoid

[12:37] <tantek> szilles: we should do something easy to do that for small rotations will probably be ok

[12:37] <tantek> szilles: and for big rotations, you're going to need to avoid the break

[12:37] <tantek> daniel: rotate before and slicing afterwards is this (middle)

[12:37] <tantek> rossen: I'm in favor of the top one! (exits room)

[12:37] <tantek> daniel, fantasai, smfr continue discussing whiteboard

[12:37] * smfr Quit (smfr)

[12:37] * stearns likes Rossen's strategy

[12:38] <tantek> plinss, we're talking about a box ...

[12:38] <tantek> szilles: it's fragmented in any case

[12:39] <tantek> plinss: how do you get the upper right hand result?

[12:39] <tantek> fantasai: you lay it out as if in contiguous media, you do the transformation, and then you just slice it

[12:39] <tantek> smfr: the bottom you've actually done fragmentations...

[12:39] <tantek> szilles: the top you haven't

[12:39] <tantek> szilles: I can think of no one who likes slicing images. no one.

[12:39] <tantek> smfr: even if the content has a forced break?

[12:40] <tantek> szilles: if it has a forced break, then you're going to apply the transform to the two pieces independently

[12:40] <stearns> slicing after transform is fine if you're avoiding the break. I want to know what happens when there is a break (intentional or not)

[12:40] <tantek> szilles: e.g. I have text, div, with transform on it, break in the middle, that forces 2 paragraphs

[12:40] <tantek> szilles: the transform is on the container

[12:40] <tantek> plinss: another complication

[12:41] <tantek> plinss: ��� what happens in the next paragraph

[12:41] * smfr has joined #css

[12:41] <tantek> dbaron: so you do the layout with fragmentation but you don't show any of it

[12:41] <tantek> fantasai: but treat transformed element as an image

[12:42] <tantek> dbaron: you lay out the transformed element as if it was not fragmented and then don't draw it

[12:42] <tantek> dbaron: then you draw it like an image (?)

[12:42] <tantek> daniel: and it doesn't change the position of the following elements

[12:42] <tantek> fantasai: ��� if you break inside it you do graphical slicing on it

[12:42] <tantek> fantasai: if you lay out while transforming you might make it taller

[12:43] <tantek> fantasai: ��� the document as a whole gets fragmented ...

[12:43] <tantek> szilles: transformation is not supposed to ...

[12:43] <tantek> smfr: high level issue, you do layout before transforms

[12:43] <tantek> smfr: transforms are more of a graphical effect you do later

[12:43] <tantek> smfr: you have to break first

[12:43] <tantek> plinss: explains an order of operations

[12:43] * Ms2ger Quit ("nn")

[12:44] <tantek> fantasai: if a trivial transform shifts things around ...

[12:44] <tantek> dbaron: smfr is right that this is not trivial and possibly not reasonable to implement

[12:44] <tantek> szilles: the user is not going to like the results

[12:44] <tantek> szilles: because the text is unreadable

[12:44] <tantek> daniel: what's the other option

[12:44] <tantek> szilles: any option is fine because the user can always do avoid pagebreak to keep whatever he wants to stay

[12:45] <tantek> szilles: but I think this on is particularly bad

[12:45] <tantek> szilles: I prefer applying the transforms to the two fragments separately

[12:45] <tantek> szilles: doesn't change layout, and most of the types of transforms are the kind you just show

[12:45] <tantek> szilles: like a slight inclination

[12:45] <tantek> szilles: it's going to be hard to distinguish the effects between keeping an origin and specifying separate origins

[12:46] <tantek> daniel: another issue: repeat origin makes the first fragment visible in the first page, but out of the page in the second one

[12:46] <tantek> szilles: if you do a 180deg rotation, both disappear

[12:46] <tantek> daniel: you can have a case where one is visible, and the other is lost above the second page

[12:47] <tantek> plinss: if the second piece gets cut off the second page then it gets drawn on the first page

[12:47] <tantek> fantasai: that's what the spec currently says

[12:47] <tantek> daniel: that's not workable

[12:47] <dbaron> plinss: Transform the fragments individually, and then slice the transformed results (potentially putting them on another page)

[12:47] <tantek> daniel: you two different rotations of two different objects

[12:47] <tantek> (thanks dbaron)

[12:48] <tantek> (I can't tell if my minutes are making any sense)

[12:48] <tantek> szilles: is there a use case for wanting to make this work across a fragmentation?

[12:48] <tantek> daniel: I thought of an example, given by steve, regions polyfill, flow of text, and second one was rotated like that.

[12:48] <tantek> daniel: and your whole document is like that. a flow of text, and a gutter that is rotated in 3D.

[12:48] <tantek> smfr: in that case the container was transformed

[12:49] <tantek> szilles: well the contents flow into the container and the container is rotated

[12:49] <tantek> szilles: it's not the contents that's rotated, it's the container

[12:49] <tantek> szilles: if you don't pick the right point to rotate around, yes you can screw up

[12:49] <tantek> smfr: but in that case you can still do all the transforms before breaking

[12:49] <tantek> szilles: but this example is worse

[12:49] <tantek> smfr: with transforms you can always move things off screen

[12:50] <tantek> daniel: we have a number of proposals here

[12:50] <tantek> daniel: what is the best in terms of user expectations and implementability

[12:50] <tantek> szilles: you won't succeed with user expectations

[12:51] <tantek> daniel: I'm trying to minimize problems

[12:51] <dbaron> smfr's whiteboard drawing http://lists.w3.org/Archives/Public/www-archive/2013Feb/0010.html

[12:51] <tantek> szilles: so this is the bouton(?) principle

[12:51] <dbaron> s/bouton(?)/Bhutan/

[12:51] <tantek> daniel: ideal solution is not possible, so let's do the best we have

[12:51] <tantek> simon: the container itself is fragmented ...

[12:51] * teoli Quit (Ping timeout: 60 seconds)

[12:51] <tantek> simon: each fragment as its own transform origin

[12:51] <tantek> szilles: that's what I was arguing for also

[12:52] <tantek> daniel: we needed to list everything

[12:52] <tantek> szilles: that does destroy the effect the user was trying to achieve (as david pointed out)

[12:52] <tantek> daniel: we are back to the original proposal I made to steve and alan.

[12:52] <tantek> daniel: does it make sense?

[12:52] <tantek> smfr: transform the fragments independently

[12:52] <tantek> daniel: each fragment is transformed relative to the container

[12:53] <tantek> smfr: I would like a solution where layout and breaking happens first, and transformation happens later in a graphical layer

[12:53] <dbaron> daniel: transform each fragment individually, with the origin relative to the fragment

[12:53] <tantek> daniel: if you have 0,0 it is the top left corner of each fragment

[12:53] <tantek> smfr: the transform spec says origin is relative to the border box - do we have a good definition of that for fragments?

[12:53] <SimonSapin> http://www.w3.org/TR/CSS21/box.html#box-dimensions

[12:53] <dbaron> fantasai: the border box of the fragment is well-defined

[12:54] <tantek> smfr: the border box of a fragment is well defined

[12:54] <tantek> fantasai: zero width, controls for it to be non-zero

[12:54] <tantek> fantasai: this is the simplest thing to implement

[12:55] <tantek> szilles: simplest thing for the user to understand and control

[12:55] <tantek> daniel: so ok...

[12:55] <tantek> szilles: since transforms don't affect layout, they're dangerous to use

[12:55] <tantek> daniel: transform is applied to each fragment independently

[12:55] <tantek> (meme discussions)

[12:55] <fantasai> "If you print your transforms, you're gonna have a bad time."

[12:55] <tantek> daniel: we can forge a test case

[12:56] <tantek> simon: we need a test where content can overflow the page

[12:56] <fantasai> hober, if you make that, I will put it in the spec

[12:56] <tantek> plinss: controls to turn on slicing

[12:56] <tantek> simon: if you decide pages are supposed to be above each other, what happens when you overflow to the side

[12:56] <tantek> RESOLVED: transformation is applied independently to each fragment.

[12:57] <tantek> szilles: the coordinate system of the transform is defined relative to each fragment

[12:57] * hober fantasai: what do you want me to make?

[12:57] <tantek> simon: yes, but you could imagine border boxes bounding box of all fragments...

[12:57] <glazou> http://lockerz.com/s/281826419

[12:57] <tantek> szilles: ��� it's own coordinate system

[12:58] <tantek> smfr: transforms act as positioning ancestors

[12:58] <tantek> smfr: you can put position absolute inside something transformed, the absolute offset is relative to the transformed ancestor

[12:58] <tantek> smfr: what happens when it fragments

[12:58] <tantek> szilles: this is the problem with pagination in the first place

[12:58] <tantek> szilles: because it says that you reset to the page for its position

[12:59] <tantek> smfr: for fixed?

[12:59] * fantasai wonders if we need a transform-break property in the future....

[12:59] <tantek> smfr: if you have a position absolute that has descendants

[12:59] <tantek> smfr: a what happens on second page

[12:59] <tantek> bert: the ones that occur exactly at the point where the fragment breaks, do they occur on the first or second page

[12:59] <tantek> szilles: similar to a problem with floats and page breaks

[13:00] <tantek> szilles: isn't it the case that with a relatively positioned thing is relative to the fragment that it's in?

[13:00] * fantasai hober, nm, can't put copyrighted pics in the specs :/

[13:00] <tantek> smfr: if it has relative position -10px up

[13:00] <tantek> smfr: does it show up on the previous page? or just disappear?

[13:00] <tantek> szilles: disappear

[13:01] <tantek> szilles: trying to consistently apply the rule that the fragments are relatively independent things, so you treat them separately, rather than trying to figure out what would you have done if they were not fragments

[13:02] <tantek> ...

[13:02] <tantek> daniel: let's move back to second simon's issue about sizing

[13:03] <tantek> fantasai: I think the definition in box should be a guiding principle for us

[13:03] <SimonSapin> http://dev.w3.org/csswg/css3-box/#intrinsic

[13:03] <SimonSapin> http://dev.w3.org/csswg/css3-sizing/

[13:03] <tantek> fantasai: but we should be defining specific to each layout module exactly how to fulfill this in ways

[13:03] <tantek> fantasai: that accommodate ...

[13:03] <tantek> bert: I wonder if that's possible

[13:03] <fantasai> s/.../practical considerations/

[13:03] <SimonSapin> SimonSapin: we have two conflicting definitions of max-content and min-content

[13:04] <SimonSapin> SimonSapin: what���s the plan?

[13:04] <tantek> bert: you want to take into account properties like hyphenation, widows and orphans

[13:04] <SimonSapin> (earlier)

[13:04] <tantek> bert: can become quite handy

[13:04] <tantek> s/handy/ difficult

[13:04] <tantek> bert: due to lack of resources, may have to fallback to something simpler

[13:04] <tantek> bert: when you have the possibility

[13:04] <tantek> ...

[13:05] <tantek> dbaron: I think box is defining the goal in too much detail. overemphasizing the concept of overflow.

[13:05] <tantek> dbaron: when we implemented hyphenation we chose to NOT affect the min intrinsic width

[13:05] <tantek> dbaron: we might then choose to hyphenate some things or not

[13:05] * glenn Quit (Client closed connection)

[13:05] <tantek> bert: but if someone turns hyphenation on, don't they want it to change?

[13:05] <tantek> dbaron: not necessarily

[13:05] <tantek> bert: very narrow column with long words in it

[13:06] <tantek> bert: e.g. two columns rather than one

[13:06] <tantek> dbaron: doing the computation for hyphenation is quite expensive

[13:06] <tantek> dbaron: you're going to have to do multiple runs of text measurements over the same string, because of kerning, ligatures etc. due to where you might hyphenate

[13:07] <tantek> dbaron: we need to get used to the idea that we're defining these things in the definitions of properties, and not just trying to do this overarching thing doesn't quite work right.

[13:08] <tantek> tantek: agreed with dbaron, prefer specifying in properties instead of overarching areas

[13:08] <tantek> bert: we want people to compete on doing things the best possible way

[13:08] <tantek> bert: that's a general principle we want to apply to table and grid layout

[13:08] <tantek> bert: try to make it as compact as possible, but limit to reasonable time or hardware

[13:08] <tantek> bert: or if you animate it

[13:09] <tantek> bert: if you have some time to layout a grid, then please try to find line breaks that make things as compact as possible

[13:09] <tantek> bert: I don't want unsightly gaps

[13:09] <tantek> bert: I want a way to make tables that actually look good

[13:09] <tantek> bert: at same time, I don't want to force the optimal, but I want to make it possible to do the optimal

[13:09] <tantek> bert: CSS should be able to do that

[13:09] <tantek> bert: e.g. with electronic books and such

[13:11] <tantek> bert: so if we say in the intrinsic sizing, here are some hints on approximating things, if you're in a hurry, that's fine. but if we say you must do it in this approximate way, I don't think that's good enough.

[13:11] <tantek> bert: measuring overflow is the best criterion for measuring optimal layout or not. maybe there are other things you can measure.

[13:11] <tantek> dbaron: there are all sorts of things like elements with width 110% that are always going to overflow

[13:12] <tantek> dbaron: the way we want to do things is build up intrinsic widths from leaves to their ancestors

[13:12] <tantek> dbaron: so an element with width 110% may or may not influence the intrinsic width of its ancestor, and that is what should affect its ancestor's intrinsic width, not the overflow of every possible descendant.

[13:12] * florian Quit (Ping timeout: 60 seconds)

[13:13] <tantek> bert: the way you use it is to minimize overflow, not look for 0

[13:13] <tantek> dbaron: it will always overflow out of its parent, but not necessarily its great grandparent

[13:13] <tantek> dbaron: but having to worry about that is too complicated and breaks the notion of a functional subtrees

[13:14] <tantek> bert: not summing the parts - not how it works

[13:14] <tantek> dbaron: it is how it works - interop across 4 implementations so we should document that

[13:14] <tantek> bert: it won't work well for grids and columns

[13:14] <tantek> dbaron: there are rules we can write for grids and columns to make it work well

[13:14] <tantek> szilles: I'm losing track

[13:15] <tantek> szilles: 1. you want a computationally efficient way to get a good enough answer

[13:15] <tantek> szilles: 2. and you want an option that's better than "good enough"

[13:15] <dbaron> s/1. you want/1. dbaron wants/

[13:15] <dbaron> s/and you want/and Bert wants/

[13:15] <tantek> szilles: OTOH I thought I heard this morning that I could define different rules for table cells than other circumstances.

[13:15] <tantek> (thanks dbaron)

[13:15] <tantek> szilles: I think the provision as written allows you to change the rules for table cells

[13:16] <tantek> szilles: I'm not arguing you want to, in principle you could special case table cells

[13:16] <tantek> dbaron: of course we have to special case table cells and intrinsic width of a table, and the way you deal with percentages is interesting

[13:16] <tantek> dbaron: I don't think we want to just say that's derived from a general principle, I think we have to write up what the rules are

[13:17] <tantek> bert: at some point I want a third table layout algorithm where you actually get what you want in a table

[13:17] <tantek> bert: I think we need something for things like regions

[13:17] <tantek> bert: it makes a difference how much you put in one region vs. the second region

[13:18] <tantek> bert: because of the affect it has on other regions, same size, or fit on the page, or hyphenation possibility in one case and not another.

[13:18] <tantek> bert: those are local things that have a very global or much higher level than a single element effect

[13:18] <tantek> szilles: I think it's reasonably clear.

[13:19] <tantek> szilles: the piece I don't understand is

[13:19] <tantek> szilles: I agree with what david just said

[13:19] <tantek> szilles: document what's interop

[13:19] * isherman-book Quit ("Leaving.")

[13:19] * smfr Quit (Client closed connection)

[13:19] * smfr has joined #css

[13:19] <tantek> szilles: that doesn't handle bert's piece where I want to allow people to do better if they can and not be in violation of the spec

[13:19] <tantek> szilles: bert's definition was intended to say what he thought what better meant

[13:20] <tantek> szilles: david points out that doesn't help the reader of the spec because it leaves too many unanswered variables to get a useful initial implementation.

[13:20] <tantek> szilles: I'm looking at ways to specify the sizing thing in a way that you can say that implementations may do better than this and still be conformant

[13:20] <tantek> szilles: OTOH people complain when two implementations don't break lines in exactly the same place

[13:21] <tantek> szilles: everytime we don't specify exactly what the answer is someone is unhappy

[13:21] <tantek> glenn: specify an open source tool open source font will make the same line breaks

[13:21] <tantek> szilles: I can think of lots of reasons to not go there - separate issue - not related to sizing

[13:21] <tantek> szilles: david, do you have a problem with doing better?

[13:22] <tantek> dbaron: there's a large amount of content out there that depends on particular behavior

[13:22] <tantek> szilles: I would prefer that the leaving open be in the sizing module but I don't know how to say it

[13:22] <tantek> dbaron: it sounds like the path we're going towards is, Bert want CSS as a whole to allow implementations to do better

[13:23] <tantek> dbaron: I would like a specification for how CSS is used on the web that specifies what you have to do to be compatible with what's on the web

[13:23] <tantek> dbaron: if those have to be two different specifications that would be unfortunate

[13:23] <tantek> simon: bert is right that the sizing spec would close the possibility of doing better at some point

[13:23] <tantek> simon: but maybe the spec can include that

[13:24] <tantek> simon: similar to a recent proposal of balancing text in line breaks

[13:24] <tantek> simon: what you do normally, and balancing which is more expensive

[13:24] <tantek> bert: difficult in how you specify

[13:24] <tantek> bert: some way to say please do this optimal

[13:24] <tantek> bert: or 50% of

[13:24] <tantek> bert: depends on algorithm and parameters

[13:24] <tantek> simon: maybe resolve by documenting how web works today

[13:24] <tantek> simon: and have a way to do an optimal switch

[13:25] <tantek> bert: already differences today

[13:25] <tantek> bert: some impls do better line breaks than others, some do better page breaks

[13:25] <tantek> glenn: an opt-in approach would be for standard

[13:25] <tantek> fantasai: no that's the default for browser

[13:25] <tantek> s

[13:25] <tantek> glenn: no it doesn't have to be

[13:25] <tantek> fantasai: if it's going to break the web you're going to need to

[13:25] <tantek> glenn: there is no breaking the web when it comes to sizing

[13:26] <tantek> fantasai: there are somethings that no matter how weird crazy they are, you have to implement them

[13:26] <tantek> simon: for me as an implementer it is important that this is documented

[13:26] <dbaron> s/an opt-in approach would be for standard/if you want an opt-in approach, it should be to opt-in to choosing the browser standard/

[13:26] <tantek> szilles: I like simon's suggestion that we define a particular algorithm, and we can add a property later for the author to specify that he wants a different criteria to be used for sizing

[13:27] <tantek> szilles: it would be left up to defining whatever criteria would change for the new property/value

[13:27] <tantek> szilles: but it would at least give us a baseline for today

[13:27] <tantek> bert: but problem is with the old content

[13:27] <tantek> bert: old content doesn't done have hyphenation

[13:27] <tantek> bert: optimal should be turned on by default

[13:28] <dbaron> bert: hyphenation should have been on by default

[13:28] <tantek> john: problem is with content suddenly.. if you suddenly upgrade the browser and the page layout changes

[13:28] <tantek> john: issue for microsoft products

[13:28] <tantek> smfr: issue for us too

[13:28] <tantek> smfr: but we tell people cannot depend on pixel-same rendering from release to release

[13:29] <tantek> simon: bert, use your user style sheet

[13:29] <dbaron> s/sheet/sheet to turn on hyphenation/

[13:29] <tantek> simon: we don't have to change the definition of in CSS initial values

[13:29] <tantek> (dbaron, I think simon meant in general, beyond hyphenation for example)

[13:29] <tantek> szilles: for hyphenation you really need to say letter counts and

[13:30] <SimonSapin> yes, hyphenation was just an example

[13:30] <tantek> szilles: there are ...

[13:30] <tantek> szilles: I prefer the opt-in approach

[13:30] <tantek> plinss: you could also do user vs. ua style sheet

[13:30] <tantek> fantasai: I think bert and I need to sit down and shift texts into one place

[13:30] <tantek> fantasai: here is what you can potentially do better, and here is the baseline of what browsers should do

[13:31] <tantek> fantasai: and yes there will be a gap where behaviors could be better

[13:31] <tantek> fantasai: the algorithm will be normative, that will be the baseline

[13:31] <tantek> simon: how can you do better then?

[13:31] <tantek> fantasai: because you say so in the spec that you can do better

[13:31] <tantek> fantasai: e.g. in multicol the spec already notes possible need to do many many passes to do better measurement. we already say this will give you an approximation.

[13:32] <tantek> fantasai: if you can do better, you may do better

[13:33] <dbaron> fantasai: I think action should be for me and bert to incorporate the text from box into sizing and ...

[13:33] <dbaron> tantek: I think there are 2 principles worth documenting (1) ... interop ... (2) we want CSS to allow as high fidelity layout as possible.

[13:33] <dbaron> tantek: I'd like to action parties to write these up (e.g., on wiki) so we can reference them

[13:34] <fantasai> s#interop#interop/deterministic layout#

[13:34] <SimonSapin> +1 for having the rationales somewhere, as Tantek says

[13:35] <tantek> ACTION: Bert, write-up CSS design principle of defining CSS features to allow implementations to potentially do as high fidelity layout / presentation as possible.

[13:35] * trackbot is creating a new ACTION.

[13:35] <trackbot> Error finding 'Bert,'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.

[13:35] * RRSAgent records action 3

[13:35] <tantek> ACTION: Bert write-up CSS design principle of defining CSS features to allow implementations to potentially do as high fidelity layout / presentation as possible.

[13:35] * trackbot is creating a new ACTION.

[13:35] * RRSAgent records action 4

[13:35] <trackbot> Created ACTION-540 - Write-up CSS design principle of defining CSS features to allow implementations to potentially do as high fidelity layout / presentation as possible. [on Bert Bos - due 2013-02-13].

[13:36] <tantek> ACTION: fantasai write-up CSS design principle of defining baseline CSS features with deterministic algorithm(s) that reflect interoperable implementation behaviors and compatibility with web content

[13:36] * trackbot is creating a new ACTION.

[13:36] * RRSAgent records action 5

[13:36] <trackbot> Created ACTION-541 - Write-up CSS design principle of defining baseline CSS features with deterministic algorithm(s) that reflect interoperable implementation behaviors and compatibility with web content [on Elika Etemad - due 2013-02-13].

[13:37] <tantek> ACTION: Bert work with Elika remove material on sizing in Box module and incorporate equivalent material into Sizing module.

[13:37] * trackbot is creating a new ACTION.

[13:37] * RRSAgent records action 6

[13:37] <trackbot> Created ACTION-542 - Work with Elika remove material on sizing in Box module and incorporate equivalent material into Sizing module. [on Bert Bos - due 2013-02-13].

[13:38] <tantek> ...

[13:38] <tantek> plins: overflow

[13:38] <dbaron> dbaron: postpone to teleconferences

[13:38] <tantek> dbaron: postpone to teleconferences

[13:38] <tantek> john: I have a minor issue

[13:38] <dbaron> Topic: css3-text

[13:39] * cabanier Quit ("Leaving.")

[13:40] <jdaggett> http://www.w3.org/Style/CSS/Tracker/products/10

[13:40] * isherman-book has joined #css

[13:40] <dbaron> ScribeNick: dbaron

[13:40] <tantek> <br type="stretch">

[13:40] * dbaron thinks this would be better written in MathML

[13:49] * plinss is now known as plinss_away

[13:56] <dbaron> </br>

[13:56] <jdaggett> http://www.w3.org/Style/CSS/Tracker/products/10

[13:56] * plinss_away is now known as plinss

[13:56] <dbaron> jdaggett: This is list of issues on css3-text. Koji and Elika want to push text to LC.

[13:57] <dbaron> jdaggett: I think this spec needs to be restructured; I think we need to drop a lot of things, because for one reason or another, they're underspecified, experiments, or not clear.

[13:57] <dbaron> jdaggett: I think some of these issues are more than going in and tweaking the wording; I think we should defer some of them all together.

[13:57] <jdaggett> http://www.w3.org/Style/CSS/Tracker/issues/291

[13:57] <dbaron> jdaggett: I think we can start with a few of these that are relatively simple.

[13:57] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012Dec/0052.html

[13:58] <jdaggett> http://dev.w3.org/csswg/css3-text/#line-break

[13:58] * glenn has joined #css

[13:58] <dbaron> jdaggett: so the text module has 'line-break' property followed by 'word-break' property

[13:58] <dbaron> jdaggett: These are to some extent governing similar things.

[13:59] <dbaron> jdaggett: These are somewhat based on IE properties, though IE has sort of deprecated... is it 'line-break'? Documentation says word-break equivalent to line-break?

[13:59] <dbaron> fantasai: That seems very unlikely; not the same thing.

[13:59] <dbaron> jdaggett: Both about where you want to have a soft wrap opportunity.

[13:59] <dbaron> jdaggett: 'line-break' is trying to give you general categories; 'word-break' is giving you escape hatches.

[13:59] <dbaron> fantasai: the other way around

[13:59] <dbaron> jdaggett: 'line-break' is giving general categories

[13:59] <dbaron> jdaggett: line-break has loose, normal, strict -- general categories

[14:00] * isherman-book Quit (Ping timeout: 60 seconds)

[14:00] <dbaron> fantasai: word-break is supposed to apply to entire text. General policy, controls breaking between letters.

[14:00] <dbaron> fantasai: line-break is supposed to control line breaking around punctuation. One exception for small kana.

[14:00] <dbaron> jdaggett: There's an interaction between these properties; overlapping, I'd say.

[14:00] <dbaron> fantasai: They overlap in that they both control breaking around small kana, but that's the only overlap.

[14:01] <dbaron> jdaggett: So let me ask one question: why can't these be unified?

[14:01] <dbaron> fantasai: I tried; people want to vary them independently.

[14:01] <dbaron> jdaggett: One property with keywords for one or both?

[14:01] <dbaron> jdaggett: word-break is unfortunate as a property name; really about line-breaking

[14:01] <dbaron> glenn: implementations can be orthogonal to a certain degree, maybe completely

[14:01] <SimonSapin> word-break sounds like hyphenation

[14:01] <dbaron> fantasai: property names are historical; not much I can do, and I didn't have anything substantially better

[14:01] <dbaron> jdaggett: both apply to a similar category of things; would be better as one property

[14:02] <dbaron> jdaggett: unfortunately glenn is now implementing this for WebKit, so we're not just talking about the IE implementation

[14:02] <dbaron> jdaggett: only IE that has implemented these properties in the past

[14:02] <dbaron> koji: don't know about Firefox

[14:02] <dbaron> fantasai: working on, but don't have one?

[14:02] <dbaron> jdaggett: so effectively properties only supported by one browser

[14:02] <dbaron> glenn: I know word-break partially supported by WebKit, and there's a patch for line-break.

[14:02] <dbaron> jdaggett: But you're working on that.

[14:03] <dbaron> Koji: glenn working on line-break; word-break is in Safari 3.0

[14:03] <dbaron> glenn: I know that when I implemented line-break, including a large suite of tests, I did not have to take word-break into account.

[14:03] <dbaron> glenn: so it seemed orthogonal from a semantic perspectavi

[14:04] <dbaron> jdaggett: because 'word-break' only applies between letter breaking opportunities?

[14:04] <dbaron> glenn: word-break said that you can consider all possible soft breaks within a space-separated segment or not

[14:04] <dbaron> glenn: then once you consider soft opportunities then at athat point the line-break property semantics came into play by defining what were soft-break opportunties and what were not

[14:04] <dbaron> glenn: ... in certain contexts, contexts being certain languages

[14:04] <dbaron> glenn: the semantics of the two properties were layered on each other so orthogonal to implement

[14:05] <dbaron> jdaggett: not sure how that's possible given that break-all and keep-all... text "except where forbidden by the line-break property" and "including those explicitly allowed by line-break"

[14:05] <dbaron> glenn: if it said keep-all, then you wouldn't consider any word-breaking in cjk

[14:05] <dbaron> glenn: so none of the soft breaks would apply

[14:05] <dbaron> glenn: if it said break-all, then all would apply

[14:05] <dbaron> glenn: if normal, then it allowed line breaking within words

[14:05] <dbaron> glenn: I was dealing with normal and break-all

[14:06] <dbaron> fantasai: if you do break-all and line-break: strict, then you're allowed to break between any two characters, except can't break before small kana

[14:06] <dbaron> fantasai: I thought this seemed weird, but people do that.

[14:06] <dbaron> glenn: I was just reading the definition of -ms-word-break: for break-all, behaves as normal for cjk text, but allows line-break to break normally for non-cjk text.

[14:06] <dbaron> glenn: so it excluded applicability for cjk text

[14:06] <dbaron> fantasai: because they break normally

[14:07] <dbaron> steve: cjk has kumimoji rules...

[14:07] <dbaron> stevez: sorry, kinsouk

[14:07] <dbaron> stevez: sorry, kinsoku

[14:07] <dbaron> smfr: are these 2 properties consulted at different times in the linebreaking algorithm, or do they all contribute to the possible breaks after which you decide where to break?

[14:07] <dbaron> jdaggett: I'm not sure I believe glenn's assertion

[14:08] <dbaron> jdaggett: where you said first deal with word-break and then deal with line-break

[14:08] <dbaron> jdaggett: seems like with keep-all specified, you still have to consider what line-break is

[14:08] <dbaron> stevez: common use in cjk seems to be to allow western words to be arbitrarily split rather than kept together

[14:08] <dbaron> stevez: no idea what this would mean in Arabic

[14:09] <dbaron> glenn: IE documentation also says keep-all is suitable for non-cjk text including small amounts of cjk, break-all suitable for cjk text including small amounts of non-cjk text

[14:09] * fantasai notes it's defined for Arabic in css3-text

[14:09] <dbaron> jdaggett: so the question is: will this break / be different from the IE implementation?

[14:09] <dbaron> glenn: The IE documentation claims that the unprefixed property is deprecated

[14:09] <dbaron> fantasai: ... in favor of the prefixed one

[14:10] <dbaron> fantasai: probably because there was a previous revisiion of css3-text where I tried to combine them into one thing

[14:10] <dbaron> glenn: I have to admit, in testing of my patch, i did not create a combinatorial test of line-break and word-break; I just assumed word-break was normal and tested line-berak featured

[14:10] <dbaron> jdaggett: has it landed?

[14:10] <dbaron> glenn: landed, but pulled out for performance regression, not functionality

[14:11] <dbaron> jdaggett: would we in the near future have something to test with?

[14:11] <dbaron> glenn: I'll be resubmitting in the next few weeks

[14:11] <dbaron> jdaggett: important to figure out if there are differences in the implementation and if those differences are important

[14:11] <dbaron> glenn: that's reasonable

[14:11] <dbaron> stevez: I'm more concerned that this is aimed at western text in a cjk setting

[14:11] <dbaron> fantasai: depends on the value

[14:12] <dbaron> stevez: It's still western in cjk, not south asian, not SE asian, not middle-eastern, and it is ill-defined for those cases, all of which have nuances

[14:12] <dbaron> fantasai: It's defined, it's just not useful

[14:12] <dbaron> stevez: it defines letters; for S asian, which work in terms of syllables rather than letters, it's ill-defined

[14:12] <dbaron> jdaggett: what they're saying is it's not useful

[14:12] <dbaron> jdaggett: is there something here that would be useful for those contexts?

[14:13] <dbaron> jdaggett: if this is unneeded ,then it doesn't matter so much, but if there's something here that's needed ,then that needs to go in the spec

[14:13] <dbaron> stevez: It just seems to me that letters are the wrong thing to define this in terms of.

[14:13] <dbaron> fantasai: Letters are defined to be grapheme clusters in L* or N* categories

[14:13] <dbaron> stevez: but syllables are not grapheme clusters

[14:13] <dbaron> jdaggett: I think the question is much more about if this applies in contexts other than cjk.

[14:14] <dbaron> Koji: is the question about whether to merge these 2 into a single property?

[14:14] <dbaron> jdaggett: In response to what Steve is saying, that these seem to be western/cjk only...

[14:14] <dbaron> stevez: Once sentence in here that's impossible to satisfy: when scripts that are shaped are broken, required to be shaped as not broken... but there are required ligatures that you can't break

[14:14] <dbaron> glenn: [missed].

[14:15] <dbaron> glenn: example 4 shows 3 words with break opportunities between each connecting character (and non-connecting)

[14:15] <dbaron> stevez: I understand connecting/non-connecting, but ligatures are worse than that.

[14:15] <dbaron> glenn: I think ligatures are second order to connectedness

[14:15] <dbaron> [discussion of lam-alef]

[14:15] <dbaron> [scribe can't keep up]

[14:16] <dbaron> glenn: what this doesn't do is discern the distinction between breaking between glyphs vs. characters

[14:16] <dbaron> glenn: so if result of char->glyph mapping produced ligatures and then connecting glyphs, that's a little different than saying break at the characters that correspond to the output glyphs.

[14:16] <dbaron> glenn: that's not really defined here

[14:16] <dbaron> stevez: where are letters defined?

[14:16] * fantasai trying to remember what was the goal of this discussion, and fails

[14:17] <dbaron> jdaggett: "A letter for the purpose of this specification is a character belonging to ..."

[14:17] <dbaron> fantasai: characters are similarly redefined to be grapheme clusters

[14:17] <dbaron> jdaggett reads definition

[14:17] <dbaron> stevez: syllables are not grapheme clusters

[14:17] * heycam|away is now known as heycam

[14:17] <dbaron> fantasai: if you want to deal with breaking between syllables, we could add new values, but that's not a requirement anyone has given me

[14:18] <dbaron> jdaggett: One issue I have is about line-break: the text uses SHOULD language; I think that makes the entire behavior of this property a SHOULD behavior. I think UAs should be required...

[14:18] <dbaron> fantasai: would changing recommended to required help?

[14:18] <dbaron> glenn: in many CSS specs [missed]

[14:18] <dbaron> jdaggett: I think what Elika said would be sufficient.

[14:19] <dbaron> jdaggett: What I don't like is that it's using vague terms -- in the hands of an implementor, you'll get implementations that do different tgings.

[14:19] <dbaron> fantasai: what's vague?

[14:19] <dbaron> jdaggett: what's loose, normal, and strict, for non-cjk languages?

[14:19] <dbaron> glenn: it's clearly defined

[14:19] <dbaron> fantasai: It says "If the content language is C, J, or K..."

[14:20] <dbaron> fantasai: It says allow X, disallow Y, and if the content language is C J or K then also Z

[14:20] <dbaron> jdaggett: For a different language, are there different rules that are stricter or not stricted?

[14:20] <dbaron> er

[14:20] <dbaron> [discussion about which part of the spec they're reading]

[14:21] <dbaron> Koji: first bullet applies to all languages, second applies to C J and K

[14:21] <dbaron> jdaggett: c'mon, it's about Kana

[14:21] <dbaron> fantasai: Can you quote the part of the text you have a problem with?

[14:21] <dbaron> jdaggett: As defined, this says nothing about what is done for other languages

[14:21] <dbaron> fantasai: you do nothing

[14:22] <dbaron> [multiple discussions]

[14:22] <glenn> http://trac.webkit.org/wiki/LineBreakingCSS3Mapping

[14:22] <dbaron> glenn: Link to table derived from this spec, with precise definition covering all languages.

[14:22] <dbaron> glenn: if you look at the header of that table, you see ICU open/close parentheses, loose open/close parentheses

[14:23] <dbaron> glenn: That's the column for if it's not cjk, what does loose mean?

[14:23] <dbaron> glenn: - means "as otherwise defined by the default line breaking behavior"

[14:23] <dbaron> glenn: So there are some fallbacks to the default linebreaking behavior defined earlier in the spec

[14:23] <dbaron> glenn: so for any language you can determine which applies

[14:23] <dbaron> stevez: you created this table how?

[14:23] <dbaron> glenn: by interpreting the spec that fantasai wrote

[14:23] <dbaron> glenn: and factoring in the use of ICU and UAX14

[14:24] <dbaron> glenn: what I'm trying to say is that there's a definitive, unambigious answer about what normal, loose, and strict, mean for all languaes, from my reading of the spec

[14:24] <dbaron> jdaggett: (1) says RECOMMENDED

[14:24] <dbaron> fantasai: fixed now

[14:24] <dbaron> jdaggett: (2) not saying anything about other languages

[14:25] <dbaron> jdaggett: in the gestalt of the property, we've got 7 categories for line breaking... if I apply this to all languages is it really the case that loose and strict in this context should really never have a different meaning?

[14:25] <dbaron> fantasai: it's possible we might want to do that in the future

[14:25] <dbaron> fantasai: for this level there are no behavior differences for non-cjk text

[14:25] * cabanier has joined #css

[14:25] <dbaron> glenn: this does provide specific results for cjk

[14:25] <dbaron> fantasai: we've gotten no feedback for needs from other languages

[14:25] <dbaron> stevez: the table given does affect other languages

[14:26] <dbaron> stevez: loose sets before/after breaking on ellipsis, and doesn't for strict and normal

[14:26] <dbaron> stevez: ellipsis seems to me to be non-language-specific

[14:26] <dbaron> stevez: Is it only the ellipses that are in a cjk sequence, or all of them?

[14:26] <dbaron> fantasai: We don't say that it's for certain ones... it's for these characters, period.

[14:26] <dbaron> glenn: This table on ellipsis character refers to a specific codepoint, tied in to default behavior of ICU

[14:26] <dbaron> glenn: B/A mean break as permitted before or after

[14:27] <dbaron> glenn: I agree with jdaggett that recommended...

[14:27] <dbaron> fantasai: THat's done

[14:27] <fantasai> RELOAD THE PAGE

[14:27] <dbaron> glenn: if the user-agent implements this property then I think it's done

[14:27] <dbaron> Koji: RELOAD THE PAGE

[14:27] <dbaron> glenn: the fact that it doesn't define it for other languages I don't view as an issue; I agree with Elika

[14:28] <dbaron> glenn: If somebody comes forward and says that for Thai, we want, then fine...

[14:28] <dbaron> jdaggett: for breaks after prefixes, currency symbols, why not define it in terms of currency symbols rather than specific codepoints?

[14:28] <dbaron> fantasai: Could you file that as an issue?

[14:28] <fantasai> ISSUE: Why aren't all currency symbols included in line-break rules

[14:28] * trackbot is creating a new ISSUE.

[14:28] <trackbot> Created ISSUE-301 - Why aren't all currency symbols included in line-break rules; please complete additional details at <http://www.w3.org/Style/CSS/Tracker/issues/301/edit>.

[14:29] <dbaron> jdaggett: The original issue was about the confluence of the two properties.

[14:29] <dbaron> jdaggett: I think there was text added that clarified keep-all.

[14:30] <dbaron> fantasai: So I think we can move on.

[14:30] <dbaron> glenn: In order to address his comment about behavior for other languages, I think we should add a note...

[14:30] <dbaron> fantasai: There's one note, should we have two?

[14:30] <dbaron> jdaggett: There's a line saying "support for this property is optional..."; I think this should be removed.

[14:30] <fantasai> "Support for this property is optional. It is recommended for UAs that wish to support CJK typography and strongly recommended for UAs in the Japanese market. "

[14:30] <dbaron> glenn: I agree.

[14:31] <dbaron> glenn: Support for the property is optional in that there aren't conformance criteria

[14:31] <dbaron> fantasai: we do

[14:31] <dbaron> glenn: not in 2.1

[14:31] <dbaron> jdaggett: we shouldn't be talking about UAs specialized in a given market

[14:31] <dbaron> SteveZ: The person who disagrees is not in the room.

[14:31] <dbaron> (H��kon)

[14:32] <dbaron> SteveZ: Are you saying you don't want optional properties in...?

[14:32] <dbaron> jdaggett: the notion that it's optional is a redundant statement

[14:32] <dbaron> stevez: I don't think it's redundant at all.

[14:32] <dbaron> jdaggett: all browsers render japanese text

[14:32] <dbaron> fantasai: not all CSS implementations are browsers

[14:32] <dbaron> stevez: not all browsers are conformant

[14:32] <SimonSapin> http://weasyprint.org/docs/tutorial/#weasyprint-navigator

[14:33] <dbaron> stevez: this sentence is here so you can be conformant if you aren't supporting certain things

[14:33] <dbaron> jdaggett: there are a lot of properties in css that only apply in a certain context. We shouldn't be saying that if you're not involved in that context, it's optional.

[14:33] <dbaron> stevez: but it's not optional

[14:33] <dbaron> jdaggett: I don't think this is necessary, and we should remove it.

[14:33] <dbaron> stevez: Then we have to change the [forgot]

[14:34] <dbaron> steve: conformance to a module requires implementing all of the properties in the module correctly unless otherwise stated

[14:34] <dbaron> glenn: there's a section on partial implementations

[14:34] <fantasai> dbaron: The section on partial implementations what this WG insists that you do if you implement it partially. Implementing it partially doesn't mean you're conformant.

[14:35] <fantasai> dbaron: It means we recognize that implementations add features piece by piece, and states we want them to do it this way

[14:35] <dbaron> jdaggett: This is an unnecessary sentence; there are other properties in this spec equally cjk-dependent.

[14:35] <dbaron> jdaggett: We sholudn't be going through our specs and marking things optional...

[14:35] * smfr Quit (smfr)

[14:35] <dbaron> SteveZ: I personally don't care; I'd just rather not cycle back and end up in the same discussion.

[14:36] <dbaron> jdaggett: But I think H��kon was objecting to this property as a whole.

[14:36] <dbaron> SteveZ: I don't think he wanted to be required to do cjk support and vertical text support; I think his reason was largely concerned with implementing cjk.

[14:37] <dbaron> glenn: If you're asking for that particular sentence to be removed, is it safe to assume you also want to change the paragraph just before the bullets... "The precise set of rules in effect ... does recommend that" should also be removed, and the previous sentence for text wrapping should just end with a colon?

[14:37] <dbaron> glenn: you've asked to remove vague language like should and recommend

[14:37] <dbaron> jdaggett: without require, the entire property definition is left open

[14:37] <dbaron> glenn: do you want to remove that text?

[14:37] <dbaron> jdaggett: no

[14:37] <dbaron> glenn: that's inconsistent

[14:38] * dino has joined #css

[14:38] <dbaron> jdaggett: I'll raise issues on the mailing list and we can fight about this later.

[14:38] <dbaron> fantasai: Now we're deciding whether it's ok to have properties that are optional for conformance with the module.

[14:38] <dbaron> jdaggett: ... This whole module is about international text.

[14:38] <dbaron> stevez: Another way to meet what H��kon wants: note that says for implementations that do not deal with cjk text this property has no effect

[14:39] <dbaron> fantasai: not true; don't want to parse something you don't do something with

[14:39] <dbaron> fantasai: if the implementation doesn't support, it shouldn't parse or @supports

[14:39] <dbaron> stevez: in this case, support was to do nothing

[14:39] <dbaron> fantasai: support should never mean do nothing

[14:39] <dbaron> glenn: there are some specific semantics here in non-cjk text. It perscribes specific meaning to strict/normal/loose for certain non-cjk text.

[14:40] <dbaron> jdaggett: You're just saying that if the language is not cjk it applies. However, the characters are ones that are only used in Japanese text.

[14:40] <dbaron> jdaggett: except for ellipsis, maybe

[14:40] <dbaron> glenn: also hyphens

[14:40] <dbaron> glenn: U+2010, U+2013

[14:40] <dbaron> jdaggett: but that's under language-specific

[14:40] <dbaron> glenn: so only ones are ellipses, U+2025, U+2026

[14:40] <dbaron> jdaggett: if you're going to object, then we'll move it to the list and resolve it there

[14:41] <dbaron> jdaggett: it's a waste of time to talk about this; it's a non-important discussion

[14:41] <dbaron> jdaggett: I think we should remove the two sentences and go from there

[14:41] <dbaron> Koji: straw poll, and H��kon can object?

[14:41] <dbaron> jdaggett: can just ask if there are objections?

[14:41] <dbaron> Bert: is there nothing that can be done about the ellipses... whole property for just two characters?

[14:42] <dbaron> jdaggett: We're talking about the sentence

[14:42] <dbaron> glenn: yes, it would be nice if those 2 characters could be put in the cjk portion

[14:42] <dbaron> jdaggett: There aren't implementations that just wholly ignore languages

[14:42] <dbaron> fantasai: there used to be implementations that didn't support bidi at all

[14:42] <dbaron> jdaggett: they're partial implementations... let's get on with our life

[14:43] <dbaron> jdaggett: especially for a spec that's all about international text

[14:43] <dbaron> stevez: I agree in general that there shouldn't be optional properties; fairly meaningless in an interoperable world.

[14:43] <dbaron> stevez: If you're saying this particular one is bad, I don't think there's that much of a cas.

[14:43] <dbaron> s/cas/case/

[14:43] <dbaron> jdaggett: I propose we resolve on striking these sentences.

[14:44] <koji> jdaggett proposed to remove "Support for this property is optional. It is recommended for UAs that wish to support CJK typography and strongly recommended for UAs in the Japanese market"

[14:44] <fantasai> RESOLVED: Remove sentences about optionality of properties

[14:44] <dbaron> RESOLVED: Strike the two sentence "Support for this property is optional. It is recommended for UAs that wish to support CJK typography and strongly recommended for UAs in the Japanese market. "

[14:44] <dbaron> glenn: can I ask a followon?

[14:44] <dbaron> jdaggett: ok

[14:44] <SteveZ> s/sentence/sentences/

[14:45] <dbaron> glenn: prior to the bullets, just above that: "CSS distinguishes between three levels of strictness in the rules for text wrapping. The precise set of rules in effect for each level is up to the UA and should follow language conventions. However, this specification does recommend that: "

[14:46] <dbaron> glenn: I propose removing all but the first sentence of that paragraph and ending with a colon

[14:46] <dbaron> glenn: The use of "recommend" makes everything in the bullets optional

[14:46] <dbaron> fantasai: Is there a need to discuss this?

[14:46] <dbaron> glenn: I don't like recommend; I like to see requires

[14:46] <dbaron> fantasai: RELOAD

[14:47] <dbaron> glenn: ok, I'm fine with that

[14:47] <jdaggett> http://www.w3.org/Style/CSS/Tracker/issues/295

[14:47] <dbaron> jdaggett: If there aren't other issues on line-break, I'd like to talk about text-justify

[14:47] <dbaron> Bert: I had a question, just to verify...

[14:48] <dbaron> Bert: looking at the definition, letter refers to character; says characters have to have a Unicode category. But character is redefined as a cluster.

[14:48] <dbaron> fantasai: There's a definition; it's slightly complicated.

[14:48] <dbaron> jdaggett: So the text-justify property: one of the more important issues I've logged about the spec.

[14:48] <dbaron> jdaggett: I don't think we should move to last call with text-justify as specified

[14:48] <dbaron> jdaggett: see http://www.w3.org/Style/CSS/Tracker/issues/295

[14:48] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012Dec/0057.html

[14:49] <dbaron> fantasai: what we've figured out so far that distribute value is needed ;commonly opted into for cjk typography

[14:49] <dbaron> fantasai: an inter-ideopgraph is needed, since default does not allow justification of cjk, so people use it to opt in to cjk jsutification

[14:49] <dbaron> jdaggett: justification and line breaking are to some degree language dependent

[14:49] <dbaron> jdaggett: so why can't that be something that user agents simply do based on the language?

[14:49] <dbaron> jdaggett: http://dev.w3.org/csswg/css3-text/#text-justify

[14:50] <dbaron> jdaggett: shows values: none / inter-word / ... / kashida values in spec

[14:50] <dbaron> jdaggett: these are the categories

[14:50] <dbaron> jdaggett: I posted reactions that other people have had to this.

[14:50] <dbaron> jdaggett: I don't think this is the right way to specify modifications to the justification algorithm

[14:51] <dbaron> jdaggett: I think we should have a property more about the specific behavior of those things, and then abstract out across languages... e.g., in Thai, if you want to talk about different types of justification. Focus on what it's trying to do.

[14:51] * glenn Quit (Client closed connection)

[14:51] <dbaron> jdaggett: These came out of IE; if you look at the definition of these, it's vague, and not clear what they're doing.

[14:51] <dbaron> Koji: we made it clearer

[14:51] <dbaron> jdaggett: we've given a definition, but I'm not sure what the use case is

[14:52] <dbaron> jdaggett: e.g., for inter-cluster

[14:52] <dbaron> jdaggett: we discuss this at [???]. Led to action item for use cases, led to what's now in the spec. Look from author perspective. Why would author use this? If it's for Thai, why would an author choose this?

[14:52] <dbaron> fantasai: default behavior is for spaces, this distributes between thai clusters

[14:53] <dbaron> jdaggett: how is that different from distribute?

[14:53] <dbaron> fantasai: that expands latin characers

[14:53] <dbaron> fantasai: Definitely distinct from default behavior, you only turn it on in certain situations.

[14:53] <dbaron> fantasai: distribute says to justify between latin characters just as if they're cjk characters

[14:54] <dbaron> Koji: look at figure

[14:54] <dbaron> jdaggett: not clear whether space after [go] is a fullwidth space or ...

[14:54] <dbaron> fantasai: Can't show all differences between all the values without mixing all the scripts, and nobody does that in real text.

[14:55] <dbaron> fantasai: if you want us to go scan pictures of stuff, we can find pictures to scan

[14:55] <dbaron> jdaggett: these are defined in terms of breaking Unicode character space into sections, in a way that doesn't seem natural to a lot of people

[14:55] <dbaron> jdaggett: people like John Hudson who posted a detailed reponse that you didn't answer... "why are you breaking scrpts like this?"

[14:55] <dbaron> jdaggett: you're defining categories, set of scripts are defined way below... doesn't make sense to a lot of people ,which John Hudson was saying

[14:56] <dbaron> http://lists.w3.org/Archives/Public/www-style/2012Dec/0057.html

[14:56] <dbaron> jdaggett: The point I'm trying to make is what he says in the second quote ,starting with "Again, I come back to my previous point"; now I'm paraphrasing what he said.

[14:56] <dbaron> glenn: what is your issue on Thai?

[14:57] <dbaron> jdaggett: not Thai... we're breaking this down in a way that's not at all clear to implementors, and using a system of categorizing Unicode scripts not based on standard or commonly used way of breaknig it down

[14:57] <dbaron> glenn: I think we can do better examples, like for Thai. It's often the case thta you distribute between clusters.

[14:57] <dbaron> glenn: Unfortunately this example doesn't show any combining vowel signs

[14:57] <dbaron> glenn: or combining tone marks

[14:58] <dbaron> glenn: if the example had a consonant with a combining vowel sign and combining tone mark, it would be clear in the example how inter-cluster differs from distribute

[14:58] <dbaron> glenn: That's frequently used in thai signage, newspapers

[14:58] <dbaron> jdaggett: you're saying the thai characters are distributed differently fromteh latin characters?

[14:58] <dbaron> glenn: yes

[14:58] <dbaron> stevez: comes back to the definition of characetr. The definition of character now in the spec muddles that up

[14:59] <dbaron> jdaggett: Trying to look at it from a high level and classify high level categories of differences is a safe way to do this. IT's going to be error-prone . IT's not specified in a way that it's going to be interoperable.

[14:59] <dbaron> glenn: grapheme clusters is defined by unicode

[14:59] <dbaron> fantasai: categorization of scripts in not, in terms of how they justify

[14:59] <fantasai> s/in not/is not/

[15:00] <dbaron> glenn: ... priorities ..., difference between one value and the other is the priorities

[15:00] <dbaron> s/glenn/jdaggett/

[15:00] <dbaron> jdaggett: I'm still unclear about the use case.

[15:00] <dbaron> glenn: Inside of publishing companies there are probably style rules for how to deal with multi-scripts distribution.

[15:00] <dbaron> glenn: I think you're probably not going to find it outside of that context.

[15:01] <dbaron> glenn: so anything that's definitive in some context is better than the current state of affairs which is pretty random

[15:01] <dbaron> glenn: if we don't have script prioiritaziotn specified propertly, we could improve

[15:01] <dbaron> jdaggett: I think we should specify in terms of restrictions, "prioritize X less", "prioritize Y last"... we could cover all use cases that way, and leaves you not having to define broad script categories.

[15:01] <dbaron> -glenn

[15:01] <dbaron> Koji: I still don't understand what you mean by use cases

[15:01] <dbaron> Koji: use case for inter-ideograph is japan, china, etc.

[15:02] <dbaron> jdaggett: That's my entire problem with this property. If it's for CJK, why can't you just go based on the language.

[15:02] <dbaron> Koji: that's not what browsers do already for justification

[15:02] <dbaron> jdaggett: but it could easily be defined that way

[15:02] <dbaron> jdaggett: and defining it that way gives UAs more leeway to figure out what the right things, and we don't have to put a lot of effort into detailing script categories

[15:03] <dbaron> jdaggett: you're talking about pushing this to last call; it's not clear if it's the right direction

[15:03] <dbaron> Koji: It's implemented for WebKit and IE; everyone's using it

[15:03] <dbaron> jdaggett: part of the problem is that here, we don't know if implementations match

[15:03] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Ap%20{%20width%3A%202.9em%3B%20border%3A%20solid%3B%20}%0A%3C%2Fstyle%3E%0A%3Cp%20lang%3Dzh%3E%0A%E8%BF%99%E6%98%AF%E4%B8%80%E4%BA%9B%E4%B8%AD%E5%9B%BD%E5%AD%90%E3%80%82

[15:03] <dbaron> jdaggett: MS people haven't documented their impl

[15:03] <dbaron> stevez: I'm not sure what you're copmlainig about

[15:04] <fantasai> Testcase above shows that implementations don't use lang values to turn on proper justification....

[15:04] * lmclister Quit ("")

[15:04] <dbaron> jdaggett: This spec is defining script categories that are not defined elsewher; we're coming up with our own set of categories.

[15:04] <dbaron> stevez: There's no external definition of script categories that we can point to

[15:04] <dbaron> stevez: is that part of your point?

[15:04] <dbaron> jdaggett: I'd put it as that we're making groupings that are unique to this spec

[15:04] <dbaron> q+

[15:04] <dbaron> stevez: there are groupings that are in common use today

[15:05] <dbaron> stevez: there are different justification rules in common use today for groups of scripts

[15:05] * fantasai wonders if we can avoid a lot of this by removing inter-cluster

[15:05] <dbaron> jdaggett: another way to think of them is not breaking them down by script but saynig "these scripts share this behavior", and defining property values based on these behaviors, not saying property values say "value means X for this set of scripts and Y for this set"

[15:06] * fantasai is confused what the difference is between the two things above stated

[15:06] <dbaron> stevez: other problem with this outline, I think you're saying.... too many combinations of script X in Y to come up with a reasonable set of finite properties to come up with ...

[15:07] <dbaron> s/come up with .../adequately control every combination/

[15:07] <dbaron> stevez: It might be better to be able to, with a script pseudo-elemnent, to label how a fragment of text is to behave in justification

[15:08] <dbaron> stevez: that doesn't get me into the combination thing; the combinations come about by simultaneously trying to apply the set of pieces

[15:08] <dbaron> fantasai: I think that's overkill for 99.99% of the population.

[15:08] <dbaron> stevez: I think the default rules would work for 99% of the population.

[15:09] <dbaron> stevez: e.g., For latin, the rules are word-spacing, then letter-spacing; for Japanese, normally no spacing at all so need a value to say space the letters; for Thai and most of S Asian I would use cluster spcaing

[15:09] <dbaron> jdaggett: is theer a tradition of justification

[15:09] <dbaron> fantasai: for thai and many indian, yes

[15:09] <dbaron> [details]

[15:09] <dbaron> jdaggett: if I look at Thai as an example

[15:10] <fantasai> dbaron: Koji was saying that browsers don't implement lang-dependent justification rules today

[15:10] <fantasai> dbaron: Just because they don't do it today, doesn't mean the solution is that authors should specify it, if lang-dependent rules would be sufficient.

[15:10] <fantasai> dbaron: If we can do things with same amount of code, but no new properties, then that's better.

[15:11] <dbaron> Koji: I think what we came down... WG wanted not to do language-dependent .. introduce justification-language: japan

[15:11] <dbaron> jdaggett: nobody wants justification: japan. But browsers already have some line-breaking behavior based on language; it makes equal sense to do the same for justification.

[15:12] <dbaron> jdaggett: ... and what I don't quite get... if a Japanese author says text-justify on a piece of text... are there multiple styles they'd actually use?

[15:12] <dbaron> various: yes

[15:12] <dbaron> jdaggett: then we need values... but do these values make sense to the author? Do the values describe the different styles?

[15:12] <dbaron> Koji: if you want a space between characters, use inter-ideograph... people understand that

[15:13] <dbaron> fantasai: 2 typical styles in japanese: compress around extra spaces around punct; otherwise expand certain things, but don't expand between Latin

[15:13] <dbaron> fantasai: ... or just space everywhere (text-justify: distribute) -- less common, but definitely used.

[15:13] <dbaron> jdaggett: I can see the use case for text-justify: distribute.

[15:13] <dbaron> jdaggett: seems like what you want are ways to say "allow this" or "enable that"

[15:13] <dbaron> jdaggett: then it's very clear that for this set of codepoints I'm allowed to expand the box, but at a lower priority

[15:14] <dbaron> jdaggett: that way you're creating property values that make sense to what the author wants to do

[15:14] <plinss> ack dbaron

[15:14] <dbaron> jdaggett: not some "this is what's best for japan"

[15:14] <dbaron> Koji: then if ... tools work correctly, that changes layout

[15:14] <dbaron> Koji: you're saying to make justification language-dependent

[15:14] <dbaron> jdaggett: yes

[15:15] <dbaron> stevez: he's saying to put in language-specific rules for justification, and only have controls where they're needed to override language-specific rules

[15:15] <dbaron> jdaggett: yes

[15:15] <fantasai> dbaron: If you're doing lang-specific rules for justification

[15:15] <fantasai> dbaron: Could use rules specific to the language of the block

[15:15] <fantasai> dbaron: Within the block, mark sections as other languages

[15:16] <fantasai> dbaron: but not affect the justification choice for the block

[15:16] <dbaron> stevez: so you can distinguish between japanese-in-english and english-in-japanese ,which is an important distinction since therules are different

[15:16] <dbaron> jdaggett: the meta-point here is that this porperty seems like we're only doing it because IE defined it

[15:16] <dbaron> jdaggett: ... and that I see this as not the right way to do this

[15:16] <dbaron> stevez: slightly differently: we're doing it the way we're doing it because IE defined it. Can we step back and say what is really needed to do the controls that we need?

[15:16] <dbaron> stevez: we recognize the need for a property (normal vs. distribute, maybe other cases)

[15:17] <dbaron> stevez: but I think John's ocmplaint, do what IE/Word did... is that really the most reasonable way of doing this?

[15:17] <dbaron> Koji: I understand your point, but that's not what we want this way

[15:17] <dbaron> Koji: my belief is that layout language and content language are different

[15:17] <dbaron> Koji: I do not want layout dependent on language we use

[15:17] <dbaron> Koji: maybe different pseudo-element can work

[15:18] <dbaron> fantasai: no way to get correct justification by having somebody write the lagorithm in CSS syntax... would just be a nightmare, e.g., with different punct characters behaving differently

[15:18] <dbaron> fantasai: doing high-quality justification for a language justiufication can't be done reasonably making the user define the algorithm in CSS syntax

[15:18] <dbaron> fantasai: it should be a one-line request for a type of justification

[15:19] <dbaron> stevez: I sort of agree with what you're saying ... jlreq talks about jsutification and categories therein. But it largely punts on foreign language included in japanese

[15:19] <dbaron> stevez: it says what happens at the boundary, but not necessarily what's inside the foreign piece

[15:19] <dbaron> stevez: I think david's point that you need both a paragraph language and a specific language inside that may change things is another important piece to thta

[15:19] <dbaron> stevez: ... which doesn't really get picked up in what we'retalking about

[15:20] <dbaron> fantasai ;as far as the switches needed: in Japanese need regular vs distribute

[15:20] <dbaron> fantasai: ... in Latin, whether letter-spacing can expand

[15:20] <dbaron> fantasai: ... and in Arabic, ideally, spaces vs. cursive elongation (Kashida)

[15:20] <dbaron> fantasai: ... common in newspapers

[15:20] <dbaron> fantasai: Those are sets of switches that we definitely need to distinguish between

[15:20] <dbaron> jdaggett: example: cursive latin in Japanese text

[15:20] <dbaron> jdaggett: could be any number of styles applied there... can't be called Kashida (it's Latin)

[15:21] <Bert> Scribenick: Bert

[15:21] <fantasai> jdaggett: In that context, you need to say how each one of those blocks will expand

[15:21] <fantasai> jdaggett: It may be that you only want to expand on word spaces

[15:21] <Bert> jdaggett: In that context , you need to say how each type of block is going to expand.

[15:21] <Bert> ... Maybe in the case of latin, you want to strectch the characters.

[15:21] <Bert> ... not widely supported, but neither is kashida.

[15:22] <Bert> ... Picking those pieces i snot encessarily a single setting.

[15:22] <Bert> ... This single propertiy sets all of these.

[15:22] <Bert> ... Curremtly you have kashida and interideograph.

[15:22] <Bert> ... Cannot allow them together.

[15:22] <Bert> fantasai: Maybe in som efuture lavel have a new value for comobination.

[15:23] <Bert> ... those comb are soooo... we'll never get there.

[15:23] <Bert> ... Why ever discuss this in tnext 15 years?

[15:23] <Bert> jdaggett: It captures the problem that this prop is tryin to define.

[15:23] <Bert> ... Opaque to the user.

[15:23] <Bert> fantasai: We can make it a shorhand in the future,

[15:24] <Bert> jdaggett: Becaus we are defining it this way...

[15:24] <Bert> ... My alternatibe is to not define it at this level.

[15:24] <Bert> ... ONly 'auto' and 'sdtsitribute' and rest in level 4

[15:24] <Bert> fantasai: Anf 'none?

[15:24] <Bert> ... accessibilty.

[15:24] <Bert> SteveZ: What's the harm with none?

[15:25] <Bert> jdaggett: text-align: left is the same

[15:25] <Bert> SteveZ: Not the samewhen you mi arabix and latin.

[15:25] <Bert> fantasai: Setting tetx-align also turns of centering.

[15:26] <Bert> SteveZ: justification shouldn't have been in text-align.

[15:26] <Bert> fantasai: auto & distribute would get you japanese distinguishing between two set of rul, that's fine.

[15:26] <Bert> ... But why only?

[15:27] <Bert> SteveZ: You can set letter-spacing to 0

[15:27] <Bert> [discussion about what letter-spacing with a value does to justification]

[15:28] <Bert> fantasai: Don't jknow if anybody cares if you get justification if you set letter-spacing to a value.

[15:28] <Bert> SteveZ: letter-spacin: max?

[15:28] <Bert> jdaggett: CAn add some value.

[15:28] <Bert> fantasai: text-justify [missed]

[15:29] <Bert> SteveZ: jdaggett complains abou it being a hodgepodge

[15:29] <Bert> jdaggett: If we can resolve to make text-justify then we can resolveto deal with letterspacing .

[15:29] <Bert> koji: webkit and ie do this property already.

[15:30] <Bert> jdaggett: How can you NOT say that japanese behaves [...]

[15:30] <Bert> koji: there are many docs without a lang attribute

[15:30] <Bert> jdaggett: this property that was never defines is somehow already defined by practice...

[15:31] <Bert> fantasai: We have that all the time.

[15:31] <Bert> ... Not a circular referecne

[15:31] <fantasai> koji^: Those documents will break

[15:31] <Bert> jdaggett: I'm not sure this is something that breask if you treat in lang specific manner.

[15:31] <Bert> fantasai: If ther is no lang attribute that may ok.

[15:32] <Bert> ... But ther are docs out there thet habe no lang attr and specify inter-ideograph.

[15:32] <Bert> ... They should continue to justify.

[15:32] <Bert> ... Two ways.

[15:32] <Bert> ... othe ris to have the initial value do that

[15:32] <Bert> ... MY pref would be for auto to just work for japanese, even if lang is not specified.

[15:33] <Bert> jdaggett: sniffing.

[15:33] <Bert> fantasai: We don';t sniff, thsoe code points just justify.

[15:33] <Bert> ... You' dhave to test if that is web-compatible.

[15:33] <Bert> jdaggett: We don't even know how ie and webkit work.

[15:33] <Bert> ... They haven't given any input.

[15:34] <Bert> ... not on how it desirable.

[15:34] <Bert> ... was an action on sylvain.

[15:34] <Bert> ...stil not done.

[15:34] <Bert> ... for a LC, this property should not be like this.

[15:34] <Bert> .... Explore this, is one option.

[15:34] <Bert> koji: how can we make consensus?

[15:35] <Bert> ... both sides have said everything.

[15:35] <fantasai> text-justify: none | auto | distribute | inter-word

[15:35] <Bert> fantasai: I propse to define text-justify with 4 values: non auto distribute and inter-word.

[15:35] <Bert> ... interword turns off letterspacing.

[15:36] <Bert> ... distribuet as defd currently.

[15:36] <Bert> ... auto would need test cases to ensure that cjk is correctly justified with auto.

[15:36] <Bert> jdaggett: that sounds good. Not sure about inter-word.

[15:36] <Bert> plinss: sounds like a way forward.

[15:36] <Bert> SteveZ: interword not good for thai.

[15:36] <Bert> fantasai: n, but use auto.

[15:37] <Bert> s/n,/no,/

[15:37] <Bert> fantasai: If it turns out to be an issue for thai we can change it.

[15:37] <Bert> ... japanese has had very strong comments

[15:38] <Bert> plinss: can we resolve on that?

[15:38] <Bert> koji: auto includes inter-ideograph

[15:38] <Bert> fantasai: as long as the languagespecific rules are applied

[15:38] <fantasai> s/applied/do not forbid it/

[15:38] <Bert> plinss: so, as long as there is reason not to.

[15:39] <Bert> s/is/si no/

[15:39] <Bert> fantasai: if you tag something as french and it has cjk, you may want to no space it.

[15:39] <fantasai> fantasai: but if untagged, use ja behavior

[15:40] <Bert> resolved: (1) do language-specific justification and (2) and there are 4 values: none, auto, distribute and interword

[15:41] <fantasai> (3) auto includes inter-ideographic behavior

[15:41] <fantasai> Discussion on inter-word continues after the break

[15:42] * koji Quit (Ping timeout: 60 seconds)

[15:42] <fantasai> because it interacts with letter-spacing issue

[15:43] <dbaron> [dbaron and tantek leave for airport]

[15:43] * dbaron Quit ("8403864 bytes have been tenured, next gc will be global.")

[15:45] * tantek Quit (tantek)

[15:48] * heycam is now known as heycam|away

[15:50] * smfr has joined #css

[15:54] * smfr has left #css

[16:07] * heycam|away is now known as heycam

[16:09] <fantasai> Topic: letter-spacing

[16:10] <fantasai> fantasai: The letter-spacing property is defined so that if you apply any spacing value other than the initial value, it suppresses justification except at spaces.

[16:10] <fantasai> fantasai: This means that you can't combine tracking with any sort of East Asian justification

[16:11] <fantasai> fantasai: The proposal is to have letter-spacing: <length>; apply tracking, but leave justification alone

[16:11] <fantasai> fantasai: in other words it sets the optimal spacing between letters, not a fixed spacing

[16:11] <fantasai> szilles: If I have 2 different trackings on a single line

[16:11] <fantasai> szilles: What happens under justification?

[16:11] <fantasai> fantasai: I have no idea

[16:12] * koji has joined #css

[16:13] <fantasai> jdaggett: Maybe discuss that on www-style

[16:13] <jdaggett> discuss on www-style the new proposal

[16:13] <fantasai> fantasai: Anyway, you were suggesting to remove extra letter-spacing values

[16:13] <fantasai> jdaggett: The justification algorithm isn't specified, so that means the values of letter-spacing as defined in the spec, are not interoperable

[16:14] <fantasai> jdaggett: These provide very fine-grained control

[16:14] <fantasai> jdaggett: This winds up being something they tweak to handle e.g. bad justification in webkit

[16:14] <fantasai> jdaggett: Some other implementation has better justification

[16:15] <fantasai> jdaggett: But has to deal with these values of letter-spacing, which are tuned to webkit's implementation, and make no sense in this new implementation

[16:15] <fantasai> ...

[16:15] <fantasai> szilles: If we don't say something about justification spacing, when it happens, and how much, then implementations will give different results.

[16:16] <fantasai> jdaggett: If you don't have sufficiently high quality justification algorithm, then this control becomes a crutch

[16:16] <fantasai> jdaggett: And then existing content will constrain future implementations.

[16:16] <fantasai> jdaggett: Thing that concerns me here, usually letter-spacing is used by ppl in design applications where they are not setting the value empirically; they're testing against an implementation

[16:17] <fantasai> jdaggett: Usually from design to presentation, all same implementation

[16:17] <fantasai> s/not setting/setting/

[16:17] <fantasai> jdaggett: That's not the case with the Web

[16:17] <fantasai> jdaggett: If you get to point where you need to set this property, then you're already dependent on particular implementation

[16:17] <fantasai> jdaggett: You're setting it so you get what you see in WebKit

[16:18] <fantasai> szilles: I don't think that's the common use.

[16:18] <fantasai> szilles: Can be used that way

[16:18] <fantasai> szilles: But common use is to control the amount of letter-spacing that's allowed to happen

[16:18] <fantasai> jdaggett: COmmon way this is abused is to make up for deficiencies in hyphenation algorithm

[16:18] <fantasai> jdaggett: Same way InDesign gives controls you shouldn't be using to do this

[16:18] <fantasai> szilles: InDesign case it's ok, because wysiwyg in results

[16:19] <fantasai> jdaggett: If you're proposing a simplified property, willing to defer this to that discussion.

[16:20] <fantasai> fantasai: I want to close off css3-text and send to CR, so if we're redesigning the approach, want to push to L4

[16:20] <fantasai> jdaggett: But you were saying that we needed to revise letter-spacing from 2.1 ...

[16:20] <fantasai> fantasai: The issue was that 2.1 gives the ability turn off letter-spacing for justification by setting to other than normal, e.g. setting to 0

[16:21] <fantasai> fantasai: And that's important for some languages like German, the ability to turn that off.

[16:21] * SteveZ Quit (Ping timeout: 60 seconds)

[16:22] <fantasai> fantasai: I was thinking that we could let letter-spacing: <length> allow justification, and use text-justify: inter-word; to turn that off

[16:22] <fantasai> szilles: Suggest letter-spacing-control property that would limit the amount of justification in letter-spacing

[16:23] <fantasai> szilles: John said he's concerned about variety of different implementations using this capability differently

[16:23] <fantasai> szilles: So I suggested that we could define a triggering of the use f letter-spacing-based justification based on a measurement of white space

[16:24] <fantasai> szilles: Most recent idea is that if I increase word spacing by more than X%, then I will trigger the use of up to the max of letter-spacing ot reduce the word space

[16:24] <fantasai> szilles: Only reason I put latter in is to make it more clear as to when it's going to happen

[16:24] <fantasai> szilles: How much of it is used is still left up to the algorithm. Might want to do river elimination or something.

[16:25] <fantasai> szilles: The problem I have is that the use of inter-word is binary, not enough control in it.

[16:25] <fantasai> fantasai: Ok, that makes sense.

[16:25] <fantasai> szilles: If we did that, then I'm ok to have current thing have only one value

[16:25] <fantasai> jdaggett: Should we resolve on changing the current definition of letter-spacing to one value

[16:26] <fantasai> ?

[16:26] <fantasai> Bert: Depends on what else we do.

[16:26] <fantasai> szilles: Think we should go back to letter-spacing define tracking only.

[16:26] <fantasai> szilles: Controlling justification piece should be separate

[16:26] <fantasai> szilles: So I can live with doing that.

[16:26] <fantasai> jdaggett: Think we have ideas here. Not sure we have something enough to resolve on.

[16:26] <fantasai> jdaggett: Resolve on a single value?

[16:27] <fantasai> szilles: Right now we have inter-word in there, want to drop that

[16:28] <fantasai> fantasai: Think we might still need it in Korean, have to investigate. But purpose there can be not about whether letter-spacing can be used, but about whether justification tries to use spaces only.

[16:28] <fantasai> szilles: Ok, that makes sense to me then.

[16:28] <fantasai> jdaggett: How about we resolve on a single value for letter-spacing, with action on fantasai to come up with wording that handles considerations above.

[16:30] <fantasai> fantasai: So if letter-spacing takes a single value, current definition forbids tracking with justification

[16:30] <fantasai> fantasai: So when letter-spacing is used, forbids any justification other than at spaces, e.g. no justification between characters/clusters in Japanese or Thai

[16:31] <fantasai> fantasai: I'm ok to having only one value, just have a concern with this situation.

[16:32] <fantasai> koji: What about word-spacing?

[16:34] <fantasai> Bert: Have some trouble understanding what word-spacing means with three values

[16:34] <fantasai> [jdaggett and fantasai try to explain this]

[16:35] <jdaggett> what is the maximum value for word-spacing?

[16:35] <SimonSapin> Bert: I was more surprised to see 4 values on word-spacing than on letter-spacing

[16:35] <jdaggett> is it the maximum *additional* spacing (i.e. width of the space + additional word spacing)?

[16:36] <jdaggett> or the maximum of (width of the space + additional space)?

[16:37] <SimonSapin> [fantasai draws an example]

[16:38] <SimonSapin> fantasai: the maximum refers to the max of increase to word-spacing to justification

[16:39] <jdaggett> let W = width of the space

[16:39] <jdaggett> L = width of letter spacing

[16:39] <jdaggett> A = variable additional spacing

[16:39] <jdaggett> max value of word-spacing = max(A)

[16:39] <jdaggett> ]

[16:39] <SimonSapin> SimonSapin: the used word-spacing is one length that is between the computed min/max

[16:39] <SimonSapin> fantasai: yes, they all refer to the same thing

[16:40] <jdaggett> fantasai: yes, that formula is correct

[16:40] * arronei Quit ("")

[16:41] <SimonSapin> fantasai: CSS1 defines word-spacing as the additional space, and I can���t change that

[16:41] * rhauck1 Quit (Client closed connection)

[16:42] <SimonSapin> fantasai: with calc you can define calc(some value - 100%)

[16:43] <SimonSapin> plinss: letter-spacing happens on both sides of the space character

[16:43] <SimonSapin> ��� so you get double letter-spacing between words

[16:43] * rhauck has joined #css

[16:44] <SimonSapin> fantasai: [���] file an issue on German

[16:44] <SimonSapin> fantasai: you must not letter-spacing

[16:44] <SimonSapin> ��� for justification

[16:45] <SimonSapin> fantasai: we have to resolve the conflict between allowing Japanese letter-spacing for justification by default and [���]

[16:46] * lmclister has joined #css

[16:47] <SimonSapin> Bert: justify the last line (or only line) by increasing the font size

[16:48] <SimonSapin> jdaggett: copyfitting. That���s hard

[16:48] * rhauck Quit ("Leaving.")

[16:48] <SimonSapin> Bert: text-align with a string value ��� looked at "tabbing" as done in word processors

[16:49] <SimonSapin> jdaggett: not much control on how it���s lined up

[16:49] <SimonSapin> plinss: very controversial

[16:50] <SimonSapin> Bert: the idea is not to have to use a table

[16:50] <SimonSapin> jdaggett: table with this makes implementers cry

[16:50] * lmclister Quit (Ping timeout: 60 seconds)

[16:50] <SimonSapin> SimonSapin: yes

[16:51] <SimonSapin> fantasai: syntax may not be ideal, but the functionality gets annoying in any case with tables

[16:51] <SimonSapin> jdaggett: you want this working in table, wondering if it���s the right way

[16:51] <SimonSapin> fantasai: should defer to level 4

[16:51] <jdaggett> agreed

[16:52] <SimonSapin> fantasai: other issues?

[16:52] <SimonSapin> jdaggett: none logged. Will review

[16:52] <SimonSapin> jdaggett: text-justify resolution means we can toss out at the appendix [���]?

[16:52] <SimonSapin> fantasai: yes

[16:53] * lmclister has joined #css

[16:53] <SimonSapin> fantasai: redefine distribute to apply to arabic which could be interesting

[16:53] <SimonSapin> fantasai: or redefine the cursive category

[16:53] <SimonSapin> plinss: adjouned

[16:54] <glazou> s/adjouned/adjourned

[16:54] <glazou> </ftf>

[16:54] * glazou Quit (glazou)

[16:57] * jdaggett Quit (jdaggett)

[16:58] * kawabata Quit ("Page closed")

[16:58] * plinss is now known as plinss_away

[17:02] * koji Quit (Ping timeout: 60 seconds)

[17:07] * kawabata_ Quit (Ping timeout: 60 seconds)

[17:09] * SimonSapin Quit (Ping timeout: 60 seconds)

[17:13] * Kazutaka Quit (Ping timeout: 60 seconds)

[17:32] * dbaron has joined #css

[17:34] * tantek has joined #css

[17:35] * plinss_away is now known as plinss

[17:39] * heycam is now known as heycam|away

[17:43] * tantek Quit (tantek)

[17:46] * dbaron Quit (Ping timeout: 60 seconds)

[17:53] * plinss is now known as plinss_away

[17:54] * SimonSapin has joined #css

[17:54] * plinss_away is now known as plinss

[18:01] * plinss is now known as plinss_away

[18:07] * sylvaing is now known as sylvaing_away

[18:22] * SimonSapin Quit (Ping timeout: 60 seconds)

[18:32] * lmclister Quit (Client closed connection)

[18:40] * lmclister has joined #css

[18:42] * heycam|away is now known as heycam

[18:44] * lmclister Quit ("")

[19:06] * lmclister has joined #css

[20:07] * jdaggett has joined #css

[20:08] * jdaggett Quit (jdaggett)

[20:20] * heycam is now known as heycam|away

[20:45] * glenn has joined #css

[20:47] * glenn_ has joined #css

[20:47] * glenn Quit (Client closed connection)

[20:47] * glenn has joined #css

[20:47] * glenn_ Quit (Client closed connection)

[20:49] * glenn_ has joined #css

[20:49] * glenn Quit (Client closed connection)

[20:52] * isherman-book has joined #css

[20:55] * heycam|away is now known as heycam

[20:57] * glenn_ Quit (Client closed connection)

[20:57] * glenn has joined #css

[20:57] * glenn Quit (Client closed connection)

[21:15] * isherman-book Quit ("Leaving.")

[21:22] * lmclister Quit ("")

[21:26] * plinss_away is now known as plinss

[21:30] * lmclister has joined #css

[21:31] * SimonSapin has joined #css

[21:36] * lmclister Quit ("")

[22:15] * cabanier Quit ("Leaving.")

[22:18] * plinss is now known as plinss_away

[22:18] * dino Quit (dino)

[22:19] * dbaron has joined #css

[22:20] * heycam is now known as heycam|away

[22:23] * dbaron Quit (Ping timeout: 60 seconds)

[22:28] * isherman-book has joined #css

[23:01] * SteveZ has joined #css

[23:09] * isherman-book Quit ("Leaving.")

[23:10] * SimonSapin Quit (Ping timeout: 60 seconds)

[23:10] * SimonSapin has joined #css

[23:20] * antonp has joined #css

[23:24] * isherman-book has joined #css

[23:26] * dbaron has joined #css

[23:28] * isherman-book Quit ("Leaving.")

[23:45] * dbaron Quit ("8403864 bytes have been tenured, next gc will be global.")

[23:54] * SimonSapin Quit ("Leaving.")

[23:58] * nvdbleek has joined #css

[23:59] * liam has joined #css

These logs were automatically created by CSSWG_LogBot on irc.w3.org using the Java IRC LogBot.