/irc-logs / w3c / #css / 2013-07-27 / end

Options:

# Session Start: Sat Jul 27 00:00:00 2013
# Session Ident: #css
# [00:08] * Quits: tobie (tobie@public.cloak)
# [00:16] * Joins: tobie (tobie@public.cloak)
# [00:24] * Joins: sgalineau (~sgalineau@public.cloak)
# [00:27] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [00:37] * Joins: glenn (~gadams@public.cloak)
# [00:37] * Quits: sgalineau (~sgalineau@public.cloak) (Client closed connection)
# [00:48] * leaverou is now known as leaverou_away
# [00:50] * leaverou_away is now known as leaverou
# [00:52] * leaverou is now known as leaverou_away
# [00:55] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [00:56] * leaverou_away is now known as leaverou
# [01:01] * Joins: glenn (~gadams@public.cloak)
# [01:05] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [01:09] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [01:24] * Quits: tobie (tobie@public.cloak)
# [01:31] * Joins: dbaron (~dbaron@public.cloak)
# [01:36] * Disconnected
# [01:38] * Attempting to rejoin channel #css
# [01:38] * Rejoined channel #css
# [01:38] * Topic is 'http://lists.w3.org/Archives/Public/www-style/2013Jul/0518.html'
# [01:38] * Set by glazou on Wed Jul 24 17:16:04
# [01:38] * Quits: krijn (~krijnhoetmer@public.cloak) (Client closed connection)
# [01:39] * Quits: decadance (~decadance@public.cloak) (Client closed connection)
# [01:42] * Joins: fantasai (~fantasai@public.cloak)
# [01:45] * Joins: decadance (~decadance@public.cloak)
# [01:51] <plinss> TabAtkins: ping
# [01:55] <liam> grr, how did i get sucked into reading all these position papers? :)
# [01:55] * liam contemplates writing "50 shades of CSS" instead
# [01:59] * leaverou is now known as leaverou_away
# [02:00] <SimonSapin> fantasai: sounds like you want branches
# [02:01] <SimonSapin> random question: implementor or implementer?
# [02:02] <liam> the spell checker in this IRC program likes implementer, but it's probably using Canadian English
# [02:03] * leaverou_away is now known as leaverou
# [02:04] * Quits: lmclister (~lmclister@public.cloak) (lmclister)
# [02:15] <TabAtkins> plinss: pong
# [02:15] <plinss> hey, I think I answered my question, but I have another one...
# [02:16] <plinss> I just added 'typedef', 'at-ruledef', and 'funcdef' anchor types to the spec parser
# [02:16] <plinss> my new question is, for typedef anchors, should I strip the surrounding <> from the anchor name?
# [02:17] <plinss> (and if so, should I strip the () from fundef anchor names…)
# [02:17] <TabAtkins> I don't use the anchor name, just the linking text.
# [02:17] <plinss> Ok, I think I'll strip it then...
# [02:18] <plinss> we also need to add a data-for-at-rule for descdefs that aren't following an at-rule definintion (if there are any…)
# [02:20] <TabAtkins> I've begun adding a "For" entry in descdef tables for this purpose. It's present in counter-styles currently.
# [02:20] <TabAtkins> I need to discuss with the group what name they want for that line.
# [02:20] <TabAtkins> The syntax should be just a comma-separated list of at-keywords.
# [02:22] <plinss> ok, that works too
# [02:22] <TabAtkins> I'm going to have missing that be a fatal error in my processor.
# [02:26] <plinss> do you know if the document- and dom- prefix for dfn ids is consistently used for idl functions and interfaces?
# [02:26] <TabAtkins> It's not.
# [02:26] <TabAtkins> But we can establish such.
# [02:26] <plinss> we need to establish something...
# [02:26] <plinss> do you have a data-dfn-type for those?
# [02:27] <TabAtkins> Not yet. Right now they just show up as type=link (type=dfn in your data)
# [02:28] <plinss> dom- seems to be used in html5 fairly consistently
# [02:28] <TabAtkins> Sounds good to me.
# [02:29] <plinss> but we should add data-type-dfn's for those too, have names you prefer?
# [02:30] <plinss> FWIW, I see one instance of document-* in regions, in the html5 spec they seem to use dom-document- for that… we should align with that
# [02:31] <TabAtkins> This is just for ids?
# [02:31] <TabAtkins> What is dom-document-* prefix used for?
# [02:31] <plinss> yes
# [02:32] <plinss> looks like things added to document.
# [02:32] <plinss> http://www.w3.org/TR/html5/dom.html#dom-document-body for example
# [02:33] <TabAtkins> Does that mean we should generally have a pattern of "dom-{interface}-{attribute}"?
# [02:34] <plinss> I think so, yes
# [02:34] <plinss> seems to be how it's used mostly
# [02:36] <plinss> maybe for the data-dfn-types we use 'interface', 'attribute', and 'method' ?
# [02:38] <TabAtkins> Works for me.
# [02:40] <plinss> cool, adding support to the parser
# [02:43] <TabAtkins> So, to be clear, these will only be recognized as such if explicitly tagged in their <dfn>?
# [02:43] <plinss> yes, if tagged with a data-dfn-type, or if their id starts with dom-
# [02:43] <TabAtkins> Ah, kk.
# [02:44] <plinss> (and possibly some more logic with IDL classes and such, I have to look)
# [02:44] <TabAtkins> Hm, they still need to be distinguished between interface/attribute/method. How are you doing that automatically?
# [02:46] <plinss> current thinking is that methods will have a () in them, not sure about interface vs attribute yet
# [02:47] <plinss> maybe by parsing the id, e.g. dom-foo-bar is an attr (if it's not a method) where dom-foo is an interface
# [02:49] <TabAtkins> Ah, yeah, that would work.
# [02:49] <TabAtkins> So, cool. id=dom-* is an interface, id=dom-*-* with a () at the end of its contents is a method, other id=dom-*-* are attributes.
# [02:50] <plinss> yeah, except some of the methods have arguments, so that'll have to be a bit of a regex
# [02:51] <TabAtkins> Ah, yeah, you're right. Easy, though - /^[a-zA-Z0-9]+$/ and /$$/.
# [02:51] <plinss> the question now is do I call them interfacedefs, methoddefs, and attributedefs, or match the abbreviation pattern and call them ifacedefs, methdefs, and attrdefs?
# [02:51] <TabAtkins> Hahaha, do the long form.
# [02:51] <TabAtkins> propdef and descdef are grandfathered in due to class name legacy.
# [02:52] <plinss> ok, how about funcdef for css functions?
# [02:52] <TabAtkins> That works for me.
# [02:52] <plinss> ok
# [02:52] <TabAtkins> Refresh me on the full set of def types now?
# [02:52] <plinss> just about to...
# [02:53] <plinss> 'propdef','valuedef','at-ruledef','descdef','typedef','funcdef','interfacedef','methoddef','attributedef'
# [02:53] <plinss> I think maybe attributedef can be attrdef...?
# [02:54] <plinss> but for data-type-dfn you use the long name: property, value, descriptor, type, function, interface, method, attribute
# [02:54] <TabAtkins> I can change that - nobody's doing it manually yet.
# [02:54] <TabAtkins> I'm fine with just matching your usage.
# [02:55] <plinss> either way, having *def' is a bit redundant there… I kind of like the long form...
# [02:55] <TabAtkins> Okay, then let's drop 'em.
# [02:55] <plinss> drop which?
# [02:56] <TabAtkins> All the defs.
# [02:56] <TabAtkins> def suffixes, rather.
# [02:56] <TabAtkins> And just use a nice long form.
# [02:56] <TabAtkins> property, interface, etc.
# [02:57] <plinss> I'm ok with that, we do still have to respect the old id prefixes of 'propdef-*' etc...
# [02:57] <plinss> (at least I do)
# [02:58] <TabAtkins> Oh, you use that to detect? I detect properties based on just parsing the "Name" line of <table class=propdef> elements.
# [02:58] <plinss> well, I do that too. If there's a propdef class on the container then that also sets the type f the dfn inside it.
# [02:59] <plinss> that's another point, the names of the classes for the containers...
# [02:59] <plinss> the class name should probably have the *def form
# [03:00] <TabAtkins> Ah, interesting. I didn't think to use more container-based identifications.
# [03:00] <TabAtkins> But that totally makes sense.
# [03:00] <plinss> the parser already respect them (just in case)
# [03:01] <plinss> ok so how about: 'propdef','valuedef','at-ruledef','descdef','typedef','funcdef','interfacedef','methoddef','attrdef' for class names and/or id prefixes
# [03:01] <TabAtkins> kk
# [03:01] <plinss> and property, value, descriptor, type, function, interface, method, attribute for the anchor types
# [03:01] <plinss> and data-dfn-type
# [03:01] <TabAtkins> And so the presence of that class name on an ancestor, or that prefix on your id, obviates the need to manually declare your dfn-type.
# [03:01] <plinss> yep
# [03:01] <TabAtkins> Cool.
# [03:02] <plinss> and then there's a priority of there are multiple nested containers with those classes, but hopefully that doesn't happen in the real world… :-)
# [03:02] <plinss> s/priority of there/priority if there/
# [03:03] <TabAtkins> I assume nearest ancestor wins.
# [03:03] <TabAtkins> But I can also just flag it as a fatal error.
# [03:04] <plinss> the parser doesn't work that way now, but I suppose it could do nearest ancestor.
# [03:04] <plinss> I think that will actually simplify things
# [03:05] <plinss> You do realize also, that this is all going to have to be documented somewhere? :-)
# [03:05] <TabAtkins> Yup, I've got it down in a temp document for now. It'll go into my revamped preprocessor documentation.
# [03:05] <plinss> cool
# [03:06] <TabAtkins> Still edging ever closer to getting xrefs working for now.
# [03:06] <plinss> nice
# [03:06] <TabAtkins> Without the code being super hacky and ugly.
# [03:06] <plinss> that helps
# [03:07] <plinss> wondering if we also might need a data-for-interface for methods and attributes outside the interface definition?
# [03:07] <TabAtkins> They'll typically be dfned outside of it, I think.
# [03:08] <TabAtkins> I prefer the <dfn> being the actual description, with the idl fragment just linking to it.
# [03:08] <TabAtkins> So, yes.
# [03:08] <plinss> yeah, but I meant in a place not easily associated to the idl
# [03:08] <plinss> ok
# [03:08] <plinss> works for me
# [03:09] <plinss> oh, wait, I think we should add pseudo-class and pseudo-element to the dfn types
# [03:09] <plinss> can you think of any others?
# [03:09] <TabAtkins> Okay, so if you're doing an "ED" level draft (something for dev.w3.org), we want to force only linking to ED drafts (unless the ED draft doesn't exist at all, which we can tell by looking at the urls in the spec data), and vice versa for "TR" level drafts, yeah?
# [03:10] <TabAtkins> Hm, probably not for now. We're covering all the major syntax constructs in selectors and CSS.
# [03:10] <plinss> I'm not sure if we want to preclude linking between /TR and ED
# [03:11] <TabAtkins> I'll have an attribute that lets you force it, if necessary.
# [03:11] <TabAtkins> Sorry, was using bad wording up above.
# [03:11] <plinss> but /TR docs should link to /TR if the anchor is present in the ?TR version then fall back to the ED
# [03:11] <plinss> and vice versa?
# [03:11] <TabAtkins> Well, the vice versa is the case we wanted to avoid.
# [03:12] <TabAtkins> Having an ED link to another spec, but the relevant concept was removed from the latest ED of the other spec.
# [03:12] <plinss> hmm, yeah, probably
# [03:13] <TabAtkins> I'm okay with a TR-level draft downgrading to link to an ED-level draft.
# [03:13] <plinss> (not sure if that will fly with pubrules…)
# [03:13] <TabAtkins> But EDs should only upgrade to a TR-level draft if there's no ED-level draft of that spec *at all*. (There are a few example of that in the data already.)
# [03:14] <TabAtkins> That's what I was worried about. ^_^
# [03:14] <plinss> right
# [03:14] <plinss> I suppose a /TR linking to an ED is of it it's a WD, not so good if it's a CR or REC
# [03:14] <plinss> s/is of it/is OK if/
# [03:15] <plinss> I think that makes sense
# [03:16] <TabAtkins> Hm, yeah.
# [03:16] <plinss> BTW, I need a reliable way to determine the rectrack step from the specs
# [03:16] <plinss> and the editors
# [03:16] <TabAtkins> I can machine-encode that data in specs done by my processor.
# [03:17] <TabAtkins> It's all required metadata.
# [03:17] <plinss> right, but it's not currently in a nice machine readable format at the end...
# [03:17] <TabAtkins> Right, I'm saying that I *can* do that for you. ^_^
# [03:17] <plinss> right
# [03:17] <plinss> I added something to respec for this stuff a while back, lemme look
# [03:19] <plinss> ah, no, that was something else...
# [03:23] <plinss> looks like respec adds <meta name=dcterms.creator> for the editors, and vcard markup
# [03:24] <plinss> we should align with respec where we can (or have respec align with us)
# [03:26] <TabAtkins> Yeah, I'm down with aligning with respec.
# [03:26] <TabAtkins> Especially since that means we'll get picked up by their specref stuff, I think.
# [03:36] <plinss> hmm, last time I looked at the fxtx specs, they were using respec for some of them, not any more apparently
# [03:40] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [03:41] * Joins: rhauck (~Adium@public.cloak)
# [03:48] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [04:33] * leaverou is now known as leaverou_away
# [04:34] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [05:00] * Quits: logbot (~logbot@public.cloak) (Ping timeout: 180 seconds)
# [05:01] * Joins: logbot (~logbot@public.cloak)
# [05:14] * Joins: dbaron (~dbaron@public.cloak)
# [06:23] <TabAtkins> I suspect they're using bert's preprocessor now, since most of them are edited by adobe people in the csswg
# [06:23] <TabAtkins> plinss: ^^^
# [06:56] * Joins: krit (~krit@public.cloak)
# [08:14] * Joins: glenn (~gadams@public.cloak)
# [08:16] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [09:04] * leaverou_away is now known as leaverou
# [09:11] * Joins: tobie (tobie@public.cloak)
# [09:57] * Quits: tobie (tobie@public.cloak)
# [10:34] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [10:59] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [11:18] * leaverou is now known as leaverou_away
# [11:43] * Joins: teoli (~teoli@public.cloak)
# [11:55] * leaverou_away is now known as leaverou
# [12:15] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [12:16] * Joins: glenn (~gadams@public.cloak)
# [12:23] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [14:48] * Joins: teoli (~teoli@public.cloak)
# [16:28] * Joins: teoli_ (~teoli@public.cloak)
# [16:28] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [16:35] * Joins: teoli (~teoli@public.cloak)
# [16:35] * Quits: teoli_ (~teoli@public.cloak) (Client closed connection)
# [18:04] * Joins: dbaron (~dbaron@public.cloak)
# [18:12] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [18:29] * Joins: glenn (~gadams@public.cloak)
# [18:39] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [19:01] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [19:02] * Joins: teoli (~teoli@public.cloak)
# [19:20] * Joins: teoli_ (~teoli@public.cloak)
# [19:20] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [19:49] * Joins: glenn (~gadams@public.cloak)
# [19:56] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [20:01] <leaverou> SimonSapin: here?
# [20:09] * Joins: dbaron (~dbaron@public.cloak)
# [20:21] <SimonSapin> Hi leaverou
# [20:21] <leaverou> hi SimonSapin!!
# [20:21] <leaverou> You're the only paged media expert I know
# [20:21] <leaverou> so I have a question
# [20:21] <SimonSapin> sure
# [20:22] <leaverou> since the @page rule doesn't accept CSS rules inside it
# [20:22] <leaverou> how do you style an element differently based on whether it appears on a left or right page?
# [20:22] <SimonSapin> you can’t, with css-page-3
# [20:22] <SimonSapin> what are you trying to do?
# [20:23] <leaverou> add a sidebar
# [20:23] <leaverou> which should be on the left side on a left page
# [20:23] <leaverou> and on the right side on a right page
# [20:23] <SimonSapin> I see
# [20:23] <leaverou> this should be easy.
# [20:23] <SimonSapin> whose content is fragmented between paged like the main content?
# [20:23] <leaverou> if it isn't even possible, GCPM is seriously effed up
# [20:24] <leaverou> SimonSapin: no, sidebar blocks will be constrained in a single page
# [20:24] <leaverou> e.g. notes, figures etc
# [20:25] <SimonSapin> oh, ok
# [20:26] <SimonSapin> well, you can have a page margin different on left and right pages, to leave room for that
# [20:26] <leaverou> that's no use if I can't float differently
# [20:26] <SimonSapin> yeah
# [20:26] <leaverou> there are all kinds of weird stuff in the paged media specs and that incredibly common thing is not possible?!
# [20:27] <SimonSapin> I can’t think of a way
# [20:27] <leaverou> I'll post on www-style
# [20:27] <SimonSapin> and you’re right, it should be possible of not easy
# [20:27] <leaverou> should I tag it css3-gcpm or css3-page?
# [20:27] <leaverou> or sth else?
# [20:28] <SimonSapin> I’d say css-page-4
# [20:28] <SimonSapin> it’s not really "generated", and it won’t be in L3
# [20:28] <SimonSapin> and yes, GCPM is crazy
# [20:29] <SimonSapin> most parts are more like Håkon’s whish list than a spec
# [20:29] <leaverou> this is insane
# [20:29] <leaverou> I'll tag it css3-page, since it's a WD
# [20:30] <SimonSapin> feel free, but I don’t see it gaining new features
# [20:30] <SimonSapin> css3-page had been sitting around untouched since 2006
# [20:31] <leaverou> huh? A WD was published this March...
# [20:31] <SimonSapin> last year I rewrote one layout algorithm to be less insane, and did a general clean up with fantasai
# [20:32] <SimonSapin> it needs a bit more clean up, and then be published already
# [20:32] <SimonSapin> except that I’m not spending any time on it since I joined Mozilla
# [20:32] <SimonSapin> neither is anybody else
# [20:40] <SimonSapin> leaverou: you’re right that css-page desperately needs many more features, but there is just nobody actively working on it right now
# [20:41] <SimonSapin> I think glazou had some ideas, you could check with him
# [21:06] <SimonSapin> leaverou: that said, AntennaHouse might support stuff that is not in css-page-3
# [21:48] <leaverou> SimonSapin: yeah, that's what I'm hoping, otherwise I'm gonna shoot myself :P
# [21:49] <SimonSapin> eh
# [21:50] <SimonSapin> leaverou: "sidenotes" is the magic word http://www.antennahouse.com/xslfo/float-extension.htm#FootnoteCSS
# [21:53] <TabAtkins> plinss: Yo, I just realized that we might be able to solve the "associate a value with something else" problem more easily than an explicit attribute.
# [21:54] <TabAtkins> plinss: Bert's preprocessor has a microsyntax for linking text like "foo!!bar", which is used to indicate that "bar" (the thing being defined) is a subconcept of "foo". Currently this is only used for generating the index, to create sub-topics.
# [21:55] <TabAtkins> plinss: (I don't do this yet, but I want to.)
# [21:56] <TabAtkins> plinss: Perhaps we could just use that to infer connections? If a valuedef or typedef uses it, look at the "foo" and see if it's a type ("<foo>") or a property ("foo"). If a descdef uses it, assume the other value is an at-rule. Etc.
# [21:59] <plinss> that sounds reasonable, where does the foo!!bar come from?
# [22:00] <plinss> my one concern is name collisions, maybe there's a property 'foo' and a type 'foo' ...
# [22:02] <plinss> on another note, I found out that my plan for dom-<interface>-<atttr|method> ids won't work. Too many places its falls down, like the interface NamedFlow with the id: dom-named-flow
# [22:02] <plinss> also, not all methods have ()'s in the dfn
# [22:03] <plinss> I'm going to just parse the IDL and then do an association by name matching.
# [22:03] <plinss> TabAtkins: ^^^
# [22:18] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [22:29] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [22:38] * Quits: teoli_ (~teoli@public.cloak) (Client closed connection)
# [22:45] * Joins: teoli (~teoli@public.cloak)
# [22:58] * Joins: teoli_ (~teoli@public.cloak)
# [22:58] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# Session Close: Sun Jul 28 00:00:00 2013

The end :)