/irc-logs / w3c / #css / 2013-04-20 / end

Options:

# Session Start: Sat Apr 20 00:00:00 2013
# Session Ident: #css
# [00:23] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [00:34] <fantasai> plinss: There's a *lot* of spam accounts on wiki.csswg.org. Anything we can do about them?
# [00:34] <plinss> I just turned on the full captcha for the wiki yesterday
# [00:34] <fantasai> k
# [00:34] <plinss> I can go in and kill the accounts manually...
# [00:35] <plinss> have you seen any actual spam on the wiki itself?
# [00:36] <fantasai> nope
# [00:36] <fantasai> probably because all the top-level pages are locked-down
# [00:40] <krit> TabAtkins_: Is there a way to disallow quirks mode for content of certain functions?
# [00:40] <krit> TabAtkins_: (In CSS syntax.)
# [00:43] <TabAtkins_> krit: No.
# [00:43] <krit> TabAtkins_: k, thanks
# [00:44] <krit> TabAtkins_: Is <number> allowed for Color values in your quirks mode parsing?
# [00:45] <krit> TabAtkins_: if so, <number> | <color> should never be used in combination, right?
# [00:46] <krit> TabAtkins_: (It is allowed in quirks mode on the WebKit/Blink parser at least)
# [00:46] <TabAtkins_> krit: The color quirk is limited to color, background-color, and the border-color properties. Nothing else uses it.
# [00:46] <TabAtkins_> So you don't have to worry about it for new properties.
# [00:46] <TabAtkins_> Is that what you meant by your original question?
# [00:47] <krit> TabAtkins_: that was the direction I wanted to lead to, yes :)
# [00:47] <TabAtkins_> You should have just asked it. ^_^ (Or just looked at the spec: http://dev.w3.org/csswg/css-syntax/#consume-a-component-value-with-the-hashl )
# [00:47] <krit> :)
# [00:47] <TabAtkins_> Also: I'm removing those quirks from the Syntax spec. dbaron has convinced me that they instead belong in the individual properties affected by the quirk.
# [00:48] <TabAtkins_> Probably by defining a <loose-color> type that accepts <color> | <number> | <ident> | <dimension>.
# [00:48] <fantasai> huh?
# [00:49] <fantasai> since when is <number> a color?
# [00:49] <TabAtkins_> fantasai: Since forever, if you're in one of the six properties, and are in quirks mode.
# [00:49] <TabAtkins_> "color: 002200;" is valid and equivalent to "color: #002200;".
# [00:49] <fantasai> 123.56 is a color?
# [00:49] <TabAtkins_> Nope.
# [00:49] <fantasai> ah
# [00:49] <fantasai> you want <integer>
# [00:49] <fantasai> :)
# [00:49] <fantasai> and that's not the type you want
# [00:50] <fantasai> you don't want any integer, do you?
# [00:50] <TabAtkins_> Actually, I don't, because "1234e6" is a color, but not an <integer>.
# [00:50] <fantasai> or any ident
# [00:50] <fantasai> That's entirely your fault for adding scinot ^_^
# [00:50] <TabAtkins_> Whatevs.
# [00:50] <fantasai> I don't think you want 45t6 to be valid though
# [00:50] <fantasai> so your definition is wrong
# [00:51] <TabAtkins_> Sigh, yes, my syntax definition thrown out in a quick IRC message is incomplete.
# [00:52] * fantasai suggests defining it not as a combination of existing types
# [00:52] <TabAtkins_> Well, it'll definitely be prose-defined, not grammar-defined.
# [00:52] <TabAtkins_> fantasai: Hm, should I just add this to Values?
# [00:52] <TabAtkins_> <quirk-color> and <quirk-length>
# [00:52] <fantasai> <quirky-color>
# [00:52] <TabAtkins_> Yeah, quirky is better.
# [00:53] <fantasai> sure
# [00:53] <fantasai> and don't put it in any propdefs
# [00:53] <TabAtkins_> Values 3, or should I go ahead and start Values 4?
# [00:53] <TabAtkins_> Yeah.
# [00:53] <fantasai> just add a note at the very end of the section saying "In Quirks mode, this property accepts <quirky-length> instead of <length>."
# [00:53] <TabAtkins_> Yeah.
# [00:53] <fantasai> btw, workdays next week?
# [00:54] <TabAtkins_> Though that officially means 2.1 errata, since a lot of the properties are only defined there.
# [00:54] <fantasai> 2.1 doesn't define Quirks Mode
# [00:54] <fantasai> it's out of scope, not errata
# [00:54] <TabAtkins_> I'm best MWF next week.
# [00:54] <fantasai> Actually, can we just write a Quirks Mode module?
# [00:54] <fantasai> I think that's better
# [00:54] <TabAtkins_> zcorpan already has. ^_^
# [00:55] <fantasai> well let's publish it then ^_^
# [00:55] <TabAtkins_> I can write up a better definition of <quirky-color> and <quirky-length> and have him add them.
# [00:55] <fantasai> Yeah
# [00:55] <TabAtkins_> (The only non-trivial definition is line-height in the font shorthand.
# [00:55] <TabAtkins_> )
# [00:55] <fantasai> and then level 3 specs can refer to them like I propsed above
# [00:55] <TabAtkins_> Yeah.
# [00:55] <fantasai> and 2.1 will be covered by the quirks-mode module itself
# [00:55] <TabAtkins_> Sure.
# [00:57] <fantasai> Cool. Problem solved.
# [01:00] <fantasai> Let's have Quirks Mode also include the normative list of the properties that accept these (since they're all 2.1 bits)
# [01:01] <fantasai> CSS3 specs can just informatively point out the quirk
# [01:01] <fantasai> Quirks mode is thus fully defined, fully encapsulated, and adequately cross-referenced.
# [01:02] <fantasai> And then we can move onto the next easy problem, stacking contexts of table cells....
# [01:14] * Quits: sgalineau (~sgalineau@public.cloak) (Client closed connection)
# [01:27] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [01:37] <plinss> fantasai: so as I was going through deleting several hundred spam registrations on the wiki, I started noticing new ones showing up...
# [01:37] * Quits: lmclister (~lmclister@public.cloak) ("")
# [01:37] * Quits: plh3 (plehegar@public.cloak) ("Leaving")
# [01:37] <plinss> … apparently the captcha is pretty much useless
# [01:37] <plinss> … so I just disabled registrations on the wiki
# [01:38] <plinss> … legit users can register on shepherd (which spammers haven't found/can't register on yet)
# [01:39] * Quits: abucur (~abucur@public.cloak) ("Leaving")
# [01:54] <TabAtkins_> plinss: Or just ask us to register them, I suppose.
# [01:54] <TabAtkins_> plinss: But yeah, captchas are cheap to break with things like Mechanical Turk.
# [01:55] <TabAtkins_> plinss: I've put together my requirements for extracting cross-spec link targets. Do you still wanna handle this on your server, or should I do it on my own?
# [01:55] <plinss> what do you need?
# [01:56] <TabAtkins_> I just need something that'll periodically look for updated drafts and reparse them, and then expose a JSON document with all the link targets/linking text.
# [01:56] <TabAtkins_> Preferably in a simple flat way (yours is pretty nested, which is usable, but harder than needed).
# [01:56] <TabAtkins_> The selector to extract links is easy, too.
# [01:57] <plinss> well I already parse the specs and extract all the link targets
# [01:57] <TabAtkins_> I dont' want all the link targets. ^_^
# [01:57] <plinss> didn't you just say: "then expose a JSON document with all the link targets/linking text"?
# [01:58] <TabAtkins_> dfn[data-export], [data-export] dfn:not([data-noexport]), .propdef dfn:not([data-noexport]), .descdef dfn:not([data-noexport])
# [01:58] <TabAtkins_> All link targets matching that ^^^
# [01:59] <TabAtkins_> And while I can do post-processing to find uniques and collisions, it'd be awesome if that was already done and presented in the result document.
# [01:59] <plinss> ok, what exactly is that?
# [02:00] <TabAtkins_> That find all properties and descriptors, all terms explicitly marked for export, and all terms within a container marked for export.
# [02:02] <plinss> just to be clear, the above selectors are also actual link targets, as-in have ids or <a name='...'>
# [02:02] * Joins: rhauck (~Adium@public.cloak)
# [02:02] <TabAtkins_> They're all <dfn>s, which are automatically given ids by both my and Bert's processors.
# [02:02] <TabAtkins_> plinss: To be safe, I suppose you could add a [id] to each of the four, just in case.
# [02:02] <plinss> not necessary
# [02:03] <plinss> so I already find all the possible link targets and classify them (I have dfn and propdef types already)
# [02:03] <plinss> but it sounds link you want a sub-type of something like exported-dfn ?
# [02:04] <TabAtkins_> Sure, if that's how you'd like to organize it. I want to make exporting an opt-in decision, because I definitely use "local" definitions in my specs sometimes.
# [02:06] <plinss> I can add that to my parser fairly easily, so we might as well keep it all in one place...
# [02:06] <TabAtkins_> Cool.
# [02:06] <TabAtkins_> (Actually, it would probably be useful to have all dfns, and just flag with a warning when you link to a non-exported one.)
# [02:06] <plinss> btw, what's .descdef used for?
# [02:06] * Joins: tantek (~tantek@public.cloak)
# [02:07] <TabAtkins_> Descriptor definition tables, for at-rules with property-like contents.
# [02:07] <TabAtkins_> It's styled identically to a propdef in our stylesheet.
# [02:07] <plinss> ok
# [02:08] <TabAtkins_> I forget - does your data source also record the linking texts for each target?
# [02:08] <plinss> define "linking texts"
# [02:08] <TabAtkins_> For <dfn>foo</dfn>, "foo". For <dfn title="bar|baz">foo</dfn>, "bar" and "baz".
# [02:09] <TabAtkins_> The text that the autolinker uses to match terms to definitions.
# [02:09] <plinss> I definitely do the first case, lemme check on the title attr
# [02:10] <TabAtkins_> I have a slightly broken implementation of it in my processor. (Bert's allows you to use !! to define sub-terms, which I don't deal with yet.)
# [02:10] <TabAtkins_> (Mainly because I'm unsure how it actually works.)
# [02:10] <plinss> I don't currently grab the title attr, but that would be trivial to add
# [02:11] <TabAtkins_> It's required for autolinking to work, so it would be appreciated. ^_^
# [02:11] <plinss> on the "bar|baz" case do you really need that as a list?
# [02:12] <TabAtkins_> I *could* process it myself, but that seems silly if we're already parsing it apart.
# [02:12] <TabAtkins_> Just split it on "|".
# [02:13] <TabAtkins_> After all, the title attribute is only useful for the purpose of providing linking texts.
# [02:13] <TabAtkins_> (Also, note that providing the title attribute makes the text content no longer be a linking text.)
# [02:14] <plinss> it's not the parsing that I'm thinking of, it's the logical model. each anchor already has a title, using the title attr is trivial as I said, I'm unclear on what it means to have multiple titles
# [02:15] <TabAtkins_> It means that either an autolink with either link text will link up to that dfn.
# [02:16] <TabAtkins_> With <dfn title="bar|baz">foo</dfn>, both <a>bar</a> *and* <a>baz</a> get autolinked to the definition.
# [02:16] <TabAtkins_> (But <a>foo</a> won't, because the presence of a title overrides the normal linking text extraction behavior, which just uses the text content.)
# [02:16] <TabAtkins_> (In my processor, an <a> without an href is an autolink. In Bert's, it's any inline element other than <a>.)
# [02:17] <plinss> Ok, so I'm wondering if instead of overriding the current notion of anchor's 'title' (which is currently the text inside the anchor), I should maybe just add a link text field...
# [02:18] <TabAtkins_> Yes, that's the actual meaning for my purposes.
# [02:18] <plinss> ok, I'll do that then
# [02:19] <TabAtkins_> Cool.
# [02:20] <plinss> now for the types, I'm thinking I should just add an 'export' field rather than new anchor types, then you'll get exported 'dfn', 'propdef', and 'descdef' anchor types...
# [02:20] <plinss> with export: True/False
# [02:23] <TabAtkins_> What's the effect on the JSON structure? Each spec's entry has a 'dfn' field filled with a list of anchors?
# [02:25] <plinss> no each spec has a list of anchors, each has a type
# [02:25] <plinss> see: https://test.linss.com/shepherd/api/spec/?spec=css3-flexbox&anchors=1 for an example
# [02:26] <plinss> section anchors have a list of children
# [02:26] <plinss> although I can add a param to not do the nesting I suppose
# [02:26] <TabAtkins_> (btw, dns is failing for me to reach your server)
# [02:26] <TabAtkins_> I can process the nesting away if it's inconvenient for you.
# [02:26] <TabAtkins_> I'll need to do processing anyway.
# [02:26] <plinss> grr, sorry, that's my internal server, should be test.csswg.org
# [02:27] <TabAtkins_> (I need to reverse the relationship so I get a map from link text => url.)
# [02:27] <TabAtkins_> Do you only parse /TR, or hit up dev.w3.org as well?
# [02:28] <plinss> currently only /tr, but I'll be adding the drafts at some point in the not-too-distant future
# [02:29] <TabAtkins_> Cool. I'll need that before I can actually start using it. ^_^
# [02:29] <plinss> (note the uri in my json can be more than the fragment for multi-page specs)
# [02:29] <plinss> ok, timeframe?
# [02:29] <TabAtkins_> Also: I'll need a way to manually trigger a reparse of a given spec.
# [02:30] <TabAtkins_> I'm not in any hurry, but I'll add the functionality as soon as you give me the data.
# [02:30] <TabAtkins_> And make fantasai very happy. ^_^
# [02:30] <plinss> well we have to keep fantasai happy
# [02:30] <plinss> why do you need the manual re-parse trigger?
# [02:31] <TabAtkins_> So that, if I notice while writing spec A that I need to refer to something in spec B that isn't currently dfn'd, I can go edit spec B, trigger a reparse, pull down the new list of anchors, and get autolinking working.
# [02:32] <TabAtkins_> Rather than ahving to wait for your server to do its periodic sweep.
# [02:33] <plinss> ok, well the /TR specs generally get checked every night, when I add the drafts I was going to reparse on push
# [02:33] <plinss> but I can also make you an admin on shepherd and you can re-parse at will...
# [02:33] <plinss> there's already an admin ui for that
# [02:34] <plinss> (which also lets you add new specs)
# [02:34] <TabAtkins_> Making just me one probably won't help, since I want my processor to be usable by everyone...
# [02:34] <TabAtkins_> It's fine to have a chokepoint for adding new specs, but not for reparsing specs.
# [02:35] <plinss> do you need to parse specs that aren't in the drafts repo?
# [02:35] <TabAtkins_> Hm, good question. I guess not.
# [02:36] <plinss> so if it auto parses when someone pushes that should be sufficient, right?
# [02:36] <TabAtkins_> (I will need a way to link out to non-us specs, but I'm thinking of doing that by maintaining a map in the CSSWG repo, which anyone in CSS can edit.)
# [02:36] <TabAtkins_> Oh yeah, that'd be *ideal*.
# [02:36] <TabAtkins_> Also automatically handles permissions properly - only we get to flood your server. ^_^
# [02:36] <plinss> that was the plan for the drafts anyhow
# [02:36] <TabAtkins_> Cool.
# [02:37] * Joins: isherman-book (~Adium@public.cloak)
# [02:37] <plinss> (the server should be able to handle it, Linode keeps giving me free upgrades)
# [02:40] <TabAtkins_> We only push a few times a day, and parsing a single spec is the work of less than a second.
# [02:40] <plinss> about that yes
# [02:40] <plinss> do you only need the linking text on your exported dfn's?
# [02:41] <TabAtkins_> Depends. I'd be fine with just that. I was thinking about allowing linking to unexported dfns, but with a warning in the console output.
# [02:41] <TabAtkins_> But I won't be sad if I can't do that.
# [02:42] <plinss> I was just wondering if there's a use for the linking text on other anchor types…
# [02:44] * Quits: isherman-book (~Adium@public.cloak) ("Leaving.")
# [02:47] <TabAtkins_> plinss: Like I said, there could be a use for linking to <dfn>s that weren't explicitly exported. I'd just want to flag those with a warning when my processor hits them, because they might be local definitions that weren't meant to be linked to.
# [02:48] <plinss> right, but what I was asking is there a need/use for the linking text on other anchor types, like sections and <abbr>?
# [02:48] <TabAtkins_> Oh, no.
# [02:48] <plinss> ok
# [02:48] <TabAtkins_> Well, technically I allow local linking to headings, but I'm not sure that's a great idea.
# [02:49] <TabAtkins_> Not abbr, though - that's not an anchor.
# [02:49] <plinss> it is if it has an id...
# [02:49] <plinss> or is contained in or contains an <a name>
# [02:49] <plinss> and we do have those in some specs...
# [02:50] <TabAtkins_> Hm, I guess. I haven't seen them yet.
# [02:50] <TabAtkins_> Example?
# [02:50] <plinss> looking
# [02:50] <plinss> ok, maybe we don't :-)
# [02:50] <TabAtkins_> Haha.
# [02:51] <plinss> I was either being pedantic or I found it in a spec that isn't currently parsed by shepherd...
# [02:51] <plinss> (probably being pedantic)
# [02:51] <TabAtkins_> I mean, maybe that's reasonable? Letting someone denote a "defining" instance of an abbr, and other specs can just use an <abbr> without a title, so the processor fills it in for them.
# [02:53] <plinss> ok, so what I was thinking then is to maybe only populate the linking_text field with the contents of title attributes (split on '|') and otherwise you just use the title field
# [02:53] <plinss> that way I don't send the same data twice when there isn't a title attr
# [02:53] <plinss> and then I'll just capture them all
# [02:57] <TabAtkins_> So the linking_text field won't exist otherwise?
# [03:16] <plinss> either that or be null/false, do you have a preference?
# [03:17] <TabAtkins_> Depends on which is easier to deal with in the data structure that Python returns from parsed JSON. I think it does a simple Dict, so having it be missing would probably be easier.
# [03:18] <plinss> ok, that makes the json smaller anyhow...
# [03:18] <TabAtkins_> Yeah.
# [03:20] <plinss> do you have a preference for a separate internal/external field or different anchor types (propdef, propdef-internal, etc…)
# [03:20] <TabAtkins_> What's the distinction you're making?
# [03:22] <plinss> so currently all anchors have a type field: 'section', 'dfn', 'abbr', 'propdef', 'other'
# [03:23] <plinss> but you want to know the export status, so I can either add a new field, or new anchor types...
# [03:23] <TabAtkins_> Oh, new field - the "export: <bool>" think you mentioned up above.
# [03:23] <plinss> ok
# [03:24] <plinss> it looks like bare <dfn> are opt-in and propdef/descdef are opt-out right?
# [03:24] <TabAtkins_> Yes.
# [03:25] <TabAtkins_> And you can put [data-export] on a container to auto-opt-in all the contained dfns, unless they manually opt-out.
# [03:25] <TabAtkins_> (Useful for a <dl> of terms, for instance.)
# [03:25] <plinss> right, I saw that
# [03:26] <plinss> I was just wondering if there's a common case and maybe it's an 'internal' field that isn't there if exported...
# [03:29] <plinss> or if we should just have a bool on every anchor...
# [03:29] <TabAtkins_> As long as I can find all the exported anchors, do whatever makes you happy.
# [03:29] <plinss> k
# [03:29] <TabAtkins_> Like I said, I'll be parsing it into a completely new form anyway.
# [03:29] * Joins: glenn (~gadams@public.cloak)
# [03:30] <plinss> I'll see what the data looks like once I parse it and then tweak the json if needed
# [03:41] * Quits: tantek (~tantek@public.cloak) (tantek)
# [03:53] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [04:18] * leaverou is now known as leaverou_away
# [04:43] * Joins: krit (~krit@public.cloak)
# [04:58] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [05:08] * Joins: lmclister (~lmclister@public.cloak)
# [05:11] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [05:18] * Quits: lmclister (~lmclister@public.cloak) (Ping timeout: 60 seconds)
# [05:19] * Joins: lmclister (~lmclister@public.cloak)
# [06:05] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
# [06:14] * Joins: krit (~krit@public.cloak)
# [07:43] * Joins: SimonSapin (~simon@public.cloak)
# [07:53] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [08:29] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [09:19] * Joins: glenn (~gadams@public.cloak)
# [10:05] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [12:58] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 60 seconds)
# [13:13] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [16:02] * Joins: krit (~krit@public.cloak)
# [16:36] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
# [18:37] * Joins: SimonSapin (~simon@public.cloak)
# [20:05] * Joins: lmclister (~lmclister@public.cloak)
# [20:44] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 60 seconds)
# [21:00] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [21:11] * Quits: lmclister (~lmclister@public.cloak) ("")
# [22:17] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [22:21] * Joins: krit (~krit@public.cloak)
# [22:37] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [22:39] * Joins: lmclister (~lmclister@public.cloak)
# [22:53] * Quits: lmclister (~lmclister@public.cloak) ("")
# [22:59] * Joins: rhauck1 (~Adium@public.cloak)
# [23:01] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [23:22] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [23:37] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
# Session Close: Sun Apr 21 00:00:01 2013

The end :)