/irc-logs / w3c / #css / 2012-11-27 / end

Options:

# Session Start: Tue Nov 27 00:00:00 2012
# Session Ident: #css
# [00:06] <stearns> on above, all of my makefiles used http:// - changing to https://cgi.w3.org/member-bin/process.cgi did the trick
# [00:13] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [00:29] * Joins: krit (~krit@public.cloak)
# [00:31] * Quits: krit (~krit@public.cloak) (Client closed connection)
# [00:46] * Quits: drublic (~drublic@public.cloak) (Client closed connection)
# [00:50] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
# [01:01] * Joins: dbaron (~dbaron@public.cloak)
# [01:20] * Joins: krit (~krit@public.cloak)
# [01:23] <krit> TabAtkins: Hi. I got confused between the two threads. Can you copy paste your marker-pattern syntax proposal again please?
# [01:24] <TabAtkins> krit: Yeah
# [01:25] <TabAtkins> marker-pattern: [ <distance>? <marker-instance> [ <distance> <marker-instance>? ]* ]#
# [01:25] <TabAtkins> Basically, in each track, you can alternate between distances and markers.
# [01:26] <TabAtkins> You can omit a marker to mean "use the same marker as before".
# [01:26] <TabAtkins> And then you can comma-separate independent tracks.
# [01:28] <krit> TabAtkins: how can you define a different order for on marker? —#———#
# [01:29] <krit> TabAtkins: does it need to be comma separated then?
# [01:29] <TabAtkins> What do you mean? Like you want that pattern, repeating?
# [01:29] <krit> yes
# [01:29] <TabAtkins> marker-pattern: 10px url(...) 30px;
# [01:29] <TabAtkins> (You can omit the second url(), since it's the same marker.)
# [01:29] <TabAtkins> It'll then just cycle through the list to get repetitions.
# [01:30] <TabAtkins> Basically, it computes to a list of (marker, distance) pairs, which are then cycled through.
# [01:30] <krit> TabAtkins: so the first distance is your offset?
# [01:30] <krit> (some kind of at least)
# [01:30] <TabAtkins> Depends on what you mean by that. The property I gave above will make a marker that cycles like -#---#-#---#-#---#.
# [01:31] <TabAtkins> If you wanted -#---#---#---#, I'd need to add an explicit offset. Or, just rephrase it so that the first distance is an offset.
# [01:32] <TabAtkins> In other words, if I say the first <distance> is an offset (and is not cycled), then I'd write the first one above as "10px url() 30px 10px", while the second is "10px url() 30px".
# [01:32] <TabAtkins> That's probably a good idea, honestly.
# [01:33] <krit> one part left that I just thought about at this moment. What about he paint order. Do you draw the first sequence and then the second on top of it? (sequence as a rule till the next comma)
# [01:34] <TabAtkins> Good question. Probably, yes.
# [01:34] <TabAtkins> Or the other way around. Whichever matches other properties.
# [01:34] <TabAtkins> background is last-first.
# [01:34] <TabAtkins> Dunno what shadows are.
# [01:34] <heycam|away> sorry for butting in without reading the thread properly (just skimmed it): is your proposal TabAtkins that we take my proposal, and allow comma separated lists of those things?
# [01:34] * heycam|away is now known as heycam
# [01:35] * heycam grrs at dircproxy not auto un-awaying him
# [01:35] <krit> the only problem that I see with comma separation is the shorthand (why i didn't brought it up).
# [01:36] <krit> a keyword like "pattern" could help
# [01:36] <krit> but it would be different to all other shhorthands that we have so far
# [01:36] <TabAtkins> We're edging into this pattern in some places, when you have a really complex thing that can't be easily disambiguated.
# [01:36] <krit> till now, shot hands just differ on the separation ('/' or ',')
# [01:37] <TabAtkins> Honestly, I think / should almost never be used. I think it makes border-image, for example, *really* hard to read.
# [01:37] <TabAtkins> I think I arged for keywords in background, but we decided on / instead.
# [01:38] <TabAtkins> But anyway, small things like 'background' or 'font' or 'animation' aren't a huge deal. But for very complex properties like 'border-image' or 'marker', I think using / is a mistake.
# [01:38] <krit> TabAtkins: I have nothing agains '/' when it makes sense. for background I actully think it is not a bad idea. Developers want syntax to be simple
# [01:38] <TabAtkins> Current examples are radial-gradient, which uses keywords to distinguish between the size and center (and focus, once level 4 is adopted).
# [01:39] <TabAtkins> We experimented with it in 'flex', before simplifying the syntax to not need it.
# [01:39] <krit> TabAtkins: I would be absolutely in favor for simplifications
# [01:40] <krit> TabAtkins: heycam: I actually have nothing in mind in keeping marker separate from marker-pattern and marker-segment
# [01:41] <TabAtkins> One interesting simplification I brought up in the thread - we might be able to combine marker-pattern and marker-segment, using a keyword in each track to specify whether it's a per-segment or whole-path pattern.
# [01:41] <TabAtkins> Only downside is we can't easily get the nice default behavior of marker-segment, where it takes a single url() and puts it in the center.
# [01:41] <heycam> TabAtkins, that sounds like an earlier proposal we talked about in Hamburg
# [01:41] <TabAtkins> heycam: Could be, I don't recall.
# [01:41] <heycam> TabAtkins, where you could say "edge" and that meant advance the position to the middle of the next segment
# [01:42] <krit> TabAtkins: heycam: I just want them to have the same syntax. But a keyword doesn't help much if you want to have both
# [01:42] <TabAtkins> Sorta. You want percentages of the current segment, though.
# [01:42] <heycam> I see
# [01:42] <krit> TabAtkins: or your grammar gets unneccessary complicated
# [01:43] <heycam> so I like the multiple tracks idea, because it's similar to what I want to be able to do with stroke and fill later on
# [01:43] <krit> TabAtkins: heycam(think of markers on segment ends and dots along the path)
# [01:43] <heycam> i.e. just comma separate to allow multiple ones
# [01:43] <TabAtkins> krit: No, the grammar just changes to:
# [01:43] <TabAtkins> marker-pattern: [ <distance>? <marker-instance> [ <distance> <marker-instance>? ]* ]#
# [01:43] <TabAtkins> dammit, one sec.
# [01:44] <krit> TabAtkins: sknow what you mean
# [01:44] <TabAtkins> marker-pattern: [ [ segment | path ] <distance>? <marker-instance> [ <distance> <marker-instance>? ]* ]#
# [01:44] <krit> keyword per sequence
# [01:44] <TabAtkins> marker-pattern: [ [ segment | path ]? <distance>? <marker-instance> [ <distance> <marker-instance>? ]* ]#
# [01:44] <TabAtkins> yeah
# [01:45] <heycam> TabAtkins, is "path" like what I have currently, and "segment" means resolve percentages against each segment length, and repeat the whole pattern per segment instead of over the whole path?
# [01:45] <krit> heycam: more
# [01:45] <TabAtkins> heycam: Yeah.
# [01:45] <krit> heycam: segment means you start the pattern on each segment again
# [01:45] <heycam> ok
# [01:45] <heycam> plus the percentages thing
# [01:45] <krit> right
# [01:46] <TabAtkins> And values before/beyond the length of the current segment are ignored.
# [01:46] <krit> heycam: patterns are implementable on webkit today (working on it), segments need more time
# [01:46] <heycam> what would you want to use "segment" for, beyond what marker-segment does currently?
# [01:46] <TabAtkins> It's a slight complexity hit, as instead of "marker-segment: url()" you have to say "marker-pattern: segment 50% url()", but it simplifies the overall model a little.
# [01:47] <krit> TabAtkins: agree
# [01:47] <krit> TabAtkins: marker-pattern: segment url() 50% would work as well ;)
# [01:48] <heycam> I guess I'm not seeing the advantage to handling marker-segment inside marker-pattern
# [01:48] <krit> TabAtkins: maybe it is a bit different ...
# [01:48] <heycam> is it so that you can control the order of painting, like have segment markers on top of pattern markers?
# [01:48] <krit> heycam: one property less, other then that, nothing
# [01:48] <TabAtkins> krit: Would it? I guess that's best, actually. (I was assuming that if you didn't specify an offset, the first marker was placed at 0.)
# [01:49] <krit> TabAtkins: without values after url, you could say it is no pattern
# [01:49] <krit> TabAtkins: and gets drawn once
# [01:49] <TabAtkins> heycam: No particular use-case advantage either way. It just merges some concepts, so the model is simpler (and the shorthand, too).
# [01:49] <heycam> but more complex for authors to write marker-segment things
# [01:49] <TabAtkins> A bit, yeah.
# [01:49] <krit> heycam: but a lot more powerful
# [01:50] <krit> heycam: I forinstance would like to have markers on peaks, you and TabAtkins on the middle of the segment
# [01:50] <krit> s/peak/end of segment.
# [01:51] <heycam> krit, but you can do that with what is currentl in the spec, right?
# [01:51] <TabAtkins> heycam: If it wasn't for the percentages thing, just using the older "edge" proposal would work fine (you can repeat after that).
# [01:51] <heycam> TabAtkins, so I do think your proposal is better than the old "edge" keyword proposal
# [01:52] <heycam> so here is one thing you could do with this that you can't with the current spec
# [01:52] <heycam> if you want each edge to look like: -----x-x-----
# [01:52] <krit> heycam: https://svgwg.org/svg2-draft/painting.html#SegmentMarkers marker-segment just allowed a url
# [01:53] <TabAtkins> Yeah. But that can be done either by mine, or by krit's proposal.
# [01:53] <TabAtkins> In krit's, "marker-segment: calc(50% - 20px) url(), calc(50% + 20px) url();".
# [01:53] <heycam> ok
# [01:53] <TabAtkins> In mine the same, except call it marker-pattern and put a "segment" keyword.
# [01:53] <krit> heycam: TabAtkins: with first distance as offset, I am absolutely fine with your proposal :D
# [01:54] <TabAtkins> Or, well, you can simlpify a bit. "marker-pattern: segment url() calc(50% - 20px) url() 40px".
# [01:54] <TabAtkins> krit: kk
# [01:54] <heycam> TabAtkins, what controls that you don't repeat that pattern?
# [01:55] <heycam> TabAtkins, or is it just that you would fall off the end?
# [01:55] <TabAtkins> heycam: Well, in this specific case, it would fall off the end. We can either add an explicit cycle/no-cycle indicator, or just require that you do something like "none 100%" at the end to ensure that repeats fall off.
# [01:56] <heycam> I think that makes the simple "marker in the middle of the segment" even more complex to write
# [01:56] <TabAtkins> Yeah, I think you're right.
# [01:56] <krit> heycam: well no
# [01:56] <krit> heycam: 50% url() says actually nothing about the repeating
# [01:56] <TabAtkins> I'm thinking the defaults for the two use-cases are different enough that merging them would be kinda painful.
# [01:57] <heycam> krit, oh is that because the first is offset and not a length to repeat?
# [01:57] <krit> heycam: therefore, the marker is repeated on thesame place over and over again
# [01:57] <TabAtkins> krit: You don't want that - it'll mean you couldn't do transparent colors. ^_^
# [01:57] <krit> heycam: which would be the same as draw the marker once
# [01:57] <krit> TabAtkins: question of defintion
# [01:57] <krit> TabAtkins: just say that it is treated as drawing it once
# [01:58] <heycam> krit, so in the spec at the moment I say that if the lengths all add up to zero then you don't paint anything. but we could define it so that it just doesn't repeat, only does it once.
# [01:58] <TabAtkins> It's fine to say "XXX means draw it once". But don't try and state that they're equivalent. ^_^
# [01:58] <krit> no, right.
# [01:58] <heycam> I'm also slightly uneasy about treating the first value as an offset and not part of the repeated pattern
# [01:59] <heycam> because there's nothing that makes that obvious when you look at the property value
# [01:59] <TabAtkins> You *do* need an offset, for the pattern like -#---#---#---#---#.
# [01:59] <heycam> I agree with that
# [02:00] <heycam> (would you want an offset at the other end too? to ensure a marker doesn't get placed right at the end of the path?)
# [02:00] <krit> heycam: btw. looks like I can't help on implementing SVG stuff in Mozilla :(
# [02:00] <heycam> krit, why's that?
# [02:00] <TabAtkins> Independent implementations.
# [02:00] <krit> heycam: at least not if we follow the CSS WG guideline
# [02:01] <heycam> oh in terms of independent implementations?
# [02:01] <krit> TabAtkins: TWO independent implementations
# [02:01] <krit> TabAtkins: (ok, there is no one indepdent :P)
# [02:01] <TabAtkins> Two or more is implied by my use of plurals. ^_^
# [02:01] <heycam> krit, what were you going to hhelp with?
# [02:02] <krit> heycam: yeah, still implement most new SVG features in WebKit :)
# [02:02] <krit> heycam: was looking in helping out on masking in the future ;)
# [02:02] <heycam> krit, oh cool
# [02:02] <krit> heycam: not cool
# [02:02] <heycam> well yeah :p
# [02:02] <heycam> krit, I'm not sure I'm going to work on the CSS Masking stuff outside of the mask-type property
# [02:03] <krit> hehe
# [02:03] <heycam> at least any time soon
# [02:04] * heycam must lunch bbl
# [02:04] * heycam is now known as heycam|away
# [02:09] * krit needs to get hired by MS first and Opera afterwards, implement CSS Masking and SVG 2 there, moves on two Mozilla and blocks SVG 2 for forever!!!
# [02:10] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [02:11] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [02:34] * Quits: logbot (~logbot@public.cloak) (Ping timeout: 60 seconds)
# [02:38] * Joins: logbot (~logbot@public.cloak)
# [02:38] * heycam|away is now known as heycam
# [02:52] * Joins: krit (~krit@public.cloak)
# [02:54] * Quits: jet (~jet@public.cloak) (jet)
# [03:04] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [03:11] * Joins: isherman (~Adium@public.cloak)
# [04:12] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 60 seconds)
# [04:52] * Joins: krit (~krit@public.cloak)
# [05:48] * Joins: dbaron (~dbaron@public.cloak)
# [06:25] * Quits: stearns (~anonymous@public.cloak) (Client closed connection)
# [06:25] * Joins: stearns (~anonymous@public.cloak)
# [06:34] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [08:05] * heycam is now known as heycam|away
# [08:23] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 60 seconds)
# [08:32] * Joins: SimonSapin (~simon@public.cloak)
# [08:37] * Joins: dbaron (~dbaron@public.cloak)
# [08:39] * leaverou is now known as leaverou_away
# [08:45] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [08:55] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [09:14] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 60 seconds)
# [09:48] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
# [10:30] * Joins: SimonSapin (~simon@public.cloak)
# [10:33] * Joins: drublic (~drublic@public.cloak)
# [10:57] * Joins: Ms2ger` (~Ms2ger@public.cloak)
# [11:00] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 60 seconds)
# [11:07] * Joins: tmpsantos (~tmpsantos@public.cloak)
# [11:24] * Joins: {Darktears} (~darktears@public.cloak)
# [11:24] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [11:33] * Joins: teoli (~teoli@public.cloak)
# [12:25] * Quits: Ms2ger` (~Ms2ger@public.cloak) (Client closed connection)
# [13:01] * Joins: jet (~jet@public.cloak)
# [13:25] * Quits: jet (~jet@public.cloak) (jet)
# [13:38] * Quits: {Darktears} (~darktears@public.cloak) (Ping timeout: 60 seconds)
# [14:31] * Joins: Ms2ger` (~Ms2ger@public.cloak)
# [14:40] * Joins: {Darktears} (~darktears@public.cloak)
# [16:07] * Quits: Ms2ger` (~Ms2ger@public.cloak) (Ping timeout: 60 seconds)
# [17:11] * Joins: krit (~krit@public.cloak)
# [17:29] * Quits: tmpsantos (~tmpsantos@public.cloak) ("Leaving")
# [17:40] * Joins: jet (~jet@public.cloak)
# [17:58] * Joins: dbaron (~dbaron@public.cloak)
# [18:21] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
# [18:22] * Quits: arronei (~arronei@public.cloak) ("")
# [18:23] * Joins: teoli_ (~teoli@public.cloak)
# [18:23] * Joins: SimonSapin (~simon@public.cloak)
# [18:25] * Joins: arronei (~arronei@public.cloak)
# [18:26] * Quits: teoli (~teoli@public.cloak) (Ping timeout: 60 seconds)
# [18:36] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
# [18:56] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 60 seconds)
# [19:37] * Parts: jet (~jet@public.cloak) (jet)
# [19:46] * Joins: victor (~Adium@public.cloak)
# [19:46] * Parts: victor (~Adium@public.cloak) (victor)
# [19:49] * Joins: dbaron (~dbaron@public.cloak)
# [20:37] * Quits: isherman (~Adium@public.cloak) (Client closed connection)
# [21:15] * Quits: {Darktears} (~darktears@public.cloak) (Ping timeout: 60 seconds)
# [21:34] * Joins: isherman (~Adium@public.cloak)
# [21:46] * Quits: SamB_MacG5 (~SamB_MacG5@public.cloak) (Ping timeout: 60 seconds)
# [21:50] * Joins: SamB_MacG5 (~SamB_MacG5@public.cloak)
# [21:50] * Joins: victor (~Adium@public.cloak)
# [21:50] * Parts: victor (~Adium@public.cloak) (victor)
# [22:44] * Quits: teoli_ (~teoli@public.cloak) (Client closed connection)
# [22:58] * heycam|away is now known as heycam
# [23:22] * Joins: cabanier (~cabanier@public.cloak)
# Session Close: Wed Nov 28 00:00:00 2012

The end :)