#css IRC Log


IRC Log for 2012-08-15

Timestamps are in PDT.

[00:03] * tantek has joined #css

[00:31] * myakura has joined #css

[00:34] * myakura Quit (Ping timeout)

[00:49] * glenn Quit (Client exited)

[00:57] * drublic has joined #css

[00:58] * tantek Quit (Quit: tantek)

[01:49] * glenn has joined #css

[01:53] * glenn Quit (Ping timeout)

[01:59] * heycam is now known as heycam|away

[02:00] * jarek has joined #css

[02:00] * jarek Quit (Quit: jarek)

[02:05] * macpherson_ has joined #css

[02:06] * macpherson Quit (Ping timeout)

[02:15] * macpherson__ has joined #css

[02:16] * macpherson_ Quit (Connection reset by peer)

[02:17] * macpherson_ has joined #css

[02:19] * macpherson__ Quit (Ping timeout)

[02:21] * miketaylr Quit (Quit: Leaving...)

[02:28] * macpherson__ has joined #css

[02:30] * macpherson_ Quit (Ping timeout)

[02:32] * myakura has joined #css

[02:35] * myakura Quit (Ping timeout)

[02:50] * glenn has joined #css

[02:53] * myakura has joined #css

[02:53] * glenn Quit (Ping timeout)

[03:00] * myakura Quit (Client exited)

[03:50] * glenn has joined #css

[03:54] * glenn Quit (Ping timeout)

[04:06] * leaverou has joined #css

[04:11] * decadance_ Quit (Quit: leaving)

[04:12] * decadance has joined #css

[04:33] * leaverou Quit (Quit: leaverou)

[04:51] * glenn has joined #css

[04:54] * glenn Quit (Ping timeout)

[05:28] * Zakim excuses himself; his presence no longer seems to be needed

[05:28] * Zakim has left #css

[05:29] * shepazu has joined #css

[05:39] * leaverou has joined #css

[05:43] * leaverou Quit (Quit: leaverou)

[05:52] * glenn has joined #css

[05:55] * glenn Quit (Ping timeout)

[06:26] * myakura has joined #css

[06:52] * glenn has joined #css

[06:56] * glenn Quit (Ping timeout)

[07:00] * jet has joined #CSS

[07:05] * arronei_ has joined #css

[07:10] * miketaylr has joined #css

[07:11] * arronei_ Quit (Quit: arronei_)

[07:11] * miketaylr Quit (Quit: dflk;adfslkj;alsiekfj;laiskdf)

[07:11] * miketaylr has joined #css

[07:21] * jet_ has joined #CSS

[07:24] * jet Quit (Ping timeout)

[07:24] * jet_ is now known as jet

[07:34] * jet Quit (Quit: jet)

[07:46] * jet has joined #CSS

[07:46] * glenn has joined #css

[07:47] * tantek has joined #css

[08:03] * krit has joined #css

[08:19] * tantek Quit (Quit: tantek)

[08:23] * jet_ has joined #CSS

[08:25] * jet Quit (Ping timeout)

[08:25] * sylvaing_away is now known as sylvaing

[08:26] * jet_ is now known as jet

[08:32] * jet Quit (Quit: jet)

[08:32] * jet has joined #CSS

[08:39] * glenn Quit (Client exited)

[08:42] * dbaron has joined #css

[08:51] * florian has joined #css

[08:52] * glazou has joined #css

[08:53] * Zakim has joined #css

[08:53] <glazou> RRSAgent, make logs public

[08:53] <RRSAgent> I have made the request, glazou

[08:53] <glazou> rrsagent, this meeting spans midnight

[08:53] <RRSAgent> ok, glazou; I will not start a new log at midnight

[08:55] * glenn has joined #css

[08:56] * lstorset has joined #css

[08:57] * krit Quit (Quit: Leaving.)

[08:59] * SteveZ has joined #css

[09:00] * TabAtkins_ has joined #css

[09:01] * cabanier has joined #css

[09:10] <TabAtkins_> ScribeNick: TabAtkins_

[09:10] <TabAtkins_> Topic: Prefixing Policy

[09:10] <glazou> Topic: Prefixes

[09:11] <TabAtkins_> dbaron: I thinkt he first thing is that we shouldn't think of it as a prefixing policy, but rather as an "experimental features" policy.

[09:11] <TabAtkins_> dbaron: Because the right solution may not involve prefixes.

[09:11] <TabAtkins_> Topic: Experimental Features Policy

[09:11] <TabAtkins_> florian: Two rpoblems with the current policy.

[09:11] <TabAtkins_> florian: There's no clear good way for authors to use it.

[09:11] <TabAtkins_> florian: And not even just clear - I think there's no good way at all.

[09:12] <TabAtkins_> florian: A common "best practice" is to list all the vendors followed by the unprefixed, which lets you write your site and forget about it.

[09:12] * Ms2ger Oh dear

[09:12] <TabAtkins_> florian: This matches most author's workflow.

[09:12] <TabAtkins_> sylvaing: Until we renamed things.

[09:12] <TabAtkins_> florian: Yeah, but if we dont' change things, that works.

[09:12] <TabAtkins_> tantek: I think your first statement was flawed.

[09:12] <TabAtkins_> tantek: I think that "making it work" isn't necessarily something the WG should be committing to, if it's experimental.

[09:13] <TabAtkins_> florian: There is no good way to use these, so people use them in bad ways.

[09:13] <TabAtkins_> glenn: Modernizr helps make this less painful, right?

[09:13] <TabAtkins_> tantek: This is why I think that David's way of reframing the problem is useful.

[09:14] <TabAtkins_> florian: the things that we consider "experimetnal" are being used.

[09:14] <TabAtkins_> florian: And with the current way we prefix things, there's no good way to use it, thus they do it in bad ways.

[09:15] <TabAtkins_> glazou: Note that when browsers introduce a new experimental feature, they don't say it as an "experimental" feature - it's just a feature!

[09:15] <TabAtkins_> glazou: "Now you can do border-foo!"

[09:15] <fantasai> sylvaing: Authors are using it because it's in production releases

[09:15] <TabAtkins_> florian: This is true, but I think we should be careful about drawing conclusions from it.

[09:15] * tantek has joined #css

[09:15] <TabAtkins_> florian: If we refrain from shipping too many half-ready things, we get around the issue, but we harm the competitivity of either the browsers doing it, or the platform as a whole.

[09:16] <TabAtkins_> tantek: I think that Daniel's point is important, and calls to attention that we don't just have experimetnal features, we also have vendor-specific features, that are being shipped.

[09:17] * krit has joined #css

[09:17] <TabAtkins_> tantek: And the vendors are saying "you can use this, because we will support this". And this is a different class of problems.

[09:17] <fantasai> sylvaing^: Is it really experimental if we have multiple browsers shipping interoperable implementations?

[09:17] <TabAtkins_> tantek: Sometimes vendor-specific features are loved by we bauthors and then the WG has to figure out how to spec it, and that's similar to experimental, but usually they're separate.

[09:18] <TabAtkins_> florian: I want to be careful about calling these things "vendor-specific". If apple introduces something that is meant to write the UI of itunes, or Moz introduce something meant for the UI of Firefox, etc., this is vendor-specific.

[09:18] <TabAtkins_> florian: But if you write a feature that you have no particular intent to share with other brwosers, but you serve it from arbitrary web servers to arbitrary brwosers, this is not vendor-specific.

[09:19] <TabAtkins_> florian: Opera has no reason to try and implement the things for iTunes, but it needs to implement the things used on iPhone, because they're exposed.

[09:19] <TabAtkins_> tantek: I think that problem has been previously characterized as "once you'veleaked it to the web".

[09:19] <TabAtkins_> hober: canvas, for instance.

[09:19] <TabAtkins_> tantek: Once you've leaked it, you can't take it back.

[09:19] <TabAtkins_> florian: For those things that aren't meant to hit the web at all, it's fairly easy to define the policy for them.

[09:20] <TabAtkins_> hober: A bit difficult, because there may be an initial use for a proeprty - it's specialized for a certain client - but after they work with it, it turns out to have general applicability.

[09:20] <TabAtkins_> hober: So I think it'll prove difficult to use a different mechanism for the two cases.

[09:20] <TabAtkins_> florian: I think that if something's not meant for the web, it just shouldn't be exposed to the web at all.

[09:21] <TabAtkins_> florian: If you later think you should expose it to the web, you can flip that switch later.

[09:21] <TabAtkins_> florian: If you have a context switch that lets you hide it from the browser when it's in "web mode", we'd avoid a lot of issues.

[09:21] <TabAtkins_> florian: They should probably be prefixed, to avoid accident collisions with WG stuff.

[09:22] <TabAtkins_> glazou: I'm not sure there's a firm line. Standalone web apps are becoming more prevalent. Nobody knew initially that iTunes was built in web stuff.

[09:22] <hober> Of course, vendor-prefixed properties get created for several different purposes. see https://lists.webkit.org/pipermail/webkit-dev/2010-July/013534.html

[09:22] <TabAtkins_> glazou: Hiding stuff behind a pref isn't going to happen, or only for a few months until the standalone app is turned into a web app.

[09:23] <TabAtkins_> glazou: The proprietary CSS extensions we know of, only the ones designed for *very specific* things, like for MS word, don't eventually hit the web.

[09:23] <TabAtkins_> dbaron: There are plenty of vendor-prefixed things that haven't taken off.

[09:23] <TabAtkins_> glazou: Sure, but these are the no-question things. Others, vendors may at least consider it.

[09:23] <TabAtkins_> tantek: What do you mean by "things for ms word dont' eventually hit the web"?

[09:24] <TabAtkins_> glazou: The -mso- stuff never even considered to hit the web.

[09:24] <TabAtkins_> tantek: You can find tons of mso prefixes on the web.

[09:24] <TabAtkins_> glazou: Yes, but no one ever implemented them, or even intended to.

[09:24] <TabAtkins_> florian: I think you're not disagreeing with me - if you create mso or itunes things, and you initially isolate them...

[09:25] <TabAtkins_> florian: If someone else realizes they're not specialized and would be generally useful, someone can bring them to the WG.

[09:25] <TabAtkins_> glazou: *If* someone brings them to the WG. People don't do that.

[09:25] <TabAtkins_> jdaggett: About the mso stuff, that's just "gluck". The presence of a prefixed property in public isn't indicative that it's meaningful.

[09:26] * karl has joined #css

[09:26] <dbaron> TabAtkins: a problem you brought up is that we are making things exposde to the public without bringing them to the WG

[09:26] <TabAtkins_> sylvaing: Can't do it.

[09:26] <TabAtkins_> glazou: It's a problem of strategy.

[09:27] <karl> RRSAgent, pointer?

[09:27] <RRSAgent> See http://www.w3.org/2012/08/13-css-irc#T16-27-20

[09:27] <TabAtkins_> sylvaing: People have public bits they don't want to expose.

[09:27] <TabAtkins_> TabAtkins_: That means that browsers are using the web and the WG as a means to bless their actions after they've blasted the web, so they retain first-mover advantage.

[09:28] * Rossen has joined #css

[09:28] <TabAtkins_> leif: The WG can bring things up on their own, yes.

[09:28] <fantasai> sylvaing^: It's a matter of corporate disclosure

[09:29] <TabAtkins_> sylvaing: Sometimes it's not even mentioned. There are things in W8 that aren't even mentioned - just using CSS.

[09:29] <TabAtkins_> jdaggett: Some of these are proprietary proeprties - not really intended to be part of CSS.

[09:29] <TabAtkins_> jdaggett: And that's part of the problem. Authors dont' see that distinction.

[09:29] <TabAtkins_> jdaggett: Many marketing departments - there's a tendency to take feature X with a prefix on it and say that it's part of CSS3, even if the only thing that backs that up is a blog post or a private draft.

[09:29] <sylvaing> s/mentioned/submitted yet

[09:30] <TabAtkins_> florian: MS has probably extended CSS to make Metro UIs possible. Some of these features may be intended for the WG later, but not yet ready; others may not be intended for the web at all.

[09:30] <TabAtkins_> florian: For the ones not intended for the web at all, I say just dont' expose them at all.

[09:31] <TabAtkins_> florian: For the others that you intend to be on the web, it would be useful to ship them (because you have to), but not expose them to the web.

[09:31] <TabAtkins_> florian: This is similar to iTunes, and other types of things.

[09:31] <TabAtkins_> florian: So what happens when you actually expose things to the web.

[09:32] <TabAtkins_> florian: As long as you don't, you should have them prefixed, so that whatever ends up on the web (a standardized version of it, or something independent with the same name), we don't get name collisions between these two.

[09:33] <TabAtkins_> florian: Which the web doesn't care abuot, but the private app would stop working if a same-named feature started doing something else.

[09:33] <TabAtkins_> szilles: So I think you're saying that we own the unprefixed space, and anyone else must prefix.

[09:33] <TabAtkins_> florian: I think whether or not random people introducing random things to the web should or shouldn't prefix is a separate question.

[09:33] <TabAtkins_> florian: But for the things that *aren't* meant for the web, don't expose them, and prefix them.

[09:34] <TabAtkins_> glazou: Again, I think the idea to "don't expose them to the web" is unworkable. More apps move to webapps.

[09:34] <TabAtkins_> glazou: I don't think it'll happen. Browsers will want to expose them to the web sot hey can write webapps.

[09:35] <TabAtkins_> plinss: I think it's reasonable for webkit to understand epub stuff, but only when reading epub files. Not when doing normal web content.

[09:35] <TabAtkins_> glazou: When I'm downloading a random epub file from the web, should it or not render epub properties?

[09:36] <TabAtkins_> florian: If you can recognize it as epub...

[09:36] <TabAtkins_> glazou: There's no difference between epub and a random html file.

[09:36] * jdaggett has joined #css

[09:36] <TabAtkins_> hober: I think it's unreasonable to expect epub authors to have a different workflow than regular html workflows.

[09:37] <TabAtkins_> plinss: If it cant' tell, it can't tell. But if it can tell one way or the other, do or don't respect epub properties.

[09:37] <TabAtkins_> glazou: I don't think that's reasoanble. Right now on the web you have some epub readers. They're just webapps.

[09:37] <TabAtkins_> jdaggett: You're advocating a bad idea.

[09:37] <TabAtkins_> glazou: Not advocating - describing.

[09:38] <TabAtkins_> jdaggett: You're saying that any group that wants to create their own flavor of HTML or CSS, those things are their own entity. Whether any particular UA shows it in the way that's intended is a private matter.

[09:38] <TabAtkins_> szilles: Browsers aren't the only thing that can display web content.

[09:38] <TabAtkins_> szilles: They may accept different things than what the browser accepts.

[09:38] <TabAtkins_> szilles: If those other things become popular enough, there may be pressure to adopt what they do.

[09:39] <TabAtkins_> szilles: So I'm hearing daniel say that it's a market force that we cant' do anything about.

[09:39] <TabAtkins_> sylvaing: In W8, we try to have a clean separation between web and app.

[09:39] <TabAtkins_> sylvaing: But quickly, the Facebooks and Netflixes of the world, just build an app with a web container.

[09:40] <TabAtkins_> sylvaing: And quickly they want the full set of things that apps can do.

[09:40] * Koji has joined #css

[09:40] <TabAtkins_> florian: But at that point we get to the point where you're deciding that things are appropriate for the web, not just for siloed content.

[09:40] <TabAtkins_> jdaggett: I think the epub process is a perfect example of how we should not try and act.

[09:41] <TabAtkins_> jdaggett: Where you take a laundry list of features that someone says they want, and stick it into a document with no attempt to distill or worry about interactinos or do the hard work.

[09:41] <TabAtkins_> tantek: Regarding epub - I think they're a great example of the *reality* tha other groups will try to extend or fork the web platform.

[09:41] <TabAtkins_> tantek: Before epub we had chtml, though that's an example of something that died.

[09:42] <TabAtkins_> tantek: Other groups will try to extend.

[09:42] <TabAtkins_> tantek: We can try to outcompete them, or we can get outcompeted.

[09:42] <TabAtkins_> glazou: Epub is a nice extensions because they have public documents detailing everything.

[09:42] <TabAtkins_> hober: epub tried to track us as well as they could, given our schedule, and they tried to be good actors in this case.

[09:42] <TabAtkins_> glazou: yes, it's a good case.

[09:42] <TabAtkins_> glazou: It's not the best thing to do, but they tried to do good.

[09:43] <TabAtkins_> dbaron: They had a schedule, and no intention of putting in enough resources to meet that schedule properly.

[09:43] <TabAtkins_> szilles: I think it's important that such experiments are identified as such.

[09:43] <TabAtkins_> szilles: But I think we should adopt a "fast follow" appraoch, so that when something looks important, we can produce a similar version of it.

[09:44] <TabAtkins_> szilles: Not necessarily idetnical - one of the problems with the fast actors is that they often don't think about interactions,w hich slows us down.

[09:44] <TabAtkins_> jdaggett: It isn't just a matterof slow and burearcratic, as tantek puts it - it's just a damned hard problem.

[09:44] * krit Quit (Quit: Leaving.)

[09:45] <TabAtkins_> glazou: It can be fast and agile and not disclosed because of competitive reasons.

[09:45] <TabAtkins_> tantek: Often burearcracy and process has gotten in our way historically.

[09:45] * Bert tinks for discussions like this we need more than one fast and agile scribe :-)

[09:45] <TabAtkins_> tantek: We're aware of and trying to fix that problem.

[09:45] <TabAtkins_> jdaggett: Prioritization si crucial.

[09:46] <TabAtkins_> jdaggett: If we aren't prioritizing the right thing, if we're spending lots of time on exotic things here an there, that's a problem.

[09:46] <TabAtkins_> florian: I think it magnifies the problem - it's not a root cuase.

[09:46] * sylvaing ...this isn't controversial enough. Let's use political analogies!

[09:46] <TabAtkins_> szilles: I think making it possible for us to do fast follow is how we should address this problem, not changing the way we identify things.

[09:47] <TabAtkins_> szilles: How we label is a red herring.

[09:47] * smfr has joined #css

[09:47] <TabAtkins_> plinss: It alleviates some of the pressure.

[09:47] <TabAtkins_> plinss: There's no disagreement in the group that thigns come up that we need to work on more aggressively.

[09:47] <TabAtkins_> glazou: From my perspective the problem is about getting the technical information about a property impld by one of the members and not yet disclosed, such as text-size-adjust.

[09:48] <TabAtkins_> tantek: People brought up a bunch of examples.

[09:48] <TabAtkins_> fantasai: Examples: text-size-adjust was not disclosed and became super-popular

[09:48] <TabAtkins_> fantasai: border-radius, microsoft's grid layout proposal...

[09:48] <TabAtkins_> fantasai: Looking at different ones of these, you'll make different suggestions about what's best.

[09:49] <TabAtkins_> fantasai: border-radius - why have prefixes? We all did the same.

[09:49] <TabAtkins_> fantasai: grid layout - if MS shipped what they had unprefixed, we'd have had no chance to fix the problems in it.

[09:49] <TabAtkins_> fantasai: So we shouldn't focus on justone of these problems, we should look at all of them.

[09:49] * myakura Quit (Client exited)

[09:49] <TabAtkins_> fantasai: Like T&A is more of a border-radius case.

[09:49] <TabAtkins_> tantek: More general examples.

[09:49] <TabAtkins_> tantek: There was the UI example - UI of iTunes or Firefox.

[09:50] <TabAtkins_> florian: Slight break - we don't all agree on the exact details of the problem, but we all have a shared idea of what it is generally.

[09:50] <TabAtkins_> florian: So rather than get the details more, let's talk about solutions and see if it turns out good.

[09:50] <TabAtkins_> fantasai: Starting proposal!

[09:50] <TabAtkins_> fantasai: Section A.

[09:50] <TabAtkins_> fantasai: If it's not web-ready, ship it prefixed and don't expose it to the web.

[09:51] <TabAtkins_> Section B.

[09:51] <TabAtkins_> fantasai: For standards-track features, ship only in non-release builds.

[09:51] <TabAtkins_> fantasai: ...unprefixed.

[09:51] <TabAtkins_> fantasai: If another browser ships a release and we have some level of good interop and we think it's a good idea, everyone ship as release.

[09:52] <TabAtkins_> dbaron: The way another browser "ships a release" is by breaking these rules in the first place.

[09:53] <TabAtkins_> fantasai: If three browsers total implement (non-shipping) and we have interop and think it's a good idea, everyone ship.

[09:53] <TabAtkins_> fantasai: Maybe if it's not a solid spec and we dont' have a testsuite, but we're still forced to ship, ship both prefixed and unprefixed so authors can turn things off that are broken in a particular impl.

[09:53] <TabAtkins_> glazou: This does not solve the text-size-adjust problem.

[09:54] <TabAtkins_> szilles: What problem does this solve?

[09:54] <TabAtkins_> TabAtkins_: The bit where we have multiple prefixed versions living for a while and making authors lives hard.

[09:55] <TabAtkins_> szilles: In order to do that, you still need a test suite and therefore why not go through the process we have now.

[09:55] <TabAtkins_> florian: If you want to test *strict* interop, you need a test suite. If you just need a rough idea, you don't need that - subjecive judgements are possible.

[09:55] <tantek> q+

[09:55] * Zakim sees tantek on the speaker queue

[09:56] <plinss> ack tantek

[09:56] * Zakim sees no one on the speaker queue

[09:56] <TabAtkins_> tantek: Response to steve - what we ahve seen with T&A&transforms, these exampels have disproven your statement.

[09:56] <TabAtkins_> tantek: In practice, we have not needed a testsuite to get itnerop, as evidenced by author adoption.

[09:56] <TabAtkins_> tantek: if they weren't "sufficiently interoperable", authors wouldn't be using them so much.

[09:57] <TabAtkins_> tantek: This is a pretty strong bar.

[09:57] <TabAtkins_> glazou: "perceived interop", not "interop".

[09:57] <TabAtkins_> szilles: My concern is that, left to the vendors to declare interop, this won't work.

[09:57] <TabAtkins_> szilles: Marketing departments have a strong idea to do that.

[09:58] <TabAtkins_> plinss: I don't think anyone is suggesting that a single vendor declaring interop is sufficient.

[09:58] <TabAtkins_> plinss: I think the current process we have, where someone suggests we have sufficient interop and then asks the group for unprefix, is sufficient.

[09:58] <TabAtkins_> dbaron: But we did that with TTA, and the group said no the first time.

[09:59] <TabAtkins_> florian: When we asked the group "can we release TTA", we were aiming for a different level of interop.

[09:59] <dbaron> hmmm, maybe I'm misremembering and thinking of something else

[09:59] <TabAtkins_> florian: We were asking for full interop. We're now not shooting for that - we want "sufficient interop".

[09:59] <tantek> dbaron - no you're remembering correctly

[09:59] <fantasai> no, the first time we decided not to unprefix, largely because MS did not want to

[09:59] <tantek> we asked to unprefix TTA in Paris in February and were told no

[09:59] <tantek> I'm sure we can look that up in the minutes

[09:59] <fantasai> and then when they decided to unprefix, that gave us consensus in the WG

[09:59] <TabAtkins_> florian: Now, between these two stages, you shoudl ship prefixed *and* unprefixed, so individual authors can use the unprefixed if it works for them, and provide brwoser-specific styles using prefixes to work around problem in specific browsers.

[10:00] <TabAtkins_> glazou: I'm seeing two cases.

[10:00] <TabAtkins_> glazou: I don't think that this process is the difficult one.

[10:00] <TabAtkins_> glazou: I think the hard one is the browser vendor developing a proprietary feature and then everyone else discovers it by surprise,a nd we have to implement.

[10:00] <TabAtkins_> florian: If text-size-adjust was released under this process, it would not be in a webkit prefix.

[10:01] <TabAtkins_> florian: It would put us in mostly the same difficulty as now, except that browsers who decided to implement it wouldn't be forced to implement it with a webkit prefix, which is today's situation.

[10:01] <TabAtkins_> florian: This system doesn't prevent the bad things from happening, but it untaints them.

[10:01] <TabAtkins_> florian: All the things we're trying to do with text-size-adjust now, we'd mostly have to do anyway. It won't go away.

[10:02] <TabAtkins_> florian: But at least we're not stuck witht he webkit prefix name that everyone has to support.

[10:02] <TabAtkins_> florian: It's not fantastic, but it's an improvement.

[10:02] <TabAtkins_> tantek: There's a bunch of different problems ehre.

[10:02] <TabAtkins_> tantek: I like the proposal as developed. It doesnt solve all the problems, but it soles all of them.

[10:02] <dbaron> q+

[10:02] * Zakim sees dbaron on the speaker queue

[10:03] <TabAtkins_> florian: I think it doesn't solve all of them, but it solves some of them better than the current world.

[10:03] <TabAtkins_> szilles: If you publish anything unprefixed before you have a reasonable belief that it's reasonably interoperable, you're going to get uninteroperable things, and it will become unusable.

[10:03] <tantek> s/soles all of them/solves some of them well enough/

[10:04] <TabAtkins_> szilles: Or everyoen will follow the bad design.

[10:04] <TabAtkins_> TabAtkins_: The reality is that everyone follows the bad design *and* puts a webkit prefix on it.

[10:04] <TabAtkins_> szilles: But it prevents us from doing better under a better name.

[10:04] <tantek> "if it works, the author will use the unprefixed version because it's shorter typing"

[10:04] <tantek> -Szilles

[10:05] <TabAtkins_> glenn: A random remark - I noticed a posting that "the point of the vendor prefix is to assert the instability of a feature".

[10:05] <TabAtkins_> glazou: A corollaorya of that is that purely proprietary things shouldnt' use a prefix.

[10:05] <TabAtkins_> dbaron: I don't think we should try to come up with a master plan for the future.

[10:06] <TabAtkins_> dbaron: We should be figuring out how to adjust what we're doing.

[10:06] <TabAtkins_> dbaron: And I think it will require continued adjustment in the future.

[10:06] <dbaron> ack dbaron

[10:06] * Zakim sees no one on the speaker queue

[10:06] <TabAtkins_> dbaron: We won't do it all today.

[10:06] <Ms2ger> s/corollaorya/corollary/

[10:06] <TabAtkins_> dbaron: I think a few directions in which we should be adjusting things...

[10:06] <TabAtkins_> dbaron: (1) ship less prefixed stuff on the web

[10:06] * Ms2ger thinks that was what was meant, at least

[10:06] <TabAtkins_> dbaron: (2) unprefix things faster when we get interop

[10:07] <TabAtkins_> florian: I think we need to acknowledge that not everyone will follow the policy.

[10:07] <TabAtkins_> florian: This will happen, so our policy shoudl just not make things worse when this happens.

[10:07] <TabAtkins_> hober: Note that dbaron's #2 is something we can do right now withotu changing policies.

[10:07] <tantek> "when we get interop" - what level of interop? authors vs. test suites

[10:07] <TabAtkins_> fantasai: Actually, the current policy is just the "legacy content" excuse.

[10:07] <TabAtkins_> fantasai: That's what we used for TTA.

[10:08] <tantek> TabAtkins: for the one issue of let's unprefix faster, let's formally adopt Elika's stated proposal (from dbaron)

[10:08] <tantek> szilles: I can live with that

[10:09] <TabAtkins_> glenn: That's reminiscent of the knowledge that Maciej required for CR-exit.

[10:09] <tantek> s/knowledge/language

[10:09] <TabAtkins_> glenn: For HTML.

[10:09] <TabAtkins_> szilles: I like that it's not individual manufacturers making that decision.

[10:09] <TabAtkins_> tantek: One thing I'llr aise is that one recent RFC deprecated the use of x-.

[10:09] <hober> glenn was referring to this email: http://lists.w3.org/Archives/Public/public-html/2012Aug/0190.html

[10:09] <TabAtkins_> tantek: But they drew a strong line between vendor-specific and experimental features.

[10:10] <TabAtkins_> tantek: They think that using x- for vendor-specific still works.

[10:10] <TabAtkins_> tantek: But not for experimental, because in the end everyone implemented it anyway.

[10:10] <TabAtkins_> tantek: So let's consider that work and analysis done by IETF.

[10:11] <TabAtkins_> plinss: Let me assert that, while learning from IETF is useful, we might not want to follow them exactly - they have a different problem space.

[10:11] * hober suspects we've exceeded our timebox for this topic

[10:12] <TabAtkins_> TabAtkins_: So are there standing objections to fantasai's proposal?

[10:12] * mmielke has joined #css

[10:12] <TabAtkins_> glazou: No objection, but I'd like to see it written otu formally in an email, as it's nearly unreadable here in the minutes.

[10:12] * miketaylr Quit (Quit: Leaving...)

[10:12] <TabAtkins_> [consensus]

[10:13] <TabAtkins_> glazou: We'll post to email, and formally resolve in a few days if there are no objections.

[10:13] * mmielke Quit (Quit: mmielke)

[10:13] <TabAtkins_> Topic: Fonts

[10:15] <glenn> s/Maciej required for/Maciej suggests for permissive version of/

[10:15] <dbaron> http://people.mozilla.org/~jdaggett/tests/simplekerningligs.html

[10:15] <TabAtkins_> jdaggett: I wanted to talk about default font features.

[10:15] <TabAtkins_> jdaggett: We talked aboutit a bit on the call.

[10:15] <TabAtkins_> jdaggett: People seemed comfortable, but there were some concerns fromMS developers.

[10:15] <dbaron> also, https://groups.google.com/group/mozilla.dev.platform/msg/6107b1b7bd4fb799?dmode=source&output=gplain&noredirect was my earlier proposal on experimental features

[10:15] <TabAtkins_> jdaggett: So we'll quickly review.

[10:16] <TabAtkins_> jdaggett: [shows demo]

[10:16] <dbaron> alternate link for that is https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/itl6mtx2dxI[1-25]

[10:16] <TabAtkins_> jdaggett: This is showing raw text with no kerning or ligatures, and the second line is FF default, with ligatures and kerning.

[10:16] <TabAtkins_> florian: The default is influence by data coming fromthe font?

[10:16] <TabAtkins_> jdaggett: No, there is a set of features that are declared as "default" in the OT spec.

[10:17] <TabAtkins_> jdaggett: Because FF is turning these on by default, the fourth line and the second line match.

[10:17] <TabAtkins_> jdaggett: However, if we go over to Chrome, the default case is different from the random-feature case.

[10:18] <TabAtkins_> jdaggett: The internal reason for this is that there's a different rendering path with differetn defaults.

[10:18] <TabAtkins_> jdaggett: I'm saying that the default case should be the same as the random-feature case.

[10:18] <TabAtkins_> jdaggett: So that turning on a random feature shouldn't also turn on random other features.

[10:18] <TabAtkins_> jdaggett: [shows comparative screenshot]

[10:19] <TabAtkins_> jdaggett: What this shhows is language-sensitive features.

[10:19] <TabAtkins_> jdaggett: In turkish there is a dotted and dotless i. So when you do small caps, you need to put a dot on the i to be correct.

[10:19] <TabAtkins_> jdaggett: This is specified with a language tag. This gets sent downt ot he font engine, and that handles things correctly.

[10:19] <TabAtkins_> jdaggett: In IE10, this works correctly, but it's not yet implemented in webkit.

[10:20] <TabAtkins_> jdaggett: But weird behavior in IE10 for another feature.

[10:20] <TabAtkins_> jdaggett: In serbian, this glyph should be a localized alternate.

[10:20] <TabAtkins_> jdaggett: But if you turn on a randomf eature, FF gives you the same thing, but in IE10 all of a sudden the localized feature appears.

[10:21] <TabAtkins_> glenn: So the algorithm used by the UA to enable the OT advanced tables is different in different brwosers.

[10:21] <TabAtkins_> jdaggett: Yes, but I'm saying there shouldn't be side-effects from random features.

[10:21] <TabAtkins_> florian: So either everyone should match FF and keep the default features on, or they shouldn't turn on the default at all unless they're epxlicitly asked for.

[10:21] <glenn> s/brwosers/browsers/

[10:21] <TabAtkins_> sylvaing: (1) there is no font-feature-settings - what features are on by default? That's a difference.

[10:21] <TabAtkins_> sylvaing: (2) when you do ask for a specific font feature, do you get just that, or do other things pop up?

[10:22] <TabAtkins_> jdaggett: If we go to the OT spec...

[10:22] <TabAtkins_> jdaggett: It's a bit scattered.

[10:22] <TabAtkins_> jdaggett: These are the default features,a cross scripts.

[10:22] <TabAtkins_> jdaggett: Some specific scripts have extra features by default.

[10:22] <dbaron> http://people.mozilla.org/~jdaggett/tests/default-feature-list.html

[10:22] <TabAtkins_> jdaggett: [describes the table]

[10:23] <dbaron> http://people.mozilla.org/~jdaggett/tests/simpleccmptest.html

[10:23] <TabAtkins_> jdaggett: [shows tone marks using one fo the default OT features]

[10:23] <TabAtkins_> jdaggett: This works in Chrome too, which shows that though they're not enabling the features by default, they have some logic that is turning on this feature when they show up.

[10:24] <TabAtkins_> sylvaing: Do you have a ref to the OT spec?

[10:24] <TabAtkins_> jdaggett: In CSS3 Fonts, section 7, there are several links in the text.

[10:24] <TabAtkins_> szilles: Which spec? ISO or MS?

[10:24] <TabAtkins_> jdaggett: Loosely-defined.

[10:24] <TabAtkins_> jdaggett: ISO is a file-format spec - it doesn't cover layout.

[10:24] <TabAtkins_> jdaggett: So we have to be a bit looser about what we consdier "the spec".

[10:24] <glenn> http://www.microsoft.com/typography/otspec/

[10:24] <TabAtkins_> jdaggett: Hopefully they'll be more rigorous in the future.

[10:25] <glenn> ISO/IEC 14496-22 "Open Font Format" standard. The standard was published in 2007, and is now freely available for download from ITTF website. OpenType version 1.6 is identical to the ���Final Draft International Standard��� version of ISO/IEC 14496-22 FDIS ���Open Font Format��� (second edition).

[10:26] * miketaylr has joined #css

[10:26] <TabAtkins_> sylvaing: Our default rendering is consistent across the windows platform

[10:26] <TabAtkins_> jdaggett: So if you could review this list and suggest changes, would be great.

[10:27] <TabAtkins_> jdaggett: I think we're covered here.

[10:27] <TabAtkins_> florian: If I'm following you right, there are three ways of doing this.

[10:27] <glenn> http://www.microsoft.com/typography/otspec/featuretags.htm

[10:27] <TabAtkins_> florian: One is the Chrome/MS way, which is not ideal.

[10:27] <TabAtkins_> florian: Another is the Firefox, which may require an extra switch.

[10:27] <TabAtkins_> jdaggett: Let me finish.

[10:27] <TabAtkins_> jdaggett: The features in the list in red are those which can be controlled.

[10:27] <TabAtkins_> jdaggett: ...via font-variant-ligatures.

[10:28] <TabAtkins_> jdaggett: I've put in a "none" value to font-variant-ligatures which turns off all defaults.

[10:28] <TabAtkins_> jdaggett: That will not disable the requried features.

[10:28] <TabAtkins_> jdaggett: These are usually specialized features that are *needed* for correct rendering of various things.

[10:29] <TabAtkins_> glenn: How would someone shut down the rlig feature?

[10:29] <TabAtkins_> jdaggett: font-feature-settings: rlig 0;. It's possible.

[10:29] <TabAtkins_> jdaggett: I was going to put in an example of this showing a use-case of seeing the individual characters in Arabic, but I don't want to explain how to shut these things down easily.

[10:30] <TabAtkins_> jdaggett: There are some perforamnce considerations.

[10:30] <TabAtkins_> jdaggett: As the glyph composition shows, some of these are already handled in an ad-hoc way.

[10:30] * krit has joined #css

[10:30] <TabAtkins_> jdaggett: Most fonts, you can do a simple analysis and do a fast path if the font doesn't have a feature at all.

[10:30] <TabAtkins_> jdaggett: It just means there's a little additional logic before taking the fast path.

[10:31] <TabAtkins_> jdaggett: So I think we should resolve that the "none" value resolves the issue.

[10:32] <TabAtkins_> Bert: Is "none" the same as setting "no-*" for all the others?

[10:32] <TabAtkins_> jdaggett: Yes.

[10:33] <TabAtkins_> sylvaing: What about an "auto" value that is a default?

[10:33] <TabAtkins_> jdaggett: I'm keeping "normal" as the default.

[10:33] <TabAtkins_> jdaggett: kerning has "auto", because that's more prevalent and can be controlled by browser vendors.

[10:34] <TabAtkins_> RESOLVED: Accept font-variant-ligatures as written: "normal" is initial value, and "none" is added which turns off those features.

[10:34] <TabAtkins_> plinss: My only concern is that "normal" seems underdefined.

[10:34] <TabAtkins_> jdaggett: There's a section that defines the common defaults.

[10:34] <TabAtkins_> glenn: Could you put those common defaults for this feature in this section?

[10:34] <TabAtkins_> jdaggett: Oh, sure.

[10:35] <TabAtkins_> plinss: The reason you're not explicitly saying "'normal' means foo and bar" is because it varies on font engine and script>

[10:35] <TabAtkins_> jdaggett: Yes.

[10:35] <TabAtkins_> RESOLVED: Public a new WD of Fonts.

[10:36] <TabAtkins_> <br dur=15min>

[10:36] <TabAtkins_> RESOLVED: Publish a new WD of fonts.

[10:36] <dbaron> "My system just crashed." "Oh, good."

[10:45] <glenn> s/put those common defaults for this feature in this section/put a link from "common defaults" to its defining section/

[10:48] * Rossen Quit (Ping timeout)

[10:51] <jet> dbaron: LOL!

[10:52] * Rossen has joined #css

[10:57] * krit Quit (Quit: Leaving.)

[10:57] * krit has joined #css

[11:00] <fantasai> http://www.w3.org/Style/CSS/Tracker/products/10

[11:01] <Bert> ScribeNick: Bert

[11:01] <dbaron> Topic: CSS3 Text

[11:02] <Bert> fantasai: We resolved to postpone to level 4, but now we have a shorthand idea.

[11:02] <Bert> ... [issue-236]

[11:02] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/236

[11:02] <Bert> tab: sounds useful, now we have a useful way to address aliasing.

[11:03] <Bert> florian: I'd agree

[11:03] <Bert> fantasai: So resolve that word-wrap is shorthand for overflow-wrap?

[11:03] <Bert> RESOLVED: make word-wrap shorthand fpr overflow-wrap

[11:04] <Bert> issue-221?

[11:04] * trackbot getting information on ISSUE-221

[11:04] <trackbot> ISSUE-221 -- text-emphasis-color can't recompute color to match text on descendants -- raised

[11:04] <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/221

[11:04] <Bert> fantasai: there is an errata open, should be posted to css3-color

[11:04] * smfr Quit (Client exited)

[11:05] * smfr has joined #css

[11:05] * smfr Quit (Client exited)

[11:05] * smfr has joined #css

[11:05] <tantek> http://www.w3.org/Style/2011/REC-css3-color-20110607-errata.html

[11:06] <Bert> action bert: add errata to css3-color errata ist about currentcolor, (as in above URL)

[11:06] * trackbot noticed an ACTION. Trying to create it.

[11:06] * RRSAgent records action 15

[11:06] <trackbot> Created ACTION-502 - Add errata to css3-color errata ist about currentcolor, (as in above URL) [on Bert Bos - due 2012-08-22].

[11:06] <Bert> issue-243?

[11:06] * trackbot getting information on ISSUE-243

[11:06] <trackbot> ISSUE-243 -- graphical effects and text-decoration -- raised

[11:06] <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/243

[11:06] <dbaron> record of currentColor errata is in http://lists.w3.org/Archives/Public/www-style/2012May/0541.html

[11:06] <Bert> fantasai: issue with underline and shadow and all these kinds of things

[11:06] <Bert> ... if you have an ancestor,

[11:07] <Bert> ... say whole para is underlined and a text has shadow, etc.

[11:07] <Bert> ... is the underline shadowed?

[11:07] <Bert> SteveZ: Is the underline logically part of the para even if physically it is not?

[11:07] <Bert> fantasai: How about visibility?

[11:07] <Bert> SteveZ: If not visible, also not undelrined, I think.

[11:08] <Bert> dbaron: ssociated with the text.

[11:08] <Bert> ... text decor gets colors from elt it comes from.

[11:08] <Bert> fantasai: if invisible, definitely not visible.

[11:08] <Bert> dbaron: You mean opacity?

[11:08] <Bert> fantasai: yes

[11:08] <Bert> dbaron: opacity happens all at once.

[11:08] <Bert> ... I can't imagine another option

[11:09] <Bert> ... opctity on ancestor applies to all descentants.

[11:09] <Bert> fantasai: Then remaining question is filter efefects (same way?) and tet shadow,

[11:09] * krit Quit (Quit: Leaving.)

[11:09] <Bert> tab: filter efect is same yes

[11:09] <Bert> fantasai: part of underline could be shadowed and part not, looks weird.

[11:09] <Bert> SteveZ: looks weird eihter way

[11:10] <Bert> fantasai: [draws on white board]

[11:10] <Bert> dbaron: three cases:

[11:10] <Bert> ... shadow on something inide, on same, on something outside.

[11:10] <Bert> ... debate is on inside case

[11:10] <Bert> SteveZ: For emphasiz, I think the udenrline should get shdaow

[11:11] <Bert> fantasai: [draws text with underline, part of it get shadow]

[11:11] <Bert> ... does underline get shadow?

[11:11] <Bert> TabAtkins_: I think so. Some case lookk weird, but bulk is ok.

[11:11] <Bert> dbaron: I have diff. intuition

[11:11] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jan/att-0265/underline-shadow.png

[11:12] <Bert> sylvaing: ie does shadow the underline

[11:12] <Bert> ... so the etst case is para is underlined, and a part of iut has shadow?

[11:12] <Bert> fantasai: yes

[11:12] <Bert> sylvaing: webkit shadows the underine, ff also,

[11:13] <Bert> dbaron: what i syour test case, sylvaing ?

[11:13] <sylvaing> <!doctype html>

[11:13] <sylvaing> <style>

[11:13] <sylvaing> p {

[11:13] <sylvaing> text-decoration: underline;

[11:13] <sylvaing> }

[11:13] <sylvaing> #test {

[11:13] <sylvaing> text-shadow: 0.1em 0.1em #333;

[11:13] <sylvaing> }

[11:13] <sylvaing> </style>

[11:13] <sylvaing> <p>This is <span id="test">underlined</span></p>

[11:13] <Bert> sylvaing: [trying to copy his test case]

[11:14] <Bert> SteveZ: it makes more sens with shadow below than with above.

[11:14] <Bert> sylvaing: looks like opera doesn't shadow th eunderline

[11:15] <Bert> dbaron: Not sure we could do anything than what we do. WOnder how Opera is able to.

[11:15] <Bert> ... text-shadow is inherited.

[11:15] <Bert> ... we don't even now what is outside or inside

[11:16] <Bert> fantasai: But you do know for udnerline.

[11:16] <Bert> florian: We don't shadow the undelrine either way.

[11:16] <dbaron> s/either way/either way you nest them/

[11:17] <Bert> bert: in fantasai 's drawing i think without shadow looks better...

[11:17] <Bert> dbaron: To implement, you'd redo your text decoration...

[11:17] <Bert> fantasai: Basically the same way as for color

[11:18] <fantasai> s/Basically/Basically you do your shadow finding/

[11:18] <Bert> fantasai: So it is possible to implement, what do we want?

[11:19] <Bert> ... if we decide it is not shadowed, users can still aplly a filter effect to get a shadow.

[11:19] <Bert> ... It is not a very common case.

[11:19] <Bert> sylvaing: We have interop between 3 browsers out of 4 i tested.

[11:19] <Bert> SteveZ: General underline rule covers position and color.

[11:19] <Bert> ... We'd like it to behave the same way.

[11:20] <Bert> ... Filter effects hould apply, we said.

[11:20] <Bert> ... Authors would be surprised if shadow was absent.

[11:20] <Bert> tab: I dont' care that much, lets go with [??]

[11:21] <Bert> plinss:biased towards finding shadow the same way as the color.

[11:21] <Bert> ... decotration visually belongs to parent,

[11:21] <Bert> ... slight bias.

[11:21] <Bert> SteveZ: So doesn't matter much now, and once it does, we'll put in a proeprty to control it.

[11:21] <Bert> plinss: I'm never quite sure how it should behave,

[11:22] <Bert> SteveZ: It's certainly one of th emost complex definitions.

[11:22] <Bert> dbaron: inclined to agree with bert about lower one [no shadow] being better.

[11:22] <Bert> SteveZ: I think it depends on the shadow. THis shadow is above. Below would look less strange.

[11:23] <Bert> plinss: the letter is different color, undelrine visually doens't belong to that text.

[11:23] <dbaron> I was actually saying I agreed with Brad (since fantasai quoted his opinion), but it turns out Brad and Bert agree :-)

[11:24] <Bert> fantasai: I'll look strange no matter what.

[11:24] <Bert> sylvaing: is there a use case where it is abad thing what browsers do now?

[11:25] <Bert> dbaron: I think i prefer to go the other way, more consistent with the model.

[11:25] <Bert> SteveZ: Despite that filters apply?

[11:25] <Bert> dbaron: Different kinds of things.

[11:25] <Bert> TabAtkins_: They just apply to the pixels.

[11:26] <dbaron> more consistent with the model and with most of the people who expressed an opinion about which is better

[11:26] <Bert> SteveZ: How would the user see the difference wheteher it is picel based or not?

[11:26] <Bert> sylvaing: Without a use caseshowing it is clearly wrong, I'd not like to change.

[11:27] <dbaron> A) shadows draw the same decorations as the text they're shadowing

[11:27] <Bert> glazou: bottom

[11:27] <Bert> [strawpoll]

[11:28] <Bert> sylvaing: top

[11:28] <Bert> Bert: bottom

[11:28] <Bert> koji: top

[11:28] <Bert> SteveZ: top

[11:28] <Bert> glenn: top

[11:28] <Bert> ted: top

[11:28] <Bert> alan: top

[11:28] <Bert> fantasai: abstain

[11:28] <Bert> tantek: abstain

[11:28] <Bert> TabAtkins_: top

[11:28] <Bert> dbaron: bottom

[11:29] <Bert> florian: bottom

[11:29] <Bert> leif: bottom

[11:29] <dbaron> http://lists.w3.org/Archives/Public/www-style/2012Jan/att-0265/underline-shadow.png

[11:29] <Bert> peter: bottom

[11:29] <Bert> fantasai: How about a public poll?

[11:29] <Bert> sylvaing: Does anybody object to what is already done?

[11:29] <glazou> glazou: NO CONSENSUS

[11:30] <Bert> florian: That would be ok, even if it is against what i prefer.

[11:30] <dbaron> dbaron: yep

[11:30] <Bert> RESOLVED: top

[11:31] <Bert> s/top/ apply shadow, because it is what is most widely implemented now.

[11:31] <Bert> issue-273?

[11:31] * trackbot getting information on ISSUE-273

[11:31] <trackbot> ISSUE-273 -- Interaction of text-decoration longhands and blink -- raised

[11:31] <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/273

[11:31] <Bert> fantasai: issue is that text-deco takes a number of values, including blink.

[11:31] <Bert> ... we dont have long hand for blink.

[11:32] <Bert> ... we can make 'blink' a valid value in one of the long hand properties.

[11:32] <Bert> ... or we can make a blink property

[11:32] <Bert> ... or we can throw it away in the DOM.

[11:33] <Bert> [jokes about blink]

[11:33] <Bert> fantasai: Could be a text-decoration-style

[11:33] <Bert> TabAtkins_: I'm using animation instead of blink

[11:33] <Bert> glazou: [shows his home page with blinking underline]

[11:34] <Bert> dbaron: most browsers haven't implemented blink.

[11:34] <Bert> ... not in webkit and IE.

[11:34] <fantasai> Tab: <blink> can be implemented as an animation

[11:34] <Bert> glazou: I don't like special cases. so not fantasai's last option.

[11:35] <Bert> dbaron: We added an additional proeprty -moz-tex-blink to solve this issue.

[11:35] <Bert> glazou: i like that one.

[11:35] <Bert> dbaron: It is an extra property for a feature we might rather remove.

[11:35] <Bert> fantasai: Prefer to not ceate new property, seems excessive.

[11:35] <Bert> ... prefer to put in on text-decoration-style.

[11:36] <Bert> TabAtkins_: Prefer to ignore the blink on the shorthand, parse it, but doens't do anything.

[11:36] <Bert> fantasai: not even store it?

[11:37] <Bert> tab: right, doens't round trip, only round trips functionally.

[11:37] <Bert> dbaron: it is backwards-incompatible to pout it on anything else than tetx-decoration-style.

[11:38] <Bert> ... in fact, current spec seems not backwards compatible.

[11:38] <Bert> glazou: do not want to deprecate it.

[11:38] <Bert> TabAtkins_: But only two impls, so why not deprecate it?

[11:38] <Bert> plinss: We have two impls.

[11:38] <dbaron> We haven't yet implemented the backwards-incompatible change that's in the spec

[11:39] <Bert> tantek: dprecate doesn't mean remove.

[11:39] <dbaron> it looks like we still accept 'text-decoration: underline blink overline'

[11:39] <Bert> plinss: But still needs to be defined, even if deprecated.

[11:39] <Bert> ... can you say 'underline red overline'

[11:40] <Bert> dbaron: Not according to spec, and don't thing you should be able to

[11:40] <Bert> plinss: and 'underine solid overline'?

[11:40] <Bert> fantasai: Seems odd ordering.

[11:40] <Bert> ... Inclinded to say no.

[11:40] <Bert> dbaron: Easiest path forward is to make 'blink' value of text-decoration-line

[11:41] <Bert> ... the way we make the shorthand is bit weird.

[11:41] <Bert> ... because on eof the long hands is the old property.

[11:41] <Bert> ... We coluld just have added the new properties

[11:41] <Bert> ... we moved text-decoration functionailty.

[11:42] <Bert> ... blink is funny since CSS1.

[11:42] <Bert> [talk about history of netscape]

[11:43] <Bert> florian: Opera has implemented it. I'm not srongly asking for deprecation, but in favor of deprecation.

[11:43] <Bert> SteveZ: You don't really want people to use blink for accessibilty reasons.

[11:44] <Bert> fantasai: We can map BLINK tag to anaimation in user agent style sheet.

[11:44] <dbaron> glazou (before SteveZ): If we're going to deprecate it, should have an example explaining how to do it with animations.

[11:44] <Bert> plinss: resolve to put blink on txt-decoration-line and deprecate it?

[11:44] <Bert> florian: so: should not, but are allowed to use blink?

[11:45] <Bert> plinss: it is a warning that it *may* be removed from spec later.

[11:45] <Bert> RESOLVED: blink is value of text-decoration-line and it is deprecated with warning that authors should not use it.

[11:46] <Bert> RESOLVED: add example of corresponding animation to the spec.

[11:46] * jdaggett Quit (Quit: jdaggett)

[11:46] * jdaggett has joined #css

[11:47] <dbaron> (in the UA style sheet appendix)

[11:47] <jdaggett> http://people.mozilla.org/~jdaggett/tests/letter-spacing-tests.html

[11:47] <Bert> jdaggett: I did some tests.

[11:47] <Bert> ... Checking interopreability.

[11:48] <Bert> ... letter spacing should control spacing on either side of char, but should not affect last letter (if right aligned line)

[11:48] <Bert> ... [shows image]

[11:48] <fantasai> http://dev.w3.org/csswg/css3-text/#letter-spacing

[11:48] <fantasai> "Letter-spacing must not be applied at the beginning or at the end of a line."

[11:48] <Bert> ... But implementatiosn add spacing after last letter.

[11:48] <Bert> ... [shows another image]

[11:49] <Bert> ... THis image shows fully justified.

[11:49] <Bert> fantasai: The spec already says what UAs must do.

[11:49] <Bert> jdaggett: It doesn't say *how* spacing is applied.

[11:50] <Bert> ... at the end of the line yu should not get space.

[11:50] <Bert> fantasai: Yes, that is a bug according to the current spec.

[11:50] <Bert> jdaggett: But the spec doesn't say exacty that

[11:51] <Bert> dbaron: the spec is precise, but you are describing a differnet model, eqwually precise, but different at element boundaries.

[11:51] <Bert> jdaggett: I think you atually have to get into how it works, e.g., in rtl.

[11:52] <Bert> fantasai/dbaron: What impls do is already bug, according to current spec.

[11:52] <Bert> jdaggett: I don't see that text.

[11:52] <Bert> .. What fantasai quoted is not precise enough.

[11:52] <Bert> fantasai: Give me an example that is not covered by the spec, and we'll improve the spec.

[11:53] <Bert> jdaggett: and between ltr trl boundaries?

[11:53] <Bert> fantasai: It is still "between chars" as the spec says.

[11:53] <Bert> SteveZ: Hald on each side, and you can't tell the difference.

[11:53] <Bert> fantasai: You can do it as trailing edge, but you stll have to handle the boundaries correctly.

[11:53] <Bert> jdaggett: I'll have to look more.

[11:54] <Bert> ... I started from looking nto justification.

[11:54] <Bert> ... letter nd word spaceing is input to justify.

[11:54] <Bert> ... allowed ot expand in different places.

[11:54] <Bert> ... but the actual algo wasn't clear form the spec, for different values.

[11:54] <Bert> ... Each diff value of text-justify,

[11:54] <Bert> florian: I have a similar concern:

[11:55] <Bert> ... reading the spec, good algos can be done, but spec doesn't tell you how.

[11:55] <Bert> ... the spec doens't induce vendors to implement those algos

[11:55] <Bert> SteveZ: It is modeled on systems from well before XSL.

[11:56] <Bert> jdaggett: Now we are designing knobs with semi-undefined justification systems.

[11:56] <Bert> ... how these inputs are used, i don't see differences between justify values.

[11:56] <Bert> fantasai: Priorities between buckets.

[11:56] <Bert> ... It sorts the expansion opportunities into buckets.

[11:57] <Bert> ... It doesn't tell you the algo precisely.

[11:57] <Bert> ... It is not our job to define the algo.

[11:57] <Bert> jdaggett: That's the pb, Knobs have no precise meaning.

[11:57] <Bert> alan: not ndefined, maybe udnerspecified.

[11:57] <Bert> florian: Intentinally, i think. Don't prevvent better algos.

[11:58] <Bert> jdaggett: But we need a mininmum.

[11:58] <Bert> ... I don't udnertsand th euse cases for the different justify values.

[11:58] <Bert> ... What are teh examples.

[11:58] <Bert> ... I dnbd' tsee a whole lot of difference in trying them.

[11:58] <Bert> ... It seems to have been modeled on IE 5.5.

[11:58] <Bert> ... Not clear where the difference are.

[11:59] <Bert> ... What are the use cases, maybe sylvain can tell?

[11:59] <Bert> .. Are the cases till relevant?

[11:59] <Bert> s/.. /... /

[11:59] <Bert> sylvaing: You wan tto deprecate some?

[11:59] <Bert> jdaggett: Spec is just too vague.

[11:59] <Bert> fantasai: table in spec shows the differences.

[12:00] <Bert> florian: Don't agree. It seems most of these are needed for internationaliztion.

[12:00] <Bert> fantasai: One case is mixed scripts on one line.

[12:00] <Bert> ... Interword will expand the spaces and nothing else.

[12:00] <Bert> ... ideograph exapnds between ideographs.

[12:01] <Bert> ... distribute expands both.

[12:01] <Bert> florian: Different countries have different expectaions.

[12:01] <Bert> jdaggett: Do we have collected the examples?

[12:01] <Bert> florian: With this spec we can impl an algo that matches the spec.

[12:02] <Bert> ... But that algo may still not be very good.

[12:02] <Bert> ... A bad algo can stil be conformant.

[12:02] <Bert> fantasai: We cannot define all algos. That's more than a PhD research.

[12:02] <Bert> jdaggett: All I ask is some simple use cases.

[12:03] <Bert> ... why is it important to have these property values?

[12:03] <Bert> fantasai: Pictures?

[12:03] <Bert> jdaggett: Conncrete exampels.

[12:03] <Bert> jdaggett: Is there enough info in the spec to say if an impl matches?

[12:04] <Bert> ... Not saying we should deprecate. But I don't see the diff. when trying them out.

[12:04] <Bert> florian: I'm not sure I'm asking for more specific. That might lock into bad algo.

[12:04] <Bert> ... But I'm gemnerally unhappy.

[12:04] <Bert> ... Not sure if more defined makes me happier.

[12:05] <Bert> SteveZ: Document whatr the differences are is one yhing.

[12:05] <Bert> jdaggett: Spc shoul dat leats have rudimentary examples.

[12:05] <Bert> SteveZ: You say we should take things out *until* we can provice examples?

[12:05] <Bert> jdaggett: Posting to www-style is OK, too.

[12:06] <Bert> jdaggett: Would like to ask sylvaing to find where it comes from.

[12:06] <Bert> ... No doubt came from cases in MS Office.

[12:06] <Bert> ... can we get more info?

[12:06] <Bert> ... The description by MS is "this is good for Thai"

[12:06] <Bert> ... But why is it good?

[12:07] <Bert> fantasai: So you wan texamples in the spec. I'll take an action.

[12:07] <Bert> sylvaing: And I one to fine out about IE5

[12:07] <Bert> s/fine/find/

[12:07] <Bert> jdaggett: We are trying to break it down by script. That is not the ideal way.

[12:07] <Bert> fantasai: Typographic tradition.

[12:08] <Bert> jdaggett: Kashida is an example.

[12:08] <Bert> ... Could apply to cursive in general.

[12:08] <Bert> ... Even if it is not currently used for latin.

[12:08] <Bert> SteveZ: Swash charcters?

[12:08] <Bert> ... They can go across words.

[12:08] <Bert> jdaggett: They extend?

[12:08] <Bert> SteveZ: yes

[12:09] <Bert> jdaggett: This is about alongating.

[12:09] <fantasai> s/along/elong/

[12:09] <Bert> ACTION fantasai: put examples of text-justify in the spec.

[12:09] * trackbot noticed an ACTION. Trying to create it.

[12:09] * RRSAgent records action 16

[12:09] <trackbot> Created ACTION-503 - Put examples of text-justify in the spec. [on Elika Etemad - due 2012-08-22].

[12:10] <Bert> ACTION sylvaing: look into history of text-justify in IE 5+

[12:10] * trackbot noticed an ACTION. Trying to create it.

[12:10] * RRSAgent records action 17

[12:10] <trackbot> Created ACTION-504 - Look into history of text-justify in IE 5+ [on Sylvain Galineau - due 2012-08-22].

[12:11] <Bert> issue-276?

[12:11] * trackbot getting information on ISSUE-276

[12:11] <trackbot> ISSUE-276 -- Split Text Decoration into separate module? -- raised

[12:11] <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/276

[12:11] <Bert> jdaggett: Why needed to split?

[12:11] <Bert> fantasai: module is very long.

[12:12] <Bert> ... text-deco no interaction with anything else in spec.

[12:12] <Bert> florian: Useful if that makes things faster. Does it here?

[12:12] <Bert> fantasai: Don;'t think so now. Maybe future levels may be different.

[12:12] <Bert> ... Table of contents makes more sense.

[12:13] <Bert> florian: Somewhat helpful for prioritizing.

[12:13] <Bert> ... Smaller spec easier.

[12:14] <Bert> jdaggett: I think the spec needs to be stronger. Take thinks to level 4.

[12:14] <fantasai> s/stronger/smaller/

[12:15] <Bert> ... This spec should be considered for what is specified and anot and push thibgs out accordingly.

[12:15] <Bert> ... DOn't think tetx-deco needs its own spec.

[12:15] <Bert> SteveZ: But splitting makes it easier.

[12:15] <Bert> tantek: Agree.

[12:15] <Bert> florian: I'm happy with split if editors want it and take on editing both.

[12:16] <Bert> jdaggett: *AND* not new features in either part.

[12:16] <Bert> fantasai: Agreed. No new features planned.

[12:16] <Bert> ... But we need to talk about one issue next.

[12:17] <Bert> bert: it is so hard to find in which spec a prop is defined.

[12:17] <lstorset> Handy CSS property index for split specs: http://meiert.com/en/indices/css-properties/

[12:17] <Bert> tantek: That is a glbal pb. Needs to be fixed.

[12:17] <Bert> glenn: snapshot?

[12:17] <Bert> fantasai: snapshot doesn't incude anything below CR.

[12:18] * Molly has joined #css

[12:18] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Ap%20{%20font-size%3A%203em%3B%20text-decoration%3A%20line-through%20}%0Aa%20{%20xpadding%3A%200.2em%3B%20}%0Aa%3Ahover%20{%20background%3A%20yellow%3B%20}%0A%3C%2Fstyle%3E%0A%3Cp%3Eone%20%3Ca%3Etwo%3C%2Fa%3E%20%3Ca%3Ethree%3C%2Fa%3E%20%3Ca%3Efour%3C%2Fa%3E%20%3Ca%3Efive%3C%2Fa%3E%20six

[12:18] <Bert> RESOLVED: split text-decoration into sepearet module.

[12:18] <Bert> issue-275?

[12:18] * trackbot getting information on ISSUE-275

[12:18] <trackbot> ISSUE-275 -- constant vs. varying text-decoration positions -- raised

[12:18] <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/275

[12:19] <Bert> issue-270?

[12:19] * trackbot getting information on ISSUE-270

[12:19] <trackbot> ISSUE-270 -- text-decoration-skip value for border/padding/margin -- raised

[12:19] <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/270

[12:19] <Bert> fantasai: [explains example above]

[12:19] <Bert> ... strange effects on hover.

[12:20] <Bert> ... imagine you're hovering over a link, with padding

[12:20] <Bert> ... the strike through is fragmented.

[12:20] <Bert> ... looks really bad.

[12:20] <Bert> dbaron: We discussed text-decaration models a lot.

[12:20] <Bert> ... We came up with one. Took many years to get it impleented.

[12:21] <Bert> ... FF implemented it. Now you say we don't want thtta model.

[12:21] * miketaylr Quit (Quit: Leaving...)

[12:21] <Bert> fantasai: Use case is editor's names on drafts.

[12:21] <Bert> ... I added padding around the links.

[12:21] <Bert> ... That broke strike trhrough.

[12:22] <Bert> ... Any kind of padding on inline elements will break it.

[12:22] <Bert> alan: padding is not content, text-decoration should not apply.

[12:23] <Bert> sylvaing: But underline doesn't stop under padding.

[12:23] <sylvaing> correction: it actually does

[12:23] <Bert> glazou: Say in an editor I select a paragraph, and it has modification marks, highlighted with line thrhough.

[12:23] <Bert> fantasai: But the para is a block.

[12:24] <Bert> ... Issue is if ancestor is striking through an elt.

[12:24] <Bert> dbaron: Proposal?

[12:24] <Bert> fantasai: I propose keyword 'box-decoration'

[12:24] <Bert> dbaron: On inline elts only?

[12:24] <Bert> fantasai: Yes.

[12:24] <dbaron> (display:inline, not inline-block, etc.)

[12:24] * jet_ has joined #CSS

[12:24] <Bert> ... If text-deco is pallied by ancestor

[12:25] <Bert> ... then is is applied from margin edge to margin edge.

[12:25] <Bert> tantek: We had long discussions long ago.

[12:25] <Bert> ... We all did something different with CSS2

[12:25] <Bert> ... We settled on a model that looks reasonable.

[12:25] <Bert> ... We had to make exceptions for blocks

[12:25] <fantasai> tantek^: about how box properties apply to inlines

[12:26] <Bert> ... This seems liek ame pb. We missed an exception.

[12:26] <Bert> ... Same case as how borders and bgs apply to boxes.

[12:26] <Bert> ... Rather than add property, we need to fix the definition.

[12:27] <Bert> ... We did it with borders and bg, I think we should try to do the same here.

[12:27] <Bert> glazou: It's only inline?

[12:27] * jet Quit (Ping timeout)

[12:27] * jet_ is now known as jet

[12:27] <Bert> fantasai: Yes, strictly.

[12:27] <Bert> ... Either define, or add value (or both).

[12:27] <fantasai> for text-decoration-skip

[12:27] <Bert> dbaron: We aren't yet interop on the CSS 2.1 behavior.

[12:28] <dbaron> dbaron: So I'm ok with it even though it's a change from 2.1.

[12:28] <Bert> tantek: Maybe apply an optimistic change and give authors a way to scream if it breaks pages.

[12:28] <Bert> ... Evaluate case by case, then change default accordingly.

[12:28] <Bert> glazou: I can live with proposed change.

[12:29] <Bert> ... MAkes no sens for non-inline.

[12:29] <Bert> fantasai: Should try to do it by default.

[12:30] <glazou> <br type="lunch" />

[12:30] * leaverou has joined #css

[12:31] <Bert> dbaron: Drawing the text-dco is thus independent of the text. Draws through margins.

[12:31] <Bert> florian: what does it mean?

[12:31] <Bert> dbaron: May be detecatable in cases with nested inlines.

[12:31] <Bert> ... E.g., with relative pos.

[12:31] * Zakim excuses himself; his presence no longer seems to be needed

[12:31] * Zakim has left #css

[12:33] <Bert> dbaron: Add new value to text-decoration-skip. Not part of initial value. Default is to draw decoration from margin edge to margin edge.

[12:33] <dbaron> difference between "from margin to margin" and "through inlines" is detectable with painting order, e.g., with <span padding><span relpos>text</span></span>

[12:33] <fantasai> Default is to draw decoration on margin/padding/border

[12:34] <dbaron> RESOLVED: Add a new value to text-decoration-skip controlling whether decorations are drawn through the padding/border/margin of display:inline elements. This new value is not part of the initial value and therefore (change from CSS 2.1) decorations are drawn through padding/border/margin of inlines by default.

[12:38] * Blatt has joined #css

[12:39] * miketaylr has joined #css

[12:43] * Molly thinks it must be lunch

[12:44] * Ms2ger Quit (Quit: nn)

[12:44] * Molly Quit (Quit: Page closed)

[12:51] * Blatt1 has joined #css

[12:53] * Blatt Quit (Quit: Page closed)

[12:54] * Blatt1 has left #css

[12:58] * Blatt has joined #css

[13:02] * jet_ has joined #CSS

[13:03] * jet Quit (Ping timeout)

[13:03] * jet_ is now known as jet

[13:09] * krit has joined #css

[13:13] * krit What is the skype handle for calling in?

[13:13] <fantasai> csswg?

[13:13] * fantasai not sure, should ask jdaggett

[13:14] <jdaggett> fantasai: i think daniel/tab knows the skype csswg username

[13:14] <jdaggett> not me

[13:16] * krit TabAtkins_? do you know the skype handle?

[13:26] * achicu has joined #css

[13:28] * Koji Quit (Ping timeout)

[13:28] * mvujovic has joined #css

[13:32] <fantasai> ScribeNick: fantasai

[13:32] * Zakim has joined #css

[13:32] <glazou> Zakim, make room for 3

[13:32] <Zakim> I don't understand 'make room for 3', glazou

[13:32] <glazou> Zakim, room for 3

[13:32] <Zakim> I don't understand 'room for 3', glazou

[13:33] <plinss> zakim, room for 3?

[13:33] <Zakim> ok, plinss; conference Team_(css)20:33Z scheduled with code 26631 (CONF1) for 60 minutes until 2133Z

[13:33] * vhardy_ has joined #css

[13:34] <Zakim> Team_(css)20:33Z has now started

[13:34] <Zakim> +??P0

[13:34] * vhardy__ has joined #css

[13:34] <glazou> Zakim, ??P0 is me

[13:34] <Zakim> +glazou; got it

[13:35] <glazou> krit: waiting for you on the call above

[13:35] <Zakim> +krit

[13:35] <krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html

[13:36] <fantasai> Vincent: FPWD request for filters

[13:36] * fantasai can't hear

[13:36] * vhardy_ Quit (Ping timeout)

[13:36] * hober krit: can you type whatever you're saying? it's hard to hear you

[13:37] <fantasai> krit: Are there any questions?

[13:37] <fantasai> krit^: Spec is a combination of predefined filter effects, SVG filter effects, and CSS shaders

[13:37] * krit I am sorry

[13:37] <fantasai> alan: SVGWG already agreed to publish

[13:38] * krit I don't hear anyone. Can you scribe?

[13:39] <fantasai> fantasai: Last time CSSWG discussed this, we concluded we wanted several "targets" of things to filter

[13:39] <glazou> krit: what's your skype id ?

[13:39] <fantasai> fantasai: One was the background, another was background + border as a single unit, another was borders only, another was content only, another was entire element as a whole

[13:39] <krit> krit85

[13:39] <glazou> krit: leaving the call now

[13:39] <Zakim> -glazou

[13:40] <fantasai> fantasai: Can I apply e.g. an opacity filter, or a blur filter, to any one of these things listed above?

[13:40] <fantasai> fantasai: If not, I think that's an issue

[13:40] <fantasai> hober: ok with just marking that as an issue

[13:40] <fantasai> fantasai: sure

[13:41] <cabanier> fantasai: are you thinking of blending and compositing?

[13:41] <cabanier> fantasai: It's in there. I haven't heard of doing this for filters too (but it makes sense)

[13:42] <fantasai> no idea what the technical term, only that we want to be able to apply filters to each part

[13:43] <fantasai> fantasai: We've had requests for background-fiter, border-filter, etc-filter (replace filter with opacity, or shadow, or whatever)

[13:43] <fantasai> fantasai: We decided we should do this generically with filters, rather than adding a new property for each

[13:43] <fantasai> fantasai: So this module needs to be accommodating those requests somehow

[13:43] <fantasai> ACTION krit: mark this as an issue

[13:43] * trackbot noticed an ACTION. Trying to create it.

[13:43] <trackbot> Sorry, couldn't find user - krit

[13:43] * RRSAgent records action 18

[13:44] * krit might be dschulze

[13:44] <fantasai> ACTION dschulze: mark this as an issue

[13:44] * trackbot noticed an ACTION. Trying to create it.

[13:44] * RRSAgent records action 19

[13:44] <trackbot> Created ACTION-505 - Mark this as an issue [on Dirk Schulze - due 2012-08-22].

[13:44] <fantasai> alan: Anything else?

[13:45] <Zakim> -krit

[13:45] <Zakim> Team_(css)20:33Z has ended

[13:45] <Zakim> Attendees were glazou, krit

[13:45] * fantasai is a little confused why everything's prefixed with FE but supposes that's inherited from SVG?

[13:46] <fantasai> RESOLVED: Publish Filters FPWD

[13:46] <fantasai> Topic: Masking

[13:46] <fantasai> Topic: Transforms

[13:46] <krit> http://dev.w3.org/csswg/css3-transforms/#animation

[13:47] <fantasai> krit: Talked about interpolation, and request for some tests

[13:47] <fantasai> krit: All browsers do ?

[13:47] <fantasai> krit: All browsers do matrix decomposing

[13:47] <fantasai> krit: ...

[13:48] <krit> http://wiki.csswg.org/topics/interpolation-rotate3d

[13:48] <fantasai> krit: Let me post a link

[13:48] <fantasai> krit: What I tested was browsers interpolation on rotate3d

[13:48] <fantasai> krit: Actually looks like all browsers do magic decomposing (matrix decomposing)

[13:49] <fantasai> ????

[13:49] * fantasai gives up

[13:49] * fantasai suggests sylvaing minutes, since he's near the mic

[13:49] <fantasai> krit: Suggest we always to matrix decomposing

[13:49] <dbaron> s/Suggest/Suggest that when rotate3d() is involved/

[13:49] <krit> for rotate3d we always decompose with matrix

[13:49] * jet Quit (Quit: jet)

[13:50] <krit> thats is what all browsers do with the exception of chrome

[13:50] <krit> chrome does number interpolation if the roatate is arround 0,0,1

[13:50] <krit> 0,10

[13:50] * Koji has joined #css

[13:50] <krit> or 1,00

[13:51] <krit> I can change the behavior of Chrome in WebKit to match all other browsers

[13:51] <fantasai> fantasai: Is matrix decomposition satisfactory for what users would want to do?

[13:51] <krit> I would expect that useres want number interpolation

[13:51] <krit> but that is not what browsers seem to do

[13:52] <fantasai> dbaron: Not that great

[13:52] <krit> It seems unlikely that IE10 can change the behavior

[13:52] <krit> it is already ready for shipping

[13:54] * krit can someone scribe? I can't hear you

[13:54] * achicu Quit (Quit: achicu)

[13:54] <stearns> sylvaing: current behavior is used in our app frameworks - could be tricky to change

[13:54] <stearns> <silence>

[13:55] * krit ok :)

[13:55] <hober> hober: i'm happy with krit's proposal on this issue

[13:55] <sylvaing> it will be harder if we depend on the unprefixed version of the feature; also depends on other live content that may use this.

[13:55] <fantasai> fantasai: So do we really want to lock that in? or just consider it a bug ?

[13:56] <krit> A bug in browsers or implementation?

[13:56] <fantasai> sylvaing: It's hard for us because we use this in our app frameworks.

[13:56] <fantasai> fantasai: Usually the problem is switching behavior from a numeric interpolation case to a matrix decomposition one

[13:56] <fantasai> fantasai: Other way around I understood from last time was not so much of a problem

[13:56] <fantasai> TabAtkins: In first case, where everything's the same, would expect angle.

[13:56] <fantasai> TabAtkins: But where vectors are different, would be weird.

[13:56] <fantasai> TabAtkins: Even if we do numeric interpolation, interpolating the 3 args numerically is probably not what authors want.

[13:56] <fantasai> dbaron: I think we want numeric interpolation when the 3 components are the same

[13:56] <fantasai> TabAtkins: That would be minimally good

[13:56] <fantasai> TabAtkins: That would at least allow rotation along an axis that is not x/y/z

[13:57] <fantasai> dbaron: If authors want something more complicated to animate, then they have to explicitly split it up the way they want

[13:57] <krit> I am unsure if Safari can implement numerical interpolation for rotate3d in general

[13:57] <fantasai> fantasai: Seems better than matrix decomp

[13:58] <fantasai> TabAtkins: So question is, do we normalize the vector before comparison?

[13:58] <fantasai> Vincent: Don't think that'll work

[13:58] <fantasai> krit: Spec wants the vectors to be normalized

[13:58] <fantasai> krit: Safari doesn't, sticks on CoreAnimation

[13:58] <fantasai> krit: Can't do numeric interpolation

[13:59] * decadance Quit (Quit: leaving)

[13:59] <fantasai> sylvaing: That's their problem.

[13:59] <fantasai> krit: This will mean that you'll have different behavior on Safari than other browsers

[13:59] <fantasai> TabAtkins: Not strictly true. Safari just has to do some additional bookkeeping

[13:59] * decadance has joined #css

[14:00] <fantasai> dbaron suggests doing this on a telecon

[14:00] <fantasai> Proposal A: rotate3d() always uses matrix decomposition

[14:01] <fantasai> Proposal B: rotate3d() uses numeric interpolation when the first 3 arguments (defining the axis) match

[14:01] <fantasai> Proposal C: roate3d() uses numeric interpolation when the first 3 arguments (defining the axis) match *after normalizing the vector*

[14:01] <fantasai> A is implemented right now, but what authors will want

[14:02] <fantasai> is B or C

[14:02] <hober> RRSAgent: url?

[14:02] <RRSAgent> I'm logging. Sorry, nothing found for 'url'

[14:02] <fantasai> because otherwise can't rotate along axes other than xyz

[14:02] <fantasai> krit: There is no B, spec says they are normalized

[14:02] <plinss> rrsagent, pointer?

[14:02] <RRSAgent> See http://www.w3.org/2012/08/13-css-irc#T21-02-43

[14:02] <fantasai> TabAtkins: At what stage? Does it say computed values are normalized?

[14:02] * hober plinss: how intuitive

[14:02] <fantasai> TabAtkins: If not, we can say that

[14:03] <dbaron> The spec says it's normalized, but doesn't say when, so it's basically meaningless.

[14:03] <fantasai> plinss: Only place that user would notice is when rotate takes you back where you came from?

[14:03] <fantasai> dbaron: No, lots of cases

[14:03] <fantasai> dbaron: If you decompose a 90deg rotation into 2 components, won't do exactly the same thing

[14:04] <fantasai> dbaron: The bigger the angular difference, the more noticeable it is

[14:04] <fantasai> dbaron: Past 180deg, will notice greatly because might get different direction of rotation

[14:04] <fantasai> dbaron: or different number of rotations.

[14:04] <dbaron> krit: Animating from negative vector to positive vector?

[14:04] <dbaron> dbaron: Just count as a mismatched vector.

[14:05] <fantasai> fantasai: So we're down to A or C.

[14:05] <fantasai> fantasai: I think we should go with C, since that's what authors will want.

[14:05] <fantasai> hober: Go with A, that's what's implemented

[14:06] <fantasai> TabAtkins: This isn't a compat issue, so we don't need to do bugwards compat

[14:07] <fantasai> plinss: My concern is that sometimes you get matrix decomposition behavior, and some cases you don't. Will authors be surprised about that?

[14:07] <fantasai> hober, TabAtkins: it's predictable

[14:07] <fantasai> TabAtkins: If the vector is the same, we interpolate otherwise not

[14:08] <fantasai> Vincent: We have two vectors, right, we could ... even if they don't match

[14:09] <fantasai> Vincent: Could do better behavior than decomposing

[14:09] <fantasai> plinss: That would be less surprising to the author, I think

[14:09] <fantasai> TabAtkins: So that would be option D, fully define interpolation

[14:10] <fantasai> dbaron: There are a bunch of places where you'll have to make a lot of arbitrary decisions

[14:10] <dbaron> dbaron: special behavior for antiparallel vectors? If so, use that behavior for any >90deg angle? What about 90deg angles?

[14:10] <fantasai> hober: Would be nice if Simon were here for this

[14:11] <fantasai> plinss: Anyone want to take an action to try to define D

[14:11] <fantasai> ACTION Vincent: Write a proposal for vector interpolation for rotate3d()

[14:11] * trackbot noticed an ACTION. Trying to create it.

[14:11] * RRSAgent records action 20

[14:11] <trackbot> Created ACTION-506 - Write a proposal for vector interpolation for rotate3d() [on Vincent Hardy - due 2012-08-22].

[14:12] <fantasai> plinss: anything else?

[14:12] <fantasai> krit: Can we publish after decision about rotate3d()?

[14:12] <fantasai> plinss: How far are we from LC?

[14:13] <fantasai> krit: Some minor issues, would also like to publish WD and ask for review before going to LC

[14:13] <fantasai> plinss: Asking if this is last WD before LC

[14:13] <fantasai> RESOLVED: Publish WD of Transforms after rotate3d() is resolved

[14:14] <dbaron> s/rotate3d()/rotate3d() animation/

[14:14] * Blatt Quit (Quit: Leaving.)

[14:14] <dbaron> The other issue, by the way, is whether "falling back to matrix interpolation" means for the function or for the entire list.

[14:14] <krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html

[14:14] <dbaron> I think it should be just for the function.

[14:14] <fantasai> krit: CSSWG decided to apply masking to HTML content, SVG WG ants to work together with CSSWG

[14:14] <fantasai> krit: So we made FXTF draft for masking

[14:14] * Bert noticed that editor's draft has a rotate3d() with only 3 args in section 18. Typo?

[14:14] <fantasai> krit: It's a proposal that just specifies ... for browsers

[14:15] <fantasai> krit: We have Firefox that .. and we have Webkit that does something with masking

[14:15] <fantasai> krit: Specification which tries to address both proposals

[14:15] <fantasai> krit: Two different sets of properties

[14:15] <fantasai> krit: One is mask-image, similar to bg image

[14:15] <fantasai> krit: idea is that authors don't need to learn new syntax for it

[14:15] <fantasai> krit: syntax is exactly the same

[14:15] <fantasai> krit: behavior is same, just with masking

[14:16] <fantasai> krit: masking process ... filter

[14:16] <fantasai> krit: There's also 2nd set of properties mask-box-image

[14:16] <fantasai> krit: similar to border-image

[14:16] <krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#mask-box-image

[14:16] * drublic_ has joined #css

[14:16] * drublic Quit (Ping timeout)

[14:16] <fantasai> krit: Does CSSWG want to go with this approach?

[14:16] <fantasai> krit: any concerns about this?

[14:17] <fantasai> fantasai: Are there use cases for all these properties?

[14:17] <fantasai> krit: They are quite useful, easier/ more poweful than SVG masking

[14:17] <fantasai> krit: So think it's very useful

[14:18] <fantasai> krit: ...

[14:18] <fantasai> krit: mask-box-image, used quite a lot

[14:18] <fantasai> krit: still a feature that's heavily used on mobile devices today

[14:18] <fantasai> fantasai: My opinion is basically if roc thinks it's a good idea, it's good

[14:19] <fantasai> hober: harmonizing webkit-mask with SVG is a no-brainer, should continue to work on it

[14:19] <fantasai> dbaron: Would like a chance for other to people look at it

[14:19] <fantasai> krit: roc said same thing as you, fantasai

[14:20] <fantasai> Vincent: Goal was to see if group thinks its a good idea to work on this

[14:21] <fantasai> fantasai: Think it's good to work on this, think that idea of aligning with existing properties seems smart,

[14:21] <fantasai> fantasai: Think that in cases where the values match an existing property, should refer to the definitions in the existing property rather than repeating it

[14:22] <fantasai> e.g. postion should refer to definition of <position> in css3-background rather than duplicating it

[14:22] <fantasai> dbaron: I'm a little unsure how high priority this should be

[14:22] <fantasai> dbaron: There's been some stuff in webkit for awhile

[14:22] <fantasai> dbaron: we've had a huge a mount of pressure for TTA, but not so much for masking

[14:23] <fantasai> dbaron: That makes me think that there are a bunch of other things this group works on that are probably higher priority than this

[14:23] <fantasai> krit: I can't disagree with that of course

[14:23] <fantasai> krit: We want to address this in SVGWG, so don't see how it can harm the CSSWG

[14:24] <fantasai> hober: In the contextof is it a priority, I've certainly had on my to-do item to spec -webkit-mask, so thankful to dirk for taking this on

[14:24] <dbaron> s/TTA/transforms, transitions, and animations/

[14:24] <fantasai> Bert: I have two questions

[14:24] <fantasai> Bert: Since 'clip' has never been used, why would 'mask' be used more?

[14:25] <fantasai> Bert: Second, isn't this a kind of filter

[14:25] <fantasai> TabAtkins: We have lots of examples of -webkit-mask being used on the Web

[14:25] <fantasai> krit: Used a lot for images and videos

[14:25] <fantasai> krit: clip-mask can also be used similar to shapes in CSS exclusions

[14:26] <fantasai> krit: I'm fine to specify if CSSWG wants

[14:26] <fantasai> fantasai: Speccing something that replaces -webkit-mask with a standard feature seems like a good idea

[14:27] <fantasai> hober: And doing it in a way that harmonizing with SVG is good

[14:27] <fantasai> krit: Been in Webkit for 4 years

[14:28] <fantasai> Leif: Not handled by other spec?

[14:28] <fantasai> TabAtkins: Theoretically could be a filter, but like box-shadow, something that seems ot benefit from having its own property. Also SVG has its own masking already anyway

[14:29] <fantasai> Mask the filters? :)

[14:29] <dbaron> krit, also http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html should say who the Editors are

[14:29] <fantasai> krit: In SVG, masking, then filters, then clipping is separate step

[14:29] <fantasai> jdaggett: Should we move on?

[14:30] <fantasai> Topic deferred, giving dbaron &co to ask others for feedback

[14:30] <fantasai> Topic: Writing Modes

[14:30] * vhardy_ has joined #css

[14:30] * vhardy__ Quit (Connection reset by peer)

[14:31] <fantasai> koji: In the end I would like one working group resolution, so would like to start from some background.

[14:32] <fantasai> koji: UTR50 started last August

[14:32] * vhardy_ Quit (Quit: vhardy_)

[14:32] <fantasai> koji: At that point, there was a problem that UTR50 defines it scope to capture major us in Japanese, and there was probably a little different from what fantasai wanted for CSS3 Writing Modes

[14:32] <fantasai> koji: So after UTR50 draft 1 was done, there was a lot of feedback

[14:33] <fantasai> koji: But rather tha each codepoint issue, of upright vs. sideways, but what is scope and goal of UTR50 and scope/goal of Wirting Modes

[14:33] <fantasai> koji: The editor, Eric, set scope to Japanese

[14:33] <fantasai> koji: Most feedback I saw was scope should be global rather than Japanese

[14:33] <fantasai> koji: Other feedback like multi-language / math expressions shoudl be handled

[14:33] <fantasai> koji: Some people wnat that consistency by ignoring osme legacy usage

[14:34] <fantasai> koji: Some people want better typogrpahy than what's used today

[14:34] <fantasai> koji: Some issues resolved by discusison, but in the end , everyone wants different scope for UTR50 and discussion was stuck, and that's what I saw before the UTC

[14:34] <fantasai> jdaggett: I don't think that's a fair representation because the basis of UTR50 was to make the default orientation a character proeprty

[14:34] <fantasai> jdaggett: To not be a combination of other properties and font information

[14:35] <fantasai> jdaggett: The original draft of Writing Modes had that as the defining factor of orientation

[14:35] <fantasai> jdaggett: The goal of UTR50 was to give us a defautl distinction, that at least set Latin sideways, and kanji upright

[14:35] <fantasai> jdaggett: beyond that, I don't think it's as important

[14:35] <fantasai> koji: Everyone agrees with that

[14:35] <fantasai> koji: Issues is about symbols

[14:35] <fantasai> jdaggett: Key point is that this thing have consistency

[14:36] <fantasai> jdaggett: Specifics of whether one symbols is upright/sideways is much less important

[14:36] <fantasai> jdaggett: Just trying to set a set of reasonable default

[14:36] <fantasai> jdaggett: If you're talking about math expressions in vertical text, you're off in the weeds

[14:36] <fantasai> jdaggett: What has come out of UTC and the mail you sent around, this is the scope

[14:36] <fantasai> jdaggett: That is much more confined scope, I'm fine with that

[14:36] <fantasai> koji: The UTC resolved to tighten the scope

[14:36] <fantasai> koji: Now UTR50 scope is Japanese and then East Asian

[14:37] <fantasai> koji: And it's goal is interchangeability rather than better typography

[14:37] <fantasai> koji: And to capture major use

[14:37] <fantasai> florian: So they won't address non-EA things?

[14:37] <fantasai> koji: I misunderstood at first point, but scope they mean priority

[14:37] <fantasai> fantasai: Scope is all of Unicode

[14:38] <dbaron> fantasai: Figure it out for all of Unicode -- the question is when different usage has conflicting requirements, then usage in East Asia win

[14:38] <fantasai> koji: For that, usage in East Asia wins, and Japanese wins over that

[14:38] <fantasai> koji: For some scripts, Unicode defines its scope to being able to write about such scripts, but not to write its native scripts

[14:38] <dbaron> Florian: ...

[14:38] <dbaron> jdaggett: and that's precisely why we shouldn't bikeshed on this

[14:38] * jet has joined #CSS

[14:39] <fantasai> koji: Basic idea is goal of UTR50 is to interchange

[14:39] <fantasai> koji: For various specific applications, encouraged to tailor

[14:39] <fantasai> koji: So UTR50 resolved to go back or tighten the scope

[14:40] <fantasai> koji: means if we follow UTR50, CSS Writing Modes scope would match that of UTR50

[14:40] <fantasai> Florian: Question is They have changed the way they define everything, are we ok with that.

[14:40] <fantasai> jdaggett: As long as there's not an uproar, then it's okay

[14:41] <dbaron> fantasai: UTC's scope document (UTC member confidential) seemed reasonable to me

[14:41] <dbaron> fantasai: though one point I wanted clarified

[14:42] <dbaron> jdaggett: I think writing mode should just say that ... is defined by this property over here in Unicode.

[14:42] <dbaron> fantasai: I think we just need them to publish a draft that has known errors fixed.

[14:42] <dbaron> jdaggett: Koji, I'm upset that you were going to UTC meeting as representative of this group without informing us what was going on before it.

[14:43] <dbaron> koji: I apologize for that.

[14:43] <dbaron> koji: I prefer to use UTR50 as is, and I want to make sure everyone is ok with that.

[14:43] <dbaron> jdaggett: I think we're all fine.

[14:43] <dbaron> koji: UTC resolved not to do SVO for the first version.

[14:43] <dbaron> koji: writing mode has text-orientation: upright. Discussion about whether upright is forced or smart.

[14:43] <dbaron> koji: e.g., parentheses being upright

[14:44] <dbaron> koji: UTC had resolved to add SVO to solve that

[14:44] <dbaron> jdaggett: I think we should make text-orientation: upright be upright always

[14:44] <dbaron> jdaggett: authors who want sideways parentheses should use sideways (or mixed)

[14:44] <dbaron> koji: Could defer smart upright or define our own properties

[14:44] <dbaron> fantasai: or refer to existing draft tables.

[14:45] <dbaron> florian: it's an option, but we shouldn't pick it

[14:45] <dbaron> jdaggett: It's only an illusion that this is smart. It only goes so far. It many situations it will not look right.

[14:45] <dbaron> florian: This kind of table can only be maintained by Unicode.

[14:45] <dbaron> Steve: I'd propose we either drop upright or leave it as forced upright as Koji suggested.

[14:46] <dbaron> Steve: And we have the option, later, if a table for smart upright is later defined that we think is worth adopting, we have the option of adding a value to use that.

[14:46] <dbaron> Florian: I think that's fair.

[14:46] <dbaron> fantasai: My original intention with text-orientation that all values would be usable at a span level or at a paragraph level.

[14:46] <dbaron> fantasai: If upright becomes forced-upright then forced upright is only usable on a particular span, because it breaks on hyphens, brackets.

[14:47] <dbaron> fantasai: I don't see a use case where forced upright is better than upright.

[14:47] <dbaron> Steve: Do you want to take upright out?

[14:47] <dbaron> Steve: We don't have a definition of what smart upright would do.

[14:47] <dbaron> jdaggett: We need upright in some situations.

[14:47] <dbaron> jdaggett: Need to have it for making Latin upright.

[14:47] <dbaron> Florian: I think we're in agreement.

[14:48] <dbaron> fantasai: I'm not happy with upright being a forced upright, but I'm not going to override the WG.

[14:48] <dbaron> fantasai: I don't think there's a use in having ...

[14:48] <dbaron> fantasai: We could use the data that are already there.

[14:49] <dbaron> Florian: I think having smart upright would be nice, but I wouldn't do it before Unicode defines and maintains what it means.

[14:49] <dbaron> jdaggett: I think smart-upright is an illusion.

[14:49] <dbaron> koji: UTC had some discussion on this, and they may add the value of ??? in the future.

[14:49] <dbaron> Bert: Can you explain difference between smart and forced?

[14:50] <dbaron> fantasai draws "(some-text)" in both forced and smart upright

[14:50] <dbaron> jdaggett: With a regular font this isn't going to work, because regular fonts don't have vertical metrics.

[14:51] <dbaron> fantasai: IF you have a font that has vertical metrics, or you're using capital letters...

[14:51] <dbaron> fantasai: People want to do this on book spines and things -- to get this effect, you need to put spans around ( - and )

[14:51] <dbaron> jdaggett: For the set of use cases here I think that's acceptable.

[14:51] <dbaron> alan: esp. if you have to modify the spans individually for the lack of font metrics

[14:51] <dbaron> fantasai: If you don't have vertical metrics you might as well use ...

[14:52] <dbaron> Florian: I understand that smart upright is valuable, and I think we can pursue it in the next level based on what's going on in Unicode.

[14:52] <dbaron> Peter: We're still calling the value 'upright'?

[14:52] <dbaron> jdaggett: If you have smart upright, then you have no way of forcing character to upright

[14:53] <dbaron> fantasai: You could use tate-chu-yoku.

[14:53] <dbaron> RESOLUTION: text-orientation:upright is a forced upright; it always means upright

[14:53] * fantasai is sad we are resolving to add a feature that has no use case

[14:53] <dbaron> koji: Excel does forced upright up until 2007; switched to smart upright in 2007. Been doing vertical writing since 1995.

[14:54] <dbaron> koji: Last one is HO property is being removed from UTR50 draft 7.

[14:55] <dbaron> jdaggett: Mongolian and Phags-Pa are vertical-only languages, but for convenience when they are discussed in English text they are often rotated into the horizontal

[14:55] <dbaron> jdaggett: The way the fonts are designed -- typically designed rotated 90 degrees.

[14:55] <dbaron> jdaggett: The HO property was to call out set of scripts that have this behavior -- scripts that are vertical only but rotated left when displayed horizontally

[14:55] <dbaron> Glenn: Goes back to history of Mongolian

[14:56] <dbaron> [discussion of history of scripts]

[14:56] <dbaron> jdaggett: It was never really a very important property, because it just said whether the script was Mongolian or Phags-Pa.

[14:57] <dbaron> Koji: Some points have different orientation of glyphs from the Unicode code chart.

[14:57] <dbaron> Koji: So to make visually correct orientation you have to render differently from UTR50.

[14:57] <dbaron> Koji: Because UTR50 reflects against code charts, and code charts and fonts don't match.

[14:58] <dbaron> jdaggett: Summarizing: the handling of Phags-Pa and Mongolian is different from other scripts in the way you deal with orientations, and you can leave it to implementations to figure that out.

[14:58] <dbaron> (before prev line) Koji: ...

[14:58] <dbaron> Steve: Using the horizontal metrics in vertical settings

[14:59] <dbaron> jdaggett: Spec can write a simple sentence saying that the way fonts are designed for Mongolian and Phags-Pa are unique, and implementations need to deal with that separately.

[14:59] <dbaron> fantasai: Problem is that the Unicod ecode charts have it upright as though in vertical text, but fonts have it sideways assuming reference is horizontal text.

[14:59] * mvujovic Quit (Quit: Leaving.)

[14:59] <dbaron> Steve: Just the way people historically made the fonts.

[15:00] * mvujovic has joined #css

[15:00] <dbaron> Bert: schedule?

[15:00] <dbaron> jdaggett: I think the draft needs cleanup first.

[15:00] <dbaron> fantasai: Also need to wait for UTR50 to publish an update.

[15:00] <dbaron> Steve: As long as it's in something equivalent to last call or one step away from...

[15:01] * achicu has joined #css

[15:01] <dbaron> jdaggett: First we need a WD that just says [...]

[15:01] <dbaron> jdaggett: The ED right now points at a fictitious property.

[15:01] <dbaron> Bert: What schedule do we expect? LC soon?

[15:01] <dbaron> jdaggett: Depends on edits Koji makes in Unicode.

[15:02] <dbaron> jdaggett: ... incorporates changes that have been discussed. Draft 7 will. Expect to publish next UTC (November).

[15:02] <dbaron> s/jdaggett/koji/

[15:02] <dbaron> koji: UTC has public review period after the draft. If people agree with it, could go quickly.

[15:03] <dbaron> jdaggett: First step is to get a WD that says ...

[15:03] <dbaron> fantasai: Other thing we were blocked on was an objection from Glenn on the naming of the logical directions.

[15:03] <dbaron> Glenn: before/after vs. head/foot

[15:03] <dbaron> Steve: Glenn made one objection, Murakami-san made one, I'm unhappy (but only unhappy)

[15:04] <dbaron> jdaggett: Can we put an issue in the spec labeling this as an objection?

[15:04] <dbaron> GLenn: Don't want to block this; I'm in the unhappy category.

[15:04] <dbaron> Glenn: Some concern about cultural notion of head and foot.

[15:04] <dbaron> jdaggett: Why can't we mark this as an issue?

[15:04] <dbaron> jdaggett: shouldn't block this as a WD

[15:04] <dbaron> [agreement, it seems]

[15:05] <dbaron> [desire to resolve before LC]

[15:05] <dbaron> Steve: Are people willing to reconsider this or should we go away and give up?

[15:05] <dbaron> Florian: I'd prefer not to reconsider.

[15:05] <dbaron> Peter: I'd prefer not to discuss discussing it right now.

[15:06] <dbaron> Peter: We'll rename it before we go to last call. :-)

[15:06] <dbaron> Topic: Lists

[15:06] <fantasai> ScribeNick: fantasai

[15:06] <fantasai> TabAtkins: There are two issues to talk about

[15:06] <fantasai> TabAtkins: This has been sitting in WD because nobody has reviewed the draft yet

[15:06] <fantasai> TabAtkins: Would like to advance the spec

[15:07] <fantasai> TabAtkins: Otherwise I'll request LC

[15:07] <fantasai> TabAtkins: In simplest case, marker positions are same

[15:07] <fantasai> TabAtkins: Outside that, all implementations have different ideas of how markers are positioned

[15:07] <fantasai> TabAtkins: spec is similar to what IE does, because that was sanest

[15:07] <fantasai> Rossen: 3 years ago looked at it

[15:08] <fantasai> Rossen: We spent a ton of time looking at list markesr and looked at all the different implementations

[15:08] <fantasai> Rossen: As soon as you have anything other than simplest possible text with marker inside, all hell broke loose

[15:08] <fantasai> dbaron: There's a section called marker positoining, but nowhere near long enough to cover all this

[15:08] <fantasai> TabAtkins: Split across marker position and marker attachment

[15:09] <fantasai> TabAtkins: Actual definition in Ch 7

[15:09] <fantasai> TabAtkins: 7.1 defines behavior in terms of terms, and what that means.. then defined in ... right there

[15:09] <dbaron> http://dev.w3.org/csswg/css3-lists/#positioning-markers

[15:10] <fantasai> TabAtkins: If it's incomplete, please give me feedback. Correct me on anything that's wrong.

[15:10] <fantasai> TabAtkins: Counter handling. Everybody is pretty sane on this

[15:10] <fantasai> TabAtkins: Tried to tighten up definitions in the spec

[15:10] <fantasai> TabAtkins: Added the counter-set property, equivalent to counter-reset, except doesn't create a new scope

[15:10] <fantasai> TabAtkins: This is required if you want to implement HTML's value attribute in terms of CSS

[15:11] <fantasai> TabAtkins: same as counter-increment, just sets to explicit value intead

[15:11] <fantasai> TabAtkins discusses some weird case

[15:12] <fantasai> TabAtkins: I defined the ::marker pseudo-element

[15:12] <fantasai> TabAtkins: So you can style it, e.g. color the marker

[15:12] <fantasai> TabAtkins: Can be done right now with hacks and markup tweaks, rather annoying to do

[15:13] <fantasai> TabAtkins: marker-attachment property, was put in at request of bidi requirements groups

[15:13] <fantasai> TabAtkins: To address the problem of list markers appearing on the wrong side

[15:13] <fantasai> dbaron: I think this is a bad name

[15:14] <fantasai> TabAtkins explains the use case

[15:15] <fantasai> dbaron: We had a really long discussion about this at a TPAC

[15:15] * arno has joined #css

[15:16] <fantasai> dbaron: Given that there's a whole bunch of issues with whether the marker follows text-align stuff, or whether it moves around floats, 'marker-attachment' sounds like it addresses those issues, and it doesn't

[15:16] <fantasai> dbaron: maybe 'marker-side' or 'marker-direction'

[15:16] * hober marker-direction-follows: [parent | list-item]

[15:16] <fantasai> Rossen: If it's an arrow, if it points to the left or the right? :)

[15:17] <fantasai> plinss asks about marker direction of contents

[15:17] * sylvaing boustrophedon lists?

[15:17] <fantasai> TabAtkins: Last thing is inline list items

[15:18] * jarek has joined #css

[15:18] <fantasai> dbaron: Does it support list-style-position: outside

[15:18] <fantasai> TabAtkins: Hm, probably should

[15:18] <fantasai> TabAtkins: Ok, those were changes that need review

[15:18] <fantasai> TabAtkins: Let's start with one jdaggett is pacing about

[15:18] <fantasai> TabAtkins: Which is the question of user-defined identifiers

[15:18] <fantasai> TabAtkins: Do we preserve the case of user-defined idents?

[15:19] <fantasai> TabAtkins: ASCII case-fold?

[15:19] <fantasai> TabAtkins: ..

[15:19] <fantasai> http://wiki.csswg.org/topics/custom-ident-case-sensitivity

[15:20] <stearns> jdaggett: we should design a simple system

[15:20] <stearns> jdaggett: this is not very important

[15:21] <stearns> jdaggett: CSS is otherwise case-insensitive

[15:21] <fantasai> TabAtkins: Interesting thing here is that @counter-style lets you redefine idents, including case-insensitive ones in CSS2.1

[15:21] <fantasai> jdaggett: users expect it to be case-insensitive

[15:21] <fantasai> TabAtkins: So proposal is to make them case-insensitive, figure out which kind it is

[15:22] <fantasai> jdaggett: Not always the best ways, but define something simple

[15:22] <fantasai> jdaggett: for where handled within itself

[15:22] <fantasai> Florian: Seems reasonable, but what do you do on the OM side of things?

[15:22] <fantasai> Florian: Does the OM output the saem case as input or lowercase or what?

[15:23] <fantasai> TabAtkins: Just do whatever OM does for idents

[15:23] <fantasai> fantasai: What idents do depends on whether it's a predefined keyword or not

[15:24] <fantasai> jdaggett: There are user idents in @font-feature rules

[15:24] <fantasai> Florian: From an author point of view, jdaggett's proposal is best.

[15:24] <fantasai> Florian: Question is if we will get this right on implementation side

[15:25] <fantasai> dbaron: What is jdaggett proposing?

[15:25] <fantasai> fantasai: Unicode lowercasing

[15:25] <fantasai> dbaron: In some cases where there are user-defined idents, we want a mechanism for fast comparison

[15:25] <fantasai> dbaron: such as atomization

[15:26] <fantasai> dbaron: if there isn't a function that you can get a unique thing that you can compare, then we have a problem

[15:26] <fantasai> dbaron: some unicode case comparisons that don't give you that

[15:26] <smfr> animation keyframes use user idents too, which are exposed to JS via animation events

[15:26] <fantasai> jdaggett: You might be thinking of full case mapping

[15:26] <fantasai> jdaggett: Unicode has simple case mapping and full case mapping

[15:27] <fantasai> jdaggett: full case mapping doesn't preserve lenght of a string, e.g. eszet will become double capital S

[15:27] <fantasai> jdaggett: There's also a simple set that preserves length of string

[15:28] * drublic_ Quit (Client exited)

[15:28] <fantasai> fantasai raises issue of lowercasing, uppercasing, case-folding

[15:28] * drublic has joined #css

[15:28] <fantasai> ACTION jdaggett: propose case-comparison proposal

[15:28] * trackbot noticed an ACTION. Trying to create it.

[15:28] * RRSAgent records action 21

[15:28] <trackbot> Created ACTION-507 - Propose case-comparison proposal [on John Daggett - due 2012-08-22].

[15:28] * achicu Quit (Quit: achicu)

[15:29] * mvujovic Quit (Quit: Leaving.)

[15:29] <fantasai> TabAtkins: Should we resolve on ASCII-case-insensitivity

[15:29] <fantasai> jdaggett: Uncertain about that

[15:29] <fantasai> TabAtkins: It's in the platform, HTML has it in a number of places too

[15:29] <fantasai> Bert: Agree with jdaggett that it's a weird thing

[15:29] * mvujovic has joined #css

[15:30] <fantasai> TabAkins: I'm concerned about going back to case-sensitive

[15:30] <fantasai> plinss: So we're proposing to make idents case-insensitive in a form TBD

[15:30] <fantasai> dbaron: I'd also like to resolve that the form will support atomization

[15:30] <fantasai> dbaron: There has to be some conversion you can do once, such that you can do atomization

[15:31] <fantasai> fantasai: I think that's true for all of the casing optimizations.

[15:31] <fantasai> fantasai: You just can't do round-tripping.

[15:31] <fantasai> plinss: What about Unicode normalization?

[15:31] * drublic Quit (Ping timeout)

[15:32] <fantasai> plinss: These identifiers are going to cross document boundaries, and cross into script. entirely possible that multiple style sheets applying to one page are generated by different people with different editors with different normalizations

[15:32] <fantasai> jdaggett: then they will not match

[15:32] <fantasai> dbaron: If we want to fix that, then we want to normalize the whole sheet as parse time

[15:32] <fantasai> TabAtkins: I don't think you can avoid perf problems without doing that.

[15:32] <fantasai> dbaron: You have to do it in so many different places.

[15:33] <fantasai> dbaron: Unless you can test this for everything

[15:33] <fantasai> fantasai: I think if we had a normalization form that worked for content, we could normalize the entire web platform on parse, and it'd be fine. But we don't have that.

[15:35] <fantasai> fantasai: So I don't think we can do normalization until we have a normalization form that works.

[15:35] <fantasai> plinss: That's valid feedback to i18n

[15:36] <fantasai> plinss: This issue keeps coming up

[15:36] * Zakim excuses himself; his presence no longer seems to be needed

[15:36] * Zakim has left #css

[15:36] <fantasai> RESOLVED: user-idents in CSS are case-insensitive, insensitivity of a type TBD

[15:37] <dbaron> ... but where the type of case comparison allows for atomization and hashing via a single up-front conversion

[15:38] <fantasai> Topic: Counter Styles

[15:38] <fantasai> fantasai: Previous discussion was to have counter styles in a different document

[15:39] <fantasai> fantasai: Proposal is to put @counter-style with them

[15:39] <fantasai> Florian: Point of splitting was to not put the counter styles list on the REC track

[15:40] <dbaron> The definition of Caseless Matching (Case Folding) in Unicode 6.0 section 5.18 actually seems like it would be ok.

[15:40] <Bert> scribe: Bert

[15:40] <Bert> fantasai: Definitions of all counter styles in 2.1 make a good module.

[15:41] <Bert> ... Finsihed and complete, after case-insens inssue.

[15:41] <Bert> ... All the rest deals with a lot of things, not near LC

[15:41] <Bert> ... It is holding up counter style

[15:41] <Bert> ... So we might as well give it is own title

[15:41] <Bert> jdaggett: As bare minimum ou need to [???]

[15:42] <Bert> ... Splitteing counter-style

[15:42] <stearns> s/???/address OM/

[15:42] <Bert> TabAtkins_: Takes 5 mins to define.

[15:42] <Bert> ... As soon as I have a checkout of the tetx.

[15:43] <Bert> florian: jdaggett has an opinion, but not as strong as whether or not to define long list of counter styles normatively.

[15:43] <Bert> ... We should on defining that long list.

[15:43] <Bert> ... I vote for not.

[15:43] <Bert> glenn: define whats in 2.1 and thats it.

[15:43] <Bert> fantasai: Do't want to limit ot 2.1

[15:44] <Bert> ... The criteria for 2.1 where basically what bert and howcome knew about.

[15:44] <Bert> tantek: Will fantasai draw up ciriteria?

[15:44] <Bert> dbaron: We shoukd have a def for the 2.1 one, Everyone impls them.

[15:44] <dbaron> all the 2.0 ones

[15:45] <dbaron> some of which were dropped from 2.1

[15:45] <Bert> glenn: Want to focus on 2.1, want to see a proposal.

[15:45] <Bert> fantasai: Want to see how hard it is for author to come with a style.

[15:45] <Bert> ... If it is hard, we should prefedine

[15:45] <Bert> ... Khmer might be easy for an author.

[15:45] <Bert> ... CJK is not easy.

[15:46] <Bert> glenn: mapping between numbers anbd symbols and then author can work it out.

[15:46] <Bert> fantasai: hat's what were talking about

[15:46] <Bert> jdaggett: Multiple ways of doing it.

[15:46] <dbaron> http://www.w3.org/TR/2008/REC-CSS2-20080411/generate.html#propdef-list-style-type

[15:46] <dbaron> has a bunch that are not in 2.1

[15:47] <Bert> TabAtkins_: Should not define a common resource. W3C would not host it.

[15:47] * shepazu Quit (Quit: shepazu)

[15:47] <Bert> glenn: rathole to define what is significnt or not, base don community size, e.g

[15:47] * hober why don't we host the resources on xanthir.com?

[15:47] <Bert> jdaggett: We do 't know what the quality is of the definitions we have.

[15:48] <Bert> ... Should be a community effort.

[15:48] * hober we put a lot of specs there :)

[15:48] <Bert> plinss: You say (1) we cannot define it, (2) it is a quality issue.

[15:48] * jarek_ has joined #css

[15:49] * jarek Quit (Ping timeout)

[15:49] <Bert> jdaggett: We cannot judge the quality. Who can jusge the Khmer numbering here?

[15:49] <Bert> glenn: I was there and I talked with the government there.

[15:49] <Bert> florian: We should draw a line somewhere.

[15:50] <stearns> s/I talked with/would not accept a proposal unless it came from/

[15:50] <Bert> tantek: jdaggett is asking for community. Community provides examples, test cases, etc. We can check them.

[15:50] <Bert> jdaggett: We cannot check them.

[15:50] <Bert> plinss: You aregue ther eis npublic review.

[15:50] <Bert> florian: Toss it out to specialized group.

[15:51] <Bert> SteveZ: Why doesn;'t the wikipedia solution work here? Put it out,

[15:51] <Bert> ... Leave the community to get it right.

[15:51] <Bert> ... *We* are not going to get it right.

[15:51] <Bert> TabAtkins_: OK

[15:51] <Bert> fantasai: I'd like a counter style smodule

[15:51] <Bert> ... That defines 2.0 and 2.1 styles.

[15:52] <Bert> ... And has informative appendix with the other currently in the draft.

[15:52] <Bert> some people: no

[15:52] <Bert> plinss: [missed]

[15:52] <Bert> tantek: We have a wiki. Propose it there.

[15:52] <Bert> ... If the community steps up, that's great. If not, too bad.

[15:53] <Bert> koji: I agree wiki is good place to develop for a community. But o ce developed, how to put it in browsers?

[15:53] <Bert> florian: You don't.

[15:53] <Bert> ... Authors copy it it to their own style sheets.

[15:54] <Bert> SteveZ: Knowing what we know, we would have creatred a registry.

[15:54] <Bert> dbaron: here is the set in 2.0, I think all implemented in browsers.

[15:54] <Bert> ... One value got split in current draft, because of multiple interpretations.

[15:54] <Bert> ... CJK ideographic.

[15:54] <Bert> ... Split into 6 values.

[15:55] <Bert> fantasai: Complication with that one is that an author is not going to come up with that on hois own.

[15:55] <Bert> ... Those should be in the required set of built-ins.

[15:55] <Bert> dbaron: I think the required set should be the 2.0/2.1 set plus these 6.

[15:56] <Bert> plinss: 2.0 is not the justification, it is just our source.

[15:56] <Bert> tantek: What is already implemented is the justification.

[15:56] <Bert> dbaron: It is sane and not a big addition.

[15:56] <Bert> glenn: 2.1 list is enough for me.

[15:56] <Bert> ... Everything else, incl 2.0, in a registry.

[15:56] <Bert> dbaron: Don't kick out if it is implemented cross-browser.

[15:57] <Bert> [discussion about what FF supports]

[15:57] <Bert> florian: I can live with dbaron proposal. Not further than that.

[15:57] <Bert> TabAtkins_: Everything else goes into registry on wiki.

[15:58] <Bert> sylvaing: test cases?

[15:58] <Bert> dbaron: I think I submitted some. May have been removed since.

[15:58] <Bert> sylvaing: If no 2 impls, we can remove.

[15:58] <Bert> ... Strat with that, everything goes to wiki.

[15:58] <Bert> TabAtkins_: TEsting is easy, generate a 1000 numbers.

[15:59] * jet Quit (Ping timeout)

[16:00] <Bert> RESOLVED: Move counter-style rule and symbols functions to the coutner stylesspec. Retain in that spec the 2.0, 2.1 and the six way cjk ideographic split. Move rest of counter styles to registry on W3C wiki.

[16:01] <Bert> [discussion about origin of six-way split of cjk ideographic]

[16:01] <Bert> florian: Mark 6-way split at risk?

[16:01] <Bert> dbaron: Agreed.

[16:01] <Bert> RESOLVED: {cont'd) and mark 6-way split at risk.

[16:02] <Bert> glenn: I object to 6-way split. At risk is OK.

[16:02] * arno Quit (Quit: Leaving.)

[16:04] * arno has joined #css

[16:07] * jarek_ Quit (Quit: jarek_)

[16:07] * jarek has joined #css

[16:17] * Koji Quit (Ping timeout)

[16:21] <fantasai> Topic: Editorship

[16:21] <fantasai> Alan: Propos krit as editor on Filter effects

[16:21] <fantasai> RESOLVED: krit as editor on Filter effects

[16:21] <fantasai> Topic: Sticky Positioning

[16:21] * jet has joined #CSS

[16:21] <fantasai> hober: I posted to www-style a proposal for adding a new position value

[16:22] <fantasai> hober: called 'sticky'

[16:22] <fantasai> hober: similar to relpos

[16:22] <fantasai> fantasai: It's like a combination of relpos and fixedpos that actually works

[16:24] * jdaggett Quit (Quit: jdaggett)

[16:24] * Koji has joined #css

[16:26] <fantasai> hober: It's in-flow like relpos

[16:26] <fantasai> hober: but the calculation of the offset is based on the intersection of the veiwport and the containing block

[16:26] <fantasai> hober: common use cases are, e.g. sidebar in a web page

[16:26] <fantasai> hober demonstrates

[16:26] * smfr perks up

[16:26] <fantasai> hober: This sort of thing is really common on the Web, using scroll events to emulate with JS

[16:27] <fantasai> hober: All just a single new position value

[16:27] <fantasai> hober: footer and header of table are always visible in viewport

[16:27] * stearns expects the functionality to include hober-presentation-mode

[16:27] <fantasai> hober shows address book that works like iPhone address book headers

[16:28] <fantasai> plinss asks about a case of header and footer overlap

[16:28] <fantasai> hober: So I think it might be worth, in the longer term, adding a property for handling collisions

[16:28] <fantasai> hober: complicated if doing in multiple dimensions

[16:28] * sylvaing was hoping hober would do this while riding his bike around the room

[16:28] <fantasai> by default would overlap

[16:28] * arno Quit (Quit: Leaving.)

[16:29] <fantasai> hober: Looking for resolution to pursue the feature

[16:29] <fantasai> szilles: How does it behave for print?

[16:29] <fantasai> fantasai: would be same as relpos

[16:29] <dbaron> [5 conversations at once]

[16:29] <fantasai> glazou: I think it's not that easy to specify

[16:30] <fantasai> hober: I'll take an action to write a description

[16:30] <fantasai> szilles: If I don't have scrolling it doesn't move

[16:30] * heycam|away is now known as heycam

[16:31] <dbaron> fantasai: Then you have the overlapping problem you have with fixed pos -- end up with tons of overlap. If you want this effect when printing you need to make space for it.

[16:31] <fantasai> plinss^: why not print on every page

[16:31] <fantasai> glazou: If I can describe it this was included in the P language

[16:31] * fantasai thinks everything was in P language

[16:31] <fantasai> glazou: mechanism similar to pseudo-elements, you could select any element, such as viewport

[16:32] <fantasai> glazou: then had an element, and on that you could say "min-y: 0" inside the viewport

[16:32] <fantasai> glazou: meant element was always visible or invisible

[16:32] <fantasai> hober: Common design pattern, ppl emulate a lot with JS

[16:32] <fantasai> hober: But scrolling has gotten strange as time has gone on, so increasingly problematic

[16:33] * glazou fantasai yes, almost was everything already in P...

[16:33] <fantasai> Rossen: One question I have, new value is that the behavior is not applicable or useful for position: absolute

[16:33] * glazou fantasai yes, almost everything was already in P...

[16:33] <arronei> sticky, real world use case: http://store.apple.com/us/configure/MD102LL/A?=

[16:33] <fantasai> hober: yes

[16:33] <smfr> arronei: news.google.com sidebar

[16:34] <fantasai> hober: Of all cases I've seen, makes more sense for in-flow positioning than out-of-flow. You want to leave space in flow for the item

[16:34] * sylvaing arronei is shopping....

[16:34] <fantasai> plinss: Suggest considering abspos version of this

[16:34] * arronei no already did that weeks ago

[16:35] * stearns but wouldn't that encourage abspos use?

[16:35] <fantasai> Bert: Seems you might want sticky differently in horizontal and vertical dimensions

[16:35] * smfr has never seen an abspos equivalent in the wild

[16:35] <fantasai> hober: Suppose you had a wide table, not so tall

[16:36] <fantasai> hober: you might want the column headers to stick the viewport, but if you scroll the table horizontally itself, you might want the row headers to stick within the viewport but not the scrolly

[16:36] <fantasai> hober: is it the nearest scrollable ancestor that you stick to?

[16:36] <fantasai> hober: do you have same decision in both dimensions?

[16:36] * arno has joined #css

[16:36] <fantasai> hober: worth thinking about

[16:37] <fantasai> plinss: Think proposal is for hober to write something up for css3-positioning

[16:37] <fantasai> plinss: would you co-edit?

[16:37] <fantasai> hober: either way

[16:37] <arronei> hober: add the proposal to http://wiki.csswg.org/spec/css3-positioning

[16:37] <fantasai> glazou: Suppose green is the viewport

[16:38] <fantasai> glazou draws a big green box, left half has three black boxes stacked on top. Another black box below that, followed by red box, followed by blue box

[16:38] <Rossen> smfr, an example is running shopping cart totals positioned to left/right of forms

[16:38] <fantasai> glazou: with collision could you get them to stack?

[16:38] <fantasai> overlap by default

[16:38] <fantasai> hober: I think overlapping by default is the right behavior here, could reus collision later

[16:38] <fantasai> hober: also question of percentage values, at what distance do you start sticking

[16:39] <smfr> stacking gets hard; you end up with a float-like algorithm

[16:39] <dbaron> I'm not convinced that reusing this same collision avoidance mechanism is the right thing.

[16:39] <fantasai> Topic: Animations

[16:40] <sylvaing> https://docs.google.com/spreadsheet/ccc?key=0Akz3Ts2PEQF2dE1fTHhJMlJBbnp6UmZNY2dzVHpEVGc

[16:40] * fantasai notes yelp search results also uses stickypos

[16:40] <fantasai> sylvaing: This describes list of issues we had at last F2F

[16:40] <fantasai> sylvaing: some things fixed already

[16:40] <fantasai> sylvaing: hopefully reach LC at TPAC or before

[16:41] <fantasai> sylvaing: couple left over from Hamburg

[16:41] <fantasai> sylvaing: where in cascade do images go?

[16:41] <fantasai> sylvaing: I believe dbaron described what Gecko was doing

[16:41] <fantasai> sylvaing: The emerging consensus was that transitions would happen at the very end

[16:41] <fantasai> sylvaing: you would go from current animation value to the trnasition end, but never really resolved on it

[16:42] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14713

[16:42] <sylvaing> http://lists.w3.org/Archives/Public/public-fx/2012AprJun/0107.html

[16:42] <fantasai> sylvaing: we discussed this part

[16:42] <smfr> s/images/animations

[16:42] <fantasai> sylvaing: here's gecko's cascade

[16:42] <fantasai> sylvaing: we never resolved that

[16:42] <fantasai> sylvaing: I haven't checked recent webkit, but they used to have .. at the bottom

[16:42] <fantasai> sylvaing: in Gecko transitions are more important than animations

[16:43] <fantasai> dbaron: Except we would start a transition during an animation?

[16:43] <smfr> webkit still applies animations after everything else

[16:43] <fantasai> dbaron: starting a transition happens when we detect a computed value change that was not caused by an animation

[16:43] <fantasai> dbaron: the restyling operation..

[16:43] <fantasai> dbaron: The before and after styles are different in the no-animation case

[16:44] <fantasai> dbaron: I'm trying to remember what's the difference...

[16:44] <fantasai> s/dbaron/sylvaing/

[16:44] <fantasai> sylvaing: Other implementations don't let user !important and UA !important override animations. I think we do want that

[16:44] <fantasai> dbaron: I think we do want that.

[16:44] <fantasai> dbaron: Questio nis whether we want them under the other !important rules

[16:45] <fantasai> sylvaing: so any opinions?

[16:45] <fantasai> Florian: I remember having an opinion, but don't remember what it was

[16:46] <fantasai> fantasai: What are the options?

[16:46] <fantasai> sylvaing: Option A, animations are higher than UA and author !important rules

[16:46] <fantasai> sylvaing: Gecko allows them to override

[16:47] <fantasai> dbaron: Another option would be to put animations here, between author normal an dauthor override

[16:47] <fantasai> fantasai: Where would scoped style fit in with that?

[16:48] <fantasai> dbaron: Author override and scoped would be a group

[16:48] <fantasai> dbaron: Question would be whether animations would go before the !important rules, or after them

[16:49] <fantasai> fantasai: So either animations would come right before all the !importants, or it would come right after all the author styles (including !importants)

[16:50] <fantasai> fantasai: I think having animations override user/UA !imporant rules it's not a good idea

[16:50] <fantasai> dbaron explains why having transitions at the end of the cascade makes sense: the UA/user !important rules would prevent computed value changes that could trigger transitions

[16:51] <fantasai> sylvaing: so user rules could start them, but that's just about it

[16:51] <fantasai> glazou: I'm using them in BlueGryffon to prevent animations to run

[16:51] <fantasai> dbaron: Use case: user wants to override colors, but is fine with animations causing movement

[16:53] <fantasai> RESOLVED: Animations are below user !important rules, not above them. [still discussing whether below or above author !important]

[16:53] <fantasai> fantasai: So remaining question is whether author !important override animations or not

[16:54] <glazou> glazou: yes I think both User and Author !important should override animations

[16:55] <fantasai> RESOLVED: Animations override all normal rules, but are overridden by all !important rules.

[16:56] <fantasai> RESOLVED: Transitions happen last in the cascade

[16:56] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14713

[16:57] <fantasai> sylvaing: snapshotting of values at the start of animation, action on smfr and dbaron on which properties snapshot or not

[16:57] <fantasai> sylvaing: talk about that yet?

[16:57] <fantasai> dbaron: not yet, no

[16:58] <fantasai> sylvaing: Raised by ...

[16:58] <fantasai> sylvaing: afaict not used

[16:58] <fantasai> dbaron: Yes, let's remove them

[16:59] <fantasai> RESOLVED: Remove initAnimationEvent method https://www.w3.org/Bugs/Public/show_bug.cgi?id=15338

[16:59] <fantasai> sylvaing: need to define a constructor

[17:00] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14781

[17:00] <fantasai> sylvaing: Spec doesn't specify starting frmae / ending frame, spec defines generating them but doesn't define when ...

[17:00] <fantasai> dbaron: I believe we update it dynamically

[17:00] <fantasai> sylvaing: at some point you have your first frame, and others follow.

[17:00] <fantasai> dbaron: You're animating from that to some other pont

[17:01] <fantasai> dbaron: if there's a style change that changes here, you're following this line instead of this line

[17:01] <fantasai> Florian: You put a transition for the adjustment being smooth?

[17:01] <fantasai> dbaron: Yes, maybe?

[17:01] <fantasai> sylvaing: I think we do it static at the moment. Think Webkit does too

[17:02] <fantasai> hober: Should be snapshotting after delay

[17:02] <fantasai> sylvaing: but compute first frame, last frame

[17:02] <fantasai> sylvaing: we didn't have a use case for dynamic case

[17:02] <fantasai> dbaron: My worry about dynamic case is mostly style changes that are nearly sequential

[17:02] <fantasai> dbaron: Because it'll expose when browsers coalesce things or not

[17:02] * jdaggett has joined #css

[17:02] <fantasai> dbaron: Would like to minimize how much that's exposed

[17:03] * leaverou_ has joined #css

[17:03] * leaverou Quit (Ping timeout)

[17:04] * leaverou_ is now known as leaverou

[17:04] <fantasai> sylvaing: Is that related to issue of which properties to snapshot?

[17:04] <fantasai> dbaron: testcases with a 5s delay are annoying

[17:05] <fantasai> dbaron: If I move th emouse into it while animating, it jumps to other position while animating

[17:05] <fantasai> sylvaing: Shouldn't this relate to general snapshotting issue?

[17:05] <fantasai> sylvaing: ok, think it's the same bug

[17:06] <sylvaing> https://www.w3.org/Bugs/Public/slhow_bug.cgi?id=15850

[17:07] <fantasai> sylvaing: I don't understand how you get an invalid rule here

[17:07] <smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15850

[17:07] * jet Quit (Quit: jet)

[17:08] <fantasai> sylvaing: Have a few more edits, then ask for new WD

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

[17:09] <fantasai> RESOLVED: Publish updated WD with those edits

[17:10] <fantasai> sylvaing: Aiming for LC at TPAC or before

[17:10] * Rossen Quit (Ping timeout)

[17:11] <fantasai> Topic: Scientific Notation

[17:12] <fantasai> TabAtkins: Required for SVG.

[17:13] <fantasai> dbaron: Unitless lengths and scientific notation are allowed in SVG attributes.

[17:13] * fantasai asks about CSS escapes

[17:13] <fantasai> TabAtkins: One use is to align with SVG

[17:13] <fantasai> TabAtkins: Other is it's useful in transformation matrices

[17:14] <fantasai> TabAtkins: Syntax spec already defines parsing for it, just have a flag for it to turn it on or off. So no additional work on the spec side.

[17:14] <dbaron> 8.574e-21parsec == 1px

[17:14] <fantasai> Florian: I will not object to scinot, but I'm not interested in it

[17:15] <fantasai> plinss: Any objections to adding scientific notation?

[17:15] <fantasai> Bert: Yes.

[17:15] <fantasai> Bert: I'm not happy with what we add, we don't have anything left for normal people.

[17:16] <fantasai> hober: Tab has two use cases

[17:16] <fantasai> hober: I don't consider them incredibly important, but they're reasonable.

[17:16] * mvujovic Quit (Quit: Leaving.)

[17:16] <fantasai> fantasai: I defer to dbaron.

[17:16] <fantasai> dbaron: I'm against it, but I'm not going to object.

[17:17] <fantasai> fantasai: That's my opinion.

[17:17] <fantasai> szilles: I'm not opposed, I'm not for

[17:17] <fantasai> alan: I think rationalizing things with SVG seems reasonable to do

[17:17] <fantasai> szilles: Useful, but not critical.

[17:18] <fantasai> Florian: which definition of scinot is this?

[17:18] <fantasai> Tab: Same as SVG. Number e integer

[17:18] <fantasai> Florian: How does this interact with minimum you're supposed to support

[17:19] <fantasai> TabAtkins: Turns into equivalent number

[17:19] <fantasai> dbaron: scinot is not valid in integers, only valid in numbers

[17:19] <fantasai> dbaron: Don't want to deal with scinot in integers

[17:20] <fantasai> TabAtkins quotes his spec text

[17:20] * jarek Quit (Quit: jarek)

[17:21] <fantasai> dbaron and TabAtkins discuss parsing problems

[17:21] <fantasai> and floats

[17:21] <fantasai> hober: Just force it to be a number

[17:21] * jdaggett maybe now is the right time to talk about priorities again...

[17:22] <fantasai> ....

[17:22] <fantasai> dbaron: Things that are integer are things we will represent using an integer rather than a floating type. Really don't want to encourage people to do exponents

[17:22] <fantasai> Florian: Since you don't care either way, when we're specifying precision of support, shouldn't require ... cancel out

[17:23] <fantasai> TabAtkins: So you're allowed to do truncation as you're parsing

[17:23] <fantasai> dbaron: SVG's integer type does not accept scinot

[17:23] * cabanier Quit (Quit: Leaving.)

[17:23] <dbaron> http://www.w3.org/TR/SVG11/types.html#BasicDataTypes says <integer> doesn't take scientific notation and <number> does

[17:23] * smfr wonders when we'd see z-index: 1e27

[17:23] * stearns a line above this one

[17:23] <fantasai> proposal: scinot for <number>, allow range-checking based on parse time as well as interpretation-time limits

[17:25] <fantasai> straw poll -> no consensus

[17:25] <fantasai> Straw poll again, more formally

[17:25] <fantasai> glazou: yes

[17:25] <fantasai> bert: NO

[17:25] <fantasai> koji: abstain

[17:25] <fantasai> szilles: yes

[17:25] <jdaggett> jdaggett: no

[17:25] <fantasai> glenn: yes

[17:26] <fantasai> hober: abstain abstain

[17:26] <fantasai> alan: yes

[17:26] <fantasai> fantasai: defer to dbaron

[17:26] <fantasai> tantek: defer to dbaron

[17:26] <dbaron> dbaron: no, but not objecting

[17:26] <fantasai> Tab: yes

[17:26] <smfr> yes

[17:26] <fantasai> Florian: abstain

[17:26] <fantasai> leif: why not, yes

[17:26] <fantasai> plinss: yes

[17:27] <fantasai> "Simon says"

[17:27] <smfr> :D

[17:28] <fantasai> Bert: Not really fair to ask every F2F until not enough around

[17:28] <fantasai> who disagree

[17:29] <fantasai> 5 no, 8 yes

[17:29] <fantasai> RESOLVED: add scinot to CSS

[17:29] <fantasai> Topic: text-size-adjust

[17:30] <fantasai> dbaron: Don't know what there is to discuss...

[17:30] <fantasai> tantek: Question is about going to FPWD

[17:30] <fantasai> dbaron: Think I'd rather not.

[17:30] <dbaron> with the ED as is

[17:30] <fantasai> Meeting closed.

[17:30] <jdaggett> but it's just 5:30?

[17:31] * florian Quit (Ping timeout)

[17:31] <stearns> text-size-adjust shut the whole thing down

[17:32] * lstorset Quit (Ping timeout)

[17:32] * Koji Quit (Quit: Leaving...)

[17:32] * glazou Quit (Quit: glazou)

[17:32] * glenn Quit (Client exited)

[17:33] * smfr has left #css

[17:33] * tantek Quit (Quit: tantek)

[17:35] * glazou has joined #css

[17:35] * TabAtkins_ Quit (Ping timeout)

[17:35] * dbaron Quit (Ping timeout)

[17:36] * SteveZ Quit (Ping timeout)

[17:37] * glazou Quit (Quit: glazou)

[17:42] * arno Quit (Quit: Leaving.)

[17:46] * glenn has joined #css

[17:50] * arno has joined #css

[18:17] * jdaggett Quit (Quit: jdaggett)

[18:39] * leaverou Quit (Quit: leaverou)

[18:48] * heycam is now known as heycam|away

[19:20] * heycam|away is now known as heycam

[19:35] * achicu has joined #css

[19:35] * achicu has left #css

[19:42] * krit Quit (Quit: Leaving.)

[20:14] * dbaron has joined #css

[20:19] * dbaron Quit (Ping timeout)

[20:21] * arno Quit (Quit: Leaving.)

[20:30] * shepazu has joined #css

[21:06] * leaverou has joined #css

[22:00] * dholbert Quit (Ping timeout)

[22:02] * dholbert has joined #css

[22:02] * miketaylr Quit (Quit: dflk;adfslkj;alsiekfj;laiskdf)

[22:22] * dbaron has joined #css

[22:35] * Disconnected.

[22:35] * CSSWG_LogBot has joined #css

[22:35] * Topic is 'http://wiki.csswg.org/planning/sandiego-2012'

[22:35] * Set by Ms2ger on Mon Aug 13 08:52:40 PDT 2012

[22:35] * gsnedders has joined #css

[22:35] * shans_away has joined #css

[22:35] * glazou has joined #css

[22:35] * shans_away is now known as shans

[22:35] * sylvaing_away has joined #css

[22:35] * sylvaing_away is now known as sylvaing

[22:36] * vhardy_away has joined #css

[22:36] * vhardy_away is now known as vhardy

[22:36] * alexmog_away has joined #css

[22:36] * alexmog_away is now known as alexmog

[23:14] * glazou Quit (Quit: glazou)

[23:38] * mwenge Quit (Ping timeout)

[23:39] * leaverou has joined #css

[23:42] * Ms2ger has joined #css

[23:42] * jet has joined #CSS

[23:44] * dbaron Quit (Ping timeout)

[23:53] * glenn Quit (Ping timeout)

[23:59] * leaverou Quit (Quit: leaverou)

These logs were automatically created by CSSWG_LogBot on irc.w3.org using the Java IRC LogBot.