/irc-logs / w3c / #css / 2014-05-21 / end

Options:

# Session Start: Wed May 21 00:00:00 2014
# Session Ident: #css
# [00:03] * Joins: rhauck (~Adium@public.cloak)
# [00:23] * Joins: dauwhe (~dauwhe@public.cloak)
# [00:28] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [00:58] * Joins: rhauck1 (~Adium@public.cloak)
# [01:03] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [01:36] * Joins: jdaggett (~jdaggett@public.cloak)
# [01:43] * Joins: Shinsuke (~Shinsuke@public.cloak)
# [01:45] * Quits: tantek (~tantek@public.cloak) (tantek)
# [01:52] * Joins: dauwhe (~dauwhe@public.cloak)
# [01:54] * Joins: dwim (~uid10661@public.cloak)
# [01:56] * Joins: dael (~dael@public.cloak)
# [01:59] * Quits: lmclister (~lmclister@public.cloak) ("")
# [02:00] * Joins: SteveZ (~SteveZ@public.cloak)
# [02:01] * Joins: shans_ (~shans@public.cloak)
# [02:01] * Joins: glazou (~glazou@public.cloak)
# [02:02] <glazou> https://attendee.gotowebinar.com/register/5412617925660825345
# [02:02] * plinss changes topic to 'http://wiki.csswg.org/planning/seoul-2014#agenda - https://attendee.gotowebinar.com/register/5412617925660825345'
# [02:02] * plinss changes topic to 'http://wiki.csswg.org/planning/seoul-2014#agenda - https://attendee.gotowebinar.com/register/5412617925660825345'
# [02:04] * Joins: andrey (~andrey@public.cloak)
# [02:04] * Joins: murakami (~murakami@public.cloak)
# [02:06] * Joins: jh_hong (~jh_hong@public.cloak)
# [02:15] * Joins: dbaron (~dbaron@public.cloak)
# [02:15] * Quits: rhauck1 (~Adium@public.cloak) ("Leaving.")
# [02:15] <dael> glaz: Let's start
# [02:15] * liam mutes too (thanks for unmuting)
# [02:16] <dael> glaz: WE have krit calling in and the first is CSS masking
# [02:16] * Joins: clilley (~clilley@public.cloak)
# [02:16] <krit> http://dev.w3.org/fxtf/css-masking-1/#masking
# [02:16] <dael> krit: CSS Masking had some changes since last WD one was that we now have posistion masking support
# [02:16] <krit> http://dev.w3.org/fxtf/css-masking-1/#the-mask-composite
# [02:16] <dael> krit: To make this possible it was an issue how to combine diff mask layers and I introduced mask composite prop
# [02:17] * Joins: abinader (~sid21713@public.cloak)
# [02:17] <dael> krit: Which is using composite operators to make it easier to use instead of using whole composite mode
# [02:17] <dael> krit: The mask-source-type which needed to be renamed to mask-type
# [02:17] <dael> krit: Therefore it all needs to be renamed since webkit and Blink are shipping
# [02:17] <dael> krit: I've called it mask-operation
# [02:18] <dael> krit: mask-type is mask-operation and mask-box-type is mask-box-operation
# [02:18] <dael> krit: No change requests in 2 weeks, so is it possible to pub a new LC?
# [02:18] <dael> krit: It might be last LC
# [02:18] <dael> glaz: Thoughts?
# [02:18] <dael> fantasai: Thre was one issue that was raised with layers about grouping the operations and combining the images and the reason we defered we didn't know how to do syntax to do properties.
# [02:19] * Joins: Rossen_ (~Rossen@public.cloak)
# [02:19] <dael> fantasai: [missed]
# [02:20] <dael> krit: Grouping isn't important at the moment but is interesting. We can think about that at backgrounds and borders, but for now I think we're fine with not having grouping
# [02:20] <dael> krit: We can introduce it in backgrounds and borders.
# [02:20] <dael> TabAtkins: I'm fine with that. Whatever solution is in B&B will be fine
# [02:20] <dael> fantasai: If we do an expression language that will be different from ones that map.
# [02:20] <dael> TabAtkins: And in the future we can have both.
# [02:20] <dael> krit: Any other requests or can we go to LC?
# [02:21] <dael> glaz: Comments?
# [02:21] * Joins: adenilson (~anonymous@public.cloak)
# [02:21] <dael> glaz: TabAtkins is fine, I'm fine, clilley, Rossen_
# [02:21] <dael> RESOLVED: LC for CSS Masking
# [02:21] <dael> clilley: Can you get the doc ready today so I can req pub on thursday?
# [02:21] <dael> krit: Next week?
# [02:21] <dael> clilley: This week
# [02:21] <dael> krit: Sure.
# [02:21] <dael> krit: Do you think you can get it on Thursday?
# [02:22] <dael> clilley: Yeah. As long as it's ready we can pub on Thursday.
# [02:22] <dael> krit: Yeah
# [02:22] <dael> fantasai: What was the mask type change?
# [02:22] <fantasai> fantasai: is it in the ED yet?
# [02:22] <dael> krit: For some reason it wasn't input. I looked online and all that's missing is the change from mask-source-type
# [02:22] * Joins: plh (~plh@public.cloak)
# [02:22] <dael> krit: And the mask-mode
# [02:22] <dael> krit: And mask-box-layout
# [02:23] <dael> krit: I'm not sure if I put it on the wrong branch, but it needs to be changed first
# [02:23] <dael> fantasai: Is there a clearer name than mask-mode?
# [02:23] <dael> TabAtkins: That's what we used in SVG and I can't come up with better.
# [02:23] <dael> fantasai: Okay.
# [02:23] <dael> fantasai: Where is it in SVG?
# [02:23] <dael> TabAtkins: Mask element
# [02:23] <dael> clilley: So you can't rename it
# [02:23] <dael> fantasai: I'm happy if it matches something
# [02:24] <dael> fantasai: It's otherwise very vague but...
# [02:24] <dael> krit: So you're fine with mask-mode?
# [02:24] <dael> fantasai: If it matches SVG yes
# [02:24] <dael> krit: There isn't in mask-mode, it was interduced in SVG
# [02:24] <dael> TabAtkins: There's an attribute. There's a same named thing so there's consisstancy
# [02:24] <dael> krit: We use mode quite often. That's true.
# [02:25] <dael> krit: Any better suggestions or is it fine?
# [02:25] <dael> fantasai: Were is mode? I was looking at masking module
# [02:25] <krit> http://dev.w3.org/fxtf/filters/
# [02:25] <dael> krit: It is in the spec linked above. There's a lot of use of mode.
# [02:25] <dael> krit: Composate operator
# [02:25] <dael> fantasai: If it means the same thing, but it doesn't?
# [02:26] <dael> fantasai: It's used for blending, not mask interpretation.
# [02:26] <dael> krit: True.
# [02:26] <dael> fantasai: And Masking will need blend modes at some point?
# [02:26] <dael> krit: No.
# [02:26] <dael> clilley: He's arguing we use mode for that sort of thing
# [02:26] <dael> fantasai: Are we going to add blending modes to masking?
# [02:26] <dael> krit: For background it's called background-blend-mode so it's explicit
# [02:26] <dael> astearns: If we do we can call them blenders.
# [02:27] <dael> TabAtkins: Which is clear at that point.
# [02:27] <astearns> s/blenders/blendmodes/
# [02:27] <dael> fantasai: The blend mode is clear.
# [02:27] * astearns though I do like blenders
# [02:27] <dael> fantasai: Okay. I'm not happy it matches something else, but I don't have a better idea.
# [02:27] <dael> fantasai: If it concept matched that would be awesome
# [02:27] <dael> clilley: Do we have a better name or can we move on?
# [02:27] <dael> fantasai: We can move on
# [02:28] <dael> krit: The next one?
# [02:28] <dael> glaz: That's all for masking? Okay.
# [02:28] <dael> Topic: Geometry Interfaces
# [02:28] <krit> http://dev.w3.org/fxtf/geometry/
# [02:28] <dael> krit: We worked on the geometry interface with is the dom-point dom-matrix etc that we had in different pub before.
# [02:28] <fantasai> s/awesome/matching a different concept is less awesome/
# [02:29] <dael> krit: They had been in CSSOM view and this is combination of the interface that we actually use in OM and SVG
# [02:29] <dael> krit: There have been some slight changes to DomMatrix.
# [02:29] <krit> http://dev.w3.org/fxtf/geometry/#dom-dommatrixreadonly-isidentity
# [02:29] * fantasai doesn't like "mode" or "type" in property names because they're semantic no-ops
# [02:29] <dael> krit: There had been long discussions on the ML and I added ident to the dom matrix interface that checks if the matrix is an identity transformer
# [02:29] <dael> krit: There are some issue
# [02:29] <krit> http://dev.w3.org/fxtf/geometry/#issue-5712ca41
# [02:30] <dael> krit: One is for the DOMMatrix constructor. One issue I'd like to resolve is issue 2 (link)
# [02:30] <dael> krit: This is where DOM Matrix takes a string that can be a translater.
# [02:30] * fantasai the only thing they express is "i take an enumerated type"
# [02:30] <glazou> krit: your document lacks a normative reference to WebIDL please
# [02:30] <dael> krit: The translation y ou can use in CSS can be passed into the string because you can pass the start and generate the DOM Matrix
# [02:30] * Quits: plh (~plh@public.cloak) ("Page closed")
# [02:30] <dael> krit: SCG uses the transform attr and it has less restrictions. It doesn't req units
# [02:31] <dbaron> s/SCG/SVG/
# [02:31] <dael> krit: In SVG we have the transform attr and it has less rest. It doesn't req unit and it has white spaces between function name and the breaks.
# [02:31] <dael> krit: I would suggest that we allow transform attr syntax here.
# [02:31] <dael> krit: It allows CSS syntax and SVG syntax
# [02:32] <TabAtkins> s/breaks/braces/
# [02:32] <dael> krit: The SVG syntax wll be along for a long time and use of SVG syntax would allow CSS syntax to work. The SVG group wanted approval from CSS
# [02:32] <dael> TabAtkins: I'm fine with unitless, but I don't like the let's have it be an ident plus paran
# [02:32] * Joins: plh (~plh@public.cloak)
# [02:32] <dael> TabAtkins: It's a strange artifact and doesn't nee to be maintained
# [02:32] <dael> krit: I haven't seen it but it's in theory allowed
# [02:33] <dael> TabAtkins: I don't think we need to spread that aspect further, but unitless if fine
# [02:33] <dael> krit: We would need a third syntax. It creats a string from trnasform and passes to Matrix
# [02:33] <dael> TabAtkins: And if you're not weirf it'll work
# [02:33] <dael> krit: I don't think that it's a good idea to have a thurd syntax
# [02:34] <dael> TabAtkins: It's only 3rd because it accepts the unitless SG thing when CSS ingeneral doesn't do that. That's the only seperation and I don't think that's sig. difference
# [02:34] <dael> krit: User agents have to impl three diff for very little gain
# [02:34] <dael> krit: It gets you closer to CSS without whitespaces
# [02:34] * fantasai agrees in not having a 3rd syntax
# [02:34] <dael> krit: I'm not sure if that ain is good enough
# [02:34] <dael> TabAtkins: Whenever you do the unitless is that intp as px?
# [02:34] <dael> krit: yes.
# [02:35] <dael> TabAtkins: So it's accepting the wierd or req to use pix, I'm fine with sticking to CSS, but don't see a reason. If we have to do one or another, I want CSS.
# [02:35] <dael> clilley: Unitless doesn't mean px always
# [02:35] <dael> TabAtkins: But it has to be understandable.
# [02:35] * glazou hi SteveZ ; do you want me to unmute you?
# [02:35] <dael> clilley: If I do 0.3 by 0.3 it can be huge.
# [02:35] <dael> krit: If clilley Is talking about user units, it's always 1 px
# [02:35] <dael> clilley: No it's not
# [02:36] <dael> krit: It is
# [02:36] <dael> krit: It means 1px sn't always 1pixel when it's transform
# [02:36] <dael> krit: It depends on what you mean.
# [02:37] <dael> clilley: So 1px can be 3000 divice pixals. Most people if they say the want a 1px font they don't expect huge. Forcing people to write px isn't useful. For a lot of content people that aren't used to scalable, they set to fixed and use px, but that's the only way
# [02:37] <dael> krit: I agree on the behviour. Do we want CSS, SVG, or a mix
# [02:37] <dael> clilley: Does mix mean the superset?
# [02:37] <dael> krit: SVG is the superset
# [02:37] <dael> TabAtkins: CSS syntax that accepts numbers that are interp as px units
# [02:38] <dael> krit: How would you do with having CSS syntax w/o units
# [02:38] <dael> TabAtkins: Have them set numbers that are interp as pixal units.
# [02:38] <dael> krit: Um.
# [02:38] <clilley> s/the only/not the only/
# [02:38] <dael> krit: I hope we can get rid of whitespace in SVG. I didn't see the behviour in use so maybe it's fine, but in this case I'd change SCG transform syntax.
# [02:39] <dael> krit: I'm fine with keeping this issue open unit SVG transform is resolved
# [02:39] <dael> krit: I'd like to pub a FPWD with these issues and we can compare.
# [02:39] <dael> TabAtkins: absolutely publish, yeah.
# [02:39] <dael> glaz: Other op?
# [02:39] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [02:39] <dael> RESOLVED: Publish FPWD
# [02:39] <dael> clilley: plh, canw e pub FPWD?
# [02:40] <dael> plh: Yes.
# [02:40] <dael> plinss: I q. In shenshen we got a bunch of feedback that isn't in here. Is that rejected, not considered?
# [02:40] <dbaron> s/feedback/feedback from Alex Russell/
# [02:40] * Joins: koji (~koji@public.cloak)
# [02:40] <dbaron> s/shenshen/Shenzhen/
# [02:40] <dael> krit: So waht about Alex Russell?
# [02:40] <dael> krit: I tried to ping him and he didn't respond?
# [02:41] <dael> clilley: What was the subs. of your ping?
# [02:41] <dael> krit: I summerized the promises we have in CSS WG with the interface and he was suggesting growth instead of new itnerface. I asked him to comment on the ML and summerize his opinion and that from others. He didn't respond or comment on the ML
# [02:41] <dael> plinss: I'll follow up with him.
# [02:41] <dael> krit: I talked with Mozilla and he feels we should have the new interface.
# [02:42] <dael> plinss: Okay
# [02:42] <dael> glaz: So are we done with this topic?
# [02:42] <dael> krit: Yeah.
# [02:42] <dael> Topic: Test Results Script
# [02:43] <dael> clilley: I was winching with our web and communications team where they wanted us to take outthe paragraph markers. We got to leave them, but I compained about taking out this script that gave a nice summary of the test suite
# [02:43] <dael> clilley: Without it the pages aren't as useful and the reaction was surprising positive. I went a few rounds of what we would need to keep this and one was accessability and I proved this doens't interfear with that
# [02:43] <dael> clilley: The next was does this make the doc non archiaval. I said no.
# [02:44] <dael> clilley: And can you jsut inline the results, no because we want it to be in real time.
# [02:44] <dael> clilley: The one sticking point is that the script isn't hosted at w3c.org
# [02:44] <dael> clilley: I said I'd talk about this. Since then someone popped up witha bunch of hand waving where it would let the data live where it does and the script can be on w3c.org
# [02:45] <dael> plinss: It's fine by me, it makes it harder if I update the script, but that's okay.
# [02:45] <dael> clilley: Will you update in a way that breakst he API?
# [02:45] <dael> plinss: I wrote it a long time ago and the API has only had one update since.
# [02:45] <dael> plinss: I intent to get back in in the next few weeks and let me do that and then you can have a fairly stable script
# [02:45] <dael> clilley: Thank you. I think it's very good.
# [02:46] <dael> plinss: It doesn't link to the style sheet. Do you want that piece too and have it live on the w3c server?
# [02:46] <dael> plinss: That's doable
# [02:46] <dael> plh: Do you think about how you do a new ap you need to do the script. Is that painful and do we want to try a new location?
# [02:47] <dael> clilley: All the thing for a pub need to be underneath. I think it's worth pushing on a well known location where it's installed and point there. It also solves the version problem.
# [02:47] <dael> clilley: That's worth pushing for.
# [02:47] <glazou> SteveZ: I unuted you
# [02:47] <glazou> unmuted
# [02:47] <dael> plh: You can still share it across spec.
# [02:47] <dael> plh: As long as you won't ever break it, that would be nice.
# [02:47] <dael> clilley: If it's instearting a style sheet link through the script, that needs to come in before the final offical sheet.
# [02:48] <dael> clilley: So for next step we need to refactor and stabilize?
# [02:48] <dael> plinss: Yeah, let me have another pass to stabilite
# [02:49] <dael> plh: Then we need to deal with bikeshead
# [02:49] <dael> plinss: Yes, bikeshed is making those links.
# [02:49] <dael> plinss: So we'll want to use our on version of the script on the drafts?
# [02:49] <dael> clilley: It seems more efficent if the script is together. If not, let's shift.
# [02:49] <dael> TabAtkins: It's the browser making the requests.
# [02:49] <dael> clilley: Then we'll use the same version for all.
# [02:50] <dael> clilley: Any origan problems if some is on dev and some is on www
# [02:50] <dael> TabAtkins: Shouldn't
# [02:50] <dael> clilley: Okay. The ball is in plinss court.
# [02:50] <dael> plinss: I recall an issue with TR where it doesn't exist?
# [02:50] <dael> clilley: I believe they're serving HPS.
# [02:50] <dael> plh: We don't use it for TR commands.
# [02:51] <dael> plinss: If people are doing the FTP for it it would be shipping wrong
# [02:51] <dael> plh: I don't believe people are.
# [02:51] <dael> plinss: But we can do it on dev
# [02:51] <dael> plh: It's possible people could access it but since the link is related the script will be through HTTPS as well
# [02:51] <dael> plinss: I was think of issues a while ago.
# [02:51] <dael> plh: Testing will be needed
# [02:51] <dael> plinss: Okay. We're fine.
# [02:52] <dael> plh: I tried to access through HTTPS and got redirected
# [02:52] <dael> plinss: And dev isn't doing HTTPS
# [02:52] <dael> plinss: I think bikeshead has a sceme for that. I think we're okay.
# [02:52] <dael> plinss: Okay.
# [02:52] <plinss> s/has a sceme/uses scheme relative urls/
# [02:52] <dael> Topic: Selectors 4
# [02:53] <dael> fantasai: There's been a lot of text changes so I need to review and we'll want another WD with that
# [02:53] <dael> fantasai: I think what we needf rom the WG is opinions on what's this level vs the next. Right now the draft has a cut of what we think goes in this level
# [02:54] <dael> glaz: So nothing to do really
# [02:54] <dael> fantasai: I don't think so
# [02:54] <dbaron> http://dev.w3.org/csswg/selectors4/
# [02:54] <dael> glaz: If you have anything to discuss on 4 now is the time.
# [02:54] <dael> glaz: We need time to review the added text
# [02:54] <dael> TabAtkins: And I have more to rewrite
# [02:54] <dael> glaz: If we close this now it means we've used the morning's agenda. CSS3 text is on this afternoon for SteveZ and Bert
# [02:55] <dael> glaz: We don't have Bert on the call
# [02:55] * clilley "I added a load of new text, can I publish a new WD yesterday" -- Napoleon
# [02:55] <dael> TabAtkins: I had a 5 or 10 minute topic from last night.
# [02:55] * liam thinks Napoleon would just say, "I added a load of new text and I commanded the Rec to be published"
# [02:55] <dael> TabAtkins: At least year's blink con one of the bloomburg guys that does blackberry asked me to prop a value for text overflowt hat does a fade over the edge
# [02:56] <dael> TabAtkins: So when the thing overflows you don't kill characters for an elip.
# [02:56] <dael> TabAtkins: The name they're using is -blackberry-fade.
# [02:56] <dael> TabAtkins: I think text-overflow-fade is good
# [02:56] <dael> hober: Is the fade config?
# [02:56] <dael> TabAtkins: Yeah.
# [02:56] <fantasai> s/text-overflow-fade/text-overflow: fade/
# [02:56] <dael> plinss: My concern is that is there a new paradim next year. Can we do a generic way to handle overflow markers where someone could use a fade.
# [02:56] * Joins: lmclister (~lmclister@public.cloak)
# [02:57] <dael> hober: Link how I do a fade from 0k black to transparent black
# [02:57] <dael> plinss: My point is can we get creative and come up with ::voverflow or something
# [02:57] <dael> clilley: Where the overflow defines and area that you can style.
# [02:57] <dael> plinss: And the default is elipsis
# [02:57] <dael> glaz: Can we just add a value for that effect?
# [02:58] <dael> TabAtkins: If we had a way to config, given that we don't have a way to composite jsut the content there's no way...
# [02:58] <dael> hober: masking?
# [02:58] <dael> fantasai: That get's BG. You just want ttext to fade.
# [02:58] <dael> fantasai: The easiest is a keyword
# [02:58] <dael> plinss: But when we want a diff effect, do we need another kyword
# [02:58] <dael> TabAtkins: Well if it's similar we jsut tack on.
# [02:58] <dael> TabAtkins: The obvious is eventually do a pseudo when it's needed
# [02:59] <clilley> krit mentioned adding an image
# [02:59] <dael> Rossen_: One common req we get becides layout is that people wnat to use it for bubble or whatever have you so we need to be able to attach other behavious
# [02:59] <dael> fantasai: Yeah.
# [02:59] <dael> TabAtkins: and that's true for block overflow
# [02:59] <dael> Rossen_: And if we don't know which period is where the marker is more than just a layout. Evenually we put the power in the designer's hands.
# [02:59] <dael> TabAtkins: I agree.
# [03:00] <dael> hober: I think that's a better long term way
# [03:00] <dael> TabAtkins: None of that solves that there is no was in CSS without new abilities to do a lets fade the content over some fraction
# [03:00] <dael> Rossen_: Well what we talked about
# [03:00] <dael> TabAtkins: We have conceptiual framework, but nothing that can be extended
# [03:00] <dael> krit: Is it poss that instead of one keyword we have the image and that uses mask That give more freedom
# [03:01] <dael> TabAtkins: Are there use cases for fading with an arbitratry image?
# [03:01] <dael> krit: I can image it. there are different ways to indicate and that's platform dependant
# [03:01] <dael> TabAtkins: You mean adding an image, yes.
# [03:01] <dael> clilley: If you use the image and use lumanence.
# [03:01] <dael> TabAtkins: You can't fade the content via the masking of another elemnt
# [03:02] <dael> plinss: It seems we should fix that
# [03:02] <dael> krit: You can fade and mask just the test. if you use text overflow and just use the image it's not an issue
# [03:02] <dael> TabAtkins: Maps instead of displays?
# [03:02] <dael> Rossen_: And you large is your image, krit?
# [03:02] <dael> krit: You have to define that
# [03:03] <dael> Rossen_: In the case of text overflow what you would do when you layout the last word you would have to work your way backwards to fine the elipsis
# [03:03] <dael> Rossen_: Actual size is det. at layout and if you're just doing one generic image, how do you align
# [03:03] <dael> krit: You can define it with gradent.
# [03:03] * liam happy to see a demonstration of CSS aural properties combined with the proposed new feature
# [03:03] <krit> s/You can define it with gradient./How would you define the offset for gradients?/
# [03:04] <dael> TabAtkins: I'm still not clear krit I think you're suggesting we can spec an image instead of a string and have an option for use this image as a mask instead of as an image. Is that correct?
# [03:04] <krit> yes
# [03:04] <dael> krit: Yes
# [03:05] <dael> TabAtkins: That seems weird to me because it feels like jamming a special behaviour in and if we're introducing something more than keyword it should be more general so that you can use an element as the mask of another element
# [03:05] <dael> fantasai: Do we want a pseudo for something like ::content and all you can apply is masking/filters. As a general thing.
# [03:05] <dael> TabAtkins: no, we don't want that b/c...well, it won't solve the overflow b/c you can't tell what side the overflow is on.
# [03:05] <dael> plinss: Yeah, that's orthaganal to the question
# [03:06] <dael> fantasai: Can overflow take 2 values?
# [03:06] <dael> TabAtkins: Yes
# [03:06] * hober can't come up with a ::last-line joke
# [03:06] <dael> fantasai: If we add image we can do that. If we let the image be a mask that solves it
# [03:06] <dael> TabAtkins: But saying you can do that for text overflow, that seems oddly specfic way of generalization.
# [03:06] <dael> TabAtkins: That's an odd place to stop. Either design something that works clearly or design the general facility
# [03:07] <dael> fantasai: I'm in favor of the keyword regardless.
# [03:07] <dael> fantasai: I would suggest we add fade to text-overflow
# [03:07] <dael> fantasai: We'll need a more general solution that has event handling and full styling, but even if we had that it would be awkward for this simple, straigthforward case
# [03:07] <dael> hober: You think a single keyword would be enough for most people's design?
# [03:08] <dael> TabAtkins: For most people, but allowing to passa length wouldn't be a problem
# [03:08] <dael> hober: People who have gone to the effort already are they people that was a level of control
# [03:08] <dael> glaz: The fade length is likely different on a small screen.
# [03:08] <dael> TabAtkins: I've seen some long fades.
# [03:08] <dael> fantasai: So you want to use percentage length
# [03:08] <dael> TabAtkins: percentages and lengths
# [03:09] <dael> glaz: Adding length doesn't really fit. fade should be functional
# [03:09] <dael> TabAtkins: As a keyword and a function it should take a length
# [03:09] <dael> hober: Words for me
# [03:09] <dael> glaz: Me too
# [03:09] <hober> s/Words/Works/
# [03:09] <dael> TabAtkins: We can discuss the greater generalization later
# [03:09] <dael> glaz: I've seen a text overflow with flat text and rounding
# [03:09] <dael> plinss: It's a transform, right?
# [03:09] <dael> glaz: It's a transform.
# [03:10] <dael> plinss: People will want to do transforms. If we give them one we want a lot.
# [03:10] <dael> hober: And if we get feedback it's good.
# [03:10] <dael> plinss: I don't mind the keyword, I want to explain that the keyword creates these things and you can override that by adding these lines of CSS
# [03:10] <dael> hober: And you can describe the pseudo as something you can work toward and get at laters
# [03:11] <dael> plinss: Let's explain in terms of our primitives
# [03:11] <dael> fantasai: I think adding the keyword makes sense and we should work o nthe general solution. And having these use cases will help us get there coreectly.
# [03:11] <dael> TabAtkins: I think it's the inside pseudo hixie tried forever ago
# [03:11] <dael> fantasai: I don't think so.
# [03:12] <dael> fantasai: We could spend the morning trying to figure out this problem. People want control over overflow, they want elipsis in the direction of the block
# [03:12] <dael> fantasai: WE always find that solving it takes time and we have time
# [03:12] <dael> Rossen_: WE can look into use content-outflow
# [03:12] <dael> Rossen_: ::after
# [03:12] <dbaron> s/content-outflow/::after { content: ... }/
# [03:12] <dael> fantasai: I don't think we want to do that
# [03:13] <dael> plinss: How does that interact witht he overflow
# [03:13] <dael> fantasai: It's part of the text alignmenet.
# [03:13] <dael> hober: It's the last part of the content
# [03:13] <fantasai> s/alignment/content/
# [03:13] <dael> plinss: So that you have content after can cause the elipsis
# [03:13] <fantasai> fantasai^: that gets elided
# [03:13] <dael> fantasai: If you haev a long bit of ::after content a lot will get elipsised, but if it's short...
# [03:13] <fantasai> *ellipsized
# [03:14] <dael> dbaron: What needs solvign for block overflow?
# [03:14] <dael> fantasai: 1 is to have the block overflow inline and 2 is to have it after last line
# [03:14] <glazou> ellipsizationnized
# [03:14] <dael> dbaron: I've seen the latter as fades.
# [03:14] <dael> TabAtkins: When in JS it'll be centered on the last line.
# [03:15] <dael> TabAtkins: The other req would be to be able to recieve click events.
# [03:15] <dael> fantasai: We need a way of defining events
# [03:15] <dael> dbaron: In some cases you only want click in some places.
# [03:15] <dael> fantasai: I propose we take a break, get the awesome green board, and start doing examples.
# [03:15] * dauwhe greenboarding is the new bikeshedding
# [03:16] <dael> glaz: I don't think the greenboard will get in the elevator.
# [03:16] <dael> [break = 15min]
# [03:16] * dbaron at least it's not waterboarding
# [03:22] * Quits: jh_hong (~jh_hong@public.cloak) (Ping timeout: 180 seconds)
# [03:29] * hober dauwhe: OMG WE HAVE TO FIND THIS DUNKIE'S: http://a3.img.mobypicture.com/2378b797a7d4d4a988c73d49fe28e3b3_view.jpg
# [03:30] * liam dauwhe - discussion on arabic drop initials/words/numbers: https://groups.google.com/forum/#!topic/persian-computing/W-Upl6DAEcg
# [03:32] * Joins: jh_hong (~jh_hong@public.cloak)
# [03:34] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [03:34] * dauwhe_ liam: that's great. Those are the first actual examples I've seen. Thanks!
# [03:36] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [03:39] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [03:39] * Joins: myakura (~myakura@public.cloak)
# [03:42] * Joins: tantek (~tantek@public.cloak)
# [03:43] * krit TabAtkins I just noticed that Bikeshed removed <pre> closing text which is leading to bad results
# [03:43] <krit> <div class=example>
# [03:43] <krit> Consider a shape that is clipped by a clipping path applied to an ancestor:
# [03:43] <krit> <pre><code class=html><g clip-path="circle()">
# [03:43] <krit> <path id="shape" d="M0,0 L10,10, L 20,0 z"/>
# [03:43] <krit> </g>
# [03:43] <krit> </code></pre>
# [03:43] <krit> The shape is referenced by a <a>'use'</a> element:
# [03:43] <krit> <pre><code class=html><use xlink:href="#shape"/>
# [03:43] <krit> </code></pre>
# [03:43] <krit> The geometry of the shape is not influenced by the circular clipping path.
# [03:43] <krit> </div>
# [03:43] <krit> oops
# [03:43] <krit> https://www.irccloud.com/pastebin/s2nE2bXp
# [03:44] <krit> gets to
# [03:44] <krit> https://www.irccloud.com/pastebin/CeY6YX28
# [03:44] * krit TabAtkins making the next part of <pre>
# [03:45] <TabAtkins> Hm, shouldn't be doing that. I'll investigate.
# [03:46] * dauwhe_ I think I had a similar issue, where I had to add more line breaks to avoid validity errors
# [03:46] <krit> TabAtkins: It seems not to do it if a </div> follows after </pre>
# [03:50] <TabAtkins> The new Markdown code is still a little bit buggy, sorry.
# [03:52] <krit> https://www.irccloud.com/pastebin/cj4sRSA8
# [03:52] <krit> TabAtkins: that is another error I get from the validator
# [03:54] <TabAtkins> krit: I can't reproduce your first error.
# [03:54] <TabAtkins> That validator issue is easy to diagnose. I think I fixed that yesterday.
# [03:54] <TabAtkins> Have you updated Bikeshed recently?
# [03:55] <krit> TabAtkins: happens in example 3 http://dev.w3.org/fxtf/css-masking-1/#clipping-paths
# [03:55] <krit> TabAtkins: yes
# [03:57] * SteveZ I am leaving webinar. Will be back at 1PM Korean time for Text
# [03:57] <TabAtkins> krit: Huh. I grabbed your source code from Masking and just ran it through bikeshed, and it does the right thing.
# [03:57] <TabAtkins> Got some context around as well, just in case.
# [03:58] <krit> TabAtkins: di you run make, or bikeshed?
# [03:58] <TabAtkins> I looked up Overview.src.html from my browser, found the example, copied out a chunk of it into a test document.
# [03:58] <TabAtkins> Then ran Bikeshed.
# [03:59] * Quits: lmclister (~lmclister@public.cloak) ("")
# [04:01] <krit> TabAtkins: hm, looks like i didn't run latest build
# [04:01] <krit> TabAtkins: issue 1 resolved :)
# [04:01] <TabAtkins> hahaha I KNEW IT
# [04:02] <TabAtkins> The other one looks like an unquoted title, which definitely happened before I fixed the problem.
# [04:02] <TabAtkins> I presume you have title="nonzero value" in your source?
# [04:03] <krit> TabAtkins: The following drawing illustrates the nonzero rule:
# [04:03] <TabAtkins> Oh! Use <a> like a normal person.
# [04:03] <TabAtkins> I don't do a lot of the fixup on .
# [04:04] <TabAtkins> Support for is pretty much just to appease fantasai
# [04:04] <krit> TabAtkins: just <a> freaks out the SVG preprocessor I still have to use
# [04:04] <liam> to appease fantas ?
# [04:05] <krit> TabAtkins: FATAL ERROR: No 'value' refs found for 'nonzero'.
# [04:05] <krit> TabAtkins: --> <a value>
# [04:06] <TabAtkins> Yeah, go look at your <dfn>. Bikeshed doesn't know it's a valuedef.
# [04:07] <krit> TabAtkins: so <dfn dfn-value>nonzero</dfn> ?
# [04:07] * liam guessing a productive session on editing is happening & discussion may resume after lunch?
# [04:08] <TabAtkins> Private discussion on how to resolve logical box properties with physical ones between fantasai and rossen.
# [04:08] <TabAtkins> The rest of us are on break.
# [04:08] <liam> tx
# [04:08] <TabAtkins> And me and krit are doing stuff.
# [04:08] <liam> doing = good
# [04:08] <liam> ftf time awesome for that.
# [04:09] <TabAtkins> krit: Either <dfn value for=clip-rule>nonzero</dfn>, or put <dl dfn-type=value dfn-for=clip-rule> and then just plain <dfn>
# [04:09] <TabAtkins> krit: rtfm ^_^
# [04:09] <krit> TabAtkins: fixed now. Thanks!
# [04:12] * Joins: zcorpan (~zcorpan@public.cloak)
# [04:17] * Quits: Henke37c (~Henrik@public.cloak) (Client closed connection)
# [04:19] <dael> Glenn Adams, Rossen Atanassov, Tab Atkins, David Baron, Adenilson Cavalcanti, Dave Cramer, Bruno de Oliveira Abinader, Elika Etemad, Daniel Glazman, Dongwoo Joshua Im, Koji Ishii, Dael Jackson, Philippe Le Hégaret, Chris Lilley, Peter Linss, Shinyu Murakami, Edward O'Connor, Simon Pieters, Andrey Rybka, Alan Stearns, Shane Stephens, Jet Villegas + 5 observers
# [04:20] <dael> Phone: krit, SteveZ, liam, Bert (dael - check at EoD)
# [04:21] * Joins: myakura_ (~myakura@public.cloak)
# [04:27] * Quits: myakura (~myakura@public.cloak) ("Page closed")
# [04:27] * myakura_ is now known as myakura
# [04:32] <zcorpan> plinss: glazou: plh and i added two suggested topics at http://wiki.csswg.org/planning/seoul-2014#wednesday
# [04:34] <dael> fantasai: First is logical properties in general. There's 4 impl. Webkit Microsoft Mozilla and AH and there's no spec.
# [04:34] <glazou> zcorpan: noted
# [04:34] <dael> fantasai: When I wrote it the WG said I wasn't allowed to (4 years ago)
# [04:34] <dael> fantasai: We're proposing the take that spec and resurect it seperatly and publish it as an ED with a FPWD shortly after
# [04:35] <dael> fantasai: Editors would be me and Rossen_ with murakami ghost editing.
# [04:35] * Joins: harayama (~harayama@public.cloak)
# [04:35] <dael> fantasai: Further commetns?
# [04:35] <dael> hober: It's a great idea. do it.
# [04:36] <dael> dbaron: I may have comments when it exists, but I'm happy to have it.
# [04:36] <dael> hober: If you check the UA stylesheet for right and left we clearly need it.
# [04:36] <dael> Rossen_: There's enough web content that it demands having this.
# [04:36] <dael> Rossen_: We don't want to go into technical now.
# [04:37] <dael> RESOLVED: ED of CSS Logical Properties
# [04:37] * Quits: jh_hong (~jh_hong@public.cloak) ("Page closed")
# [04:37] * Joins: lmclister (~lmclister@public.cloak)
# [04:38] <dael> dauwhe_: Should we try and use logical prop when writing specs?
# [04:38] * Joins: jhh (~jhh@public.cloak)
# [04:38] <dael> fantasai: I think all future drafts of layout should have logical and physical spec'ed together.
# [04:38] <dael> Rossen_: There's 2 exceptions, B&B and exclussions. It was demanded that we name all the properties from the start
# [04:38] <dael> hober: So exclussions is only logical
# [04:38] <dael> TabAtkins: Well we didn't have a way to mix.
# [04:39] <dael> hober: So where webkit has phsycial and logical, the shorthand is physical, so are there exclusion shorthands that are logical?
# [04:39] <dael> Rossen_: No. You have wrap-start, wrap-end and it's in the logical way of whatever we decide logical is
# [04:39] <dael> fantasai: And shorthands prob want a keyword to spec that it's logical.
# [04:39] <dael> hober: !logical
# [04:39] <dael> Rossen_: We can have an option
# [04:40] <dael> TabAtkins: Do we want to defer discussion about order for four sides in a marging
# [04:40] <dael> fantasai: The one that starts block-start, line start, block end, line end
# [04:40] <dael> hober: start after end before should be the order
# [04:40] <dael> TabAtkins: Depends on if you're english-specific
# [04:40] <dael> dbaron: What fantasai said matches arabic and hebrew
# [04:41] <dael> fantasai: But that gets you what's on the beginging half of the block to be set first.
# [04:41] <dael> TabAtkins: It's opposite way of the circle for somebody.
# [04:41] * Parts: adenilson (~anonymous@public.cloak) (adenilson)
# [04:41] <dael> fantasai: We have start comes before end so the shorthand should match that
# [04:41] <dael> hober: I was hoping for if I have a margin for lengths that's physical. If I put !logical at the end I don't see something different
# [04:41] <fantasai> s/match that/match that semantic/
# [04:42] <dael> TabAtkins: It won't happen. Either english is wrong and arabic is right or vice verse.
# [04:42] <dael> TabAtkins: And verical modes are completely a mess. We can bless one writing method with being identicial
# [04:42] <dael> TabAtkins: We have precedent with grid positioning.
# [04:42] <dael> TabAtkins: Grid only uses logical
# [04:43] <dael> hober: I'm not conviced, but we can discuss this later.
# [04:43] <dael> zcorpan: I agree with hober that it should be similar to the spirit of the phsyical
# [04:44] <dael> fantasai: But the spirit was lets go forwarda nd if we have four directions, lets go clockwise. If you're talking logical you don't go start to end, you do start,start corner
# [04:44] <dael> hober: In horizontal LR it would be odd if !logical made my margins float.
# [04:44] <dael> TabAtkins: I don't understand why that's valid because if people have a differently directioned language they can argue for a different result
# [04:45] <dael> plinss: One reason it is what it is if you leave things off and repeat you get logical (reasonable) results.
# [04:45] <dael> plinss: That rule is preserved.
# [04:45] <dael> hober: That's regardless of chioce
# [04:45] <dbaron> it's not pure repeating (for the 3 value case)
# [04:45] <dael> Rossen_: Currently most content is in physical.
# [04:45] <dael> Rossen_: If you have a keyword that breaks this half the time...
# [04:46] <dael> TabAtkins: So if someone is an idiot and converts to logical without thinking about it, you're left and right will swap.
# [04:46] <dael> zcorpan: I think people will use the keyword because i'ts cool
# [04:46] * Joins: murakami (~murakami@public.cloak)
# [04:46] * dauwhe_ This would be a bad time for to mention margin-inside and margin-outside ^_^
# [04:46] <dael> hober: If you have existing content and want to make it flip to logical, it should be as easy as possible
# [04:46] <dael> Rossen_: I can see libraries changing.
# [04:46] <plinss> s/rule is preserved/rule should be preserved/
# [04:46] * liam makes dauwhe_ read the XSL-FO spec :-) :-)
# [04:47] <dael> TabAtkins: And the first time a library switches people will see a bug. You're positing a library that forces you into logical
# [04:47] <dael> TabAtkins: They'd assume english and swap the values. You're assuming librabry authors are idiots.
# [04:47] <dael> TabAtkins: There's a different between one person that writes a plug for 100 webpages. Are you write a library and pushing without result?
# [04:48] <dael> clilley: THen people wouldn't use your library
# [04:48] <dael> TabAtkins: You want to make sure the omitting arguements makes sense.
# [04:48] <dael> hober: If you have two values it applies to the start and end. plinss argues we shouldn't do something pathalogical.
# [04:48] * Quits: glazou (~glazou@public.cloak) (Ping timeout: 180 seconds)
# [04:48] <dael> dbaron: The arguement is that the first two arguements 1 shoudl be block and 1 inline
# [04:48] <dael> fantasai: And we're arguing that of the two inlines that start should be first.
# [04:48] <dbaron> s/The arguement/peterl's argument/
# [04:49] <dael> hober: I think the underlying is that the org clockwise was a mistake, but it's one we'll live with forever and I think consistany with that mistake is a good thing.
# [04:49] * dauwhe_ what properties would mirror-universe Spock use to write CSS?
# [04:49] <dael> glaz: Are we done with logical properties?
# [04:49] * Joins: adenilson (~anonymous@public.cloak)
# [04:49] <dael> fantasai: WE can move to background-position x/y
# [04:49] * astearns !logical means clockwise, logical! means anti-clockwise
# [04:50] <dael> dbaron: To be clear, this is the day we have a 1-2 that needs to be 1-2 which means we need to break in the next 10 minutes.
# [04:50] <dael> fantasai: I'll present and we can ruminate over lunch.
# [04:50] * dbaron notes that lunch will not consist of grass
# [04:50] <dael> fantasai: The problem is we have a background position prop which takes two values (for simplicity)
# [04:51] * dauwhe_ only because we're not meeting in Boulder, Colorado
# [04:51] * plinss (hopefully)
# [04:51] <dael> fantasai: That are all keywords. They are top, center, bottom, left, center right. One from each set of 3
# [04:51] * liam wants !deosil and !widdershins
# [04:52] <dael> fantasai: When you throw in logical values you can do this or do inline-start, center, inline-end, and than block-start, center, block-end and pick 2 from each section
# [04:52] * TabAtkins liam: Ah, I was trying to recall what the funky clockwise word was.
# [04:52] <dael> fantasai: And than you have these properties that have been impl of background-position x/y and what do they map to?
# [04:52] * liam :)
# [04:52] <dael> fantasai: What do we assign to these long hands.
# [04:52] * liam "sunwise" as an alternative spelling.
# [04:53] * Quits: jhh (~jhh@public.cloak) (Ping timeout: 180 seconds)
# [04:53] <dael> fantasai: The other case is pick any two keywords from the <position> options and you can have top-start
# [04:53] <dael> fantasai: If you have english it's top left, arabic top-right, and japanese it's where the block starts.
# [04:54] <dael> fantasai: You've already constrained the first dimension, so you just have to pick the second.
# [04:54] <dbaron> case (1) is using only physical (top/center/bottom and left/center/right)
# [04:54] <dbaron> case (2) is using only logical (inline-start/center/inline-end and block-start/center/block-end)
# [04:54] <dael> fantasai: Let's say you have a sun and a fish background, you want the sun to be in the origan, not to be scrolled off so you'd want that in the start corner, but in the top for sure.
# [04:54] <dbaron> case (3) is mixing one value from case (1) with (start/center/end) (note no block- or inline-)
# [04:54] <dael> fantasai: So there's reasons to combine logical and physical.
# [04:55] <dael> fantasai: This world with a combination of logical/physical doesn't map to x and y axis.
# [04:55] <dael> Rossen_: What introduced background-position
# [04:55] <dael> fantasai: inline-block
# [04:55] <dael> TabAtkins: In the same way we'd have alias
# [04:55] <dael> fantasai: But we can't actually accept it as an alias
# [04:55] * sgalineau reading a discussion about logical properties backwards was not my best idea
# [04:55] <dael> TabAtkins: You can alias after you figure out writing modes.
# [04:56] <dael> hober: If you set margin sstart and inspect margin top
# [04:56] <dael> dbaron: So then the long hands let you spec combinations that can't be represented.
# [04:56] <dael> hober: So the margin shorthand if you have something global to the property line, the short hand is all physical or logical, but if you use longhand you can mix.
# [04:57] <dael> dbaron: So in your 3rd case of start-center-end they're values of x and y because they're not spec values of inline-start.
# [04:57] <dael> TabAtkins: That's how I was thinking I would handling the shorthanding.
# [04:57] <dael> dbaron: I don't quite follow the implications
# [04:57] <dael> zcorpan: If you are mixing the phsyical one can get into shorthand fine?
# [04:57] <dael> zcorpan: So if you have top-start than it goes into position-y.
# [04:58] <dael> zcorpan: The problem is if you spec both as logical?
# [04:58] * Joins: jh_hong (~jh_hong@public.cloak)
# [04:58] <dael> fantasai: That's this whole mess and having these properties mapping there's an adidtional problem with all of the other cases with logical prop the initial values are identical
# [04:59] <dael> fantasai: If they all have 0 and there's no conflict. But here with background-position-x/y they'll be top left. That's fine in english, but in other languages it'll be inconsistant
# [04:59] <dael> dbaron: And you need to know which one to use.
# [04:59] <dael> fantasai: And you can't use a cascase because there isn't one.
# [04:59] <dael> TabAtkins: I say spec by fiat
# [04:59] <dael> dbaron: There's another way. If you haev something spec for one, if the winning is background-posistion-y you use that for x, but if the winning is background-inline that wins
# [05:00] <dael> dbaron: It could be 2 but one gets overridden
# [05:00] <dael> hober: But with none?
# [05:00] * plh rrsagent, where am I?
# [05:00] * RRSAgent See http://www.w3.org/2014/05/21-css-irc#T03-00-06
# [05:00] <dael> dbaron: We leave the current defual
# [05:00] <dael> TabAtkins: So if we do fiat physical, if you speck background-position-block and you spec in the direction, ir should work.
# [05:00] <dael> TabAtkins: I'm fine with that.
# [05:00] <dael> dbaron: I'm okay. It's more complex than I was hoping.
# [05:00] <dael> fantasai: Yeah.
# [05:01] <dael> fantasai: It would have been nice to avoid the longhands.
# [05:01] <dael> hober: It would be prob premature to res on res in this way since we haven't tried, but let's agree the initial spec should be this way and we'll alter if needed.
# [05:02] <dael> [whiteboard photo from dbaron]
# [05:02] <dael> [break = lunch]
# [05:07] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [05:07] * Quits: jh_hong (~jh_hong@public.cloak) (Ping timeout: 180 seconds)
# [05:07] <dbaron> whiteboard photo: http://lists.w3.org/Archives/Public/www-archive/2014May/att-0008/dsc06433-fantasai-whiteboard.jpg
# [05:08] * Quits: andrey (~andrey@public.cloak) (Ping timeout: 180 seconds)
# [05:09] * Quits: shans_ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [05:09] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
# [05:10] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [05:13] * Quits: dauwhe_ (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [05:20] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [05:29] * Quits: dael (~dael@public.cloak) (Ping timeout: 180 seconds)
# [05:32] * Joins: myakura (~myakura@public.cloak)
# [05:39] * Joins: dauwhe (~dauwhe@public.cloak)
# [05:53] * Joins: andrey (~andrey@public.cloak)
# [05:54] * Joins: dael (~dael@public.cloak)
# [05:55] * Joins: jh_hong (~jh_hong@public.cloak)
# [05:56] * Joins: adenilson (~anonymous@public.cloak)
# [05:59] * SteveZ Steve is here
# [05:59] * fantasai waves
# [05:59] * dauwhe Hello, Steve!
# [05:59] * SteveZ waves back
# [05:59] * liam waves to Steviepoos
# [05:59] * Joins: glazou (~glazou@public.cloak)
# [05:59] <glazou> Bert: yt?
# [05:59] * liam hears the arrival also of the Vogon fleet
# [06:00] <dael> glaz: Let's start even if Bert isn't here.
# [06:00] <dael> glaz: First is CSS 3 Text
# [06:00] * dauwhe Groop, I implore thee, my foonting turlingdromes
# [06:00] <dael> glaz: And we have 5 sub items. First is texxt-align short ending
# [06:00] <dael> fantasai: We discussed this at Paris F2F
# [06:01] <dael> fantasai: We currently have a text-slign property and we have text-align-last prop.
# [06:01] * glazou SteveZ said "woof woof" ; we should save that for the minutes :-D
# [06:01] <dbaron> s/short ending/shorthanding/
# [06:02] <dael> fantasai: They're currently independant and we think that we can make text-align-last a longhand for text-align
# [06:02] <dael> clilley: With making it take an optional 2nd value?
# [06:02] <dael> fantasai: That's one poss.
# [06:02] <dael> fantasai: The case were people use align-last is auto or justify, which means justify the last line b/c it's not be default
# [06:03] <dael> dauwhe: We call this forced justiciation in my work
# [06:03] <dael> fantasai: In Japanese people with set text-align: justify, text-justify: distribute and text-align-last: justify.
# [06:03] <dael> fantasai: We elimated that last step to make it easier
# [06:03] <dael> fantasai: We were going to tie in to have it happen only end justification is happening
# [06:04] * liam compares http://www.w3.org/TR/2012/WD-xslfo20-20120117/#text-align-last
# [06:04] <dael> clilley: So you mean that you can set text-align-last to justify and only the last line will justify?
# [06:04] <dael> fantasai: Yeah
# [06:04] <dael> fantasai: The prop on the table was to have text-align and text-align-all which would take the other values
# [06:04] <dael> fantasai: We also have where people would want hte first line aligned for poetry or something.
# [06:05] * liam wonders why you can't use :first-line
# [06:05] <dael> fantasai: Currently we have an issue in the spec where we need a name for that and we'll drop it if we can't find a name
# [06:05] <dael> TabAtkins: Can you apply text-align to first line?
# [06:05] * Joins: shans_ (~shans@public.cloak)
# [06:05] <dael> fantasai: I don't know. I think you could.
# [06:05] <dael> TabAtkins: They don't cascade together.
# [06:05] <dael> fantasai: The cascading is a bit of a problem.
# [06:05] <dael> fantasai: I think it is do we want to switch text-align to a short hand and potenitally a text-align-first
# [06:06] <dael> dbaron: I think you had expalined a case where the first and last lines should work differently in cascade terms.
# [06:06] <dael> fantasai: When you set first diff from all you want to make sure you're restting all the alignment in the next declaration
# [06:06] <dael> fantasai: The q was do we want text align as a delcaration.
# [06:06] <dael> fantasai: Should/would that obliterate a privious text-align
# [06:07] <TabAtkins> s/first line/::first-line/
# [06:07] <dael> dbaron: I think it's where -last applies to anything before a break.
# [06:07] <dael> dauwhe: That's something that's tripepd me on text-align-last that it applies after a forced line break
# [06:07] <dael> dbaron: I rememebr there's something not semetric and you convined me they should cascade sperate
# [06:08] <dael> glaz: can we use text align on the first and last line pseudo?
# [06:08] <SteveZ> As I recall, "text-align-last" applies to paragraphs that have only one line
# [06:08] <dael> fantasai: I won't cascade correctly. If you override and want thigns to center, it won't work because the pseudo is more specific.
# [06:08] <dael> fantasai: That's a problem that shows up in various problems since the cascade rests things that are on the pseudo
# [06:08] <dael> TabAtkins: I wouldn't call that killer, but it's a down side
# [06:09] <dael> TabAtkins: Bolding the first line differently happens quite a bit. We use first-line for a lot of things that fall into a similar bucket and we're okay with making those not cascade.
# [06:09] <dael> dbaron: I think text-align-last wouldn't work with a last-line pseudo
# [06:10] <dael> dauwhe: I wish it was the last line. It would solve a lot of my problems.
# [06:10] <dael> dbaron: You want the opposite too
# [06:10] <dael> fantasai: You want a property for both things. No one has brought that up before.
# [06:10] * SteveZ it is hard to hear Dave
# [06:10] * liam fears Dave has been Assimilated
# [06:11] <dael> dauwhe: I can work up examples, but we run into problems where we're trying to force a line break. In inDesign there's a lot of ways to do a line break and you can't do that in CSS because it'll force justify the last line even if it only has two characters
# [06:11] <dael> fantasai: Okay.
# [06:11] * liam notes that cascading is generally less important for people generating print from their own content (!) or for epub
# [06:11] <dael> fantasai: I think I need to work on reloading the previous discussions into my brain. Unless there's something else to point out, I'll do that as we discuss other things
# [06:12] <dael> liam: We added a bunch of stuff for XFL-FO for this. We have a bunch more values there and I'd have to look at how they interact
# [06:12] <dauwhe> s/XFL-FO/XSL-FO/
# [06:12] <dael> glaz: Okay.
# [06:12] <dael> fantasai: most recent prop was text-align and a shorthand for -all and -last where they take the same values except -last takes auto
# [06:12] <liam> [xsl-fo text-align-last has relative | start | center | end | justify | inside | outside | left | right | inherit ]
# [06:13] <liam> http://www.w3.org/TR/2012/WD-xslfo20-20120117/#text-align-last
# [06:13] <dael> fantasai: The other is that they have the values that are attached to each. S you can set to justify: justify but it reads better.
# [06:13] <dael> fantasai: So in most cases, the authors only need one keyword.
# [06:13] <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Aug/0391.html
# [06:13] * SteveZ who is chopping wood?
# [06:14] <fantasai> s/The other is that they have the values that are attached to each./The text-align shorthand takes one or two keywords, second one setting text-align-last. Alternately a justify-all keyword./
# [06:14] <dael> fantasai: I guess we should go to the next issue while I find old minutes where we discussed
# [06:14] <dael> dbaron: I could be mis rememebring
# [06:15] <dael> fantasai: It was something about when you set text-align-last and you set the rest of it, if you want the rest of it to...um...
# [06:16] <dael> fantasai: If you only have one line it'll be text-align first takes priority, folowed by -last, followed by -therest
# [06:16] <dael> SteveZ: I dont understand how -first takes priority because it would be wrong for western.
# [06:16] <dael> fantasai: If it's not justify.
# [06:16] * hober text-align-most, text-align-middle :)
# [06:16] <dael> SteveZ: Is that why text align-last took priority
# [06:16] <dael> fantasai: I think -first take auto or start becasue there's no use case for antoher value
# [06:16] <dael> SteveZ: What's auto mean?
# [06:17] <dael> fantasai: do same as text-align-all
# [06:17] <dael> SteveZ: There's 4 componets? -all, -first, -last
# [06:17] <dael> fantasai: And the shorthand text-align
# [06:18] <dael> SteveZ: I still think -first doesn't work because -all will want to be, in wetern you want all but the last line just
# [06:18] <dael> fantasai: You leave first as auto
# [06:18] <dael> SteveZ: But if it's priory it's justify
# [06:18] <dauwhe> s/wetern/Western/
# [06:18] <dael> dbaron: Auto says nothing special for the first, keep going
# [06:18] <dael> SteveZ: But you have to decide if the first is just
# [06:18] <dael> fantasai: I see what you're saying. Start takes priority but auto doesn't
# [06:18] <dael> TabAtkins: It's same as start-self.
# [06:19] <dael> astearns: But in western you want to take the text-align value if there's only one line.
# [06:19] <astearns> s/text-align/text-align-last/
# [06:19] <dael> fantasai: dauwhe problem he brough about different behviour form last line vs after a forced break. It means another prop
# [06:19] <dael> fantasai: And if we add that is text-align-last actually the last line, or after breaks.
# [06:19] <dael> koji: Is there a use case?
# [06:20] <dael> dauwhe: The use-case is tied in details of hypenations and justification of text, but we get requests to alter a lot.
# [06:20] <dael> dauwhe: If that happens outside the paramenters, you do a soft return and than that line is justified. That's desireable for us
# [06:20] <dael> dauwhe: We don't want to force that just to the last line usually.
# [06:20] <dael> dbaron: So we need a mech for that. For saying a break should be treated as a non-forced
# [06:21] <liam> +1
# [06:21] <dael> dauwhe: Yeah.
# [06:21] <dael> fantasai: That makes more sense.
# [06:21] <dael> dauwhe: I know it's an oddball use case.
# [06:21] * Joins: Rossen_ (~Rossen@public.cloak)
# [06:21] <SteveZ> I agree that a softbreak should not be treated as a hard break
# [06:21] * Joins: koji (~koji@public.cloak)
# [06:21] <dael> astearns: I think it comes up where people try and use a break and are confused that it's a paragraph break when they want a soft break
# [06:22] <dael> koji: So iss the break feel alrigt?
# [06:22] <dael> dauwhe: It feels liek a different break character
# [06:22] <dael> glenn: Is there a unicode that has that sematic?
# [06:22] <dael> fantasai: There's a soft break that we don't want to get into here.
# [06:22] <dael> dbaron: I'm of the opinion that if we can't rememebr why to seperate, we should combine
# [06:23] <dbaron> I found http://lists.w3.org/Archives/Public/www-style/2013Aug/0391.html
# [06:23] <dbaron> fantasai is quoting from Minutes 2013-11-12 Tues IV
# [06:23] <dael> fantasai: Minutes from last F2F, we were ambivilent, than we heard from digipub and they said it would be better to go short-hand long-hand
# [06:23] <dael> plinss: Unicode does have a line seperated vs paragraph seperater
# [06:23] <dael> fantasai: I think that's the bidi(?) one
# [06:23] <dael> fantasai: It's similar to soft
# [06:24] <dael> dbaron: If we agree we want that use case to be from a soft-break, we don't need to do that now
# [06:24] <dael> fantasai: So let's agree it'll be solved by a soft-break mechanism.
# [06:24] <dael> koji: There's two issues in text-align I understand
# [06:24] <dael> fantasai: I can defer text-align-first to the next level. We don't have a good shorthand.
# [06:24] <dbaron> s/good shorthand/good way to express it in the shorthand/
# [06:25] <dael> fantasai: I think we need text-align-all and -last with text-align as the shorthand
# [06:25] <dael> fantasai: I think that's what we want to do. We should make that change and than go back to soft-breat
# [06:25] <dael> dbaron: So text-align is a shorthand and takes one or two values
# [06:25] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [06:25] <dael> fantasai: Or the shorthand justify-all
# [06:25] <dael> SteveZ: So how do I get wester to align all but the last line?
# [06:26] <liam> s/western/western layout/
# [06:26] <dael> fantasai: Justify.
# [06:26] <dbaron> s/Justify/text-align: justify/
# [06:26] <dael> fantasai: Any other comments?
# [06:26] <dael> RESOLVED: text-align as shorthand for text-align-last and text-align-all
# [06:26] <dael> SteveZ: My understanding of french poetry is the first line is left just and the rest if right.
# [06:27] <dael> fantasai: We're def. that to 4
# [06:27] <dael> SteveZ: What I'm curious is if I say text-align: right and than say text-align: na and text-align: start that will work
# [06:27] <dael> fantasai: Yes.
# [06:27] <dael> dbaron: But that's what's defer to level 4
# [06:28] <dael> fantasai: Part of the reason is that's fine in general if the browser supports, but if it doesn't you get all right align and that's not the fallback you want
# [06:28] <dael> fantasai: We want a way to express that in shorthand so that declaration that makes the other lines go right gets thrown out by newer browsers
# [06:28] <dael> s/newer/older
# [06:28] <dael> fantasai: That gives us a migration forward. no one has come up with a good way to express this in the shorthand. We've asked for keywords and no one has come u p with one.
# [06:29] <dael> fantasai: Unless there's a keyword, we're going to drop
# [06:29] <dael> dbaron: It could be a / to seperate the first and the all/last
# [06:29] <dael> fantasai: Maybe.
# [06:29] <dael> dbaron: I'm fine dropping it
# [06:29] <dbaron> s/Maybe./Maybe. ... would not be super-clear./
# [06:29] <dael> RESOLVED: Defer text-align-first to level 4
# [06:30] <fantasai> s/text-align-first/text-align-first and text-align: start-end/
# [06:30] <fantasai> We are in need of an understandable keyword for start-end
# [06:30] <dael> fantasai: And we have to go back to the soft break
# [06:31] <dael> fantasai: Current spec says that text-align-last takes affect after every force break. If we want to say except line seperater we can.
# [06:31] <dael> fantasai: line seperater is intended to be a soft break because it doesn't break to bidi pparagraph
# [06:31] <dael> dauwhe: I found a unicode where line seperater corripond to HTML <break>
# [06:31] <dael> clilley: But understanding of break is often wrong
# [06:32] <dael> fantasai: We did compat and found that is a paragraph seperator
# [06:32] <dael> dauwhe: Can we apply a prop to break itself?
# [06:32] <dael> plinss: Didn't we def break as replaced content?
# [06:32] * Joins: zcorpan (~zcorpan@public.cloak)
# [06:32] <dael> fantasai: my one concern is you have a bidi embedded...if you're doing a hard break it's a semantic break.
# [06:32] <zcorpan> s/<break>/ /
# [06:33] <dael> fantasai: If you have a multi-line quote and you might have an embedding and you don't want to break the embedding.
# [06:33] <dbaron> s/quote/quote in poetry/
# [06:33] <fantasai> s/embedding/embedding on the line breaks/
# [06:33] <dael> dauwhe: I'll send out what I've been testing for this unicode character
# [06:33] <dael> fantasai: I'm not sure line-seperator is a good option
# [06:34] <dael> fantasai: I'm not sure it's not either.
# [06:34] <dael> koji: Since most of these cases are for a single line, can we consider changing this to be last-line? The point I'm not sure is if we need the options.
# [06:34] * Joins: yamamoto (~yamamoto@public.cloak)
# [06:34] <dael> koji: I'm not sure if it wants to consider as a line.
# [06:35] <dael> dauwhe: So you might be okay with text-align-last not applying before first line breaks
# [06:35] <dael> koji: From major use cases I'm fine
# [06:35] <dael> fantasai: In Japan if you're just the very last line, if you have more text youw ant to jsutify all those.
# [06:35] * liam hopes fantasai can justify that assertion
# [06:35] <dael> fantasai: You'll find use cases where you want to justify all but the last line, but not the lines that are after a forsced break which isn't hte last line
# [06:36] <dael> fantasai: So having it apply to all is right, though you might want something to restrict and not apply to the last line.
# [06:36] <dael> dauwhe: I feel need to mull this over
# [06:36] <dael> fantasai: WE can leave that there. We need another WD cycle anyway
# [06:36] <dael> plinss: grapheme cluster termonology
# [06:37] <dael> fantasai: So we've alises the term character to grapheme cluster so we can jsut say character
# [06:37] <dael> clilley: And this has a lot of problems where people think that character means different things
# [06:37] <dael> clilley: Logically you can say right is left, but it's still confusing
# [06:38] <dael> fantasai: Character has a lot of means and we picked one definition
# [06:38] * astearns proposes graphtainer
# [06:38] <dael> fantasai: This gets word. i18n said people will be confused and you should use the right term
# [06:38] * dauwhe graphenetainer
# [06:38] <dael> fantasai: Having heard from James Clark about Tai letter spacing vs line break, we have to conclude there's two things we're talking about
# [06:39] <dauwhe> s/Tai/Thai/
# [06:39] <dael> fantasai: one is the grapheme cluster in regards to space and one is to line breaking
# [06:39] <dael> clilley: And which is unicode?
# [06:39] <dael> fantasai: Neither
# [06:39] <dbaron> s/in regards to space/with regards to spacing/
# [06:39] <dael> fantasai: unicode is trying to solve both problems, but targeting line breaking.
# [06:40] <dael> fantasai: In order to do correct line breaking, you'll have to extend to meaning of grapheme cluster
# [06:40] <dael> fantasai: Unicode allows for taloring for this case. They are aiming at the line breaking unit and the def they have is mostly there
# [06:40] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [06:40] <dael> fantasai: Then we have spacing where in some cases it's larger than the grapheme cluster but in Thai it's smaller.
# [06:40] <dael> fantasai: And some of those you have to deconstruct to construct correctly
# [06:40] <liam> "lump"
# [06:40] <dael> fantasai: So now we don't want character or grapheme cluster.
# [06:41] <glazou> "graster"
# [06:41] <dael> fantasai: So. Does anyone have suggestions?
# [06:41] <glazou> "glazter"
# [06:41] <zcorpan_> "mario"
# [06:42] <dael> TabAtkins: At this point we're in the foo/bar territory
# [06:42] <dael> dauwhe: Does first letter make this more complicated?
# [06:42] * liam spray-paints the bike shed with "glyph cluster"
# [06:42] <dael> fantasai: No I think it mostly uses line breaking.
# [06:42] <Shinsuke> koji
# [06:42] * Rossen_ WCHAR
# [06:42] <dael> koji: We could go line-break point as grapheme cluster and define spaceing as something.
# [06:43] * glazou it seems "graster" is trending :-)
# [06:43] <dael> clilley: You could denife a new term so they have to look it up.
# [06:43] <liam> LCBO is where we get da booze eh?
# [06:43] <liam> (there is also the Beer Store)
# [06:43] <dael> clilley: Letter Spacing break oppertunity is LSBO
# [06:43] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [06:44] <dael> fantasai: So. Unless there are further suggestions we can move on.
# [06:44] * dauwhe new rule: don't talk about CSS text on the last day of a F2F
# [06:44] <dael> SteveZ: One comment. It seems to me the grouping is more important than the breaking aspect
# [06:44] * dbaron suspects hober's friend is w3cmemes
# [06:45] <dael> SteveZ: So I didn't like letter spacing break oppertunity and prefered talking of nature groups
# [06:45] <dael> fantasai: Break opportunity is a break between these "things" and we need a name for the "things"
# [06:45] <dael> fantasai: If you're reading this definition, I wanted a one sentence of what this property does
# [06:45] <dael> SteveZ: How about unitary characters
# [06:46] <dael> koji: You mentioned using HTML?
# [06:46] * glazou if LCBO hosts a CSSWG ftf, can we do some testing ? :-D
# [06:46] <dael> fantasai: It's different. I don't think they mean grapheme cluster
# [06:46] <dael> TabAtkins: It's codepoint or scalor value. On or the other.
# [06:46] <dael> zcorpan_: It's both in HTML. It's scalor if it can be, elsewise it' codepoint.
# [06:47] <dael> TabAtkins: scalori s a subset of codepoint that exlused the lone surregate.
# [06:47] <dbaron> s/scalori s/scalar value is/
# [06:47] <fantasai> visually-perceived character and semantically-perceived character?
# [06:47] <dael> TabAtkins: It's nto relevenet since I'm not talking about code points.
# [06:47] <fantasai> (Unicode calls Grapheme clusters "user-perceived characters")
# [06:47] <dael> zcorpan_: HTML is complicated because it wants scalors and codepoints
# [06:48] * liam not sure that's appropriate for e.g. Hindi
# [06:48] <dael> dbaron: So how about creating CSS charaters
# [06:48] <dbaron> s/CSS charaters/the term "CSS character"/
# [06:48] <dael> hober: CSS character would be confusing witht he ch
# [06:48] <dael> fantasai: I think it's a problem with parsing
# [06:49] <dael> TabAtkins: I changed all references from character to codepoint
# [06:49] <dael> clilley: The reason there was a link to character, is that he thought that he would use an existing definition
# [06:49] <dael> fantasai: He picked a different definition and didn't realize that.
# [06:49] * liam thinks we could have shady characters and shifty characters
# [06:50] <dael> fantasai: Anyways. i'm gonna put up a chart on the whiteboard and over the next break you can add suggestions
# [06:50] <dael> koji: No opposition to CSS characters?
# [06:50] * astearns we could follow terrible html terms and use 'palpable character'
# [06:50] * dbaron thinks the Earl of Gloucester is an important character (in King Lear)
# [06:50] <dael> fantasai: There isn't a dominant one, really. We need two terms.
# [06:50] <zcorpan_> http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#unicode-code-point was what i was thinking about. not called "character" though
# [06:50] <zcorpan_> actually it is "character"
# [06:51] <dael> fantasai: What's next?
# [06:51] <clilley> palpatine character? yes emperor
# [06:51] <dael> plinss: Def text-justify: auto
# [06:51] * Joins: murakami_ (~murakami@public.cloak)
# [06:51] * zcorpan_ TabAtkins ^
# [06:52] * TabAtkins zcorpan, Yeah, so it's "code point". ^_^
# [06:52] * clilley wonders if plane 14 language switching codes are 'palpable'
# [06:52] * TabAtkins with some editorial magic that lets him talk about code units and code points interchangeably and have it do what he means.
# [06:53] <dael> [spec text being projected]
# [06:53] <liam> [text-justify - at one point i'd proposed (and the wg accepted) a property to let the user ask for a named justification/line-breaking] algorithm
# [06:53] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [06:54] <fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013
# [06:54] <dael> fantasai: The issue was...(link above)
# [06:54] <dael> fantasai: I believe this is text-justify: auto being more international one.
# [06:54] <fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013#issue-57
# [06:54] <dael> koji: 57 where there was feedback that we accepted
# [06:55] <dael> fantasai: The i18n group wanted us to be more explicite about UA doing the right thing in all cases
# [06:55] <dael> fantasai: Current state is that if you don't spec a language tag on your text is uses western justification
# [06:55] <dael> fantasai: This is aproblem for CJK texts because there's no spaces and that we dropped text-justify: interideographic in favor of auto
# [06:56] <dael> fantasai: But there's pages out there that use auto assuming it's work for CJK.
# [06:56] <dael> fantasai: We said where UA if possible sure use the approapriate spacing for the text, but we added a better example.
# [06:56] <dael> fantasai: [reads example 10 text]
# [06:57] <dael> fantasai: That will cause CJK pages that set text-align: justify to start justifying which I hope wouldn't break anything.
# [06:57] <dael> fantasai: We go futher saying if you know the content language you can be more sophisticated.
# [06:57] <dael> clilley: I like that it includes English as a more specific thing. Can you remind me of the letter definition
# [06:58] <dael> fantasai: So it's a grapheme cluster where it's not spaces, not punctuation, not whatever the n catagory way
# [06:58] <dael> fantasai: I want to go oevr this with impl to see if it's okay or if they want more explict text, or if they won't justify CJK without a languge tag...
# [06:58] * zcorpan_ TabAtkins if it were then the html spec would just say "code point" instead of being complicated. but whatever
# [06:59] <dael> clilley: This appears to only be for unrecognized language. So this allows them to do this for any language. So this is only about special languages where you don't have something for it
# [06:59] <dael> fantasai: We want UA to justify with CJK spacing by default
# [06:59] <dael> clilley: And that's testable and I like that.
# [06:59] <dael> fantasai: So I wanted to hear from impl what they think.
# [06:59] * TabAtkins zcorpan_: Nah, the editorial magic is useful. But still, the actual set of things he's referring to are codepoints.
# [06:59] <dael> SteveZ: What happens for languages like arabic which don't put spaces?
# [07:00] <dael> fantasai: What happens is with arabic you put spaces and just at spaces. for Thai if there's a space you just at that space and if there isn't you would expand between clusters
# [07:00] <dael> fantasai: The requires a 2 level justufucation algorithm.
# [07:00] <dael> clilley: So that algorythm is wrong for Thai?
# [07:00] <dael> fantasai: Thai spaces between grapheme clusters.
# [07:00] <dael> fantasai: Word spereators are characters
# [07:01] <dael> SteveZ: So it's letter spacing
# [07:01] <dael> dbaron: This is when there's no language tag. So it would be useful to have more clear req. here.
# [07:01] <dael> dbaron: I think the current text assume the impl knows more about world lang thant hte spec author and that's not usually the case.
# [07:01] <dael> dbaron: It won't be wide knowledge.
# [07:02] <dael> dwim: I did text-justify in Blink and I can do English and Korean, but I don't know arabic and what they pref. More spec. cases are needed.
# [07:03] <dael> fantasai: If you impl primaryily expanding word seperators alsong with secondary expanding, you get there. But if we have an impl that has better knowledge I want them to be able to do that
# [07:03] <dael> clilley: So could choose needs to be changed. This is the minimal. So a test with a nonsense lang is needed.
# [07:03] <dael> dbaron: So it's also useful to say when there's a lang spec.
# [07:03] <dael> fantasai: It's here.
# [07:03] <dael> dbaron: That's not much.
# [07:04] <dael> dbaron: I think the spec is unclear enough it'll be ignored. So if not ignored you should spec.
# [07:04] <dael> clilley: You remove the part that says ex 10 and you make it non-mornative. People with good knowledge of second language, you let them do that with your second sentence
# [07:04] <dael> fantasai: We want the UA to use a universal comprimise, but it can be more specific.
# [07:05] <dael> clilley: So make it normative by saying this is the minimal required. Say from primarily onwards this is the baseline.
# [07:05] * liam q+
# [07:05] <dael> koji: But than what's minimal. Can you swap secondary and primary?
# [07:05] <dael> zcorpan_: You can also say if you have better, give me feedback?
# [07:05] <dael> glenn: I like it as is
# [07:05] <dael> zcorpan_: Is there a problem with spacing between characters in english
# [07:06] <dael> fantasai: Yes. I fyou haev a mix of CJK and other on the line, you want to spec between characters.
# [07:06] <dael> liam: There's a problem in german. Letter spacing is used for emphasis.
# [07:06] <dbaron> s/spec between characters/space between the CJK characters and not the English; you could space between the English as a tertiary measure/
# [07:06] <dael> liam: A year ago I had an action item, I had sent a prop to let the author to name which alg they want for line breaking and that was for CSS 4 text.
# [07:07] <fantasai> dbaron, maybe adding "and should, at minimum, adequately handle both Western and non-Western scripts by default" ?
# [07:07] <dael> liam: I hadn't realized I had that action, I'll rewrite the propsal for advanced linebreaking and some of this could be refered to such a property
# [07:07] <fantasai> [insert example here]
# [07:07] <dael> clilley: It could be useful.
# [07:07] * Joins: Rossen__ (~Rossen@public.cloak)
# [07:08] <dael> liam: Maybe you wen're on he call, but the goal was, when you do a better line-breaking a lot of the research has been print and it goes wrong for screen.
# [07:08] <dael> liam: If you use the line-breaking algoritm and you edit the text, you insert your pointer and type so the dynamic makes you pointer move up and down by a few lines.
# [07:08] <dael> liam: That's not accepable.
# [07:09] <dael> liam: I was going to let you say you plan to edit this and do that shortly before you start the editing. That would tell the user agent you accept the text as is and don't refind line breaking. For print you can optimize just a few lines.
# [07:09] <dael> liam: Than you get something that's slightly better. Being about to say an end is useful for several languages.
# [07:09] <dael> fantasai: Any further comments on this?
# [07:10] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [07:10] <dael> koji: A comprimise that's not suboptimal for CJK so IE will have some justification issues for quality.
# [07:10] <liam> [ proposal from last March - http://lists.w3.org/Archives/Public/www-style/2013Mar/0183.html ]
# [07:11] <dael> koji: You have something optimal for CJK and now we're removed it. If language isn't spec it's suboptimal for CJK.
# [07:11] <dael> fantasai: CJK is secondary anyway because if you have a line with a spac you just the spac. JL rec says that already.
# [07:11] <dael> fantasai: I think it compresses instead of expand.
# [07:11] <dael> koji: Compressing is okay. Expanding... Anyway.
# [07:11] <dael> koji: Since we're talking line breakign changes anyway.
# [07:12] <dael> fantasai: dbaron did you see the IRC text?
# [07:12] * dauwhe high-end typesetters often have rules that you can only reduce letter- and word-spacing to justify text, never increase space.
# [07:12] <dael> dbaron: It's so far from what an impl would write. This spec is sayin do a pile of research.
# [07:12] <dael> clilley: If you want.
# [07:12] <dael> fantasai: I had more spec and people said they don't want more spec.
# [07:12] <dael> clilley: I was pushing for more specific.
# [07:12] <dael> fantasai: I can't please both directions.
# [07:13] <dael> SteveZ: The main comment I wanted to make is whatever you write should be testable and some things I heard didn't sound testable
# [07:13] <dael> fantasai: Auto is to "do the right thing" and we don't say what that is
# [07:13] <dael> SteveZ: Which makes it hard to test and get interop
# [07:13] <dael> fantasai: I'll need 6 montsh research to spec the right thing plus a research budget.
# [07:14] * liam thinks there might be travel advisories against travel to thaland this week, sorry
# [07:14] <dael> fantasai: I can't give yout he alg.
# [07:14] <dael> dbaron: So how should impl?
# [07:14] <dbaron> s/impl/implementors do it/
# [07:14] <dael> Rossen__: So why is it in the spec
# [07:14] <dael> fantasai: Because we need to say a baseline of how to justify.
# [07:15] <dael> fantasai: I don't have the answers and I've been doing this for 10 years. If you want an algorithm, I don't have it.
# [07:15] <dael> fantasai: I don't have actionable requests.
# [07:15] <dael> fantasai: I can answer spec questions, but if you want a step by step algorithm, I can't do that.
# [07:15] * glazou let's clusterize everything
# [07:15] * fantasai you mean grasterize, right? :)
# [07:15] * fantasai thanks Steve :)
# [07:15] <dael> SteveZ: I thought I heard two things useful.
# [07:16] * liam "thought"?
# [07:16] * glazou fantasai don't tempt me :-D
# [07:16] <dael> SteveZ: 1 was clilley point that we need a nonesense language to test and 2nd we need an algorithm that processes that nonsense lang which I thought was prioritize existing spaces or use letter spacing
# [07:16] <dael> SteveZ: That's testable
# [07:17] <dael> SteveZ: Outside the nonsense language you can't test because people may have heuristics that let them do a better job
# [07:17] <dbaron> https://www.rfc-editor.org/rfc/rfc6919.txt has "SHOULD CONSIDER" which seems to match this case
# [07:17] * plh proposes klingon to test justification
# [07:17] <dael> fantasai: There's simple cases where we can say you should get this result
# [07:17] <dael> fantasai: But we can't say here's the algorithm you must use.
# [07:17] * glazou plh, eh css is more complex than klingon ;-)
# [07:18] <dael> fantasai: So we can say here's a praragraph of latin words with spaces and we can test if it's been handled correctly. And than do 5 CJK characters in a 6em box and than Thai and than etc. We can't test script mixing because people will want to have different priorities
# [07:18] <dael> fantasai: So we can test, but we can't spec more than a few outputs on a test case.
# [07:18] * hober glazou plh: klingon's justification rules are the same as english
# [07:18] * glazou wonders how to write "grapheme cluster" in klingon though
# [07:18] <dael> fantasai: I can say you should have these outputs, but nothing more spec.
# [07:19] <clilley> "I can't define justification, but I know it when I see it"
# [07:19] <dael> dbaron: This sounds hard to jsutify spending time on because we'll write some code, someone will tell us it's wrong, we have to re-write and on and on and we may as well stick witht he western behaviour
# [07:19] * plh notes to David that it's called "job security"
# [07:19] <dael> clilley: That seems worse. Unless you're well known you get english.
# [07:19] <dael> TabAtkins: If you're not known you have to be a special case.
# [07:19] * hober glazou: closest I an get is "Degh"
# [07:20] <dael> clilley: Well the prose is something where her'es a good way for spacing in general and if there's special cases you can do that better.
# [07:20] * hober (that means "symbol")
# [07:20] <dael> fantasai: What are you asking me to do dbaron ?
# [07:20] * glazou let's adopt Degh
# [07:20] <dael> dbaron: I'm curious what other impl think they'll do. I'd rather have an alogrithm in the spec that's better than what we have and we can move toward and have something where if people say they think we can do better in their language, tell them they should get it in the spec.
# [07:21] * liam wonders if it'd be better to have a set of justification-in-language-X documents?
# [07:21] <dael> clilley: Yeah. So people will come with different opinions and this can get concensus of how things can be.
# [07:21] <dael> plinss: This is sounding like counter-styles.
# [07:21] <dael> zcorpan_: An algorithm in the spec that we know is wrong and can get feedback and importove is more likely to get interop
# [07:21] <dael> zcorpan_: You can put in a bit note saying it's prob. wrong
# [07:21] <dael> clilley: It's prob sub-optimal
# [07:22] <dael> SteveZ: The Japaense layout req taskforce is the best to capture what you need and even they recognie that it's house styles. Don't assume there's a right way.
# [07:23] <dael> dauwhe: We devote our lives to carefully justifying text. But we do a lot of hand tweeking for results and it's so immensely complicated and we're frustrated we have so little control over it.
# [07:23] <dael> dbaron: I think broswers have different introp than formatters. We can more about interop
# [07:24] <dael> dbaron: I don't consider it worth investing in something like this if it's complicated and won't lead to browser interop. I'm curious what others think
# [07:24] <dael> Rossen__: I think your last sentence summerizes well We won't put in much without an interop result
# [07:24] <dael> hober: If we spec something that's simplier to being worse in common cases, sure we could converge, but we don't want to if it's worse.
# [07:24] <dael> fantasai: I don't htink we're prop you do worse. We're prop we do better in non-English
# [07:25] <dael> fantasai: I don't htink introp of languages isn't the goal. We want the text to jsutify and look good, but exactly what it looks like we shouldn't obsess over. That'll vary and that's okay.
# [07:25] <dael> dauwhe: I have no expections that every word will maintain across browsers
# [07:25] <dael> fantasai: That's true jsut from different font librabries
# [07:26] <dael> dauwhe: If font version changes it breaks justification. The smallest length can make large changes.
# [07:26] <dael> plinss: There is an expectation that if I only change the browser, I should get the same thing
# [07:26] <dael> dauwhe: That doens't happen today
# [07:26] <dael> plinss: People want that.
# [07:26] <dael> dauwhe: And this isn't text-align: justify, but othervalues of text-align
# [07:27] <dael> dbaron: If we start doing something that we think is better, someone will think it's worse and be furious and it's easier to point to a spec with some research than to say we thought this was better because we talked to the guy over here.
# [07:27] * liam says, f they're angry they can come and join the WG and help us fix it
# [07:27] <dael> fantasai: We want interop on if a line of text has been jsutified or not. Where it happens is less important.
# [07:27] <dael> fantasai: Right now if you have CJK and you justify, it's not right.
# [07:27] <dael> fantasai: That's how deep the spec should get.
# [07:28] <dael> dbaron: Thent he spec should require that.
# [07:28] <dael> dbaron: If that's what you want to solve it should be must level
# [07:28] <dael> fantasai: As far as an alogirthm, I can do a non-normative appendix, but I don't want people that have a better idea or different performance be locked into a browser-required alogrithm.
# [07:28] <dael> dbaron: That's fair
# [07:28] <fantasai> s/not right/left-aligned/
# [07:29] <dael> dauwhe: Plus that might take a 5 years for the algorithm
# [07:29] <Rossen__> s/dbaron: That's fair/Rossen__: That's fair/
# [07:29] <dael> plinss: Thinking back to counter styles, you mentioned that justification style is a hosue style so maybe at some point we want to name the prop to control all the properites of just and do it as an @ rule so people who want to be really specific can.
# [07:29] <dael> plinss: We can have our list of default parameters for these languages that are good starting points
# [07:30] <dael> dauwhe: That might be a good way of describing it.
# [07:30] <dael> fantasai: So not going to happen in the next year.
# [07:30] <dael> plinss: I'm sayin somewhere downt he road
# [07:30] <dael> fantasai: The algorithm will have different kinds of outputs.
# [07:30] <fantasai> s/year/6 years/
# [07:30] <dael> koji: Are we resolving this as adding a non-normative appendix?
# [07:31] <dael> fantasai: We're saing require what should be justified
# [07:31] <dael> koji: So liek the minimum
# [07:31] <jdaggett> frankly, one *could* spec text-justify: auto in infinite detail but as fantasai says, this would take a *lot* of research and probably wouldn't be completely relevant in the end
# [07:31] <dael> fantasai: These are justification oppotunities and if they exist you must do them. Would that work for you?
# [07:31] <dael> dbaron: I guess so. There's a bunch of things you said about where you know how to prioritize that should be in the spec.
# [07:31] <jdaggett> "ideal" justification is not something easily defined, there's typically "better for this use"
# [07:32] <dael> dauwhe: And hopefully the simple statements can be tested.
# [07:32] * glazou wants |text-transform: suffixize| for CSS WG dogfood
# [07:32] <jdaggett> to say that "this has already been done for print" is nonsense, a lot of print typography is manual tweeking up the wazoo
# [07:33] * fantasai :)
# [07:33] <dael> RESOLVED: Require which lines are justified even if justification method is not defined
# [07:33] <dael> plinss: next is arabic letters connecting between elements
# [07:33] <dbaron> jdaggett, but if fantasai is saying that the point of the text in the spec is to ensure that CJK text should be justified inter-ideograph when justify is specified, then the spec should at least require that
# [07:33] <dael> fantasai: So this was people taking a UL and formatting as inline elements and because there wasn't space all the arabic words jammed together.
# [07:33] * dauwhe jdaggett: most of the time spent in producing a book is manual adjustment of word, line, and page breaks.
# [07:34] <dael> fantasai: So if you format with no spaces the arabic elements run up together. We were discussing how to create boundries at the element boundry
# [07:34] <dael> fantasai: We could create a prop devoted to it, we could piggyback off of bidi isolation
# [07:34] <jdaggett> dbaron: sure, if specific requirements are being stated those should be detailed, agreed
# [07:34] <dael> fantasai: Or if you have non-0 padding or margin, you consider that shaping isolated
# [07:35] <dael> fantasai: This is about shaping behviour for scripts like arabic?
# [07:35] * plh sounds like we need justify: manual
# [07:35] <dael> glenn: What about arabic cuase the spaces to collapse
# [07:35] <dael> TabAtkins: It's not. Its the lack of space causes it to have text on text.
# [07:35] <dael> TabAtkins: Can you do a zero-width non-joiner? Is that sufficent?
# [07:36] <dael> fantasai: Yep. I think we can do that.
# [07:36] <jdaggett> plus any print justification algorithm is inherently offline and can do infinite automatic adjustments without worrying too much about rendering speed. this isn't true for browsers
# [07:36] <dael> fantasai: Let me pull up the thread.
# [07:36] <liam> [people do worry about formatting speed. Luckily there are very good very fast algorithms, but there are NP-complete corner cases for all of them]
# [07:37] <dael> fantasai: I thinkt hat would work if author is aware. If we want this in UA stylesheet or take affect automatically it wouldn't work, but I'm not sure we need that
# [07:37] <dael> fantasai: I can reply to the thread and ask if that's felt to be suffiecent.
# [07:37] <jdaggett> liam: but with browsers those algorithms need to execute in real-time on $25 devices
# [07:37] <plh> http://lists.w3.org/Archives/Public/www-style/2014Feb/0302
# [07:37] <jdaggett> it ain't the same!
# [07:37] <liam> jdaggett, yes, understood.
# [07:37] <dael> fantasai: Okay. Next?
# [07:37] <dael> koji: Control characters
# [07:37] <koji> http://dev.w3.org/csswg/css-text-3/issues-lc-2013#issue-72
# [07:38] <dael> fantasai: We got a question from James Clark about why are we ignoring form feed, verical tab, and new-line characters?
# [07:38] <dael> TabAtkins: They're normalize out.
# [07:38] <dael> fantasai: You can stick them in the DOM
# [07:39] <dael> TabAtkins: Oh...neermind.
# [07:39] <dael> fantasai: Then ROc said mozilla has control character visiability prop, do we want that?
# [07:39] <dael> plinss: Some word processers let yo make spaces visible
# [07:40] <dael> fantasai: Then there was a reply saying that there was a section...[missed]
# [07:40] <dael> zcorpan_: But you can put it into the script afterwards
# [07:40] <dael> fantasai: But then it will work out in legacy
# [07:40] <dael> fantasai: So there's a legacy problem with pages that use control characters.
# [07:40] <dael> dbaron: But pages that are in UTF-8 can spec these control points
# [07:40] <dael> fantasai: Do we need to care in CSS?
# [07:40] <dael> clilley: no.
# [07:41] <dael> fantasai: So we say Zach Winburg's comment is our of spec.
# [07:41] <dael> fantasai: For the original comments, just say there's no reason too. They're formmating
# [07:41] <astearns> s/our of spec/out of scope/
# [07:41] <dael> glenn: Sometimes you want to see control codes. If you're doing arabic you want to see left or right marks and joiners, but not in the default
# [07:42] <dael> TabAtkins: mozilla has a display for invisble characters
# [07:42] <dael> zcorpan_: That was to catch errors
# [07:42] <dael> TabAtkins: Some times you want to display on purpose
# [07:42] <dael> glenn: Unicode has a block that has visual depiction symbols and some fonts support those for control groups
# [07:42] <dael> fantasai: Wasn't there a prop in GCPM?
# [07:42] <dael> glenn: You don't wnat to change the character content
# [07:43] <dael> clilley: Text transform doesn't
# [07:43] <dael> TabAtkins: That's a decent idea
# [07:43] <clilley> text-transform: control-visible
# [07:43] <dael> fantasai: And you can pick waht you want.
# [07:43] <dael> TabAtkins: We can add a keyword to replace Mozilla's propritary
# [07:43] <dael> zcorpan_: And would that be compat with showing spaces or tabs?
# [07:43] <dael> TabAtkins: This is what it would do.
# [07:43] <dael> zcorpan_: I thought it was just control, not spaces.
# [07:44] <dael> fantasai: So any suggestions on responding to this comment other than no change?
# [07:44] <dael> fantasai: Apperently we conflict with unicode, but I don't think we care.
# [07:44] <clilley> s/care/are
# [07:44] <dael> koji: I think the proposal also wants to treat things with whitespace. Is that reasonable to add?
# [07:45] <dael> koji: He's saying because HTML and Unicode do it's own thing we should.
# [07:45] <dael> koji: Form-feed character
# [07:45] <dael> fantasai: I don't have an opinion. We should do what browsers do which I'm guessing is not to display
# [07:45] <dael> koji: impl?
# [07:45] <dael> dbaron: I'm not sure.
# [07:45] <dbaron> s/dbaron/?/
# [07:45] <dael> fantasai: We can write a test
# [07:46] <dael> fantasai: it's invisible
# [07:46] <dael> fantasai: So I think that's what we're doing. And the sepc says don't render
# [07:46] <plinss> s/?/Rossen__/
# [07:46] <dael> koji: We don't have formfeed as whitespace
# [07:46] <dael> fantasai: no, it's a control character.
# [07:46] <dael> fantasai: Any other comments?
# [07:46] <dael> fantasai: I think that's all the text stuff
# [07:47] <dael> [break = 15 min]
# [07:49] * Quits: lmclister (~lmclister@public.cloak) ("")
# [07:56] * Quits: shans_ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [07:58] * Joins: shans_ (~shans@public.cloak)
# [08:06] * Quits: zcorpan_ (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [08:08] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:10] <dael> Topic: split CSS3 Text
# [08:10] * dauwhe so...
# [08:11] <dael> koji: The basic issue is some properties are ready but some properties need more work
# [08:11] * clilley modules will be split, until morale improves
# [08:12] <dael> koji: I'm proposing the split the fast moving ones so they can go to CR while the other ones can stay in a different spec.
# [08:12] <dael> astearns: I'm all for splitting to different levels. You had prop at some point different modules
# [08:13] <dael> fantasai: My concern is the things we're chunning on are the things that are the highest priority, where as the things that are stable the 2.1 stuff is fine. So text-justify, line-break and word-break are the thigns the i18n care aboutt he most and the split would make them go slower.
# [08:13] <dael> fantasai: I think in this case I'd be against pushing that stuff to the next level
# [08:13] * glazou "Box model / Render tree ? No. sudo Box model / Render tree ? Ok." :-)
# [08:13] <dael> fantasai: That might mean it'll be another 3 to 6 months to CR, but I don't think it'll be more than that
# [08:14] <dael> fantasai: We need to do the eidts we discussed today, do a ne WD and do a few cycles of LC to get comments.
# [08:14] <dael> fantasai: And that's kinda what we're stuck on right now
# [08:14] <clilley> rrsagent, here
# [08:14] <RRSAgent> See http://www.w3.org/2014/05/21-css-irc#T06-14-32
# [08:14] <dael> koji: The size is quite large so half the properties we get almost 0 feedback so asking review of all the features every time doens't makes sense
# [08:15] <dael> fantasai: We can say what has changed since last LC and please focus on those things. i think if we split we'll have to do LC/CR for one and FPWD from the other and that takes longer.
# [08:15] <dael> plh: What about at risk?
# [08:15] <dael> fantasai: The thigns that are holding back we don't want to drop
# [08:15] <dael> glaz: You said FPWD was hard?
# [08:16] <dael> fantasai: It would take the focus away from the things that need work to the things that are stable and giong well. There's also a certain amount of editorial work and to keep the two drafts in sync.
# [08:16] <dael> fantasai: That won't make things go fasted except what's high priority
# [08:16] <dael> glaz: This is a level. We don't need everything in the other level. It's not versions.
# [08:17] <dael> glaz: You don't need to copy 3 into 4. 4 is an extension
# [08:17] <SteveZ> The AB (some time ago) advised that we do not produce delta specs
# [08:17] <dael> TabAtkins: You really do. You don't want delta specs.
# [08:17] <dael> fantasai: There's individuals that interact
# [08:17] <dael> glaz: That's the purpose of levels!
# [08:17] <dael> dauwhe: Is there a natural split? I want one-stop-shopping for text.
# [08:17] <SteveZ> Delta specs are not reader friendly
# [08:18] <dael> fantasai: I think this will jsut get text-indent and a few others to CR faster
# [08:18] <dael> koji: What happened to text-decoration is that the spec went to CR and impl starts. This will help us focus on the things left in the spec. I can see a lot of benefits
# [08:18] <dael> fantasai: If the high priority thigns were in the stable state I'd agree.
# [08:18] <dael> koji: But that helps me to move low priority to other specs.
# [08:19] <dael> hober: So you're saying that you should move the higher readiness to CR?
# [08:19] <dael> glaz: A few years ago we said if there are things that are slow and blocking we should remove them to antoher level
# [08:19] <dael> dbaron: But the ideal is we do that for things that are high priority.
# [08:20] <dael> fantasai: When we split text-decoration it's because it was long and there was a logical break. It turned out one part was faster, but I was expecting the same.
# [08:20] <dael> fantasai: There is a clear priority here. I want to concentrate on the high priority things.
# [08:20] <dael> koji: If half the CSS items are thigns we don't want, why keep them?
# [08:21] <dael> fantasai: It was in 2.1 plus a few minor extensions, plus hanging punctuation and I don't think hanging puctuation is worth it.
# [08:21] <dael> koji: There are 7 properties
# [08:21] <dael> glaz: Beurocratic isn't bad, it's editorial
# [08:21] <dael> fantasai: What are the 7 prop?
# [08:21] <dael> koji: [in irc]
# [08:21] <koji> https://lists.w3.org/Archives/Member/w3c-css-wg/2014AprJun/0121.html
# [08:22] <koji> Higher (zero-to-few feedback to the last LC): text-transform white-space tab-size hyphens overflow-wrap/word-wrap text-indent hanging-punctuation Lower: word-break line-break text-align text-align-last text-justify word-spacing letter-spacing
# [08:22] <koji> Higher (zero-to-few feedback to the last LC): text-transform white-space tab-size hyphens overflow-wrap/word-wrap text-indent hanging-punctuation
# [08:22] <dael> plh: Are the impl of those sever prop?
# [08:22] <dael> fantasai: Yes. Of all. The first 2 are in CSS 2.1, the next 2 have impl, hanging-puntuation is AH and text-indent is in CSS 2.1
# [08:23] <dael> fantasai: The lower 4 are high for i18n and ebook communities. If it'll take us 6 months or less it'll cause more confusion instead of benefit. We won't know why we pub two levels in 6 months.
# [08:23] <dael> glaz: We did that for selectors
# [08:23] <dael> fantasai: No, they were many years apart
# [08:24] <dael> glaz: We split levels 3 and 4 and we released CR when we did 4.
# [08:24] <dael> fantasai: But 4 isn't going to CR in multiple years.
# [08:24] <dael> fantasai: These properties should go in 6 months. I think it should be 6 months.
# [08:25] <dael> fantasai: Selectors 3 went to PR. Here we have a WD that we're taking to CR and creating a new one to also take to CR.
# [08:25] <dael> fantasai: We also have impl of everything that we're planning to defer.
# [08:25] <dael> fantasai: They all have impl.
# [08:25] <dael> Rossen__: So how confident are you in the 6 months?
# [08:26] <dael> fantasai: It depends on how much time I put in, but koji is also available so as long as we're actively responding, we should be able to
# [08:26] <dael> fantasai: We're not getting "redign this" feedback
# [08:26] * Joins: jcraig (~jcraig@public.cloak)
# [08:26] <dael> koji: I think that's optimistic. Last time i18n asked for a 3 month extension to LC. To make CR in 6 months we have to do the WD in one or two months. That's tough.
# [08:26] <dael> Rossen__: So we're talking about longer.
# [08:27] <dael> koji: That's why i want to reduce the focus
# [08:27] <dael> fantasai: I wasn't really working on this for the last 6 months, koji was the only one working.
# [08:27] <dael> koji: I expect a lot of work.
# [08:27] <dael> dauwhe: Can w3c help focus i18n on this?
# [08:27] <dael> fantasai: I think that LC was during the holidays.
# [08:28] <dael> glaz: That's not a valid excuse. There's always holidays. We've even discussed this during a F2F.
# [08:28] <dael> fantasai: They're overloaded I think.
# [08:28] <dael> s/there's always holidays/they're always later
# [08:29] <dael> clilley: Part of their job is to check every spec everyone produces
# [08:29] <dael> koji: I can't imagine how one person could make all the test cases for this spec.
# [08:29] <dael> koji: I don't have an impl team.
# [08:29] <dael> plh: If we don't know we can get to rec in 6 months, why aren't we splitting?
# [08:29] * Joins: lmclister (~lmclister@public.cloak)
# [08:30] <dael> koji: We said CR. To PR I need help from impl.
# [08:30] <dael> hober: CR is an offical call for impl. What's stopping us from unofficially asking we'd like people to impl
# [08:30] <dael> fantasai: They're impl already.
# [08:30] <dael> hober: So then why haven't I heard of a call for impl?
# [08:30] <dael> dbaron: And if there was a CR we'd feel more confident.
# [08:31] <dael> clilley: CR gives a message of stability. There's no patitent difference. You can CR in 0 time. If you have full pass test suite you don't have to go to CR if you've met the exit criteria
# [08:31] <dael> clilley: You just need a test suite that passes
# [08:31] <dael> koji: What happened to text decoration is that once it got to CR it was picked up. I think CR gives a good message
# [08:32] <dael> fantasai: What on this list would you pick out?
# [08:32] <dael> dbaron: I think we would impl the stuff in the lower list.
# [08:32] <dael> fantasai: I don't see a benefit of taking the higher level stuff to CR.
# [08:32] <dael> fantasai: text-indent maybe, but no one is super excited. Maybe hinging punctuation for CJK, but that's one property.
# [08:33] <dauwhe> s/hinging/hanging/
# [08:33] <dael> fantasai: The things people are really waiting on are the thigns in the lower list. Those are the ones that a transition to CR would make a difference and the split will slow them getting to CR at least somewhat. It will add time.
# [08:34] <dael> fantasai: Making sure it's all coherent and ther's intro text. It's easy to cut things out, it's hard to pull things out and make it fit together. That takes time and it's not worth spending without a beneit and I don't think we would get a benefit.
# [08:34] <dael> clilley: Splitting won't help in any way. I think fantasai gave a good demistration of that.
# [08:34] <dael> glaz: Is there concensios.
# [08:34] <dael> RESOLVED: No change
# [08:34] <Rossen__> s/demistration/demonstration/
# [08:34] <dael> Topic: web-platform-tests and csswg-test github
# [08:35] <dael> plh: I don't know how familair people are with testing we have and the differences between the two
# [08:35] <dael> plh: How much detail should I go into?
# [08:35] * fantasai note to Dael, in the previous conversation, might be useful to cut/paste the lists from Koji's email into the minutes
# [08:36] <dael> plh: With webplatform tests contains test suits for abourd 60 spec from 6 WG. THe goal is actually to make the web work. It might sound crazy, but that's the goal and there's imput to make that work
# [08:36] <dael> plh: There's high activity on that at the moment. At the moment ?? from Mozilla is doing fantastic work to get it to work on Firefox. My hope is by end of year we'd get results from browsers
# [08:36] <zcorpan> s/??/James Graham/
# [08:36] <astearns> s/??/jgraham/
# [08:36] * glazou fantasai koji pasted the two lists into IRC
# [08:37] <dael> plh: So you put a test into the suite and overnight you get results.
# [08:37] <dael> plh: That would be very useful for WG to get the raw test results. That's the goal. The problem is it wan'ts to cover CSS as well
# [08:37] <dael> plh: By running the tests it's also web tests. and there's ongoing work to be able to write a webdriver test as well
# [08:38] <dael> plh: So theres' a huge advantage to haveing CSS. The CSS test repo is a mirror of mecurial. I'd assume this group is more familair than me.
# [08:38] <dael> plh: So there's discussion about how to get them to interact. There's 3 proposals.
# [08:38] <dael> plh: 1 is to make a simple solution. Make the CSS repo a sub of webplatformtest
# [08:38] <dbaron> s/sub/submodule/
# [08:39] <dael> plh: So if you want to maek a publich test you make it on the CSS repo. On the pro it's easy, on the con it's confusing because people can't pull requests from the same place. Right now webplatform is using a review different system than CSS
# [08:39] <astearns> s/publich test/pull request/
# [08:39] <zcorpan> s/review different system/different review system/
# [08:40] * hober does anyone who didn't formerly work at opera actually like critic?
# [08:40] <dael> plh: The third that can be argued the most is we have different requirements. webrepo placed the bar low to favor test submission.
# [08:40] <dael> plh: The seoncd solution is to have the repo as a subtree. The problem is you would have two systems and you could send pull requests to both.
# [08:40] <dael> plh: We're used to dealing with one place and we'd have to look at two with different test requirements
# [08:41] * zcorpan hober i think darobin said he started to like it but maybe i wasn't allowed to cite him on that. i might misremember him for someone else also, but still
# [08:41] <dael> plh: Third solution is to say we're not going to try and integrate.
# [08:41] * hober zcorpan: :)
# [08:41] <dael> plh: People will send submitters to webplatform test and in order to satisfy the requirements it'll have to move to the reposity by the same or a different person
# [08:41] <dael> plh: So it would be submit your test to the webplatform and than the CSS will reask
# [08:42] <dael> plh: CSS platofrm does have tools that the webplatofrm doesn't have. The whole system we have on ED is all on the CSS test repo and you wouldn't get that on webplatform until written.
# [08:42] <dael> clilley: That was discussed this morning.
# [08:42] <dael> plh: I'm talking about a bigger rewrite
# [08:42] <dael> plinss: I was giong to clean up, but not fundimentally re-write
# [08:42] <dael> clilley: I misunderstood
# [08:43] <dael> plh: To finish, we don't have everyone in the room, but we can start by saying are the opinions, what to test contributors want to see?
# [08:43] <dael> plh: At the end of the day with webplatform test we can let people submit test and merge into CSS test repo that's fine.
# [08:44] <dael> plh: Do people have opinions, do they care at the moment?
# [08:44] <dael> zcorpan: My opinion is that people should be able to make a pull request to webplatform tests for when they want to add CSS tests and not have to put in the meta data that the CSS WG req for their tests
# [08:44] <dael> zcorpan: How the syncing works I have less opinons
# [08:44] <dael> plinss: Without some fundimental metadata we won't get use from the test.
# [08:45] <dael> plinss: The fundimental dicodomy is that the stated goal of the webplatform is to get better tests, but they don't care about getting specs to REC and we do
# [08:45] <dael> zcorpan: There is some meta data to annotate which tests to which section. You put it in a directory and it annotates it for a particular section.
# [08:46] <dael> plinss: I don't care about what form the meta data is in, but I'm saying we need to to exist. And if you're promising our minimum of meta data we can work witht hat
# [08:46] <dael> zcorpan: Right
# [08:46] <dael> plinss: Biggest problem is tracking issues. Where are the bugs going to be filed and where tracked and if we're copying back how will people know where to look
# [08:46] <dael> hober: We already have that problem.
# [08:47] <dael> plinss: But at least we haev a system. There's even less information about where we'll track information for the tests.
# [08:47] <dael> plh: We have a tracking per WG and er system that's automatically
# [08:47] <dael> plh: I can tell you the number of tests and pull requests we have to each spec. You mentioned that it didn't care about getting to REC and you're right.
# [08:48] * Quits: jcraig (~jcraig@public.cloak) (Ping timeout: 180 seconds)
# [08:48] <dael> plh: But WG can use it to get to rec and that's good enough. If we can get test results from three or four browsers that great.
# [08:48] <dael> astearns: I think the most important thing is one place to submit for any webplatform tests. So any one place that takes difference and reviews differences is a big thing
# [08:49] * Joins: jcraig (~jcraig@public.cloak)
# [08:49] <dael> plh: If we do that there's a lot of work to be done. most of the CSS tests re manual so they'll have to be run manually which takes time.
# [08:50] <dael> plh: It may will be that we have an appraoch like with the presto where they have thier of github and we're trying to over time move thier tests to webplatform and than remove them from the original repository. We'll be sucessful when that's 0, but it'll take us a while.
# [08:51] <dael> astearns: So. I'm much more concerned with getting test solutions than having a single place to track issues and reviews. I jsut want the tests.
# [08:51] <dael> astearns: I'll accept multiple processes and the headaches to get bigger test suites.
# [08:51] <dael> astearns: I thought we decided as long as a review happened, it didn't matter where. It jsut mattered that it was tracked.
# [08:52] <dael> astearns: There could be a review in many places and we can deal with having the headache of having these mulitple ways as long as we get more tests in the test suite.
# [08:52] <dael> zcorpan: Multiple reviews thing is already an issue in webplatform without CSS
# [08:52] <dael> astearns: And it's an issue in CSS
# [08:52] <dael> plinss: I have a plan to sync our systems
# [08:52] <dael> astearns: And if you get to it great. If not that's fine.
# [08:53] <dael> plinss: I don't know how to sync those three and another repo. It sounds like a nightmare, but maybe it's possible.
# [08:53] <dael> plinss: fundimentally from one aspect I don't care and don't want to worry about this stuff. If we had an all in one we can use I'd be happy, but we don't. The other systems out there don't meet our needs. they don't help use get the specs to REC.
# [08:54] <dael> plinss: And they'ren ot offering to help us with the needs beyond what they're acknoledged.
# [08:54] <dael> astearns: But getting to REC means sufficent tests and I don't have any evendence that any tools help us get to rec
# [08:55] <dael> plinss: But what we have is multi test suites so we can run against things becides browers. We accpet from other sources and fold them into an area to generate the data to get us to REC. That's not from sheppard.
# [08:55] <astearns> s/any tools/critic *or* shepherd/
# [08:55] <fantasai> s/multi/multi-format/
# [08:55] <dael> plinss: I'm all for trying to blend, but I don't want the throw out the baby with the bathwater and make it harder to get specs done. If we can bring thigns together and get them in one place, but still keep going, that's great.
# [08:55] * Quits: lmclister (~lmclister@public.cloak) ("")
# [08:56] <dael> plinss: I don't know what the right step is. If it's sub trees and pulling from different places or if it's submodules
# [08:56] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [08:56] <dael> astearns: If all tests were in same repsoitory and we have our system or our tess and the tess in W3C and their tests do what they want, maybe the competition will move fast
# [08:57] <dael> plh: And we tried to be highly modular and they're likely to try and impose every bit of the system
# [08:57] * Ms2ger "tess"?
# [08:57] <dael> plinss: The other problem is there's a lot of histroical review data we would lose or have the track seperatly
# [08:57] <dael> s/tess/test
# [08:58] <plh> s/likely/not likely/
# [08:58] <dael> plinss: I don't want to lose that information. Tests have to be good tests of they make our jobs harder. If the webplatform can live with use in a subdirectory we can do that and maintina our own repo for as long as we need to. But I don't know if that will fly
# [08:58] * dbaron wouldn't mind spending 15 minutes on a position:sticky interop issue (which I realize might be good to do while we have a whiteboard)
# [08:58] <Ms2ger> I don't think that improves the situation.
# [08:59] <dael> plh: I think we've done as much as we can on this topic
# [08:59] <dael> plinss: There are questions about if putting all CSS in a subdirectory is good enough
# [08:59] <dael> plh: I don't have an answer. I think there are some people who don't like this approach
# [08:59] <Ms2ger> My personal answer to that is "no"
# [08:59] * Ms2ger plh ^
# [08:59] * fantasai answer to which question?
# [09:00] <dael> Topic: annotate url() with "crossorigin" "integrty" etc.
# [09:00] * fantasai nm
# [09:00] * SteveZ It is midnight here. My coach has turned into a pumpkin and me with it. Good night!
# [09:00] <dael> zcorpan: So yesterday ?? talked about an ability to to give attr to a url in CSS
# [09:00] * krit SteveZ night!
# [09:00] * liam night SteveZ
# [09:00] <dael> zcorpan: It doesn't have to be url. I mean the functionality
# [09:01] <TabAtkins> s/??/Anne van Kesteren/
# [09:01] * fantasai 'night Steve! Thanks for staying up with us
# [09:01] * dauwhe waves goodbye
# [09:01] * krit is someone talking?
# [09:01] <fantasai> s/be url/be url() function/
# [09:01] <SteveZ> bye
# [09:01] * krit can't here anything
# [09:01] <dael> zcorpan: In HTML you can do <link rel=stylesheet href=http:// a/b crossorigin=anonymous>
# [09:01] * TabAtkins zcorpan was drawing on the board
# [09:01] * krit ah now
# [09:01] * liam - there was a gap
# [09:01] * Quits: SteveZ (~SteveZ@public.cloak) ("Page closed")
# [09:02] <dael> zcorpan: In this case you can read the stylesheet data in CSSOM but without crossorigin you can't read it.
# [09:02] <dael> zcorpan: So today with @import you cannot annotate the url with the crossorigin. You can have a media here, but the media piece is missing.
# [09:02] <krit> zcorpan: Is that just about Stylesheets or other resources like images as well?
# [09:02] <dael> zcorpan: So import stylesheets can't be read in CSSOM
# [09:03] <dael> zcorpan: What it's asking for is some way to spec a crossorigin.
# [09:03] <dael> zcorpan: There's also a spec called sub resource integrity which takes and integrity attr
# [09:03] <astearns> http://w3c.github.io/webappsec/specs/subresourceintegrity/
# [09:03] <dael> zcorpan: And the user can compare the downloaded hash with the spec hash and they prob. want to use this is CSS as well.
# [09:03] <dael> zcorpan: So how?
# [09:04] <dael> zcorpan: You can't put anything ins url() but we can come up with some other fucntion like newurl("...", crossorigin...);
# [09:04] * Joins: jh (~jh@public.cloak)
# [09:04] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
# [09:04] <dael> zcorpan: I don't have a concrete prop for how to do this, but I wanted to see what people thing.
# [09:05] <dael> glaz: To be sure I understand, current behaviour of linking, we can link to any stylesheet from anywhere. If this is going to be changed without crossorgin, you won't be able to reach across, right?
# [09:05] <dael> dbaron: No the issue you can't acces without crossorigin.
# [09:05] <dael> zcorpan: You should be able to opt-in to loading and accessing
# [09:05] <dael> glaz: This is a change
# [09:05] <dael> zcorpan: It's a new feature.
# [09:05] <dael> plinss: I haven't read up on crossorigin, but I'm assuming it's more than having the attr that makes it accessible
# [09:06] <dael> zcorpan: Yeag
# [09:06] <dael> TabAtkins: Relatively easy. There's already been a lot of work done.
# [09:06] <dael> plinss: It'll depend on the responce of the server.
# [09:06] <dael> zcorpan: Yeah. If you try and link and spec and if the server doesn't support...
# [09:06] <hober> something like link(<url> <plist>?) (where <plist> is [<ident> <string>]+) e.g. link(http://a/b crossorigin "anonymous" integrity "6d8f296997bfd407d3c82bd950585200")
# [09:06] <dael> plinss: So you're requiresting that the browser does thing
# [09:06] <dael> zcorpan: If the server doesn't support cores you'll get an error
# [09:07] <glazou> s/reach across/reeach the OM
# [09:07] <dael> plinss: You don't get the style sheet? Not just you don't get access?
# [09:07] <dbaron> s/cores/CORS/
# [09:07] <dael> zcorpan: Yes. If you opt into I want cores and it doesn't support you get a network error
# [09:07] * Joins: adenilson (~anonymous@public.cloak)
# [09:07] <dael> plh: One question if when you function you'll need to have some questions about lazyload.
# [09:07] * Quits: jh_hong (~jh_hong@public.cloak) (Ping timeout: 180 seconds)
# [09:07] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [09:07] <dael> hober: If you look at my IRC syntax and you accept aribrary.
# [09:08] <dael> plh: That would work.
# [09:08] <glazou> s/cores/CORS
# [09:08] <dael> zcorpan: I think your prop needs quotes for parsing, but is fine
# [09:08] <dbaron> s/your/your (hober's)/
# [09:08] <hober> so link(<url> <plist>?) (where <plist> is [<ident> <string>]+) e.g. link("http://a/b" crossorigin "anonymous" integrity "6d8f296997bfd407d3c82bd950585200")
# [09:08] <dael> dbaron: I think this is fine if we come up with a good name for it.
# [09:09] <dael> zcorpan: So we have link. Any other ideas?
# [09:09] <dael> dbaron: Or href.
# [09:09] <dael> fantasai: Are we using this for anything but @import?
# [09:09] <dbaron> ... because there's precedent, not because it's any good
# [09:09] <dael> zcorpan: Yeah.
# [09:09] <dael> fantasai: For images we can put in the image function.
# [09:09] <dael> hober: The generic case is just slightly worst than current syntax
# [09:10] <dael> TabAtkins: One poss is we play with parsing for " URLs can take arguements after.
# [09:10] <dael> hober: So no new function
# [09:10] <dael> TabAtkins: You would have to fo " or you're get an error
# [09:10] <krit> what about a core() function?
# [09:10] <krit> cors(<url> | image, CORS arguments) ?
# [09:10] <dael> hober: I'm sympatetic to no new function, but I worry about I'm an author I hear of this awesome thing, but I don't look at if I " the URL
# [09:11] <dael> TabAtkins: So same scenario if we add a new prop though.
# [09:11] <dael> plinss: And if you're really niave you don't check if the serve supports CORS
# [09:11] <dael> dbaron: If you find a way to do TabAtkins prop you make URLs with quotes return as tokins
# [09:11] <krit> people love url()!!!
# [09:11] <krit> you can not get rid of it
# [09:11] <dael> TabAtkins: I think I can do this.
# [09:11] <dael> TabAtkins: It'll consume space until it find the quote
# [09:12] <dael> dbaron: It's the URL without " tokin that's crazy so this will work.
# [09:12] <fantasai> s/tokin/token
# [09:12] <dbaron> s/tokin/token/
# [09:12] <dael> TabAtkins: Yeah. I want to get into the code to make sure but at this point I'm certain I can do this quick.
# [09:12] <dael> zcorpan: I like the URL with quotes idea.
# [09:12] <dael> fantasai: But you don't need multiple
# [09:12] <dael> TabAtkins: Everywhere a function can take a URL it can take a cross.
# [09:13] <dael> fantasai: I don't know about that. In SVG it uses a hyphin
# [09:13] <TabAtkins> s/cross/quoted string/
# [09:13] * dauwhe not nearly enough em-dashes in CSS syntax
# [09:13] <dael> hober: I love this idea of inhancing URL
# [09:13] * fantasai we resolved not to use beyond ASCII
# [09:14] <krit> what about image() ???
# [09:14] <dael> action TabAtkins figure out if inhancing URL works
# [09:14] * trackbot is creating a new ACTION.
# [09:14] <trackbot> Created ACTION-632 - Figure out if inhancing url works [on Tab Atkins Jr. - due 2014-05-28].
# [09:14] <liam> s/inhancing/enhancing/
# [09:14] * glazou so in fact the topic was "crossoriginize this"
# [09:14] * fantasai and em-dash is not ASCII
# [09:14] * krit glazou could you unmute me?
# [09:14] * astearns I loved "On Beyond ASCII" as a kid
# [09:14] <dael> TabAtkins: We'd build the resource integrty stuff alongside.
# [09:14] <dael> zcorpan: I don't expect the entegrity right now.
# [09:14] <glazou> done
# [09:14] <dael> krit: You're just talking about URL what about image.
# [09:14] <dael> hober: Image takes URL arguement so it's same thing
# [09:15] <dael> TabAtkins: Alternatly we could also allow these in image fucntion grammar.
# [09:15] <dael> fantasai: How often would we use this for images?
# [09:15] <dael> plinss: I think integrety would become popular for things like online banking
# [09:15] <dael> fantasai: I image it would in the HTML, but the CSS?
# [09:15] <dael> TabAtkins: We can always let you do it as URL and flatten it later if necessary
# [09:16] <dael> fantasai: Yes. I think it won't be used often for images.
# [09:16] * liam doesn't see why not
# [09:16] <dael> fantasai: Also it's more closely tied tot he network request rather thant the image proessing.
# [09:16] <fantasai> so fits better in url() than flattened into image()
# [09:16] <dael> plinss: So TabAtkins you'll come back to us
# [09:17] <dael> hober: If it doesn't work we can add the function
# [09:17] <dael> Topic: grid/subgrid
# [09:17] <dael> Rossen__: Quick review
# [09:17] <dael> Rossen__: Grid is awesome.
# [09:17] <astearns> [whiteboard drawing]
# [09:18] <dael> Rossen__: The thing we can do with grid is you have a division of space and you have lines where you can size and have adaptive layout
# [09:18] <dael> Rossen__: The one thing it doesn't give you is grouping.
# [09:18] <dael> Rossen__: If you have items on the grid you want to group and attach behviour, you can't.
# [09:19] <fantasai> http://fantasai.inkedblade.net/style/discuss/subgrid-markup/
# [09:19] <dael> Rossen__: For ex a simple form with a button and an input field for text. If you want to treat it as a group where text spans two cells and the button is one, but I want hover where the whole group is hovered, in order to deal witht hat we into subgrid
# [09:19] <dael> Rossen__: It behavies liek a semi-transparent item in the level of grid and the purpose is grouping.
# [09:19] <fantasai> My position: If you can convince me that 80% of Web use cases for grid layout can be handled without compromising accessibility, I will retract my objection to removing subgrid. Otherwise not.
# [09:20] <dael> Rossen__: All the items in a subgrid are in the top-level grid, but have this invisible elemnt that let's us attach behaviour
# [09:20] <dael> Rossen__: For the past 1 or 2 years one exersize we went though was take the initial grid spec with is an app based grid with cells and try and merge that with typography based grid
# [09:20] <dael> Rossen__: We did that . Everyone in the grid taskforce contributed a lot
# [09:21] <dael> Rossen__: The spec is in fairly good shape to get to LC
# [09:21] <dael> fantasai: I think it needs another round or two for the algorithm
# [09:21] <dael> Rossen__: As concepts it's good
# [09:21] <fantasai> fantasai: but design-wise, it's good
# [09:21] <dael> Rossen__: The one wrinkle is that impl subgrid will be fairly complex.
# [09:21] * Quits: Rossen__ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [09:22] <dael> Rossen__: The reason why is (and subgrids nest) so the entire layout of subgrids boils down to the dependnency of subgrids which can bring any element anywhere in a subtree with a different amount of spanning on some leverl as well as overflow
# [09:22] <dael> rossen: the current sampling makes me thing blink and firefox are close to impl grid
# [09:22] <dael> fantasai: mozilla is nowhere near
# [09:23] <dael> jet: It's been going around for a bit
# [09:23] <dael> rossen: But we want to push grid out as soon as we can. We want to rev our unprefixed version of grid for everything except subgrid.
# [09:23] <TabAtkins> (jet indicated someone named "max" was put on it too)
# [09:24] <fantasai> I think you mean "mats"
# [09:24] <dael> rossen: I think subgrid as a functionality is needed. I prop we move subgirid to level 2, allow level 1 to ship so all impl that are close can roll out at the same time
# [09:24] <dael> rossen: And than work on subgrid as soon as we can
# [09:24] <dael> rossen: In the meantime if we find out impl of subgrid is quicker, we might pull into level 1 before rec, but my initial prototyping suggests it will have a sig impl delay
# [09:25] <dael> fantasai: My position is if we can cover 80% of common use cases with existing without subgrid or comp accessability, I'm okay, but I'm not convised. I think we can cover 30% There's common cases that wil be worse with grid.
# [09:25] * Ms2ger has a feeling this discussion has been had several times
# [09:25] <dael> fantasai: Those case for which grid is designed and I haven't heard markup for an example that uses grid and isn't bad markup
# [09:26] * astearns ms2ger would be correct. this is a sub-conversation nested fairly deeply
# [09:26] <dael> rossen: I can tell you almost, nearly all HTML based windows store apps use grid.
# [09:26] * TabAtkins this is us attempting to pop the stack of this convo completely
# [09:26] <dael> rossen: They're assiable and request subgrid as a future, but almost all that content that will be on the web will be fine without subgrid
# [09:26] * Ms2ger astearns, I propose to move this discussion to F2F v2
# [09:26] <zcorpan> s/assiable/accessible/
# [09:26] <dael> fantasai: App layouts seem to be simplier
# [09:26] <dael> rossen:I don't agree.
# [09:27] <dael> fantasai: I want a concrete example of something common with proper markup and I haven't seen that
# [09:27] <dael> dbaron: fantasai concern is about people having to remove thigns from markup
# [09:28] <dael> TabAtkins: So anythign doing a vaguely grid layout, accessibility wise it's fine, right now they're deeply nested, but for accessibility they're fine. There's a decent number of use cases for in page components that are better solved by subgrid, but I want to solve page layout right now.
# [09:28] <dael> fantasai: So write an ex an post to the ML
# [09:28] <dael> TabAtkins: Look at any website
# [09:28] * liam wants to see page layout solved too :-)
# [09:28] <dael> fantasai: I did and said you'd have to remove these things and add emply elements.
# [09:29] <dael> fantasai: I went to a grid layout system, I posted the link about. There's people that made frameworks for gridlink layouts.
# [09:29] <dbaron> s/things/things (section markup and ids)/
# [09:29] <dbaron> s/assiable/accessible/
# [09:29] <dael> fantasai: I took that, figured out how to mark with grid and subgrid and figured out it's very different.
# [09:29] <dael> TabAtkins: This first is fine if you don't remove sections.
# [09:30] <dael> fantasai: If you want the pictures to line up, you need to remove the markup that collects around "here" [pointing] unless you guarentee it lines up.
# [09:30] <dael> fantasai: So something where you have something that looks like a grid, but doesn't rely on things being the same size. If its' same size, why not use flex.
# [09:31] <dael> TabAtkins: You don't need subgrid until you're trying to style with padding and border. You're taking each top level piece and display box works.
# [09:31] <dael> fantasai: Than we can put display box in grid
# [09:31] <dael> TabAtkins: That's silly.
# [09:31] <dbaron> s/display box/display-box: contents/
# [09:31] <dbaron> s/in grid/in the grid spec/
# [09:31] <dael> fantasai: I agree. I don't want to give a feature that authors will be excited about but to use it they have to strip out content to use it, they're continue to do that after we ship subgrid
# [09:32] <dael> fantasai: Markup won't sure for 2 years, it'll suck for 10 because people will keep stripping it out.
# [09:32] <dael> TabAtkins: Given the pattern worst case you need a diva round the pattern so that you can say auto: flow
# [09:32] <dael> hober: I thinkt he point stands is you have to take out the layout for a complicated model.
# [09:32] <dael> fantasai: auto:flow only works in one direction.
# [09:33] <dael> fantasai: I'm not convinced this isn't harmful. I'm pretty sure it's harmful. Unless you have examples that show me I'm wrong, but you have not done that
# [09:33] * dauwhe see footer at http://alistapart.com
# [09:33] <dael> TabAtkins: Most sites have a simple grid that's hard to do now and can be addressed fine with grid
# [09:33] <dael> fantasai: And how many of the use cases is that?
# [09:33] <dael> TabAtkins: The plan is people will use grid forever
# [09:34] <dael> fantasai: I don't want them int he habit to do harmful thigns to use grid and keep using it
# [09:34] <dael> TabAtkins: This is a short period of time
# [09:34] <dael> fantasai: So we wait until subgrid is impl
# [09:34] * liam wonders if fantasai is trying to be a little paternalistic here?
# [09:34] <dael> fantasai: It's not tutorials, it's about habits. I fyou do it the old way it'll work in old version os IE.
# [09:35] <dael> hober: Prob shouldn't add verya ttractive desireable features to use practically in the real world but require reduced markup quality.
# [09:35] <dael> TabAtkins: I say not many or most case and the markup qualityt oday is so terrible we're improving anyway
# [09:35] <dael> TabAtkins: We'd rather a flatter structure.
# [09:35] <dael> plinss: Does display box conent solve most of the problems
# [09:35] <dael> TabAtkins: Some
# [09:36] <dael> plinss: Enough to aleviate your concerns?
# [09:36] <dael> fantasai: Yes, my concerns about active markup being bad
# [09:36] * hober %$&* it, let's change the default styling of div to be display-box: contents
# [09:36] <dael> plinss: So is display box being ready before subgrid a way to make this work
# [09:36] <dael> TabAtkins: So I can't promise, but it's likely ready before subgrid
# [09:36] <dael> TabAtkins: We have something else calling for this feature.
# [09:37] <dael> plinss: Does this handle your concerns?
# [09:37] <dael> TabAtkins: I'm otherwise going to object to obections here.
# [09:37] <dael> fantasai: If that's impl and shipped before or with grid and we update the spec to have a nice tutorial to use these together, htan I think that will be acceptable
# [09:38] <dael> plinss: Okay.
# [09:38] <dael> TabAtkins: Sounds fine to me
# [09:38] <dael> rossen: Jet, you're okay witht hat?
# [09:38] <dael> fantasai: I'm waiting for display content before I remove my objection
# [09:38] <dael> TabAtkins: The agreement was it shipping
# [09:38] <dael> fantasai: Until that's happening, I'm not removing my obj
# [09:39] <dael> dbaron: Would you be okay with something in the spec that says impl impling grid are also expected to impl display: box
# [09:39] <dael> hober: That's a message to say that things should be in the order. All the example should have to use it in order to have the affect you want.
# [09:39] <dael> TabAtkins: The examples today don't need it
# [09:39] * Joins: rossen___ (~uid21900@public.cloak)
# [09:39] <SimonSapin> s/display: box/display-box/
# [09:39] <dael> plinss: So phrase it in a way to say display: box content is an impl requirement of grid
# [09:40] <dael> dbaron: They're correct that the examples should have it as well
# [09:40] * Joins: Rossen_ (~Rossen@public.cloak)
# [09:40] <dael> clilley: rossen___ the app store has an accessibility review? Any problems?
# [09:40] * dbaron thought we had a compromise, and then Chris changed the topic
# [09:41] <dael> rossen___: Grid is a default that's used for authoring apps. In order to submit it has to meet assicibility. Im' not sure how it's essessed
# [09:41] <dael> rossen___: With the current grid which we have without subgrid, all these application exist just fine
# [09:41] <dael> clilley: Some data would be useful
# [09:41] <dael> rossen___: They're all new content. Nonea re using the same pattern as the website, though I wouldn't expect much different
# [09:41] <dael> fantasai: Put if you have labesla nd forms elements, it's a jumble
# [09:42] <Ms2ger> s/labesla nd/labels and/
# [09:42] <dael> dbaron: The other point is on the web we want the platform so people write accessibile as the default. If you have a revew state that means you havea different situation.
# [09:42] <dael> dbaron: I think we almost had a comprimise
# [09:42] * Parts: rossen___ (~uid21900@public.cloak)
# [09:43] <dael> plinss: Proposed res is to move subgrid to level two and add a requirement for display-box to be used with grid.
# [09:43] <dael> fantasai: I'd prefer a label for at risk
# [09:43] * Quits: Shinsuke (~Shinsuke@public.cloak) (Ping timeout: 180 seconds)
# [09:43] <dael> astearns: How far along is the display box impl?
# [09:43] <dael> plinss: Peple said it's easier
# [09:43] <dael> astearns: Is it impl yet?
# [09:43] <dael> plinss: So it's coming real soon.
# [09:43] <dael> fantasai: We should finish the draft.
# [09:44] <fantasai> jet^: Think it's almost landed
# [09:44] <dael> RESOLVED: move subgrid to at risk for level 1 and add a requirement for display-box to be used with grid and include examples
# [09:44] <dael> fantasai: I'll make the edits
# [09:44] <dael> Rossen_: I'll review them
# [09:44] <dael> TabAtkins: And I'll go over them.
# [09:45] <fantasai> Topic: sticky
# [09:45] <dael> Topic: position sticky
# [09:45] * fantasai do we even have an editor for positioning?
# [09:45] <dael> dbaron: It's a followup to an issue that hasn't been editing into spec. There was a thread started that it doesn't explain the two boxes you need to use sticky
# [09:45] <fantasai> fantasai: Can we turn the spec into a list of links into the www-style archives?
# [09:46] <dael> dbaron: My understanding of sticky is that you have soemthing like a hearder and you want to to scroll up witht he content and than stop for a period of time witht he content where it's the header and than sroll off when it's done being used
# [09:46] <dael> dbaron: So it's fundimentally like position: relative except the offset is changing dynamically.
# [09:46] <dael> dbaron: You can use any of top.right.bottom.left properties
# [09:47] <fantasai> . -> /
# [09:47] <dael> dbaron: You have the boxes you care about. the scrollable box, the element's containing block, and than you have the sticky element itself.
# [09:47] * liam wonders if this is e.g. for a table header that remains visible when you scroll a long table
# [09:47] <dael> dbaron: For the sticky element we only care about the margin box and for the scrollable area we care about the padding box.
# [09:47] * fantasai yes
# [09:47] <dael> dbaron: What happens if you set none of the offesets nothing interesting happens.
# [09:48] <dael> dbaron: If you set the offset to top: 20px, it's relative to the outside box so it means you care about the edge that's 20px from the top of the scrollable area. So you prevent this margin box from going above...
# [09:49] <dael> dbaron: So top 20px says the top px of the sticky box won't go above the container as long as the scrolling box doesn't go above
# [09:49] <dael> hober: So it implicitly controls two edges
# [09:49] <dael> dbaron: It's two constraints. And the 2nd overirdes the first.
# [09:49] <dael> dbaron: The point of the 2nd is to have it scroll off. Even though this isn't in the spec, we agree that this is how it works.
# [09:49] * astearns position:sticky-for-a-while
# [09:49] <dael> dbaron: Where impl don't agree is if the boxes are the same size
# [09:50] <dael> Rossen_: Or some of the internal boxes are bigger.
# [09:50] <dael> dbaron: I want to discuss what if they're the same. The issue is that the second constraint constrains relative to something that's scrolling withint the scrollable area
# [09:50] <dael> hober: If they're the same you never hit the bottom
# [09:51] <dael> dbaron: The problem is the scrollable box is sorta like two boxes. the actualy box and the scrollable area.
# [09:51] <dael> dbaron: There are three options for the second constrant where the sticky element's containing block is it's scrollable container
# [09:51] <dael> dbaron: I prefer 1) Throw out hte second constraint
# [09:51] <dael> dbaron: 2) make the scrollable constraint the area inside the scrollable conatiner
# [09:52] <dael> dbaron: and that means most of the time the 2nd constraint doesn't happen either unless you're in an overflow case
# [09:52] <dael> dbaron: Geicko does #1
# [09:52] <dael> dbaron: 3rd is webkit which is use the box that isn't being scrolled. You have to write weird test cases to trigger this
# [09:52] * Joins: yamamoto_ (~yamamoto@public.cloak)
# [09:53] <plinss> s/Geicko/Gecko/
# [09:53] <dael> dbaron: Webkit will force the sticky element intot he box, even if it's below it.
# [09:53] <dael> dbaron: If the sticky element is scrolled up above, it'll force it down into the box. Which seems crazy
# [09:53] * clilley Geckos have sticky elements on their toes
# [09:54] <dael> dbaron: I think in this case where the two boxes are the same, the purpose of the contianing block constrant has disappeared
# [09:54] <dael> [whiteboard]
# [09:54] <dael> dbaron: I've got a testcase link in which Gecko and Webkit disagree
# [09:54] <dbaron> https://bug915302.bugzilla.mozilla.org/attachment.cgi?id=8386943
# [09:55] * krit wondered about the relation between Gecko and Geicko before...
# [09:55] <TabAtkins> *Geiko
# [09:55] <dael> dbaron: So the case...
# [09:56] <dael> dbaron: In webkit, I was right the first time. If the box is way below, webkit will constrain it to the bottom and than will scroll it up to the 20px margins until, I'm not sure when
# [09:56] <dael> Rossen_: Can I add one more view?
# [09:56] <dael> Rossen_: This is what I was going to add intot he spec and it's almost ready.
# [09:56] <dael> Rossen_: Last I talked about this with Cory is the follwoing.
# [09:56] <dael> Rossen_: We have an element to which you'llb e using position: sticky.
# [09:57] <dael> Rossen_: You default to 0px, not matter what
# [09:57] <dael> dbaron: They default to auto, not 0
# [09:57] <dael> hober: For what it's worth, the webkit testcase is paying attention to how I thought.
# [09:57] <dael> dbaron: [corrects]
# [09:57] <dael> hober: Oh. That's evil.
# [09:58] <dael> dbaron: The other thing to notice is they have a bottom of 180px that pushes them outside the containing block.
# [09:59] <dael> Rossen_: So the termonology we used is the sticky position which is the position at which the box will get stuck. Also the release position which is the condition at which the box gets put away.
# [09:59] <dael> hober: That you're using enormous values is what makes it apperent.
# [09:59] <dael> Rossen_: So sticky position is byt he scroller, release pos is trigger by containing block and an open question is if cont. block is the same as the scroll in which case we need to define reasonable behaviour.
# [10:00] <dael> dbaron: I was suggesting if they're the ame you throw away release
# [10:00] <dael> Rossen_: So it's stuff forever. that could be reasonable. If you have a bunch of these they'd stick on eachother. It would be sucky if they're the same size, but a reasonable comprimise.
# [10:00] <dael> Rossen_: The other problem is when sticky is about the trigger so we have to either define so it's brought back or it doens't trigger
# [10:01] <dael> dbaron: The other fun case is if you have both top and bottom or left and right and figuring out who wins
# [10:01] <dael> Rossen_: We can use the scroll direction as a preference so ify ou're scrolling down we take preference of the tob
# [10:02] <dael> hober: Having the behaviour depend on initial scroll direction is weird. As an author trying to debug, not realizing it's that you originally scrolled
# [10:02] <dael> dbaron: I think he ment by which way you can scroll to overflow.
# [10:02] <dael> hober: I'm presuming you've scrolled a bit
# [10:02] <dael> Rossen_: Initially. When the scroller is at origin than you have a direction
# [10:02] <dael> hober: That does seem reasonable
# [10:03] <dael> adenilson: I have all thre browsers and they're all doing something weird
# [10:03] <dael> dbaron: It's a weird testcase
# [10:03] <dael> dbaron: We should try and fix this
# [10:03] <dael> TabAtkins: We're no longer shipping sticky
# [10:03] <dael> TabAtkins: It's in stable, but not in less stable versions
# [10:04] <dael> dbaron: I think chrome has sticky in experemental web platform, but apple is shipping and we are.
# [10:04] <dael> TabAtkins: The more i think about it, webkit's behaviour makes sense
# [10:04] <dael> dbaron: It makes sesne to pull to the opposite edge
# [10:04] <dael> TabAtkins: It doesn't want to exit it's containing block
# [10:04] <dael> hober: Which is undesireable in the weird case where they're the same.
# [10:05] <dael> Rossen_: Having section don't necessary mean...they can be sep by headers
# [10:05] <dael> hober: But they the stack
# [10:05] <dael> TabAtkins: This is how I'd expect if the containing block is the viewport
# [10:05] <dael> Rossen_: Or if the release is defined by interacting with another sticky item
# [10:05] <dael> hober: No no
# [10:06] <dael> dbaron: Youc an compute this locally and this is all data you want to send to your compositor. What I don't like about webkit is it's totally different information in that one case
# [10:06] <dael> dbaron: In every other case it's in the scrolling except in that case where the release is a scrolling position
# [10:06] * Joins: shans__ (~shans@public.cloak)
# [10:07] <dael> fantasai: Sticky is relative to the nearest ancestor
# [10:07] <dael> fantasai: It's sticky in both dimensions
# [10:07] <dael> hober: Yes. In the axis you set and offset
# [10:07] <dael> dbaron: top/bottom/left/right auto means not sticky
# [10:07] <dael> hober: It's relatively positiioned, but you haven't offset it from it's original static position.
# [10:07] <dael> fantasai: Okay.
# [10:08] <dael> dbaron: In firefox the green one is honoring the bottom 180 and the orange one is honoring the top 180
# [10:08] <dael> dbaron: Green starts like that beciase that's bottom 180.
# [10:09] <dael> dbaron: There's no release constraint, just sticky.
# [10:09] <dael> TabAtkins: Whereas in ours this means sticky so it stays
# [10:09] <dael> hober: So there's a release side where you're willing to release but if you haven't hit that you should stick
# [10:09] <dael> TabAtkins: Now that I can see it live, I can see it's a bug
# [10:09] <dael> TabAtkins: I'm not sure.
# [10:10] <dael> TabAtkins: If I like it or not.
# [10:10] * Quits: shans_ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [10:10] <dael> TabAtkins: If you say the green is bottom 180, top 0 it wouldn't ever fall off.
# [10:10] <dael> dbaron: It's kinda an edge case and I jsut want the make the impl simplier and don't have to worry about a release that's outside the box.
# [10:10] <dael> TabAtkins: I'm assuming this is because it's easier, but I'm not sure
# [10:11] <dael> hober: I think Simon thought through a lot of edge cases.
# [10:11] <dael> TabAtkins: I'm not opposed to changing.
# [10:11] <dael> dbaron: I think we're done this topic
# [10:11] <dael> TabAtkins: Who is edit position?
# [10:11] <dael> Rossen_: It's going
# [10:11] <dael> TabAtkins: You have a plan?
# [10:11] <dael> Rossen_: Yeah.
# [10:11] <dael> Rossen_: I have most of this edit done, I have to clean it up.
# [10:12] <dael> TabAtkins: Can we define static pos in your draft
# [10:12] <dael> Rossen_: Fine with me. WE need it for flex and grid
# [10:12] <dael> plinss: We haven't pub a WD in 2 years
# [10:12] <dael> Rossen_: As soon as I have the edit I'll ask for a new WD
# [10:12] <dael> Topic: CSS conditions
# [10:13] <dael> dbaron: This was a humorous spec
# [10:13] <dael> plinss: FPWD on April 1, 2015
# [10:14] <dael> dbaron: Is there stuff worth saying about the workshop?
# [10:14] <dael> hober: I have questions about it.
# [10:14] <dael> hober: Is it in this building?
# [10:14] <dael> many: yes
# [10:14] <dael> hober: It starts at 9?
# [10:14] <dael> astearns: 9:30. It's all day, but the afternoon is in Korean.
# [10:15] * krit the morning is in Korea and the afternoon in Korean?
# [10:15] <dael> dauwhe: We got the announcement in Korean.
# [10:15] <dael> dauwhe: It's independant talks.
# [10:15] <dael> plh: Is there a page for this thing?
# [10:15] <dael> clilley: It's only e-mail
# [10:16] <dael> hober: If the format is morning is in English and the purpose of WG to attend is to be able to interact, I assume there's oportunities for people to ask questions in the afternoon an have those translated back
# [10:16] <dael> dwim: Are you sure the afternoon is in Korean?
# [10:16] <dael> dwim: Korea guys may present in English
# [10:16] <dael> glaz: The meeting tomorrow is witht he TTA members. It's the gov't telecom agency
# [10:17] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [10:17] <dael> glaz: They are going to host the meeting on this floow starting at 9am about W3C and CSS ingeneral and than a focus on CSS in the morning.
# [10:18] <dael> glaz: The Korean members will give talks in Korean for the rest of the day. Al WG members are welcome to join.
# [10:18] * Quits: jh (~jh@public.cloak) ("Page closed")
# [10:18] <dael> glaz: And that's it.
# [10:18] <dael> glaz: Let me check the exact schedule.
# [10:18] <dael> plh: Is there a page for this?
# [10:18] <dael> glaz: No.
# [10:19] <dael> glaz: 9:30 for the first session, welcome at 9.
# [10:19] <dael> glaz: There's prob. an introduction by an offical before.
# [10:19] <dael> glaz: Registration is at 9, just say you're a CSS WG member
# [10:20] * liam not p;lanning to attend workshop :)
# [10:20] * astearns liam: slacker
# [10:20] <dael> glaz: at 2pm is pure CSS drawing. 3pm is CSS post and pre process. 4pm is CSS 3
# [10:20] * liam :)
# [10:21] * liam Live Free or Die
# [10:21] * liam Live three or Die
# [10:21] <dael> glaz: A few minutes ago I e-mailed TTA to thank them for hosting. I think the walking distance hotel was very convenient and they were incredibly helpful
# [10:21] <liam> [I would like to thank Daniel for the audio webinar facility]
# [10:21] <dael> glaz: I'd also like to thank dwim for all the help he gave us
# [10:21] <dael> Meeting agorned
# [10:22] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [10:22] <glazou> THANK U DAEL !!!
# [10:22] * Quits: plh (~plh@public.cloak) ("Page closed")
# [10:22] * Quits: glazou (~glazou@public.cloak) ("Page closed")
# [10:22] <krit> bye folks!
# [10:22] <liam> bye :)
# [10:22] <liam> 4:20am here
# [10:22] * Quits: dael (~dael@public.cloak) ("Page closed")
# [10:23] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [10:25] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [10:25] * Quits: andrey (~andrey@public.cloak) (Ping timeout: 180 seconds)
# [10:25] * Quits: shans__ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [10:27] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [10:28] * Quits: clilley (~clilley@public.cloak) ("Page closed")
# [10:28] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [10:29] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [10:30] * Quits: yamamoto_ (~yamamoto@public.cloak) ("Page closed")
# [10:31] * Quits: murakami_ (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [10:39] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [10:47] * Joins: dauwhe (~dauwhe@public.cloak)
# [10:52] * Quits: heeyoun (~uid33091@public.cloak) (Client closed connection)
# [10:53] * Joins: heeyoun (~uid33091@public.cloak)
# [10:57] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [11:04] * Quits: yamamoto (~yamamoto@public.cloak) ("Page closed")
# [11:30] * Joins: antonp (~Thunderbird@public.cloak)
# [11:36] * Quits: Garbee (~uid21171@public.cloak) (Client closed connection)
# [11:37] * Quits: abinader (~sid21713@public.cloak) (Client closed connection)
# [11:37] * Joins: abinader (~sid21713@public.cloak)
# [11:37] * Joins: Garbee (~uid21171@public.cloak)
# [11:52] * Joins: dauwhe (~dauwhe@public.cloak)
# [11:58] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
# [11:59] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [12:00] * Joins: antonp (~Thunderbird@public.cloak)
# [12:07] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
# [12:09] * Joins: antonp (~Thunderbird@public.cloak)
# [12:24] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
# [12:24] * Joins: antonp (~Thunderbird@public.cloak)
# [12:35] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
# [12:36] * Joins: antonp (~Thunderbird@public.cloak)
# [12:47] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
# [12:48] * Joins: antonp (~Thunderbird@public.cloak)
# [12:51] * Joins: dauwhe (~dauwhe@public.cloak)
# [13:00] * Parts: dauwhe (~dauwhe@public.cloak) (dauwhe)
# [13:01] * Quits: dwim (~uid10661@public.cloak) ("Connection closed for inactivity")
# [13:02] * Joins: dbaron (~dbaron@public.cloak)
# [13:11] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [13:20] * Joins: zcorpan (~zcorpan@public.cloak)
# [13:20] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
# [13:21] * Joins: antonp (~Thunderbird@public.cloak)
# [13:28] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
# [13:28] * Joins: antonp1 (~Thunderbird@public.cloak)
# [13:44] * Joins: antonp (~Thunderbird@public.cloak)
# [13:44] * Quits: antonp1 (~Thunderbird@public.cloak) (Client closed connection)
# [13:47] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [13:47] * Joins: zcorpan (~zcorpan@public.cloak)
# [13:54] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [13:55] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
# [13:55] * Joins: antonp (~Thunderbird@public.cloak)
# [13:58] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
# [14:02] * Joins: antonp (~Thunderbird@public.cloak)
# [14:13] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
# [14:16] * Joins: antonp (~Thunderbird@public.cloak)
# [14:38] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [14:44] * Joins: jdaggett (~jdaggett@public.cloak)
# [15:31] * Joins: zcorpan (~zcorpan@public.cloak)
# [15:43] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [15:45] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [16:03] * Joins: koji_ (~koji@public.cloak)
# [16:03] <koji_> fantasai; I:m ok to have the S&C added to HTML later, if that:s easier process wise. Would want an active version of it somewhere, so we can develop it, but don:t care if it:s in HTMl5
# [16:03] * Parts: koji_ (~koji@public.cloak)
# [16:09] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [16:32] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [16:33] * Quits: dauwhe_ (~dauwhe@public.cloak) (Client closed connection)
# [16:33] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [16:46] * Joins: dauwhe (~dauwhe@public.cloak)
# [16:52] * Joins: dauwhe__ (~dauwhe@public.cloak)
# [16:52] * Quits: dauwhe_ (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [16:54] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [16:54] * Joins: dauwhe (~dauwhe@public.cloak)
# [17:00] * Quits: dauwhe__ (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [17:06] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [17:11] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [17:13] * Joins: dauwhe (~dauwhe@public.cloak)
# [17:17] * Joins: xiaoqian (xiaoqian@public.cloak)
# [17:19] * Quits: dauwhe_ (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [17:19] * Joins: dauwhe__ (~dauwhe@public.cloak)
# [17:20] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [17:20] * Joins: dauwhe (~dauwhe@public.cloak)
# [17:25] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [17:26] * Joins: zcorpan (~zcorpan@public.cloak)
# [17:26] * Quits: dauwhe__ (~dauwhe@public.cloak) (Client closed connection)
# [17:27] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [17:28] * Joins: dauwhe__ (~dauwhe@public.cloak)
# [17:29] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [17:32] * Joins: rhauck (~Adium@public.cloak)
# [17:33] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [17:34] * Quits: dauwhe_ (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [17:35] * Joins: dauwhe (~dauwhe@public.cloak)
# [17:35] * Quits: xiaoqian (xiaoqian@public.cloak) ("Page closed")
# [17:35] * Quits: dauwhe__ (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [17:41] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [17:52] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [17:57] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [18:01] * Joins: lmclister (~lmclister@public.cloak)
# [18:11] * Joins: dauwhe (~dauwhe@public.cloak)
# [18:22] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [18:43] * Quits: harayama (~harayama@public.cloak) (Ping timeout: 180 seconds)
# [18:53] * Joins: rhauck (~Adium@public.cloak)
# [19:07] * Joins: jcraig (~jcraig@public.cloak)
# [19:16] * Quits: lmclister (~lmclister@public.cloak) ("")
# [19:16] * Joins: dauwhe (~dauwhe@public.cloak)
# [19:21] * Joins: lmclister (~lmclister@public.cloak)
# [19:23] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [19:57] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [20:09] * Joins: jcraig (~jcraig@public.cloak)
# [20:17] * Joins: dauwhe (~dauwhe@public.cloak)
# [20:25] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [20:48] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [20:48] * Quits: tantek (~tantek@public.cloak) (tantek)
# [20:50] * Joins: zcorpan (~zcorpan@public.cloak)
# [21:01] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [21:02] * Joins: tantek (~tantek@public.cloak)
# [21:09] * Quits: tantek (~tantek@public.cloak) (tantek)
# [21:13] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [21:18] * Joins: dauwhe (~dauwhe@public.cloak)
# [21:25] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [21:29] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [21:30] * Joins: zcorpan (~zcorpan@public.cloak)
# [21:30] * Joins: jcraig (~jcraig@public.cloak)
# [21:30] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [21:30] * Joins: zcorpan (~zcorpan@public.cloak)
# [21:35] * Joins: darktears (~darktears@public.cloak)
# [21:38] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [21:39] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [21:42] * Joins: tantek (~tantek@public.cloak)
# [21:43] * Joins: zcorpan (~zcorpan@public.cloak)
# [21:44] * Joins: jcraig (~jcraig@public.cloak)
# [21:46] <krit> zcorpan: Do you plan to use bikeshed on CSS OM View
# [21:46] <krit> ?
# [21:47] <zcorpan> krit: yeah
# [21:47] <krit> zcorpan: cool, it would auto link DOMRect and so on
# [21:47] <zcorpan> yes
# [21:58] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [22:01] * Joins: jcraig (~jcraig@public.cloak)
# [22:04] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [22:10] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [22:10] * Joins: darktears (~darktears@public.cloak)
# [22:10] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [22:30] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [22:30] * Joins: zcorpan (~zcorpan@public.cloak)
# [22:37] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [23:14] * Joins: jcraig (~jcraig@public.cloak)
# [23:20] * Joins: dauwhe (~dauwhe@public.cloak)
# [23:20] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [23:21] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [23:21] * Quits: dauwhe_ (~dauwhe@public.cloak) ("")
# [23:23] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [23:27] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [23:57] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# Session Close: Thu May 22 00:00:00 2014

The end :)