# [18:08] <dael> fantasai: There was a message from simon on CSS-background that seems straightforward. If we have time we can look at that.
# [18:09] <dael> ??:I don't have anything, but I was wondering what the policy was. The last item is what I'm interested in and I have to leave early. Any way to shuffle?
# [18:09] <dael> plinss: We can certainly shuffle, but TabAtkins_ is the one that mentioned it and he's not here.
# [18:10] <dael> bert: I put a few hotels around here, but you might want to look in surrounding towns. I don't know if people want rental cars, but you can maybe set up carpools
# [18:10] <TabAtkins_> Kk. Of your okay with me being irc-only, I can talk.
# [18:12] <dael> plinss: TabAtkins_ sent this in about exposing some functions for color parsing. bkardell_ you said you were interested, do you want to speak?
# [18:12] <dael> bkardell_: He said in his e-mail he was planning on looking at deeper integration with CSS OM and I was curious what exactly this might intail
# [18:13] <dael> bkardell_: According to this you can make your own color format and that means you could expxess color format in ways that we're reflected in CSS or were but what form would they stringify...
# [18:13] <dael> bkardell_: It may be difficult with just IRC
# [18:13] <TabAtkins_> Ah, the "deeper integration" is what I talked about at the January f2f.
# [18:14] <TabAtkins_> The JS Value Objects-based proposal.
# [18:14] <dael> plinss: I presume with your own format it's just stringify and parsing and you'd get a POC format that you could assign directly
# [18:14] <TabAtkins_> But that's still blocked on JS, so no need to worry about that for now.
# [18:14] <dael> plinss: Since TabAtkins_ is only partly here, any other opinions?
# [18:15] <TabAtkins_> sylvaing__: Whatever you want - that's an author-defined function.
# [18:15] <dael> bkardell_: The proposal inc both. It says authors can define their own color format by adding to RGB with appropriate color tags. If we're talking about the prop that's part of it.
# [18:16] <TabAtkins_> They explicitly did "RGBAColor.prototype.fromMySpecialColor = function(foo, bar) { ... };"
# [18:16] <TabAtkins_> Sorry, scratch the ".prototype".
# [18:16] <dael> plinss: I dont presume those color caps would be embeddible raw unless we really open parsing. This is only for authors programitically for whatever IO format, they can modify style sheets, but not add this as CSS source.
# [18:16] <dael> bkardell_: It seems that if you did thi from the prosp of serialization type, it is worth being able to diff browser native and user defined?
# [18:17] <TabAtkins_> bkardell_: I am *not* talking about extending CSS itself (yet). This proposal is just to produce a Color object that has the right hooks that authors can use it for thier own needs, beyond just CSS.
# [18:17] <dael> plinss: I'm not sure you'd need to. We have serialization for color so if you do an entire stylesheet it would go back to RGB. It wouldn't attempt another model because they style sheet wouldn't know what that format is.
# [18:18] <dael> plinss: I'm not hearing obj. Let's acept the prop and add to CSS Color 4 or the OM as approptiate
# [18:18] <dael> Topic extrinsic sizing of controls
# [18:18] <bkardell_> tabatkins: I'm wondering really if RGBAColor.serializationTypes would differentiate an author defined serializationType, for example
# [18:18] <TabAtkins_> Okay, I was going to ask what spec to put it in. Color works. ^_^
# [18:18] <dael> fantasai: I was looking at the e-mail, I don't htink you meant extensic, I think you meant explicit.
# [18:18] <TabAtkins_> bkardell_: It doesn't differentiate, no.
# [18:18] <dael> gregwhitworth: I'm ref to exterior width. I know vendors get antsy about what's on the interior
# [18:19] <dael> fantasai: So extrinisic isn't the word. I think this is in CSS2.1 we spec where the scrollbar goes and takes room. It's not super clear but it spec the Firefox behaviour
# [18:19] <TabAtkins_> bkardell_: But the default serializer is rgba(), and having the ability to serialize is distinct from the ability to parse.
# [18:20] <TabAtkins_> Eh, don't wanna write out an example right now. It'll look something like the Custom Pseudo-classes bit.
# [18:20] <bkardell_> TabAtkins_: Yeah, it was mainly about is there utility in being able to thinking about future proposals...maybe I'll comment privately || on ML
# [18:21] <dael> fantasai: min-width effects content box, but we take out the scrollbar once you form a containin block. So the content inside is in a smaller box.
# [18:22] <Zakim> dael, listening for 10 seconds I heard sound from the following: ??P3 (9%), fantasai (69%), [IPcaller] (19%)
# [18:22] <dael> fantasai: The update is that we've been working on the box model, partic anon box.
# [18:23] <dael> fantasai: I've been doing thaton the list mozilla is impl the rules so we're getting good feedback
# [18:23] <dael> fantasai: My goal is to get Boris to agree the rules are correct and than get a new WD. THere stuff with Ruby layout I haven't drafted.
# [18:24] <dael> fantasai: We've also defined white space by making anon boxes that are similar to exisiting, but they don't pair. If there's pairs, they get paired with anon boxes in another layer
# [18:24] <dael> fantasai: For nested I'm trying to handle with layout rules rather then trying something fancy in box generation.
# [18:24] * sgalineau is someone in a restaurant kitchen?
# [18:24] <dael> fantasai: That'st he overview. If there's interest I can do more details.
# [18:25] <gregwhitworth> fantasai: I do think extrinsic is the correct term per the sizing spec as I don't want controls demensions to be determined by the contents if stated the the author
# [18:25] <dael> rossen: I was in and out and counldn't review.
# [18:26] * dbaron is clearly happy with bz's review of ruby anonymous box rules and doesn't feel the need to review them separately
# [18:26] <dael> rossen: I got fantasai e-mail, but I'm just not ready. If we want to make desc I'd ask to postpone. Is this just an awareness, that's fine. But if you want concensus, I'd prefer next week
# [18:26] <dael> fantasai: I'll explain, but not resolve.
# [18:27] <dael> fantasai: For Grid we have 2 prop in any dimnestions there's grid coloumn start and end. These can be lines or a span of this many lines or names lines.
# [18:27] <alex_antennahouse> skype crashed, calling in again
# [18:27] * dbaron thinks ??P3 was the kitchen noises
# [18:27] <dael> fantasai: We have error handling if you spec, for say, a line that doesn't exist. Or a diff case if you're spanning for 5 and there's only 4. We had various rules for different cases for what if you don't have enough.
# [18:28] <dael> fantasai: What we did was we realized we could have a simple rule that says there's an explicit grid and that's the one you set up. There's also an implicit grid where if you position an item with numbers such that it's no longer in that explicit grid, they're that implicit grid
# [18:29] <dael> fantasai: We decided we could simplify by saying if you can't find a named line, assume that the implicit grid has those lines and count in there. It's simple and consistant.
# [18:29] <dael> fantasai: It can give you odd results, but that's good because it gives you things that are noticibly off.
# [18:29] <dael> fantasai: Those are the main advantages of this new set of rules. We're looking for review from anyone with an opinion
# [18:30] <dael> rossen: I don't see anything wrong witht he approach, I have to sit down and work through the cases and see if this is sufficent.
# [18:30] <dael> fantasai: If you're interested, send you comments, otherwise well close with rossen's opinon next week.
# [18:30] <dael> plinss: It sounds reasonable approach, any times there's an error the author won't get it. I think this is as good as we'll get.
# [18:31] <dael> rossen: I'd better to keep the error as dominat and simple as possible. We don't want the "help" them too much. We want to to be outragious so that it's obviously an error. Let me sit down and I'll have a better opinon next itme.
# [18:31] <dael> fantasai: b/c we have a rule with jsut numbers and not names, if you say 7th and there's only 5, we create a 7th.
# [18:32] <dael> fantasai: If you think of named lines creating an implicit grid, we just do the name thing. We add named lines until you have the right number.
# [18:32] <dael> plinss: The problem is if people are adding named, there's a pattern and the author wll expect a pattern, but I don't htink we want to create an algorythm for that.
# [18:32] <dael> rossen: I agree, especially int he error case.
# [18:36] <dael> fantasai: Once we're through those we'll have a complete DoC to review with the WG and do a new LC. We really appriciate comments because there's a lot of tricky things
# [18:37] <dael> fantasai: There are Japanese and Chinese docs that are fomatted similarly. Korean isn't though. Most modern docs are in hangul, but some have Chinese charaters.
# [18:37] <dael> fantasai: So Chinese charaters are a part of Korean, but not commen. Korean does have spaces and uses spaces to just like Latin.
# [18:38] <dael> fantasai: Chinese and Japanese don't use spaces to justify. What happens in a line of Japaeses you'll have only 0 or 1 spaces and if you use spaces to jusitfy you have huge spaces. Instead you space between characters.
# [18:38] <dael> fantasai: This has created a problem between Korean and Japanese documents where Korean wants to use the spaces to just.
# [18:39] <dael> fantasai: I think one rowser spaces between Chinese and Japanese, but not Hangul which creates some problems. We're looking fro a comprimise that's appropriate for untagged content. If it's tagged you're fine, but when it's untagged that's what we're stuck on. While the spec won't requrire anything, we wanted to have a suggestion
# [18:39] <fantasai> s/problems/problems with mixed-script text/
# [18:40] <dael> SteveZ: Question. Clearly the existance of either Hangul or the various kana in Japanese gives you a hint of the language, but that req pre-scanning
# [18:40] <dael> fantasai: So far we're tried to avoid heuristic detection. If we built that in it would be a sig. paradym shift.
# [18:40] <dael> fantasai: We're trying to avoid heyristic and only rely on tags and prop.
# [18:40] <dael> SimonSapin: Would it make sense to look at lang?
# [18:41] <dael> fantasai: This is when lang isn't present
# [18:41] <dael> SteveZ: Anyone looking at the page could tell you what language. It'll seem strange to the user that they sytem can't
# [18:41] <dael> fantasai: If the WG wants to go that route we can. I think there was a text-script prop before wher eyou auto-detect the dom. script and if it's wrong you can tag, but so far we've avoided auto.
# [18:42] <dael> dbaron: I'd rather encourage people to tag their lang correctly
# [18:43] <dael> SteveZ: I think...I agree that haven't tagging on something is the best way to go, but we've already learned people copy from others and do the min to get it look right and I think browsers in Korea may get tuned to make a Korean assumption and it works if you don't take it out of the context.
# [18:43] <dael> ??: There's lang setting in the OS
# [18:44] <dael> fantasai: We don't use the OS because it would make our page look different depending on what computer you're looking at. We want to depand only on page content.
# [18:45] <fantasai> s/as a/has a character encoding/
# [18:45] <dael> plinss: I agree. If we want to encourage authors we can define the default as the worst behavior.
# [18:45] <dael> dbaron: There's enough pages without langague tag that we can't do something horrible, but we can do something like make hyphens not work.
# [18:45] <bkardell_> this doesn't seem horrible if there is no way to tell
# [18:45] <dael> fantasai: So we can make spacing look not optimal, but that's the worst.
# [18:46] <dael> SteveZ: So is plinss suggesting something that doesn't work in either and dbaron says that's not an option?
# [18:46] <dael> fantasai: I think dbaron is saying don't break stuff, but you won't get the best behaviour if you don't tag
# [18:47] <dael> plinss: I was trying to encourage authors to tag, which means as little magic and markup as possible
# [18:47] <dael> ??: Can you treat justification so it doesn't work without language tagging?
# [18:47] <dael> fantasai: I think the default should be better where it doesn't work for CJK and does for latin. We can't make it worse than it is. All space sep. lang work now.
# [18:48] <dael> SteveZ: If the current state is it doesn't work for non-space-sep lang. we can leave it to make eople tag
# [18:48] <dael> fantasai: We dropped inter-character value so there's a bunch of pages that spec inter-character, but since we dropped that and assumed auto would handle it, we have to make sure auto does
# [18:48] <dael> SteveZ: This sounds like a problem we made.
# [18:49] <dael> fantasai: A bit. BUt I don't think Firefox supports it so it's not comepletely us.
# [18:49] <dael> SteveZ: WE dropped inter-characcter because?
# [18:49] <dael> fantasai: The arguement was auto should be able to do it. We have a couple of solutions that approx the right thing, but not quite perfect. The discussion is of the possiible comp., what's the best
# [18:52] <dael> SimonSapin: What happens if we spec none of visibility hidden. It's not clear in the spec what should happen, but we have strong introp that the BG is still show with display on, but not with visibility hidden.
# [18:55] <dael> fantasai: I don't have much opinion, but whatever we do should be consistant with how we do writing mode direction and overflow propagation.
# [18:55] <dael> plinss: If you're in a display: none situation, will any of the prop have an effect.
# [18:55] <dael> plinss: All you'd draw is a canvas
# [18:56] <dael> fantasai: You can detect with overflow: scroll and than it may have an effect depending on propigation.
# [18:57] <dael> Rossen_: We treat it the same way tot he root element which HTML spec that we take those and leave body so it has a chance to redefine for overflow or writing. If HTML doesn't have it we take it from body
# [18:57] <dael> SimonSapin: The spec says don't do that.
# [18:57] <SimonSapin> "Note that the direction property of the HTML BODY element is not propagated to the viewport. That special behavior only applies to the background and overflow properties."
# [18:57] <dael> Rossen_: That spec was written 5 years after we did that impl. Maybe it now says something different, but that's what we do.
# [18:58] <dael> Rossen_: It's interesting that it deviates from how we handle overflow I would expect same.
# [18:58] <dael> fantasai: We had a legacy constraint that we were hoping wasn't there for direction
# [18:58] <dael> fantasai: We wanted authors to tag the root
# [18:59] <dael> Rossen_: If you haven't impl writing-mode, maybe. If you've had it from a long time then you have an issue and if you write ignoring that you can avoid the issue.
# [18:59] <dael> fantasai: This is direction. It's been around since the 90s.
# [19:00] <dael> SimonSapin: For writing-mode and direction prop this propigation only applies to prinicple writing mode which is only used for paged media
# [19:00] <dael> fantasai: Regions wouldn't need principal writing mode. It has its own thing.
# [19:01] <plh> (fyi: the note was including in the FPWD of writing modes back in 2010, but it's not part of CSS2.1)
# [19:01] <dael> plinss: We're low on time and should wrap up. I think we agree we want to spec current behavious, at least for background prop. Where is that?
# [19:01] <dael> fantasai: backgrounds and boards 3
# [19:13] <SimonSapin> fantasai: http://dev.w3.org/csswg/css-grid/#propdef-grid-area "Note: The resolution order for this shorthand is row-start/column-start/row-end/column-end, which goes CCW for LTR pages, the opposite direction of the related 4-edge properties using physical directions, like margin.", was there a reason for not making it like physical shorthands?
# [19:19] <TabAtkins> SimonSapin: Because you want to be able to specify the position by itself, typically be placing the start edges, and with the dumb ordering that would require using the first and last of for arguments. With the current order, you just use the first two and omit the latter two.
# [19:19] <TabAtkins> Ms2ger: I think you misread what I wrote.