/irc-logs / w3c / #css / 2013-02-06 / end

Options:

# Session Start: Wed Feb 06 00:00:00 2013
# Session Ident: #css
# [00:00] <Bert> ... Fallback is currently per representationn
# [00:00] <Bert> ... Can have two styles, even num and odd number, and they fall back to each other.
# [00:00] <Bert> ... can get cycle.
# [00:00] <Bert> ... should it fal back to decimal?
# [00:01] <Bert> ... What do impelmenters think?
# [00:01] <Bert> SimonSapin: Didn't implement first. Fall back to decimal is fine.
# [00:01] <fantasai> s/Didn't/Did/
# [00:02] * Quits: dbaron (~dbaron@public.cloak) (Client closed connection)
# [00:02] <Bert> dbaron: Don't understand the issue yet, so can't say.
# [00:02] * Joins: dbaron (~dbaron@public.cloak)
# [00:02] <Bert> TabAtkins_: [drawing on white board]
# [00:02] * Quits: dbaron (~dbaron@public.cloak) (dbaron)
# [00:02] * Joins: dbaron (~dbaron@public.cloak)
# [00:03] * Quits: TabAtkins_ (~TabAtkins@public.cloak) (Ping timeout: 60 seconds)
# [00:03] <Bert> ... @counter-style only-even {fallback: only-odd}
# [00:04] <Bert> ... @counter-style only-odd {fallback: only-even}
# [00:04] <Bert> dbaron: curent spec is OK, then. Fallback per counter value, not per counter style.
# [00:05] <Bert> RESOLVED: current spec is OK for fallback per counter value
# [00:05] <Bert> TabAtkins: Issue with ethiopic
# [00:05] <Bert> ... Was in 2.1, not in 2.0
# [00:05] <Bert> ... Cannot be represented with @counter-style
# [00:06] <Bert> ... Everythign else can, or was already in 2.0
# [00:06] <Bert> ... Do we care about this style to predefine it?
# [00:06] <Bert> fantasai: Leave and mark at risk.
# [00:06] <Bert> TabAtkins: Not sure we'll resolve it, then.
# [00:06] <Bert> fantasai: If after CR nobody implemented it, we drop it.
# [00:07] <Bert> ... Nothing to resolve, just depends on implementers.
# [00:07] <Bert> tantek: In general, put it at rsik if not implemented.
# [00:07] <Bert> dbaron: We have 5 ethiopic styles
# [00:07] <Bert> TabAtkins: The alphabetic styles are fine.
# [00:07] <Bert> dbaron: We have a 62-line algo for the ethipoic style.
# [00:08] <Bert> TabAtkins: I suspect it is there becase hixie knew moz had some support.
# [00:08] <Bert> ... I can mark it at risk.
# [00:09] <Bert> RESOLVED: mark ethiopic-numeric at risk.
# [00:09] <Bert> fantasai: So only some edits and then last call?
# [00:09] <Bert> TabAtkins: yes
# [00:09] <Bert> topic: text
# [00:10] <Bert> [longer than 1 hour, move to tomorrow]
# [00:10] <smfr> http://lists.w3.org/Archives/Public/www-style/2013Jan/0223.html
# [00:10] * Joins: TabAtkins_ (~TabAtkins@public.cloak)
# [00:10] <Bert> topic: top layer positioning
# [00:11] <Bert> TabAtkins: dom spec for dialog and full screen have concept of something on top of everything else.
# [00:11] <Bert> ... We don't ahve that in CSS.
# [00:11] * Joins: danielfilho (~danielfilho@public.cloak)
# [00:11] <Bert> ... Abs pos doesn't guarantee the top.
# [00:11] <Bert> smfr: stacking contexts can be on top.
# [00:12] <Bert> TabAtkins: I propsoed to address this directly, some extension to position or z-index
# [00:12] <Bert> ... eparate stacking context
# [00:12] <Bert> ... that is put on top of everything else.
# [00:12] <Bert> glazou: Seems simliar to alerts
# [00:12] <Bert> TabAtkins: Yes
# [00:12] <Bert> glazou: Security issue?
# [00:12] <Bert> tantek: yes
# [00:13] <Bert> glazou: Same issues with alerts
# [00:13] <Bert> TabAtkins: Can already do it now.
# [00:13] <Bert> smfr: Not overlaying the chrome
# [00:13] <Bert> glazou: But if a page does that now, you can still put somethign above it.
# [00:13] <Bert> ... user style sheet, e.g..
# [00:13] * Quits: dbaron (~dbaron@public.cloak) (Client closed connection)
# [00:14] <Bert> TabAtkins: MAybe users cannot do that anyway, right now.
# [00:14] <Bert> ... Order in the document may prevent it.
# [00:14] * Joins: dbaron (~dbaron@public.cloak)
# [00:14] <Bert> smfr: Security issues not usnique to this.
# [00:14] <Bert> dbaron: So it needs to escape from filters, etc.?
# [00:14] <Bert> TabAtkins: Yes, no effect on ancestor of [...]
# [00:14] <Bert> SteveZ: Only one such stacking context?
# [00:15] <Bert> TabAtkins: Yes, only one.
# [00:15] <Bert> SimonSapin: [missed]
# [00:15] <Bert> ... Are transformed?
# [00:15] <Bert> TabAtkins: yes, but not fixed pos anymore
# [00:16] <Bert> Rossen: And with full screen?
# [00:16] <Bert> TabAtkins: This is a non-magic full-screen. You can get it without magic in CSS.
# [00:16] <SimonSapin> s/[missed]/What happens to fixed-pos elements in a transform?/
# [00:16] <Bert> ...seems wasteful to have magical capabilities in browser that user cannot invoke himself.
# [00:17] <Bert> smfr: We want to be able to implement everything through CSS.
# [00:17] <Bert> ... fullscreen has a backdrop element.
# [00:17] <Bert> TabAtkins: That goes down in the top context, too, doesn't it?
# [00:17] <Bert> ... Put it as sibling of the root... no... We'll figure it out.
# [00:18] <Bert> ... Does anybody see problems?
# [00:18] <Bert> dbaron: Where is the proposal?
# [00:18] <Bert> TabAtkins: [points at screen]
# [00:18] <Bert> ... the top layer cannot fixed pos, but it can be canvas-relative.
# [00:18] <Bert> glazou: Scollable?
# [00:18] <Bert> TabAtkins: Yes
# [00:19] <Bert> smfr: fullscreen describes a dialog centered in the viewport. We cannot currently do that in CSS.
# [00:19] <Bert> Rossen: [...] go into top layer?
# [00:19] <Bert> TabAtkins: Yes.
# [00:19] <Bert> smfr: So what spec does this go into?
# [00:19] <Bert> TabAtkins: Could be positioning spec.
# [00:19] <Bert> ... Arron is editor.
# [00:20] <Bert> ... I can become co-editor as well.
# [00:20] <Bert> smfr: What is syntax?
# [00:20] <Bert> TabAtkins: Don't know yet.
# [00:20] <Bert> fantasai: would change order, but not position?
# [00:20] <Bert> smfr: Position, too
# [00:20] <Bert> fantasai: relative to what?
# [00:20] <Bert> smfr: initial containing block, maybe.
# [00:21] <Bert> Rossen: yes, incitial CB, but also above everything else.
# [00:21] <Bert> ... like position: page
# [00:21] <Bert> ... escapes all its ancestors.
# [00:21] <Bert> ... sized into the root, but then scrolled with everything else.
# [00:22] <Bert> fantasai: 'pos: page' doesn't exactly do that.
# [00:22] <Bert> Rossen: positioning spec seems right place.
# [00:22] <Bert> ... let's start discussing it, and when you have something we put it in.
# [00:23] <Bert> SteveZ: We talked about Extension to let you pick wihich ancestor to be relative to.
# [00:23] <Bert> ... this is similar.
# [00:23] <Bert> TabAtkins: All current position values have to unmagic themselves.
# [00:23] <Bert> ... one more value doens't seem bad.
# [00:24] <Bert> SteveZ: Split it into two: choose CB and choose layer?
# [00:24] <Bert> TabAtkins: Haven't thought about syntax yet.
# [00:24] <Bert> SteveZ: So you say everything can go into that top layer.
# [00:25] <Bert> fantasai: Seems more complicated than it looked at first glance.
# [00:25] <Bert> ... scrolls as well.
# [00:25] <fantasai> s/looked/looks/
# [00:25] <Bert> Rossen: Maybe not only positioned elements in top layer.
# [00:25] <fantasai> fantasai: if you have a long scrolling document and you want to put sometihng into the top layer, you want it visible right there, not positioned into the ICB which is scrolled way off the screen
# [00:25] <Bert> ... e.g. a form where each element in turn can be on top.
# [00:25] <Bert> ... pop it up.
# [00:25] <Bert> TabAtkins: what does that mean.
# [00:26] <Bert> smfr: Like graying out everything but the element.
# [00:26] <Bert> ... Would liek to not separate psotiining from layering.
# [00:26] <Bert> ... harder to implement.
# [00:26] <Bert> ... a child of a fixed element can then move.
# [00:27] * Joins: mollyholzschlag (~mholzsch@public.cloak)
# [00:27] <Bert> SteveZ: You may want to position it at its current position, but in top level.
# [00:27] <Bert> plinss: Sticky psoitioning?
# [00:27] <Bert> ... Two or hree attributes that are othogonal.
# [00:27] <Bert> ... vieport aspect, positioning aspect, layering aspec.
# [00:28] <Bert> ... But I can see smfr's concerns.
# [00:28] <Bert> SteveZ: You can get some of that already.
# [00:28] <Bert> smfr: If you abs pos it, it may be relatibe to an animated ancestor...
# [00:29] <Bert> ... but it is not contained witin its hierarchy
# [00:29] <Bert> smfr: Offset is magically computed, even if cb is ICB.
# [00:29] <Bert> ... Don't really like proposals where something i s layed out and depend son arbitray element.
# [00:30] <Bert> ... All these dependencies.
# [00:30] * Joins: RRSAgent (rrsagent@public.cloak)
# [00:30] <RRSAgent> logging to http://www.w3.org/2013/02/05-css-irc
# [00:30] <Bert> SteveZ: Understand, but trying to solve elika's problem.
# [00:30] <Bert> fantasai: We need use cases.
# [00:30] <Bert> TabAtkins: We have some.
# [00:30] <Bert> smfr: See html5
# [00:30] * dbaron RRSAgent, remind us in 25 hours to go home
# [00:30] <RRSAgent> I'm logging. I don't understand 'remind us in 25 hours to go home', dbaron. Try /msg RRSAgent help
# [00:30] <Bert> TabAtkins: Trying to solve fullscreen ni CSS.
# [00:31] * dbaron oh, wait, that's Zakim
# [00:31] <Bert> fantasai: Efectively a new canvas on top of the old canvas and the scrollbars control that new canvas.
# [00:31] <Bert> ... different from throwing it into the ICB.
# [00:31] <smfr> http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#set-up-the-position
# [00:31] <Bert> ... OK, I understand better now.
# [00:31] <Bert> smfr: HTML spec says "magically aligned"
# [00:32] <Bert> ... we eant to remove the magic.
# [00:32] <Bert> TabAtkins: Just one new canvas.
# [00:32] <Bert> fantasai: When that new cnvas has content, than you cannot scroll the old canvas?
# [00:32] <Bert> tantek: You can still scroll it.
# [00:32] <Bert> SteveZ: So there is a lock between them and you scroll them togehter.
# [00:33] <Bert> tantek: Different from fullscreen. That doesn't scroll along. Dialog does.
# [00:33] <Bert> smfr: Fullscreen is for backdrop element,
# [00:33] <Bert> ... that does other magical things.
# [00:33] <Bert> fantasai: Do you wan tot ever scroll the dialog off the screen?
# [00:33] <Bert> TabAtkins: Scroll it a bit.
# [00:33] * plinss http://w3cmemes.tumblr.com/post/34634329920/csswg-resolves-to-use-less-magic
# [00:34] <Bert> SteveZ: You want to scroll what't behind it, because the dialog is obscuring it!
# [00:34] <Bert> fantasai: Not a bad idea, can be investigated. Maybe not right now.
# [00:34] <Bert> TabAtkins: I'll figure out more requirements and propsoals
# [00:35] <Bert> SteveZ: We have a whole bucnch of things this must fit into. HTML5 doesn't have that. Just has magic.
# [00:35] <Bert> ... I'm OK with positioning other than to CB.
# [00:37] <Bert> topic: counter styles [cont'd]
# [00:37] <dbaron> RESOLVED: Remove the example about simulating filled counter styles and add a feature for filled counter styles.
# [00:38] <dbaron> Topic: Variables
# [00:38] <TabAtkins_> http://dev.w3.org/csswg/css-variables
# [00:39] <Bert> glazou: I spoke about this in Pris and syaing that it is not variables, but user-defiend proeprties helped people a lot.
# [00:39] <Bert> TabAtkins: But we made them because we neede dvariable.
# [00:39] <Bert> TabAtkins: But "user-defined proeprties" doesn't explain what they are for,
# [00:40] <Bert> fantasai: Somebody propsoed a long time ago
# [00:40] <Bert> ... before 2008
# [00:40] <Bert> ... and described them as variables
# [00:40] <Bert> ... So I think that is fine.
# [00:40] <Bert> ... Should then also change the prefix from "var-"
# [00:40] <Bert> TabAtkins: They are made for use as variables.
# [00:41] <Bert> bert: I explained them recently in the same way as glazou.
# [00:41] <tantek> Cascading Variable Sheets? CVS?
# [00:41] <fantasai> no, they're part of CSS
# [00:42] <Bert> ... arbitrary proeprty-value pairs attached to element
# [00:42] <Bert> fantasai: Leave title alone, but change the prefix.
# [00:42] <Bert> TabAtkins: Section is laready called "custom proeprties"
# [00:43] <Bert> glazou: I saw jow people reacted. They didb't get variables.
# [00:43] <Bert> ... People do look at the name of the document.
# [00:43] * dbaron americans { var-cvs: "Consumer Value Stores"; } programmers { var-cvs: "Concurrent Versioning System"; } tantek { var-cvs: "Cascading Variable Sheets; }
# [00:43] <Bert> ... The name matters.
# [00:43] <Bert> ... more than the abstract.
# [00:43] <Bert> fantasai: "Custom referencable properties"
# [00:43] <Bert> glazou: I can live with variable. It's unfortunate.
# [00:44] <Bert> Rossen: Naming is important.
# [00:44] <Bert> glazou: I explained earlier why these were not variables.
# [00:44] <Bert> ... I had an actiom item for it.
# [00:44] <Bert> ... Explain why there are customg proeprties.
# [00:44] * heycam is now known as heycam|away
# [00:44] <Bert> plinss: case-insesnitivity of prefix?
# [00:45] <fantasai> fantasai: Would changing the dash to a space help that?
# [00:45] <Bert> fantasai: "var" <space> <name>, 'var fo'o instead of ''var-foo'
# [00:45] <Bert> TabAtkins: :Would be relatively easy to chnage.
# [00:46] <Bert> glazou: No, I don't want that.
# [00:46] * fantasai has to say, kindof leaning towards' François' suggestion to use my- instead of var-
# [00:46] <dbaron> I'd like "unclosed" to change to "unmatched" in section 2
# [00:46] <TabAtkins_> p { var foo: blue; color: var(foo); }
# [00:46] * fantasai also my() instead of var()
# [00:46] * fantasai emphasizes we're grabbing the property value from this element, not somewhere else in the style sheet
# [00:47] <Bert> TabAtkins: Force lowercase?
# [00:47] <Bert> plinss: That would be more consitent.
# [00:47] <Bert> ... not necessarily falls under general rule we decinded yesterday.
# [00:47] <Bert> jdaggett: Simple exception is ok.
# [00:48] <Bert> ... consistency as much as possible, but in this it's ok
# [00:48] <Bert> plinss: If it is case-insensite, then will be reserializedin lowercase.
# [00:48] <Bert> ... make the whole thing case-sensitive, and var must be in lowercase.
# [00:49] <dbaron> dbaron: not so great for people who write their CSS in lowercase
# [00:50] <dbaron> er, uppercase
# [00:50] <Bert> [discussion about fashions for upper and lowercase. HTML used be written in upper, before XML]
# [00:50] <Bert> plinss: if VAR- is changed to var-, a naive script writer will make a bug.
# [00:50] <fantasai> RESOLVED: "var-" is case-sensitive
# [00:51] <Bert> RESOLVED: "var-" is lowercase and case-sensitive.
# [00:51] <Bert> glazou: In section 4, API, can you add an example?
# [00:51] <Bert> TabAtkins: Sure.
# [00:51] <Bert> SimonSapin: Want to switch to [missed]
# [00:52] <Bert> TabAtkins: yes.
# [00:52] <Bert> fantasai: its' minor
# [00:52] <Bert> ... what do other implementers think?
# [00:52] <fantasai> s/[missed]/referencing css3-syntax instead of CSS2.1/
# [00:52] <Bert> glazou: Do we not have a class for invalid example in specs?
# [00:53] <Bert> [discussion about flashy styles for wrong examples]
# [00:54] <fantasai> TabAtkins: Value of custom property is defined as anything matching 'value' production in CSS2.1 grammar
# [00:54] <Bert> TabAtkins: value production in CSS2 grammar
# [00:54] <fantasai> TabAtkins: It's very wide
# [00:54] <fantasai> TabAtkins: However, some surprising lacks, due to 2.1 not being a total grammar
# [00:54] <fantasai> TabAtkins: None are actually necessary, e.g. according to 2.1
# [00:55] <fantasai> TabAtkins: Technically could put something like var-a: {a:b};
# [00:55] <fantasai> TabAtkins: but var-a: {a}; is not valid
# [00:55] <fantasai> TabAtkins: It's a particularity of how CSS2.1's grammar production works
# [00:55] <fantasai> plinss: Any reason you'd want something like that?
# [00:55] <fantasai> TabAtkins: If you're just using it to pass data around and using in JS, would be nice to take more arbitrary values without parsing into a string
# [00:56] <fantasai> glenn: CSSOM issue, DOM2Style specifies that properties had to have some value
# [00:56] <fantasai> glenn: Can't be null
# [00:56] <fantasai> TabAtkins: Doesn't seem like a necessary restriction to apply
# [00:56] <fantasai> glenn: Useful b/c tell syou that it as never specified in the first place
# [00:56] <fantasai> glenn: Parse in CSS2 a value list property vs entry that doesn't have a value
# [00:56] <fantasai> glenn: enumerate items list, ask fo rproperty that wasn't specified
# [00:56] <fantasai> glenn: return null
# [00:57] * heycam|away is now known as heycam
# [00:57] <fantasai> glazou: Since value of a variable is usable right now only on the right-hand side of a property, is it worth discussing this?
# [00:57] <fantasai> TabAtkins: This isn't useful in CSS itself, but to pass around in JS it's useful
# [00:57] <fantasai> TabAtkins: François Remy is using this to pass information for some polyfills, e.g.
# [00:57] <fantasai> TabAtkins: Think making it easy to polyfill is a good idea
# [00:58] <fantasai> TabAtkins: When you were saying, "This isn't varaibles, it's custom properties", this is exactly that
# [00:58] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 60 seconds)
# [00:58] <fantasai> Bert asks for clarification
# [00:58] <fantasai> dbaron: You're wrong.
# [00:58] <fantasai> dbaron: They're both valid.
# [00:59] <fantasai> dbaron: I'm not sure that the value production..
# [00:59] <fantasai> dbaron: I went back to this at one point, only one very minor change I would make
# [00:59] <fantasai> dbaron: It really allows pretty close to anything.
# [00:59] <fantasai> TabAtkins: would have to look at it more closely myself then
# [00:59] <fantasai> dbaron: Value can be any or block
# [00:59] <fantasai> dbaron: and in that case both are block
# [00:59] <fantasai> dbaron: block is a brace and then can have, first option is any,
# [00:59] <fantasai> dbaron: any can be ident
# [00:59] <fantasai> dbaron: another one is colon
# [01:00] <fantasai> dbaron: so you're done
# [01:00] <fantasai> dbaron: A block can contain another block
# [01:00] <fantasai> TabAtkins: Then I'll look to see if there's any change we need to make
# [01:00] <fantasai> dbaron: There's a change I proposed awhile ago, looking for it.
# [01:01] * Joins: tantek (~tantek@public.cloak)
# [01:01] <fantasai> TabAtkins: Ok, I will look to see if we need any changes.
# [01:02] <fantasai> plinss: I remember CDO/CDC only allowed in top level of style sheet
# [01:02] <fantasai> glazou: Only a few minutes remaining
# [01:02] <fantasai> glazou: Any objections to publishing LC?
# [01:03] <fantasai> Rossen: What about the name?
# [01:03] <fantasai> plinss, fantasai: We'll rename it at Last Call.
# [01:03] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [01:03] <fantasai> RESOLVED: Publish Cascading Variables as LC
# [01:03] <fantasai> Bert: Which other groups should we ping?
# [01:03] <fantasai> WebApps, SVG, i18n (wrt case-sensitivity)
# [01:04] * Joins: rhauck (~Adium@public.cloak)
# [01:04] <fantasai> glazou: At some point wouldn't someone say we should map data attrs to var properties?
# [01:05] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 60 seconds)
# [01:05] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [01:05] <fantasai> Meeting closed.
# [01:05] * Quits: glazou (~glazou@public.cloak) (glazou)
# [01:05] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [01:05] * plinss is now known as plinss_away
# [01:06] * Quits: Kazutaka (~Kazutaka@public.cloak) ("Page closed")
# [01:07] * Quits: smfr (~smfr@public.cloak) (smfr)
# [01:07] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [01:09] <dbaron> I would prefer the definition be [value | CDO S* | CDC S* ] +
# [01:09] <dbaron> so that we don't have to deal with forbidding CDO/CDC at top-level but allowing them inside () [] {}
# [01:09] <dbaron> maybe we could discuss that tomorrow
# [01:09] * Quits: tantek (~tantek@public.cloak) (tantek)
# [01:09] * Quits: SteveZ (~chatzilla@public.cloak) (Ping timeout: 60 seconds)
# [01:10] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [01:11] * Quits: mollyholzschlag (~mholzsch@public.cloak) ("sleeping computer is sleeping")
# [01:11] * Quits: TabAtkins_ (~TabAtkins@public.cloak) (Ping timeout: 60 seconds)
# [01:20] * Quits: koji (~koji@public.cloak) (Ping timeout: 60 seconds)
# [01:22] * Quits: kawabata (~kawabata@public.cloak) (Ping timeout: 60 seconds)
# [01:35] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [01:35] * Joins: rhauck (~Adium@public.cloak)
# [01:47] * Quits: sylvaing (~sylvaing@public.cloak) (Ping timeout: 60 seconds)
# [02:06] * Joins: SimonSapin (~simon@public.cloak)
# [02:21] * Joins: glazou (~glazou@public.cloak)
# [02:28] * Joins: glenn (~gadams@public.cloak)
# [02:32] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [02:33] * Quits: glazou (~glazou@public.cloak) (glazou)
# [02:34] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [02:36] * heycam is now known as heycam|away
# [02:38] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 60 seconds)
# [02:45] * Quits: lmclister (~lmclister@public.cloak) ("")
# [02:47] * Joins: liam (liam@public.cloak)
# [03:01] * Joins: SimonSapin (~simon@public.cloak)
# [03:02] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [03:03] * Joins: tantek (~tantek@public.cloak)
# [03:07] * Quits: tantek (~tantek@public.cloak) (Client closed connection)
# [03:08] * Joins: tantek (~tantek@public.cloak)
# [03:11] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [03:15] <tantek> greetings, anyone actually here instead of just having their server bots signed in for them? wanted to chat about minor spec markup improvements.
# [03:19] <tantek> I've tried adding h-entry (microformats2 version of hAtom) to CSS3-UI: http://dev.w3.org/csswg/css3-ui/ and wondering what people think (also added a few more rel values)
# [03:29] <danielfilho> I am, but I don't think I have enought skills to discuss such thing with you. I'm more a watcher here :D
# [03:35] * Joins: dbaron (~dbaron@public.cloak)
# [03:35] * Joins: sylvaing (~sylvaing@public.cloak)
# [03:37] * Joins: jdaggett (~jdaggett@public.cloak)
# [04:10] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [04:21] * Quits: tantek (~tantek@public.cloak) (Client closed connection)
# [04:22] * Joins: tantek (~tantek@public.cloak)
# [04:35] * Joins: lmclister (~lmclister@public.cloak)
# [04:44] * Joins: jdaggett (~jdaggett@public.cloak)
# [04:44] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [04:47] * Quits: sylvaing (~sylvaing@public.cloak) (Ping timeout: 60 seconds)
# [04:49] * Quits: dbaron (~dbaron@public.cloak) (Client closed connection)
# [04:54] * Joins: dbaron (~dbaron@public.cloak)
# [05:00] * Joins: glazou (~glazou@public.cloak)
# [05:11] * Quits: dbaron (~dbaron@public.cloak) (Client closed connection)
# [05:11] * Joins: dbaron (~dbaron@public.cloak)
# [05:14] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [05:16] * Joins: isherman-book (~Adium@public.cloak)
# [05:16] * Quits: isherman-book (~Adium@public.cloak) ("Leaving.")
# [05:30] * Quits: glazou (~glazou@public.cloak) (glazou)
# [05:32] * Quits: tantek (~tantek@public.cloak) (tantek)
# [05:39] * Joins: glenn (~gadams@public.cloak)
# [05:45] * Joins: glazou (~glazou@public.cloak)
# [05:47] * Joins: isherman-book (~Adium@public.cloak)
# [05:47] * Joins: tantek (~tantek@public.cloak)
# [05:48] * Joins: SimonSapin (~simon@public.cloak)
# [05:48] * Quits: lmclister (~lmclister@public.cloak) ("")
# [05:53] * Joins: lmclister (~lmclister@public.cloak)
# [05:54] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [05:57] * Quits: isherman-book (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [06:14] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [06:15] * plinss_away is now known as plinss
# [06:20] * heycam|away is now known as heycam
# [06:24] * Joins: isherman-book (~Adium@public.cloak)
# [06:25] * Quits: glazou (~glazou@public.cloak) (glazou)
# [06:26] * plinss is now known as plinss_away
# [06:29] * Joins: glazou (~glazou@public.cloak)
# [06:32] * Quits: isherman-book (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [06:33] * Quits: glazou (~glazou@public.cloak) (glazou)
# [06:34] * Joins: glenn (~gadams@public.cloak)
# [06:34] * Quits: tantek (~tantek@public.cloak) (tantek)
# [06:42] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [06:45] * Joins: glenn (~gadams@public.cloak)
# [06:47] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [06:59] * Joins: isherman-book (~Adium@public.cloak)
# [07:05] * Quits: paul___irish (~paul___irish@public.cloak) ("ZNC - http://znc.sourceforge.net")
# [07:07] * Joins: paul___irish (~paul___irish@public.cloak)
# [07:07] * Quits: isherman-book (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [07:34] * Joins: isherman-book (~Adium@public.cloak)
# [07:43] * Quits: isherman-book (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [07:49] * Joins: glazou (~glazou@public.cloak)
# [07:52] * Quits: glazou (~glazou@public.cloak) (glazou)
# [08:00] * Quits: paul___irish (~paul___irish@public.cloak) (Ping timeout: 60 seconds)
# [08:00] * Joins: paul___irish (~paul___irish@public.cloak)
# [08:48] * heycam is now known as heycam|away
# [08:54] * Quits: lmclister (~lmclister@public.cloak) ("")
# [09:11] * Quits: liam (liam@public.cloak) ("Client exiting")
# [09:11] * Joins: liam (liam@public.cloak)
# [09:17] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:36] * Quits: liam (liam@public.cloak) (Ping timeout: 60 seconds)
# [09:42] * Joins: tantek (~tantek@public.cloak)
# [09:45] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:45] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:46] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:46] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:46] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [09:47] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:47] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:48] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:48] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:50] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:50] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:56] * plinss_away is now known as plinss
# [10:09] * Joins: isherman-book (~Adium@public.cloak)
# [10:10] * Joins: liam (liam@public.cloak)
# [10:14] * Joins: leif (~lstorset@public.cloak)
# [10:18] * plinss is now known as plinss_away
# [10:30] * Quits: isherman-book (~Adium@public.cloak) ("Leaving.")
# [10:44] * Joins: sylvaing (~sylvaing@public.cloak)
# [10:48] * Quits: sylvaing (~sylvaing@public.cloak) (Ping timeout: 60 seconds)
# [11:00] * Joins: isherman-book (~Adium@public.cloak)
# [11:17] * Quits: isherman-book (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [11:20] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 60 seconds)
# [11:23] * Joins: tmpsantos (~tmpsantos@public.cloak)
# [11:45] * Joins: isherman-book (~Adium@public.cloak)
# [11:58] * Quits: isherman-book (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [12:25] * Joins: isherman-book (~Adium@public.cloak)
# [12:26] * Joins: cabanier (~cabanier@public.cloak)
# [12:31] * Joins: nvdbleek1 (~nvdbleek@public.cloak)
# [12:31] * Quits: nvdbleek (~nvdbleek@public.cloak) (Client closed connection)
# [12:38] * Quits: isherman-book (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [12:46] * Quits: nvdbleek1 (~nvdbleek@public.cloak) ("Leaving.")
# [12:46] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [12:47] * Joins: teoli (~teoli@public.cloak)
# [12:50] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [12:50] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [12:51] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [12:51] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:03] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:03] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:06] * Joins: isherman-book (~Adium@public.cloak)
# [13:06] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:06] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:09] * Quits: leif (~lstorset@public.cloak) ("Leaving.")
# [13:11] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:11] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:16] * Joins: leif (~lstorset@public.cloak)
# [13:16] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:16] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:18] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:18] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:19] * Quits: isherman-book (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [13:21] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:21] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:26] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:26] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:31] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:31] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:36] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:36] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:37] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:37] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:41] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:41] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:46] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:46] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:48] * Joins: isherman-book (~Adium@public.cloak)
# [13:50] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:50] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:51] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:51] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:56] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:56] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [14:01] * Quits: isherman-book (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [14:19] * Quits: leif (~lstorset@public.cloak) ("Leaving.")
# [14:22] * Joins: leif (~lstorset@public.cloak)
# [14:28] * Joins: isherman-book (~Adium@public.cloak)
# [14:34] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [14:43] * Quits: isherman-book (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [14:45] * Quits: tmpsantos (~tmpsantos@public.cloak) ("Leaving")
# [14:58] * Quits: tantek (~tantek@public.cloak) (tantek)
# [15:11] * Joins: isherman-book (~Adium@public.cloak)
# [15:17] * Joins: glenn (~gadams@public.cloak)
# [15:23] * Quits: danielfilho (~danielfilho@public.cloak) (Client closed connection)
# [15:23] * Joins: danielfilho (~danielfilho@public.cloak)
# [15:24] * Quits: isherman-book (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [15:26] * Joins: abucur (~Adium@public.cloak)
# [15:52] * Joins: isherman-book (~Adium@public.cloak)
# [16:02] * Joins: tantek (~tantek@public.cloak)
# [16:05] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [16:05] * Quits: isherman-book (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [16:07] * Joins: tmpsantos (~tmpsantos@public.cloak)
# [16:11] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [16:33] * Joins: isherman-book (~Adium@public.cloak)
# [16:38] * Quits: tantek (~tantek@public.cloak) (tantek)
# [16:47] * Quits: isherman-book (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [16:55] * Joins: mibalan (~chatzilla@public.cloak)
# [16:57] * Quits: mibalan (~chatzilla@public.cloak) ("ChatZilla 0.9.89 [Firefox 18.0.1/20130116073211]")
# [17:02] * plinss_away is now known as plinss
# [17:02] * Joins: SimonSapin (~simon@public.cloak)
# [17:05] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [17:05] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:06] * Quits: liam (liam@public.cloak) (Ping timeout: 60 seconds)
# [17:08] * Joins: dbaron (~dbaron@public.cloak)
# [17:12] * Joins: glenn (~gadams@public.cloak)
# [17:15] * Joins: glazou (~glazou@public.cloak)
# [17:15] * Joins: isherman-book (~Adium@public.cloak)
# [17:21] * Joins: Kazutaka (~Kazutaka@public.cloak)
# [17:26] <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.
# [17:26] <dbaron> jdaggett: Bert, would you mind that?
# [17:26] <dbaron> Bert: I don't mind, but it's a lot of work.
# [17:26] * Quits: isherman-book (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [17:27] * Joins: smfr (~smfr@public.cloak)
# [17:30] * smfr changes topic to 'http://wiki.csswg.org/planning/tucson-2013'
# [17:31] <dbaron> [discussion]
# [17:31] <dbaron> Peter: Anolis is also more self-contained.
# [17:31] * Joins: SteveZ (~chatzilla@public.cloak)
# [17:32] * Ms2ger listens
# [17:32] <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
# [17:32] * trackbot is creating a new ACTION.
# [17:32] <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].
# [17:32] * Joins: koji (~koji@public.cloak)
# [17:32] * Joins: jdaggett (~jdaggett@public.cloak)
# [17:33] * jdaggett good morning tucson!
# [17:34] <fantasai> ScribeNick: fantasai
# [17:34] * Joins: tantek (~tantek@public.cloak)
# [17:34] <dbaron> Topic: Variables, continued
# [17:34] * Joins: TabAtkins_ (~TabAtkins@public.cloak)
# [17:34] <fantasai> dbaron: We had some discussion on list about what exactly should and shouldn't be allow in variables.
# [17:34] <fantasai> dbaron: Simple change I would like to make
# [17:35] <fantasai> dbaron: Current rules have quirk that CDO/CDC are only allowed if they're inside braces, but not at top level
# [17:35] <fantasai> dbaron: Would like to change this.
# [17:35] <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Feb/0196.html
# [17:35] <fantasai> dbaron: Some other discussion about rules
# [17:36] <fantasai> dbaron: Remaining discussion was wrt allowing unmatched constructs
# [17:36] <fantasai> dbaron: I'm queasy about that
# [17:36] <dbaron> fantasai: Would break forward-compatible parsing.
# [17:37] <fantasai> TabAtkins: Only proposing to add closing brackets
# [17:37] <fantasai> dbaron: I meant six things
# [17:37] <fantasai> dbaron: Opening brackets, braces, parens, baduri, badstring, bad...
# [17:37] <fantasai> dbaron: These consume to end of file
# [17:37] <dbaron> s/bad.../badcomment/
# [17:38] <dbaron> dbaron: except for baduri and badstring
# [17:38] <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
# [17:39] <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]
# [17:40] <fantasai> RESOLVED: Can't put unmatched brackets, praces, parens in variables
# [17:40] <fantasai> (unless escaped)
# [17:40] <dbaron> s/praces/braces/
# [17:40] * Joins: rhauck (~Adium@public.cloak)
# [17:40] <fantasai> RESOLVED: Accept CDO/CDC at top level in variableshttp://lists.w3.org/Archives/Public/www-style/2013Feb/0196.html
# [17:41] <fantasai> dbaron: baduri is very much like an unmatched opening paren
# [17:42] <fantasai> RESOLVED: No badstring in variables
# [17:42] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [17:43] <fantasai> dbaron: I'm ok with accepting badurl, but would like to review the text before going to LC
# [17:43] <fantasai> plinss: I'm a little uncomfortable accepting badurl...
# [17:43] <fantasai> TabAtkins: It's like a function token
# [17:44] <fantasai> plinss: It takes other things inside that though
# [17:44] <fantasai> plinss: Inside a URL token, can't you have unmatched square brackets?
# [17:44] <fantasai> dbaron: Yes
# [17:44] <fantasai> plinss: That's dangerous
# [17:44] * Joins: Rossen (~Rossen@public.cloak)
# [17:44] <fantasai> plinss: I don't think you're gaining a whole lot by accepting badurl
# [17:44] <fantasai> plinss: The URL token is a realy odd weird piece of CSS parsing
# [17:45] <fantasai> plinss: I suspect we'd be opening up a danger zone and break something down the road
# [17:45] <dbaron> fantasai: I think it's safer not to accept badurl, and it's a very weak use case.
# [17:45] <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
# [17:46] <fantasai> RESOLVED: badurl is not allowed in variables
# [17:46] <dbaron> (so all the resolutions here except for the CDO/CDC change are no-change resolutions)
# [17:47] <dbaron> Topic: discussing whether to discuss placeholder styling
# [17:47] <fantasai> Topic: Placeholders
# [17:47] <fantasai> TabAtkins: My proposal is to do the placeholder pseudo-class and fill-opacity
# [17:47] <fantasai> TabAtkins: which fantasai called her crazy proposal
# [17:48] <fantasai> TabAtkins: I know dbaron had an objection to fill-opacity, didn't get into it
# [17:48] <dbaron> glazou: discussion limited to 20 minutes
# [17:49] <fantasai> dbaron: I'm not objecting to doing it, objecting to making decent placeholder styling depend on that
# [17:49] <fantasai> tantek: Would fill-opacity affect existing pages?
# [17:50] <fantasai> TabAtkins: No. You just multiply color's alpha by fill-opacity and use that. Very simple.
# [17:50] <dbaron> s/existing pages/performance of existing pages using placeholder/
# [17:50] <fantasai> smfr: A little odd to do fill-opacity without fill
# [17:51] <fantasai> dbaron: My concern is web-compat implications
# [17:51] * 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
# [17:51] <fantasai> dbaron: Maybe people are using it and expecting it to have no effect
# [17:51] <dbaron> ... outside of SVG
# [17:51] <fantasai> TabAtkins: Same problem with other SVG properties we import
# [17:52] <fantasai> tantek: We could add fill-opacity, leave placeholder issue open
# [17:52] <fantasai> dbaron: Point is I want placeholder issue resolved in a timeframe that's faster than resolving fill-opacity
# [17:52] <fantasai> dbaron: I'm fine with pseudo-class + pseudo-element
# [17:52] <dbaron> Tab: I think the only problem there was that we couldn't decide on names.
# [17:54] <dbaron> [tab sets up a possibility table on the whiteboard]
# [17:54] <fantasai> szilles: Could you describe what each thing is?
# [17:54] <fantasai> TabAtkins: ::placeholder is a box immediately containing the placeholder text
# [17:54] <fantasai> TabAtkins: :placeholder is a pseudo-class that matches the input element when the placeholder is showing
# [17:55] <fantasai> TabAtkins writes various options on the whiteboard
# [17:56] * Joins: isherman-book (~Adium@public.cloak)
# [17:56] <fantasai> :placeholder
# [17:56] <fantasai> :has-placeholder
# [17:56] <fantasai> :showing-placeholder
# [17:56] <fantasai> :placeholder-showing
# [17:56] <fantasai> :placeholding
# [17:56] <fantasai> ::placeholder
# [17:56] <fantasai> ::placeholder-text
# [17:56] <fantasai> ::placeholder-content
# [17:56] <fantasai> ::placeholder-value
# [17:57] * stearns ::value?
# [17:57] <dbaron> Tantek: eliminate ::value because of sylvaing's use case about fading out the placeholder while typing
# [17:57] <stearns> ok
# [17:57] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 60 seconds)
# [17:57] <dbaron> ?: eliminate ::placeholder-text because of Bert's objection that it might not be text
# [17:58] <dbaron> fantasai: Authors might be more likely to go for the one that's called "placeholder"
# [17:58] <dbaron> fantasai: Also if one author uses pseudo-class and the other uses pseudo-element, cascading rules don't apply
# [17:58] * stearns has a preference for ::placeholder and some other name for the pseudo-class, as ::placeholder matches the HTML attribute
# [17:58] * Joins: Rossen (~Rossen@public.cloak)
# [17:59] <dbaron> dbaron: That same confusion happens with nested elements.
# [17:59] <dbaron> Tantek: agree with dbaron; it's an existing style sheet cross
# [17:59] <dbaron> ... -organizational problem
# [17:59] * fantasai thinks she agrees with stearns, but isn't sure whta to call the other thing
# [18:00] * stearns :showing-placeholder makes the most sense to me
# [18:00] <dbaron> I'm in favor of ::placeholder and :showing-placeholder as well.
# [18:00] <fantasai> Bert: I agree with fantasai, I think authors will think of the two as being mostly the same thing
# [18:00] * fantasai agrees with dbaron and stearns
# [18:00] <dbaron> Tab and Peter want :placeholder and either ::placeholder-{content,value}
# [18:01] * glazou agrees with dbaron and stearns and fantasai
# [18:01] * Joins: lmclister (~lmclister@public.cloak)
# [18:01] <fantasai> tantek: Prever :has because it's shorter
# [18:01] <fantasai> smfr: Problem with has is that it might mean "has a placeholder attribute"
# [18:02] * SimonSapin agrees on ::placeholder and ( :showing-placeholder or :placeholder-showing )
# [18:02] <dbaron> :placeholder-shown ?
# [18:02] * Bert :waiting, :pre-fill, :hinted, :prompt
# [18:02] * Quits: leif (~lstorset@public.cloak) ("Leaving.")
# [18:02] <fantasai> tantek: :placeholder-shows
# [18:02] <fantasai> plinss: :placeholder-active
# [18:02] <fantasai> plinss: :placeholder-visible
# [18:02] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 60 seconds)
# [18:03] * Quits: isherman-book (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [18:03] * Joins: Rossen (~Rossen@public.cloak)
# [18:04] <dbaron> loooking at HTML5 spec's terminology leads to :placeholder-presented, which nobody likes
# [18:04] <dbaron> Tantek: :shows-placeholder ?
# [18:05] * Joins: JohnJansen (~JohnJansen@public.cloak)
# [18:06] <fantasai> Straw Poll
# [18:06] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 60 seconds)
# [18:06] <fantasai> A :placeholder-shows
# [18:06] <fantasai> B :placeholder-active
# [18:06] <fantasai> C :placeholder-visible
# [18:06] <fantasai> D :shows-placeholder
# [18:06] <fantasai> E :placeholder-shown
# [18:07] <fantasai> glazou: E
# [18:07] <fantasai> jdaggett: abstain
# [18:07] <fantasai> SimonSapin: E
# [18:07] <fantasai> dbaron: C
# [18:07] <fantasai> glenn: abstain
# [18:07] <fantasai> koji: abstain
# [18:07] <fantasai> fantasai: abstain
# [18:07] <dbaron> smfr: C
# [18:07] <fantasai> Rossen: abstrain
# [18:07] <dbaron> Tantek: D
# [18:07] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 60 seconds)
# [18:07] <dbaron> 2 abstains
# [18:07] <fantasai> The Japanese Delegation abstains
# [18:07] <dbaron> Steve: weak E
# [18:07] <dbaron> Bert: abstain
# [18:08] <dbaron> Peter: Still prefer :placeholder and ::something-more
# [18:08] <fantasai> plinss: votes for the write-in candidate
# [18:08] <dbaron> Tab: C, though I prefer plinss's write-in-candidate
# [18:08] <fantasai> Conclusion: E vs. C
# [18:09] * Quits: JohnJansen (~JohnJansen@public.cloak) ("Page closed")
# [18:09] <fantasai> glazou: I think from international audience, I think best is :placeholder-shown
# [18:09] <fantasai> glazou: It's understandable. Does not confuse with visibility property
# [18:09] * stearns C might be better than E - visible may be in more people's vocabularies than shown
# [18:09] <dbaron> Tab: any objections to E?
# [18:09] <fantasai> RESOLVED: :placeholder-shown & ::placeholder adopted
# [18:10] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [18:10] * Quits: tmpsantos (~tmpsantos@public.cloak) ("Leaving")
# [18:10] <fantasai> Topic: Regions Update
# [18:10] <fantasai> szilles: Many, but not all, were at meetup last night
# [18:10] <fantasai> szilles: Main new thing is that there's a polyfill out there
# [18:11] <fantasai> szilles: Runs on any moder browser
# [18:11] <fantasai> szilles: a) function complete, and b) perf-challenged
# [18:11] <smfr> s/moder/modern
# [18:11] <fantasai> szilles: But allows experimenting with the concepts
# [18:11] * Joins: tantek (~tantek@public.cloak)
# [18:11] <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
# [18:11] <stearns> s/function/not function/ ??
# [18:12] <fantasai> szilles: Both Bert and Håkon replied that this deals with their objection.
# [18:12] <fantasai> szilles: That's the essence of what I wanted to say.
# [18:12] <fantasai> szilles: questions or concerns?
# [18:12] <fantasai> glazou: We don't have no mechanism for easy/fast prototyping of CSS features
# [18:13] <fantasai> glazou: Long ago a proposal for having selectors that map to JS boolean method
# [18:13] <fantasai> glazou: We need to think about a way for prototyping CSS features via JS
# [18:13] <fantasai> glazou: Would allow larger experiments and tests
# [18:13] <TabAtkins_> See my recent blog post over this exact topic: http://www.xanthir.com/b4N80
# [18:13] <fantasai> glazou: Web community needs it, we could also use ourselves, something to think about for the future
# [18:13] <TabAtkins_> +1
# [18:14] <stearns> see also: http://www.w3.org/community/nextweb/
# [18:15] <SteveZ> URL for Regions Polyfill: http://adobe-webplatform.github.com/css-regions-polyfill/
# [18:16] <fantasai> Topic: Conditional Rules
# [18:16] * Joins: Rossen (~Rossen@public.cloak)
# [18:16] <dbaron> Topic: Regions, continued
# [18:16] <fantasai> Bert: The web component example refers to the web components in the HTML, not from the CSS
# [18:16] <fantasai> Bert: So you still can't do this from CSS
# [18:16] <fantasai> szilles: I thought we had some kind of include
# [18:17] <fantasai> Bert: Yes, that's what we discussed
# [18:17] <fantasai> Bert: But it appears not to be there
# [18:17] <fantasai> Bert: So you still can't reuse the style sheet
# [18:17] <fantasai> Bert: you need to change the HTML file if you want to change style
# [18:17] <fantasai> Bert: There is no other way, apparently
# [18:18] <fantasai> szilles: Ok, I will take that comment back
# [18:18] <fantasai> szilles: If there was a way of including a template description via stylesheet instead of via HTML
# [18:19] <stearns> there is a way using decorators, but that's not as far along as templates
# [18:19] <stearns> I showed a decorator example on the wiki page
# [18:19] <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
# [18:20] * Joins: sylvaing (~sylvaing@public.cloak)
# [18:20] <fantasai> tantek: To put another way, you can make that decision via media queries
# [18:20] <fantasai> fantasai^: And the comment from Bert is that this example does not meet that requirement
# [18:21] <fantasai> tantek: I'd say what fantasai says, except s/markup/content/
# [18:21] * Quits: sylvaing (~sylvaing@public.cloak) ("")
# [18:21] <fantasai> tantek: I'd also say, our examples should be exemplary, not bad examples, but show best practice
# [18:21] * sylvaing_away is now known as sylvaing
# [18:21] <fantasai> tantek: Path of sending different markup is a bad path in general. Causes problems across browsers, esp. non-majority browsers, across devices
# [18:22] <fantasai> tantek: Anything we can do to discourage sending different markup is a good thing
# [18:22] <fantasai> glazou: Anything else on Regions?
# [18:22] <stearns> web components are bad practice?
# [18:22] <fantasai> Bert: Assuming we do this Web Components, where should it be defined that you can include Web Components?
# [18:23] <fantasai> Bert: Where is the syntax defined for including the Web Components?
# [18:23] <fantasai> TabAtkins: In the Web Components spec
# [18:23] <fantasai> Bert: But that doesn't define a CSS syntax
# [18:23] <fantasai> Bert: If you include a style sheet, that style sheet has to in turn somehow include a Web Component
# [18:24] <fantasai> TabAtkins: Use <link>
# [18:24] <fantasai> Bert: That doesn't work for XML
# [18:24] <fantasai> szilles: I have some ideas
# [18:24] <fantasai> szilles: Need to think about it
# [18:25] <fantasai> ACTION Steve: figure out how to link web components templates for using regions via CSS
# [18:25] * trackbot is creating a new ACTION.
# [18:25] * RRSAgent records action 1
# [18:25] <trackbot> Created ACTION-538 - Figure out how to link web components templates for using regions via CSS [on Steve Zilles - due 2013-02-13].
# [18:25] <fantasai> Topic: Conditional Rules
# [18:25] * sylvaing oh great, there is ::placeholder pseudo-element. No doubt, the DoubleTree provides peyote to its guests
# [18:26] * fantasai gave sylvaing honorary mention in her talk about spec-writing last night
# [18:27] * sylvaing whoa.
# [18:27] * fantasai for fulfilling the role of making snarky comments on IRC during the meetings :)
# [18:27] * fantasai and doing a damn good job of it
# [18:27] <dbaron> http://dev.w3.org/csswg/css3-conditional/doc-20121213-LCWD.txt
# [18:27] * Joins: kawabata (~kawabata@public.cloak)
# [18:28] * sylvaing I think you're calling me the court jester
# [18:28] <fantasai> dbaron: First issue is editorial, improving examples
# [18:28] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Dec/0277.html
# [18:28] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [18:28] * Joins: glenn (~gadams@public.cloak)
# [18:29] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Dec/0330.html
# [18:29] <fantasai> 3rd issue http://lists.w3.org/Archives/Public/www-style/2013Jan/0070.html
# [18:29] <fantasai> "What does @supports return when the OS prevents the support?"
# [18:30] <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?"
# [18:30] <fantasai> dbaron: My inclination is to say not pay attention to that
# [18:30] <fantasai> dbaron: These can be considered UA stylesheet rules
# [18:30] <fantasai> dbaron: In some cases, might not want to expose this information
# [18:31] <fantasai> jdaggett: I think this is a very slippery slope
# [18:31] <fantasai> dbaron: In which direction?
# [18:31] <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
# [18:31] <fantasai> dbaron: So in favor of saying that it does not affected by this stuff
# [18:31] <fantasai> jdaggett: yes
# [18:31] <fantasai> jdaggett: Should be very cut and dry
# [18:31] <fantasai> plinss: I agree with that
# [18:31] <fantasai> plinss: Also, those sorts of thing,s if they're going to be exposed, should be via media queries
# [18:32] <fantasai> plinss: You don't say you don't support color if you're on a monocrhome display
# [18:32] <dbaron> dbaron: That's exactly what I was going to say.
# [18:32] <fantasai> SimonSapin: @supports should match whether declarations are handled as invalid
# [18:32] <dbaron> (er, last 2 in previous order)
# [18:32] * Joins: isherman-book (~Adium@public.cloak)
# [18:32] <fantasai> dbaron: Sounds like we're all in favor of saying that it's not affected by things like UA preferences
# [18:33] <fantasai> dbaron: Add text to the spec saying that
# [18:33] <fantasai> RESOLVED: @supports is not affected by limitations imposed by UA or system
# [18:33] <dbaron> or user preferences
# [18:33] <fantasai> s/UA/user prefs/
# [18:33] <fantasai> 4th issue
# [18:33] <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Jan/0436.html
# [18:34] <fantasai> dbaron: Replied to reject [explains rationale in message]
# [18:34] <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Jan/0442.html
# [18:35] <fantasai> fantasai: I agree with your rationale
# [18:35] <fantasai> fantasai: If we want to go in that direction, should add some syntax for flagging individual lines as required.
# [18:35] <fantasai> fantasai: But not doing that right now anyway.
# [18:35] <fantasai> 5th issue
# [18:35] * Joins: jarek (~jarek@public.cloak)
# [18:36] <fantasai> dbaron: WebApps posted API issues
# [18:36] <fantasai> dbaron: Made some edits to clarify
# [18:36] <fantasai> dbaron: One thing I need to figure out, need to test what implementations do
# [18:36] <fantasai> dbaron: Haven't had a chance to do that yet
# [18:36] <fantasai> fantasai: Can anyone else help with that?
# [18:36] <fantasai> dbaron: It's error handling for insertRule
# [18:36] <fantasai> dbaron: Same question exists for the style sheet object
# [18:36] <fantasai> dbaron: We should come back on this one
# [18:37] <fantasai> 6th issue should come back on
# [18:37] <fantasai> dbaron: It's a long message sent not too long before LC
# [18:37] <fantasai> dbaron: Rewrote a bunch of stuff, have to figure out whether addressed or not
# [18:37] <fantasai> dbaron: Don't think we're quite ready for CR
# [18:37] <fantasai> dbaron: But maybe next telecon
# [18:38] <fantasai> [discussion of scheduling next telecon]
# [18:38] <fantasai> ppl travelling next week, so next call is the 20th
# [18:39] <fantasai> <br type=coffee>
# [18:42] * Quits: TabAtkins_ (~TabAtkins@public.cloak) (Ping timeout: 60 seconds)
# [19:00] <Bert> Scribenick: bert
# [19:00] <Bert> Topic: fonts
# [19:00] <Bert> jdaggett: What should the LC period be?
# [19:00] <Bert> ... It's a big spec
# [19:01] <Bert> ... 6 weeks? 2 months?
# [19:01] <Bert> fantasai: no more than 6 weeks
# [19:01] <Bert> ... You can do a 2nd LC
# [19:01] <Bert> jdaggett: So plan for 2 LCs?
# [19:01] <Bert> fantasai: Can also offer an extension after a while.
# [19:01] <Bert> dbaron: And wait a bit after the daedline
# [19:01] <Bert> ... because there will be late comments.
# [19:02] <Bert> glazou: Officially not obliged to respond after deadline.
# [19:02] <Bert> ... But in practice...
# [19:02] <Bert> jdaggett: So 6 weeks then
# [19:02] <Bert> ... Aks Webapps, SVG and i18n for cooments
# [19:02] <Bert> fantasai: LC or WD?
# [19:02] <Bert> jdaggett: First a WD.
# [19:03] <Bert> Topic: multicol
# [19:03] <fantasai> SimonSapin: Discussed multicol at tpca
# [19:03] <fantasai> SimonSapin: Problem with pseudo-algorithm, which has concept of unknown available widht, and I don't think it makes sense
# [19:03] <fantasai> SimonSapin: Don't see a situation in which that happens
# [19:04] <fantasai> SimonSapin: After long discussion with Håkon and Bert, f2f and email, still don't have a resolution
# [19:04] <fantasai> SimonSapin: Underlying issue is that from what I understand from Bert's explanation,
# [19:04] <fantasai> SimonSapin: this condition is triggered when you calculate intrinsic sizes of a multicol element
# [19:04] <fantasai> SimonSapin: The issue then is that we have two definitions of this
# [19:04] <fantasai> SimonSapin: One in sizing, one in box
# [19:05] <fantasai> SimonSapin: But whichever we pick, neither of them defines available width == unknown
# [19:05] <fantasai> Bert: Multicol relies only on level 2
# [19:05] <fantasai> Bert: And CSS2.1 doesn't define shrink-to-fit in many cases
# [19:05] <fantasai> Bert: So cases where it's shrink-to-fit are undefined
# [19:06] <fantasai> Bert: Multicol cannot defined actual size of columns because it relies on shrink-to-fit algorithm
# [19:06] <fantasai> Bert: And multicol doesn't want to define it either
# [19:06] <fantasai> Bert: need a sizing algo ot define shrink-to-fit
# [19:06] <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
# [19:06] <dbaron> fantasai: ... and then deal with that in a later module
# [19:07] <fantasai> szilles: Could add a note pointing to where the definition might appear, or a suggested strategy
# [19:07] <Ms2ger> s/tpca/tpac/
# [19:08] <fantasai> dbaron: I would rather partially define it than say it's undefined
# [19:08] <fantasai> Bert: It defines what the final width if you have both number of columns and column width
# [19:09] <fantasai> Bert: If either one is missing, then can't calculate
# [19:09] <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
# [19:09] <dbaron> fantasai: Saying the multicol is exactly the column-width times column-count violates that formula
# [19:10] <dbaron> fantasai: the narrowest a multi-column element can take ... drops columns rather than overflowing
# [19:10] <dbaron> fantasai: ... when the window is narrow... so you stay within the containing block
# [19:10] <dbaron> fantasai: The formula that says you multiply the width by the column count violates the shrink-to-fit formula.
# [19:11] <fantasai> Bert: If you set the column width and column count, that's what you should get
# [19:11] <fantasai> fantasai: But you don't get that
# [19:11] <glazou> ScribeNick: jdaggett
# [19:12] <SimonSapin> http://dev.w3.org/csswg/css3-multicol/#pseudo-algorithm
# [19:12] <jdaggett> bert: discussing col-width and number of columns
# [19:13] <SimonSapin> lines 5~8
# [19:13] <jdaggett> simon: bert is talking
# [19:13] <jdaggett> bert: 8 possible cases
# [19:13] <jdaggett> bert: this alg is trying to compactly specify this
# [19:14] <dbaron> q+ to say that it shouldn't be talking about shrink-to-fit
# [19:14] <jdaggett> simon: so you're saying in the case of mult-col with width this alg applies?
# [19:14] <jdaggett> bert and simon talking about 2.1 vs. this alg
# [19:14] <jdaggett> simon: this is contradiction with 2.1 alg
# [19:15] <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)."
# [19:15] <jdaggett> dbaron: other specs shouldn't talk about shrink to fit
# [19:15] <dbaron> dbaron: they should talk about preferred intrinsic width and minimum intrinsic width
# [19:15] <fantasai> dbaron: They should talk about preferred minimum width and minimum width, which are the inputs to shrink-to-fit
# [19:15] <SimonSapin> Floats: "If 'width' is computed as 'auto', the used value is the "shrink-to-fit" width. "
# [19:15] <jdaggett> fantasai: i agree with dbaron
# [19:16] <jdaggett> fantasai: they can use shrink to fit but they shouldn't define it
# [19:16] <jdaggett> bert: so lines 5-8 should be...
# [19:17] <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.
# [19:17] <dbaron> Bert: so min intrinsic should be column-count * column-width
# [19:17] <Bert> (lines 05-08 effectively say that the min intrinsic width is N * W + (N - 1) * gap)
# [19:17] <dbaron> fantasai: But it shouldn't be, because it won't overflow if it's smaller than that.
# [19:18] <dbaron> fantasai: ... since a multicol can be narrower than that without overflow
# [19:18] <jdaggett> bert: the user says i want that width, so that's the min width
# [19:18] <jdaggett> dbaron: there are cases
# [19:18] <fantasai> dbaron: There are cases where it is appropriate for a minimum width to be ...
# [19:18] <fantasai> fantasai: You can't define table layout sensibly if you define it some other way
# [19:18] <fantasai> dbaron: We could decide that it's better for the minimum intrinsic width to use or ignore column count
# [19:19] <fantasai> dbaron: Doesn't have to be strictly in terms of what causes overflow, because that's a primitive and strict definition
# [19:19] <dbaron> s/strict/incorrect/
# [19:19] <jdaggett> bert: dbaron is correct but that's what we did in multi-col
# [19:19] <jdaggett> simon: so the multi-col is defining min-width
# [19:19] <jdaggett> bert: yes, should mention that...
# [19:19] <dbaron> Simon: I see no relationship between what's written and defining minimum intrinsic width
# [19:19] <jdaggett> simon: so what is max-width?
# [19:20] <fantasai> dbaron: In case where column widht and column-count are both specified, max-content should include both of them
# [19:20] <fantasai> dbaron: More interesting if some aren't specified
# [19:20] <jdaggett> fantasai: tab and i worked through some examples for flexbox
# [19:20] <jdaggett> fantasai: since we use these concepts everywhere
# [19:21] <fantasai> http://dev.w3.org/csswg/css3-sizing/#multicol-intrinsic
# [19:21] <jdaggett> fantasai: the results should be consistent
# [19:21] <dbaron> fantasai: and we wrote a spec for that, which is not consistent with what multicol sys
# [19:21] <jdaggett> stevez: section 19-23 talks about behavior
# [19:23] <dbaron> jdaggett: Seems like multiple specs are involved; should there be an action on Bert, fantasai, Simon, dbaron to decide what should happen where?
# [19:23] <dbaron> fantasai: I think the problem is we've brought this up at every face-to-face and there's no agreement.
# [19:23] <jdaggett> fantasai: happens repeatedly at f2f
# [19:24] <dbaron> fantasai: Maybe would help if dbaron got involved?
# [19:24] <jdaggett> stevez: the disagreement is on min?
# [19:24] <dbaron> SteveZ: Is the disagreement only on min? clear what preferred is.
# [19:24] <jdaggett> simon: can we agree that multi-col should not define min-width or max-width?
# [19:24] <dbaron> s/min-width or max-width/min-content or max-content widths/
# [19:25] <jdaggett> simon and bert discussing which spec should define this
# [19:26] <dbaron> Bert: The sizing spec would then have to define every type of box, and thus never be done.
# [19:26] <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
# [19:26] <jdaggett> fantasai: b/c multi-col is further along
# [19:26] <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
# [19:26] <jdaggett> fantasai discussing size vs. box specs
# [19:26] <dbaron> fantasai: but multicol is already in CR
# [19:26] <jdaggett> bert: i agree
# [19:27] <dbaron> Bert: I agree with that, but multicol cannot completely define things without knowing intrinsic widths of what's inside
# [19:27] <jdaggett> stevez: if i have a col width, then that is the min intrinsic width?
# [19:27] <dbaron> fantasai: Multicol can assume that the things inside the columns have preferred intrinsic and minimum widths
# [19:27] <jdaggett> fantasai: yes
# [19:27] <jdaggett> fantasai: multi-col is tricky
# [19:28] <jdaggett> fantasai: sizing dealt with what happens when the containing block varies
# [19:28] <jdaggett> fantasai: and we put results into the defn
# [19:28] <jdaggett> fantasai discussing relation with table sizing alg
# [19:29] <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
# [19:30] <fantasai> szilles: So special thing wrt multicol is that the optimal width is neither minimum nor the maximum
# [19:30] <jdaggett> stevez discussing details of multi-col alg
# [19:30] <dbaron> fantasai: You almost never get exactly the column-width you asked for.
# [19:31] <fantasai> szilles: Wrt getting 2.1 shrink-to-fit, there's no harm in throwing away the column count
# [19:31] <fantasai> szilles: and doing the right thing to get the smallest value
# [19:31] <jdaggett> stevez: don't see the harm in throwing away column count
# [19:31] <jdaggett> fantasai: that would make it work as the screen size changes
# [19:31] <jdaggett> bert: that's the author's choice
# [19:32] <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.
# [19:32] <jdaggett> fantasai: for an inflow block you don't get what you ask for
# [19:32] <dbaron> fantasai: So we should do the same thing for floats, and not include column-count in the minimum intrinsic width.
# [19:32] <dbaron> I think fantasai is correct that column-count shouldn't factor into minimum intrinsic widths for multicols.
# [19:32] <jdaggett> stevez: calc min width, then apply 19-23
# [19:33] <fantasai> dbaron, well, it should if column-width is not specified, because then you don't drop columns...
# [19:33] <fantasai> dbaron, but if both are specified, yes
# [19:33] <jdaggett> bert: that could have been a choice
# [19:33] <jdaggett> bert: it's easier to use what multi-col does now
# [19:34] <jdaggett> stevez: this is the argument if what you want is overflow
# [19:34] <dbaron> fantasai: I don't think we should overflow by default in some cases when the normal behavior is not to overflow.
# [19:35] <jdaggett> fantasai stevez bert discussing details of the multi-col alg
# [19:36] <fantasai> Bert: This case isn't the improtant one, could go either way, tho would prefer not to change it
# [19:36] <jdaggett> glazou: simon is not happy with one of the specs, we have to solve
# [19:36] <fantasai> Bert: Interesting cases are the next two
# [19:37] <fantasai> SimonSapin: Issue is with concept of unknown available width in the multicol module
# [19:37] <jdaggett> simon: we can decide either way but i'm objecting to how it's done in multi-col
# [19:37] <fantasai> SimonSapin: I'm objecting to the way it's done in multicol right now
# [19:37] <jdaggett> stevez: is that form or content, the results or how it's specified?
# [19:37] <dbaron> Steve: the results or the way it's specified?
# [19:37] <jdaggett> simon: how it's specificed
# [19:37] <jdaggett> fantasai: i don't like the results
# [19:38] <jdaggett> dbaron: i agree with both objections, how it's specified and the results
# [19:38] * Joins: TabAtkins_ (~TabAtkins@public.cloak)
# [19:39] * Quits: dino (~dino@public.cloak) (dino)
# [19:39] <jdaggett> dbaron: the only way out of this is to remove instrinsic width details from multi-col
# [19:39] <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)
# [19:40] <jdaggett> simon and bert discuss dependencies of alg in different specs
# [19:41] <jdaggett> sizing solves all?
# [19:41] <jdaggett> fantasai: remove from multi-col and work on in sizing
# [19:41] <jdaggett> fantasai: it's an early WD so we can incorporate other layout models
# [19:41] <jdaggett> fantasai: that's what's needed
# [19:42] <jdaggett> bert resisting
# [19:42] <jdaggett> fantasai: i want to take the fixes that were proposed by simon
# [19:42] <jdaggett> simon: the changes from tpac leaves some things undefined, to be defined by sizing
# [19:43] <dbaron> Simon: Changes I proposed were to remove all the parts of multicol algorithm related to "unknown available width"
# [19:43] <jdaggett> bert resisting
# [19:43] <jdaggett> stevez: to be clear, you're saying remove 5-8 and width alg in sizing?
# [19:43] <dbaron> Simon: I want to remove the idea that available width can be unknown.
# [19:44] <TabAtkins_> Dont' resist, Bert. Come to the dark side...
# [19:44] <dbaron> dbaron: There is and should be no concept of "unknown available width".
# [19:44] * glazou TabAtkins you finally disclose you're bert's dad ?-)
# [19:45] <jdaggett> discussion of where available width is
# [19:45] * TabAtkins_ glazou NOOOOOOOOOOOOOOOOOOOO
# [19:46] <jdaggett> dbaron and bert discussing widths some more
# [19:46] <jdaggett> and so on and so on...
# [19:46] <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
# [19:46] <jdaggett> repeat while (true) discuss width;
# [19:47] <jdaggett> discussion of unknown available width
# [19:48] <dbaron> dbaron: the rules for preferred and minimum intrinsic widths don't deal with a concept of available width
# [19:48] * sylvaing Bert as Luke Skywalker sounds pretty epic
# [19:48] <dbaron> dbaron: the rules for intrinsic width calculation should be separate from that algorithm, and there should be no concept of "unknown available width"
# [19:48] * Joins: rhauck (~Adium@public.cloak)
# [19:48] <fantasai> SimonSapin: Where multicol says "available width", it should say "used width"
# [19:49] <jdaggett> simon: when multi-col says avaiable width it should say "available width of multi-col element"
# [19:49] <SimonSapin> s/"available width of multi-col element"/"used width of multi-col element"/
# [19:49] <dbaron> SteveZ: Can we resolve to switch multicol from an 8-part algorithm to 4-part algorithm?
# [19:49] <jdaggett> bert: now we're making things more undefined
# [19:50] <jdaggett> simon: yes
# [19:50] * sylvaing CSS: now with more undefined
# [19:52] <jdaggett> glazou: the discussion is going in circles
# [19:52] <jdaggett> stevez: throw out the cause of the disagreement and procede
# [19:52] <jdaggett> stevez: not ideal but practical for proceeding with the CR
# [19:52] <glazou> I suggest the corsican way ; we vite, throw the poll boxes to the sea, lock the room and the last survivor wins
# [19:52] <glazou> s/vite/vote
# [19:54] <jdaggett> discussions of scope of multi-col pseudo-alg
# [19:54] <jdaggett> bert resisting
# [19:54] <fantasai> fantasai: Scope of the pseudo-algorithm should be to calculate the number and width of the columns
# [19:55] <fantasai> fantasai: It should take as input a used width (calculated by the various layout algorithms as appropriate), column-count, and column-width
# [19:55] * sylvaing RESOLVED: must add a 'bert resisting' meme
# [19:55] <fantasai> Bert: That's what it does already
# [19:55] * jdaggett should be an emoji character
# [19:55] <fantasai> fantasai: No, it tries to calculate a width in some cases
# [19:55] <fantasai> it should not do that.
# [19:55] * sylvaing jdaggett YES
# [19:56] <fantasai> SimonSapin: This algorithm does 2 things. I am proposing to move one half into sizing or anothe rmodule
# [19:56] <jdaggett> simon: this alg does two things, i suggest moving half to sizing
# [19:56] <fantasai> SimonSapin: These two things are really different, and confusing to do them both with the same algorithm
# [19:56] <jdaggett> simon: the two things are different, confusing to do with the same alg
# [19:56] * sylvaing IRC echo is enabled
# [19:56] <jdaggett> bert: might well be but how do we keep track
# [19:57] <jdaggett> bert: why not do in multi-col?
# [19:57] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [19:58] <jdaggett> stevez: doesn't seem to make sense to do in multi-col
# [19:58] <jdaggett> dbaron: any layout type can define these independently
# [19:58] <jdaggett> dbaron: defn in multi-col is totally unreasonable
# [19:58] <jdaggett> simon: could have in multi-col but hard to get right before CR
# [19:58] <dbaron> dbaron: I don't see any reason to pull it out of this module except that the definition in css3-multicol is unreasonable.
# [19:59] * Joins: rhauck (~Adium@public.cloak)
# [19:59] <jdaggett> rossen: sizing defines intrinsic sizing?
# [19:59] <jdaggett> bert: yes but can't define for all layout types
# [19:59] <jdaggett> simon: that's another issue
# [19:59] <jdaggett> bert: sizing alg can only do that for known layout types
# [20:00] <jdaggett> fantasai: they can use the terminology from sizing
# [20:00] <jdaggett> stevez: we haven't finished sizing yet
# [20:00] <jdaggett> stevez: so trying to define what multi-col does
# [20:00] <jdaggett> stevez: doesn't make sense
# [20:00] * Joins: rhauck1 (~Adium@public.cloak)
# [20:00] <jdaggett> dbaron: you can use the 2.1 terminology without any problems i think
# [20:01] <jdaggett> bert resisting
# [20:01] <dbaron> dbaron: I think the multicol intrinsic sizing rules are simple enough that (above)
# [20:01] <jdaggett> fantasai: it's going to take a lot of work to get right before CR
# [20:01] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [20:01] <jdaggett> fantasai: makes more sense to tackle them together in sizing
# [20:01] <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.
# [20:02] <jdaggett> bert thinking
# [20:02] <dbaron> SteveZ: can we import the text from css3-sizing into multicol?
# [20:02] <jdaggett> discussion of whether to use sizing text in multi-col
# [20:02] <dbaron> fantasai: Not stable enough yet.
# [20:03] * sylvaing jdaggett is defining a whole collection of bert emojis
# [20:03] <dbaron> fantasai: ... for a CR-level module. We can incorporate it into level 2 of multicol.
# [20:03] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [20:03] <jdaggett> stevez: the text in sizing wouldn't work to replace 5-8?
# [20:03] <jdaggett> fantasai: wouldn't do the same thing
# [20:04] <jdaggett> fantasai: might need to add more to deal with tables and floats
# [20:04] <fantasai> s/more/more concepts/
# [20:04] <fantasai> s/with/with both/
# [20:04] <jdaggett> bert: i could try rewriting this in terms of preferred intrinsic sizes defined in 2.1
# [20:05] <jdaggett> fantasai: better to file comments on the sizing spec
# [20:05] <jdaggett> fantasai: need to understand what the sizing spec is trying to solve
# [20:05] <jdaggett> bert: not sure that this fits the bill
# [20:06] <fantasai> fantasai: Might need to have separate concept of preferred size vs. max-content size for multicol elements
# [20:06] <jdaggett> glazou: need to wrap up
# [20:07] * Joins: kawabata_ (~kawabata@public.cloak)
# [20:07] <jdaggett> stevez: we're arguing over whether there's something in the multi-col spec that talks about intrinsic width
# [20:07] <jdaggett> fantasai: that's not a good idea
# [20:07] <jdaggett> bert: should ask implementors whether that's okay
# [20:08] <jdaggett> glazou: what's the plan?
# [20:08] <jdaggett> fantasai: remove 3-10 in the multi-col alg
# [20:09] <jdaggett> fantasai: then remove the concept of available width
# [20:09] <jdaggett> fantasai: define in terms of used width
# [20:10] <jdaggett> fantasai: then it becomes an issue on sizing
# [20:10] <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.)
# [20:10] <TabAtkins_> (So she can make reservations.)
# [20:10] <jdaggett> fantasai: accept or reject?
# [20:10] <jdaggett> bert thinking
# [20:11] <jdaggett> bert: we have to ask some people first
# [20:11] <jdaggett> bert: not objecting but if we remove it's a pity
# [20:12] <jdaggett> stevez proposing a and b points to add to multi-col
# [20:12] <jdaggett> stevez: a is intrinsic size is not defined in multi-col
# [20:12] <jdaggett> stevez: b is to add a note that it'll be defined in sizing (or some other non-normative place)
# [20:12] * Joins: teoli (~teoli@public.cloak)
# [20:13] <jdaggett> stevez: this is editorial so we can update
# [20:13] <jdaggett> bert: ok, so i'll propose new text
# [20:13] <jdaggett> resolved on the plan outlined above
# [20:15] <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
# [20:15] <jdaggett> <br type=昼飯>
# [20:15] <fantasai> ACTION Bert: Propose text for the resolution above
# [20:15] * trackbot is creating a new ACTION.
# [20:15] * RRSAgent records action 2
# [20:15] <trackbot> Created ACTION-539 - Propose text for the resolution above [on Bert Bos - due 2013-02-13].
# [20:17] <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.
# [20:17] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [20:17] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 60 seconds)
# [20:18] * Quits: smfr (~smfr@public.cloak) (smfr)
# [20:25] * plinss is now known as plinss_away
# [20:27] * plinss_away is now known as plinss
# [20:43] * Joins: smfr (~smfr@public.cloak)
# [20:44] * Quits: abucur (~Adium@public.cloak) (Client closed connection)
# [20:44] * Joins: florian (~florian@public.cloak)
# [20:44] * Quits: TabAtkins_ (~TabAtkins@public.cloak) (Ping timeout: 60 seconds)
# [20:45] <glazou> http://www.pasticheme.com/menu/default.cfm?slide=menu
# [20:48] * Quits: smfr (~smfr@public.cloak) (smfr)
# [20:58] * Quits: jarek (~jarek@public.cloak) (jarek)
# [21:00] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [21:00] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [21:02] * Quits: isherman-book (~Adium@public.cloak) (Client closed connection)
# [21:07] * Joins: isherman-book (~Adium@public.cloak)
# [21:17] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [21:21] * Joins: smfr (~smfr@public.cloak)
# [21:22] * Joins: cabanier (~cabanier@public.cloak)
# [21:28] <tantek> Scribenick tantek
# [21:28] <tantek> smfr: issue summary?
# [21:28] <plinss> http://lists.w3.org/Archives/Public/www-style/2013Jan/0089.html
# [21:28] <fantasai> http://www.w3.org/mid/AFDF40EF-A5C9-45B0-8F74-082A461939FF@adobe.com
# [21:28] <tantek> smfr goes to the whiteboard
# [21:29] <tantek> smfr draws boxes on the whiteboard
# [21:30] <tantek> smfr: you've got a block that's split across multicols or pages
# [21:31] <tantek> fantasai: we resolved that the fragmentation occurs before ...
# [21:31] <tantek> szilles: the middle one is resolved out
# [21:31] <tantek> (scribenote: need image to reference)
# [21:31] <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.
# [21:33] <tantek> szilles: … applies individually to the fragments, in other words I treat each fragment as if it were an independent element.
# [21:34] <tantek> (photos taken of redrawn whiteboard)
# [21:34] <tantek> daniel: points to whiteboard, explains rotation, origin
# [21:35] <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.
# [21:35] <tantek> szilles: where is the rotation point? (is the question) It ought to be relative to each fragment.
# [21:36] <tantek> szilles: because that's going to guarantee its going to be on the page, or might be
# [21:36] <tantek> dbaron: another principle
# [21:36] <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
# [21:36] <tantek> dbaron: and having the transform origin be different breaks that
# [21:36] <tantek> fantasai: we are already screwed on that point...
# [21:37] <stearns> having the fragmentation breaks that
# [21:37] <tantek> daniel: explains options on the whiteboard
# [21:37] <tantek> dbaron, simon, daniel discuss / question diagram
# [21:37] <tantek> smfr,szilles joins discussion of whiteboard
# [21:38] <tantek> fantasai: both of the bottom ones (of the 6 on the whiteboard) are going to give you bad results
# [21:38] <tantek> smfr: I disagree
# [21:38] <tantek> daniel: I'm not sure
# [21:38] <tantek> fantasai: I'll show you
# [21:38] <tantek> dbaron: the bottom two
# [21:38] <tantek> szilles: consider a 180deg rotation
# [21:39] <dbaron> s/bottom ones (of the 6 on the whiteboard)/bottom two (all the ones on the whiteboard)/
# [21:39] <dbaron> fantasai: Closest thing to expected result for the user is a graphical slice rather than doing fragmentation.
# [21:39] <tantek> fantasai: you don't actually do fragmentation on the box, you first rotate it and then ...
# [21:39] <tantek> daniel: can we do better? (in response to szilles)
# [21:40] <tantek> szilles: you can always say break-within:avoid
# [21:40] <tantek> szilles: we should do something easy to do that for small rotations will probably be ok
# [21:40] <tantek> szilles: and for big rotations, you're going to need to avoid the break
# [21:40] <tantek> daniel: rotate before and slicing afterwards is this (middle)
# [21:40] <tantek> rossen: I'm in favor of the top one! (exits room)
# [21:41] <tantek> daniel, fantasai, smfr continue discussing whiteboard
# [21:41] * Quits: smfr (~smfr@public.cloak) (smfr)
# [21:41] * stearns likes Rossen's strategy
# [21:41] <tantek> plinss, we're talking about a box ...
# [21:41] <tantek> szilles: it's fragmented in any case
# [21:42] <tantek> plinss: how do you get the upper right hand result?
# [21:42] <tantek> fantasai: you lay it out as if in contiguous media, you do the transformation, and then you just slice it
# [21:42] <tantek> smfr: the bottom you've actually done fragmentations...
# [21:42] <tantek> szilles: the top you haven't
# [21:43] <tantek> szilles: I can think of no one who likes slicing images. no one.
# [21:43] <tantek> smfr: even if the content has a forced break?
# [21:43] <tantek> szilles: if it has a forced break, then you're going to apply the transform to the two pieces independently
# [21:43] <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)
# [21:43] <tantek> szilles: e.g. I have text, div, with transform on it, break in the middle, that forces 2 paragraphs
# [21:43] <tantek> szilles: the transform is on the container
# [21:44] <tantek> plinss: another complication
# [21:44] <tantek> plinss: … what happens in the next paragraph
# [21:45] * Joins: smfr (~smfr@public.cloak)
# [21:45] <tantek> dbaron: so you do the layout with fragmentation but you don't show any of it
# [21:45] <tantek> fantasai: but treat transformed element as an image
# [21:45] <tantek> dbaron: you lay out the transformed element as if it was not fragmented and then don't draw it
# [21:45] <tantek> dbaron: then you draw it like an image (?)
# [21:45] <tantek> daniel: and it doesn't change the position of the following elements
# [21:45] <tantek> fantasai: … if you break inside it you do graphical slicing on it
# [21:46] <tantek> fantasai: if you lay out while transforming you might make it taller
# [21:46] <tantek> fantasai: … the document as a whole gets fragmented ...
# [21:46] <tantek> szilles: transformation is not supposed to ...
# [21:46] <tantek> smfr: high level issue, you do layout before transforms
# [21:46] <tantek> smfr: transforms are more of a graphical effect you do later
# [21:46] <tantek> smfr: you have to break first
# [21:47] <tantek> plinss: explains an order of operations
# [21:47] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [21:47] <tantek> fantasai: if a trivial transform shifts things around ...
# [21:47] <tantek> dbaron: smfr is right that this is not trivial and possibly not reasonable to implement
# [21:47] <tantek> szilles: the user is not going to like the results
# [21:47] <tantek> szilles: because the text is unreadable
# [21:48] <tantek> daniel: what's the other option
# [21:48] <tantek> szilles: any option is fine because the user can always do avoid pagebreak to keep whatever he wants to stay
# [21:48] <tantek> szilles: but I think this on is particularly bad
# [21:48] <tantek> szilles: I prefer applying the transforms to the two fragments separately
# [21:48] <tantek> szilles: doesn't change layout, and most of the types of transforms are the kind you just show
# [21:48] <tantek> szilles: like a slight inclination
# [21:49] <tantek> szilles: it's going to be hard to distinguish the effects between keeping an origin and specifying separate origins
# [21:49] <tantek> daniel: another issue: repeat origin makes the first fragment visible in the first page, but out of the page in the second one
# [21:49] <tantek> szilles: if you do a 180deg rotation, both disappear
# [21:50] <tantek> daniel: you can have a case where one is visible, and the other is lost above the second page
# [21:50] <tantek> plinss: if the second piece gets cut off the second page then it gets drawn on the first page
# [21:50] <tantek> fantasai: that's what the spec currently says
# [21:51] <tantek> daniel: that's not workable
# [21:51] <dbaron> plinss: Transform the fragments individually, and then slice the transformed results (potentially putting them on another page)
# [21:51] <tantek> daniel: you two different rotations of two different objects
# [21:51] <tantek> (thanks dbaron)
# [21:51] <tantek> (I can't tell if my minutes are making any sense)
# [21:51] <tantek> szilles: is there a use case for wanting to make this work across a fragmentation?
# [21:51] <tantek> daniel: I thought of an example, given by steve, regions polyfill, flow of text, and second one was rotated like that.
# [21:52] <tantek> daniel: and your whole document is like that. a flow of text, and a gutter that is rotated in 3D.
# [21:52] <tantek> smfr: in that case the container was transformed
# [21:52] <tantek> szilles: well the contents flow into the container and the container is rotated
# [21:52] <tantek> szilles: it's not the contents that's rotated, it's the container
# [21:52] <tantek> szilles: if you don't pick the right point to rotate around, yes you can screw up
# [21:52] <tantek> smfr: but in that case you can still do all the transforms before breaking
# [21:53] <tantek> szilles: but this example is worse
# [21:53] <tantek> smfr: with transforms you can always move things off screen
# [21:53] <tantek> daniel: we have a number of proposals here
# [21:54] <tantek> daniel: what is the best in terms of user expectations and implementability
# [21:54] <tantek> szilles: you won't succeed with user expectations
# [21:54] <tantek> daniel: I'm trying to minimize problems
# [21:54] <dbaron> smfr's whiteboard drawing http://lists.w3.org/Archives/Public/www-archive/2013Feb/0010.html
# [21:54] <tantek> szilles: so this is the bouton(?) principle
# [21:54] <dbaron> s/bouton(?)/Bhutan/
# [21:54] <tantek> daniel: ideal solution is not possible, so let's do the best we have
# [21:54] <tantek> simon: the container itself is fragmented ...
# [21:54] * Quits: teoli (~teoli@public.cloak) (Ping timeout: 60 seconds)
# [21:55] <tantek> simon: each fragment as its own transform origin
# [21:55] <tantek> szilles: that's what I was arguing for also
# [21:55] <tantek> daniel: we needed to list everything
# [21:55] <tantek> szilles: that does destroy the effect the user was trying to achieve (as david pointed out)
# [21:55] <tantek> daniel: we are back to the original proposal I made to steve and alan.
# [21:55] <tantek> daniel: does it make sense?
# [21:55] <tantek> smfr: transform the fragments independently
# [21:56] <tantek> daniel: each fragment is transformed relative to the container
# [21:56] <tantek> smfr: I would like a solution where layout and breaking happens first, and transformation happens later in a graphical layer
# [21:56] <dbaron> daniel: transform each fragment individually, with the origin relative to the fragment
# [21:56] <tantek> daniel: if you have 0,0 it is the top left corner of each fragment
# [21:57] <tantek> smfr: the transform spec says origin is relative to the border box - do we have a good definition of that for fragments?
# [21:57] <SimonSapin> http://www.w3.org/TR/CSS21/box.html#box-dimensions
# [21:57] <dbaron> fantasai: the border box of the fragment is well-defined
# [21:57] <tantek> smfr: the border box of a fragment is well defined
# [21:58] <tantek> fantasai: zero width, controls for it to be non-zero
# [21:58] <tantek> fantasai: this is the simplest thing to implement
# [21:58] <tantek> szilles: simplest thing for the user to understand and control
# [21:58] <tantek> daniel: so ok...
# [21:58] <tantek> szilles: since transforms don't affect layout, they're dangerous to use
# [21:58] <tantek> daniel: transform is applied to each fragment independently
# [21:59] <tantek> (meme discussions)
# [21:59] <fantasai> "If you print your transforms, you're gonna have a bad time."
# [21:59] <tantek> daniel: we can forge a test case
# [21:59] <tantek> simon: we need a test where content can overflow the page
# [21:59] <fantasai> hober, if you make that, I will put it in the spec
# [21:59] <tantek> plinss: controls to turn on slicing
# [21:59] <tantek> simon: if you decide pages are supposed to be above each other, what happens when you overflow to the side
# [22:00] <tantek> RESOLVED: transformation is applied independently to each fragment.
# [22:00] <tantek> szilles: the coordinate system of the transform is defined relative to each fragment
# [22:01] * hober fantasai: what do you want me to make?
# [22:01] <tantek> simon: yes, but you could imagine border boxes bounding box of all fragments...
# [22:01] <glazou> http://lockerz.com/s/281826419
# [22:01] <tantek> szilles: … it's own coordinate system
# [22:01] <tantek> smfr: transforms act as positioning ancestors
# [22:01] <tantek> smfr: you can put position absolute inside something transformed, the absolute offset is relative to the transformed ancestor
# [22:01] <tantek> smfr: what happens when it fragments
# [22:02] <tantek> szilles: this is the problem with pagination in the first place
# [22:02] <tantek> szilles: because it says that you reset to the page for its position
# [22:02] <tantek> smfr: for fixed?
# [22:02] * fantasai wonders if we need a transform-break property in the future....
# [22:02] <tantek> smfr: if you have a position absolute that has descendants
# [22:02] <tantek> smfr: a what happens on second page
# [22:02] <tantek> bert: the ones that occur exactly at the point where the fragment breaks, do they occur on the first or second page
# [22:03] <tantek> szilles: similar to a problem with floats and page breaks
# [22:03] <tantek> szilles: isn't it the case that with a relatively positioned thing is relative to the fragment that it's in?
# [22:03] * fantasai hober, nm, can't put copyrighted pics in the specs :/
# [22:03] <tantek> smfr: if it has relative position -10px up
# [22:04] <tantek> smfr: does it show up on the previous page? or just disappear?
# [22:04] <tantek> szilles: disappear
# [22:04] <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
# [22:05] <tantek> ...
# [22:05] <tantek> daniel: let's move back to second simon's issue about sizing
# [22:06] <tantek> fantasai: I think the definition in box should be a guiding principle for us
# [22:06] <SimonSapin> http://dev.w3.org/csswg/css3-box/#intrinsic
# [22:06] <SimonSapin> http://dev.w3.org/csswg/css3-sizing/
# [22:06] <tantek> fantasai: but we should be defining specific to each layout module exactly how to fulfill this in ways
# [22:07] <tantek> fantasai: that accommodate ...
# [22:07] <tantek> bert: I wonder if that's possible
# [22:07] <fantasai> s/.../practical considerations/
# [22:07] <SimonSapin> SimonSapin: we have two conflicting definitions of max-content and min-content
# [22:07] <SimonSapin> SimonSapin: what’s the plan?
# [22:07] <tantek> bert: you want to take into account properties like hyphenation, widows and orphans
# [22:07] <SimonSapin> (earlier)
# [22:07] <tantek> bert: can become quite handy
# [22:07] <tantek> s/handy/ difficult
# [22:07] <tantek> bert: due to lack of resources, may have to fallback to something simpler
# [22:08] <tantek> bert: when you have the possibility
# [22:08] <tantek> ...
# [22:08] <tantek> dbaron: I think box is defining the goal in too much detail. overemphasizing the concept of overflow.
# [22:08] <tantek> dbaron: when we implemented hyphenation we chose to NOT affect the min intrinsic width
# [22:08] <tantek> dbaron: we might then choose to hyphenate some things or not
# [22:08] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [22:09] <tantek> bert: but if someone turns hyphenation on, don't they want it to change?
# [22:09] <tantek> dbaron: not necessarily
# [22:09] <tantek> bert: very narrow column with long words in it
# [22:09] <tantek> bert: e.g. two columns rather than one
# [22:09] <tantek> dbaron: doing the computation for hyphenation is quite expensive
# [22:10] <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
# [22:10] <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.
# [22:11] <tantek> tantek: agreed with dbaron, prefer specifying in properties instead of overarching areas
# [22:11] <tantek> bert: we want people to compete on doing things the best possible way
# [22:11] <tantek> bert: that's a general principle we want to apply to table and grid layout
# [22:12] <tantek> bert: try to make it as compact as possible, but limit to reasonable time or hardware
# [22:12] <tantek> bert: or if you animate it
# [22:12] <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
# [22:12] <tantek> bert: I don't want unsightly gaps
# [22:12] <tantek> bert: I want a way to make tables that actually look good
# [22:12] <tantek> bert: at same time, I don't want to force the optimal, but I want to make it possible to do the optimal
# [22:13] <tantek> bert: CSS should be able to do that
# [22:13] <tantek> bert: e.g. with electronic books and such
# [22:14] <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.
# [22:14] <tantek> bert: measuring overflow is the best criterion for measuring optimal layout or not. maybe there are other things you can measure.
# [22:15] <tantek> dbaron: there are all sorts of things like elements with width 110% that are always going to overflow
# [22:15] <tantek> dbaron: the way we want to do things is build up intrinsic widths from leaves to their ancestors
# [22:16] <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.
# [22:16] * Quits: florian (~florian@public.cloak) (Ping timeout: 60 seconds)
# [22:16] <tantek> bert: the way you use it is to minimize overflow, not look for 0
# [22:16] <tantek> dbaron: it will always overflow out of its parent, but not necessarily its great grandparent
# [22:16] <tantek> dbaron: but having to worry about that is too complicated and breaks the notion of a functional subtrees
# [22:17] <tantek> bert: not summing the parts - not how it works
# [22:17] <tantek> dbaron: it is how it works - interop across 4 implementations so we should document that
# [22:17] <tantek> bert: it won't work well for grids and columns
# [22:17] <tantek> dbaron: there are rules we can write for grids and columns to make it work well
# [22:18] <tantek> szilles: I'm losing track
# [22:18] <tantek> szilles: 1. you want a computationally efficient way to get a good enough answer
# [22:18] <tantek> szilles: 2. and you want an option that's better than "good enough"
# [22:18] <dbaron> s/1. you want/1. dbaron wants/
# [22:18] <dbaron> s/and you want/and Bert wants/
# [22:18] <tantek> szilles: OTOH I thought I heard this morning that I could define different rules for table cells than other circumstances.
# [22:19] <tantek> (thanks dbaron)
# [22:19] <tantek> szilles: I think the provision as written allows you to change the rules for table cells
# [22:19] <tantek> szilles: I'm not arguing you want to, in principle you could special case table cells
# [22: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
# [22: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
# [22:17] <tantek> bert: at some point I want a third table layout algorithm where you actually get what you want in a table
# [22:17] <tantek> bert: I think we need something for things like regions
# [22:17] <tantek> bert: it makes a difference how much you put in one region vs. the second region
# [22: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.
# [22:18] <tantek> bert: those are local things that have a very global or much higher level than a single element effect
# [22:18] <tantek> szilles: I think it's reasonably clear.
# [22:19] <tantek> szilles: the piece I don't understand is
# [22:19] <tantek> szilles: I agree with what david just said
# [22:19] <tantek> szilles: document what's interop
# [22:19] * Quits: isherman-book (~Adium@public.cloak) ("Leaving.")
# [22:19] * Quits: smfr (~smfr@public.cloak) (Client closed connection)
# [22:19] * Joins: smfr (~smfr@public.cloak)
# [22: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
# [22:19] <tantek> szilles: bert's definition was intended to say what he thought what better meant
# [22: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.
# [22: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
# [22:20] <tantek> szilles: OTOH people complain when two implementations don't break lines in exactly the same place
# [22:21] <tantek> szilles: everytime we don't specify exactly what the answer is someone is unhappy
# [22:21] <tantek> glenn: specify an open source tool open source font will make the same line breaks
# [22:21] <tantek> szilles: I can think of lots of reasons to not go there - separate issue - not related to sizing
# [22:21] <tantek> szilles: david, do you have a problem with doing better?
# [22:22] <tantek> dbaron: there's a large amount of content out there that depends on particular behavior
# [22:22] <tantek> szilles: I would prefer that the leaving open be in the sizing module but I don't know how to say it
# [22: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
# [22: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
# [22:23] <tantek> dbaron: if those have to be two different specifications that would be unfortunate
# [22:23] <tantek> simon: bert is right that the sizing spec would close the possibility of doing better at some point
# [22:23] <tantek> simon: but maybe the spec can include that
# [22:24] <tantek> simon: similar to a recent proposal of balancing text in line breaks
# [22:24] <tantek> simon: what you do normally, and balancing which is more expensive
# [22:24] <tantek> bert: difficult in how you specify
# [22:24] <tantek> bert: some way to say please do this optimal
# [22:24] <tantek> bert: or 50% of
# [22:24] <tantek> bert: depends on algorithm and parameters
# [22:24] <tantek> simon: maybe resolve by documenting how web works today
# [22:24] <tantek> simon: and have a way to do an optimal switch
# [22:25] <tantek> bert: already differences today
# [22:25] <tantek> bert: some impls do better line breaks than others, some do better page breaks
# [22:25] <tantek> glenn: an opt-in approach would be for standard
# [22:25] <tantek> fantasai: no that's the default for browser
# [22:25] <tantek> s
# [22:25] <tantek> glenn: no it doesn't have to be
# [22:25] <tantek> fantasai: if it's going to break the web you're going to need to
# [22:25] <tantek> glenn: there is no breaking the web when it comes to sizing
# [22:26] <tantek> fantasai: there are somethings that no matter how weird crazy they are, you have to implement them
# [22:26] <tantek> simon: for me as an implementer it is important that this is documented
# [22: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/
# [22: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
# [22:27] <tantek> szilles: it would be left up to defining whatever criteria would change for the new property/value
# [22:27] <tantek> szilles: but it would at least give us a baseline for today
# [22:27] <tantek> bert: but problem is with the old content
# [22:27] <tantek> bert: old content doesn't done have hyphenation
# [22:27] <tantek> bert: optimal should be turned on by default
# [22:28] <dbaron> bert: hyphenation should have been on by default
# [22:28] <tantek> john: problem is with content suddenly.. if you suddenly upgrade the browser and the page layout changes
# [22:28] <tantek> john: issue for microsoft products
# [22:28] <tantek> smfr: issue for us too
# [22:28] <tantek> smfr: but we tell people cannot depend on pixel-same rendering from release to release
# [22:28] <tantek> simon: bert, use your user style sheet
# [22:29] <dbaron> s/sheet/sheet to turn on hyphenation/
# [22:29] <tantek> simon: we don't have to change the definition of in CSS initial values
# [22:29] <tantek> (dbaron, I think simon meant in general, beyond hyphenation for example)
# [22:29] <tantek> szilles: for hyphenation you really need to say letter counts and
# [22:29] <SimonSapin> yes, hyphenation was just an example
# [22:29] <tantek> szilles: there are ...
# [22:30] <tantek> szilles: I prefer the opt-in approach
# [22:30] <tantek> plinss: you could also do user vs. ua style sheet
# [22:30] <tantek> fantasai: I think bert and I need to sit down and shift texts into one place
# [22:30] <tantek> fantasai: here is what you can potentially do better, and here is the baseline of what browsers should do
# [22:31] <tantek> fantasai: and yes there will be a gap where behaviors could be better
# [22:31] <tantek> fantasai: the algorithm will be normative, that will be the baseline
# [22:31] <tantek> simon: how can you do better then?
# [22:31] <tantek> fantasai: because you say so in the spec that you can do better
# [22: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.
# [22:32] <tantek> fantasai: if you can do better, you may do better
# [22:33] <dbaron> fantasai: I think action should be for me and bert to incorporate the text from box into sizing and ...
# [22: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.
# [22:33] <dbaron> tantek: I'd like to action parties to write these up (e.g., on wiki) so we can reference them
# [22:33] <fantasai> s#interop#interop/deterministic layout#
# [22:34] <SimonSapin> +1 for having the rationales somewhere, as Tantek says
# [22: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.
# [22:35] * trackbot is creating a new ACTION.
# [22:35] <trackbot> Error finding 'Bert,'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
# [22:35] * RRSAgent records action 3
# [22: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.
# [22:35] * trackbot is creating a new ACTION.
# [22:35] * RRSAgent records action 4
# [22: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].
# [22: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
# [22:36] * trackbot is creating a new ACTION.
# [22:36] * RRSAgent records action 5
# [22: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].
# [22:37] <tantek> ACTION: Bert work with Elika remove material on sizing in Box module and incorporate equivalent material into Sizing module.
# [22:37] * trackbot is creating a new ACTION.
# [22:37] * RRSAgent records action 6
# [22: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].
# [22:38] <tantek> ...
# [22:38] <tantek> plins: overflow
# [22:38] <dbaron> dbaron: postpone to teleconferences
# [22:38] <tantek> dbaron: postpone to teleconferences
# [22:38] <tantek> john: I have a minor issue
# [22:38] <dbaron> Topic: css3-text
# [22:39] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [22:39] <jdaggett> http://www.w3.org/Style/CSS/Tracker/products/10
# [22:40] * Joins: isherman-book (~Adium@public.cloak)
# [22:40] <dbaron> ScribeNick: dbaron
# [22:40] <tantek> <br type="stretch">
# [22:40] * dbaron thinks this would be better written in MathML
# [22:49] * plinss is now known as plinss_away
# [22:55] <dbaron> </br>
# [22:56] <jdaggett> http://www.w3.org/Style/CSS/Tracker/products/10
# [22:56] * plinss_away is now known as plinss
# [22:56] <dbaron> jdaggett: This is list of issues on css3-text. Koji and Elika want to push text to LC.
# [22: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.
# [22: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.
# [22:57] <jdaggett> http://www.w3.org/Style/CSS/Tracker/issues/291
# [22:57] <dbaron> jdaggett: I think we can start with a few of these that are relatively simple.
# [22:57] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012Dec/0052.html
# [22:57] <jdaggett> http://dev.w3.org/csswg/css3-text/#line-break
# [22:58] * Joins: glenn (~gadams@public.cloak)
# [22:58] <dbaron> jdaggett: so the text module has 'line-break' property followed by 'word-break' property
# [22:58] <dbaron> jdaggett: These are to some extent governing similar things.
# [22:58] <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?
# [22:59] <dbaron> fantasai: That seems very unlikely; not the same thing.
# [22:59] <dbaron> jdaggett: Both about where you want to have a soft wrap opportunity.
# [22:59] <dbaron> jdaggett: 'line-break' is trying to give you general categories; 'word-break' is giving you escape hatches.
# [22:59] <dbaron> fantasai: the other way around
# [22:59] <dbaron> jdaggett: 'line-break' is giving general categories
# [22:59] <dbaron> jdaggett: line-break has loose, normal, strict -- general categories
# [22:59] * Quits: isherman-book (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [23:00] <dbaron> fantasai: word-break is supposed to apply to entire text. General policy, controls breaking between letters.
# [23:00] <dbaron> fantasai: line-break is supposed to control line breaking around punctuation. One exception for small kana.
# [23:00] <dbaron> jdaggett: There's an interaction between these properties; overlapping, I'd say.
# [23:00] <dbaron> fantasai: They overlap in that they both control breaking around small kana, but that's the only overlap.
# [23:00] <dbaron> jdaggett: So let me ask one question: why can't these be unified?
# [23:01] <dbaron> fantasai: I tried; people want to vary them independently.
# [23:01] <dbaron> jdaggett: One property with keywords for one or both?
# [23:01] <dbaron> jdaggett: word-break is unfortunate as a property name; really about line-breaking
# [23:01] <dbaron> glenn: implementations can be orthogonal to a certain degree, maybe completely
# [23:01] <SimonSapin> word-break sounds like hyphenation
# [23:01] <dbaron> fantasai: property names are historical; not much I can do, and I didn't have anything substantially better
# [23:01] <dbaron> jdaggett: both apply to a similar category of things; would be better as one property
# [23:02] <dbaron> jdaggett: unfortunately glenn is now implementing this for WebKit, so we're not just talking about the IE implementation
# [23:02] <dbaron> jdaggett: only IE that has implemented these properties in the past
# [23:02] <dbaron> koji: don't know about Firefox
# [23:02] <dbaron> fantasai: working on, but don't have one?
# [23:02] <dbaron> jdaggett: so effectively properties only supported by one browser
# [23:02] <dbaron> glenn: I know word-break partially supported by WebKit, and there's a patch for line-break.
# [23:02] <dbaron> jdaggett: But you're working on that.
# [23:03] <dbaron> Koji: glenn working on line-break; word-break is in Safari 3.0
# [23: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.
# [23:03] <dbaron> glenn: so it seemed orthogonal from a semantic perspectavi
# [23:04] <dbaron> jdaggett: because 'word-break' only applies between letter breaking opportunities?
# [23:04] <dbaron> glenn: word-break said that you can consider all possible soft breaks within a space-separated segment or not
# [23: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
# [23:04] <dbaron> glenn: ... in certain contexts, contexts being certain languages
# [23:04] <dbaron> glenn: the semantics of the two properties were layered on each other so orthogonal to implement
# [23: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"
# [23:05] <dbaron> glenn: if it said keep-all, then you wouldn't consider any word-breaking in cjk
# [23:05] <dbaron> glenn: so none of the soft breaks would apply
# [23:05] <dbaron> glenn: if it said break-all, then all would apply
# [23:05] <dbaron> glenn: if normal, then it allowed line breaking within words
# [23:05] <dbaron> glenn: I was dealing with normal and break-all
# [23: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
# [23:06] <dbaron> fantasai: I thought this seemed weird, but people do that.
# [23: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.
# [23:06] <dbaron> glenn: so it excluded applicability for cjk text
# [23:06] <dbaron> fantasai: because they break normally
# [23:07] <dbaron> steve: cjk has kumimoji rules...
# [23:07] <dbaron> stevez: sorry, kinsouk
# [23:07] <dbaron> stevez: sorry, kinsoku
# [23: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?
# [23:07] <dbaron> jdaggett: I'm not sure I believe glenn's assertion
# [23:08] <dbaron> jdaggett: where you said first deal with word-break and then deal with line-break
# [23:08] <dbaron> jdaggett: seems like with keep-all specified, you still have to consider what line-break is
# [23:08] <dbaron> stevez: common use in cjk seems to be to allow western words to be arbitrarily split rather than kept together
# [23:08] <dbaron> stevez: no idea what this would mean in Arabic
# [23: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
# [23:09] * fantasai notes it's defined for Arabic in css3-text
# [23:09] <dbaron> jdaggett: so the question is: will this break / be different from the IE implementation?
# [23:09] <dbaron> glenn: The IE documentation claims that the unprefixed property is deprecated
# [23:09] <dbaron> fantasai: ... in favor of the prefixed one
# [23:10] <dbaron> fantasai: probably because there was a previous revisiion of css3-text where I tried to combine them into one thing
# [23: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
# [23:10] <dbaron> jdaggett: has it landed?
# [23:10] <dbaron> glenn: landed, but pulled out for performance regression, not functionality
# [23:11] <dbaron> jdaggett: would we in the near future have something to test with?
# [23:11] <dbaron> glenn: I'll be resubmitting in the next few weeks
# [23:11] <dbaron> jdaggett: important to figure out if there are differences in the implementation and if those differences are important
# [23:11] <dbaron> glenn: that's reasonable
# [23:11] <dbaron> stevez: I'm more concerned that this is aimed at western text in a cjk setting
# [23:11] <dbaron> fantasai: depends on the value
# [23: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
# [23:12] <dbaron> fantasai: It's defined, it's just not useful
# [23:12] <dbaron> stevez: it defines letters; for S asian, which work in terms of syllables rather than letters, it's ill-defined
# [23:12] <dbaron> jdaggett: what they're saying is it's not useful
# [23:12] <dbaron> jdaggett: is there something here that would be useful for those contexts?
# [23:12] <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
# [23:13] <dbaron> stevez: It just seems to me that letters are the wrong thing to define this in terms of.
# [23:13] <dbaron> fantasai: Letters are defined to be grapheme clusters in L* or N* categories
# [23:13] <dbaron> stevez: but syllables are not grapheme clusters
# [23:13] <dbaron> jdaggett: I think the question is much more about if this applies in contexts other than cjk.
# [23:13] <dbaron> Koji: is the question about whether to merge these 2 into a single property?
# [23:14] <dbaron> jdaggett: In response to what Steve is saying, that these seem to be western/cjk only...
# [23: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
# [23:14] <dbaron> glenn: [missed].
# [23:15] <dbaron> glenn: example 4 shows 3 words with break opportunities between each connecting character (and non-connecting)
# [23:15] <dbaron> stevez: I understand connecting/non-connecting, but ligatures are worse than that.
# [23:15] <dbaron> glenn: I think ligatures are second order to connectedness
# [23:15] <dbaron> [discussion of lam-alef]
# [23:15] <dbaron> [scribe can't keep up]
# [23:16] <dbaron> glenn: what this doesn't do is discern the distinction between breaking between glyphs vs. characters
# [23: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.
# [23:16] <dbaron> glenn: that's not really defined here
# [23:16] <dbaron> stevez: where are letters defined?
# [23:16] * fantasai trying to remember what was the goal of this discussion, and fails
# [23:17] <dbaron> jdaggett: "A letter for the purpose of this specification is a character belonging to ..."
# [23:17] <dbaron> fantasai: characters are similarly redefined to be grapheme clusters
# [23:17] <dbaron> jdaggett reads definition
# [23:17] <dbaron> stevez: syllables are not grapheme clusters
# [23:17] * heycam|away is now known as heycam
# [23: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
# [23: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...
# [23:18] <dbaron> fantasai: would changing recommended to required help?
# [23:18] <dbaron> glenn: in many CSS specs [missed]
# [23:18] <dbaron> jdaggett: I think what Elika said would be sufficient.
# [23:18] <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.
# [23:19] <dbaron> fantasai: what's vague?
# [23:19] <dbaron> jdaggett: what's loose, normal, and strict, for non-cjk languages?
# [23:19] <dbaron> glenn: it's clearly defined
# [23:19] <dbaron> fantasai: It says "If the content language is C, J, or K..."
# [23:20] <dbaron> fantasai: It says allow X, disallow Y, and if the content language is C J or K then also Z
# [23:20] <dbaron> jdaggett: For a different language, are there different rules that are stricter or not stricted?
# [23:20] <dbaron> er
# [23:20] <dbaron> [discussion about which part of the spec they're reading]
# [23:21] <dbaron> Koji: first bullet applies to all languages, second applies to C J and K
# [23:21] <dbaron> jdaggett: c'mon, it's about Kana
# [23:21] <dbaron> fantasai: Can you quote the part of the text you have a problem with?
# [23:21] <dbaron> jdaggett: As defined, this says nothing about what is done for other languages
# [23:21] <dbaron> fantasai: you do nothing
# [23:21] <dbaron> [multiple discussions]
# [23:22] <glenn> http://trac.webkit.org/wiki/LineBreakingCSS3Mapping
# [23:22] <dbaron> glenn: Link to table derived from this spec, with precise definition covering all languages.
# [23:22] <dbaron> glenn: if you look at the header of that table, you see ICU open/close parentheses, loose open/close parentheses
# [23:22] <dbaron> glenn: That's the column for if it's not cjk, what does loose mean?
# [23:23] <dbaron> glenn: - means "as otherwise defined by the default line breaking behavior"
# [23:23] <dbaron> glenn: So there are some fallbacks to the default linebreaking behavior defined earlier in the spec
# [23:23] <dbaron> glenn: so for any language you can determine which applies
# [23:23] <dbaron> stevez: you created this table how?
# [23:23] <dbaron> glenn: by interpreting the spec that fantasai wrote
# [23:23] <dbaron> glenn: and factoring in the use of ICU and UAX14
# [23: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
# [23:24] <dbaron> jdaggett: (1) says RECOMMENDED
# [23:24] <dbaron> fantasai: fixed now
# [23:24] <dbaron> jdaggett: (2) not saying anything about other languages
# [23: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?
# [23:25] <dbaron> fantasai: it's possible we might want to do that in the future
# [23:25] <dbaron> fantasai: for this level there are no behavior differences for non-cjk text
# [23:25] * Joins: cabanier (~cabanier@public.cloak)
# [23:25] <dbaron> glenn: this does provide specific results for cjk
# [23:25] <dbaron> fantasai: we've gotten no feedback for needs from other languages
# [23:25] <dbaron> stevez: the table given does affect other languages
# [23:25] <dbaron> stevez: loose sets before/after breaking on ellipsis, and doesn't for strict and normal
# [23:25] <dbaron> stevez: ellipsis seems to me to be non-language-specific
# [23:26] <dbaron> stevez: Is it only the ellipses that are in a cjk sequence, or all of them?
# [23:26] <dbaron> fantasai: We don't say that it's for certain ones... it's for these characters, period.
# [23:26] <dbaron> glenn: This table on ellipsis character refers to a specific codepoint, tied in to default behavior of ICU
# [23:26] <dbaron> glenn: B/A mean break as permitted before or after
# [23:27] <dbaron> glenn: I agree with jdaggett that recommended...
# [23:27] <dbaron> fantasai: THat's done
# [23:27] <fantasai> RELOAD THE PAGE
# [23:27] <dbaron> glenn: if the user-agent implements this property then I think it's done
# [23:27] <dbaron> Koji: RELOAD THE PAGE
# [23: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
# [23:28] <dbaron> glenn: If somebody comes forward and says that for Thai, we want, then fine...
# [23:28] <dbaron> jdaggett: for breaks after prefixes, currency symbols, why not define it in terms of currency symbols rather than specific codepoints?
# [23:28] <dbaron> fantasai: Could you file that as an issue?
# [23:28] <fantasai> ISSUE: Why aren't all currency symbols included in line-break rules
# [23:28] * trackbot is creating a new ISSUE.
# [23: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>.
# [23:29] <dbaron> jdaggett: The original issue was about the confluence of the two properties.
# [23:29] <dbaron> jdaggett: I think there was text added that clarified keep-all.
# [23:29] <dbaron> fantasai: So I think we can move on.
# [23:30] <dbaron> glenn: In order to address his comment about behavior for other languages, I think we should add a note...
# [23:30] <dbaron> fantasai: There's one note, should we have two?
# [23:30] <dbaron> jdaggett: There's a line saying "support for this property is optional..."; I think this should be removed.
# [23: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. "
# [23:30] <dbaron> glenn: I agree.
# [23:31] <dbaron> glenn: Support for the property is optional in that there aren't conformance criteria
# [23:31] <dbaron> fantasai: we do
# [23:31] <dbaron> glenn: not in 2.1
# [23:31] <dbaron> jdaggett: we shouldn't be talking about UAs specialized in a given market
# [23:31] <dbaron> SteveZ: The person who disagrees is not in the room.
# [23:31] <dbaron> (Håkon)
# [23:32] <dbaron> SteveZ: Are you saying you don't want optional properties in...?
# [23:32] <dbaron> jdaggett: the notion that it's optional is a redundant statement
# [23:32] <dbaron> stevez: I don't think it's redundant at all.
# [23:32] <dbaron> jdaggett: all browsers render japanese text
# [23:32] <dbaron> fantasai: not all CSS implementations are browsers
# [23:32] <dbaron> stevez: not all browsers are conformant
# [23:32] <SimonSapin> http://weasyprint.org/docs/tutorial/#weasyprint-navigator
# [23:32] <dbaron> stevez: this sentence is here so you can be conformant if you aren't supporting certain things
# [23: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.
# [23:33] <dbaron> stevez: but it's not optional
# [23:33] <dbaron> jdaggett: I don't think this is necessary, and we should remove it.
# [23:33] <dbaron> stevez: Then we have to change the [forgot]
# [23:34] <dbaron> steve: conformance to a module requires implementing all of the properties in the module correctly unless otherwise stated
# [23:34] <dbaron> glenn: there's a section on partial implementations
# [23: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.
# [23:34] <fantasai> dbaron: It means we recognize that implementations add features piece by piece, and states we want them to do it this way
# [23:35] <dbaron> jdaggett: This is an unnecessary sentence; there are other properties in this spec equally cjk-dependent.
# [23:35] <dbaron> jdaggett: We sholudn't be going through our specs and marking things optional...
# [23:35] * Quits: smfr (~smfr@public.cloak) (smfr)
# [23:35] <dbaron> SteveZ: I personally don't care; I'd just rather not cycle back and end up in the same discussion.
# [23:35] <dbaron> jdaggett: But I think Håkon was objecting to this property as a whole.
# [23: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.
# [23:36] <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?
# [23:37] <dbaron> glenn: you've asked to remove vague language like should and recommend
# [23:37] <dbaron> jdaggett: without require, the entire property definition is left open
# [23:37] <dbaron> glenn: do you want to remove that text?
# [23:37] <dbaron> jdaggett: no
# [23:37] <dbaron> glenn: that's inconsistent
# [23:37] * Joins: dino (~dino@public.cloak)
# [23:37] <dbaron> jdaggett: I'll raise issues on the mailing list and we can fight about this later.
# [23:38] <dbaron> fantasai: Now we're deciding whether it's ok to have properties that are optional for conformance with the module.
# [23:38] <dbaron> jdaggett: ... This whole module is about international text.
# [23: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
# [23:39] <dbaron> fantasai: not true; don't want to parse something you don't do something with
# [23:39] <dbaron> fantasai: if the implementation doesn't support, it shouldn't parse or @supports
# [23:39] <dbaron> stevez: in this case, support was to do nothing
# [23:39] <dbaron> fantasai: support should never mean do nothing
# [23: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.
# [23:39] <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.
# [23:40] <dbaron> jdaggett: except for ellipsis, maybe
# [23:40] <dbaron> glenn: also hyphens
# [23:40] <dbaron> glenn: U+2010, U+2013
# [23:40] <dbaron> jdaggett: but that's under language-specific
# [23:40] <dbaron> glenn: so only ones are ellipses, U+2025, U+2026
# [23:40] <dbaron> jdaggett: if you're going to object, then we'll move it to the list and resolve it there
# [23:40] <dbaron> jdaggett: it's a waste of time to talk about this; it's a non-important discussion
# [23:41] <dbaron> jdaggett: I think we should remove the two sentences and go from there
# [23:41] <dbaron> Koji: straw poll, and Håkon can object?
# [23:41] <dbaron> jdaggett: can just ask if there are objections?
# [23:41] <dbaron> Bert: is there nothing that can be done about the ellipses... whole property for just two characters?
# [23:41] <dbaron> jdaggett: We're talking about the sentence
# [23:42] <dbaron> glenn: yes, it would be nice if those 2 characters could be put in the cjk portion
# [23:42] <dbaron> jdaggett: There aren't implementations that just wholly ignore languages
# [23:42] <dbaron> fantasai: there used to be implementations that didn't support bidi at all
# [23:42] <dbaron> jdaggett: they're partial implementations... let's get on with our life
# [23:42] <dbaron> jdaggett: especially for a spec that's all about international text
# [23:43] <dbaron> stevez: I agree in general that there shouldn't be optional properties; fairly meaningless in an interoperable world.
# [23:43] <dbaron> stevez: If you're saying this particular one is bad, I don't think there's that much of a cas.
# [23:43] <dbaron> s/cas/case/
# [23:43] <dbaron> jdaggett: I propose we resolve on striking these sentences.
# [23:43] <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"
# [23:43] <fantasai> RESOLVED: Remove sentences about optionality of properties
# [23:43] <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. "
# [23:44] <dbaron> glenn: can I ask a followon?
# [23:44] <dbaron> jdaggett: ok
# [23:44] <SteveZ> s/sentence/sentences/
# [23: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: "
# [23:45] <dbaron> glenn: I propose removing all but the first sentence of that paragraph and ending with a colon
# [23:46] <dbaron> glenn: The use of "recommend" makes everything in the bullets optional
# [23:46] <dbaron> fantasai: Is there a need to discuss this?
# [23:46] <dbaron> glenn: I don't like recommend; I like to see requires
# [23:46] <dbaron> fantasai: RELOAD
# [23:47] <dbaron> glenn: ok, I'm fine with that
# [23:47] <jdaggett> http://www.w3.org/Style/CSS/Tracker/issues/295
# [23:47] <dbaron> jdaggett: If there aren't other issues on line-break, I'd like to talk about text-justify
# [23:47] <dbaron> Bert: I had a question, just to verify...
# [23:47] <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.
# [23:47] <dbaron> fantasai: There's a definition; it's slightly complicated.
# [23:48] <dbaron> jdaggett: So the text-justify property: one of the more important issues I've logged about the spec.
# [23:48] <dbaron> jdaggett: I don't think we should move to last call with text-justify as specified
# [23:48] <dbaron> jdaggett: see http://www.w3.org/Style/CSS/Tracker/issues/295
# [23:48] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012Dec/0057.html
# [23:48] <dbaron> fantasai: what we've figured out so far that distribute value is needed ;commonly opted into for cjk typography
# [23: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
# [23:49] <dbaron> jdaggett: justification and line breaking are to some degree language dependent
# [23:49] <dbaron> jdaggett: so why can't that be something that user agents simply do based on the language?
# [23:49] <dbaron> jdaggett: http://dev.w3.org/csswg/css3-text/#text-justify
# [23:50] <dbaron> jdaggett: shows values: none / inter-word / ... / kashida values in spec
# [23:50] <dbaron> jdaggett: these are the categories
# [23:50] <dbaron> jdaggett: I posted reactions that other people have had to this.
# [23:50] <dbaron> jdaggett: I don't think this is the right way to specify modifications to the justification algorithm
# [23: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.
# [23:51] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [23: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.
# [23:51] <dbaron> Koji: we made it clearer
# [23:51] <dbaron> jdaggett: we've given a definition, but I'm not sure what the use case is
# [23:51] <dbaron> jdaggett: e.g., for inter-cluster
# [23: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?
# [23:52] <dbaron> fantasai: default behavior is for spaces, this distributes between thai clusters
# [23:52] <dbaron> jdaggett: how is that different from distribute?
# [23:53] <dbaron> fantasai: that expands latin characers
# [23:53] <dbaron> fantasai: Definitely distinct from default behavior, you only turn it on in certain situations.
# [23:53] <dbaron> fantasai: distribute says to justify between latin characters just as if they're cjk characters
# [23:53] <dbaron> Koji: look at figure
# [23:54] <dbaron> jdaggett: not clear whether space after [go] is a fullwidth space or ...
# [23:54] <dbaron> fantasai: Can't show all differences between all the values without mixing all the scripts, and nobody does that in real text.
# [23:54] <dbaron> fantasai: if you want us to go scan pictures of stuff, we can find pictures to scan
# [23: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
# [23:55] <dbaron> jdaggett: people like John Hudson who posted a detailed reponse that you didn't answer... "why are you breaking scrpts like this?"
# [23: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
# [23:55] <dbaron> http://lists.w3.org/Archives/Public/www-style/2012Dec/0057.html
# [23: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.
# [23:56] <dbaron> glenn: what is your issue on Thai?
# [23: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
# [23:57] <dbaron> glenn: I think we can do better examples, like for Thai. It's often the case thta you distribute between clusters.
# [23:57] <dbaron> glenn: Unfortunately this example doesn't show any combining vowel signs
# [23:57] <dbaron> glenn: or combining tone marks
# [23: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
# [23:58] <dbaron> glenn: That's frequently used in thai signage, newspapers
# [23:58] <dbaron> jdaggett: you're saying the thai characters are distributed differently fromteh latin characters?
# [23:58] <dbaron> glenn: yes
# [23:58] <dbaron> stevez: comes back to the definition of characetr. The definition of character now in the spec muddles that up
# [23: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.
# [23:59] <dbaron> glenn: grapheme clusters is defined by unicode
# [23:59] <dbaron> fantasai: categorization of scripts in not, in terms of how they justify
# [23:59] <fantasai> s/in not/is not/
# [23:59] <dbaron> glenn: ... priorities ..., difference between one value and the other is the priorities
# [23:59] <dbaron> s/glenn/jdaggett/
# Session Close: Thu Feb 07 00:00:00 2013

The end :)