<florian> I heard someone was looking for me, but not who was. Anybody knows?

<dael> ScribeNick: dael

glazou: Welcome tot he second day of the CSS meeting.
... We have a few things for today. The wiki says animation behaviour, but that's this afternoon. We have flexbox issues, layout.
... There's the AC meeting from 11-3, I will be there, plinss will chair until 2. Bert will chair for the 2-3 hour, thank you bert.
... So we have flexbox issues?

<smfr> Simon Fraser

<vollick_> Ian Vollick, Google.

<SimonSapin> Simon Sapin, Mozilla

<Bert> Bert Bos, W3C

<florian> Florian Rivoal, Invited Expert

<dauwhe> Dave Cramer, Hachette Livre

<krit> Dirk Schulze, Adobe

<dbaron> David Baron, Mozilla

<zcorpan> Simon Pieters

<andreyr> Andrey Rybka, Bloomberg

<astearns> Alan Stearns, Adobe

<bobtung> Bobby Tung, Invited Expert

<bradk> Brad Kemper, Invited Expert

<alant> Alan Turransky, IAB

MaRakow: do you mind if I present?

<shans__> Shane Stephens, Google

Discuss split layout/visual viewport and zoom types

<iank> Ian Kilpatrick, Google

<murakami> Shinyu Murakami, Vivliostyle/AntennaHouse

maRakow: I want to talk about what's missing from specs as they stand.
... The behaviours are for zooming in various ways and how we think about the viewport in various situations.

<hiroshi2> Hiroshi Sakakibara, Beyond Perspective Solutions, Japan

maRakow: There's a couple current discriptions that we have. In CSS OM we have page and pinch zoom.

<plinss> Peter Linss, HP

<yamamoto> Kazutaka Yamamoto, NTT

<glazou> Daniel Glazman, Disruptive Innovations, Co-chair

maRakow: And device adaptation actual viewport is the viewport used.
... First thing is why don't we have one zoom type. I'll go through this fast to ensure same page.
... If we have a page content and we want to zoom there's two ways. Layout zoom where we inc size of content and everything rewraps within the viewport.
... WE do this for consistant zooms. This is something the user doesn't have negative issues of zoom in.
... The intention of the second type is less about reflowing the content and more about keeping it consistant.
... If it's more of a temp zoom you may just want a piece of content
... In this situation we call the area you can see as the visual viewport which is distint from layout viewport
... This isn't reflected in spec text. They're talking about inital viewport and that's important to the layout, but there's no text about the visual viewport
... One reason it's important is pinched zoom and fixed elements. Fixed is desc as attached to a sing viewport
... Do you attach fixed to visual, layout, both?
... [shows an example on the screen]
... The two top fixed elements are meant to travel with you on the page. Side nav is supposed to align nicely witht he right content. That's a problem where fixed are imune to scrolling, but whent he doc only expects one direction of scroll they align to one side and zoom starts to overlap the content.
... When the non-fixed content is zoomed it will overlap

<AH_Miller> Michael Miller, Antenna House

maRakow: [shows and example on Gizmodo] On this page there's a side navagation aligned on the left side.
... What we do instead is fix to the layout viewport so it stays when you pinch zoom b/c the layout viewport is stationary.
... If you attach instead to visual, the content starts to crossover
... There's a couple way you can do this.
... Otehr scenarios are bars at the top and bottom, content scrolling on left/right side of content (ie ads) and also full page overlays.
... If you pinch zoom and attached to upper left corner, it's hard to pinch zoom in.
... A page we use a lot is Atlantis World Fair.
... It's an ex of fixed content that expects to align with non-fixed content.
... Chrome has been doing a lot of work on this. It's similar to what we're doing, they keep content aligned left/right with fixed and not fixed.

<bkardell_> vollickhas joined #css

maRakow: This is a sort of thing we'd like to see desc in some spec in terms of how the viewports interact, how do the types of zoom interact, and defining the types of zoom.
... There's a lot of words that get thrown around. base-zoom, layout-zoon, and base-zoom are used interchangeably for things that change inside initail containing
... There's also visual-zoom and pinch-zoom. The ones we favor are base and visual zoom since the terms often don't describe all the ways the zoom can occur.
... My thoughts are we need to put through the existing spec and spec what each spec is referring to as well as getting good definitions

dino: Do you expose any of these as APIs?

maRakow: In part thats were some of the props for the client with client height are defined, They refer to a viewport. mostly we spec the prop hanging off the doc layout with the client height viewport.

dino: So the user can know they're pinched in two times?

maRakow: We have a prop that reveals that.
... We've talked about wanting a more explicit API.

dino: Do you ever expect the user or allow layout to happen as the pinch zoom changes. Someone wants a legend on the map and remain 1 to 1

maRakow: We don't. We have a few other things like touch keyboard where when we resize we allow scrolling to the bottom with keyboard up. We have a positioning type where you fix an item to the visual viewport, but that's the only case.

dbaron: My assumption is every spec is referring to a layout viewport b/c I think most were written before visual viewport existed.
... I think...there was talk about the lack of interop of all this that's interesting. I know of one place there the video is online.
... I'm inclined to think that it ought not be nec to go through every ast spec, though it would be nice as we revise for clarity.

maRakow: I spent some time making a list and for the most part it's swapping a word, but there were places where clarifying text would be helpful. As I finish the list I can send it to the ML

smfr: When I was talking to rossen he desc the model where when you're panning the layout viewport isn't moving, but when you hit the edge you start scrolling. Can you clarify when the scroll events fire?

<dino_> http://lanyrd.com/profile/ppk/

<dino_> http://www.youtube.com/watch?v=TF9ID1xwxno

<dino_> Presentation on Mobile Viewports

maRakow: We do fire scroll events. the model we have to interact two viewports, one req is that if you pinch zoom in, scroll down, inch out and scroll up you should be in the same place, so we need to make sure the viewports travel together. They're a box withing a box.

<astearns> also: http://www.smashingmagazine.com/2014/04/29/meet-mobile-web-handbook-new-smashing-book-peter-paul-koch/

maRakow: So as you go down you drag both viewports with you.

<bradk> http://www.quirksmode.org/mobile/viewports2.html

maRakow: So if I pinch zoom in and pan up/down he fixed element is aligned to the fixed element. When you hit the edge of the layout port, that's when you start to drag the other viewport.
... All the fixed elements are where you expect

smfr: And if you zoom and scroll sideways

maRakow: It'll stay consent here since this page doesn't have hor scroll available, but it should.

smfr: One issue I have is the pos of fixed opbjects depends on how you got to that state. We don't have that in iOS model.

maRakow: You mean like state pool?

smfr: You're dragging the layout viewport around. If you came back to that same page, but arriv through diff scrolling action, you could end up in a diff place.

dbaron: What does iOS model do diff?

smfr: Can I project?
... This is a page with four fixed elements, bars across the top and bottom.
... This is zoomed out. When I zoom in we keep fixed things relative to physical viewport so bars at 100% width layout to a narrow witdh. If you follow that model and zoom in enough fixed thigns crowd so we start pushing off screen by interpolating between the two viweports so you scoll around and see the edge of the fixed things.
... That gives weird drifting behaviour, but ameliorates the probelm where things get in your way. The layout of fixed position doesn't have any difference.

BenPoulain: the IOS moble website when you're targeting, it wasn't defined for that.

krit: Would the elevator model work on yours?

smfr: No.
... One thing I'd like to see is web authors express how fixed should zoom. People layout fixed and leave the left or top auto. I'd like them to be able to express that they always want it at the top but it's okay to move it.
... I've tried keying it off and it doesn't always work.

maRakow: We're trying to find compat for desktop. We handle fixed so at any point in pinch zoom you see everything when you scroll. WE tackled keeping content on screen at all times with a new prop which is device-fixed which attaches to visual viewport.
... It's opt-in, but it seemed dangerious to do that by default

smfr: And that gives you diff zooming? Doesn't scalle w/ page?

maRakow: Correct. If an author uses it they should already think of it.

florian: Both behaviours make sense. Seems we need an author level way of picking which they want.

dbaron: Some of this is more about adopting desktop to mobile, not really about content made for smaller.

???: Not quite. I have a touch screen, but sometimes I want to zoom. I'm not trying to pidgen hole

dbaron: Keying off auto seems like the wrong thing to me.

maRakow: It works well with content aligned with non-fixed content. If you leave the top/left on auto you don't have to do resizing logic, it's always just aligned since it's pos as absolute.
... In the gizmodo case, if you have a two column layout and then position the fixed as top/bottom/left/right auto as you resize you don't have to say change te left to make it stayed aligned.

dbaron: Ast he user resizes?

maRakow: Corrent.
... Just resizing. As the margin is reduced by shrinking the window, this pages will have a resize handler that changes left if they're spec finding left. If it's auto that'll auto be repos alongthe content.

smfr: Auto changes the fixed element relative to te right place.

dbaron: Based on the assumption it's scrolled to inital scrolling positiong.

smfr: I think it's indep.

dbaron: It matches the original position.

smfr: It's kinda like using auto, you use it where it is. Anyway, authors do this.

maRakow: I don't exect a conclusion today, I wanted to socialize the problem. We can con't on the mailing list.

smfr: I'm hesitant to say...to spec the zooming viewport behav in such a way that all UAs need to conform and can't innovate, but I'd like to see ways for authors to express what they want and we can converge on behaviour.

BenPoulain: And think about when you layout in the port.

<MaRakow> http://gizmodo.com/

maRakow: I think this is a good start.

<MaRakow> https://www.flickr.com/photos/34654941@N02/8560297430/in/photolist-8MXZUM-2nF5aq-baAvmM-fTMsFJ-e3rLc1-hVcTTe-ncLVr5-egjd34-mJuvoW-dDwovw-4aeSwh-6mC7FC-48nagT-bRgbVB-azj7AV-e1Ci8t-9bLLEJ-69489U-dk6EgQ-bXqvdN/lightbox/

<MaRakow> http://www.lostworldsfairs.com/atlantis/

glazou: Okay, so, nothing else on this?
... Thank you very much.

Flexbox issues

fantasai: I think we gotbasically 3 issues
... One of them, well 4.
... one was something TabAtkins and I have to work out and might not be quite ready.

<fantasai> http://lists.w3.org/Archives/Public/www-style/2014Oct/0489.html

fantasai: 2nd was alinement diff should depend on if the flexbox wraps, not the # of lines it happens to wrap to.
... The spec says that if there is one line of flex content than the align content prop is not used. If there's more than one we use align content to figure out how it fits.
... The prop is in a flex container that has wrapping the alignment dep on # of lines, so if my screen is wider than test they'll get unexpected behaviour
... This should dep on if the flexbox is wrappable, not on if it has more than one line

TabAtkins: The spec orig behaved like this and Alex Mogilevski requested the change

fantasai: I think is is more likely to give unexpected behaviour. So say I want to base-align to itself and center in theb ox and you don't get that because it falls on one line.
... So I thinkw e should change to just dep on flex wrap prop. People responded it makes sense.

TabAtkins: He did respond and say it was fine.

fantasai: Other comments?

TabAtkins: I think we need a Rossen okay and we're fine.

fantasai: How do we dial someone in?

dbaron: They call Zakim and Zakim calls this number.

plinss: So we're waiting for a call?

fantasai: He says he'll call in a minute.

TabAtkins: Did fantasai give you context?

dholbert: I was following in IRC.

TabAtkins: Comments? Yea/Nay?

dholbert: Yes. The align content change makes sense to me.

fantasai: There's one more issue Rossen was going to talk about.

TabAtkins: He's not here.

fantasai: Okay. In that case maybe we can ask dholbert to call back when he's here.

dholbert: Bye, talk to you soon.

dbaron: If there were enough to justify it dholbert could drive here.

fantasai: I thinkw e have 3 issues total, so I think TabAtkins and I should work on one over th break, but I don't think it's a WG issue. I think we'll all get confused.
... That's all for now, we can come back with rossen.

glazou_: I suggest a 15 minute coffee break and that will allow rossen to arrive.

[Break]

glazou_: Let's restart
... Since everyone is in the room and we have rossen, let's do flexbox

fantasai: He's waiting on feedback, so we only have one issue. The total DoC will be 3 comments and we'll have to go through the last one, maybe later.

rossen: If we get news, they should have had numbers by now. If I get it we'll maybe take 15 minutes.

glazou_: So I suggest taking things from the afternoon.
... Can we do ::role()?

::role()

TabAtkins: jcraig suggested a :role pseduo

hober: There's a few problem. One is the impl RA roles on the elements. When you have multi roles on one element, you get all of them.
... For styling you may want to style that as a switch or a checkbox. Right now that's difficult in CSS.
... THere's also the case of wanting to simply style all the buttons on the page
... You want to be able to say :role() and be done.

TabAtkins: That's convincing. Is there anything outside that?

hober: WE can always add more.

glazou_: You mentioned implied role. So some won't need an assigned role. WE'll need to refer to HTML.

hober: In CSS we say the host language has that.

dbaron: It's :: or :

TabAtkins: It's a functional class. It should be an ident.

glazou_: Can you have multi roles?

hober: Syntatically you can.

<dbaron> hober: but only one is active

glazou_: So if you have multi roles on one ident it's whitespace broken?

dino: So if you do colon role

hober: You can do :role button and :role super button. Or we seperate in the list itself.

glazou_: So the role attr is multi but the role pseudo is only one?

hober: Yeah.

dauwhe: dpub is working on adding things for role attr.

TabAtkins: Do you know if it will be consistent with this?

dauwhe: They haven't said. I'll raise that with them.

TabAtkins: So I guess that's simple. obj to adding :role() to selectors?
... So :role(button) would target anything thatha s a button accoring to aria rules.

hober: It wouldn't match button role = checkbox or something crazy

dbaron: So people are okay with agreeing CSS won't do future things to influence what the aria role is.

hober: It should be defined by pointing overthere.

fantasai: We need to have another language that has CSS language. OUr stuff should be about styling.

TabAtkins: If someone would like to impl cascading attr selectors in a browser *shrug*

dbaron: Having CSS do this side makes sense, but we can't do both.

hober: Should we have a note in the spec saying "you may be confused"

glazou_: When we had selectors we didn't have a note. I'm not sure we need a note.

hober: Okay.

glazou_: So not obj

<fantasai> fantasai^: People keep asking us to put things in CSS that belong in the DOM, because they want to use CSS selectors and cascading to attach it to the tree.

RESOLUTION: add :role() to selectors

glazou_: who is going prose?

TabAtkins: I will.

Status of selectors 4

dbaron: I stuck this on the agenda because I want to get to some things. At some point we should stop adding features and advance it

fantasai: I think I want to trim it to the thigns that will go to CR when I have time. Make a cut and put everything else in level 5. That was my goal last year, so I don't know if it will happen.
... I would be happy to take a resolution that :dir should be unprefixed.

glazou_: So to do that, does the WG think it's stable enough ot do it and 2nd are all impl okay?
... So object to it being stable?

fantasai: :dir and :lang are quite stable, the syntax is obvious, they fall in the level 3 template.

SimonSapin: Do you think the complex lang matching is ready?

fantasai: We're just point ing to it. I think Microsoft impl that.

glazou_: There were bugs in browser impl about :lang where one rendering language wasn't parsing more than one dash.
... It was a bit back. Make sure it was fixed.
... 2nd question, impl you okay with unprefixed :dir?

RESOLUTION: unprefix :dir and :lang

florian: Do we have a test suite?

fantasai: I think Mozilla does.

florian: It would be good to share so people who were prefixed get it right.

<ArronEi> There are very few test cases

<bradk_> :dur? collender?

glazou_: Anything else on Selectors 4? Test suite? Very few cases, can we have more?

fantasai: Mozilla impl so I'm sure they have a bunch of test cases. I'm not sure where.

<ArronEi> I will put the selectors 4 on my list

<ArronEi> ... for more cases

dino: Has there ever been a prop for an OM API to be able to set a pseudo class on something? Like if you want to set the initial-letter on a div.

TabAtkins: That's a pseudo element.

glazou_: So astearns and I suggested an API a way to create programmatically pseudo-elements. I'm not sure it got consensus, but I think it should happen.

florian: On this topic it doesn't look like the test stask from Opera will help. I went through the repo and they're barely there.

glazou: It would be good to have more tests. Anything else on Selectors 4 dbaron ?

dbaron: That's it. We have a bunch of JS scripts that would need to be rewritten, but they're straightforward.

<florian> s/stack/stash/

Rossen_ 's extra item

Rossen_: fantasai and I spent time cleaning up. We think we figured out the outstanding issues and cleaning up the lang.

fantasai: There's one issue open, let me pull it up.

dbaron: What's the next level?

fantasai: I think we need to repub WD, ask for review, go to CR
... WE say that if you have something you can't fragment, for ex some inline blocks, there's no line break opp possble within a line box
... You have an inline block on a line box, it happens to be 1 1/2 pages. You can't fit it on one page. We have lang that says if you're printing and have a thing that doesn't have breaks and will not fit, you can break whereever you want so the content doesn't disappear.
... The issue was do we want this for other frag such as Regions and multi-col

<astearns> issue in this section: http://dev.w3.org/csswg/css-break/#possible-breaks

fantasai: The default is no data loss for printing. For regions and multi-col you might be able to scroll to see it another way, but it's prob easier from impl to only have one way to fragment so we were thinking for this level we should be consistant
... That was our prop for closing this. Is there a diff perspective?

dbaron: I'm fine with it, though I don't think slightly different printing rules is that big a deal.

<fantasai> http://dev.w3.org/csswg/css-break-3/#possible-breaks

astearns: We need something saying what happens with other fragmentainers and the printing models is a good starting default. If we need something else we can add.

florian: Given that the prop is do what you need to to make it fit, we can check again later.
... It gives room to play around.

fantasai: So we'll close as apply to all fragmentainers. I think that's all the fragmentation issues. Anything else let us know. We'd like a resolution to pub a new WD with 6 weeks for review and than pub CR

dbaron: What's in the draft for new features

<dbaron> ... as opposed to just specifying things better

fantasai: We changed break-before and break-after prop. We have new values for force break, always and any. We have the rectoverso (?) values.
... Always forces a break through all the levels, so if you have a region in a pagination etc you break through all the things.
... We also have some values for regions spec things in addition to column and page spec. They're going to be at risk b/c it depends on where regions goes. I think that's it for new features.

Bert: A float is a fragmentainer?

fantasai: It's not.
... Unless it's a region.

Bert: Yeah. I was wondering if it's a useful case to include

fantasai: Technically a line box is a fragmentainer, but we put it out of scope.

Bert: I can imagine someone doing a three column layout and want a break mid-float.

astearns: Unless there's somewhere else for the content to go.

Rossen_: You can make a region inside a float.
... If you have a region inside your float, sure you can have three floats and call yoru content trhough there. Then you'd be frag context in a region in a float.

Bert: So I can page break in a void, but I can't use page break for any inside a float. So it would break over two pages, but I don't have full control as to where. I can suppress a break, but not force a break.
... Seems asymetric. I can do that with a region, I assume, but not a float.
... Sounded like the extra keyword of any would do it.
... I have to think more about that. I'm wondering why float isn't fragmentainer.

fantasai: Because it doesn't cause fragmentionation. A fragmentainer is a page, column, or region

Rossen_: It's what happens inside, not outside.

Bert: A page break can occur mid-float.

Rossen_: It's the content inside a float

fantasai: If you force a page break inside a float, the fragmentainer that's important is the page, not the float. You can do a page break inside a float. We define how that works, but the page isn't a fragmentainer, it's a containing block.

Bert: The floar has a flow.

Rossen_: Just like a table cell

fantasai: It doesn't make it a fragementainer, just a containing block.

Bert: It would still be useful to indicate where in the float I want to break it.

fantasai: Use page-break.

florian: You don't want floats to break across a page. That's not what we're doing, you can't split the flaot in half without splitting the page in half. Floats don't break without being in the page

Bert: If you break before always, any content after the float is on the current page.

fantasai: affect of the page break is only on the paralel flow

Bert: So it is for a float. So fragmentainer isn't the word I was looking for.
... OKay. That's what I wanted.

fantasai: Alright.

Rossen_: Publish a WD of fragmentation and give 6 weeks for feedback before CR?

<bkardell_> +1

glazou: Obj?

RESOLUTION: Publish a WD of fragmentation and give 6 weeks for feedback before CR

glazou: I have to leave for the AC meeting.

plinss: transforms next?

Transforms

smfr: I recently updated the ED of transforms to contain new text the desc rendering of 3D transforms
... This section on transform rendering is rewritten
... The first part is 2D transforms which we're clear on. 3D is the new
... Initially it talks about perspective. 6.1.2 desc how 3D trans elements are rendered, how they interweave and intersect with non-transformed elements. This was unclear before so this is making it good enough to impl

florian: Was it unclear or unintent ambig?

smfr: Unclear. I added a 3D rengering context. analigous to CSS stacking. It's a set of elements inside of which the 3 transformed elements are altered and can intersect, but are then flattened into a plane, just as stacking is flattened
... the way I spec'ed it here I mirrored the behaviour of stacking context in that an element with z-inder -1 will go behind the content and other decendants
... Let me show you pictures. This is on the wiki and I have a link from transforms as the first issue
... if you look at the blue box and compare to pale blue box, you'll see it's behind and that's the CSS2.1 order
... Now and element with a neg z-translate will go behind and a positive will go in front.
... This is the rendering the spec prop where the order is the B&B. Where the z = 0 plane it's the stanadard rengering. On top of that is the positive translated content.
... This is the idea behavior that the spec desc.
... A consiquence is it's poss to intersect tranlasted with the untranslated element.
... One of the issues is that this spec requires UA to basically render the root at two planes so it can do intersections.
... The problem is it could force UAs to allocated tqice as much memeory for some elements, so I have some concerns, but it is basically the ideal behaviour.
... On the ML Robert O'Callahan prop an altertantive where translate z-1 on top and if you rotate it wouldn't intersect. It's a bit more special case, but would allow browsers not to allocated twice as much memory.
... One consiquence is what happens...let me go back to the spec
... The issue we desc is issue 3.
... There's more subtile ones about UA impl details and if you intersect z=0 planes sometimes.
... krit asked if this is flattening. In the spec we have 3 values for transform style prop.
... There's a new auto which is the default. It means ignore this forthe purpose of computing 3D
... flat is make it flattening and it's a 3D rendering context ancestor.
... preserve 3D is the specil on where allow decendants to live in the same 3D space.
... So the default is auto which lets them live in the same space and maybe intersect.
... There's things that req flatten, like clipping, opacity. Byt default tranform and perspective also cause flattening. With transforms people want to build 3D hiraracy. If an element has a tranform the author can override the flattening.
... The role of transform style is controlling if transforms in perspective cause flattening. The root flattens by default which is simple.
... The previous had woring as to if elements belongs to 3D context, now it says every element belongs, like stacking.
... The main issue to discuss is the one I showed you because that influences..before I can write test cases
... Robert proposed the second.

krit: Resonaing?

smfr: My efficent for UA.

bkardell_: So it's possible to have a bunch of 3D sorting at the same time

smfr: You do it in the 3D rendering context you belong to. It has access to 3D rendering context. That happens no matter which model.
... One impact of Robert's model is position fixed won't intersect 3D transformed. So a position fixedw ould like in the z=0 frame. I think that's a downside of this model.
... It would be possble to have a combo, it's not impossible, it's just in some config.

MaRakow: Can you talk about how the new values would be used. If I have an item with preserve 3D

smfr: That was a mis-nomer. Preserve prevents flatting, not creates it. They would prob set preserve 3D flat, though that would likely be the default. It's only used if you want to override the default.

MaRakow: So every element would have auto except the root of the scene.

smfr: Preserve would only be used on transformed elements that want to live in the same 3D space.

MaRakow: I'm trying to figure out how it's diff from inheritence.

smfr: It's been suggested transform should inherit. I didn't do that b/c it would cause flattening in places we don't.

MaRakow: What's an example?

smfr: webkit if you have a perspective element and then a div, in most cases transform respects perspective.

MaRakow: Is the middle div already transform style flat?

smfr: It's more like auto.
... I think we may be willing to make it inherited. It simplifies.

MaRakow: That seems like a more existing concept as opposed to the children behaviour.
... Going back to z index, I think the neg Z index would be a pain point.

smfr: So you favor Robert's behav

krit: There's interop for that.

smfr: It has weaknesses. If it had a 2D transform it wouldn't interweave with a 3d. The spec would have to have special language saying it pops to the front. We would have to actively prevent interweaving.

MaRakow: The 3D rendering context is gone?

smfr: It's there, but morphed into an ex

MaRakow: Because they're in the same 3D rendering context you have to have the 3D?

smfr: In this ex everything is in the same context. I guess the nautual is by mirroring is the left, but the one on the right is Roberts, where anything with 3D pops tot he front. I think it's weird because anything that's 2D isn't part of that set of depth

plinss: Also if you're 3D into the Z plane you'd expect behind. I accept it's easier to impl, but is it rational? Does it give expeted?

MaRakow: What seems to me is the scenario between the text and bg where it's splitting.

smfr: But you have to impl that.

MaRakow: I wouldn't say we enjoy that.

florian: TabAtkins any thoughts from google?

vollick: I have a preference to the proposal from smfr.

krit: That proposal is more what users would expect if they understand Z index.

smfr: WE may have to do impl experements and come back.

krit: So does he obj to your model?

smfr: He agreed with my comment where it wuld force impl to output more memory.
... Maybe impl can be smart and know if they won't intersect.
... I guess with animations it's hard.

MaRakow: Does this do that much if everything is in the same 3d rendering context?

smfr: It's hard to know compat risk b/c impl are different. For webkit I intend to only do this for unprefixed, but other browsers don't have that luxury.

krit: WE created a lot of tests to observe behavior and for many tests, each browser was completely different. Current can't align.

MaRakow: Previous design that required you to declare here's where the content is, I'm hesitant to give that aspect up because it makes it easier to think of 3D and makes it more backage.

smfr: It's easy in current but existing conent might have issues. Making transform style inherit might solve.

MaRakow: In the new model you might have to wrap in a container div

smfr: The perspective prop calls it flatting too so you end up with three contexts. I don't think compat risk is too bad

MaRakow: I'd like to explore inheritence more.

smfr: Okay.
... Other feedback?

Bert: It's complex. I've given tutorials, but perspective is weird. What I never succeed is transform style. ou try it and it doesn't work the expected way.

smfr: That's b/c existing impl isn't constant. The new spec is more specific and the scope is limited.

Bert: Why do I need it

smfr: Hirearcies of elemnts with 3D elements. YOu often do syblins and you don't need transform style. If you want a decendant of a face of a cube to have it's own transform you need it.
... If you think of it like CSS Stacking, a transform is like z-index 0 it causes flattening, but you can override with preserve 3d.

Bert: So if you take a cube and make it roate, the cube disappears.

smfr: You'd want preserve 3d on the container. There's subtilty, it's about making an element not flatten. It allows its decendants to share the 3d space it lives in.
... There's a lot of content about preserve 3d for perspective, but you oly need it on decendants.
... You don't need preserve 3d on the root of a 3d scene.

plinss: If I have a minor compent and I want to to participate and it has a random ancestor, I need to set the perserve on the ancestor, not the child. I get technically why, but as an author you may want the other way around.

smfr: We have the opacity prop that forces stacking b/c the way it's speced you ender the decendants opaquely. Preseve 3d is render with the opacity and then combine. We don't have that for opacity, but that's the equivellen.

plinss: That's the way it should have worked, bt the other is cheaper.

MaRakow: From the author perspective, I think they're used to it being 2D and when your'e 3D you're asking to flatten at a certain point.

smfr: IN the new sib transforms will intersect. I think it's the correct behaviour. It's a change, but I found it hard to write text to formalize the other behaior

MaRakow: I think that's true for members of the same scene from an author perspective. I think it makes sense for those to intersect.
... That's weirder is the cases where they intent to isolate and it happens it's near other content that they thought of as 2D, but now it intersects.

smfr: So you're concerned about intersection with?

MaRakow: I thinkt he author doesn't tink of the non 3d section being part of the transform.

smfr: So you'd prefer the 2nd?

MaRakow: I think they should be capable of intersecting, but that's not te default expectation.

smfr: I think the choice between the two of if you get depth sorting by default, the pro is it's more like z-inder and more consistent of a default, but it's more resource requiring and may have unexpected intersect. Also 2D transforms don't interact in the same way as 3D.
... IN our impl some decendant with something special wills tart intersecting and we'll have to turn it off in a funny way

MaRakow: I don't have a strong opinion, ut if the feedback is I'm not sure which, I think we should avoid the intersection.

smfr: I think the feedback will go away.
... Other comments?

krit: In this case you spec on the container itself. I think I would expect it to intersect the text by default

plinss: It seems like a reasonable default. I think you should let the author opt,bti u t makes sense.

smfr: I think flippers and stuff will still work as expected.

<smfr> https://wiki.csswg.org/spec/intersection-of-transformed-and-untransformed-elements

krit: You're unsure if an author thinks it's better to have intersection?

MaRakow: I think the main thing is as an author I don't expect everything in my page to participate in 3D.

krit: In this case?

MaRakow: I'm not sure. I have to go figure out.

smfr: We've seen people put perspective on the body, but mostly they want a 3d scene.

MaRakow: It's hard to think about it in terms of test cases because I'm not sure about more active applications. Have you guys impl this?

smfr: I've done part. transform style auto value, but not the intersection.

MaRakow: Feedback?

smfr: Great.

plinss: So are you looking for a resolution?

smfr: Looking for impl and author feedback.

krit: MaRakow do you want to look at it again?

MaRakow: Sure. It's like to see what your results are.

plinss: More transforms?
... Everything else folks wanted in the afternoon.
... What about animations?

Rossen_: sylvaing wanted that.

smfr: I think we wanted to do that at 3pm.

fantasai: Text?

Text

fantasai: Let me pull up notes. The main issue was the justification where' I'd want koji.
... Other stuff is as I was cleaning handling of Korean, I noticed we have text saying just method depends on lang conventions. We need to havei t say writing system and convention.
... Many languages can be written in multiple writing systems. The correct layout isn't only language-dependent. Mongolian, Japanese, Turkish.
... So if anyone has comments or concerns about that let me know, if not I'll take a resolution to update the spec.

murakami: For korean and hangul, all the text didn't have word spacing. and it's not sufienct to distinguish modern and older hangul text. And the lang attr cannot be used. I think the text justify property is needed for distingushing modern and older style hangul.

fantasai: I think old style hangul is only hangul, correct? Doesn't include latin?

murakami: I don't think too much hangul, but I think the word text was used in 1896. Before then, Hangul text did not have word spacing.

fantasai: If the text does not inc latin, then inter-character is suffiecent. If we need to worry about lating, we need inter-idiographic.

murakami: I think it's needed.

fantasai: I think for right now it's enough of an edge case we should address it in the next level. IN general it can be worked around with intercharacter value unless it's mixed script. In that case we'd need to look at reintroducing interidiograph

murakami: INtercharacter isn't good for all hangul. The latin letters may be included in old hangul text.

TabAtkins: Is ther much old hangul on the web?

murakami: I don't know very much, but some examples I posted on the ML.
... Not I. Someone else.

fantasai: I think someone said they were wrong.

TabAtkins: The KL examples were pretty wrong.

fantasai: I don't have a trong opinion, but I think jdagget does. I think we should take justification up when he calls later today.
... I think we should come back to this and resolve on effects being writing system and language dependant.
... Any concerns with that issue?

RESOLUTION: layout method should depend on writing system in addition to language convention

fantasai: The rest needs to be afternoon.
... I think andreyr had a selection issue?

Selection issue

andreyr: WE discussed in France, but fantasai put together the spec. The grammer and spelling squiggly lines, we wanted to control that color.
... We asked to add it to the spec. Andy objections or opinions?

florian: It was mentioned that there are security concerns, but it can be handled as long as we're careful

TabAtkins: You're limited to only color prop. things that don't affect layout.

fantasai: Add ::spelling-error and ::grammar-error and have it follow restrictions in layout model of ::selection and add additional security verbage

plinss: Do we want distinct pseudo-element or a functional one?
... I'm just curios

andreyr: I don't have an opinion

fantasai: I don't have much of one. We already have selection.

<liam> [ is the squiggly line already a text-decoration value? ]

plinss: I'm thinking of other uses like annotations. I'm wondering if it's extensibility point, or do we add more names?

fantasai: I think we're anames either way.

plinss: Is it the full scope or a limited scope. It's something to consider.

<astearns> liam: yes. wavy: http://www.w3.org/TR/css-text-decor-3/#text-decoration-style-property

<SimonSapin> liam, yes, 'wavy' http://dev.w3.org/csswg/css-text-decor/#propdef-text-decoration-style

fantasai: Full pseudo-element space for now. If we find a need to abstract it we have time. There was discussion of having custom, that would need to be encapsulated. For these in the browser they won'tbe customer. Having the outlined not in that scope is a good idea.

<liam> [ thanks, slthough does this let you colour it differently from the text?? ]

fantasai: WE won't be mixing custom and pseudo which is a good idea.

plinss: Adding to what?

TabAtkins: pseduo-elements

<SimonSapin> liam, text-decoration-color

plinss: Wasn't pseduo-elements abandoned for a while?

TabAtkins: Didn't we just revive it?

fantasai: Yes. the plan is work in the meeting, do more testing, then post to www-style, ask for reviews, and then ask for FPWD

SimonSapin: What are the security issues?

fantasai: :visited exposes history, this exposes your dictionary.

TabAtkins: It' a fingerprinting link.

plinss: WE need to care about thos. Also in thing like OSX your address book gets added to your dictionary, so it's def a security thing.
... Even if you want to say fingerprinting is a lost cause, you don't want to open the surface error. You don't want to say I don't care about fingerprinting.

TabAtkins: But once I can be fingerprinted more doesn't hurt.

plinss: It's a different set of values. And there are folks working on fingerprinting.

florian: It was pointed out yesterday we made a resolution on elipsisw ith two values we said start/end instead of left right, given that a fairly reasonable useage is arrows, we may want direction.

fantasai: That's why the spec currently has left/right

florian: The other arguement is there are some things that do flip

fantasai: We have line-left and line-right. It should be physical and mozilla impl that.

florian: It's that or let the author pick what he needs.

plinss: Are there use cases in both ways?

fantasai: I've seen elipsis and arrow, I haven't seen start and end different

florian: If you go with parens they mirror, but you prob don't want to. The reasonable use cases don't need that and we could later have a syntax to let you say start/end.
... We also pointed out that it was inconsistant, but when you have a value it applying to end makes sense.
... So it stays inconsistant. It's not clean but sounds practical.

plinss: In my mind i'm thinking when it shows up is logical, but which one we choose is phsyical.

fantasai: It depends on scroll position. Initial scroll state is logical.

TabAtkins: It depends on if it's overflowing this end.

plinss: In the single value case you're not spec the end, it's just a value with whereever there's ovrflow.

florian: I think you spec end. I'm not sure you should, but that's what it says.

plinss: So you explicitly don't get an elipsis on the other side if you only have one value. You never get one on the start end.

florian: If there is one value it only applies to end line edge.

fantasai: Whatever is there is prob right.

plinss: Is that what we want?

fantasai: Given that the one value has a lot of use, we can't change a whole lot. There's silliness already like you have to spec overflow not visiable. That's the behavior we're stuck with.

florian: So do we agree to replace yesterday's resolution with line-left and line-right?

RESOLUTION: replace yesterday's resolution for start/end with line-left and line-right

Counter Styles

fantasai: It's in LC. Any open issues? If not, lets go to CR?

TabAtkins: One issue was about a handful of styles that browsers have impl but weren't in the draft since we cut it down. I add the ones with high interop.
... About 20 styles that are impl since they are dependable for authors
... The ones that aren't clear is the Tamil style is only FF.

<TabAtkins> afar, oromo, sidama, tigre

florian: For the 20 you talked about, you said reasonable, is that 2 or more?

TabAtkins: 2 or more.
... The list above is supported by the browsers with roots in webki.
... My opinion is to not put them and recommend that they're removed for consistancy. It's still in the original document. So, yea or nay on that. Keep the ones that are impl my more than one browser.
... I'll ask for removal with bugs.

plinss: Is that what we want?

TabAtkins: Yeah. If you do the author definition, you don't need the one ot be in FF

plinss: Other opinions?

Bert: Can you repeat the ones you keep?

TabAtkins: It's long. If you find the list in the archives there's a list from Richard Ishida of the additional values supported by FF and webkit derived.
... All the values are in the spec right now.
... The ones that are one browser are in the minutes above.

florian: Are we confident they're right?

TabAtkins: Richard has been testing and he's confident.

florian: We pushed them our because we aren't sure. HOpefully the match what speakers would expect. If that's true I'm happy witht he spec.

TabAtkins: It's just listing them. They can be fixed in the future.

florian: One reason we're pushing in this direction is to avoid time discussing languages we don't udnerstand.

plinss: But it's not all browsers.

TabAtkins: Everybody by IE which is pretty close

<bradk_> "Archived-At" header shows where an e-mail is archived for Web access

TabAtkins: If no one objects we can keep the list of 2+ browser supported languages and not have the 1 browser suppoted.

<TabAtkins> RESOLVED: Add to Counter Styles the additional styles supported by 2+ browsers (per r12a's email), do not add the styles supported by only one browser.

TabAtkins: That's the only e-mail from counter styles since the LC announcement.
... So given that I've made the change in the ED can we go to CR?

Bert: Go for it!

TabAtkins: This has to be old process CR.

fantasai: I think you should be able to go into the new.

florian: We siad it wasn't clear if you can do it with this.

TabAtkins: I think we can just do it.

plinss: I think the doc says if you're in LC you cannot switch tot he new process.

fantasai: We've fulfilled the old process req.

plinss: Let's resolved to take counter styles to CR and go to the new process if we can.

TabAtkins: So obj to pub under some form of CR?

RESOLUTION: take counter styles to CR and go to the new process if we can.

plinss: I propose we break until 2pm.

[lunch break until 2pm]

<jdaggett> what time are things scheduled to start again?

<SimonSapin> jdaggett: 2 pm, in ~40 minutes

<jdaggett> ok, cool, thanks!

<jdaggett> got up at 5am for nothing... :P

<dholbert> jdaggett, got up at 5am for musing about ancient hangul!

<jdaggett> dholbert: god i hate those mornings...

<jdaggett> leave it for the ancients?

<fantasai> jdaggett: works for me

<jdaggett> :P

<fantasai> I think what we're looking at is, if you want to handle such documents, either we need to add back 'inter-ideograph' or 'inter-cluster', or they have to use 'inter-character'

<fantasai> well, actually, nevermind

<glazou> jdaggett: rofl

<fantasai> if there's no spaces, they'll space out

Bert: Is everyone here, shall we start?

Fonts

Bert: I guess we need jdaggett. Can someone ping him to call?

<jdaggett> need to dial in

TabAtkins: While we wait, richard pointed out we didn't create a time for CR for counter styles.

Bert: What time? We do 6 or 3 months

TabAtkins: 3 months?

ChrisL: You can always take longer.

<jdaggett> so dial into zakim and do what?

<dbaron> jdaggett, ^

RESOLUTION: 3 months for counter styles CR

<bradk_> http://tldr.someecards.com/wiki/gavel/

Bert: So fonts. First subtopic...

ChrisL: It's osmething jdaggett thought we didn't need to.

Bert: Classification of Kai as cursive.

jdaggett: I took it out of the draft

fantasai: I think they'd like it to be reliably returned.

jdaggett: I had some people say serif too. It'snot an interesting debate for CSS.

Bert: What are the downsides of leaving it out.

jdaggett: I took any reference out and I don't think we should delare it either way. The spec was just listing examples and if there's controversy we should leave it out.

ChrisL: I agree. If there's differences it shouldn't be an example.

jdaggett: Okay.

r12a: My understanding is that the Chinese wanted to get to somewhere when it would give you something like Kai if you select cursive. They'd like to know a way to influence it to get the correct font.

jdaggett: Stepping away from Chinese, the generic cursive is somewhat useless because i can be all manner of things. It's prob not used that much. It's a random font that looks scripty.

ChrisL: Good examples?

fantasai: Problem is Chinese use things like a Kai font in a similar was to a roman font vs an italic. WE need a generic way for the distintion where you don't lose the semantic. They need a way to switch without providing their own font. It's about I need to express stylistic difference.

jdaggett: The underlying problem is we don't have availability on, you don't have kai style font on every system. These sorts aren't available across platforms so as a generic it's not useful.

bobtung: There's Kai on Microsoft on iOS, it's Android that doesn't have Kai or Ming. It's important in ebooks, such as Chinese. We usually use the Kai for citations, quotations, and dialog.

florian: And you're saying it might not be universal, but it's common.

bobtung: Many of them.

Bert: I'm not hearing progress.

fantasai: I think it comes down ot we say either we don't care about your problem, or we say we'll classify Kai as cursive and use cursive vs serif as a way to switch. Or we decide we'll do something with font style and add a kai keyword.
... I'm inclined to not do the first option. It should be expessible in a generic way.

florian: What's wrong with creating a Kai catagory.

ChrisL: You have to decide what happens when you use it for another language.

jdaggett: To put this in a diff context, I think every script has a diff set of typographic decisions. There are broad catagories to classify fonts. I think it's not really helpful for CSS to try and use generics to classify.
... The idea of a generic is you can use it across systems and it's consistent. I don't think in this case or any of the other cases, like slabserif.

fantasai: I'm not in favor of inc # of generics. I think we need the very broad catagories we have and they serve as a generic fallback font family. I think we should solve this specific problem by classifying it as cursive or italic or making it a new font style value.

r12a: So you're saying you'd take Kai out of the serif?

jdaggett: I don't think CSS is the right place to make this decision. It doesn't make sense for us to enter this debate.

r12a: The proposal was from a Chinese group for pub industry was that Kai was in the wrong place. I'm asking do you want to keep Kai under serif catagory or will you take it out?

fantasai: He's already done that.

r12a: That's fine.

fantasai: That doesn't solve the publishing industry's problem.

jdaggett: I think you need font availability consistent across platforms and you don't have that, particularly on mobile.

florian: I don't think this group should go with a large effort, but if it's not done here, where?

Bert: We had two options, a new generic family of Kai wasn't popular. Another option was a font style. Is that reasonable?
... What would be the downside of that?
... We're not making progress.

jdaggett: I think this is better on the list with a wider audience that might have knowedlge that applies.

Bert: No new ideas?

fantasai: One thing we migh want to resolve is if we're going to address the issue. If we're not we should resolve it now. If we're going to find a solution, then the list is going to be charged with finding a solution

Bert: So should we try and come up with a solution, or say it's not our business?
... fantasai says we should solve it.

bradk_: If we don't solve it will impl do different things?

fantasai: Or no one doing anything.

dbaron: So what is the issue? Allowing authors to choose a Kai font?

ChrisL: Allowing them to say I want two types of fonts, A or B, and they're distinct and it should work for more than Chinese.

fantasai: That's really vague. I don't think anyone will be satisfied.

ChrisL: If not that, we should be providing fonts. We're moving that way.

fantasai: ereaders don't hvae that option. Lots of devices don't so looking at system fonts is a thing.
... Chinese is also a pretty big download. If it's generic enough that most Chinese ereaders would have it.

jdaggett: I think this requires extra knowledge that's not in the room, so I think we should defer to the list.

Bert: I think we can conclude we won't solve it here, but I want to ask are we going to try and solve it at all or give up.

jdaggett: one condition to solve this, a generic requires common support across devices. If there is common support then having a CSS solution for a generic makes sense, but if you don't have a common support there's not much you can do.

Bert: And how will we find that out?

jdaggett: I don't know. Maybe people in the Chinese pub group can come up wtih a list of fonts?

r12a: We can take this back to the group of publishers who brought this up in Bejing.

fantasai: We might find the nec fonts won't be on all devices, for EX my windows computer will only likely have one.

jdaggett: It's more android that you'd worry about.

fantasai: If it's not targetted at the Chinese market, it won't likely have more than one. If we limit to the Chinese market we might find the availability.

jdaggett: Hong Kong too or just mainland?

fantasai: All of them. If you're looking across the world the answer will be no. Will it be on all systems in the target audience, we might get a yes, though maybe a no. If your criteria is all systems everywhere needs to have these fonts, we won't have that.

Bert: I think we've discussed enough.

r12a: bobtung is here and he has a table taht shows the major systems have Kai, serif, an sansserif, but lets go back to the list.

Bert: So the question is do we want this to go back to the list?

florian: So list or never or...?

Bert: Back tot he ML and try and solve it, or should we not try. We won't have a solution right now. Anyone thinking we shouldn't move this to the ML?
... No one objects, so back to the list ofr a solution.

fantasai: So the goal is the list will come up with a solution and not entertain not having a solution unless we discover it's intractable.

Bert: Yes. Okay with you jdaggett?

jdaggett: I'm not really comfortable with it, but we can deal on the ML.

RESOLUTION: Topic goes back to the mailing list

<jdaggett> http://lists.w3.org/Archives/Public/www-style/2014Oct/0472.html

Unicode-range issues

jdaggett: This is small impl details about unicode range. Can someone project the link?

[Trying to find someoe to project]

jdaggett: If people bring up the link in IRC, unicode-range allows you to say for spec fonts, only download if you're using it for this set of char. Sometiems you're pulling down a font for non-specific character list and instead are pulling down the line metric. So we have 3 fonts we can download, which do we choose
... You can solve this many ways. You can decide on a specific character, on the last font defined, any choice is arbitraty. Chrome looks for the first font that defines a space character.
... Safari and IE claim to support, but their impl pulls down the whole font no matter what so that's not close to spec. Does it make sense to do thiso r is there a better way?

ChrisL: I agree it's arbitrary and it's more important that we pick something. The space thing is as good as any.

TabAtkins: Ditto.

dbaron: I think it's fine. Some units do depend on a particular character. The x unit can depend on characters, the ch depends on 0. So maybe it should be a 0 character for the ch and space for everything.

ChrisL: If we're doing arbitrary, why not 0 for everything?

TabAtkins: I doubt we thought this through much when impl but if you have spaces, you have 0s likely.

fantasai: Another consideration was one use case you want numbers to line up. 0 will always have the width of the number. Numbers typically are things you want to line up so we wanted to pick from there.

jdaggett: Within a font there are a set of non-glyph specific metrics. What I'm getting at is the only thing needed is the general font metrics to pick up a font.
... For fonts that depend ona measurement for a glyph it should be more specific.

Bert: I'm hearing any character is fine.

ChrisL: Given that one thing requires 0, I think we should use that.

dbaron: But if you're doing a thing using actual font metrics, you do this.

fantasai: WE do use the space to measure how it's tagged.

ChrisL: Okay. I withdraw that.

dbaron: I think it's not the question of if it has a space, but if the unicode range for the @font includes a space.
... If you were looking for a space and the space was in the unicode range and the font didn't have it you would continue to fall back.

Bert: So does that give you enough information jdaggett ?

jdaggett: It seems we can use the space character to use which fonts to look up and I can post the wording change.
... 2nd issue in that e-mail, in situtations with overlapping unicode-ranges, the spec needs to be more specific about loading behavior where you don't want to load all fonts in that family that havea code point. You only want to load one at a time.
... If there's some character in the unicode range of two different fonts, you want to pull the first font and test before pulling the second.

<ChrisL> I support the proposed restriction on one concurrent download per font family

ChrisL: I was about to agree, but what if you have bold, itla and roman.

jdaggett: No, no. If you look at the match algo where this would go is set 5 where you've already matched to a specific.

ChrisL: that's fine.

Bert: Thoughts on impl? If you're serializing things may slow down

ChrisL: If you initiate a download of a larger font you'd have o throw it away, so this is saving time

jdaggett: In the ex you've got a latin and a fallback and you don't want to load fallback unless you really have to.

Bert: Okay. Different opinions?
... I see thumbs up.

<jdaggett> resolved: only download a single font per family when unicode-range values overlap

jdaggett: Next issue is the proposal from Google.

<jdaggett> http://lists.w3.org/Archives/Public/www-style/2014Oct/0434.html

<jdaggett> https://github.com/igrigorik/css-font-timeout/blob/patch-1/README.md

TabAtkins: Yes. I will link to...

Bert: jdaggett did.

jdaggett: That's the post and the proposal.

TabAtkins: Right now browsers do different things handling a font download that's taking a long time. FF and Chrome will display nothing for 3 sec and use the fallback until it comes in. Microsoft immediatly does fallback, Safari shows nothing until the font comes in
... These are all geared to when text was the only thing. This is for a font-rendering descriptor that lets authors control font fallback behaviour. These are all variants on the manditory requirement
... If you have a less nec font and are okay witht he user seeing a fallback, you can use swap or optional which only uses the font if it's downloaded.

jdaggett: What happens on reflow?
... Lets say you hover over an element that changes the style, what happens? Do you continue to use the non-downloaded font or?

TabAtkins: For consistancy, for optional or swap if you hit the case where you're sticking with fallback for page lifetime, you're staying with it.

fantasai: What about resize?

TabAtkins: Maybe you won't reflow.

jdaggett: This font made it or didn't and then it's like a state that's maintained? If I add elements what happens?

TabAtkins: The name resolves to a particular font at a particular time.

jdaggett: So even if I download the font it'll never appear on that page?

TabAtkins: Yes.

jdaggett: Why is this necessary?

TabAtkins: The prop version isn't as necessary. It can be left off. The property is if all you know is that a given element is important and needs to be displayed you can set that at the element level instead of tagging each font face.
... It means thatf some elements show up some times you might not trigger the font download manditorily.

jdaggett: So if I set one option and one manditory on a different element, what happens to the other element?

TabAtkins: That don't delare rendering?

jdaggett: Or additional section. You're saving a piece of state and I'm not sure which one.

TabAtkins: On a per element basis you would override a piece of state. So you're okay with your header reflowing, but you don't care about using the fallback on small pieces of text.
... In the example the header always gets the branding it wants.

jdaggett: Why can't this be with script?

florian: As a user I don't like the manditory and I want swap and I'll put that in my user stylesheet and I can't do that if it's script.

jdaggett: You want this in the user stylesheet?

florian: I do.

TabAtkins: The manditory strategy is pretty easy to do, the others are a more involved piece of code, especially the optional value.
... Using the font loading API for the more optional ones is more difficult that it might look

jdaggett: What's the default?

TabAtkins: We're not sure.
... It would be UA defined.

fantasai: I think it should be auto. The UA should be able to come up with other ideas. If we say the current manditory of 3 s it doesn't let them come up with something thatsn' ot a timeout.

jdaggett: And FF isn't a straight 3 sec timeout. We check to see if it's progressed about the first 3s and if it has we wait another 3 s before fallback. So you have to be careful not to block.

TabAtkins: So that seems like it should be UA defined.

fantasai: Do you have another name becides auto?

TabAtkins: Yeah, sure auto then

Bert: Other opinions?

MaRakow: Is anyone asking for optional? When they never get the right font?

<fantasai> TabAtkins^: Sometimes we just say it's UA-defined

TabAtkins: I'll have to ask for more examples.

<fantasai> fantasai^: Yeah, and that has to map to one of the other options.

jdaggett: I think the timeout needs to have a definition. Like starting when?

TabAtkins: When the CSS is seen more or less.

jdaggett: One of the problems is downloadable fonts have a lot of content and we only look once layout starts we tend to not get into a good position in the queue.
... Optional will fail a lot of times.

florian: It fails on first load.

TabAtkins: Optional is for fonts nice to have but not required.

jdaggett: I think some of the resource based is better than CSS

TabAtkins: I'd like examples.

jdaggett: It's like you're loading the resource here for use in another page.

TabAtkins: Sure, yes.

fantasai: That doesn't make sense.

TabAtkins: You're loading for other pages in the domain.

fantasai: What happens with iframes?

TabAtkins: They're a new page. They're a weird element, seperate.

Bert: So do we continue working, or think it's a bad idea.

jdaggett: I think tehre's useful stuff, but I'm not sure this finegrained stuff is useful to give to authors. The timeout may be something a user wants to set. It's like anti-aliasing, it's a preference. I think the swapping in and out is, well, does the user want to see the text. When I'm on mobile Safari I don't really care I just want to wait before seeing the text.
... You're making it an author preference.

TabAtkins: The property value exists to override that.

jdaggett: As a user I couldn't override.

TabAtkins: You could apply it to the user style sheet and who care about loading the font for 60 secondss what the author says.

florian: And if your browser doesn't allow user stylesheets, get another one.

bradk_: Another case for manditory is if you have icon fonts.

florian: Manditory is relevent on icon fonts so it's useful to have in the hands of authors. that's the reason why.

jdaggett: We created font loading to give authors this level of control. They should decide how they want to introduce it or not. I don't think this has to be encapsulated as a CSS property

TabAtkins: You can use font loading for loading behaviours you'd want, but making the common cases simple, the non-defaults and better for users. The defaults are hostile because they're trying to be conservitive.

fantasai: It's user preference.

TabAtkins: It's per font. You don't want icon fonts to shwo with fallback.

fantasai: Are icon fonts the ones that change letters into pictures?

TabAtkins: Yes. The default is tuned for that kind of usage instead of fonts that render text. The don't show anything until the font is loaded is bad. We should preserve that ability, but being able to do this is better.

fantasai: How did we end up in this mess? We've optimized for the stupidity. The people that want the right thing now have to learn more CSS prop to make your page nice for the user.

TabAtkins: You've described CSS. Yes.

jdaggett: Instead of using icon fonts, if you use an icon image you have the same problem.

fantasai: Use emoji.

TabAtkins: Remember we didn't have emoji when we made this.

florian: I think this needs tweeking, but I think it's worth persuing.

Bert: I heard looking into resource hints should be looked into, can it be done with API, though user stylesheets can't. Other things to look into?

bradk_: Defining when timeout starts.

Bert: I didn't hear full opposition or support so it needs futher study.

TabAtkins: If we're okay on the mailing list.

fantasai: I say we call it font loading instead

Bert: There's one more issue on fonts?

<fantasai> jdaggett: font-rendering is a terrible name

jdaggett: Last thing I wanted approval on was I wanted a CSS4 fonts so when people have new ideas we have a placeholder.

<fantasai> +1

fantasai: +1

TabAtkins: Given my experience, I recommend we make this a delta spec and whenever you want to publish it's much easier to keep error from creaping in.

jdaggett: Hopefully everything will be fixed.

TabAtkins: I hoped that too.

Bert: So you can work on CSS4 Fonts.
... Okay, back to plinss

jdaggett: I have to go.

fantasai: Can you be back?

jdaggett: After 5pm your time

fantasai: We'll save it for you.

<fantasai> jdaggett: Thanks. :/

Animation

dino: If we're going to break soon, this might take an hour or more.
... We could briefly talk about which we have krit...the filters proposal? Or is something more important?
... Scrolling and animations is all one thing.

plinss: So break and get back to that.

[15 min break]

plinss: Let's get started.

dino: The topics we had discussed in this section were some animation features related to scroll, the before scroll event, and the scroll snap points.
... WE can go through in order. From the CSS wiki is the proposal of three things related to animations. I don't have a demo for animation behavior so we can start with that.
... If someone can paste the link in IRC. This is adding what's called addidtive animations to CSS animations

<astearns> http://lists.w3.org/Archives/Public/www-style/2014Sep/0135.html

dino: If you have an animation on a transform and a second on that transform, it overrides the first animation and the element. So this prop is it replaces or adds. So if there's a rotation animations and yadd enough it would combine.

<astearns> (animation-behavior: add)

dino: There was a proposal for cumulative and additive.

bkardell_: The cumulative is if it adds and repeats on itself.

dino: So like a bouncing ball where you'd like it to bounce and then contniue.

smfr: Does this mean we have to spec which properties are additive

dino: Yes. Web animations has done a good job of that. Most aren't additive.

bkardell_: Or it's just replace.

smfr: So if it's absolute 10 pixels, can you add less?

<astearns> s/bkardell_ /birtles/

dino: If it's al enght they add, color adds componantwise. If it's a transform they multi the matrix

<fantasai> I'd like to suggest animation-behavior -> animation-combine

dino: I guess the q to the group is this in animations level 2?

dbaron_: One thought is we have had other caes where we want additive cascading. I don't htink that's an obj but it's related.

TabAtkins: I think that falls to a different spot unless it's addition over lists. I can't think of additive values where you have two lists and you add to append.

dbaron_: Filters and transforms.

birtles: The other feedback was the name.

dino: I shouldc are all my proposals I don't care about name. It should be animation composit.
... So the scrolling part. Part of the e-mail had a proposal for 2 prop one that's when the animation starts. the default is it starts when it's applied. I called that animation trigger. The other was the time base.
... One of the major performance things is to make scrolling as smooth as possible. The current web trend is to do fancy scroll things and that makes pages scroll slowly. They do this by making JS that listens to every scroll.
... Doing something by anmation delay you have to know when a user gets there. I added this one prop, animation trigger, when you scroll to this value, but it could take other values.
... So as the target element hits the top of the page, an animatio happens. It's the beginning of the animation and runs like normal. You can animation any old thing.
... Once you have the idea of being able to map an animation to start at a scroll point, you can take the time domain and map to the physical cdomain, so I've got a start and end value and as I scroll up and down I'm going through time. I can do that with different keyframes or different mappings.
... You can get nice timing function on scroll. Once you have this you can animation any prop. I've got a target that's alignd with the top of the element.
... One of the awesome things is b/c we know what'soin gg to happen in advance we can do this in the compositing threat.
... If you look at the apple.com website on the new imac you hit a point where it scrolls and then becomes mostly sticky, but drifts a bit.
... So the e-mail has better specifics.

florian: What I've seen is you scroll to apoint there is scrolling to a time mapping, but until you hit the end of the animation you disable scrolling.

dino: I want to add the minimum # of properties to get as many cases as possible.
... You might have 2 animations, both triggered at this point, one which allows you to scrub through time with scroll and one that switches to sticky.
... The common one is when things fly in, you don't want the to fly out when you scroll up.
... So common is you want to run each time and what happens when you skip over the trigger, like a scroll to. I think it addresses a lot of the common things. It should be completely compat with web animations. I don't think it conflicts.
... In the proposal I said this is mapping the animations timeline to scroll, but you could map to a media element. Or a more common is you have a live stream that stops with hang.
... Another thing I put on the lsit was the onion's where it says how far in the document you've progressed. We'd be able to do that with this script by saying the animation runs from 0 to 100 and it's body start and body end.

shans: What kind of prop can you animate when you use this?

dino: There is a big issue. This could have animations trigger themselves. If you animate the size of the object it's annoying, but we have that already on hover.

shans: That means you can animate the margins.

florian: It's not slower than in script

dino: Or animations already.

shans: So here the animation is synced.

dino: There are things we could do in advance that we could sync.

shans: But no guar this would sync

dino: Yes.

shans: Scroll with one value starts an animation, scroll with two doesn't.

dino: I think I need a prop that has a lot more detail. A syntax proposal with different options.

dbaron_: I like the way you do it in the e-mail better than the visual.
... What you have in the e-mail isn't clear how you map the duriation to the scroll.

dino: The animation runs from 0 progress to 1 progress. If the begin and endof my scroll is 100 pixels it's percentages.

dbaron_: The e-mail can't spec lengths in the scroll.

dino: Right. The trigger does. You're right. It's a mistake.

dbaron_: It should have scroll start/end.

plinss: So it should be on timebase.

TabAtkins: There has been discussion on this about 2 years ago. We're totally cool with this.

dino: I expect there will be a lot of itteration on syntax.

zcorpan: Is it useful to have a scroll offset, or is it more useful to refer to an element.

dino: It should accept the same as scroll elements and the calc mode. You don't want somethig to happen when the element hits the top of the screen because you don't know the height.

plinss: What about 5%. I want to make sure pixels isn't the default. It's a good usecase, but it's bad for dependant.

dino: Yeah.

zcorpan_: this seems to only handle scrolling in one direction

dino: It should be scrolling both directions. Your first question reminded me, at the moment the scroll position is to always scroll in it's current frame. So if you're in an iframe you don't want to be able to determine the position for scroll based on your document.
... You can imagine like light buttons where it could work, the syntax can get confusing. We might want to start small. I'm not trying to deal with every paralyx effect, but if we can do some things faster, that's great.

<kip> dino: Would it be possible to trigger based on direction + velocity? (Or is this best done another way?)

plinss: Common use case is like when the next button only lights up when you hit the next button

shans: As a request can we run this with JS.

dino: In animations, yes.

plinss: The time base could be user defined.

dino: It would drop you into slow scrolling.

plinss: Here's something we're defining in CSS and you can define it within CSS script.

<kip> dino: Use case would be a search bar that animates away when you scroll quickly downwards

plinss: Another use case is an animation with media and pauses when the media is buffering or the opposite.

dino: And you might want to sync the time base to an animation
... Another part of the prop once you have triggers you can add the ability to trigger an animation from another animation
... Without editing many many keyframes.
... The trigger's function syntax is good.

hober: Prior to going into animation trigger, you said something about behavior, was there supposed to be a resolution recorded.

RESOLUTION: start work on Animations 2

zcorpan_: So the directions should be x and y, or inline and block?

dino: Yes, it's logical.

plinss: We need to make sense with overflow and scroll behavior.

??: Probibly logical for it to start as you pass

plinss: I'm thinking block and inline ifyou're specifying y you might not want to say animation block. We just want to make sure it makes sense when we're done.

Bert: So how do I turn it off? What's the shortest way to disconnect
... Maybe time base auto?

dino: It's common. People don't like these pages. First they hate having so much happen on scroll, then they hate scrolling disappearing.

plinss: The discontinuity is annoying.

dino: I do not like it when I'm scrolling vertical and things move horizontal. Web authors do this stuff either way.

plinss: WE shouldn't make bad things easier.

slightlyoff: I disagree wtih that. I think you should give authors all the power.

Bert: I'm fine adding it as long as there's an easy way to turn it off.

dino: It's easy to turn it off.

plinss: I'm with you giving power and apability, but there's a fundimental part of CSS to giving the user the end power.

rbyers: Before we do specifics, a general. Over the last 6 months we've been talking to people about why they're making mobile native apps.
... one thing we've hear is that they can get a lot more touch sensitive effects. Can I project?
... So starting with scroll linked effects. People have been doing this forever, but it's urgent for us because some of our design requires this and we're having to tell people you can't do this on the web.

<rbyers> https://www.polymer-project.org/components/core-scroll-header-panel/demo.html

rbyers: This is the simpliest example. This is a simple effect with a fade and header and I think dino prop can do this. We impl today based on scroll events. A lot of demos you wouldn't notice if you weren't but on a slow device you'd notice that the scrolling isn't sync witht he effect.
... We've got a test page here. If I switch to Safari you can see it's not as sync. And on a slow phone you can really tell. dino proposal does that
... We want to get more complex. We call this hidey bars. The top controls shrink and hide as you scroll. As you scroll up the header and footer hides and if you scroll down the reappear.

<rbyers> http://jsbin.com/zosevo/3

rbyers: I think dino prop would work for this, but I think when you take your finger off the device you want it to snap.
... Here's an example (irc)
... We can do this if we listen for touch events, but we don't have anytinhg for whent he finger is off the touchpad. Maybe we can extend the prop for active scrolling and momentum scrolling afterwards.

weinig: You can consider non-novel triggers and use new triggers to start that.

rbyers: Then it gets more complex. Lots of native apps use pull to refresh. It's scroll linked, but you have to change the scroll somehow. We talked about that as scroll customization.
... We want to change the notion of scroll top and support some kind of customization for overscroll. We want to change the relationship between the input and output. In this case we have a function that applies friction.
... That's what the native apps do. On mobile Twitter did this without anyone asking them to because mobile is rich enough. I'm worried about defining CSS properties 6 years later. I think we need to be able to explain in lower level primitives so app developers don't have to wait.
... There's a few other things that make it complicated. One of the biggest is changing the relationship of how scrolling decides what to target.
... If I pull down inside the iframe it'll work as expected, but if I pull down it will move with isn't the expectation. This is hard to solve because you can't communication between iframes withs cript.
... We need something that acts as the broker between things getting inputs and things that will act.
... You need to let pull to refresh to either talk to it's decendants or ancestors.
... That's almost the most complex. What are the low level primitives, you realize other common effects are also explainable, for ex something like the scroll effect in google images, but there could be. If I fling it, should it match the native phsyics of the browser.
... Maybe I want to scroll vertically but also have browsers top hiding and showing and right now we can't do that on the web
... I think that mostly captures the scenarios. I think we'd be able to explain overflow scroll in terms of primitives and customize it. and how it handles deltas distributions.
... What's the simpliest low level thing we could add that lets us solve these schenarios and als snap points.

weinig: I don't understand explain in terms of primitives. Overflow scroll can happen in a different process.

rbyers: before scroll offers a composition API to mediate and it relies on some kind of composition.
... What I care about is the composition API. That could be JS on the main thread or a worker, maybe someone wants to come up with that in a declaritive language. Those are impl details, but if we're going to explain the scrolling we've got we need to explain the thread.
... On chrome we've done work where a highly responcive main thread where on that limted set we'd be okay losing our threaded scrolling, but I think you're saying we should aim high.

weinig: My memory is that it was historically fired but it was changed to be not that because it caused bad scrolling. The before scroll reintroduces that with a diff name, but not a different web.

rbyers: It lets you opt in.
... The a11y web says we need to put the developers in the driver seat. I think it's relevent where you can opt into having more control. I don't htink every website shouldg et ride of threaded scrolling.

dbaron: You referenced your prop, but have you talked about it?

rbyers: I think it's more useful to talk about the thigns driving it. The details are irrelevent based on these high levels. If we're having CSS APIs going through time, that's one thing. Then how would we suppoprt pull to refresh and the problems with it
... before scroll says there should be some API that takes as imput how much the user has tried to scroll and lets the app decide how that should be distributed among elements.

birtles: I think an intersection is to have a script face timline that explains main thread scrolling, but also user written timelines that only apply to elements.

rbyers: You need more than an animation timeline. This doesn't address compisition prob

birtles: I think it does. Like timing functions

rbyers: dino prop lets you control animation objects, but scroll offset isn't animationable.

birtles: Okay.

florian: It looks like rather then having content you overscroll, you can make the content expand for a sim effect, but I'm not sure it's good enough.

rbyers: Yeah, then at the boundry you're switching between scrolling and transform and the challenge is that you have to deal with switching the physics over. It gets trickier from that. We started from lets drive on a low level and we tried to aim for a perfect bar. We were using osmething like Twitter on iOS as perfect.
... The other point is what Sam was bringing up. If we hink apps should have control over that we can either let them do script on the main thread, we could empower script to run UI effects on a different threat, or we come up with some non JS language like if CSS could be rich enough. I doubt that it can be captured fully in a declaritive language, but maybe you could.
... We could also let Ian talk a bit about expalining scrolling threaded animations.

plinss: I think there's buy in to lets define the primitives. In general it's a sound principal.
... It's something we should drive for. We can argue how it's exposed.

hober: I think this isn't the place to have the arguement.

plinss: If you have a request to see the set of primitives, what are they.

rbyers: We're not far along the impl, but I already know the obj to before scroll are about the high level objects. I know tht giveing up threaded scrolling for this power isn't desireable.

weinig: Even though it was novel, the rubberbanding and friction wasn't actually novel. The primitives depend on what you're interested in. So keeping them consistent might inform your primitives.

rbyers: I think there's a good middle ground. I'd be interested in saying something like the platform defines overflow, but you can customize. We need primitives like keep this window open when the user is scrolling.

weinig: What are the primitives?

rbyers: 2 parts.

<rbyers> scroll-delay: https://docs.google.com/a/chromium.org/document/d/1aOQRw76C0enLBd0mCG_-IM6bso7DxXwvqTiRWgNdTn8/edit

rbyers: There's threads on each of these, but let me paste.
... This allows browsers to develop an API. We've changed over time what scroll should sync with and that makes it clear for us there is no prefect answer. In IE it's not with start of touch.
... In Chrome scrolling is always with start of touch, but not all touch moves. You can let author opt into the IE behavior. Scrolling is sync with wheel events. It's not clear that's right in all cases.
... I don't know if it's a major problem with scroll, but it's huge for wheel events. Maybe pages should be able to opt out and maybe we should be able to say they scroll freely.
... There's 3 poss things to block on. Start, touch, and wheel. scroll event it doesn't block on
... You could says i want my sync events with my scroll. That's the jist of scroll delay.

jrossi: The use case for disabling the delay for start touch
...: It's performance. In IE we don't have this block dependancy. The use case for making an even like scroll become blocking is these custom effects. You're choosing between fast and customizable

jrossi: This makes use think more along the lines like animations. It would le tyou get some of these effects. It's poss to build a demo of a lot of these that hits 60 frames, but I'm not sure that's reasonable for current webdev

rbyers: That's existing.

jrossi: If we can find a way like animation triggers that let you create the UI without that's goodness.

rbyers: When you say a lot of these, it's only the first where scroll would handle. It's not rich enough for the triggers or the hidey-bars. I'm just worried that every new scenario will take a few years to make a new CSS prop.

jrossi: I'm not sure we move the web forward.
... It's too easy to fall into the these are mutually exclisive. WE don't have a pragmatic way for them to play with animation triggers. So saying it needs to be a JS API because that's the only way to experiment

slightlyoff: Why is that odd?

jrossi: Becuase you can't show animation triggers doesn't make this a bad idea.

slightlyoff: I think it's proof this should go first. If you want to avoid a world where nativ apps are beating you to the punch...You need to give dev flexability.

weinig: That's not prving the point

slightlyoff: You've got the example of the apple website where they do thigns that are slow to do what they want and that's bad, but you don't have another way for them to behave.
... Dev today have a whole matrix about taking control so they use libraries.

jrossi: Even the libraries do it poorly

slightlyoff: There isn't a uniform model for doing it.

samweinig: They're doing it in a variety of places.

slightlyoff: But if you're looking at the various ways people are working, that there is no way for them to take control is the problem.

dino: You're saying because there's no standard to hook into feature,s that's what makes it slow?

slightlyoff: It makes it slower.
... The tech they've adopted may be mal-adapted for the new ways you create.
... You have evidence of this in front of you

rbyers: So if the primary obj is you don't want opeple to choose between more likely performance and control, the remaining choices are high level APIs or a primitive that explains the threaded effects.
... What we're hitting is we want a primitive that explains scrolling, but not all of scrolling. The alternative is to say if that's an important fast past and primitives are important, we need a primitive that expains that. We need customization that explains it in an extensible way.

<TabAtkins> ScribeNick: TabAtkins

volick: This example [on screen] is half-baked, but it's to illustrate a point.
... If we could find a way of exposing the knobs that threads turn, and expose it to JS, then next time one of these situations shows up, authors can do things directly.
... [tries to get the demo working on the projector]

<adenilson> the demo gods must be angry...

volick: [demo shows some things spinning jankily, others spinning smoothly]
... For the smooth things I'm twiddling the knobs in a special worker-like thing; the janky ones are on the main thread.
... [shows example code]
... What I've done is bind opaque identifiers to these knobs...
... Let me show you main-thread code first.
... I find elements, bind some animated proeprties. This is declarative, so the UA can figure out what you're doing.
... Then these get pushed to the UI Worker, which is a special worker that lives on the compositinig thread.
... I pass it the tokens for the animated properties, get back an "animation context" that lets me adjust these properties.

rbyers: Since it's on the compositor, when you ask for the current scroll position/etc, you get the exact correct value, not something that might be delayed relative to what's on screen.

volick: Of course, this does give the possibility of people doing badly.

dino: So when you set scalars like that (in the UI worker), you're not setting properties directly...?
... You set transform because it's easy to do on compositor. What about background-color?

volick: There's a subset of elements.

dino: If you set transform there, are you actually setting the transform style on the element?

volick: Yes, but not synchronously. It's plumbed back.

dbaron: So this requires standardizing the set of things that happen on the compositor thread.

volick: It's not necessarily true that the UI worker must run on the compositor thread.

dbaron: What if one of these workers animates transform and background-position? Chrome animates both on the compositor thread, Firefox animates transform only, bg-position on main thread.

volick: Intent is that you identify the properties that are definitely on compositor thread; you'd add judiciously.

dbaron: I'm more confortable if we agree here on standardizing that list here, rather than just starting with Chrome's set.

volick: Sure.

dino: We sometimes composite based on different state in the page.
... Might not always be consistent.

<dael> TabAtkins: I suspect it's possible to come up wtih a thing up front where its eq to coming up with a JS. In that case we wouldn't have to worry about a combined list and it would run acceptable in anyting that doesn't composit. It would make perf testing hard.

weinig: That sound slike it would make it harder to perf test your site.

???: I think this has the same risk as dean's proposal, in that the input to the animation is limited to what you define as the input to your compositor.

benjaminp: You'll be able to use more operations on the input, so it's a bit more powerful than a pure declarative solution...

rbyers: Ian's API does need more than just scroll offset, but it's about more than just inputs; it's about how you process them.

volick: If you'd still like the browser to be the broker for composing these things, yu could make a variant of beforescroll that is done on the compositor.
... Byn forcing hte author to express their intent very clearly, it lets the UA prepare in ways that you can't do with rAF.

smfr: Do you have a sense that the stuff you can change in UIWorker is enough to do hideybars/etc?
... I think that font-size changes, for example, might be desirable in scroll things.
... I think we'll end up with people doing very complex things in their UI worker that they could have done in CSS.

rbyers: I think UI Worker isn't trying to solve every problem. You can just animate normally.
... The scenarios we're tyring to copy today, though, are fast on native apps for a reason - they don't do font-size changes, etc. They take advantage of GPU rasterization, etc.
... We think all the scenarios we've talked aobut can usually be done without rasterization.

dino: So in your example where the text got smaller, it was a transform, not a font-size?

rbyers: Yup.

dino: So I think there's a nice path from your proposal giving complete control, while the CSS one does less powerful things, but makes it even simpler.
... I like the idea of investigating this UI Worker.

MaRakow: I'm curious to see if there's a way to allow the other properties to be modified, but you lose guarantees on how synchronized they are.
... Even some of the parallaxing effects, they aren't too noticeable if they're not perfectly synchronized.
... I'd like to see more detail on yoru pull-to-refresh.
... Want to see a way to do an off-thread "drag this element around the page", or an element with zooming control.

rbyers: Yeah, touch position is a likely input.

MaRakow: I think you often want to plug back into native behavior, too - native inertia, native rubber-band effect, etc.

rbyers: Taht's a good segue into beforescroll.
... Note that this isn't about opposed ideas. scroll-delay lets you do anything on the main thread, with sync. UI Worker lets you do some things on the scroll thread, with sync.
... beforescroll lets you just intercept scrolls - you get an event when there's a "scroll intention" from the user.
... Then you can tell the browser to execute a scroll natively.

???: I'd like to see some evolution of the UI Worker proposal, based on the examples you brought up.

???: Is this new thing going to have arbitrary dom access, for example? Or just some limited information?

volick: I have some half-baked ideas on that.

rbyers: Yeah. There's an incremental path here.
... Even without the advanced scenarios like pull-to-refresh, we can do a lot of good. We don't need to block.

volick: Also useful to talk about the palette of knobs you might be able to turn.
... If you can raster fast, maybe you can do colors or font-size.
... Worth chatting about that.

birtles: Maybe define a transform function taht takes a scroll input and outputs a scroll output?
... You can run that on either thread as you need to. You can use the same architecture as the animations.
... Then I think there's a path between dino's proposal and this.
... As we find effects that are commonly used, we can mash those up and prepackage those as we need to.

volick: I'll have to think a bit more on that.

<MaRakow> also want to make sure my apprehension is noted in the minutes -- I'm interested but want more details

<dael> ScribeNick: dael

rbyers: someone asked for the details of beforescroll before. Is that worthwile.

dbaron: I think tis' useful to go into the detailes before it's too late to change..

smfr: Can you summarize?

rbyers: Let me project. Here's the link.

<rbyers> beforescroll proposal: https://docs.google.com/a/chromium.org/document/d/1oEVWIVdMZ2OlVZMvcZZ3IgaT6RAUNSKAzpzb9AlVeLw/edit#heading=h.kd0gtwwz5bf9

rbyers: Right now this is in terms of DOM event, but the high level concepts are most interesting.
... Let me get the diagram. We looked at our scrolling architecture.
... You can debate on details, but our chromium archetecture and abstract the key boxes where the dev has say.
... There's 3 input stacks and the boxes that are red are extensibility points where apps can plug in.
... Out of that we think conspetually, internally we have gesture events that drive the scroll. It's the scroll intention.
... Then tehre's a phase where we take the objects and pass them up through the containing blocks. That maps to native UI apps.
... The idea was to give a hook that's like overriding the native view. That could be a DOM that fires beforescroll event. I could re impl overflow scroll by saying I have a div that listens to beforescroll events.
... The key thing is they have deltas and a method with how much the want to consume. It has a delta y of 50 and I scroll veritically so I call that and say I want to consume them. So beforescroll would bubble up and it would be seen by the outer scroller that would apply it's delta. It comes down to details of diaginal scrolling.
... We need to support where a user is dragging diag.
... There's some that expose missing pieces like velocity of scroll.
... Some kind of info about the phase of the scroll yo're in

MaRakow: Is control delta used anywhere else?

rbyers: Anyone using before scroll. Some of these just need sync, but anything using beforescroll.
... We havea version similar to pull to refrest where there's an overscroll and the image zooms out a bit. So in that case yu'd need scroll customization. Also just the image search case.
... In that case you're replacing the scroll yourself. You've just got a reg div which wouldn't normally controlt he scroll. When we see the user trys to control on top we use a transform.
... But if they get to the beginning and scroll more we need it to bubble out. Any time you need to cusomize you have to invoke consume delta.

MaRakow: It seems you're trying to emulate elastic

rbyers: Not just that. If you think of a normal scroller, there's some code that says the user wants to scroll, how much can I scroll by? In other methods that's exposed to the developer.
... That's not just about getting past the limits. There's a difference by asking to scroll and what you can scroll by

dbaron: So pull to refrest, do you agree to scroll more than normal allowed?

rbyers: It's less b/c friction.

dbaron: You're doing it by setting transforms. You have initial scroll and have content above that top. Do you do that by placing content above or play with transforms?

rbyers: Either.

dbaron: So you can scroll to a negative offset. Right now our natives croller doesn't support that. But it's reasonable to have that.

dino: For rubberbanding you'd consume all the scroll deltas, inverse translate in the non-scroll, how do the next scroll events relate to the change? If you move the element?

<dbaron> the last dbaron: line was rbyers:

rbyers: deltas are the inputs. The deltas come from the input.

florian: So you've scrolled past the limit and then you generated scroll events?

rbyers: A lot of this is handled as a before scroll event. The browser has an overflow scroll div and it should be indistinguisable from one from JS.
... There might be security concerns. There might need to be a trusted bit, but that's ortoginal.
... So we tryied to recast our funky scrolling, such as the rails for scroll or overscroll effect at the end, we tried to desc those in terms of beforescoll. If we're right about design we could swap impl and we can take scrolling from the rendering engine core and re impl all the effects we've got. We'd do demos to prove to ourselves it's possible.
... I think that's the briefest high level overview I can give.

plinss: We have jdaggett calling back in again soon. Anything else on this?

dbaron: What's next?

rbyers: The group wants more details about UI worker. I think we need to get those in shape and send.

dbaron: I think you've sent some stuff on beforescroll.

rbyers: And scroll delay. One challange for us is if we feel we can afford to wait for UI worker to support this.
... WE feel some urgency, so it's poss that Chrome may procceed with our main thread idea

dbaron: I'm not the authoritative person at Mozilla for this, but I think roc sounded positive.
... I don't know.
... Some depends on the state of other browsers. I don't think it's useful end result to only have two browsers impl something.
... Because webdev can't use it

slightlyoff: That's the position they're in now.

rbyers: A bunch of the effects take advantage of this across different browsers.
... I guess I would agree with slightlyoff that there might be value in allowing apps to do this

dino: There's value if browsers do things awesome.

rbyers: There's also value in the browser doing something horrible and depricating it.

slightlyoff: They (web dev) were at least able to ship to users with that browsers.

bkardell_: If you're cleaver you can ship to all browsers.

rbyers: There's one sight that relies on Chrome, but on Safari you get a bar on the top that says install our native app.
... I don't think it's bad to allow those choices.

dbaron: Where i was going is it may be worth it to get these in a draft somewhere. It's worth talking about. I don't want to see it dropped because you thought no one liked it. We should follow up.

plinss: Okay. Anyone in touch with jdaggett?

dbaron: He's on IRC

<jdaggett> here

<dbaron> jdaggett, ^

<jdaggett> :P

<jdaggett> ok, dialing in now...

<jdaggett> "the conference is restricted at this time"

plinss: Let's get back to John, I guess.

<jdaggett> ok, in 26631 now...

<jdaggett> lonely here...

<dbaron> jdaggett, did you misdial?

<dbaron> jdaggett, try again?

<jdaggett> kk

plinss: We have snap points.

fantasai: jdaggett Is here, just need to connect.

plinss: Other conference ends in 5 min, so let's have Zakim time out.

<jdaggett> "you are the first participant in this conf"

<jdaggett> argh...

<jdaggett> which conf are you in?!?

<dbaron> jdaggett, we're going to try again in 5 mins

plinss: I don't think we have a choice. We can let Zakim time out and then get jdaggett.

Snap Points.

<jdaggett> plinss: ok

<adenilson> is it just me or is it a bit cold in here?

MaRakow: I updated the spec, roc had some responces, I wanted to see if there was concern about my edits.
... If not I'd liek a FPWD.

<smfr> http://dev.w3.org/csswg/css-snappoints/

MaRakow: For anyone that haven't looked at the edits, I've removed most of the requests for new functionality that doesn't exist in a browser.
... I need feedback for name of snap-coordinate and snap-destination.
... Those are the main topics.
... I wanted feedback.

smfr: I haven't caught up, but were there responces to hober e-mails?

MaRakow: I don't think I have anything about that. I'd say no because our impl doesn't include implicit steps.

smfr: So there's content you can' scroll to without snap points?

MaRakow: Which is intentional.

smfr: We have things were at the end you want the last element on the right edge and the scroll element is stuck. I'm not sure if that use case works.

<dbaron> jdaggett, try dialing again

MaRakow: Could merge element and interval snap lists. You can merge an interval and element snap points.

smfr: We'd prefer repeat with an extra place go to the end.

<jdaggett> ipcaller is me

smfr: Two other areas that are under spec. One area was how do you transition between scrolling gesture and animating to a snap point.
... That can get weird if you have to go back.

MaRakow: That was intentionally underspec. The dynmaic point is on a snap point. That's partly for when you don't have an animation and also to allow freedom.

smfr: So like if you're going fast and want to skip the nearest point.
... I don't know if we need that specified.
... Also exactly how proximity works.

MaRakow: Again somewhat one purpose. I think the heuristics are best for UA. It's going to be soft and should break anything. I think it's best unspecified.

smfr: Maybe errors that you want to avoid you can leave a note in spec.
... Final thing. If the user isn't scrolling but the snap points change, do you adjust?

MaRakow: I added that. Manditory that you must update to land on a snap point, optional for prox.

fantasai: One this I want to make sure is handled well is varying screen sizes. I think someof your examples would work if it's smaller than screen, but not if bigger.
... If you have a mand snap point in the middle, but you're on a smaller screen than picture, you can never see the whole thing

MaRakow: I think that's where it would be inappropriate to madatde scroll offset.

fantasai: You want to mandate it lands on each picture.

MaRakow: You want the user to scroll to the end and not snap.

fantasai: People design for one screen size and don't think about smaller. Whatever we're designing here if they do't think about it they get something appropriate.

MaRakow: My take is that you still don't want to use manditory.

fantasai: The person designed stopping on each picture. They didn't think about my small screen. We enabled something that degrades badly. Degrading well is better.

MaRakow: I don't know if there's a solution to that.
... It's part of responcive design is you need to be aware of small screen.

fantasai: I'll review the draft, but in general we should consider that.

MaRakow: The notes I took were adding implicit snap points on start/end of the scroller, maybe as a repeat function option
... Specing the ability to travel past multiple snap points with interital
... And adding something about screen size.
... So can we do FPWD

RESOLUTION: publish FPWD of snap points

plinss: Anything else on that?

Text

fantasai: Okay.
... Let's start with justification.
... I'd like jdaggett comments
... Text justify auto when the content is untagged. How do we deal with conflicting Korean and Japaese?

jdaggett: Better language tags.

fantasai: And for the default?

jdaggett: So you don't know what the language is?

fantasai: Yes.

jdaggett: It's not idea because JApaense content in an English browser won't show the right way, but it's justification. I'm not sure how critical it'll be.

fantasai: In general we try and not use locale.

jdaggett: It's not optimal, but it's want impl do today.

fantasai: So if I have Mozilla with untagged Japanese in a Japaense location it uses CJK spaceing?

jdaggett: That would depend. I know Japaense font selection we do sniffing of lcoal

fantasai: Not for justification, I don't think. Given that we don't do it we shouldn't start.

jdaggett: There's a lot of things, ie line breaking, where it's untagged and we use locale.
... I'm not sure. Auto is a catch all. What needs to be defined?

fantasai: We were asked for an ex of justification algo that shows off here's what you could do if you need justification and have not additional information.
... We want taht same for most lang.
... Korean wants to expand spaces, but not between Han. Japaense wants not space expanding, but wants at Han.

jdaggett: Is that the case for auto? Are you talking justify: auto?

fantasai: Text-justify: auto
... If they're using distribute they get spacing everywhere. If they spec lang tag they get the right thing. the case with problems is it's untagged and auto. Somebrowsers don't do any spacing in Japanese. Others are like let's justify between Han and Hanna and that looks weird for Korean because hopefully no one will notice since they don't use a lot of Han.
... Those are the two things impl. Another option is 2 level of priority. Expand at spaces if they get too wide and then expand betwee CJ and K.
... Those are the three options. I can put them all in the spec, or jsut one of them. I'd like to close on this today so we can go forward.

stevez: jdaggett sniffing makes sense. If you have Hangul you should do your Hangul thing. That would get us away from suboptimal solution.

fantasai: I don't want to sniff locale. That gets web designers to think teir webpage looks awesome.

jdaggett: This is sort of a none-issue. We can infur from the script.

fantasai: We haven't been doing that. If impl want to do sniffing, I can put that in the spec.

stevez: None of the three answers are good. They're all bad. There's a poss of being good in all cases if you sniff.

florian: How much do you sniff? t's not picking the wrong one, bt it's being unstable.

stevez: These are doc without lang tag. If you want it to work, lang tag. I understand you're saying people won't lang tag if it looks good.

jdaggett: I don't understand why a normative algo is important.

florian: but you'd get where my website looks fine and then you switch and it breaks.

fantasai: We have a non-normative algo that we're supposed to put in. Normatively we only have a handful of req.

jdaggett: For uato I'd suggest that if the lang isn't see, see if it can be inferred from the script. Just put that as a suggestion

fantasai: It's up to impl. The feedback I was given earlier were we don't want to sniff. If people feel differently now that it's 10 years later, I can do it. But tat needs to be consensus.

stevez: Last discussion is there is not algo that works well for both Korean and Japanese without a lang tag. We can pick one that doesn't work for a language and we end up in a bad situation where we icked a language, or we can do the simple sniffing thing.
... In the cases we care about, you'll see soon what language. If it's all Kanji, you can do a good job.

florian: Sniffing gets you unstable. You see Chinese and get more content and you see diversity. Nothing is great so we have to accept some suckage.

fantasai: I what to hear from dbaron because he's wanted more details on auto

dbaron: The kind of details I wanted auto to ave are the kind that avoid saying hey browsers impl you do the research on the right behavior for all these languages.
... I think if, If you know the right behavior for tagged and if you want to say the behavior for untagged isn't defined, that better than not defining the correct behavior. You're defining where is the thing you should do for each language.

fantasai: We can't put that normaively in thie doc.

stevez: You have what's normative for tagged.

fantasai: We don't.

stevez: that was the wiki?

fantasai: Yeah. What's normative is for auto justification. [cites spec]
... There's some discussion about if Chinese and Japanese, Kana Kani andHangul should be the same within a line or diff and we've had some feedback from Japan that they want differently.
... So we need a "what works"
... We can add a link to a doc to what we think is right for this small handful of script and good luck for the rst.

r12a: Yo have Japanese, we're working on Chinese and Mongolian. We can get more. I wouldn't have thought you needed to spec all Japaense layout in a CSS spec.

dbaron: Or refer to it. I don't think it's reasonable to expect original research on hundreds of lang. the requirements should be in or linked to.

fantasai: I think we don'thave requirements for lots of languages.

dbaron: So it's not in this level of the spec.

fantasai: It should all be in a note.

stevez: That was the purpose of the wiki to allow contribution without us vetting.

fantasai: If you're happy for us to have what we know about this handful of lang, if that's sufficient I'm happy to put that in the spec instead of an ex of a default.

dbaron: What I wasn't okay with that is that I felt what sed to be there was saying you had to do original research I'm fine with that.

stevez: Do we have a location we can point to.

fantasai: I think we can do that through i18n WG.

stevez: Your, r12a =, doesn't specify that. I thnk it points to JL rec. The generic site.

r12a: That points to JL rec.
... We can talk about it.

stevez: Maybe as a joint project. So I'd object to saying they're req or normative, tey're information that would allow people to do a reasonable job. The question is how do you do interop testing

<r12a> https://www.w3.org/International/wiki/Improving_typography_on_the_Web_and_in_eBooks

stevez: Some people would have practitioners that wuld allow them to do better. The JL are one set, but not the only set. That's why Adobe tabled a bunch of the things like spacing and line breaking

<r12a> https://www.w3.org/International/wiki/Improving_typography_on_the_Web_and_in_eBooks#Alignment_and_justification

fantasai: Yeah. We have some normativ req so what we can test are what I read out. We can test if it's just if one op is there.
... You can test that that first character ended up on ths end, that's the mose we can do.
... If that works for people I'm hppy o not put in a suggested algo.

florian: If we end up not defining that's fine. We shoucareful about opening the door. People who worked on encodings found content sniffing was not a good idea. The situation is a different.

stevez: It is different b/c rules are tied to script. The amount of sniffing to hit 90% is not much. You may get errors and you say please language tag it. I would propose tht you add that browsers may snift hte script to suggest which rules to use.

r12a: The other possibility is that we allow it to be broken if you don't spec the lang on purpose.

florian: The problem is legacy content. For new things that's a great idea, but there's legacy out there.

dbaron: That's what we did for hyphination. We said auto doesn't work without lang spec.

fantasai: Mozilla just does spacing.

dbaron: It's conditional if it's language Chinese or Japanese which comes from local, tag, or inferred from content. If our best guess language when we have to come up with a language comes to Japanese or Chinese, we use different rules.

fantasai: There was explicit lang, char set, and locale.

dbaron: The http header falls in there.

<jdaggett> plus accept-lang http header

stevez: Maybe the right thing to say is UA impl may use what information it has about the language in determiniing the spacing rules.

<jdaggett> wildly different?!? cmon...

fantasai: The one that that will be tricky if you'll get diff results depending on what the UA thought the lang was.

stevez: Than I agree with florian that we're trying to encourage lang tag.

fantasai: But if it's user generated or only works on the one page they checked, some will fail, but you're like oh it looks great here.
... I'd like to not do content or locale sniffing. Those are most likely to cause accidental breakage.

florian: What would be the correct way to deal with you're writing a web mail client in Japaense and get a plain text Korean message?

fantasai: You don't justify plain text e-mails

r12a: It's only confusable with Japanese if using Hanga characters. Korean is only confusable with the Hanga character and they're few and imbedded into Hangul in that ex. It's more difficult with titles in Japaese, but that's a limited amount of text.

stevez: And those aren't typically not justified.

fantasai: They might be.

plinss: We're about out of time.
... Are we finding common ground?

fantasai: I think we don't need an ex algo in the spec.

dbaron: It would be nice to not lose your research.

stevez: We should create the wiki with your information.

bert: And it would be nice to turn that into a note

stevez: It's informative.

bert: But a date on it.

murakami: I have a question. I think most people will be happy if lang is not specified, Hangul is inter word justification, and others (Japaense and Chinese roots) are intercharacter

fantasai: It's awk for Korean with Hana in it because you have spaces in the middle of the word. So imagine if you had spacing around each side of Kanji.

murakami: The lang attr should be spec. If it's not specified the optimized justification cannot be expected.

florian1: We're allowing but not requiring.

fantasai: Question is do we put it in the spec. I can put algo examples in the spec.
... They're all acceptable options. I can put them into spec if it's useful.

florian1: To be clear I don't think we have consensus on what you're not allowed to do. It's not obvious that we're agreeing.

fantasai: I'm not sure of compat impact.

dbaron: I suspect that location would be bad for Japanese content.

fantasai: Does Microsoft sniff?

ArronEi_: I don't believe so.

Rossen_: I don't believe so. I have to check.

fantasai: Lets do some testing. If IE does not justify Japanese when it's untagged using the local to do that, we might say to do tht.
... We can come back in a few weeks after all the edits have been made.
... one complication with backcompat is some browsers honor text-justify: interideograph. WE dropped it but docs that spec that will expect to be justified. It will be justified in Microsoft because the support and Mozilla because the sniffing.

hiroshi2: A character, sniffing for local. In an exteme case, the text exits, how do you sniff that and what justification algo should be applied?

fantasai: So we were suggesting sniffing local, so I have american flag, so it says because my computer I will jsutify like English. You don't look on text, but rely on operating system.

florian1: That's another option.

stevez: If you can't guess what it is by looking at character you go back to the default set of rules because no matter what it won't look good. From where I'm sitting the goal would be do a large portion of the existing archive in a way that won't surpirse the users of that archive.

dbaron: Why are we specifing this stuff?

florian1: Are there things we can agree to not use, tt's what I talked about.

??: I'm not sure I agree to use lang tag. The likelyhood a template uses lang=en is pretty high.

fantasai: Justification isn't disruptive if you don't do it correctly.

jcraig: So it's fine for justification, not determining accruate lang.

florian1: It's hard to get anythign better.

fantasai: It also incetivises doing it correctly

r12a: And people tag correctly a lot more. That's not the case anymore. But the other arguement is true where if it's notworking, you figure out why and change the lang.

zcorpan_: In HTML there's a rule to det the language and it first looks at lang. Then there's a step that looks at content language. Step 3 is HTTP header.

dbaron: It feels like we'e expanding this discussion instead of solving our problem.

stevez: So we drop trying to resolve allowing or forbiddig and just go witht e text dbaron can live with and so can fantasai. That resolves for now and there's work to do, but not on the doc itself.

<zcorpan_> https://html.spec.whatwg.org/multipage/dom.html#language

r12a: I'd like to see tests to see what happens on the browsers. I'd like to help create those tests.

fantasai: We can talk about those during i18n.
... So either don't put an example of a justification algorithm or put multiple examples.

jdaggett: I think if you put one, it has to be real world and not made up.

fantasai: I'm talking algo, not text.

<jcraig> s/??: So it's fi/jcraig: So it's fi/

fantasai: Once we can put in is the one murakami_-san mentioned.

stevez: I'm okay with multi, not with one.

plinss: Okay with none?

stevez: I am on the basis I'd like to see us establish a site where we can put the information in. It's informative information.

fantasai: Is there a preference between none or multiple?

florian1: As long as the multi are somewhere, I don't care where.

dbaron: Either option comes with a link to the wiki?

<jdaggett> the examples should simply highlight good choices :)

fantasai: Yes.

dbaron: I'm fine with either.

stevez: None and a wiki link

<jdaggett> single or multiple is not as important as them being good...

RESOLUTION: No examples of justification algo for text-justify: auto, link to a wiki or note desc language specific conventions

<Bert> (Fantasai's white board text: 1) Lang tag; 2) Content-Language HTTP header; 3) System/OS locale; 4) Content sniffing; 5) Charset)

plinss: Is that it?
... Thursday there's joint with digipub in the morning and SVG in the afternoon. There's also a18n in the morning

fantasai: Friday morning.

dbaron: Can someone put times on the wiki? The top and bottom of the wiki disagree.
... Come Thursday I'm jsut going to look at the wiki.

plinss: We'll fit it.
... We're adjorned.

[end of meeting]

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/glenn/glazou/
Succeeded: s/krit:/dino:/
Succeeded: s/??/BenPoulain/
Succeeded: s/Goblieski(?)/Mogilevski/
Succeeded: s/elika/fantasai/g
Succeeded: s/folling/following/
Succeeded: s/Roseen/Rossen/
Succeeded: s/::role/:role/
Succeeded: s/colen/colon/
Succeeded: s/Micrsoft/Mozilla/
Succeeded: s/ArronEi/astearns/
Succeeded: s/astearns/astearns and I/
Succeeded: s/two /pseudo-/
FAILED: s/stack/stash/
Succeeded: s/Media//
Succeeded: s/bkardell_ /vollick/
Succeeded: s/author you want/author you may want/
Succeeded: s/only language/only language-dependent/
Succeeded: s/morimoto/murakami/
Succeeded: s/That/:visited/
Succeeded: s/all hangul/old hangul/
Succeeded: s/got/god/
Succeeded: s/rbyers/r12a/
Succeeded: s/??/bobtung/
Succeeded: s/flats/slabs/
Succeeded: s/auto than/auto then/
Succeeded: s/frames/iframes/
Succeeded: s/set?/set./
Succeeded: s/anti-aliasing/anti-aliasing, it's a preference/
Succeeded: s/I don't/When I'm on mobile Safari I don't/
Succeeded: s/care/care about loading the font for 60 seconds/
Succeeded: s/and want/I just want/
FAILED: s/bkardell_ /birtles/
Succeeded: s/a time base/timebase/
Succeeded: s/aniation/animation/
Succeeded: s/x and y/x and y, or inline and block/
Succeeded: s/??/slightlyoff/
Succeeded: s/rick/rbyers/
Succeeded: s/???/weinig/
Succeeded: s/???/weinig/
Succeeded: s/bkardell_/birtles/
Succeeded: s/???/jrossi/
Succeeded: s/??/slightlyoff/
Succeeded: s/jrossi/samweinig/
Succeeded: s/???/benjaminp/
Succeeded: s/??/smfr/
Succeeded: s/Rok/roc/
Succeeded: s/it's/let's/
Succeeded: s/distribute/auto/
Succeeded: s/sites/cites/
Succeeded: s/computable/confusable/
Succeeded: s/florian/bert/
Succeeded: s/??/hiroshi2/
Succeeded: s/??: So it's fine for justification, not determining accruate lang./jcraig: So it's fine for justification, not determining accruate lang./
FAILED: s/??: So it's fi/jcraig: So it's fi/
Succeeded: s/if it's not specified and Hangul is spacing justification. And/if lang is not specified, Hangul is inter word justification, and/
Succeeded: s/it optimizes the justification and it cannot be expected/the optimized justification cannot be expected/
Found ScribeNick: dael
Found ScribeNick: TabAtkins
Found ScribeNick: dael
Inferring Scribes: dael, TabAtkins
Scribes: dael, TabAtkins
ScribeNicks: dael, TabAtkins

WARNING: Replacing list of attendees.
Old list: SantaBarbara dholbert
New list: SantaBarbara jdaggett


WARNING: Replacing list of attendees.
Old list: SantaBarbara jdaggett
New list: SantaBarbara +1.778.785.aaaa kgilbert


WARNING: Replacing list of attendees.
Old list: SantaBarbara +1.778.785.aaaa kgilbert
New list: kgilbert SantaBarbara jdaggett

Default Present: kgilbert, SantaBarbara, jdaggett
Present: kgilbert SantaBarbara jdaggett

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

Guessing minutes URL: http://www.w3.org/2014/10/28-css-minutes.html
People with action items: 

WARNING: Possible internal error: join/leave lines remaining: 
        <bkardell_> vollickhas joined #css



WARNING: Possible internal error: join/leave lines remaining: 
        <bkardell_> vollickhas joined #css



WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)